RE: decisions on L2 solutions documents

Rick, Loa,
 
Based on the following comments, are there still any other issues that
should be considered in the next version which then could be considered for
WG status?
 
Dinesh
-----Original Message-----
From: Radoaca, Vasile [BL60:X624:EXCH] 
Sent: Tuesday, May 20, 2003 7:22 PM
To: 'Rick Wilder'; Loa Andersson
Cc: [email protected]
Subject: RE: decisions on L2 solutions documents



Rick, Loa 

 Below are my answers to your questions. 

Vasile 

-----Original Message----- 
From: Rick Wilder [ mailto:[email protected] <mailto:[email protected]>
] 
Sent: Thursday, May 15, 2003 6:34 PM 
To: Loa Andersson; Ould-Brahim, Hamid [CAR:1A00:EXCH] 
Cc: [email protected] 
Subject: RE: decisions on L2 solutions documents 



Agreed, Loa. 

Here are the questions/requests-for-clarification that came up. 

    a) how do the discovery and signaling parts of the document 
       relate to those described in the other solutions documents and which 
       of them are suggested to be mandatory to implement 

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

2) 
The GVPLS model is defined as an extension of the VPLS model, as HVPLS is
defined as an extension of it in order to optimize some of the parameters
(e.g. VC-Label)

There are two ways to mitigate these two elements: 
a) the lasserre-vkompella-vpls draft includes the Rosen's signaling model,
but it used only for non-distributed model. In this case, GVPLS would be
built using Rosen's mechanism

b) extends the current vpls signaling mechanism to include the components
needed for the distributed model 

We had intensive discussions between the authors of vpls, gvpls and rosen's
proposals to achieve a reasonable compromise. Unfortunately, at this point
in time, the authors of the lasserre-vkompella draft didn't consider to
include Rosen's signaling mechanism. As such, based on assumption 2) we
decided for GVPLS to extend the current vpls signaling mechanism. However,
the model is transparent to such extensions, should a decision would be
taken in favor of Rosen's signaling, then GVPLS solution can accommodate it.

Regarding the signaling protocol: the current draft has a default model, the
LDP protocol. However, the BGP signaling is presented as an alternative. Our
current resolution is the following: LDP is mandatory for GVPLS. 

                                        
The BGP signaling option would be defined in a separate draft. We would try
to see how we can accommodate our BGP signaling with
draft-kompella-ppvpn-vpls-01 bgp model.

Regarding the discovery process: We recognize that an auto-discovery
mechanism is needed for 3 VPLS components: 
- VPLS core [N-PE devices] 
- VPLS access [U-PE devices] 
- VPN Members/VPN End Points 

However, the M2P PW model has a very nice property: the U-PE and VPN Members
auto-discovery processes can be combined with LDP signaling protocol. While
the M2P is not mandatory, we considered that it is worth to present such
property and allow vendors to implement and interop.


    b) what is the status of the MAC-in-MAC encapsulation work in IEEE? 

> vasile 
A distributed model needs to have an access protocol that must comply with
the Service address scheme presented in GVPLS. 

There are two models  that can be used: PW (splice PW) or Mac-in-Mac.
Mac-in-Mac protocol is not mandatory. However, regarding  it's status in
IETF, the solution was socialized, and Nortel together with other
vendors/SPs are looking to present  a solution draft in the next IEEE
sessions.

From GVPLS perspective, Mac-in-Mac is just an option - it's shows that GVPLS
is flexible enough to adopt different access protocols, if the assumptions
are respected.

Probable the best resolution for GVPLS would be to adopt the splice PW as
the default model. Mac-in-Mac model would be explained in a separate draft
[ex. informational rfc] until a specific resolution would take place in
IEEE. 


    c) for the case where the U-PE network is a completely ethernet 
       switched network, and encapsulation like MAC-in-MAC is used, 
       what part of the architecture belongs to the IETF? 
> vasile 
definitively, the architecture of such access networks should belong to
IEEE. However, regardless of Mac-in-Mac or PW models, a control protocol
should be employed in such access networks - we are considering to submit a
GVPLS companion proposal for such control protocol. In addition, such
control protocol can be used also for Q-in-Q and HVPLS models


    c) definition of M2P PWs is outside the scope of this WG and 
       probably should go to PWE3 
> vasile 
we are considering to get the M2P PW topic in the PWE3 agenda. The M2P PW
can be used in other contexts than VPLS. 
The M2P PW is an option that can fit nicely with the multipoint nature of
the VPLS service - 

    d) how does the definition of semantics of the PW CW given 
       in the document relate to those defined in the PWE3 WG? 
> vasile 
the CW, is optional in both pwe3-ethernet-encap-01.txt and in gvpls drafts.
In GVPLS we use the format that was presented in the version mentioned
above, where the sequence number was replaced with the SRC-ID indication.

In the new GVPLS version we would use the new format presented in the
version pwe3-ethernet-encap-02.txt, where there are 16 bits reserved and 16
bits used for the sequence number. The 16 bits reserved "for further
extension" would be used in the VPLS context as SRC-ID indication. We
understand that such proposal needs to be discussed also in the PWE3 group.

However, a PW P2P used in the context of the VPLS can have a mechanism to
indicate the SP source address from where it's originating, without breaking
the original PW model. In the current solutions there are two ways to
indicate the SP Source address: a) using the Control Plane [ex.VC-label ] or
using the Data Plane [ex. CW]. In our current experiments by far, the Data
Plane model scale and perform better than the Control  plane model. 

IF we use PW P2P with Source indication, in the control plane, then the
natural evolution is to combine the LSPs that have the same destination into
a M2P PW.


Some conclusions: 
As we understand the questions, I think there are ways to move forward, and
to see GVPLS as an extension of the  vpls non-distributed model
[draft-lasserre-vkomeplla-vpls], and worth to be continued as working
document. However, a revised version would be taken in consideration for the
next IETF meeting; some components as BGP signaling and MAC-in-MAC would be
presented in separate drafts. The interoperability aspects between vpls and
gvpls would still be  maintained in the draft, if there are not other
opinions.

Cheers 
   Vasile 



-----Original Message----- 
From: Loa Andersson [ mailto:[email protected] <mailto:[email protected]> ] 
Sent: Thursday, May 15, 2003 4:08 PM 
To: Hamid Ould-Brahim 
Cc: Rick Wilder; [email protected] 
Subject: Re: decisions on L2 solutions documents 

Rick, 

the question from Hamid is what I should call "loaded". The real issue here
is (evn if you felt you had the wg support from the mailing list at the
time, which I don't know), that the issues the AD / wg chair discussion
should be made available to the list/wg.

Review results may change how you feel about making things wg doc or not,
even if they come form ADs :) 

Mailing list discussion of those review results may lift or confirm those
conserns. 

/Loa 

Hamid Ould-Brahim wrote: 
> Rick, 
> 
>  > 
>  > - GVPLS/LPE draft-radoaca-ppvpn-gvpls-01.txt : This draft is  > not 
> made a WG document at this time. Several questions have  > come up 
> regarding this document during discussions between  > the ADs and WG 
> chairs. In order to make an informed decision,  > these questions will 
> be posted shortly to begin a discussion.  > 
> 
> In your opinion as ppvpn chair was there consensus on the mailing list 
> that this draft should advance to WG doc status? 
> 
> Hamid. 
> 


-- 
/Loa 

mobile + 46 739 81 21 64 
email: [email protected]