One document matched: draft-ietf-grow-bgp-gshut-00.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<rfc ipr='pre5378Trust200902' docName='draft-ietf-grow-bgp-gshut-00' category="info">

<front> 
<date month='June' year='2009' day='15'/>


<title>Graceful BGP session shutdown</title>

<author surname="Pierre Francois" name ="Francois" fullname="Pierre Francois">
<organization>Universite catholique de Louvain</organization>
<address>
<postal>
<street>Place Ste Barbe, 2</street>
<city>Louvain-la-Neuve</city> <code>1348</code>
<country>BE</country>
</postal>
<uri>http://inl.info.ucl.ac.be/pfr</uri>
<email>pierre.francois@uclouvain.be</email>
</address>
</author>


<author surname="Bruno Decraene" name ="Decraene" fullname="Bruno Decraene">
<organization>France Telecom</organization>
<address>
<postal>
<street>38-40 rue du General Leclerc</street>
<city>92794 Issi Moulineaux cedex 9</city> <code></code>
<country>FR</country>
</postal>
<email>bruno.decraene@orange-ftgroup.com</email>
</address>
</author>

<author surname="Cristel Pelsser" name = "Pelsser" fullname="Cristel Pelsser">
<organization>NTT Corporation</organization>
<address>
<postal>
<street>9-11, Midori-Cho 3 Chrome</street>
<city>Musashino-Shi, Tokyo</city> <code>180-8585</code>
<country>JP</country>
</postal>
<email>pelsser.cristel@lab.ntt.co.jp</email>
</address>
</author>

<author surname="Clarence Filsfils" name = "Filsfils" fullname="Clarence Filsfils">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>De kleetlaan 6a </street>
<city>Diegem</city> <code>1831</code>
<country>BE</country>
</postal>
<email>cfilsfil@cisco.com</email>
</address>
</author>

<area>General</area>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>

<abstract>
	
	<t>This draft describes operational procedures aimed at reducing the
		amount of traffic lost during planned maintenances of
		routers, involving the shutdown of BGP peering
		sessions.
	</t>

</abstract>

</front>

<middle>
<section title="Introduction">

	<t> Routing changes in BGP can be caused by planned, manual,
	maintenance operations. This document discusses operational
	procedures to be applied in order to reduce or eliminate
	losses of packets during the maintenance. These losses come
	from the transient lack of reachability during the BGP
	convergence following the shutdown of an eBGP peering session
	between two Autonomous System Border Routers (ASBR).</t>

	<t> This document presents procedures for the cases where the
	forwarding plane is impacted by the maintenance, hence when
	the use of Graceful Restart does not apply.</t>


	<t> The procedures described in this document can be applied
	to reduce or avoid packet loss for outbound and inbound
	traffic flows initially forwarded along the peering link to be
	shut down.  These procedures allow routers to keep using old
	paths until alternate ones are learned, ensuring that routers
	always have a valid route available during the convergence
	process.</t>

	<t> The goal of the document is to meet the requirements
	described in <xref target="REQS"/> at best, without
	changing the BGP protocol or BGP implementations.</t>

	<t> Still, it explains why reserving a community value for
	the purpose of BGP session graceful shutdown would reduce the
	management overhead bound with the solution. It would also
	allow vendors to provide an automatic graceful shutdown mechanism that
	does not require any configuration at maintenance time. </t>


</section>

<section title = "Terminology">

	<t> g-shut initiator : a router on which the session shutdown
	is performed for the maintenance. </t>

	<t> g-shut neighbor : a router that peers with the g-shut
	initiator via (one of) the session(s) to be shut down.</t>

	<t> Note that for the link-up case, we will refer to these
	nodes as g-no-shut initiator, and g-no-shut neighbor.</t>

	<t> Initiator AS : the Autonomous System of the g-shut initiator.</t>

	<t> Neighbor AS : the Autonomous System of the g-shut neighbor.</t> 

	<t> Affected path / Nominal / pre-convergence path : a BGP path via the peering link(s)
		undergoing the maintenance. This path will no longer exist
		after the shutdown.</t>

