Subject: Meta: routing protocol abuse

From: Alex Zinin <[email-masked]>
Date: Thu, 22 May 2003 18:56:06 -0700

Folks-

 /*
  * The topic is quite sensitive, so handle with care please. I know some
  * of you may have a conflict of interest given what your companies do,
  * so I'd like to explicitly ask you to take your vendor hat off and put
  * your IETF rtg-dir member hat on when you participate in this
  * discussion (no offense).
  */

 The discussion about appropriate and inappropriate applications of IP
 routing protocols has been going on for quite a while. The most
 noticeable outburst of it could be correlated with appearance of 2547
 ;), however, this is not what I'd like us to talk about now.

 I'd like to draw your attention to the following draft--
     draft-kompella-ppvpn-vpls-01.txt

 --which proposes to use BGP for VPLS (L2 VPN service) discovery and
 signaling. In particular, please pay attention to the way the
 semantics of the NLRI field have been changed (section 3.2.1), and to
 the fact the best path selection algorithm is not employed at all.
 These two facts--loss of any addressing semantics, and loss of best
 path selection--make me think that the proposed approach essentially
 transforms BGP into what I call a "universal transport system."

 There two questions here:

  1. Where is the line between appropriate and inappropriate use
     of routing protocols in general, and BGP in particular (there
     maybe different aspects between LS IGPs that have a pure
     transport/flooding component, and BGP whose info relaying
     behavior is tightly coupled with the best path selection algo.)

  2. Does the draft in question cross this line?

 Before this sort of discussion starts in public, I'd like to hear
 opinions (preferably with technical and architectural arguments)
 of the folk whose technical judgement I trust.

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

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 23 May 2003 20:17:11 +0200

Let me give you an outlook of possible outcomes I see rather than an
opinion.

> ;), however, this is not what I'd like us to talk about now.
this one's lost for sure.

> transforms BGP into what I call a "universal transport system."
yes, many more such approaches are around in different stages
(translation of E.164
fields in NLRIs and so on).

>     behavior is tightly coupled with the best path selection algo.)
There is no line IMHO, it's just a hues-of-grey-border, especially in IP.
Strictly speaking, something like BGP is a routing protocol which
means, it should answer the 'How do I get from A to B' question or even
stricter, in
ISO terms, it must involve relaying between layer-3 entities. That's the
theoretical
one and based on that, things like 2547 are a layer that needs its own
protocol
and things like L2 info have no business whatsoever in routing protocol
data.

The practical one is that vendors piggy-back lots of garb into routing
protocols that
have no business there since
it's the fastest way to ship features that involve anything that needs
reasonable amount
of quickly but loosely synchronized data and there is piles such stuff.
Moreover, building
partitioned, loosely synchronized, distributed databases is hard like
hell. So, Pedro's 'discussion'
on idr was basically euphemistically gold-platting these very facts by
some pseudo-philosophical
contortions. HOWEVER, this is vendor-reality and a good local solution
for the problem
space they are faced with or rather maybe, created for themselves
(insanely short
development cycles, feature creep, disregard for any S [stability,
scalability, security, ...]
in the first release). The ethics of IP, namely 'running code' have been
since long
modified into 'quick-and-dirty running code' and is used as excuse for
lack of a unifying
architecture that underlies today's IP-networking realities and their
variations. So, where
am I going with this rant ?  Well, vendor reality is that routing
protocols are being
force-fed anything they can bear and has the promise to generate revenue
and this
won't be changed anytime soon since engineering 'ethics' is gone since a
while and
IETF has no power whatever these days to stop anything major vendors are
doing
and deploying. In the short term, IETF can just hang on for the ride.
How to change
this situation is yes another topic and not one I want to touch here or
rather at all.

My advice as to the whole issue: IETF is a documenting and not a
defining body
since a while and directions you [or maybe whole IESG]
are trying to push it into (tightening specifications to
the point of over-specifying [and delaying documents ridiculously]
and an retrofited-'architecture' which however is not laid down
anywhere as I saw it) are not very promising IMHO and the vendor will
happilly
trot on. On a larger scale, two outcomes I envision possible: either IP
is the
combustion engine of networking
and it will hang on for next 100 years despite being smelly, inefficient
and ripe to
be displaced by better solutions and we will preserve this status-quo OR
the whole thing will flame out and end up
overridden by something small and elegant that will come out of the
dark. The 2nd
outcome would be unlikely BUT for the fact that technology is almost
weightless and
the daemon of 6-months-product-cycles made displacement of existing
solutions
much easier than in the case of combustion-engine-driven toys.

    so, just food for thought

    -- tony

