Explicitly advertising the TE protocols enabled on links in OSPF Chris Bowers Shraddha Hegde Seoul, IETF97

SRLG-aware IPFRR using LDP or node-SIDs (LFA and RLFA) Shortest path before failure Local failure seen by S X Y X Y SRLG-implied remote failure W W SRLG-aware repair path Z Z D D Y-to-Z link shares an SRLG with link from S-to-X. SRLG-aware IP-FRR repair path for needs to use RLFA tunnel to W to avoid Y-to-Z link. S uses IGP advertisement from Y to determine SRLG of Y-to-Z link. This application of SRLG for IP-FRR was standardized in RFC 5286 (IPFRR/LFA): Section 3 and RFC 7916 (LFA Manageability): Section 6.2.4.1.

Using info in Link TLV in TE Opaque LSA for SRLG-aware IP-FRR Advertisements originated by router Y. Router LSA Advertising Rtr = Router-ID-Y # links = 3 Link Type = point-to-point Link ID = Router-ID-Z Link Data = 1.1.5.1 Metric = 10 Link ID = Router-ID-W Link Data = 1.1.9.1 Link ID = Router-ID-S Link Data = 1.1.1.2 S uses values in blue to correlate each Link TLV with each link in the Router LSA TE Opaque LSA Advertising Rtr = Router-ID-Y S 1.1.1.1 Link TLV Link type sub-TLV Point-to-Point 1.1.1.2 1.1.9.1 Link ID sub-TLV Link ID = Router-ID-Z X Y 1.1.5.1 1.1.9.2 Local Intf IP addr sub-TLV Local address = 1.1.5.1 W 1.1.5.2 Remote Intf IP addr sub-TLV Remote address = 1.1.5.2 RFC 5286: “Information about remote link SRLG membership may be dynamically obtained using [RFC4205] or [RFC4203].” Z SRLG sub-TLV 1001 D S learns the SRLGs of links from Y using the SRLG sub-TLV in the Link TLV of the TE Opaque LSA defined in RFC 4203 (OSPF) and RFC 4205 (ISIS). This is explicitly described in RFC 5286 (IPFRR/LFA): Section 3 and RFC 7916 (LFA Manageability): Section 6.2.4.1. This has been implemented and deployed in networks for several years. SRLG 1001

SRLG-aware TI-LFA using Node and Adj-SIDs Shortest path before failure Local failure seen by S X Y X Y SRLG-implied remote failure 1 2 1 2 SRLG-aware repair path Z Z D D Link 1 from Y-to-Z shares an SRLG with link from S-to-X. SRLG-aware FRR repair path for needs to use link 2 from Y-to-Z in order to avoid link 1. S needs to use IGP advertisements from Y to determine SRLGs on link 1 and 2 and adj-SIDs for link 1 and 2.

Using info in Link TLV and Extended Link TLV for SRLG-aware TI-LFA TE Opaque LSA Advertising Rtr = Router-ID-Y Link TLV Link type sub-TLV Point-to-Point Link ID sub-TLV Link ID = Router-ID-Z Local Intf IP addr sub-TLV Local address = 1.1.5.1 Remote Intf IP addr sub-TLV Remote address = 1.1.5.2 TE Opaque LSA Advertising Rtr = Router-ID-Y Link TLV Link type sub-TLV Point-to-Point Link ID sub-TLV Link ID = Router-ID-Z Local Intf IP addr sub-TLV Local address = 1.1.6.1 Remote Intf IP addr sub-TLV Remote address = 1.1.6.2 Correlated Link Information 1.1.1.1 Advertising Rtr = Router-ID-Y Link Type = point-to-point Link ID = Router-ID-Z Link Data/Local Addr = 1.1.5.1 Remote address = 1.1.5.2 SRLG=1001 Adj-SID Label = 2001 Router LSA Advertising Rtr = Router-ID-Y # links = 3 Link Type = point-to-point Link ID = Router-ID-Z Link Data = 1.1.5.1 Metric = 10 Link ID = Router-ID-W Link Data = 1.1.6.1 Link ID = Router-ID-S Link Data = 1.1.1.2 1.1.1.2 X Y 1.1.5.1 1.1.6.1 SRLG sub-TLV SRLG=1001 SRLG sub-TLV SRLG=1005 1.1.5.2 1.1.6.2 Advertising Rtr = Router-ID-Y Link Type = point-to-point Link ID = Router-ID-Z Link Data/Local Addr = 1.1.6.1 Remote address = 1.1.6.2 SRLG=1005 Adj-SID Label = 2001 Z Extended Link Opaque LSA Advertising Rtr = Router-ID-Y Extended Link TLV Link type = Point-to-Point Link ID = Router-ID-Z Link Data = 1.1.5.1 Adjacency-SID sub-TLV Label = 2001 Extended Link Opaque LSA Advertising Rtr = Router-ID-Y Extended Link TLV Link type = Point-to-Point Link ID = Router-ID-Z Link Data = 1.1.6.1 Adjacency-SID sub-TLV Label = 2002 D SRLG 1001 Implementations already make these correlations today.

