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

From: "Hector Avalos" <[email-masked]>
Date: Thu, 17 Apr 2003 22:43:24 +0200

>>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. 

Hector> What would be the type of signaling message a PE17  will send to
a PE43
Hector> that any other PE should be aware if the VPLS is a full mesh ?
Hector> 

>>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?

Hector> This is the same behavior than 2547bis and it works very well.
Hector> PE will need to handle one single message, so there is no issue
here.
Hector> There are RR which can handle this with no issues. And if there
is
Hector> an scaling issues we can partition the network with several RR
Hector> like in 2547bis. So there is no scaling issues here.

>>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?

Hector> With BGP the NLRI is the same for a VPLS with 2 PEs or 1000 PEs
Hector> With BGP only the label base and offset is send on the NLRI
Hector> he label block hack as you called it...So no issues again.

>>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.) 

Hector> for mesh VPLS I don't see the PE to PE message requirement.
Hector> If it is to announce that the local port is down, it should
announce it
Hector> to all other PEs in the domain.

>>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.)

Hector> what is the issue with this regarding its benefits ?

>>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?

Hector> I wonder what is the conception of a VPLS domain size.
Hector> I guess that VPLS will not be applicable to +100 sites VPNs
Hector> For a VPLS domain of 100 sites, a PE needs to reserve 100 labels
Hector> If a PE supports 1000 VPNS of this size, then we end-up with
100,000 labels.
Hector> I don't see any issue.
Hector> I know some 2547bis applications which signals one label per
prefix.
Hector> If we do the math using VPNs with 100 routes each, we will see 
Hector> the label block uses quite less labels. So  there should be no
issues
Hector> on PEs using label blocks.

>>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. 

Hector> please share with us which PE-to-PE signaling needs to be done
Hector> on a multi-point environment

>>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.  

Hector> I think that comparing BGP vs LDP for signaling is a wrong
comparison
Hector> BGP also does auto-discovery, which LDP doesn't.
Hector> So I guess that Mourad's question remains open. How two
protocols will be more efficient
Hector> for signaling and auto-discovery ?

---

From: Eric Rosen <[email-masked]>
Date: Fri, 18 Apr 2003 12:36:25 -0400

Hector> What would  be the type of signaling  message a PE17 will  send to a
Hector> PE43 that any other PE should be aware if the VPLS is a full mesh?

I think you're asking whether PE17  might really ever need to send a control
message to PE43 that the other 98 PEs don't need to know about.

Some possible examples:  sequence number synchronization, OAM functions that
utilize the control plane, QoS.

I'll admit though that  using BGP for VPLS signaling is not  quite as bad as
using it  for VPWS signaling.  Surely no  one would ever propose  it for the
latter, right ;-)

Eric> So instead of sending one  message, you send 100.  Ninety-eight of the
Eric> PEs that receive the message will parse it and find it irrelevant. 

Well, I'm  always delighted to hear  folks say how well  2547bis works!  But
this is not the same behavior.  In L3VPN, if a PE makes a routing change for
some VPN,  that change is  meaningful to all  the other PEs  supporting that
VPN. Thus it MUST be communicated  to all the other PEs.  What we're talking
about with VPLS  is information that is meaningful to only  one remote PE in
the VPLS, but gets sent to all the others anyway.

If one  expected a VPLS to contain  a relatively small number  of sites, one
wouldn't even bother with the label block hack.

Hector> 100,000 labels. 

If you  really have 100 sites  in a VPLS, each  PE needs to  use 100 labels,
however you distribute them, and whether  you are using label blocks or not.
The wastage  only comes if you  overprovision the label block  size to allow
for  future expansion.   Then  the  issue isn't  that  you're using  100,000
labels, it's  that 50,000  of them  (assuming there are  50 sites  now, with
plans to  possibly add 50  more, if business  is good) aren't being  used at
all.

Hector> prefix. 

And in such  applications, if VPLS requires that a PE  hold 50,000 labels in
abeyance for  possible future expansion,  that's 50,000 fewer  prefixes that
that PE can support in L3VPN.

There are  also some advantages  to being able  to assign the  in-use labels
compactly.  If a  router reboots, it may  be a good idea for  it to remember
where it  left off assigning labels  before, so that it  can start assigning
new labels from where it left off.  This reduces the likelihood of confusion
if some some system out there  is still using the old labels.  (Perhaps that
other system hasn't gotten the latest  BGP updates yet, or perhaps it is one
of  those newfangled  "non-stop-forwarding" systems  which is  continuing to
forward even  if it is temporarily  unable to process the  BGP updates.)  If
you're using  a scheme which wastes  labels, it's more difficult  to do this
effectively. 

The notion  of a label range  being meaningful at the  protocol level really
departs from the MPLS architecture.   If some hardware designer decides that
even numbered labels should be  used for 2547, odd numbered labels non-prime
numbers for VPWS, and prime numbers for VPWS, he should be able to do that.

Hector> I  think  that  comparing  BGP  vs  LDP for  signaling  is  a  wrong
Hector> comparison BGP  also does auto-discovery,  which LDP doesn't.   So I
Hector> guess that Mourad's question remains open. How two protocols will be
Hector> more efficient for signaling and auto-discovery ?

I  guess I  thought I  had addressed  that. If  you were  to use  Radius for
auto-discovery, would you also be proposing to use it for signaling?