Subject: RE: Open Routing Area meeting in Vienna

From: Jeff Parker <[email-masked]>
Date: Thu, 31 Jul 2003 09:55:26 -0400

> How is carrying it in another protocol going to keep the new 
> data being carried and processed from impacting the old data 
> being carried and processed?   

Russ -
	I haven't heard concern about the amount of raw
data a box is carrying.  I have heard concerns about 
Implementation Complexity and Protocol Convergence.  

	I agree that producing a new protocol with the
maturity and utility of BGP or IS-IS is difficult.  
But at some point we hit the salami principle: it 
isn't adding this slice or that slice that gets you,
but soon you have a sandwich that only Dagwood
Bumstead can handle.*  At some point, it is time
to start a new sandwich.  

- jeff parker

* Kurt - Appologies for this grossly US reference.  

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Russ White <[email-masked]>
Date: Thu, 31 Jul 2003 10:16:38 -0400 (EDT)

> Implementation Complexity and Protocol Convergence.

Well.. I'm hearing (on this thread) that the reason BGP converges so slowly
is the amount of data it is carrying, and then on the other side, that this
isn't the problem it's a deployment issue, but then back that the
deployment issues are caused by the protocol, etc.... In fact, the only
thing that seperating a specific set of data out is going to give you is
the ability to prioritize what you converge first.

If we are going to develop a new protocol, should we develop it over
something other than TCP, just so we don't overload the TCP stack on the
box, and impact BGP's performance? Or perhaps we should go down to the IP
layer, and say that too much is being carried there? It's hard to say when
you should stop, and say that it's okay to multiplex here, and not there.

It's easy to do what http has done, and pile everything on one channel.
It's also easy to do what ospf has done, and make a seperate channel for
everything (unecessarily, in my opinion).

> 	I agree that producing a new protocol with the maturity and utility
> of BGP or IS-IS is difficult.  But at some point we hit the salami
> principle: it isn't adding this slice or that slice that gets you, but
> soon you have a sandwich that only Dagwood Bumstead can handle.* At some
> point, it is time to start a new sandwich.

But, if you're eating the same amount of food either way, then is it better
to get a "bigger mouth," or a "smaller sandwich?" And if you have to eat
1000 smaller sandwiches, are you going to be any less full? Maybe we're
just facing a case of having too much information to cart around, rather
than a case of "time to build a second sandwich." I don't know.... (?).

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone

---

From: Russ White <[email-masked]>
Date: Thu, 31 Jul 2003 10:16:38 -0400 (EDT)

:-)

Russ

---

From: Mark Handley <[email-masked]>
Date: Thu, 31 Jul 2003 15:27:22 +0100

>the ability to prioritize what you converge first.

No, using different connections also means two datasets don't share
fate to the same extent.

If one dataset's sender generates an illegal message, the receiver
won't tear down the TCP connection for all datasets.  

If the reader for one dataset fails to read quickly enough (because
it's buggy, or it's doing something time consuming, or it's waiting on
someone else, or whatever), then it will block a shared TCP connection
for everyone.

If one dataset generates an excessively large amount of data, using
separate connections means it won't cause the other datasets to be
directly delayed by TCP congestion control and being queued behind the
large amount of data - they'll be indirectly delayed by competing with
the other TCP connection, but this is a much less severe situation.

In particular, using different connections gives most of the control
over which thing gets scheduled first to the receiving router.  If two
datasets share a connection, this gives the sending router much more
control over the relative scheduling at the receiver.

Cheers,
	Mark

---

From: Mark Handley <[email-masked]>
Date: Thu, 31 Jul 2003 15:27:22 +0100

Cheers,
	Mark

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 31 Jul 2003 21:29:37 +0200

Mark,

As said before to Lars you can easily carry each AFI/SAFI with a
separate BGP session today. So what is the problem which mandates new
protcol to achive any of the points you made below ?

R.

> Mark Handley wrote:

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 31 Jul 2003 21:29:37 +0200

Mark,

R.