Subject: RP overloading: operational feedback

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

OK, in this thread, I'm going to drop proxy statements a la "I am
being told...", and bring the main points of the operational feedback
I've seen on the list.

Regarding the role of the operational feedback in this discussion...
Each problem we address here will have several dimensions. Examples
are scalability, stability, backwards compatibility, security.
Operational considerations represent another dimension. We have to
recognize and clearly realize that. Just like SEC people give us clue
on what does and does not make sense security-wise, OPS people give us
their view of the world, and we ought to take it into consideration.
At the end, they are the consumers of whatever we produce here.

In order of appearance, grouped by the author, compacted:

Randy said:
> ...it is scarily not appropriate to characterize bgp as
>> the architecture of a given city is good, communication is
>> perfect and can scale

Tulip Rasputin wrote:

> BGP is critical for the Internet...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... the
> fact remains that by doing this we make BGP more and more vulnerable
> than what it already is.

Kurt said:
> The SPs that went to
> the mike said they didn't see the benefit of overloading BGP with all 
> this. Or any other routing protocol.

>  From the SP POV this is about operational stability. Not about software
> engineering.

> What are the facts that we need to put everything into BGP? And where
> do we stop?

> I think one of the problems with BGP is that it has lured into this "as
> there is nothing better, let's put it all in there". To be honest I 
> think that the reason that you are seeing customers being perfectly 
> happy to put various features into BGP is not that they don't see a 
> problem with it. They don't think there is an alternative.

> I would say that the problem we are having now is the opposite. In
> order to solve a software problem, people are trying to add things to a 
> protocol.

Geoff said:

> Keeping the network vaguely stable at it's current size
> is taking increasingly large amounts of manual effort, and no, this
> cannot scale indefinitely.
> 
> There _are_ problems in BGP deployments, and overloading the running
> instance of the protocol to carry more information related to various overlay
> signalling applications does not in itself assist in improving the situation.
> For me its a counter-intuitive action that increases the level of operational
> reliance on a single element of the network.

Dorian said:

> I wonder how many other operators started out with
> a strong stance against overloading of BGP, and after years ...just gave up
> I certainly have. As an operator stability and optimal performance of
> BGP implementations are of upmost concern for me, and there was a time
> that many others appeared to feel the same. Afterall, MSDP didn't end
> up in BGP and became a separate protocol because of that concern.

> However, since then I've seen vendors continually ignore our concern
> and input and overload other features into BGP. 

> So, is it really that operators all want to pile everything on BGP, or
> is it that they don't see any alternatives?

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

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