Subject: RE: L2vpn Digest, Vol 36, Issue 2

From: "Yu, Henry" <[email-masked]>
Date: Tue, 3 Apr 2007 22:04:07 -0600

As a network operator that has been using VPLS for a number of years, I'm very much a proponent of moving the draft-kompella-l2vpn-l2vpn along as a WG document within the Standards track.  Interprovider VPNs have been addressed within rfc4364 and draft-kompella-l2vpn-l2vpn addresses these same options in a similar manner.   Deborah made a very valid point when she stated "For an operator, the cost savings will be if they can use the same operations", which completely applies to why I would like to see draft-kompella-l2vpn-l2vpn stay within the Standards track.

Cheers,

Henry

Sr. Manager, IP Architecture and Security

Time Warner Telecom

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, April 03, 2007 10:00 AM
To: [email-masked]
Subject: L2vpn Digest, Vol 36, Issue 2

Send L2vpn mailing list submissions to
        [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
        https://www1.ietf.org/mailman/listinfo/l2vpn
or, via email, send a message with subject or body 'help' to
        [email-masked]

You can reach the person managing the list at
        [email-masked]

When replying, please edit your Subject line so it is more specific than "Re: Contents of L2vpn digest..."

Today's Topics:

   1. RE: draft-kompella-l2vpn-l2vpn-02 (Ali Sajassi (sajassi))
   2. RE: draft-kompella-l2vpn-l2vpn-02 to PS
      (BRUNGARD, DEBORAH A, ATTLABS)

----------------------------------------------------------------------

Message: 1
Date: Mon, 2 Apr 2007 10:49:17 -0700
From: "Ali Sajassi \(sajassi\)" <[email-masked]>
Subject: RE: draft-kompella-l2vpn-l2vpn-02
To: "Kireeti Kompella" <[email-masked]>
Cc: [email-masked]
Message-ID:
        <[email-masked]>
Content-Type: text/plain;       charset="us-ascii"

Kireeti,

Nice try :-) Although the charter doesn't include inter-AS and needs to be updated (as per charter text itself), the assumption all along has been that all L2VPN solutions will cover inter-AS. As the matter of fact, the L2VPN-requirement RFC (RFC 4665) has a clear set of requirements for inter-AS. Furthermore, the L2VPN-framework RFC (RFC
4664) also covers inter-AS. And last but not least, all the current standard-track VPLS and VPWS solutions do cover inter-AS scenarios. So, I would say we should spend our efforts in fixing the problem rather than bypassing it.

Cheers,
Ali

