Subject: Re: [GROW] Repeated Errors in BGP - draft-ietf-grow-ops-reqs-for-bgp-error-handling

From: Jeffrey Haas <[email-masked]>
Date: Mon, 7 May 2012 13:57:57 -0400

On Fri, Apr 13, 2012 at 07:27:36PM +0100, Rob Shakir wrote:
> I'd like to ask the WG their collective opinion on a couple of matters in this draft, which come from some discussions at IETF83 (in particular with John Scudder and Adam Simpson) about how the requirements are currently written regarding repeated errors.

In reviewing this thread, there's another possible tool we could leverage.
The consensus seems to be trending toward "if the session is bad enough,
take it down.  Potentially hold it down if it continues to be bad."

An alternative before you get to such a stage is to perform BGP graceful
shutdown procedures on the session's routes.  This permits the routes to be
routes of last resort until the issue is dealt with.

-- Jeff

---

From: Jakob Heitz <[email-masked]>
Date: Tue, 8 May 2012 21:08:11 -0400

On Monday, May 07, 2012 10:58 AM, Jeffrey Haas <> wrote:

>> I'd like to ask the WG their collective opinion on a couple of
>> matters in this draft, which come from some discussions at IETF83
>> (in particular with John Scudder and Adam Simpson) about how the
>> requirements are currently written regarding repeated errors.   
> 
> In reviewing this thread, there's another possible tool we could
> leverage. The consensus seems to be trending toward "if the session
> is bad enough, take it down.  Potentially hold it down if it
> continues to be bad." 
> 
> An alternative before you get to such a stage is to perform BGP
> graceful shutdown procedures on the session's routes.  This permits
> the routes to be routes of last resort until the issue is dealt with.

That raises the possibility that the routes are actually used.
That may cause loops.

-- 
Jakob Heitz.

---

From: <[email-masked]>
Date: Wed, 9 May 2012 07:36:53 +0000

From: grow Jakob Heitz Sent: Wednesday, May 09, 2012 3:08 AM
>That raises the possibility that the routes are actually used.

Would you mind sharing an example of such loops following an eBGP session failure?
That would help me. (Hopefully some others).

Thanks,
Bruno

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 9 May 2012 04:09:53 -0400

A has a route learnt from C.
A configures a long AS path prepend, but because of a bug activated by
a too long AS path, it sends no AS path. B receives it,
but does not withdraw the route. It announces the route to C.
C had a better route before, but due to policy did not
announce it to B. C starts sending traffic to B.
B send to A. A sends to C. loop.

Here is the way:
If you can isolate an error to a set of routes withdraw them.
If not, drop the session and withdraw all routes from it.
RFD takes care of flapping sessions.

On Wednesday, May 09, 2012 12:37 AM, [email-masked] <mailto:[email-masked]> wrote:

> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc 
> pas etre diffuses, exploites ou copies sans autorisation. Si vous
> avez recu ce message par erreur, veuillez le signaler 
> a l'expediteur et le detruire ainsi que les pieces jointes. Les
> messages electroniques etant susceptibles d'alteration, France
> Telecom - Orange decline toute responsabilite si ce message a ete
> altere, deforme ou falsifie. Merci.  
> 
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; 
> If you have received this email in error, please notify the sender
> and delete this message and its attachments. 
> As emails may be altered, France Telecom - Orange is not liable for
> messages that have been modified, changed or falsified. Thank you.

-- 
Jakob Heitz.

---

From: <[email-masked]>
Date: Wed, 9 May 2012 10:11:34 +0000

Jakob,

Thanks for your example.

For sure, if a router (partially) erase the AS PATH, we can have loops. So far, I don't see how this is related to BGP error handling, not to mention to Jeff proposition.

In more details, is B configured to enforce first AS? 
 - if so, it should detect the error and react. As per draft-ietf-idr-error-handling I guess it should treat as withdraw. I don't see the issue. Or are you considering a case of two different bugs in two consecutive routers (A & B)?
 - if not, well, the loop is the current BGP behavior. Not specific to BGP error handling as no router see an error.

