Subject: RE: [PWE3] Re: Issues with draft-kompella-ppvpn-vpls-01.txt

From: Mourad BERKANE <[email-masked]>
Date: Tue, 15 Apr 2003 11:03:38 +0200

I fully support draft-kompella-ppvpn-vpls-01

BGP as VPLS Signaling protocol isn't only an elegant solution :-),
it is a natural solution when 2 SPs would like to extand their VPLS domains.
If you push back BGP VPLS Signaling, how will this Carrier's Carriers VPLS
implementation will be done if one of this SP don't want to activate LDP
inside his network, BGP being already enabled on all PE routers?

If a vendor could explain me how using 2 differents protocols for Control
Plane (signaling and auto-discovery) will be more efficient (technical
argumentations please and not philosophical ones) than when using only one
protocol (MP-BGP).

Mourad

-----Message d'origine-----
De : Eric Rosen [mailto:[email-masked]]
Envoyé : lundi 14 avril 2003 20:59
À : Kireeti Kompella
Cc : Ali Sajassi; Yakov Rekhter; [email-masked]; [email-masked]
Objet : Re: [PWE3] Re: Issues with draft-kompella-ppvpn-vpls-01.txt

I don't believe in the "overloading BGP" argument myself, though it is clear
that that  argument has  many adherents.   To my mind,  the issue  is really
whether BGP is  a good protocol for  the kind of signaling that  needs to be
done.  Sure, "with enough thrust, even  pigs can fly".  In 2547, we chose to
use BGP  not because it  was there,  but because it  is a good  protocol for
distributing  a large  amount of  routing information  that  originates from
other  routing   domains.   I  like   BGP  for  auto-discovery   because  in
auto-discovery,  we  want a  protocol  that  provides a  point-to-multipoint
capability and  allows an originator  to update and withdraw  information at
will; BGP  as a protocol seems  like a good match.   Is it a  good match for
point-to-point signaling?  That's a lot more of a stretch. 

Kireeti> if  you  use  any  measurable  criteria for  the  complexity  of  a
Kireeti> solution, on all these measures, 

Well, that's  the claim.  Let's see,  suppose you need  to resynchronize the
sequence numbers on a particular  PE-PE pseudowire.  How efficient is BGP at
doing that?   Suppose there is some problem  in getting data from  one PE to
another?  Does  the fact that the  control plane goes through  a third party
(route  reflector) make  it easier  to  troubleshoot that  problem, or  more
difficult? 

Kireeti> First  of all,  there are  several  clear benefits.   Just ask  the
Kireeti> Service Providers who responded. 

You're referring to the benefit of "elegance"?  

Kireeti> Finally, to  address your  issues in your  first email, we  are not
Kireeti> asking that this  doc be made an RFC  -- just that it be  made a WG
Kireeti> doc.   As Alex  said: "For  a  document to  become a  WG draft,  it
Kireeti> doesn't have to be 100% correct." 

Adopting your  document as  a WG  doc would be  an expression  by the  WG of
support for using BGP  as a way to do p2p signaling.   The WG should be very
sure that it wants to do that before adopting your doc. 

Kireeti> if you  look at  the service offered,  you see strong  parallels --
Kireeti> any-to-any connectivity, learned forwarding 

If you compare bridging to routing,  you'll see the very same parallels, yet
the technologies  are very  different, have very  different applicabilities,
and require very different solutions.

Kireeti> a proposal that only shows how to do signaling is clearly inferior 

Certainly what is  needed is a complete solution, rather  than just a piece.
However, when the solution contains multiple identifiable components, proper
layering generally results in more long term simplicity and flexibility. 

If  the proposal  is  to use  BGP  for signaling  pseudowires,  I think  the
technical discussion should focus on its suitability for that purpose. 

Yakov> in the context of VPLS we are talking not just about multiple ways of
Yakov> distributing labels, but whether one always have to have one protocol
Yakov> for  distributing  labels, and  another  for  auto-discovery, or  one
Yakov> protocol for both would be enough.

Well,  I don't  really see  how  this is  different than  the "CR-LDP  isn't
another protocol"  argument.  The arguments  are being repeated  almost word
for word, albeit not by the same set of people ;-)

You seem to be  arguing that "given a protocol to do X, if  we need to do Y,
it is better to piggyback Y on the X-protocol than to use a protocol that is
designed to do  Y."  In general, this argument form is  not valid, it really
is a matter of how suitable the X protocol is for Y. 

