PW Name, VCID/VPNID and VPLS...

Vach,

[changed the subject to reflect the topic being discussed]...

>Two meta-points.  First, Eric has resubmitted his draft to 
>ppvpn as draft-rosen-ppvpn-l2-signaling-03.txt.   

Yes and it is compatible with pwe3 control draft.

> Second, why have two FECs for PWE3?   

On that I agree with you. It looks like this is the result of two things:

a) PWE3/Martini draft didn't take into account the l2vpn problem
   and the ability to support multiple provisioning models besides
   just double-sided provisioning/signaling.

b) The VCID when reused in a VPLS context changed from representing
   the PWID to representing a VPLS membership scheme (with
   all the limitations of a four-octets global id).

In other words this is a *bug* resulting from reusing exactly 
PWE3 initial work to accommodate l2vpn work without taking into account 
the nature of l2vpn requirements and provisioning models...

I think pwe3 wg should have as well addressed the question of 
provisioning models for a pseudo-wire in early stages not just 
recently. Ironically, neither the pwe3 requirement draft nor
the architecture draft addressed the "pw [multiple] provisioning models" 
and yet pwe3 control draft contains signaling specification
for multiple provisioning models. [Something that needs to be 
fixed!].

> Surely, if we use the Generalized ID FEC, then we don't need fec type 128.

> Let's simplify.

>I have no problem with the "Generalized ID FEC TLV" concept.  
>In fact, we are probably in violent agreement on that.  
>The (minor) issue is what it looks like:
>
> AGI: <type> <octet-string>
> VPN ID TLV: <type> <length> <octet-string> 

The AGI is actually  <one-octet-length> <octet-string>

The octet string contains a globally unique ID
(taken among formats that allow building global
unique id such as RD/RT, 2685, etc).

Honestly, I don't see why a solution needs to support multiple 
types of vpn-ids.

If one wants a VPN-ID which uniquely identifies a VPN, is
a name for a VPN, works across domains, is used in management, 
etc, then use RFC2685, it is already a standard, and has already 
been used before (no need to have multiple types).

However, if there is a need for multiple globally unique ids
(which I think is the case here), then let's not call that VPN-IDs 
but just globally unique id, defined for that specific solution.
Of course the solution needs to describe how these ids are 
constructed (for example use RT, embed 2685, etc) and more
importantly how these ids are used. 

If we insist on multiple VPN-IDs then we need to ask the question
whether we want to extend/obsolete RFC2685...My suggestion is
not to take that route and avoid the problem altogether
by using globally unique ids and defining them as such.

> But where I have considerably more difference of opinion is how 
> to name a PW.  In a VPWS or a VPLS, I would like to be able to name 
> each constituent PW.  So, I want a VPN ID that contains a number of PWs.  
> pwe3-control says use a 32-bit number that is unique between a pair of
PEs.  
> It also qualifies that 32-bit number with a VC type.  That's probably not 
> necessary, and some of the implementations that I have had the pleasure 
> of working with agree with me.  In other words, a PW is named 
> (PE1, VC type, VCID, PE2). 

Okay. I understand your point. Actually what you're saying is we should 
have a requirement to support a PWID (VCID) in order to uniquely identify
the PW within a VPLS in addition to the ability to 
uniquely identify a VPLS using a VPN ID or global unique id.

In that case, I am not sure we can reuse exactly the same 
provisioning model and semantic of VCID. 

It looks to me that if a VCID is needed (which I
think can be optional for VPLS), instead of using the traditional
martini PWid FEC and extending the group id, why not use the 
Generalized ID FEC and encode the VCID as an optional parameter. 

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

I assume in your suggestion of using a VCID per PW (as in Martini
case) implies the provisioning model is a double-sided 
provisioning of pw. That basically rules out the ability
to support a VPN auto-discovery mechanism for  VPLS service
(since both ends have apriori knowledge of the pw).
This has implications on scaling the vpls service...

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

I think in draft-rosen the PW is named based on the pair:

  <PE1, <AGI, AII1>, PE2, <AGI, AII2>>,       
  < PE2, <AGI, AII2>, PE1, <AGI, AII1>

If we use the VCID as option (as a suggestion), then the 
pseudo-wire will still be identified with a pair of LSP as above with
the addition of a VCID option. 

>  I am not not convinced of the benefits of this naming scheme.   

I think the ability to assign a VCID (if needed) should not
constrain the ability to use a Generalized ID FEC
outside the traditional martini PWid FEC. The benefits is
the same flexible signaling scheme can be used for multiple
l2vpn services, and multiple provisioning models...

> Eric and I have exchanged some emails in this regard, 
> and are continuing to do so.

> Finally, draft-rosen says the SAII and TAII are 0 for VPLS.  
> That means that there is no name for the PW between a pair of VPLS nodes.

>
>  That may generally be ok since the full name of a PW is 
> {VPNID, (PE1, 0, 0, PE2)} and we generally have only a single 
>  PW between a pair of nodes in a VPLS.

