draft-ietf-idr-te-lsp-distribution-06.txt   draft-ietf-idr-te-lsp-distribution-07.txt 
Network Working Group S. Previdi, Ed. Network Working Group S. Previdi, Ed.
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track J. Dong, Ed. Intended status: Standards Track J. Dong, Ed.
Expires: July 10, 2017 M. Chen Expires: January 2, 2018 M. Chen
Huawei Technologies Huawei Technologies
H. Gredler H. Gredler
RtBrick Inc. RtBrick Inc.
J. Tantsura J. Tantsura
Individual Individual
January 6, 2017 July 1, 2017
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-06 draft-ietf-idr-te-lsp-distribution-07
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
router and advertise it into BGP-LS updates. Such information can be router and advertise it into BGP-LS updates. Such information can be
used by external components for path computation, re-optimization, used by external components for path computation, re-optimization,
service placement, network visualization, etc. service placement, network visualization, etc.
Requirements Language Requirements Language
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 July 10, 2017. This Internet-Draft will expire on January 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Carrying TE Policy Information in BGP . . . . . . . . . . . . 5 2. Carrying TE Policy Information in BGP . . . . . . . . . . . . 5
2.1. TE Policy Information . . . . . . . . . . . . . . . . . . 5 2.1. TE Policy Information . . . . . . . . . . . . . . . . . . 5
2.2. TE Policy NLRI . . . . . . . . . . . . . . . . . . . . . 5 2.2. TE Policy NLRI . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. TE Policy Descriptors . . . . . . . . . . . . . . . . 6 2.2.1. TE Policy Descriptors . . . . . . . . . . . . . . . . 7
2.3. TE Policy State . . . . . . . . . . . . . . . . . . . . . 12 2.3. TE Policy State . . . . . . . . . . . . . . . . . . . . . 12
2.3.1. RSVP Objects . . . . . . . . . . . . . . . . . . . . 14 2.3.1. RSVP Objects . . . . . . . . . . . . . . . . . . . . 14
2.3.2. PCE Objects . . . . . . . . . . . . . . . . . . . . . 15 2.3.2. PCE Objects . . . . . . . . . . . . . . . . . . . . . 15
2.3.3. SR TE Policy Sub-TLVs . . . . . . . . . . . . . . . . 15 2.3.3. SR TE Policy Sub-TLVs . . . . . . . . . . . . . . . . 16
3. Operational Considerations . . . . . . . . . . . . . . . . . 21 3. Operational Considerations . . . . . . . . . . . . . . . . . 22
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
4.1. BGP-LS NLRI-Types . . . . . . . . . . . . . . . . . . . . 22 4.1. BGP-LS NLRI-Types . . . . . . . . . . . . . . . . . . . . 22
4.2. BGP-LS Protocol-IDs . . . . . . . . . . . . . . . . . . . 22 4.2. BGP-LS Protocol-IDs . . . . . . . . . . . . . . . . . . . 23
4.3. BGP-LS Descriptors TLVs . . . . . . . . . . . . . . . . . 22 4.3. BGP-LS Descriptors TLVs . . . . . . . . . . . . . . . . . 23
4.4. BGP-LS LSP-State TLV Protocol Origin . . . . . . . . . . 23 4.4. BGP-LS LSP-State TLV Path Origin . . . . . . . . . . . . 23
5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 4.5. BGP-LS LSP-State TLV Dataplane . . . . . . . . . . . . . 24
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 5. Security Considerations . . . . . . . . . . . . . . . . . . . 24
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Normative References . . . . . . . . . . . . . . . . . . 24 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24
7.2. Informative References . . . . . . . . . . . . . . . . . 25 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 8.1. Normative References . . . . . . . . . . . . . . . . . . 25
8.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
In many network environments, traffic engineering policies are In many network environments, traffic engineering 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).
skipping to change at page 5, line 20 skipping to change at page 5, line 20
2. Carrying TE Policy Information in BGP 2. Carrying TE Policy Information in BGP
2.1. TE Policy Information 2.1. TE Policy Information
TE Policy information is advertised in BGP UPDATE messages using the TE Policy information is advertised in BGP UPDATE messages using the
MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. The "Link- MP_REACH_NLRI and MP_UNREACH_NLRI attributes [RFC4760]. The "Link-
State NLRI" defined in [RFC7752] is extended to carry the TE Policy State NLRI" defined in [RFC7752] is extended to carry the TE Policy
information. BGP speakers that wish to exchange TE Policy information. BGP speakers that wish to exchange TE Policy
information MUST use the BGP Multiprotocol Extensions Capability Code information MUST use the BGP Multiprotocol Extensions Capability Code
(1) to advertise the corresponding (AFI, SAFI) pair, as specified in (1) to advertise the corresponding (AFI, SAFI) pair, as specified in
[RFC4760]. [RFC4760]. A new TLV carried in the Link_State Attribute defined in
[RFC7752] is also defined in order to carry the attributes of a TE
Policy (Section 2.3).
The format of "Link-State NLRI" is defined in [RFC7752]. A new "NLRI The format of "Link-State NLRI" is defined in [RFC7752]. A new "NLRI
Type" is defined for TE Policy Information as following: Type" is defined for TE Policy Information as following:
o NLRI Type: TE Policy NLRI (suggested codepoint value 5, to be o NLRI Type: TE Policy NLRI (suggested codepoint value 5, to be
assigned by IANA). assigned by IANA).
[RFC7752] defines the BGP-LS NLRI as follows: [RFC7752] defines the BGP-LS NLRI as follows:
0 1 2 3 0 1 2 3
skipping to change at page 6, line 13 skipping to change at page 6, line 13
IANA) is shown in the following figure: IANA) is shown in the following figure:
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
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Protocol-ID | | Protocol-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | | Identifier |
| (64 bits) | | (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Headend (Node Descriptors) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// TE Policy Descriptors (variable) // // TE Policy Descriptors (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
o Protocol-ID field specifies the signaling protocol of the TE o Protocol-ID field specifies the component that owns the TE Policy
Policy. The following Protocol-IDs are defined (suggested values, state in the advertising node. The following Protocol-IDs are
to be assigned by IANA) and apply to the TE Policy NLRI: defined (suggested values, to be assigned by IANA) and apply to
the TE Policy NLRI:
+-------------+----------------------------------+ +-------------+----------------------------------+
| Protocol-ID | NLRI information source protocol | | Protocol-ID | NLRI information source protocol |
+-------------+----------------------------------+ +-------------+----------------------------------+
| 8 | RSVP-TE | | 8 | RSVP-TE |
| 9 | Segment Routing | | 9 | 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 Following TE Policy Descriptors are defined: o "Headend" consists of a Node Descriptor defined in [RFC7752].
o "TE Policy Descriptors" consists of:
+-----------+----------------------------------+ +-----------+----------------------------------+
| Codepoint | Descriptor TLV | | Codepoint | Descriptor TLV |
+-----------+----------------------------------+ +-----------+----------------------------------+
| 267 | Tunnel ID | | 267 | Tunnel ID |
| 268 | LSP ID | | 268 | LSP ID |
| 269 | IPv4/6 Tunnel Head-end address | | 269 | IPv4/6 Tunnel Head-end address |
| 270 | IPv4/6 Tunnel Tail-end address | | 270 | IPv4/6 Tunnel Tail-end address |
| 271 | SR TE Policy | | 271 | SR TE Policy |
| 272 | Local Cross Connect | | 272 | Local Cross Connect |
skipping to change at page 11, line 17 skipping to change at page 11, line 17
interface (incoming or outgoing) in the form of an IPv4 address or an interface (incoming or outgoing) in the form of an IPv4 address or an
IPv6 address. IPv6 address.
The Interface sub-TLV has the following format: The Interface sub-TLV has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Interface Address (4 or 16 octets) //
+-+-+-+-+-+-+-+-+
| Flags |
+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Interface Identifier (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Interface Address (4 or 16 octets) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: where:
o Type: To be assigned by IANA (suggested value: 1) o Type: To be assigned by IANA (suggested value: 1)
o Length: 5 or 17. o Length: 9 or 21.
o Flags: 1 octet of flags defined as follows: o Flags: 1 octet of flags defined as follows:
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|I| | |I| |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
where: where:
* I-Flag is the Interface flag. When set, the Interface Sub-TLV * I-Flag is the Interface flag. When set, the Interface Sub-TLV
describes an incoming interface. If the I-flag is not set, describes an incoming interface. If the I-flag is not set,
then the Interface Sub-TLV describes an outgoing interface. then the Interface Sub-TLV describes an outgoing interface.
o Local Interface Identifier: a 4 octet identifier.
o Interface address: a 4 octet IPv4 address or a 16 octet IPv6 o Interface address: a 4 octet IPv4 address or a 16 octet IPv6
address. address.
2.2.1.6.1.2. Forwarding Equivalent Class (FEC) Sub-TLV 2.2.1.6.1.2. Forwarding Equivalent Class (FEC) Sub-TLV
The FEC sub-TLV is optional and contains the FEC associated to the The FEC sub-TLV is optional and contains the FEC associated to the
incoming label. incoming label.
The FEC sub-TLV has the following format: The FEC sub-TLV has the following format:
skipping to change at page 12, line 45 skipping to change at page 12, line 52
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.
2.3. TE Policy State 2.3. TE Policy State
A new TLV called "TE Policy State TLV" (codepoint to be assigned by A new TLV called "TE Policy State TLV" (codepoint to be assigned by
IANA), is used to describe the characteristics of the TE Policy, IANA), is used to describe the characteristics of the TE Policy,
which is carried in the optional non-transitive BGP Attribute which is carried in the optional non-transitive BGP Attribute
"LINK_STATE Attribute" defined in [RFC7752]. These TE Policy "LINK_STATE Attribute" defined in [RFC7752]. These TE Policy
characteristics include the characteristics and attributs of the characteristics include the characteristics and attributes of the
policy, it's dataplane, explicit path, Quality of Service (QoS) policy, it's dataplane, explicit path, Quality of Service (QoS)
parameters, route information, the protection mechanisms, etc. parameters, route information, the protection mechanisms, etc.
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 |
// TE Policy State Information (variable) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TE Policy State TLV +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// TE Policy State Sub-TLVs (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Suggested value 1158 (to be assigned by IANA) where:
TE Policy State Information: Consists of a set of objects as defined TE Policy State TLV
in [RFC3209],[RFC3473], [RFC5440] and
[I-D.previdi-idr-segment-routing-te-policy]. Rather than replicating
all these objects in this document, the semantics and encodings of
the objects are reused. These objects are carried in the "TE Policy
State Information" with the following format.
0 1 2 3 o Type: Suggested value 1158 (to be assigned by IANA)
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Protocol-Origin| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Protocol specific TE Policy objects //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TE Policy State Information o Length: the total length of the TE Policy State TLV not including
Type and Length fields.
The Protocol-Origin field identifies the protocol from which the o Path-origin: identifies the component (or protocol) from which the
contained object originated. This allows for objects defined in contained object originated. This allows for objects defined in
different protocols to be collected while avoiding the possible code different components to be collected while avoiding the possible
collisions among these protocols. Three Protocol-Origins are defined code collisions among these components. Following path-origin
in this document (suggested values, to be assigned by IANA) codepoints are defined in this document (suggested values, to be
assigned by IANA).
+----------+------------------+ +----------+------------------+
| Protocol | LSP Object | | Code | Path |
| Origin | Origin | | Point | Origin |
+----------+------------------+ +----------+------------------+
| 1 | RSVP-TE | | 1 | RSVP-TE |
| 2 | PCE | | 2 | PCE |
| 3 | BGP SR TE Policy | | 3 | BGP SR TE Policy |
| 4 | NETCONF |
| 5 | Static |
+----------+------------------+ +----------+------------------+
The 8-bit Reserved field SHOULD be set to 0 on transmission and MUST o Dataplane: describes to which dataplane the policy is applied to.
be ignored on receipt. The following dataplane values are defined:
The Length field is set to the Length of the value field, which is +----------+------------------+
the total length of the contained object. | Code | Dataplane |
| Point | |
+----------+------------------+
| 1 | MPLS-IPv4 |
| 2 | MPLS-IPv6 |
| 3 | IPv6 |
+----------+------------------+
The Valued field is a TE Policy object which is defined in the o RESERVED: 16-bit field field. SHOULD be set to 0 on transmission
protocol identified by the Protocol-Origin field. and MUST be ignored on receipt.
TE Policy State sub-TLVs: objects as defined in [RFC3209],[RFC3473],
[RFC5440] and [I-D.previdi-idr-segment-routing-te-policy]. Rather
than replicating all these objects in this document, the semantics
and encodings of the objects are reused. These objects are carried
in the "TE Policy State Information" with the following format.
2.3.1. RSVP Objects 2.3.1. RSVP Objects
RSVP-TE objects are encoded in the "Value" field of the LSP State TLV RSVP-TE objects are encoded in the "Value" field of the LSP State TLV
and consists of MPLS TE LSP objects defined in RSVP-TE [RFC3209] and consists of MPLS TE LSP objects defined in RSVP-TE [RFC3209]
[RFC3473]. Rather than replicating all MPLS TE LSP related objects [RFC3473]. Rather than replicating all MPLS TE LSP related objects
in this document, the semantics and encodings of the MPLS TE LSP 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 objects are re-used. These MPLS TE LSP objects are carried in the
LSP State TLV. LSP State TLV.
When carrying RSVP-TE objects, the "Protocol-Origin" field is set to When carrying RSVP-TE objects, the "Path-Origin" field is set to
"RSVP-TE" (suggested value 1, to be assigned by IANA). "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]
o ROUTE_RECORD Object (RRO) [RFC3209] o ROUTE_RECORD Object (RRO) [RFC3209]
skipping to change at page 15, line 24 skipping to change at page 15, line 34
state TLV. state TLV.
2.3.2. PCE Objects 2.3.2. PCE Objects
PCE objects are encoded in the "Value" field of the MPLS TE LSP State PCE objects are encoded in the "Value" field of the MPLS TE LSP State
TLV and consists of PCE objects defined in [RFC5440]. Rather than TLV and consists of PCE objects defined in [RFC5440]. 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 LSP State TLV. These MPLS TE LSP objects are carried in the LSP State TLV.
When carrying PCE objects, the "Protocol-Origin" field is set to When carrying PCE objects, the "Path-Origin" field is set to "PCE".
"PCE" (suggested value 2, to be assigned by IANA).
The following PCE Objects are defined: The following PCE 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 16, line 4 skipping to change at page 16, line 17
Segment Routing Traffic Engineering Policy (SR TE Policy) as Segment Routing Traffic Engineering Policy (SR TE Policy) as
described in [I-D.previdi-idr-segment-routing-te-policy]makes use of described in [I-D.previdi-idr-segment-routing-te-policy]makes use of
the Tunnel Encapsulation Attribute defined in the Tunnel Encapsulation Attribute defined in
[I-D.ietf-idr-tunnel-encaps] and defines following sub-TLVs: [I-D.ietf-idr-tunnel-encaps] and defines following sub-TLVs:
o Preference o Preference
o Binding SID o Binding SID
o Weight o Weight
o Segment List o Segment List
o Segment o Segment
The equivalent sub-TLVs are defined hereafter and carried in the TE The equivalent sub-TLVs are defined hereafter and carried in the TE
Policy State TLV. When carrying SR TE Policy objects, the "Protocol- Policy State TLV. When carrying SR TE Policy objects, the "Path-
Origin" field is set to "BGP SR TE Policy" (suggested value 3, to be Origin" field is set to "BGP SR TE Policy".
assigned by IANA).
2.3.3.1. Preference Object 2.3.3.1. Preference Object
The Preference sub-TLV has the following format: The Preference sub-TLV has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Flags | RESERVED | | Type | Length | Flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 23, line 17 skipping to change at page 23, line 41
| Point | | in | | Point | | in |
+----------+--------------------------------------+---------------+ +----------+--------------------------------------+---------------+
| 1158 | TE Policy State TLV | this document | | 1158 | TE Policy State TLV | this document |
| 267 | Tunnel ID TLV | this document | | 267 | Tunnel ID TLV | this document |
| 268 | LSP ID TLV | this document | | 268 | LSP ID TLV | this document |
| 269 | IPv4/6 Tunnel Head-end address TLV | this document | | 269 | IPv4/6 Tunnel Head-end address TLV | this document |
| 270 | IPv4/6 Tunnel Tail-end address TLV | this document | | 270 | IPv4/6 Tunnel Tail-end address TLV | this document |
| 271 | SR TE Policy Identifier TLV | this document | | 271 | SR TE Policy Identifier TLV | this document |
+----------+--------------------------------------+---------------+ +----------+--------------------------------------+---------------+
4.4. BGP-LS LSP-State TLV Protocol Origin 4.4. BGP-LS LSP-State TLV Path 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 "Protocol Origin" and contains the codepoints registry is called "Path Origin" and contains the codepoints
allocated to the "Protocol Origin" field defined in Section 2.3. The allocated to the "Path Origin" field defined in Section 2.3. 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):
+----------+------------------+ +----------+------------------+
| Protocol | Description | | Code | Path |
| Origin | | | Point | Origin |
+----------+------------------+ +----------+------------------+
| 1 | RSVP-TE | | 1 | RSVP-TE |
| 2 | PCE | | 2 | PCE |
| 3 | BGP SR TE Policy | | 3 | BGP SR TE Policy |
+----------+------------------+ | 4 | NETCONF |
| 5 | Static |
+----------+------------------+
4.5. BGP-LS LSP-State TLV Dataplane
This document requests IANA to maintain a new sub-registry under
"Border Gateway Protocol - Link State (BGP-LS) Parameters". The new
registry is called "Dataplane" and contains the codepoints allocated
to the "dataplane" field defined in Section 2.3. The registry
contains the following codepoints (suggested values, to be assigned
by IANA):
+----------+------------------+
| Code | Dataplane |
| Point | |
+----------+------------------+
| 1 | MPLS-IPv4 |
| 2 | MPLS-IPv6 |
| 3 | IPv6 |
+----------+------------------+
5. Security Considerations 5. Security Considerations
Procedures and protocol extensions defined in this document do not Procedures and protocol extensions defined in this document do not
affect the BGP security model. See [RFC6952] for details. affect the BGP security model. See [RFC6952] for details.
6. Acknowledgements 6. Acknowledgements
The authors would like to thank Dhruv Dhody, Mohammed Abdul Aziz The authors would like to thank Dhruv Dhody, Mohammed Abdul Aziz
Khalid, Lou Berger, Acee Lindem, Siva Sivabalan, Arjun Sreekantiah, Khalid, Lou Berger, Acee Lindem, Siva Sivabalan, Arjun Sreekantiah,
Dhanendra Jain and Clarence Filsfils for their review and valuable and Dhanendra Jain for their review and valuable comments.
comments.
7. References 7. Contributors
7.1. Normative References
The following people have substantially contributed to the editing of
this document:
Ketan Talaulikar
Cisco Systems
Email: ketant@cisco.com
Clarence Filsfils
Cisco Systems
Email: cfilsfil@cisco.com
8. References
8.1. Normative References
[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,
<http://www.rfc-editor.org/info/rfc2119>. <http://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, <http://www.rfc-editor.org/info/rfc2205>. September 1997, <http://www.rfc-editor.org/info/rfc2205>.
skipping to change at page 25, line 22 skipping to change at page 26, line 27
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,
<http://www.rfc-editor.org/info/rfc5440>. <http://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,
<http://www.rfc-editor.org/info/rfc7752>. <http://www.rfc-editor.org/info/rfc7752>.
7.2. Informative References 8.2. Informative References
[I-D.ietf-idr-tunnel-encaps] [I-D.ietf-idr-tunnel-encaps]
Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel Rosen, E., Patel, K., and G. Velde, "The BGP Tunnel
Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-03 Encapsulation Attribute", draft-ietf-idr-tunnel-encaps-06
(work in progress), November 2016. (work in progress), June 2017.
[I-D.ietf-pce-stateful-pce] [I-D.ietf-pce-stateful-pce]
Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP
Extensions for Stateful PCE", draft-ietf-pce-stateful- Extensions for Stateful PCE", draft-ietf-pce-stateful-
pce-18 (work in progress), December 2016. pce-21 (work in progress), June 2017.
[I-D.previdi-idr-segment-routing-te-policy] [I-D.previdi-idr-segment-routing-te-policy]
Previdi, S., Filsfils, C., Sreekantiah, A., Sivabalan, S., Previdi, S., Filsfils, C., Mattes, P., Rosen, E., and S.
Mattes, P., Rosen, E., and S. Lin, "Advertising Segment Lin, "Advertising Segment Routing Policies in BGP", draft-
Routing Traffic Engineering Policies in BGP", draft- previdi-idr-segment-routing-te-policy-07 (work in
previdi-idr-segment-routing-te-policy-03 (work in progress), June 2017.
progress), December 2016.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation
Element (PCE)-Based Architecture", RFC 4655, Element (PCE)-Based Architecture", RFC 4655,
DOI 10.17487/RFC4655, August 2006, DOI 10.17487/RFC4655, August 2006,
<http://www.rfc-editor.org/info/rfc4655>. <http://www.rfc-editor.org/info/rfc4655>.
[RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
BGP, LDP, PCEP, and MSDP Issues According to the Keying BGP, LDP, PCEP, and MSDP Issues According to the Keying
and Authentication for Routing Protocols (KARP) Design and Authentication for Routing Protocols (KARP) Design
Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
<http://www.rfc-editor.org/info/rfc6952>. <http://www.rfc-editor.org/info/rfc6952>.
Authors' Addresses Authors' Addresses
Stefano Previdi (editor) Stefano Previdi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Via Del Serafico, 200
Rome 00142
Italy
Email: sprevidi@cisco.com Email: stefano@previdi.net
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
Mach(Guoyi) Chen Mach(Guoyi) Chen
 End of changes. 42 change blocks. 
93 lines changed or deleted 142 lines changed or added

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