Subject: RE: Standard solution for L2VPN signaling already exist !!

From: "Sasha Vainshtein" <[email-masked]>
Date: Thu, 22 Mar 2007 21:58:16 +0200

Ali and all,
Sorry, missed that fact completely.
 
In this case draft-kompella-l2vpn-l2vpn-02.txt should be indeed
progressed as an Informational RFC.
 
Regards,
              Sasha

________________________________

From: Ali Sajassi (sajassi) [mailto:[email-masked]] 
Sent: Thursday, March 22, 2007 8:48 PM
To: Sasha Vainshtein; Luca Martini (lmartini)
Cc: Kireeti Kompella; [email-masked]; Loa Andersson
Subject: Standard solution for L2VPN signaling already exist !!

I am changing the "subject" to reflect the important fact that a
standard-track solution already exist for general L2VPN and VPWS
signaling which is specified in section 3.3 of
http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-08.txt
<http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-08.txt>
(sitting in RFC-Editor queue). Therefore, I think, at most the l2vpn
draft using BGP signaling (draft-kompella-l2vpn-l2vpn-02.txt) should be
just an informational RFC if we want to move it forward given that it
suffers from the issue I mention during the WG meeting where the
standard-track solution does NOT suffer.
 
-Ali

________________________________

	From: Sasha Vainshtein [mailto:[email-masked]] 
	Sent: Thursday, March 22, 2007 10:12 AM
	To: Luca Martini (lmartini)
	Cc: Kireeti Kompella; [email-masked]; Loa Andersson
	Subject: RE: Raising of hands ...

	Luca and all,
	I am not sure the PWE3 precedent you quote is applicable.
	 
	In that case we had TWO competing proposals solving essentially
the same problem.
	Not being able to reach a consensus, the PWE3 WG has opted to
publish both as Informational RFCs.
	 
	IF there were an alternative proposal, the L2VPN WG would have
several options:

	*	Publish one as  a Standards Track document and the other
one as Informational 
	*	Publish both as Standards Track documents if the
differences in the applicability justify that (this is how this WG has
published both RFC 4761 and RFC 4762 as PS) 
	*	Publish both as Informational if the differences in the
applicability are not substantial and consensus cannot be reached 
	*	Drop all (well, this is always an option and does not
really require alternative proposals:-)

	BUT I have not seen any alternative proposals so far. 
	 
	Simply stating that all the PWs in a PVWS are set using LDP is
not enough IMHO. 
	You would need something close to the control plane sections of
RFC 4762, only more complicated. 
	 
	Regards,
	            Sasha
________________________________

	From: Luca Martini [mailto:[email-masked]] 
	Sent: Thursday, March 22, 2007 5:16 PM
	To: Loa Andersson
	Cc: Kireeti Kompella; [email-masked]
	Subject: Re: Raising of hands ...

	Loa Andersson wrote: 

		Loa Andersson wrote:

			Yakov,
			
			not sure here, but I think the draft specifies
protocol and uses
			the normative IETF language (MUST, SHOULD, etc
...) (though Kireeti
			as usual is to lazy to capitalize.
			
			So, short of major rewriting this can be
"informational".

		So, short of major rewriting this can't be
"informational".

	Loa,
	We have several documents from PWE3 that are informational RFCs
yet they have the same characteristics as this document.
	So I do not agree that just because of the language of the
document or what it defines , this is going to be a standard
recommendation of the IETF.
	I believe it is standard IETF policy to standardize a single
common method. However it is also common practice to permit additional
informational RFCs when needed.
	I believe that we settled on an LDP PW , and the use of BGP for
autodiscovery.
	
	Luca 

	h

		sorry about that
		
		/Loa

			/Loa
			
			Yaakov Stein wrote:

				I just wanted to clarify that I raised
my hand for making
				draft-kompella-l2vpn-l2vpn a WG
document,
				but prefer it to be informational, not
standards-track.
				
				Y(J)S

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 22 Mar 2007 16:18:02 -0700 (PDT)

> Sorry, missed that fact completely.

Sasha, you were doing great, and thanks for that!  Now, don't give up 
so easily!  :-)

