Simplified Extension of LSP Space for IS-IS

draft-ietf-isis-wg-extlsp-00.txtLes Ginsberg

Stefano Previdi

Mike Shand

Problem Statement

IS-IS LSP Space is generous but limited (256 * 1492)

Adequate for advertising ReachabilityMay not be adequate (someday) for

advertisement of non-routing informationMT support and/or aggressive inter-level

leaking may exceed capacity

RFC 3786

Allows a system to be assigned additional system IDs and issue Extended LSPs

Defined Alias System ID - TLV 24Two Operating Modes:

Mode 1 – Compatible w legacy routersMode 2 –Not compatible w legacy routers

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)

(not so)Simplified ProposalUtilizes 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

© 2002, Cisco Systems, Inc. Company Confidential

Changes since previous versionAdd 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

© 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

© 2002, Cisco Systems, Inc. Company Confidential

Extended LSP MUST HAVEsIS 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

© 2002, Cisco Systems, Inc. Company Confidential

Normal LSP MUST HAVEsIS 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

© 2002, Cisco Systems, Inc. Company Confidential

Extended LSP MUST NOT HAVEs

No Neighbors other than to Originating SystemIS 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)

© 2002, Cisco Systems, Inc. Company Confidential

Extended LSP MAY HAVELeaf 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)

© 2002, Cisco Systems, Inc. Company Confidential

New TLVsAlias TLV (24) – has system-id of originating

system.IS Neighbor Attribute TLV (23) – identical to TLV 22MT IS Neighbor Attribute TLV (223) – identical to

TLV 222

Neighbor Attribute TLVs DO NOT establish a neighbor relationship!!!

© 2002, Cisco Systems, Inc. Company Confidential

IS Neighbor Attribute TLVsMay appear in any LSP (normal or extended)

Handling multiple TLVs w the same context (e.g. link):

No conflicts: TLVs are additiveConflicts:

1. Normal LSPs2. Extended LSP w lowest system-id

Overcomes 255 byte limitation

© 2002, Cisco Systems, Inc. Company Confidential

Handling Neighbor Attribute Info in Multiple TLVs

LSP-R

TLV 23Neighbor A-00200.200.200.1 !Interface address200.200.200.2 !Neighbor interface address100 Mb !Maximum bandwidth

LSP-R’

TLV 23Neighbor A-00200.200.200.1 !Interface address200.200.200.2 !Neighbor interface address100 Mb !Maximum bandwidth – not used0x2 !GMPLS Link Protection

© 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

Advantages of Simplified Proposal

Single Operating ModeNo Change to handling of LSPs in SPFBackwards CompatibleTLV “overflow” (>255/object) is easily accommodated

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

Why Solve This Now?

Existence of RFC 3786 may lead to deployments

Alternative Solution will then be more costly/difficult