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.
Robert,
From: Robert Raszuk Sent: Wednesday, May 09, 2012 11:00 PM
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.
What you propose (using LOCAL_PREF) is what the g-shut draft also propose.
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.
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
used both on iBGP and eBGP side.
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
Regards,
R.
On Wed, May 09, 2012 at 03:32:52PM -0500, Tony Li wrote:
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
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
_________________________________________________________________________________________________________________________
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.
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
