1 / 11

Protocol Topology Support for IS-IS

Protocol Topology Support for IS-IS. draft-ietf-noguchi-isis-protocol-topology-01.txt. Kay Noguchi <kay@ipinfusion.com>. 56th IETF San Francisco, CA, USA March 18, 2003. Contents. RFC 1195 Restrictions Goal New TLV and Sub-TLV Adjacency Formation LSP Encoding SPF Calculation

philantha-carlyn
Download Presentation

Protocol Topology Support for IS-IS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Protocol Topology Support for IS-IS draft-ietf-noguchi-isis-protocol-topology-01.txt Kay Noguchi <kay@ipinfusion.com> 56th IETF San Francisco, CA, USA March 18, 2003

  2. Contents • RFC 1195 Restrictions • Goal • New TLV and Sub-TLV • Adjacency Formation • LSP Encoding • SPF Calculation • Migration Mechanism

  3. RFC 1195 Restrictions • Every router MUST be capable of all network layer protocols that are present in an area. • Can’t mix IPv4 only and IPv6 only routers • Protocol Support capability MUST be identical on all interfaces. • Node oriented protocol support capability

  4. Goal • IPv4 only, IPv6 only and IPv4/IPv6 dual routers can co-exist. • By maintaining different SPF trees for each network layer protocols. • Different protocol support capability on each Interface • Interface oriented protocol support capability

  5. New TLV and Sub-TLV • Interface Protocols Supported TLV • Encoded in IS-IS Hello. • Convey interface oriented protocol support capability to neighboring routers. • Protocols Supported Sub-TLV • Encoded in Extended IS-Reachability TLV. • Flood interface oriented protocol support capability in the area.

  6. MUST drop IS-IS Hello which doesn’t contain Interface Protocols Supported TLV. To avoid possible routing loop. Point-to-Point Interfaces MUST NOT form an adjacency if at least one of the same protocol capability is not met with neighboring router. Broadcast Interfaces MUST attempt to form an adjacency regardless of the neighbor’s protocol capability. No change in DIS election. Adjacency Formation

  7. Use Protocols Supported Sub-TLV. Point-to-Point Interfaces ANDing local and remote side of protocol support capability. Broadcast Interfaces Regular LSP Local side of protocol support capability Pseudo-Node LSP Remote side of protocol support capability LSP Encoding

  8. SPF Calculation • SPF MUST be calculated separately for each network layer protocol. • New Protocol Supported Sub-TLV MUST be used instead of old Protocols Supported TLV. • Reverse protocol support check is not “MUST” because pseudo-node LSP also contains Protocol Supported Sub-TLV.

  9. Migration Mechanism • Start to advertise new TLV and Sub-TLV in addition to the old TLV. • Change adjacency formation and SPF calculation based on this draft. • Stop to advertise old TLV. • Change interface protocol support capability appropriately.

  10. Questions?

  11. Questions to M-ISIS • Non M-ISIS IPv4 router and M-ISIS IPv6 router. • How to make adjacency? • Non M-ISIS IPv4/IPv6 dual router and M-ISIS IPv4/IPv6 dual router. • Possible routing loop? • IPv6 Reachability TLV and MT Reachable IPv6 Prefixs(M-ISIS). • Do we need both?

More Related