---

From: Russ White <[email-masked]>
Date: Fri, 23 May 2003 21:54:30 -0400 (EDT)

So, my general feeling is that if it's related to routing, carrying it in a
routing protocol is fine. I've not looked at the ppvpn stuff close enough
to say one way or the other, but BGP has already drawn these lines rather
wide for us, as have other protocols, really. Tags for admin filtering,
like communities, and other policy information--this information isn't
really needed for finding a route to the destination, per se.

I'd probably draw the lines pretty wide, including policy and security
information, but I've not looked at the ppvpn stuff close enough to know if
I'd include that.

:-)

Russ

>  of the folk whose technical judgement I trust.

__________________________________
[email-masked] CCIE <>< Grace Alone

---

From: Alex Zinin <[email-masked]>
Date: Fri, 23 May 2003 19:04:56 -0700

Russ,

> information,

Agreed.

> but I've not looked at the ppvpn stuff close enough to know if
> I'd include that.

Could you look at it, pls?

Alex

---

From: Alex Zinin <[email-masked]>
Date: Fri, 23 May 2003 22:13:46 -0700

Tony,

> Let me give you an outlook of possible outcomes I see rather than an

Thanks, see below, pls.

> this one's lost for sure.

agreed

> There is no line IMHO, it's just a hues-of-grey-border, especially
> in IP. Strictly speaking, something like BGP is a routing protocol
> which means, it should answer the 'How do I get from A to B'
> question or even stricter, in ISO terms, it must involve relaying
> between layer-3 entities. That's the theoretical one and based on
> that, things like 2547 are a layer that needs its own protocol and
> things like L2 info have no business whatsoever in routing protocol
> data.

> The practical one is that vendors piggy-back lots of garb into
> routing protocols that have no business there since it's the fastest
> way to ship features that involve anything that needs reasonable
> amount of quickly but loosely synchronized data and there is piles
> such stuff. Moreover, building partitioned, loosely synchronized,
> distributed databases is hard like hell. So, Pedro's 'discussion' on
> idr was basically euphemistically gold-platting these very facts by
> some pseudo-philosophical contortions. HOWEVER, this is
> vendor-reality and a good local solution for the problem space they
> are faced with or rather maybe, created for themselves (insanely
> short development cycles, feature creep, disregard for any S
> [stability, scalability, security, ...] in the first release). The
> ethics of IP, namely 'running code' have been since long modified
> into 'quick-and-dirty running code' and is used as excuse for lack
> of a unifying architecture that underlies today's IP-networking
> realities and their variations. So, where am I going with this rant
> ? Well, vendor reality is that routing protocols are being force-fed
> anything they can bear and has the promise to generate revenue and
> this won't be changed anytime soon since engineering 'ethics' is
> gone since a while and

The above is an honest description of reality

> IETF has no power whatever these days to stop anything major vendors
> are doing and deploying. In the short term, IETF can just hang on
> for the ride. How to change this situation is yes another topic and
> not one I want to touch here or rather at all.

> defining body since a while and

Some questions:

 Q1: what should we do if someone brings a complete BS to a WG
     (let's say someone decided that TCP over ISIS was a cool thing
     to do) and says it's coded and possibly deployed?

 Q2: will the answer be different depending on whether the guy
     comes from a major vendor or from whoknowswhere.com?

> directions you [or maybe whole IESG] are trying to push it into
> (tightening specifications to the point of over-specifying [and
> delaying documents ridiculously] and an retrofited-'architecture'
> which however is not laid down anywhere as I saw it) are not very
> promising IMHO and the vendor will happilly trot on.

I'd say the direction is to avoid _under_specification, not to promote
over-specification. It would also seem as somewhat orthogonal topic,
but I am indeed interested in discussing this, so I'll start a
separate thread on this.