This is the only solution that addresses both the auto-discovery and 
signaling aspects of an L2 *VPN*.  The PWE solution only addresses 
signaling of a *PW*.  An L2VPN consists of a number of related PWs 
(such as all those requested by an enterprise).

I know full well that many would be happy to see this draft die, or be 
relegated to "informational", for whatever reasons.  However, there 
are two important points that are being missed:

a) this draft proposes very minor changes to an existing PS document
    (RFC 4761)
b) the arguments that led to the standardization of both RFC 4761 and
    RFC 4762 hold equally here.

> progressed as an Informational RFC.

Kireeti.
-------

---

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Fri, 23 Mar 2007 04:45:02 -0700

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]] 
> Sent: Thursday, March 22, 2007 4:18 PM
> To: Sasha Vainshtein
> Cc: [email-masked]
> Subject: draft-kompella-l2vpn-l2vpn-02 to PS
> 
> Sasha, you were doing great, and thanks for that!  Now, don't 
> give up so easily!  :-)
> 
> This is the only solution that addresses both the 
> auto-discovery and signaling aspects of an L2 *VPN*.  The PWE 
> solution only addresses signaling of a *PW*.  An L2VPN 
> consists of a number of related PWs (such as all those 
> requested by an enterprise).
> 

That is NOT true !! In the standard-track solution (described in the
draft below)
http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-08.txt 

Section 3.3.2 talks about the auto-discovery for L2VPN/VPWS and section
3.3.3 talks about signaling for the L2VPN/VPWS. So my question still
remains that if there is already a comprehensive standard-track solution
exist that covers both auto-discovery and signaling, then why do I want
another one which has even other issues ??

> I know full well that many would be happy to see this draft 
> die, or be relegated to "informational", for whatever 
> reasons.  However, there are two important points that are 
> being missed:
> 

In case of RFC 4761 & 4762, we didn't have a prior standard-track
solution and that's why we progressed both of them. But in this case, a
standard-track solution already exist !!

-Ali

> <http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-signaling-08.txt
> > draft using BGP signaling 
> (draft-kompella-l2vpn-l2vpn-02.txt) should 
> > be just an informational RFC if we want to move it forward 
> given that 
> > it suffers from the issue I mention during the WG meeting where the 
> > 	In that case we had TWO competing proposals solving 
> essentially the 
> > same problem.
> > 	Not being able to reach a consensus, the PWE3 WG has 
> opted to publish 
> > both as Informational RFCs.
> >
> > 	Simply stating that all the PWs in a PVWS are set using 
> LDP is not 
> > enough IMHO.
> > 	You would need something close to the control plane 
> sections of RFC 
> > 4762, only more complicated.
> >
> > 	Regards,
> > 	            Sasha
> > 			not sure here, but I think the draft 
> specifies protocol and uses
> > 			So, short of major rewriting this can 
> be "informational".
> >
> >

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 29 Mar 2007 18:24:23 +0100

It is always the strong preference of the IETF that we should only have 
ONE standards track method.

There is precedence for this in PWE3 with SATOP which was universally 
agreed as a TDM method and hence was standards track. With CESoPSN and 
TDMoIP - on which there was no universal agreement both were published 
as informational. The position here is that *if* the market eventually 
decides  on one of the two approaches  that will be advanced to 
standards track - meanwhile we are waiting for the market.

Similarly with the LDP vs RSVP PW signaling issue, it was agreed that 
unless there was a compelling reason to adopt a new signaling protocol 
we would remain with LDP for multi-segment PW signaling.

We already have an agreed method of L2VPN signaling and an agreed method 
of L2VPN discovery. There is no need for an additional standards track 
approach, and to introduce one would not only be confusing, but will 
increase costs as equipment ends up implementing both methods and may 
well introduce interworking issues.

We should take the normal approach here. If we think the concept merits 
an RFC, we should publish it as an informational. If at a later date the 
market decides that this is a preferred approach, then and only then 
should we consider standards track status for this approach.

- Stewart