Subject: re: On BGP and VPLS

From: Mark Seery <[email-masked]>
Date: Sat, 3 May 2003 00:32:28 -0700 (PDT)

Alex,

I think your instinct about engaging sooner rather
than later, is correct. Some questions for you:

There are (at least) two very distinct environments
that VPLS is targeted at. There is of course the case
of a stand-alone ISP for which an "optimal solution
could be provided". There is also the case of complex
orgainzations that have an ISP that might be already
offering L3VPN and be very comfortable with BGP4
technology, and perhaps not already using LDP, and now
wants to add VPLS. This is very different from the
organization that wants to build a new network with
VPLS as the initial offering, and wants to maintain
characteristics of other layer 2 services offered
within that organization (perhaps a NAP is yet another
unique environment). Is it permissable in your eyes to
pursue different solutions for these different types
of groups, or is one solution what you would steer the
group towards? 

Is operational comfort with an approach to networking
a sufficient justification for an approach? For
example, if an organization is more comfortable with
p2p, from a variety of OAM, billing, and work
procedure perspectives, is that sufficient
justification for that approach, even though it is
arguably less bandwidth efficient? Is a higher
standard required? 

In section 2. you raise the important issue of load on
the receiver due to the reception of the same
information more than once. Does this ever occur in
standard IP/BGP networks?

In section 3. you raise the important attribute of
scaling - summarization. Would you agree that all
inter-domain proposals should address this issue? 

Also with respect to summarization, is the inability
to summarize a function of the proposal in question,
or a function of the fact that Ethernet does not have
a summarizable address plane/structure (in L3VPNs even
though a VPN idenitifer is required IP prefixes are
still basically being used - I believe?). So without a
good address plane for scalable networking, we are
left with signaling names: VE IDs, PE IDs, VPLS IDs,
Group IDs etc. What we are really dealing with here is
members of a set, not subnetworks. Do we qualify these
names? Do we create relationships for sets, and
subsets,......Seems like this basic issue has to be
dealt with. So strangely enough, multicast (where PEs
in a VPLS are in the same multicast group) addresses
this issue very nicely - if we stick to the concept of
a LAN segment. If we continue to put more and more
bridging functionality within a PE, then I think
multicast is limited in its ability to address this
problem, i.e. how many members are there in each
multicast group when every PE is a bridge?

More generally, a number of people have suggested
inter-domain and intra-domain work/requirements be
separated - what are your thoughts on that issue? Do
you think there might be other important inter-domain
issues that should be considered? Is it fair to drill
down on one inter-domain issue until all the
requirements have been laid out?

WRT point 5. Coupling of VPLS and BGP SW. Is it your
assertion that any software implementation is going to
have the problem described in 5 b), or just that the
installed base of software would have this problem and
therefore that is sufficient reason to be concerned.

Lastly, the "L2PE" concept introduced in this proposal
is important I believe to maintain, as it allows for a
constructive separation of functionality allowing
routers as we know them today to be productively put
to work; so whatever the result of your particular
questions, it would be good to see this concept
preserved in some fashion.

Thanks,
Mark

---

From: Pedro Roque Marques <[email-masked]>
Date: Sat, 3 May 2003 01:53:39 -0700 (PDT)

Mark Seery writes:

> More generally, a number of people have suggested inter-domain and
> intra-domain work/requirements be separated - what are your thoughts
> on that issue? Do you think there might be other important
> inter-domain issues that should be considered? Is it fair to drill
> down on one inter-domain issue until all the requirements have been
> laid out?

Just a particular comment here...

The argument that was constructed to justify the separation of inter
and intra domain is one that imho is rather sketchy...

The assertion was that as IP routing uses inter and inter domain
protocols so should VPLS. The point that is missing in the argument is
that VPLS already does that by separating the signaling/routing of
PE-PE tunnels (LSPs) and 'forwarding designators' used for exterior
traffic (so called Private Wires in a particular view of the world).

The PE-PE LSP can be signaled using any mechanism: LDP, RSVP-TE,
labeled-BGP on ASBR/ASBR boundaries, etc.