> On a larger scale, two outcomes I envision possible: either IP is
> the combustion engine of networking and it will hang on for next 100
> years despite being smelly, inefficient and ripe to be displaced by
> better solutions and we will preserve this status-quo OR the whole
> thing will flame out and end up overridden by something small and
> elegant that will come out of the dark. The 2nd outcome would be
> unlikely BUT for the fact that technology is almost weightless and
> solutions much easier than in the case of combustion-engine-driven
> toys.

>     so, just food for thought

Thanks again!
Alex

---

From: Tony Przygienda <[email-masked]>
Date: Sat, 24 May 2003 09:08:15 +0200

>>Let me give you an outlook of possible outcomes I see rather than an
sorry for the tannic truth ;-/ I'll be speaking in riddles again I fear.

>
>  
>
>
>  
>
>>... used as excuse for lack
ok

>     to do) and says it's coded and possibly deployed?
the moment somebody coded and deployed such a thing (given it's a major
vendor, whereas
I define major as someone with decent customer base that won't go
chapter 11 tommorow,
so it's a shifting target) it's too late. That's the trick. Ye shall
have your ear on the ground and
listen carefully before stuff shows up and influence it then. How ?
Well, command respect
by any of the organization managament approaches (a book on group
dynamics and
organizational behavior 101 may do the trick) and learn to put the right
people into right
places and pretty soon you'll know stuff before drafts show up. Then a
certain influence
can be taken.

If something shows up coded & deployed by major vendor, you only very,
very marginally
influence the outcome these days. Basically the 15secs attention span of
sillicon valley has
passed by then and changing the code is a major pain. You remember that
I'm sure.

If something is criminally stupid, then it should die by the virtue of
the process in any case,
however I observe that IETF in last couple years had only a sketchy
record on that one.
It's heretic to say here but in a sense I think that the ATM Forum
approach of voting was
doing a better job in producing good specs. However, good specs are not
necessarily
what makes the technology successfull I learned.

>but I am indeed interested in discussing this, so I'll start a
ok, I think we agree in principle here but in terms of tactics we
butt-head most of the times.

    -- tony

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 27 May 2003 11:09:03 -0400

>      draft-kompella-ppvpn-vpls-01.txt

Could someone tell me what draft the following reference is
supposed to refer to:

   [ 4] Kompella, K., et al, "MPLS-based Layer 2 VPNs", work in
        progress.

These drafts all seem to have the habit of referring to things
as "work in progress" without even a "draft-ietf-ppvpn-blah"

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 27 May 2003 11:32:28 -0400

> information, but I've not looked at the ppvpn stuff close enough to know if

I'm going to make it a point to try to read all of the current ppvpn
documents sometime this week along with trying to make progress
on the BGP MIB work. :-)

Without having read the supporting documents, here are some
observations.

1. We're distributing stuff in BGP that is *useful* to distribute in
   bgp.  Namely, this is stuff that allows us to do inter-domain
   binding of VPLS networks.
2. We're using extended communities for this stuff again.  Given
   their "optional" status and the knobs for tweaking them are
   pretty broad, it introduces some fragility into anything that
   uses them, but this is a broad argument and should be considered
   secondary.
3. We aren't passing around things that are IP reachability.  However,
   we're passing around stuff that is associated with VPN reachability
   as defined by route distinguishers.  Essentially, we seem to be
   doing the equivalent of "foreign key" work in sql.  Its not
   directly associated, but is one step away.

   BGP cares about its best-path rules a bunch.  Anything that goes
   in NLRI should care about it.  This looks like it might not.
   (Again, I need to read the rest of the dox.)