Or eventually, we have a different reading of Jeff proposal. I understood that the proposition is to use as last resort the routes received _before_ the BGP error (i.e. valid routes received through a valid BGP UPDATE but which would be implicitly withdrawn with the BGP notification). Not route from the invalid BGP UPDATE.

Regards,
Bruno

>From: Jakob Heitz [mailto:[email-masked]] Sent: Wednesday, May 09, 2012 10:10 AM
>
>On Wednesday, May 09, 2012 12:37 AM, [email-masked]
><mailto:[email-masked]> wrote:
>
>_______________________________________________________________________________
>__________________________________________
>>

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 9 May 2012 06:42:07 -0400

The loop occurs because of an error in the update message:
The AS path was missing. The receiving router "handled"
the error and propagated it.

I just gave you an example of how slippery the error
handling slope can be.

Please don't lose perspective.

Error handling should be simple.

I don't want to trust anything from a buggy router.
However, it has been shown that dropping everything from
a router because of a small bug is too severe.

Therefore, I'm prepared to accept the additional rule:
If an error can be isolated to a set of prefixes,
withdraw only the prefixes, and send an operational message.

Nothing more.

On Wednesday, May 09, 2012 3:12 AM, [email-masked] <mailto:[email-masked]> wrote:

> Jakob,
> 
> Thanks for your example.
> 
> For sure, if a router (partially) erase the AS PATH, we can have
> loops. So far, I don't see how this is related to BGP error handling,
> not to mention to Jeff proposition.  
> 
>  - if so, it should detect the error and react. As per
> draft-ietf-idr-error-handling I guess it should treat as withdraw. I
> don't see the issue. Or are you considering a case of two different
> bugs in two consecutive routers (A & B)?   
>  - if not, well, the loop is the current BGP behavior. Not specific
> to BGP error handling as no router see an error. 
> 
> 
> Or eventually, we have a different reading of Jeff proposal. I
> understood that the proposition is to use as last resort the routes
> received _before_ the BGP error (i.e. valid routes received through a
> valid BGP UPDATE but which would be implicitly withdrawn with the BGP
> notification). Not route from the invalid BGP UPDATE.    
> 
> Regards,
> Bruno
> 
>>>>> leverage. The consensus seems to be trending toward "if the
>>>>> session is bad enough, take it down.  Potentially hold it down if
>>>>> it continues to be bad." 
>>>>> 
>>>>> graceful shutdown procedures on the session's routes.  This
>>>>> permits the routes to be routes of last resort until the issue is
>>>>> dealt with.
>>>> 
>>> Would you mind sharing an example of such loops following an eBGP
>>> session failure? That would help me. (Hopefully some others).
>>> 
>>> Thanks,
>>> Bruno
>>> 
>>> 
>>> 
>>> they should not be distributed, used or copied without
>>> authorisation. If you have received this email in error, please
>>> notify the sender and delete this message and its attachments.

---

From: <[email-masked]>
Date: Wed, 9 May 2012 12:31:55 +0000

>From: Jakob Heitz [mailto:[email-masked]] Sent: Wednesday, May 09, 2012 12:42 PM
>
>The AS path was missing. 

Well your original text was not that specific. I understood that the AS PATH attribute was present but its length was 0. So no error in the UPDATE received.

>The receiving router "handled"

I've heard that argument a few times in the discussion draft-ietf-idr-error-handling vs RFC 4271 (current error handling). IMHO it is not a valid one:

A) Note that what you want is not even the current RFC 4271 behavior which do accept and do try to correct some error from a buggy router. Including for well know attributes:

e.g. RFC 4271 §5.1.5 LOCAL_PREF
"A BGP speaker MUST NOT include this attribute in UPDATE messages it
   sends to external peers, except in the case of BGP Confederations
   [RFC3065].  If it is contained in an UPDATE message that is received
   from an external peer, then this attribute MUST be ignored by the
   receiving speaker, except in the case of BGP Confederations
   [RFC3065]."

And idem in RFC 1771:
"  A BGP speaker shall not include this attribute in UPDATE messages
   that it sends to BGP speakers located in a neighboring autonomous
   system. If it is contained in an UPDATE message that is received from
   a BGP speaker which is not located in the same autonomous system as
   the receiving speaker, then this attribute shall be ignored by the
   receiving speaker."

