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

From: "asodder" <[email-masked]>
Date: Wed, 16 Oct 2002 14:03:57 -0400

>This  is actually a  PWE3 issue,  as it  has to  do with  the
ethernet-over-
>IP/MPLS  encapsulation and  the service  provided thereby,  but  has
nothing
>really to do with VPNs.

Eric,

You mentioned that this is a PWE3 issue, however I was under the (maybe
incorrect) assumption that the outer mac frame follows the rules as
specified in the PWE3 draft for ethernet-over-IP/MPLS.  If this is incorrect
do let me know.  The inner mac frame is different but should be transported
as data in the outer mac frame.

Arnold

---
You are currently subscribed to ppvpn as: [email-masked]
To unsubscribe send a blank email to
[email-masked]

---
You are currently subscribed to ppvpn as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Eric Rosen <[email-masked]>
Date: Thu, 17 Oct 2002 09:20:44 -0400

Arnold> You mentioned  that this is  a PWE3 issue,  however I was  under the
Arnold> (maybe incorrect)  assumption that the  outer mac frame  follows the
Arnold> rules as specified in  the PWE3 draft for ethernet-over-IP/MPLS.  If
Arnold> this is incorrect do let me  know.  The inner mac frame is different
Arnold> but should be transported as data in the outer mac frame. 

If you want to argue that the ethernet-over-IP/MPLS service begins after the
MAC-in-MAC encaps  has been done,  and ends before the  corresponding decaps
has been done, then you could argue that the rules for the MAC-in-MAC encaps
are outside PWE3's scope.

The rules  for MAC-in-MAC  encapsulation would then  be totally  outside the
scope of  the IETF,  I believe,  as there is  no IP  or MPLS  involved.  The
proposal would have to be taken to IEEE. 

This might be a good way to approach it, as the hierarchy would then be done
in the  layer 2 network using layer  2 techniques, and in  the MPLS/IP layer
one can just do "ordinary" VPLS without need for further hierarchy. 

If  on the  other  hand you  want  to argue  that the  ethernet-over-IP/MPLS
service  begins before the  MAC-in-MAC encaps  is done,  and ends  after the
decaps is  done, then  it would have  to be  considered part of  the IP/MPLS
encapsulation and would fall under PWE3.

---

From: "asodder" <[email-masked]>
Date: Tue, 22 Oct 2002 21:00:54 -0400

Eric,

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

I think I may need to explain the control plane much more.  VHLS does not
need a per LAN segment VC label to be signaled, since the VC is only used to
demux VHLS data from other PWE3 point-to-point traffic.  Thus a single VC is
signaled and the VHLS VPN identifier is used to demux the data at the
receiving PE. This is not the same as VPLS which requires multiple VC labels
to be signaled since the VC label is used to determine which VPN the frame
belongs to and also which PE device the frame was received from.

I'm very interested in your last statement which implies that if the service
begins before the MAC-in-MAC encaps is done then the standardization effort
belongs in the PWE3 working group.  Could you please elaborate.

Thanks,
Arnold

---

From: Eric Rosen <[email-masked]>
Date: Wed, 23 Oct 2002 10:06:51 -0400

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

Arnold> I'm very interested in your last statement which implies that if the
Arnold> service  begins  before  the  MAC-in-MAC  encaps is  done  then  the
Arnold> standardization effort belongs in the PWE3 working group.  Could you
Arnold> please elaborate. 

There's  not  really  anything  to  elaborate.   The  specification  of  the
encapsulation  needed to  provide an  ethernet service  over an  IP  or MPLS
network is in the domain of PWE3.