<!--
	<t> Nominal / pre-convergence path : A path that is rendered
	invalid due to maintenance. In the case of the maintenance of
	an eBGP peering link, an affected path is one via the peering
	link being shut down. In the case of the maintenance of an
	iBGP peering link, an affected path is one learned via the
	session being shut down. </t>-->
	
	<t> Affected prefix : a prefix initially reached via an affected path.</t>

	<t> Affected router : a router having an affected prefix.</t>

	<t> Backup / alternate / post-convergence path : a path toward an affected
		prefix that will be selected as the best path by an affected
		router, when the link is shut down and the BGP
		convergence is completed.</t>

	<t> Transient alternate path : a path towards an affected prefix that
		may be transiently selected as best by an affected router
		during the convergence process but that is not a
		post-convergence path.  </t>
	
	<t> Loss of Connectivity (LoC) : the state when a router has
	no path towards an affected prefix.</t>


</section>

<section title="Packet loss upon manual eBGP session shutdown" anchor="sec.loss">

	<t> Packets can be lost during a manual shutdown of an eBGP
	session for two reasons. </t>
			
	<t> First, routers involved in the convergence process can
	transiently lack of paths towards an affected prefix, and drop traffic
	destined to this prefix. This is because alternate paths can
	be hidden by nodes of an AS. This happens when the paths are
	not selected as best by the ASBR that receive them on an eBGP
	session, or by Route Reflectors that do not propagate them
	further in the iBGP topology because they do not select them
	as best. </t>

	<t> Second, within the AS, routers' FIB can be transiently
	inconsistent during the BGP convergence and packets towards
	affected prefixes can loop and be dropped. Note that these
	loops only happen when ASBR-to-ASBR encapsulation is not used
	within the AS.</t>

	<t> This document only addresses the first reason. </t>

</section>




<section title = "Practices to avoid packet losses" anchor = "sec.practices">

	<t>This section describes means for an ISP to reduce the
	transient loss of packets upon a manual shutdown of a BGP
	session. </t>

	<section title = "Improving availability of alternate paths">
	
	<t>All solutions that increase the availability of alternate
	BGP paths in routers performing packet lookups in BGP tables <xref
	target="BestExternal"/> <xref target="AddPath"/> help in
	reducing the LoC bound with manual shutdown of eBGP sessions.
	</t>

	<t>One solution increasing diversity in such a way that, at
	any single step of the convergence process following the eBGP
	session shutdown, a BGP router does not receive a message
	withdrawing the only path it currently knows for a given NLRI,
	allows for a simplified g-shut procedure. This simplified
	procedure would only tackle potential LoC for the inbound
	traffic.</t>

	<t>Using advertise-best-external <xref target="BestExternal"/>
	on ASBRs and RRs helps in avoiding lack of alternate paths in route
	reflectors upon a convergence. Hence it reduces the LoC
	duration for the outbound traffic of the ISP upon an eBGP
	Session shutdown by reducing the iBGP path hunting.</t>

	<t>Still it does not ensure that BGP routers will always have
	at least one path towards affected prefixes during the
	convergence following the event. This property may be verified
	in future revisions of <xref target="BestExternal"/>, notably
	of its Section 4, hence the current proposal will be updated
	accordingly.</t>


	<t>Increasing diversity with <xref target="AddPath"/> might lead
	to the respect of this property, depending on the path
	propagation decision process that add-path compliant routers
	would use. </t>

	<t>Note that the LoC for the inbound traffic of the maintained
	router, induced by a lack of alternate path propagation within
	the iBGP topology of a neighboring AS is not under the control
	of the operator performing the maintenance, hence the
	procedure described in <xref target = "sec.inbound"/> should be applied
	upon the maintenance, even if not required for the outbound traffic.
	</t>

	</section>

	<section title = "Graceful shutdown procedures for eBGP sessions">

		<t> This section aims at describing a procedure to be
		applied to reduce the LoC with readily available BGP
		features, and without assuming a particular iBGP design
		in the Initiator and Neighbor ASes.</t>

		<section title = "Outbound traffic" anchor = "sec.outbound">

			<t>This section discusses a mean to render the
			affected paths less desirable by the BGP
			decision process of affected routers, still
			allowing these to be used during the
			convergence while alternate paths are
			propagated to the affected routers.</t>
				
			

