Title: Advertising Generic Information in IS-IS
1Advertising Generic Information in IS-IS
- draft-ietf-isis-genapp-00.txt
- Les Ginsberg
- Stefano Previdi
- Mike Shand
2Changes since previous version
- Now a WG document
- Standards track
- Applicability statement
3Applicability 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.
4Applicability Statement
- May be interpreted to cover existing information
- Migration to use of GENAPP is seen as desirable
- WG is the authority
5What 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)
6Ready for Last Call
7IS-IS and BFD
- draft-ietf-isis-bfd-tlv-00.txt
- Chris Hopps
- Les Ginsberg
8Changes since previous version
- Now a WG document
- Standards track
- TLV now includes MTID
9Problem 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
10- IS-IS PDUs exchanged
- Adjacency UP
- BFD session requested (neighbor IP address)
- If BFD session doesnt come up could be
- IP forwarding failure
- No BFD Config/Support
11Advertise support for BFD in IIHs
Type 139 (proposed) Length of octets in the
value field (1 to 255) Value
No. of octets
-----------------------------
RRRR MTID 2
-----------------------------
NLPID 1
-----------------------------
-----------------------------
RRRR MTID 2
-----------------------------
NLPID 1
------------------------------
12Why was MTID Added?
- BFD sessions apply to specific topologies
- NLPIDs are not SAFI specific
13When 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
14Determining 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
15MTID 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.
16MTID 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.
17MTID 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.
18Transition 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
19MTID 0 (IPv4) BFD 0/IPv4
MTID 0 (IPv4) BFD 0/IPv4
- Adjacency is Up
- B configures IPv4 BFD support
- IIH from B includes BFD-TLV for MTID 0/IPv4
hold time not updated - BFD session comes up
- Normal hold time update resumes
20Transition 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
21MTID 0 (IPv4) BFD 0/IPv4
MTID 0 (IPv4) BFD 0/IPv4
- Adjacency is Up/BFD session Up
- B deconfigures IPv4 BFD support
- IPv4 BFD session admin down on A
- IIH from B has no BFD-TLV for MTID 0/IPv4
- Normal hold time update resumes
22Questions?