4. The presence of TLV's in the NLRI is problematic.  I don't know 
   all of what is supposed to be there, but traditionally an NLRI
   is meant to convey "this *thing* is reachable".  Even in 2547,
   the "thing" is a NLRI bound with a RD and label stack to reach
   that end-thing.  The fact that the BGP Nexthop is used in 2547
   to derive the LSP to reach the end-thing that is transmitted in the
   NLRI successfully leverages things and using extended communities
   for VPN membership makes sense.  (The lack of useful documentation
   on how aggregation of extended community attributes in some situations
   seems like an interoperability accident waiting to happen, but the 
   authors don't seem to care.)

   The one thing that is immediately referenced in the document that
   I've read (draft-kompella-ppvpn-vpls-02) is the relearn sequence
   number.  This *immediately* implies an amount of churn that has
   very little to do with an "end-point thing" and is a property of
   it.  Traditionally, that belongs in the BGP path attributes.  I'm
   now wondering what else is being put in there.

I have a gut reaction as to how "things should look", but I want to 
see the other dox before getting too preachy.

-- 
Jeff Haas 
NextHop Technologies

---

From: Alex Zinin <[email-masked]>
Date: Tue, 27 May 2003 10:45:03 -0700

Jeff,

 I'm pretty sure it is the following draft:
 http://www.ietf.org/internet-drafts/draft-kompella-ppvpn-l2vpn-03.txt

---

From: Alex Zinin <[email-masked]>
Date: Tue, 27 May 2003 12:43:31 -0700

Tony,

> sorry for the tannic truth ;-/ I'll be speaking in riddles again I fear.

I appreciate you being honest, really.

> the moment somebody coded and deployed such a thing (given it's a
> major vendor, whereas I define major as someone with decent customer
> base that won't go chapter 11 tommorow, so it's a shifting target)
> it's too late. That's the trick.

Agreed that it is too late to (at least) usefully influence their code
and its deployment. At that moment the IETF process also becomes quite
painful, because the vendor will have a deep vested interest in that
mechanism. At that point I see a couple potential outcomes:

 1. The mechanism is considered by the WG as generally good,
    gets accepted with [possibly] minor tweaks, and goes STD track.
    No questions here.

 2. The WG believes the problem needs to be solved, but there is
    a strong push back on the actual solution. A question here:

    Does it make sense for the WG to say "well, ok, you guys did
    your job, publish it as INFO so folks can work with you if
    needed, but let's work on the IETF STD spec where the WG
    will decide what's good",

    in other words, does "coded & deployed" mean it's too late
    for the IETF to work on this problem?

 3. The WG is not interested in solving the problem.
    The proposal may again go INFO (assuming it documents a vendor's
    approach).

> Ye shall have your ear on the ground and listen carefully before
> stuff shows up and influence it then. How ? Well, command respect by
> any of the organization managament approaches (a book on group
> dynamics and organizational behavior 101 may do the trick) and learn
> to put the right people into right places and pretty soon you'll
> know stuff before drafts show up. Then a certain influence can be
> taken.

Agree completely. Good that you formulated this.

They way I put it when I talk to WG chairs is "you should keep
your eyes open and ears clean to make sure you know what folks
want to do and that the right people talk to each other even
before stuff comes to the WG."

> If something shows up coded & deployed by major vendor, you only
> very, very marginally influence the outcome these days. Basically
> the 15secs attention span of sillicon valley has passed by then and
> changing the code is a major pain. You remember that I'm sure.

> If something is criminally stupid, then it should die by the virtue
> of the process in any case,

Do you mean the IETF process? Which part of it?

> record on that one. It's heretic to say here but in a sense I think
> that the ATM Forum approach of voting was doing a better job in
> producing good specs. However, good specs are not necessarily what
> makes the technology successfull I learned.

> butt-head most of the times.

Looks like we're converging...

Alex

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 27 May 2003 16:06:11 -0400

> mechanism. At that point I see a couple potential outcomes:

And really the only question comes of when its an existing mechanism
that is being hijacked/overloaded.  Then its up to whoever the
custodian of that thing, whether it be protocol or routing protocol,
to deal with it.

Especially when its the big companies that do this.

It argues to have spaces in our protocols for vendor-specific
extension mechanisms, but it also argues to *not* have them there
so that something that is vendor-specific but well-deployed doesn't
sit in a funny spot in the protocol.

All said and done, anything that is a well thought out and scalable
extension to a routing protocol, no matter how clunky it "feels",
is probably ok so long as it doesn't hamper other potential later
extensions to a protocol.  But it will take people *talking* to
figure that out.

Preferably before you have product that you can't change without
huge compatability problems.

-- 
Jeff Haas 
NextHop Technologies

---

From: Alex Zinin <[email-masked]>
Date: Wed, 28 May 2003 00:41:38 -0700

> that is being hijacked/overloaded.

Not sure if I got it right--do you mean this is not applicable
to a situation where a new protocol is being developed?

> Then its up to whoever the

Do you mean an IETF WG or a vendor who "feels" like owning the
protocol for whatever reason?

> extension mechanisms,

What do you see as arguments for this?

> but it also argues to *not* have them there

So we had this discussion in the IESG and the feeling was that
vendor-specific extensions, in the form of legitimate,
non-experimental (i.e., not for lab-only use) mechanisms are rather
problematic. The IETF don't get to review the specs, we don't see
changes in security and protocol characteristics, etc. and the SPs
can't make an informed decision.

> extensions to a protocol.  But it will take people *talking* to

Should an extension be "routing-related" or just any?
I.e., if I come up with a well thought out proposal to distribute
DNS records in BGP, would that be good?

Alex

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 28 May 2003 07:04:36 -0400

> to a situation where a new protocol is being developed?

Lets put it this way:

If its a completely new protocol, let them do whatever they want.
If it succeeds wildly, document it informationally so people can
make compatibile implementations.  The process of documenting it is
enough to start shaking out interoperability issues and a second version
of the protocol may fix brokenness in the first version.

However, if its something that is overloading an existing mechanism,
then there are people who already care.

I'll be blunt here:  No one would care about what is being done with
VPLS or rfc2547 vpns if it didn't sit on top of BGP.  Sure, *we* would
since we're trying to help you as AD Get Things Done Right, but it 
wouldn't matter *in the same way*.

What I see a bit of here is that BGP is an IETF protocol and thus is
"owned" by the IETF community.  However, it is also "owned" by the
IDR working group, and these things that seem "unclean" about it are
happening outside of IDR.  Hence, there is some feeling of protocol
hijack by another WG.

The fact that one of the hijacking parties is Ye Ancient and Venerable
(he'll kill me next IDR session I'm sure) author and editor of the
specification in question doesn't change the fact that the WG feels
some ownership over it.

Then again, I may be channeling my own feelings in the matter and not
those of the WG.

Regardless of those feelings of hijack, this is the IETF.  We can
resolve the process issues at some later date or concurrently, but the
real question for now, at least with regard to VPLS, is does this
stuff make sense within the context of the protocol?

Pedro made some interesting arguments to me privately.  I need to 
digest them a bit.

> What do you see as arguments for this?

If you're going to hijack, here's a private space to go off and do
so without necessarily dragging the entire WG to hell with you.
If your hell is pleasantly warm and we want to implement it too...

> problematic.

Ya think? :-)

