RE: decisions on L2 solutions documents

Vach,

  See my comments below - 

Cheers
 Vasile

-----Original Message-----
From: Vach Kompella [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