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

From: Jeffrey Haas <[email-masked]>
Date: Mon, 8 Jul 2002 14:42:48 -0400

The proposal for the INFORM message gives the opportunity to redress
an open issue in the MP-BGP specification:

: 6. Error Handling
: 
:    If a BGP speaker receives from a neighbor an Update message that
:    contains the MP_REACH_NLRI or MP_UNREACH_NLRI attribute, and the
:    speaker determines that the attribute is incorrect, the speaker must
:    delete all the BGP routes received from that neighbor whose AFI/SAFI
:    is the same as the one carried in the incorrect MP_REACH_NLRI or
:    MP_UNREACH_NLRI attribute. For the duration of the BGP session over
:    which the Update message was received, the speaker then should ignore
:    all the subsequent routes with that AFI/SAFI received over that
:    session.

This amounts to silently ignoring reachability.

INFORM would at least make this non-silent.  However, additional pushback
might be warranted.  Upon receipt of an INFORM (or similar) message
the receiving peer may wish to choose one or more of the following actions:

o Just log it per INFORM
o Stop sending this AFI/SAFI
o Reset the peering session (contrary to the wishes of the peer?)

Thoughts?

-- 
Jeff Haas 
NextHop Technologies

---

From: Russ White <[email-masked]>
Date: Mon, 8 Jul 2002 17:12:12 -0400 (EDT)

When we originally conceived of the INFORM, we had included an
"action code" as well. This turned out to be rather cumbersome,
defining all of them. Probably the best thing to do is to make
certain this code is included in the spec, and perhaps loosen up
the text as to what may be done when receiving an INFORM to
include user configurable options, such as dropping the session
or just the impacted updates, etc.

:-)

Russ

> o Reset the peering session (contrary to the wishes of the peer?)

__________________________________
[email-masked] CCIE <>< Grace Alone

---

From: Alex Zinin <[email-masked]>
Date: Mon, 8 Jul 2002 15:22:59 -0700

Jeff,

 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.

 [I thought I brought up this issue already, but I couldn't find
 any evidence]

-- 
Alex

---

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

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.)

-- 
Jeff Haas 
NextHop Technologies