draft-ietf-idr-segment-routing-te-policy-02.txt   draft-ietf-idr-segment-routing-te-policy-03.txt 
Network Working Group S. Previdi, Ed. Network Working Group S. Previdi, Ed.
Internet-Draft C. Filsfils Internet-Draft C. Filsfils
Intended status: Standards Track D. Jain, Ed. Intended status: Standards Track D. Jain, Ed.
Expires: September 3, 2018 Cisco Systems, Inc. Expires: November 19, 2018 Cisco Systems, Inc.
P. Mattes P. Mattes
Microsoft Microsoft
E. Rosen E. Rosen
Juniper Networks Juniper Networks
S. Lin S. Lin
Google Google
Mar 2, 2018 May 18, 2018
Advertising Segment Routing Policies in BGP Advertising Segment Routing Policies in BGP
draft-ietf-idr-segment-routing-te-policy-02 draft-ietf-idr-segment-routing-te-policy-03
Abstract Abstract
This document defines a new BGP SAFI with a new NLRI in order to This document defines a new BGP SAFI with a new NLRI in order to
advertise a candidate path of a Segment Routing Policy (SR Policy). advertise a candidate path of a Segment Routing Policy (SR Policy).
An SR Policy is a set of candidate paths consisting of one or more An SR Policy is a set of candidate paths consisting of one or more
segment lists. The headend of an SR Policy may learn multiple segment lists. The headend of an SR Policy may learn multiple
candidate paths for an SR Policy. Candidate paths may be learned via candidate paths for an SR Policy. Candidate paths may be learned via
a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP.
This document specifies the way in which BGP may be used to This document specifies the way in which BGP may be used to
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 3, 2018. This Internet-Draft will expire on November 19, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. SR TE Policy Encoding . . . . . . . . . . . . . . . . . . . . 5 2. SR TE Policy Encoding . . . . . . . . . . . . . . . . . . . . 5
2.1. SR TE Policy SAFI and NLRI . . . . . . . . . . . . . . . 5 2.1. SR TE Policy SAFI and NLRI . . . . . . . . . . . . . . . 5
2.2. SR TE Policy and Tunnel Encapsulation Attribute . . . . . 7 2.2. SR TE Policy and Tunnel Encapsulation Attribute . . . . . 7
2.3. Remote Endpoint and Color . . . . . . . . . . . . . . . . 8 2.3. Remote Endpoint and Color . . . . . . . . . . . . . . . . 8
2.4. SR TE Policy Sub-TLVs . . . . . . . . . . . . . . . . . . 8 2.4. SR TE Policy Sub-TLVs . . . . . . . . . . . . . . . . . . 9
2.4.1. Preference Sub-TLV . . . . . . . . . . . . . . . . . 8 2.4.1. Preference Sub-TLV . . . . . . . . . . . . . . . . . 9
2.4.2. SR TE Binding SID Sub-TLV . . . . . . . . . . . . . . 9 2.4.2. SR TE Binding SID Sub-TLV . . . . . . . . . . . . . . 10
2.4.3. Segment List Sub-TLV . . . . . . . . . . . . . . . . 10 2.4.3. Segment List Sub-TLV . . . . . . . . . . . . . . . . 11
2.4.4. Explicit NULL Label Policy Sub-TLV . . . . . . . . . 21 2.4.4. Explicit NULL Label Policy Sub-TLV . . . . . . . . . 27
3. Extended Color Community . . . . . . . . . . . . . . . . . . 23 2.4.5. Policy Priority Sub-TLV . . . . . . . . . . . . . . . 28
4. SR Policy Operations . . . . . . . . . . . . . . . . . . . . 23 2.4.6. Policy Name Sub-TLV . . . . . . . . . . . . . . . . . 29
4.1. Configuration and Advertisement of SR TE Policies . . . . 23 3. Extended Color Community . . . . . . . . . . . . . . . . . . 30
4.2. Reception of an SR Policy NLRI . . . . . . . . . . . . . 24 4. SR Policy Operations . . . . . . . . . . . . . . . . . . . . 30
4.2.1. Acceptance of an SR Policy NLRI . . . . . . . . . . . 24 4.1. Configuration and Advertisement of SR TE Policies . . . . 30
4.2.2. Usable SR Policy NLRI . . . . . . . . . . . . . . . . 24 4.2. Reception of an SR Policy NLRI . . . . . . . . . . . . . 31
4.2.3. Passing a usable SR Policy NLRI to the SRTE Process . 25 4.2.1. Acceptance of an SR Policy NLRI . . . . . . . . . . . 31
4.2.4. Propagation of an SR Policy . . . . . . . . . . . . . 25 4.2.2. Usable SR Policy NLRI . . . . . . . . . . . . . . . . 32
4.3. Flowspec and SR Policies . . . . . . . . . . . . . . . . 25 4.2.3. Passing a usable SR Policy NLRI to the SRTE Process . 32
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2.4. Propagation of an SR Policy . . . . . . . . . . . . . 32
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 4.3. Flowspec and SR Policies . . . . . . . . . . . . . . . . 33
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 26 5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 34
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
8.1. Existing Registry: Subsequent Address Family Identifiers 8.1. Existing Registry: Subsequent Address Family Identifiers
(SAFI) Parameters . . . . . . . . . . . . . . . . . . . . 28 (SAFI) Parameters . . . . . . . . . . . . . . . . . . . . 35
8.2. Existing Registry: BGP Tunnel Encapsulation Attribute 8.2. Existing Registry: BGP Tunnel Encapsulation Attribute
Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 28 Tunnel Types . . . . . . . . . . . . . . . . . . . . . . 35
8.3. Existing Registry: BGP Tunnel Encapsulation Attribute 8.3. Existing Registry: BGP Tunnel Encapsulation Attribute
sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 28 sub-TLVs . . . . . . . . . . . . . . . . . . . . . . . . 35
8.4. New Registry: SR Policy List Sub-TLVs . . . . . . . . . . 28 8.4. New Registry: SR Policy List Sub-TLVs . . . . . . . . . . 36
8.5. New Registry: SR Policy Binding SID Flags . . . . . . . . 36
9. Security Considerations . . . . . . . . . . . . . . . . . . . 29 8.6. New Registry: SR Policy Segment Flags . . . . . . . . . . 37
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. Security Considerations . . . . . . . . . . . . . . . . . . . 37
10.1. Normative References . . . . . . . . . . . . . . . . . . 29 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
10.2. Informational References . . . . . . . . . . . . . . . . 30 10.1. Normative References . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 10.2. Informational References . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
Segment Routing (SR) allows a headend node to steer a packet flow Segment Routing (SR) allows a headend node to steer a packet flow
along any path. Intermediate per-flow states are eliminated thanks along any path. Intermediate per-flow states are eliminated thanks
to source routing [I-D.ietf-spring-segment-routing]. to source routing [I-D.ietf-spring-segment-routing].
The headend node is said to steer a flow into a Segment Routing The headend node is said to steer a flow into a Segment Routing
Policy (SR Policy). Policy (SR Policy).
skipping to change at page 6, line 36 skipping to change at page 6, line 51
[RFC4271] using BGP multiprotocol extensions [RFC4760] with an AFI of [RFC4271] using BGP multiprotocol extensions [RFC4760] with an AFI of
1 or 2 (IPv4 or IPv6) and with a SAFI of 73 (assigned by IANA from 1 or 2 (IPv4 or IPv6) and with a SAFI of 73 (assigned by IANA from
the "Subsequent Address Family Identifiers (SAFI) Parameters" the "Subsequent Address Family Identifiers (SAFI) Parameters"
registry). registry).
An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI An update message that carries the MP_REACH_NLRI or MP_UNREACH_NLRI
attribute with the SR Policy SAFI MUST also carry the BGP mandatory attribute with the SR Policy SAFI MUST also carry the BGP mandatory
attributes. In addition, the BGP update message MAY also contain any attributes. In addition, the BGP update message MAY also contain any
of the BGP optional attributes. of the BGP optional attributes.
The next-hop of the SR Policy SAFI NLRI is set based on the AFI. For The next-hop network address field in SR Policy SAFI (73) updates may
example, if the AFI is set to IPv4 (1), then the next-hop is encoded be either a 4 octet IPv4 address or a 16 octet IPv6 address,
as a 4-byte IPv4 address. If the AFI is set to IPv6 (2), then the independent of the SR Policy AFI. The length field of the next-hop
next-hop is encoded as a 16-byte IPv6 address of the router. Setting address specifies the next-hop address family. If the next-hop
of and processing of the next-hop field is governed by standard BGP length is 4, then the next-hop is an IPv4 address; if the next-hop
procedures as described in section 3 in [RFC4760]. length is 16, then it is a global IPv6 address; and if the next-hop
length is 32, then it has a global IPv6 address followed by a link-
local IPv6 address. The setting of the next-hop field and its
attendant processing is governed by standard BGP procedures as
described in section 3 in [RFC4760].
It is important to note that any BGP speaker receiving a BGP message It is important to note that any BGP speaker receiving a BGP message
with an SR Policy NLRI, will process it only if the NLRI is among the with an SR Policy NLRI, will process it only if the NLRI is among the
best paths as per the BGP best path selection algorithm. In other best paths as per the BGP best path selection algorithm. In other
words, this document does not modify the BGP propagation or bestpath words, this document does not modify the BGP propagation or bestpath
selection rules. selection rules.
It has to be noted that if several candidate paths of the same SR It has to be noted that if several candidate paths of the same SR
Policy (endpoint, color) are signaled via BGP to a head-end, it is Policy (endpoint, color) are signaled via BGP to a head-end, it is
recommended that each NLRI use a different distinguisher. If BGP has recommended that each NLRI use a different distinguisher. If BGP has
installed into the BGP table two advertisements whose respective installed into the BGP table two advertisements whose respective
NLRIs have the same color and endpoint, but different distinguishers, NLRIs have the same color and endpoint, but different distinguishers,
both advertisements are passed to the SRTE process as different both advertisements are passed to the SRTE process as different
candidate paths. In addition, the originator information candidate paths. In addition, the originator information
corresponding to the each candidate path, as described in section 2.4 corresponding to the each candidate path, as described in section 2.4
([I-D.filsfils-spring-segment-routing-policy]) is passed to the SRTE ([I-D.filsfils-spring-segment-routing-policy]), is passed to the SRTE
process. process.
2.2. SR TE Policy and Tunnel Encapsulation Attribute 2.2. SR TE Policy and Tunnel Encapsulation Attribute
The content of the SR Policy is encoded in the Tunnel Encapsulation The content of the SR Policy is encoded in the Tunnel Encapsulation
Attribute originally defined in [I-D.ietf-idr-tunnel-encaps] using a Attribute originally defined in [I-D.ietf-idr-tunnel-encaps] using a
new Tunnel-Type TLV (codepoint is 15, assigned by IANA (see new Tunnel-Type TLV (codepoint is 15, assigned by IANA (see
Section 8) from the "BGP Tunnel Encapsulation Attribute Tunnel Types" Section 8) from the "BGP Tunnel Encapsulation Attribute Tunnel Types"
registry). registry).
The SR Policy Encoding structure is as follows: The SR Policy Encoding structure is as follows:
SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint> SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
Attributes: Attributes:
Tunnel Encaps Attribute (23) Tunnel Encaps Attribute (23)
Tunnel Type: SR Policy Tunnel Type: SR Policy
Binding SID Binding SID
Preference Preference
Priority
Policy Name
Explicit NULL Label Policy (ENLP)
Segment List Segment List
Weight Weight
Segment Segment
Segment Segment
... ...
... ...
where: where:
o SR Policy SAFI NLRI is defined in Section 2.1. o SR Policy SAFI NLRI is defined in Section 2.1.
o Tunnel Encapsulation Attribute is defined in o Tunnel Encapsulation Attribute is defined in
[I-D.ietf-idr-tunnel-encaps]. [I-D.ietf-idr-tunnel-encaps].
o Tunnel-Type is set to 15 (assigned by IANA from the "BGP Tunnel o Tunnel-Type is set to 15 (assigned by IANA from the "BGP Tunnel
Encapsulation Attribute Tunnel Types" registry). Encapsulation Attribute Tunnel Types" registry).
o Preference, Binding SID, Segment-List, Weight and Segment are o Preference, Binding SID, Priority, Policy Name, ENLP, Segment-
defined in this document. List, Weight and Segment sub-TLVs are defined in this document.
o Additional sub-TLVs may be defined in the future. o Additional sub-TLVs may be defined in the future.
A Tunnel Encapsulation Attribute MUST NOT contain more than one TLV A Tunnel Encapsulation Attribute MUST NOT contain more than one TLV
of type "SR Policy". of type "SR Policy". If more than one TLV of type "SR Policy"
appears, the update is considered malformed and the "treat-as-
withdraw" strategy of [RFC7606] is applied.
Multiple occurrences of "Segment List" MAY be encoded within the same Multiple occurrences of "Segment List" MAY be encoded within the same
SR Policy. SR Policy.
Multiple occurrences of "Segment" MAY be encoded within the same Multiple occurrences of "Segment" MAY be encoded within the same
Segment List. Segment List.
2.3. Remote Endpoint and Color 2.3. Remote Endpoint and Color
The Remote Endpoint and Color sub-TLVs, as defined in The Remote Endpoint and Color sub-TLVs, as defined in
[I-D.ietf-idr-tunnel-encaps], MAY also be present in the SR Policy [I-D.ietf-idr-tunnel-encaps], MAY also be present in the SR Policy
encodings. encodings.
The Remote Endpoint and Color Sub-TLVs are not used for SR Policy The Remote Endpoint and Color Sub-TLVs are not used for SR Policy
encodings and therefore their value is irrelevant in the context of encodings and therefore their value is irrelevant in the context of
SR Policy SAFI NLRI. If present, the Remote Endpoint sub-TLV and the the SR Policy SAFI NLRI. If present, the Remote Endpoint sub-TLV and
Color sub-TLV MUST be ignored by the BGP speaker. the Color sub-TLV MUST be ignored by the BGP speaker.
2.4. SR TE Policy Sub-TLVs 2.4. SR TE Policy Sub-TLVs
This section defines the SR Policy sub-TLVs. This section defines the SR Policy sub-TLVs.
Preference, Binding SID, Segment-List are assigned from the "BGP Preference, Binding SID, Segment-List, Priority, Policy Name and
Tunnel Encapsulation Attribute sub-TLVs" registry. Explicit NULL Label Policy sub-TLVs are assigned from the "BGP Tunnel
Encapsulation Attribute Sub-TLVs" registry.
Weight and Segment Sub-TLVs are assigned from a new registry defined Weight and Segment sub-TLVs are assigned from a new registry defined
in this document and called: "SR Policy List Sub-TLVs". See in this document and called: "SR Policy List Sub-TLVs". See
Section 8 for the details of the registry. Section 8 for the details of the registry.
2.4.1. Preference Sub-TLV 2.4.1. Preference Sub-TLV
The Preference sub-TLV does not have any effect on the BGP bestpath The Preference sub-TLV does not have any effect on the BGP bestpath
selection or propagation procedures. The contents of this sub-TLV selection or propagation procedures. The contents of this sub-TLV
are used by the SRTE process as described in section 2.9 in are used by the SRTE process as described in section 2.9 in
([I-D.filsfils-spring-segment-routing-policy]). ([I-D.filsfils-spring-segment-routing-policy]).
The Preference sub-TLV is optional, MUST NOT appear more than once in The Preference sub-TLV is optional and it MUST NOT appear more than
the SR Policy and has following format: once in the SR Policy. If the Preference sub-TLV appears more than
once, the update is considered malformed and the "treat-as-withdraw"
strategy of [RFC7606] is applied.
The Preference sub-TLV has following format:
0 1 2 3 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 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 | RESERVED | | Type | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference (4 octets) | | Preference (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
skipping to change at page 9, line 24 skipping to change at page 10, line 16
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
o Preference: a 4-octet value. o Preference: a 4-octet value.
2.4.2. SR TE Binding SID Sub-TLV 2.4.2. SR TE Binding SID Sub-TLV
The Binding SID sub-TLV is not used by BGP. The contents of this The Binding SID sub-TLV is not used by BGP. The contents of this
sub-TLV are used by the SRTE process as described in section 6 in sub-TLV are used by the SRTE process as described in section 6 in
([I-D.filsfils-spring-segment-routing-policy]). ([I-D.filsfils-spring-segment-routing-policy]).
The Binding SID sub-TLV is optional, MUST NOT appear more than once The Binding SID sub-TLV is optional and it MUST NOT appear more than
in the SR Policy and has the following format: once in the SR Policy. If the Binding SID sub-TLV appears more than
once, the update is considered malformed and the "treat-as-withdraw"
strategy of [RFC7606] is applied.
The Binding SID sub-TLV has the following format:
0 1 2 3 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 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 | RESERVED | | Type | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding SID (variable, optional) | | Binding SID (variable, optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
o Type: 13 o Type: 13
o Length: specifies the length of the value field not including Type o Length: specifies the length of the value field not including Type
and Length fields. Can be 2 or 6 or 18. and Length fields. Can be 2 or 6 or 18.
o Flags: 1 octet of flags. None are defined at this stage. Flags o Flags: 1 octet of flags. Following flags are defined (to be
SHOULD be set to zero on transmission and MUST be ignored on assigned by IANA from the registry "SR Policy Binding SID Flags"
receipt. defined in this document Section 8.5):
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S|I| |
+-+-+-+-+-+-+-+-+
where:
* S-Flag: This flag encodes the "Specified-BSID-only" behavior.
It is used by SRTE process as described in section 6.2.3 in
([I-D.filsfils-spring-segment-routing-policy]).
* I-Flag: This flag encodes the "Drop Upon Invalid" behavior. It
is used by SRTE process as described in section 8.2 in
([I-D.filsfils-spring-segment-routing-policy]).
* Unused bits in the Flag octet SHOULD be set to zero upon
transmission and MUST be ignored upon receipt.
o RESERVED: 1 octet of reserved bits. SHOULD be unset on o RESERVED: 1 octet of reserved bits. SHOULD be unset on
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
o Binding SID: if length is 2, then no Binding SID is present. o Binding SID: if length is 2, then no Binding SID is present.
o If length is 6 then the Binding SID contains a 4-octet SID. Below o If length is 6 then the Binding SID contains a 4-octet SID. Below
format is used to encode the SID. TC, S, TTL(Total of 12bits) are format is used to encode the SID. TC, S, TTL(Total of 12bits) are
RESERVED and SHOULD be set to Zero and MUST be ignored. RESERVED and SHOULD be set to Zero and MUST be ignored.
skipping to change at page 10, line 33 skipping to change at page 11, line 45
as an optional Weight sub-TLV. as an optional Weight sub-TLV.
The Segment List sub-TLV may exceed 255 bytes length due to large The Segment List sub-TLV may exceed 255 bytes length due to large
number of segments. Therefore a 2-octet length is required. number of segments. Therefore a 2-octet length is required.
According to [I-D.ietf-idr-tunnel-encaps], the first bit of the sub- According to [I-D.ietf-idr-tunnel-encaps], the first bit of the sub-
TLV codepoint defines the size of the length field. Therefore, for TLV codepoint defines the size of the length field. Therefore, for
the Segment List sub-TLV a code point of 128 (or higher) is used. the Segment List sub-TLV a code point of 128 (or higher) is used.
See Section 8 for details of codepoints allocation. See Section 8 for details of codepoints allocation.
The Segment List sub-TLV is optional and MAY appear multiple times in The Segment List sub-TLV is optional and MAY appear multiple times in
the SR Policy. the SR Policy. The ordering of Segment List sub-TLVs, each sub-TLV
encoding a Segment List, does not matter.
The Segment List sub-TLV contains zero or more Segment sub-TLVs and The Segment List sub-TLV contains zero or more Segment sub-TLVs and
MAY contain a Weight sub-TLV. MAY contain a Weight sub-TLV.
The Segment List sub-TLV has the following format: The Segment List sub-TLV has the following format:
0 1 2 3 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 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 | RESERVED | | Type | Length | RESERVED |
skipping to change at page 11, line 18 skipping to change at page 12, line 30
o RESERVED: 1 octet of reserved bits. SHOULD be unset on o RESERVED: 1 octet of reserved bits. SHOULD be unset on
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
o sub-TLVs: o sub-TLVs:
* An optional single Weight sub-TLV. * An optional single Weight sub-TLV.
* Zero or more Segment sub-TLVs. * Zero or more Segment sub-TLVs.
Validation of an explicit path encoded by the Segment List sub-TLV is Validation of an explicit path encoded by the Segment List sub-TLV is
completely in the scope of SRTE process as described in section 5 in completely within the scope of SRTE process as described in section 5
([I-D.filsfils-spring-segment-routing-policy]). in ([I-D.filsfils-spring-segment-routing-policy]).
2.4.3.1. Weight Sub-TLV 2.4.3.1. Weight Sub-TLV
The Weight sub-TLV specifies the weight associated to a given The Weight sub-TLV specifies the weight associated to a given
candidate path (i.e., a given segment list). The contents of this candidate path (i.e., a given segment list). The contents of this
sub-TLV are used only by the SRTE process as described in section sub-TLV are used only by the SRTE process as described in section
2.11 in ([I-D.filsfils-spring-segment-routing-policy]). 2.11 in ([I-D.filsfils-spring-segment-routing-policy]).
The Weight sub-TLV is optional, MUST NOT appear more than once inside The Weight sub-TLV is optional and it MUST NOT appear more than once
the Segment List sub-TLV, and has the following format: inside the Segment List sub-TLV. If the Weight sub-TLV appears more
than once, the update is considered malformed and the "treat-as-
withdraw" strategy of [RFC7606] is applied.
The Weight sub-TLV has the following format:
0 1 2 3 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 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 | RESERVED | | Type | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Weight | | Weight |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
skipping to change at page 12, line 20 skipping to change at page 13, line 41
The Segment sub-TLV is optional and MAY appear multiple times in the The Segment sub-TLV is optional and MAY appear multiple times in the
Segment List sub-TLV. Segment List sub-TLV.
The Segment sub-TLV does not have any effect on the BGP bestpath The Segment sub-TLV does not have any effect on the BGP bestpath
selection or propagation procedures. The contents of this sub-TLV selection or propagation procedures. The contents of this sub-TLV
are used only by the SRTE process as described in section 4 in are used only by the SRTE process as described in section 4 in
([I-D.filsfils-spring-segment-routing-policy]). ([I-D.filsfils-spring-segment-routing-policy]).
[I-D.filsfils-spring-segment-routing-policy] defines several types of [I-D.filsfils-spring-segment-routing-policy] defines several types of
Segment Sub-TLVs: Segments:
Type 1: SID only, in the form of MPLS Label Type 1: SID only, in the form of MPLS Label
Type 2: SID only, in the form of IPv6 address Type 2: SID only, in the form of IPv6 address
Type 3: IPv4 Node Address with optional SID Type 3: IPv4 Node Address with optional SID
Type 4: IPv6 Node Address with optional SID Type 4: IPv6 Node Address with optional SID for SR MPLS
Type 5: IPv4 Address + index with optional SID Type 5: IPv4 Address + index with optional SID
Type 6: IPv4 Local and Remote addresses with optional SID Type 6: IPv4 Local and Remote addresses with optional SID
Type 7: IPv6 Address + index with optional SID Type 7: IPv6 Address + index for local and remote pair with optional SID for SR MPLS
Type 8: IPv6 Local and Remote addresses with optional SID Type 8: IPv6 Local and Remote addresses with optional SID for SR MPLS
Type 9: IPv6 Node Address with optional SID for SRv6
Type 10: IPv6 Address + index for local and remote pair with optional SID for SRv6
Type 11: IPv6 Local and Remote addresses for SRv6
2.4.3.2.1. Type 1: SID only, in the form of MPLS Label 2.4.3.2.1. Type 1: SID only, in the form of MPLS Label
The Type-1 Segment Sub-TLV encodes a single SID in the form of an The Type-1 Segment Sub-TLV encodes a single SID in the form of an
MPLS label. The format is as follows: MPLS label. The format is as follows:
0 1 2 3 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 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 | RESERVED | | Type | Length | Flags | RESERVED |
skipping to change at page 13, line 5 skipping to change at page 14, line 37
| Label | TC |S| TTL | | Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
o Type: 1 (to be assigned by IANA from the registry "SR Policy List o Type: 1 (to be assigned by IANA from the registry "SR Policy List
Sub-TLVs" defined in this document). Sub-TLVs" defined in this document).
o Length is 6. o Length is 6.
o Flags: 1 octet of flags. None are defined at this stage. Flags o Flags: 1 octet of flags as defined in Section 2.4.3.2.12.
SHOULD be set to zero on transmission and MUST be ignored on
receipt.
o RESERVED: 1 octet of reserved bits. SHOULD be unset on o RESERVED: 1 octet of reserved bits. SHOULD be unset on
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
o Label: 20 bits of label value. o Label: 20 bits of label value.
o TC: 3 bits of traffic class. o TC: 3 bits of traffic class.
o S: 1 bit of bottom-of-stack. o S: 1 bit of bottom-of-stack.
skipping to change at page 13, line 41 skipping to change at page 15, line 24
o If the originator wants to recommend a value for these fields, it o If the originator wants to recommend a value for these fields, it
puts those values in the TC and/or TTL fields. puts those values in the TC and/or TTL fields.
o The receiver MAY override the originator's values for these o The receiver MAY override the originator's values for these
fields. This would be determined by local policy at the receiver. fields. This would be determined by local policy at the receiver.
One possible policy would be to override the fields only if the One possible policy would be to override the fields only if the
fields have the default values specified above. fields have the default values specified above.
2.4.3.2.2. Type 2: SID only, in the form of IPv6 address 2.4.3.2.2. Type 2: SID only, in the form of IPv6 address
The Type-2 Segment Sub-TLV encodes a single SID in the form of an The Type-2 Segment Sub-TLV encodes a single SRv6 SID in the form of
IPv6 SID. The format is as follows: an IPv6 address. The format is as follows:
0 1 2 3 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 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 | RESERVED | | Type | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 SID (16 octets) // // SRv6 SID (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
o Type: 2 (to be assigned by IANA from the registry "SR Policy List o Type: 2 (to be assigned by IANA from the registry "SR Policy List
Sub-TLVs" defined in this document). Sub-TLVs" defined in this document).
o Length is 18. o Length is 18.
o Flags: 1 octet of flags. None are defined at this stage. Flags o Flags: 1 octet of flags as defined in Section 2.4.3.2.12.
SHOULD be set to zero on transmission and MUST be ignored on
receipt.
o RESERVED: 1 octet of reserved bits. SHOULD be unset on o RESERVED: 1 octet of reserved bits. SHOULD be unset on
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
o IPv6 SID: 16 octets of IPv6 address. o SRv6 SID: 16 octets of IPv6 address.
The IPv6 Segment Identifier (IPv6 SID) is defined in The IPv6 Segment Identifier (SRv6 SID) is defined in
[I-D.ietf-6man-segment-routing-header]. [I-D.ietf-6man-segment-routing-header].
2.4.3.2.3. Type 3: IPv4 Node Address with optional SID 2.4.3.2.3. Type 3: IPv4 Node Address with optional SID
The Type-3 Segment Sub-TLV encodes an IPv4 node address and an The Type-3 Segment Sub-TLV encodes an IPv4 node address, SR Algorithm
optional SID in the form of either an MPLS label or an IPv6 address. and an optional SID in the form of an MPLS label. The format is as
The format is as follows: follows:
0 1 2 3 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 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 | RESERVED | | Type | Length | Flags | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Node Address (4 octets) | | IPv4 Node Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SID (optional, 4 or 16 octets) // | SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
o Type: 3 (to be assigned by IANA from the registry "SR Policy List o Type: 3 (to be assigned by IANA from the registry "SR Policy List
Sub-TLVs" defined in this document). Sub-TLVs" defined in this document).
o Length is 6 or 10 or 22. o Length is 6 or 10.
o Flags: 1 octet of flags. None are defined at this stage. Flags o Flags: 1 octet of flags as defined in Section 2.4.3.2.12.
SHOULD be set to zero on transmission and MUST be ignored on
receipt.
o RESERVED: 1 octet of reserved bits. SHOULD be unset on o SR Algorithm: 1 octet specifying SR Algorithm as described in
transmission and MUST be ignored on receipt. section 3.1.1 in [I-D.ietf-spring-segment-routing], when A-Flag as
defined in Section 2.4.3.2.12 is present. SR Algorithm is used by
SRTE process as described in section 4 in
([I-D.filsfils-spring-segment-routing-policy]). When A-Flag is
not encoded, this field SHOULD be unset on transmission and MUST
be ignored on receipt.
o IPv4 Node Address: a 4 octet IPv4 address representing a node. o IPv4 Node Address: a 4 octet IPv4 address representing a node.
o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. o SID: 4 octet MPLS label.
The following applies to the Type-3 Segment sub-TLV: The following applies to the Type-3 Segment sub-TLV:
o The IPv4 Node Address MUST be present. o The IPv4 Node Address MUST be present.
o The SID is optional and MAY be of one of the following formats: o The SID is optional and specifies a 4 octet MPLS SID containing
label, TC, S and TTL as defined in Section 2.4.3.2.1.
* MPLS SID: a 4 octet label containing label, TC, S and TTL as
defined in Section 2.4.3.2.1.
* IPV6 SID: a 16 octet IPv6 address.
o If length is 6, then only the IPv4 Node Address is present. o If length is 6, then only the IPv4 Node Address is present.
o If length is 10, then the IPv4 Node Address and the MPLS SID are o If length is 10, then the IPv4 Node Address and the MPLS SID are
present. present.
o If length is 22, then the IPv4 Node Address and the IPv6 SID are 2.4.3.2.4. Type 4: IPv6 Node Address with optional SID for SR MPLS
present.
2.4.3.2.4. Type 4: IPv6 Node Address with optional SID
The Type-4 Segment Sub-TLV encodes an IPv6 node address and an The Type-4 Segment Sub-TLV encodes an IPv6 node address, SR Algorithm
optional SID in the form of either an MPLS label or an IPv6 address. and an optional SID in the form of an MPLS label. The format is as
The format is as follows: follows:
0 1 2 3 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 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 | RESERVED | | Type | Length | Flags | SR Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 Node Address (16 octets) // // IPv6 Node Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SID (optional, 4 or 16 octets) // | SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
o Type: 4 (to be assigned by IANA from the registry "SR Policy List o Type: 4 (to be assigned by IANA from the registry "SR Policy List
Sub-TLVs" defined in this document). Sub-TLVs" defined in this document).
o Length is 18 or 22 or 34. o Length is 18 or 22.
o Flags: 1 octet of flags. None are defined at this stage. Flags o Flags: 1 octet of flags as defined in Section 2.4.3.2.12.
SHOULD be set to zero on transmission and MUST be ignored on
receipt.
o RESERVED: 1 octet of reserved bits. SHOULD be unset on o SR Algorithm: 1 octet specifying SR Algorithm as described in
transmission and MUST be ignored on receipt. section 3.1.1 in [I-D.ietf-spring-segment-routing], when A-Flag as
defined in Section 2.4.3.2.12 is present. SR Algorithm is used by
SRTE process as described in section 4 in
([I-D.filsfils-spring-segment-routing-policy]). When A-Flag is
not encoded, this field SHOULD be unset on transmission and MUST
be ignored on receipt.
o IPv6 Node Address: a 16 octet IPv6 address representing a node. o IPv6 Node Address: a 16 octet IPv6 address representing a node.
o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. o SID: 4 octet MPLS label.
The following applies to the Type-4 Segment sub-TLV: The following applies to the Type-4 Segment sub-TLV:
o The IPv6 Node Address MUST be present. o The IPv6 Node Address MUST be present.
o The SID is optional and MAY be of one of the following formats: o The SID is optional and specifies a 4 octet MPLS SID containing
label, TC, S and TTL as defined in Section 2.4.3.2.1.
* MPLS SID: a 4 octet label containing label, TC, S and TTL as
defined in Section 2.4.3.2.1.
* IPV6 SID: a 16 octet IPv6 address.
o If length is 18, then only the IPv6 Node Address is present. o If length is 18, then only the IPv6 Node Address is present.
o If length is 22, then the IPv6 Node Address and the MPLS SID are o If length is 22, then the IPv6 Node Address and the MPLS SID are
present. present.
o If length is 34, then the IPv6 Node Address and the IPv6 SID are
present.
2.4.3.2.5. Type 5: IPv4 Address + Local Interface ID with optional SID 2.4.3.2.5. Type 5: IPv4 Address + Local Interface ID with optional SID
The Type-5 Segment Sub-TLV encodes an IPv4 node address, a local The Type-5 Segment Sub-TLV encodes an IPv4 node address, a local
interface Identifier (Local Interface ID) and an optional SID in the interface Identifier (Local Interface ID) and an optional SID in the
form of either an MPLS label or an IPv6 address. The format is as form of an MPLS label. The format is as follows:
follows:
0 1 2 3 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 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 | RESERVED | | Type | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID (4 octets) | | Local Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Node Address (4 octets) | | IPv4 Node Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SID (optional, 4 or 16 octets) // | SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
o Type: 5 (to be assigned by IANA from the registry "SR Policy List o Type: 5 (to be assigned by IANA from the registry "SR Policy List
Sub-TLVs" defined in this document). Sub-TLVs" defined in this document).
o Length is 10 or 14 or 26. o Length is 10 or 14.
o Flags: 1 octet of flags. None are defined at this stage. Flags o Flags: 1 octet of flags as defined in Section 2.4.3.2.12.
SHOULD be set to zero on transmission and MUST be ignored on
receipt.
o RESERVED: 1 octet of reserved bits. SHOULD be unset on o RESERVED: 1 octet of reserved bits. SHOULD be unset on
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
o Local Interface ID: 4 octets as defined in o Local Interface ID: 4 octets of interface index as defined in
[I-D.ietf-pce-segment-routing]. [I-D.ietf-pce-segment-routing].
o IPv4 Node Address: a 4 octet IPv4 address representing a node. o IPv4 Node Address: a 4 octet IPv4 address representing a node.
o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. o SID: 4 octet MPLS label.
The following applies to the Type-5 Segment sub-TLV: The following applies to the Type-5 Segment sub-TLV:
o The IPv4 Node Address MUST be present. o The IPv4 Node Address MUST be present.
o The Local Interface ID MUST be present. o The Local Interface ID MUST be present.
o The SID is optional and MAY be of one of the following formats: o The SID is optional and specifies a 4 octet MPLS SID containing
label, TC, S and TTL as defined in Section 2.4.3.2.1.
* MPLS SID: a 4 octet label containing label, TC, S and TTL as
defined in Section 2.4.3.2.1.
* IPV6 SID: a 16 octet IPv6 SID.
o If length is 10, then the IPv4 Node Address and Local Interface ID o If length is 10, then the IPv4 Node Address and Local Interface ID
are present. are present.
o If length is 14, then the IPv4 Node Address, the Local Interface o If length is 14, then the IPv4 Node Address, the Local Interface
ID and the MPLS SID are present. ID and the MPLS SID are present.
o If length is 26, then the IPv4 Node Address, the Local Interface
ID and the IPv6 SID are present.
2.4.3.2.6. Type 6: IPv4 Local and Remote addresses with optional SID 2.4.3.2.6. Type 6: IPv4 Local and Remote addresses with optional SID
The Type-6 Segment Sub-TLV encodes an adjacency local address, an The Type-6 Segment Sub-TLV encodes an adjacency local address, an
adjacency remote address and an optional SID in the form of either an adjacency remote address and an optional SID in the form of an MPLS
MPLS label or an IPv6 address. The format is as follows: label. The format is as follows:
0 1 2 3 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 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 | RESERVED | | Type | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IPv4 Address (4 octets) | | Local IPv4 Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote IPv4 Address (4 octets) | | Remote IPv4 Address (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SID (4 or 16 octets) // | SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
o Type: 6 (to be assigned by IANA from the registry "SR Policy List o Type: 6 (to be assigned by IANA from the registry "SR Policy List
Sub-TLVs" defined in this document). Sub-TLVs" defined in this document).
o Length is 10 or 14 or 26. o Length is 10 or 14.
o Flags: 1 octet of flags. None are defined at this stage. Flags o Flags: 1 octet of flags as defined in Section 2.4.3.2.12.
SHOULD be set to zero on transmission and MUST be ignored on
receipt.
o RESERVED: 1 octet of reserved bits. SHOULD be unset on o RESERVED: 1 octet of reserved bits. SHOULD be unset on
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
o Local IPv4 Address: a 4 octet IPv4 address. o Local IPv4 Address: a 4 octet IPv4 address.
o Remote IPv4 Address: a 4 octet IPv4 address. o Remote IPv4 Address: a 4 octet IPv4 address.
o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. o SID: 4 octet MPLS label.
The following applies to the Type-6 Segment sub-TLV: The following applies to the Type-6 Segment sub-TLV:
o The Local IPv4 Address MUST be present and represents an adjacency o The Local IPv4 Address MUST be present and represents an adjacency
local address. local address.
o The Remote IPv4 Address MUST be present and represents the remote o The Remote IPv4 Address MUST be present and represents the remote
end of the adjacency. end of the adjacency.
o The SID is optional and MAY be of one of the following formats: o The SID is optional and specifies a 4 octet MPLS SID containing
label, TC, S and TTL as defined in Section 2.4.3.2.1.
* MPLS SID: a 4 octet label containing label, TC, S and TTL as
defined in Section 2.4.3.2.1.
* IPV6 SID: a 16 octet IPv6 address.
o If length is 10, then only the IPv4 Local and Remote addresses are o If length is 10, then only the IPv4 Local and Remote addresses are
present. present.
o If length is 14, then the IPv4 Local address, IPv4 Remote address o If length is 14, then the IPv4 Local address, IPv4 Remote address
and the MPLS SID are present. and the MPLS SID are present.
o If length is 26, then the IPv4 Local address, IPv4 Remote address 2.4.3.2.7. Type 7: IPv6 Address + Interface ID for local and remote
and the IPv6 SID are present. pair with optional SID for SR MPLS
2.4.3.2.7. Type 7: IPv6 Address + Local Interface ID with optional SID
The Type-7 Segment Sub-TLV encodes an IPv6 node address, a local The Type-7 Segment Sub-TLV encodes an IPv6 Link Local adjacency with
interface identifier (Local Interface ID) and an optional SID in the IPv6 local node address, a local interface identifier (Local
form of either an MPLS label or an IPv6 address. The format is as Interface ID), IPv6 remote node address , a remote interface
follows: identifier (Remote Interface ID) and an optional SID in the form of
an MPLS label. The format is as follows:
0 1 2 3 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 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 | RESERVED | | Type | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID (4 octets) | | Local Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 Node Address (16 octets) // // IPv6 Local Node Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SID (optional, 4 or 16 octets) // | Remote Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 Remote Node Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
o Type: 7 (to be assigned by IANA from the registry "SR Policy List o Type: 7 (to be assigned by IANA from the registry "SR Policy List
Sub-TLVs" defined in this document). Sub-TLVs" defined in this document).
o Length is 22 or 26 or 38. o Length is 22, 26, 42 or 46.
o Flags: 1 octet of flags. None are defined at this stage. Flags o Flags: 1 octet of flags as defined in Section 2.4.3.2.12.
SHOULD be set to zero on transmission and MUST be ignored on
receipt.
o RESERVED: 1 octet of reserved bits. SHOULD be unset on o RESERVED: 1 octet of reserved bits. SHOULD be unset on
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
o Local Interface ID: 4 octets of interface index. o Local Interface ID: 4 octets of interface index as defined in
[I-D.ietf-pce-segment-routing].
o IPv6 Node Address: a 16 octet IPv6 address representing a node. o IPv6 Local Node Address: a 16 octet IPv6 address.
o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. o Remote Interface ID: 4 octets of interface index as defined in
[I-D.ietf-pce-segment-routing].
The following applies to the Type-7 Segment sub-TLV: o IPv6 Remote Node Address: a 16 octet IPv6 address.
o The IPv6 Node Address MUST be present. o SID: 4 octet MPLS label.
o The Local Interface ID MUST be present. The following applies to the Type-7 Segment sub-TLV:
o The SID is optional and MAY be of one of the following formats: o The Local Interface ID and IPv6 Local Node Address MUST be
present.
* MPLS SID: a 4 octet label containing label, TC, S and TTL as o The Remote Interface ID and Remote Node Address pair is optional.
defined in Section 2.4.3.2.1. If Remote Interface ID is present, the Remote Node Address MUST be
present as well. Similarly, if Remote Node Address is present,
the Remote Interface ID MUST be present as well.
* IPV6 SID: a 16 octet IPv6 address. o The SID is optional and specifies a 4 octet MPLS SID containing
label, TC, S and TTL as defined in Section 2.4.3.2.1.
o If length is 22, then the IPv6 Node Address and Local Interface ID o If length is 22, then the Local Interface ID and the Local IPv6
are present. Address are present.
o If length is 26, then the IPv6 Node Address, the Local Interface o If length is 26, then the Local Interface ID, Local IPv6 Address
ID and the MPLS SID are present. and the MPLS SID are present.
o If length is 38, then the IPv6 Node Address, the Local Interface o If length is 42, then the Local Interface ID, Local IPv6 Node
ID and the IPv6 SID are present. Address, Remote Interface ID, and the Remote IPv6 Node Address are
present.
o If length is 46, then the Local Interface ID, Local IPv6 Node
Address, Remote Interface ID, Remote IPv6 Node Address and the
MPLS SID are present.
2.4.3.2.8. Type 8: IPv6 Local and Remote addresses with optional SID 2.4.3.2.8. Type 8: IPv6 Local and Remote addresses with optional SID
for SR MPLS
The Type-8 Segment Sub-TLV encodes an adjacency local address, an The Type-8 Segment Sub-TLV encodes an adjacency local address, an
adjacency remote address and an optional SID in the form of either an adjacency remote address and an optional SID in the form of an MPLS
MPLS label or an IPv6 address. The format is as follows: label. The format is as follows:
0 1 2 3 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 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 | RESERVED | | Type | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local IPv6 Address (16 octets) // // Local IPv6 Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Remote IPv6 Address (16 octets) // // Remote IPv6 Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SID (4 or 16 octets) // | SID (optional, 4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
o Type: 8 (to be assigned by IANA from the registry "SR Policy List o Type: 8 (to be assigned by IANA from the registry "SR Policy List
Sub-TLVs" defined in this document). Sub-TLVs" defined in this document).
o Length is 34 or 38 or 50. o Length is 34 or 38.
o Flags: 1 octet of flags. None are defined at this stage. Flags o Flags: 1 octet of flags as defined in Section 2.4.3.2.12.
SHOULD be set to zero on transmission and MUST be ignored on
receipt.
o RESERVED: 1 octet of reserved bits. SHOULD be unset on o RESERVED: 1 octet of reserved bits. SHOULD be unset on
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
o Local IPv6 Address: a 16 octet IPv6 address. o Local IPv6 Address: a 16 octet IPv6 address.
o Remote IPv6 Address: a 16 octet IPv6 address. o Remote IPv6 Address: a 16 octet IPv6 address.
o SID: either 4 octet MPLS SID or a 16 octet IPv6 SID. o SID: 4 octet MPLS label.
The following applies to the Type-8 Segment sub-TLV: The following applies to the Type-8 Segment sub-TLV:
o The Local IPv6 Address MUST be present and represents an adjacency o The Local IPv6 Address MUST be present and represents an adjacency
local address. local address.
o The Remote IPv6 Address MUST be present and represents the remote o The Remote IPv6 Address MUST be present and represents the remote
end of the adjacency. end of the adjacency.
o The SID is optional and MAY be of one of the following formats: o The SID is optional and specifies a 4 octet MPLS SID containing
label, TC, S and TTL as defined in Section 2.4.3.2.1.
* MPLS SID: a 4 octet label containing label, TC, S and TTL as o If length is 34, then only the IPv6 Local and Remote addresses are
defined in Section 2.4.3.2.1. present.
* IPV6 SID: a 16 octet IPv6 address. o If length is 38, then IPv6 Local and Remote addresses and the MPLS
SID are present.
o If length is 34, then only the IPv6 Local and Remote addresses are 2.4.3.2.9. Type 9: IPv6 Node Address with optional SRv6 SID
The Type-9 Segment Sub-TLV encodes an IPv6 node address, SR Algorithm
and an optional SID in the form of an IPv6 address. The format is as
follows:
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) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SID (optional, 16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
o Type: 10 (to be assigned by IANA from the registry "SR Policy List
Sub-TLVs" defined in this document).
o Length is 18 or 34.
o Flags: 1 octet of flags as defined in Section 2.4.3.2.12.
o SR Algorithm: 1 octet specifying SR Algorithm as described in
section 3.1.1 in [I-D.ietf-spring-segment-routing], when A-Flag as
defined in Section 2.4.3.2.12 is present. SR Algorithm is used by
SRTE process as described in section 4 in
([I-D.filsfils-spring-segment-routing-policy]). When A-Flag is
not encoded, this field SHOULD be unset on transmission and MUST
be ignored on receipt.
o IPv6 Node Address: a 16 octet IPv6 address.
o SID: 16 octet IPv6 address.
The following applies to the Type-9 Segment sub-TLV:
o The IPv6 Node Address MUST be present.
o The SID is optional and specifies a SRv6 SID in the form of 16
octet IPv6 address.
o If length is 18, then only the IPv6 Node Address is present.
o If length is 34, then the IPv6 Node Address and the SRv6 SID are
present. present.
o If length is 38, then the IPv6 Local address, IPv4 Remote address 2.4.3.2.10. Type 10: IPv6 Address + Interface ID for local and remote
and the MPLS SID are present. pair for SRv6 with optional SID
o If length is 50, then the IPv6 Local address, IPv4 Remote address The Type-10 Segment Sub-TLV encodes an IPv6 Link Local adjacency with
and the IPv6 SID are present. local node address, a local interface identifier (Local Interface
ID), remote IPv6 node address , a remote interface identifier (Remote
Interface ID) and an optional SID in the form of an IPv6 address.
The format is as follows:
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 | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 Local Node Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote Interface ID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// IPv6 Remote Node Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SID (optional, 16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
o Type: 11 (to be assigned by IANA from the registry "SR Policy List
Sub-TLVs" defined in this document).
o Length is 22, 38, 42 or 58.
o Flags: 1 octet of flags as defined in Section 2.4.3.2.12.
o RESERVED: 1 octet of reserved bits. SHOULD be unset on
transmission and MUST be ignored on receipt.
o Local Interface ID: 4 octets of interface index as defined in
[I-D.ietf-pce-segment-routing].
o IPv6 Local Node Address: a 16 octet IPv6 address.
o Remote Interface ID: 4 octets of interface index as defined in
[I-D.ietf-pce-segment-routing].
o IPv6 Remote Node Address: a 16 octet IPv6 address.
o SID: 16 octet IPv6 address.
The following applies to the Type-10 Segment sub-TLV:
o The Local Interface ID and the Local IPv6 Node Addresses MUST be
present.
o The Remote Interface ID and Remote Node Address pair is optional.
If Remote Interface ID is present, the Remote Node Address MUST be
present as well. Similarly, if Remote Node Address is present,
the Remote Interface ID MUST be present as well.
o The SID is optional and specifies a SRv6 SID in the form of 16
octet IPv6 address.
o If length is 22, then the Local Interface ID, Local IPv6 Node
Address, are present.
o If length is 38, then the Local Interface ID, Local IPv6 Node
Address and the SRv6 SID are present.
o If length is 42, then the Local Interface ID, Local IPv6 Node
Address, Remote Interface ID, and the Remote IPv6 Node Address are
present.
o If length is 58, then the Local Interface ID, Local IPv6 Node
Address, Remote Interface ID, Remote IPv6 Node Address and the
SRv6 SID are present.
2.4.3.2.11. Type 11: IPv6 Local and Remote addresses for SRv6 with
optional SID
The Type-11 Segment Sub-TLV encodes an adjacency local address, an
adjacency remote address and an optional SID in the form of IPv6
address. The format is as follows:
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 | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Local IPv6 Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Remote IPv6 Address (16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SID (optional, 16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
o Type: 12 (to be assigned by IANA from the registry "SR Policy List
Sub-TLVs" defined in this document).
o Length is 34 or 50.
o Flags: 1 octet of flags as defined in Section 2.4.3.2.12.
o RESERVED: 1 octet of reserved bits. SHOULD be unset on
transmission and MUST be ignored on receipt.
o Local IPv6 Address: a 16 octet IPv6 address.
o Remote IPv6 Address: a 16 octet IPv6 address.
o SID: 16 octet IPv6 address.
The following applies to the Type-11 Segment sub-TLV:
o The Local IPv6 Node Address MUST be present.
o The Remote IPv6 Node Address MUST be present.
o The SID is optional and specifies a SRv6 SID in the form of 16
octet IPv6 address.
o If length is 34, then the Local IPv6 Node Address and the Remote
IPv6 Node Address are present.
o If length is 50, then the Local IPv6 Node Address, the Remote IPv6
Node Address and the SRv6 SID are present.
2.4.3.2.12. Segment Flags
The Segment Types described above MAY contain following flags in the
"Flags" field (codes to be assigned by IANA from the registry "SR
Policy Segment Flags" defined in this document Section 8.6):
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|V|A| |
+-+-+-+-+-+-+-+-+
where:
V-Flag: This flag encodes the "Segment Validation" behavior. It
is used by SRTE process as described in section 5 in
([I-D.filsfils-spring-segment-routing-policy]).
A-Flag: This flag indicates the presence of SR Algorithm id in the
"SR Algorithm" field applicable to various Segment Types. SR
Algorithm is used by SRTE process as described in section 4 in
([I-D.filsfils-spring-segment-routing-policy]).
Unused bits in the Flag octet SHOULD be set to zero upon
transmission and MUST be ignored upon receipt.
The following applies to the Segment Flags:
o V-Flag is applicable to all Segment Types.
o A-Flag is applicable to Segment Types 3, 4 and 9. If A-Flag
appears with any other Segment Type, it MUST be ignored.
2.4.4. Explicit NULL Label Policy Sub-TLV 2.4.4. Explicit NULL Label Policy Sub-TLV
In order to steer an unlabeled IP packet into an SR policy, it is In order to steer an unlabeled IP packet into an SR policy, it is
necessary to create a label stack for that packet, and to push one or necessary to create a label stack for that packet, and to push one or
more labels onto that stack. more labels onto that stack.
The Explicit NULL Label Policy sub-TLV is used to indicate whether an The Explicit NULL Label Policy sub-TLV is used to indicate whether an
Explicit NULL Label [RFC3032] must be pushed on an unlabeled IP Explicit NULL Label [RFC3032] must be pushed on an unlabeled IP
packet before any other labels. packet before any other labels.
skipping to change at page 22, line 23 skipping to change at page 27, line 48
0 1 2 3 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 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 | RESERVED | | Type | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ENLP | | ENLP |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Where: Where:
Type: TBD (to be assigned by IANA from the registry "SR Policy Type: TBD1 (to be assigned by IANA from the registry "BGP Tunnel
List Sub-TLVs" defined in this document). Encapsulation Attribute sub-TLVs" defined in this document
Section 8.3).
Length: 3. Length: 3.
Flags: 1 octet of flags. None are defined at this stage. Flags Flags: 1 octet of flags. None are defined at this stage. Flags
SHOULD be set to zero on transmission and MUST be ignored on SHOULD be set to zero on transmission and MUST be ignored on
receipt. receipt.
RESERVED: 1 octet of reserved bits. SHOULD be unset on RESERVED: 1 octet of reserved bits. SHOULD be unset on
transmission and MUST be ignored on receipt. transmission and MUST be ignored on receipt.
ELNP(Explicit NULL Label Policy): Indicates whether Explicit NULL ENLP(Explicit NULL Label Policy): Indicates whether Explicit NULL
labels are to be pushed on unlabled IP packets that are being labels are to be pushed on unlabeled IP packets that are being
steered into a given SR policy. This field has one of the steered into a given SR policy. This field has one of the
following 4 values: following 4 values:
1: Push an IPv4 Explicit NULL label on an unlabeled IPv4 1: Push an IPv4 Explicit NULL label on an unlabeled IPv4
packet, but do not push an IPv6 Explicit NULL label on an packet, but do not push an IPv6 Explicit NULL label on an
unlabeled IPv6 packet. unlabeled IPv6 packet.
2: Push an IPv6 Explicit NULL label on an unlabeled IPv6 2: Push an IPv6 Explicit NULL label on an unlabeled IPv6
packet, but do not push an IPv4 Explicit NULL label on an packet, but do not push an IPv4 Explicit NULL label on an
unlabeled IPv4 packet. unlabeled IPv4 packet.
3: Push an IPv4 Explicit NULL label on an unlabeled IPv4 3: Push an IPv4 Explicit NULL label on an unlabeled IPv4
packet, and push an IPv6 Explicit NULL label on an unlabeled packet, and push an IPv6 Explicit NULL label on an unlabeled
IPv6 packet. IPv6 packet.
4: Do not push an Explicit NULL label. 4: Do not push an Explicit NULL label.
The policy signaled in this Sub-TLV MAY be overridden by local The policy signaled in this Sub-TLV MAY be overridden by local
policy. policy.
2.4.5. Policy Priority Sub-TLV
An operator MAY set the Policy Priority sub-TLV to indicate the order
in which the SR policies are re-computed upon topological change.
The Priority sub-TLV does not have any effect on the BGP bestpath
selection or propagation procedures. The contents of this sub-TLV
are used by the SRTE process as described in section 2.11 in
([I-D.filsfils-spring-segment-routing-policy]).
The Priority sub-TLV is optional and it MUST not appear more than
once in the SR Policy TLV. If the Priority sub-TLV appears more than
once, the update is considered malformed and the "treat-as-withdraw"
strategy of [RFC7606] is applied.
The Priority sub-TLV has following format:
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 | Priority | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
Type: TBD2 (to be assigned by IANA from the registry "BGP Tunnel
Encapsulation Attribute sub-TLVs" defined in this document
Section 8.3).
Length: 2.
Priority: a 1-octet value.
RESERVED: 1 octet of reserved bits. SHOULD be unset on
transmission and MUST be ignored on receipt.
2.4.6. Policy Name Sub-TLV
An operator MAY set the Policy Name sub-TLV to attach a symbolic name
to the SR Policy candidate path.
Usage of Policy Name sub-TLV is described in section 2 in
([I-D.filsfils-spring-segment-routing-policy]).
The Policy Name sub-TLV may exceed 255 bytes length due to long
policy name. Therefore a 2-octet length is required. According to
[I-D.ietf-idr-tunnel-encaps], the first bit of the sub-TLV codepoint
defines the size of the length field. Therefore, for the Policy Name
sub-TLV a code point of 128 (or higher) is used. See Section 8 for
details of codepoints allocation.
The Policy Name sub-TLV is optional and it MUST not appear more than
once in the SR Policy TLV. If the Policy Name sub-TLV appears more
than once, the update is considered malformed and the "treat-as-
withdraw" strategy of [RFC7606] is applied.
The Policy Name sub-TLV has following format:
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 | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Policy Name //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where:
Type: TBD3 (to be assigned by IANA from the registry "BGP Tunnel
Encapsulation Attribute sub-TLVs" defined in this document
Section 8.3).
Length: Variable.
RESERVED: 1 octet of reserved bits. SHOULD be unset on
transmission and MUST be ignored on receipt.
Policy Name: Symbolic name for the policy. It SHOULD be a string
of printable ASCII characters, without a NULL terminator.
3. Extended Color Community 3. Extended Color Community
The Color Extended Community as defined in The Color Extended Community as defined in
[I-D.ietf-idr-tunnel-encaps] is used to steer traffic into a policy. [I-D.ietf-idr-tunnel-encaps] is used to steer traffic into a policy.
When the Color Extended Community is used for the purpose of steering When the Color Extended Community is used for the purpose of steering
the traffic into an SRTE policy, the RESERVED field (as defined in the traffic into an SRTE policy, the RESERVED field (as defined in
[I-D.ietf-idr-tunnel-encaps] is changed as follows: [I-D.ietf-idr-tunnel-encaps] is changed as follows:
1 1
skipping to change at page 25, line 24 skipping to change at page 32, line 36
Engineering (SRTE) process. The description of the SRTE process is Engineering (SRTE) process. The description of the SRTE process is
outside the scope of this document and it's described in outside the scope of this document and it's described in
[I-D.filsfils-spring-segment-routing-policy]. [I-D.filsfils-spring-segment-routing-policy].
4.2.3. Passing a usable SR Policy NLRI to the SRTE Process 4.2.3. Passing a usable SR Policy NLRI to the SRTE Process
Once BGP has determined that the SR Policy NLRI is usable, BGP passes Once BGP has determined that the SR Policy NLRI is usable, BGP passes
the path to the SRTE process described in the path to the SRTE process described in
([I-D.filsfils-spring-segment-routing-policy]). Note that, along ([I-D.filsfils-spring-segment-routing-policy]). Note that, along
with the path details, BGP also passes the originator information for with the path details, BGP also passes the originator information for
breaking ties in path-selection process as described in section 2.4 breaking ties in the path-selection process as described in section
in [I-D.filsfils-spring-segment-routing-policy]. 2.4 in [I-D.filsfils-spring-segment-routing-policy].
The SRTE process applies the rules defined in section 2 The SRTE process applies the rules defined in section 2
[I-D.filsfils-spring-segment-routing-policy] to determine whether a [I-D.filsfils-spring-segment-routing-policy] to determine whether a
path is valid and to select the best path among the valid paths. path is valid and to select the best path among the valid paths.
4.2.4. Propagation of an SR Policy 4.2.4. Propagation of an SR Policy
By default, a BGP node receiving an SR Policy NLRI MUST NOT propagate By default, a BGP node receiving an SR Policy NLRI MUST NOT propagate
it to any EBGP neighbor. it to any EBGP neighbor.
skipping to change at page 27, line 49 skipping to change at page 35, line 15
8. IANA Considerations 8. IANA Considerations
This document defines new Sub-TLVs in following existing registries: This document defines new Sub-TLVs in following existing registries:
o Subsequent Address Family Identifiers (SAFI) Parameters o Subsequent Address Family Identifiers (SAFI) Parameters
o BGP Tunnel Encapsulation Attribute Tunnel Types o BGP Tunnel Encapsulation Attribute Tunnel Types
o BGP Tunnel Encapsulation Attribute sub-TLVs o BGP Tunnel Encapsulation Attribute sub-TLVs
This document also defines a new registry: "SR Policy List Sub-TLVs". This document also defines following new registries:
o SR Policy List Sub-TLVs
o SR Policy Binding SID Flags
o SR Policy Segment Flags
8.1. Existing Registry: Subsequent Address Family Identifiers (SAFI) 8.1. Existing Registry: Subsequent Address Family Identifiers (SAFI)
Parameters Parameters
This document defines a new SAFI in the registry "Subsequent Address This document defines a new SAFI in the registry "Subsequent Address
Family Identifiers (SAFI) Parameters" that has been assigned by IANA: Family Identifiers (SAFI) Parameters" that has been assigned by IANA:
Codepoint Description Reference Codepoint Description Reference
----------------------------------------------- -----------------------------------------------
73 SR Policy SAFI This document 73 SR Policy SAFI This document
skipping to change at page 28, line 34 skipping to change at page 36, line 10
8.3. Existing Registry: BGP Tunnel Encapsulation Attribute sub-TLVs 8.3. Existing Registry: BGP Tunnel Encapsulation Attribute sub-TLVs
This document defines new sub-TLVs in the registry "BGP Tunnel This document defines new sub-TLVs in the registry "BGP Tunnel
Encapsulation Attribute sub-TLVs" to be assigned by IANA: Encapsulation Attribute sub-TLVs" to be assigned by IANA:
Codepoint Description Reference Codepoint Description Reference
------------------------------------------------------ ------------------------------------------------------
12 Preference sub-TLV This document 12 Preference sub-TLV This document
13 Binding SID sub-TLV This document 13 Binding SID sub-TLV This document
128 Segment List sub-TLV This document 128 Segment List sub-TLV This document
TBD1 ENLP sub-TLV This document
TBD2 Priority sub-TLV This document
TBD3 Policy Name sub-TLV This document
8.4. New Registry: SR Policy List Sub-TLVs 8.4. New Registry: SR Policy List Sub-TLVs
This document defines a new registry called "SR Policy List Sub- This document defines a new registry called "SR Policy List Sub-
TLVs". The allocation policy of this registry is "First Come First TLVs". The allocation policy of this registry is "First Come First
Served (FCFS)" according to [RFC8126]. Served (FCFS)" according to [RFC8126].
Following Sub-TLV codepoints are defined: Following Sub-TLV codepoints are defined:
Value Description Reference Value Description Reference
------------------------------------------------------------------ ---------------------------------------------------------------------------------
1 MPLS SID sub-TLV This document 1 MPLS SID sub-TLV This document
2 IPv6 SID sub-TLV This document 2 SRv6 SID sub-TLV This document
3 IPv4 Node and SID sub-TLV This document 3 IPv4 Node and SID sub-TLV This document
4 IPv6 Node and SID sub-TLV This document 4 IPv6 Node and SID for SR-MPLS sub-TLV This document
5 IPv4 Node, index and SID sub-TLV This document 5 IPv4 Node, index and SID sub-TLV This document
6 IPv4 Local/Remote addresses and SID sub-TLV This document 6 IPv4 Local/Remote addresses and SID sub-TLV This document
7 IPv6 Node, index and SID sub-TLV This document 7 IPv6 Node, index for remote and local pair This document
8 IPv6 Local/Remote addresses and SID sub-TLV This document and SID for SR-MPLS sub-TLV
9 Weight sub-TLV This document 8 IPv6 Local/Remote addresses and SID sub-TLV This document
9 Weight sub-TLV This document
10 IPv6 Node and SID for SRv6 sub-TLV This document
11 IPv6 Node, index for remote and local pair This document
and SID for SRv6 sub-TLV
12 IPv6 Local/Remote addresses and SID for This document
SRv6 sub-TLV
8.5. New Registry: SR Policy Binding SID Flags
This document defines a new registry called "SR Policy Binding SID
Flags". The allocation policy of this registry is "First Come First
Served (FCFS)" according to [RFC8126].
Following Flags are defined:
Bit Description Reference
---------------------------------------------------------------------------------
0 Drop Upon Invalid Flag (I-Flag) This document
1 Specified-BSID-Only Flag (S-Flag) This document
2-7 Unassigned
8.6. New Registry: SR Policy Segment Flags
This document defines a new registry called "SR Policy Segment
Flags". The allocation policy of this registry is "First Come First
Served (FCFS)" according to [RFC8126].
Following Flags are defined:
Bit Description Reference
---------------------------------------------------------------------------------
0 Segment Validation Flag (V-Flag) This document
1 SR Algorithm Flag (A-Flag) This document
2-7 Unassigned
9. Security Considerations 9. Security Considerations
TBD. TBD.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.filsfils-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad,
F., Talaulikar, K., Ali, Z., Hegde, S.,
daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com,
b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B.,
Litkowski, S., and P. Mattes, "Segment Routing Policy for
Traffic Engineering", draft-filsfils-spring-segment-
routing-policy-05 (work in progress), February 2018.
[I-D.ietf-idr-tunnel-encaps] [I-D.ietf-idr-tunnel-encaps]
Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel
Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-09 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-09
(work in progress), February 2018. (work in progress), February 2018.
[I-D.ietf-pce-segment-routing] [I-D.ietf-pce-segment-routing]
Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
and J. Hardwick, "PCEP Extensions for Segment Routing", and J. Hardwick, "PCEP Extensions for Segment Routing",
draft-ietf-pce-segment-routing-11 (work in progress), draft-ietf-pce-segment-routing-11 (work in progress),
November 2017. November 2017.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>. <https://www.rfc-editor.org/info/rfc3032>.
skipping to change at page 30, line 31 skipping to change at page 38, line 46
RFC 7606, DOI 10.17487/RFC7606, August 2015, RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>. <https://www.rfc-editor.org/info/rfc7606>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
10.2. Informational References 10.2. Informational References
[I-D.filsfils-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., Raza, K., Liste, J., Clad,
F., Talaulikar, K., Ali, Z., Hegde, S.,
daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com,
b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B.,
Litkowski, S., and P. Mattes, "Segment Routing Policy for
Traffic Engineering", draft-filsfils-spring-segment-
routing-policy-05 (work in progress), February 2018.
[I-D.ietf-6man-segment-routing-header] [I-D.ietf-6man-segment-routing-header]
Previdi, S., Filsfils, C., Raza, K., Dukes, D., Leddy, J., Previdi, S., Filsfils, C., Leddy, J., Matsushima, S., and
Field, B., daniel.voyer@bell.ca, d., d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
daniel.bernier@bell.ca, d., Matsushima, S., Leung, I., (SRH)", draft-ietf-6man-segment-routing-header-12 (work in
Linkova, J., Aries, E., Kosugi, T., Vyncke, E., Lebrun, progress), April 2018.
D., Steinberg, D., and R. Raszuk, "IPv6 Segment Routing
Header (SRH)", draft-ietf-6man-segment-routing-header-08
(work in progress), January 2018.
[I-D.ietf-idr-flowspec-redirect-ip] [I-D.ietf-idr-flowspec-redirect-ip]
Uttaro, J., Haas, J., Texier, M., Andy, A., Ray, S., Uttaro, J., Haas, J., Texier, M., Andy, A., Ray, S.,
Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to Simpson, A., and W. Henderickx, "BGP Flow-Spec Redirect to
IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work IP Action", draft-ietf-idr-flowspec-redirect-ip-02 (work
in progress), February 2015. in progress), February 2015.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<https://www.rfc-editor.org/info/rfc4456>. <https://www.rfc-editor.org/info/rfc4456>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205, Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016, RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>. <https://www.rfc-editor.org/info/rfc7942>.
 End of changes. 104 change blocks. 
241 lines changed or deleted 592 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/