rfc9494.original.xml   rfc9494.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
tf-idr-long-lived-gr-06" ipr="trust200902" updates="6368" obsoletes="" submissio
nType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRef
s="true" version="3">
<!-- xml2rfc v2v3 conversion 3.17.4 -->
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** --> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF" category=" std" consensus="true" docName="draft-ietf-idr-long-lived-gr-06" number="9494" ip r="trust200902" updates="6368" obsoletes="" xml:lang="en" tocInclude="true" tocD epth="4" symRefs="true" sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.17.4 -->
<front> <front>
<!-- The abbreviated title is used in the page header - it is only necessary <title abbrev="Long-Lived Graceful Restart">Long-Lived Graceful Restart for
if the BGP</title>
full title is longer than 39 characters --> <seriesInfo name="RFC" value="9494"/>
<title abbrev="Long-Lived Graceful Restart">Support for Long-lived BGP Grace
ful Restart</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-idr-long-lived-gr-06"/>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="James Uttaro" initials="J." surname="Uttaro"> <author fullname="James Uttaro" initials="J." surname="Uttaro">
<organization>Independent Contributor</organization> <organization>Independent Contributor</organization>
<address> <address>
<email>juttaro@ieee.org</email> <email>juttaro@ieee.org</email>
</address> </address>
</author> </author>
<author fullname="Enke Chen" initials="E." surname="Chen"> <author fullname="Enke Chen" initials="E." surname="Chen">
<organization>Palo Alto Networks</organization> <organization>Palo Alto Networks</organization>
<address> <address>
<email>enchen@paloaltonetworks.com</email> <email>enchen@paloaltonetworks.com</email>
</address> </address>
</author> </author>
<author fullname="Bruno Decraene" initials="B." surname="Decraene"> <author fullname="Bruno Decraene" initials="B." surname="Decraene">
<organization>Orange</organization> <organization>Orange</organization>
<address> <address>
<email>bruno.decraene@orange.com</email> <email>bruno.decraene@orange.com</email>
</address> </address>
</author> </author>
<author fullname="John G. Scudder" initials="J. G." surname="Scudder">
<author fullname="John G. Scudder" initials="J." surname="Scudder">
<organization>Juniper Networks</organization> <organization>Juniper Networks</organization>
<address> <address>
<email>jgs@juniper.net</email> <email>jgs@juniper.net</email>
</address> </address>
</author> </author>
<date/> <date year="2023" month="November"/>
<!-- Meta-data Declarations --> <area>rtg</area>
<workgroup>idr</workgroup>
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. --
>
<keyword>template</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract> <abstract>
<t> <t>
In this document, we introduce a new BGP capability termed "Long-lived This document introduces a BGP capability called the "Long-Lived
Graceful Restart Capability" so that stale routes can be retained for a Graceful Restart Capability" (or "LLGR Capability"). The benefit of this capabi
longer time upon session failure than is provided for by BGP Graceful lity is that stale routes can be retained for a
Restart (RFC 4724). A well-known BGP community longer time upon session failure than is provided for by BGP Graceful Restart (a
s described in RFC 4724). A well-known BGP community called
"LLGR_STALE" is introduced for marking stale routes retained for a "LLGR_STALE" is introduced for marking stale routes retained for a
longer time. A second well-known BGP community, "NO_LLGR", is introduced longer time. A second well-known BGP community called "NO_LLGR" is introduced
to mark routes for which these procedures should not be applied. for marking routes for which these procedures should not be applied.
We also specify that such long-lived stale routes be treated as We also specify that such long-lived stale routes be treated as
the least-preferred, and their advertisements be limited to BGP speakers the least preferred and that their advertisements be limited to BGP speakers
that have advertised the new capability. Use of this extension is not that have advertised the capability. Use of this extension is not
advisable in all cases, and we provide guidelines to help determine if it advisable in all cases, and we provide guidelines to help determine if it
is. is.
</t> </t>
<t> <t>
This memo updates RFC 6368 by specifying that the LLGR_STALE community must be This memo updates RFC 6368 by specifying that the LLGR_STALE community must be
propagated into, or out of, the path attributes exchanged between PE and propagated into, or out of, the path attributes exchanged between the Provider E
CE. dge (PE) and Customer Edge (CE) routers.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" numbered="true" toc="default"> <section anchor="intro" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t> <t>
Historically, routing protocols in general, and BGP in particular, have been Routing protocols in general, and BGP in particular, have historically been
designed with a focus on correctness, where a key part of "correctness" is designed with a focus on "correctness", where a key part of correctness is
for each network element's forwarding state to converge toward the current for each network element's forwarding state to converge to the current
state of the network as quickly as possible. For this reason, the protocol state of the network as quickly as possible. For this reason, the protocol
was designed to remove state advertised by routers that went down (from a was designed to remove state advertised by routers that went down (from a
BGP perspective) as quickly as possible. Over time, this has been relaxed BGP perspective) as quickly as possible. Over time, this has been relaxed
somewhat, notably by BGP Graceful Restart (GR) <xref target="RFC4724" format="de fault"/>; somewhat, notably by BGP Graceful Restart (GR) <xref target="RFC4724" format="de fault"/>;
however, the paradigm however, the paradigm
has remained one of attempting to rapidly remove "stale" state from the has remained one of attempting to rapidly remove stale state from the
network. network.
</t> </t>
<t> <t>
Over time, two phenomena have arisen that call into question the underlying Over time, two phenomena have arisen that call into question the underlying
assumptions of this paradigm. The first is the widespread adoption of assumptions of this paradigm.</t>
tunneled forwarding infrastructures, for example, MPLS. Such infrastructures <ol><li>The widespread adoption of
tunneled forwarding infrastructures (for example, MPLS). Such infrastructures
eliminate the risk of some types of forwarding loops that can arise in eliminate the risk of some types of forwarding loops that can arise in
hop-by-hop forwarding and thus reduce one of the motivations for strong hop-by-hop forwarding; thus, they reduce one of the motivations for strong
consistency between forwarding elements. The second is the increasing use consistency between forwarding elements.</li>
of BGP as a transport for data which is less closely associated with packet forw <li>The increasing use
arding of BGP as a transport for data that is less closely associated with packet forwa
rding
than was originally the case. Examples include the use of BGP for than was originally the case. Examples include the use of BGP for
autodiscovery (<xref target="RFC4761" format="default">VPLS</xref>) and filter p auto-discovery (<xref target="RFC4761" format="default">Virtual Private LAN Serv
rogramming ice (VPLS)</xref>) and filter programming
(<xref target="RFC8955" format="default">FLOWSPEC</xref>). In these cases, (<xref target="RFC8955" format="default">Flow Specification (FLOWSPEC)</xref>).
BGP data takes on a character more akin to configuration than to traditional In these cases,
routing. BGP data takes on a character more akin to configuration than to conventional
</t> routing.</li></ol>
<t> <t>
The observations above motivate a desire to offer network operators the The observations above motivate a desire to offer network operators the
ability to choose to retain BGP data for a longer period than has hitherto ability to choose to retain BGP data for a longer period than has hitherto
been possible when the BGP control plane fails for some reason. Although been possible when the BGP control plane fails for some reason. Although
the semantics of BGP Graceful Restart <xref target="RFC4724" format="default"/> are close to those desired, the semantics of BGP Graceful Restart <xref target="RFC4724" format="default"/> are close to those desired,
several gaps exist, most notably in the maximum time for which "stale" informati several gaps exist, most notably in the maximum time for which stale information
on can be retained: Graceful Restart imposes a 4095-second upper bound.
can be retained -- Graceful Restart imposes a 4095-second upper bound.
</t> </t>
<t> <t>
In this document, we introduce a new BGP capability termed "Long-lived Graceful In this document, we introduce a BGP capability called the "Long-Lived Graceful
Restart Capability" so that stale information can be retained for a longer time Restart Capability". The goal of this capability is that stale information can b
across a session reset. We also introduce two new BGP well-known communities, "L e retained for a longer time
LGR_STALE", across a session reset. We also introduce two BGP well-known communities:<
to mark such information, and "NO_LLGR", to indicate that these procedures shoul /t>
d not <ul><li>LLGR_STALE to mark such information, and</li>
be applied to the marked route. Long-lived stale information is to be treated as <li>NO_LLGR to indicate that these procedures should not
least-preferred, be applied to the marked route.</li></ul>
<t>Long-lived stale information is to be treated as least preferred,
and its advertisement limited to BGP speakers that support the and its advertisement limited to BGP speakers that support the
new capability. Where possible, we reference the semantics of BGP Graceful capability. Where possible, we reference the semantics of BGP Graceful
Restart <xref target="RFC4724" format="default"/> rather than specifying similar semantics in this document. Restart <xref target="RFC4724" format="default"/> rather than specifying similar semantics in this document.
</t> </t>
<t> <t>
The expected deployment model for this extension is that it will only be invoked The expected deployment model for this extension is that it will only be invoked
for certain address families. This is discussed in more detail in <xref target=" for certain address families. This is discussed in more detail in <xref target="
deploy" format="default"> deploy" format="default"></xref>.
the Deployment Considerations section</xref>. When used, its use may be combined
with that of traditional Graceful Restart, in which case it is invoked only afte The use of this extension may be combined with that of conventional
r Graceful Restart; in such a case, it is invoked after the conventional
the traditional Graceful Restart interval has elapsed, or it may be invoked Graceful Restart interval has elapsed. When not combined, LLGR is invoked immed
immediately. Apart from the potential to greatly extend the timer, the most iately.
obvious difference between Long-Lived and traditional Graceful Restart is that
in the Long-Lived version, routes are "depreferenced", that is, treated as least Apart from the potential to greatly extend the timer, the most
-preferred, obvious difference between LLGR and conventional Graceful Restart is that
whereas in the traditional version, route preference is not affected. in LLGR, routes are "depreferenced"; that is, they are treated as least preferre
The design choice to treat Long-Lived Stale routes as least-preferred was inform d. Contrarily, in conventional GR, route preference is not affected.
ed by The design choice to treat long-lived stale routes as least preferred was inform
the expectation that they might be retained for a (potentially) almost ed by
unbounded period of time, whereas in the traditional Graceful Restart the expectation that they might be retained for (potentially) an almost
case, stale routes are retained for only a brief interval. In the Graceful Resta unbounded period of time; whereas, in the conventional Graceful Restart
rt case, the case, stale routes are retained for only a brief interval. In the case of Gracef
tradeoff between advertising new route status (at the cost of routing churn) ul Restart, the
trade-off between advertising new route status (at the cost of routing churn)
and not advertising it (at the cost of suboptimal or incorrect route selection) and not advertising it (at the cost of suboptimal or incorrect route selection)
is resolved in favor of not advertising. In the LLGR case, it is resolved in is resolved in favor of not advertising. In the case of LLGR, it is resolved in
favor of advertising new state, and using stale information only as a last resor favor of advertising new state, using stale information only as a last resort.
t.
</t> </t>
<t> <t>
<xref target="examples" format="default"/> provides some simple examples illustr ating the <xref target="examples" format="default"/> provides some simple examples illustr ating the
operation of this extension. operation of this extension.
</t> </t>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<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
<xref target="RFC2119" format="default">BCP 14</xref> <xref target="RFC8174"
format="default"/> when,
and only when, they appear in all capitals, as shown here.
</t>
</section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Definitions</name> <name>Terminology</name>
<dl newline="false" spacing="normal" indent="2"> <section numbered="true" toc="default">
<dt>CE:</dt> <name>Definitions</name>
<dd> <dl newline="false" spacing="normal" indent="2">
A Customer Edge router. <xref target="RFC4364" format="default"/> <dt>Depreference:</dt>
</dd>
<dt>Depreference, Depreferenced:</dt>
<dd> <dd>
A route is said to be depreferenced if A route is said to be depreferenced if
it has its route selection preference reduced in reaction to some it has its route selection preference reduced in reaction to some
event. event.
</dd> </dd>
<dt>Helper:</dt>
<dd>
Sometimes referred to as "helper router". During Graceful Restart or Long-Lived
Graceful Restart, the router that detects a session failure and
applies the listed procedures. <xref target="RFC4724" format="default"/> refers
to this as the
"receiving speaker".
</dd>
<dt>Route:</dt>
<dd>
In this document, "route" means any information encoded as BGP Network Layer Rea
chability Information (NLRI) and a
set of path attributes. As discussed above, the connection between such
routes and the installation of forwarding state may be quite remote.
</dd>
</dl>
<t>Further note that, for brevity, in this document when we reference con
ventional Graceful
Restart, we cite its base specification, <xref target="RFC4724" format="default"
/>. That specification has been updated by <xref target="RFC8538" format="defaul
t"/>. The citation to <xref target="RFC4724" format="default"/>
is not intended to be limiting.</t>
</section>
<section numbered="true" toc="default">
<name>Abbreviations</name>
<dl newline="false" spacing="normal" indent="2">
<dt>CE:</dt>
<dd>Customer Edge (See <xref target="RFC4364" format="default"/> for mor
e information on Customer Edge routers.)
</dd>
<dt>EoR:</dt> <dt>EoR:</dt>
<dd> <dd>
Marker for End-of-RIB, defined in <xref target="RFC4724" format="default"/> Sect ion 2. End-of-RIB (See <xref target="RFC4724" sectionFormat="of" section="2"/> for more information on End-of-RIB markers.)
</dd> </dd>
<dt>GR:</dt> <dt>GR:</dt>
<dd> <dd>
Abbreviation for "Graceful Restart" <xref target="RFC4724" format="default"/>, a lso sometimes Graceful Restart (See <xref target="RFC4724" format="default"/> for more informa tion on GR.) This term is also sometimes
referred to herein as "conventional Graceful Restart" or referred to herein as "conventional Graceful Restart" or
"conventional GR" to distinguish it from the "Long-lived Graceful "conventional GR" to distinguish it from the "Long-Lived Graceful
Restart" defined by this document. Restart" or "LLGR" defined by this document.
</dd>
<dt>Helper:</dt>
<dd>
Or "helper router". During Graceful Restart or Long-lived
Graceful Restart, the router that detects a session failure and
applies the listed procedures. <xref target="RFC4724" format="default"/> refers
to this as the
"receiving speaker".
</dd> </dd>
<dt>LLGR:</dt> <dt>LLGR:</dt>
<dd> <dd>
Abbreviation for "Long-lived Graceful Restart". Long-Lived Graceful Restart
</dd> </dd>
<dt>LLST:</dt> <dt>LLST:</dt>
<dd> <dd>
Abbreviation for "Long-lived Stale Time". Long-Lived Stale Time
</dd> </dd>
<dt>PE:</dt> <dt>PE:</dt>
<dd> <dd>
A Provider Edge router. <xref target="RFC4364" format="default"/> Provider Edge (See <xref target="RFC4364" format="default"/> for more informatio n on Provider Edge routers.)
</dd> </dd>
<dt>Route:</dt>
<dd>
We use "route" to mean any information encoded as a BGP NLRI and
set of path attributes. As discussed above, the connection between such
routes and the installation of forwarding state may be quite remote.
</dd>
<dt>VRF:</dt> <dt>VRF:</dt>
<dd> <dd>
VPN Routing and Forwarding table. <xref target="RFC4364" format="default"/> VPN Routing and Forwarding (See <xref target="RFC4364" format="default"/> for m ore information on VRF tables.)
</dd> </dd>
</dl> </dl>
</section> </section>
<section numbered="true" toc="default">
<name>Requirements Language</name>
<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>
</section>
</section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Protocol Extensions</name> <name>Protocol Extensions</name>
<t> <t>
A new BGP capability and two new BGP communities are introduced. A BGP capability and two BGP communities are introduced in the subsections that follow.
</t> </t>
<section anchor="llgr_cap" numbered="true" toc="default"> <section anchor="llgr_cap" numbered="true" toc="default">
<name>Long-lived Graceful Restart Capability</name> <name>Long-Lived Graceful Restart Capability</name>
<t> <t>
The "Long-lived Graceful Restart Capability", or "LLGR Capability" The "Long-Lived Graceful Restart Capability", or "LLGR Capability",
(value: 71) is a BGP capability <xref target="RFC5492" format="default"/> (value: 71) is a BGP capability <xref target="RFC5492" format="default"/>
that can be used by a BGP speaker to indicate its ability to preserve that can be used by a BGP speaker to indicate its ability to preserve
its state according to the procedures of this document. This its state according to the procedures of this document. If the LLGR capability
capability MUST be advertised in conjunction with the Graceful Restart is advertised, the Graceful Restart capability <xref target="RFC4724" format="d
capability <xref target="RFC4724" format="default"/>, see <xref target="use_of_g efault"/>
r" format="default">the "Use of Graceful Restart Capability" <bcp14>MUST</bcp14> also be advertised; see <xref target="use_of_gr" format="def
section</xref>. ault"></xref>.
</t> </t>
<t> <t>
The capability value consists of zero or more tuples &lt;AFI, SAFI, The capability value consists of zero or more tuples &lt;AFI, SAFI,
Flags, Long-lived Stale Time&gt; as follows: Flags, LLST&gt; as follows:
</t> </t>
<artwork align="left" name="" type="" alt=""><![CDATA[ <artwork align="left" name="" type="" alt=""><![CDATA[
+--------------------------------------------------+ +--------------------------------------------------+
| Address Family Identifier (16 bits) | | Address Family Identifier (16 bits) |
+--------------------------------------------------+ +--------------------------------------------------+
| Subsequent Address Family Identifier (8 bits) | | Subsequent Address Family Identifier (8 bits) |
+--------------------------------------------------+ +--------------------------------------------------+
| Flags for Address Family (8 bits) | | Flags for Address Family (8 bits) |
+--------------------------------------------------+ +--------------------------------------------------+
| Long-lived Stale Time (24 bits) | | Long-Lived Stale Time (24 bits) |
+--------------------------------------------------+ +--------------------------------------------------+
| ... | | ... |
+--------------------------------------------------+ +--------------------------------------------------+
| Address Family Identifier (16 bits) | | Address Family Identifier (16 bits) |
+--------------------------------------------------+ +--------------------------------------------------+
| Subsequent Address Family Identifier (8 bits) | | Subsequent Address Family Identifier (8 bits) |
+--------------------------------------------------+ +--------------------------------------------------+
| Flags for Address Family (8 bits) | | Flags for Address Family (8 bits) |
+--------------------------------------------------+ +--------------------------------------------------+
| Long-lived Stale Time (24 bits) | | Long-Lived Stale Time (24 bits) |
+--------------------------------------------------+ +--------------------------------------------------+
]]></artwork> ]]></artwork>
<t> <t>
The meaning of the fields are as follows: The meaning of the fields are as follows:
</t> </t>
<ul empty="true" spacing="normal"> <dl newline="true" spacing="normal">
<li> <dt>
Address Family Identifier (AFI), Subsequent Address Family Address Family Identifier (AFI), Subsequent Address Family
Identifier (SAFI): Identifier (SAFI):
</dt>
</li> <dd><t>
<li>
<ul empty="true" spacing="compact">
<li>
The AFI and SAFI, taken in combination, indicate that the BGP The AFI and SAFI, taken in combination, indicate that the BGP
speaker has the ability to preserve its forwarding state for speaker has the ability to preserve its forwarding state for
the address family during a subsequent BGP restart. Routes may the address family during a subsequent BGP restart. Routes may
be explicitly associated with a particular AFI and SAFI using be either:</t>
the encoding of <xref target="RFC4760" format="default"/> or implicitly as
sociated with
&lt;AFI=IPv4, SAFI=Unicast&gt; if using the encoding of <xref target="RFC4
271" format="default"/>.
</li>
</ul>
</li>
<li>
Flags for Address Family:
</li> <ul><li>explicitly associated with a particular AFI and SAFI if using
<li> the encoding described in <xref target="RFC4760" format="default"/>, or</l
<ul empty="true" spacing="compact"> i>
<li>
<li>implicitly associated with
&lt;AFI=IPv4, SAFI=Unicast&gt; if using the encoding described in <xref ta
rget="RFC4271" format="default"/>.</li></ul>
</dd>
<dt>
Flags for Address Family:</dt>
<dd>
This field contains bit flags relating to routes that were This field contains bit flags relating to routes that were
advertised with the given AFI and SAFI. advertised with the given AFI and SAFI.</dd>
</li> </dl>
</ul> <artwork name="" type="" align="center" alt=""><![CDATA[
</li> 0 1 2 3 4 5 6 7
</ul> +-+-+-+-+-+-+-+-+
<artwork name="" type="" align="left" alt=""><![CDATA[ |F| Reserved |
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+
|F| Reserved |
+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
<ul empty="true" spacing="compact"> -+-+-+-+-+-+-+-+
<li>
<ul empty="true" spacing="compact"> <ul empty="true" spacing="compact">
<li> <li>
The most significant bit is used to indicate whether the The most significant bit is used to indicate whether the
state for routes that were advertised with the given AFI and state for routes that were advertised with the given AFI and
SAFI has indeed been preserved during the previous BGP restart. SAFI has indeed been preserved during the previous BGP restart.
When set (value 1), the bit indicates that the state has been When set (value 1), the bit indicates that the state has been
preserved. This bit is called the "F bit" since it was preserved. This bit is called the "F bit" since it was
historically used to indicate the preservation of Forwarding State. historically used to indicate the preservation of forwarding state.
Use of the F bit is detailed in the <xref target="session_resets" format=" Use of the F bit is detailed in <xref target="session_resets" format="defa
default"> ult"></xref>.
Session Resets section</xref>. The remaining bits are reserved and <bcp14>MUST</bcp14> be set to zero by
</li> the
<li>
The remaining bits are reserved and MUST be set to zero by the
sender and ignored by the receiver. sender and ignored by the receiver.
</li> </li>
</ul> </ul>
</li> <dl newline="true">
<li> <dt>
Long-lived Stale Time: Long-Lived Stale Time:</dt>
<dd>
</li>
<li>
<ul empty="true" spacing="compact">
<li>
This time (in seconds) specifies how long stale information This time (in seconds) specifies how long stale information
(for this AFI/SAFI) may be retained by the receiver (in addition (for this AFI/SAFI) may be retained by the receiver (in addition
with the period specified by the "Restart Time" in the to the period specified by the "Restart Time" in the
Graceful Restart Capability). Because the potential use cases for Graceful Restart Capability). Because the potential use cases for
this extension vary widely, there is no suggested default this extension vary widely, there is no suggested default
value for the LLST. value for the LLST.
</li> </dd>
</ul> </dl>
</li>
</ul>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>LLGR_STALE Community</name> <name>LLGR_STALE Community</name>
<t> <t>
The well-known BGP community <xref target="RFC1997" format="default"/> The well-known BGP community LLGR_STALE (value: 0xFFFF0006) can be used to mark
"LLGR_STALE" (value: 0xFFFF0006) can be used to mark stale routes stale routes
retained for a longer period of time. Such long-lived stale routes are to retained for a longer period of time (see <xref target="RFC1997" format="default
be handled according to the procedures specified in the <xref target="operation" "/> for more information on BGP communities). Such long-lived stale routes are t
format="default">Theory of Operation section</xref>. o
be handled according to the procedures specified in <xref target="operation" for
mat="default"></xref>.
</t> </t>
<t> <t>
An implementation MAY allow users to configure policies that accept, An implementation <bcp14>MAY</bcp14> allow users to configure policies that acce pt,
reject, or modify routes based on the presence or absence of this community. reject, or modify routes based on the presence or absence of this community.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>NO_LLGR Community</name> <name>NO_LLGR Community</name>
<t> <t>
The well-known BGP community "NO_LLGR" (value: 0xFFFF0007) can be The well-known BGP community NO_LLGR (value: 0xFFFF0007) can be
used to mark routes that a BGP speaker does not want to be treated according to used to mark routes that a BGP speaker does not want to be treated according to
these procedures, as detailed in <xref target="operation" format="default">the O these procedures, as detailed in <xref target="operation" format="default"></xre
peration f>.
section</xref>.
</t> </t>
<t> <t>
An implementation MAY allow users to configure policies that accept, An implementation <bcp14>MAY</bcp14> allow users to configure policies that acce pt,
reject, or modify routes based on the presence or absence of this community. reject, or modify routes based on the presence or absence of this community.
</t> </t>
</section> </section>
</section> </section>
<section anchor="operation" numbered="true" toc="default"> <section anchor="operation" numbered="true" toc="default">
<name>Theory of Operation</name> <name>Theory of Operation</name>
<t> <t>
If A BGP speaker is configured to support the procedures of this If a BGP speaker is configured to support the procedures of this
document, it MUST use <xref target="RFC5492" format="default">BGP Capabilities document, it <bcp14>MUST</bcp14> use <xref target="RFC5492" format="default">BGP
Advertisement</xref> to advertise the "Long-lived Graceful Restart Capabilities
Capability". The setting of the parameters for an AFI/SAFI depends on Advertisement</xref> to advertise the Long-Lived Graceful Restart
Capability. The setting of the parameters for an AFI/SAFI depends on
the properties of the BGP speaker, network scale, and local the properties of the BGP speaker, network scale, and local
configuration. configuration.
</t> </t>
<t> <t>
In the presence of the "Long-lived Graceful Restart Capability", the In the presence of the Long-Lived Graceful Restart Capability, the
procedures specified in <xref target="RFC4724" format="default"/> and <xref targ procedures specified in <xref target="RFC4724" format="default"/> continue to ap
et="RFC8538" format="default"/> continue to apply ply
unless explicitly revised by this document. unless explicitly revised by this document.
</t> </t>
<section anchor="use_of_gr" numbered="true" toc="default"> <section anchor="use_of_gr" numbered="true" toc="default">
<name>Use of Graceful Restart Capability</name> <name>Use of the Graceful Restart Capability</name>
<t> <t>
The Graceful Restart capability MUST be advertised in conjunction If the LLGR Capability is advertised, the Graceful Restart capability <bcp14>MU
with the LLGR capability. If it is not so advertised, the LLGR ST</bcp14> also be advertised. If it is not so advertised, the LLGR
capability MUST be disregarded. The purpose for mandating that both Capability <bcp14>MUST</bcp14> be disregarded. The purpose for mandating this
be used in conjunction is to enable the reuse of certain base mechanisms is to enable the reuse of certain base
that are common to both "flavors", notably origination, collection, mechanisms that are common to both "flavors" notably: origination,
and processing of EoR, as well as the finite state machine modifications collection, and processing of EoR as well as the finite-state-machine modifica
and connection reset logic introduced by GR. tions and connection-reset logic introduced by GR.
</t> </t>
<t> <t>
We observe that if support for conventional Graceful Restart is not desired We observe that, if support for conventional Graceful Restart is not desired
for the session, the conventional GR phase can be skipped by omitting all for the session, the conventional GR phase can be skipped by omitting all
AFI/SAFI from the GR capability, advertising a Restart Time of zero, or AFIs/SAFIs from the GR Capability, advertising a Restart Time of zero, or
both. The <xref target="session_resets" format="default">Session Resets section< both. <xref target="session_resets" format="default"></xref>
/xref> discusses the interaction of conventional and LLGR.
discusses the interaction of conventional and long-lived GR.
</t> </t>
</section> </section>
<section anchor="session_resets" numbered="true" toc="default"> <section anchor="session_resets" numbered="true" toc="default">
<name>Session Resets</name> <name>Session Resets</name>
<t> <t>
<xref target="RFC4724" format="default">BGP Graceful Restart</xref>, updated by <xref target="RFC4724" format="default">BGP Graceful Restart</xref> defines cond
<xref target="RFC8538" format="default"/>, defines conditions itions
under which a BGP session can reset and have its associated routes under which a BGP session can reset and have its associated routes
retained. If such a reset occurs for a session for which the LLGR retained. If such a reset occurs for a session in which the LLGR
Capability has also been exchanged, the following procedures apply. Capability has also been exchanged, the following procedures apply:</t>
</t>
<t> <ul><li>
If the Graceful Restart Capability that was received does not list all If the Graceful Restart Capability that was received does not list all
AFI/SAFI supported by the session, then for those non-listed AFI/SAFI the AFIs/SAFIs supported by the session, then the GR Restart Time shall be deemed ze
GR "Restart Time" shall be deemed zero. Similarly, if the received LLGR ro for those AFIs/SAFIs that are not listed.</li>
Capability does not list all AFI/SAFI supported by the session, then for
those non-listed AFI/SAFI the "Long-lived Stale Time" shall be deemed zero. <li>Similarly, if the received LLGR
</t> Capability does not list all AFIs/SAFIs supported by the session, then the Long-
Lived Stale Time shall be deemed zero for those AFIs/SAFIs that are not listed.
</li></ul>
<t> <t>
The following text in <xref target="RFC4724" format="default">Section 4.2 of the The following text in <xref target="RFC4724" sectionFormat="of" section="4.2"/>
GR no longer applies:
specification</xref> no longer applies:
</t> </t>
<ul empty="true" spacing="normal"> <blockquote>
<li>
If the session does not get re-established within the "Restart If the session does not get re-established within the "Restart
Time" that the peer advertised previously, the Receiving Speaker Time" that the peer advertised previously, the Receiving Speaker
MUST delete all the stale routes from the peer that it is <bcp14>MUST</bcp14> delete all the stale routes from the peer that it is
retaining. retaining.
</li> </blockquote>
</ul>
<t> <t>
and the following procedures are specified instead: and the following procedures are specified instead:
</t> </t>
<t> <t>
After the session goes down, and before the session is re-established, After the session goes down, and before the session is re-established,
the stale routes for an AFI/SAFI MUST be retained. The interval for the stale routes for an AFI/SAFI <bcp14>MUST</bcp14> be retained. The interval f or
which they are retained is which they are retained is
limited by the sum of the "Restart Time" in the received Graceful Restart Capabi limited by the sum of the Restart Time in the received Graceful Restart Capabili
lity ty
and the "Long-lived Stale Time" in the received Long-lived Graceful and the Long-Lived Stale Time in the received Long-Lived Graceful
Restart Capability. The timers received in the Long-lived Graceful Restart Restart Capability. The timers received in the Long-Lived Graceful Restart
Capability SHOULD be modifiable by local configuration, which may impose either Capability <bcp14>SHOULD</bcp14> be modifiable by local configuration, which may
an upper or a lower bound, or both, on their respective values. impose an upper bound, a lower bound, or both on their respective values.
</t> </t>
<t> <t>
If the value of the "Restart Time" or the "Long-lived Stale Time" is zero, If the value of the Restart Time or the Long-Lived Stale Time is zero,
the duration of the corresponding period would be zero seconds. For the duration of the corresponding period would be zero seconds. For
example, if the "Restart Time" is zero and the "Long-lived Stale Time" is example, if the Restart Time is zero and the Long-Lived Stale Time is
nonzero, only the procedures particular to LLGR would apply. Conversely, if nonzero, only the procedures particular to LLGR would apply. Conversely, if
the "Long-lived Stale Time" is zero and the "Restart Time" is nonzero, only the Long-Lived Stale Time is zero and the Restart Time is nonzero, only
the procedures of GR would apply. If both are zero, none of these procedures the procedures of GR would apply. If both are zero, none of these procedures
would apply, only those of the base BGP specification (although EoR would would apply, only those of the base BGP specification <xref target="RFC4271" for mat="default"/> (although EoR would
still be used as detailed in <xref target="RFC4724" format="default"/>). And fin ally, if both still be used as detailed in <xref target="RFC4724" format="default"/>). And fin ally, if both
are nonzero, then the procedures would be applied serially -- first those of are nonzero, then the procedures would be applied serially: first those of
GR, then those of LLGR. We observe that during the first interval, while the GR and then those of LLGR. During the first interval, we observe that, while th
e
procedures of GR are in effect, route preference would not be affected. procedures of GR are in effect, route preference would not be affected.
During the second interval, while LLGR procedures are in effect, routes During the second interval, while LLGR procedures are in effect, routes
would be treated as least-preferred as specified elsewhere in this document. would be treated as least preferred as specified elsewhere in this document.
</t> </t>
<t> <t>
Once the "Restart Time" period ends (including the case that the "Restart Once the Restart Time period ends (including the case in which the Restart
Time" is zero), the LLGR period is said to have begun and the following Time is zero), the LLGR period is said to have begun and the following
procedures MUST be performed: procedures <bcp14>MUST</bcp14> be performed:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
For each AFI/SAFI for which it has received a nonzero "Long-lived For each AFI/SAFI for which it has received a nonzero Long-Lived
Stale Time", the helper router MUST start a timer for that Stale Time, the helper router <bcp14>MUST</bcp14> start a timer for that
"Long-lived Stale Time". If the timer for the "Long-lived Stale Long-Lived Stale Time. If the timer for the Long-Lived Stale
Time" for a given AFI/SAFI expires before the session is Time for a given AFI/SAFI expires before the session is
re-established, the helper MUST delete all stale routes of that re-established, the helper <bcp14>MUST</bcp14> delete all stale routes of t
hat
AFI/SAFI from the neighbor that it is retaining. AFI/SAFI from the neighbor that it is retaining.
</li> </li>
<li> <li>
The helper router MUST attach the LLGR_STALE community The helper router <bcp14>MUST</bcp14> attach the LLGR_STALE community
to the stale routes being retained. Note that this requirement to the stale routes being retained. Note that this requirement
implies that the routes would need to be readvertised, to implies that the routes would need to be readvertised in order to
disseminate the modified community. disseminate the modified community.
</li> </li>
<li> <li>
If any of the routes from the peer have been marked with If any of the routes from the peer have been marked with
the NO_LLGR community, either as sent by the peer, the NO_LLGR community, either as sent by the peer
or as the result of a configured policy, they or as the result of a configured policy, they
MUST NOT be retained, but MUST be removed as per the <bcp14>MUST NOT</bcp14> be retained and <bcp14>MUST</bcp14> be removed as p er the
normal operation of <xref target="RFC4271" format="default"/>. normal operation of <xref target="RFC4271" format="default"/>.
</li> </li>
<li> <li>
The helper router MUST perform the procedures listed under The helper router <bcp14>MUST</bcp14> perform the procedures listed in
<xref target="processing_lls" format="default"/>. <xref target="processing_lls" format="default"/>.
</li> </li>
</ul> </ul>
<t> <t>
Once the session is re-established, the procedures specified in <xref target="RF C4724" format="default"/> Once the session is re-established, the procedures specified in <xref target="RF C4724" format="default"/>
apply for the stale routes irrespective of whether the stale routes are apply for the stale routes irrespective of whether the stale routes are
retained during the "Restart Time" period or the "Long-lived Stale Time" period. retained during the Restart Time period or the Long-Lived Stale Time period.
However, in the case of consecutive restarts, the previously marked stale routes However, in the case of consecutive restarts, the previously marked stale routes
MUST NOT <bcp14>MUST NOT</bcp14>
be deleted before the timer for the "Long-lived Stale Time" expires. be deleted before the timer for the Long-Lived Stale Time expires.
</t> </t>
<t> <t>
Similarly to <xref target="RFC4724" format="default"/>, once the session is re-e Similar to <xref target="RFC4724" format="default"/>, once the LLGR Period begin
stablished, if the F bit s, the
Helper <bcp14>MUST</bcp14> immediately remove all the stale routes from the p
eer
that it is retaining for that address family if any of the
following occur:</t>
<ul>
<li>the F bit
for a specific address family is not set in the newly received LLGR for a specific address family is not set in the newly received LLGR
Capability, or if a specific address family is not included in the newly Capability, or</li>
received LLGR Capability, or if the LLGR and accompanying GR Capability are <li>a specific address family is not included in the newly
not received in the re-established session at all, then the Helper MUST received LLGR Capability, or</li>
immediately remove all the stale routes from the peer that it is retaining <li>the LLGR and accompanying GR Capability are
for that address family. not received in the re-established session at all.</li></ul>
</t>
<t> <t>
If a "Long-lived Stale Time" timer is running for routes with a given If a Long-Lived Stale Time timer is running for routes with a given
AFI/SAFI received from a peer, it MUST NOT be updated (other than by AFI/SAFI received from a peer, it <bcp14>MUST NOT</bcp14> be updated (other than
by
manual operator intervention) until the peer has established and manual operator intervention) until the peer has established and
synchronized a new session. The session is termed "synchronized" for a synchronized a new session. The session is termed "synchronized" for a
given AFI/SAFI once the EoR for that AFI/SAFI has been received from the given AFI/SAFI once the EoR for that AFI/SAFI has been received from the
peer, or once the Selection_Deferral_Timer discussed in <xref target="RFC4724" f ormat="default"/> expires. peer or once the Selection_Deferral_Timer discussed in <xref target="RFC4724" fo rmat="default"/> expires.
</t> </t>
<t> <t>
The value of a "Long-lived Stale Time" in the capability received The value of a Long-Lived Stale Time in the capability received
from a neighbor MAY be reduced by local configuration. from a neighbor <bcp14>MAY</bcp14> be reduced by local configuration.
</t> </t>
<t> <t>
While the session is down, the expiration of a "Long-lived Stale Time"
timer is treated analogously to the expiration of the "Restart Time" While the session is down, the expiration of a Long-Lived Stale Time
timer in Graceful Restart, other than applying only to the AFI/SAFI it timer is treated analogously to the expiration of the Restart Time
timer in <xref target="RFC4724" format="default" />, other than applying only to
the AFI/SAFI it
accompanies. However, the timer continues to run once the session has accompanies. However, the timer continues to run once the session has
re-established. The timer is neither stopped nor updated until EoR is re-established. The timer is neither stopped nor updated until the EoR marker is
received for the relevant AFI/SAFI from the peer. If the timer expires received for the relevant AFI/SAFI from the peer. If the timer expires
during synchronization with the peer, any stale routes that the peer has during synchronization with the peer, any stale routes that the peer has
not refreshed, are removed. If the session subsequently resets prior to not refreshed are removed. If the session subsequently resets prior to
becoming synchronized, any remaining routes (for the AFI/SAFI whose LLST becoming synchronized, any remaining routes (for the AFI/SAFI whose LLST
timer expired) MUST be removed immediately. timer expired) <bcp14>MUST</bcp14> be removed immediately.
</t> </t>
</section> </section>
<section anchor="processing_lls" numbered="true" toc="default"> <section anchor="processing_lls" numbered="true" toc="default">
<name>Processing LLGR_STALE Routes</name> <name>Processing LLGR_STALE Routes</name>
<t> <t>
A BGP speaker that has advertised the "Long-lived Graceful Restart A BGP speaker that has advertised the Long-Lived Graceful Restart
Capability" to a neighbor MUST perform the following upon Capability to a neighbor <bcp14>MUST</bcp14> perform the following upon
receiving a route from that neighbor with the "LLGR_STALE" community, receiving a route from that neighbor with the LLGR_STALE community
or upon attaching the "LLGR_STALE" community itself per or upon attaching the LLGR_STALE community itself per
<xref target="session_resets" format="default"/>: <xref target="session_resets" format="default"/>:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
Treat the route as the least-preferred in route selection (see below). Treat the route as the least preferred in route selection (see below).
See the <xref target="depref" format="default">Risks of Depreferencing Rout See <xref target="depref" format="default"></xref> for a discussion of pote
es ntial risks inherent in doing
section</xref> for a discussion of potential risks inherent in doing
this. this.
</li> </li>
<li> <li>
The route SHOULD NOT be advertised to any neighbor from which the The route <bcp14>SHOULD NOT</bcp14> be advertised to any neighbor from whic
Long-lived Graceful Restart Capability has not been received. The h the
exception is described in the <xref target="partial_deploy" format="default Long-Lived Graceful Restart Capability has not been received. The
">Optional exception is described in <xref target="partial_deploy" format="default"></
Partial Deployment Procedure section</xref>. Note that this xref>. Note that this
requirement implies that such routes should be withdrawn from any such requirement implies that such routes should be withdrawn from any such
neighbor. neighbor.
</li> </li>
<li> <li>
The "LLGR_STALE" community MUST NOT be removed when The LLGR_STALE community <bcp14>MUST NOT</bcp14> be removed when
the route is further advertised. the route is further advertised.
</li> </li>
</ul> </ul>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Route Selection</name> <name>Route Selection</name>
<t> <t>
A "least-preferred" route MUST be treated as less preferred than any other route A least preferred route <bcp14>MUST</bcp14> be treated as less preferred than an
that y other route that is not also least preferred. When performing route selection
is not also least-preferred. When performing route selection between two routes between two routes when both
both are least preferred, normal tiebreaking applies. Note that this
of which are least-preferred, normal tie-breaking applies. Note that this
would only be expected to happen if the only routes available for selection would only be expected to happen if the only routes available for selection
were least-preferred -- in all other cases, such routes would have been were least preferred; in all other cases, such routes would have been
eliminated from consideration. eliminated from consideration.
</t> </t>
</section> </section>
<!--
<section title="Multicast VPN">
<t>
If LLGR is being used in a network that carries Multicast VPN (MVPN)
traffic (<xref target="RFC6513"></xref>,<xref target="RFC6514"></xref>),
special considerations apply.
</t>
<t>
<xref target="RFC6513"></xref> defines the notion of the "Upstream PE" and the
"Upstream
Multicast Hop" (UMH) for a particular multicast flow. To determine the
Upstream PE and/or the UMH for a particular flow, a particular set of
comparable BGP routes (the "UMH-eligible" routes for that flow, as
defined in <xref target="RFC6513"></xref>) is considered, and the "best" one (
according to the
BGP bestpath selection algorithm) is chosen. The UMH-eligible routes are
routes with AFI/SAFI 1/1, 1/2, 2/1, or 2/2. When a router detects a
change in the Upstream PE or UMH for a given flow, the router may modify
its data plane state for that flow. For example, the router may begin to
discard any packets of the flow that it believes have arrived from the
previously chosen Upstream PE or UMH. The assumption is that the newly
chosen Upstream PE and/or UMH will make the corresponding changes, if
necessary, to their own data plane states. In addition, if a router
detects a change in the Uptream PE or UMH for a given flow, it may
originate or readvertise (with different attributes) certain of the BGP
MCAST-VPN routes (routes with SAFI 5) that are defined in <xref target="RFC651
4"></xref>. The
assumption is that the MCAST-VPN routes will be properly distributed by
BGP to other routers that have data plane states for the given flow, i.e.,
that BGP will converge so that all routers handle the flow in a
consistent manner.
</t>
<t>
However, if detection of a change to the Upstream PE or UMH is based
entirely on stale routes, one cannot assume that BGP will converge;
rather one must assume that the UMH-eligible routes and the MCAST-VPN
routes are not being properly distributed. Since the purpose of the LLGR
procedures is to try to keep the data flowing (by "freezing" the data
plane states) when the control plane updates are not being properly
distributed, it does not seem appropriate to react to changes that are
based entirely on stale routes. Therefore, the following rules MUST be
applied when a router is computing or recomputing the Upstream PE and/or
the UMH for a given multicast flow:
</t>
<t><list style="symbols">
<t>
STALE routes (i.e., UMH-eligible routes with the LLGR_STALE attribute)
are less preferable than non-STALE routes.
</t>
<t>
If all the UMH-eligible routes for a given flow are STALE, then the
Upstream PE and/or UMH for that flow is considered to be "stale".
</t>
<t>
If the Upstream PE or UMH for a given multicast flow has already been
determined, and the result of a new computation yields a new Upstream
PE or UMH, but the Upstream PE or UMH is "stale" (as defined just
above), then the Upstream PE and/or UMH for that flow MUST be left
unchanged.
</t>
<t>
If the Upstream PE or UMH for a given multicast flow has not already
been determined, but is now determined to be STALE, the multicast flow
is considered to have no reachable Upstream PE and/or UMH.
</t>
</list></t>
<t>
<xref target="RFC6514"></xref> also defines a set of route types with SAFI 5 (
"MCAST-VPN"
routes). LLGR can be applied to MCAST-VPN routes. However, the
following MCAST-VPN route types require special procedures, as specified
in this section:
</t>
<t><list style="symbols">
<?rfc subcompact="yes" ?>
<t>
Leaf A-D routes
</t>
<t>
C-multicast Shared Tree Join routes
</t>
<t>
C-multicast Source Tree Join routes
</t>
</list></t>
<?rfc subcompact="no" ?>
<t>
Routes of these three types are always "targeted" to a particular
upstream router. Depending on the situation, the targeted router
may be the Upstream PE for a given flow or the UMH for a given
flow. Alternatively, the targeted router may be determined by
choosing the "best" route (according to the BGP bestpath
algorithm) from among a set of comparable Intra-AS I-PMSI A-D
routes, or from among a set of comparable Inter-AS I-PMSI A-D
routes, or from among a set of comparable S-PMSI A-D routes. (See
<xref target="RFC6513"/>, <xref target="RFC6514"/>, <xref
target="RFC6625"/>, and <xref target="RFC7524"/> for details.) Once the
target is chosen, it is identified in an IPv4-address-specific
Route Target (RT) or an IPv6-address-specific RT that is attached
to the route before the route is advertised. If the target for
one of these routes changes, the value of the attached RT will
also change. This in turn may cause the route to be advertised,
readvertised, or withdrawn on specific BGP sessions.
</t>
<t>
For cases where the targeted router is the Upstream PE or the UMH for a
particular flow, the rules given previously in this section apply. For
example, if a Leaf A-D route is targeted to a flow's UMH, and all the
relevant UMH-eligible routes are stale, the UMH is left unchanged. Thus
the Leaf A-D route is not readvertised with a new RT.
</t>
<t>
In those cases where the targeted router for a given Leaf A-D route is
selected by comparing a set of S-PMSI A-D routes, or where the targeted
router for a given C-multicast Shared or Source Tree Join route is
selected by comparing a set of Inter-AS I-PMSI A-D routes, the following
rules MUST be applied:
</t>
<t><list style="symbols">
<t>
STALE routes (i.e., "I/S-PMSI A-D routes" with the LLGR_STALE attribute)
are less preferable than non-STALE routes.
</t>
<t>
If all the routes being considered are STALE, then the targeted router
of the Leaf A-D route or C-multicast Shared or Source Tree Join route
MUST NOT be changed.
</t>
</list></t>
<t>
This prevents a Leaf A-D route or C-multicast route from being targeted
to a particular router if the relevant I/S-PMSI A-D routes from that
router are stale. Since those routes are stale, it is likely that the
Leaf A-D route or C-multicast route would not make it to the targeted
router, in which case it is better to maintain the existing data plane
states than to make changes that presuppose that the MCAST-VPN routes
will be properly distributed.
</t>
</section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Errors</name> <name>Errors</name>
<t> <t>
If the LLGR capability is received without an accompanying GR capability, If the LLGR Capability is received without an accompanying GR Capability,
the LLGR capability MUST be ignored, that is, the implementation MUST behave the LLGR Capability <bcp14>MUST</bcp14> be ignored, that is, the implementation
as though no LLGR capability had been received. <bcp14>MUST</bcp14> behave
as though no LLGR Capability has been received.
</t> </t>
</section> </section>
<section anchor="partial_deploy" numbered="true" toc="default"> <section anchor="partial_deploy" numbered="true" toc="default">
<name>Optional Partial Deployment Procedure</name> <name>Optional Partial Deployment Procedure</name>
<t> <t>
Ideally, all routers in an Autonomous System would support this Ideally, all routers in an Autonomous System (AS) would support this
specification before it was enabled. However, to facilitate incremental specification before it were enabled. However, to facilitate incremental
deployment, stale routes MAY be advertised to neighbors that have not deployment, stale routes <bcp14>MAY</bcp14> be advertised to neighbors that have
advertised the Long-lived Graceful Restart Capability under the following not
advertised the Long-Lived Graceful Restart Capability under the following
conditions: conditions:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
The neighbors MUST be internal (IBGP or Confederation) The neighbors <bcp14>MUST</bcp14> be internal (Internal BGP (IBGP) or Confe deration)
neighbors. neighbors.
</li> </li>
<li> <li>
The NO_EXPORT community <xref target="RFC1997" format="default"/> MUST be a ttached to the stale The NO_EXPORT community <xref target="RFC1997" format="default"/> <bcp14>MU ST</bcp14> be attached to the stale
routes. routes.
</li> </li>
<li> <li>
The stale routes MUST have their LOCAL_PREF set to zero. See the <xref targ et="depref" format="default">Risks of Depreferencing Routes section</xref> for a The stale routes <bcp14>MUST</bcp14> have their LOCAL_PREF set to zero. See <xref target="depref" format="default"></xref> for a
discussion of potential risks inherent in doing this. discussion of potential risks inherent in doing this.
</li> </li>
</ul> </ul>
<t> <t>
If this strategy for partial deployment is used, the network operator should If this strategy for partial deployment is used, the network operator should
set LOCAL_PREF to zero for all long-lived stale routes throughout the Autonomous System. set the LOCAL_PREF to zero for all long-lived stale routes throughout the Autono mous System.
This trades off a small reduction in flexibility (ordering may not be This trades off a small reduction in flexibility (ordering may not be
preserved between competing long-lived stale routes) for consistency between rou ters preserved between competing long-lived stale routes) for consistency between rou ters
that do, and do not, support this specification. Since the consistency of route that do, and do not, support this specification. Since the consistency of route
selection can be important for preventing forwarding loops, the latter selection can be important for preventing forwarding loops, the latter
consideration dominates. consideration dominates.
</t> </t>
</section> </section>
<section anchor="pe_ce" numbered="true" toc="default"> <section anchor="pe_ce" numbered="true" toc="default">
<name>Procedures when BGP is the PE-CE Protocol in a VPN</name> <name>Procedures When BGP Is the PE-CE Protocol in a VPN</name>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Procedures when EBGP is the PE-CE Protocol in a VPN</name> <name>Procedures When EBGP Is the PE-CE Protocol in a VPN</name>
<t> <t>
In VPN deployments, for example <xref target="RFC4364" format="default"/>, EBGP
is In VPN deployments (for example, <xref target="RFC4364" format="default"/>), Ext
ernal BGP (EBGP) is
often used as a PE-CE protocol. It may be a practical necessity in such often used as a PE-CE protocol. It may be a practical necessity in such
deployments to accommodate interoperation with peer routers that cannot easily b e deployments to accommodate interoperation with peer routers that cannot easily b e
upgraded to support specifications such as this one. This leads to a upgraded to support specifications such as this one. This leads to a problem: th
problem: in this specification, we take pains to ensure that "stale" e procedures defined elsewhere in this
routing information will not leak beyond the perimeter of routers that document generally prevent LLGR stale routes from being sent across
support these procedures so that it can be depreferenced as expected, and EBGP sessions that don't support LLGR, but this could prevent the
we provide <xref target="partial_deploy" format="default">a workaround</xref> fo VPN routes from being used for their intended purpose.
r the case
where one or more IBGP routers are not upgraded. However, in the VPN PE-CE
case, the protocol in use is EBGP, and our workaround does not work since
it relies on the use of LOCAL_PREF, an IBGP-only path attribute.
</t> </t>
<t> <t>
We observe that the principal motivation for restricting the propagation of We observe that the principal motivation for restricting the propagation of
"stale" routing information is the desire to prevent it from spreading "stale" routing information is the desire to prevent it from spreading
without limit once it exits the "safe" perimeter. We further observe that without limit once it exits the "safe" perimeter. We further observe that
VPN deployments are typically topologically constrained, making this VPN deployments are typically topologically constrained, making this
concern moot. For this reason, an implementation MAY advertise stale routes concern moot. For this reason, an implementation <bcp14>MAY</bcp14> advertise st ale routes
over a PE-CE session, when explicitly configured to do so. That is, the over a PE-CE session, when explicitly configured to do so. That is, the
second rule listed in <xref target="processing_lls" format="default"/> MAY be second rule listed in <xref target="processing_lls" format="default"/> <bcp14>MA Y</bcp14> be
disregarded in such cases. All other rules continue to apply. Finally, disregarded in such cases. All other rules continue to apply. Finally,
if this exception is used, the implementation SHOULD by default attach if this exception is used, the implementation <bcp14>SHOULD</bcp14>, by default, attach
the NO_EXPORT community to the routes in question, as an additional the NO_EXPORT community to the routes in question, as an additional
protection against stale routes spreading without limit. Attachment of protection against stale routes spreading without limit. Attachment of
the NO_EXPORT community MAY be disabled by explicit configuration, to the NO_EXPORT community <bcp14>MAY</bcp14> be disabled by explicit configuration in order to
accommodate exceptional cases. accommodate exceptional cases.
</t> </t>
<t> <t>
See further discussion of using explicitly configured policy to See further discussion of using an explicitly configured policy to
mitigate this issue in <xref target="deploy_pe_ce" format="default"/>. mitigate this issue in <xref target="deploy_pe_ce" format="default"/>.
</t> </t>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Procedures when IBGP is the PE-CE Protocol in a VPN</name> <name>Procedures When IBGP Is the PE-CE Protocol in a VPN</name>
<t> <t>
If IBGP is used as the PE-CE protocol, following the procedures of If IBGP is used as the PE-CE protocol, following the procedures of
<xref target="RFC6368" format="default"/>, then when a PE router imports a VPN <xref target="RFC6368" format="default"/>, then when a PE router imports a VPN
route that contains the ATTR_SET attribute into a destination VRF and route that contains the ATTR_SET attribute into a destination VRF and
subsequently advertises that route to a CE router, subsequently advertises that route to a CE router:</t>
</t> <ul>
<ul spacing="normal"> <li><t>If the CE router supports the procedures of this document (in
<li> other words, if the CE router has advertised the LLGR Capability):</t>
If the CE router does support the procedures of this document (in <t indent="3">In
other words, if the CE router has advertised the LLGR Capability): In addition to including the path attributes
addition to including in the advertised route the path attributes derived from the ATTR_SET attribute in the advertised route as per <xref target=
derived from the ATTR_SET as per <xref target="RFC6368" format="default"/>, the "RFC6368" format="default"/>, the
PE router MUST also include the LLGR_STALE community if it is present PE router <bcp14>MUST</bcp14> also include the LLGR_STALE community if it is pre
sent
in the path attributes of the imported route, even if it is not in the path attributes of the imported route, even if it is not
present in the ATTR_SET attribute. present in the ATTR_SET attribute.
</li> </t></li>
<li> <li><t>If the CE router does not support the
If the CE router does not support the procedures of this document:</t>
procedures of this document, then the optional procedures of <xref target="parti <t indent="3">Then the optional procedures of <xref target="partial_d
al_deploy" format="default"/> MAY be followed, attaching the NO_EXPORT eploy" format="default"/> <bcp14>MAY</bcp14> be followed, attaching the NO_EXPOR
T
community and setting the value of LOCAL_PREF to zero, overriding the community and setting the value of LOCAL_PREF to zero, overriding the
value found in the ATTR_SET. value found in the ATTR_SET.
</li> </t></li></ul>
</ul>
<t> <t>
Similarly, when a PE router receives a route from a CE into its VRF Similarly, when a PE router receives a route from a CE into its VRF
and subsequently exports that route to a VPN address family, and subsequently exports that route to a VPN address family:
</t> </t>
<ul spacing="normal"> <ul>
<li> <li><t>If the PE router supports the procedures of this document (in
If the PE router does support the procedures of this document (in other words, if the PE router has advertised the LLGR Capability):</t>
other words, if the PE router has advertised the LLGR Capability): <t indent="3">In addition to including in the VPN route the ATTR_SET derived fro
In addition to including in the VPN route the ATTR_SET derived from m
the path attributes as per <xref target="RFC6368" format="default"/>, the PE rou ter the path attributes as per <xref target="RFC6368" format="default"/>, the PE rou ter
MUST also include the LLGR_STALE community in the VPN route if it is <bcp14>MUST</bcp14> also include the LLGR_STALE community in the VPN route if it
present in the path attributes of the route as received from the CE. is
</li> present in the path attributes of the route as received from the CE.</t></li>
<li>
If the PE router does not support the procedures of this document, <li><t>If the PE router does not support the procedures of this document:</t>
there exists no ideal solution. The CE could advertise a route with
<t indent="3">There exists no ideal solution. The CE could advertise a route wit
h
LLGR_STALE, with the understanding that the LLGR_STALE marking will LLGR_STALE, with the understanding that the LLGR_STALE marking will
only be honored by the provider network if appropriate policy only be honored by the provider network if appropriate policy
configuration exists on the PE (see <xref target="deploy_pe_ce" format="default" />). configuration exists on the PE (see <xref target="deploy_pe_ce" format="default" />).
It is at least guaranteed that LLGR_STALE will be propagated when It is at least guaranteed that LLGR_STALE will be propagated when
the route is propagated beyond the provider network. Or, the CE the route is propagated beyond the provider network, or the CE
could refrain from advertising the LLGR_STALE route to the incapable could refrain from advertising the LLGR_STALE route to the incapable
PE. PE.
</li> </t></li>
</ul> </ul>
</section> </section>
</section> </section>
</section> </section>
<section anchor="deploy" numbered="true" toc="default"> <section anchor="deploy" numbered="true" toc="default">
<name>Deployment Considerations</name> <name>Deployment Considerations</name>
<t> <t>
The deployment considerations discussed in <xref target="RFC4724" format="defaul t"/> apply to this The deployment considerations discussed in <xref target="RFC4724" format="defaul t"/> apply to this
document. In addition, network operators are cautioned to carefully document. In addition, network operators are cautioned to carefully
consider the potential disadvantages of deploying these procedures for a consider the potential disadvantages of deploying these procedures for a
given AFI/SAFI. Most notably, if used for an AFI/SAFI that conveys given AFI/SAFI. Most notably, if used for an AFI/SAFI that conveys
traditional reachability information, the use of a long-lived stale route could conventional reachability information, the use of a long-lived stale route could
result in a loss of connectivity for the covered prefix. This specification result in a loss of connectivity for the covered prefix. This specification
takes pains to mitigate this risk where possible, by making such routes takes pains to mitigate this risk where possible by making such routes
least-preferred and by restricting the scope of such routes to routers that least preferred and by restricting the scope of such routes to routers that
support these procedures (or, optionally, a single Autonomous System, see support these procedures (or, optionally, a single Autonomous System, see
<xref target="partial_deploy" format="default">"Optional Partial Deployment Proc <xref target="partial_deploy" format="default"></xref>). However, if a stale ro
edure"</xref>). ute is chosen as best for a given prefix,
However, according to the then according to the normal rules of IP forwarding, that route will
normal rules of IP forwarding a stale more-specific route, that has no be used for matching destinations, even if a non-stale less specific
non-stale alternate paths available, will still be used instead of a matching route is also available. Networks in which the deployment of these pro
non-stale less-specific route. Networks in which the deployment of these procedu cedures
res would be especially concerning include those that do not use "tunneled"
would be especially concerning include those which do not use "tunneled" forwarding (in other words, those using conventional hop-by-hop forwarding).
forwarding (in other words, those using traditional hop-by-hop forwarding).
</t> </t>
<t> <t>
Implementations MUST NOT enable these procedures by default. They MUST Implementations <bcp14>MUST NOT</bcp14> enable these procedures by default. They <bcp14>MUST</bcp14>
require affirmative configuration per AFI/SAFI in order to enable them. require affirmative configuration per AFI/SAFI in order to enable them.
</t> </t>
<t> <t>
The procedures of this document do not alter the route resolvability The procedures of this document do not alter the route resolvability
requirement of Section 9.1.2.1 of <xref target="RFC4271" format="default"/>. Bec ause of this, it will commonly be requirement of <xref target="RFC4271" sectionFormat="of" section="9.1.2.1"/>. Be cause of this, it will commonly be
the case that "stale" IBGP routes will only continue to be used if the the case that "stale" IBGP routes will only continue to be used if the
router depicted in the next hop remains resolvable, even if its BGP router depicted in the next hop remains resolvable, even if its BGP
component is down. Details of IGP component is down. Details of IGP
fault-tolerance strategies are beyond the scope of this document. In fault-tolerance strategies are beyond the scope of this document. In
addition to the foregoing, it may be advisable to check the viability of addition to the foregoing, it may be advisable to check the viability of
the next hop through other means, for example, the next hop through other means, for example,
<xref target="RFC5880" format="default">BFD</xref>. This may be especially <xref target="RFC5880" format="default">Bidirectional Forwarding Detection (BFD) </xref>. This may be especially
useful in cases where the next hop is known directly at the network layer, useful in cases where the next hop is known directly at the network layer,
notably EBGP. notably EBGP.
</t> </t>
<t> <t>
As discussed in this document, after a BGP session goes down and before the As discussed in this document, after a BGP session goes down and before the
session is re-established, stale routes may be retained for up to two session is re-established, stale routes may be retained for up to two
consecutive periods, controlled by the "Restart Time" and the "Long-lived consecutive periods, controlled by the Restart Time and the Long-Lived
Stale Time", respectively. During the first period routing churn would be Stale Time, respectively:</t>
prevented but with potential blackholing of traffic. During the second
period potential blackholing of traffic may be reduced but routing churn <ul><li>During the first period, routing churn would be
would be visible throughout the network. The setting of the relevant prevented, but with potential persistent packet loss.</li>
parameters for a particular application should take into account the <li>During the second
tradeoffs, the network dynamics, and potential failure scenarios. If needed, period, potential persistent packet loss may be reduced, but routing churn
would be visible throughout the network.</li>
</ul>
<t>The setting of the relevant parameters for a particular application should ta
ke into account
trade-offs, network dynamics, and potential failure scenarios. If needed,
the first period can be bypassed either by local configuration or by setting the first period can be bypassed either by local configuration or by setting
the "Restart Time" in the Graceful Restart Capability to zero and/or not the Restart Time in the Graceful Restart Capability to zero and/or not
listing the AFI/SAFI in that Capability. listing the AFI/SAFI in that capability.
</t> </t>
<t> <t>
The setting of the F bit (and the "Forwarding State" bit of the The setting of the F bit (and the Forwarding State bit of the
accompanying GR capability) depends in part on deployment considerations. accompanying GR Capability) depends, in part, on deployment considerations.
The F bit can be understood as an indication that the Helper should flush The F bit can be understood as an indication that the Helper should flush
associated routes (if the bit is left clear). As discussed in <xref target="intr associated routes (if the bit is left clear). As discussed in <xref target="intr
o" format="default"> o" format="default"></xref>, an important use case for LLGR is for routes that a
the Introduction</xref>, an important use case for LLGR is for routes that are m re more
ore akin to configuration than to conventional routing. For such routes, it may
akin to configuration than to traditional routing. For such routes, it may make sense to always set the F bit, regardless of other considerations. Likewis
make sense to always set the F bit, regardless of other considerations. e, for control-plane-only entities, such as dedicated route
Likewise, for control-plane-only entities such as dedicated route reflectors that do not participate in the forwarding plane, it makes
reflectors, that do not participate in the forwarding plane, it makes sense sense to always set the F bit. Overall, the rule of thumb is that if loss of
to always set the F bit. Overall, the rule of thumb is that if loss of
state on the restarting router can reasonably be expected to cause a state on the restarting router can reasonably be expected to cause a
forwarding loop or black hole, the F bit should be set scrupulously forwarding loop or persistent packet loss, the F bit should be set scrupulously
according to whether state has been retained. Specifics of when the F bit according to whether state has been retained. Specifics of whether or not the F
is, and is not, set are implementation-dependent and may also be controlled bit
by configuration. Also, for every AFI/SAFI represented in the LLGR capability is set are implementation dependent and may also be controlled
that is also represented in the GR capability, there will be two corresponding by configuration. Also, for every AFI/SAFI represented in the LLGR Capability
F bits -- the LLGR F bit and the GR F bit. If the LLGR F bit is set, the that is also represented in the GR Capability, there will be two corresponding
F bits: the LLGR F bit and the GR F bit. If the LLGR F bit is set, the
corresponding GR F bit should also be set, since to do otherwise would cause corresponding GR F bit should also be set, since to do otherwise would cause
the state to be cleared on the Receiving Router per the normal rules of GR, the state to be cleared on the Receiving Router per the normal rules of GR,
violating the intent of the set LLGR bit. violating the intent of the set LLGR bit.
</t> </t>
<section anchor="deploy_pe_ce" numbered="true" toc="default"> <section anchor="deploy_pe_ce" numbered="true" toc="default">
<name>When BGP is the PE-CE Protocol in a VPN</name> <name>When BGP Is the PE-CE Protocol in a VPN</name>
<t> <t>
As discussed in <xref target="pe_ce" format="default"/>, it may be necessary for a PE to As discussed in <xref target="pe_ce" format="default"/>, it may be necessary for a PE to
advertise stale routes to a CE in some VPN deployments, even if the CE advertise stale routes to a CE in some VPN deployments, even if the CE
does not support this specification. In that case, the operator does not support this specification. In that case, the operator
configuring their PE to advertise such routes should notify the operator configuring their PE to advertise such routes should notify the operator
of the CE receiving the routes, and the CE should be configured to of the CE receiving the routes, and the CE should be configured to
depreference the routes. depreference the routes.
</t> </t>
<t> <t>
Similarly, it may be necessary for a CE to advertise stale routes to a Similarly, it may be necessary for a CE to advertise stale routes to a
skipping to change at line 983 skipping to change at line 790
safe operation in hop-by-hop routed networks. When routers within an AS apply di fferent criteria in safe operation in hop-by-hop routed networks. When routers within an AS apply di fferent criteria in
selecting routes, they can arrive at inconsistent route selections. selecting routes, they can arrive at inconsistent route selections.
This can lead to the formation of forwarding loops unless some This can lead to the formation of forwarding loops unless some
form of tunneled forwarding is used to prevent "core" routers from form of tunneled forwarding is used to prevent "core" routers from
making a (potentially inconsistent) forwarding decision based on the making a (potentially inconsistent) forwarding decision based on the
IP header. IP header.
</t> </t>
<t> <t>
This specification uses the state of a peering session as an input This specification uses the state of a peering session as an input
to the selection criteria, depreferencing routes that are associated to the selection criteria, depreferencing routes that are associated
with a session that has gone down but have not yet aged out. Since with a session that has gone down but that have not yet aged out. Since
different routers within an AS might have different notions as to different routers within an AS might have different notions as to
whether their respective sessions with a given peer are up or down, they might whether their respective sessions with a given peer are up or down, they might
apply different selection criteria to routes from that peer. This apply different selection criteria to routes from that peer. This
could result in a forwarding loop forming between such routers. could result in a forwarding loop forming between such routers.
</t> </t>
<t> <t>
For an example of such a forwarding loop, consider the following For an example of such a forwarding loop, consider the following
simple topology: simple topology:
</t> </t>
<artwork align="left" name="" type="" alt=""><![CDATA[ <figure>
A ---- B ---- C ------------------------- D <artwork align="left" name="" type="" alt="">
^ ^ <![CDATA[
| | A ---- B ---- C ------------------------- D
R1 R2 ^ ^
]]></artwork> | |
R1 R2
]]></artwork></figure>
<t> <t>
In this example, A - D are routers with a full mesh of IBGP sessions In this example, A - D are routers with a full mesh of IBGP sessions
between them (the sessions are not shown). between them (the sessions are not shown).
The short links have unit cost, the long link has cost 5. The short links have unit cost, the long link has cost 5.
Routers A and D are AS border routers, each advertising some route, R, into Routers A and D are AS border routers, each advertising some route, R, with the
the AS -- these are denoted R1 and R2 in the diagram. In ordinary same LOCAL_PREF into
the AS: denoted R1 and R2 in the diagram. In ordinary
operation, it can be seen that routers B and C will select R1 for operation, it can be seen that routers B and C will select R1 for
forwarding, and will forward toward A. forwarding and will forward toward A.
</t> </t>
<t> <t>
Suppose that the session between A and B goes down for some reason, and Suppose that the session between A and B goes down for some reason, and
stays down long enough for LLGR processing to be invoked on B. Then on B, it stays down long enough for LLGR processing to be invoked on B. Then, on B,
route R1 will be depreferenced, leading to the selection of R2 by B. route R1 will be depreferenced, leading to the selection of R2 by B.
However, C will continue to prefer R1. It can be seen that in this case, a However, C will continue to prefer R1. In this case, it can be seen that a
forwarding loop for packets destined to R would form between B and C. (We forwarding loop for packets destined to R would form between B and C. (We
note that other forwarding loop scenarios can be constructed for note that other forwarding loop scenarios can be constructed for
traditional GR, but are generally considered less severe since GR can conventional GR, but these are generally considered less severe since GR can
remain in effect for a much more limited interval.) remain in effect for a much more limited interval.)
</t> </t>
<t> <t>
The potential benefits of this specification can outweigh the The potential benefits of this specification can outweigh the
risks discussed above, as long as care is exercised in deployment. risks discussed above, as long as care is exercised in deployment.
The cardinal rule to be followed is, if a given set of routes are The cardinal rule to be followed is that if a given set of routes is
being used within an AS for hop-by-hop forwarding, it is not being used within an AS for hop-by-hop forwarding, enabling LLGR procedures is
recommended to enable LLGR procedures. If tunneled forwarding (such not
recommended. If tunneled forwarding (such
as MPLS) is used within the AS, or if routes are being used for as MPLS) is used within the AS, or if routes are being used for
purposes other than hop-by-hop forwarding, less caution is needed, purposes other than hop-by-hop forwarding, less caution is needed;
though the operator should still carefully consider the consequences however, the operator should still carefully consider the consequences
of enabling LLGR. of enabling LLGR.
</t> </t>
</section> </section>
</section> </section>
<section numbered="true" toc="default"> <section numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <t>
The security implications of the LLGR mechanism defined The security implications of the LLGR mechanism defined
in this document are akin to those incurred by the maintenance of in this document are akin to those incurred by the maintenance of
stale routing information within a network. However, since the stale routing information within a network. However, since the
retention time may potentially be much longer, the window during retention time may be much longer, the window during
which certain attacks are feasible may be substantially increased. which certain attacks are feasible may substantially increase.
This is particularly This is particularly
relevant when considering the maintenance of routing information that relevant when considering the maintenance of routing information that
is used for service segregation - such as MPLS label entries. is used for service segregation, such as MPLS label entries.
</t> </t>
<t> <t>
For MPLS VPN services, the effectiveness of the traffic isolation For MPLS VPN services, the effectiveness of the traffic isolation
between VPNs relies on the correctness of the MPLS labels between between VPNs relies on the correctness of the MPLS labels between
ingress and egress PEs. In particular, when an egress PE withdraws a ingress and egress PEs. In particular, when an egress PE withdraws a
label L1 allocated to a VPN1 route, this label must not be assigned label L1 allocated to a VPN1 route, this label must not be assigned
to a VPN route of a different VPN until all ingress PEs stop using to a VPN route of a different VPN until all ingress PEs stop using
the old VPN1 route using L1. the old VPN1 route using L1.
</t> </t>
<t> <t>
Such a corner case may happen today if the propagation of VPN routes Such a corner case may happen today if the propagation of VPN routes
by BGP messages between PEs takes more time than the label re-allocation by BGP messages between PEs takes more time than the label reallocation
delay on a PE. Given that we can generally bound the worst-case delay on a PE. Given that we can generally bound the worst-case
BGP propagation time to a few minutes (for example 2-5), the security BGP propagation time to a few minutes (for example, 2-5 minutes), the security
breach will not occur if PEs are designed to not reallocate a breach will not occur if PEs are designed to not reallocate a
previously used and withdrawn label before a few minutes. previously used and withdrawn label before a few minutes.
</t> </t>
<t> <t>
The problem is made worse with BGP GR between PEs as VPN routes can The problem is made worse with BGP GR between PEs because VPN routes can
be stalled for a longer period of time (for example 20 minutes). be stalled for a longer period of time (for example, 20 minutes).
</t> </t>
<t> <t>
This is further aggravated by the BGP LLGR extension proposed This is further aggravated by the LLGR extension specified
in this document as VPN routes can be stalled for a much longer in this document because VPN routes can be stalled for a much longer
period of time (for example 2 hours, 1 day). period of time (for example, 2 hours, 1 day).
</t> </t>
<t> <t>
In order to exploit the vulnerability described above, there is a In order to exploit the vulnerability described above, an attacker
requirement to engineer a specific LLGR state between two PE devices, needs to engineer a specific LLGR state between two PE devices and
whilst engineering label reallocation to occur in a manner that also cause the label reallocation to occur such that the two
results in the two topologies overlapping. topologies overlap. To avoid the potential for a VPN breach, the
Therefore, to avoid the potential for a VPN breach, before enabling BGP operator should ensure that the lower bound for label reuse is greater
LLGR for a VPN address family, the operator should endeavor to ensure than the upper bound on the LLST before enabling LLGR for a VPN
that the lower bound on when a label might be reused is greater than the address family. <xref target="session_resets" format="default"/> discusses the
upper bound on LLST. <xref target="session_resets" format="default"/> discusses
the
provision of an upper bound on LLST. Details of features for setting provision of an upper bound on LLST. Details of features for setting
a lower bound on label reuse time are beyond the scope of this document; a lower bound on label reuse time are beyond the scope of this document;
however, factors that might need to be taken into account when setting however, factors that might need to be taken into account when setting
this value include: this value include:
</t> </t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
The load of the BGP route churn on a PE (in terms of the number The load of the BGP route churn on a PE (in terms of the number
of VPN labels advertised and the churn rate). of VPN labels advertised and the churn rate).
</li> </li>
<li>
The label allocation policy on the PE (possibly depending <li>The label allocation policy on the PE, which possibly depends upon
upon the size of the pool of the VPN labels (which can be the size of the pool of the VPN labels (which can be restricted by
restricted by hardware considerations or other MPLS usages), hardware considerations or other MPLS usages), the label
the label allocation scheme (for example per route or per VRF/CE), allocation scheme (for example, per route or per VRF/CE), and the
the re-allocation policy (for example least recently used label). reallocation policy (for example, least recently used label). </li>
</li>
</ul> </ul>
<t> <t>
Note that <xref target="RFC4781" format="default"/> which defines Graceful Resta Note that <xref target="RFC4781" format="default"/>, which defines the Graceful
rt Mechanism Restart Mechanism
for BGP with MPLS is also applicable to BGP LLGR. for BGP with MPLS, is also applicable to LLGR.
</t> </t>
</section> </section>
<section anchor="examples" numbered="true" toc="default"> <section anchor="examples" numbered="true" toc="default">
<name>Examples of Operation</name> <name>Examples of Operation</name>
<t> <t>
For illustrative purposes, we present a few examples of how this For illustrative purposes, we present a few examples of how this
specification might be used in practice. These examples are neither specification might be used in practice. These examples are neither
exhaustive nor normative. exhaustive nor normative.
</t> </t>
<t> <t>
skipping to change at line 1127 skipping to change at line 935
<tr> <tr>
<th align="left">Time</th> <th align="left">Time</th>
<th align="left">Event</th> <th align="left">Event</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">t</td> <td align="left">t</td>
<td align="left">ASBR1's IBGP session with RR fails. ASBR1 <td align="left">ASBR1's IBGP session with RR fails. ASBR1
retains RR's routes according to the rules retains RR's routes according to the rules
of <xref target="RFC4724" format="default">GR</xref></ td> of GR <xref target="RFC4724" format="default"></xref>. </td>
</tr> </tr>
<tr> <tr>
<td align="left">t+1</td> <td align="left">t+1</td>
<td align="left">GR Restart Time expires. ASBR1 transitions <td align="left">GR Restart Time expires. ASBR1 transitions
RR's routes to long-lived stale by attaching RR's routes to long-lived stale routes by attaching
the LLGR_STALE community and depreferencing the LLGR_STALE community and depreferencing
them. However, since it has no backup them. However, since it has no backup
routes, it continues to make use of them. It routes, it continues to make use of them. It
re-announces them to EXT with the re-announces them to EXT with the
LLGR_STALE community attached.</td> LLGR_STALE community attached.</td>
</tr> </tr>
<tr> <tr>
<td align="left">t+1+3600</td> <td align="left">t+1+3600</td>
<td align="left">LLST expires. ASBR1 removes RR's stale <td align="left">LLST expires. ASBR1 removes RR's stale
routes from its own RIB and sends BGP updates routes from its own RIB and sends BGP updates
to withdraw them from EXT.</td> to withdraw them from EXT.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>
Next, imagine the same scenario but suppose RR1 advertised a GR Restart Next, imagine the same scenario, but suppose RR1 advertised a GR Restart
Time of zero, effectively disabling GR. Equally, ASBR1 could have used Time of zero, effectively disabling GR. Equally, ASBR1 could have used
local configuration to override RR1's offered Restart Time, setting it to a local configuration to override RR1's offered Restart Time, setting it to
a locally-configured value of zero: a locally configured value of zero:
</t> </t>
<table align="center"> <table align="center">
<thead> <thead>
<tr> <tr>
<th align="left">Time</th> <th align="left">Time</th>
<th align="left">Event</th> <th align="left">Event</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">t</td> <td align="left">t</td>
<td align="left">ASBR1's IBGP session with RR fails. ASBR1 transitio ns <td align="left">ASBR1's IBGP session with RR fails. ASBR1 transitio ns
RR's routes to long-lived stale by attaching RR's routes to long-lived stale routes by attaching
the LLGR_STALE community and depreferencing the LLGR_STALE community and depreferencing
them. However, since it has no backup them. However, since it has no backup
routes, it continues to make use of them. It routes, it continues to make use of them. It
re-announces them to EXT with the re-announces them to EXT with the
LLGR_STALE community attached.</td> LLGR_STALE community attached.</td>
</tr> </tr>
<tr> <tr>
<td align="left">t+0+3600</td> <td align="left">t+0+3600</td>
<td align="left">LLST expires. ASBR1 removes RR's stale <td align="left">LLST expires. ASBR1 removes RR's stale
routes from its own RIB and sends BGP updates routes from its own RIB and sends BGP updates
skipping to change at line 1196 skipping to change at line 1005
<tr> <tr>
<th align="left">Time</th> <th align="left">Time</th>
<th align="left">Event</th> <th align="left">Event</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">t</td> <td align="left">t</td>
<td align="left">ASBR1's IBGP session with RR fails. ASBR1 <td align="left">ASBR1's IBGP session with RR fails. ASBR1
retains RR's routes according to the rules retains RR's routes according to the rules
of <xref target="RFC4724" format="default">GR</xref></ td> of GR <xref target="RFC4724" format="default"></xref>. </td>
</tr> </tr>
<tr> <tr>
<td align="left">t+1</td> <td align="left">t+1</td>
<td align="left">GR Restart Time expires. ASBR1 transitions <td align="left">GR Restart Time expires. ASBR1 transitions
RR's routes to long-lived stale by attaching RR's routes to long-lived stale routes by attaching
the LLGR_STALE community and depreferencing the LLGR_STALE community and depreferencing
them. However, since it has no backup them. However, since it has no backup
routes, it continues to make use of them. It routes, it continues to make use of them. It
re-announces them to EXT with the re-announces them to EXT with the
LLGR_STALE community attached.</td> LLGR_STALE community attached.</td>
</tr> </tr>
<tr> <tr>
<td align="left">t+1+179</td> <td align="left">t+1+179</td>
<td align="left">Session is reestablished and resynchronized. ASBR1 <td align="left">Session is re-established and resynchronized. ASBR1
removes the LLGR_STALE community from removes the LLGR_STALE community from
RR1's routes and re-announces them to EXT with RR1's routes and re-announces them to EXT with
the LLGR_STALE community removed.</td> the LLGR_STALE community removed.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
<t> <t>
Finally, imagine the original scenario, but consider that EXT has not Finally, imagine the original scenario, but consider that EXT has not
advertised the LLGR Capability to ASBR1: advertised the LLGR Capability to ASBR1:
</t> </t>
skipping to change at line 1233 skipping to change at line 1042
<tr> <tr>
<th align="left">Time</th> <th align="left">Time</th>
<th align="left">Event</th> <th align="left">Event</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">t</td> <td align="left">t</td>
<td align="left">ASBR1's IBGP session with RR fails. ASBR1 <td align="left">ASBR1's IBGP session with RR fails. ASBR1
retains RR's routes according to the rules retains RR's routes according to the rules
of <xref target="RFC4724" format="default">GR</xref></ td> of GR <xref target="RFC4724" format="default"></xref>. </td>
</tr> </tr>
<tr> <tr>
<td align="left">t+1</td> <td align="left">t+1</td>
<td align="left">GR Restart Time expires. ASBR1 transitions <td align="left">GR Restart Time expires. ASBR1 transitions
RR's routes to long-lived stale by attaching RR's routes to long-lived stale routes by attaching
the LLGR_STALE community and depreferencing the LLGR_STALE community and depreferencing
them. However, since it has no backup them. However, since it has no backup
routes, it continues to make use of them. It routes, it continues to make use of them. It
withdraws them from EXT.</td> withdraws them from EXT.</td>
</tr> </tr>
<tr> <tr>
<td align="left">t+1+3600</td> <td align="left">t+1+3600</td>
<td align="left">LLST expires. ASBR1 removes RR's stale <td align="left">LLST expires. ASBR1 removes RR's stale
routes from its own RIB.</td> routes from its own RIB.</td>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
<section anchor="Acknowledgements" numbered="true" toc="default">
<name>Acknowledgements</name>
<t>
We would like to thank Nabil Bitar, Martin Djernaes, Roberto Fragassi,
Jeffrey Haas, Jakob Heitz, Daniam Henriques, Nicolai Leymann, Mike McBride, Paul
Mattes, John Medamana, Pranav
Mehta, Han Nguyen, Saikat Ray, Valery Smyslov, and Bo Wu for their valuable inpu
t
and contributions to the discussion and solution.
</t>
</section>
<section numbered="true" toc="default">
<name>Contributors</name>
<artwork align="left" name="" type="" alt=""><![CDATA[
Clarence Filsfils
Cisco Systems
Brussels 1150
Belgium
Email: cf@cisco.com
]]></artwork>
<artwork align="left" name="" type="" alt=""><![CDATA[
Pradosh Mohapatra
Sproute Networks
Email: mpradosh@yahoo.com
]]></artwork>
<artwork align="left" name="" type="" alt=""><![CDATA[
Yakov Rekhter
]]></artwork>
<!-- Note: Yakov has requested that his email address not be
published. I (John Scudder) can contact him if needed. -->
<artwork align="left" name="" type="" alt=""><![CDATA[
Eric Rosen
Email: erosen52@gmail.com
]]></artwork>
<artwork align="left" name="" type="" alt=""><![CDATA[
Rob Shakir
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: robjs@google.com
]]></artwork>
<artwork align="left" name="" type="" alt=""><![CDATA[
Adam Simpson
Nokia
Email: adam.1.simpson@nokia.com
]]></artwork>
</section>
<section anchor="IANA" numbered="true" toc="default"> <section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t> <t>
This document defines a new BGP capability - Long-lived Graceful Restart This document defines a BGP capability called the "Long-Lived Graceful Restart
Capability. IANA has assigned a Capability Code of 71, from the "Capability Code Capability". IANA has assigned a value of 71 from the "Capability Codes"
s"
registry. registry.
</t> </t>
<t> <t>
This document introduces a new BGP well-known community "LLGR_STALE" for marking This document introduces two BGP well-known communities:</t>
long-lived stale routes, and another well-known community "NO_LLGR" to <ul><li> the first called "LLGR_STALE" for marking
mark routes that should not be retained if stale. IANA has assigned these long-lived stale routes, and</li>
<li>the second called "NO_LLGR" for
marking routes that should not be retained if stale.</li></ul>
<t>IANA has assigned these
well-known community values 0xFFFF0006 and 0xFFFF0007, respectively, from the well-known community values 0xFFFF0006 and 0xFFFF0007, respectively, from the
"BGP Well-known Communities" registry. "BGP Well-known Communities" registry.
</t> </t>
<t>
For each of these three registrations, IANA is requested to update the
reference to refer to this document.
</t>
<t> <t>
IANA is requested to establish a new registry called "Long-lived Graceful IANA has established a registry called the "Long-Lived Graceful
Restart Flags for Address Family" under the Restart Flags for Address Family" registry under the
Border Gateway Protocol (BGP) Parameters group. The registration "Border Gateway Protocol (BGP) Parameters" group. The registration
procedures are Standards Action. The registry should initially be procedures are Standards Action (see <xref target="RFC8126" format="default"/>).
populated as follows: The registry is initially populated as follows:
</t> </t>
<table align="center"> <table align="center">
<thead> <thead>
<tr> <tr>
<th align="left">Bit Position</th> <th align="left">Bit Position</th>
<th align="left">Name</th> <th align="left">Name</th>
<th align="left">Short Name</th> <th align="left">Short Name</th>
<th align="left">Reference</th> <th align="left">Reference</th>
</tr> </tr>
</thead> </thead>
<tbody> <tbody>
<tr> <tr>
<td align="left">0</td> <td align="left">0</td>
<td align="left">Preservation of state</td> <td align="left">Preservation of state</td>
<td align="left">F</td> <td align="left">F</td>
<td align="left">This document</td> <td align="left">RFC 9494</td>
</tr> </tr>
<tr> <tr>
<td align="left">1-7</td> <td align="left">1-7</td>
<td align="left">Unassigned</td> <td align="left">Unassigned</td>
<td align="left"/> <td align="left"/>
<td align="left"/> <td align="left"/>
</tr> </tr>
</tbody> </tbody>
</table> </table>
</section> </section>
</middle> </middle>
<back> <back>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC1997" target="https://www.rfc-editor.org/info/rfc1
997" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1997.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1997.xml"
<front> />
<title>BGP Communities Attribute</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"
<author fullname="R. Chandra" initials="R." surname="Chandra"/> />
<author fullname="P. Traina" initials="P." surname="Traina"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"
<author fullname="T. Li" initials="T." surname="Li"/> />
<date month="August" year="1996"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4724.xml"
<abstract> />
<t>This document describes an extension to BGP which may be used t <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4760.xml"
o pass additional information to both neighboring and remote BGP peers. [STANDAR />
DS-TRACK]</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5492.xml"
</abstract> />
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6368.xml"
<seriesInfo name="RFC" value="1997"/> />
<seriesInfo name="DOI" value="10.17487/RFC1997"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"
</reference> />
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2 <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8538.xml"
119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"> />
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author fullname="S. Bradner" initials="S." surname="Bradner"/>
<date month="March" year="1997"/>
<abstract>
<t>In many standards track documents several words are used to sig
nify the requirements in the specification. These words are often capitalized. T
his document defines these words as they should be interpreted in IETF documents
. This document specifies an Internet Best Current Practices for the Internet Co
mmunity, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC4271" target="https://www.rfc-editor.org/info/rfc4
271" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml">
<front>
<title>A Border Gateway Protocol 4 (BGP-4)</title>
<author fullname="Y. Rekhter" initials="Y." role="editor" surname="R
ekhter"/>
<author fullname="T. Li" initials="T." role="editor" surname="Li"/>
<author fullname="S. Hares" initials="S." role="editor" surname="Har
es"/>
<date month="January" year="2006"/>
<abstract>
<t>This document discusses the Border Gateway Protocol (BGP), whic
h is an inter-Autonomous System routing protocol.</t>
<t>The primary function of a BGP speaking system is to exchange ne
twork reachability information with other BGP systems. This network reachability
information includes information on the list of Autonomous Systems (ASes) that
reachability information traverses. This information is sufficient for construct
ing a graph of AS connectivity for this reachability from which routing loops ma
y be pruned, and, at the AS level, some policy decisions may be enforced.</t>
<t>BGP-4 provides a set of mechanisms for supporting Classless Int
er-Domain Routing (CIDR). These mechanisms include support for advertising a set
of destinations as an IP prefix, and eliminating the concept of network "class"
within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes,
including aggregation of AS paths.</t>
<t>This document obsoletes RFC 1771. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4271"/>
<seriesInfo name="DOI" value="10.17487/RFC4271"/>
</reference>
<reference anchor="RFC4724" target="https://www.rfc-editor.org/info/rfc4
724" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4724.xml">
<front>
<title>Graceful Restart Mechanism for BGP</title>
<author fullname="S. Sangli" initials="S." surname="Sangli"/>
<author fullname="E. Chen" initials="E." surname="Chen"/>
<author fullname="R. Fernando" initials="R." surname="Fernando"/>
<author fullname="J. Scudder" initials="J." surname="Scudder"/>
<author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
<date month="January" year="2007"/>
<abstract>
<t>This document describes a mechanism for BGP that would help min
imize the negative effects on routing caused by BGP restart. An End-of-RIB marke
r is specified and can be used to convey routing convergence information. A new
BGP capability, termed "Graceful Restart Capability", is defined that would allo
w a BGP speaker to express its ability to preserve forwarding state during BGP r
estart. Finally, procedures are outlined for temporarily retaining routing infor
mation across a TCP session termination/re-establishment.</t>
<t>The mechanisms described in this document are applicable to all
routers, both those with the ability to preserve forwarding state during BGP re
start and those without (although the latter need to implement only a subset of
the mechanisms described in this document). [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4724"/>
<seriesInfo name="DOI" value="10.17487/RFC4724"/>
</reference>
<reference anchor="RFC4760" target="https://www.rfc-editor.org/info/rfc4
760" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4760.xml">
<front>
<title>Multiprotocol Extensions for BGP-4</title>
<author fullname="T. Bates" initials="T." surname="Bates"/>
<author fullname="R. Chandra" initials="R." surname="Chandra"/>
<author fullname="D. Katz" initials="D." surname="Katz"/>
<author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
<date month="January" year="2007"/>
<abstract>
<t>This document defines extensions to BGP-4 to enable it to carry
routing information for multiple Network Layer protocols (e.g., IPv6, IPX, L3VP
N, etc.). The extensions are backward compatible - a router that supports the ex
tensions can interoperate with a router that doesn't support the extensions. [ST
ANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4760"/>
<seriesInfo name="DOI" value="10.17487/RFC4760"/>
</reference>
<reference anchor="RFC5492" target="https://www.rfc-editor.org/info/rfc5
492" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5492.xml">
<front>
<title>Capabilities Advertisement with BGP-4</title>
<author fullname="J. Scudder" initials="J." surname="Scudder"/>
<author fullname="R. Chandra" initials="R." surname="Chandra"/>
<date month="February" year="2009"/>
<abstract>
<t>This document defines an Optional Parameter, called Capabilitie
s, that is expected to facilitate the introduction of new capabilities in the Bo
rder Gateway Protocol (BGP) by providing graceful capability advertisement witho
ut requiring that BGP peering be terminated.</t>
<t>This document obsoletes RFC 3392. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5492"/>
<seriesInfo name="DOI" value="10.17487/RFC5492"/>
</reference>
<!-- &RFC6513;
&RFC6514;
&RFC6625; -->
<reference anchor="RFC6368" target="https://www.rfc-editor.org/info/rfc636
8" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6368.xml">
<front>
<title>Internal BGP as the Provider/Customer Edge Protocol for BGP/M
PLS IP Virtual Private Networks (VPNs)</title>
<author fullname="P. Marques" initials="P." surname="Marques"/>
<author fullname="R. Raszuk" initials="R." surname="Raszuk"/>
<author fullname="K. Patel" initials="K." surname="Patel"/>
<author fullname="K. Kumaki" initials="K." surname="Kumaki"/>
<author fullname="T. Yamagata" initials="T." surname="Yamagata"/>
<date month="September" year="2011"/>
<abstract>
<t>This document defines protocol extensions and procedures for BG
P Provider/Customer Edge router iteration in BGP/MPLS IP VPNs. These extensions
and procedures have the objective of making the usage of the BGP/MPLS IP VPN tra
nsparent to the customer network, as far as routing information is concerned. [S
TANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6368"/>
<seriesInfo name="DOI" value="10.17487/RFC6368"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba"/>
<date month="May" year="2017"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying that
only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8538" target="https://www.rfc-editor.org/info/rfc8
538" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8538.xml">
<front>
<title>Notification Message Support for BGP Graceful Restart</title>
<author fullname="K. Patel" initials="K." surname="Patel"/>
<author fullname="R. Fernando" initials="R." surname="Fernando"/>
<author fullname="J. Scudder" initials="J." surname="Scudder"/>
<author fullname="J. Haas" initials="J." surname="Haas"/>
<date month="March" year="2019"/>
<abstract>
<t>The BGP Graceful Restart mechanism defined in RFC 4724 limits t
he usage of BGP Graceful Restart to BGP messages other than BGP NOTIFICATION mes
sages. This document updates RFC 4724 by defining an extension that permits the
Graceful Restart procedures to be performed when the BGP speaker receives a BGP
NOTIFICATION message or the Hold Time expires. This document also defines a new
subcode for BGP Cease NOTIFICATION messages; this new subcode requests a full se
ssion restart instead of a Graceful Restart.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8538"/>
<seriesInfo name="DOI" value="10.17487/RFC8538"/>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC4761" target="https://www.rfc-editor.org/info/rfc4
761" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4761.xml"> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4761.xml"
<front> />
<title>Virtual Private LAN Service (VPLS) Using BGP for Auto-Discove <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4781.xml"
ry and Signaling</title> />
<author fullname="K. Kompella" initials="K." role="editor" surname=" <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml"
Kompella"/> />
<author fullname="Y. Rekhter" initials="Y." role="editor" surname="R <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml"
ekhter"/> />
<date month="January" year="2007"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"
<abstract> />
<t>Virtual Private LAN Service (VPLS), also known as Transparent L
AN Service and Virtual Private Switched Network service, is a useful Service Pro <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8955.xml"
vider offering. The service offers a Layer 2 Virtual Private Network (VPN); howe />
ver, in the case of VPLS, the customers in the VPN are connected by a multipoint
Ethernet LAN, in contrast to the usual Layer 2 VPNs, which are point-to-point i
n nature.</t>
<t>This document describes the functions required to offer VPLS, a
mechanism for signaling a VPLS, and rules for forwarding VPLS frames across a p
acket switched network. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4761"/>
<seriesInfo name="DOI" value="10.17487/RFC4761"/>
</reference>
<reference anchor="RFC4781" target="https://www.rfc-editor.org/info/rfc4
781" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4781.xml">
<front>
<title>Graceful Restart Mechanism for BGP with MPLS</title>
<author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
<author fullname="R. Aggarwal" initials="R." surname="Aggarwal"/>
<date month="January" year="2007"/>
<abstract>
<t>A mechanism for BGP that helps minimize the negative effects on
routing caused by BGP restart has already been developed and is described in a
separate document ("Graceful Restart Mechanism for BGP"). This document extends
this mechanism to minimize the negative effects on MPLS forwarding caused by the
Label Switching Router's (LSR's) control plane restart, and specifically by the
restart of its BGP component when BGP is used to carry MPLS labels and the LSR
is capable of preserving the MPLS forwarding state across the restart.</t>
<t>The mechanism described in this document is agnostic with respe
ct to the types of the addresses carried in the BGP Network Layer Reachability I
nformation (NLRI) field. As such, it works in conjunction with any of the addres
s families that could be carried in BGP (e.g., IPv4, IPv6, etc.). [STANDARDS-TRA
CK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4781"/>
<seriesInfo name="DOI" value="10.17487/RFC4781"/>
</reference>
<reference anchor="RFC4364" target="https://www.rfc-editor.org/info/rfc4
364" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4364.xml">
<front>
<title>BGP/MPLS IP Virtual Private Networks (VPNs)</title>
<author fullname="E. Rosen" initials="E." surname="Rosen"/>
<author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
<date month="February" year="2006"/>
<abstract>
<t>This document describes a method by which a Service Provider ma
y use an IP backbone to provide IP Virtual Private Networks (VPNs) for its custo
mers. This method uses a "peer model", in which the customers' edge routers (CE
routers) send their routes to the Service Provider's edge routers (PE routers);
there is no "overlay" visible to the customer's routing algorithm, and CE router
s at different sites do not peer with each other. Data packets are tunneled thro
ugh the backbone, so that the core routers do not need to know the VPN routes. [
STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4364"/>
<seriesInfo name="DOI" value="10.17487/RFC4364"/>
</reference>
<reference anchor="RFC5880" target="https://www.rfc-editor.org/info/rfc5
880" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5880.xml">
<front>
<title>Bidirectional Forwarding Detection (BFD)</title>
<author fullname="D. Katz" initials="D." surname="Katz"/>
<author fullname="D. Ward" initials="D." surname="Ward"/>
<date month="June" year="2010"/>
<abstract>
<t>This document describes a protocol intended to detect faults in
the bidirectional path between two forwarding engines, including interfaces, da
ta link(s), and to the extent possible the forwarding engines themselves, with p
otentially very low latency. It operates independently of media, data protocols,
and routing protocols. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5880"/>
<seriesInfo name="DOI" value="10.17487/RFC5880"/>
</reference>
<!-- &RFC7524; -->
<reference anchor="RFC8955" target="https://www.rfc-editor.org/info/rfc895
5" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8955.xml">
<front>
<title>Dissemination of Flow Specification Rules</title>
<author fullname="C. Loibl" initials="C." surname="Loibl"/>
<author fullname="S. Hares" initials="S." surname="Hares"/>
<author fullname="R. Raszuk" initials="R." surname="Raszuk"/>
<author fullname="D. McPherson" initials="D." surname="McPherson"/>
<author fullname="M. Bacher" initials="M." surname="Bacher"/>
<date month="December" year="2020"/>
<abstract>
<t>This document defines a Border Gateway Protocol Network Layer R
eachability Information (BGP NLRI) encoding format that can be used to distribut
e (intra-domain and inter-domain) traffic Flow Specifications for IPv4 unicast a
nd IPv4 BGP/MPLS VPN services. This allows the routing system to propagate infor
mation regarding more specific components of the traffic aggregate defined by an
IP destination prefix.</t>
<t>It also specifies BGP Extended Community encoding formats, whic
h can be used to propagate Traffic Filtering Actions along with the Flow Specifi
cation NLRI. Those Traffic Filtering Actions encode actions a routing system can
take if the packet matches the Flow Specification.</t>
<t>This document obsoletes both RFC 5575 and RFC 7674.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8955"/>
<seriesInfo name="DOI" value="10.17487/RFC8955"/>
</reference>
</references> </references>
</references> </references>
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>
We would like to thank <contact fullname="Nabil Bitar"/>, <contact
fullname="Martin Djernaes"/>, <contact fullname="Roberto Fragassi"/>, <contact
fullname="Jeffrey Haas"/>, <contact fullname="Jakob Heitz"/>, <contact
fullname="Daniam Henriques"/>, <contact fullname="Nicolai Leymann"/>, <contact
fullname="Mike McBride"/>, <contact fullname="Paul Mattes"/>, <contact
fullname="John Medamana"/>, <contact fullname="Pranav Mehta"/>, <contact
fullname="Han Nguyen"/>, <contact fullname="Saikat Ray"/>, <contact
fullname="Valery Smyslov"/>, and <contact fullname="Bo Wu"/> for their
valuable input and contributions to the discussion and solution.
</t>
</section>
<section numbered="false" toc="default">
<name>Contributors</name>
<contact fullname="Clarence Filsfils">
<organization>Cisco Systems</organization>
<address>
<postal>
<street></street>
<city>Brussels</city>
<region></region><code>1150</code>
<country>Belgium</country>
</postal>
<email>cf@cisco.com</email>
</address>
</contact>
<contact fullname="Pradosh Mohapatra">
<organization>Sproute Networks</organization>
<address>
<email>mpradosh@yahoo.com</email>
</address>
</contact>
<contact fullname="Yakov Rekhter">
<organization></organization>
<address>
<email></email>
</address>
</contact>
<contact fullname="Eric Rosen">
<organization></organization>
<address>
<email>erosen52@gmail.com</email>
</address>
</contact>
<contact fullname="Rob Shakir">
<organization>Google, Inc.</organization>
<address>
<postal>
<street>1600 Amphitheatre Parkway</street>
<city>Mountain View</city>
<region>CA</region><code>94043</code>
<country>United States of America</country>
</postal>
<email>robjs@google.com</email>
</address>
</contact>
<contact fullname="Adam Simpson">
<organization>Nokia</organization>
<address>
<email>adam.1.simpson@nokia.com</email>
</address>
</contact>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 178 change blocks. 
1056 lines changed or deleted 634 lines changed or added

This html diff was produced by rfcdiff 1.48.