Subject: Timeslot to discuss VPLS issues

From: "Vach Kompella" <[email-masked]>
Date: Mon, 16 Jun 2003 10:15:17 -0700

Loa/Rick,

Can I get a timeslot to discuss some VPLS issues in draft-lasserre-vkompella
(soon to be submitted as draft-ietf-ppvpn-vpls-ldp-00.txt which is substantively
the same as draft-lasserre-vkompella-ppvpn-vpls-04)?  These are the issues:

1.  The VC type has changed from 0xb (VPLS) to 0x5 (ethernet).  Most people have
implemented VPLS using 0xb, but the newer implementations use 0x5.  It's not the
value, but the concept here that is at question: if the VC type is no different
from a pt2pt ethernet PW, then how does one distinguish a group of pt2pt PWs
from a group of split-horizon PWs?  One idea is to use an optional parameter,
say Split horizon Group ID, to name a split horizon group of PWs.  This would
give us both the capability to identify whether a PW is split horizon enabled or
not, as well as extend the notion of split-horizon-ness to groups.

2.  Naming the VPLS: currently the name of the VPLS is the VCID.  This is not
adequate.  I proposed a VPN ID TLV.  Eric proposed a Generalized ID FEC.  I'd
like to get this resolved as to which direction we should proceed.  I have
already raised this issue on the mailing list, and would like to get some more
feedback before Vienna.

What I would like is to be able to name the VPLS, name each PW in the VPLS,
identify each PW with a VC type, and associate each PW with a split-horizon
group.  Apart from causing inconsistencies between draft versions, this also
impacts progress on the hvpls oam draft, so I'd like this cleaned up asap.
Thanks.

Vach Kompella
TiMetra Networks
[email-masked]
650-237-5152

---

From: Eric Rosen <[email-masked]>
Date: Mon, 23 Jun 2003 11:23:58 -0400

Vach> 2.  Naming the VPLS: currently the name of the VPLS is the VCID.  This
Vach>     is  not adequate.   I  proposed a  VPN  ID TLV.   Eric proposed  a
Vach>     Generalized ID  FEC.  I'd  like to get  this resolved as  to which
Vach>     direction we should proceed.  I  have already raised this issue on
Vach>     the mailing list, and would  like to get some more feedback before
Vach>     Vienna. 

Vach> What I would like is to be able  to name the VPLS, name each PW in the
Vach> VPLS, identify  each PW with a VC  type, and associate each  PW with a
Vach> split-horizon group. 

I'd like  to be able to  do this too; in  fact, the Generalized  FEC Id does
this  easily.  The  only real  difference  between the  VPN ID  TLV and  the
Generalized FEC ID is  that the latter allows a PW to  have a different name
at each of its endpoints, while the former requires it to have the same name
at both endpoints.

If one considers only those  applications which appear in drafts co-authored
by Vach ;-), then  it will appear that there is no need  for PWs to be named
differently at  the two endpoints.  If there  is no such need,  then the two
proposals are  functionally identical,  but the Generalized  FEC Id  is more
complicated. (I'd  say only "slightly" more complicated,  but perhaps others
would diagree.)

However,  if  one considers  some  additional  applications  (such as  those
described  in draft-rosen-ppvpn-l2-signaling-03.txt  sections  5.1.1.2, 5.3,
5.4, and 5.5), then I don't think the VPN ID TLV is adequate.  Of particular
concern is  the application in 5.5  (distributed VPLS), as this  needs to be
interoperable with "regular"  VPLS.  I think we need  one naming space which
covers both the  distributed VPLS and the regular VPLS, and  I don't see how
this can be the VPN ID TLV. 

Perhaps not  everyone takes distributed VPLS  seriously, but if it  is to be
ruled out, it  should be done so explicitly, not  as a (possibly unintended)
side-effect of the way we adopt a naming space.

The  other applications  for which  the VPN  ID TLV  is unsuitable  are VPWS
applications, and conceivably we could  use a different naming structure for
VPWS than  for VPLS.  However, I  think that would be  a complication rather
than a simplification.

My  thinking is  that the  Generalized FEC  Id is  a naming  mechanism which
provides everything that  is needed for VPLS, but which  also can cover more
applications.  So I don't really see the downside.