<!--			<section title = "Local Preference tweaking" anchor = "sec.loc-pref">-->

				<t>A decrease of the local-pref value
				of the affected paths can be issued in
				order to render the affected paths
				less preferable, at the highest
				possible level of the BGP Decision
				Process.</t>

				<t>This operation can be performed by
				reconfiguring the out-filters
				associated with the iBGP sessions
				established by the g-shut initiator.
				</t>

				<t> The modification of the filters
				MUST supplant any other rule affecting
				the local-pref value of the old
				paths.</t>

				<t> Compared to using an in-filter of
				the eBGP session to be shut down, the
				modification of the out-filters will
				not let the g-shut initiator switch to
				another path, as the input to the BGP
				decision process of that router does
				not change. As a consequence, the g-shut
				initiator will not send a withdraw
				message over its iBGP sessions when it
				receives an alternate path over an iBGP
				session. It will however modify the
				local-pref of the affected paths so
				that upstream routers will switch to
				alternate ones.</t>

				<t> When the actual shutdown of the
				session is performed, the g-shut
				initiator will itself switch to the
				alternate paths.</t>


<!--
		<section title = "Outbound traffic, simplified g-shut procedure" anchor = "sec.outbound.simplified">


		  <t>In an iBGP deployment where no transient lack of
		  alternate paths can occur during the convergence of
		  the BGP routers within the initiator AS, an
		  in-filter modification can directly be issued so
		  that all routers, including the g-shut initiator,
		  switch to the alternate paths before the data-plane
		  is impacted by the maintenance operation.
		  </t>

		</section>
-->
		</section>

	<section title = "Inbound traffic" anchor = "sec.inbound">

	  <t> The solution described for the outbound traffic can be
	  applied at the neighbor AS. This can be done either
	  "manually" or by using a community value dedicated to this
	  task.</t>

		<section title = "Phone call" anchor = "sec.phone"> 

			<t> The operator performing the maintenance of
			the eBGP session can contact the operator at
			the other side of the peering link, and let
			him apply the procedure described above for
			its own outbound traffic.</t>

		</section>

		<section title = "Community tagging" anchor = "sec.community">

			<t> A community value (referred to as GSHUT
			community in this document) can be agreed upon
			by neighboring ASes. A path tagged with this
			community must be considered as soon to be
			affected by a maintenance operation. </t>
			
			<section title ="Pre-Configuration"> 

			<t> A g-shut neighbor is pre-configured to set
			a low local-pref value for the paths received
			over eBGP sessions which are tagged with the
			GSHUT community.</t>

			<t>This rule must supplant any other rule
			affecting the local-pref value of the
			paths. </t>

			<t>This local-pref reconfiguration SHOULD be
			performed at the out-filters of the iBGP
			sessions of the g-shut neighbor. That is, the
			g-shut neighbor does not take into account
			this low local-pref in its own BGP best path
			selection. As described in <xref target = "sec.outbound"
			/> this avoids sending the withdraw messages
			that can lead to LoC.  </t>

			</section>

			<section title = "Operational action upon maintenance">

				<t>Upon the manual shutdown, the
				output filter associated with the
				maintained eBGP session will be
				modified on the g-shut initiator so as
				to tag all the paths advertised over
				the session with the GSHUT community.
				</t>

			</section>

			<section title = "Transitivity of the community">

				<t>If the GSHUT community is an
				extended community, it SHOULD be set
				non transitive.</t>
				
				<t>If a normal community is used, this
				community SHOULD be removed from the
				path by the ASBR of the peer receiving
				it. If not, the GSHUT community MAY be
				removed from the path by all the ASBRs of
				the neighboring AS, before propagating the path
				to other peers.</t>

				<t>Not propagating the community
				further in the Internet reduces the
				amount of BGP churn and avoids
				rerouting in distant ASes that would
				also recognize this community value.
				In other words, it helps concealing
				the convergence at the maintenance
				location. </t>

				<t> There are cases where an
				interdomain exploration is to be
				performed to recover the reachability,
				e.g., in the case of a shutdown in
				confederations where the alternate
				paths will be found in another AS of
				the confederation. In such scenarios,
				the community value SHOULD be allowed
				to transit through the confederation
				but MAY be removed from the paths
				advertised outside of the
				confederation.</t>

				<t> When the local-pref value of a
				path is conserved upon its propagation
				from one AS of the confederation to
				the other, there is no need to have
				the GSHUT community be propagated
				throughout that confederation. </t>

			</section>

			<section title = "Easing the configuration for G-SHUT">

			  <t>From a configuration burden viewpoint, it
			  would be much easier to reserve a value for
			  the GSHUT community.</t>
				
			  <t> First, on the g-shut initiator, an
			  operator would have a single configuration
			  rule to be applied at the maintenance time,
			  which would not depend on the identity of
			  its peer. This would make the maintenance
			  operations less error prone.</t>

			  <t>Second, on the g-shut neighbor, a simple
			  filter related to g-shut can be applied to
			  all iBGP sessions. Additionnaly, this filter
			  doesn't need to be updated each time
			  neighboring ASes are added or removed.</t>


			</section>

