Comments on GVPLS

Vasile,
 
I took the liberty to change the subject.
 
I want to make a couple of points to your comments.
 
As a general one, GVPLS is a good attempt to create a "perfect" solution. To
do so, it includes a lot of complexities (e.g., different encapsulation than
PWE3, multicast-unknown frame VCs). The question is "do we need to have all
of those now?". I think not. Let's have some experience with the service and
evolve it over time. Let's not complicate the solution up front. You said it
best in your draft "simplicity, ease of deployment and manageability". 
 
- "Scalability" is a freely used term. What do you mean by "VPLS
(lasserre-vkompella) is not scaleable"? Where do you see the limitation of
1000 VPLS instances for VPLS (lasserre-vkompella)? 
- You keep referring to VC label scalability issue? In his draft, Kireeti
says this is non issue (which I agree with), and his solution wastes service
labels. Your comparison of VC label scalability is not correct either. The
comparison should be "CW+VC label" in GVPLS to "VC label" in VPLS. 
- Would you please elaborate on the MAC explosion in PEs? What scenario do
you have in your mind? Do you think customers would put more than roughly
hundred hosts per a broadcast domain? We heard those scenarios from
marketing (like 900 sites). However, after we talked to the customers
themselves, they understand that putting all 900 sites in one broadcast
domain is not wise. Most likely they confuse the layer-2 VPN with the
layer-3 VPN.
- The objective of GVPLS and HVPLS is the same, but their constraints are
not. GVPLS relaxes the constraints by not following PWE3 encapsulation.
- I am also interested in your answer (maybe you already did and I missed
it) to the following e-mail from
<http://standards.nortelnetworks.com/cgi-bin/wa.exe?A2=ind0304&L=ppvpn&D=0&T
=0&P=42937> lidefeng <[email protected]>
"In draft-radoaca-ppvpn-gvpls-01.txt,when control word is used(as mentioned
in section 5.1.2 VSI-n of draft-chen-ppvpn-dvpls-compare-01.txt), the remote
forwarding towards remote N-PE in the local N-PE is performed by splicing
access PW corresponding to remote U-PE to core PW corresponding to the same
remote U-PE-id,and local U-PE-id is added to control word,that is,take the
U-PE-id as the SRC-CW-U-PE-ID field,however,U-PE-id is the is a 6-byte-long
device id,and SRC-U-PE-ID represents the address of the originator U-PE
deivece,is a 4-byte long IP address in IPv4,while the SRC-CW-U-PE-ID is 12
bits long,I wonder how to mapp these parameter in implementation."

 
thanks,
yetik

-----Original Message-----
From: Vasile Radoaca [mailto:[email protected]] 
Sent: Sunday, June 01, 2003 3:39 PM
To: '[email protected]'; Dinesh Mohan; Ppvpn; Rick Wilder
Subject: RE: decisions on L2 solutions documents



Vach, 

  See my comments below - 

Cheers 
 Vasile 

-----Original Message----- 
From: Vach Kompella [mailto:[email protected]
<mailto:[email protected]> ] 
Sent: Friday, May 30, 2003 12:50 PM 
To: Radoaca, Vasile [BL60:X624:EXCH]; Mohan, Dinesh [CAR:1A11:EXCH]; Ppvpn;
Rick Wilder 
Subject: RE: decisions on L2 solutions documents 


Vasile, Dinesh, 

Some comments below.  I've tried to identify Rick's, Vasile's and my
comments. Outlook may mess the whole thing up, so apologies in advance.

-Vach 

.. clipped 
Rick>> Here are the questions/requests-for-clarification that came up. 
Rick>>     a) how do the discovery and signaling parts of the document 
Rick>>        relate to those described in the other solutions documents 
Rick>> and 
which 
Rick>>        of them are suggested to be mandatory to implement 

VR> > vasile 
VR> There are couple of assumptions that need to be taken in 
VR> consideration: 
VR> 1) 
VR> The GVPLS model, as a distributed model, needs to have a signaling
mechanism 
that allows PW to be 
VR> identified by VPN-ID, and the End Points together. The 
pwe3-control-protocol-02.txt draft, with 
VR> Rosen's extensions to the PW Signaling mechanism address this 
VR> problem. 

Vach>> As a matter of fact, Rosen's signaling separately identifies the 
Vach>> PW and 
the VPN.  Think of the 
Vach>> VPNID as a collection of PWs, and think of the SAII, TAII between 
Vach>> a pair 
of PEs as the PW 
Vach>> identifier.  So, if you want to use the Rosen model, why write 
Vach>> your own 
draft? 

>> Vasile 
Rosen's draft presents only the extensions to the Martini's PW model, for
the control plan in order to accommodate more general models, like the
distributed model. The new GVPLS draft would be based on Rosen signaling
[PWE3-Control 02.txt]. 

So, the GVPLS has his own role as solution draft. 

.. clipped 

Vach>> There are two issues here.  The first is whether we need a 
Vach>> separate model for distributed VPLS or 
Vach>> not.  The second is whether we need a VPN ID. 

Vach>> To the first point, Ali and Eric have described how to use p2p 
Vach>> PWs in conjuction with a learning 
Vach>> bridge in the position of the MTU to make a distributed VPLS 
Vach>> node.  don't think we need to have 
Vach>> another way to create a distributed VPLS node. 

