Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Hi Rob, Thanks for your reply. More inline. >From: Rob Shakir [mailto:r...@rob.sh] >Sent: Monday, January 28, 2013 7:49 PM > >Hi Bruno, > >Thanks for the review of this version of the draft. I've added some feedback >in-line as [rjs]. My apologies for the delay in responding. > >On 8 Jan 2013, at

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Hi Bruno, Thanks for the review of this version of the draft. I've added some feedback in-line as [rjs]. My apologies for the delay in responding. On 8 Jan 2013, at 10:57, bruno.decra...@orange.com wrote: > 1) Critical error (§3) > > IMHO, the term “critical error” is mixing both technical/p

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On 15/01/2013 02:37, Chandra Appanna wrote: > I for one have not seen a lot of real data from the SPs and > other newer users of BGP in my dealings of many years that reflect the need > for > such solutions in the real world. Chandra, This particular problem tends only to crop up every so often,

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Rather late reply on this topic.. But I happen to agree with Jared. I did start out thinking that the bgp error handling idea was a new twist of a solution that was very interesting but after all this debate and my own introspection, I am actually back in the camp of not believing in the idea of so

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Sat, Jan 5, 2013 at 6:50 AM, John Leslie wrote: >Actually, we could invent a message type which reflects the content > of a "bad" update, but it would only be useful for logging at the > sending peer for human perusal; and, to be useful to that human it > would need to classify the problem

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Hi Jakob, We (the authors) are working on a re-spin of this draft. My aim is to do this within the next week or so. Kind regards, r. On 5 Jan 2013, at 05:50, Jakob Heitz wrote: > On Friday, January 04, 2013 9:30 PM, Jeff Wheeler > wrote: > >> Jakob's "i got this

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Jakob Heitz wrote: > On Friday, January 04, 2013 4:35 PM, John Leslie wrote: > >> Replay of an errant update can't help, and would likely crash its >> receiver. Don't do that! > > Sorry, that's not what I meant. > I meant a future operational message that says > "this upda

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Friday, January 04, 2013 9:30 PM, Jeff Wheeler wrote: > Jakob's "i got this bad message, here it is" feature. Just to set the record straight, it's not my idea and I was referring to the older discussion about this. I'll note that http://tools.ietf.org/html/draf

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Fri, Jan 4, 2013 at 7:34 PM, John Leslie wrote: >Lacking a TLV structure for messages, we should not let go of a > marker which separates messages. Even if you were inventing "BGP 5" and you cleaned up all the messy extensions and implied field lengths, I think you would be persuaded to ke

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Jakob Heitz wrote: > > Current usages of BGP probably will not have anything matching > a marker in the byte stream other than the marker. I can't think of any way for it to get there that isn't an error... > But future additions could well do that. Sounds like a very bad idea to me. >

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Friday, January 04, 2013 4:35 PM, John Leslie wrote: >> What about a notification message or a possible future >> operational message that replays the errant update. > >Definitely a bad idea! > >Replay of an errant update can't help, and would likely crash its >

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Current usages of BGP probably will not have anything matching a marker in the byte stream other than the marker. But future additions could well do that. There is a draft to increase the maximum length, so you can't rely on that being <= 4096. What about a notification message or a possible futur

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Tony Li wrote (on Fri 04-Jan-2013 at 17:02 +): > To: Jeff Wheeler > I agree that the Message Length will either be correct or it won't. > Now, all us need is an oracle (the computer science kind ;-), to > tell us which is which. Got any handy? ;-) The outermost framing for the message i

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Almost no one has commented on whether or not a capability code should be used to re-order the contents of BGP Messages, and Attributes, as suggested by error-handling. This is really important if error-handling is to rely on such re-ordering. Many folks are saying error-handling needs it, the dr

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On , Tony Li <> wrote: > possible mistake. It's easy to have an inconsistency which > is in the tens or hundreds of bytes. Now what? We could > again check both alternatives, but again, the presence of a > Marker, even in one of the possible locations, is no > guarantee. You could easily skip

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Jan 4, 2013, at 9:54 AM, "Smith, Donald" wrote: >> In short, treat-as-withdraw is a fail safe approach. Ignoring updates >> is not. > But in a peering world you have potentially just withdrawn all of your routes > to a peer from that peer. > > You will now prefer some other peer for all o

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

