| Network | P. Shaofu |
| Internet-Draft | L. Yao |
| Intended status: Standards Track | ZTE Corporation |
| Expires: December 7, 2020 | June 5, 2020 |
Advertising Segment Routing Policies Attributes in BGP
draft-peng-idr-segment-routing-te-policy-attr-00
This document defines necessary attributes advertised with a candidate path of a Segment Routing (SR) Policy when BGP is used to distribute SR Policy. New sub-TLVs for the SR Policy attributes are defined for signaling information about each segment to meet more requirements.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 7, 2020.
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Segment Routing (SR) [RFC8402] allows a headend node to steer a packet flow along any path. Intermediate per-flow states are eliminated thanks to source routing.
[I-D.ietf-spring-segment-routing-policy] details the concepts of SR Policy and steering into an SR Policy. These apply equally to the MPLS and IPv6 (known as SRv6) data plane instantiations of Segment Routing with their respective representations of segments as SR-MPLS SID and SRv6 SID as described in [RFC8402].
[I-D.ietf-idr-segment-routing-te-policy] specifies the way to use BGP to distribute one or more of the candidate paths of an SR Policy to the headend of that policy. It defines a new BGP address family (SAFI), i.e., SR Policy SAFI NLRI. In UPDATE messages of that address family, the NLRI identifies an SR Policy Candidate Path, and the attributes encode the segment lists and other details of that SR Policy Candidate Path. Currently 11 Segment Types (from A to K) are defined to encode SR-MPLS or SRv6 segments.
This document continues to extend [I-D.ietf-idr-segment-routing-te-policy] and define some new Segment Types with more attribute information to meet more requirements.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
[I-D.ietf-idr-bgp-ls-segment-routing-ext] describes extensions to BGP-LS to advertise the SR-MPLS information. According to Node Attributes, Link Attribute, and Prefix Attribute that collected from across an SR-MPLS domain, an external controller can construct the end-to-end path (with its associated SIDs) that need to be applied to an incoming packet to achieve the desired end-to-end forwarding. The Flags and Algorithm information contained in the collected Adjacency SID or Prefix SID can be used as the basis for path selection when controller compute an SR path.
When controller distribute an SR-MPLS Policy to the headend of that policy, it is not necessary to fill in above flags in each Segment, as they have no prompting effect on packet encapsulation.
For algorithm attribute, [I-D.peng-lsr-algorithm-related-adjacency-sid] complement that the algorithm identifier can be also included as part of an Adjacency-SID advertisement for SR-MPLS. For this reason, an SR-MPLS Policy advertised to the headend may also contain algorithm specific Adjacecny-SID.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
The Type L Segment Sub-TLV is similar with existed Type A Segment Sub-TLV, it also encodes a single SR-MPLS SID, but with additional algorithm information. The format is as follows:
Where:
SR Algorithm: 1 octet specifying SR Algorithm as described in section 3.1.1 in [RFC8402] when A-Flag is set. If A-Flag is not set, this field SHOULD be set to zero on transmission and MUST be ignored on receipt.
Other fields have the same meaning as existed Type A Segment Sub-TLV.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Node Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SR-MPLS SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2
The Type M Segment Sub-TLV is similar with existed Type E Segment Sub-TLV, it also encodes an IPv4 node address, a local interface Identifier (Local Interface ID) and an optional SR-MPLS SID, but with additional algorithm information. The format is as follows:
Where:
SR Algorithm: 1 octet specifying SR Algorithm as described in section 3.1.1 in [RFC8402] when A-Flag is set. If A-Flag is not set, this field SHOULD be set to zero on transmission and MUST be ignored on receipt.
Other fields have the same meaning as existed Type E Segment Sub-TLV.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IPv4 Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote IPv4 Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SR-MPLS SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3
The Type N Segment Sub-TLV is similar with existed Type F Segment Sub-TLV, it also encodes an adjacency local address, an adjacency remote address and an optional SR-MPLS SID, but with additional algorithm information. The format is as follows:
Where:
SR Algorithm: 1 octet specifying SR Algorithm as described in section 3.1.1 in [RFC8402] when A-Flag is set. If A-Flag is not set, this field SHOULD be set to zero on transmission and MUST be ignored on receipt.
Other fields have the same meaning as existed Type F Segment Sub-TLV.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 Local Node Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 Remote Node Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SR-MPLS SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4
The Type O Segment Sub-TLV is similar with existed Type G Segment Sub-TLV, it also encodes an IPv6 Link Local adjacency with IPv6 local node address, a local interface identifier (Local Interface ID), IPv6 remote node address , a remote interface identifier (Remote Interface ID) and an optional SR-MPLS SID, but with additional algorithm information. The format is as follows:
Where:
SR Algorithm: 1 octet specifying SR Algorithm as described in section 3.1.1 in [RFC8402] when A-Flag is set. If A-Flag is not set, this field SHOULD be set to zero on transmission and MUST be ignored on receipt.
Other fields have the same meaning as existed Type G Segment Sub-TLV.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local IPv6 Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Remote IPv6 Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SR-MPLS SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5
The Type P Segment Sub-TLV is similar with existed Type H Segment Sub-TLV, it also encodes an adjacency local address, an adjacency remote address and an optional SR-MPLS SID, but with additional algorithm information. The format is as follows:
Where:
SR Algorithm: 1 octet specifying SR Algorithm as described in section 3.1.1 in [RFC8402] when A-Flag is set. If A-Flag is not set, this field SHOULD be set to zero on transmission and MUST be ignored on receipt.
Other fields have the same meaning as existed Type H Segment Sub-TLV.
[I-D.ietf-idr-bgpls-srv6-ext] describes extensions to BGP-LS to advertise the SRv6 information. According to SRv6 Node Attributes, SRv6 Link Attribute, SRv6 Prefix Attribute and SRv6 SID NLRI that collected from across an SRv6 domain, an external controller can construct the end-to-end path (with its associated SIDs) that need to be applied to an incoming packet to achieve the desired end-to-end forwarding. The Flags and Algorithm information contained in the collected END SID or END.X SID can be used as the basis for path selection when controller compute an SR path.
When controller distribute an SRv6 Policy to the headend of that policy, it is not necessary to fill in these Flags in each Segment, as they have no prompting effect on packet encapsulation.
[I-D.ietf-spring-srv6-network-programming] has defined some fundamental Behaviors with additional Flavors for the function of SRv6 SID. Different type of SIDs, such as END SID, END.X SID, VPN Service SID, etc, could be allocated from the same SRv6 SID Locator, each with individual structure. The ISIS [I-D.ietf-lsr-isis-srv6-extensions] and OSPFv3 [I-D.ietf-lsr-ospfv3-srv6-extensions] also defined that Locator is algorithm specific. And, [I-D.ietf-idr-bgpls-srv6-ext] also advertise SRv6 Locators and Segments with specific algorithm. Thus, an SRv6 Policy advertised to the headend may contain any type of SID with specific algorithm.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6 SID (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Behavior | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BL | NL | FL | AL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6
The Type Q Segment Sub-TLV is similar with existed Type B Segment Sub-TLV, it also encodes a single SRv6 SID, but with additional algorithm, endpoint behavior and SID strucutre information. The format is as follows:
Where:
Type: TBD
Length is 26.
SR Algorithm: 1 octet specifying SR Algorithm as described in section 3.1.1 in [RFC8402] when A-Flag is set. If A-Flag is not set, this field SHOULD be set to zero on transmission and MUST be ignored on receipt.
Endpoint Behavior: 2 octets specifying the Endpoint Behavior code point for this SRv6 SID as defined in section 9.2 of [I-D.ietf-spring-srv6-network-programming].
BL: 1 octet specifying Block Length of the SID structure.
NL: 1 octet specifying Node Length of the SID structure.
FL: 1 octet specifying Function Length of the SID structure.
AL: 1 octet specifying Argument Length of the SID structure.
Other fields have the same meaning as existed Type B Segment Sub-TLV.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 Node Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6 SID (24 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Behavior | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BL | NL | FL | AL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7
The Type Q Segment Sub-TLV is similar with existed Type B Segment Sub-TLV, it also encodes an IPv6 node address, SR Algorithm and an optional SRv6 SID, but with additional endpoint behavior and SID strucutre information. The format is as follows:
Where:
Type: TBD
Length is 42 when the SRv6 SID(with its endpoint behavior and structure) is present else is 18.
SR Algorithm: 1 octet specifying SR Algorithm as described in section 3.1.1 in [RFC8402] when A-Flag is set. If A-Flag is not set, this field SHOULD be set to zero on transmission and MUST be ignored on receipt.
Endpoint Behavior: 2 octets specifying the Endpoint Behavior code point for this SRv6 SID as defined in section 9.2 of [I-D.ietf-spring-srv6-network-programming].
BL: 1 octet specifying Block Length of the SID structure.
NL: 1 octet specifying Node Length of the SID structure.
FL: 1 octet specifying Function Length of the SID structure.
AL: 1 octet specifying Argument Length of the SID structure.
Other fields have the same meaning as existed Type I Segment Sub-TLV.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 Local Node Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 Remote Node Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6 SID (optional, 24 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Behavior | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BL | NL | FL | AL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8
The Type S Segment Sub-TLV is similar with existed Type J Segment Sub-TLV, it also encodes an IPv6 Link Local adjacency with local node address, a local interface identifier (Local Interface ID), remote IPv6 node address, a remote interface identifier (Remote Interface ID) and an optional SRv6 SID, but with additional algorithm, endpoint behavior and SID strucutre information. The format is as follows:
Where:
Type: TBD
Length is 66 when the SRv6 SID (with its endpoint behavior and structure) is present else is 42.
SR Algorithm: 1 octet specifying SR Algorithm as described in section 3.1.1 in [RFC8402] when A-Flag is set. If A-Flag is not set, this field SHOULD be set to zero on transmission and MUST be ignored on receipt.
Endpoint Behavior: 2 octets specifying the Endpoint Behavior code point for this SRv6 SID as defined in section 9.2 of [I-D.ietf-spring-srv6-network-programming].
BL: 1 octet specifying Block Length of the SID structure.
NL: 1 octet specifying Node Length of the SID structure.
FL: 1 octet specifying Function Length of the SID structure.
AL: 1 octet specifying Argument Length of the SID structure.
Other fields have the same meaning as existed Type J Segment Sub-TLV.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local IPv6 Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Remote IPv6 Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SRv6 SID (optional, 24 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint Behavior | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BL | NL | FL | AL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9
The Type T Segment Sub-TLV is similar with existed Type K Segment Sub-TLV, it also encodes an adjacency local address, an adjacency remote address and an optional SRv6 SID, but with additional algorithm, endpoint behavior and SID strucutre information. The format is as follows:
Where:
Type: TBD
Length is 58 when the SRv6 SID (with its endpoint behavior and structure) is present else is 34.
SR Algorithm: 1 octet specifying SR Algorithm as described in section 3.1.1 in [RFC8402] when A-Flag is set. If A-Flag is not set, this field SHOULD be set to zero on transmission and MUST be ignored on receipt.
Endpoint Behavior: 2 octets specifying the Endpoint Behavior code point for this SRv6 SID as defined in section 9.2 of [I-D.ietf-spring-srv6-network-programming].
BL: 1 octet specifying Block Length of the SID structure.
NL: 1 octet specifying Node Length of the SID structure.
FL: 1 octet specifying Function Length of the SID structure.
AL: 1 octet specifying Argument Length of the SID structure.
Other fields have the same meaning as existed Type K Segment Sub-TLV.
[I-D.ietf-idr-segment-routing-te-policy] has defined basic SR policy operations. This document emphasizes the use of algorithm and other attributes for the headend.
In most cases, the controller compute the SR path and advertise the candidate path with ultimate SID list to the headend according to selected link-state database with SR information, and the headend does not need to worry about how to convert a segment represented by node/link to a SID. It is the local matter and policy for the headend to use algorithm field to verify whether the received SID is consistent with that stored in the local database. If verification fails, the headend may treat the total segment list is invalid, and turn to use other valid segment list.
In a few cases, the controller may advertise the candidate path without optional SID to the headend. The headend must convert each segment represented by node/link to a SID within the determined algorithm context. If the conversion is not successful, the headend must treat the total segment list is invalid, and turn to use other valid segment list.
However, for inter-domain case, the headend almost has no capability to do the above conversion, because it has not the entire topology view.
For SRv6 policy, the headend can do more enhanced function according to endpoint behavior and structure attribute of each SID, that's the local behavior of the headend.
Value Description Reference
------------------------------------------------------------------------
TBD1 Type L MPLS Algorithm related SID sub-TLV This document
TBD2 Type M IPv4 Node, index and Algorithm related This document
SID sub-TLV
TBD3 Type N IPv4 Local/Remote addresses and Algorithm This document
related SID sub-TLV
TBD4 Type O IPv6 Node, index for remote and local pair This document
and Algorithm related SID for SR-MPLS sub-TLV
TBD5 Type P IPv6 Local/Remote addresses and Algorithm This document
related SID sub-TLV
TBD6 Type Q SRv6 Algorithm related SID sub-TLV This document
TBD7 Type R IPv6 Node and Algorithm related SID for This document
SRv6 sub-TLV
TBD8 Type S IPv6 Node, index for remote and local pair This document
and Algorithm related SID for SRv6 sub-TLV
TBD9 Type T IPv6 Local/Remote addresses and Algorithm This document
related SID for SRv6 sub-TLV
Figure 10
This document requests codepoint allocations for new Segment Sub-TLVs in the "SR Policy List Sub-TLVs" registry.
Procedures and protocol extensions defined in this document do not affect the security considerations discussed in [I-D.ietf-idr-segment-routing-te-policy].
TBD
| [I-D.ietf-idr-bgp-ls-segment-routing-ext] | Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H. and M. Chen, "BGP Link-State extensions for Segment Routing", Internet-Draft draft-ietf-idr-bgp-ls-segment-routing-ext-16, June 2019. |
| [I-D.ietf-idr-bgpls-srv6-ext] | Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., daniel.bernier@bell.ca, d. and B. Decraene, "BGP Link State Extensions for SRv6", Internet-Draft draft-ietf-idr-bgpls-srv6-ext-02, January 2020. |
| [I-D.ietf-idr-segment-routing-te-policy] | Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., Rosen, E., Jain, D. and S. Lin, "Advertising Segment Routing Policies in BGP", Internet-Draft draft-ietf-idr-segment-routing-te-policy-09, May 2020. |
| [I-D.ietf-lsr-isis-srv6-extensions] | Psenak, P., Filsfils, C., Bashandy, A., Decraene, B. and Z. Hu, "IS-IS Extension to Support Segment Routing over IPv6 Dataplane", Internet-Draft draft-ietf-lsr-isis-srv6-extensions-08, April 2020. |
| [I-D.ietf-lsr-ospfv3-srv6-extensions] | Li, Z., Hu, Z., Cheng, D., Talaulikar, K. and P. Psenak, "OSPFv3 Extensions for SRv6", Internet-Draft draft-ietf-lsr-ospfv3-srv6-extensions-00, February 2020. |
| [I-D.ietf-spring-segment-routing-policy] | Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A. and P. Mattes, "Segment Routing Policy Architecture", Internet-Draft draft-ietf-spring-segment-routing-policy-07, May 2020. |
| [I-D.ietf-spring-srv6-network-programming] | Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., Matsushima, S. and Z. Li, "SRv6 Network Programming", Internet-Draft draft-ietf-spring-srv6-network-programming-15, March 2020. |
| [I-D.peng-lsr-algorithm-related-adjacency-sid] | Peng, S. and R. Chen, "Algorithm Related IGP-Adjacency SID Advertisement", Internet-Draft draft-peng-lsr-algorithm-related-adjacency-sid-00, March 2020. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997. |
| [RFC8174] | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. |
| [RFC8200] | Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017. |
| [RFC8402] | Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Litkowski, S. and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018. |
| [RFC8660] | Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S. and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019. |
| [RFC8665] | Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W. and J. Tantsura, "OSPF Extensions for Segment Routing", RFC 8665, DOI 10.17487/RFC8665, December 2019. |
| [RFC8666] | Psenak, P. and S. Previdi, "OSPFv3 Extensions for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, December 2019. |
| [RFC8667] | Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Gredler, H. and B. Decraene, "IS-IS Extensions for Segment Routing", RFC 8667, DOI 10.17487/RFC8667, December 2019. |
| [RFC8754] | Filsfils, C., Dukes, D., Previdi, S., Leddy, J., Matsushima, S. and D. Voyer, "IPv6 Segment Routing Header (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020. |