Yakov> The fact that the  two drafts [kompella and lasserre/vkompella] share
Yakov> the same data plane is a feature, not a bug.

Of course, I never said otherwise.  But the specification of that data plane
should not  be in both  places, one doc  should reference the other.

---

From: Eric Rosen <[email-masked]>
Date: Thu, 17 Apr 2003 13:29:21 -0400

Mourad> If a  vendor could explain me  how using 2  differents protocols for
Mourad> Control Plane (signaling and  auto-discovery) will be more efficient
Mourad> (technical  argumentations please and  not philosophical  ones) than
Mourad> when using only one protocol (MP-BGP). 

I don't  know why the one  who explains this needs  to be a  vendor ;-), but
there are a large number of inefficiences in using BGP for the signaling. 

Suppose that 100 PEs participate in a particular VPLS, and suppose that PE17
has some information to signal to PE43. 

With point-to-point  signaling, PE17 sends  a message to PE43,  PE43 replies
(if necessary), and we're done. 

With BGP-based signaling, PE17 sends a message to the route reflector, which
then  resends it to  PEs 1-16,  and PEs  18-99.  So  instead of  sending one
message, you  send 100.   Ninety-eight of the  PEs that receive  the message
will parse it and find it irrelevant. Efficient?

Now let's  look at the individual  messages.  When some PE,  say PE92, joins
the VPLS instance, it needs to allocate 99 labels, one for each of the other
PEs.  With point-to-point  signaling, PE92 must engage each  of the other 99
PEs in one short transaction. PE92 can assign the labels in a way which best
suits its implementation, and labels are  not assigned unless they are to be
used. 

With BGP-based  signaling, we could  have PE92 assign 99  individual labels.
Then PE92  would send  a rather long  message to  the RR, containing  the 99
assignments.  The RR would forward these  to the 99 other PEs, each of which
would then have to find the one label that it cares about.  Efficient? 

