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

2. 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

3. 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 =
Metric = 10
Link ID = Router-ID-W
Link Data =
Link ID = Router-ID-S
Link Data =
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
Link TLV
Link type sub-TLV
Point-to-Point
Link ID sub-TLV
Link ID = Router-ID-Z X Y
Local Intf IP addr sub-TLV
Local address = W
Remote Intf IP addr sub-TLV
Remote address =
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
This has been implemented and deployed in networks for several years.
SRLG 1001

4. 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.

5. 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 =
Remote Intf IP addr sub-TLV
Remote address =
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 =
Remote Intf IP addr sub-TLV
Remote address =
Correlated Link Information
Advertising Rtr = Router-ID-Y
Link Type = point-to-point
Link ID = Router-ID-Z
Link Data/Local Addr = Remote address =
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 =
Metric = 10
Link ID = Router-ID-W
Link Data =
Link ID = Router-ID-S
Link Data = X Y
SRLG sub-TLV
SRLG=1001
SRLG sub-TLV
SRLG=1005
Advertising Rtr = Router-ID-Y
Link Type = point-to-point
Link ID = Router-ID-Z
Link Data/Local Addr = Remote address =
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 =
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 =
Adjacency-SID sub-TLV
Label = 2002 D
SRLG 1001
Implementations already make these correlations today.

6. 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

7. 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 =
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 = Z M P
Remote Intf IP addr sub-TLV
Remote address =
SRLG sub-TLV
SRLG=1001 D
SRLG 1001 N

8. 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 =
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 2
Remote Intf IP addr sub-TLV
Remote address =
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

9. 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 =
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 = L O X Y
Remote Intf IP addr sub-TLV
Remote address =
Local Intf IP addr sub-TLV
Local address =
SRLG sub-TLV
SRLG=1001
Remote Intf IP addr sub-TLV
Remote address = 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

10. 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 =
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 =
Remote Intf IP addr sub-TLV
Remote address =
Local Intf IP addr sub-TLV
Local address =
SRLG sub-TLV
SRLG=1001
Remote Intf IP addr sub-TLV
Remote address =
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

11. 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 =
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 =
Remote Intf IP addr sub-TLV
Remote address =
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

12. 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

13. 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 =
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 =
Remote Intf IP addr sub-TLV
Remote address =
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

14. 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

15. 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