draft-ietf-idr-bgp-ls-segment-routing-ext-12.txt   draft-ietf-idr-bgp-ls-segment-routing-ext-13.txt 
Inter-Domain Routing S. Previdi Inter-Domain Routing S. Previdi
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Standards Track K. Talaulikar, Ed. Intended status: Standards Track K. Talaulikar, Ed.
Expires: September 9, 2019 C. Filsfils Expires: October 20, 2019 C. Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
H. Gredler H. Gredler
RtBrick Inc. RtBrick Inc.
M. Chen M. Chen
Huawei Technologies Huawei Technologies
March 8, 2019 April 18, 2019
BGP Link-State extensions for Segment Routing BGP Link-State extensions for Segment Routing
draft-ietf-idr-bgp-ls-segment-routing-ext-12 draft-ietf-idr-bgp-ls-segment-routing-ext-13
Abstract Abstract
Segment Routing (SR) allows for a flexible definition of end-to-end Segment Routing (SR) allows for a flexible definition of end-to-end
paths by encoding paths as sequences of topological sub-paths, called paths by encoding paths as sequences of topological sub-paths, called
"segments". These segments are advertised by routing protocols e.g. "segments". These segments are advertised by routing protocols e.g.
by the link state routing protocols (IS-IS, OSPFv2 and OSPFv3) within by the link state routing protocols (IS-IS, OSPFv2 and OSPFv3) within
IGP topologies. IGP topologies.
This draft defines extensions to the BGP Link-state address-family in This draft defines extensions to the BGP Link-state address-family in
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 9, 2019. This Internet-Draft will expire on October 20, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 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
skipping to change at page 2, line 39 skipping to change at page 2, line 39
2.1.4. SR Local Block TLV . . . . . . . . . . . . . . . . . 8 2.1.4. SR Local Block TLV . . . . . . . . . . . . . . . . . 8
2.1.5. SRMS Preference TLV . . . . . . . . . . . . . . . . . 9 2.1.5. SRMS Preference TLV . . . . . . . . . . . . . . . . . 9
2.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . . . 10 2.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . . . 10
2.2.1. Adjacency SID TLV . . . . . . . . . . . . . . . . . . 10 2.2.1. Adjacency SID TLV . . . . . . . . . . . . . . . . . . 10
2.2.2. LAN Adjacency SID TLV . . . . . . . . . . . . . . . . 12 2.2.2. LAN Adjacency SID TLV . . . . . . . . . . . . . . . . 12
2.2.3. L2 Bundle Member Attribute TLV . . . . . . . . . . . 14 2.2.3. L2 Bundle Member Attribute TLV . . . . . . . . . . . 14
2.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . . . 15 2.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . . . 15
2.3.1. Prefix SID TLV . . . . . . . . . . . . . . . . . . . 16 2.3.1. Prefix SID TLV . . . . . . . . . . . . . . . . . . . 16
2.3.2. Prefix Attribute Flags TLV . . . . . . . . . . . . . 17 2.3.2. Prefix Attribute Flags TLV . . . . . . . . . . . . . 17
2.3.3. Source Router Identifier (Source Router-ID) TLV . . . 18 2.3.3. Source Router Identifier (Source Router-ID) TLV . . . 18
2.3.4. Range TLV . . . . . . . . . . . . . . . . . . . . . . 19 2.3.4. Range TLV . . . . . . . . . . . . . . . . . . . . . . 18
2.4. Equivalent IS-IS Segment Routing TLVs/Sub-TLVs . . . . . 21 2.4. Equivalent IS-IS Segment Routing TLVs/Sub-TLVs . . . . . 20
2.5. Equivalent OSPFv2/OSPFv3 Segment Routing TLVs/Sub-TLVs . 21 2.5. Equivalent OSPFv2/OSPFv3 Segment Routing TLVs/Sub-TLVs . 21
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
3.1. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . 23 3.1. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . 23
4. Manageability Considerations . . . . . . . . . . . . . . . . 24 4. Manageability Considerations . . . . . . . . . . . . . . . . 24
5. Security Considerations . . . . . . . . . . . . . . . . . . . 25 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.1. Normative References . . . . . . . . . . . . . . . . . . 26 8.1. Normative References . . . . . . . . . . . . . . . . . . 27
8.2. Informative References . . . . . . . . . . . . . . . . . 28 8.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
Segment Routing (SR) allows for a flexible definition of end-to-end Segment Routing (SR) allows for a flexible definition of end-to-end
paths by combining sub-paths called "segments". A segment can paths by combining sub-paths called "segments". A segment can
represent any instruction, topological or service-based. A segment represent any instruction, topological or service-based. A segment
can have a local semantic to an SR node or global within a domain. can have a local semantic to an SR node or global within a domain.
Within IGP topologies an SR path is encoded as a sequence of Within IGP topologies an SR path is encoded as a sequence of
skipping to change at page 12, line 10 skipping to change at page 12, line 10
[I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-isis-segment-routing-extensions],
* OSPFv2: Label or index value as defined in * OSPFv2: Label or index value as defined in
[I-D.ietf-ospf-segment-routing-extensions], [I-D.ietf-ospf-segment-routing-extensions],
* OSPFv3: Label or index value as defined in * OSPFv3: Label or index value as defined in
[I-D.ietf-ospf-ospfv3-segment-routing-extensions], [I-D.ietf-ospf-ospfv3-segment-routing-extensions],
The Flags and, as an extension, the SID/Index/Label fields of this The Flags and, as an extension, the SID/Index/Label fields of this
TLV need to be interpreted accordingly to the respective underlying TLV need to be interpreted accordingly to the respective underlying
IS-IS, OSPFv2 or OSPFv3 protocol. The consumer of the BGP-LS IS-IS, OSPFv2 or OSPFv3 protocol. The Protocol-ID of the BGP-LS Link
interested in this TLV information MUST check the Protocol-ID of the NLRI should be used to determine the underlying protocol
BGP-LS Link NLRI and refer to the underlying protocol specification specification for parsing these fields.
in order to parse these fields.
2.2.2. LAN Adjacency SID TLV 2.2.2. LAN Adjacency SID TLV
For a LAN, normally a node only announces its adjacency to the IS-IS For a LAN, normally a node only announces its adjacency to the IS-IS
pseudo-node (or the equivalent OSPF Designated and Backup Designated pseudo-node (or the equivalent OSPF Designated and Backup Designated
Routers). The LAN Adjacency Segment TLV allows a node to announce Routers). The LAN Adjacency Segment TLV allows a node to announce
adjacencies to all other nodes attached to the LAN in a single adjacencies to all other nodes attached to the LAN in a single
instance of the BGP-LS Link NLRI. Without this TLV, the instance of the BGP-LS Link NLRI. Without this TLV, the
corresponding BGP-LS link NLRI would need to be originated for each corresponding BGP-LS link NLRI would need to be originated for each
additional adjacency in order to advertise the SR TLVs for these additional adjacency in order to advertise the SR TLVs for these
skipping to change at page 13, line 45 skipping to change at page 13, line 45
[I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-isis-segment-routing-extensions],
* OSPFv2: Label or index value as defined in * OSPFv2: Label or index value as defined in
[I-D.ietf-ospf-segment-routing-extensions], [I-D.ietf-ospf-segment-routing-extensions],
* OSPFv3: Label or index value as defined in * OSPFv3: Label or index value as defined in
[I-D.ietf-ospf-ospfv3-segment-routing-extensions], [I-D.ietf-ospf-ospfv3-segment-routing-extensions],
The Neighbor ID, Flags and, as an extension, the SID/Index/Label The Neighbor ID, Flags and, as an extension, the SID/Index/Label
fields of this TLV need to be interpreted accordingly to the fields of this TLV need to be interpreted accordingly to the
respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. The consumer respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. The
of the BGP-LS interested in this TLV information MUST check the Protocol-ID of the BGP-LS Link NLRI should be used to determine the
Protocol-ID of the BGP-LS Link NLRI and refer to the underlying underlying protocol specification for parsing these fields.
protocol specification in order to parse these fields.
2.2.3. L2 Bundle Member Attribute TLV 2.2.3. L2 Bundle Member Attribute TLV
The L2 Bundle Member Attribute TLV identifies an L2 Bundle Member The L2 Bundle Member Attribute TLV identifies an L2 Bundle Member
link which in turn is associated with a parent L3 link. The L3 link link which in turn is associated with a parent L3 link. The L3 link
is described by the Link NLRI defined in [RFC7752] and the L2 Bundle is described by the Link NLRI defined in [RFC7752] and the L2 Bundle
Member Attribute TLV is associated with the Link NLRI. The TLV MAY Member Attribute TLV is associated with the Link NLRI. The TLV MAY
include sub-TLVs which describe attributes associated with the bundle include sub-TLVs which describe attributes associated with the bundle
member. The identified bundle member represents a unidirectional member. The identified bundle member represents a unidirectional
path from the originating router to the neighbor specified in the path from the originating router to the neighbor specified in the
skipping to change at page 15, line 5 skipping to change at page 15, line 5
Length: Variable. Length: Variable.
L2 Bundle Member Descriptor: A Link Local Identifier as defined in L2 Bundle Member Descriptor: A Link Local Identifier as defined in
[RFC4202]. [RFC4202].
Link attributes for L2 Bundle Member Links are advertised as sub-TLVs Link attributes for L2 Bundle Member Links are advertised as sub-TLVs
of the L2 Bundle Member Attribute TLV. The sub-TLVs are identical to of the L2 Bundle Member Attribute TLV. The sub-TLVs are identical to
existing BGP-LS TLVs as identified in the table below. existing BGP-LS TLVs as identified in the table below.
+-----------+----------------------------+--------------------------+ +-------------+------------------------------------+----------------+
| TLV Code | Description | Reference Document | | TLV Code | Description | Reference |
| Point | | | | Point | | Document |
+-----------+----------------------------+--------------------------+ +-------------+------------------------------------+----------------+
| 1088 | Administrative group | [RFC7752] | | 1088 | Administrative group (color) | [RFC7752] |
| | (color) | | | 1089 | Maximum link bandwidth | [RFC7752] |
| 1089 | Maximum link bandwidth | [RFC7752] | | 1090 | Max. reservable link bandwidth | [RFC7752] |
| 1090 | Max. reservable link | [RFC7752] | | 1091 | Unreserved bandwidth | [RFC7752] |
| | bandwidth | | | 1092 | TE default metric | [RFC7752] |
| 1091 | Unreserved bandwidth | [RFC7752] | | 1093 | Link protection type | [RFC7752] |
| 1092 | TE default metric | [RFC7752] | | 1099 | Adjacency Segment Identifier (Adj- | Section 2.2.1 |
| 1093 | Link protection type | [RFC7752] | | | SID) TLV | |
| 1099 | Adjacency Segment | Section 2.2.1 | | 1100 | LAN Adjacency Segment Identifier | Section 2.2.2 |
| | Identifier (Adj-SID) TLV | | | | (Adj-SID) TLV | |
| 1100 | LAN Adjacency Segment | Section 2.2.2 | | 1114 | Unidirectional link delay | [RFC8571] |
| | Identifier (Adj-SID) TLV | | | 1115 | Min/Max Unidirectional link delay | [RFC8571] |
| 1114 | Unidirectional link delay | [I-D.ietf-idr-te-pm-bgp] | | 1116 | Unidirectional Delay Variation | [RFC8571] |
| 1115 | Min/Max Unidirectional | [I-D.ietf-idr-te-pm-bgp] | | 1117 | Unidirectional packet loss | [RFC8571] |
| | link delay | | | 1118 | Unidirectional residual bandwidth | [RFC8571] |
| 1116 | Unidirectional Delay | [I-D.ietf-idr-te-pm-bgp] | | 1119 | Unidirectional available bandwidth | [RFC8571] |
| | Variation | | | 1120 | Unidirectional bandwidth | [RFC8571] |
| 1117 | Unidirectional packet loss | [I-D.ietf-idr-te-pm-bgp] | | | utilization | |
| 1118 | Unidirectional residual | [I-D.ietf-idr-te-pm-bgp] | +-------------+------------------------------------+----------------+
| | bandwidth | |
| 1119 | Unidirectional available | [I-D.ietf-idr-te-pm-bgp] |
| | bandwidth | |
| 1120 | Unidirectional bandwidth | [I-D.ietf-idr-te-pm-bgp] |
| | utilization | |
+-----------+----------------------------+--------------------------+
Table 3: BGP-LS Attribute TLVs also used as sub-TLVs of L2 Bundle Table 3: BGP-LS Attribute TLVs also used as sub-TLVs of L2 Bundle
Member Attribute TLV Member Attribute TLV
2.3. Prefix Attribute TLVs 2.3. Prefix Attribute TLVs
The following Prefix Attribute TLVs are defined: The following Prefix Attribute TLVs are defined:
+------+------------------------+---------------+ +------+------------------------+---------------+
| Type | Description | Section | | Type | Description | Section |
skipping to change at page 17, line 21 skipping to change at page 17, line 16
[I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-isis-segment-routing-extensions],
* OSPFv2: Label or index value as defined in * OSPFv2: Label or index value as defined in
[I-D.ietf-ospf-segment-routing-extensions], [I-D.ietf-ospf-segment-routing-extensions],
* OSPFv3: Label or index value as defined in * OSPFv3: Label or index value as defined in
[I-D.ietf-ospf-ospfv3-segment-routing-extensions], [I-D.ietf-ospf-ospfv3-segment-routing-extensions],
The Flags and, as an extension, the SID/Index/Label fields of this The Flags and, as an extension, the SID/Index/Label fields of this
TLV need to be interpreted accordingly to the respective underlying TLV need to be interpreted accordingly to the respective underlying
IS-IS, OSPFv2 or OSPFv3 protocol. The consumer of the BGP-LS IS-IS, OSPFv2 or OSPFv3 protocol. The Protocol-ID of the BGP-LS
interested in this TLV information MUST check the Protocol-ID of the Prefix NLRI should be used to determine the underlying protocol
BGP-LS Prefix NLRI and refer to the underlying protocol specification specification for parsing these fields.
in order to parse these fields.
2.3.2. Prefix Attribute Flags TLV 2.3.2. Prefix Attribute Flags TLV
The Prefix Attribute Flags TLV carries IPv4/IPv6 prefix attribute The Prefix Attribute Flags TLV carries IPv4/IPv6 prefix attribute
flags information. These flags are defined for OSPFv2 in [RFC7684], flags information. These flags are defined for OSPFv2 in [RFC7684],
for OSPFv3 in [RFC5340] and for IS-IS in [RFC7794]. for OSPFv3 in [RFC5340] and for IS-IS in [RFC7794].
The Prefix Attribute Flags TLV has the following format: The Prefix Attribute Flags TLV has the following format:
0 1 2 3 0 1 2 3
skipping to change at page 18, line 19 skipping to change at page 18, line 12
* IS-IS flags correspond to the IPv4/IPv6 Extended Reachability * IS-IS flags correspond to the IPv4/IPv6 Extended Reachability
Attribute Flags defined in [RFC7794] Attribute Flags defined in [RFC7794]
* OSPFv2 flags correspond to the Flags field of the OSPFv2 * OSPFv2 flags correspond to the Flags field of the OSPFv2
Extended Prefix TLV defined in [RFC7684] Extended Prefix TLV defined in [RFC7684]
* OSPFv3 flags map to the Prefix Options field defined in * OSPFv3 flags map to the Prefix Options field defined in
[RFC5340] and extended via [RFC8362] [RFC5340] and extended via [RFC8362]
The Flags field of this TLV need to be interpreted accordingly to the The Flags field of this TLV need to be interpreted accordingly to the
respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. The consumer respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. The
of the BGP-LS interested in this TLV information MUST check the Protocol-ID of the BGP-LS Prefix NLRI should be used to determine the
Protocol-ID of the BGP-LS Prefix NLRI and refer to the underlying underlying protocol specification for parsing these fields.
protocol specification in order to parse this field.
2.3.3. Source Router Identifier (Source Router-ID) TLV 2.3.3. Source Router Identifier (Source Router-ID) TLV
The Source Router-ID TLV contains the IPv4 or IPv6 Router-ID of the The Source Router-ID TLV contains the IPv4 or IPv6 Router-ID of the
originator of the Prefix. For IS-IS protocol this is as defined in originator of the Prefix. For IS-IS protocol this is as defined in
[RFC7794] IPv4 or IPv6 Router-ID of the originating router. For OSPF [RFC7794] IPv4 or IPv6 Router-ID of the originating router. For OSPF
protocol, this is as defined in [I-D.ietf-lsr-ospf-prefix-originator] protocol, this is as defined in [I-D.ietf-lsr-ospf-prefix-originator]
and is a 32 bit OSPF Router-ID of the originating router.. and is a 32 bit OSPF Router-ID of the originating router..
The Source Router-ID TLV has the following format: The Source Router-ID TLV has the following format:
skipping to change at page 19, line 12 skipping to change at page 19, line 4
Router-ID: the IPv4 or IPv6 Router-ID in case of IS-IS and the Router-ID: the IPv4 or IPv6 Router-ID in case of IS-IS and the
OSPF Router-ID in the case of OSPF. OSPF Router-ID in the case of OSPF.
2.3.4. Range TLV 2.3.4. Range TLV
The range TLV is used in order to advertise a range of prefix-to-SID The range TLV is used in order to advertise a range of prefix-to-SID
mappings as part of the Segment Routing Mapping Server (SRMS) mappings as part of the Segment Routing Mapping Server (SRMS)
functionality [I-D.ietf-spring-segment-routing-ldp-interop], as functionality [I-D.ietf-spring-segment-routing-ldp-interop], as
defined in the respective underlying IGP SR extensions defined in the respective underlying IGP SR extensions
[I-D.ietf-ospf-segment-routing-extensions], [I-D.ietf-ospf-segment-routing-extensions],
[I-D.ietf-ospf-ospfv3-segment-routing-extensions] and [I-D.ietf-ospf-ospfv3-segment-routing-extensions] and
[I-D.ietf-isis-segment-routing-extensions]. [I-D.ietf-isis-segment-routing-extensions].
A consumer of the BGP-LS information MUST NOT mis-interpret a Prefix A Prefix NLRI, that been advertised with a Range TLV, is considered
NLRI, that been advertised with a Range TLV associated with it on as a normal routing prefix (i.e. prefix reachability) unless there is
account of an SRMS prefix-to-SID mapping in the underlying IGP, as a also an IGP metric TLV (TLV 1095) attached to it.
normal routing prefix (i.e. prefix reachability) unless there is also
an IGP metric TLV (TLV 1095) attached to it.
The format of the Range TLV is as follows: The format of the Range TLV is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | Range Size | | Flags | Reserved | Range Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 24, line 41 skipping to change at page 24, line 41
affect the BGP protocol operations and management other than as affect the BGP protocol operations and management other than as
discussed in the Manageability Considerations section of [RFC7752]. discussed in the Manageability Considerations section of [RFC7752].
Specifically, the malformed attribute tests for syntactic checks in Specifically, the malformed attribute tests for syntactic checks in
the Fault Management section of [RFC7752] now encompass the new BGP- the Fault Management section of [RFC7752] now encompass the new BGP-
LS Attribute TLVs defined in this document. The semantic or content LS Attribute TLVs defined in this document. The semantic or content
checking for the TLVs specified in this document and their checking for the TLVs specified in this document and their
association with the BGP-LS NLRI types or their BGP-LS Attribute is association with the BGP-LS NLRI types or their BGP-LS Attribute is
left to the consumer of the BGP-LS information (e.g. an application left to the consumer of the BGP-LS information (e.g. an application
or a controller) and not the BGP protocol. or a controller) and not the BGP protocol.
A consumer of the BGP-LS information retrieves this information from A consumer of the BGP-LS information retrieves this information over
a BGP protocol component that is doing the signaling over a BGP-LS a BGP-LS session (refer Section 1 and 2 of [RFC7752]). The handling
session, via some APIs or a data model (refer Section 1 and 2 of of semantic or content errors by the consumer would be dictated by
[RFC7752]). The handling of semantic or content errors by the the nature of its application usage and hence is beyond the scope of
consumer would be dictated by the nature of its application usage and this document.
hence is beyond the scope of this document.
This document only introduces new Attribute TLVs and any syntactic This document only introduces new Attribute TLVs and any syntactic
error in them would result in only that specific attribute being error in them would result in only that specific attribute being
discarded with an error log. The SR information introduced in BGP-LS discarded with an error log. The SR information introduced in BGP-LS
by this specification, may be used by BGP-LS consumer applications by this specification, may be used by BGP-LS consumer applications
like a SR path computation engine (PCE) to learn the SR capabilities like a SR path computation engine (PCE) to learn the SR capabilities
of the nodes in the topology and the mapping of SR segments to those of the nodes in the topology and the mapping of SR segments to those
nodes. This can enable the SR PCE to perform path computations based nodes. This can enable the SR PCE to perform path computations based
on SR for traffic engineering use-cases and to steer traffic on paths on SR for traffic engineering use-cases and to steer traffic on paths
different from the underlying IGP based distributed best path different from the underlying IGP based distributed best path
skipping to change at page 25, line 26 skipping to change at page 25, line 25
The extensions, specified in this document, do not introduce any new The extensions, specified in this document, do not introduce any new
configuration or monitoring aspects in BGP or BGP-LS other than as configuration or monitoring aspects in BGP or BGP-LS other than as
discussed in [RFC7752]. The manageability aspects of the underlying discussed in [RFC7752]. The manageability aspects of the underlying
SR features are covered by [I-D.ietf-spring-sr-yang], SR features are covered by [I-D.ietf-spring-sr-yang],
[I-D.ietf-isis-sr-yang] and [I-D.ietf-ospf-sr-yang]. [I-D.ietf-isis-sr-yang] and [I-D.ietf-ospf-sr-yang].
5. Security Considerations 5. Security Considerations
The new protocol extensions introduced in this document augment the The new protocol extensions introduced in this document augment the
existing IGP topology information that was distributed via [RFC7752]. existing IGP topology information that is distributed via [RFC7752].
The Security Considerations section of [RFC7752] also applies to The Security Considerations section of [RFC7752] also applies to
these extensions. The procedures and new TLVs defined in this these extensions. The procedures and new TLVs defined in this
document, by themselves, do not affect the BGP-LS security model document, by themselves, do not affect the BGP-LS security model
discussed in [RFC7752]. discussed in [RFC7752].
The TLVs introduced in this document are used to propagate IGP
defined information ([I-D.ietf-isis-segment-routing-extensions],
[I-D.ietf-ospf-segment-routing-extensions] and
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]). These TLVs
represent the SR information associated with the IGP node, link and
prefix. The IGP instances originating these TLVs are assumed to
support all the required security and authentication mechanisms (as
described in [I-D.ietf-isis-segment-routing-extensions],
[I-D.ietf-ospf-segment-routing-extensions] and
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]) in order to
prevent any security issue when propagating the TLVs into BGP-LS.
The advertisement of the link attribute information defined in this
document presents no additional risk beyond that associated with the
existing set of link attribute information already supported in
[RFC7752].
BGP-LS SR extensions enable traffic engineering use-cases within the BGP-LS SR extensions enable traffic engineering use-cases within the
Segment Routing domain. SR operates within a trusted domain (refer Segment Routing domain. SR operates within a trusted domain
Security Considerations section in [RFC8402] for more detail) and its [RFC8402] and its security considerations also apply to BGP-LS
security considerations also apply to BGP-LS sessions when carrying sessions when carrying SR information. The SR traffic engineering
SR information.The SR traffic engineering policies using the SIDs policies using the SIDs advertised via BGP-LS are expected to be used
advertised via BGP-LS are expected to be used entirely within this entirely within this trusted SR domain (e.g. between multiple AS/
trusted SR domain (e.g. between multiple AS/domains within a single domains within a single provider network). Therefore, precaution is
provider network). Therefore, precaution is necessary to ensure that necessary to ensure that the SR information collected via BGP-LS is
the SR information collected via BGP-LS is limited to specific limited to specific consumers in a secure manner within this SR
controllers or applications in a secure manner within this SR domain. domain.
The isolation of BGP-LS peering sessions is also required to ensure The isolation of BGP-LS peering sessions is also required to ensure
that BGP-LS topology information (including the newly added SR that BGP-LS topology information (including the newly added SR
information) is not advertised to an external BGP peering session information) is not advertised to an external BGP peering session
outside an administrative domain. outside an administrative domain.
6. Contributors 6. Contributors
The following people have substantially contributed to the editing of The following people have substantially contributed to the editing of
this document: this document:
skipping to change at page 26, line 42 skipping to change at page 27, line 9
The authors would like to thank Jeffrey Haas, Aijun Wang, Robert The authors would like to thank Jeffrey Haas, Aijun Wang, Robert
Raszuk and Susan Hares for their review of this document and their Raszuk and Susan Hares for their review of this document and their
comments. The authors would also like to thank Alvaro Retana for his comments. The authors would also like to thank Alvaro Retana for his
extensive review and comments which helped correct issues and improve extensive review and comments which helped correct issues and improve
the document. the document.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-idr-te-pm-bgp]
Ginsberg, L., Previdi, S., Wu, Q., Tantsura, J., and C.
Filsfils, "BGP-LS Advertisement of IGP Traffic Engineering
Performance Metric Extensions", draft-ietf-idr-te-pm-
bgp-18 (work in progress), December 2018.
[I-D.ietf-isis-l2bundles] [I-D.ietf-isis-l2bundles]
Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and
E. Aries, "Advertising L2 Bundle Member Link Attributes in E. Aries, "Advertising L2 Bundle Member Link Attributes in
IS-IS", draft-ietf-isis-l2bundles-07 (work in progress), IS-IS", draft-ietf-isis-l2bundles-07 (work in progress),
May 2017. May 2017.
[I-D.ietf-isis-segment-routing-extensions] [I-D.ietf-isis-segment-routing-extensions]
Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A.,
Gredler, H., and B. Decraene, "IS-IS Extensions for Gredler, H., and B. Decraene, "IS-IS Extensions for
Segment Routing", draft-ietf-isis-segment-routing- Segment Routing", draft-ietf-isis-segment-routing-
extensions-22 (work in progress), December 2018. extensions-24 (work in progress), April 2019.
[I-D.ietf-lsr-ospf-prefix-originator] [I-D.ietf-lsr-ospf-prefix-originator]
Wang, A., Lindem, A., Dong, J., Talaulikar, K., and P. Wang, A., Lindem, A., Dong, J., Talaulikar, K., and P.
Psenak, "OSPF Extension for Prefix Originator", draft- Psenak, "OSPF Extension for Prefix Originator", draft-
ietf-lsr-ospf-prefix-originator-00 (work in progress), ietf-lsr-ospf-prefix-originator-00 (work in progress),
February 2019. February 2019.
[I-D.ietf-ospf-ospfv3-segment-routing-extensions] [I-D.ietf-ospf-ospfv3-segment-routing-extensions]
Psenak, P. and S. Previdi, "OSPFv3 Extensions for Segment Psenak, P. and S. Previdi, "OSPFv3 Extensions for Segment
Routing", draft-ietf-ospf-ospfv3-segment-routing- Routing", draft-ietf-ospf-ospfv3-segment-routing-
skipping to change at page 28, line 19 skipping to change at page 28, line 30
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
F. Baker, "OSPFv3 Link State Advertisement (LSA) F. Baker, "OSPFv3 Link State Advertisement (LSA)
Extensibility", RFC 8362, DOI 10.17487/RFC8362, April Extensibility", RFC 8362, DOI 10.17487/RFC8362, April
2018, <https://www.rfc-editor.org/info/rfc8362>. 2018, <https://www.rfc-editor.org/info/rfc8362>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and
C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of
IGP Traffic Engineering Performance Metric Extensions",
RFC 8571, DOI 10.17487/RFC8571, March 2019,
<https://www.rfc-editor.org/info/rfc8571>.
8.2. Informative References 8.2. Informative References
[I-D.ietf-isis-sr-yang] [I-D.ietf-isis-sr-yang]
Litkowski, S., Qu, Y., Sarkar, P., Chen, I., and J. Litkowski, S., Qu, Y., Sarkar, P., Chen, I., and J.
Tantsura, "YANG Data Model for IS-IS Segment Routing", Tantsura, "YANG Data Model for IS-IS Segment Routing",
draft-ietf-isis-sr-yang-04 (work in progress), June 2018. draft-ietf-isis-sr-yang-05 (work in progress), March 2019.
[I-D.ietf-ospf-sr-yang] [I-D.ietf-ospf-sr-yang]
Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem,
"YANG Data Model for OSPF SR (Segment Routing) Protocol", "YANG Data Model for OSPF SR (Segment Routing) Protocol",
draft-ietf-ospf-sr-yang-07 (work in progress), March 2019. draft-ietf-ospf-sr-yang-07 (work in progress), March 2019.
[I-D.ietf-spring-segment-routing-ldp-interop] [I-D.ietf-spring-segment-routing-ldp-interop]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and
S. Litkowski, "Segment Routing interworking with LDP", S. Litkowski, "Segment Routing interworking with LDP",
draft-ietf-spring-segment-routing-ldp-interop-15 (work in draft-ietf-spring-segment-routing-ldp-interop-15 (work in
skipping to change at page 28, line 47 skipping to change at page 29, line 21
[I-D.ietf-spring-sr-yang] [I-D.ietf-spring-sr-yang]
Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J. Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J.
Tantsura, "YANG Data Model for Segment Routing", draft- Tantsura, "YANG Data Model for Segment Routing", draft-
ietf-spring-sr-yang-12 (work in progress), February 2019. ietf-spring-sr-yang-12 (work in progress), February 2019.
[RFC5706] Harrington, D., "Guidelines for Considering Operations and [RFC5706] Harrington, D., "Guidelines for Considering Operations and
Management of New Protocols and Protocol Extensions", Management of New Protocols and Protocol Extensions",
RFC 5706, DOI 10.17487/RFC5706, November 2009, RFC 5706, DOI 10.17487/RFC5706, November 2009,
<https://www.rfc-editor.org/info/rfc5706>. <https://www.rfc-editor.org/info/rfc5706>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
Authors' Addresses Authors' Addresses
Stefano Previdi Stefano Previdi
Huawei Technologies Huawei Technologies
Rome Rome
Italy Italy
Email: stefano@previdi.net Email: stefano@previdi.net
Ketan Talaulikar (editor) Ketan Talaulikar (editor)
 End of changes. 22 change blocks. 
87 lines changed or deleted 91 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/