Subject: Open Routing Area meeting in Vienna

From: Bill Fenner <[email-masked]>
Date: Tue, 8 Jul 2003 16:00:09 -0700

Hiya folks,

  Alex and I managed to both assume that the other one was going to
schedule the routing area meeting for Vienna -- oops!  Luckily, we
have very forgiving people in charge of the scheduling, so we were
able to get a room: Hall NO on Thursday afternoon, 1530-1730.  (This
is on the online agenda, but didn't make it into the printed version.)

  We will begin with the usual status reports from the working groups
and BOFs that meet.  We'll start the open mic time with a discussion of
reuse of routing protocols for things that look less and less like
routing, and we'll see where things go from there.  A more complete
agenda will follow.

  Bill

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

---

From: Tulip Rasputin <[email-masked]>
Date: Wed, 30 Jul 2003 02:51:18 -0400 (EDT)

Robert,
 
> There has always been an issue if one should extend one city with new
> buildings or start over and build new city. My take on this is that if
> the architecture of a given city is good, communication is perfect and
> can scale adding a new buildings or districts nicely divided from one
> another will not harm anyone to get to large sizes accomodating all
> newcommers.

I *dont* like this analogy at all but since you've started this, let me make an attempt to explain
you using the same. Say you have this really great city and the taxes are really low here. The
infrastructure is great, the climate is fantastic and you have lovely beaches. Everybody is happy,
the administration is satisfied with the population and the related issues.

Because of the above mentioned factors, people from nearby (and far off) states/cities start
immigrating to this city. They believe that the infrastructure is great (and all the other things
which i mentioned) and that it would really take them no time to commute to their work (which
happens to be in other cities!). 

Over a period of time, you have equal number of people living in this city who work here and who
work in places nowhere connected/associated with this city. They by all means share the same
resources as the people living/working in this city. Dont you now see a problem with this (traffic
jams/increased property rates/rents/pollution/etc)?

The local authorities would somehow need to put a check on this. They can as a deterrent increase
the taxes or do something to prevent more people from coming in. The infrastructure is now enough
to just keep this much population. Now what if more people want to come in who need to work here?
What about the offsprings? 

As i had said earlier, i dont approve of this analogy at all and infact find it quite dumb - but
used the same to explain my point and what probably has been plaguing the ADs and the other
IETFers for long!

BGP is critical for the Internet (Pedro might feel uncomfortable for my using this term so loosely
:) !) and we must proceed with caution. By adding more and more features we will only be bloating
the code size and the probability of introducing more and more bugs. Yes, this is an
implementation specific issue and the vendors will have their own ways to deal with it - but the
fact remains that by doing this we make BGP more and more vulnerable than what it already is.

Regards,
Rasputin

P.S.

And why is it that we only see some of the vendors in favor of bundling BGP with everything. Is
there any ISP out there which feels the same? What is it that they feel is right? Would they want
to muck around with BGP?

______________________________________________________________________ 
Post your free ad now! http://personals.yahoo.ca

---

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.

---

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

---

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

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

There are really two questions

   a) Should data for my application be carried in BGP?

   b) Should data for his application be carried in BGP?

It is tempting to say that the answer to a) is yes
and the answer to b) is no.  

I don;t know what the right answer is, but see the
attempt to write down some rules as a useful effort.

- jeff parker

---

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

- jeff parker

---

From: Jeff Parker <[email-masked]>
Date: Thu, 31 Jul 2003 11:33:56 -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

I suspect, but cannot prove, that more applications 
will mean higher connectivity, as more boxes need
to get 'their' information.

- jeff parker

---

From: Jeff Parker <[email-masked]>
Date: Thu, 31 Jul 2003 11:33:56 -0400

- jeff parker

---

From: Jeff Parker <[email-masked]>
Date: Thu, 31 Jul 2003 15:07:23 -0400

> I don't think you can support this on a big-O analysis of 
> convergence.  Let me try to break it down.
...
> This might be about software engineering, or protocol aesthetics, but 
> I don't think it's about theoretical convergence properties.
> 
> --John

John -
	Thanks for the analysis: I spoke rashly. 

	We now return to the discussion of protocol aesthetics,
already in progress.   

- jeff parker

---

From: Jeff Parker <[email-masked]>
Date: Thu, 31 Jul 2003 15:07:23 -0400

...

John -

- jeff parker