OSPF Application Specific TE Link Attributes

Existing OSPFv2 TE-related link attribute advertisement (for example, bandwidth) definitions are used in RSVP-TE deployments (refer to draft-ietf-spring-segment-routing-policy-07.txt for more information). Since the definition of the original RSVP-TE use case, additional applications (for example, Segment Routing Traffic Engineering (SR-TE)) that may use the link attribute advertisement have also been defined.

This usage has introduced ambiguity in deployments that include a mix of RSVP-TE and SR-TE support. For example, it is not possible to unambiguously indicate the specific advertisements used by RSVP-TE and SR-TE. Although this may not be an issue for fully congruent topologies, any incongruence causes ambiguity. An additional issue arises in cases where both applications are supported on a link but the link attribute values associated with each application differ. Advertisements without OSPFv2 application specific TE link attributes do not support the advertisement of application specific values for the same attribute on a specific link.

CLI syntax:

Config
   router
      ospf
         traffic-engineering-options
               sr-te {legacy|application-specific-link-attributes}
               no sr-te 

The traffic-engineering-options command enables the context to configure advertisement of the TE attributes of each link on a per-application basis. Two applications are supported in SR OS: RSVP-TE and SR-TE.

The legacy mode of advertising TE attributes that is used in RSVP-TE is still supported. In addition, the following configuration options are allowed:

The IETF Draft draft-ietf-ospf-te-link-attr-reuse-14.txt defines a subset of all possible TE extensions and TE Metric Extensions that can be encoded within Application Specific Link sub TLVs. Table 1 describes the relevant values for SR OS.

Table 1. Nokia Support for ASLA Extended Link TLV Encoding

OSPFv2 Extended Link TLV Sub-TLVs (RFC7684)

IANA

Attribute Type

TE-DB 1

SR OS

sub-TLV of Extended Link TLV 2

SR OS

Nested sub-TLV of ASLA Extended Link TLV encoding3

10

ASLA

11

Shared Risk Link Group

12

Unidirectional Link Delay

13

Min/Max Unidirectional Link Delay

14

Unidirectional Delay Variation

15

Unidirectional Link Loss

16

Unidirectional Residual Bandwidth

17

Unidirectional Available Bandwidth

18

Unidirectional Utilized Bandwidth

19

Administrative Group

Y

20

Extended Administrative Group

22

TE Metric

23

Maximum Link Bandwidth

Notes:

  1. Support to include the attributes from received LSA's into Nokia TE-DB and export into BGP-LS. Refer to draft-ietf-idr-bgp-ls-app-specific-attr-02.txt for more information.

  2. Node support to encode the link attribute as sub-TLV in an OSPFv2 Extended Link TLV.

  3. Node support to encode the link attribute as sub-TLV in an OSPFv2 Application Specific Extended Link sub-TLV.

The solution proposed in the OSPF Link Traffic Engineering Attribute Reuse Draft (draft-ietf-ospf-te-link-attr-reuse-14.txt) assumes that OSPF does not need to move all RSVP-TE attributes from the TE Opaque LSA into the Extended Link LSA. For, RSVP-TE, consequently, there is no significant modification and it can continue to be advertised using existing OSPF TLVs. For SR-TE and future applications, the ASLA TLVs may be used. Alternatively, existing TE Opaque LSAs could be used through configuration. Table 2 describes the possible configurations for TE Opaque LSAs.

Table 2. Configuration Considerations for TE Opaque LSAs

Interior Gateway Protocol Configuration

ospf>traffic-engineering <20.7

ospf>traffic-engineering

ospf>te-opts>no sr-te

ospf>traffic-engineering

ospf>te-opts>sr-te legacy

ospf>traffic-engineering

ospf>te-opts>sr-te application-link-attribute

Interface config

MPLS + RSVP

TE-Opaque

TE-Opaque

TE-Opaque

TE-Opaque

MPLS + SR

TE-Opaque 1

ASLA (SR-TE)

MPLS + RSVP + SR

TE-Opaque

TE-Opaque

TE-Opaque

TE-Opaque (RSVP) + ASLA (SRTE)

Note:
  1. If the local router interface is configured with MPLS+SR, and RSVP-TE is deployed on remote servers, the remote routers will wrongly conclude that the link is RSVP-enabled.