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


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