Re: [GROW] draft-ietf-grow-bgp-gshut
Robert, >From: Robert Raszuk [mailto:rob...@raszuk.net] >Sent: Thursday, May 10, 2012 >3:23 PM > >Bruno, > > > 2. On the iBGP side, (re-) advertises the path received over > > the eBGP session being shutdown with a low LOCAL_PREF. > >Sounds good. 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 >some value if you are assuming automation in g-shut to local pref >translation ? 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 >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. > > > > > _ 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
Re: [GROW] draft-ietf-grow-bgp-gshut
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. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] draft-ietf-grow-bgp-gshut
Robert, >From: Robert Raszuk [mailto:rob...@raszuk.net] Sent: Thursday, May 10, 2012 >2:17 PM > >Bruno, > > > 2. Lower the local preference value of the paths received over the > > eBGP session being shut down, upon their propagation over iBGP > > 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/ ? 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 >r. > > > >> 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: >>> omatches the g-shut community >>> osets 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 be
Re: [GROW] draft-ietf-grow-bgp-gshut
Bruno, > 2. Lower the local preference value of the paths received over the > eBGP session being shut down, upon their propagation over iBGP > 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. 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: omatches the g-shut community osets 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 potent
[GROW] draft-ietf-grow-bgp-gshut
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: >omatches the g-shut community >osets 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
Re: [GROW] Repeated Errors in BGP - draft-ietf-grow-ops-reqs-for-bgp-error-handling
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: omatches the g-shut community osets 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 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. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Repeated Errors in BGP - draft-ietf-grow-ops-reqs-for-bgp-error-handling
Jeff, Tony, >From: Tony Li >Sent: Wednesday, May 09, 2012 10:33 PM > >On May 9, 2012, at 3:29 PM, Jeffrey Haas wrote: > >>> 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. >> >> 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, > >Understood. I have no issues with withdrawn routes. The issue is with g-shut >routes that continue to sink traffic. 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 >Tony > >___ >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. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Repeated Errors in BGP - draft-ietf-grow-ops-reqs-for-bgp-error-handling
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. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
Re: [GROW] Repeated Errors in BGP - draft-ietf-grow-ops-reqs-for-bgp-error-handling
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, > >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. > >> 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. ___ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
