draft-ietf-idr-bgp-ls-segment-routing-ext-11.txt   draft-ietf-idr-bgp-ls-segment-routing-ext-12.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 Intended status: Standards Track K. Talaulikar, Ed.
Expires: April 25, 2019 C. Filsfils Expires: September 9, 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
October 22, 2018 March 8, 2019
BGP Link-State extensions for Segment Routing BGP Link-State extensions for Segment Routing
draft-ietf-idr-bgp-ls-segment-routing-ext-11 draft-ietf-idr-bgp-ls-segment-routing-ext-12
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
order to carry segment routing information via BGP. order to carry segment routing information via BGP.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 9, 2019.
This Internet-Draft will expire on April 25, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
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 . . . . . . . . . . . . 5 2. BGP-LS Extensions for Segment Routing . . . . . . . . . . . . 4
2.1. Node Attributes TLVs . . . . . . . . . . . . . . . . . . 5 2.1. Node Attributes TLVs . . . . . . . . . . . . . . . . . . 5
2.1.1. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . 6 2.1.1. SID/Label Sub-TLV . . . . . . . . . . . . . . . . . . 5
2.1.2. SR-Capabilities TLV . . . . . . . . . . . . . . . . . 7 2.1.2. SR Capabilities TLV . . . . . . . . . . . . . . . . . 6
2.1.3. SR-Algorithm TLV . . . . . . . . . . . . . . . . . . 8 2.1.3. SR Algorithm TLV . . . . . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . 13 2.2.3. L2 Bundle Member Attribute TLV . . . . . . . . . . . 14
2.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . . . 14 2.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . . . 15
2.3.1. Prefix-SID TLV . . . . . . . . . . . . . . . . . . . 15 2.3.1. Prefix SID TLV . . . . . . . . . . . . . . . . . . . 16
2.3.2. Prefix Attribute Flags TLV . . . . . . . . . . . . . 16 2.3.2. Prefix Attribute Flags TLV . . . . . . . . . . . . . 17
2.3.3. Source Router Identifier (Source Router-ID) TLV . . . 17 2.3.3. Source Router Identifier (Source Router-ID) TLV . . . 18
2.3.4. Range TLV . . . . . . . . . . . . . . . . . . . . . . 17 2.3.4. Range TLV . . . . . . . . . . . . . . . . . . . . . . 19
2.4. Equivalent IS-IS Segment Routing TLVs/Sub-TLVs . . . . . 19 2.4. Equivalent IS-IS Segment Routing TLVs/Sub-TLVs . . . . . 21
2.5. Equivalent OSPFv2/OSPFv3 Segment Routing TLVs/Sub-TLVs . 20 2.5. Equivalent OSPFv2/OSPFv3 Segment Routing TLVs/Sub-TLVs . 21
3. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 3.1. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . 23
4.1. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . 21 4. Manageability Considerations . . . . . . . . . . . . . . . . 24
5. Manageability Considerations . . . . . . . . . . . . . . . . 22 5. Security Considerations . . . . . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 8.1. Normative References . . . . . . . . . . . . . . . . . . 26
9.1. Normative References . . . . . . . . . . . . . . . . . . 24 8.2. Informative References . . . . . . . . . . . . . . . . . 28
9.2. Informative References . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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
topological sub-paths, called "IGP segments". These segments are 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).
Two types of IGP segments are defined, Prefix segments and Adjacency [RFC8402] defines the Link-State IGP segments - Prefix, Node, Anycast
segments. Prefix segments, by default, represent an ECMP-aware and Adjacency segments. Prefix segments, by default, represent an
shortest-path to a prefix, as per the state of the IGP topology. ECMP-aware shortest-path to a prefix, as per the state of the IGP
Adjacency segments represent a hop over a specific adjacency between topology. Adjacency segments represent a hop over a specific
two nodes in the IGP. A prefix segment is typically a multi-hop path adjacency between two nodes in the IGP. A prefix segment is
while an adjacency segment, in most of the cases, is a one-hop path. typically a multi-hop path while an adjacency segment, in most of the
[RFC8402]. cases, is a one-hop path. Node and Anycast Segments are variations
of the Prefix Segment with their specific characteristics.
When Segment Routing is enabled in a 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 in: IS-IS
[I-D.ietf-isis-segment-routing-extensions], OSPFv2 [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
paths. The flooding scope for the IGP extensions for Segment routing
is IGP area-wide. Consequently, the contents of a Link State
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
to construct segments across multiple IGP Area or AS boundaries.
In order to address the need for applications that require
topological visibility across IGP areas, or even across Autonomous
Systems (AS), the BGP-LS address-family/sub-address-family have been
defined to allow BGP to carry Link-State information. The BGP
Network Layer Reachability Information (NLRI) encoding format for
BGP-LS and a new BGP Path Attribute called the BGP-LS attribute are
defined in [RFC7752]. The identifying key of each Link-State object,
namely a node, link, or prefix, is encoded in the NLRI and the
properties of the object are encoded in the BGP-LS attribute.
+------------+ +------------+
| Consumer | | Consumer |
+------------+ +------------+
^ ^
| |
v v
+-------------------+ +-------------------+
| BGP Speaker | +-----------+ | BGP Speaker | +-----------+
| (Route-Reflector) | | Consumer | | (Route-Reflector) | | Consumer |
+-------------------+ +-----------+ +-------------------+ +-----------+
skipping to change at page 4, line 30 skipping to change at page 4, line 30
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
| BGP | | BGP | | BGP | | BGP | | BGP | | BGP |
| Speaker | | Speaker | . . . | Speaker | | Speaker | | Speaker | . . . | Speaker |
+-----------+ +-----------+ +-----------+ +-----------+ +-----------+ +-----------+
^ ^ ^ ^ ^ ^
| | | | | |
IGP IGP IGP IGP IGP IGP
Figure 1: Link State info collection Figure 1: Link State info collection
Segment Routing (SR) allows advertisement of single or multi-hop
paths. The flooding scope for the IGP extensions for Segment routing
is IGP area-wide. Consequently, the contents of a Link State
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
to construct segments across multiple IGP Area or AS boundaries.
In order to address the need for applications that require
topological visibility across IGP areas, or even across Autonomous
Systems (AS), the BGP-LS address-family/sub-address-family have been
defined to allow BGP to carry Link-State information. The BGP
Network Layer Reachability Information (NLRI) encoding format for
BGP-LS and a new BGP Path Attribute called the BGP-LS attribute are
defined in [RFC7752]. The identifying key of each Link-State object,
namely a node, link, or prefix, is encoded in the NLRI and the
properties of the object are encoded in the BGP-LS attribute.
Figure 1 describes a typical deployment scenario. In each IGP area, Figure 1 describes a typical deployment scenario. In each IGP area,
one or more nodes are configured with BGP-LS. These BGP speakers one or more nodes are configured with BGP-LS. These BGP speakers
form an IBGP mesh by connecting to one or more route-reflectors. form an IBGP mesh by connecting to one or more route-reflectors.
This way, all BGP speakers (specifically the route-reflectors) obtain This way, all BGP speakers (specifically the route-reflectors) obtain
Link-State information from all IGP areas (and from other ASes from Link-State information from all IGP areas (and from other ASes from
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). what information is or isn't advertised to the external component) as
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) then can information. An external component (e.g., a controller) then can
collect SR information from across an SR domain and construct the collect SR information from across an SR domain (as described in
end-to-end path (with its associated SIDs) that need to be applied to [RFC8402]) and construct the end-to-end path (with its associated
an incoming packet to achieve the desired end-to-end forwarding. SIDs) that need to be applied to an incoming packet to achieve the
Here the SR domain is defined as a single administrative domain that desired end-to-end forwarding. The SR domain may be comprised of a
may be comprised of a single AS or multiple ASes under consolidated single AS or multiple ASes.
global SID administration.
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 illustrates the equivalent Attribute. Section 2.4 and Section 2.5 lists the equivalent TLVs and
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
map link-state information to BGP-LS NLRI within the BGP-LS map link-state information to BGP-LS NLRI within the BGP-LS
Attribute. This document adds additional BGP-LS Attribute TLVs in Attribute. This document adds additional BGP-LS Attribute TLVs in
order to encode SR information. It does not introduce any changes to order to encode SR information. It does not introduce any changes to
the encoding of the BGP-LS NLRIs. the encoding of the BGP-LS NLRIs.
Some of the TLVs defined in this document contain fields (e.g. flags)
whose semantics need to be interpreted accordingly to the respective
underlying IS-IS, OSPFv2 or OSPFv3 protocol. The receiver of the
BGP-LS update for any of the NLRIs MUST check the Protocol-ID of the
NLRI and refer to the underlying protocol specification in order to
parse such fields. The individual field descriptions in the sub-
sections below point to the relevant underlying protocol
specifications for such fields.
2.1. Node Attributes TLVs 2.1. Node Attributes TLVs
The following Node Attribute TLVs are defined: The following Node Attribute TLVs are defined:
+-----------------+----------+---------------+ +------+-----------------+---------------+
| Description | Length | Section | | Type | Description | Section |
+-----------------+----------+---------------+ +------+-----------------+---------------+
| SID/Label | variable | Section 2.1.1 | | 1161 | SID/Label | Section 2.1.1 |
| SR Capabilities | variable | Section 2.1.2 | | 1034 | SR Capabilities | Section 2.1.2 |
| SR Algorithm | variable | Section 2.1.3 | | 1035 | SR Algorithm | Section 2.1.3 |
| SR Local Block | variable | Section 2.1.4 | | 1036 | SR Local Block | Section 2.1.4 |
| SRMS Preference | variable | Section 2.1.5 | | 1037 | SRMS Preference | Section 2.1.5 |
+-----------------+----------+---------------+ +------+-----------------+---------------+
Table 1: Node Attribute TLVs Table 1: Node Attribute TLVs
These TLVs can ONLY be added to the BGP-LS Attribute associated with These TLVs should only be added to the BGP-LS Attribute associated
the Node NLRI that originates the corresponding underlying IGP TLV/ with the Node NLRI describing the IGP node that is originating the
sub-TLV described below. corresponding IGP TLV/sub-TLV described below.
2.1.1. SID/Label Sub-TLV 2.1.1. SID/Label Sub-TLV
The SID/Label TLV is used as 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 SRLB (Section 2.1.4) TLVs and has the following (Section 2.1.2) and Segment Routing Local Block (SRLB)
format: (Section 2.1.4) TLVs and 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: Figure 2: SID/Label sub-TLV Format
Type: TBD, see Section 4. Where:
Length: Variable, 3 or 4. Type: 1161
Length: Either 3 or 4 depending whether the value is encoded as a
label or 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). If length is set to represent a label (the total TLV size is 7). If length is set to
4, then the value represents a 32 bit SID (the total TLV size is 4, then the value represents a 32 bit SID (the total TLV size is
8). 8).
The receiving router MUST ignore the SID/Label sub-TLV if the 2.1.2. SR Capabilities TLV
length is other then 3 or 4.
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 SR-MPLS forwarding plane. This information IPv4 and IPv6 support for the SR-MPLS forwarding plane. This
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
[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
[I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-segment-routing-extensions] and
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [I-D.ietf-ospf-ospfv3-segment-routing-extensions].
The SR Capabilities TLV has 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 | | Range Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SID/Label sub-TLV (variable) // // SID/Label sub-TLV (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD, see Section 4. Figure 3: SR Capabilities TLV Format
Length: Variable. Where:
Type: 1034
Length: Variable. Minimum length is 12.
Flags: 1 octet of flags as defined in Flags: 1 octet of flags as defined in
[I-D.ietf-isis-segment-routing-extensions]. [I-D.ietf-isis-segment-routing-extensions] for IS-IS. The flags
are not currently defined for OSPFv2 and OSPFv3 and SHOULD be set
to 0 and MUST be ignored on receipt.
Reserved: 1 octet that SHOULD be set to 0 and MUST be ignored on Reserved: 1 octet that SHOULD be set to 0 and MUST be 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 value indicating the number of labels in Range Size: 3 octet with a non-zero value indicating the number
the range. of labels in the range.
SID/Label sub-TLV (as defined in Section 2.1.1) which encodes SID/Label sub-TLV (as defined in Section 2.1.1) which encodes
the first label in the range. the first label in the range. Since the SID/Label sub-TLV is
used to indicate the first label of the SRGB 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
[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
[I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-segment-routing-extensions] and
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [I-D.ietf-ospf-ospfv3-segment-routing-extensions].
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 | |
+- -+ +- -+
| | | |
+ + + +
where: Figure 4: SR Algorithm TLV Format
Type: TBD, see Section 4. Where:
Length: Variable. Type: 1035
Length: Variable. Minimum length is 1 and maximum can be 256.
Algorithm: 1 octet identifying the algorithm. Algorithm: 1 octet identifying the algorithm.
2.1.4. SR Local Block TLV 2.1.4. SR Local Block TLV
The SR Local Block (SRLB) TLV contains the range(s) of labels the The SR Local Block (SRLB) TLV contains the range(s) of labels the
node has reserved for local SIDs. Local SIDs are used, e.g., in IGP node has reserved for local SIDs. Local SIDs are used, e.g., in IGP
(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.
skipping to change at page 9, line 28 skipping to change at page 8, line 50
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | | Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Range Size | | Range Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// SID/Label sub-TLV (variable) // // SID/Label sub-TLV (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD, see Section 4. Figure 5: SRLB TLV Format
Length: Variable. Where:
Type: 1036
Length: Variable. Minimum length is 12.
Flags: 1 octet of flags. None are defined at this stage. Flags: 1 octet of flags. None are defined at this stage.
Reserved: 1 octet that SHOULD be set to 0 and MUST be ignored on Reserved: 1 octet that SHOULD be set to 0 and MUST be 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 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 sub-TLV (as defined in Section 2.1.1) which encodes
the first label in the range. the first label in the range. Since the SID/Label sub-TLV is
used to indicate the first label of the SRLB 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
[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
[I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-segment-routing-extensions] and
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [I-D.ietf-ospf-ospfv3-segment-routing-extensions].
The SRMS Preference TLV has 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 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type: TBD, see Section 4. Figure 6: SRMS Preference TLV Format
Where:
Type: 1037
Length: 1. Length: 1.
Preference: 1 octet. Unsigned 8 bit SRMS preference. Preference: 1 octet. Unsigned 8 bit SRMS preference.
The use of the SRMS Preference TLV is defined in The use of the SRMS Preference TLV is defined in
[I-D.ietf-isis-segment-routing-extensions], [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]. [I-D.ietf-ospf-ospfv3-segment-routing-extensions].
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:
+----------------------------------------+----------+---------------+ +------+-----------------------+---------------+
| Description | Length | Section | | Type | Description | Section |
+----------------------------------------+----------+---------------+ +------+-----------------------+---------------+
| Adjacency Segment Identifier (Adj-SID) | variable | Section 2.2.1 | | 1099 | Adjacency SID TLV | Section 2.2.1 |
| TLV | | | | 1100 | LAN Adjacency SID TLV | Section 2.2.2 |
| LAN Adjacency Segment Identifier (Adj- | variable | Section 2.2.2 | | 1172 | L2 Bundle Member TLV | Section 2.2.3 |
| SID) TLV | | | +------+-----------------------+---------------+
| L2 Bundle Member TLV | variable | Section 2.2.3 |
+----------------------------------------+----------+---------------+
Table 2: Link Attribute TLVs Table 2: Link Attribute TLVs
These TLVs can ONLY be added to the BGP-LS Attribute associated with These TLVs should only be added to the BGP-LS Attribute associated
the Link NLRI whose local node originates the corresponding with the Link NLRI describing the link of the IGP node that is
underlying IGP TLV/sub-TLV described below. originating the corresponding IGP TLV/sub-TLV described below.
For a LAN, normally a node only announces its adjacency to the IS-IS
pseudo-node (or the equivalent OSPF Designated and Backup Designated
Routers)[I-D.ietf-isis-segment-routing-extensions]. The LAN
Adjacency Segment TLV allows a node to announce adjacencies to all
other nodes attached to the LAN in a single instance of the BGP-LS
Link NLRI. Without this TLV, the corresponding BGP-LS link NLRI
would need to be originated for each additional adjacency in order to
advertise the SR TLVs for these neighbor adjacencies.
2.2.1. Adjacency SID TLV 2.2.1. Adjacency SID TLV
The Adjacency SID (Adj-SID) TLV has the following format: The Adjacency SID TLV is used in order to advertise information
related to an Adjacency SID. This information is originated as in
Adj-SID sub-TLV of IS-IS [I-D.ietf-isis-segment-routing-extensions],
OSPFv2 [I-D.ietf-ospf-segment-routing-extensions] and OSPFv3
[I-D.ietf-ospf-ospfv3-segment-routing-extensions].
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) | | SID/Label/Index (variable) |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
where: Figure 7: Adjacency SID TLV Format
Type: TBD, see Section 4. Where:
Type: 1099
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 field of following flags as defined in Flags. 1 octet value which sould be parsed as:
[I-D.ietf-isis-segment-routing-extensions],
[I-D.ietf-ospf-segment-routing-extensions] and * IS-IS Adj-SID flags are defined in
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [I-D.ietf-isis-segment-routing-extensions] section 2.2.1.
* OSPFv2 Adj-SID flags are defined in
[I-D.ietf-ospf-segment-routing-extensions] section 6.1.
* OSPFv3 Adj-SID flags are defined in
[I-D.ietf-ospf-segment-routing-extensions] section 7.1.
Weight: Weight used for load-balancing purposes. Weight: Weight used for load-balancing purposes.
Reserved: 2 octets that SHOULD be set to 0 and MUST be ignored on Reserved: 2 octets that SHOULD be set to 0 and MUST be ignored on
receipt. receipt.
SID/Index/Label: Label or index value depending on the flags SID/Index/Label:
setting as defined in [I-D.ietf-isis-segment-routing-extensions],
[I-D.ietf-ospf-segment-routing-extensions] and * IS-IS: Label or index value as defined in
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [I-D.ietf-isis-segment-routing-extensions],
* OSPFv2: Label or index value as defined in
[I-D.ietf-ospf-segment-routing-extensions],
* OSPFv3: Label or index value as defined in
[I-D.ietf-ospf-ospfv3-segment-routing-extensions],
The Flags and, as an extension, the SID/Index/Label fields of this
TLV need to be interpreted accordingly to the respective underlying
IS-IS, OSPFv2 or OSPFv3 protocol. The consumer of the BGP-LS
interested in this TLV information MUST check the Protocol-ID of the
BGP-LS Link NLRI and refer to the underlying protocol specification
in order to parse these fields.
2.2.2. LAN Adjacency SID TLV 2.2.2. LAN Adjacency SID TLV
The LAN Adjacency SID (LAN-Adj-SID-SID) TLV has the following format: For a LAN, normally a node only announces its adjacency to the IS-IS
pseudo-node (or the equivalent OSPF Designated and Backup Designated
Routers). The LAN Adjacency Segment TLV allows a node to announce
adjacencies to all other nodes attached to the LAN in a single
instance of the BGP-LS Link NLRI. Without this TLV, the
corresponding BGP-LS link NLRI would need to be originated for each
additional adjacency in order to advertise the SR TLVs for these
neighbor adjacencies.
This information is originated as in LAN Adj-SID sub-TLV of IS-IS
[I-D.ietf-isis-segment-routing-extensions], OSPFv2
[I-D.ietf-ospf-segment-routing-extensions] and OSPFv3
[I-D.ietf-ospf-ospfv3-segment-routing-extensions].
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Neighbor ID / IS-IS System-ID | | OSPF Neighbor ID / IS-IS System-ID |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Label/Index (variable) | | SID/Label/Index (variable) |
+---------------------------------------------------------------+ +---------------------------------------------------------------+
where: Figure 8: LAN Adjacency SID TLV Format
Type: TBD, see Section 4. Where:
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 field of following flags as defined in Flags. 1 octet value which sould be parsed as:
[I-D.ietf-isis-segment-routing-extensions],
[I-D.ietf-ospf-segment-routing-extensions] and * IS-IS LAN Adj-SID flags are defined in
[I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [I-D.ietf-isis-segment-routing-extensions] section 2.2.2.
* OSPFv2 LAN Adj-SID flags are defined in
[I-D.ietf-ospf-segment-routing-extensions] section 6.2.
* OSPFv3 LAN Adj-SID flags are defined in
[I-D.ietf-ospf-segment-routing-extensions] section 7.3.
Weight: Weight used for load-balancing purposes. Weight: Weight used for load-balancing purposes.
Reserved: 2 octets that SHOULD be set to 0 and MUST be ignored on Reserved: 2 octets that SHOULD be set to 0 and MUST be ignored on
receipt. receipt.
SID/Index/Label: Label or index value depending on the flags Neighbor ID: 6 octets for IS-IS for the System-ID and 4 octets for
setting as defined in [I-D.ietf-isis-segment-routing-extensions], OSPF for the OSPF Router-ID of the neighbor.
[I-D.ietf-ospf-segment-routing-extensions] and
[I-D.ietf-ospf-ospfv3-segment-routing-extensions].
2.2.3. L2 Bundle Member SID/Index/Label:
* IS-IS: Label or index value as defined in
[I-D.ietf-isis-segment-routing-extensions],
* OSPFv2: Label or index value as defined in
[I-D.ietf-ospf-segment-routing-extensions],
* OSPFv3: Label or index value as defined in
[I-D.ietf-ospf-ospfv3-segment-routing-extensions],
The Neighbor ID, Flags and, as an extension, the SID/Index/Label
fields of this TLV need to be interpreted accordingly to the
respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. The consumer
of the BGP-LS interested in this TLV information MUST check the
Protocol-ID of the BGP-LS Link NLRI and refer to the underlying
protocol specification in order to parse these fields.
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
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 originated as in L2 Bundle Member Attributes TLV
of IS-IS [I-D.ietf-isis-l2bundles]. The equivalent 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Link attribute sub-TLVs(variable) // // Link attribute sub-TLVs(variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: Figure 9: L2 Bundle Member Attributes TLV Format
Type: TBD, see Section 4. Where:
Type: 1172
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 L2Bundle 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 Document |
| Point | | | | Point | | |
+-----------+----------------------------+--------------------------+ +-----------+----------------------------+--------------------------+
| 1088 | Administrative group | [RFC7752] | | 1088 | Administrative group | [RFC7752] |
| | (color) | | | | (color) | |
| 1089 | Maximum link bandwidth | [RFC7752] | | 1089 | Maximum link bandwidth | [RFC7752] |
| 1090 | Max. reservable link | [RFC7752] | | 1090 | Max. reservable link | [RFC7752] |
skipping to change at page 14, line 42 skipping to change at page 15, line 42
| | utilization | | | | 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:
+------------------------+----------+---------------+ +------+------------------------+---------------+
| Description | Length | Section | | Type | Description | Section |
+------------------------+----------+---------------+ +------+------------------------+---------------+
| Prefix SID | variable | Section 2.3.1 | | 1158 | Prefix SID | Section 2.3.1 |
| Range | variable | Section 2.3.4 | | 1159 | Range | Section 2.3.4 |
| Prefix Attribute Flags | variable | Section 2.3.2 | | 1170 | Prefix Attribute Flags | Section 2.3.2 |
| Source Router-ID | variable | Section 2.3.3 | | 1171 | Source Router-ID | Section 2.3.3 |
+------------------------+----------+---------------+ +------+------------------------+---------------+
Table 4: Prefix Attribute TLVs Table 4: Prefix Attribute TLVs
These TLVs can ONLY be added to the BGP-LS Attribute associated with These TLVs should only be added to the BGP-LS Attribute associated
the Prefix NLRI whose local node originates the corresponding with the Prefix NLRI describing the prefix of the IGP node that is
underlying IGP TLV/sub-TLV described below. originating the corresponding IGP TLV/sub-TLV described below.
2.3.1. Prefix-SID TLV
The Prefix-SID TLV is used in order to advertise information related
to a Prefix-SID. This information is originated in:
o IS-IS, as defined by the Prefix-SID TLV in 2.3.1. Prefix SID TLV
[I-D.ietf-isis-segment-routing-extensions].
o OSPFv2 and OSPFv3, as defined by the Prefix-SID TLV in The Prefix SID TLV is used in order to advertise information related
[I-D.ietf-ospf-segment-routing-extensions] and to a Prefix SID. This information is originated as in Prefix-SID
[I-D.ietf-ospf-ospfv3-segment-routing-extensions] respectively. sub-TLV of IS-IS [I-D.ietf-isis-segment-routing-extensions], OSPFv2
[I-D.ietf-ospf-segment-routing-extensions] and OSPFv3
[I-D.ietf-ospf-ospfv3-segment-routing-extensions].
The Prefix-SID 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SID/Index/Label (variable) | | SID/Index/Label (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: Figure 10: Prefix SID TLV Format
Type: TBD, see Section 4. Where:
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 sould be parsed as: Flags: 1 octet value which sould be parsed as:
* IS-IS Prefix-SID flags are defined in * IS-IS Prefix SID flags are defined in
[I-D.ietf-isis-segment-routing-extensions] section 2.1. [I-D.ietf-isis-segment-routing-extensions] section 2.1.
* OSPFv2 Prefix-SID flags are defined in * OSPFv2 Prefix SID flags are defined in
[I-D.ietf-ospf-segment-routing-extensions] section 5. [I-D.ietf-ospf-segment-routing-extensions] section 5.
* OSPFv3 Prefix-SID flags are defined in * OSPFv3 Prefix SID flags are defined in
[I-D.ietf-ospf-segment-routing-extensions] section 5. [I-D.ietf-ospf-segment-routing-extensions] section 5.
Algorithm: 1 octet value identify the algorithm. Algorithm: 1 octet value identify the algorithm.
Reserved: 2 octets that SHOULD be set to 0 and MUST be ignored on Reserved: 2 octets that SHOULD be set to 0 and MUST be 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
[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
TLV need to be interpreted accordingly to the respective underlying
IS-IS, OSPFv2 or OSPFv3 protocol. The consumer of the BGP-LS
interested in this TLV information MUST check the Protocol-ID of the
BGP-LS Prefix NLRI and refer to the underlying protocol specification
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
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) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: Figure 11: Prefix Attribute Flags TLV Format
Type: TBD, see Section 4. Where:
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 parsed field). Flags are routing protocol specific and are to be parsed
as below: as below:
* IS-IS flags are defined in [RFC7794] * IS-IS flags correspond to the IPv4/IPv6 Extended Reachability
Attribute Flags defined in [RFC7794]
* OSPFv2 flags are defined in [RFC7684] * OSPFv2 flags correspond to the Flags field of the OSPFv2
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
[RFC7794] and extended via [RFC8362] [RFC5340] and extended via [RFC8362]
The Flags field of this TLV need to be interpreted accordingly to the
respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. The consumer
of the BGP-LS interested in this TLV information MUST check the
Protocol-ID of the BGP-LS Prefix NLRI and refer to the underlying
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]. The Source Router-ID TLV may be used to carry the OSPF [RFC7794] IPv4 or IPv6 Router-ID of the originating router. For OSPF
Router-ID of the 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..
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 6 octet Router-ID //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: Figure 12: Source Router-ID TLV Format
Type: TBD, see Section 4. Where:
Length: 4 or 16. Type: 1171
IPv4/IPv6 Address: 4 octet IPv4 address or 16 octet IPv6 address. Length: 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
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 functionality mappings as part of the Segment Routing Mapping Server (SRMS)
[I-D.ietf-spring-segment-routing-ldp-interop], as defined in the functionality [I-D.ietf-spring-segment-routing-ldp-interop], as
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]. The Prefix-NLRI to which [I-D.ietf-isis-segment-routing-extensions].
the Range TLV is attached MUST be advertised as a non-routing prefix
where no IGP metric TLV (TLV 1095) is attached. A consumer of the BGP-LS information MUST NOT mis-interpret a Prefix
NLRI, that been advertised with a Range TLV associated with it on
account of an SRMS prefix-to-SID mapping in the underlying IGP, as a
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// sub-TLVs // // sub-TLVs //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where: Figure 13: Range TLV Format
Figure 2: Range TLV format Where:
Type: TBD, see Section 4. Type: 1159
Length: variable Length: Variable, 11 or 12 depending on Label or Index encoding of
the SID
Flags: as defined in [I-D.ietf-ospf-segment-routing-extensions], Flags: as defined in [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].
Reserved: 1 octet that SHOULD be set to 0 and MUST be ignored on Reserved: 1 octet that SHOULD be set to 0 and MUST be ignored on
receipt. receipt.
Range Size: 2 octets as defined in Range Size: 2 octets as defined in
[I-D.ietf-ospf-segment-routing-extensions]. [I-D.ietf-ospf-segment-routing-extensions].
The Flags field of this TLV need to be interpreted accordingly to the
respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. The consumer
of the BGP-LS interested in this TLV information MUST check the
Protocol-ID of the BGP-LS Prefix NLRI and refer to the underlying
protocol specification in order to parse this field.
Within the Range TLV, the prefix-to-SID mappings are advertised using Within the Range TLV, the prefix-to-SID mappings are advertised using
sub-TLVs as below: sub-TLVs as below:
Range TLV Range TLV
Prefix-SID TLV (used as a sub-TLV in this context) Prefix-SID TLV (used as a sub-TLV in this context)
where: Where:
o The Range TLV is defined in Section 2.3.4. o The Range TLV is defined in Section 2.3.4.
o The Prefix-SID TLV (used as sub-TLV in this context) is defined in o The Prefix-SID TLV (used as sub-TLV in this context) is defined in
Section 2.3.1. Section 2.3.1.
The following sub-sections describe the procedures for mapping of
information from the underlying IGP protocols into the Range TLV.
2.3.4.1. Advertisement Procedure for OSPF 2.3.4.1. Advertisement Procedure for OSPF
The OSPFv2/OSPFv3 Extended Prefix Range TLV is encoded in the Range The OSPFv2/OSPFv3 Extended Prefix Range TLV is encoded in the Range
TLV. The flags of the Range TLV have the semantic mapped to the TLV. The flags of the Range TLV have the semantic mapped to the
definition in [I-D.ietf-ospf-segment-routing-extensions] section 4 or definition in [I-D.ietf-ospf-segment-routing-extensions] section 4 or
[I-D.ietf-ospf-ospfv3-segment-routing-extensions] section 4. [I-D.ietf-ospf-ospfv3-segment-routing-extensions] section 4.
Then the prefix-to-SID mapping from the OSPF Prefix SID sub-TLV is Then the prefix-to-SID mapping from the OSPF Prefix SID sub-TLV is
encoded using the BGP-LS Prefix-SID TLV as defined in Section 2.3.1 encoded using the BGP-LS Prefix-SID TLV as defined in Section 2.3.1
with the flags set according to the definition in with the flags set according to the definition in
skipping to change at page 19, line 31 skipping to change at page 21, line 13
[I-D.ietf-isis-segment-routing-extensions] section 2.4.4.1. [I-D.ietf-isis-segment-routing-extensions] section 2.4.4.1.
2.4. Equivalent IS-IS Segment Routing TLVs/Sub-TLVs 2.4. Equivalent IS-IS Segment Routing TLVs/Sub-TLVs
This section illustrate the IS-IS Segment Routing Extensions TLVs and This section illustrate the IS-IS Segment Routing Extensions TLVs and
sub-TLVs mapped to the ones defined in this document. sub-TLVs mapped to the ones defined in this document.
The following table, illustrates for each BGP-LS TLV, its equivalence The following table, illustrates for each BGP-LS TLV, its equivalence
in IS-IS. in IS-IS.
+---------------------------------------+----------+----------------+ +------------+------------+-----------------------------------------+
| Description | Length | IS-IS TLV/sub- | | Descriptio | IS-IS TLV | Reference |
| | | TLV | | n | /sub-TLV | |
+---------------------------------------+----------+----------------+ +------------+------------+-----------------------------------------+
| SR Capabilities | variable | 2 [1] | | SR Capabil | 2 | draft-ietf-isis-segment-routing- |
| SR Algorithm | variable | 19 [2] | | ities | | extensions section-3.1 |
| SR Local Block | variable | 22 [3] | | SR | 19 | draft-ietf-isis-segment-routing- |
| SRMS Preference | 1 | 19 [4] | | Algorithm | | extensions section-3.2 |
| Adjacency Segment Identifier (Adj- | variable | 31 [5] | | SR Local | 22 | draft-ietf-isis-segment-routing- |
| SID) | | | | Block | | extensions section-3.3 |
| LAN Adjacency Segment Identifier | variable | 32 [6] | | SRMS | 19 | draft-ietf-isis-segment-routing- |
| (LAN-Adj-SID) | | | | Preference | | extensions section-3.2 |
| Prefix SID | variable | 3 [7] | | Adjacency | 31 | draft-ietf-isis-segment-routing- |
| Range | variable | 149 [8] | | SID | | extensions section-2.2.1 |
| SID/Label TLV | variable | 1 [9] | | LAN | 32 | draft-ietf-isis-segment-routing- |
| Prefix Attribute Flags | variable | 4 [10] | | Adjacency | | extensions section-2.2.2 |
| Source Router ID | variable | 11/12 [11] | | SID | | |
| L2 Bundle Member TLV | variable | 25 [12] | | Prefix SID | 3 | draft-ietf-isis-segment-routing- |
+---------------------------------------+----------+----------------+ | | | extensions section-2.1 |
| Range | 149 | draft-ietf-isis-segment-routing- |
| | | extensions section-2.4 |
| SID/Label | 1 | draft-ietf-isis-segment-routing- |
| | | extensions section-2.3 |
| Prefix | 4 | RFC7794 section-2.1 |
| Attribute | | |
| Flags | | |
| Source | 11/12 | RFC7794 section-2.2 |
| Router-ID | | |
| L2 Bundle | 25 | draft-ietf-isis-l2bundles section-2 |
| Member | | |
| Attributes | | |
+------------+------------+-----------------------------------------+
Table 5: IS-IS Segment Routing Extensions TLVs/Sub-TLVs Table 5: IS-IS Segment Routing Extensions TLVs/Sub-TLVs
2.5. Equivalent OSPFv2/OSPFv3 Segment Routing TLVs/Sub-TLVs 2.5. Equivalent OSPFv2/OSPFv3 Segment Routing TLVs/Sub-TLVs
This section illustrate the OSPFv2 and OSPFv3 Segment Routing This section illustrate the OSPFv2 and OSPFv3 Segment Routing
Extensions TLVs and sub-TLVs mapped to the ones defined in this Extensions TLVs and sub-TLVs mapped to the ones defined in this
document. document.
The following table, illustrates for each BGP-LS TLV, its equivalence The following table, illustrates for each BGP-LS TLV, its equivalence
in OSPFv2 and OSPFv3. in OSPFv2 and OSPFv3.
+-------------------------------------+----------+------------------+ +------------+------------+-----------------------------------------+
| Description | Length | OSPFv2 TLV/sub- | | Descriptio | OSPFv2 TLV | Reference |
| | | TLV | | n | /sub-TLV | |
+-------------------------------------+----------+------------------+ +------------+------------+-----------------------------------------+
| SR Capabilities | variable | 9 [13] | | SR Capabil | 9 | draft-ietf-ospf-segment-routing- |
| SR Algorithm | variable | 8 [14] | | ities | | extensions section-3.2 |
| SR Local Block | variable | 14 [15] | | SR | 8 | draft-ietf-ospf-segment-routing- |
| SRMS Preference | 1 | 15 [16] | | Algorithm | | extensions section-3.1 |
| Adjacency Segment Identifier (Adj- | variable | 2 [17] | | SR Local | 14 | draft-ietf-ospf-segment-routing- |
| SID) | | | | Block | | extensions section-3.3 |
| LAN Adjacency Segment Identifier | variable | 3 [18] | | SRMS | 15 | draft-ietf-ospf-segment-routing- |
| (Adj-SID) | | | | Preference | | extensions section-3.4 |
| Prefix SID | variable | 2 [19] | | Adjacency | 2 | draft-ietf-ospf-segment-routing- |
| Range | variable | 2 [20] | | SID | | extensions section-6.1 |
| SID/Label TLV | variable | 1 [21] | | LAN | 3 | draft-ietf-ospf-segment-routing- |
| Prefix Attribute Flags | variable | 4 [22] | | Adjacency | | extensions section-6.2 |
+-------------------------------------+----------+------------------+ | SID | | |
| Prefix SID | 2 | draft-ietf-ospf-segment-routing- |
| | | extensions section-5 |
| Range | 2 | draft-ietf-ospf-segment-routing- |
| | | extensions section-4 |
| SID/Label | 1 | draft-ietf-ospf-segment-routing- |
| | | extensions section-2.1 |
| Prefix | 4 | RFC7684 section-2.1 |
| Attribute | | |
| Flags | | |
| Source | TBD | draft-ietf-lsr-ospf-prefix-originator |
| Router-ID | | section-4 |
+------------+------------+-----------------------------------------+
Table 6: OSPF Segment Routing Extensions TLVs/Sub-TLVs Table 6: OSPFv2 Segment Routing Extensions TLVs/Sub-TLVs
+-------------------------------------+----------+------------------+ +-----------+------------+------------------------------------------+
| Description | Length | OSPFv3 TLV/sub- | | Descripti | OSPFv3 TLV | Reference |
| | | TLV | | on | /sub-TLV | |
+-------------------------------------+----------+------------------+ +-----------+------------+------------------------------------------+
| SR Capabilities | variable | 9 [23] | | SR Capabi | 9 | draft-ietf-ospf-ospfv3-segment-routing- |
| SR Algorithm | variable | 8 [24] | | lities | | extensions section-3.2 |
| SR Local Block | variable | 14 [25] | | SR | 8 | draft-ietf-ospf-ospfv3-segment-routing- |
| SRMS Preference | 1 | 15 [26] | | Algorithm | | extensions section-3.1 |
| Adjacency Segment Identifier (Adj- | variable | 5 [27] | | SR Local | 14 | draft-ietf-ospf-ospfv3-segment-routing- |
| SID) | | | | Block | | extensions section-3.3 |
| LAN Adjacency Segment Identifier | variable | 6 [28] | | SRMS Pref | 15 | draft-ietf-ospf-ospfv3-segment-routing- |
| (Adj-SID) | | | | erence | | extensions section-3.4 |
| Prefix SID | variable | 4 [29] | | Adjacency | 5 | draft-ietf-ospf-ospfv3-segment-routing- |
| Range | variable | 9 [30] | | SID | | extensions section-6.1 |
| SID/Label TLV | variable | 7 [31] | | LAN | 6 | draft-ietf-ospf-ospfv3-segment-routing- |
| Prefix Attribute Flags | variable | 4 [32] | | Adjacency | | extensions section-6.2 |
+-------------------------------------+----------+------------------+ | SID | | |
| Prefix | 4 | draft-ietf-ospf-ospfv3-segment-routing- |
| SID | | extensions section-5 |
| Range | 9 | draft-ietf-ospf-ospfv3-segment-routing- |
| | | extensions section-4 |
| SID/Label | 7 | draft-ietf-ospf-ospfv3-segment-routing- |
| | | extensions section-2.1 |
| Prefix | 4 | RFC8362 section-3.1 |
| Attribute | | |
| Flags | | |
| Source | TBD | draft-ietf-lsr-ospf-prefix-originator |
| Router-ID | | section-4 |
+-----------+------------+------------------------------------------+
Table 7: OSPFv3 Segment Routing Extensions TLVs/Sub-TLVs Table 7: OSPFv3 Segment Routing Extensions TLVs/Sub-TLVs
3. Implementation Status 3. IANA Considerations
Note to RFC Editor: Please remove this section prior to publication,
as well as the reference to RFC 7942.
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to [RFC7942], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
Several early implementations exist and will be reported in detail in
a forthcoming version of this document. For purposes of early
interoperability testing, when no FCFS code point was available,
implementations have made use of the values described in Table 8.
It will ease implementation interoperability and deployment if the
value could be preserved also due to the large amount of codepoints
this draft requires. However, when IANA-assigned values are
available, implementations will be updated to use them.
4. IANA Considerations
This document requests assigning code-points from the registry "BGP- Early allocation of codepoints has been done by IANA for this
LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute document from the registry "BGP-LS Node Descriptor, Link Descriptor,
TLVs" based on table Table 8. The column "IS-IS TLV/Sub-TLV" defined Prefix Descriptor, and Attribute TLVs" based on Table 8. The column
in the registry does not require any value and should be left empty. "IS-IS TLV/Sub-TLV" defined in the registry does not require any
value and should be left empty.
4.1. TLV/Sub-TLV Code Points Summary 3.1. TLV/Sub-TLV Code Points Summary
This section contains the global table of all TLVs/sub-TLVs defined This section contains the global table of all TLVs/sub-TLVs defined
in this document. in this document.
+-------------+-------------------------------------+---------------+ +----------------+-----------------------------+---------------+
| TLV Code | Description | Reference | | TLV Code Point | Description | Reference |
| Point | | | +----------------+-----------------------------+---------------+
+-------------+-------------------------------------+---------------+ | 1034 | SR Capabilities | Section 2.1.2 |
| 1034 | SR Capabilities | Section 2.1.2 | | 1035 | SR Algorithm | Section 2.1.3 |
| 1035 | SR Algorithm | Section 2.1.3 | | 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 | | 1099 | Adjacency SID | Section 2.2.1 |
| 1099 | Adjacency Segment Identifier (Adj- | Section 2.2.1 | | 1100 | LAN Adjacency SID | Section 2.2.2 |
| | SID) TLV | | | 1158 | Prefix SID | Section 2.3.1 |
| 1100 | LAN Adjacency Segment Identifier | Section 2.2.2 | | 1159 | Range | Section 2.3.4 |
| | (Adj-SID) TLV | | | 1161 | SID/Label | Section 2.1.1 |
| 1158 | Prefix SID | Section 2.3.1 | | 1170 | Prefix Attribute Flags | Section 2.3.2 |
| 1159 | Range | Section 2.3.4 | | 1171 | Source Router-ID | Section 2.3.3 |
| 1161 | SID/Label TLV | Section 2.1.1 | | 1172 | L2 Bundle Member Attributes | Section 2.2.3 |
| 1170 | Prefix Attribute Flags | Section 2.3.2 | +----------------+-----------------------------+---------------+
| 1171 | Source Router-ID | Section 2.3.3 |
| 1172 | L2 Bundle Member TLV | Section 2.2.3 |
+-------------+-------------------------------------+---------------+
Table 8: Summary Table of TLV/Sub-TLV Codepoints Table 8: Summary Table of TLV/Sub-TLV Codepoints
5. Manageability Considerations 4. Manageability Considerations
This section is structured as recommended in [RFC5706]. This section is structured as recommended in [RFC5706].
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].
Procedures and protocol extensions defined in this document do not Procedures and protocol extensions defined in this document do not
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 is retrieving this information A consumer of the BGP-LS information retrieves this information from
from a BGP protocol component that is doing the signaling over a BGP- a BGP protocol component that is doing the signaling over a BGP-LS
LS session, via some APIs or a data model (refer Section 1 and 2 of session, via some APIs or a data model (refer Section 1 and 2 of
[RFC7752]). The handling of semantic or content errors by the [RFC7752]). The handling of semantic or content errors by the
consumer would be dictated by the nature of its application usage and consumer would be dictated by the nature of its application usage and
hence is beyond the scope of this document. This document only hence is beyond the scope of this document.
introduces new Attribute TLVs and an error in them would result in
only that specific attribute being discarded with an error log. This document only introduces new Attribute TLVs and any syntactic
error in them would result in only that specific attribute being
discarded with an error log. The SR information introduced in BGP-LS
by this specification, may be used by BGP-LS consumer applications
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
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
different from the underlying IGP based distributed best path
computation. Errors in the encoding or decoding of the SR
information may result in the unavailability of such information to
the SR PCE or incorrect information being made available to it. This
may result in the SR PCE not being able to perform the desired SR
based optimization functionality or to perform it in an unexpected or
inconsistent manner. The handling of such errors by applications
like SR PCE may be implementation specific and out of scope of this
document.
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].
6. 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 was 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].
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 (refer
skipping to change at page 23, line 36 skipping to change at page 26, line 5
trusted SR domain (e.g. between multiple AS/domains within a single trusted SR domain (e.g. between multiple AS/domains within a single
provider network). Therefore, precaution is necessary to ensure that provider network). Therefore, precaution is necessary to ensure that
the SR information collected via BGP-LS is limited to specific the SR information collected via BGP-LS is limited to specific
controllers or applications in a secure manner within this SR domain. controllers or applications in a secure manner within this SR 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.
7. 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
Les Ginsberg Les Ginsberg
Cisco Systems Cisco Systems
skipping to change at page 24, line 4 skipping to change at page 26, line 21
Cisco Systems Cisco Systems
Email: ppsenak@cisco.com Email: ppsenak@cisco.com
Les Ginsberg Les Ginsberg
Cisco Systems Cisco Systems
Email: ginsberg@cisco.com Email: ginsberg@cisco.com
Acee Lindem Acee Lindem
Cisco Systems Cisco Systems
Email: acee@cisco.com Email: acee@cisco.com
Saikat Ray Saikat Ray
Individual Individual
Email: raysaikat@gmail.com Email: raysaikat@gmail.com
Jeff Tantsura Jeff Tantsura
Apstra Inc. Apstra Inc.
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
8. Acknowledgements 7. Acknowledgements
The authors would like to thank Jeffrey Haas, Aijun Wang and Robert The authors would like to thank Jeffrey Haas, Aijun Wang, Robert
Raszuk for their review of this document and their comments. Raszuk and Susan Hares for their review of this document and their
comments. The authors would also like to thank Alvaro Retana for his
extensive review and comments which helped correct issues and improve
the document.
9. References 8. References
9.1. Normative References 8.1. Normative References
[I-D.ietf-idr-te-pm-bgp] [I-D.ietf-idr-te-pm-bgp]
Ginsberg, L., Previdi, S., Wu, Q., Tantsura, J., and C. Ginsberg, L., Previdi, S., Wu, Q., Tantsura, J., and C.
Filsfils, "BGP-LS Advertisement of IGP Traffic Engineering Filsfils, "BGP-LS Advertisement of IGP Traffic Engineering
Performance Metric Extensions", draft-ietf-idr-te-pm- Performance Metric Extensions", draft-ietf-idr-te-pm-
bgp-14 (work in progress), October 2018. bgp-18 (work in progress), December 2018.
[I-D.ietf-isis-l2bundles]
Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and
E. Aries, "Advertising L2 Bundle Member Link Attributes in
IS-IS", draft-ietf-isis-l2bundles-07 (work in progress),
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., Litkowski, S., Decraene, B., and J. Tantsura, Gredler, H., and B. Decraene, "IS-IS Extensions for
"IS-IS Extensions for Segment Routing", draft-ietf-isis- Segment Routing", draft-ietf-isis-segment-routing-
segment-routing-extensions-19 (work in progress), July extensions-22 (work in progress), December 2018.
2018.
[I-D.ietf-lsr-ospf-prefix-originator]
Wang, A., Lindem, A., Dong, J., Talaulikar, K., and P.
Psenak, "OSPF Extension for Prefix Originator", draft-
ietf-lsr-ospf-prefix-originator-00 (work in progress),
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-
extensions-16 (work in progress), October 2018. extensions-23 (work in progress), January 2019.
[I-D.ietf-ospf-segment-routing-extensions] [I-D.ietf-ospf-segment-routing-extensions]
Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment- Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions-25 (work in progress), April 2018. routing-extensions-27 (work in progress), December 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions
in Support of Generalized Multi-Protocol Label Switching in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005,
<https://www.rfc-editor.org/info/rfc4202>. <https://www.rfc-editor.org/info/rfc4202>.
skipping to change at page 25, line 30 skipping to change at page 28, line 10
S. Ray, "North-Bound Distribution of Link-State and S. Ray, "North-Bound Distribution of Link-State and
Traffic Engineering (TE) Information Using BGP", RFC 7752, Traffic Engineering (TE) Information Using BGP", RFC 7752,
DOI 10.17487/RFC7752, March 2016, DOI 10.17487/RFC7752, March 2016,
<https://www.rfc-editor.org/info/rfc7752>. <https://www.rfc-editor.org/info/rfc7752>.
[RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and
U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4
and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794,
March 2016, <https://www.rfc-editor.org/info/rfc7794>. March 2016, <https://www.rfc-editor.org/info/rfc7794>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
9.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-04 (work in progress), June 2018.
[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-05 (work in progress), July 2018. 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
progress), September 2018. progress), September 2018.
[I-D.ietf-spring-sr-yang] [I-D.ietf-spring-sr-yang]
Litkowski, S., Qu, Y., Sarkar, P., and J. Tantsura, "YANG Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J.
Data Model for Segment Routing", draft-ietf-spring-sr- Tantsura, "YANG Data Model for Segment Routing", draft-
yang-09 (work in progress), June 2018. 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>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
9.3. URIs
[1] http://tools.ietf.org/html/draft-ietf-isis-segment-routing-
extensions-16#section-3.1
[2] http://tools.ietf.org/html/draft-ietf-isis-segment-routing-
extensions-16#section-3.2
[3] http://tools.ietf.org/html/draft-ietf-isis-segment-routing-
extensions-16#section-3.3
[4] http://tools.ietf.org/html/draft-ietf-isis-segment-routing-
extensions-05#section-3.2
[5] http://tools.ietf.org/html/draft-ietf-isis-segment-routing-
extensions-16#section-2.2.1
[6] http://tools.ietf.org/html/draft-ietf-isis-segment-routing-
extensions-16#section-2.2.2
[7] http://tools.ietf.org/html/draft-ietf-isis-segment-routing-
extensions-16#section-2.1
[8] http://tools.ietf.org/html/draft-ietf-isis-segment-routing-
extensions-16#section-2.4
[9] http://tools.ietf.org/html/draft-ietf-isis-segment-routing-
extensions-16#section-2.3
[10] http://tools.ietf.org/html/RFC7794
[11] http://tools.ietf.org/html/RFC7794
[12] http://tools.ietf.org/html/draft-ietf-isis-l2bundles-07
[13] http://tools.ietf.org/html/draft-ietf-ospf-segment-routing-
extensions-25#section-3.2
[14] http://tools.ietf.org/html/draft-ietf-ospf-segment-routing-
extensions-25#section-3.1
[15] http://tools.ietf.org/html/draft-ietf-ospf-segment-routing-
extensions-25#section-3.3
[16] http://tools.ietf.org/html/draft-ietf-ospf-segment-routing-
extensions-25#section-3.4
[17] http://tools.ietf.org/html/draft-ietf-ospf-segment-routing-
extensions-25#section-6.1
[18] http://tools.ietf.org/html/draft-ietf-ospf-segment-routing-
extensions-25#section-6.2
[19] http://tools.ietf.org/html/draft-ietf-ospf-segment-routing-
extensions-25#section-5
[20] http://tools.ietf.org/html/draft-ietf-ospf-segment-routing-
extensions-25#section-4
[21] http://tools.ietf.org/html/draft-ietf-ospf-segment-routing-
extensions-25#section-2.1
[22] http://tools.ietf.org/html/RFC7684#section-2.1
[23] http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-
routing-extensions-12#section-3.2
[24] http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-
routing-extensions-12#section-3.1
[25] http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-
routing-extensions-12#section-3.3
[26] http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-
routing-extensions-12#section-3.4
[27] http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-
routing-extensions-12#section-6.1
[28] http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-
routing-extensions-12#section-6.2
[29] http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-
routing-extensions-12#section-5
[30] http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-
routing-extensions-12#section-4
[31] http://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-
routing-extensions-12#section-2.1
[32] http://tools.ietf.org/html/RFC8362#section-3.1
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 Ketan Talaulikar (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
India India
Email: ketant@cisco.com Email: ketant@cisco.com
Clarence Filsfils Clarence Filsfils
Cisco Systems, Inc. Cisco Systems, Inc.
Brussels Brussels
Belgium Belgium
 End of changes. 124 change blocks. 
459 lines changed or deleted 500 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/