draft-ietf-idr-te-lsp-distribution-09.txt   draft-ietf-idr-te-lsp-distribution-10.txt 
Network Working Group S. Previdi, Ed. Network Working Group S. Previdi
Internet-Draft Internet-Draft
Intended status: Standards Track K. Talaulikar Intended status: Standards Track K. Talaulikar, Ed.
Expires: December 31, 2018 Cisco Systems, Inc. Expires: August 30, 2019 Cisco Systems, Inc.
J. Dong, Ed. J. Dong, Ed.
M. Chen M. Chen
Huawei Technologies Huawei Technologies
H. Gredler H. Gredler
RtBrick Inc. RtBrick Inc.
J. Tantsura J. Tantsura
Nuage Networks Apstra
June 29, 2018 February 26, 2019
Distribution of Traffic Engineering (TE) Policies and State using BGP-LS Distribution of Traffic Engineering (TE) Policies and State using BGP-LS
draft-ietf-idr-te-lsp-distribution-09 draft-ietf-idr-te-lsp-distribution-10
Abstract Abstract
This document describes a mechanism to collect the Traffic This document describes a mechanism to collect the Traffic
Engineering and Policy information that is locally available in a Engineering and Policy information that is locally available in a
node and advertise it into BGP-LS updates. Such information can be node and advertise it into BGP Link State (BGP-LS) updates. Such
used by external components for path computation, re-optimization, information can be used by external components for path computation,
service placement, network visualization, etc. re-optimization, service placement, network visualization, etc.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "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.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 August 30, 2019.
This Internet-Draft will expire on December 31, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 44 skipping to change at page 2, line 45
5. MPLS-TE Policy State TLV . . . . . . . . . . . . . . . . . . 14 5. MPLS-TE Policy State TLV . . . . . . . . . . . . . . . . . . 14
5.1. RSVP Objects . . . . . . . . . . . . . . . . . . . . . . 15 5.1. RSVP Objects . . . . . . . . . . . . . . . . . . . . . . 15
5.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 16 5.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 16
6. SR Policy State TLVs . . . . . . . . . . . . . . . . . . . . 17 6. SR Policy State TLVs . . . . . . . . . . . . . . . . . . . . 17
6.1. SR Binding SID . . . . . . . . . . . . . . . . . . . . . 17 6.1. SR Binding SID . . . . . . . . . . . . . . . . . . . . . 17
6.2. SR Candidate Path State . . . . . . . . . . . . . . . . . 19 6.2. SR Candidate Path State . . . . . . . . . . . . . . . . . 19
6.3. SR Candidate Path Name . . . . . . . . . . . . . . . . . 21 6.3. SR Candidate Path Name . . . . . . . . . . . . . . . . . 21
6.4. SR Candidate Path Constraints . . . . . . . . . . . . . . 21 6.4. SR Candidate Path Constraints . . . . . . . . . . . . . . 21
6.4.1. SR Affinity Constraint . . . . . . . . . . . . . . . 23 6.4.1. SR Affinity Constraint . . . . . . . . . . . . . . . 23
6.4.2. SR SRLG Constraint . . . . . . . . . . . . . . . . . 24 6.4.2. SR SRLG Constraint . . . . . . . . . . . . . . . . . 24
6.4.3. SR Bandwidth Constraint . . . . . . . . . . . . . . . 24 6.4.3. SR Bandwidth Constraint . . . . . . . . . . . . . . . 25
6.4.4. SR Disjoint Group Constraint . . . . . . . . . . . . 25 6.4.4. SR Disjoint Group Constraint . . . . . . . . . . . . 25
6.5. SR Segment List . . . . . . . . . . . . . . . . . . . . . 27 6.5. SR Segment List . . . . . . . . . . . . . . . . . . . . . 27
6.6. SR Segment . . . . . . . . . . . . . . . . . . . . . . . 29 6.6. SR Segment . . . . . . . . . . . . . . . . . . . . . . . 30
6.6.1. Segment Descriptors . . . . . . . . . . . . . . . . . 31 6.6.1. Segment Descriptors . . . . . . . . . . . . . . . . . 31
6.7. SR Segment List Metric . . . . . . . . . . . . . . . . . 37 6.7. SR Segment List Metric . . . . . . . . . . . . . . . . . 38
7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 39 7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 40
8. Manageability Considerations . . . . . . . . . . . . . . . . 40 8. Manageability Considerations . . . . . . . . . . . . . . . . 41
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
9.1. BGP-LS NLRI-Types . . . . . . . . . . . . . . . . . . . . 40 9.1. BGP-LS NLRI-Types . . . . . . . . . . . . . . . . . . . . 41
9.2. BGP-LS Protocol-IDs . . . . . . . . . . . . . . . . . . . 40 9.2. BGP-LS Protocol-IDs . . . . . . . . . . . . . . . . . . . 41
9.3. BGP-LS TLVs . . . . . . . . . . . . . . . . . . . . . . . 41 9.3. BGP-LS TLVs . . . . . . . . . . . . . . . . . . . . . . . 42
9.4. BGP-LS SR Policy Protocol Origin . . . . . . . . . . . . 41 9.4. BGP-LS SR Policy Protocol Origin . . . . . . . . . . . . 42
9.5. BGP-LS TE State Path Origin . . . . . . . . . . . . . . . 42 9.5. BGP-LS TE State Object Origin . . . . . . . . . . . . . . 43
9.6. BGP-LS TE State Dataplane . . . . . . . . . . . . . . . . 42 9.6. BGP-LS TE State Address Family . . . . . . . . . . . . . 43
9.7. BGP-LS SR Segment Descriptors . . . . . . . . . . . . . . 43 9.7. BGP-LS SR Segment Descriptors . . . . . . . . . . . . . . 44
9.8. BGP-LS Metric Type . . . . . . . . . . . . . . . . . . . 43 9.8. BGP-LS Metric Type . . . . . . . . . . . . . . . . . . . 44
10. Security Considerations . . . . . . . . . . . . . . . . . . . 44 10. Security Considerations . . . . . . . . . . . . . . . . . . . 45
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 44 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 45
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
13.1. Normative References . . . . . . . . . . . . . . . . . . 44 13.1. Normative References . . . . . . . . . . . . . . . . . . 45
13.2. Informative References . . . . . . . . . . . . . . . . . 46 13.2. Informative References . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
In many network environments, traffic engineering policies are In many network environments, traffic engineering (TE) policies are
instantiated into various forms: instantiated into various forms:
o MPLS Traffic Engineering Label Switched Paths (TE-LSPs). o MPLS Traffic Engineering Label Switched Paths (TE-LSPs).
o IP based tunnels (IP in IP, GRE, etc). o IP based tunnels (IP in IP, GRE, etc).
o Segment Routing Policies (SR Policy) as defined in o Segment Routing (SR) Policies as defined in
[I-D.ietf-spring-segment-routing-policy] [I-D.ietf-spring-segment-routing-policy]
o Local MPLS cross-connect configuration o Local MPLS cross-connect configuration
All this information can be grouped into the same term: TE Policies. All this information can be grouped into the same term: TE Policies.
In the rest of this document we refer to TE Policies as the set of In the rest of this document we refer to TE Policies as the set of
information related to the various instantiation of polices: MPLS TE information related to the various instantiation of polices: MPLS TE
LSPs, IP tunnels (IPv4 or IPv6), SR Policies, etc. LSPs, IP tunnels (IPv4 or IPv6), SR Policies, etc.
TE Polices are generally instantiated at the head-end and are based TE Polices are generally instantiated at the head-end and are based
skipping to change at page 6, line 41 skipping to change at page 6, line 43
| Protocol-ID | NLRI information source protocol | | Protocol-ID | NLRI information source protocol |
+-------------+----------------------------------+ +-------------+----------------------------------+
| TBD | RSVP-TE | | TBD | RSVP-TE |
| TBD | Segment Routing | | TBD | Segment Routing |
+-------------+----------------------------------+ +-------------+----------------------------------+
o "Identifier" is an 8 octet value as defined in [RFC7752]. o "Identifier" is an 8 octet value as defined in [RFC7752].
o "Headend" consists of a Node Descriptor defined in [RFC7752]. o "Headend" consists of a Node Descriptor defined in [RFC7752].
o "TE Policy Descriptors" consists of (values TBD see IANA o "TE Policy Descriptors" consists of one or more of the TLVs listed
Considerations Section 9.3): as below: (values TBD see IANA Considerations Section 9.3):
+-----------+----------------------------------+ +-----------+----------------------------------+
| Codepoint | Descriptor TLVs | | Codepoint | Descriptor TLVs |
+-----------+----------------------------------+ +-----------+----------------------------------+
| TBD | Tunnel ID | | TBD | Tunnel ID |
| TBD | LSP ID | | TBD | LSP ID |
| TBD | IPv4/6 Tunnel Head-end address | | TBD | IPv4/6 Tunnel Head-end address |
| TBD | IPv4/6 Tunnel Tail-end address | | TBD | IPv4/6 Tunnel Tail-end address |
| TBD | SR Policy Candidate Path | | TBD | SR Policy Candidate Path |
| TBD | Local MPLS Cross Connect | | TBD | Local MPLS Cross Connect |
skipping to change at page 10, line 30 skipping to change at page 10, line 30
receiver. receiver.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|E|O| | |E|O| |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
where: where:
* E-Flag : Indicates the encoding of endpoint as IPv6 address * E-Flag : Indicates the encoding of endpoint as IPv6 address
when SET and IPv4 address when CLEAR when set and IPv4 address when clear
* O-Flag : Indicates the encoding of originator address as IPv6 * O-Flag : Indicates the encoding of originator address as IPv6
address when SET and IPv4 address when CLEAR address when set and IPv4 address when clear
o Reserved : 2 octets which SHOULD be set to 0 by originator and o Reserved : 2 octets which SHOULD be set to 0 by originator and
MUST be ignored by receiver. MUST be ignored by receiver.
o Endpoint : 4 or 16 octets (as indicated by the flags) containing o Endpoint : 4 or 16 octets (as indicated by the flags) containing
the address of the endpoint of the SR Policy the address of the endpoint of the SR Policy
o Color : 4 octets that indicates the color of the SR Policy o Color : 4 octets that indicates the color of the SR Policy
o Originator ASN : 4 octets to carry the 4 byte encoding of the ASN o Originator ASN : 4 octets to carry the 4 byte encoding of the ASN
skipping to change at page 14, line 19 skipping to change at page 14, line 19
where: where:
* 4-Flag is the IPv4 flag. When set, the FEC Sub-TLV describes * 4-Flag is the IPv4 flag. When set, the FEC Sub-TLV describes
an IPv4 FEC. If the 4-flag is not set, then the FEC Sub-TLV an IPv4 FEC. If the 4-flag is not set, then the FEC Sub-TLV
describes an IPv6 FEC. describes an IPv6 FEC.
o Mask Length: 1 octet of prefix length. o Mask Length: 1 octet of prefix length.
o Prefix: an IPv4 or IPv6 prefix whose mask length is given by the " o Prefix: an IPv4 or IPv6 prefix whose mask length is given by the "
Mask Length" field. Mask Length" field padded to an octet boundary.
5. MPLS-TE Policy State TLV 5. MPLS-TE Policy State TLV
A new TLV called "MPLS-TE Policy State TLV", is used to describe the A new TLV called "MPLS-TE Policy State TLV", is used to describe the
characteristics of the MPLS-TE Policy and it is carried in the characteristics of the MPLS-TE Policy and it is carried in the
optional non-transitive BGP Attribute "LINK_STATE Attribute" defined optional non-transitive BGP Attribute "LINK_STATE Attribute" defined
in [RFC7752]. These MPLS-TE Policy characteristics include the in [RFC7752]. These MPLS-TE Policy characteristics include the
characteristics and attributes of the policy, it's dataplane, characteristics and attributes of the policy, its dataplane, explicit
explicit path, Quality of Service (QoS) parameters, route path, Quality of Service (QoS) parameters, route information, the
information, the protection mechanisms, etc. protection mechanisms, etc.
The MPLS-TE Policy State TLV has the following format: The MPLS-TE Policy State 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path-origin | Dataplane | RESERVED | | Object-origin | Address Family| RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// MPLS-TE Policy State Objects (variable) // // MPLS-TE Policy State Objects (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
MPLS-TE Policy State TLV MPLS-TE Policy State TLV
o Type: TBD (see IANA Considerations Section 9.3) o Type: TBD (see IANA Considerations Section 9.3)
o Length: the total length of the MPLS-TE Policy State TLV not o Length: the total length of the MPLS-TE Policy State TLV not
including Type and Length fields. including Type and Length fields.
o Path-origin: identifies the component (or protocol) from which the o Object-origin: identifies the component (or protocol) from which
contained object originated. This allows for objects defined in the contained object originated. This allows for objects defined
different components to be collected while avoiding the possible in different components to be collected while avoiding the
codepoint collisions among these components. Following path- possible codepoint collisions among these components. Following
origin codepoints are defined in this document. object-origin codepoints are defined in this document.
+----------+------------------+ +----------+------------------+
| Code | Path | | Code | Object |
| Point | Origin | | Point | Origin |
+----------+------------------+ +----------+------------------+
| 1 | RSVP-TE | | 1 | RSVP-TE |
| 2 | PCEP | | 2 | PCEP |
| 3 | Local/Static | | 3 | Local/Static |
+----------+------------------+ +----------+------------------+
o Dataplane: describes to which dataplane the policy is applied to. o Address Family: describes the address family used to setup the
The following dataplane values are defined in this document: MPLS-TE policy. The following address family values are defined
in this document:
+----------+------------------+ +----------+------------------+
| Code | Dataplane | | Code | Dataplane |
| Point | | | Point | |
+----------+------------------+ +----------+------------------+
| 1 | MPLS-IPv4 | | 1 | MPLS-IPv4 |
| 2 | MPLS-IPv6 | | 2 | MPLS-IPv6 |
+----------+------------------+ +----------+------------------+
o RESERVED: 16-bit field. SHOULD be set to 0 on transmission and o RESERVED: 16-bit field. SHOULD be set to 0 on transmission and
skipping to change at page 16, line 5 skipping to change at page 16, line 5
5.1. RSVP Objects 5.1. RSVP Objects
RSVP-TE objects are encoded in the "MPLS-TE Policy State Objects" RSVP-TE objects are encoded in the "MPLS-TE Policy State Objects"
field of the MPLS-TE Policy State TLV and consists of MPLS TE LSP field of the MPLS-TE Policy State TLV and consists of MPLS TE LSP
objects defined in RSVP-TE [RFC3209] [RFC3473]. Rather than objects defined in RSVP-TE [RFC3209] [RFC3473]. Rather than
replicating all MPLS TE LSP related objects in this document, the replicating all MPLS TE LSP related objects in this document, the
semantics and encodings of the MPLS TE LSP objects are re-used. semantics and encodings of the MPLS TE LSP objects are re-used.
These MPLS TE LSP objects are carried in the MPLS-TE Policy State These MPLS TE LSP objects are carried in the MPLS-TE Policy State
TLV. TLV.
When carrying RSVP-TE objects, the "Path-Origin" field is set to When carrying RSVP-TE objects, the "Object-Origin" field is set to
"RSVP-TE". "RSVP-TE".
The following RSVP-TE Objects are defined: The following RSVP-TE Objects are defined:
o SENDER_TSPEC and FLOW_SPEC [RFC2205] o SENDER_TSPEC and FLOW_SPEC [RFC2205]
o SESSION_ATTRIBUTE [RFC3209] o SESSION_ATTRIBUTE [RFC3209]
o EXPLICIT_ROUTE Object (ERO) [RFC3209] o EXPLICIT_ROUTE Object (ERO) [RFC3209]
skipping to change at page 17, line 8 skipping to change at page 17, line 8
5.2. PCEP Objects 5.2. PCEP Objects
PCEP objects are encoded in the "MPLS-TE Policy State Objects" field PCEP objects are encoded in the "MPLS-TE Policy State Objects" field
of the MPLS-TE Policy State TLV and consists of PCEP objects defined of the MPLS-TE Policy State TLV and consists of PCEP objects defined
in [RFC5440]. Rather than replicating all MPLS TE LSP related in [RFC5440]. Rather than replicating all MPLS TE LSP related
objects in this document, the semantics and encodings of the MPLS TE objects in this document, the semantics and encodings of the MPLS TE
LSP objects are re-used. These MPLS TE LSP objects are carried in LSP objects are re-used. These MPLS TE LSP objects are carried in
the MPLS-TE Policy State TLV. the MPLS-TE Policy State TLV.
When carrying PCEP objects, the "Path-Origin" field is set to "PCEP". When carrying PCEP objects, the "Object-Origin" field is set to
"PCEP".
The following PCEP Objects are defined: The following PCEP Objects are defined:
o METRIC Object [RFC5440] o METRIC Object [RFC5440]
o BANDWIDTH Object [RFC5440] o BANDWIDTH Object [RFC5440]
For the MPLS TE LSP Objects listed above, the corresponding sub- For the MPLS TE LSP Objects listed above, the corresponding sub-
objects are also applicable to this mechanism. Note that this list objects are also applicable to this mechanism. Note that this list
is not exhaustive, other MPLS TE LSP objects which reflect specific is not exhaustive, other MPLS TE LSP objects which reflect specific
skipping to change at page 17, line 42 skipping to change at page 17, line 43
This section defines the various TLVs which enable the headend to This section defines the various TLVs which enable the headend to
report the state of an SR Policy, its CP(s), SID-List(s) and their report the state of an SR Policy, its CP(s), SID-List(s) and their
status. These TLVs are carried in the optional non-transitive BGP status. These TLVs are carried in the optional non-transitive BGP
Attribute "LINK_STATE Attribute" defined in [RFC7752] and enable the Attribute "LINK_STATE Attribute" defined in [RFC7752] and enable the
same consistent form of reporting for SR Policy state irrespective of same consistent form of reporting for SR Policy state irrespective of
the Protocol-Origin used to provision the policy. Detailed procedure the Protocol-Origin used to provision the policy. Detailed procedure
is described in Section 7 . is described in Section 7 .
6.1. SR Binding SID 6.1. SR Binding SID
The SR Binding SID (BSID) TLV provides the BSID and its attributes The SR Binding SID (BSID) is an optional TLV that provides the BSID
for the SR Policy CP. The TLV MAY also optionally contain the and its attributes for the SR Policy CP. The TLV MAY also optionally
Provisioned BSID value for reporting when explicitly provisioned. contain the Provisioned BSID value for reporting when explicitly
provisioned.
The TLV has the following format: The 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSID Flags | RESERVED | | BSID Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 18, line 38 skipping to change at page 18, line 38
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|B|U|S|L|F| | |D|B|U|S|L|F| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
* D-Flag : Indicates the dataplane for the BSIDs and if they are * D-Flag : Indicates the dataplane for the BSIDs and if they are
16 octet SRv6 SID when SET and are 4 octet SR/MPLS label value 16 octet SRv6 SID when set and are 4 octet SR/MPLS label value
when CLEAR. when clear.
* B-Flag : Indicates the allocation of the value in the BSID * B-Flag : Indicates the allocation of the value in the BSID
field when SET and indicates that BSID is not allocated when field when set and indicates that BSID is not allocated when
CLEAR. clear.
* U-Flag : Indicates the provisioned BSID value is unavailable * U-Flag : Indicates the provisioned BSID value is unavailable
when SET. when set.
* S-Flag : Indicates the BSID value in use is specified or * S-Flag : Indicates the BSID value in use is specified or
provisioned value when SET and dynamically allocated value when provisioned value when set and dynamically allocated value when
CLEAR. clear.
* L-Flag : Indicates the BSID value is from the Segment Routing * L-Flag : Indicates the BSID value is from the Segment Routing
Local Block (SRLB) of the headend node when SET and is from the Local Block (SRLB) of the headend node when set and is from the
local label pool when CLEAR local label pool when clear
* F-Flag : Indicates the BSID value is one allocated from dynamic * F-Flag : Indicates the BSID value is one allocated from dynamic
range due to fallback (e.g. when specified BSID is unavailable) range due to fallback (e.g. when specified BSID is unavailable)
when SET. when set.
o RESERVED: 2 octets. SHOULD be set to 0 by originator and MUST be o RESERVED: 2 octets. SHOULD be set to 0 by originator and MUST be
ignored by receiver. ignored by receiver.
o Binding SID: It indicates the operational or allocated BSID value o Binding SID: It indicates the operational or allocated BSID value
for the CP based on the status flags. for the CP based on the status flags.
o Provisioned BSID: Optional field used to report the explicitly o Provisioned BSID: Optional field used to report the explicitly
provisioned BSID value as indicated by the S-Flag being SET. provisioned BSID value as indicated by the S-Flag being clear.
The BSID fields above are 4 octet carrying the MPLS Label or 16 The BSID fields above are 4 octet carrying the MPLS Label or 16
octets carrying the SRv6 SID based on the BSID D-flag. When carrying octets carrying the SRv6 SID based on the BSID D-flag. When carrying
the MPLS Label, as shown in the figure below, the TC, S and TTL the MPLS Label, as shown in the figure below, the TC, S and TTL
(total of 12 bits) are RESERVED and SHOULD be set to 0 by originator (total of 12 bits) are RESERVED and SHOULD be set to 0 by originator
and MUST be ignored by the receiver. and MUST be ignored by the receiver.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 20, line 9 skipping to change at page 20, line 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference (4 octets) | | Preference (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
o Type: TBD (see IANA Considerations Section 9.3) o Type: TBD (see IANA Considerations Section 9.3)
o Length: 12 octets o Length: 12 octets
o Priority : 1 octet value which indicates the priority of the CP o Priority : 1 octet value which indicates the priority of the CP.
Refer Section 2.12 of [I-D.ietf-spring-segment-routing-policy].
o RESERVED: 1 octet. SHOULD be set to 0 by originator and MUST be o RESERVED: 1 octet. SHOULD be set to 0 by originator and MUST be
ignored by receiver. ignored by receiver.
o Flags: 2 octet field that indicates attribute and status of the o Flags: 2 octet field that indicates attribute and status of the
CP. The following bit positions are defined and the semantics are CP. The following bit positions are defined and the semantics are
described in detail in [I-D.ietf-spring-segment-routing-policy]. described in detail in [I-D.ietf-spring-segment-routing-policy].
Other bits SHOULD be cleared by originator and MUST be ignored by Other bits SHOULD be cleared by originator and MUST be ignored by
receiver. receiver.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|A|B|E|V|O|D|C|I|T| | |S|A|B|E|V|O|D|C|I|T| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
* S-Flag : Indicates the CP is in administrative shut state when * S-Flag : Indicates the CP is in administrative shut state when
SET set
* A-Flag : Indicates the CP is the active path (i.e. one * A-Flag : Indicates the CP is the active path (i.e. one
provisioned in the forwarding plane) for the SR Policy when SET provisioned in the forwarding plane) for the SR Policy when set
* B-Flag : Indicates the CP is the backup path (i.e. one * B-Flag : Indicates the CP is the backup path (i.e. one
identified for path protection of the active path) for the SR identified for path protection of the active path) for the SR
Policy when SET Policy when set
* E-Flag : Indicates that the CP has been evaluated for validity * E-Flag : Indicates that the CP has been evaluated for validity
(e.g. headend may evaluate CPs based on their preferences) when (e.g. headend may evaluate CPs based on their preferences) when
SET set
* V-Flag : Indicates the CP has at least one valid SID-List when * V-Flag : Indicates the CP has at least one valid SID-List when
SET set
* O-Flag : Indicates the CP was instantiated by the headend due * O-Flag : Indicates the CP was instantiated by the headend due
to an on-demand-nexthop trigger based on local template when to an on-demand-nexthop trigger based on local template when
SET set. Refer Section 8.5 of
[I-D.ietf-spring-segment-routing-policy].
* D-Flag : Indicates the CP was delegated for computation to a * D-Flag : Indicates the CP was delegated for computation to a
PCE/controller when SET PCE/controller when set
* C-Flag : Indicates the CP was provisioned by a PCE/controller * C-Flag : Indicates the CP was provisioned by a PCE/controller
when SET when set
* I-Flag : Indicates the CP will perform the "drop upon invalid" * I-Flag : Indicates the CP will perform the "drop upon invalid"
behavior when no other active path is available for this SR behavior when no other active path is available for this SR
Policy and this path is the one with best preference amongst Policy and this path is the one with best preference amongst
the available CPs. the available CPs. Refer Section 8.2 of
[I-D.ietf-spring-segment-routing-policy].
* T-Flag : Indicates the CP has been marked as eligible for use * T-Flag : Indicates the CP has been marked as eligible for use
as Transit Policy on the headend when SET as Transit Policy on the headend when set. Refer Section 8.3
of [I-D.ietf-spring-segment-routing-policy].
o Preference : 4 octet value which indicates the preference of the o Preference : 4 octet value which indicates the preference of the
CP CP. Refer Section 2.7 of
[I-D.ietf-spring-segment-routing-policy].
6.3. SR Candidate Path Name 6.3. SR Candidate Path Name
The SR Candidate Path Name TLV is an optional TLV that is used to The SR Candidate Path Name TLV is an optional TLV that is used to
carry the symbolic name associated with the candidate path. The TLV carry the symbolic name associated with the candidate path. The TLV
has the following format: 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 21, line 45 skipping to change at page 21, line 48
o Type: TBD (see IANA Considerations Section 9.3) o Type: TBD (see IANA Considerations Section 9.3)
o Length: variable o Length: variable
o CP Name : Symbolic name for the CP. It is a string of printable o CP Name : Symbolic name for the CP. It is a string of printable
ASCII characters without a NULL terminator. ASCII characters without a NULL terminator.
6.4. SR Candidate Path Constraints 6.4. SR Candidate Path Constraints
The SR Candidate Path Constraints TLV is an optional TLV that is used The SR Candidate Path Constraints TLV is an optional TLV that is used
to report the contraints associated with the candidate path. The to report the constraints associated with the candidate path. The
constraints are generally applied to a dynamic candidate path which constraints are generally applied to a dynamic candidate path which
is computed by the headend. The constraints may also be applied to is computed by the headend. The constraints may also be applied to
an explicit path where the headend is expected to validate that the an explicit path where the headend is expected to validate that the
path expresses satisfies the specified constraints and the path is to path expresses satisfies the specified constraints and the path is to
be invalidated by the headend when the constraints are no longer met be invalidated by the headend when the constraints are no longer met
(e.g. due to topology changes). (e.g. due to topology changes).
The TLV has the following format: The 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Algorithm | RESERVED | | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTID | Algorithm | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs (variable) // | sub-TLVs (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
o Type: TBD (see IANA Considerations Section 9.3) o Type: TBD (see IANA Considerations Section 9.3)
o Length: variable o Length: variable
o Flags: 2 octet field that indicates the constraints that are being o Flags: 2 octet field that indicates the constraints that are being
applied to the CP. The following bit positions are defined and applied to the CP. The following bit positions are defined and
the other bits SHOULD be cleared by originator and MUST be ignored the other bits SHOULD be cleared by originator and MUST be ignored
by receiver. by receiver.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|P|U|A| | |D|P|U|A|T| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
* A-Flag : Indicates that the CP needs to use SRv6 dataplane when * D-Flag : Indicates that the CP needs to use SRv6 dataplane when
SET and SR/MPLS dataplane when CLEAR set and SR/MPLS dataplane when clear
* P-Flag : Indicates that the CP needs to use only protected SIDs * P-Flag : Indicates that the CP needs to use only protected SIDs
when SET when set
* U-Flag : Indicates that the CP needs to use only unprotected * U-Flag : Indicates that the CP needs to use only unprotected
SIDs when SET SIDs when set
* A-Flag : Indicates that the CP needs to use the SIDs belonging * A-Flag : Indicates that the CP needs to use the SIDs belonging
to the specified SR Algorithm only when SET to the specified SR Algorithm only when set
* T-Flag: Indicates that the CP needs to use the SIDs belonging
to the specified topology only when set
o RESERVED: 2 octet. SHOULD be set to 0 by originator and MUST be
ignored by receiver.
o MTID : Indicates the multi-topology identifier of the IGP topology
that is preferred to be used when the path is setup. When the
T-flag is set then the path is strictly useing the specified
topology SIDs only.
o Algorithm : Indicates the algorithm that is preferred to be used o Algorithm : Indicates the algorithm that is preferred to be used
when the path is setup. When the A-flag is SET then the path is when the path is setup. When the A-flag is set then the path is
strictly using the specified algorithm SIDs only. strictly using the specified algorithm SIDs only.
o RESERVED: 1 octet. SHOULD be set to 0 by originator and MUST be o RESERVED: 1 octet. SHOULD be set to 0 by originator and MUST be
ignored by receiver. ignored by receiver.
o sub-TLVs: optional sub-TLVs MAY be included in this TLV to o sub-TLVs: optional sub-TLVs MAY be included in this TLV to
describe other constraints. describe other constraints.
The following constraint sub-TLVs are defined for the SR CP The following constraint sub-TLVs are defined for the SR CP
Constraints TLV. Constraints TLV.
skipping to change at page 27, line 28 skipping to change at page 28, line 10
6.5. SR Segment List 6.5. SR Segment List
The SR Segment List TLV is used to report the SID-List(s) of a The SR Segment List TLV is used to report the SID-List(s) of a
candidate path. The TLV has following format: candidate path. The 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Algorithm | RESERVED | | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MTID | Algorithm | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Weight (4 octets) | | Weight (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-TLVs (variable) // | sub-TLVs (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
o Type: TBD (see IANA Considerations Section 9.3) o Type: TBD (see IANA Considerations Section 9.3)
o Length: variable o Length: variable
o Flags: 1 octet field that indicates attribute and status of the o Flags: 2 octet field that indicates attribute and status of the
SID-List.The following bit positions are defined and the semantics SID-List.The following bit positions are defined and the semantics
are described in detail in are described in detail in
[I-D.ietf-spring-segment-routing-policy]. Other bits SHOULD be [I-D.ietf-spring-segment-routing-policy]. Other bits SHOULD be
cleared by originator and MUST be ignored by receiver. cleared by originator and MUST be ignored by receiver.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|D|E|C|V|R|C|A| | |D|E|C|V|R|F|A|T|M| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
* D-Flag : Indicates the SID-List is comprised of SRv6 SIDs when * D-Flag : Indicates the SID-List is comprised of SRv6 SIDs when
SET and indicates it is comprised of SR/MPLS labels when CLEAR. set and indicates it is comprised of SR/MPLS labels when clear.
* E-Flag : Indicates that SID-List is an explicit path when SET * E-Flag : Indicates that SID-List is an explicit path when set
and indicates dynamic path when CLEAR. and indicates dynamic path when clear.
* C-Flag : Indicates that SID-List has been computed for a * C-Flag : Indicates that SID-List has been computed for a
dynamic path when SET. It is always reported as SET for dynamic path when set. It is always reported as set for
explicit paths. explicit paths.
* V-Flag : Indicates the SID-List has passed verification or its * V-Flag : Indicates the SID-List has passed verification or its
verification was not required when SET and failed verification verification was not required when set and failed verification
when CLEAR. when clear.
* R-Flag : Indicates that the first Segment has been resolved * R-Flag : Indicates that the first Segment has been resolved
when SET and failed resolution when CLEAR. when set and failed resolution when clear.
* C-Flag : Indicates that the computation for the dynamic path * F-Flag : Indicates that the computation for the dynamic path
failed when SET and succeeded (or not required in case of failed when set and succeeded (or not required in case of
explicit path) when CLEAR explicit path) when clear
* A-Flag : Indicates that all the SIDs in the SID-List belong to * A-Flag : Indicates that all the SIDs in the SID-List belong to
the specified algorithm when SET. the specified algorithm when set.
o RESERVED: 1 octet. SHOULD be set to 0 by originator and MUST be * T-Flag : Indicates that all the SIDs in the SID-List belong to
the specified topology (identified by the multi-topology ID)
when set.
* M-Flag : Indicates that the SID-list has been removed from the
forwarding plane due to fault detection by a monitoring
mechanism (e.g. BFD) when set and indicates no fault detected
or monitoring is not being done when clear.
o RESERVED: 2 octet. SHOULD be set to 0 by originator and MUST be
ignored by receiver. ignored by receiver.
o MTID : 2 octet that indicates the multi-topology identifier of the
IGP topology to be used when the T-flag is set.
o Algorithm: 1 octet that indicates the algorithm of the SIDs used o Algorithm: 1 octet that indicates the algorithm of the SIDs used
in the SID-List when the A-flag is SET. in the SID-List when the A-flag is set.
o RESERVED: 1 octet. SHOULD be set to 0 by originator and MUST be
ignored by receiver.
o Weight: 4 octet field that indicates the weight associated with o Weight: 4 octet field that indicates the weight associated with
the SID-List for weighted load-balancing the SID-List for weighted load-balancing. Refer Section 2.2 and
2.11 of [I-D.ietf-spring-segment-routing-policy].
o Sub-TLVs : variable and contains the ordered set of Segments and o Sub-TLVs : variable and contains the ordered set of Segments and
any other optional attributes associated with the specific SID- any other optional attributes associated with the specific SID-
List. List.
The SR Segment sub-TLV (defined in Section 6.6) is the only currently The SR Segment sub-TLV (defined in Section 6.6) MUST be included as
defined sub-TLV for use with the SR Segment List TLV and it MUST be an ordered set of sub-TLVs within the SR Segment List TLV when the
included as an ordered set of sub-TLVs within the SR Segment List TLV SID-List is not empty. A SID-List may be empty in certain cases
when the SID-List is not empty. A SID-List may be empty in certain (e.g. for a dynamic path) where the headend has not yet performed the
cases (e.g. for a dynamic path) where the headend has not yet computation and hence not derived the segments required for the path;
performed the computation and hence not derived the segments required in such cases, the SR Segment List TLV SHOULD NOT include any SR
for the path; in such cases, the SR Segment List TLV SHOULD NOT Segment sub-TLVs.
include any SR Segment sub-TLVs.
6.6. SR Segment 6.6. SR Segment
The SR Segment sub-TLV describes a single segment in a SID-List. One The SR Segment sub-TLV describes a single segment in a SID-List. One
or more instances of this sub-TLV in an ordered manner constitute a or more instances of this sub-TLV in an ordered manner constitute a
SID-List for a SR Policy candidate path. It is a sub-TLV of the SR SID-List for a SR Policy candidate path. It is a sub-TLV of the SR
Segment List TLV and has following format: Segment List TLV and 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Segment Type | RESERVED | Flags | | Segment Type | RESERVED | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID (4 or 16 octets) // | SID (4 or 16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SID Descriptor (variable) // // Segment Descriptor (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Sub-TLVs (variable) // // Sub-TLVs (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
o Type: TBD (see IANA Considerations Section 9.3) o Type: TBD (see IANA Considerations Section 9.3)
o Length: variable o Length: variable
skipping to change at page 30, line 14 skipping to change at page 31, line 6
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|E|V|R|A| | |S|E|V|R|A| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
* S-Flag : Indicates the presence of SID value in the SID field * S-Flag : Indicates the presence of SID value in the SID field
when SET and that no value is indicated when CLEAR. when set and that no value is indicated when clear.
* E-Flag : Indicates the SID value is explicitly provisioned * E-Flag : Indicates the SID value is explicitly provisioned
value (locally on headend or via controller/PCE) when SET and value (locally on headend or via controller/PCE) when set and
is a dynamically resolved value by headend when CLEAR is a dynamically resolved value by headend when clear
* V-Flag : Indicates the SID has passed verification or did not * V-Flag : Indicates the SID has passed verification or did not
require verification when SET and failed verification when require verification when set and failed verification when
CLEAR. clear.
* R-Flag : Indicates the SID has been resolved or did not require * R-Flag : Indicates the SID has been resolved or did not require
resolution (e.g. because it is not the first SID) when SET and resolution (e.g. because it is not the first SID) when set and
failed resolution when CLEAR. failed resolution when clear.
* A-Flag : Indicates that the Algorithm indicated in the Segment * A-Flag : Indicates that the Algorithm indicated in the Segment
descriptor is valid when SET. When CLEAR, it indicates that descriptor is valid when set. When clear, it indicates that
the headend is unable to determine the algorithm of the SID. the headend is unable to determine the algorithm of the SID.
o SID : 4 octet carrying the MPLS Label or 16 octets carrying the o SID : 4 octet carrying the MPLS Label or 16 octets carrying the
SRv6 SID based on the F-flag. When carrying the MPLS Label, as SRv6 SID based on the Segment Type. When carrying the MPLS Label,
shown in the figure below, the TC, S and TTL (total of 12 bits) as shown in the figure below, the TC, S and TTL (total of 12 bits)
are RESERVED and SHOULD be set to 0 by originator and MUST be are RESERVED and SHOULD be set to 0 by originator and MUST be
ignored by the receiver. ignored by the receiver.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label | TC |S| TTL | | Label | TC |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
o SID Descriptor : variable size SID descriptor based on the type of o Segment Descriptor : variable size Segment descriptor based on the
segment (refer Section 6.6.1 for details) type of segment (refer Section 6.6.1 for details)
o Sub-Sub-TLVs : variable and contains any other optional attributes o Sub-Sub-TLVs : variable and contains any other optional attributes
associated with the specific SID-List. associated with the specific SID-List.
Currently no Sub-Sub-TLV of the SR Segment sub-TLV is defined. Currently no Sub-Sub-TLV of the SR Segment sub-TLV is defined.
6.6.1. Segment Descriptors 6.6.1. Segment Descriptors
[I-D.ietf-spring-segment-routing-policy] section 4 defines multiple [I-D.ietf-spring-segment-routing-policy] section 4 defines multiple
types of segments and their description. This section defines the types of segments and their description. This section defines the
skipping to change at page 32, line 6 skipping to change at page 32, line 45
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
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Algorithm | | Algorithm |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Where: Where:
o Algorithm: 1 octet value that indicates the algorithm used for o Algorithm: 1 octet value that indicates the algorithm used for
picking the SID. This is valid only when the A-flag has been SET picking the SID. This is valid only when the A-flag has been set
in the Segment TLV. in the Segment TLV.
6.6.1.2. Type 2: SRv6 SID 6.6.1.2. Type 2: SRv6 SID
The Segment is SRv6 type and is specified simply as the SRv6 SID The Segment is SRv6 type and is specified simply as the SRv6 SID
address. The format of its Segment Descriptor is as follows: address. The format of its Segment Descriptor 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
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Algorithm | | Algorithm |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Where: Where:
o Algorithm: 1 octet value that indicates the algorithm used for o Algorithm: 1 octet value that indicates the algorithm used for
picking the SID. This is valid only when the A-flag has been SET picking the SID. This is valid only when the A-flag has been set
in the Segment TLV. in the Segment TLV.
6.6.1.3. Type 3: SR-MPLS Prefix SID for IPv4 6.6.1.3. Type 3: SR-MPLS Prefix SID for IPv4
The Segment is SR-MPLS Prefix SID type and is specified as an IPv4 The Segment is SR-MPLS Prefix SID type and is specified as an IPv4
node address. The format of its Segment Descriptor is as follows: node address. The format of its Segment Descriptor 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
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
skipping to change at page 38, line 29 skipping to change at page 39, line 29
MUST be ignored by receiver. MUST be ignored by receiver.
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|M|A|B|V| | |M|A|B|V| |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
where: where:
* M-Flag : Indicates that the metric margin allowed for path * M-Flag : Indicates that the metric margin allowed for path
computation is specified when SET computation is specified when set
* A-Flag : Indicates that the metric margin is specified as an * A-Flag : Indicates that the metric margin is specified as an
absolute value when SET and is expressed as a percentage of the absolute value when set and is expressed as a percentage of the
minimum metric when CLEAR. minimum metric when clear.
* B-Flag : Indicates that the metric bound allowed for the path * B-Flag : Indicates that the metric bound allowed for the path
is specified when SET. is specified when set.
* V-Flag : Indicates that the metric value computed is being * V-Flag : Indicates that the metric value computed is being
reported when SET. reported when set.
o RESERVED: 2 octets. SHOULD be set to 0 by originator and MUST be o RESERVED: 2 octets. SHOULD be set to 0 by originator and MUST be
ignored by receiver. ignored by receiver.
o Metric Margin : 4 octets which indicate the metric margin value o Metric Margin : 4 octets which indicate the metric margin value
when M-flag is SET. The metric margin is specified as either an when M-flag is set. The metric margin is specified as either an
absolute value or as a percentage of the minimum computed path absolute value or as a percentage of the minimum computed path
metric based on the A-flag. The metric margin loosens the metric based on the A-flag. The metric margin loosens the
criteria for minimum metric path calculation up to the specified criteria for minimum metric path calculation up to the specified
metric to accomodate for other factors such as bandwidth metric to accomodate for other factors such as bandwidth
availability, minimal SID stack depth and maximizing of ECMP for availability, minimal SID stack depth and maximizing of ECMP for
the SR path computed. the SR path computed.
o Metric Bound : 4 octects which indicate the maximum metric value o Metric Bound : 4 octects which indicate the maximum metric value
that is allowed when B-flag is SET. If the computed path metric that is allowed when B-flag is set. If the computed path metric
crosses the specified bound value then the path is considered as crosses the specified bound value then the path is considered as
invalid. invalid.
o Metric Value : 4 octets which indicate the metric value of the o Metric Value : 4 octets which indicate the metric value of the
computed path when V-flag is SET. This value is available and computed path when V-flag is set. This value is available and
reported when the computation is successful and a valid path is reported when the computation is successful and a valid path is
available. available.
7. Procedures 7. Procedures
The BGP-LS advertisements for the TE Policy NLRI are originated by The BGP-LS advertisements for the TE Policy NLRI are originated by
the headend node for the TE Policies that are instantiated on its the headend node for the TE Policies that are instantiated on its
local node. local node.
For MPLS TE LSPs signaled via RSVP-TE, the NLRI descriptor TLVs as For MPLS TE LSPs signaled via RSVP-TE, the NLRI descriptor TLVs as
skipping to change at page 42, line 15 skipping to change at page 43, line 15
(suggested values, to be assigned by IANA): (suggested values, to be assigned by IANA):
+------------+---------------------------------------------------------+ +------------+---------------------------------------------------------+
| Code Point | Protocol Origin | | Code Point | Protocol Origin |
+------------+---------------------------------------------------------+ +------------+---------------------------------------------------------+
| 1 | PCEP | | 1 | PCEP |
| 2 | BGP SR Policy | | 2 | BGP SR Policy |
| 3 | Local (via CLI, Yang model through NETCONF, gRPC, etc.) | | 3 | Local (via CLI, Yang model through NETCONF, gRPC, etc.) |
+------------+---------------------------------------------------------+ +------------+---------------------------------------------------------+
9.5. BGP-LS TE State Path Origin 9.5. BGP-LS TE State Object Origin
This document requests IANA to maintain a new sub-registry under This document requests IANA to maintain a new sub-registry under
"Border Gateway Protocol - Link State (BGP-LS) Parameters". The new "Border Gateway Protocol - Link State (BGP-LS) Parameters". The new
registry is called "TE State Path Origin" and contains the codepoints registry is called "TE State Path Origin" and contains the codepoints
allocated to the "Path Origin" field defined in Section 5. The allocated to the "Object Origin" field defined in Section 5. The
registry contains the following codepoints (suggested values, to be registry contains the following codepoints (suggested values, to be
assigned by IANA): assigned by IANA):
+----------+------------------+ +----------+------------------+
| Code | Path | | Code | Object |
| Point | Origin | | Point | Origin |
+----------+------------------+ +----------+------------------+
| 1 | RSVP-TE | | 1 | RSVP-TE |
| 2 | PCEP | | 2 | PCEP |
| 3 | Local/Static | | 3 | Local/Static |
+----------+------------------+ +----------+------------------+
9.6. BGP-LS TE State Dataplane 9.6. BGP-LS TE State Address Family
This document requests IANA to maintain a new sub-registry under This document requests IANA to maintain a new sub-registry under
"Border Gateway Protocol - Link State (BGP-LS) Parameters". The new "Border Gateway Protocol - Link State (BGP-LS) Parameters". The new
registry is called "TE State Dataplane" and contains the codepoints registry is called "TE State Address Family" and contains the
allocated to the "dataplane" field defined in Section 5. The codepoints allocated to the "Address Family" field defined in
registry contains the following codepoints (suggested values, to be Section 5. The registry contains the following codepoints (suggested
assigned by IANA): values, to be assigned by IANA):
+----------+------------------+ +----------+------------------+
| Code | Dataplane | | Code | Address |
| Point | | | Point | Family |
+----------+------------------+ +----------+------------------+
| 1 | MPLS-IPv4 | | 1 | MPLS-IPv4 |
| 2 | MPLS-IPv6 | | 2 | MPLS-IPv6 |
+----------+------------------+ +----------+------------------+
9.7. BGP-LS SR Segment Descriptors 9.7. BGP-LS SR Segment Descriptors
This document requests IANA to maintain a new sub-registry under This document requests IANA to maintain a new sub-registry under
"Border Gateway Protocol - Link State (BGP-LS) Parameters". The new "Border Gateway Protocol - Link State (BGP-LS) Parameters". The new
registry is called "SR Segment Descriptor Types" and contains the registry is called "SR Segment Descriptor Types" and contains the
skipping to change at page 44, line 41 skipping to change at page 45, line 41
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-spring-segment-routing-policy] [I-D.ietf-spring-segment-routing-policy]
Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d.,
bogdanov@google.com, b., and P. Mattes, "Segment Routing bogdanov@google.com, b., and P. Mattes, "Segment Routing
Policy Architecture", draft-ietf-spring-segment-routing- Policy Architecture", draft-ietf-spring-segment-routing-
policy-01 (work in progress), June 2018. policy-02 (work in progress), October 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>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205, Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <https://www.rfc-editor.org/info/rfc2205>. September 1997, <https://www.rfc-editor.org/info/rfc2205>.
skipping to change at page 46, line 11 skipping to change at page 47, line 11
Element (PCE) Communication Protocol (PCEP)", RFC 5440, Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009, DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>. <https://www.rfc-editor.org/info/rfc5440>.
[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and
S. Ray, "North-Bound Distribution of Link-State and S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752, Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016, DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>. <https://www.rfc-editor.org/info/rfc7752>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
13.2. Informative References 13.2. Informative References
[RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J.
McManus, "Requirements for Traffic Engineering Over MPLS", McManus, "Requirements for Traffic Engineering Over MPLS",
RFC 2702, DOI 10.17487/RFC2702, September 1999, RFC 2702, DOI 10.17487/RFC2702, September 1999,
<https://www.rfc-editor.org/info/rfc2702>. <https://www.rfc-editor.org/info/rfc2702>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003, DOI 10.17487/RFC3630, September 2003,
skipping to change at page 47, line 13 skipping to change at page 48, line 13
<https://www.rfc-editor.org/info/rfc7471>. <https://www.rfc-editor.org/info/rfc7471>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP) Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231, Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017, DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>. <https://www.rfc-editor.org/info/rfc8231>.
Authors' Addresses Authors' Addresses
Stefano Previdi (editor) Stefano Previdi
Email: stefano@previdi.net Email: stefano@previdi.net
Ketan Talaulikar Ketan Talaulikar (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
India
Email: ketant@cisco.com Email: ketant@cisco.com
Jie Dong (editor) Jie Dong (editor)
Huawei Technologies Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd. Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095 Beijing 100095
China China
Email: jie.dong@huawei.com Email: jie.dong@huawei.com
skipping to change at page 47, line 44 skipping to change at page 48, line 45
China China
Email: mach.chen@huawei.com Email: mach.chen@huawei.com
Hannes Gredler Hannes Gredler
RtBrick Inc. RtBrick Inc.
Email: hannes@rtbrick.com Email: hannes@rtbrick.com
Jeff Tantsura Jeff Tantsura
Nuage Networks Apstra
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
 End of changes. 96 change blocks. 
153 lines changed or deleted 197 lines changed or added

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