Advertising Generic Information in IS-IS

draft-ietf-isis-genapp-00.txtLes Ginsberg

Stefano Previdi

Mike Shand

Changes since previous version

• Now a WG document

• Standards track

• Applicability statement

Applicability Statement

“The GENINFO TLV supports the advertisement of application specific information in IS-IS LSPs which is not directly related to the operation of the IS-IS protocol. Information which is not directly used by the IS-IS Decision process falls into this category. The Decision Process is defined by [ISO10589] and extended by [RFC1195] and [RFC3906].”

Applicability Statement

• May be interpreted to cover existing information

• Migration to use of GENAPP is seen as desirable

• WG is the authority

What existing info MIGHT

be candidates for GENAPP?

• TE/G-MPLS sub-TLV info (from TLVs 22/23/222/223)

• TE Mesh Group sub-TLV (TLV 242)

• PCE sub-TLV info (TLV 242)

Ready for Last Call

IS-IS and BFD

draft-ietf-isis-bfd-tlv-00.txtChris Hopps

Les Ginsberg

Changes since previous version

• Now a WG document

• Standards track

• TLV now includes MTID

Problem Statement

• BFD used to detect IPv4/IPv6 forwarding failures

• IS-IS PDUs do not always share fate with IP packets

• Adjacencies may be established even when IP forwarding problems are detectable

A BIP

IS-IS

1. IS-IS PDUs exchanged

2. Adjacency UP

3. BFD session requested (neighbor IP address)

If BFD session doesn’t come up could be:

• IP forwarding failure

• No BFD Config/Support

Advertise support for BFD in IIHsType 139 (proposed) Length # of octets in the value field (1 to 255) Value: No. of octets +-----------------------------+ |R|R|R|R| MTID | 2 +-----------------------------+ | NLPID | 1 +-----------------------------+ : : +-----------------------------+ |R|R|R|R| MTID | 2 +-----------------------------+ | NLPID | 1 +------------------------------+

Why was MTID Added?

• BFD sessions apply to specific topologies

• NLPIDs are not SAFI specific

When BFD is supported by both neighbors…

• Hold adjacency in Init state until BFD session is UP

• Bring adjacency down when BFD session goes down

• P2P – 3 way state is DOWN when BFD is down

• LAN – omit neighbor MAC address when BFD is down

Determining when new rules apply

For each MTID/NLPID shared by the neighbors, if BFD support is configured for both neighbors, BFD session must be UP to use that topology

At least one topology must be “useable” in order for adjacency to come up

A BIP

IS-IS

MTID: 0(IPv4), 2(IPv6)

BFD: 0/IPv4, 2/IPv6

MTID: 0 (IPv4)

BFD: 0/IPv4

IPv4 BFD Session MUST be UP before adjacency comes up.

A BIP

IS-IS

MTID: 0(IPv4), 0(IPv6)

BFD: 0/IPv4, 2/IPv6

MTID: 0 (IPv4,IPv6)

BFD: 0/IPv4

Single Topology/Multiple AFIs

IPv4 Session MUST be UP before adjacency comes up.

A BIP

IS-IS

MTID: 0 (IPv4), 2 (IPv6)

BFD: 0/IPv4, 2/IPv6

MTID: 0 (IPv4), 2 (IPv6)

BFD: 0/IPv4

Multi-topology (one AFI/topology)

Normal adjacency establishment rules.

IPv4 BFD Session MUST be UP for MTID #0 to be useable.

Transition – enable BFD

Detected by addition of NLPID in BFD-TLV

For existing adjacencies, do not update hold time on receipt of IIH until BFD session is UP

A BIP

IS-IS

MTID: 0 (IPv4)

BFD: 0/IPv4

MTID: 0 (IPv4)

BFD: 0/IPv4

1. Adjacency is Up

2. B configures IPv4 BFD support

3. IIH from B includes BFD-TLV for MTID 0/IPv4 – hold time not updated

4. BFD session comes up

5. Normal hold time update resumes

Transition – disable BFD

Detected by transition of BFD session state to admin down

For existing adjacencies, do not update hold time on receipt of IIH until corresponding NLPID is no longer advertised in BFD-TLV

A BIP

IS-IS

MTID: 0 (IPv4)

BFD: 0/IPv4

MTID: 0 (IPv4)

BFD: 0/IPv4

1. Adjacency is Up/BFD session Up

2. B deconfigures IPv4 BFD support

3. IPv4 BFD session admin down on A

4. IIH from B has no BFD-TLV for MTID 0/IPv4

5. Normal hold time update resumes

Questions?