1. Simplified Extension of LSP Space for IS-IS draft-ietf-isis-wg-extlsp-00.txt Les Ginsberg Stefano Previdi Mike Shand

2. Problem Statement IS-IS LSP Space is generous but limited (256 * 1492) Adequate for advertising Reachability May not be adequate (someday) for advertisement of non-routing information MT support and/or aggressive inter-level leaking may exceed capacity

3. RFC 3786 Allows a system to be assigned additional system IDs and issue Extended LSPs Defined Alias System ID - TLV 24 Two Operating Modes: Mode 1 – Compatible w legacy routers Mode 2 –Not compatible w legacy routers

4. Issues w RFC 3786 To achieve full flexibility Mode 2 is desired – but requires: Utilize proper system ID to neighbors dependent on where IS neighbor will be advertised Not backwards compatible Real problems are: space consumed by non-routing info Potential explosion of leaf info (MT, leaking)

5. (not so)Simplified Proposal Utilizes Multiple System IDs and Alias System ID TLV like RFC 3786 Prohibits Neighbor TLVs except to Originating System – essentially Mode 1 of RFC 3786 Defines new TLVs to carry non-routing info associated w neighbors

6. © 2002, Cisco Systems, Inc. Company Confidential Changes since previous version Add support for advertising leaf information in extended LSPs Defines new TLVs to carry non-routing info associated w neighbors Define rules for considering non-routing info for the same object when multiple TLVs are required

7. © 2002, Cisco Systems, Inc. Company Confidential Topology R R` 0-> <-max-1 A LSP-R Neighbor A Neighbor R` (0) LSP-R` Alias TLV(R) Neighbor R (max-metric-1) LSP-A Neighbor R

8. © 2002, Cisco Systems, Inc. Company Confidential Extended LSP MUST HAVEs IS Neighbor to Originating System using Maxmetric-1 (MT support – for all topologies) Area Address(es) – same as Originating System OL, ATT, P bits MUST BE ZERO MT TLV (229) as necessary

9. © 2002, Cisco Systems, Inc. Company Confidential Normal LSP MUST HAVEs IS Neighbor to Virtual IS using metric of zero (MT support – for all topologies) MT TLV (229) – for all topologies w leaf info advertised in either normal or extended LSPs

10. © 2002, Cisco Systems, Inc. Company Confidential Extended LSP MUST NOT HAVEs No Neighbors other than to Originating System IS Neighbors (2) Extended IS Reachability (22) MT IS Neighbors (222) TLVs which MAY NOT appear in Extended LSPs: ES Neighbors (3) Part. DIS (4) Prefix Neighbors (5)

11. © 2002, Cisco Systems, Inc. Company Confidential Extended LSP MAY HAVE Leaf Information (avoid if possible) IP Int. Reach (128) IP Ext. Address (130) The extended IP reachability TLV (135) MT IP. Reach (235) IPv6 IP. Reach (236) MT IPv6 IP. Reach (237)

12. © 2002, Cisco Systems, Inc. Company Confidential New TLVs Alias TLV (24) – has system-id of originating system. IS Neighbor Attribute TLV (23) – identical to TLV 22 MT IS Neighbor Attribute TLV (223) – identical to TLV 222 Neighbor Attribute TLVs DO NOT establish a neighbor relationship!!!

13. © 2002, Cisco Systems, Inc. Company Confidential IS Neighbor Attribute TLVs May appear in any LSP (normal or extended) Handling multiple TLVs w the same context (e.g. link): No conflicts: TLVs are additive Conflicts: 1.Normal LSPs 2.Extended LSP w lowest system-id Overcomes 255 byte limitation

14. © 2002, Cisco Systems, Inc. Company Confidential Handling Neighbor Attribute Info in Multiple TLVs LSP-R TLV 23 Neighbor A-00 200.200.200.1 !Interface address 200.200.200.2 !Neighbor interface address 100 Mb !Maximum bandwidth LSP-R’ TLV 23 Neighbor A-00 200.200.200.1 !Interface address 200.200.200.2 !Neighbor interface address 100 Mb !Maximum bandwidth – not used 0x2 !GMPLS Link Protection

15. © 2002, Cisco Systems, Inc. Company Confidential OL and Leaf Info: Consistency w legacy behavior R R` 0-> <-max-1 A (legacy) B C 100 200.200.200/24

16. Advantages of Simplified Proposal Single Operating Mode No Change to handling of LSPs in SPF Backwards Compatible TLV “overflow” (>255/object) is easily accommodated

17. Limitations of Simplified Proposal Requires support for extended LSPs in support of non- routing info extensions (in the future) ( ) Requires new TLV for TE Info to achieve full separation of routing/non-routing info

18. Why Solve This Now? Existence of RFC 3786 may lead to deployments Alternative Solution will then be more costly/difficult