> Should an extension be "routing-related" or just any?

It depends on what it sits on.  Thus, the argument is situational.

> DNS records in BGP, would that be good?

Or policy data in DNS?

As I griped in IDR a while back, now I know how the DNS group feels
about having its mechanisms hijacked.

-- 
Jeff Haas 
NextHop Technologies

---

From: Alex Zinin <[email-masked]>
Date: Wed, 28 May 2003 09:58:04 -0700

Jeff-

Thanks for being direct, this is what I'd like our conversations
here to be. See below, pls.

> of the protocol may fix brokenness in the first version.

Unless, of course, there is an interest within the IETF community
sufficient to start an WG, where the protocol would be developed.
In this case the spec would be sent to STD track

Agreed.

> wouldn't matter *in the same way*.

Agreed

> happening outside of IDR.  Hence, there is some feeling of protocol

Agreed. In fact recently I've been pushing for making sure that
protocol-specific mechanisms are owned by the protocol-specific
WGs, and one of the things I was going to do is bring this document
to IDR.

What is still a question to me is the 2547bis spec. Essentially
it also changes BGP. The right way would be to take that piece
out of the spec and bring to IDR, but it has the potential of
substantially delaying the spec and will be perceived as an attempt
to stall this work, so I am leaning towards asking IDR to review
the spec, but leaving it in PPVPN, with the caveat that this will
be considered as an exception, not the rule...

> specification in question doesn't change the fact that the WG feels

Exactly.

> Then again, I may be channeling my own feelings in the matter and not

No, I think you are not the only one who has this feeling.

> Pedro made some interesting arguments to me privately.  I need to 

OK, would be interesting to see what you think.

...

> about having its mechanisms hijacked.

At least here we have an opportunity to get it right (I mean
bring it to the right WG).

Alex

---

From: mike shand <[email-masked]>
Date: Thu, 29 May 2003 14:26:28 +0100