Note that in distributed VPLS case, the SAII and TAII are not null
and are actually used to identify the U-PE. So the use of non null
SAII, and TAII has applicability in the context of VPLS. There is
benefit in having these fields for VPLS as well...


> However, when we have a VPLS node which has a pair of spokes to the 
> same MTU (HVPLS situation), we have to name >the PWs differently.   
> This scenario comes up in certain regulatory environments where the 
> MTU owner is only allowed to provide L2 transport service.    
> Consider the following physical topology.

>   CE1------------MTU-------------PE
>                   |
>   CE2--------------

>In an unregulated case, the MTU could host a FIB, and turn packets around 
>between the two CEs.  However, in a regulated environment, the PE may have 
>to host the FIB.  We have then two spokes from the PE to the MTU, one for 
>CE1 and one for CE2. 

I think you meant two spoke connections from PE to the MTU, each spoke 
connection is associated with a particular CE.


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

>I want to be able to name each spoke.   

Let me rewrite your example with some labels:

   CE1------------\    /---- SPC1 ------\
                    MTU                PE 
   CE2=============/  \====== SPC2 ====/
 

SP1,2 are Spoke Connections for each CE.

> On the PE side, I have a FIB.  In draft-rosen, the PE would name the SAII
0.   

Although hierarchical VPLS wasn't addressed in Eric's draft. You may follow
similar procedures with distributed VPLS for that specific
scenario (or for all hvpls), for a PW signaled by the MTU for
SPC1, the SAII contains an MTU id, let say i, and for SPC2, the SAII will 
carry an MTU id of j (as an example).

> The PE would have to know the name of the TAII on the MTU going to CE1.   

Same thing, for signaled PW from PE to MTU, the SAII will be null,
and TAII will be set to the MTU id for that spoke connection
(for example "i").

PW will be used to disambiguate between CEs. A packet received on 
SPC1 for example will be forwarded directly to CE1.

> The PE would have to know the name of the TAII on the MTU going to CE2.  
> Otherwise, there would be no names for these two PWs. 

No there is. As I said HVPLS, DVPLS are special cases when
generalized id FEC is used. The two PWs will still be
identified with the pair mentioned before (and that includes
the SAII, TAII, and AGI). From signaling point of view
it is the same. 

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

One can view it as well as adding a third FEC option
in addition to the two existing ones.  This will look like a
a "double" bug in PWE3 control draft :-).

>  - my proposal requires a VPN ID that groups PWs across the 
> network that belong to the same VPN 
> - my proposal uses the VCID field to name a PW within the VPN 

With the adverse effect that not only a VPN-ID needs to
be configured but as well a VCID needs to be configured
on both ends of the PW wire.  

My suggestion is if an AGI is used, then 
the VCID can be optional, and need not be configured.
 
> - the delta between existing fec type 128 in pwe3-control and
> my proposal is minimal 

Does it really matter the minimum delta given that we will end up with
a new style of FEC being signaled in addition to
the current PWid FEC. 

> - I feel that draft-rosen suggests a much broader change 
> (with additional benefits, but do we need them?)
 
I would say it has applicability for multiple l2vpn services
and deployment scenarios. In my view it's worth considering 
instead of creating a brand new FEC that requires double-sided
provisioning for each pw making up the vpls service.

Hamid.

-Vach

-----Original Message-----
From: Hamid Ould-Brahim [mailto:[email protected]]
Sent: Friday, May 30, 2003 10:37 AM
To: [email protected]; Vasile Radoaca; Dinesh Mohan; Ppvpn; Rick Wilder
Subject: RE: decisions on L2 solutions documents


Vach, 

A comment on vpn-id/martini... 

> Vach>> naming the PWs, not in naming the VPN ID.  The issue 
> of using a globally 
> unique name for the VPLS 
> Vach>> has been discussed.  In an attempt to keep the 
> signaling compatible with 
> draft-martini, we agreed 
> Vach>> on using a VCID.  

I think in the pw control draft (draft-ietf-pwe3-control-protocol-02.txt), 
Eric's signaling extensions have been added that can 
accommodate as well a global unique id. Why not use 
the control draft extensions. 



>However, there was an intent all 
> along to somehow make 
> that identifier a 
> Vach>> globally unique.  Suggestions were made such as adding 
> a VPN ID in the 
> optional parameters field, 
> Vach>> etc.  My last proposal was to have a bona fide VPN ID 
> TLV in the FEC. 
> 

Yes. But that is not defined in pwe control draft and if added 
it looks redundant to Eric's additions. I requested before 
clarifications on the use of VPN-ID TLV (which was left 
unanswered btw - see the archive) 
  
http://standards.nortelnetworks.com/cgi-bin/wa.exe?A2=ind0305&L=ppvpn&T=0&O=
A&P=980. 

I don't see why we still didn't resolve that problem. 

Why not just adopt the pwe3 control draft's Generalized ID 
FEC element instead of defining another VPN-ID TLV 
(which I assume if done needs to be captured in the same 
draft). 

Is there any reason why not? 

Hamid.