rfc9125xml2.original.xml   rfc9125.xml 
<?xml version="1.0" encoding="iso-8859-1"?> <?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <!DOCTYPE rfc [
<?rfc strict="no" ?> <!ENTITY nbsp "&#160;">
<?rfc toc="yes"?> <!ENTITY zwsp "&#8203;">
<?rfc tocompact="yes"?> <!ENTITY nbhy "&#8209;">
<?rfc tocdepth="3"?> <!ENTITY wj "&#8288;">
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2119.xml">
<!ENTITY RFC4271 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4271.xml">
<!ENTITY RFC4272 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4272.xml">
<!ENTITY RFC4360 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4360.xml">
<!ENTITY RFC4364 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4364.xml">
<!ENTITY RFC4684 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4684.xml">
<!ENTITY RFC4760 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.4760.xml">
<!ENTITY RFC5291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5291.xml">
<!ENTITY RFC5925 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5925.xml">
<!ENTITY RFC6952 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6952.xml">
<!ENTITY RFC7752 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7752.xml">
<!ENTITY RFC7911 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7911.xml">
<!ENTITY RFC7926 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7926.xml">
<!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8126.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
<!ENTITY RFC8402 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8402.xml">
<!ENTITY RFC9012 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.9012.xml">
<!ENTITY I-D.ietf-idr-bgpls-segment-routing-epe SYSTEM "http://xml2rfc.ietf.org/
public/rfc/bibxml3/reference.I-D.ietf-idr-bgpls-segment-routing-epe">
<!ENTITY I-D.farrel-spring-sr-domain-interconnect SYSTEM "http://xml2rfc.ietf.or
g/public/rfc/bibxml3/reference.I-D.farrel-spring-sr-domain-interconnect">
<!ENTITY I-D.ietf-idr-bgp-ls-segment-routing-ext SYSTEM "http://xml2rfc.ietf.org
/public/rfc/bibxml3/reference.I-D.ietf-idr-bgp-ls-segment-routing-ext">
]> ]>
<rfc category="std" docName="draft-ietf-bess-datacenter-gateway-13" ipr="trust20 <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" number="9125" doc
0902"> Name="draft-ietf-bess-datacenter-gateway-13" ipr="trust200902" obsoletes="" upda
tes="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" symRef
s="true" sortRefs="true" version="3" consensus="true">
<front> <front>
<title abbrev="SR DC Gateways">Gateway Auto-Discovery and Route Advertisemen <title abbrev="SR DC Gateways">Gateway Auto-Discovery and Route
t for Segment Routing Enabled Site Interconnection</title> Advertisement for Site Interconnection Using Segment Routing</title>
<seriesInfo name="RFC" value="9125"/>
<author fullname="Adrian Farrel" initials="A." surname="Farrel"> <author fullname="Adrian Farrel" initials="A." surname="Farrel">
<organization>Old Dog Consulting</organization> <organization>Old Dog Consulting</organization>
<address> <address>
<email>adrian@olddog.co.uk</email> <email>adrian@olddog.co.uk</email>
</address> </address>
</author> </author>
<author fullname="John Drake" initials="J." surname="Drake"> <author fullname="John Drake" initials="J." surname="Drake">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<email>jdrake@juniper.net</email> <email>jdrake@juniper.net</email>
</address> </address>
</author> </author>
<author fullname="Eric Rosen" initials="E." surname="Rosen"> <author fullname="Eric Rosen" initials="E." surname="Rosen">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<email>erosen52@gmail.com</email> <email>erosen52@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Keyur Patel" initials="K." surname="Patel"> <author fullname="Keyur Patel" initials="K." surname="Patel">
<organization>Arrcus, Inc.</organization> <organization>Arrcus, Inc.</organization>
<address> <address>
<email>keyur@arrcus.com</email> <email>keyur@arrcus.com</email>
</address> </address>
</author> </author>
<author fullname="Luay Jalil" initials="L" surname="Jalil"> <author fullname="Luay Jalil" initials="L" surname="Jalil">
<organization>Verizon</organization> <organization>Verizon</organization>
<address> <address>
<email>luay.jalil@verizon.com</email> <email>luay.jalil@verizon.com</email>
</address> </address>
</author> </author>
<date month="August" year="2021"/>
<date year="2021" />
<area>Routing</area> <area>Routing</area>
<workgroup>BESS Working Group</workgroup> <workgroup>BESS Working Group</workgroup>
<keyword>SR</keyword> <keyword>SR</keyword>
<keyword>GW</keyword> <keyword>GW</keyword>
<keyword>BGP</keyword> <keyword>BGP</keyword>
<abstract> <abstract>
<t>Data centers are attached to the Internet or a backbone network by
<t>Data centers are attached to the Internet or a backbone network by gat gateway routers. One data center typically has more than one gateway
eway routers. One data for commercial, load-balancing, and resiliency reasons. Other sites,
center typically has more than one gateway for commercial, load balanc such as access networks, also need to be connected across backbone
ing, and resiliency reasons. networks through gateways.</t>
Other sites, such as access networks, also need to be connected across <t>This document defines a mechanism using the BGP Tunnel Encapsulation
backbone networks through attribute to allow data center gateway routers to advertise routes to
gateways.</t> the prefixes reachable in the site, including advertising them on behalf
of other gateways at the same site. This allows segment routing to be
<t>This document defines a mechanism using the BGP Tunnel Encapsulation a used to identify multiple paths across the Internet or backbone network
ttribute to allow data center between different gateways. The paths can be selected for
gateway routers to advertise routes to the prefixes reachable in the s load-balancing, resilience, and quality purposes.</t>
ite, including advertising
them on behalf of other gateways at the same site. This allows segmen
t routing to be used to
identify multiple paths across the Internet or backbone network betwee
n different gateways. The
paths can be selected for load-balancing, resilience, and quality purp
oses.</t>
</abstract> </abstract>
</front>
<middle>
<section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
</front> <t>Data centers (DCs) are critical components of the infrastructure used
by network operators to provide services to their customers. DCs
<middle> (sites) are interconnected by a backbone network, which consists of any
number of private networks and/or the Internet. DCs are attached to the
<section anchor="introduction" title="Introduction"> backbone network by routers that are gateways (GWs). One DC typically has
more
<t>Data centers (DCs) are critical components of the infrastructure used by than one GW for various reasons including commercial preferences, load
network operators to provide balancing, or resiliency against connection or device failure.</t>
services to their customers. DCs (sites) are interconnected by a backbo <t>Segment Routing (SR) (<xref target="RFC8402" format="default"/>) is a
ne network, which consists of protocol mechanism that can be used within a DC as well as for steering
any number of private networks and/or the Internet. DCs are attached to traffic that flows between two DC sites. In order for a source site
the backbone network by (also known as an ingress site) that uses SR to load-balance the flows
gateway routers (GWs). One DC typically has more than one GW for variou it sends to a destination site (also known as an egress site), it needs
s reasons including commercial to know the complete set of entry nodes (i.e., GWs) for that egress DC
preferences, load balancing, or resiliency against connection or device from the backbone network connecting the two DCs. Note that it is
failure.</t> assumed that the connected set of DC sites and the border nodes in the
backbone network on the paths that connect the DC sites are part of the
<t>Segment Routing (SR) <xref target="RFC8402" /> is a protocol mechanism t same SR BGP - Link State (LS) instance (see <xref target="RFC7752"
hat can be used within a DC, and format="default"/> and <xref
also for steering traffic that flows between two DC sites. In order for target="RFC9086" format="default"/>) so
a source site (also known as an that traffic engineering using SR may be used for these flows.</t>
ingress site) that uses SR to load balance the flows it sends to a desti
nation site (also known as an egress
site), it needs to know the complete set of entry nodes (i.e., GWs) for
that egress DC from the backbone
network connecting the two DCs. Note that it is assumed that the connec
ted set of DC sites and the border nodes
in the backbone network on the paths that connect the DC sites are part
of the same SR BGP Link State (LS)
instance (<xref target="RFC7752" /> and <xref target="I-D.ietf-idr-bgpls
-segment-routing-epe" />) so that
traffic engineering using SR may be used for these flows.</t>
<t>Other sites, such as access networks, also need to be connected across b <t>Other sites, such as access networks, also need to be connected
ackbone networks through gateways. across backbone networks through gateways. For illustrative purposes,
For illustrative purposes, consider the ingress and egress sites shown i consider the ingress and egress sites shown in <xref
n <xref target="david_hockney" /> target="david_hockney" format="default"/> as separate Autonomous Systems (
as separate ASes (noting that the sites could be implemented as part of ASes) (noting that
the ASes to which they are attached, or the sites could be implemented as part of the ASes to which they are
as separate ASes). The various ASes that provide connectivity between t attached, or as separate ASes).
he ingress and egress sites could each
be constructed differently and use different technologies such as IP, MP
LS using global table routing information
from native BGP, MPLS IP VPN, SR-MPLS IP VPN, or SRv6 IP VPN. That is,
the ingress and egress sites can be connected
by tunnels across a variety of technologies. This document describes ho
w SR identifiers (SIDs) are used to
identify the paths between the ingress and egress sites.</t>
<t>The solution described in this document is agnostic as to whether the tr The various ASes that provide connectivity between the ingress and
ansit ASes do or do not have SR capabilities. egress sites could each be constructed differently and use different
The solution uses SR to stitch together path segments between GWs and th technologies such as IP; MPLS using global table routing information
rough the ASBRs. Thus, there is a requirement from BGP; MPLS IP VPN; SR-MPLS IP VPN; or SRv6 IP VPN.
that the GWs and ASBRs are SR-capable. The solution supports the SR pat
h being extended into the ingress and egress
sites if they are SR-capable.</t>
<t>The solution defined in this document can be seen in the broader context That is, the ingress and egress sites can be connected by tunnels across
of site interconnection in a variety of technologies. This document describes how SR Segment
<xref target="I-D.farrel-spring-sr-domain-interconnect" />. That docume Identifiers (SIDs) are used to identify the paths between the ingress
nt shows how other existing and egress sites.</t>
protocol elements may be combined with the solution defined in this docu
ment to provide a full system,
but is not a necessary reference for understanding this document.</t>
<t>Suppose that there are two gateways, GW1 and GW2 as shown in <xref targe <t>The solution described in this document is agnostic as to whether the
t="david_hockney" />, for a given transit ASes do or do not have SR capabilities. The solution uses SR to
egress site and that they each advertise a route to prefix X which is lo stitch together path segments between GWs and through the Autonomous
cated within the System Border Routers (ASBRs). Thus, there is a requirement that the
egress site with each setting itself as next hop. One might think that GWs and ASBRs are SR capable. The solution supports the SR path being
the GWs for X could extended into the ingress and egress sites if they are SR capable.</t>
be inferred from the routes&apos; next hop fields, but typically it is n <t>The solution defined in this document can be seen in the broader
ot the case that both routes get context of site interconnection in <xref
distributed across the backbone: rather only the best route, as selected target="I-D.farrel-spring-sr-domain-interconnect" format="default"/>.
by BGP, is distributed. This That document shows how other existing protocol elements may be combined
precludes load balancing flows across both GWs.</t> with the solution defined in this document to provide a full system, but
it is not a necessary reference for understanding this document.</t>
<figure anchor="david_hockney" title="Example Site Interconnection"> <t>Suppose that there are two gateways, GW1 and GW2 as shown in <xref
<artwork align="center"> target="david_hockney" format="default"/>, for a given egress site and
<![CDATA[ that they each advertise a route to prefix X, which is located within the
egress site with each setting itself as next hop. One might think that
the GWs for X could be inferred from the routes' next-hop fields, but
typically it is not the case that both routes get distributed across the
backbone: rather only the best route, as selected by BGP, is
distributed. This precludes load-balancing flows across both GWs.</t>
<figure anchor="david_hockney">
<name>Example Site Interconnection</name>
<artwork align="center" name="" type="" alt=""><![CDATA[
----------------- --------------------- ----------------- ---------------------
| Ingress | | Egress ------ | | Ingress | | Egress ------ |
| Site | | Site |Prefix| | | Site | | Site |Prefix| |
| | | | X | | | | | | X | |
| | | ------ | | | | ------ |
| -- | | --- --- | | -- | | --- --- |
| |GW| | | |GW1| |GW2| | | |GW| | | |GW1| |GW2| |
-------++-------- ----+-----------+-+-- -------++-------- ----+-----------+-+--
| \ | / | | \ | / |
| \ | / | | \ | / |
skipping to change at line 173 skipping to change at line 157
| | | | | | | | | | | |
| | ----| |---- | | | | ----| |---- | |
| | AS1 |ASBR+------+ASBR| AS2 | | | | AS1 |ASBR+------+ASBR| AS2 | |
| | ----| |---- | | | | ----| |---- | |
| --------------- -------------------- | | --------------- -------------------- |
--+-----------------------------------------------+-- --+-----------------------------------------------+--
| |ASBR| |ASBR| | | |ASBR| |ASBR| |
| ---- AS3 ---- | | ---- AS3 ---- |
| | | |
----------------------------------------------------- -----------------------------------------------------
]]> ]]></artwork>
</artwork> </figure>
</figure>
<t>The obvious solution to this problem is to use the BGP feature that allo
ws the advertisement of
multiple paths in BGP (known as Add-Paths) <xref target="RFC7911" /> to
ensure that all routes to
X get advertised by BGP. However, even if this is done, the identity of
the GWs will be lost as
soon as the routes get distributed through an Autonomous System Border R
outer (ASBR) that will
set itself to be the next hop. And if there are multiple Autonomous Sys
tems (ASes) in the
backbone, not only will the next hop change several times, but the Add-P
aths technique will
experience scaling issues. This all means that the Add-Paths approach i
s effectively limited to
sites connected over a single AS.</t>
<t>This document defines a solution that overcomes this limitation and work
s equally well with a
backbone constructed from one or more ASes using the Tunnel Encapsulatio
n attribute
<xref target="RFC9012" /> as follows:
<list style="empty">
<t>When a GW to a given site advertises a route to a prefix X within
that site, it
will include a Tunnel Encapsulation attribute that contains the un
ion of the Tunnel
Encapsulation attributes advertised by each of the GWs to that sit
e, including itself.</t>
</list></t>
<t>In other words, each route advertised by a GW identifies all of the GWs
to the same site (see
<xref target="DCGWautodisco" /> for a discussion of how GWs discover eac
h other). I.e., the Tunnel
Encapsulation attribute advertised by each GW contains multiple Tunnel T
LVs, one or more from each
active GW, and each Tunnel TLV will contain a Tunnel Egress Endpoint Sub
-TLV that identifies the GW
for that Tunnel TLV. Therefore, even if only one of the routes is distr
ibuted to other ASes, it will
not matter how many times the next hop changes, as the Tunnel Encapsulat
ion attribute will remain
unchanged.</t>
<t>To put this in the context of <xref target="david_hockney" />, GW1 and G
W2 discover each other as
gateways for the egress site. Both GW1 and GW2 advertise themselves as
having routes to prefix
X. Furthermore, GW1 includes a Tunnel Encapsulation attribute which is
the union of its Tunnel
Encapsulation attribute and GW2&apos;s Tunnel Encapsulation attribute.
Similarly, GW2 includes a
Tunnel Encapsulation attribute which is the union of its Tunnel Encapsul
ation attribute and GW1&apos;s
Tunnel Encapsulation attribute. The gateway in the ingress site can now
see all possible paths
to X in the egress site regardless of which route is propagated to it, a
nd it can choose one, or
balance traffic flows as it sees fit.</t>
</section>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP 14
<xref target="RFC2119" /> <xref target="RFC8174" /> when, and only when,
they appear in all capitals, as shown here.</t>
</section> <t>The obvious solution to this problem is to use the BGP feature that
allows the advertisement of multiple paths in BGP (known as Add-Paths)
(<xref target="RFC7911" format="default"/>) to ensure that all routes to X
get advertised by BGP. However, even if this is done, the identity of
the GWs will be lost as soon as the routes get distributed through an
ASBR that will set itself to be the
next hop. And if there are multiple ASes in the
backbone, not only will the next hop change several times, but the
Add-Paths technique will experience scaling issues. This all means that
the Add-Paths approach is effectively limited to sites connected over a
single AS.</t>
<t>This document defines a solution that overcomes this limitation and
works equally well with a backbone constructed from one or more ASes
using the Tunnel Encapsulation attribute (<xref target="RFC9012"
format="default"/>) as follows:
</t>
<ul empty="true" spacing="normal">
<li>When a GW to a given site advertises a route to a prefix X within
that site, it will include a Tunnel Encapsulation attribute that
contains the union of the Tunnel Encapsulation attributes advertised
by each of the GWs to that site, including itself.</li>
</ul>
<t>In other words, each route advertised by a GW identifies all of the
GWs to the same site (see <xref target="DCGWautodisco"
format="default"/> for a discussion of how GWs discover each other),
i.e., the Tunnel Encapsulation attribute advertised by each GW contains
multiple Tunnel TLVs, one or more from each active GW, and each Tunnel
TLV will contain a Tunnel Egress Endpoint sub-TLV that identifies the GW
for that Tunnel TLV. Therefore, even if only one of the routes is
distributed to other ASes, it will not matter how many times the next
hop changes, as the Tunnel Encapsulation attribute will remain
unchanged.</t>
<t>To put this in the context of <xref target="david_hockney"
format="default"/>, GW1 and GW2 discover each other as gateways for the
egress site. Both GW1 and GW2 advertise themselves as having routes to
prefix X. Furthermore, GW1 includes a Tunnel Encapsulation attribute,
which is the union of its Tunnel Encapsulation attribute and GW2's
Tunnel Encapsulation attribute. Similarly, GW2 includes a Tunnel
Encapsulation attribute, which is the union of its Tunnel Encapsulation
attribute and GW1's Tunnel Encapsulation attribute. The gateway in the
ingress site can now see all possible paths to X in the egress site
regardless of which route is propagated to it, and it can choose one or
balance traffic flows as it sees fit.</t>
</section>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<section anchor="DCGWautodisco" title="Site Gateway Auto-Discovery"> <t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
<t>To allow a given site&apos;s GWs to auto-discover each other and to coor </section>
dinate their operations, <section anchor="DCGWautodisco" numbered="true" toc="default">
<name>Site Gateway Auto-Discovery</name>
<t>To allow a given site's GWs to auto-discover each other and to coordina
te their operations,
the following procedures are implemented: the following procedures are implemented:
<list style="symbols"> </t>
<t>A route target (<xref target="RFC4360" />) MUST be attached to eac <ul spacing="normal">
h GW&apos;s auto-discovery route <li>A route target (<xref target="RFC4360" format="default"/>) <bcp14>MU
(defined below) and its value MUST be set to a value that indicate ST</bcp14> be
s the site identifier. The attached to each GW's auto-discovery route (defined below), and its
rules for constructing a route target are detailed in <xref target value <bcp14>MUST</bcp14> be set to a value that indicates the site iden
="RFC4360" />. It is tifier. The
RECOMMENDED that a Type x00 or x02 route target be used.</t> rules for constructing a route target are detailed in <xref
target="RFC4360" format="default"/>. It is <bcp14>RECOMMENDED</bcp14> t
<t>Site identifiers are set through configuration. The site identifi hat a Type
ers MUST be the same across all x00 or x02 route target be used.</li>
GWs to the site (i.e., the same identifier is used by all GWs to t <li>Site identifiers are set through configuration. The site
he same site), and MUST be identifiers <bcp14>MUST</bcp14> be the same across all GWs to the site (
unique across all sites that are connected (i.e., across all GWs t i.e., the
o all sites that are interconnected).</t> same identifier is used by all GWs to the same site) and <bcp14>MUST</bc
p14> be
<t>Each GW MUST construct an import filtering rule to import any rout unique across all sites that are connected (i.e., across all GWs to
e that carries a route target with all sites that are interconnected).</li>
the same site identifier that the GW itself uses. This means that <li>Each GW <bcp14>MUST</bcp14> construct an import filtering rule to im
only these GWs will import port any
those routes, and that all GWs to the same site will import each o route that carries a route target with the same site identifier that
ther&apos;s routes and will the GW itself uses. This means that only these GWs will import those
learn (auto-discover) the current set of active GWs for the site.< routes, and that all GWs to the same site will import each other's
/t> routes and will learn (auto-discover) the current set of active GWs
</list> for the site.</li>
</t> </ul>
<t>The auto-discovery route that each GW advertises consists of the follow
<t>The auto-discovery route that each GW advertises consists of the followi ing:
ng: </t>
<list style="symbols"> <ul spacing="normal">
<t>An IPv4 or IPv6 Network Layer Reachability Information (NLRI) <xre <li>IPv4 or IPv6 Network Layer Reachability Information (NLRI) (<xref
f target="RFC4760"/> target="RFC4760" format="default"/>) containing one of the GW's
containing one of the GW&apos;s loopback addresses (that is, with loopback addresses (that is, with an AFI/SAFI pair that is one of the
an AFI/SAFI pair following: IPv4/NLRI used for unicast forwarding (1/1); IPv6/NLRI used f
that is one of IPv4/NLRI used for unicast forwarding (1/1), IPv6/N or
LRI used for unicast unicast forwarding (2/1); IPv4/NLRI with MPLS Labels (1/4); or
forwarding (2/1), IPv4/NLRI with MPLS Labels (1/4), or IPv6/NLRI w IPv6/NLRI with MPLS Labels (2/4)).</li>
ith MPLS Labels (2/4)).</t>
<t>A Tunnel Encapsulation attribute <xref target="RFC9012" /> contain
ing the GW&apos;s
encapsulation information encoded in one or more Tunnel TLVs.</t>
</list>
</t>
<t>To avoid the side effect of applying the Tunnel Encapsulation attribute
to any packet that is addressed
to the GW itself, the address advertised for auto-discovery MUST be a di
fferent loopback address than is
advertised for packets directed to the gateway itself.</t>
<t>As described in <xref target="introduction" />, each GW will include a T
unnel Encapsulation attribute with
the GW encapsulation information for each of the site&apos;s active GWs
(including itself) in every route
advertised externally to that site. As the current set of active GWs ch
anges (due to the addition of a
new GW or the failure/removal of an existing GW) each externally adverti
sed route will be re-advertised with
a new Tunnel Encapsulation attribute which reflects the current set of a
ctive GWs.</t>
<t>If a gateway becomes disconnected from the backbone network, or if the s
ite operator decides to terminate
the gateway&apos;s activity, it MUST withdraw the advertisements describ
ed above. This means that remote gateways
at other sites will stop seeing advertisements from or about this gatewa
y. Note that if the routing within a site is
broken (for example, such that there is a route from one GW to another,
but not in the reverse direction), then
it is possible that incoming traffic will be routed to the wrong GW to r
each the destination prefix - in this
degraded network situation, traffic may be dropped.</t>
<t>Note that if a GW is (mis)configured with a different site identifier fr
om the other GWs to the
same site then it will not be auto-discovered by the other GWs (and will
not auto-discover the other
GWs). This would result in a GW for another site receiving only the Tun
nel Encapsulation attribute
included in the BGP best route; i.e., the Tunnel Encapsulation attribute
of the (mis)configured GW or that
of the other GWs.</t>
</section>
<section anchor="EPE" title="Relationship to BGP Link State and Egress Peer En
gineering">
<t>When a remote GW receives a route to a prefix X, it uses the Tunnel Egre
ss Endpoint Sub-TLVs in the containing
Tunnel Encapsulation attribute to identify the GWs through which X can b
e reached. It uses this information
to compute SR Traffic Engineering (SR TE) paths across the backbone netw
ork looking at the information
advertised to it in SR BGP Link State (BGP-LS) <xref target="I-D.ietf-id
r-bgp-ls-segment-routing-ext" />
and correlated using the site identity. SR Egress Peer Engineering (EPE
)
<xref target="I-D.ietf-idr-bgpls-segment-routing-epe" /> can be used to
supplement the information advertised
in BGP-LS.</t>
</section>
<section anchor="advertising" title="Advertising a Site Route Externally">
<t>When a packet destined for prefix X is sent on an SR TE path to a GW for
the site containing X (that is,
the packet is sent in the ingress site on an SR TE path that describes t
he whole path including those parts
that are within the egress site), it needs to carry the receiving GW&apo
s;s SID for X such that this SID
becomes the next SID that is due to be processed before the GW completes
its processing of the packet. To
achieve this, each Tunnel TLV in the Tunnel Encapsulation attribute cont
ains a Prefix-SID sub-TLV
<xref target="RFC9012" /> for X.</t>
<t>As defined in <xref target="RFC9012" />, the Prefix-SID sub-TLV is only
for IPv4/IPV6 labelled unicast routes,
so the solution described in this document only applies to routes of tho
se types. If the use of the Prefix-SID
sub-TLV for routes of other types is defined in the future, further docu
ments will be needed to describe their
use for site interconnection consistent with this document.</t>
<t>Alternatively, if MPLS SR is in use and if the GWs for a given egress si
te are configured to allow GWs at remote
ingress sites to perform SR TE through that egress site for a prefix X,
then each GW to the egress site computes
an SR TE path through the egress site to X, and places each in an MPLS l
abel stack sub-TLV <xref target="RFC9012" />
in the SR Tunnel TLV for that GW.</t>
<t>Please refer to Section 7 of <xref target="I-D.farrel-spring-sr-domain-i
nterconnect" /> for worked examples of
how the SID stack is constructed in this case, and how the advertisement
s would work.</t>
</section>
<section anchor="encaps" title="Encapsulation">
<t>If a site is configured to allow remote GWs send packets to the site in
the site&apos;s native encapsulation, then
each GW to the site will also include multiple instances of a Tunnel TL
V for that native encapsulation in externally
advertised routes: one for each GW and each containing a Tunnel Egress E
ndpoint sub-TLV with that GW&apos;s address.
A remote GW may then encapsulate a packet according to the rules defined
via the sub-TLVs included in each of the
Tunnel TLVs.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>IANA maintains a registry called "Border Gateway Protocol (BGP)
Parameters" with a sub-registry called "BGP Tunnel Encapsulation
Attribute Tunnel Types." The registration policy for this registry
is First-Come First-Served <xref target="RFC8126" />.</t>
<t>IANA previously assigned the value 17 from this sub-registry for "SR
Tunnel", referencing this document. IANA is now requested to mark
that assignment as deprecated. IANA may reclaim that codepoint at
such a time that the registry is depleted.</t>
</section>
<section anchor="security" title="Security Considerations"> <li>A Tunnel Encapsulation attribute (<xref target="RFC9012"
<t>From a protocol point of view, the mechanisms described in this document format="default"/>) containing the GW's encapsulation information
can leverage the security mechanisms already encoded in one or more Tunnel TLVs.</li>
defined for BGP. Further discussion of security considerations for BGP </ul>
may be found in the BGP specification itself <t>To avoid the side effect of applying the Tunnel Encapsulation
<xref target="RFC4271" /> and in the security analysis for BGP <xref tar attribute to any packet that is addressed to the GW itself, the address
get="RFC4272" />. The original discussion of advertised for auto-discovery <bcp14>MUST</bcp14> be a different
the use of the TCP MD5 signature option to protect BGP sessions is found loopback address than is advertised for packets directed to the gateway
in <xref target="RFC5925" />, while itself.</t>
<xref target="RFC6952" /> includes an analysis of BGP keying and authent <t>As described in <xref target="introduction" format="default"/>, each
ication issues.</t> GW will include a Tunnel Encapsulation attribute with the GW
encapsulation information for each of the site's active GWs (including
itself) in every route advertised externally to that site. As the
current set of active GWs changes (due to the addition of a new GW or
the failure/removal of an existing GW), each externally advertised route
will be re-advertised with a new Tunnel Encapsulation attribute, which
reflects the current set of active GWs.</t>
<t>If a gateway becomes disconnected from the backbone network, or if
the site operator decides to terminate the gateway's activity, it
<bcp14>MUST</bcp14> withdraw the advertisements described above. This
means that remote gateways at other sites will stop seeing
advertisements from or about this gateway. Note that if the routing
within a site is broken (for example, such that there is a route from
one GW to another but not in the reverse direction), then it is
possible that incoming traffic will be routed to the wrong GW to reach
the destination prefix; in this degraded network situation, traffic may
be dropped.</t>
<t>Note that if a GW is (mis)configured with a different site identifier
from the other GWs to the same site, then it will not be auto-discovered
by the other GWs (and will not auto-discover the other GWs). This would
result in a GW for another site receiving only the Tunnel Encapsulation
attribute included in the BGP best route, i.e., the Tunnel Encapsulation
attribute of the (mis)configured GW or that of the other GWs.</t>
</section>
<section anchor="EPE" numbered="true" toc="default">
<name>Relationship to BGP - Link State and Egress Peer Engineering</name>
<t>When a remote GW receives a route to a prefix X, it uses the Tunnel
Egress Endpoint sub-TLVs in the containing Tunnel Encapsulation
attribute to identify the GWs through which X can be reached. It uses
this information to compute SR Traffic Engineering (SR TE) paths across
the backbone network looking at the information advertised to it in SR
BGP - Link State (BGP-LS) (<xref
target="RFC9085" format="default"/>) and
correlated using the site identity. SR Egress Peer Engineering (EPE)
(<xref target="RFC9086"
format="default"/>) can be used to supplement the information advertised
in BGP-LS.</t>
</section>
<section anchor="advertising" numbered="true" toc="default">
<name>Advertising a Site Route Externally</name>
<t>When a packet destined for prefix X is sent on an SR TE path to a GW
for the site containing X (that is, the packet is sent in the ingress
site on an SR TE path that describes the whole path including those
parts that are within the egress site), it needs to carry the receiving
GW's SID for X such that this SID becomes the next SID that is due to be
processed before the GW completes its processing of the packet. To
achieve this, each Tunnel TLV in the Tunnel Encapsulation attribute
contains a Prefix-SID sub-TLV (<xref target="RFC9012"
format="default"/>) for X.</t>
<t>As defined in <xref target="RFC9012" format="default"/>, the
Prefix-SID sub-TLV is only for IPv4/IPV6 Labeled Unicast routes, so the
solution described in this document only applies to routes of those
types. If the use of the Prefix-SID sub-TLV for routes of other types
is defined in the future, further documents will be needed to describe
their use for site interconnection consistent with this document.</t>
<t>Alternatively, if MPLS SR is in use and if the GWs for a given egress
site are configured to allow GWs at remote ingress sites to perform SR
TE through that egress site for a prefix X, then each GW to the egress
site computes an SR TE path through the egress site to X and places each
in an MPLS Label Stack sub-TLV (<xref target="RFC9012"
format="default"/>) in the SR Tunnel TLV for that GW.</t>
<t>Please refer to <xref
target="I-D.farrel-spring-sr-domain-interconnect" sectionFormat="of"
section="7" format="default"/> for worked examples of how the SID stack
is constructed in this case and how the advertisements would work.</t>
</section>
<t>The mechanisms described in this document involve sharing routing or rea <section anchor="encaps" numbered="true" toc="default">
chability information between sites: that may <name>Encapsulation</name>
mean disclosing information that is normally contained within a site. S
o it needs to be understood that normal security
paradigms based on the boundaries of sites are weakened and interception
of BGP messages may result in information being
disclosed to third parties. Discussion of these issues with respect to
VPNs can be found in <xref target="RFC4364" />,
while <xref target="RFC7926" /> describes many of the issues associated
with the exchange of topology or TE information
between sites.</t>
<t>Particular exposures resulting from this work include: <t>
<list style="symbols"> If a site is configured to allow remote GWs to send packets to the site in
<t>Gateways to a site will know about all other gateways to the same s the site's native encapsulation, then each GW to the site will also include
ite. This feature applies within a site multiple instances of a Tunnel TLV for that native encapsulation in
and so is not a substantial exposure, but it does mean that if the externally advertised routes: one for each GW. Each Tunnel TLV contains a
BGP exchanges within a site can be snooped or Tunnel Egress Endpoint sub-TLV with the address of the GW that the Tunnel TLV
if a gateway can be subverted then an attacker may learn the full s identifies. A remote GW may then encapsulate a packet according to the rules
et of gateways to a site. This would facilitate defined via the sub-TLVs included in each of the Tunnel TLVs.</t>
more effective attacks on that site.</t> </section>
<section anchor="iana" numbered="true" toc="default">
<name>IANA Considerations</name>
<t>The existence of multiple gateways to a site becomes more visible a <t>
cross the backbone and even into remote sites. IANA maintains the "BGP Tunnel Encapsulation Attribute Tunnel
This means that an attacker is able to prepare a more comprehensive Types” registry in the "Border Gateway Protocol (BGP) Tunnel
attack than exists when only the locally attached Encapsulation" registry.
backbone network (e.g., the AS that hosts the site) can see all of </t>
the gateways to a site. For example, a Denial of
Service attack on a single GW is mitigated by the existence of othe
r GWs, but if the attacker knows about all the
gateways then the whole set can be attacked at once.</t>
<t>A node in a site that does not have external BGP peering (i.e., is <t>
not really a site gateway and cannot speak BGP IANA had previously assigned the value 17 from this subregistry
into the backbone network) may be able to get itself advertised as for "SR Tunnel", referencing this document as an Internet-Draft.
a gateway by letting other genuine gateways discover At that time, the assignment policy for this range of the registry
it (by speaking BGP to them within the site) and so may get those g was "First Come First Served" <xref target="RFC8126"/>.
enuine gateways to advertise it as a gateway into </t>
the backbone network. This would allow the malicious node to attra <t>
ct traffic without having to have secure BGP peerings
with out-of-site nodes.</t>
<t>An external party intercepting BGP messages anywhere between sites IANA has marked that assignment as deprecated. IANA may reclaim that
may learn information about the functioning of the codepoint at such a time that the registry is depleted.
sites and the locations of end points. While this is not necessari
ly a significant security or privacy risk, it is
possible that the disclosure of this information could be used by a
n attacker.</t>
<t>If it is possible to modify a BGP message within the backbone, it m </t>
ay be possible to spoof the existence of a
gateway. This could cause traffic to be attracted to a specific no
de and might result in black-holing of traffic.</t>
</list></t>
<t>All of the issues in the list above could cause disruption to site inter </section>
connection, but are not new protocol vulnerabilities <section anchor="security" numbered="true" toc="default">
so much as new exposures of information that SHOULD be protected against <name>Security Considerations</name>
using existing protocol mechanisms such as securing <t>From a protocol point of view, the mechanisms described in this
the TCP sessions over which the BGP messages flow. Furthermore, it is a document can leverage the security mechanisms already defined for BGP.
general observation that if these attacks are Further discussion of security considerations for BGP may be found in
possible then it is highly likely that far more significant attacks can the BGP specification itself (<xref target="RFC4271" format="default"/>)
be made on the routing system. It should be noted and in the security analysis for BGP (<xref target="RFC4272"
that BGP peerings are not discovered, but always arise from explicit con format="default"/>). The original discussion of the use of the TCP MD5
figuration.</t> signature option to protect BGP sessions is found in <xref
target="RFC5925" format="default"/>, while <xref target="RFC6952"
format="default"/> includes an analysis of BGP keying and authentication
issues.</t>
<t>The mechanisms described in this document involve sharing routing or
reachability information between sites, which may mean disclosing
information that is normally contained within a site. So it needs to be
understood that normal security paradigms based on the boundaries of
sites are weakened and interception of BGP messages may result in
information being disclosed to third parties. Discussion of these
issues with respect to VPNs can be found in <xref target="RFC4364"
format="default"/>, while <xref target="RFC7926" format="default"/>
describes many of the issues associated with the exchange of topology or
TE information between sites.</t>
<t>Particular exposures resulting from this work include:
</t>
<ul spacing="normal">
<li>Gateways to a site will know about all other gateways to the same
site. This feature applies within a site, so it is not a substantial
exposure, but it does mean that if the BGP exchanges within a site can
be snooped or if a gateway can be subverted, then an attacker may learn
the full set of gateways to a site. This would facilitate more
effective attacks on that site.</li>
<li>The existence of multiple gateways to a site becomes more visible
across the backbone and even into remote sites. This means that an
attacker is able to prepare a more comprehensive attack than exists
when only the locally attached backbone network (e.g., the AS that
hosts the site) can see all of the gateways to a site. For example, a
Denial-of-Service attack on a single GW is mitigated by the existence
of other GWs, but if the attacker knows about all the gateways, then
the whole set can be attacked at once.</li>
<li>A node in a site that does not have external BGP peering (i.e., is
not really a site gateway and cannot speak BGP into the backbone
network) may be able to get itself advertised as a gateway by letting
other genuine gateways discover it (by speaking BGP to them within the
site), so it may get those genuine gateways to advertise it as a
gateway into the backbone network. This would allow the malicious
node to attract traffic without having to have secure BGP peerings
with out-of-site nodes.</li>
<li>An external party intercepting BGP messages anywhere between sites
may learn information about the functioning of the sites and the
locations of endpoints. While this is not necessarily a significant
security or privacy risk, it is possible that the disclosure of this
information could be used by an attacker.</li>
<t>Given that the gateways and ASBRs are connected by tunnels that may run <li>If it is possible to modify a BGP message within the backbone, it
across parts of the network that are not trusted, may be possible to spoof the existence of a gateway. This could cause
data center operators using the approach set out in this network MUST co traffic to be attracted to a specific node and might result in traffic
nsider using gateway-to-gateway encryption to not being delivered.
protect the data center traffic. Additionally, due consideration MUST b </li>
e given to encrypting end-to-end traffic as it
would be for any traffic that uses a public or untrusted network for tra
nsport.</t>
</section> </ul>
<t>All of the issues in the list above could cause disruption to site
interconnection, but they are not new protocol vulnerabilities so much
as new exposures of information that <bcp14>SHOULD</bcp14> be protected
against using existing protocol mechanisms such as securing the TCP
sessions over which the BGP messages flow. Furthermore, it is a general
observation that if these attacks are possible, then it is highly likely
that far more significant attacks can be made on the routing system. It
should be noted that BGP peerings are not discovered but always arise
from explicit configuration.</t>
<t>Given that the gateways and ASBRs are connected by tunnels that may
run across parts of the network that are not trusted, data center
operators using the approach set out in this network <bcp14>MUST</bcp14>
consider using gateway-to-gateway encryption to protect the data center
traffic. Additionally, due consideration <bcp14>MUST</bcp14> be given
to encrypting end-to-end traffic as it would be for any traffic that
uses a public or untrusted network for transport.</t>
</section>
<section anchor="manageability" numbered="true" toc="default">
<name>Manageability Considerations</name>
<t>The principal configuration item added by this solution is the
allocation of a site identifier. The same identifier
<bcp14>MUST</bcp14> be assigned to every GW to the same site, and each
site <bcp14>MUST</bcp14> have a different identifier. This requires
coordination, probably through a central management agent.</t>
<t>It should be noted that BGP peerings are not discovered but always
arise from explicit configuration. This is no different from any other
BGP operation.</t>
<t>The site identifiers that are configured and carried in route targets
(see <xref target="DCGWautodisco" format="default"/>) are an important
feature to ensure that all of the gateways to a site discover each
other. Therefore, it is important that this value is not misconfigured
since that would result in the gateways not discovering each other and
not advertising each other.</t>
<section anchor="manageability" title="Manageability Considerations"> <section anchor="rtc" numbered="true" toc="default">
<t>The principal configuration item added by this solution is the allocatio
n of a site identifier. The same identifier
MUST be assigned to every GW to the same site, and each site MUST have a
different identifier. This requires coordination,
probably through a central management agent.</t>
<t>It should be noted that BGP peerings are not discovered, but always aris <name>Relationship to Route Target Constraint</name>
e from explicit configuration. This is no different
from any other BGP operation.</t>
<t>The site identifiers that are configured and carried in route targets (s <t>
ee <xref target="DCGWautodisco" />) are an important
feature to ensure that all of the gateways to a site discover each other
. It is, therefore, important that this value is
not misconfigured since that would result in the gateways not discoverin
g each other and not advertising each other.</t>
<section anchor="rtc" title="Relationship to Route Target Constraint"> In order to limit the VPN routing information that is maintained at a given
<t>In order to limit the VPN routing information that is maintained at a route reflector, <xref target="RFC4364"/> suggests that route reflectors use
given route reflector, <xref target="RFC4364" /> "Cooperative Route Filtering", which was renamed "Outbound Route Filtering"
suggests the use of "Cooperative Route Filtering" <xref target="RFC52 and defined in <xref target="RFC5291"/>.
91" /> between route reflectors. <xref target="RFC4684" />
defines an extension to that mechanism to include support for multipl
e autonomous systems and asymmetric VPN topologies such
as hub-and-spoke. The mechanism in RFC 4684 is known as Route Target
Constraint (RTC).</t>
<t>An operator would not normally configure RTC by default for any AFI/S <xref
AFI combination, and would only enable it after careful target="RFC4684" format="default"/> defines an extension to that
consideration. When using the mechanisms defined in this document, t mechanism to include support for multiple autonomous systems and
he operator should consider carefully the effects of asymmetric VPN topologies such as hub-and-spoke. The mechanism in RFC
filtering routes. In some cases this may be desirable, and in others 4684 is known as Route Target Constraint (RTC).</t>
it could limit the effectiveness of the procedures.</t>
</section>
</section>
<!-- <t>An operator would not normally configure RTC by default for any
<section anchor="contrib" title="Contributors"> AFI/SAFI combination and would only enable it after careful
<t>The following people contributed to discussions that led to the consideration. When using the mechanisms defined in this document,
development of this document:</t> the operator should carefully consider the effects of filtering
routes. In some cases, this may be desirable, and in others, it could
limit the effectiveness of the procedures.</t>
</section>
</section>
<figure> </middle>
<artwork align="left"> <back>
<![CDATA[
TBD
name
Email: email
]]>
</artwork>
</figure>
</section>
<section anchor="acks" title="Acknowledgements"> <displayreference target="I-D.farrel-spring-sr-domain-interconnect" to="SR-INTER
<t>Thanks to Bruno Rijsman, Stephane Litkowski, Boris Hassanov, Linda Dunba CONNECT"/>
r, Ravi Singh, and Daniel Migault for review
comments, and to Robert Raszuk for useful discussions. Gyan Mishra prov
ided a helpful GenArt review, and John
Scudder and Benjamin Kaduk made helpful comments during IESG review.</t>
</section>
</middle> <references>
<name>References</name>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4271.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4360.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4760.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5925.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7752.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.9012.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4272.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4364.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4684.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5291.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6952.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7911.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7926.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8126.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8402.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9085.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.9086.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-farrel-
spring-sr-domain-interconnect.xml"/>
<back> </references>
<references title="Normative References"> </references>
&RFC2119;
&RFC4271;
&RFC4360;
&RFC4760;
&RFC5925;
&RFC7752;
&RFC8174;
&RFC9012;
</references>
<references title="Informative References"> <section anchor="acks" numbered="false" toc="default">
&RFC4272; <name>Acknowledgements</name>
&RFC4364; <t>Thanks to <contact fullname="Bruno Rijsman"/>, <contact
&RFC4684; fullname="Stephane Litkowski"/>, <contact fullname="Boris Hassanov"/>,
&RFC5291; <contact fullname="Linda Dunbar"/>, <contact fullname="Ravi Singh"/>,
&RFC6952; and <contact fullname="Daniel Migault"/> for review comments, and to
&RFC7911; <contact fullname="Robert Raszuk"/> for useful discussions. <contact
&RFC7926; fullname="Gyan Mishra"/> provided a helpful GenArt review, and <contact
&RFC8126; fullname="John Scudder"/> and <contact fullname="Benjamin Kaduk"/> made
&RFC8402; helpful comments during IESG review.</t>
&I-D.farrel-spring-sr-domain-interconnect; </section>
&I-D.ietf-idr-bgp-ls-segment-routing-ext;
&I-D.ietf-idr-bgpls-segment-routing-epe;
</references>
</back> </back>
</rfc> </rfc>
 End of changes. 44 change blocks. 
566 lines changed or deleted 471 lines changed or added

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