One document matched: draft-gredler-idr-bgp-ls-segment-routing-extension-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-gredler-idr-bgp-ls-segment-routing-extension-02"
ipr="trust200902">
<front>
<title abbrev="BGP LS extensions for Segment Routing">
BGP Link-State extensions for Segment Routing</title>
<author fullname="Hannes Gredler" initials="H." surname="Gredler" role="editor">
<organization>Juniper Networks, Inc.</organization>
<address>
<postal>
<street>1194 N. Mathilda Ave.</street>
<city>Sunnyvale</city>
<region>CA</region>
<code>94089</code>
<country>US</country>
</postal>
<email>hannes@juniper.net</email>
</address>
</author>
<author fullname="Saikat Ray" initials="S." surname="Ray" role="editor">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>170, West Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>
<email>sairay@cisco.com</email>
</address>
</author>
<author fullname="Stefano Previdi" initials="S." surname="Previdi">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>Via Del Serafico, 200</street>
<city>Rome</city>
<code>00142</code>
<country>Italy</country>
</postal>
<email>sprevidi@cisco.com</email>
</address>
</author>
<author fullname="Clarence Filsfils" initials="C." surname="Filsfils">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street></street>
<city>Brussels</city>
<code></code>
<country>Belgium</country>
</postal>
<email>cfilsfil@cisco.com</email>
</address>
</author>
<author fullname="Mach(Guoyi) Chen" initials="M." surname="Chen">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Building, No. 156 Beiqing Rd.</street>
<city>Beijing</city>
<code>100095</code>
<country>China</country>
</postal>
<email>mach.chen@huawei.com</email>
</address>
</author>
<author fullname="Jeff Tantsura" initials="J." surname="Tantsura">
<organization>Ericsson</organization>
<address>
<postal>
<street>300 Holger Way</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>US</country>
</postal>
<email>jeff.tantsura@ericsson.com</email>
</address>
</author>
<date day="16" month="October" year="2014"/>
<area>Routing</area>
<workgroup>Inter-Domain Routing</workgroup>
<keyword>BGP</keyword>
<keyword>Segment Routing</keyword>
<keyword>SID</keyword>
<keyword>MPLS</keyword>
<keyword>Label advertisement</keyword>
<keyword>IS-IS</keyword>
<keyword>OSPF</keyword>
<keyword>OSPFv3</keyword>
<abstract>
<t>Segment Routing (SR) allows for a flexible definition of end-to-end
paths within link-state graphs by encoding paths as sequences of
topological sub-paths, called "segments".</t>
<t> The link-state routing protocols (IS-IS, OSPF and
OSPFv3) have been extended to advertise the segments.
But flooding based propagation of path segments using IGPs is
limited by the perimeter of the IGP domain. For building paths
which span across IGP domains (e.g. multiple ASes), the Border
Gateway Protocol (BGP) is better suited as its propagation
perimeter is not limited like the IGPs.
</t>
<t>This draft defines extensions to the BGP Link-state
address-family to carry path segment information via BGP.
</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.
</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>Segment Routing (SR) allows for a flexible definition of end-to-end
paths within link-state topologies by encoding paths as sequences of
topological sub-paths, called "segments".
Segment routing is an amalgamation of source routing and MPLS.
In Segment Routing, the ingress node prepends a sequence of
instructions, called "segments", to the packet. The SR capable
nodes sequentially execute the instructions on the packet to
achieve packet forwarding via required topological paths as well
as service paths.
</t>
<t> The segments can be thought of, in a simple way, to
represent instructions such as "go to node N using the shortest
path", "follow the shortest path for prefix P", "use
link/node/ERO L", etc. Each segment is identified by a 32 bit
Segment Identifier (SID) (when unmodified MPLS data-plane is
used, the SIDs are restricted to 20 bits). There are "global"
segments that are known to all SR nodes in the local domain, and
there are local segments whose semantics are known only to the
nodes that originate them. The segment routing architecture is
described in <xref target="I-D.filsfils-rtgwg-segment-routing"/>
and segment routing use-cases in <xref
target="I-D.filsfils-rtgwg-segment-routing-use-cases"/>.
</t>
<t>Segment routing is enabled in a network by advertising the
segments (including the associated SIDs) to the nodes in the
network. The IGP link-state routing protocols (<xref
target="I-D.previdi-isis-segment-routing-extensions">IS-IS</xref>,
<xref
target="I-D.psenak-ospf-segment-routing-extensions">OSPFv2</xref>
and <xref
target="I-D.psenak-ospf-segment-routing-ospfv3-extension">OSPFv3</xref>)
have been extended to advertise the segments. Using these
extensions, segment routing can be enabled within an IGP domain.
</t>
<figure anchor="MECHANISM-CONSUMER-PRODUCER"
title="Link State info collection">
<artwork>
+------------+
| Consumer |
+------------+
^
|
v
+-------------------+
| BGP Speaker | +-----------+
| (Route-Reflector) | | Consumer |
+-------------------+ +-----------+
^ ^ ^ ^
| | | |
+---------------+ | +-------------------+ |
| | | |
v v v v
+-----------+ +-----------+ +-----------+
| BGP | | BGP | | BGP |
| Speaker | | Speaker | . . . | Speaker |
+-----------+ +-----------+ +-----------+
^ ^ ^
| | |
IGP IGP IGP
</artwork>
</figure>
<t>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 possible to construct segments
across an IGP Area or AS boundaries.
</t>
<t>To address the need for applications that require visibility
into LSDB across IGP areas, or even across ASes, the BGP-LS
address-family/sub-address-family have been defined that allows
BGP to carry LSDB information. The BGP Network Layer
Reachability Information (NLRI) encoding format for BGP-LS and a
new BGP Path Attribute called BGP-LS attribute are defined in
<xref target="I-D.ietf-idr-ls-distribution"></xref>. The
identifying key of each LSDB object, namely a node, a link or a
prefix, is encoded in the NLRI and the properties of the object
are encoded in the BGP-LS attribute. Figure <xref
target="MECHANISM-CONSUMER-PRODUCER"/> describes a typical
deployment scenario. In each IGP area, one or more nodes are
configured with BGP-LS. These BGP speakers form an IBGP mesh by
connecting to one or more route-reflectors. This way, all BGP
speakers - specifically the route-reflectors - obtain LSDB
information from all IGP areas (and from other ASes from EBGP
peers). An external component connects to the route-reflector to
obtain this information (perhaps moderated by a policy regarding
what information is sent to the external component, and what
information isn't).
</t>
<t>This document describes extensions to BGP-LS to carry the
segments. An external component - a Controller - then can
collect segment information in the "northbound direction" across
IGP areas/autonomous systems and construct the segment stack
that need to be added to an incoming packet to achieve the
desired end-to-end forwarding.
</t>
</section>
<section title="BGP-LS Extensions for Segment Routing">
<t>The BGP-LS NLRI can be a node NLRI, a link NLRI or a prefix
NLRI. The corresponding BGP-LS attribute is a node attribute, a
link attribute or a prefix attribute. <xref
target="I-D.ietf-idr-ls-distribution">BGP-LS</xref> defines the
TLVs that map link-state information to BGP-LS NLRI and BGP-LS
attribute. This document adds additional BGP-LS attribute TLVs
to encode SR information.
</t>
<t> <xref
target="I-D.previdi-isis-segment-routing-extensions"/> defines the
following TLVs to encode SR information.
<list style="symbols">
<t>TLV for Prefix-SID</t>
<t>TLV for Adjacency-SID between two nodes as well as between nodes in a LAN</t>
<t>TLV for SID/Label binding for advertising paths from other protocols (and their optional ERO)</t>
<t>TLV for SR Capabilities</t>
<t>TLV for SR Algorithm</t>
</list>
These TLVs are mapped to BGP-LS attribute TLVs in the following way.
<figure anchor="TLV-figure" title="TLV format">
<artwork>
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Value (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
The 2 octet Type field values are defined in <xref
target="node-attribute_tlv"/>, <xref
target="link-attribute_tlv"/>, and <xref
target="prefix-attribute_tlv"/>. The next 2 octet Length field
encodes length of the rest of the TLV. The Value portion of the
TLV is variable and is equal to the corresponding Value portion
of the TLV defined in <xref
target="I-D.previdi-isis-segment-routing-extensions"/>.
</t>
<t>In each case, multiple TLVs for a given type are allowed to be
added. The semantics of multiple such values are determined by
<xref target="I-D.previdi-isis-segment-routing-extensions"/>.
</t>
<section anchor="node_attribute" title="Node Attribute TLVs">
<t>The following 'Node Attribute' TLVs are defined:
</t>
<texttable anchor="node-attribute_tlv"
title="Node Attribute TLVs">
<ttcol align="center">TLV Code Point</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Length</ttcol>
<ttcol align="right">IS-IS SR TLV/sub-TLV</ttcol>
<c>1033</c>
<c>SID/Label Binding</c>
<c>variable</c>
<c><eref target="http://tools.ietf.org/html/draft-previdi-isis-segment-routing-extensions-04#section-2.4">149</eref></c>
<c>1034</c>
<c>SR Capabilities</c>
<c>variable</c>
<c><eref target="http://tools.ietf.org/html/draft-previdi-isis-segment-routing-extensions-04#section-3.1">2</eref></c>
<c>1035</c>
<c>SR Algorithm</c>
<c>variable</c>
<c><eref target="http://tools.ietf.org/html/draft-previdi-isis-segment-routing-extensions-04#section-3.2">15</eref></c>
</texttable>
<t>The sections refer to <xref target="I-D.previdi-isis-segment-routing-extensions"/>.
</t>
<t>These TLVs can ONLY be added to the Node Attribute
associated with the Node NLRI that originates the
corresponding SR TLV.
</t>
</section>
<section anchor="link_attribute" title="Link Attribute TLVs">
<t>The following 'Link Attribute' TLVs are are defined:
</t>
<texttable anchor="link-attribute_tlv"
title="Link Attribute TLVs">
<ttcol align="center">TLV Code Point</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="right">Length</ttcol>
<ttcol align="right">IS-IS SR TLV/sub-TLV</ttcol>
<c>1099</c>
<c>Adjacency Segment Identifier (Adj-SID) TLV</c>
<c>variable</c>
<c><eref target="http://tools.ietf.org/html/draft-previdi-isis-segment-routing-extensions-04#section-2.3.1">31</eref></c>
<c>1100</c>
<c>LAN Adjacency Segment Identifier (Adj-SID) TLV</c>
<c>variable</c>
<c><eref target="http://tools.ietf.org/html/draft-previdi-isis-segment-routing-extensions-04#section-2.3.2">32</eref></c>
</texttable>
<t>The sections refer to <xref
target="I-D.previdi-isis-segment-routing-extensions"/>.
</t>
<t>These TLVs can ONLY be added to the Link Attribute
associated with the link whose local node originates the
corresponding SR TLV.
</t>
<t> For a LAN, normally a node only announces its adjacency
to the pseudo-node. <xref
target="I-D.previdi-isis-segment-routing-extensions"/>
allows a node to announce adjacency to all other nodes
attached to the LAN. In such a case, the corresponding
BGP-LS link NLRI must be originated for each additional link
in order to add the SR TLVs to the Link Attribute.
</t>
</section>
<section title="Prefix Attribute TLVs">
<t>The following 'Prefix Attribute' TLVs are defined:
</t>
<texttable anchor="prefix-attribute_tlv"
title="Prefix Attribute TLVs">
<ttcol align="center">TLV Code Point</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="right">Length</ttcol>
<ttcol align="left">IS-IS SR TLV/sub-TLV</ttcol>
<c>1158</c>
<c>Prefix SID</c>
<c>variable</c>
<c><eref target="http://tools.ietf.org/html/draft-previdi-isis-segment-routing-extensions-04#section-2.2">3</eref></c>
</texttable>
<t>The sections refer to <xref
target="I-D.previdi-isis-segment-routing-extensions"/>.
</t>
<t>These TLVs can ONLY be added to the Prefix Attribute whose
local node in the corresponding prefix NLRI is the node that
originates the corresponding SR TLV.
</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document requests assigning code-points from the
registry for BGP-LS attribute TLVs based on table <xref
target="BGPLSCODEPOINTS"/>.
</t>
</section>
<section anchor="Manageability" title="Manageability Considerations">
<t>This section is structured as recommended in <xref
target="RFC5706"></xref>.</t>
<section anchor="Operational-Considerations"
title="Operational Considerations">
<section anchor="Operations" title="Operations">
<t>Existing BGP and BGP-LS operational procedures apply.
No new operation procedures are defined in this document.
</t>
</section>
</section>
</section>
<section anchor="TLVSUMMARY" title="TLV/Sub-TLV Code Points Summary">
<t>This section contains the global table of all TLVs/Sub-TLVs defined in
this document.</t>
<texttable anchor="BGPLSCODEPOINTS"
title="Summary Table of TLV/Sub-TLV Codepoints">
<ttcol align="center">TLV Code Point</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="center">Length</ttcol>
<ttcol align="left">IS-IS SR TLV/sub-TLV</ttcol>
<!-- BGP-LS Attribute TLVs -->
<!-- Node Attributes TLVs -->
<c>1033</c>
<c>SID/Label Binding</c>
<c>variable</c>
<c><eref target="http://tools.ietf.org/html/draft-previdi-isis-segment-routing-extensions-04#section-2.4">149</eref></c>
<c>1034</c>
<c>SR Capabilities</c>
<c>variable</c>
<c><eref target="http://tools.ietf.org/html/draft-previdi-isis-segment-routing-extensions-04#section-3.1">2</eref></c>
<c>1035</c>
<c>SR Algorithm</c>
<c>variable</c>
<c><eref target="http://tools.ietf.org/html/draft-previdi-isis-segment-routing-extensions-04#section-3.2">15</eref></c>
<!-- Link Attribute TLVs -->
<c>1099</c>
<c>Adjacency Segment Identifier (Adj-SID) TLV</c>
<c>variable</c>
<c><eref target="http://tools.ietf.org/html/draft-previdi-isis-segment-routing-extensions-04#section-2.3.1">31</eref></c>
<c>1100</c>
<c>LAN Adjacency Segment Identifier (Adj-SID) TLV</c>
<c>variable</c>
<c><eref target="http://tools.ietf.org/html/draft-previdi-isis-segment-routing-extensions-04#section-2.3.2">32</eref></c>
<!-- Prefix Attributes TLVs -->
<c>1158</c>
<c>Prefix SID</c>
<c>variable</c>
<c><eref target="http://tools.ietf.org/html/draft-previdi-isis-segment-routing-extensions-04#section-2.2">3</eref></c>
</texttable>
</section>
<section anchor="Security" title="Security Considerations">
<t>Procedures and protocol extensions defined in this document do not
affect the BGP security model. See the 'Security Considerations' section
of <xref target="RFC4271"/> for a discussion of BGP security. Also refer
to <xref target="RFC4272"/> and <xref target="RFC6952"/>
for analysis of security issues for BGP.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>TBD.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-idr-ls-distribution-04.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-previdi-isis-segment-routing-extensions-04"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-psenak-ospf-segment-routing-extensions-03.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-psenak-ospf-segment-routing-ospfv3-extension-00.xml"?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-filsfils-rtgwg-segment-routing-01.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-filsfils-rtgwg-segment-routing-use-cases-02.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4272.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5706.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6952.xml"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:00:27 |