Subject: RP overloading: impact on routing SW

From: Alex Zinin <[email-masked]>
Date: Thu, 31 Jul 2003 00:29:45 -0700

Pedro wrote:
> Personally, i believe that this issue is being completly blown out of
> proportion.

It's ok to think so. The thing is however--sufficient number of people
indicated their concerns, and this has been happening for years. Both
sides need to talk and find common ground.

> I've not seen any evidence to suggest that adding VPN
> services, as we are discussing, has higher impact in routing software
> stability than to add any other type of functionality.
> I'd like to see people that believe otherwise put forward data that
> corroborates that view.

As far as routing SW stability is concerned, I think the concern is
not that this very VPN service will blow BGP up, but about the
increasing number of extensions we see in routing protocols, and while
we can't stop routing code from changing at all (I don't think anyone
disagrees that there are legitimate reasons to extend RPs), we should
seriously look at what is coming in, whether this belongs in routing,
and what we should do about this long term.

Robert wrote:
...
> If I have BGP free core, and I don't type by accident "router bgp ..." I
> don't really see a good reason to buy routers which do not support BGP
> just so I don't have it in the core. If I have IPv4 ASBRs and i am not
> keen on running on them 2547 just don't configure vpnv4 AF there. I am
> yet to see a one single case where new opaque to existing functionality
> code presence if not configured or enabled by user caused any trouble to
> anyone.
  
I have to say it's not that simple.

There are reasons (beyond required flash mem and DRAM size) for
existence of feature sets in SW of at least one major vendor. There
were also reasons why one major vendor had to maintain two code
trains--one with 2547, and another where SPs asked to please "don't
even think about touching BGP!"

Eric wrote:

Kurt>> What on  earth makes us think  that adding data to  be distributed and
Kurt>> processed  will not  have impact?   Or  make it  worse? Could  someone
Kurt>> enlighten me?
> 
> Let's look at two cases: 
> 
> 1. The new  data is going to be  distributed to the same set  of nodes which
>    currently speak BGP for the purpose of maintaining their Internet routing
>    tables.  
> 
>    Assuming that there is some necessity of distributing that new data, then
>    however one distributes  it, those nodes are going to  have to handle it.
>    Either they  have enough capacity for  it or they don't.   Using a second
>    protocol does not reduce the distribution or the capacity load. 
>
> 2. The  new data is distributed  to a different  set of nodes than  the ones
>    which currently speak  BGP for the purpose of  maintaining their Internet
>    routing tables. 
> 
>    In this case, the use of BGP by  the nodes which need the new data has no
>    impact  on the nodes  which use  BGP to  maintain their  Internet routing
>    tables. 
> 
> So in neither case do I see what this terrifying impact is. 

Eric, I think the concern is (the SP folks will correct me if I'm
wrong) that in both cases we have increased protocol and code
complexity which doesn't help their stability regardless of whether a
given SP uses the new features or not, and in case 1 there might be
potential interference between the distributed systems because of
resource contention at several levels: transport connections, queues,
mem bufs, etc.

Kurt wrote:
> The first thing that
> amazes me is that developers of various features _even want_ them to 
> use BGP

I'd say there's difference in opinions in those circles too.
However, as you correctly pointed out before--there's currently
no alternative now, so the choice is kind of obvious.

-- 
Alex
http://www.psg.com/~zinin/

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