B) See also RFC 1122:
      1.2.2  Robustness Principle

         At every layer of the protocols, there is a general rule whose
         application can lead to enormous benefits in robustness and
         interoperability [IP:1]:

                "Be liberal in what you accept, and
                 conservative in what you send"

>withdraw only the prefixes

That would be fine for me. So I don't think we are in real significant disagreement. 

> and send an operational message.

Do you mean that the support of operational message on your BGP peers would be MUST/prerequisite for draft-ietf-idr-error-handling? If so I would disagree. I want to limit the impact of errors regardless of the capabilities of my peers (regardless if my peer is in a different AS or not)

>Nothing more.

That would be ok for me, at least as a first step until we get operational experience on the new error handling.

But to come back to the original point, IMHO Jeff proposal seems valid and you have not succeeded in proving otherwise.

Thanks,
Regards,
Bruno

>On Wednesday, May 09, 2012 3:12 AM, [email-masked]

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 9 May 2012 10:57:17 -0400

> That raises the possibility that the routes are actually used.

I'm not talking about the routes we'd be doing "treat as withdraw", I'm
talking about all of the otherwise "good" routes on the session.

-- Jeff

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 9 May 2012 11:03:50 -0400

> talking about all of the otherwise "good" routes on the session.

Sorry, I misunderstood.

You mean for the case when a router does "treat as withdraw" for
routes in an errored update message, but does not bring down
the session, to deprefer the rest of the routes from that peer.

Right?

-- 
Jakob Heitz.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 9 May 2012 14:21:03 -0400

> the session, to deprefer the rest of the routes from that peer.

Correct.

The topic this thread was covering was "what do we do when we receive a very
large number of faulty updates".  If a session gets a few bad updates, it's
reasonable to expect that a few "bad routes" got into the Internet's table.
If we get a very large number, it may be safer to assume that something is
very broken upstream.

When we've decided the upstream is broken enough, for some threshold of
broken, two reasonable actions are:
- Bring down the peering session.  
- Exercise "graceful shutdown" on that session to permit its routes to be 
  used as a path of last resort.  In this case, we perhaps do not take the
  session down.

The faulty routes are always handled according to the error-handling draft
semantics.

-- Jeff

---

From: Tony Li <[email-masked]>
Date: Wed, 9 May 2012 13:31:21 -0500

> The faulty routes are always handled according to the error-handling draft

Jeff,

One clarification: by "graceful shutdown" are you implying the use of "graceful restart"?

Tony

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 9 May 2012 14:45:36 -0400

Tony,

> One clarification: by "graceful shutdown" are you implying the use of "graceful restart"?

http://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-03

---

From: Tony Li <[email-masked]>
Date: Wed, 9 May 2012 14:12:05 -0500

> http://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-03

Thank you.  This seems to indicate that after a g-shut event, the neighbor would continue to advertise the prefixes to its peers (albeit tagged with the community).  Wouldn't this cause non-updated routers to blackhole traffic?  What happens when only half of you IBGP peers are updated?

If the peering doesn't come back for an extended period, couldn't this cause traffic to transit and then be blackholed, assuming there are no alternate paths?

This is violating BGP's fundamental principle: "Advertise what you're using, use what you advertise."  It seems like black holes are inevitable.

Tony

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 9 May 2012 16:29:03 -0400

Tony,

> This is violating BGP's fundamental principle: "Advertise what you're using, use what you advertise."  It seems like black holes are inevitable.

Please see the other clarification I posted.  Graceful shutdown is applied
to the routes from the peer that is sending bad updates that are accepted
and valid.  Routes that contain errors are processed with the stated "treat
as withdraw" behavior.

In other words, the goal is to remove the bad neighbor's valid routes from
the forwarding path as much as possible since that neighbor is presumed to
possibly crazy.

-- Jeff

---

From: Tony Li <[email-masked]>
Date: Wed, 9 May 2012 15:32:52 -0500

Jeff,

Understood.  I have no issues with withdrawn routes.  The issue is with g-shut routes that continue to sink traffic.

