Subject: RE: draft-kompella-l2vpn-l2vpn-02 to PS

From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Date: Tue, 3 Apr 2007 10:42:05 -0500

I understand the concern with introducing a 2nd standards' approach for
VPWS signaling. What's missing in the discussion is the flip side - the
operator's concern which was the rationale for 4761 being a standard. An
operator already supporting L3VPNs and VPLS using BGP signaling, will
need to use a different protocol for VPWS? For an operator, the cost
savings will be if they can use the same operations. To an operator,
it's L2VPN. Operators not using BGP have different needs (and
equipment). The need for a standard on this is no different than the
rationale for having standards. Vendors against this as a standard will
not be preventing it's use. And if they are supporting equipment in this
market, it would seem in their interest to want a standard.

On inter-domain, BGP is already a proven, scalable, easily applied (for
operators with BGP), working technology. When interdomain L2VPNs are
included in the charter, it would seem to be an obvious consideration.

Deborah

-----Original Message-----
From: Stewart Bryant [mailto:[email-masked]] 
Sent: Thursday, March 29, 2007 1:24 PM
To: [email-masked]
Subject: Re: draft-kompella-l2vpn-l2vpn-02 to PS

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

Kireeti Kompella wrote:
> On Thu, 22 Mar 2007, Sasha Vainshtein wrote:
>
>> Ali and all,
>> 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.
>
>> 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
> Kireeti.
> -------
>

---

From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Date: Tue, 3 Apr 2007 12:53:16 -0700

Hi Deborah,

I agree with you that from operational point of view, an operator who is
used to L3VPN operation would like to leverage its L3VPN mechanism for
its VPLS and VPWS services. However, the question is that where does the
bulk of this leverage comes from: BGP auto-discovery versus BGP
signaling. And if we look into the details, all the advantages that one
would get from L3VPN operation (both intra as well as inter AS
scenarios) come from BGP auto-discovery where one can use similar
constructs of L3VPN such as using RT to define a topology and RD for
unique identification in VPLS and VPWS as well as well as leveraging all
the scalability and advantages of BGP.

On the other hand, the BGP signaling of L3VPN and VPLS/VPWS are quite
different because in case of VPLS/VPWS, there must be a point-to-point
association between the two PEs whereas, there is no such requirement
what so ever in L3VPN and thus resulting in big divergence from L3VPN
operation model. As the matter of fact not only this is causing a
divergence but also introducing significant restriction for inter-AS
operation where now different Autonomous Systems must coordinate their
CE-id assignment among themselves. This restriction never existed in
L3VPN autonomous systems where they operated independently from one
another - as the name "Autonomous System" implies. 

Last but not least, one must also consider the interoperability between
BGP and LDP signaling for VPWS and how it works which I am sure it
easier said than done. 

Regards,
Ali

> From: BRUNGARD, DEBORAH A, ATTLABS [mailto:[email-masked]] 
> Sent: Tuesday, April 03, 2007 8:42 AM
> To: Stewart Bryant (stbryant); [email-masked]
> Subject: RE: draft-kompella-l2vpn-l2vpn-02 to PS
> 
> I understand the concern with introducing a 2nd standards' 
> approach for VPWS signaling. What's missing in the discussion 
> is the flip side - the operator's concern which was the 
> rationale for 4761 being a standard. An operator already 
> supporting L3VPNs and VPLS using BGP signaling, will need to 
> use a different protocol for VPWS? For an operator, the cost 
> savings will be if they can use the same operations. To an 
> operator, it's L2VPN. Operators not using BGP have different 
> needs (and equipment). The need for a standard on this is no 
> different than the rationale for having standards. Vendors 
> against this as a standard will not be preventing it's use. 
> And if they are supporting equipment in this market, it would 
> seem in their interest to want a standard.
> 
> On inter-domain, BGP is already a proven, scalable, easily 
> applied (for operators with BGP), working technology. When 
> interdomain L2VPNs are included in the charter, it would seem 
> to be an obvious consideration.
> 
> Deborah
> 
> 
> 
> 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.
> 
> 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
> 
> 
> Kireeti Kompella wrote:
> >> draft using BGP signaling 
> (draft-kompella-l2vpn-l2vpn-02.txt) should
> be
> protocol 
> >> and uses

---

From: "BALUS Florin" <[email-masked]>
Date: Wed, 4 Apr 2007 10:17:18 -0500

I agree with Ali, BGP Auto-discovery from L2VPN Signaling draft does
cover the requirements for similar operational model with L3VPNs.  

On the signaling side, I will add that we spent a lot of effort into
standardizing in PWE3 a number of P2P Signaling solutions to address SP
Requirements based on LDP Signaling.

Are we supposed to go back and to redo all this work for BGP signaling?
And then to keep discussing/developing two standards tracks for every
new PWE3 proposals? 

> Sent: Tuesday, April 03, 2007 12:53 PM
> To: BRUNGARD, DEBORAH A, ATTLABS; Stewart Bryant (stbryant); 
> [email-masked]
> I agree with you that from operational point of view, an 
> operator who is used to L3VPN operation would like to 
> leverage its L3VPN mechanism for its VPLS and VPWS services. 
> However, the question is that where does the bulk of this 
> leverage comes from: BGP auto-discovery versus BGP signaling. 
> And if we look into the details, all the advantages that one 
> scenarios) come from BGP auto-discovery where one can use 
> similar constructs of L3VPN such as using RT to define a 
> topology and RD for unique identification in VPLS and VPWS as 
> well as well as leveraging all the scalability and advantages of BGP.
> 
> On the other hand, the BGP signaling of L3VPN and VPLS/VPWS 
> are quite different because in case of VPLS/VPWS, there must 
> be a point-to-point association between the two PEs whereas, 
> there is no such requirement what so ever in L3VPN and thus 
> resulting in big divergence from L3VPN operation model. As 
> the matter of fact not only this is causing a divergence but 
> also introducing significant restriction for inter-AS 
> operation where now different Autonomous Systems must 
> coordinate their CE-id assignment among themselves. This 
> restriction never existed in L3VPN autonomous systems where 
> they operated independently from one another - as the name 
> "Autonomous System" implies. 
> 
> Last but not least, one must also consider the 
> interoperability between BGP and LDP signaling for VPWS and 
> how it works which I am sure it easier said than done. 
> 
> Regards,
> Ali
> 
> > approach for VPWS signaling. What's missing in the 
> discussion is the 
> > flip side - the operator's concern which was the rationale for 4761 
> > being a standard. An operator already supporting L3VPNs and 
> VPLS using 
> > BGP signaling, will need to use a different protocol for 
> VPWS? For an 
> > operator, the cost savings will be if they can use the same 
> > operations. To an operator, it's L2VPN. Operators not using 
> BGP have 
> > different needs (and equipment). The need for a standard on 
> this is no 
> > different than the rationale for having standards. Vendors against 
> > this as a standard will not be preventing it's use.
> > And if they are supporting equipment in this market, it 
> would seem in 
> > their interest to want a standard.
> > 
> > On inter-domain, BGP is already a proven, scalable, easily applied 
> > (for operators with BGP), working technology. When 
> interdomain L2VPNs 
> > are included in the charter, it would seem to be an obvious 
> > consideration.
> > 
> > Deborah
> > 
> > 
> > 
> > It is always the strong preference of the IETF that we should only 
> > have ONE standards track method.
> > 
> universally 
> agreed that 
> standards track 
> > 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
> > 
> only then 
> > (draft-kompella-l2vpn-l2vpn-02.txt) should be