>To: Smith, Donald >Cc: 'Jeff Wheeler'; 'i...@ietf.org'; 'grow@ietf.org' >Subject: Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp- >error-handling-06.txt > > >Hi Donald, > >>> A session reset seems like the only (

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Jeff, >>> To review, you've said that ignoring a BGP message is not even >>> possible. Of course we know that isn't true. >> >> Do we? Given an arbitrary set of errors on a byte stream where there are no >> guaranteed delimiters, how do you propose to resynchronize with absolute >> certain

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Jan 3, 2013, at 9:33 PM, Jeff Wheeler wrote: >> Non-sequitur. Cyclic resets are orthogonal to treat-as-withdraw. As >> enumerated above, ignore-bad-message is harder to implement and is more >> dangerous. > > No, ignore-bad-message is not harder to implement. To say so is simply a lie.

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Saikat, > [SR] Ok. This however does not happen in bgp-free core (ASBR2 will tunnel > the packet to ASBR4 even if AR3 is in the forwarding path). True but http://tools.ietf.org/html/draft-ietf-idr-error-handling-03 does not mandate nor recommend to use "treat-as-withdraw" in IBGP in tun

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On 3 Jan 2013, at 22:05, Jared Mauch wrote: > Oh, I understand all these use-cases, but there is a case for a well-designed > network not always sharing/mixing the NLRI. eg: We don't transport v4 NLRI > in v6 transport, nor v6 NLRI in v4 transport. If you have a single session > with massive

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Fri, Jan 4, 2013 at 1:54 AM, Saikat Ray (sairay) wrote: > [SR] Ok. This however does not happen in bgp-free core (ASBR2 will tunnel > the packet to ASBR4 even if AR3 is in the forwarding path). Yes, absolutely true. On Fri, Jan 4, 2013 at 2:01 AM, Tony Li wrote: > And we should als

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Thu, Jan 03, 2013 at 02:31:16PM -0800, Tony Li: > As I've said before, errors can be reasonably classified into two groups: > syntactic and semantic. > > A syntactic error would be any inconsistency of length fields, > incompatibility between a type and a length, or any other error that would

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Jeff, >>> No, ignore-bad-message is not harder to implement. To say so is simply a >>> lie. >> >> I'm sorry, but this conversation has taken a turn for the worse. I may be >> wrong (I really don't think so), but I am not lying. >> >> You owe me an apology and I'm not going to continue thi

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

> Bugs can be present at other places than an ASBR. Imagine the following very > ordinary network: > > AS100 --- [ ASBR2 --- AR3 --- ASBR4 --- ] AS500 > > ASBR2 will have iBGP routing exchange with ASBR4 by some means. This may be > an ordinary iBGP session, via a route-reflector, or whateve

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Bugs can be present at other places than an ASBR. Imagine the following very ordinary network: AS100 --- [ ASBR2 --- AR3 --- ASBR4 --- ] AS500 ASBR2 will have iBGP routing exchange with ASBR4 by some means. This may be an ordinary iBGP session, via a route-reflector, or whatever. If AR3 is bu

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Thu, Jan 3, 2013 at 9:53 PM, Saikat Ray (sairay) wrote: > [SR] Wrong in what sense? BGP code does not care whether it is a transit or > an ASBR. What I described is exactly what the code will do. > (i) a path for a prefix (a "net") is withdrawn. > (ii) BGP deletes

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Jan 3, 2013, at 6:33 PM, Jeff Wheeler wrote: >> Non-sequitur. Cyclic resets are orthogonal to treat-as-withdraw. As >> enumerated above, ignore-bad-message is harder to implement and is more >> dangerous. > > No, ignore-bad-message is not harder to implement. To say so is simply a lie.

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

-Original Message- From: Jeff Wheeler [mailto:j...@inconcepts.biz] Sent: Thursday, January 03, 2013 6:49 PM To: Saikat Ray (sairay) Cc: i...@ietf.org; grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt On Thu, Jan 3, 2013 at 9:37 PM

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Thu, Jan 3, 2013 at 9:37 PM, Saikat Ray (sairay) wrote: > If a transit router in your AS treats-as-withdraw a prefix, other routers may > try to send traffic across it, but the router which has treated-as-withdraw > will either have no information for that route, or it will have made a > dif

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