In IP routing, exterior routes are not redistributed into IGPs (and
typically vice-versa: an aggregate route is advertised given the
presence of a more specific IGP route).

There are many reasons not to redistriute 'exterior' information into
IGPs but i would sumarize it as a separation of the task of learning
the internal SP topology vs the external topology.

In the case of VPNs, the external topology is the information about
customer attachement points (and routes for L3VPN).

Having distinct mechanisms for VPLS attachements that happen to belong
to your AS and those than do not, is not necessarly a good idea. There
is hardly any reason for a PE to know that for instance or have to
deal w/ 2 different mechanisms.

There may be other arguments to go that route but i don't think this
is a valid one.

It seems to me that the unstated argument, which may or may not be
valid, is that "at the moment i'm not terribly concerned about the
problem, lets get something working first".

However it ends up coming back to potential reasons why pick LDP over
BGP for signaling... the major technical advantage of a BGP based
solution is that BGP has mechanisms to distribute the information more
than one hop away.

My very personal opinion is that we cannot, at this point resolve this
as a tecnical issue. What ends up carrying more weight at this
particular point w/ those that are entitled to make the decision
(service providers) is mostly familiarity w/ the precursors of both
proposals.

This is actually a very reasonable position given that there is much
more required to deploy a workable solution than just what ends up
being described in this particular set of proposals.

My guess is that the issues that people that work for equipement
vendors have been focusing the most on on this particular discussion
are rather small concerns when it comes to actually deploy a
production network.  "How can i fit a solution in existing network
design and provisioning tools ?" may be a question more in the minds
of SPs...

This discussion started w/ the request to elevate both proposals to WG
document status... it seems to me that the circularity of the
discussion has proven that there is no strong argument to select one
proposal over the other at this point.

Personally, i believe that it would be best for the group to focus on
completly both solutions further. I am under the impression, perhaps
mistakenly, that there are few issues that have not been addressed.

I'm sure that as SP gain more experience w/ implementation of both
solutions that we will be able to discuss issues in less abstract
terms than P-t-P and MP-t-P signaling ;-)

thanks,
  Pedro.

---

From: Juha Heinanen <[email-masked]>
Date: Sat, 3 May 2003 12:22:00 +0300

> (service providers) is mostly familiarity w/ the precursors of both

i fully agree.  if iesg starts to weight solutions based on their
technical merit or purity, it makes itself irrelevant.  the "market" has
already decided (by the help of the big marketing muscle of major router
vendors) that bgp/mpls is a good way to implement vpns.  if some small
players like me don't like the idea of requiring bgp and mpls for vpns,
but would prefer a directory (radius) and ip based solution instead,
they don't have any chance to get their message through.  iesg is in the
same boat and it better shut up or loose its face.

-- juha

---

From: Mark Seery <[email-masked]>
Date: Sat, 3 May 2003 09:05:50 -0700 (PDT)

Pedro,

Thank you for your well thought out comments.

>> It seems to me that the unstated argument, which
may or may not be valid, is that "at the moment i'm
not terribly concerned about the problem, lets get
something working first". <<

This is indeed the unstated argument and a very
relevant one. There are SPs who are wishing to go
implement VPLS, and I suspect (very strongly) that
many of these SPs are no where near having to worry
about inter-domain issues. Which, IMO, is a strong
reason for removing the distraction of inter-domain
requirements from the debate, and allowing
intra-domain solution(s) to progress.

WRT to the thrust of your argument. You present
interesting view points. I would however suggest, that
unless a robust debate occurs on inter-domain
requirements, it can not be said with assurity that
there are none.

Mark

---

From: Alex Zinin <[email-masked]>
Date: Sat, 3 May 2003 18:23:22 -0700

Mark,

  Thanks for your message. You asked several questions
  that I think the WG should discuss, so what I'll do
  is take some of them to separate threads and answer
  the rest here.

  See below, please.

> of groups, or is one solution what you would steer the

I believe the goal for the WG should be to work out
a single solution.