To avoid  the inefficiency here,  we have the  "label block hack",  in which
PE92 reduces the  size of its message by assigning a  contiguous block of 99
labels, specifying only the beginning and  the end of the block.  But now if
PE92 needs to signal  something to PE27, how does it do  it?  I think all it
can do  is create a  message with  99 signals, 98  of which are  "null".  It
sends it  to the RR,  which forwards it  to the other  99 PEs.  All  of them
parse  the message, 98  of them  throw it  away, and  PE27 finally  gets its
signal.  Efficient?   (And if  this sort of  efficiency were  not considered
important, we wouldn't have the label block hack to begin with.) 

The requirement  to allocate labels  in contiguous blocks like  this imposes
constraints  on  the way  in  which  implementations  may assign  labels  to
particular  functions.   This  is  the  only  place in  all  of  MPLS  where
constraints like this  are imposed.  How labels are  allocated should really
be a  local implementation matter,  not constrained by  protocols.  (Perhaps
you consider this to be a  "philosophical" argument, but I think it can have
a real impact on future implementations.)

To  get the  best  use out  of  the label  block hack,  it  is advisable  to
overprovision, so  that all  the PEs which  are on-line allocate  in advance
label space  for PEs that are  not yet on-line.  Now  you're wasting labels;
each wasted label  corresponds to a real piece of high  speed memory in your
forwarding  engine, i.e.,  this is  real  resources being  wasted, not  just
"numbers".  E.g.,  each wasted  label is  one less L3VPN  route that  can be
supported.  Efficient?

In general,  providing two functions by  using a single  protocol instead of
two  is only  more  efficient if  the single  protocol  does a  good job  of
providing both functions.  Did you ever have both a telnet connection and an
ftp connection open  to the same destination at the same  time?  Would it be
more efficient to use telnet to  do your file transfers, since that would be
"one protocol"?  What really needs to be discussed in the present context is
whether  BGP is  a good  signaling  protocol for  setting up  point-to-point
circuits. It's  true VPLS provides,  much like L3VPN, a  multipoint service.
However, VPLS is built on top  of a mesh of point-to-point circuits, whereas
L3VPN  is  not.  That  difference  needs to  be  taken  into account  before
concluding that the same set of mechanisms should be used in both cases. 

I think  that some  people have presumed  that in  VPLS, there really  is no
PE-to-PE signaling  that needs to  be done.  You  just piggyback a  bunch of
labels on the auto-discovery mechanism,  and you're all done.  If that's the
case, then the inefficiencies I discussed above don't come into play.  But I
haven't  seen any  justification for  this presumption.   Certainly  in PWE3
there's quite  a few things that  can be signaled on  a point-to-point basis
with respect to an ethernet pseudowire.  And in VPLS itself, there are quite
a number of  issues (many still unresolved) about  when and where sequencing
is  needed, about  how to  transmit control  messages, etc.,  which  seem to
require some sort of signaling after the circuit has been set up. 

So it  seems to  me that there  are quite  a few technical  disadvantages to
using  BGP-with-RRs  (which is  inherently  a point-to-multipoint  signaling
substrate) as the basis for doing point-to-point signaling.

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 17 Apr 2003 13:48:20 -0700 (PDT)

> (if necessary), and we're done.

Sure.  N*(N-1) is small when N = 2.

> will parse it and find it irrelevant. Efficient?

Excuse me, but are you not an author of rfc2547bis and
draft-ietf-ppvpn-bgpvpn-auto-03.txt?

In both of the above, you send 100 messages to all the PEs, even if the
only other member of the VPN is PE43.

So, for a more accurate picture (since BGP is *not* only for signaling),
PE17 sends a message to the route reflector, saying essentially, "I'm
in VPN foo, and btw, these are the labels to use".  The RR then sends
100 messages to all other PEs.  Most of these PEs ignore the message
(they are not part of VPLS foo); the ones who are find out, with one
message, that PE17 is part of VPLS foo, and which labels to use.

Summary: one NLRI per PE per VPLS.

Efficient?

With BGP+LDP, the flow would be: PE17 sends a message to the route
reflector, saying essentially, "I'm in VPN foo" (no labels).  The RR
then sends 100 messages to all other PEs.  Most of these PEs ignore
the message (they are not part of VPLS foo); the ones who are find
out that PE17 is part of VPLS foo.

So far, not much difference -- except: no labels.  Now, the PEs who
are in VPLS foo must kick off a separate interaction -- a new LDP
session if needed, and new messages for the exchange of labels.  And
each PE in VPLS foo must do this independently.

Summary: one NLRI per PE per VPLS plus N*(N-1) LDP label exchanges
per VPLS with N members.

Efficient?  Certainly when N = 2.

As for the "label block hack", sure, call it a hack, that should scare
people away -- argumentum ad hominem always works.

Efficient block allocation is a solved problem.  Ask anyone who does
memory management, or any number of allocation problems.

> "numbers".  E.g.,  each wasted  label is  one less L3VPN  route that  can be

You certainly can do it this way.  We don't.  As for "wasting" labels,
it amazes me that a vendor that allocates individual labels for each IP
VPN prefix from the same PE keeps harping on this.

To give credit where credit is due, the idea of using BGP for both
auto-discovery and signaling came from RFC 2547.  I thought this was
clear; but I'll state it for the record.  The one issue was that for
IP VPNs, a single label per site suffices; for VPLS, you need several.
Hence label blocks.

Kireeti.

---

From: Eric Rosen <[email-masked]>
Date: Fri, 18 Apr 2003 13:43:26 -0400

Eric> Suppose that  100 PEs  participate in a  particular VPLS,  and suppose
Eric> that PE17 has some information to signal to PE43.x

Eric> With point-to-point  signaling, PE17 sends a message  to PE43, PE43
Eric> replies  (if necessary), and we're done.

Kireeti> Sure.  N*(N-1) is small when N = 2. 

I think you missed the first sentence above. 

Kireeti> Excuse  me,   but  are  you   not  an  author  of   rfc2547bis  and
Kireeti> draft-ietf-ppvpn-bgpvpn-auto-03.txt? 

Yes, indeed. 

Kireeti> In both of the above, you send 100 messages to all the PEs, even if
Kireeti> the only other member of the VPN is PE43.

The case  under discussion is where PE1,  ..., PE100 are all  members of the
VPN.  In L3VPN, and in auto-discovery, there just isn't any possible case in
which  PE17  has  something to  say  only  to  PE43,  because there  are  no
point-to-point   connections.   In  L2VPN,   which  is   built  on   top  of
point-to-point connections, it becomes possible  to use the control plane to
talk about individual point-to-point connections.   In VPWS, one has to do a
fair amount of this,  in VPLS less.  The issue is whether  BGP is a good way
to do this, and whether there is enough of this to matter.

It's not necessarily true that in either L3VPN or L2VPN, information is ever
sent to all  PEs; techniques like ORF can be used  to limit the distribution
to only those PEs which belong to the particular VPN or VPLS.  What there is
no way to do is to limit the distribution of information further.  In L3VPN,
there is no reason to do that, but in L2VPN there is.

Kireeti> As for  the "label block hack",  sure, call it a  hack, that should
Kireeti> scare people away -- argumentum ad hominem always works. 

No, "ad hominem" would be if I called you a hacker; the worst you can accuse
me of is "name calling" ;-) But I  think it's fair to call it a hack because
it imposes constraints on the  label assignment methodology that depart from
the MPLS architecture,  and the reason for imposing  those constraints is to
make  a particular sort  of solution  (BGP-based L2VPN  signaling) possible.
It's quite a clever hack, actually, but  that's not the same as being a good
idea.