-Original Message- From: idr-boun...@ietf.org [mailto:idr-boun...@ietf.org] On Behalf Of Jeff Wheeler Sent: Thursday, January 03, 2013 6:34 PM To: Tony Li Cc: i...@ietf.org; grow@ietf.org Subject: Re: [Idr] [GROW] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt On Thu,

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

> A syntactic error would be any inconsistency of length fields, > incompatibility between a type and a length, or any other error that > would introduce any doubt about the parsing of the message. Once this > type of error has occurred, then the remainder of the data stream is > wholly in doubt.

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Thu, Jan 3, 2013 at 4:28 PM, Jared Mauch wrote: > Also, if you're seeing some problem, I'm sure that some other set of > people out there will be seeing it as well. The shared pain/cost will > exist. If you can't take the risk of speaking BGP, have your ISP send you > default (or nothing) and

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Robert Raszuk wrote (on Thu 03-Jan-2013 at 20:18 +): > To: Jeff Wheeler > > Hi Jeff, > > > Ignore-bad-message is very simple and provides a band-aid for more > > problems, including unforeseen problems. > How are you going to clean the NLRIs in your network (both transit > or stub) which wer

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Thu, Jan 3, 2013 at 3:18 PM, Robert Raszuk wrote: > How are you going to clean the NLRIs in your network (both transit or > stub) which were withdrawn in the messages your BGP implementation > declared "bad" and decided to ignore ? I can fix them later, maybe even after I've had time to fully

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Jared Mauch wrote (on Thu 03-Jan-2013 at 17:40 +): > Not sure who you're asking, but I think this whole draft is an > idealist attempt to workaround software defects that may be > uncorrectable as a whole. (I say this as a $large_operator as > measured here: http://as-rank.caida.org/?mode

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Thu, Jan 3, 2013 at 2:35 PM, Michael Long wrote: > Either upgrade to fixed code or policy out the offending announcement. You actually can't policy out the announcement on the receiving side. This is why I continue to state that you need help from external parties to solve these problems. Ve

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Thu, Jan 3, 2013 at 12:40 PM, Jared Mauch wrote: > Not sure who you're asking, but I think this whole draft is an idealist > attempt to workaround software defects that may be uncorrectable as a whole. > (I say this as a $large_operator as measured here: > http://as-rank.caida.org/?mode0=as

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Thu, Jan 3, 2013 at 8:01 PM, Tony Li wrote: > Example please? Assuming that the prefixes are parsed out of the message > correctly, then treating them as withdrawn should be hazard free. If a transit router in your AS treats-as-withdraw a prefix, other routers may try to send traffic across

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Hi Jeff, > I've already posted an alternative. The BGP MARKER makes it possible > to recover Message framing. I'm not sure I think this is a good idea. I'm pretty convinced that it's NOT a good idea. What happens if the marker is preceded by 0xFF? Ok, you can make some educated guesses

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Thu, Jan 3, 2013 at 5:31 PM, Tony Li wrote: > A syntactic error would be any inconsistency of length fields, > incompatibility between a type and a length, or any other error that would > introduce any doubt about the parsing of the message. Once this type of > error has occurred, then the

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Le 03/01/2013 20:36, Enke Chen a écrit : > hi, Jeff: > > On 1/3/13 11:22 AM, Jeff Wheeler wrote: > > [snip] > >> >>> Respectfully, I think you're misunderstanding my position completely. My >>> point is that a reasonable implementation cannot possibly live up to the >>> expectations that you're

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

03, 2013 3:31 PM > >To: Jeff Wheeler > >Cc: i...@ietf.org; grow@ietf.org > >Subject: Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp- > >error-handling-06.txt > > > > >I support the general concept of improved error handling and softer > >fa

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

