Re: bgp update destroying transit on redback routers ?
Aha, it looks that our Quebecer friends from Hostlogistic (AS46609) have again been advertising their now famous funny aggregate with their mad Brocade router, since yesterday 10pm UTC (that is 5pm in Quebec)... Same route to 206.125.164.0/22, same AGGREGATOR attribute full of 0. At least I can say that the patched Ericsson's bgpd stopped reseting the sessions. regards, Olivier Le 2 déc. 2011 à 23:14, Jeff Tantsura a écrit : Hi Alexandre, You are right, the behavior is exactly as per RFC4271 section 6: When any of the conditions described here are detected, a NOTIFICATION message, with the indicated Error Code, Error Subcode, and Data fields, is sent, and the BGP connection is closed. So because ASN 0 in AGGREGATOR is seen as a malformed UPDATE we send 3/9 and close the connection. Ideally it should be treated as treat-as-withdraw as per draft-chen-ebgp-error-handling, however please note - this is still a draft, not a normative document and with all my support it takes time to implement. Once again, we understand the implications for our customers and hence going to disable ASN 0 check. P.S. We have strong evidence that the update in question was caused by a bug on a freshly updated router (I'm not going to disclose the vendor) Regards, Jeff -Original Message- From: Alexandre Snarskii [mailto:s...@snar.spb.ru] Sent: Friday, December 02, 2011 6:36 AM To: Jeff Tantsura Cc: nanog@nanog.org Subject: Re: bgp update destroying transit on redback routers ? On Thu, Dec 01, 2011 at 04:56:43PM -0500, Jeff Tantsura wrote: Hi, Let me take it over from now on, I'm the IP Routing/MPLS Product Manager at Ericsson responsible for all routing protocols. There's nothing wrong in checking ASN in AGGREGATOR, we don't really want see ASN 0 anywhere, that's how draft-wkumari-idr-as0 (draft-ietf-idr-as0-00) came into the worlds. This draft says that If a BGP speaker receives a route which has an AS number of zero in the AS_PATH (or AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW. This same behavior applies to routes containing zero as the Aggregator or AS4 Aggregator. but observed behaviour was more like following: If a BGP speaker receives [bad route] it MUST close session immediately with NOTIFICATION Error Code 'Update Message Error' and subcode 'Error with optional attribute'.
RE: bgp update destroying transit on redback routers ?
Olivier, Thanks! We've done our best to provide the fix ASAP. Regards, Jeff -Original Message- From: Olivier Benghozi [mailto:olivier.bengh...@wifirst.fr] Sent: Thursday, December 22, 2011 5:20 AM To: nanog@nanog.org Cc: Alexandre Snarskii; Jeff Tantsura Subject: Re: bgp update destroying transit on redback routers ? Aha, it looks that our Quebecer friends from Hostlogistic (AS46609) have again been advertising their now famous funny aggregate with their mad Brocade router, since yesterday 10pm UTC (that is 5pm in Quebec)... Same route to 206.125.164.0/22, same AGGREGATOR attribute full of 0. At least I can say that the patched Ericsson's bgpd stopped reseting the sessions. regards, Olivier Le 2 déc. 2011 à 23:14, Jeff Tantsura a écrit : Hi Alexandre, You are right, the behavior is exactly as per RFC4271 section 6: When any of the conditions described here are detected, a NOTIFICATION message, with the indicated Error Code, Error Subcode, and Data fields, is sent, and the BGP connection is closed. So because ASN 0 in AGGREGATOR is seen as a malformed UPDATE we send 3/9 and close the connection. Ideally it should be treated as treat-as-withdraw as per draft-chen-ebgp-error-handling, however please note - this is still a draft, not a normative document and with all my support it takes time to implement. Once again, we understand the implications for our customers and hence going to disable ASN 0 check. P.S. We have strong evidence that the update in question was caused by a bug on a freshly updated router (I'm not going to disclose the vendor) Regards, Jeff -Original Message- From: Alexandre Snarskii [mailto:s...@snar.spb.ru] Sent: Friday, December 02, 2011 6:36 AM To: Jeff Tantsura Cc: nanog@nanog.org Subject: Re: bgp update destroying transit on redback routers ? On Thu, Dec 01, 2011 at 04:56:43PM -0500, Jeff Tantsura wrote: Hi, Let me take it over from now on, I'm the IP Routing/MPLS Product Manager at Ericsson responsible for all routing protocols. There's nothing wrong in checking ASN in AGGREGATOR, we don't really want see ASN 0 anywhere, that's how draft-wkumari-idr-as0 (draft-ietf-idr-as0-00) came into the worlds. This draft says that If a BGP speaker receives a route which has an AS number of zero in the AS_PATH (or AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW. This same behavior applies to routes containing zero as the Aggregator or AS4 Aggregator. but observed behaviour was more like following: If a BGP speaker receives [bad route] it MUST close session immediately with NOTIFICATION Error Code 'Update Message Error' and subcode 'Error with optional attribute'.
RE: draft-ietf-idr-as0-00 (bgp update destroying transit on redback routers ?)
Hi Daniel, I do understand the use of it however have my doubts about usability as such, I'd really like to see anyone using it for the reason below. All of updates with ASN 0 I have seen in the past few years were there due to software bugs, not explicit configuration - same as this one. Warren/ idr - I do support addition of AGGREGATOR in the draft Regards, Jeff P.S. Jeffrey/John - this draft makes use of no-aggregator-id de facto illigal, are you (your customers) OK with it? Thanks! -Original Message- From: Daniel Ginsburg [mailto:d...@net-geek.org] Sent: Friday, December 02, 2011 5:13 AM To: Jeff Tantsura; Warren Kumari Cc: nanog@nanog.org; i...@ietf.org Subject: draft-ietf-idr-as0-00 (bgp update destroying transit on redback routers ?) Hi, This is true that no-aggregator-id knob zeroes out the AGGREGATOR attribute. The knob, as far as I was able to find out, dates back to gated and there's a reason why it was introduced - it helps to avoid unnecessary updates. Assume that an aggregate route is generated by two (or more) speakers in the network. These two aggregates differ only in AGGREGATOR attribute. One of the aggregates is preferred within the network (due to IGP metric, for instance, or any other reasons) and is announced out. Now if something changes within the network and the other instance of the aggregate becomes preferred, the network has to issue an outward update different from the previous only in AGGREGATOR attribute, which is completely superfluous. If the network employs the no-aggregator-id knob to zero out the AGGREGATOR attribute, both instances of the aggregate route are completely equivalent, and no redundant outward updates have to be send if one instance becomes better than another due to some internal event, which nobody in the Internet cares about. In other words, the no-aggregator-id knob has valid operational reasons to be used. And, IMHO, the draft-ietf-idr-as0-00 should not prohibit AS0 in AGGREGATOR attribute. On 02.12.2011, at 1:56, Jeff Tantsura wrote: Hi, Let me take it over from now on, I'm the IP Routing/MPLS Product Manager at Ericsson responsible for all routing protocols. There's nothing wrong in checking ASN in AGGREGATOR, we don't really want see ASN 0 anywhere, that's how draft-wkumari-idr-as0 (draft-ietf-idr-as0-00) came into the worlds. To my knowledge - the only vendor which allows changing ASN in AGGREGATOR is Juniper, see no-aggregator-id, in the past I've tried to talk to Yakov about it, without any results though. So for those who have it configured - please rethink whether you really need it. As for SEOS - understanding that this badly affects our customers and not having draft-ietf-idr-error-handling fully implemented yet, we will temporarily disable this check in our code. Patch will be made available. Please contact me for any further clarifications. Regards, Jeff P.S. Warren has recently included AGGREGATOR in the draft, please see 2. Behavior This document specifies that a BGP speaker MUST NOT originate or propagate a route with an AS number of zero. If a BGP speaker receives a route which has an AS number of zero in the AS_PATH (or AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW. This same behavior applies to routes containing zero as the Aggregator or AS4 Aggregator.
Re: [Idr] draft-ietf-idr-as0-00 (bgp update destroying transit on redback routers ?)
Can anyone familiar with this knob and its usage, answer a question: Would anything break, in terms of use of that knob, if instead of zeroing the AGGREGATOR, the local AS (as seen from the outside world, in the case of confederations) were used? Would the functionality of the knob, in reducing updates, be preserved? Would routes be considered malformed or would it trigger any other bad behavior? Perhaps this is a way of resolving the conflict between this knob and the AS0 draft? Brian On Fri, Dec 2, 2011 at 8:12 AM, Daniel Ginsburg d...@net-geek.org wrote: Hi, This is true that no-aggregator-id knob zeroes out the AGGREGATOR attribute. The knob, as far as I was able to find out, dates back to gated and there's a reason why it was introduced - it helps to avoid unnecessary updates. Assume that an aggregate route is generated by two (or more) speakers in the network. These two aggregates differ only in AGGREGATOR attribute. One of the aggregates is preferred within the network (due to IGP metric, for instance, or any other reasons) and is announced out. Now if something changes within the network and the other instance of the aggregate becomes preferred, the network has to issue an outward update different from the previous only in AGGREGATOR attribute, which is completely superfluous. If the network employs the no-aggregator-id knob to zero out the AGGREGATOR attribute, both instances of the aggregate route are completely equivalent, and no redundant outward updates have to be send if one instance becomes better than another due to some internal event, which nobody in the Internet cares about. In other words, the no-aggregator-id knob has valid operational reasons to be used. And, IMHO, the draft-ietf-idr-as0-00 should not prohibit AS0 in AGGREGATOR attribute. On 02.12.2011, at 1:56, Jeff Tantsura wrote: Hi, Let me take it over from now on, I'm the IP Routing/MPLS Product Manager at Ericsson responsible for all routing protocols. There's nothing wrong in checking ASN in AGGREGATOR, we don't really want see ASN 0 anywhere, that's how draft-wkumari-idr-as0 (draft-ietf-idr-as0-00) came into the worlds. To my knowledge - the only vendor which allows changing ASN in AGGREGATOR is Juniper, see no-aggregator-id, in the past I've tried to talk to Yakov about it, without any results though. So for those who have it configured - please rethink whether you really need it. As for SEOS - understanding that this badly affects our customers and not having draft-ietf-idr-error-handling fully implemented yet, we will temporarily disable this check in our code. Patch will be made available. Please contact me for any further clarifications. Regards, Jeff P.S. Warren has recently included AGGREGATOR in the draft, please see 2. Behavior This document specifies that a BGP speaker MUST NOT originate or propagate a route with an AS number of zero. If a BGP speaker receives a route which has an AS number of zero in the AS_PATH (or AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW. This same behavior applies to routes containing zero as the Aggregator or AS4 Aggregator. ___ Idr mailing list i...@ietf.org https://www.ietf.org/mailman/listinfo/idr
draft-ietf-idr-as0-00 (bgp update destroying transit on redback routers ?)
Hi, This is true that no-aggregator-id knob zeroes out the AGGREGATOR attribute. The knob, as far as I was able to find out, dates back to gated and there's a reason why it was introduced - it helps to avoid unnecessary updates. Assume that an aggregate route is generated by two (or more) speakers in the network. These two aggregates differ only in AGGREGATOR attribute. One of the aggregates is preferred within the network (due to IGP metric, for instance, or any other reasons) and is announced out. Now if something changes within the network and the other instance of the aggregate becomes preferred, the network has to issue an outward update different from the previous only in AGGREGATOR attribute, which is completely superfluous. If the network employs the no-aggregator-id knob to zero out the AGGREGATOR attribute, both instances of the aggregate route are completely equivalent, and no redundant outward updates have to be send if one instance becomes better than another due to some internal event, which nobody in the Internet cares about. In other words, the no-aggregator-id knob has valid operational reasons to be used. And, IMHO, the draft-ietf-idr-as0-00 should not prohibit AS0 in AGGREGATOR attribute. On 02.12.2011, at 1:56, Jeff Tantsura wrote: Hi, Let me take it over from now on, I'm the IP Routing/MPLS Product Manager at Ericsson responsible for all routing protocols. There's nothing wrong in checking ASN in AGGREGATOR, we don't really want see ASN 0 anywhere, that's how draft-wkumari-idr-as0 (draft-ietf-idr-as0-00) came into the worlds. To my knowledge - the only vendor which allows changing ASN in AGGREGATOR is Juniper, see no-aggregator-id, in the past I've tried to talk to Yakov about it, without any results though. So for those who have it configured - please rethink whether you really need it. As for SEOS - understanding that this badly affects our customers and not having draft-ietf-idr-error-handling fully implemented yet, we will temporarily disable this check in our code. Patch will be made available. Please contact me for any further clarifications. Regards, Jeff P.S. Warren has recently included AGGREGATOR in the draft, please see 2. Behavior This document specifies that a BGP speaker MUST NOT originate or propagate a route with an AS number of zero. If a BGP speaker receives a route which has an AS number of zero in the AS_PATH (or AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW. This same behavior applies to routes containing zero as the Aggregator or AS4 Aggregator.
Re: bgp update destroying transit on redback routers ?
http://tools.ietf.org/html/draft-wkumari-idr-as0-01 one of the reasons the above was written... That does not include when ASN=0 is used in the aggregator attribute. Could you add that? next rev
Re: bgp update destroying transit on redback routers ?
On Thu, Dec 01, 2011 at 04:56:43PM -0500, Jeff Tantsura wrote: Hi, Let me take it over from now on, I'm the IP Routing/MPLS Product Manager at Ericsson responsible for all routing protocols. There's nothing wrong in checking ASN in AGGREGATOR, we don't really want see ASN 0 anywhere, that's how draft-wkumari-idr-as0 (draft-ietf-idr-as0-00) came into the worlds. This draft says that If a BGP speaker receives a route which has an AS number of zero in the AS_PATH (or AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW. This same behavior applies to routes containing zero as the Aggregator or AS4 Aggregator. but observed behaviour was more like following: If a BGP speaker receives [bad route] it MUST close session immediately with NOTIFICATION Error Code 'Update Message Error' and subcode 'Error with optional attribute'. -- In theory, there is no difference between theory and practice. But, in practice, there is.
Re: bgp update destroying transit on redback routers ?
On Fri, Dec 2, 2011 at 9:35 AM, Alexandre Snarskii s...@snar.spb.ru wrote: This draft says that ...note it's a DRAFT, not a STANDARD... If a BGP speaker receives a route which has an AS number of zero in the AS_PATH (or AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW. This same behavior applies to routes containing zero as the Aggregator or AS4 Aggregator. but observed behaviour was more like following: If a BGP speaker receives [bad route] it MUST close session immediately with NOTIFICATION Error Code 'Update Message Error' and subcode 'Error with optional attribute'. hence this old behavor
RE: bgp update destroying transit on redback routers ?
Hi Alexandre, You are right, the behavior is exactly as per RFC4271 section 6: When any of the conditions described here are detected, a NOTIFICATION message, with the indicated Error Code, Error Subcode, and Data fields, is sent, and the BGP connection is closed. So because ASN 0 in AGGREGATOR is seen as a malformed UPDATE we send 3/9 and close the connection. Ideally it should be treated as treat-as-withdraw as per draft-chen-ebgp-error-handling, however please note - this is still a draft, not a normative document and with all my support it takes time to implement. Once again, we understand the implications for our customers and hence going to disable ASN 0 check. P.S. We have strong evidence that the update in question was caused by a bug on a freshly updated router (I'm not going to disclose the vendor) Regards, Jeff -Original Message- From: Alexandre Snarskii [mailto:s...@snar.spb.ru] Sent: Friday, December 02, 2011 6:36 AM To: Jeff Tantsura Cc: nanog@nanog.org Subject: Re: bgp update destroying transit on redback routers ? On Thu, Dec 01, 2011 at 04:56:43PM -0500, Jeff Tantsura wrote: Hi, Let me take it over from now on, I'm the IP Routing/MPLS Product Manager at Ericsson responsible for all routing protocols. There's nothing wrong in checking ASN in AGGREGATOR, we don't really want see ASN 0 anywhere, that's how draft-wkumari-idr-as0 (draft-ietf-idr-as0-00) came into the worlds. This draft says that If a BGP speaker receives a route which has an AS number of zero in the AS_PATH (or AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW. This same behavior applies to routes containing zero as the Aggregator or AS4 Aggregator. but observed behaviour was more like following: If a BGP speaker receives [bad route] it MUST close session immediately with NOTIFICATION Error Code 'Update Message Error' and subcode 'Error with optional attribute'. -- In theory, there is no difference between theory and practice. But, in practice, there is.
bgp update destroying transit on redback routers ?
Hi there, Since about 15:00u GMT we receive bgp updates from our transit which destroys the bgp sessions with them with message: send NOTIFICATION: 3/9 (update: optional attribute error) with 11 byte data. mxReadMs=610 We use redback smartedge routers (SE100) currently for BGP. Anyone who have seen this also? regards, Igor
Re: bgp update destroying transit on redback routers ?
On Thu, Dec 01, 2011 at 05:07:15PM +0100, Igor Ybema wrote: Hi there, Since about 15:00u GMT we receive bgp updates from our transit which destroys the bgp sessions with them with message: send NOTIFICATION: 3/9 (update: optional attribute error) with 11 byte data. mxReadMs=610 We use redback smartedge routers (SE100) currently for BGP. Anyone who have seen this also? Have a complaint from our customer too. On our side (juniper) this is logged as: NOTIFICATION received from peer-ip (External AS peer-as): code 3 (Update Message Error) subcode 9 (error with optional attribute), Data: c0 07 08 00 00 00 As far as I can decode this attribute this is: c0: optional, transitive, no partial, no extended-length 07: AGGREGATOR 08: attribute length is 8 bytes. I think attribute length may be a problem here, because per RFC AGGREGATOR is an optional transitive attribute of length 6. -- In theory, there is no difference between theory and practice. But, in practice, there is.
Re: bgp update destroying transit on redback routers ?
AGGREGATOR is an optional transitive attribute of length 6. -- In theory, there is no difference between theory and practice. But, in practice, there is. Typical, because: AGGREGATOR is an optional transitive attribute of length 6. The attribute contains the last AS number that formed the aggregate route (encoded as 2 octets), followed by the IP address of the BGP speaker that formed the aggregate route (encoded as 4 octets). Usage of this attribute is described in 5.1.7 And what to do with 4-byte AS-numbers then? That would explain the 8 bytes. regards, Igor
Re: bgp update destroying transit on redback routers ?
And what to do with 4-byte AS-numbers then? That would explain the 8 bytes. Looking futher: Two new attributes, AS4_PATH and AS4_AGGREGATOR, are introduced that can be used to propagate four-octet based AS path information cross BGP speakers that do not support the four-octet AS numbers. However this router is AS4 capable, but probably fails to understand a 4-byte AS in the normal AGGREGATOR attribute. If I understand correctly a AS4 capable router should understand when announcing that to it's peer. I'm I correct? Should I file this as a bug? (redback/ericsson is already looking also) regards, Igor
Re: bgp update destroying transit on redback routers ?
Alexandre Snarskii s...@snar.spb.ru wrote: AGGREGATOR is an optional transitive attribute of length 6. The attribute contains the last AS number that formed the aggregate route (encoded as 2 octets), followed by the IP address of the BGP speaker that formed the aggregate route (encoded as 4 octets). Usage of this attribute is described in 5.1.7 And what to do with 4-byte AS-numbers then? That would explain the 8 bytes. Hi, we also have some issues with this here, the update message the Redback logged is: 0049 02 002e 4001 01 00 4002 12 02 04 0513 0d1c b611 b611 4003 04 50ef82c1 4006 00 c007 08 00 00 16 ce7d a4 The prefix is 206.125.164.0/22, AS-PATH is 1299 3356 46609 46609 (Telia, Level3, and finally Hostlogistic with one prepend). The AGGREGATOR is full of 0. I guess this could be what bothers the Redback/Ericsson code. I see the same route by other sessions, and the aggregator looks OK, since the sh bgp says: 206.125.164.0/22 [...] 8218 4436 46609 46609 [...] Origin incomplete, localpref 100, med 100, weight 100, external, best aggregator: 206.125.165.242, AS 46609, atomic-aggregate So Hostlogistic route to Level3 is malformed (according to the RFC, the AGGREGATOR content is mandatory if the attribute is present), but their route to NLayer is OK. Or maybe a Level3 router has a problem? Anyway, our Redback/Ericsson routers are the problem now, since the other vendors don't throw away the BGP sessions... I've opened a case at Ericsson, still waiting for an answer :-/ regards, Olivier Benghozi Wifirst
Re: bgp update destroying transit on redback routers ?
So Hostlogistic route to Level3 is malformed (according to the RFC, the AGGREGATOR content is mandatory if the attribute is present), but their route to NLayer is OK. Or maybe a Level3 router has a problem? Anyway, our Redback/Ericsson routers are the problem now, since the other vendors don't throw away the BGP sessions... I've opened a case at Ericsson, still waiting for an answer :-/ Correct. This was pointed out to me just now off-list by another reader. Ericsson coder also contacted me and noted that is fixed a few months ago, but he is not sure which release has the fix. I hope he will respond on-list about this for everyone to read. regards, Igor
Re: bgp update destroying transit on redback routers ?
Hi all, A new update. A coder from ericsson told me that the problem is not 4-byte asn related. It is related to aggregator-asn=0 and aggregator-ip=0.0.0.0. Ericsson does not accept this as valid ASN and IP-address. The question is now, are all other vendors wrong in accepting this attribute (clearly ASN=0 and IP=0.0.0.0 isn't corresponding to the RFC stating 'which shall contain its own AS number and IP address') or is Ericsson being to strict? regards, Igor
Re: bgp update destroying transit on redback routers ?
On Thu, Dec 1, 2011 at 3:15 PM, Igor Ybema i...@ergens.org wrote: Hi all, A new update. A coder from ericsson told me that the problem is not 4-byte asn related. It is related to aggregator-asn=0 and aggregator-ip=0.0.0.0. Ericsson does not accept this as valid ASN and IP-address. The question is now, are all other vendors wrong in accepting this attribute (clearly ASN=0 and IP=0.0.0.0 isn't corresponding to the RFC stating 'which shall contain its own AS number and IP address') or is Ericsson being to strict? http://tools.ietf.org/html/draft-wkumari-idr-as0-01 one of the reasons the above was written... regards, Igor
Re: bgp update destroying transit on redback routers ?
http://tools.ietf.org/html/draft-wkumari-idr-as0-01 one of the reasons the above was written... That does not include when ASN=0 is used in the aggregator attribute. Could you add that? regards, Igor
Re: bgp update destroying transit on redback routers ?
On Thu, Dec 1, 2011 at 3:23 PM, Igor Ybema i...@ergens.org wrote: http://tools.ietf.org/html/draft-wkumari-idr-as0-01 one of the reasons the above was written... That does not include when ASN=0 is used in the aggregator attribute. Could you add that? that's a warren question...
RE: bgp update destroying transit on redback routers ?
Hi, Let me take it over from now on, I'm the IP Routing/MPLS Product Manager at Ericsson responsible for all routing protocols. There's nothing wrong in checking ASN in AGGREGATOR, we don't really want see ASN 0 anywhere, that's how draft-wkumari-idr-as0 (draft-ietf-idr-as0-00) came into the worlds. To my knowledge - the only vendor which allows changing ASN in AGGREGATOR is Juniper, see no-aggregator-id, in the past I've tried to talk to Yakov about it, without any results though. So for those who have it configured - please rethink whether you really need it. As for SEOS - understanding that this badly affects our customers and not having draft-ietf-idr-error-handling fully implemented yet, we will temporarily disable this check in our code. Patch will be made available. Please contact me for any further clarifications. Regards, Jeff P.S. Warren has recently included AGGREGATOR in the draft, please see 2. Behavior This document specifies that a BGP speaker MUST NOT originate or propagate a route with an AS number of zero. If a BGP speaker receives a route which has an AS number of zero in the AS_PATH (or AS4_PATH) attribute, it SHOULD be logged and treated as a WITHDRAW. This same behavior applies to routes containing zero as the Aggregator or AS4 Aggregator.
Re: bgp update destroying transit on redback routers ?
On Dec 1, 2011, at 3:36 PM, Christopher Morrow wrote: On Thu, Dec 1, 2011 at 3:23 PM, Igor Ybema i...@ergens.org wrote: http://tools.ietf.org/html/draft-wkumari-idr-as0-01 one of the reasons the above was written... That does not include when ASN=0 is used in the aggregator attribute. Could you add that? that's a warren question... http://tools.ietf.org/html/draft-wkumari-idr-as0-01 has been replaced with http://tools.ietf.org/html/draft-ietf-idr-as0-00 -- which does include it. Thanks all, W
RE: bgp update destroying transit on redback routers ?
Thanks Warren! I have already brought this to the list. Regards, Jeff -Original Message- From: Warren Kumari [mailto:war...@kumari.net] Sent: Thursday, December 01, 2011 3:05 PM To: Christopher Morrow Cc: nanog@nanog.org Subject: Re: bgp update destroying transit on redback routers ? On Dec 1, 2011, at 3:36 PM, Christopher Morrow wrote: On Thu, Dec 1, 2011 at 3:23 PM, Igor Ybema i...@ergens.org wrote: http://tools.ietf.org/html/draft-wkumari-idr-as0-01 one of the reasons the above was written... That does not include when ASN=0 is used in the aggregator attribute. Could you add that? that's a warren question... http://tools.ietf.org/html/draft-wkumari-idr-as0-01 has been replaced with http://tools.ietf.org/html/draft-ietf-idr-as0-00 -- which does include it. Thanks all, W
Re: bgp update destroying transit on redback routers ?
On 1 Dec 2011, at 23:04, Warren Kumari wrote: tp://tools.ietf.org/html/draft-wkumari-idr-as0-01 has been replaced with http://tools.ietf.org/html/draft-ietf-idr-as0-00 -- which does include it. Whilst we are on the subject of relevant drafts - it should be noted that situations like this provide significant motivation for the work presented in both [0] and [1] (full disclosure: I am the editor of [0]). I'd really encourage the community to review both documents and comment on whether they provide benefit in this problem space. I'm very happy to take feedback on the requirements draft [0] particularly - since this aimed to describe this problem from an operator perspective. Essentially, until something is done in a more general sense in the protocol, we will continue to see threads liked this one popping up every few months. I'll post a further update to the nanog list when we have requested a working group last-call on the requirements draft asking for reviews. Thanks for your time, r. [0]: http://tools.ietf.org/html/draft-ietf-grow-ops-reqs-for-bgp-error-handling-02 [1]: http://tools.ietf.org/html/draft-ietf-idr-error-handling-00