Tony

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 9 May 2012 16:51:03 -0400

> Understood.  I have no issues with withdrawn routes.  The issue is with g-shut routes that continue to sink traffic.

Perhaps I'm unclear on your reservations.

If we don't go through something like graceful shutdown and leave the
peering session up, we're potentially going to pull significantly more
traffic toward the "bad" peering session than if we didn't do such a thing.

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 09 May 2012 23:00:24 +0200

Jeff,

I do not understand why we are not going to re-advertise "good" routes 
with lowest local preference which would not result in holes of some 
boxes understanding g-shut community and some not.

In fact I spoke to Bruno in the past on that and I was hoping we all 
converged that g-shut community would be used only on the EBGP side to 
indicate to the peer that it should in turn lower local pref on his 
side. Apparently g-shut draft still calls for this new community to be 
used both on iBGP and eBGP side.

Regards,
R.

> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
>
>

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 9 May 2012 21:49:18 -0400

On Wednesday, May 09, 2012 1:51 PM, Jeffrey Haas <mailto:[email-masked]> wrote:

>> Understood.  I have no issues with withdrawn routes.  The issue is
>> with g-shut routes that continue to sink traffic. 
> 

This is for ebgp only, not ibgp. right?

-- 
Jakob Heitz.

---

From: <[email-masked]>
Date: Thu, 10 May 2012 08:57:08 +0000

Robert, Tony,

Please find below some clarification regarding gshut (draft-ietf-grow-bgp-gshut):
- the g-shut community in itself has no effect on BGP path selection
- when the eBGP session is being g-shut, 
	- on the iBGP side, routes (from the eBGP session beeing gshut) are readvertised with a low LOCAL_PREF (e.g. 0).
	- on the eBGP side, routes (from the eBGP session beeing gshut) are readvertised with the ghsut community. Then (if the neighbor AS is willing to use g-shut), on the AS boundary (eBGP), routes having the g-shut community are set to a lower LOCAL_PREF.

So in both involved ASes, route are de-preferenced because of the lower LOCAL_PREF. (not by iBGP routers interpreting the g-shut community).

Regards,
Bruno

>From: Robert Raszuk >Sent: Wednesday, May 09, 2012 11:00 PM
>
>Jeff,
>
>>> Understood.  I have no issues with withdrawn routes.  The issue is with g-
>shut routes that continue to sink traffic.
>>

---

From: <[email-masked]>
Date: Thu, 10 May 2012 08:57:18 +0000

Robert,

>From: Robert Raszuk Sent: Wednesday, May 09, 2012 11:00 PM
>
>Jeff,
>

What you propose (using LOCAL_PREF) is what the g-shut draft also propose.

>side.

The g-shut community has always been used to signal the ghsut only on the eBGP side. On the iBGP side, LOCAL_PREF has always been used.

> Apparently g-shut draft still calls for this new community to be

On the iBGP side, LOCAL_PREF is used to lower the preference of the g-shut draft.
In _addition_ to this, the g-shut community is attached for _informational_ purpose. Because some AS internal BGP policy may have a need to know that the route is being g-shut. And it's cleaner to use a community to provide the root cause rather than try to guess from the low LOCAL_PREF the root cause.

Regards,
Bruno

---

From: <[email-masked]>
Date: Thu, 10 May 2012 09:17:50 +0000

Jeff, Tony,

>From: Tony Li >Sent: Wednesday, May 09, 2012 10:33 PM
>
>>> Thank you.  This seems to indicate that after a g-shut event, the neighbor
>would continue to advertise the prefixes to its peers (albeit tagged with the
>community).  Wouldn't this cause non-updated routers to blackhole traffic?
>What happens when only half of you IBGP peers are updated?
>>>
>>> If the peering doesn't come back for an extended period, couldn't this cause
>traffic to transit and then be blackholed, assuming there are no alternate
>paths?
>>>
>>> This is violating BGP's fundamental principle: "Advertise what you're using,
>use what you advertise."  It seems like black holes are inevitable.
>>

In iBGP, as per my previous clarification, I don't see an issue within the AS de-preferencing the routes received from the "bad" eBGP peer:
- if there is a backup path, it will be used. Fine.
- otherwise, it may be better to still use the routes learnt from a valid UPDATE.

