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

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Wed, 10 Jul 2002 14:44:15 -0400

pedro:

As was mentioned in earlier email:

" Also, keep in mind that in the case of dynamic capability negotiation
  is possible and perfectly legal to receive a message which relies on
  a capability which was recently withdrawn. Consider for example the
  case where a route-refresh message and a capability message which
  withdraws the route-refresh capability cross each other."

In this case there was no corruption in the payload of the Update message
and yet the state machine was in a inconsistent state for a particular
capability due to the race condition. In your approach you would have 
considered that peer's routes invalid and terminated the session. In my,
approach I would not, but yet send back an INFORM to the inconsistent 
peer and expect it to take the proper corrective action. My way, gives a 
little room for the protocol to tolerate temporary inconsistency. 
Yours wont. 

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

I am in favour of ignoring the entire update message if it has invalid
capabilities. Thus previous updates are still maintained. I am also in
favour of defining a tolerance counter for invalid update messages such
that after a number of invalid updates, only then should the receiving peer
drop the session.

> 
> 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...
>
If we are talking of gracefull ways of handling invalid updates, then an
immediate session drop is unacceptable. If we are talking of non-gracefull
way, then you are right. 

The problem is, in my experiences taking abrupt action most of the time is
not necessary and usually leads to unstable and unconverged network. Cause
if you drop the peer, and the race condition occurs again and again after
a session restarts, you will be in a perpetual loop and you will experience
oscillations in routes and then that opens the topic to our previous thread
of converstation here on the list. Also if the offending router has a
software
bug that causes this condition, what makes you think if you drop the session
the offending router will magically correct its code?
 
> In most of the cases you have already received and accepted corrupted
> data that fail to trigger any validation checks.
> 
 Can you explain in detail the scenario you are talking about here?

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

Agree on this point.

> 2) Drop all information from the peer ASAP...

Disagree on this point. Why all previous good updates from this peer bad?

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

I sure hope the people who drafted this, have deployment experience and are 
saying this for the majority of the cases.

Can we get some voices on this from the authors of this draft?

>   Pedro.

Thanks,
Ben

---

From: Pedro Roque Marques <[email-masked]>
Date: Wed, 10 Jul 2002 12:06:24 -0700 (PDT)

Abarbanel, Benjamin writes:

> pedro: As was mentioned in earlier email:

> " Also, keep in mind that in the case of dynamic capability
> negotiation is possible and perfectly legal to receive a message
> which relies on a capability which was recently withdrawn. Consider
> for example the case where a route-refresh message and a capability
> message which withdraws the route-refresh capability cross each
> other."

> In this case there was no corruption in the payload of the Update
> message and yet the state machine was in a inconsistent state for a
> particular capability due to the race condition.

> In your approach
> you would have considered that peer's routes invalid and terminated
> the session.

No. It has been a while since i read that particular proposal but i
seem to rememeber and i believe that the following algotihm is
recomended there or has been discussed...

At an nlri withrawl:
- Keep track of nlri which where enabled until that event
- Start a timer (something like 30 secs)
- For the duration of the timer ignore updates that match the
remebered nlri.
- When the timer kicks, cleanup the 'old nlri'...

No additional spec changes... implementation details that afect the
behaviour during a shortest interval of time.

> In my, approach I would not, but yet send back an
> INFORM to the inconsistent peer and expect it to take the proper
> corrective action.

imho, that isn't the correct behaviour on a 'race condition' kind of
scenario... you want to discard those messages silently without
generating new messages in response.

btw: If a BGP speaker, receives an inform that claims that it is
sending an NLRI that in fact it is not configured to send what is the
suggested behaviour ? I'd be tempted by default to reset the session
since the peer clearly doesn't know what it is talking about.

> My way, gives a little room for the protocol to
> tolerate temporary inconsistency.  Yours wont.

I believe it is a weak argument...
Temporary, triggered inconsistencies, should not be handled at the
expense of ignoring the problem of inconsistencies that happen due to
failure in a more generic case...

btw: i've omitted my usual rant on how i believe that dynamic capability
negociation for NLRI is a questionable enhancement from a cost/benefit
point of view. Shouldn't be monopolizing the soap box...

  Pedro.