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

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

I am in favour of providing a tolerance counter that will drop the session
only after a max number of bad update messages are received. Thus if the
offending
peer does not correct or adjust itself in terms of capabilities, after a
number
of INFORM responses are sent to it, then and only then should the receiving
router drop the session. This will cover the case, where the INFORM is also
mis-processed in the "ships in the night" scenario.

Ben

> -----Original Message-----
> From: Chandrashekhar Appanna [mailto:[email-masked]]
> Sent: Wednesday, July 10, 2002 2:09 PM
> To: Abarbanel, Benjamin
> Cc: 'Bruno Rijsman'; [email-masked]
> Subject: Re: INFORM proposal and MP-BGP (RFC 2858)
> 
> 
> 
> But that and the ability to INFORM is not the same. In the
> example you provide, the INFORM is not providing any extra 
> advantage. If the peer did not process/rcv the withdraw 
> why do you hope that it will rcv/process the INFORM?
> 
> I think the behavior of the withdraw itself is the problem here,
> It has to handle the case of a message cross that you describe, 
> in a well defined manner. 
> 
> -
> Chandra A.
> 
> On Wed, Jul 10, 2002 at 11:50:32AM -0400, Abarbanel, Benjamin wrote:
> > Correct. The protocol has to be elastic, since it carries 
> so much weight in 
> > controlling stability in the Internet.
> > 
> > Ben
> > 
> > > -----Original Message-----
> > > From: Bruno Rijsman [mailto:[email-masked]]
> > > Sent: Wednesday, July 10, 2002 11:47 AM
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject: RE: INFORM proposal and MP-BGP (RFC 2858)
> > > 
> > > 
> > > Re> Just because you receive an Update message with 
> capabilities that
> > > Re> were not negotiated at the OPEN message, should not 
> require the
> > > Re> peering session to terminate. The affect of all that 
> peer routes
> > > Re> going down will destabilize the network.
> > > 
> > > 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.
> > > 
> > > 
> > > 
> > > _________________________________________________________________
> > > Send and receive Hotmail on your mobile device: 
http://mobile.msn.com

---

From: Chandrashekhar Appanna <[email-masked]>
Date: Wed, 10 Jul 2002 15:21:20 -0700

You can be tolerant in your implementation today if you choose
and if your customers will accept it. I do not see how you hope
that a new INFORM message will let an implementation correct itself 
when the implementation failed to do the right thing in the first 
place.

-
Chandra A.