One document matched: draft-francois-bgp-gshut-00.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<rfc ipr='full3978' docName='draft-francois-bgp-gshut-00'>

<front>
<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>

<date month="March" year="2008" />
<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 standardizing 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> 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 BR-to-BR 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>Using advertise-best-external on ASBRs improves the
		availability of alternate paths. Hence it reduces the LoC duration
		for the outbound traffic of the ISP upon an eBGP
		Session shutdown. </t>

		<t>All solutions that improve the availability of
		paths beyond the Route Reflectors barrier also help in
		reducing the LoC. These have been discussed for years
		but are not yet available, probably due to their
		implementation complexity.
		</t>

		<!--
		<t> Also, the LoC for the inbound traffic 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. </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 particular iBGP
		design for the AS performing the maintenance and in
		the neighboring 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>-->

		</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
				have the GSHUT community value be
				standardized. </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, the same filter related to
				g-shut can be applied to all iBGP
				sessions, at the g-shut neighbor.
				</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>
	
	</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
		affected prefixes after the convergence, 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.</t>

	<t> Using the out-filter reconfiguration avoids the forwarding
	loops between the g-shut initiator and its 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 neighbor keeps
	using the affected paths via its eBGP peering links. When the
	first step is finished, all the upstream routers have switched
	to alternate paths and the transition performed by the g-shut
	initiator 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 be
	used to 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 a peering link is shut down between a
	provider and one of its customers, and another peering 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 sending 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 our 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">

			<t>Upon the reception of the update of a primary path with a lower local-pref value, 
				Route Reflectors will either propagate the update, or select an alternate path
				and propagate it within their RR iBGP full-mesh, to their own Route Reflectors in the case
				of a multiple level Route Reflector hierarchy, and to their clients.</t>

			<t>During the convergence process controlled with the described procedure, some corner case timings can trigger
				transient unreachabilities.</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 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 session
				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
			advertise best external, or any flavor of
			add-path <xref target ="AddPath"/>,
			seems to be the most pragmatic solution to
			these corner cases. </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 procedures">

		<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 = "Techniques with limited applicability">

  <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 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 directly propagate a withdraw
    message over the iBGP sessions for which it is not acting as a
    Route Reflector. 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 propagates
					an Update message 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
					propagates a withdraw of 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 sending of the withdraw by 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 when the g-shut community value is to be standardized. 
Hence this draft suggests to reserve a community value, e.g., 0xFFFF0005, 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>

</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-05.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 = "December" year="2007"> </date>
</front>
<seriesInfo name="" value ="draft-decraene-bgp-graceful-shutdown-requirements-00.txt "/>
</reference>



</references>

</back>
</rfc>