Subject: RE: I-D ACTION:draft-sodder-ppvpn-vhls-01.txt

From: "asodder" <[email-masked]>
Date: Tue, 5 Nov 2002 11:02:48 -0500

Eric,

I've added a description to the draft that illustrates how the PWE3-CTRL
draft can be extended to support VHLS.  Hopefully this will illustrate the
reduction in signalling when compared with VPLS.  The updated draft can be
found at: ftp://63.77.213.10/pub/draft-sodder-ppvpn-vhls-01.txt.  [Sorry I
missed the deadline].

I have not addressed all the issues you have raised in your earlier email.
The issue of per-packet overhead is the trade-off that this approach makes
with respect to other approaches.

Your proposal for inter-operability with VPLS is good and I'll try and
detail it (hopefully with your help) and include it in the next version of
the draft.

Arnold

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]]
Sent: Wednesday, October 23, 2002 10:07 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-sodder-ppvpn-vhls-00.txt

Arnold> I   agree   that  initially   I   have   been   assuming  that   the
Arnold> ethernet-over-IP/MPLS service begins after the MAC-in-MAC encaps has
Arnold> been done, and ends before the corresponding decaps has been done.

In this case, we need only  consider how to provide the emulated LAN service
for the packets which have already been MAC-in-MAC encapsulated, and we need
to  do that  considering only  the  outer MAC  header.  So  this reduces  to
exactly the same problem that VPLS is intended to solve.

The  only relevant difference  then between  your proposal  and VPLS  is the
following.  In VPLS, signaling is used to assign a locally significant label
value that represents  a particular L2VPN instance in  a particular PE.  You
appear to be  proposing to replace the locally  significant label value with
globally significant  values, so  as to eliminate  the signaling.   It's not
completely clear  how you intend  this to work,  as your draft  says nothing
about how a packet  is associated with its source PE.  I  think you might be
intending to have each PE  signal a single label (representing the "emulated
LAN application") to  each other PE.  Then you seem to  be intending to have
each packet carry a VPN-id in  its encapsulation.  My comments on this would
be:

- It  significantly increases  the per-packet overhead.   I see  that you're
  trying to squeeze the VPN-id into some existing MAC header field, but this
  won't  work.  The  VPN-id has  to  be a  globally unique  value which  can
  feasibly be administered  in a multi-provider space, and  this means it is
  going to be about 8 bytes long.  (See, e.g., RFC 2685.)

- With a  significant increase in the per-packet overhead,  you need to make
  the assumption that  the packets will not have to  pass through any legacy
  ethernet  equipment (you  know,  the  kind that  just  barely supports  an
  ethernet frame  with a couple  of MPLS labels).   This is not  a realistic
  assumption.

- For the increase in packet size, I don't see that you gain any significant
  reduction  in  signaling,  as  you  still  seem  to  need  per-PE  control
  connections.  (To eliminate  that, I think you'd need  to require that the
  MAC-in-MAC encaps  be further encapsulated  inside IP, so you  could learn
  the  source PE's  address on  a  per-packet basis;  but I  think that  has
  problems as well.) You also  need to consider the impact of interoperating
  with  other hierarchical  VPLS or  distributed  VPLS schemes,  as well  as
  interoperating with the PWE3 p2p ethernet service, all of which seem to be
  made more  complex.  (You're not  assuming that emulated LAN  service will
  only  be  offered  with  new  L2PE  equipment  that  does  the  MAC-in-MAC
  processing, are you?)

- By carrying the VPN-id in  each packet, you impose the requirement to look
  up the  VPN-id for each  received packet, so  we have yet another  kind of
  thing to be looked up.

I can  see that VHLS  keeps the  MAC address tables  in the PE  smaller than
HVPLS does,  but the distributed (sometimes called  "decoupled") VPLS models
eliminate those tables in the PE altogether, though at the cost of requiring
MPLS in the L2PEs.

One alternative to consider might be the following.  In the distributed VPLS
model,  allow  MAC-in-MAC  to  be  an  alternative to  MPLS  for  the  local
L2PE-to-PE  signaling, but don't  carry the  MAC-in-MAC across  the network.
This would  allow the various  schemes to interoperate (e.g.,  MAC-in-MAC at
one end, MPLS at the other).