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

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

> -----Original Message-----
> From: Pedro Roque Marques [mailto:[email-masked]]
> Sent: Wednesday, July 10, 2002 3:06 PM
> To: Abarbanel, Benjamin
> Cc: [email-masked]'
> Subject: RE: INFORM proposal and MP-BGP (RFC 2858)
> 
> 
> 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.

How will the offending peer know it is doing something wrong if the
receiving 
peer does not send some indication of the problem? 

I would agree sending more than a few consecutive INFORM messages could lead
to a very big burst of INFORM messages if the offending peer does not stop
sending the invalid update messages. 

> 
> 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.
>
 
Could we not fall into this kind of race condition after session resets? 

Ben

---

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

Abarbanel, Benjamin writes:

> receiving peer does not send some indication of the problem?

There is no problem in this scenario... just messages that cross
themselfs in transit. I see no benifit in informing the sender of
this.

>> 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.
 
> Could we not fall into this kind of race condition after session

It would not be of the same session, correct... ? session implies a
TCP socket. If you do have a close, there is an implicit sequencing
event and no confusion with previous messages.

  Pedro.

---

From: Gargi Nalawade <[email-masked]>
Date: Wed, 10 Jul 2002 14:12:26 -0700

Hi All,

A few clarifications about the INFORM message & its motivations. This is
supposed to be purely an informational message. Does not propose to affect
the functionality of the protocol. Rather, it proposes to give flexibility
to implementations in that; they dont need to reset the sessions, just so
they can inform the peer of a specific noteworthy event happening. 

Take the example of max-prefix limit. If the limit is hit, the receiving
peer would just generate a local warning (if so configured) and continue
with the session. There is no mechanism of informing the other peer that
it has exceeded the prefix-limit value, other than churning through the log,
noticing the warnin & then picking up the telephone (or oops - writing an
email) & informing the peer's administrator.

This is just one such hypothetical example where the INFORM would be useful.
But the INFORM message gives us the capability to do just that. There are 
several other such scenarios seen in deployment, that necessitate the
existence of just such a mechanism.

-Gargi