Subject: Re: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt

From: Eric Rosen <[email-masked]>
Date: Mon, 11 Nov 2002 15:14:11 -0500

In your proposal,  you still require the mesh  of LDP connections.  However,
rather than having  a PE dynamically assign one label  for each emulated LAN
instance it supports,  it assigns one label meaning  "emulated LAN service".
Then the packets sent across the  network need to carry that label, and also
a globally unique VPN-id to identify a particular emulated LAN instance.  

So let's compare the overhead of your proposal to the existing proposal: 

- Same number of LDP connections.

- Fewer LDP messages sent and received at startup time. 

- Same number of  labels need to be  looked up (i.e., no savings  on size of
  lookup table)

- Data packets have to carry one more label.  Further, either that label has
  to be long  enough to be a really globally unique  VPN-id (i.e., 64 bits),
  or else there is a manageability problem. 

- That extra label has to be looked  up, for each data packet, by the egress
  PE.  Further,  as this label is  a different type of  label, this requires
  additional  lookup logic,  which means  the forwarding  path is  made more
  complex. 

So for a modest savings in messages to process at startup time, you increase
the per-packet overhead  and you complicate the forwarding  path.  This just
doesn't seem like a good tradeoff to me. 

Further one also needs to examine the implicit claim that per-VPLS signaling
has no  task other than to  assign labels.  If you  look at draft-ietf-pwe3-
control-protocol-01.txt, you will see that  it does other things than assign
labels,  such  as allowing  sequence  number  synchronization, allowing  MTU
checks, allowing passing of status information, etc.