Regarding the considerations you mention above, in my
opinion it would be wrong for us to start the discussion
by saying "SPs have X and Y deployed in their networks,
so we just have to decide whether we piggy-back on X or
on Y." Instead I'd like to see a discussion ala "What are
the functions we need? How can we best implement them?
Do we have an existing protocol that would be the right
fit for this functionality or do we need a new one(s)?"

> arguably less bandwidth efficient? Is a higher

I don't believe operational comfort alone is enough of
a justification. I think we need a technically strong
solution.

> standard IP/BGP networks?

Well, in the IP/BGP case, it is not necessarily the same info,
as path attributes are likely to be different and the BGP
speaker is interested in selecting the best among them while
preserving others as the back-up. In the VPLS case, we don't
need the best, just one copy is sufficient.

This is not necessarily an issue per se, rather an interesting
observation exposing the transport nature of this particular
proposed application of BGP. We have similar properties (more
than one copy received) in the flooding algorithm in IGPs, but
we admit that flooding is a transport component very specific
to IGPs (where every node needs all info, btw), and we don't
keep track of where we receive PDUs from as we do in BGP.

> inter-domain proposals should address this issue? 

I took this one to a separate thread.

> separated - what are your thoughts on that issue?

Same with this one.

> therefore that is sufficient reason to be concerned.

Installed base is definitely an important consideration.
However, I tend to look at this more broadly--putting VPLS
functionality in BGP increases the chances of interference.
Some consider this a strictly implementation-specific issue.
I think that whether or not VPLS-specific functionality is
sufficiently decoupled from base BGP is an implementation
aspect; while increased risk of interference is an architectural
one.

> preserved in some fashion.

I did not have comments on this particular part.

Thanks again.
Alex

---

From: Alex Zinin <[email-masked]>
Date: Sat, 3 May 2003 19:36:55 -0700

Juha,

 I think you might be confusing the IETF with the market. However,
 this discussion is well outside the scope of this WG, and if you'd
 like to continue it, I suggest we take it to the IETF problem
 statement mailing list ([email-masked]).

 So far, I am not shutting up and will continue steering the Internet
 engineering process.

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

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 05 May 2003 10:18:24 -0700

Alex,

[clipped...]

> I believe the goal for the WG should be to work out

That is certainly not in the charter. In fact the goal
you stated above directly contradicts what is in the charter:

   Multiple approaches are being developed as each approach 
   has particular characteristics and differing scope of applicability.

And if you believe that for VPLS the goal should be a single
solution, then why wouldn't you insist to have the same goal 
for L3 VPNs ?

Also, if you insist on a single solution, wouldn't that
imply a single auto-discovery mechanism for VPLS ?

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 05 May 2003 10:28:04 -0700

Alex,

>  I think you might be confusing the IETF with the market. However,

To avoid any confusion it would be very useful if you'll elaborate
on what is in your mind the relation between the IETF and the
market.

>  So far, I am not shutting up and will continue steering the Internet

One may ask whether that steering of the Internet engineering
process will make it less or more relevant to the market. Or whether
that question is relevant to the Internet engineering process in the 
first place.

Yakov.

---

From: Alex Zinin <[email-masked]>
Date: Mon, 5 May 2003 14:26:32 -0700

Yakov,

[I took the liberty to change the subject line]

>    has particular characteristics and differing scope of applicability.

Thanks for pointing out a possible contradiction. I don't think
it exists.

My opinion (and I think it would be safe for me to say it is
consistent with that of the IESG) is that as long as different
solutions are solving different problems (or, as the text of the
charter says, have different scopes of applicability), it is fine to
have more than one solution. However, for a single problem, we only
need a single STD'ized solution.

> solution, then why wouldn't you insist to have the same goal 

you forgot to add "and if you wouldn't insist on a single solution for
L3 VPNs, then why do you insist on this for L2 VPNs" ;-)

The reason is I don't want to restart the L3 VPN work in the IETF
and/or revisit the decisions that have been made in the past, while I
still see a reasonable opportunity to steer the L2 VPN work.

> imply a single auto-discovery mechanism for VPLS ?

This would definitely be my preference.

Alex