<!-- 
			<section title = "Using multiple GSHUT community values">

				<t>As for the outbound traffic, and as
					illustrated in <xref target="sec.applicability"/>, a two step approach
					may be used to avoid the LoC due to a
					maintenance. The behavior described
					here for inbound traffic is equivalent
					to the in-filter reconfiguration step
					described for the outbound traffic. If
					a two step approach is required by the
					peer for its outbound traffic (i.e.,
					for the inbound traffic of the
					maintained AS), then two community values could be used.					
				</t>

				<t>One community value, GSHUT-out, could be
					tagged to the old paths in a first
					step, by the g-shut initiator.  The
					out-filter of the iBGP sessions of the
					ASBR of the g-shut neighbor would be
					configured to reduce the local-pref
					value of such paths.</t>

				<t>The second community value, GSHUT-in, would
					lead to a local-pref decrease in the
					in-filter of the g-shut neighbor, hence
					applying the "in-filter" behavior as
					described for outbound traffic.	</t>

				<t>Of course, ISPs are free to agree upon a
					larger set of community values to apply
					more complex maintenance policies.</t>

			</section>
                      <section title = "Simplified g-shut procedure" anchor = "sec.inbound.simplified">

		      </section>
-->



		</section>
	
	</section>
	</section>
	<section title = "Graceful shutdown procedures for iBGP sessions">

		<t>If the iBGP topology is viable after the
		maintenance of the session, i.e, if all BGP speakers
		of the AS have an iBGP signaling path for all prefixes
		advertised on this g-shut iBGP session, then the
		shutdown of an iBGP session does not lead to transient
		unreachability. </t>

		<t>However, in the case of a shutdown of a router, a
		reconfiguration of the out-filters of the g-shut
		initiator should be performed to set a low local-pref
		value for the paths originated by the g-shut initiator
		(e.g, BGP aggregates redistributed from other
		protocols, including static routes).</t>

		<t>This behavior is equivalent to the recommended
		behavior for paths "redistributed" from eBGP sessions
		to iBGP sessions in the case of the shutdown of an
		ASBR. </t>

	</section>

</section>

<section title="Forwarding modes and forwarding loops" anchor="sec.forwarding">

	<t>If the AS applying the solution does not rely on
	encapsulation to forward packets from the Ingress Border
	Router to the Egress Border Router, then transient forwarding
	loops and consequent packet losses can occur during the
	convergence process, even if the procedure described above is
	applied. Hence if zero LoC is required, encapsulation is
	required between ASBRs of the AS.
</t>

	<t> Using the out-filter reconfiguration avoids the forwarding
	loops between the g-shut initiator and its directly connected
	upstream neighbors. Indeed, when this reconfiguration is
	applied, the g-shut initiator keeps using its own external
	path and lets the upstream routers converge to the alternate
	ones. During this phase, no forwarding loops can occur between
	the g-shut initiator and its upstream neighbors as the g-shut
	initiator keeps using the affected paths via its eBGP peering
	links. When all the upstream routers have switched to
	alternate paths, the transition performed by the g-shut
	initiator when the session is actually shut down, will be
	loopfree.  Transient forwarding loops between other routers
	will not be avoided with this procedure. </t>

</section>



<section title = "Dealing with Internet policies" anchor = "sec.policies">

	<t>A side gain of the maintenance solution is that it can also
	reduce the churn implied by a shutdown of an eBGP session.</t>

	<t>For this, it is recommended to apply the filters modifying
	the local-pref value of the paths to values strictly lower but
	as close as possible to the local-pref values of the
	post-convergence paths.  </t>

	<t> For example, if an eBGP link is shut down between a
	provider and one of its customers, and another link
	with this customer remains active, then the value of the
	local-pref of the old paths SHOULD be decreased to the
	smallest possible value of the 'customer' local_pref range,
	minus 1.  Thus, routers will not transiently switch to paths
	received from shared-cost peers or providers, which could lead
	to the propagation of withdraw messages over eBGP sessions with
	shared-cost peers and providers.</t>

	<t> Proceeding like this reduces both BGP churn and traffic
	shifting as routers will less likely switch to transient
	paths.</t>

	<t> In the above example, it also prevents transient
	unreachabilities in the neighboring AS that are due to the
	sending of "abrupt" withdraw messages to shared-cost peers and
	providers.</t>