Scenarios involving SR and RSVP in the same network SR only network No problem RSVP only network SR and RSVP both in the network on the same links SR on some links and RSVP on other links Short-term workaround Long-term solution

Interaction with RSVP S R L O X Y Z M P D N SR-only domain Y is advertising the Link TLV in the TE Opaque LSA for the two links from Y-to-Z. Therefore, assume that RSVP is enabled on those links. Include the links in CSPF computations and potentially try to signal RSVP LSPs across those links. SR-only domain RSVP-only domain S R RSVP ingress router This may not be the behavior desired by the operator. TE Opaque LSA Advertising Rtr = Router-ID-Y Extended Link Opaque LSA Advertising Rtr = Router-ID-Y Extended Link TLV Link type = Point-to-Point Link ID = Router-ID-Z Link Data = 1.1.5.1 Adjacency-SID sub-TLV Label = 2001 L O X Y Link TLV Link type sub-TLV Point-to-Point 1 2 Link ID sub-TLV Link ID = Router-ID-Z Local Intf IP addr sub-TLV Local address = 1.1.5.1 Z M P Remote Intf IP addr sub-TLV Remote address = 1.1.5.2 SRLG sub-TLV SRLG=1001 D SRLG 1001 N

Solution proposed in draft-hegde-ospf-advertising-te-protocols-00 Y is advertising the TE-protocol sub-TLV without the RSVP flag set for the two links from Y-to-Z. RSVP is not enabled on those links, so don’t include them in the CSPF and don’t try to signal RSVP LSPs across them. SR-only domain RSVP-only domain S R RSVP ingress router TE Opaque LSA Advertising Rtr = Router-ID-Y Extended Link Opaque LSA Advertising Rtr = Router-ID-Y Extended Link TLV Link type = Point-to-Point Link ID = Router-ID-Z Link Data = 1.1.5.1 Adjacency-SID sub-TLV Label = 2001 Link TLV Link type sub-TLV Point-to-Point L O X Y Link ID sub-TLV Link ID = Router-ID-Z Local Intf IP addr sub-TLV Local address = 1.1.5.1 1 2 Remote Intf IP addr sub-TLV Remote address = 1.1.5.2 SRLG sub-TLV SRLG=1001 Z M P TE protocol sub-TLV RSVP = NOT enabled SR = enabled Use new TE-protocol sub-TLV to explicitly indicate if RSVP is enabled on a link or not. D N

Solution proposed in draft-ppsenak-ospf-te-link-attr-reuse-03 SR-only domain RSVP-only domain TE Opaque LSA Advertising Rtr = Router-ID-Y Extended Link Opaque LSA Advertising Rtr = Router-ID-Y S R Link TLV Extended Link TLV Link type = Point-to-Point Link ID = Router-ID-Z Link Data = 1.1.5.1 Link type sub-TLV Point-to-Point RSVP ingress router Link ID sub-TLV Link ID = Router-ID-Z Adjacency-SID sub-TLV Label = 2001 Local Intf IP addr sub-TLV Local address = 1.1.5.1 L O X Y Remote Intf IP addr sub-TLV Remote address = 1.1.5.2 Local Intf IP addr sub-TLV Local address = 1.1.5.1 SRLG sub-TLV SRLG=1001 Remote Intf IP addr sub-TLV Remote address = 1.1.5.2 1 2 SRLG sub-TLV SRLG=1001 Z M P Move all needed information from the Link TLV in the TE Opaque LSA to the Extended Link TLV in the Extended Link Opaque LSA. No longer advertise the Link TLV. D N

