Subject: RE: decisions on L2 solutions documents

From: "Vasile Radoaca" <[email-masked]>
Date: Tue, 20 May 2003 19:22:06 -0400

Rick, Loa

 Below are my answers to your questions.

Vasile

-----Original Message-----
From: Rick Wilder [mailto:[email-masked]] 
Sent: Thursday, May 15, 2003 6:34 PM
To: Loa Andersson; Ould-Brahim, Hamid [CAR:1A00:EXCH]
Cc: [email-masked]
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-masked]] 
Sent: Thursday, May 15, 2003 4:08 PM
To: Hamid Ould-Brahim
Cc: Rick Wilder; [email-masked]
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-masked]

---

From: "Vach Kompella" <[email-masked]>
Date: Fri, 30 May 2003 09:49:56 -0700

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

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 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 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 problem.

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

VR> 2)
VR> The GVPLS model is defined as an extension of the VPLS model, as HVPLS is
defined as an extension of
VR> it in order to optimize some of the parameters (e.g. VC-Label)
VR> There are two ways to mitigate these two elements:
VR> a) the lasserre-vkompella-vpls draft includes the Rosen's signaling model,
but it used only for non
VR> distributed model. In this case, GVPLS would be built using Rosen's
mechanism
VR> b) extends the current vpls signaling mechanism to include the components
needed for the distributed
VR> model
VR> We had intensive discussions between the authors of vpls, gvpls and rosen's
proposals to achieve a
VR> reasonable compromise. Unfortunately, at this point in time, the authors of
the lasserre-vkompella
VR> draft didn't consider to include Rosen's signaling mechanism. As such, based
on assumption 2) we
VR> decided for GVPLS to extend the current vpls signaling mechanism. However,
the model is transparent
VR> to such extensions, should a decision would be taken in favor of Rosen's
signaling, then GVPLS
VR> solution can accommodate it.
VR> Regarding the signaling protocol: the current draft has a default model, the
LDP protocol. However,
VR> the BGP signaling is presented as an alternative. Our current resolution is
the following: LDP is
VR> mandatory for GVPLS.

Vach>> There are two issues here.  The first is whether we need a 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 PWs in
conjuction with a learning
Vach>> bridge in the position of the MTU to make a distributed VPLS node.  I
don't think we need to have
Vach>> another way to create a distributed VPLS node.

Vach>> To the second point, the primary difference between the Rosen draft and
the HVPLS draft is in
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.  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.

Vach>> Again, you mention that you would do draft-rosen.  Why are you specifying
a different protocol
Vach>> then?

Vach>> If LDP is mandatory, why do you feel it is necessary to describe BGP
signaling in your draft?
Vach>> What is different about your BGP signaling and draft-kompella?

VR> The BGP signaling option would be defined in a separate draft. We would try
to see how we can
VR> accommodate our BGP signaling with draft-kompella-ppvpn-vpls-01 bgp model.
VR> Regarding the discovery process: We recognize that an auto-discovery
mechanism is needed for 3 VPLS
VR> components:
VR> - VPLS core [N-PE devices]
VR> - VPLS access [U-PE devices]
VR> - VPN Members/VPN End Points
VR> However, the M2P PW model has a very nice property: the U-PE and VPN Members
auto-discovery
VR> processes can be combined with LDP signaling protocol. While the M2P is not
mandatory, we considered
VR> that it is worth to present such property and allow vendors to implement and
interop.

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 the
signaling that are
Vach>> described in the LDP signaling.  I don't know how you are going to add
them to the BGP signaling.
Vach>> Are the BGP signaling components such as label blocks and VE IDs 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 to keep
gvpls interoperable
Vach>> with HVPLS?

Rick>>     b) what is the status of the MAC-in-MAC encapsulation work in IEEE?
VR> > vasile
VR> A distributed model needs to have an access protocol that must comply with
the Service address
VR> scheme presented in GVPLS.
VR> There are two models  that can be used: PW (splice PW) or Mac-in-Mac.
Mac-in-Mac protocol is not
VR> mandatory. However, regarding  it's status in IETF, the solution was
socialized, and Nortel together
VR> with other vendors/SPs are looking to present  a solution draft in the next
IEEE sessions.
VR> From GVPLS perspective, Mac-in-Mac is just an option - it's shows that GVPLS
is flexible enough to
VR> adopt different access protocols, if the assumptions are respected.
VR> Probable the best resolution for GVPLS would be to adopt the splice PW as
the default model. Mac-in
VR> Mac model would be explained in a separate draft [ex. informational rfc]
until a specific resolution
VR> would take place in IEEE.

Rick>>     c) for the case where the U-PE network is a completely ethernet
Rick>>        switched network, and encapsulation like MAC-in-MAC is used,
Rick>>        what part of the architecture belongs to the IETF?

VR> > vasile
VR> definitively, the architecture of such access networks should belong to
IEEE. However, regardless of
VR> Mac-in-Mac or PW models, a control protocol should be employed in such
access networks - we are
VR> considering to submit a GVPLS companion proposal for such control protocol.
In addition, such
VR> control protocol can be used also for Q-in-Q and HVPLS models

Rick>>     c) definition of M2P PWs is outside the scope of this WG and
Rick>>        probably should go to PWE3
VR> > vasile
VR> we are considering to get the M2P PW topic in the PWE3 agenda. The M2P PW
can be used in other
VR> contexts than VPLS.
VR> The M2P PW is an option that can fit nicely with the multipoint nature of
the VPLS service -
VR>     d) how does the definition of semantics of the PW CW given
VR>        in the document relate to those defined in the PWE3 WG?
VR> > vasile
VR> the CW, is optional in both pwe3-ethernet-encap-01.txt and in gvpls drafts.
In GVPLS we use the
VR> format that was presented in the version mentioned above, where the sequence
number was replaced
VR> with the SRC-ID indication.
VR> In the new GVPLS version we would use the new format presented in the
version pwe3-ethernet-encap-
VR> 02.txt, where there are 16 bits reserved and 16 bits used for the sequence
number. The 16 bits
VR> reserved "for further extension" would be used in the VPLS context as SRC-ID
indication. We
VR> understand that such proposal needs to be discussed also in the PWE3 group.
VR> However, a PW P2P used in the context of the VPLS can have a mechanism to
indicate the SP source
VR> address from where it's originating, without breaking the original PW model.
In the current
VR> solutions there are two ways to indicate the SP Source address: a) using the
Control Plane [ex.VC-
VR> label ] or using the Data Plane [ex. CW]. In our current experiments by far,
the Data Plane model
VR> scale and perform better than the Control  plane model.
VR> IF we use PW P2P with Source indication, in the control plane, then the
natural evolution is to
VR> combine the LSPs that have the same destination into a M2P PW.

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

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 currently in any
IEEE charter
Vach>>   - the BGP in GVPLS is too similar to draft-kompella-vpls to 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 PWE3

Vach>> Can you stil justify the GVPLS draft?

VR> Cheers
VR>    Vasile

-Vach