Kireeti> As for "wasting" labels, it  amazes me that a vendor that allocates
Kireeti> individual labels  for each  IP VPN prefix  from the same  PE keeps
Kireeti> harping on this. 

Speaking of ad hominems ... 

It seems to me there are two cases: 

1. If  one thinks  of labels as  a scarce  resource which must  be carefully
   used, one certainly doesn't want to waste labels. 

2. If one  uses labels quite freely,  one doesn't want to find  out that one
   has run out of them because some have to be kept unused. 

So I don't see how wasting labels can be justified.

Kireeti> Efficient  block allocation is  a solved  problem.  Ask  anyone who
Kireeti> does memory management,

That must  be why  memory fragmentation is  so rarely  a problem ;-)  If the
label space  becomes too fragmented, I  guess one can  always reorganize it,
assuming one doesn't mind losing all one's connections in the meantime.

Kireeti> With BGP+LDP, the flow would be ... 

We can cut this  a bit short.  If you assume that  the only information that
EVER needs  to be communicated about  a particular pseudowire  is its label,
then  the  protocol  interactions  at  the startup  transient  are,  as  you
indicate,  well optimized  in  the all-BGP  solution,  which piggybacks  the
labels on  the auto-discovery.  But  if there is any  additional information
about particular pseudowires that needs to  be signaled, and if there is any
signaling which  needs to  be done after  auto-discovery has  completed, the
all-BGP  solution is  much  less effective,  particularly  once the  startup
transient is over.

(Note  that in  L3VPN,  the discovery  is  really piggybacked  on the  route
distribution, rather than vice versa.) 

We haven't even yet  raised the issue of whether it is  beneficial to have a
single signaling protocol  which can be used for  VPLS, VPWS, individual P2P
pseudowires, etc.   IMHO, given the need  to have LDP/L2TP  solutions, a BGP
solution would have to be extremely superior in order to be worth it.

Kireeti> The  one issue  was  that for  IP  VPNs, a  single  label per  site
Kireeti> suffices; for VPLS, you need several.  

Oh, the "one  issue" again.  The real difference with  respect to the number
of labels is that in IP VPNs, the labels are "per route", while in VPLS they
are  "per pair  of  PEs"  (and in  VPWS  they are  "per  pair of  attachment
circuits").   Naturally,  it  makes  sense  to use  a  routing  protocol  to
distribute per-route  labels.  To distribute "per pair  of something" labels
you'd tend to look to a "per pair of something" protocol.  

Kireeti> To give credit where credit is  due, the idea of using BGP for both
Kireeti> auto-discovery and signaling came from RFC 2547. 

Well, they say that imitation is the sincerest form of flattery, but in this
case I'm not so sure ;-)

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 18 Apr 2003 14:09:19 -0400

Just one thing to add inline. No ad hominems
from me I assure you. 8)

>distribution, rather than vice versa.)

         Eric raises a good point. In the case of pseudo-wires, it
is often important to send information related to the PW
after it has been signaled. Take the case of periodic
OAM information that must be passed between end points of the PW.
It may be necessary depending on how this is configured, to pass
this information often enough to make it interesting in terms
of the number of messages send p2p. However, when multipled by the
number of PE sites that a BGP-based solution would have to repeat
these messages uselessly to, this seems like an issue.  Even
in the case of non-periodic OAM information as described in
draft-shah-pwe3-control-protocol-extension, I don't see why
the fact that the status of one PW changing should necessarily
bother every other PE in the VPLS.

         --Tom

http://www.elsevier-international.com/catalogue/title.cfm?ISBN=155860751X