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

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Wed, 10 Jul 2002 11:40:08 -0400

Pedro and Jeff:

> -----Original Message-----
> From: Pedro Roque Marques [mailto:[email-masked]]
> Sent: Tuesday, July 09, 2002 1:45 PM
> To: Jeffrey Haas
> Cc: [email-masked]'
> Subject: Re: INFORM proposal and MP-BGP (RFC 2858)
> 
> 
> Jeffrey Haas writes:
> 
> > The operational community continues to demand resiliency from the
> > BGP protocol.
> 
> I believe you get less resiliency, not more, from accepting corrupted
> messages. If you have a peer that is sending you a given NLRI and it
> didn't negociate it then either:
> 1) The peers state machine is completly out of wack, case in which you
> want to reset it.

Just because you receive an Update message with capabilities that were not
negotiated at the OPEN message, should not require the peering session to
terminate. The affect of all that peer routes going down will destabilize
the network. 

I think a more gracefull mechanism suggested by others on this list will 
help inform the originating error'd peer of this case and allow it to either

remove the unapproved capability from future updates or self terminate the 
peering session. It is more gracefull for the originating peer to decide if
its 
publicized routes are compromised. The assumption being is that the
advertised 
routes are most likely stable and reachable and do not constitute any harm
to 
the topology. 

The receiving peer should ignore all subsequent capabilities not informed
during 
the session OPEN exchange. We would need a NON session terminating warning
message like the INFORM suggested by others to do this:

  "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?)
  "

> 2) It is a corrupted message, case in which you wish to reset it.
> 
> >  If we can avoid sending a NOTIFICATION and gracefully
> > deal with someone elses buggy code, thats a Good Thing.

It is very difficult to determine if the offending peer has buggy code or a
minor bug. Just taking down all its routes on the first sign of trouble
would not be wise.

Also, multiprotocol capabilities are new and optional things they should not
destablize the network if there is doubt on their intentions.

> 
> > Sending an INFORM would be nice here, if such a thing existed.
> 
> Personally i believe that this message is completly unnecessary.
> 
>   Pedro.
>

I think BGP needs many mechanisms for gracefullness and tolerance of
imprecise
information in order to combat the Global route instability that is caused
when
BGP routers just tear down their peering sessions at the first sign of
trouble.

Ben

---

From: Pedro Roque Marques <[email-masked]>
Date: Wed, 10 Jul 2002 11:13:39 -0700 (PDT)

Abarbanel, Benjamin writes:

> Just because you receive an Update message with capabilities that
> were not negotiated at the OPEN message, should not require the
> peering session to terminate. The affect of all that peer routes
> going down will destabilize the network.

As i've detailed in previous e-mails, the receipt of an UPDATE message
for an NLRI that has not been negociated, can, imho, only be cause by
either corruption of the state machine on your peer or of the
message. When detecting such a scenario, you want to reset all
information received from the corrupted peer as fast as possible,
since poison information can be just about the most disturbing thing
to a network.

I believe that proponents of this mechanism do need to demonstrate how
it would be useful...

> I think a more gracefull mechanism suggested by others on this list
> will help inform the originating error'd peer of this case and allow
> it to either
> remove the unapproved capability from future updates or self
> terminate the peering session.

I'm sure we must have very different experiences when it comes to
UPDATE messages that include invalid NLRI...

All the instances i've seen either in the lab or in the wild have been
cases in which either one of the lenght fields have been incorrectly
calculated or the message has been inadvertily trimed by the
sender. You see an invalid NLRI not because the peer actually intended
to send such NLRI but because, typically, you are reading garbage.

I fail to see the wisdom of adding new procedures to the protocol that
concern itself with how to deal with semantically incorrect
updates. In my experience, quite often you are not lucky enought that
the message just becomes corrupted at the byte deailing the NLRI...

In most of the cases you have already received and accepted corrupted
data that fail to trigger any validation checks.

All scenarios that i've seen lead me to conclude that the desired
outcome is to:
1) Make sure that you do not propagate junk received in the UPDATE
that you detected the error.
2) Drop all information from the peer ASAP...

RFC 2858, probably because it was drafted before capability
negociation was in place, is incorrect in specifying that one should
ignore an update with a missing NLRI. It might have been the best
aproach at the time it was drafted but it isn't now. It is just
another instance where deployment experience advises one against
following the RFCs literally... which is a concept that should be
quite familiar to people dealing with BGP.

  Pedro.