Robert,
[Changing the title of the thread to better reflect the subject]
From: Robert Raszuk [mailto:[email protected]]>Sent: Thursday, May 10, 2012
11:25 AM
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 ;(
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.
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.
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
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.
_________________________________________________________________________________________________________________________
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.
