Robert, [Changing the title of the thread to better reflect the subject]
>From: Robert Raszuk [mailto:rob...@raszuk.net] >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 >>>> GROW@ietf.org >>>> https://www.ietf.org/mailman/listinfo/grow >>>> >>>> >>> >>> _______________________________________________ >>> GROW mailing list >>> GROW@ietf.org >>> 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. _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
