Existing OSPFv2 TE-related link attribute advertisement (for example, bandwidth) definitions are used in RSVP-TE deployments (see draft-ietf-spring-segment-routing-policy-07.txt for more information). In the beginning only the RSVP-TE was using these TE-related link attributes, however additional applications (for example, Segment Routing Traffic Engineering (SR-TE)) emerged and require link attributes. The link attributes for these new applications may not always be identical as those advertised for RSVP-TE.
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 RFC 8920 defines a subset of all possible TE extensions and TE Metric Extensions that can be encoded within Application Specific Link sub TLVs. Table: Nokia support for ASLA extended link TLV encoding describes the relevant values for SR OS.
OSPFv2 extended link TLV sub-TLVs (RFC7684) | ||||
---|---|---|---|---|
IANA |
Attribute Type |
TE-DB1 |
SR OS sub-TLV of Extended Link TLV2 |
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 |
✓ |
✓ |
— |
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: Configuration considerations for TE opaque LSAs describes the possible configurations 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-Opaque4 |
ASLA (SR-TE) |
MPLS + RSVP + SR |
TE-Opaque |
TE-Opaque |
TE-Opaque |
TE-Opaque (RSVP) + ASLA (SRTE) |