In eBGP, however, IMO Tony has a point for upstream ASes (next ASes from the BGP propagation point of view). There is no guaranty that they will understand the g-shut community. Hence they will not de-preference the route and may still use the suspicious routes even if they have an alternate path. 
Then it's a question of how much we trust those routes. If we believe they are reasonable, we could still advertise them to upstream AS (this is only for the case where is no a valid backup path as those path have a low local_pref). Otherwise, we could add the NO_EXPORT community to avoid propagating that path to others ASes.

Regards,
Bruno

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 10 May 2012 11:25:17 +0200

Hello Bruno,

Excellent - this is exactly what we discussed in the past. But when I 
read the draft before sending email yesterday unfortunately it does not 
say so that clearly at all - regarding the IBGP case ;(

         iBGP         eBGP
PE1 ---- P ---- PE2 ====== PE3

The scenario I had in mind was we are receiving errored UPDATE msg from 
PE3 to PE2, PE2 treats as withdraw the parsable NLRIs then for the reast 
the thread so far indicated to inject g-shut community.

While injecting G_SHUT would not hurt and would allow for example PE1 to 
propagate it downstream in the same time error handling draft should 
IMHO me explicit to say we are advertising from PE2 towards it's AS with 
lowest LOCAL_PREF and G_SHUT.

Example:

4.2.1.1.  Pre-configuration

    On each ASBR supporting the g-shut procedure, an outbound BGP route
    policy is applied on all iBGP sessions of the ASBR, that:
    o    matches the g-shut community
    o    sets the local-pref of the paths tagged with the g-shut
         community to a low value

Here in out case we do not match on g-shut as g-shut is not received 
from EBGP.

Also perhaps it would be great to just copy and paste the quote from the 
previous email directly to a deployment section of the draft.

Best regards,
R.

---

From: <[email-masked]>
Date: Thu, 10 May 2012 10:03:43 +0000

Robert,

[Changing the title of the thread to better reflect the subject]

>From: Robert Raszuk [mailto:[email-masked]] >Sent: Thursday, May 10, 2012 11:25 AM
>
>Hello Bruno,
>

If the draft is not clear enough, we always welcome comments. Do you have specific comments that we should add in the draft? 

The following section of the draft recaps the actions to be performed. 

"4.2.1.3. BGP implementation support for G-Shut

[...]

   Upon a session shutdown specified as graceful by the operator, a BGP
   implementation supporting a g-shut feature SHOULD:

   1.   Update all the paths propagated over the corresponding eBGP
        session, tagging the GSHUT community to them.  Any subsequent
        update sent to the session being gracefully shut down would be
        tagged with the GSHUT community.
   2.   Lower the local preference value of the paths received over the
        eBGP session being shut down, upon their propagation over iBGP
        sessions.  Optionally, also tag these paths with an AS specific
        g-shut community.  Note that alternatively, the local preference
        of the paths received over the eBGP session can be lowered on
        the g-shut initiator itself, instead of only when propagating
        over its iBGP sessions."

At least to me, seems clear that the community is used on the eBGP side and LOCAL_PREF is used on the iBGP side. Eventually we could to the following change:
- :s/local preference/LOCAL_PREF
- May be start the sentence of 1. and 2. with: "on the eBGP side", "on the iBGP side"

Others comments welcomed.

>previous email directly to a deployment section of the draft.

Sorry the given the amount of emails, could you please be a little more specific? (e.g. which quote).

Thanks for the useful comments.
Best regards,
Bruno

>> The g-shut community has always been used to signal the ghsut only on the
>eBGP side. On the iBGP side, LOCAL_PREF has always been used.
>>
>> In _addition_ to this, the g-shut community is attached for _informational_
>purpose. Because some AS internal BGP policy may have a need to know that the
>route is being g-shut. And it's cleaner to use a community to provide the root
>cause rather than try to guess from the low LOCAL_PREF the root cause.
>>
>> Regards,
>> Bruno
>>
>>
>>>
>>> Regards,
>>> R.
>>>
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu
>ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
>electroniques etant susceptibles d'alteration,
>> This message and its attachments may contain confidential or privileged
>information that may be protected by law;
>> As emails may be altered, France Telecom - Orange is not liable for messages
>that have been modified, changed or falsified.
>> Thank you.
>>
>>
>>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 10 May 2012 14:16:36 +0200

Bruno,

 >      sessions.

Looking at the definition of upon:

"upon" - immediately or very soon after
http://dictionary.reference.com/browse/upon

What is the point of lowering local pref "after" their propagation over 
ibgp session ? To repropagate again ? Shouldn't it s/upon/before/ ?

r.

>> From: Robert Raszuk [mailto:[email-masked]]>Sent: Thursday, May 10, 2012 11:25 AM
>>
>> Hello Bruno,
>>

---

From: <[email-masked]>
Date: Thu, 10 May 2012 13:05:57 +0000

Robert,

>From: Robert Raszuk [mailto:[email-masked]] Sent: Thursday, May 10, 2012 2:17 PM
>
>Bruno,
>

Actually, IMO timing does matter. 

And as per your own dictionary, definition of upon also cover
5) on the occasion of
6) on (in any of various senses, used as an equivalent of on)

