Re: decisions on L2 solutions documents

Vach> I would suggest  that the full name  of a PW is {VPNID  (PE1, VC type,
Vach> VCID, PE2)}.

Vach> draft-rosen suggests that a PW is named (PE1, SAII, TAII, PE2)

Whether the VC type is part of the name is orthogonal; either proposal could
decide to use it or not, as it is always present. 

In my  proposal, you've  left out  the AGI above,  and the  AGI is  really a
VPNID.  The SAII and TAII are really VCids, so I'd say the difference is:

Vach: <VPNid, PE1, PE2, Vcid>

Eric: <VPNid, PE1, PE2, VCid at PE1, VCid at PE2>

That is, the only difference is whether to have a VCid which is unique for a
given pair of PEs, and have  that VCid provisioned at both ends, vs. whether
to allow each end to use a different VCid. 

By  allowing each  endpoint to  have  a different  VCid, it  is possible  to
accommodate  both  the  "auto-discovered  VPWS  full mesh"  scheme  and  the
"distributed VPLS" scheme,  as well as some possible  future extensions such
as switched VCs. 

Vach> Finally,  draft-rosen says the  SAII and  TAII are  0 for  VPLS.  That
Vach> means that there is  no name for the PW between a  pair of VPLS nodes.
Vach> That may generally be ok since the  full name of a PW is {VPNID, (PE1,
Vach> 0, 0, PE2)} and  we generally have only a single PW  between a pair of
Vach> nodes in a VPLS.

Yes, when there is only a single PW between a pair of nodes in a VPLS, there
is no need to assign a name to the PW, other than the VPNid. 

Vach> However, in a regulated environment, the  PE may have to host the FIB.
Vach> We have then  two spokes from the PE  to the MTU, one for  CE1 and one
Vach> for CE2.


Vach>    CE1------------\    /-----------\
Vach>                     MTU             PE
Vach>    CE2=============/  \=============/

Vach> I want to be able to name each spoke.  On the PE side, I have a FIB.  In
Vach> draft-rosen, the PE would name the SAII 0.  The PE would have to know the
Vach> name of the TAII on the MTU going to CE1.  The PE would have to know the
Vach> name of the TAII on the MTU going to CE2.  Otherwise, there would be no
Vach> names for these two PWs. 

In this case, I  would just have the MTU assign different  SAIIs to the PWs,
e.g., 1 and 2.  The two PWs would be <VPNid, MTU, PE, 1, 0> and <VPNid, MTU,
PE, 2, 0>.  I think this is exactly the same as in your proposal. 

So in my view, the two  proposals are semantically exactly the same for VPLS
and HVPLS,  it's just that  one is able  to handle additional cases  and the
other isn't. 

Vach> In summary:
Vach>  - my proposal would remove the  limited use Group ID field (actually,
Vach>    Eric pointed out I had no use for it)

Both proposals agree on this. 

Vach>  - my proposal requires a VPN ID that groups PWs across the network that
Vach>    belong to the same VPN

Both proposals agree on this. 

Vach> - my proposal uses the VCID field to name a PW within the VPN

Both proposals agree on this. 

Vach>  - the  delta between  existing fec  type 128  in pwe3-control  and my
Vach>    proposal is minimal

Eliminating the group id and adding a VPNid is "minimal"?

Vach>  - I  feel  that draft-rosen  suggests  a  much  broader change  (with
Vach>    additional benefits, but do we need them?) 

We could  compromise by  allowing a one-name  format and a  two-name format,
keeping  the one-name  format for  VPLS and  HVPLS, and  using  the two-name
format only where  is it really required.  However,  I think that compromise
would result in something which is more complicated than it needs to be. 

Another possible difference between the proposals has to do with whether the 
setting up of an LSP in one  direction can trigger the setting up of the LSP
in the  other direction,  or whether the  two directions  need to be  set up
independently.