advertising generic information in is-is draft-ietf-isis-genapp-00.txt les ginsberg stefano previdi...
TRANSCRIPT
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?