Alex,
         I'm going to answer this mostly in the context of IS-IS, since I 
have a stronger emotional attachment to that protocol:-)

1. Should a routing protocol be used as a general purpose reliable 
multicast transport system? Absolutely not, for two reasons.

a) The routing protocol is designed to accommodate a certain volume of 
"database" traffic, and we are already in many cases pushing the scaling 
boundaries with genuine routing related data. Allowing the addition of 
unbounded and uncontrolled additional data (especially if the frequency of 
change is uncontrolled) could easily cause a breakdown of the routing 
infrastructure.

b) The routing protocols are designed to operate "a priori", without any 
assistance from any other information. If you already have reasonably 
correct routing information, then it is possible to design "reliable 
multicast" systems which are much more efficient than those used by most 
routing protocols.

2. Where is the line between appropriate and inappropriate use?

I would say that anything which was related to the computation of routing 
information (i.e. that is used to influence the FIB) is fair game, BUT (and 
note the shouting), it MUST be subject to analysis to show that the volume 
and frequency of the information will stay within reasonable bounds. It is 
easy to design bad routing protocols which don't scale and this mustn't be 
taken as carte blanche to allow anyone to do so.

However, I accept that certain other information which is "related" to 
routing information, while it may not strictly be used to compute routes, 
is nevertheless better carried along with the routing information than 
elsewhere (especially if there are some synchronization issues involved).

So like others, I don't think there can be a hard and fast rule. We already 
have instances where we have gone well beyond a strict interpretation, and 
I don't think we do any good by trying to reign these in. I think it has to 
be a case by case analysis, but in the case of obviously non-routing 
related usage, the onus is on the proposer to show:-

a) why the use of a routing protocol is appropriate (and by inference, why 
some other mechanism isn't), and
b) why this use cannot break the routing protocol.

One possible (but rather unpalatable) work around to (b) would be to use a 
separate instance of the "routing protocol" isolated from the "real" route 
bearing one.

3. So what about adding 1 byte of information per router which changes only 
every year and has nothing to do with routing but would be really useful 
for something else?

This is the difficult one. The temptation is strong, and the argument that 
it could cause any problems is hard to defend, but in an ideal world I 
would still say "don't do it". Pragmatism may dictate otherwise.

4. What about proprietary extensions?

People will always make proprietary extensions for experimental purposes. 
Nothing will stop that. Historically we just choose an "unused" code point. 
e.g. 42 :-)

Theoretically we may run into problems with two different vendors choosing 
the same number for unrelated extensions. Has this ever happened? I don't 
think so. Is it likely? Not very. Is it the end of the world if it does? 
You shouldn't really be running two different vendors' experimental code in 
your production network!

Would "official" vendor specific extensions help? Marginal.

But in any case, such extensions MUST NOT be considered "blessed" by the wg 
until they have been subject to a reviewed draft which MUST use "real" code 
points assigned by IANA (or in the case of ISIS whatever workaround we have 
in place).

         My personal 2c.

                 Mike

>===8<===========End of original message text===========

---

From: Alex Zinin <[email-masked]>
Date: Thu, 29 May 2003 15:59:38 -0700

Mike,

Thanks a lot for your thoughts! See below, please.

> multicast transport system? Absolutely not, for two reasons.

Agreed on all points.

Agreed

> elsewhere (especially if there are some synchronization issues involved).

Agreed. MPLS TE attributes, strictly not needed for IP routing, would
be a good example, I think.

> b) why this use cannot break the routing protocol.

I like that. So, though we are not drawing a single line, we can
identify three possible areas and associate actions with them:

  1. Clearly routing-related: fair, but with due analysis by the
     right people (read: has to be done in appropriate IETF WGs)
     
  2. Clearly non-routing related: Ouch! Please go to the appropriate
     WG and explain:
     
       a) what other alternatives you considered, and
          why you think using a routing protocol is appropriate
          and is the best choice here

       b) why is this not going to break the protocol and
          a routing domain

  3. Not clear: Hmmm... go to the WG and see what people say

One relevant point here is whether the mechanism in case 2 should be
asked to become a WG document in the responsible WG, and what happens
if the WG doesn't agree to take it. My opinion is that the default
mode is that all protocol-specific mechanisms belong the
protocol-specific WG. If the WG does not want to take it for technical
reasons ("this smells") the proposal should be dumped. If the WG is
technically OK, but does not want to put this on the charter, it's ok
for WGs like PPVPN to host such work )provided that cross-reviews and
mutual LCs are done).
  
