Subject: RE: Open Routing Area meeting in Vienna

From: Jeff Parker <[email-masked]>
Date: Thu, 31 Jul 2003 10:37:19 -0400

> 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?" 

Russ -
	To repeat myself, I don't think the issue is the raw 
amount of data.  It is the complexity of the protocol 
and rate of convergence protocol convergence.  (And I don't
think that BGP is linear in convergence, so two smaller
sandwichs would be better than one bigger one with the
same wieght.)

> If we are going to develop a new protocol, should we 
> develop it over something other than TCP,	

	The issue isn't reuse, it is augmenting the protocol.
TCP is a general purpose transport, and both BGP and
HTTP use it.  When someone suggests augmenting TCP to
add, say, transactions, doesn't the IETF suggest that
they get a new protocol?  So I don't find your
analogy convincing, unless you want to argue that
BGP is just a general purpose distribution mechanism.  

	The idea of splitting different functions into 
different tasks on the same processor is that new or 
allarming.  This avoids fate-sharing, release-sharing,
and allows users to monitor status and manage risk.
It allows the SP to deploy versions of each protocol
that he is comfortable with.    

- jeff parker

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

---

From: Eric Rosen <[email-masked]>
Date: Thu, 31 Jul 2003 11:03:12 -0400

Jeff> TCP is a general purpose transport, and both BGP and
Jeff> HTTP use it.  When someone suggests augmenting TCP to
Jeff> add, say, transactions, doesn't the IETF suggest that
Jeff> they get a new protocol?

But  this  is  an issue  of  whether  TCP  provides functionality  which  is
appropriate for transactions.  I don't think anyone would say "you can't use
TCP because we already have too much TCP going on". 

Jeff> unless  you  want  to  argue  that  BGP  is  just  a  general  purpose
Jeff> distribution mechanism. 

It is possible  to think of BGP as a  general purpose distribution mechanism
with applications layered  on top of it, where the  "address family" is used
to multiplex the  applications.  The multi-protocol extensions to  BGP are a
pretty clear attempt to move in this direction. 

Jeff> The idea of splitting different  functions into different tasks on the
Jeff> same processor is that new or alarming. 

No question.   The issue is whether  using a different protocol  is either a
necessary or  a sufficient condition of "splitting  different functions into
different tasks".

---

From: Eric Rosen <[email-masked]>
Date: Thu, 31 Jul 2003 11:03:12 -0400

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 31 Jul 2003 17:33:58 +0200

Jeff,

> sandwichs would be better than one bigger one with the

Reg the sandwitch analogy ... 

Two (or N) smaller sandwitches could be easily done by cutting the 1
meter (sorry 3 feet) long one into pieces (read modules) before
consumption. That is exactly what making each new AFI/SAFI fully modular
is all about. Notice also that once cutted it is packed in individual
bags for distribution (each AFI/SAFI uses a separate update msg). 

Some folks on this list don't like to use knives and want to make small
sandwitches when there is only one piece of bread already in action. So
first let's make sure we have a bread ready on the table for a second
sandwitch then start putting salami on it :).

R.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 31 Jul 2003 17:33:58 +0200

Jeff,

R.

---

From: Lars Erik Gullerud <[email-masked]>
Date: 31 Jul 2003 18:16:46 +0200

> bags for distribution (each AFI/SAFI uses a separate update msg). 

One problem as I see it right now though, is that if the contents of one
of those bags isn't satisfactory (i.e. an update message is invalid),
you throw the whole loaf of bread away (i.e. peer sends notification
message and tears down the BGP session). And as more and more different
sandwiches have to be made, the chances increase that a sloppy chef
mistakenly puts ham on one of them instead of salami, so this is a real
concern.

But since we are starting to stretch this sandwich analogy, let's go
back to cleartext - I have had the "pleasure" of observing the effects
on a network where buggy router code from vendor X generated bad update
messages for one AFI (in this case, vpnv4) and BGP sessions started
dropping all over the place. Which then ended up affecting a
substantially bigger portion of the customer mass than if only the VPN
service had gone down. Without going into details, let's just say the
guys in suits were not too happy, and the guys in jeans were sweating
heavily that day.

I'm not saying a separate protocol for every service is the preferred
way to go, but from an operators POV, a "soft" failure of one service
should ideally not affect all the other services being provided on the
same infrastructure, but rather contain the failure to that particular
service. Exactly how that is achieved however, is something we Ops guys
usually prefer to leave as an exercise to the people we pay obscene
amounts of money for those giant paperweights we stuff into our 19"
racks.

/leg

---

From: Lars Erik Gullerud <[email-masked]>
Date: 31 Jul 2003 18:16:46 +0200

/leg

---

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

Lars,

There is nothing which would prohibit anyone today from using a
dedicated BGP session for each AF mesh. So all probles you are
describing are very valid, but can be already addressed today by few
extra config lines. 

Further from TCP point of view adding another protocol or using multiple
sessions for existing one is the same thing.

R.

> Lars Erik Gullerud wrote:
>

---

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

Lars,

R.

---

From: Craig Labovitz <[email-masked]>
Date: Thu, 31 Jul 2003 11:24:45 -0400

So, inter-domain BGP convergence is linear with respect to the length
of the longest possible ASPath. It is the complexity of the realized
topology, and not intrinsic properties of the protocol implementation,
that plays the largest role in convergence times.

- Craig

---

From: Craig Labovitz <[email-masked]>
Date: Thu, 31 Jul 2003 11:24:45 -0400

- Craig

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 31 Jul 2003 14:29:24 -0400

>sandwichs would be better than one bigger one with the

I don't think you can support this on a big-O analysis of 
convergence.  Let me try to break it down.

BGP's convergence time is said to be O(N!) in the number of 
autonomous systems in the Internet.  Eek!  However, leaving aside the 
fact that that's a theoretic upper bound and not the expected case, 
that is a bound for Internet-wide convergence for a particular 
destination; there is no term for number of data objects ("routes") 
in the system.  So that can't be relevant to your comment.

The data transport term for BGP or any BGP-like protocol must be 
linear, per peer, in the number of routes -- clearly you have to 
transport every route at least once, so it's at least linear, and you 
don't have to transport them more than once -- at least at this level 
of abstract discussion -- so it's not more than linear.  Since this 
analysis is independent of _how_ you transport the routes, that can't 
be what you're getting at with your "sandwich" comment either.

That leaves the on-box component.  A decent BGP implementation should 
have a per AF cost of approximately O(RPlogP) where R is the number 
of routes ("paths") per prefix, and P is the number of prefixes 
(destinations) stored in the local db for that AF.  So, right, that's 
not linear.  But it's per AF.  The cost of any BGP-like protocol 
supporting a set of related data will equally be O(RPlogP).  So 
either you sum these terms into BGP, or you divide them into 
different protocols... and still have to sum them.  So once again, I 
don't see the basis for your "two smaller sandwiches" comment.

This might be about software engineering, or protocol aesthetics, but 
I don't think it's about theoretical convergence properties.

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 31 Jul 2003 14:29:24 -0400

--John