Explicitly advertising the TE protocols enabled on links in ISIS Chris Bowers Shraddha Hegde Paul Mattes Mohan Nanduri Spencer Giacalone Imtiyaz Mohammad Seoul, IETF97

SR centralized bandwidth accounting application SR ingress router 20 20 40 10 Y Z X S D R M N O P Program SR label stacks R S 30 20 20 20 10G 30 10 30 20 40G 20G 20G X SR controller Y O centralized bandwidth accounting for SR LSPs 20G 20G 30G 20G Advertisement from Y LSPDU Source = SYS-ID-Y Z M P Extended IS Reach TLV (22) Neighbor = SYS-ID-Z Metric = 10 Learn topology via BGP-LS (including link bandwidth) 30G IPv4 intf addr sub-TLV (6) Local address = 1.1.5.1 10G 20G 30G IPv4 Nbr addr sub-TLV (8) Local address = 1.1.5.2 D N Maximum link BW sub-TLV (9) 30G

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

RSVP may also be running in the network RSVP may also be running in the network. How does an RSVP ingress router figure out that a remote link has RSVP enabled on it? This was never actually standardized for either ISIS or OSPF. For ISIS, different implementations have used different criteria. RSVP ingress router R S LSPDU Source = SYS-ID-Y Extended IS Reach TLV (22) Neighbor = SYS-ID-Z Metric = 10 X Y O Link of interest IPv4 intf addr sub-TLV (6) Local address = 1.1.5.1 IPv4 Nbr addr sub-TLV (8) Local address = 1.1.5.2 Z Maximum link BW sub-TLV (9) 30G M P Max reservable BW sub-TLV (10) 25G D Unreserved BW sub-TLV (11) Priority 0 = 12G N

For a given implementation, does the presence of a particular ISIS TLV/sub-TLV for a link trigger inclusion in the traffic-engineering database of that link for use by CSPF to find paths to signal using RSVP? TLV / sub-TLV X Y Z Superset of TLV/sub-TLVs that trigger RSVP 22 (Extended IS Reachability TLV, includes wide metrics in TLV) No 22 / 3 (Admin Group) Yes 22 / 4 (Link Local/Remote Id) 22 / 6 (IPv4 Interface Address) 22 / 8 (IPv4 Neighbor Address) 22 / 9 (Max Link Bandwidth) 22 / 10 (Max Reservable Link Bandwidth) 22 / 11 (Unreserved Bandwidth) 22 / 14 (Extended Admin Group) 22 / 18 (TE Default metric) 22/20 Link Protection Type 22/21 Interface Switching Capability 22/22 TE Bandwidth Constraints 22/33-39 TE Metric Extensions from RFC7810 138 (SRLG TLV) Implementation

SR on some links and RSVP on other links For some implementations, R will assume that RSVP is enabled on Y-to-Z link, due to presence of Max link BW sub-TLV. Network operator may not want Y-to-Z link to be used for RSVP. SR ingress router RSVP ingress router 20 20 40 10 Y Z X S D R M N O P Program SR label stacks R S 30 20 20 20 30 10 30 20 40G 20G 10G 20G X SR controller Y O centralized bandwidth accounting for SR LSPs 20G 20G 30G 20G Advertisement from Y LSPDU Source = SYS-ID-Y Z M P Extended IS Reach TLV (22) Neighbor = SYS-ID-Z Metric = 10 Learn topology via BGP-LS (including link bandwidth) 30G IPv4 intf addr sub-TLV (6) Local address = 1.1.5.1 10G 20G 30G IPv4 Nbr addr sub-TLV (8) Local address = 1.1.5.2 D N Maximum link BW sub-TLV (9) 30G

Short term workaround using administrative groups RSVP ingress router Operator configures routers to advertise administrative group 4 for those links without RSVP enabled. Operator configures constraints on R to exclude links with administrative group 4 from CSPF for RSVP LSPs. Administrative group chosen to mean RSVP-not-enabled-on-link is local to network, not assigned by IETF. R S 40G 20G 10G 20G X Y O Advertisement from Y 20G 20G 30G 20G LSPDU Source = SYS-ID-Y Extended IS Reach TLV (22) Neighbor = SYS-ID-Z Metric = 10 IPv4 intf addr sub-TLV (6) Local address = 1.1.5.1 Z M P 30G IPv4 Nbr addr sub-TLV (8) Local address = 1.1.5.2 Maximum link BW sub-TLV (9) 30G 10G 30G 20G D administrative group 4 (defined by operator to mean RSVP-not-enabled-on-link) administrative group sub-TLV(3) 0….0100 N

Long term solution using TE protocol sub-TLV RSVP ingress router Operator configures routers to advertise administrative group 4 for those links without RSVP enabled. Operator configures constraints on R to exclude links with administrative group 4 from CSPF for RSVP LSPs. Administrative group chosen to mean RSVP-not-enabled-on-link is local to network, not assigned by IETF. R S 40G 20G 10G 20G X Y O 20G Advertisement from Y Advertisement from Y 20G 30G 20G LSPDU Source = SYS-ID-Y LSPDU Source = SYS-ID-Y Extended IS Reach TLV (22) Neighbor = SYS-ID-Z Metric = 10 Extended IS Reach TLV (22) Neighbor = SYS-ID-M Metric = 10 Z M P 30G IPv4 intf addr sub-TLV (6) Local address = 1.1.5.1 IPv4 intf addr sub-TLV (6) Local address = 1.1.8.1 10G 30G 20G IPv4 Nbr addr sub-TLV (8) Local address = 1.1.5.2 IPv4 Nbr addr sub-TLV (8) Local address = 1.1.82 D N Maximum link BW sub-TLV (9) 30G Maximum link BW sub-TLV (9) 20G TE protocol sub-TLV (TBD) RSVP = NOT enabled TE protocol sub-TLV (TBD) RSVP = enabled RSVP enabled RSVP not 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