ow@ietf.org > >Subject: Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp- > >error-handling-06.txt > > > > >I support the general concept of improved error handling and softer > >failures when possible. > > > It exasperated it by causing pe

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Hi Donald, >> A session reset seems like the only (conservative) way >> of handling this, as it's unclear that further data would be accurate. > I disagree. Does a session reset fix the issue? It hasn't the last few times > I have seen this. > It exasperated it by causing peers to drop and havin

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Li >Sent: Thursday, January 03, 2013 3:31 PM >To: Jeff Wheeler >Cc: i...@ietf.org; grow@ietf.org >Subject: Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp- >error-handling-06.txt > > >On Jan 3, 2013, at 2:15 PM, Jeff Wheeler wrote: > >>>> However

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Jan 3, 2013, at 2:23 PM, Jeff Wheeler wrote: > Fortunately vendors understand that they need to produce options to > suit different kinds of customers. Fortunately, this vendor has been around long enough to understand that adding options to suit every possible behavior results in comple

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Jan 3, 2013, at 2:15 PM, Jeff Wheeler wrote: >>> However bad or difficult to clean up, what if that's not as bad as the >>> alternative ? >> >> Clearly, the treat-as-withdraw alternative is better. You're not leaving >> bogus state in the rest of the network. > > Does this mean you suppor

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Thu, Jan 3, 2013 at 5:16 PM, Tony Li wrote: > Unfortunately, the code is NOT going to be that sensitive to the variations > of the use case. The same code that the Tier 1 carrier is using is the same > code on much smaller systems. We need to find a behavior that is amenable to > all. One

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Jan 3, 2013, at 1:19 PM, Jeff Wheeler wrote: > A lot of folks are thinking about this problem in the context of the big > carrier who doesn't want a hard-to-diagnose problem of 1 RIB entry being > wrong. That's okay, it is one way to think about it. Unfortunately, the code is NOT going t

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Thu, Jan 3, 2013 at 5:05 PM, Jared Mauch wrote: > Oh, I understand all these use-cases, but there is a case for a well-designed > network not always sharing/mixing the NLRI. eg: We don't transport v4 NLRI > in v6 transport, nor v6 NLRI in v4 transport. If you have a single session > with m

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Jan 3, 2013, at 1:48 PM, "Chris Hall" wrote: > However bad or difficult to clean up, what if that's not as bad as the > alternative ? Clearly, the treat-as-withdraw alternative is better. You're not leaving bogus state in the rest of the network. Tony ___

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Jan 3, 2013, at 5:01 PM, Jeff Wheeler wrote: > On Thu, Jan 3, 2013 at 4:28 PM, Jared Mauch wrote: >> Also, if you're seeing some problem, I'm sure that some other set of >> people out there will be seeing it as well. The shared pain/cost will >> exist. If you can't take the risk of speaking

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Jeff, > I can fix them later, maybe even after I've had time to fully analyze the > problem and get a software update from my vendor. Well that assumes you have even noticed the problem in the first place. On the point of flapping - completely agree. But the knob - already available in some impl

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Jan 3, 2013, at 4:19 PM, Jeff Wheeler wrote: > On Thu, Jan 3, 2013 at 3:18 PM, Robert Raszuk wrote: > > How are you going to clean the NLRIs in your network (both transit or > > stub) which were withdrawn in the messages your BGP implementation > > declared "bad" and decided to ignore ? > >

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Hi Jeff, > Ignore-bad-message is very simple and provides a band-aid for more > problems, including unforeseen problems. How are you going to clean the NLRIs in your network (both transit or stub) which were withdrawn in the messages your BGP implementation declared "bad" and decided to ignore ?

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Jan 3, 2013, at 2:35 PM, Michael Long wrote: > > On Jan 3, 2013, at 10:00 AM, Tony Li wrote: >> >> >> All of the marketing that you're doing here is positioning this as a >> 'solution'. It's not. Yes, it will stop the flap, but it does NOTHING to >> fix or deal with the underlying bug.

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

hi, Jeff: On 1/3/13 11:22 AM, Jeff Wheeler wrote: [snip] Respectfully, I think you're misunderstanding my position completely. My point is that a reasonable implementation cannot possibly live up to the expectations that you're setting up here. To be specific, once an implementation lose

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Jan 3, 2013, at 10:00 AM, Tony Li wrote: > > > All of the marketing that you're doing here is positioning this as a > 'solution'. It's not. Yes, it will stop the flap, but it does NOTHING to > fix or deal with the underlying bug. All it does is gloss it over, and as > such, it will hav

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

