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

"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: Tony Li [mailto:tony...@tony.li] >Sent: Thursday, January 03, 2013 4:15 PM >To: Smith, Donald >

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