</section>

<section title = "Effect of the g-shut procedure on the convergence" anchor = "sec.applicability">

	<t> This section describes the effect of applying the solution.</t>

	<section title = "Maintenance of an eBGP session">

		<t> This section describes the effect of applying the solution for the shutdown of an eBGP session. </t>
	
		<section title = "Propagation on the other eBGP sessions of the g-shut initiator">
			
			<t>Nothing is propagated on the other eBGP sessions
				when the out-filters reconfiguration step is
				applied.  The reconfiguration is indeed only
				defined for its iBGP sessions.</t>

			<t>The reconfiguration of the iBGP out-filters will
				trigger the reception of alternate paths at the
				g-shut initiator. As the eBGP in-filters have
				not been modified at that step, the old paths
				are still preferred by the g-shut initiator.
			</t>

		</section>

		<section title = "Propagation on the other iBGP sessions of the g-shut initiator">
			
			<t>During the out-filter reconfiguration, path updates are propagated
				with a reduced local-pref value for the
				affected paths.  As a consequence, Route
				Reflectors and distant ASBRs select and propagate
				alternate paths through the iBGP topology as
				they no longer select the old paths as best.  </t>

<!--
			<t>When the shut-down is performed, the g-shut initiator propagates the alternate
				paths that it received on eBGP sessions to its
				iBGP sessions. Also, it withdraws on its iBGP
				sessions the paths for which the best alternate was 
				received over its iBGP sessions.</t> -->

			<t> When the shut-down is performed, for each affected prefix, the g-shut initiator propagates on its iBGP sessions:</t>

			<t> . The alternate path, if the best path was received over an eBGP sessions.</t>
			<t> . A withdraw, if the best path was received over an iBGP sessions.</t>

		</section>

		<section title = "Propagation of updates in an iBGP full-mesh">

			<t> No transient LoC can occur if a reconfiguration of
				the iBGP out-filters on the g-shut initiator
				is performed.</t>			

		</section>

		<section title = "Propagation of updates from iBGP to iBGP in a RR hierarchy" anchor ="sec.corner">

			<t>Upon the reception of the update of a
			primary path with a lower local-pref value
			from a client, a Route Reflector RR1 will either
			propagate the update, or select an alternate
			path, depending on the fact that the updated
			primary path is still the best one w.r.t. the state of
			the Adj-Rib-In of RR1.

			<t>If the updated primary path is still the
			best, then the RR will propagate an update for
			this path to the iBGP neighbors to which it
			previously advertised the path. Hence it
			cannot cause transient lack of path in the
			Adj-Rib-In of its iBGP neighbors.
			</t>

			<t>If an alternate path is picked, and this
			path was also originated by a client of RR1,
			an update will also be propagated to the same
			neighbors as the one to which the primary path
			was initially propagated. Hence it cannot
			cause transient lack of path in the Adj-Rib-In
			of its iBGP neighbors.</t>

			<t> If an alternate path is picked, and this
			path was received from a member of its
			Route-Reflector iBGP full-mesh, then a
			withdraw message is sent.  As the alternate
			path has been sent over each session of the
			iBGP full-mesh, the propagation of a withdraw
			for the primary path of RR1 is done to routers
			that are expected to know the alternate path
			picked by RR1.</t>

			<t>The following example describes a situation
			where some corner case timings could lead to transient unreachability from some
			members of the iBGP full-mesh.</t>
			<vspace />

			
				<list style="empty" hangIndent="5" >
				  <t></t>
			<t>1. A Route Reflector RR1 only knew about
			the primary path upon the shutdown.</t>
			<t> </t>
			<t>2. A member of its RR full-mesh, RR2,
			propagates an update of the old path with a
			lower local-pref.</t>
			<t> </t>
			<t>3. Another member of its RR full-mesh, RR3
			processes the update, selects an alternate
			path, and propagates an update in the
			mesh.</t>
			<t> </t>
			<t>4. RR2 receives the alternate path, selects
			it as best, and hence withdraws the updated
			old path on the iBGP sessions of the mesh.</t>
			<t> </t>
			<t>5. If for any reason, RR1 receives and
			processes the withdraw generated in step 4
			before processing the update generated in step
			3, RR1 transiently suffers from unreachability
			for the affected prefix. </t>
			
			</list></t>
			

			<t>In such corner cases, the solution improves
			the iBGP convergence behavior/LoC but does not
			ensure 0 packet loss, as we cannot define a
			simple solution relying only on a
			reconfiguration of the filters of the g-shut
			initiator. Improving the availability of
			alternate paths in Route Reflectors, using
			<xref target ="BestExternal"/>, or <xref
			target ="AddPath"/>, seems to be the most
			pragmatic solution to these corner cases. </t>

			<t> The use of <xref target="BestExternal"/>
			in the iBGP full-mesh between RRs can solve
			these corner cases by ensuring that within an
			AS, the advertisement of a new path is not
			translated into the withdraw of a former
			path.</t>

			<t> Indeed, "best-external" ensures that an
			ASBR does not withdraw a previously advertised
			(eBGP) path when it receives an additional,
			preferred path over an iBGP session. Also,
			"best-intra-cluster" ensures that a RR does
			not withdraw a previously advertised (iBGP)
			path to its non clients (e.g. other RRs in a
			mesh of RR) when it receives a new, preferred
			path over an iBGP session.</t>

		</section>

	</section>

	<section title = "Maintenance of an iBGP session">

		<t>If the shutdown does not temper with the
		viability of the iBGP topology, the described
		procedure is sufficient to avoid LoC.</t>

	</section>

	<section title = "Applicability of the g-shut procedure">

		<t> The applicability of the procedure described in
		this draft to the cases presented in <xref target =
		"REQS"/> can be shown by combining the
		effects described in this section. A complete case by
		case analysis will be provided in the next versions of
		the draft. </t>
		
		

	</section>
			

