Subject: decisions on L2 solutions documents

From: "Rick Wilder" <[email-masked]>
Date: Thu, 15 May 2003 17:06:39 -0400

Below are decisions regarding L2 solution documents which have been considered for WG document status since the SF meeting.

- VPLS  draft-lasserre-vkompella-ppvpn-vpls-04.txt is now a WG document based on strong support in SF and on this mailing list.  

- VPLS draft-kompella-ppvpn-vpls-01 is now a WG draft based on the support shown on the list.  The discussion of the appropriateness of BGP for VPLS signaling will continue on the list and, if needed, in Vienna.

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

- Radius for PE-Based VPN Discovery (draft-heinanen-radius-pe-discovery) : This draft is not made a WG document at this time. Though the draft received a high degree of support in SF, concerns have been brought to the attention of the ADs on the appropriateness of this use of Radius. Before we can make an informed decision, we would like the WG to have this discussion. Concerns will be forwarded to the WG shortly.
 
-Provisioning Models and Endpoint Identifiers in L2VPN Signaling (draft-rosen-ppvpn-l2-signaling-03.txt)
-IP over LAN Service (shah-ppvpn-ipls-01.txt)
These drafts require further discussion prior to evaluating WG support.

Rick

---

From: "Rick Wilder" <[email-masked]>
Date: Thu, 15 May 2003 18:33:55 -0400

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

    b) what is the status of the MAC-in-MAC encapsulation work 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?

    c) definition of M2P PWs is outside the scope of this WG and
       probably should go to PWE3

    d) how does the definition of semantics of the PW CW given
       in the document relate to those defined in the PWE3 WG?

-----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: "Vasile Radoaca" <[email-masked]>
Date: Fri, 16 May 2003 10:28:07 -0400

Loa/Rick

My whish was to have these questions public before the decision was made, so
we will be  more effective to defend our postion.
While your questions are reasonable and important for the debate, I do have
my self couple of clarifications that I would like to be addressed:

- these are the only questions regarding the draft?
- the decision for GVPLS as WD is revocable or depends how satisfactory 
  are the answers to such questions? 
- if the decision is not irrevocable, do we have a deadline till the debate
would proof positive or not ? A new version of the draft, that would addres
your questions, would  a prefer way to go
- can we recognize that it was support in the  group from both vendors and
SPs? 

I would try to answer to your questions during the next days. However, I
would like to invite other people to participate in the debate, that have
supported the draft, and they know GVPLS is working in the field and is
scalable as  is defined in the draft.

In a simplistic view, I see the following relationship:
- vpls < hvpls < gvpls

VPLS is the default one - probable every vendor thought about this solution.

HVPLS was invented because VPLS doesn't scale and impose some restrictions
that would be hard  validated in the real field. HVPLS does scale in only
one dimension - VC-LABEL space.
GVPLS was invented to increase the scalability in multiple dimensions, and
to distribute the load between different network components so the network
performance and stability is maintained. As any other solution a this level,
there are  more "liberal" ideas proposed in the draft [like M2P], and
probable they request more time to be incorporated in the current cycle of
thinking. 

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

    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

-----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: "Rick Wilder" <[email-masked]>
Date: Fri, 16 May 2003 18:35:14 -0400

Vasile,

See my comments in-line.

-----Original Message-----
From: Vasile Radoaca [mailto:[email-masked]] 
Sent: Friday, May 16, 2003 8:28 AM
To: Rick Wilder; Loa Andersson; Hamid Ould-Brahim
Cc: [email-masked]
Subject: RE: decisions on L2 solutions documents

Loa/Rick 

My whish was to have these questions public before the decision was
made, so we will be  more effective to defend our postion.

I think this is in line with the course we are taking. We will have a
public discussion of these questions prior to making a decision about
the future of the draft in the WG.

While your questions are reasonable and important for the debate, I do
have my self couple of clarifications that I would like to be addressed:

I can't guarantee that. Those are the questions so far. During the
discussion others could come up. In a reasonable time we should reach a
point where we can make an informed decision.

All that has been said is that we'll have a discussion, get more
information, and then decide.

- if the decision is not irrevocable, do we have a deadline till the
debate would proof positive or not ? A new version of the draft, that
would addres your questions, would  a prefer way to go

I don't think we want a long-term on-going debate. Let Loa and I decide
schedule details and get back to you early next week.

- can we recognize that it was support in the  group from both vendors
and SPs? 

The email list input is not forgotten.

I would try to answer to your questions during the next days. However, I
would like to invite other people to participate in the debate, that
have supported the draft, and they know GVPLS is working in the field
and is scalable as  is defined in the draft.

Input is invited from the WG as a whole as long as it can be focused on
clarifying the draft and analysis of its merits.

VPLS is the default one - probable every vendor thought about this
solution. 
HVPLS was invented because VPLS doesn't scale and impose some
restrictions that would be hard  validated in the real field. HVPLS does
scale in only one dimension - VC-LABEL space.

GVPLS was invented to increase the scalability in multiple dimensions,
and to distribute the load between different network components so the
network performance and stability is maintained. As any other solution a
this level, there are  more "liberal" ideas proposed in the draft [like
M2P], and probable they request more time to be incorporated in the
current cycle of thinking. 

Cheers 
   Vasile 

Thanks for your help, Vasile!

Rick

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

-----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 :) 

/Loa 

-- 
/Loa 

mobile + 46 739 81 21 64 
email: [email-masked]

---

From: "Dinesh Mohan" <[email-masked]>
Date: Tue, 27 May 2003 11:08:26 -0400

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-masked]
Subject: RE: decisions on L2 solutions documents

Rick, Loa 

 Below are my answers to your questions. 

Vasile 

-----Original Message----- 
From: Rick Wilder [ mailto:[email-masked] <mailto:[email-masked]>
] 

Agreed, Loa. 

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

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

> 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

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

> 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] <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, 

/Loa 

-- 
/Loa 

mobile + 46 739 81 21 64 
email: [email-masked]