Subject: Re: Who speaks for whom [was: Re: Open Routing Area meeting in Vienna]

From: Yakov Rekhter <[email-masked]>
Date: Wed, 06 Aug 2003 07:00:40 -0700

Danny,

[clipped...]

> On the topic of RP overloading...
>
> There are [some] very real problems folks are attempting to address and
> given MP-BGP & BGP-CAP, BGP has been the easy answer.  Heck, with IGP
> Capabilities being defined we'll be able to do more things even faster
> (although I'm kidding, be wary :-)

The discussion should certainly include extensions to ISIS, like
carrying both IPv4 and IPv6 unicast routing, IPv4 unicast routes
used by IPv4 multicast, IPv6 unicast routes used by IPv6 multicast,
using  ISIS Extensions for BGP Peer Discovery, using ISIS flooding
procedures to carry TE information.

With this in mind I'd like to hear from the folks who argue against
adding more stuff in BGP whether they also object against adding
more stuff into ISIS.

Yakov.

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

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 06 Aug 2003 07:00:40 -0700

Danny,

[clipped...]

Yakov.

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 6 Aug 2003 11:05:14 -0400

> adding more stuff in BGP whether they also object against adding

As I think I've mentioned before, I think we each have reactions
much like the DNS folk who continually find stuff being shoved
into their working infrastructure.  

(not specifically to Yakov)
Is there any way we can just frame this conversation as "how do we
keep from breaking things when we're working on extended them"?

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 6 Aug 2003 11:05:14 -0400

-- 
Jeff Haas 
NextHop Technologies

---

From: Alex Zinin <[email-masked]>
Date: Thu, 7 Aug 2003 18:18:44 -0700

> adding more stuff in BGP whether they also object against adding

ISIS and OSPF are certainly within the discussion.

On the other hand, I believe it was emphasized enough on the list that
the concern is largely about adding non-routing related info on RPs. I
think there is a good level of understanding that RPs will have new
features and extensions, but there is a desire to limit this to
routing-related applications as opposed to whatever human imagination
can come up with.

> keep from breaking things when we're working on extended them"?

I don;t think so. "What should be put in a protocol" is also an
important question in this discussion.

Wednesday, August 6, 2003, 10:17:06 AM, Tony Li wrote:
> That's an excellent point and perhaps the question that should have
> been asked instead.  The entire issue was initiated improperly by
> assuming the answer.

Far from that (assuming you mean another protocol). It is one of the
possible directions, and there's nothing wrong in discussing those.

Wednesday, August 6, 2003, 11:35:27 AM, Jeffrey Haas wrote:
...
> That might be the right action.  However, I think Alex (wearing his AD
> hat) is trying to get us to tackle the general issue.  BGP just
> happens to be the thing where the problem is most obvious.

Correct. There's a general issue of routing protocol overloading
(i.e., what is the right stuff to put on a routing protocol?) and
a more specific issue of MP-BGP. Expected outcome of the discussion
is the overall direction and very specific action items for design
teams and protocol-specific WGs.

Alex

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 7 Aug 2003 21:30:11 -0400

>important question in this discussion.

You're saying that "what should be put in a protocol" is an important 
question regardless of whether said extensions are demonstrably 
harmless?

It's very difficult to read this any other way.  Personally, I 
thought Jeff's formulation was very good.

N.b. I'm not saying anyone HAS demonstrated that <foo> is harmless. 
I am saying that your statement indicates that you're not interested 
in that question.

--John

---

From: Alex Zinin <[email-masked]>
Date: Thu, 7 Aug 2003 18:18:44 -0700

Alex

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 7 Aug 2003 21:30:11 -0400

--John

---

From: Danny McPherson <[email-masked]>
Date: Thu, 7 Aug 2003 22:51:26 -0600

> ISIS and OSPF are certainly within the discussion.

And for many of the same reasons (i.e., IGP instabilities can
trigger BGP instability, and subsequently, global instabilities,
which are largely what some folks seem to _only be concerned
with).

For example, IGP adjacency state changes trigger new BGP
updates per IGP-derived MED values, subsequently triggering
new paths selected by adjacent routing domains, and so forth,
resulting in convergence issues and a domino effect for
downstream ASes.

I think to address the issue generically is best (e.g., to determine
what encompasses "routing information").

-danny

---

From: Danny McPherson <[email-masked]>
Date: Thu, 7 Aug 2003 22:51:26 -0600

-danny

---

From: Alex Zinin <[email-masked]>
Date: Thu, 7 Aug 2003 23:50:45 -0700

John,

 Let's first make sure we don't interpret Jeff's words differently.

 What I meant is that not breaking while extending may be read as
 "without really thinking much _what_ extensions we put in, let's
 ensure we don't break the thing". While this is necessary, I don't
 think it's enough.

 I believe we should be asking ourselves questions whether <foo>
 belongs in a protocol, and add it only if we believe it does and, as
 you say, it is demonstrably harmless.

 Are we on the same page?

Alex

---

From: Alex Zinin <[email-masked]>
Date: Thu, 7 Aug 2003 23:50:45 -0700

John,

 Are we on the same page?

Alex

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 8 Aug 2003 09:53:29 -0400

[reordering]

>  you say, it is demonstrably harmless.

There's "harmless" and "harmless".

The more state you need to keep and transmit, the more copies of
something BGP is going to get.  If <foo> is suitable to be
modified on a hop-by-hop basis then it is posibly suitable to be put
into BGP.  However, putting more and more in means that the
routers have more to transmit, keep state on, do path calculations
for, etc.

The fact that we have this grand knob for AFI/SAFI's means that
so long as we don't put stuff in that makes things *mandatory*
for the protocol to scale, we can put stuff in the protocol and
let the network operators decide how far their dollars will go
in putting enough hardware in place to handle it.

VPLS made me think for a bit since many cases seem to be more suited
to a flooding-style protocol.  The key that Pedro gave me to grok
why BGP makes more sense is the fact that *policy* is applied.

If we had something that did policy on flooded information, it
might make more sense to not use BGP.  Unfortunately, then we
have to deal with the inter-domain case.

Similar "harmless" issues haunt IGP's.  If you stick something into
the LSDB, it's going to take up memory whether you use it or not.
Since the database calculation is distributed rather than by rumor,
this means that you simply need one box in an important spot to
get too much information, run out of memory and crash and your
network is very unhappy.

While this isn't quite as bad as flooding your BGP into your OSPF,
it can be a close second.

[...]
>  ensure we don't break the thing". While this is necessary, I don't

"He who breaks a thing to understand what it is, has left the paths
of wisdom." :-)

-- 
Jeff Haas 
NextHop Technologies

---

From: Eric Rosen <[email-masked]>
Date: Fri, 08 Aug 2003 10:13:39 -0400

Alex>  I  believe we  should  be asking  ourselves  questions whether  <foo>
Alex>  belongs in a protocol, and add it  only if we believe it does and, as
Alex>  you say, it is demonstrably harmless. 

I don't think "belongs in a protocol" is a technical term. 

I think  we can ask whether the  distribution requirements of foo  are a good
match for  the protocol, we can ask  whether putting foo in  the protocol is
cost  effective when  compared to  the alternatives,  we can  ask  whether a
proposed extension breaks some assumption  of the protocol or whether it has
some unintended side-effects, etc.  Once we've answered all those questions,
it doesn't make much sense to then ask "but does it belong?" 

Alex> the concern is largely about adding non-routing related info on RPs

On the  issue of fate sharing,  the issue is not  "routing vs. non-routing",
but one address family vs. another.   Why are people so quick to accept that
it's okay to lose your IPv4 routing if you have IPv6 problems? 

In BGP, it is possible  to further distinguish between address families that
require the  information to  be run through  a routing decision  process and
address families  that do not.  This is  one way of drawing  the routing vs.
non-routing distinction,  and separates out the extensions  that are focused
on L2VPN from the extensions that  really carry address prefixes of one sort
or another.  To  justify adding these sorts of extension to  BGP, one has to
think of BGP  as itself layered into a distribution  protocol and a decision
process layered above  it; these sorts of extensions  reuse the distribution
protocol but layer different  "decision processes" above it.  Some technical
concerns have  been expressed  about this, but  the "soft  notification" and
"separate session" ideas seem to address these.

---

From: Eric Rosen <[email-masked]>
Date: Fri, 08 Aug 2003 10:13:39 -0400

---

From: Jeffrey Haas <[email-masked]>
Date: Fri, 8 Aug 2003 09:53:29 -0400

[reordering]

[...]

-- 
Jeff Haas 
NextHop Technologies

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 11 Aug 2003 08:12:43 -0700

Alex,

> ISIS and OSPF are certainly within the discussion.

Seems like we have an agreement on this...

> routing-related applications as opposed to whatever human imagination

Are we talking about theory or practice ? If the latter, then please
provide few examples where vendors addition to RPs are based on
"whatever human imagination can come up with", and not on the need
to solve *practical* problems of their customers.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 11 Aug 2003 08:12:43 -0700

Alex,

Yakov.