> -----Original Message-----
> From: Kireeti Kompella [mailto:[email-masked]]
> Sent: Sunday, April 01, 2007 8:43 PM
> To: Ali Sajassi (sajassi)
> Cc: Ian Stanley; [email-masked]
> Subject: RE: draft-kompella-l2vpn-l2vpn-02
>
> Ali,
>
> On Fri, 30 Mar 2007, Ali Sajassi (sajassi) wrote:
>
> > Because of a few implementation of this solution, we are in
> favor of
> > progressing it as informational RFC; otherwise, we would not even
> > suggest the status of informational RFC for this draft. I
> think what
> > people are saying is that before we talk about
> standard-track RFC, we
> > need to really look at some of the issues that are related to this
> > draft such as inter-AS as well as we need to look at
> interoperability
> > issue between this solution and the current standard-track solution.
>
> Inter-AS is NOT in the L2VPN charter, so it makes no sense to use that
> to block the progress of this document.  In point of fact, the
> inter-AS solution for this document is much more mature than that of
> alternative solutions, and perhaps more to the point, there have been
> inter-AS *deployments* since March 2004.
>
> > So, I
> > think progressing this draft as informational RFC is a good
> step till
> > these issues are addressed.
> >
> > Cheers,
> > Ali
> >
> >
> > ________________________________
> >
> >     From: Ian Stanley [mailto:[email-masked]]
> >     Sent: Friday, March 30, 2007 3:19 PM
> >     To: Dutta, Pranjal (Pranjal); Max Ng; Ali Sajassi (sajassi);
> > [email-masked]; Bruno De Troch; Shane Amante; [email-masked]
> >     Subject: Re: draft-kompella-l2vpn-l2vpn-02
> >
> >
> >     Interesting debate and positioning, but one question of clarity
> > please..."how does the market indicate its need to you to start the
> > process for standard track"
> >
> >     I would have thought that with many implementations of
> this would be
> > enough
> >
> >     Cheers
> >     Ian
> >
> >
> >     On 30/3/07 5:53 PM, "Dutta, Pranjal (Pranjal)"
> > <[email-masked]> wrote:Dutta, Pranjal (Pranjal)
> >
> >
> >
> >             My "support" meant supporting Ali's comment. I
> hope it didn't mean
> >             something else :-). Yes, my preference is only
> for *informational*.
> >
> >             -----Original Message-----
> >             From: Max Ng [mailto:[email-masked]]
> >             Sent: Friday, 30 March, 2007 1:06 PM
> >             To: Dutta, Pranjal (Pranjal); 'Ali Sajassi (sajassi)';
> >             [email-masked]; 'Bruno De Troch'; 'Shane Amante';
> > [email-masked]
> >             Subject: RE: draft-kompella-l2vpn-l2vpn-02
> >
> >             A lot has been mentioned and discussed. My
> preference is still to go
> >             with
> >             informational on grounds that we focus on what
> has already been
> > agreed
> >             upon
> >             and rid the confusion. Should the market in the
> near future decide
> >             otherwise, we can progress it to Standard track.
> >
> >             -----Original Message-----
> >             From: Dutta, Pranjal (Pranjal)
> > [mailto:[email-masked]]
> >             Sent: Friday, March 30, 2007 2:41 PM
> >             To: Ali Sajassi (sajassi);
> [email-masked]; Bruno De Troch;
> > Shane
> >             Amante; [email-masked]
> >             Subject: RE: draft-kompella-l2vpn-l2vpn-02
> >
> >             Completely support this. The l2vpn-sig already
> adopted for LDP based
> >             method.
> >             We have wide deployments for both SS-PW and
> MS-PW with LDP signaling
> > for
> >             PWE3.
> >
> >             -Pranjal
> >
> >             -----Original Message-----
> >             From: Ali Sajassi (sajassi) [mailto:[email-masked]]
> >             Sent: Friday, 30 March, 2007 11:11 AM
> >             To: [email-masked]; Bruno De Troch; Shane Amante;
> > [email-masked]
> >             Subject: RE: draft-kompella-l2vpn-l2vpn-02
> >
> >
> >             And the current standard-track solution is based on the
> > PWE3 control
> >             protocol (RFC 4447).
> >
> >             -Ali
> >
> >             > -----Original Message-----
> >             > From: Renwei Li [mailto:[email-masked]]
> >             > Sent: Thursday, March 29, 2007 6:37 PM
> >             > To: Ali Sajassi (sajassi); 'Bruno De Troch';
> 'Shane Amante';
> >             > [email-masked]
> >             > Subject: RE: draft-kompella-l2vpn-l2vpn-02
> >             >
> >             > When we decide something to be a standard track RFC or
> >             > informational RFC, do we need to take into
> account how many
> >             > deployments there are? If so, I see more
> implementations and
> >             > deployments based on pwe3-control-protocol draft.
> >             >
> >             > On the other hand, a standard should be
> unique unless it is
> >             > intended to potentially obsolete the other
> ones. Do we intend
> >             > to obsolete other drafts using this new one?
> >             >
> >             > Just some quick thoughts...
> >             >
> >             > Renwei
> >             >
> >             >
> >             >
> >             >
> >             >
> >             > -----Original Message-----
> >             > From: Ali Sajassi (sajassi) [mailto:[email-masked]]
> >             > Sent: Thursday, March 29, 2007 3:31 PM
> >             > To: Bruno De Troch; Shane Amante; [email-masked]
> >             > Subject: RE: draft-kompella-l2vpn-l2vpn-02
> >             >
> >             > ... And I know many more networks that don't have such
> >             > deployment and some of them plan to do theirs
> based on the
> >             > standard-track solution specified in the
> l2vpn-signaling
> >             > draft. So, as I have said previously, given
> that we have a
> >             > comprehensive solution which is
> standard-track, there is no
> >             > need for another one. However, as mentioned before, I
> >             > wouldn't mind this draft to become informational RFC.
> >             >
> >             > -Ali
> >             >
> >             > > -----Original Message-----
> >             > > From: Bruno De Troch [mailto:[email-masked]]
> >             > > Sent: Thursday, March 29, 2007 1:17 PM
> >             > > To: Shane Amante; [email-masked]
> >             > > Subject: RE: draft-kompella-l2vpn-l2vpn-02
> >             > >
> >             > > I know multiple networks where this is
> already deployed, so
> >             > I prefer
> >             > > it to become a standard.
> >             > >
> >             > >
> >             > > Cheers,
> >             > >
> >             > > Bruno
> >             > >
> >             > > > -----Original Message-----
> >             > > > From: Shane Amante [mailto:[email-masked]]
> >             > > > Sent: Wednesday, March 21, 2007 17:27
> >             > > > To: [email-masked]
> >             > > > Subject: draft-kompella-l2vpn-l2vpn-02
> >             > > >
> >             > > > I was approached by several people
> outside the hallway just
> >             > > after the
> >             > > > L2VPN WG meeting expressing confusion
> over a poll in the
> >             > room about
> >             > > > making this draft a WG document, in
> particular over the
> > 'Intended
> >             > > > Status' of this WG draft, e.g.:
> Informational or Standards
> > Track.
> >             > > > Unfortunately, we were abruptly cut off
> after running over
> >             > > our time at
> >             > > > the end of the meeting, in order so they
> could convert
> >             > the room over
> >             > > for
> >             > > > the IETF plenary session, so I didn't
> have time to clarify
> >             > > it.  So, my
> >             > > > apologies for the confusion.
> >             > > >
> >             > > > Let me now ask a hopefully more precise question
> > here: How
> >             > > many people
> >             > > > are in favor of making the aforementioned
> draft a WG
> >             > draft *if* the
> >             > > > 'Intended Status' is Standards Track?
> >             > > >
> >             > > > Thanks,
> >             > > >
> >             > > > -shane
> >             > >
> >             >
> >             >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >     Regards,
> >     Ian Stanley
> >     National Manager
> >     Architecture & Design
> >     IP & Data
> >     Core Networks | Engineering
> >     02 9396 8508
> >     0419 257221
> >
> >     This communication may contain CONFIDENTIAL or
> copyright information
> > of Telstra Corporation Limited (ABN 33 051 775 556). If you
> are not an
> > intended recipient, you MUST NOT keep, forward, copy, use, save or
> > rely on this communication, and any such action is unauthorised and
> > prohibited. If you have received this communication in
> error, please
> > reply to this email to notify the sender of its incorrect delivery,
> > and then delete both it and your reply. Thank you.
> >
> >
> >
> >
>
> Kireeti.
> -------
>