>> Vasile 
The draft-rosen-ppvpn-l2siganling-03.txt, section 5.5 represents an example
how a distributed model can be built using the Generalized signaling method
[PWE3-Control]. However, such model doesn't scale at all, and it covers only
point-to-point type connections between U-PE devices and N-PE devices. In a
more general and useful case, is when an Ethernet access network is used
between U-PE and N-PE devices. Also, such model needs to be presented in and
end-to-end solution.

We have here a typical two extreme cases: 
1) VPLS/HVPLS [your solution] where the MAC learning is done in PE - in this
repsect the scalability is very limited because of MAC explosion

2) "Rosen's model ,section 5.5, where everything is built using PW [access
and core], which doesn't scale because of the number of PWs.

GVPLS is a third way, where  is balance between MAC learning and forwarding
and the number of PWs built in the core [and eventual in the access].

... clipped 


Vach>> To the second point, the primary difference between the Rosen 
Vach>> draft and the HVPLS draft is in 
Vach>> naming the PWs, not in naming the VPN ID.  The issue of using a 
Vach>> globally unique name for the VPLS 
Vach>> has been discussed.  In an attempt to keep the signaling 
Vach>> compatible with draft-martini, we agreed 
Vach>> on using a VCID.  However, there was an intent all along to 
Vach>> somehow make that identifier a 
Vach>> globally unique.  Suggestions were made such as adding a VPN ID 
Vach>> in the optional parameters field, 
Vach>> etc.  My last proposal was to have a bona fide VPN ID TLV in the 
Vach>> FEC. 
Vach>> Again, you mention that you would do draft-rosen.  Why are you 
Vach>> specifying a different protocol 
Vach>> then? 
Vach>> If LDP is mandatory, why do you feel it is necessary to describe 
Vach>> BGP signaling in your draft? 
Vach>> What is different about your BGP signaling and draft-kompella? 

>> Vasile 
BGP signaling needs to be done - and we would do in a separate draft. 

... clipped 

Vach>> Then define BGP in a separate draft.  There is a claim that the 
informational model is the same 
Vach>> for BGP and LDP.  However, there are a lot of different fields in 
Vach>> the signaling that are 
Vach>> described in the LDP signaling.  I don't know how you are going 
Vach>> to add them to the BGP signaling. 
Vach>> Are the BGP signaling components such as label blocks and VE IDs 
Vach>> or site identifiers part of the 
Vach>> informational model?  Are the LDP signaling components 

Vach>> If draft-rosen is your model for LDP signaling, how are you going 
Vach>> to keep gvpls interoperable 
Vach>> with HVPLS? 

Vasile >> this is up to VPLS/HVPLS solution - I think VPLS/HVPLS should also
adopt Rosen's signaling method. VPLS/HVPLS draft is to narrow solution to
solve the current market issues. It is one of the possibility. 

[clipped] 


Vach>> Some conclusions: 
Vach>>   - GVPLS says LDP is the signaling protocol of choice 
Vach>>   - GVPLS proposes basic interop with draft-lasserre-vkompella-vpls 
Vach>>   - one can construct a distributed VPLS node using ethernet PWs and
VPLS 
Vach>>   - MAC-in-MAC is clearly outside the scope of the IETF 
Vach>>   - at the Yokohama IETF we were told MAC-in-MAC was not 
Vach>> currently in any IEEE charter 
Vach>>   - the BGP in GVPLS is too similar to draft-kompella-vpls to 
Vach>> warrant a 
separate draft 
Vach>>   - the claim to identical information models between BGP and LDP 
signaling is not borne out 
Vach>>   - GVPLS uses different encaps from the ones being defined in 
Vach>> PWE3 

Vach>> Can you stil justify the GVPLS draft? 

>> Vasile 
As is today, it is not any other solution draft that described the VPLS
distributed model [Rosen's attempt is just an example].  GVPLS is trying to
complete this role.

A VPLS network can be composed via complex access  and core networks. It
would be to simplistic to consider the distributed model just with the PWs
on the access [the cost and the scalability do not reflect the customer's
requirements and the market direction]. From scalability point of view, we
just move the VPLS/HVPLS scalability problems from Mac learning to the
VC-labels.

Also, we need to a  have model that is flexible to accommodate new protocols
on the access networks, and M-in-M is one of the possibility. Probable, by
the time that VPLS/HVPLS solution would move forward, it's scalability and
the performance model would be already history, and M-i-M would be part of
the IEEE (who knows?).


A solution can be justifiable form political, market and theoretical
aspects.  Yes we recognize that VPLS/HVPLS doesn't scale but we would make
some special assumptions like no CE as L2 switching, no IP VPN or legacy
inter-working, no replication taken in consideration, no more than 1000 VPLS
and so on. It's obvious - from just mathematical\theoretical considerations
- that the VPLS/HVPLS doesn't scale.

If we just look to the real problems (without political clout), and where
GVPLS solutions is standing, we can realize  the VPLS system has a very fine
tunning aspects/parameters in order to scale and to perform well.   

Our product proofed already, that such systems, easily can scale beyond 5000
VPLS as is standing today. This is the reason the distributed model was
taken serious in consideration by the SPs - the draft it self is just an
expression of a solution that is working today, and it scales pretty well.

As simple answer, to your question - yes, I believe that GVPLS is needed. 




VR> Cheers 
VR>    Vasile 

-Vach