> On Thu, Jan 3, 2013 at 6:30 PM, Smith, Donald > wrote: > Exactly. Ignore (not treat as withdraw, not reset session, ...) seems the > sanest approach to me also! That's equally good as starting to drill little holes in the ship in the middle of ocean. Sure it will still swim for a while, but w

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Wed, Jan 2, 2013 at 12:56 PM, Tony Li wrote: > While we can do SOME things to decrease session resets, we cannot fix all > cases and simply treating things as a withdraw and walking away is wholly > unacceptable, as some of you will hopefully agree. Creating arbitrary hair > here is NOT goi

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Jeff, >> While we can do SOME things to decrease session resets, we cannot fix all >> cases and simply treating things as a withdraw and walking away is wholly >> unacceptable, as some of you will hopefully agree. Creating arbitrary hair >> here is NOT going to help as the error handling code

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Jeff, On Jan 3, 2013, at 11:51 AM, Jeff Wheeler wrote: > On Wed, Jan 2, 2013 at 12:56 PM, Tony Li wrote: >> While we can do SOME things to decrease session resets, we cannot fix all >> cases and simply treating things as a withdraw and walking away is wholly >> unacceptable, as some of you wil

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

"Pampers use multiple layers of protection to prevent leakage. Rommel used defense in depth to defend European fortresses." (A.White) donald.sm...@centurylink.com >-Original Message- >From: idr-boun...@ietf.org [mailto:idr-boun...@ietf.org] On Behalf Of >Jeff Wheeler >Sent: Monday, De

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

> 1) in the (big) "Internet" space, lost NLRI are a huge deal for > customers. indeed. > At some point, the equipment that is sending or receiving the BGP > message will need to be maintained by the owner. early. i want to hear it from my network management system before i get a call from the c

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Rob Shakir wrote (on Wed 02-Jan-2013 at 11:39 +): > On 1 Jan 2013, at 17:27, Chris Hall wrote: > > […snip…] > I think this is a good summary of the different approaches. In ops- > reqs-for-bgp-error-handling-06, there is no category of "fatal" > essentially because (as you highlight) the line

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On , Tony Li <> wrote: > simply treating things as a withdraw > and walking away is wholly unacceptable, It's worth reiterating that Robert and I (at least) have advocated for using http://tools.ietf.org/html/draft-ietf-idr-operational-message-00 when an error is detected but no NOTIFICATION is s

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Jan 2, 2013, at 7:26 AM, Jared Mauch wrote: > We can not correct for every error, nor should we make that a goal as the > results in writing the error handling code quickly get complex. +1 I'd also like the folks in the operational community who feel that treat-as-withdraw is a too libe

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Jeff Wheeler wrote (on Mon 31-Dec-2012 at 20:36 +): > Like I keep saying, the goal of error-handling should be to make > session-reset avoidable. Today it is not. It is creating complex > rules which must be supported by both sides of the BGP session to > try very hard to keep the networ

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Mon, Dec 31, 2012 at 3:24 PM, Jakob Heitz wrote: > That covers malformed attribute flags. Except in the MP_REACH_NLRI or MP_UNREACH_NLRI, which is not a foolish exception if the goal is to recover all the NLRI; but if the goal is to avoid session-reset, it is. Like I keep saying, the goal of

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Mon, Dec 31, 2012 at 1:41 PM, John Leslie wrote: >And, I'm not sure what it means to "settle on" "treat-as-withdraw" > that some of us consider "good enough" for a "limited" period while > humans are working to resolve the actual problem. We know that the > "limits" on such a period correla

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Jakob Heitz wrote: > On Dec 31, 2012, at 1:21 AM, "Robert Raszuk" wrote: >> On Mon, Dec 31, 2012 at 4:09 AM, John Leslie wrote: >>> Brian Dickson wrote: But, the basic problem is this: missing an UPDATE won't trigger either condition, it will at worst cause sub-optimal routing.

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Mon, Dec 31, 2012 at 12:54 PM, Jakob Heitz wrote: > I don't think treat-as-withdraw is trying to fix a single session reset. > Graceful restart can fix that. It's the rolling resets that need a human to > remove a buggy router or a config that triggered the bug. That takes several > hours. T

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Mon, Dec 31, 2012 at 5:52 AM, Rob Shakir wrote: > If we tear down the session based on a single bad UPDATE, then Bad Things™ > happen. This is why I'm confused why you aren't more interested in giving the vendor (ultimately, the operator) the choice to simply ignore bad updates. You know tha

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Jan 1, 2013, at 12:27 PM, Chris Hall wrote: > It is a truth universally acknowledged (AFAICS), that if NLRI in a > broken UPDATE are treated-as-withdraw, that is no worse than > session-reset and much to be preferred. > > So, treat-as-withdraw is a reasonable thing for any implementation to >

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On 1 Jan 2013, at 17:27, Chris Hall wrote: > […snip…] Hi All. I think this is a good summary of the different approaches. In ops-reqs-for-bgp-error-handling-06, there is no category of "fatal" essentially because (as you highlight) the line between the fatal and the critical cases is somewh

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On , Jeff Wheeler <> wrote: > On Mon, Dec 31, 2012 at 1:41 PM, John Leslie wrote: > Malformed Attribute Flags are not > one of the criteria it addresses. http://tools.ietf.org/html/draft-ietf-idr-error-handling-03 says When a path attribute (other than the MP_REACH_NLRI attribute [RFC476

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Hi Jeff, > That was a bug, but the customers had NO OPTIONS TO WORK AROUND THIS. > Their ONLY CHOICE was to wait for a patch from their vendor (for folks > whose vendor routers did this) + > the operator can buy time to diagnose it in detail, or wait for his > vendor to provide a software update

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