Problems with solution proposed in draft-ppsenak-ospf-te-link-attr-reuse-03 TE Opaque LSA Advertising Rtr = Router-ID-Y Extended Link Opaque LSA Advertising Rtr = Router-ID-Y Operator needs RSVP and SR to co-exist on the same link. Link TLV Extended Link TLV Link type = Point-to-Point Link ID = Router-ID-Z Link Data = 1.1.5.1 Link type sub-TLV Point-to-Point Link ID sub-TLV Link ID = Router-ID-Z Adjacency-SID sub-TLV Label = 2001 S R Local Intf IP addr sub-TLV Local address = 1.1.5.1 Remote Intf IP addr sub-TLV Remote address = 1.1.5.2 Local Intf IP addr sub-TLV Local address = 1.1.5.1 SRLG sub-TLV SRLG=1001 Remote Intf IP addr sub-TLV Remote address = 1.1.5.2 Maximum BW sub-TLV 10G SRLG sub-TLV SRLG=1001 L O X Y Max Reservable BW sub-TLV Priority 0 = 5G Unreserved BW sub-TLV Priority 0 = 3G 1 2 Y needs to advertise both the Link TLV in the TE Opaque LSA and the Extended Link TLV in the Extended Link Opaque LSA. In this example, Local/Remote Interface IP address sub-TLVs and SRLG sub-TLV are duplicated. How should S and R interpret this duplicated information in the event of a conflict? Current text does not clearly address this scenario. Rules for dealing with duplicated information are usually complicated. Better to not duplicate the information in the first place. Z M P D N

draft-hegde-ospf-advertising-te-protocols-00 does not have this problem. TE Opaque LSA Advertising Rtr = Router-ID-Y Extended Link Opaque LSA Advertising Rtr = Router-ID-Y Operator wants RSVP and SR co-exist on the same link. Link TLV Extended Link TLV Link type = Point-to-Point Link ID = Router-ID-Z Link Data = 1.1.5.1 Link type sub-TLV Point-to-Point Link ID sub-TLV Link ID = Router-ID-Z S Adjacency-SID sub-TLV Label = 2001 R Local Intf IP addr sub-TLV Local address = 1.1.5.1 Remote Intf IP addr sub-TLV Remote address = 1.1.5.2 SRLG sub-TLV SRLG=1001 Maximum BW sub-TLV 10G L O X Y Max Reservable BW sub-TLV Priority 0 = 5G Unreserved BW sub-TLV Priority 0 = 3G 1 2 TE protocol sub-TLV RSVP = enabled SR = enabled Z M P No information is duplicated, so there is no possibility of conflicting information that needs to be resolved. D N

Comparison of two proposed solutions draft-hegde-ospf-advertising-te-protocols draft-ppsenak-ospf-te-link-attr-reuse-03 SR-only network No problem RSVP-only network SR on some links and RSVP on other links Addresses problem SR and RSVP both in the network on the same links Creates new problems Existing deployments of RLFA that use SRLG info

A potential new bandwidth-related sub-TLV for SR-TE For example, it may be useful to define a new bandwidth related sub-TLV: “Bandwidth Usable for SR-TE” If we standardize a new “Bandwidth Usable for SR-TE” sub-TLV, we should decide whether it goes in the Link TLV or the Extended Link TLV. New attributes can make use of the Extended Link TLV if that makes sense. However, we shouldn’t move attributes that have been defined for the Link TLV to the Extended Link TLV. TE Opaque LSA Advertising Rtr = Router-ID-Y Extended Link Opaque LSA Advertising Rtr = Router-ID-Y Link TLV Extended Link TLV Link type = Point-to-Point Link ID = Router-ID-Z Link Data = 1.1.5.1 Link type sub-TLV Point-to-Point Link ID sub-TLV Link ID = Router-ID-Z Adjacency-SID sub-TLV Label = 2001 Local Intf IP addr sub-TLV Local address = 1.1.5.1 Remote Intf IP addr sub-TLV Remote address = 1.1.5.2 BW Usable for SR-TE 3G SRLG sub-TLV SRLG=1001 Maximum BW sub-TLV 10G Max Reservable BW sub-TLV Priority 0 = 5G Unreserved BW sub-TLV Priority 0 = 3G TE protocol sub-TLV RSVP = enabled SR = enabled

Potentially useful new sub-TLV: “bandwidth usable for SR-TE” Max link bandwidth = 10G 10G Explicitly leaves bandwidth non-SR-TE (shortest path routed) traffic. SR controller uses “bandwidth usable for SR-TE” to compute available bandwidth for SR LSPs. SR LSP 4 SR LSP 3 Bandwidth available for SR = 6G SR LSP 2 SR LSP 1 1 2 3 4 5 6 7

Carving up bandwidth for RSVP-TE and SR-TE on the same link link bandwidth = 10G 10G SR LSP 1 Bandwidth available for SR-TE = 3G SR controller uses “bandwidth usable for SR-TE” to compute bandwidth usable for SR-TE LSPs. SR LSP 2 Explicitly leaves bandwidth for other traffic. 5 Maximum (RSVP) reservable link bandwidth = 6G RSVP LSP 4 Unreserved Bandwidth Priority 0 unreserved bandwidth = 1G Priority 1 unreserved bandwidth = 2G … RSVP LSP 3 RSVP LSP 2 RSVP LSP 1 0G 1 2 3 4 5 6 7