> separate instance of the "routing protocol" isolated from the "real" route 

You got right to the point.

This is exactly the argument that guys overloading BGP bring (though
don't always specify). What is happening essentially is that BGP is
transformed into a separate protocol, with completely different goals,
though sharing message formats, neighbor machinery, and (clearly)
the code. The argument is that INET-BGP sessions and blah-BGP sessions
could be different. In fact, the two distributed systems would be
separate.

How do we deal with these cases?

Thanks.

Alex

---

From: Russ White <[email-masked]>
Date: Mon, 9 Jun 2003 07:51:38 -0400 (Eastern Daylight Time)

So.... I don't see it as any different that what's been used for OSPF, or
eben EIGRP at this point, so I don't see any problem with carrying this
information in BGP. I do, however, think the draft itself is a disaster. If
this were to be presented, I'd insist it be rewritten in some form that
people can actually understand. I've made some notes, but it's almost not
even worth putting them on paper.

Solutions are mentioned that weren't described, the grammer leaves me
wondering what the author is talking about. The actual solution comprises
three paragraphs or so, mostly just saying: "Do this like OSPF." It doesn't
give any real details.

In principle the concept is fine, I think. In implementation, the draft
isn't.

:-)

Russ

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 9 Jun 2003 12:29:14 -0400

Warning: Lots of opinion follows.

>      draft-kompella-ppvpn-vpls-01.txt

As Russ mentioned, this document needs some cleanup.

However, the document draft-kompella-ppvpn-l2vpn-03.txt is very well
written and seems to do a nice job of summarizing the benefits and
the problems of its features.

Unfortunatley, I can't find the document referred to by as:
"MPLS-based Layer 2 VPNs".  The complete lack of draft ID's in
the references makes it incredibly hard to trace these issues if
you don't follow things on a regular basis.

>  the fact the best path selection algorithm is not employed at all.

To address these particular points:
o I find the overloading of the NLRI field in these documents to be
  slightly problematic - but only slightly.  

  The NLRI field has been traditionally used to bind network layer
  reachability (go figure) and a set of path attributes together.

  In 2547, we extend this to include a route distinguisher and a
  MPLS label stack.  While this blurs the idea of "network layer"
  it is still consistent with enumerating reachability (and really
  extending it by allowing for multiple overlapping address/naming spaces).
  The fact that the label stack is included in the NLRI is, at first
  glance, a bit kinky.  Traditionally, this sort of information has
  been encoded in the path attributes.  The important difference here
  is that this information is generally applicable on a PER-PREFIX
  basis.  In other words, were we to not bind it at the NLRI point,
  we'd be generating a ton of BGP PDU's in order to encode the same
  information.  Thus, uncleanness aside, this is mostly optimal
  for the application.

  I'll note that a cleaner method would have been to have some
  mechanism which clearly states the keying portion of the NLRI
  and the additional properties.  Right now, this is done by
  knowing how to decode a particular AFI/SAFI.

  In draft-kompella-ppvpn-vpls-01 and draft-kompella-ppvpn-l2vpn-03,
  we go a step further than this.  We are no longer passing network
  layer reachability, we are passing completely non-IP information.
  However, we are still passing entities that serve as endpoints, some
  of it being "keying" information, some of it things that are bound
  on a per-key basis.  Thus, the 2547 analogy still holds.

  What at first glance appears "gross/ugly", the TLVs in the NLRI,
  actually formailzes what we're doing: Making the binding of per-"prefix"
  or per-"key" information explicit.

  While I, and several others including Pedro, find this practice
  unsightly, the representation makes sense.  Its no longer IP, but
  it still makes sense.