The difference between ignore and treat-as-withdraw is discussed in the draft. Anyway, the feature will be knobbed. So far, I see 2 knob options: 1. Treat-as-withdraw / ignore 2. If stream sync is lost, search ahead for the next 16*0xFF / reset the session. Cheers, Jakob On Dec 31, 2012, at 10:1

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Dec 31, 2012, at 4:49 AM, "Robert Raszuk" wrote: > > I have discovered last week in one of BGP implementation that BGP > conditional advertisement will not kick in till the trigger (check > condition) disappears completely from BGP table even if it's next hop > is no longer present in global

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

I don't think treat-as-withdraw is trying to fix a single session reset. Graceful restart can fix that. It's the rolling resets that need a human to remove a buggy router or a config that triggered the bug. That takes several hours. Treat-as-withdraw limits the damage during those hours. Could

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On 31 Dec 2012, at 16:59, Jeff Wheeler wrote: > On Mon, Dec 31, 2012 at 5:52 AM, Rob Shakir wrote: >> If we tear down the session based on a single bad UPDATE, then Bad Things™ >> happen. > > This is why I'm confused why you aren't more interested in giving the > vendor (ultimately, the operat

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Hi Robert, On 31 Dec 2012, at 12:49, Robert Raszuk wrote: > I think your draft and even the proposed solution is the best for the > current BGP4 transport of messages for the cases where some bug is > remote and you would likely end-up resetting perhaps all of your > upstream sessions .. no doubt

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Hi Rob, > we are still questioning the validity of the problem space. I am not sure where do you draw such impression from ? I think we are all clear that there is problem .. from time to time a bleeding wound appears. However it seems that there is serious concern if the cure proposed is the ri

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On 30 Dec 2012, at 21:34, Brian Dickson wrote: > But, the basic problem is this: missing an UPDATE won't trigger either > condition, it will at worst cause sub-optimal routing. Missing a WITHDRAW > _CAN_ cause Bad Things (TM) to happen. If we tear down the session based on a single bad UPDATE,

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

How about if we would mandate Enhance Route Refresh request to be send to such peer who's bad updates triggered treat-as-withdraw action ? If we resync databases OK the likehood of "bad things" should be minimal. If we fail to sync (get another malformed update(s)) then IMHO resetting the session

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

On Sun, Dec 30, 2012 at 4:34 PM, Brian Dickson wrote: > There are a couple of easy ways to ensure the WITHDRAW is not missed: > - Pack all the WITHDRAW stuff at the start > - Require that no UPDATE be sent in the same MESSAGE as a WITHDRAW, and > preferably limit WITHDRAW to one AFI/SAFI per MESSA

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Brian Dickson wrote: > > But, the basic problem is this: missing an UPDATE won't trigger either > condition, it will at worst cause sub-optimal routing. Missing a WITHDRAW > _CAN_ cause Bad Things (TM) to happen. +1 -- John Leslie ___ GROW mailing

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Here's the basic problem in a nutshell: If a WITHDRAW is missed (either standard or MP), there are two possibilities concerning withdrawn NLRIs: - the WITHDRAW was sent because the sender no longer HAS a route to the destination, or - the WITHDRAW was sent because the sender now prefers the route

Re: [GROW] [Idr] I-D Action: draft-ietf-grow-ops-reqs-for-bgp-error-handling-06.txt

Hi Brian, We discussed this at some length previously (the -00 of the requirements draft discussed automatically triggering some form of means to recover from the error). I think that there is some merit in doing so, but there are clearly also scaling considerations around this (in terms of req