Advertising Generic Information in IS-IS draft-ietf-isis-genapp-00.txt Les 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.txt Chris 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 B IP IS-IS 1.IS-IS PDUs exchanged 2.Adjacency UP 3.BFD session requested (neighbor IP address) If BFD session doesnt come up could be: IP forwarding failure No BFD Config/Support

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

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 B IP 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 B IP 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 B IP 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 B IP 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 B IP 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?