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

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

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 11:08:41 -0700

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.

---

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

Abarbanel, Benjamin writes:

> Correct. The protocol has to be elastic, since it carries so much
> weight in controlling stability in the Internet.

<meta>

If the stability of the Internet is the concern, then i believe that
one should avoid any changes to the protocol unless they are
absolutely necessary.

If we where talking about a protocol in early development then adding
extra 'bells and whistles' would probably be ok (although i can think
of quite a large number of new protocols which deployment has been
very negativly impacted by constant churn).

But since this an essential protocol to the internet, the burden of
proof required to make a modification to the protocol should be much
higher and should be on the side of the proponents.

By default the answer should be 'no'. Don't change the protocol, add
flexibility that you desire, and is fact required operationally, in
the implementations. There is plenty of space to compete there...

</meta>

  Pedro.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 10 Jul 2002 15:07:40 -0400

I want to post something more thoughtful on this thread, but have
to do it later due to time constraints.

I couldn't let this pass though.

> one should avoid any changes to the protocol unless they are

This made me laugh extremely loudly - but not at you.

I count 9 RFC extensions past RFC1771 base functionality.
I count at least 10 protocol extensions in ID form in just
my personal watch list of stuff that we may implement or have
implemented.  This list is by no means complete.

When talking to people, I often refer to BGP as the "Border Glue Protocol".
People keep adding stuff.

> the implementations. There is plenty of space to compete there...

The trick is to do it in an interoperable way.

-- 
Jeff Haas 
NextHop Technologies