--- 1/draft-ietf-idr-te-lsp-distribution-09.txt 2019-02-26 20:13:13.441440064 -0800 +++ 2/draft-ietf-idr-te-lsp-distribution-10.txt 2019-02-26 20:13:13.533442293 -0800 @@ -1,61 +1,62 @@ -Network Working Group S. Previdi, Ed. +Network Working Group S. Previdi Internet-Draft -Intended status: Standards Track K. Talaulikar -Expires: December 31, 2018 Cisco Systems, Inc. +Intended status: Standards Track K. Talaulikar, Ed. +Expires: August 30, 2019 Cisco Systems, Inc. J. Dong, Ed. M. Chen Huawei Technologies H. Gredler RtBrick Inc. J. Tantsura - Nuage Networks - June 29, 2018 + Apstra + February 26, 2019 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 This document describes a mechanism to collect the Traffic Engineering and Policy information that is locally available in a - node and advertise it into BGP-LS updates. Such information can be - used by external components for path computation, re-optimization, - service placement, network visualization, etc. + node and advertise it into BGP Link State (BGP-LS) updates. Such + information can be used by external components for path computation, + re-optimization, service placement, network visualization, etc. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [RFC2119]. + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - - This Internet-Draft will expire on December 31, 2018. + This Internet-Draft will expire on August 30, 2019. 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. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -78,55 +79,55 @@ 5. MPLS-TE Policy State TLV . . . . . . . . . . . . . . . . . . 14 5.1. RSVP Objects . . . . . . . . . . . . . . . . . . . . . . 15 5.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 16 6. SR Policy State TLVs . . . . . . . . . . . . . . . . . . . . 17 6.1. SR Binding SID . . . . . . . . . . . . . . . . . . . . . 17 6.2. SR Candidate Path State . . . . . . . . . . . . . . . . . 19 6.3. SR Candidate Path Name . . . . . . . . . . . . . . . . . 21 6.4. SR Candidate Path Constraints . . . . . . . . . . . . . . 21 6.4.1. SR Affinity Constraint . . . . . . . . . . . . . . . 23 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.5. SR Segment List . . . . . . . . . . . . . . . . . . . . . 27 - 6.6. SR Segment . . . . . . . . . . . . . . . . . . . . . . . 29 + 6.6. SR Segment . . . . . . . . . . . . . . . . . . . . . . . 30 6.6.1. Segment Descriptors . . . . . . . . . . . . . . . . . 31 - 6.7. SR Segment List Metric . . . . . . . . . . . . . . . . . 37 - 7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 39 - 8. Manageability Considerations . . . . . . . . . . . . . . . . 40 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 - 9.1. BGP-LS NLRI-Types . . . . . . . . . . . . . . . . . . . . 40 - 9.2. BGP-LS Protocol-IDs . . . . . . . . . . . . . . . . . . . 40 - 9.3. BGP-LS TLVs . . . . . . . . . . . . . . . . . . . . . . . 41 - 9.4. BGP-LS SR Policy Protocol Origin . . . . . . . . . . . . 41 - 9.5. BGP-LS TE State Path Origin . . . . . . . . . . . . . . . 42 - 9.6. BGP-LS TE State Dataplane . . . . . . . . . . . . . . . . 42 - 9.7. BGP-LS SR Segment Descriptors . . . . . . . . . . . . . . 43 - 9.8. BGP-LS Metric Type . . . . . . . . . . . . . . . . . . . 43 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 44 - 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 - 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 44 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 - 13.1. Normative References . . . . . . . . . . . . . . . . . . 44 - 13.2. Informative References . . . . . . . . . . . . . . . . . 46 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 + 6.7. SR Segment List Metric . . . . . . . . . . . . . . . . . 38 + 7. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 40 + 8. Manageability Considerations . . . . . . . . . . . . . . . . 41 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 + 9.1. BGP-LS NLRI-Types . . . . . . . . . . . . . . . . . . . . 41 + 9.2. BGP-LS Protocol-IDs . . . . . . . . . . . . . . . . . . . 41 + 9.3. BGP-LS TLVs . . . . . . . . . . . . . . . . . . . . . . . 42 + 9.4. BGP-LS SR Policy Protocol Origin . . . . . . . . . . . . 42 + 9.5. BGP-LS TE State Object Origin . . . . . . . . . . . . . . 43 + 9.6. BGP-LS TE State Address Family . . . . . . . . . . . . . 43 + 9.7. BGP-LS SR Segment Descriptors . . . . . . . . . . . . . . 44 + 9.8. BGP-LS Metric Type . . . . . . . . . . . . . . . . . . . 44 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 45 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 + 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 45 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 45 + 13.2. Informative References . . . . . . . . . . . . . . . . . 47 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 1. Introduction - In many network environments, traffic engineering policies are + In many network environments, traffic engineering (TE) policies are instantiated into various forms: o MPLS Traffic Engineering Label Switched Paths (TE-LSPs). 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] o Local MPLS cross-connect configuration 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 information related to the various instantiation of polices: MPLS TE LSPs, IP tunnels (IPv4 or IPv6), SR Policies, etc. TE Polices are generally instantiated at the head-end and are based @@ -266,22 +267,22 @@ | Protocol-ID | NLRI information source protocol | +-------------+----------------------------------+ | TBD | RSVP-TE | | TBD | Segment Routing | +-------------+----------------------------------+ o "Identifier" is an 8 octet value as defined in [RFC7752]. o "Headend" consists of a Node Descriptor defined in [RFC7752]. - o "TE Policy Descriptors" consists of (values TBD see IANA - Considerations Section 9.3): + o "TE Policy Descriptors" consists of one or more of the TLVs listed + as below: (values TBD see IANA Considerations Section 9.3): +-----------+----------------------------------+ | Codepoint | Descriptor TLVs | +-----------+----------------------------------+ | TBD | Tunnel ID | | TBD | LSP ID | | TBD | IPv4/6 Tunnel Head-end address | | TBD | IPv4/6 Tunnel Tail-end address | | TBD | SR Policy Candidate Path | | TBD | Local MPLS Cross Connect | @@ -436,24 +437,24 @@ receiver. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |E|O| | +-+-+-+-+-+-+-+-+ where: * 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 - 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 MUST be ignored by receiver. o Endpoint : 4 or 16 octets (as indicated by the flags) containing the address of the endpoint 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 @@ -611,72 +612,73 @@ where: * 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 describes an IPv6 FEC. o Mask Length: 1 octet of prefix length. 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 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 optional non-transitive BGP Attribute "LINK_STATE Attribute" defined in [RFC7752]. These MPLS-TE Policy characteristics include the - characteristics and attributes of the policy, it's dataplane, - explicit path, Quality of Service (QoS) parameters, route - information, the protection mechanisms, etc. + characteristics and attributes of the policy, its dataplane, explicit + path, Quality of Service (QoS) parameters, route information, the + protection mechanisms, etc. The MPLS-TE Policy State TLV has the 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Path-origin | Dataplane | RESERVED | + | Object-origin | Address Family| RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // MPLS-TE Policy State Objects (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: MPLS-TE Policy State TLV o Type: TBD (see IANA Considerations Section 9.3) o Length: the total length of the MPLS-TE Policy State TLV not including Type and Length fields. - o Path-origin: identifies the component (or protocol) from which the - contained object originated. This allows for objects defined in - different components to be collected while avoiding the possible - codepoint collisions among these components. Following path- - origin codepoints are defined in this document. + o Object-origin: identifies the component (or protocol) from which + the contained object originated. This allows for objects defined + in different components to be collected while avoiding the + possible codepoint collisions among these components. Following + object-origin codepoints are defined in this document. +----------+------------------+ - | Code | Path | + | Code | Object | | Point | Origin | +----------+------------------+ | 1 | RSVP-TE | | 2 | PCEP | | 3 | Local/Static | +----------+------------------+ - o Dataplane: describes to which dataplane the policy is applied to. - The following dataplane values are defined in this document: + o Address Family: describes the address family used to setup the + MPLS-TE policy. The following address family values are defined + in this document: +----------+------------------+ | Code | Dataplane | | Point | | +----------+------------------+ | 1 | MPLS-IPv4 | | 2 | MPLS-IPv6 | +----------+------------------+ o RESERVED: 16-bit field. SHOULD be set to 0 on transmission and @@ -693,21 +695,21 @@ 5.1. RSVP 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 objects defined in RSVP-TE [RFC3209] [RFC3473]. Rather than replicating all MPLS TE LSP related 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 the MPLS-TE Policy State 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". The following RSVP-TE Objects are defined: o SENDER_TSPEC and FLOW_SPEC [RFC2205] o SESSION_ATTRIBUTE [RFC3209] o EXPLICIT_ROUTE Object (ERO) [RFC3209] @@ -745,21 +747,22 @@ 5.2. PCEP Objects 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 in [RFC5440]. Rather than replicating all MPLS TE LSP related 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 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: o METRIC Object [RFC5440] o BANDWIDTH Object [RFC5440] For the MPLS TE LSP Objects listed above, the corresponding sub- objects are also applicable to this mechanism. Note that this list is not exhaustive, other MPLS TE LSP objects which reflect specific @@ -779,23 +782,24 @@ 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 status. These TLVs are carried in the optional non-transitive BGP Attribute "LINK_STATE Attribute" defined in [RFC7752] and enable the same consistent form of reporting for SR Policy state irrespective of the Protocol-Origin used to provision the policy. Detailed procedure is described in Section 7 . 6.1. SR Binding SID - The SR Binding SID (BSID) TLV provides the BSID and its attributes - for the SR Policy CP. The TLV MAY also optionally contain the - Provisioned BSID value for reporting when explicitly provisioned. + The SR Binding SID (BSID) is an optional TLV that provides the BSID + and its attributes for the SR Policy CP. The TLV MAY also optionally + contain the Provisioned BSID value for reporting when explicitly + provisioned. The TLV has the 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BSID Flags | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -818,50 +822,50 @@ 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D|B|U|S|L|F| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: * 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 - when CLEAR. + 16 octet SRv6 SID when set and are 4 octet SR/MPLS label value + when clear. * B-Flag : Indicates the allocation of the value in the BSID - field when SET and indicates that BSID is not allocated when - CLEAR. + field when set and indicates that BSID is not allocated when + clear. * U-Flag : Indicates the provisioned BSID value is unavailable - when SET. + when set. * S-Flag : Indicates the BSID value in use is specified or - provisioned value when SET and dynamically allocated value when - CLEAR. + provisioned value when set and dynamically allocated value when + clear. * 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 label pool when CLEAR + Local Block (SRLB) of the headend node when set and is from the + local label pool when clear * F-Flag : Indicates the BSID value is one allocated from dynamic 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 ignored by receiver. o Binding SID: It indicates the operational or allocated BSID value for the CP based on the status flags. 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 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 (total of 12 bits) are RESERVED and SHOULD be set to 0 by originator and MUST be ignored by the receiver. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -883,76 +887,81 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preference (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: o Type: TBD (see IANA Considerations Section 9.3) 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 ignored by receiver. o Flags: 2 octet field that indicates attribute and status of the CP. The following bit positions are defined and the semantics are described in detail in [I-D.ietf-spring-segment-routing-policy]. Other bits SHOULD be cleared by originator and MUST be ignored by receiver. 0 1 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| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: * 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 - 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 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.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 - SET + set * O-Flag : Indicates the CP was instantiated by the headend due 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 - PCE/controller when SET + PCE/controller when set * 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" behavior when no other active path is available for this SR 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 - 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 - CP + CP. Refer Section 2.7 of + [I-D.ietf-spring-segment-routing-policy]. 6.3. SR Candidate Path Name 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 has the 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -966,73 +975,86 @@ o Type: TBD (see IANA Considerations Section 9.3) o Length: variable o CP Name : Symbolic name for the CP. It is a string of printable ASCII characters without a NULL terminator. 6.4. SR Candidate Path Constraints 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 is computed by the headend. The constraints may also be applied to an explicit path where the headend is expected to validate that the path expresses satisfies the specified constraints and the path is to be invalidated by the headend when the constraints are no longer met (e.g. due to topology changes). The TLV has the 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Flags | Algorithm | RESERVED | + | Flags | RESERVED | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MTID | Algorithm | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-TLVs (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: o Type: TBD (see IANA Considerations Section 9.3) o Length: variable o Flags: 2 octet field that indicates the constraints that are being applied to the CP. The following bit positions are defined and the other bits SHOULD be cleared by originator and MUST be ignored by receiver. 0 1 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: - * A-Flag : Indicates that the CP needs to use SRv6 dataplane when - SET and SR/MPLS dataplane when CLEAR + * D-Flag : Indicates that the CP needs to use SRv6 dataplane when + set and SR/MPLS dataplane when clear * 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 - SIDs when SET + SIDs when set * 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 - 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. o RESERVED: 1 octet. SHOULD be set to 0 by originator and MUST be ignored by receiver. o sub-TLVs: optional sub-TLVs MAY be included in this TLV to describe other constraints. The following constraint sub-TLVs are defined for the SR CP Constraints TLV. @@ -1232,110 +1255,127 @@ 6.5. SR Segment List The SR Segment List TLV is used to report the SID-List(s) of a candidate path. The 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Flags | Algorithm | RESERVED | + | Flags | RESERVED | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MTID | Algorithm | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Weight (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-TLVs (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: o Type: TBD (see IANA Considerations Section 9.3) 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 are described in detail in [I-D.ietf-spring-segment-routing-policy]. Other bits SHOULD be cleared by originator and MUST be ignored by receiver. 0 1 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: * 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 - and indicates dynamic path when CLEAR. + * E-Flag : Indicates that SID-List is an explicit path when set + and indicates dynamic path when clear. * 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. * V-Flag : Indicates the SID-List has passed verification or its - verification was not required when SET and failed verification - when CLEAR. + verification was not required when set and failed verification + when clear. * 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 - failed when SET and succeeded (or not required in case of - explicit path) when CLEAR + * F-Flag : Indicates that the computation for the dynamic path + failed when set and succeeded (or not required in case of + explicit path) when clear * 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. + 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 - 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 - 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 any other optional attributes associated with the specific SID- List. - The SR Segment sub-TLV (defined in Section 6.6) is the only currently - defined sub-TLV for use with the SR Segment List TLV and it MUST be - included as an ordered set of sub-TLVs within the SR Segment List TLV - when the SID-List is not empty. A SID-List may be empty in certain - cases (e.g. for a dynamic path) where the headend has not yet - performed the computation and hence not derived the segments required - for the path; in such cases, the SR Segment List TLV SHOULD NOT - include any SR Segment sub-TLVs. + The SR Segment sub-TLV (defined in Section 6.6) MUST be included as + an ordered set of sub-TLVs within the SR Segment List TLV when the + SID-List is not empty. A SID-List may be empty in certain cases + (e.g. for a dynamic path) where the headend has not yet performed the + computation and hence not derived the segments required for the path; + in such cases, the SR Segment List TLV SHOULD NOT include any SR + Segment sub-TLVs. 6.6. SR Segment 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 SID-List for a SR Policy candidate path. It is a sub-TLV of the SR Segment List TLV and 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Segment Type | RESERVED | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SID (4 or 16 octets) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - // SID Descriptor (variable) // + // Segment Descriptor (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Sub-TLVs (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: o Type: TBD (see IANA Considerations Section 9.3) o Length: variable @@ -1353,52 +1393,52 @@ 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|E|V|R|A| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: * 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 - value (locally on headend or via controller/PCE) when SET and - is a dynamically resolved value by headend when CLEAR + value (locally on headend or via controller/PCE) when set and + is a dynamically resolved value by headend when clear * V-Flag : Indicates the SID has passed verification or did not - require verification when SET and failed verification when - CLEAR. + require verification when set and failed verification when + clear. * 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 - failed resolution when CLEAR. + resolution (e.g. because it is not the first SID) when set and + failed resolution when clear. * 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. 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 - shown in the figure below, the TC, S and TTL (total of 12 bits) + SRv6 SID based on the Segment Type. When carrying 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 and MUST be ignored by the receiver. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Label | TC |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - o SID Descriptor : variable size SID descriptor based on the type of - segment (refer Section 6.6.1 for details) + o Segment Descriptor : variable size Segment descriptor based on the + type of segment (refer Section 6.6.1 for details) o Sub-Sub-TLVs : variable and contains any other optional attributes associated with the specific SID-List. Currently no Sub-Sub-TLV of the SR Segment sub-TLV is defined. 6.6.1. Segment Descriptors [I-D.ietf-spring-segment-routing-policy] section 4 defines multiple types of segments and their description. This section defines the @@ -1439,38 +1479,38 @@ 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 +-+-+-+-+-+-+-+-+ | Algorithm | +-+-+-+-+-+-+-+-+ Where: 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. 6.6.1.2. Type 2: 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: 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 +-+-+-+-+-+-+-+-+ | Algorithm | +-+-+-+-+-+-+-+-+ Where: 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. 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 node address. The format of its Segment Descriptor 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 +-+-+-+-+-+-+-+-+ @@ -1741,51 +1781,51 @@ MUST be ignored by receiver. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |M|A|B|V| | +-+-+-+-+-+-+-+-+ where: * 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 - absolute value when SET and is expressed as a percentage of the - minimum metric when CLEAR. + absolute value when set and is expressed as a percentage of the + minimum metric when clear. * 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 - reported when SET. + reported when set. o RESERVED: 2 octets. SHOULD be set to 0 by originator and MUST be ignored by receiver. 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 metric based on the A-flag. The metric margin loosens the criteria for minimum metric path calculation up to the specified metric to accomodate for other factors such as bandwidth availability, minimal SID stack depth and maximizing of ECMP for the SR path computed. 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 invalid. 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 available. 7. Procedures The BGP-LS advertisements for the TE Policy NLRI are originated by the headend node for the TE Policies that are instantiated on its local node. For MPLS TE LSPs signaled via RSVP-TE, the NLRI descriptor TLVs as @@ -1917,50 +1957,50 @@ (suggested values, to be assigned by IANA): +------------+---------------------------------------------------------+ | Code Point | Protocol Origin | +------------+---------------------------------------------------------+ | 1 | PCEP | | 2 | BGP SR Policy | | 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 "Border Gateway Protocol - Link State (BGP-LS) Parameters". The new 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 assigned by IANA): +----------+------------------+ - | Code | Path | + | Code | Object | | Point | Origin | +----------+------------------+ | 1 | RSVP-TE | | 2 | PCEP | | 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 "Border Gateway Protocol - Link State (BGP-LS) Parameters". The new - registry is called "TE State Dataplane" and contains the codepoints - allocated to the "dataplane" field defined in Section 5. The - registry contains the following codepoints (suggested values, to be - assigned by IANA): + registry is called "TE State Address Family" and contains the + codepoints allocated to the "Address Family" field defined in + Section 5. The registry contains the following codepoints (suggested + values, to be assigned by IANA): +----------+------------------+ - | Code | Dataplane | - | Point | | + | Code | Address | + | Point | Family | +----------+------------------+ | 1 | MPLS-IPv4 | | 2 | MPLS-IPv6 | +----------+------------------+ 9.7. BGP-LS SR Segment Descriptors This document requests IANA to maintain a new sub-registry under "Border Gateway Protocol - Link State (BGP-LS) Parameters". The new registry is called "SR Segment Descriptor Types" and contains the @@ -2030,21 +2070,21 @@ Email: cfilsfil@cisco.com 13. References 13.1. Normative References [I-D.ietf-spring-segment-routing-policy] Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., bogdanov@google.com, b., and P. Mattes, "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 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, . @@ -2095,20 +2135,24 @@ Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, March 2016, . + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + 13.2. Informative References [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, DOI 10.17487/RFC2702, September 1999, . [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, @@ -2141,26 +2185,27 @@ . [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, . Authors' Addresses - Stefano Previdi (editor) + Stefano Previdi Email: stefano@previdi.net - Ketan Talaulikar + Ketan Talaulikar (editor) Cisco Systems, Inc. + India Email: ketant@cisco.com Jie Dong (editor) Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: jie.dong@huawei.com @@ -2172,13 +2217,13 @@ China Email: mach.chen@huawei.com Hannes Gredler RtBrick Inc. Email: hannes@rtbrick.com Jeff Tantsura - Nuage Networks + Apstra Email: jefftant.ietf@gmail.com