Both seems applicable to me, but I'm clearly not going to argue. If I were the editor, I would pick any proposition from a native English speaker. But I'm not.

Alternatively, what about:

2.   On the iBGP side, (re-) advertises the path received over the eBGP session being shutdown with a low LOCAL_PREF.

Bruno

>> If the draft is not clear enough, we always welcome comments. Do you have
>specific comments that we should add in the draft?
>>
>> At least to me, seems clear that the community is used on the eBGP side and
>LOCAL_PREF is used on the iBGP side. Eventually we could to the following
>change:
>>>> If you have received this email in error, please notify the sender and
>delete
>>> this message and its attachments.
>messages

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 10 May 2012 15:22:52 +0200

Bruno,

 > 2.   On the iBGP side, (re-) advertises the path received over
 > the eBGP session being shutdown with a low LOCAL_PREF.

Sounds good.

Btw what is "low" ? Is 0 low ? Is 5 low ? Should we at least recommend 
some value if you are assuming automation in g-shut to local pref 
translation ?

Jakob, Jeff,

 > This is for ebgp only, not ibgp. right?

I was assuming this is mostly for ibgp.

If this is also for ebgp are you suggesting that we will receive from 
the peer a single error in UPDATE message for SAFI X/X and then it will 
trigger full re-advertisement of all of our routes for all of our SAFIs 
over such session to this peer with g-shut ?

The way I read what Jeff proposed is this:

1. We are receiving N errors and just treat-as-withdraw or drop errored 
optional attributes when applicable

2. When N becomes more then X send g-shut to eBGP peer and lower local 
pref towards iBGP then re-advertise

3. After time T shut EBGP session.

Questions: What is value of X and T above ?

Thx,
R.

---

From: <[email-masked]>
Date: Thu, 10 May 2012 14:09:22 +0000

Robert,

>From: Robert Raszuk [mailto:[email-masked]] >Sent: Thursday, May 10, 2012 3:23 PM
>
>Bruno,
>

Great.

>Btw what is "low" ? 

Low enough such as a backup path will be preferred. We can add this in the draft.

> Is 0 low ? Is 5 low ? Should we at least recommend

Local pref value are choosen independantly by each AS. There is no way we can pick a value -except 0 may be- which will work all the time. Even 0 may not be perfect:
- 0 could already be used by others path we should never be choosen even during a ghsut.
- In an Internet network, to optimize the convergence steps and the transient behavior we should/may pick the lower value assigned to the kind of relationship being gshut (e.g. peer). Indeed, if we gshut an eBGP session with a peering policy, BGP may transiently pick any path including a path from a transit provider. This would lead to a transient withdraw to peers due to policy restriction (transit path are not advertised to peer). This is suboptimal. OTOH an ISP may not want to spend time/money to optimize this...

In short: local_pref value are a local policy.

We can clearly discuss this in the draft, but OTOH a least one person had commented that the draft was too long and could fit in 1-2 pages.

Bruno