<section title = "Summary of operations" target = "sec.summary">

<t>This section summarizes the configurations and actions to be
performed to support the g-shut procedure for eBGP peering links. </t>

   <section title = "Pre-configuration" target = "sec.summary.config">

     <t> On each ASBR supporting the g-shut procedure, set-up an out-filter applied on all iBGP sessions
     of the ASBR, that :</t>

     <t> . sets the local-pref of the paths tagged with the g-shut community to a low value</t>
     <t> . removes the g-shut community from the path.</t>
     
   </section>

   <section title = "Operations at maintenance time" target = "sec.summary.shut">
     
     <t> On the g-shut initiator : </t>
     
     <t> . Apply an in-filter on the maintained BGP session to tag the paths received over the session with the g-shut community. </t> 
     
     <t> . Apply an out-filter on the maintained BGP session to tag the paths propagated over the session with the g-shut community.</t>

     <t> . Wait for convergence to happen.</t>

     <t> . Perform a BGP session shutdown. </t>


     
   </section>

<t></t>

</section>


</section>

<!--- <section title = "How to choose a solution" anchor = "sec.pickone"> </section>-->

<!--
<section title = "Better Future" anchor = "sec.better">  

	<t> A standardized community value could be used to ease the
		configuration related to the graceful shutdown of eBGP
		sessions.  By proceeding like this, neighboring ASes would not
		have to agree on a specific community value dedicated to this
		task, and the value of the community would not differ from one
		neighboring AS to another.</t>		
		
	<t> An automatic application of the local pref tunning could be
		featured by vendors. Various possibilities, from
		a configuration-free to more complex, policy-friendly,
		configurations of the technique could be provided by vendors.</t>

</section>
-->