o Best path selection not used
  
  I dug around pretty hard to find out where this is stated.  It really
  isn't.  I thought about "well, if it isn't used, what are the implications?"

  In the intra-domain case, we could (as a contrived for-example) dispense
  with passing things around in BGP and move to a method by which the
  information is flooded in the traditional sense, perhaps using a
  reliable multicast mechanism.  However, we know that this information
  is meant to be able to be used in the inter-domain case.  So, what
  does this mean?

  It means that policy is intended to be exercised in connecting the
  tunnel endpoints.  Pedro specifically pointed out some of the older
  issues that were a problem with various ATM overlay technologies.
  The lack of policy led to suboptimal usage of the network.

  In any case where a given "prefix" is advertised by more than one
  BGP speaker, we need the ability to choose which one we're going
  to want.  Default policy can serve here along with other BGP policy
  mechanisms.

  I'm still disturbed by the fact that normal policy mechanisms, such
  as extended communities, are used to distribute membership.
  Thus, misconfiguration of policy on extended communities is potentially
  hazardous to the correct operation of your VPN-fu.  This is a separate
  issue.

  So, default bgp path selection is used and seems appropriate.  If
  we were limiting advertisement of this information by only a single
  speaker of some sort, flooding would be quite appropriate and probably
  a *lot* less ugly.  However, there are good cases for wanting to use
  policy.

  Even with this said, perhaps a flooding mechanism would be nicer -
  one where some policy could be exercised.  This would be motivated by
  the fact that these routes are likely to be essentially identical once
  distributed into your iBGP and the BGP property of maintaining a copy
  in your Adj-Ribs-In for each speaker is potentially noisier than need
  be.  This is probably worth more general study and I'm aware that
  some companies are pursuing this already.

>      behavior is tightly coupled with the best path selection algo.)

Lets split the line even further:

What is suitable to carry in BGP as a protocol:  "reachability"
should go in the NLRI field.  It is probably ok to bind per-reachability
information there as well, but only if it is tightly bound.  "Tightly"
would imply something that is likely to be bound to the reachability
such that it is likely to poorly belong in the path attributes.

Additionally, given mechanisms such as WRD and the stability of
reachability, things shouldn't be placed in a BGP PDU that are
expected to wildly fluctuate.  Bits of BGP are very expensive to run
due to its general scaling properties.  MED election and policy, for
example, are "expensive" to run although less expensive than
running Dijkstra for a similar amount of information.
(Incremental updates in your protocol can be a big friend in scaling.)

This point trends to the other half of the line - operational issues
and scaling:
Just because things can be encoded well in the protocol, doesn't mean
that the entire protocol infrastructure is going to be able to put
up with the relative load.  We currently pass everything from peer to
peer over a single TCP session multiplexing the PDU's for our various
AFI/SAFIs.

The implication of this is that while the cost of building BGP PDU's
and putting them onto your TCP stream is relatively low, it means
that you must be *very* careful to balance your priorities.  BGP was
designed to carry inter-domain reachability.  For every application
that we layer on BGP, we must preserve the ability of a box to
keep up with its Internet reachability since the convergence of the
entire routing system is dependent on its component parts.

My concern, shared by others, is that by putting all of this extra
stuff in the protocol, we are potentially harming the scalability
of the Internet routing system.  This is not to say that knowledgable
design choices can't make things work, but these choices are hard
to get right.

My gut instinct is that moving stuff that uses the BGP protocol but
isn't used for Internet transport off to a separate protocol instance
and transport session, but that simplistically assumes that it is
"that easy" to separate the guts of the pieces in the box for something
that consumes so many resources.  But there's the general idea - make
sure that you've built things so you don't hurt the Internet - and
then make your value-add services work.

>   2. Does the draft in question cross this line?

The only bit I find seriously questionable is the RSN TLV.  It seems
like something that is likely to cause excess flapping.  It would
take someone describing how it behaves in the field for us to know
for sure.

One final note:
While reading through these drafts, it was clear that the MP-Nexthop
field in the Kompella drafts wasn't properly documented.  It has been
my general assumption that the MP-Nexthop would always be of the same
form as the NLRI for an AFI/SAFI.  In this case, the NLRI contains no
IP information, which is necessary to derive the tunnel end-point.

RFC2858 doesn't say that this happens at all, it is left ambiguous.
The Kompella documents need to spell out what their nexthop looks like
and how it is used.

-- 
Jeff Haas 
NextHop Technologies

---

From: Alex Zinin <[email-masked]>
Date: Wed, 11 Jun 2003 02:23:05 -0400

Jeff, Russ-

 Thanks for your thoughts. I did read them and will
 follow up within a couple of days--traveling now.

Alex