IS-IS IPv4/IPv6 SR-TE and IPv4 RSVP-TE Feature Behavior

The TE feature in IS-IS allows the advertising router to indicate to other routers in the TE domain which applications the advertising router has enabled: RSVP-TE, SR-TE, or both. As a result, a receiving router can safely prune links that are not enabled in one of the applications from the topology when computing a CSPF path in that application.

TE behavior consists of the following steps.

  1. A valid IPv6 address value must exist for the system or loopback interface assigned to the ipv6-te-router-id command. The IPv6 address value can be either the preferred primary global unicast address of the system interface (default value) or that of a loopback interface (user configured).

    The IPv6 TE router ID is mandatory for enabling IPv6 TE and enabling the router to be uniquely identified by other routers in an IGP TE domain as being IPv6 TE capable. If a valid value does not exist, then the IPv6 and TE TLVs described in IS-IS, BGP-LS and TE Database Extensions are not advertised.

  2. The traffic-engineering command enables the existing traffic engineering behavior for IPv4 RSVP-TE and IPv4 SR-TE. Enable the rsvp context on the router and enable rsvp on the interfaces in order to have IS-IS begin advertising TE attributes in the legacy TLVs. By default, the rsvp context is enabled as soon as the mpls context is enabled on the interface. If ipv6 knob is also enabled, then the RFC 6119 IPv6 and TE link TLVs described above are advertised such that a router receiving these advertisements can compute paths for IPv6 SR-TE LSP in addition to paths for IPv4 RSVP-TE LSP and IPv4 SR-TE LSP. The receiving node cannot determine if truly IPv4 RSVP-TE, IPv4 SR-TE, or IPv6 SR-TE applications are enabled on the other routers. Legacy TE routers must assume that RSVP-TE is enabled on those remote TE links it received advertisements for.

  3. When the ipv6 command is enabled, IS-IS automatically begins advertising the RFC 6119 TLVs and sub-TLVs: IPv6 TE router ID TLV, IPv6 interface Address sub-TLV and Neighbor Address sub-TLV, or Link-Local Interface Identifiers sub-TLV if the interface has no global unicast IPv6 address. The TLVs and sub-TLVs are advertised regardless of whether TE attributes are added to the interface in the mpls context. The advertisement of these TLVs is only performed when the ipv6 knob is enabled and ipv6-routing is enabled in this IS-IS instance and ipv6-te-router-id has a valid IPv6 address.

    A network IP interface is advertised with the Link-Local Interface identifiers sub-TLV if the network IP interface meets the following conditions:

    • network IP interface has link-local IPv6 address and no global unicast IPv6 address on the interface ipv6 context

    • network IP interface has no IPv4 address and may or may not have the unnumbered option enabled on the interface ipv4 context

  4. The application-link-attributes command enables the ability to send the link TE attributes on a per-application basis and explicitly conveys that RSVP-TE or SR-TE is enabled on that link on the advertising router.

    Three modes of operation that are allowed by the application-link-attributes command.

    1. Legacy Mode: {no application-link-attributes}

      The application-link-attributes command is disabled by default and the no form matches the behavior described in list item 2. It enables the existing traffic engineering behavior for IPv4 RSVP-TE and IPv4 SR-TE. Only the RSVP-TE attributes are advertised in the legacy TE TLVs that are used by both RSVP-TE and SR-TE LSP CSPF in the TE domain routers. No separate SR-TE attributes are advertised.

      If the ipv6 command is also enabled, then the RFC 6119 IPv6 and TE link TLVs are advertised in the legacy TLVs. A router in the TE domain receiving these advertisements can compute paths for IPv6 SR-TE LSP.

      If the user shuts down the rsvp context on the router or on a specific interface, the legacy TE attributes of all the MPLS interfaces or of that specific MPLS interface are not advertised. Routers can still compute SR-TE LSPs using those links but LSP path TE constraints are not enforced since the links appear in the TE Database as if they did not have TE parameters.

      Table 1 shows the encoding of the legacy TE TLVs in both IS-IS and BGP-LS.

    2. Legacy Mode with Application Indication: {application-link-attributes + legacy}

      The legacy with application indication mode is intended for cases where link TE attributes are common to RSVP-TE and SR-TE applications and have the same value, but the user wants to indicate on a per-link basis which application is enabled.

      IS-IS continues to advertise the legacy TE attributes for both RSVP-TE and SR-TE application and includes the new Application Specific Link Attributes TLV with the application flag set to RSVP-TE and/or SR-TE but without the sub-sub-TLVs. IS-IS also advertises the Application Specific SRLG TLV with the application flag set to RSVP-TE and/or SR-TE but without the actual values of the SRLGs.

      Routers in the TE domain use these attributes to compute CSPF for IPv4 RSVP-TE LSP and IPv4 SR-TE LSP.

      If the ipv6 command is also enabled, then the RFC 6119 IPv6 and TE TLVs are advertised. A router in the TE domain that receives these advertisements can compute paths for IPv6 SR-TE LSP.

      Note: The segment-routing command must be enabled in the IS-IS instance or the flag for the SR-TE application will not be set in the Application Specific Link Attributes TLV or in the Application Specific SRLG TLV.

      To disable advertising of RSVP-TE attributes, shut down the rsvp context on the router. Note, however, doing so reverts to advertising the link SR-TE attributes using the Application Specific Link Attributes TLV and the TE sub-sub-TLVs as shown in Table 1. If legacy attributes were used, legacy routers wrongly interpret that this router enabled RSVP and may signal RSVP-TE LSP paths using its links.

      Table 1 lists the code points for IS-IS and BGP-LS legacy TLVs.

      The following excerpt from the Link State Database (LSDB) shows the advertisement of TE parameters for a link with both RSVP-TE and SR-TE applications enabled.

       TE IS Nbrs   :                      
          Nbr   : Dut-A.00                            
          Default Metric  : 10
          Sub TLV Len     : 124
          IF Addr   : 10.10.2.3
          IPv6 Addr : 3ffe::10:10:2:3
          Nbr IP    : 10.10.2.1
          Nbr IPv6  : 3ffe::10:10:2:1
          MaxLink BW: 100000 kbps
          Resvble BW: 500000 kbps 
          Unresvd BW: 
              BW[0] : 500000 kbps
              BW[1] : 500000 kbps
              BW[2] : 500000 kbps
              BW[3] : 500000 kbps
              BW[4] : 500000 kbps
              BW[5] : 500000 kbps
              BW[6] : 500000 kbps
              BW[7] : 500000 kbps
          Admin Grp : 0x1
          TE Metric : 123
          TE APP LINK ATTR    :
               SABML-flags:Legacy SABM-flags:RSVP-TE SR-TE
          Adj-SID: Flags:v4VL Weight:0 Label:524287
          Adj-SID: Flags:v6BVL Weight:0 Label:524284 
          TE SRLGs     :
             SRLGs : Dut-A.00
             Lcl Addr  : 10.10.2.3
             Rem Addr  : 10.10.2.1
             Num SRLGs       : 1
                    1003
          TE APP SRLGs     :
              Nbr : Dut-A.00
              SABML-flags:Legacy SABM-flags: SR-TE
              IF Addr   : 10.10.2.3
              Nbr IP    : 10.10.2.1
      
    3. Application Specific Mode: {application-link-attributes} or {application-link-attributes + no legacy}

      The application specific mode of operation is intended for future use cases where TE attributes may have different values in RSVP-TE and SR-TE applications (this capability is not supported in SR OS) or are specific to one application (for example, RSVP-TE ‛Unreserved Bandwidth' and `Max Reservable Bandwidth' attributes).

      IS-IS advertises the TE attributes that are common to RSVP-TE and SR-TE applications in the sub-sub-TLVs of the new ASLA sub-TLV. IS-IS also advertises the link SRLG values in the Application Specific SRLG TLV. In both cases, the application flags for RSVP-TE and SR-TE are also set in the sub-TLV.

      IS-IS begins to advertise the TE attributes that are specific to the RSVP-TE application separately in the sub-sub-TLVs of the new application attribute sub-TLV. The application flag for RSVP-TE is also set in the sub-TLV.

      SR OS does not support configuring and advertising TE attributes that are specific to the SR-TE application.

      Common value RSVP-TE and SR-TE TE attributes are combined in the same application attribute sub-TLV with both application flags set, while the non-common value TE attributes are sent in their own application attribute sub-TLV with the corresponding application flag set.

      Figure 1 shows an excerpt from the Link State Database (LSDB). Attributes in green font are common to both RSVP-TE and SR-TE applications and are combined, while the attribute in red font is specific to RSVP-TE application and is sent separately.

      Figure 1. Attribute Mapping per Application

      Routers in the TE domain use these attributes to compute CSPF for IPv4 SR-TE LSP and IPv4 SR-TE LSPs. If the ipv6 command is also enabled, then the RFC 6119 IPv6 TLVs are advertised. A router in the TE domain receiving these advertisements can compute paths for IPv6 SR-TE LSP.

      Note: The segment-routing command must be enabled in the IS-IS instance or the common TE attribute will not be advertised for the SR-TE application.

      In order to disable advertising of RSVP-TE attributes, shut down the rsvp context on the router.

      Table 1 summarizes the IS-IS link TE parameter advertisement details for the three modes of operation of the IS-IS advertisement.

      Table 1. Details of Link TE Advertisement Methods

      IGP Traffic Engineering Options

      Link TE Advertisement Details

      RSVP-TE

      (rsvp enabled on interface)

      SR-TE

      (segment-routing enabled in IGP instance)

      RSVP-TE and SR-TE

      (rsvp enabled on interface and segment-routing enabled in IGP instance)

      Legacy Mode:

      no application-link-attributes

      Legacy TE TLVs

      Legacy TE TLVs

      Legacy Mode with Application Indication:

      {application-link-attributes + legacy}

      rsvp disabled on router

      (rsvp operationally down on all interfaces)

      Legacy TE TLVs

      ASLA TLV -Flags: {Legacy=0, SR-TE=1}; TE sub-sub-TLVs

      Legacy TE TLVs

      ASLA TLV -Flags: {Legacy=1, RSVP-TE=0, SR-TE=1}

      rsvp enabled on router

      Legacy TE TLVs

      ASLA TLV -Flags: {Legacy=1, RSVP-TE=1}

      Legacy TE TLVs

      ASLA TLV -Flags: {Legacy=1, SR-TE=1}

      Legacy TE TLVs

      ASLA TLV -Flags: {Legacy=1, RSVP-TE=1, SR-TE=1}

      Application Specific Mode:

      {application-link-attributes} or {application-link-attributes + no legacy}

      ASLA TLV -Flags: {Legacy=0, RSVP-TE=1}; TE sub-sub-TLVs

      ASLA TLV -Flags: {Legacy=0, SR-TE=1}; TE sub-sub-TLVs

      ASLA TLV -Flags: {Legacy=0, RSVP-TE=1; SR-TE=1}; TE sub-sub-TLVs (common attributes)

      ASLA TLV -Flags:

      {Legacy=0, RSVP-TE=1}; TE sub-sub-TLVs (RSVP-TE specific attributes; e.g., Unreserved BW and Resvble BW)

      ASLA TLV -Flags:

      {Legacy=0, SR-TE=1}; TE sub-sub-TLVs (SR-TE specific attributes; not supported in SR OS 19.10.R1)