<section title = "Link Up cases">
  
  <t>We identify two potential causes for transient packet losses upon
  an eBGP link up event. The first one is local to the g-shut initiator,
  the second one is due to the BGP convergence following the injection of new
  best paths within the iBGP topology. </t>

  <section title = "Unreachability local to the ASBR">
    
    <t>An ASBR that selects as best a path received over a newly
    brought up eBGP session may transiently drop traffic. This can
    typically happen when the nexthop attribute differs from the IP
    address of the eBGP peer, and the receiving ASBR has not yet
    resolved the MAC address associated with the IP address of that
    "third party" nexthop. </t>

    <t>A BGP speaker implementation could avoid such losses by
    ensuring that "third party" nexthops are resolved before
    installing paths using these in the RIB.</t>

    <t>If the link up event corresponds to an eBGP session that is being manually
    brought up, over an already up multi-access link, then the
    operator can ping third party nexthops that are expected to be
    used before actually bringing the session up, or ping directed
    broadcast the subnet IP address of the link. By proceeding like
    this, the MAC addresses associated with these third party nexthops
    will be resolved by the g-no-shut initiator.
    </t>

  </section>

  <section title = "iBGP convergence">

    <t> Similar corner cases as described in <xref
    target="sec.corner"/> for the link down case, can occur during an eBGP link up event.</t>

    <t>A typical example for such transient unreachability for a given
    prefix is the following :</t>
	
	<t><list style="empty" hangIndent="5" >

	  <t>1. A Route Reflector, RR1, is initially advertising the
	  current best path to the members of its iBGP RR
	  full-mesh. It propagated that path within its RR
	  full-mesh. Another route reflector of the full-mesh, RR2,
	  knows only that path towards the prefix.
	  </t>
	
	  <t>2. A third Route Reflector of the RR full-mesh, RR3
	  receives a new best path orginated by the "g-no-shut"
	  initiator, being one of its RR clients. RR3 selects it as
	  best, and propagates an UPDATE within its RR full-mesh,
	  i.e., to RR1 and RR2.
	  </t>
 
	  <t>3. RR1 receives that path, reruns its decision process,
	  and picks this new path as best. As a result, RR1 withdraws
	  its previously announced best-path on the iBGP sessions of its RR full-mesh.
	  </t>
	
	  <t>4. If, for any reason, RR3 processes the withdraw
	  generated in step 3, before processing the update generated
	  in step 2, RR3 transiently suffers from unreachability for
	  the affected prefix. </t>
			
	  </list>
	</t>

	
			
	<t> The use of <xref target="BestExternal"/> among the RR of
	the iBGP full-mesh can solve these corner cases by ensuring
	that within an AS, the advertisement of a new route is not
	translated into the withdraw of a former route.</t>

	<t> Indeed, "best-external" ensures that an ASBR does not
	withdraw a previously advertised (eBGP) path when it receives
	an additional, preferred path over an iBGP session. Also,
	"best-intra-cluster" ensures that a RR does not withdraw a
	previously advertised (iBGP) path to its non clients
	(e.g. other RRs in a mesh of RR) when it receives a new,
	preferred path over an iBGP session.</t>

  </section>

  

</section>


<section title = "Alternative techniques with limited applicability">


  <t>A few alternative techniques have been considered to provide
  g-shut capabilities but have been rejected due to their limited
  applicability.  This section describe them for possible
  reference.</t>



  <section title = "In-filter reconfiguration" anchor = "sec.loc-pref.infilter">
    
    <t>An In-filter reconfiguration on the eBGP session undergoing the
    maintenance could be performed instead of out-filter
    reconfigurations on the iBGP sessions of the g-shut initiator.</t>
				
    <t>Upon the application of the maintenance procedure, if the
    g-shut initiator has an alternate path in its Adj-Rib-In, it will
    switch to it directly.</t>
				       
    <t>If this new path was advertised by an eBGP neighbor of the
    g-shut initiator, the g-shut initiator will send a BGP Path Update
    message advertising the new path over its iBGP and eBGP sessions.</t>
						
    <t>If this new path was received over an iBGP session, the g-shut
    initiator will select that path and withdraw the previously
    advertised path over its non-client iBGP sessions. There can be
    iBGP topologies where the iBGP peers of the g-shut initiator do
    not know an alternate path, and hence may drop traffic.</t>

    <t> Also, applying an In-filter reconfiguration on the eBGP session undergoing the maintenance 