------------------------------

Message: 2
Date: Tue, 3 Apr 2007 10:42:05 -0500
From: "BRUNGARD, DEBORAH A, ATTLABS" <[email-masked]>
Subject: RE: draft-kompella-l2vpn-l2vpn-02 to PS
To: <[email-masked]>, <[email-masked]>
Message-ID:
        <[email-masked]>
Content-Type: text/plain;       charset="us-ascii"

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

------------------------------

_______________________________________________
L2vpn mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/l2vpn

End of L2vpn Digest, Vol 36, Issue 2
************************************

The content contained in this electronic message is not intended to
constitute formation of a contract binding TWTC.  TWTC will be
contractually bound only upon execution, by an authorized officer, of
a contract including agreed terms and conditions or by express
application of its tariffs.

This message is intended only for the use of the individual or entity
to which it is addressed. If the reader of this message is not the
intended recipient, or the employee or agent responsible for
delivering the message to the intended recipient, you are hereby
notified that any dissemination, distribution or copying of this
message is strictly prohibited. If you have received this
communication in error, please notify us immediately by replying to
the sender of this E-Mail or by telephone.

---

From: Luca Martini <[email-masked]>
Date: Wed, 04 Apr 2007 08:51:31 -0600

> As a network operator that has been using VPLS for a number of years, I'm very much a proponent of moving the draft-kompella-l2vpn-l2vpn along as a WG document within the Standards track.  Interpro…
Yu,

To the point you make above , since we already have standard track 
solutions that are widely deployed, how would it help to make yet 
another solution that is not as widely deployed standard track ?
If anything it would make the inter-operations much more difficult as 
different operators would choose different non inter-operable standards.

Luca

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 4 Apr 2007 11:08:02 -0400

> Yu, Henry wrote:
>> As a network operator that has been using VPLS for a number of  
>> years, I'm very much a proponent of moving the draft-kompella- 
>> l2vpn-l2vpn along as a WG document within the Standards track.   
>> Interprovider VPNs have been addressed within rfc4364 and draft- 
>> kompella-l2vpn-l2vpn addresses these same options in a similar  
>> manner.   Deborah made a very valid point when she stated "For an  
>> operator, the cost savings will be if they can use the same  
>> operations", which completely applies to why I would like to see  
>> draft-kompella-l2vpn-l2vpn stay within the Standards track.
>>
>>
> Yu,
>
> If anything it would make the inter-operations much more difficult  
> as different operators would choose different non inter-operable  
> standards.

	My question is are there any situations where this and the other  
standards track
solution are deployed simultaneously? Also, are there any multi- 
vendor deployments where
this solution alone, or in conjunction with the existing solution is/ 
are in use?

	--Tom

>> When replying, please edit your Subject line so it is more  
>> specific than "Re: Contents of L2vpn digest..."
>>
>>
>> Today's Topics:
>>
>> Nice try :-) Although the charter doesn't include inter-AS and  
>> needs to be updated (as per charter text itself), the assumption  
>> all along has been that all L2VPN solutions will cover inter-AS.  
>> As the matter of fact, the L2VPN-requirement RFC (RFC 4665) has a  
>> clear set of requirements for inter-AS. Furthermore, the L2VPN- 
>> framework RFC (RFC
>> 4664) also covers inter-AS. And last but not least, all the  
>> current standard-track VPLS and VPWS solutions do cover inter-AS  
>> scenarios. So, I would say we should spend our efforts in fixing  
>> the problem rather than bypassing it.
>>
>> Cheers,
>> Ali
>>
>>
>>
>> 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
>>
>>
>>
>> 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:
>>