Subject: RE: INFORM proposal and MP-BGP (RFC 2858)

From: "Natale, Jonathan" <[email-masked]>
Date: Fri, 12 Jul 2002 14:33:05 -0400

This is already done--if CONFED path is received the peer stays up (and the
local pref gets ignored).  This is good, but not in an rfc nor a draft.  My
vote is for an INFORM.

-----Original Message-----
From: Jeffrey Haas [mailto:[email-masked]] 
Sent: Friday, July 12, 2002 2:29 PM
To: Alex Zinin
Cc: [email-masked]
Subject: Re: INFORM proposal and MP-BGP (RFC 2858)

Alex,

There are some circumstances under which we currently send notifications
where some weaker mechanism may be sufficient.  Almost every one of
these situations fall under the category of "well formed packet,
well-formed recognized attributes, weird/bogus data inside them".

As you infer, there are situations where we should just assume that
the buffer contains cruft and that the implementation needs a 
strong reset.

However, there are situations where we could get stuff that we can
deal with and just ignore the "Bad" things.  This was the case when
someone's implementation started leaking non-prefixed confederation
segments into the internet.  The packets were well formed, but had
cruft in them.

Similarly, if we ever add an origin type of 4, we'll have migration
issues.  If implementations just discarded updates that contained 
unrecognized data....

It may be worth our while to spend some time analyzing the protocol
for places where we can gracefully deal with failures and move along.

Or...
We could just say that NOTIFY is the right answer to deal with
confused implementations and trust to graceful restart to minimize
the impact on the Internet as a whole.  (But note that this wouldn't
have dealt with the non-prefixed confeds issue.)

On Mon, Jul 08, 2002 at 03:22:59PM -0700, Alex Zinin wrote:
>  BTW, a more generic question: if we can't trust an attribute
>  as a whole (since it's invalid), how can we trust specific fields
>  (AFI/SAFI) inside, i.e., if an MP_* attribute is malformed, it is
>  unsafe to assume that AFI/SAFI fields are correct... so, we may
>  very well end up deleting and ignoring a wrong (but valid) AFI/SAFI.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 12 Jul 2002 14:56:41 -0400

> local pref gets ignored).  This is good, but not in an rfc nor a draft.  My

IMO, this is a case where the route's local pref shouldn't be just ignored,
but the entire packet should be discarded.

-- 
Jeff Haas 
NextHop Technologies

---

From: Pedro Roque Marques <[email-masked]>
Date: Fri, 12 Jul 2002 12:14:38 -0700 (PDT)

Jeffrey Haas writes:

>> This is already done--if CONFED path is received the peer stays up
>> (and the local pref gets ignored).  This is good, but not in an rfc
>> nor a draft.  My vote is for an INFORM.

> IMO, this is a case where the route's local pref shouldn't be just
> ignored, but the entire packet should be discarded.

From both quotes above it apears to me that you are proposing to
discard an UPDATE and leave the session up. Since BGP state is
incremental, that would mean the two peers would now potentially be
out of sync.

  Pedro.

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 12 Jul 2002 16:20:14 -0400

> incremental, that would mean the two peers would now potentially be

And no less intentionally than if I discarded everything via policy.
In this case, my policy is "discard bad (for some value) packets".

Currently, we can only discard and move along.
The proposal with INFORM at least lets us tell our upstream that
they did something we didn't like, if they even care.

-- 
Jeff Haas 
NextHop Technologies

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 15 Jul 2002 17:39:45 -0400

>In this case, my policy is "discard bad (for some value) packets".

No, it's worse than that.  Here's an example of harm using your 
"let's introduce a new origin code of 4" case.

- Router A sends router B an announcement of prefix foo with origin 1.
- Router A now sends router B a replacement for prefix foo, but with 
newfangled origin 4.  The replacement has a different next hop from 
the previous announcement.
- Router B ignores the replacement because of the posited "discard 
updates that contain unrecognized data" rule.

Result?  Router B retains router A's old route, whose next hop is no 
longer valid.  This goes on forever, or until router A sends an 
update with a recognized origin, or until router A withdraws the 
route.  The bad next hop may result in nothing serious, but it may 
equally well result in a black hole or a persistent forwarding loop. 
This seems to a cure which is much worse than the disease.

Of course, refusing routes by policy doesn't have this problem at all.

Let me grant you up front that you can fix this specific case by 
being more careful in stating your rule -- instead of "discard 
updates that contain unrecognized data" make it "treat updates that 
contain unrecognized data as if they were withdraws".  But whenever 
(and if ever) you want to gloss over a protocol error like this IMO 
you need to analyze the consequences quite carefully.

--John

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 16 Jul 2002 11:24:11 -0400

> updates that contain unrecognized data" rule.

You've just given the strongest example of why not NOTIFYing can be
a bad idea.

As you mention later:

> being more careful in stating your rule 

This leaves me asking again, "Is there some way we can gracefully
deal with some errors?"  In the case of dealing with the non-prefixed
confederation segments, the answer was yes.  The example you give
could also have worked had it been worded more carefully to only
apply to path attributes and unrecognized/semantically incorrect
attributes yet still use the NLRI for purposes of discarding those
prefixes from your adj-ribs-in.

My general concern is that we already have vendors implementing
various forms of graceful error handling that aren't strictly
conformant with the spec.  If this is the norm, we should codify it.
If we don't, we risk interoperability issues due to one vendor's
bugs killing other vendor's peering sessions "far away".

-- 
Jeff Haas 
NextHop Technologies