may lead to transient LoC, in full-mesh iBGP topologies if </t>
		<t>
		<list style="empty" hangIndent="5" >

					<t> a. An ASBR of the
					initiator AS, ASBR1 did not
					initially select its own
					external path as best, and
					</t>
					<t> </t>
					<t> b. An ASBR of the
					initiator AS, ASBR2 advertises
					a new path along its
					iBGP sessions upon the
					reception of ASBR1's update
					following the in-filter
					reconfiguration on the g-shut
					initiator, and</t>
					<t> </t>
					<t> c. ASBR1 receives the
					update message, runs its
					Decision Process and hence
					withdraws its
					external path after having
					selected ASBR2's path as best,
					and</t>
					<t> </t>
					<t> d. An impacted router of the AS processes the
					withdraw of ASBR1 before processing
					the update from ASBR2.</t> 	
				</list>
			</t>

	<t> Applying a reconfiguration of the out-filters prevents
	such transient unreachabilities.</t>

	<t> Indeed, when the g-shut initiator propagates an update of
	the old path first, the withdraw from ASBR2 does
	not trigger unreachability in other nodes, as the old path is
	still available. Indeed, even though it receives alternate
	paths, the g-shut initiator keeps using its old path as best
	as the in-filter of the maintained eBGP session has not been
	modified yet. </t>

	<t> Applying the out-filter reconfiguration also prevents
	packet loops between the g-shut initiator and its direct
	neighbors when encapsulation is not used between the ASBRs of
	the AS.</t>

  </section>
	

  <section title = "Multi Exit Discriminator tweaking" anchor = "sec.med-poison"> 

			<t> The MED attribute of the paths to be avoided can be
				increased so as to force the routers in the
				neighboring AS to select other paths. </t>

			<t> The solution only works if the alternate paths are
				as good as the initial ones with respect to the
				Local-Pref value and the AS Path Length value.
				In the other cases, increasing the MED value
				will not have an impact on the decision process
				of the routers in the neighboring AS.  </t>
		
		</section>

		<section title = "IGP distance Poisoning" anchor = "sec.igp-poison">

			<t> The distance to the BGP nexthop corresponding to the maintained session 
				can be increased in the IGP so that the old paths will be less preferred
				during the application of the IGP distance tie-break rule. However, this
				solution only works for the paths whose
				alternates are as good as the old paths with
				respect to their Local-Pref value, their AS
				Path length, and their MED value.</t>

			<t> Also, this poisoning cannot be applied
			when nexthop self is used as there is no
			nexthop specific to the maintained session to
			poison in the IGP.
			</t>
		</section>


</section>


<section title = "IANA considerations">

<t>Applying the g-shut procedure is rendered much easier with a
reserved g-shut community value.  Hence this draft suggests to reserve
a community value, e.g., 0xFFFF0000, for this purpose. </t>

</section>

<section title = "Security Considerations">

	<t> By providing the g-shut service to a neighboring AS, an ISP provides
	means to this neighbor to lower the local-pref value assigned to the paths received
	from this neighbor. </t>

	<t> The neighbor could abuse the technique and do inbound traffic
	engineering by declaring some prefixes as undergoing a maintenance so as to
	switch traffic to another peering link.</t>

	<t>If this behavior is not tolerated by the ISP, it SHOULD monitor the use
	of the g-shut community by this neighbor.</t> 

</section>



<section title = "Acknowledgments">

<t>The authors wish to thank Olivier Bonaventure and Pradosh Mohapatra
for their useful comments on this work.</t>

</section>

</middle>
<back>
<references>




<reference anchor = "AddPath">
	<front>
		<title>Advertisement of Multiple Paths in BGP</title>
		<author initials ="" surname = "D. Walton" fullname="D. Walton"></author>
		<author initials = "" surname = "A. Retana" fullname = "A. Retana"></author>
		<author initials ="" surname = "E. Chen" fullname="E. Chen"></author>
		<!--<date month = "July" year = "2007"></date>-->
	</front>
	<seriesInfo name ="Internet-Draft" value = "draft-walton-bgp-add-paths-06.txt"/>

</reference>

<reference anchor = "BestExternal">
<front>
<title>Advertisement of the best-external route to IBGP</title>
<author initials ="P." surname = "Marques" fullname="P. Marques"></author>
<author initials ="R." surname = "Fernando" fullname="R. Fernando"></author>
<author initials ="E." surname = "Chen" fullname="E. Chen"></author>
<author initials ="P." surname = "Mohapatra" fullname="P. Mohapatra"></author>
<date month = "July" year="2008"> </date>
</front>
<seriesInfo name="" value ="draft-marques-idr-best-external-00.txt"/>
</reference>

<reference anchor = "REQS">
<front>
<title>Requirements for the graceful shutdown of BGP sessions</title>
<author initials ="B." surname = "Decraene" fullname="B. Decraene"></author>
<author initials ="P." surname = "Francois" fullname="P. Francois"></author>
<author initials ="C." surname = "Pelsser" fullname="C. Pelsser"></author>
<author initials ="Z." surname = "Ahmad" fullname="Z. Ahmad"></author>
<date month = "May" year="2009"> </date>
</front>
<seriesInfo name="" value ="draft-ietf-grow-bgp-graceful-shutdown-requirements-00.txt "/>
</reference>



</references>

</back>
</rfc>