< draft-ietf-idr-bgp-ls-segment-routing-ext-15.txt   draft-ietf-idr-bgp-ls-segment-routing-ext-16.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: December 1, 2019 C. Filsfils Expires: December 29, 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
May 30, 2019 June 27, 2019
BGP Link-State extensions for Segment Routing BGP Link-State extensions for Segment Routing
draft-ietf-idr-bgp-ls-segment-routing-ext-15 draft-ietf-idr-bgp-ls-segment-routing-ext-16
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 document defines extensions to the BGP Link-state address-family This document defines extensions to the BGP Link-state address-family
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 December 1, 2019. This Internet-Draft will expire on December 29, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. BGP-LS Extensions for Segment Routing . . . . . . . . . . . . 4 2. BGP-LS Extensions for Segment Routing . . . . . . . . . . . . 5
2.1. Node Attributes TLVs . . . . . . . . . . . . . . . . . . 5 2.1. Node Attributes TLVs . . . . . . . . . . . . . . . . . . 5
2.1.1. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . 5 2.1.1. SID/Label TLV . . . . . . . . . . . . . . . . . . . . 5
2.1.2. SR Capabilities TLV . . . . . . . . . . . . . . . . . 6 2.1.2. SR Capabilities TLV . . . . . . . . . . . . . . . . . 6
2.1.3. SR Algorithm TLV . . . . . . . . . . . . . . . . . . 8 2.1.3. SR Algorithm TLV . . . . . . . . . . . . . . . . . . 8
2.1.4. SR Local Block TLV . . . . . . . . . . . . . . . . . 8 2.1.4. SR Local Block TLV . . . . . . . . . . . . . . . . . 8
2.1.5. SRMS Preference TLV . . . . . . . . . . . . . . . . . 10 2.1.5. SRMS Preference TLV . . . . . . . . . . . . . . . . . 10
2.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . . . 11 2.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . . . 11
2.2.1. Adjacency SID TLV . . . . . . . . . . . . . . . . . . 11 2.2.1. Adjacency SID TLV . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . . 16 2.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . . . 16
2.3.1. Prefix SID TLV . . . . . . . . . . . . . . . . . . . 17 2.3.1. Prefix SID TLV . . . . . . . . . . . . . . . . . . . 17
skipping to change at page 3, line 9 skipping to change at page 3, line 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Normative References . . . . . . . . . . . . . . . . . . 28 8.1. Normative References . . . . . . . . . . . . . . . . . . 28
8.2. Informative References . . . . . . . . . . . . . . . . . 30 8.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
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 semantic within a can have a local semantic to an SR node or global semantic within a
domain. Within IGP topologies, an SR path is encoded as a sequence domain. Within IGP topologies, an SR path is encoded as a sequence
of topological sub-paths, called "IGP segments". These segments are of topological sub-paths, called "IGP segments". These segments are
advertised by the link-state routing protocols (IS-IS, OSPFv2 and advertised by the link-state routing protocols (IS-IS, OSPFv2 and
OSPFv3). OSPFv3).
[RFC8402] defines the Link-State IGP segments - Prefix, Node, Anycast [RFC8402] defines the Link-State IGP segments - Prefix, Node, Anycast
and Adjacency segments. Prefix segments, by default, represent an and Adjacency segments. Prefix segments, by default, represent an
ECMP-aware shortest-path to a prefix, as per the state of the IGP ECMP-aware shortest-path to a prefix, as per the state of the IGP
topology. Adjacency segments represent a hop over a specific topology. Adjacency segments represent a hop over a specific
adjacency between two nodes in the IGP. A prefix segment is adjacency between two nodes in the IGP. A prefix segment is
typically a multi-hop path while an adjacency segment, in most of the typically a multi-hop path while an adjacency segment, in most of the
cases, is a one-hop path. Node and anycast segments are variations cases, is a one-hop path. Node and anycast segments are variations
of the prefix segment with their specific characteristics. of the prefix segment with their specific characteristics.
When Segment Routing is enabled in an IGP domain, segments are When Segment Routing is enabled in an IGP domain, segments are
advertised in the form of Segment Identifiers (SIDs). The IGP link- advertised in the form of Segment Identifiers (SIDs). The IGP link-
state routing protocols have been extended to advertise SIDs and state routing protocols have been extended to advertise SIDs and
other SR-related information. IGP extensions are described in: IS-IS other SR-related information. IGP extensions are described for: IS-
[I-D.ietf-isis-segment-routing-extensions], OSPFv2 IS [I-D.ietf-isis-segment-routing-extensions], OSPFv2
[I-D.ietf-ospf-segment-routing-extensions] and OSPFv3 [I-D.ietf-ospf-segment-routing-extensions] and OSPFv3
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]. Using these [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. Using these
extensions, Segment Routing can be enabled within an IGP domain. extensions, Segment Routing can be enabled within an IGP domain.
Segment Routing (SR) allows advertisement of single or multi-hop Segment Routing (SR) allows advertisement of single or multi-hop
paths. The flooding scope for the IGP extensions for Segment routing paths. The flooding scope for the IGP extensions for Segment routing
is IGP area-wide. Consequently, the contents of a Link State is IGP area-wide. Consequently, the contents of a Link State
Database (LSDB) or a Traffic Engineering Database (TED) has the scope Database (LSDB) or a Traffic Engineering Database (TED) has the scope
of an IGP area and therefore, by using the IGP alone it is not enough of an IGP area and therefore, by using the IGP alone it is not enough
to construct segments across multiple IGP Area or AS boundaries. to construct segments across multiple IGP Area or AS boundaries.
skipping to change at page 4, line 45 skipping to change at page 4, line 45
EBGP peers). An external component connects to the route-reflector EBGP peers). An external component connects to the route-reflector
to obtain this information (perhaps moderated by a policy regarding to obtain this information (perhaps moderated by a policy regarding
what information is or isn't advertised to the external component) as what information is or isn't advertised to the external component) as
described in [RFC7752]. described in [RFC7752].
This document describes extensions to BGP-LS to advertise the SR This document describes extensions to BGP-LS to advertise the SR
information. An external component (e.g., a controller) can collect information. An external component (e.g., a controller) can collect
SR information from across an SR domain (as described in [RFC8402]) SR information from across an SR domain (as described in [RFC8402])
and construct the end-to-end path (with its associated SIDs) that and construct the end-to-end path (with its associated SIDs) that
need to be applied to an incoming packet to achieve the desired end- need to be applied to an incoming packet to achieve the desired end-
to-end forwarding. The SR domain may be comprised of a single AS or to-end forwarding. SR operates within a trusted domain consisting of
multiple ASes. a single or multiple ASes managed by the same administrative entity
e.g. within a single provider network.
2. BGP-LS Extensions for Segment Routing 2. BGP-LS Extensions for Segment Routing
This document defines SR extensions to BGP-LS and specifies the TLVs This document defines SR extensions to BGP-LS and specifies the TLVs
and sub-TLVs for advertising SR information within the BGP-LS and sub-TLVs for advertising SR information within the BGP-LS
Attribute. Section 2.4 and Section 2.5 lists the equivalent TLVs and Attribute. Section 2.4 and Section 2.5 lists the equivalent TLVs and
sub-TLVs in IS-IS, OSPFv2 and OSPFv3 protocols. sub-TLVs in IS-IS, OSPFv2 and OSPFv3 protocols.
BGP-LS [RFC7752] defines the BGP-LS NLRI that can be a Node NLRI, a BGP-LS [RFC7752] defines the BGP-LS NLRI that can be a Node NLRI, a
Link NLRI or a Prefix NLRI. BGP-LS [RFC7752] defines the TLVs that Link NLRI or a Prefix NLRI. BGP-LS [RFC7752] defines the TLVs that
skipping to change at page 5, line 34 skipping to change at page 5, line 39
| 1036 | SR Local Block | Section 2.1.4 | | 1036 | SR Local Block | Section 2.1.4 |
| 1037 | SRMS Preference | Section 2.1.5 | | 1037 | SRMS Preference | Section 2.1.5 |
+------+-----------------+---------------+ +------+-----------------+---------------+
Table 1: Node Attribute TLVs Table 1: Node Attribute TLVs
These TLVs should only be added to the BGP-LS Attribute associated These TLVs should only be added to the BGP-LS Attribute associated
with the Node NLRI describing the IGP node that is originating the with the Node NLRI describing the IGP node that is originating the
corresponding IGP TLV/sub-TLV described below. corresponding IGP TLV/sub-TLV described below.
2.1.1. SID/Label Sub-TLV 2.1.1. SID/Label TLV
The SID/Label TLV is used as a sub-TLV by the SR Capabilities The SID/Label TLV is used as a sub-TLV by the SR Capabilities
(Section 2.1.2) and Segment Routing Local Block (SRLB) (Section 2.1.2) and Segment Routing Local Block (SRLB)
(Section 2.1.4) TLVs. This information is derived from the protocol (Section 2.1.4) TLVs. This information is derived from the protocol
specific advertisements. specific advertisements.
o IS-IS, as defined by the SID/Label sub-TLV in o IS-IS, as defined by the SID/Label sub-TLV in section 2.3 of
[I-D.ietf-isis-segment-routing-extensions]. [I-D.ietf-isis-segment-routing-extensions].
o OSPFv2/OSPFv3, as defined by the SID/Label sub-TLV in o OSPFv2/OSPFv3, as defined by the SID/Label sub-TLV in section 2.1
[I-D.ietf-ospf-segment-routing-extensions] and of [I-D.ietf-ospf-segment-routing-extensions] and section 3.1 of
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [I-D.ietf-ospf-ospfv3-segment-routing-extensions].
The TLV and has the following format: The TLV has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label (variable) // | SID/Label (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: SID/Label sub-TLV Format Figure 2: SID/Label TLV Format
Where: Where:
Type: 1161 Type: 1161
Length: Variable. Either 3 or 4 depending whether the value is Length: Variable. Either 3 or 4 depending whether the value is
encoded as a label or as an index/SID. encoded as a label or as an index/SID.
SID/Label: If length is set to 3, then the 20 rightmost bits SID/Label: If length is set to 3, then the 20 rightmost bits
represent a label (the total TLV size is 7) and the 4 leftmost represent a label (the total TLV size is 7) and the 4 leftmost
skipping to change at page 6, line 35 skipping to change at page 6, line 37
represents a 32 bit SID (the total TLV size is 8). represents a 32 bit SID (the total TLV size is 8).
2.1.2. SR Capabilities TLV 2.1.2. SR Capabilities TLV
The SR Capabilities TLV is used in order to advertise the node's SR The SR Capabilities TLV is used in order to advertise the node's SR
Capabilities including its Segment Routing Global Base (SRGB) Capabilities including its Segment Routing Global Base (SRGB)
range(s). In the case of IS-IS, the capabilities also include the range(s). In the case of IS-IS, the capabilities also include the
IPv4 and IPv6 support for the SR-MPLS forwarding plane. This IPv4 and IPv6 support for the SR-MPLS forwarding plane. This
information is derived from the protocol specific advertisements. information is derived from the protocol specific advertisements.
o IS-IS, as defined by the SR Capabilities sub-TLV in o IS-IS, as defined by the SR Capabilities sub-TLV in section 3.1 of
[I-D.ietf-isis-segment-routing-extensions]. [I-D.ietf-isis-segment-routing-extensions].
o OSPFv2/OSPFv3, as defined by the SID/Label Range TLV in o OSPFv2/OSPFv3, as defined by the SID/Label Range TLV in section
[I-D.ietf-ospf-segment-routing-extensions]. OSPFv3 leverages the 3.2 of [I-D.ietf-ospf-segment-routing-extensions]. OSPFv3
same TLV as defined for OSPFv2. leverages the same TLV as defined for OSPFv2.
The SR Capabilities TLV has the following format: The SR Capabilities 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 | Reserved | | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range Size 1 | | Range Size 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label sub-TLV 1 (variable) // | SID/Label sub-TLV 1 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range Size N | | Range Size N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label sub-TLV N (variable) // | SID/Label sub-TLV N //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: SR Capabilities TLV Format Figure 3: SR Capabilities TLV Format
Where: Where:
Type: 1034 Type: 1034
Length: Variable. Minimum length is 12. Length: Variable. Minimum length is 12.
Flags: 1 octet of flags as defined in Flags: 1 octet of flags as defined in section 3.1 of
[I-D.ietf-isis-segment-routing-extensions] for IS-IS. The flags [I-D.ietf-isis-segment-routing-extensions] for IS-IS. The flags
are not currently defined for OSPFv2 and OSPFv3 and SHOULD be set are not currently defined for OSPFv2 and OSPFv3 and MUST be set to
to 0 and MUST be ignored on receipt. 0 and ignored on receipt.
Reserved: 1 octet that SHOULD be set to 0 and MUST be ignored on Reserved: 1 octet that MUST be set to 0 and ignored on receipt.
receipt.
One or more entries, each of which have the following format: One or more entries, each of which have the following format:
Range Size: 3 octet with a non-zero value indicating the number Range Size: 3 octet with a non-zero value indicating the number
of labels in the range. of labels in the range.
SID/Label sub-TLV (as defined in Section 2.1.1) which encodes SID/Label TLV (as defined in Section 2.1.1) used as sub-TLV
the first label in the range. Since the SID/Label sub-TLV is which encodes the first label in the range. Since the SID/
used to indicate the first label of the SRGB range, only label Label TLV is used to indicate the first label of the SRGB
encoding is valid under the SR Capabilities TLV. range, only label encoding is valid under the SR Capabilities
TLV.
2.1.3. SR Algorithm TLV 2.1.3. SR Algorithm TLV
The SR Algorithm TLV is used in order to advertise the SR Algorithms The SR Algorithm TLV is used in order to advertise the SR Algorithms
supported by the node. This information is derived from the protocol supported by the node. This information is derived from the protocol
specific advertisements. specific advertisements.
o IS-IS, as defined by the SR-Algorithm sub-TLV in o IS-IS, as defined by the SR-Algorithm sub-TLV in section 3.2 of
[I-D.ietf-isis-segment-routing-extensions]. [I-D.ietf-isis-segment-routing-extensions].
o OSPFv2/OSPFv3, as defined by the SR-Algorithm TLV in o OSPFv2/OSPFv3, as defined by the SR-Algorithm TLV in section 3.1
[I-D.ietf-ospf-segment-routing-extensions]. OSPFv3 leverages the of [I-D.ietf-ospf-segment-routing-extensions]. OSPFv3 leverages
same TLV as defined for OSPFv2. the same TLV as defined for OSPFv2.
The SR Algorithm TLV has the following format: The SR Algorithm 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm 1 | Algorithm... | Algorithm N | | Algorithm 1 | Algorithm... | Algorithm N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 9, line 5 skipping to change at page 9, line 5
(IS-IS, OSPF) for Adjacency-SIDs, and may also be allocated by (IS-IS, OSPF) for Adjacency-SIDs, and may also be allocated by
components other than IGP protocols. As an example, an application components other than IGP protocols. As an example, an application
or a controller may instruct a node to allocate a specific local SID. or a controller may instruct a node to allocate a specific local SID.
Therefore, in order for such applications or controllers to know the Therefore, in order for such applications or controllers to know the
range of local SIDs available, it is required that the node range of local SIDs available, it is required that the node
advertises its SRLB. advertises its SRLB.
This information is derived from the protocol specific This information is derived from the protocol specific
advertisements. advertisements.
o IS-IS, as defined by the SR Local Block sub-TLV in o IS-IS, as defined by the SR Local Block sub-TLV in section 3.3 of
[I-D.ietf-isis-segment-routing-extensions]. [I-D.ietf-isis-segment-routing-extensions].
o OSPFv2/OSPFv3, as defined by the SR Local Block TLV in o OSPFv2/OSPFv3, as defined by the SR Local Block TLV in section
[I-D.ietf-ospf-segment-routing-extensions]. OSPFv3 leverages the 3.3. of [I-D.ietf-ospf-segment-routing-extensions]. OSPFv3
same TLV as defined for OSPFv2. leverages the same TLV as defined for OSPFv2.
The SRLB TLV has the following format: The SRLB 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 | Reserved | | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range Size 1 | | Sub-Range Size 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label sub-TLV 1 (variable) // | SID/Label sub-TLV 1 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range Size N | | Sub-Range Size N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label sub-TLV N (variable) // | SID/Label sub-TLV N //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: SRLB TLV Format Figure 5: SRLB TLV Format
Where: Where:
Type: 1036 Type: 1036
Length: Variable. Minimum length is 12. Length: Variable. Minimum length is 12.
Flags: 1 octet of flags. The flags are as defined in Flags: 1 octet of flags. The flags are as defined in section 3.3
[I-D.ietf-isis-segment-routing-extensions] for IS-IS. The flags of [I-D.ietf-isis-segment-routing-extensions] for IS-IS. The
are not currently defined for OSPFv2 and OSPFv3 and SHOULD be set flags are not currently defined for OSPFv2 and OSPFv3 and MUST be
to 0 and MUST be ignored on receipt. set to 0 and ignored on receipt.
Reserved: 1 octet that SHOULD be set to 0 and MUST be ignored on Reserved: 1 octet that MUST be set to 0 and ignored on receipt.
receipt.
One or more entries, each of which have the following format: One or more entries corresponding to sub-range(s), each of which
have the following format:
Range Size: 3 octet value indicating the number of labels in Range Size: 3 octet value indicating the number of labels in
the range. the range.
SID/Label sub-TLV (as defined in Section 2.1.1) which encodes SID/Label TLV (as defined in Section 2.1.1) used as sub-TLV
the first label in the range. Since the SID/Label sub-TLV is which encodes the first label in the sub-range. Since the SID/
used to indicate the first label of the SRLB range, only label Label TLV is used to indicate the first label of the SRLB sub-
encoding is valid under the SR Local Block TLV. range, only label encoding is valid under the SR Local Block
TLV.
2.1.5. SRMS Preference TLV 2.1.5. SRMS Preference TLV
The Segment Routing Mapping Server (SRMS) Preference TLV is used in The Segment Routing Mapping Server (SRMS) Preference TLV is used in
order to associate a preference with SRMS advertisements from a order to associate a preference with SRMS advertisements from a
particular source. [I-D.ietf-spring-segment-routing-ldp-interop] particular source. [I-D.ietf-spring-segment-routing-ldp-interop]
specifies the SRMS functionality along with SRMS preference of the specifies the SRMS functionality along with SRMS preference of the
node advertising the SRMS Prefix-to-SID Mapping ranges. node advertising the SRMS Prefix-to-SID Mapping ranges.
This information is derived from the protocol specific This information is derived from the protocol specific
advertisements. advertisements.
o IS-IS, as defined by the SRMS Preference sub-TLV in o IS-IS, as defined by the SRMS Preference sub-TLV in section 3.4 of
[I-D.ietf-isis-segment-routing-extensions]. [I-D.ietf-isis-segment-routing-extensions].
o OSPFv2/OSPFv3, as defined by the SRMS Preference TLV in o OSPFv2/OSPFv3, as defined by the SRMS Preference TLV in section
[I-D.ietf-ospf-segment-routing-extensions]. OSPFv3 leverages the 3.4 of [I-D.ietf-ospf-segment-routing-extensions]. OSPFv3
same TLV as defined for OSPFv2. leverages the same TLV as defined for OSPFv2.
The SRMS Preference TLV has the following format: The SRMS Preference 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preference | | Preference |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 6: SRMS Preference TLV Format Figure 6: SRMS Preference TLV Format
Where: Where:
Type: 1037 Type: 1037
Length: 1. Length: 1.
Preference: 1 octet carrying a unsigned 8 bit SRMS preference. Preference: 1 octet carrying an unsigned 8 bit SRMS preference.
2.2. Link Attribute TLVs 2.2. Link Attribute TLVs
The following Link Attribute TLVs are are defined: The following Link Attribute TLVs are are defined:
+------+-----------------------+---------------+ +------+-----------------------+---------------+
| Type | Description | Section | | Type | Description | Section |
+------+-----------------------+---------------+ +------+-----------------------+---------------+
| 1099 | Adjacency SID TLV | Section 2.2.1 | | 1099 | Adjacency SID TLV | Section 2.2.1 |
| 1100 | LAN Adjacency SID TLV | Section 2.2.2 | | 1100 | LAN Adjacency SID TLV | Section 2.2.2 |
skipping to change at page 11, line 27 skipping to change at page 11, line 29
Table 2: Link Attribute TLVs Table 2: Link Attribute TLVs
These TLVs should only be added to the BGP-LS Attribute associated These TLVs should only be added to the BGP-LS Attribute associated
with the Link NLRI describing the link of the IGP node that is with the Link NLRI describing the link of the IGP node that is
originating the corresponding IGP TLV/sub-TLV described below. originating the corresponding IGP TLV/sub-TLV described below.
2.2.1. Adjacency SID TLV 2.2.1. Adjacency SID TLV
The Adjacency SID TLV is used in order to advertise information The Adjacency SID TLV is used in order to advertise information
related to an Adjacency SID. This information is derived from Adj- related to an Adjacency SID. This information is derived from Adj-
SID sub-TLV of IS-IS [I-D.ietf-isis-segment-routing-extensions], SID sub-TLV of IS-IS (section 2.2.1 of
OSPFv2 [I-D.ietf-ospf-segment-routing-extensions] and OSPFv3 [I-D.ietf-isis-segment-routing-extensions]), OSPFv2 (section 6.1 of
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [I-D.ietf-ospf-segment-routing-extensions]) and OSPFv3 (section 7.1
of [I-D.ietf-ospf-ospfv3-segment-routing-extensions]).
The Adjacency SID TLV has the following format: The Adjacency SID 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 | Weight | Reserved | | Flags | Weight | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 48 skipping to change at page 12, line 4
| Flags | Weight | Reserved | | Flags | Weight | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) // | SID/Label/Index (variable) //
+---------------------------------------------------------------+ +---------------------------------------------------------------+
Figure 7: Adjacency SID TLV Format Figure 7: Adjacency SID TLV Format
Where: Where:
Type: 1099 Type: 1099
Length: Variable. Either 7 or 8 depending on Label or Index Length: Variable. Either 7 or 8 depending on Label or Index
encoding of the SID encoding of the SID
Flags. 1 octet value which should be set as: Flags. 1 octet value which should be set as:
* IS-IS Adj-SID flags are defined in * IS-IS Adj-SID flags are defined in section 2.2.1 of
[I-D.ietf-isis-segment-routing-extensions]. [I-D.ietf-isis-segment-routing-extensions].
* OSPFv2 Adj-SID flags are defined in * OSPFv2 Adj-SID flags are defined in section 6.1 of
[I-D.ietf-ospf-segment-routing-extensions]. [I-D.ietf-ospf-segment-routing-extensions].
* OSPFv3 Adj-SID flags are defined in * OSPFv3 Adj-SID flags are defined in section 7.1 of
[I-D.ietf-ospf-segment-routing-extensions]. [I-D.ietf-ospf-ospfv3-segment-routing-extensions].
Weight: 1 octet carrying the weight used for load-balancing Weight: 1 octet carrying the weight used for load-balancing
purposes. purposes. The use of weight is described in section 3.4 of
[RFC8402].
Reserved: 2 octets that SHOULD be set to 0 and MUST be ignored on Reserved: 2 octets that MUST be set to 0 and ignored on receipt.
receipt.
SID/Index/Label: SID/Index/Label:
* IS-IS: Label or index value as defined in * IS-IS: Label or index value as defined in section 2.2.1 of
[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 section 6.1 of
[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 section 7.1 of
[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 are interpreted according to the respective underlying IS-IS, TLV are interpreted according to the respective underlying IS-IS,
OSPFv2 or OSPFv3 protocol. The Protocol-ID of the BGP-LS Link NLRI OSPFv2 or OSPFv3 protocol. The Protocol-ID of the BGP-LS Link NLRI
is used to determine the underlying protocol specification for is used to determine the underlying protocol specification for
parsing these fields. parsing 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
neighbor adjacencies. neighbor adjacencies.
This information is derived from LAN-Adj-SID sub-TLV of IS-IS This information is derived from LAN-Adj-SID sub-TLV of IS-IS
[I-D.ietf-isis-segment-routing-extensions] and LAN Adj-SID sub-TLV of (section 2.2.2 of [I-D.ietf-isis-segment-routing-extensions]) and LAN
OSPFv2 [I-D.ietf-ospf-segment-routing-extensions] and OSPFv3 Adj-SID sub-TLV of OSPFv2 (section 6.2 of
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [I-D.ietf-ospf-segment-routing-extensions]) and OSPFv3 (section 7.2
of [I-D.ietf-ospf-ospfv3-segment-routing-extensions]).
The LAN Adjacency SID TLV has the following format: The LAN Adjacency SID 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 | Weight | Reserved | | Flags | Weight | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 13, line 39 skipping to change at page 13, line 43
Where: Where:
Type: 1100 Type: 1100
Length: Variable. For IS-IS it would be 13 or 14 depending on Length: Variable. For IS-IS it would be 13 or 14 depending on
Label or Index encoding of the SID. For OSPF it would be 11 or 12 Label or Index encoding of the SID. For OSPF it would be 11 or 12
depending on Label or Index encoding of the SID. depending on Label or Index encoding of the SID.
Flags. 1 octet value which should be set as: Flags. 1 octet value which should be set as:
* IS-IS LAN Adj-SID flags are defined in * IS-IS LAN Adj-SID flags are defined in section 2.2.2 of
[I-D.ietf-isis-segment-routing-extensions]. [I-D.ietf-isis-segment-routing-extensions].
* OSPFv2 LAN Adj-SID flags are defined in * OSPFv2 LAN Adj-SID flags are defined in section 6.2 of
[I-D.ietf-ospf-segment-routing-extensions]. [I-D.ietf-ospf-segment-routing-extensions].
* OSPFv3 LAN Adj-SID flags are defined in * OSPFv3 LAN Adj-SID flags are defined in section 7.2 of
[I-D.ietf-ospf-segment-routing-extensions]. [I-D.ietf-ospf-segment-routing-extensions].
Weight: 1 octet carrying the weight used for load-balancing Weight: 1 octet carrying the weight used for load-balancing
purposes. purposes. The use of weight is described in section 3.4 of
[RFC8402].
Reserved: 2 octets that SHOULD be set to 0 and MUST be ignored on Reserved: 2 octets that MUST be set to 0 and ignored on receipt.
receipt.
Neighbor ID: 6 octets for IS-IS for the System-ID and 4 octets for Neighbor ID: 6 octets for IS-IS for the System-ID and 4 octets for
OSPF for the OSPF Router-ID of the neighbor. OSPF for the OSPF Router-ID of the neighbor.
SID/Index/Label: SID/Index/Label:
* IS-IS: Label or index value as defined in * IS-IS: Label or index value as defined in section 2.2.2 of
[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 section 6.2 of
[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 section 7.2 of
[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 are interpreted according to the respective fields of this TLV are interpreted according to the respective
underlying IS-IS, OSPFv2 or OSPFv3 protocol. The Protocol-ID of the underlying IS-IS, OSPFv2 or OSPFv3 protocol. The Protocol-ID of the
BGP-LS Link NLRI is used to determine the underlying protocol BGP-LS Link NLRI is used to determine the underlying protocol
specification for parsing these fields. specification for parsing these fields.
2.2.3. L2 Bundle Member Attribute TLV 2.2.3. L2 Bundle Member Attribute TLV
skipping to change at page 14, line 41 skipping to change at page 14, line 44
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
parent L3 Link. Multiple L2 Bundle Member Attribute TLVs MAY be parent L3 Link. Multiple L2 Bundle Member Attribute TLVs MAY be
associated with a Link NLRI. associated with a Link NLRI.
This information is derived from L2 Bundle Member Attributes TLV of This information is derived from L2 Bundle Member Attributes TLV of
IS-IS [I-D.ietf-isis-l2bundles]. The equivalent functionality has IS-IS (section 2 of [I-D.ietf-isis-l2bundles]). The equivalent
not been specified as yet for OSPF. functionality has not been specified as yet for OSPF.
The L2 Bundle Member Attribute TLV has the following format: The L2 Bundle Member Attribute 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| L2 Bundle Member Descriptor | | L2 Bundle Member Descriptor |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 17, line 9 skipping to change at page 17, line 9
Table 4: Prefix Attribute TLVs Table 4: Prefix Attribute TLVs
These TLVs should only be added to the BGP-LS Attribute associated These TLVs should only be added to the BGP-LS Attribute associated
with the Prefix NLRI describing the prefix of the IGP node that is with the Prefix NLRI describing the prefix of the IGP node that is
originating the corresponding IGP TLV/sub-TLV described below. originating the corresponding IGP TLV/sub-TLV described below.
2.3.1. Prefix SID TLV 2.3.1. Prefix SID TLV
The Prefix SID TLV is used in order to advertise information related The Prefix SID TLV is used in order to advertise information related
to a Prefix SID. This information is derived from Prefix-SID sub-TLV to a Prefix SID. This information is derived from Prefix-SID sub-TLV
of IS-IS [I-D.ietf-isis-segment-routing-extensions] and the Prefix of IS-IS (section 2.1 of [I-D.ietf-isis-segment-routing-extensions])
SID sub-TLV of OSPFv2 [I-D.ietf-ospf-segment-routing-extensions] and and the Prefix SID sub-TLV of OSPFv2 (section 5 of
OSPFv3 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [I-D.ietf-ospf-segment-routing-extensions]) and OSPFv3 (section 6 of
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]).
The Prefix SID TLV has the following format: The Prefix SID TLV has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Algorithm | Reserved | | Flags | Algorithm | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 17, line 36 skipping to change at page 17, line 37
Where: Where:
Type: 1158 Type: 1158
Length: Variable. 7 or 8 depending on Label or Index encoding of Length: Variable. 7 or 8 depending on Label or Index encoding of
the SID the SID
Flags: 1 octet value which should be set as: Flags: 1 octet value which should be set as:
* IS-IS Prefix SID flags are defined in * IS-IS Prefix SID flags are defined in section 2.1.1 of
[I-D.ietf-isis-segment-routing-extensions]. [I-D.ietf-isis-segment-routing-extensions].
* OSPFv2 Prefix SID flags are defined in * OSPFv2 Prefix SID flags are defined in section 5 of
[I-D.ietf-ospf-segment-routing-extensions]. [I-D.ietf-ospf-segment-routing-extensions].
* OSPFv3 Prefix SID flags are defined in * OSPFv3 Prefix SID flags are defined in section 6 of
[I-D.ietf-ospf-segment-routing-extensions]. [I-D.ietf-ospf-segment-routing-extensions].
Algorithm: 1 octet value identify the algorithm. Algorithm: 1 octet value identify the algorithm. The semantics of
algorithm are described in section 3.1.1 of [RFC8402].
Reserved: 2 octets that SHOULD be set to 0 and MUST be ignored on Reserved: 2 octets that MUST be set to 0 and ignored on receipt.
receipt.
SID/Index/Label: SID/Index/Label:
* IS-IS: Label or index value as defined in * IS-IS: Label or index value as defined in section 2.1 of
[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 section 5 of
[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 section 6 of
[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 are interpreted according to the respective underlying IS-IS, TLV are interpreted according to the respective underlying IS-IS,
OSPFv2 or OSPFv3 protocol. The Protocol-ID of the BGP-LS Prefix NLRI OSPFv2 or OSPFv3 protocol. The Protocol-ID of the BGP-LS Prefix NLRI
is used to determine the underlying protocol specification for is used to determine the underlying protocol specification for
parsing these fields. parsing 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 section 2.1
for OSPFv3 in [RFC5340] and for IS-IS in [RFC7794]. of [RFC7684], for OSPFv3 in section A.4.1.1 of [RFC5340] and for IS-
IS in section 2.1 of [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
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 (variable) // | Flags (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 18, line 49 skipping to change at page 18, line 50
Type: 1170 Type: 1170
Length: Variable. Length: Variable.
Flags: a variable length flag field (according to the length Flags: a variable length flag field (according to the length
field). Flags are routing protocol specific and are to be set as field). Flags are routing protocol specific and are to be set as
below: below:
* 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 section 2.1 of [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 section 2.1 of [RFC7684]
* OSPFv3 flags map to the Prefix Options field defined in * OSPFv3 flags map to the Prefix Options field defined in section
[RFC5340] and extended via [RFC8362] A.4.1.1 of [RFC5340] and extended in section 3.1 of [RFC8362]
The Flags field of this TLV is interpreted according to the The Flags field of this TLV is interpreted according to the
respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. The respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. The
Protocol-ID of the BGP-LS Prefix NLRI is used to determine the Protocol-ID of the BGP-LS Prefix NLRI is used to determine the
underlying protocol specification for parsing this field. underlying protocol specification for parsing 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 the IS-IS protocol this is derived originator of the Prefix. For the IS-IS protocol this is derived
from the IPv4/IPv6 Source Router ID sub-TLV as defined in [RFC7794]. from the IPv4/IPv6 Source Router ID sub-TLV as defined in section 2.2
For the OSPF protocol, this is derived from the Prefix Source Router- of [RFC7794]. For the OSPF protocol, this is derived from the Prefix
ID sub-TLV as defined in [I-D.ietf-lsr-ospf-prefix-originator]. Source Router-ID sub-TLV as defined in section 4 of
[I-D.ietf-lsr-ospf-prefix-originator].
The Source Router-ID TLV has the following format: The Source Router-ID 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 or 6 octet Router-ID // | 4 or 16 octet Router-ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Source Router-ID TLV Format Figure 12: Source Router-ID TLV Format
Where: Where:
Type: 1171 Type: 1171
Length: Variable. 4 or 16 in case of IS-IS and 4 in case of OSPF. Length: Variable. 4 or 16 in case of IS-IS and 4 in case of OSPF.
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-ospfv3-segment-routing-extensions] and [I-D.ietf-ospf-segment-routing-extensions] (section 4),
[I-D.ietf-isis-segment-routing-extensions]. The information [I-D.ietf-ospf-ospfv3-segment-routing-extensions] (section 5) and
advertised in the Range TLV is derived from the SID/Label Binding TLV [I-D.ietf-isis-segment-routing-extensions] (section 2.4). The
in the case of IS-IS and the OSPFv2/OSPFv3 Extended Prefix Range TLV information advertised in the Range TLV is derived from the SID/Label
in the case of OSPFv2/OSPFv3. Binding TLV in the case of IS-IS and the OSPFv2/OSPFv3 Extended
Prefix Range TLV in the case of OSPFv2/OSPFv3.
A Prefix NLRI, that been advertised with a Range TLV, is considered a A Prefix NLRI, that been advertised with a Range TLV, is considered a
normal routing prefix (i.e. prefix reachability) only when there is normal routing prefix (i.e. prefix reachability) only when there is
also an IGP metric TLV (TLV 1095) associated it. Otherwise, it is also an IGP metric TLV (TLV 1095) associated it. Otherwise, it is
considered only as the first prefix in the range for prefix-to-SID considered only as the first prefix in the range for prefix-to-SID
mapping advertisement. mapping advertisement.
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
skipping to change at page 20, line 40 skipping to change at page 20, line 41
Where: Where:
Type: 1159 Type: 1159
Length: Variable. 11 or 12 depending on Label or Index encoding of Length: Variable. 11 or 12 depending on Label or Index encoding of
the SID the SID
Flags: 1 octet value which should be set as: Flags: 1 octet value which should be set as:
* IS-IS SID/Label Binding TLV flags are defined in * IS-IS SID/Label Binding TLV flags are defined in section 2.4.1
[I-D.ietf-isis-segment-routing-extensions]. of [I-D.ietf-isis-segment-routing-extensions].
* OSPFv2 OSPF Extended Prefix Range TLV flags are defined in * OSPFv2 OSPF Extended Prefix Range TLV flags are defined in
[I-D.ietf-ospf-segment-routing-extensions]. section 4 of [I-D.ietf-ospf-segment-routing-extensions].
* OSPFv3 Extended Prefix Range TLV flags are defined in * OSPFv3 Extended Prefix Range TLV flags are defined in section 5
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]. of [I-D.ietf-ospf-ospfv3-segment-routing-extensions].
Reserved: 1 octet that SHOULD be set to 0 and MUST be ignored on Reserved: 1 octet that MUST be set to 0 and ignored on receipt.
receipt.
Range Size: 2 octets as defined in Range Size: 2 octets that carry the number of prefixes that are
[I-D.ietf-ospf-segment-routing-extensions]. covered by the advertisement..
The Flags field of this TLV is interpreted according to the The Flags field of this TLV is interpreted according to the
respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. The respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. The
Protocol-ID of the BGP-LS Prefix NLRI is used to determine the Protocol-ID of the BGP-LS Prefix NLRI is used to determine the
underlying protocol specification for parsing this field. underlying protocol specification for parsing this field.
The prefix-to-SID mappings are advertised using sub-TLVs as below: The prefix-to-SID mappings are advertised using sub-TLVs as below:
IS-IS: IS-IS:
SID/Label Range TLV SID/Label Range TLV
skipping to change at page 26, line 39 skipping to change at page 26, line 39
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 is distributed via [RFC7752]. existing IGP topology information that is distributed via [RFC7752].
The Security Considerations section of [RFC7752] also applies to The advertisement of the SR link attribute information defined in
these extensions. The procedures and new TLVs defined in this this document presents similar risk as associated with the existing
document, by themselves, do not affect the BGP-LS security model set of link attribute information as described in [RFC7752]. The
discussed in [RFC7752]. Security Considerations section of [RFC7752] also applies to these
extensions. The procedures and new TLVs defined in this document, by
themselves, do not affect the BGP-LS security model discussed in
[RFC7752].
The TLVs introduced in this document are used to propagate IGP The TLVs introduced in this document are used to propagate IGP
defined information ([I-D.ietf-isis-segment-routing-extensions], defined information ([I-D.ietf-isis-segment-routing-extensions],
[I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-segment-routing-extensions] and
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]). These TLVs [I-D.ietf-ospf-ospfv3-segment-routing-extensions]). These TLVs
represent the SR information associated with the IGP node, link and represent the SR information associated with the IGP node, link and
prefix. The IGP instances originating these TLVs are assumed to prefix. The IGP instances originating these TLVs are assumed to
support all the required security and authentication mechanisms (as support all the required security and authentication mechanisms (as
described in [I-D.ietf-isis-segment-routing-extensions], described in [I-D.ietf-isis-segment-routing-extensions],
[I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-segment-routing-extensions] and
skipping to change at page 27, line 4 skipping to change at page 27, line 7
The TLVs introduced in this document are used to propagate IGP The TLVs introduced in this document are used to propagate IGP
defined information ([I-D.ietf-isis-segment-routing-extensions], defined information ([I-D.ietf-isis-segment-routing-extensions],
[I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-segment-routing-extensions] and
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]). These TLVs [I-D.ietf-ospf-ospfv3-segment-routing-extensions]). These TLVs
represent the SR information associated with the IGP node, link and represent the SR information associated with the IGP node, link and
prefix. The IGP instances originating these TLVs are assumed to prefix. The IGP instances originating these TLVs are assumed to
support all the required security and authentication mechanisms (as support all the required security and authentication mechanisms (as
described in [I-D.ietf-isis-segment-routing-extensions], described in [I-D.ietf-isis-segment-routing-extensions],
[I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-segment-routing-extensions] and
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]) in order to [I-D.ietf-ospf-ospfv3-segment-routing-extensions]) in order to
prevent any security issue when propagating the TLVs into BGP-LS. 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 Segment Routing domain. SR operates within a trusted domain
[RFC8402] and its security considerations also apply to BGP-LS [RFC8402] and its security considerations also apply to BGP-LS
sessions when carrying SR information. The SR traffic engineering sessions when carrying SR information. The SR traffic engineering
policies using the SIDs advertised via BGP-LS are expected to be used policies using the SIDs advertised via BGP-LS are expected to be used
entirely within this trusted SR domain (e.g. between multiple AS/ entirely within this trusted SR domain (e.g. between multiple AS/
domains within a single provider network). Therefore, precaution is domains within a single provider network). Therefore, precaution is
necessary to ensure that the SR information advertised via BGP-LS necessary to ensure that the link-state information (including SR
sessions is limited to consumers in a secure manner within this information) advertised via BGP-LS sessions is limited to consumers
trusted SR domain. BGP peering sessions for address-families other in a secure manner within this trusted SR domain. BGP peering
than Link-State may be setup to routers outside the SR domain. The sessions for address-families other than Link-State may be setup to
isolation of BGP-LS peering sessions is recommended to ensure that routers outside the SR domain. The isolation of BGP-LS peering
BGP-LS topology information (including the newly added SR sessions is recommended to ensure that BGP-LS topology information
information) is not advertised to an external BGP peering session (including the newly added SR information) is not advertised to an
outside the SR domain. external BGP peering session outside the SR 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:
Peter Psenak Peter Psenak
Cisco Systems Cisco Systems
Email: ppsenak@cisco.com Email: ppsenak@cisco.com
 End of changes. 84 change blocks. 
142 lines changed or deleted 146 lines changed or added

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