From lizhong.jin@zte.com.cn Fri Jul 1 04:47:22 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E1A21F868F; Fri, 1 Jul 2011 04:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.838 X-Spam-Level: X-Spam-Status: No, score=-101.838 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qM3gjh+8MZ2R; Fri, 1 Jul 2011 04:47:21 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 400C921F8689; Fri, 1 Jul 2011 04:47:20 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 48643314101978; Fri, 1 Jul 2011 19:46:14 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 13796.7481467973; Fri, 1 Jul 2011 19:47:12 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p61Bl5Dc009505; Fri, 1 Jul 2011 19:47:05 +0800 (GMT-8) (envelope-from lizhong.jin@zte.com.cn) In-Reply-To: To: lamberto.sterling@gmail.com, maillist.ed@gmail.com Subject: Re: [mpls] Request comments for HSMP LSP MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: lizhong.jin@zte.com.cn Date: Fri, 1 Jul 2011 19:46:34 +0800 X-MIMETrack: S/MIME Sign by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-07-01 19:47:07, Serialize by Notes Client on JinLiZhong127666/user/zte_ltd(Release 6.5.6|March 06, 2007) at 2011-07-01 19:47:07, Serialize complete at 2011-07-01 19:47:07, S/MIME Sign failed at 2011-07-01 19:47:07: The cryptographic key was not found, Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-07-01 19:47:09, Serialize complete at 2011-07-01 19:47:09 Content-Type: multipart/alternative; boundary="=_alternative 0040BD56482578C0_=" X-MAIL: mse02.zte.com.cn p61Bl5Dc009505 Cc: l2vpn@ietf.org, mpls@ietf.org, Ice , tictoc@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 11:47:22 -0000 This is a multipart message in MIME format. --=_alternative 0040BD56482578C0_= Content-Type: text/plain; charset="US-ASCII" Hi Edward, Lamberto and all, Sorry for the later reply. And no, when apply HSMP LSP to VPLS, the path from leaf PE to root PE is exactly the shortest path. mLDP leaf will send mapping message to root node, choosing the path with routing table, and this path is the shortest path from leaf to root. We have updated the draft with more clarification of the use cases, and added new use case of VPLS application. You can get the new draft from link: http://tools.ietf.org/html/draft-jin-jounay-mpls-mldp-hsmp-03 Thank you. Lizhong > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 9 Jan 2011 02:50:16 +0100 > From: Lamberto Sterling > Subject: Re: [mpls] Request comments for HSMP LSP > To: maillist.ed@gmail.com, lizhong.jin@zte.com.cn > Cc: l2vpn@ietf.org, mpls@ietf.org, Ice , > tictoc@ietf.org, N.Leymann@telekom.de > Message-ID: > > Content-Type: text/plain; charset="iso-8859-1" > > Hi guys, > Sorry for the email subject. Change it now. > > Lamberto > > On Sat, Jan 8, 2011 at 5:19 PM, Lamberto Sterling < > lamberto.sterling@gmail.com> wrote: > > > Hi Lizhong, Edward, > > It seems that it is a good idea to apply HSMP LSP to VPLS, and the > > broadcast/unicast/unknow packet would be optimized. However, the path from > > leaf to root may not be the best path compared with current VPLS using P2P > > LSP, which is not a critical issue. > > > > Thanks > > Lamberto > > > > > > > >> > >> ------------------------------ > >> > >> > >> Date: Wed, 5 Jan 2011 15:50:45 +0800 > >> From: lizhong.jin@zte.com.cn > >> Subject: Re: [mpls] Request comments for HSMP LSP > >> To: Ed > >> Cc: l2vpn@ietf.org, mpls@ietf.org, Ice , > >> N.Leymann@telekom.de, tictoc@ietf.org > >> Message-ID: > >> < > >> OF4BA0BF75.A883E04C-ON4825780F.002802E4-4825780F.002B2AB9@zte.com.cn> > >> Content-Type: text/plain; charset="us-ascii" > >> > >> Hi Edward, > >> Thank you for the comments. I add l2vpn maillist in cc list. I agree with > >> the application you proposed, and in order to improve the scalability of > >> VPLS, P2MP PW multiplexed to HSMP LSP could be used for VPLS. Actually > >> this is a good application case for P2MP PW with reverse path (section > >> 4.4, draft-ietf-pwe3-p2mp-pw-00). We can add some description about this > >> use case. > >> > >> Regards > >> Lizhong > >> > >> > >> Ed wrote on 2011-01-05 15:05:30: > >> > >> > Hi Lizhong, > >> > > >> > I think one possible application for HSMP LSPs is to reduce the > >> > overall broadcast/multicast utilization on a VPLS. In current VPLS > >> > implementations with a full mesh of P2P LSPs between PEs, broadcast, > >> > multicast and unknown traffic are not efficiently propagated on the > >> > physical links between PEs and Ps. > >> > > >> > In the VPLS implementation scenario with HSMP LSPs, each PE signals > >> > a HSMP LSP with itself as a root to all other PEs in the VPLS. > >> > Thereafter, all broadcast/multicast/unknown traffic from this PE > >> > will use this HSMP LSP. Unicast traffic from a particular PE (e.g. > >> > PE1) to another PE (e.g. PE2) will be sent from leaf to root using > >> > the HSMP LSP where PE2 is the root. > >> > > >> > This simplifies the VPLS implementation by: > >> > - Reducing traffic utilization from broadcast, multicast > >> > and unknown traffic > >> > - Reducing the total number of LSPs maintained by each PE > >> > (i.e. instead of requiring a full mesh of LSPs, now only require one > >> > HSMP LSP per PE). > >> > > >> > This is similar to the idea expressed in draft-key-l2vpn-etree- > >> > frwk-03.txt (in a more general sense). > >> > > >> > What do you think? Would HSMP LSP be suitable for this? > >> > > >> > Regards, > >> > Edward > >> > > >> > > >> > > >> > On Wed, Jan 5, 2011 at 5:24 PM, wrote: > >> > > >> > Hi all, > >> > During IETF 79 Beijing, we made a presentation for HSMP LSP at MPLS > >> session. > >> > HSMP LSP has several use cases described in the draft, e.g, time > >> > synchronization in MPLS network, IPTV scenario, or P2MP PW. It would > >> > be appreciated if you could give more scenarios for HSMP LSP. Please > >> > review the draft, and any comments are welcome. > >> > > >> > The draft link is: http://tools.ietf.org/html/draft-jin-jounay-mpls- > >> > mldp-hsmp-01 > >> > > >> > Thank you. > >> > Authors of draft-hsmp. > >> > -------------------------------------------------------- > >> > > >> > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: archive/web/mpls/attachments/20110109/e5b476e5/attachment.html> > > ------------------------------ > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > End of mpls Digest, Vol 81, Issue 12 > ************************************ > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0040BD56482578C0_= Content-Type: text/html; charset="US-ASCII"
Hi Edward, Lamberto and all,
Sorry for the later reply. And no, when apply HSMP LSP to VPLS, the path from leaf PE to root PE is exactly the shortest path. mLDP leaf will send mapping message to root node, choosing the path with routing table, and this path is the shortest path from leaf to root.

We have updated the draft with more clarification of the use cases, and added new use case of VPLS application.
You can get the new draft from link: http://tools.ietf.org/html/draft-jin-jounay-mpls-mldp-hsmp-03

Thank you.
Lizhong


>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 9 Jan 2011 02:50:16 +0100
> From: Lamberto Sterling <lamberto.sterling@gmail.com>
> Subject: Re: [mpls] Request comments for HSMP LSP
> To: maillist.ed@gmail.com, lizhong.jin@zte.com.cn
> Cc: l2vpn@ietf.org, mpls@ietf.org, Ice <ice@cisco.com>,
>    tictoc@ietf.org,   N.Leymann@telekom.de
> Message-ID:
>    <AANLkTi=CbhP10iM7=wXcb=e9oV0cqwaTKjY7ArZquoW1@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi guys,
> Sorry for the email subject. Change it now.
>
> Lamberto
>
> On Sat, Jan 8, 2011 at 5:19 PM, Lamberto Sterling <
> lamberto.sterling@gmail.com> wrote:
>
> > Hi Lizhong, Edward,
> > It seems that it is a good idea to apply HSMP LSP to VPLS, and the
> > broadcast/unicast/unknow packet would be optimized. However, the path from
> > leaf to root may not be the best path compared with current VPLS using P2P
> > LSP, which is not a critical issue.
> >
> > Thanks
> > Lamberto
> >
> >
> >
> >>
> >> ------------------------------
> >>
> >>
> >> Date: Wed, 5 Jan 2011 15:50:45 +0800
> >> From: lizhong.jin@zte.com.cn
> >> Subject: Re: [mpls] Request comments for HSMP LSP
> >> To: Ed <maillist.ed@gmail.com>
> >> Cc: l2vpn@ietf.org, mpls@ietf.org, Ice <ice@cisco.com>,
> >>        N.Leymann@telekom.de,   tictoc@ietf.org
> >> Message-ID:
> >>        <
> >> OF4BA0BF75.A883E04C-ON4825780F.002802E4-4825780F.002B2AB9@zte.com.cn>
> >> Content-Type: text/plain; charset="us-ascii"
> >>
> >> Hi Edward,
> >> Thank you for the comments. I add l2vpn maillist in cc list. I agree with
> >> the application you proposed, and in order to improve the scalability of
> >> VPLS, P2MP PW multiplexed to HSMP LSP could be used for VPLS. Actually
> >> this is a good application case for P2MP PW with reverse path (section
> >> 4.4, draft-ietf-pwe3-p2mp-pw-00). We can add some description about this
> >> use case.
> >>
> >> Regards
> >> Lizhong
> >>
> >>
> >> Ed <maillist.ed@gmail.com> wrote on 2011-01-05 15:05:30:
> >>
> >> > Hi Lizhong,
> >> >
> >> > I think one possible application for HSMP LSPs is to reduce the
> >> > overall broadcast/multicast utilization on a VPLS. In current VPLS
> >> > implementations with a full mesh of P2P LSPs between PEs, broadcast,
> >> > multicast and unknown traffic are not efficiently propagated on the
> >> > physical links between PEs and Ps.
> >> >
> >> > In the VPLS implementation scenario with HSMP LSPs, each PE signals
> >> > a HSMP LSP with itself as a root to all other PEs in the VPLS.
> >> > Thereafter, all broadcast/multicast/unknown traffic from this PE
> >> > will use this HSMP LSP. Unicast traffic from a particular PE (e.g.
> >> > PE1) to another PE (e.g. PE2) will be sent from leaf to root using
> >> > the HSMP LSP where PE2 is the root.
> >> >
> >> > This simplifies the VPLS implementation by:
> >> > -          Reducing traffic utilization from broadcast, multicast
> >> > and unknown traffic
> >> > -          Reducing the total number of LSPs maintained by each PE
> >> > (i.e. instead of requiring a full mesh of LSPs, now only require one
> >> > HSMP LSP per PE).
> >> >
> >> > This is similar to the idea expressed in  draft-key-l2vpn-etree-
> >> > frwk-03.txt (in a more general sense).
> >> >
> >> > What do you think? Would HSMP LSP be suitable for this?
> >> >
> >> > Regards,
> >> > Edward
> >> >
> >> >
> >> >
> >> > On Wed, Jan 5, 2011 at 5:24 PM, <lizhong.jin@zte.com.cn> wrote:
> >> >
> >> > Hi all,
> >> > During IETF 79 Beijing, we made a presentation for HSMP LSP at MPLS
> >> session.
> >> > HSMP LSP has several use cases described in the draft, e.g, time
> >> > synchronization in MPLS network, IPTV scenario, or P2MP PW. It would
> >> > be appreciated if you could give more scenarios for HSMP LSP. Please
> >> > review the draft, and any comments are welcome.
> >> >
> >> > The draft link is: http://tools.ietf.org/html/draft-jin-jounay-mpls-
> >> > mldp-hsmp-01
> >> >
> >> > Thank you.
> >> > Authors of draft-hsmp.
> >> > --------------------------------------------------------
> >> >
> >>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-
> archive/web/mpls/attachments/20110109/e5b476e5/attachment.html>
>
> ------------------------------
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
>
> End of mpls Digest, Vol 81, Issue 12
> ************************************
> 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0040BD56482578C0_=-- From internet-drafts@ietf.org Tue Jul 5 04:12:35 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3BE121F8771; Tue, 5 Jul 2011 04:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LJS4C63Iq0r; Tue, 5 Jul 2011 04:12:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7583421F85D2; Tue, 5 Jul 2011 04:12:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l2vpn-vpls-mcast-09.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110705111233.23755.61078.idtracker@ietfa.amsl.com> Date: Tue, 05 Jul 2011 04:12:33 -0700 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 11:12:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 2 Virtual Private Networks Work= ing Group of the IETF. Title : Multicast in VPLS Author(s) : Rahul Aggarwal Yuji Kamite Luyuan Fang Filename : draft-ietf-l2vpn-vpls-mcast-09.txt Pages : 46 Date : 2011-07-05 This document describes a solution for overcoming a subset of the limitations of existing VPLS multicast solutions. It describes procedures for VPLS multicast that utilize multicast trees in the sevice provider (SP) network. One such multicast tree can be shared between multiple VPLS instances. Procedures by which a single multicast tree in the SP network can be used to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLSes are also described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-mcast-09.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-mcast-09.txt From rahul@juniper.net Tue Jul 5 04:15:29 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A711321F8776 for ; Tue, 5 Jul 2011 04:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tJv2D42DyvY for ; Tue, 5 Jul 2011 04:15:27 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by ietfa.amsl.com (Postfix) with ESMTP id 16FC321F8773 for ; Tue, 5 Jul 2011 04:15:26 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKThLyTH3eNoaFxxfOmYNryITt3PwviwCh@postini.com; Tue, 05 Jul 2011 04:15:26 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 5 Jul 2011 04:14:01 -0700 Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p65BDxv01125; Tue, 5 Jul 2011 04:13:59 -0700 (PDT) (envelope-from rahul@juniper.net) Date: Tue, 5 Jul 2011 04:14:01 -0700 From: Rahul Aggarwal To: Eric Rosen Subject: Re: Comments on draft-ietf-l2vpn-vpls-mcast-08 In-Reply-To: <2717.1301948396@erosen-linux> Message-ID: <20110704094331.C67332@sapphire.juniper.net> References: <2717.1301948396@erosen-linux> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII"; format=flowed Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jul 2011 11:15:29 -0000 Hi Eric, Thank you for the comments. Sorry for the delay. A revised draft that addresses your comments has been posted: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-mcast-09.txt Also please see below: > Since I haven't been following this mailing list regularly, I missed the WG > LC on draft-ietf-l2vpn-vpls-mcast-08. I do have a few comments to make > though; fortunately IETF LC has not occurred yet. > > 1. "Snooped State" > >> From section 11.3: > > If as a result of IGMP or PIM snooping on the PE-CE interfaces, > the PE has snooped state for at least one multicast join that > matches the multicast source and group advertised in the S-PMSI > A-D route. > > The document contains no definition of "IGMP snooping" or "PIM snooping", > nor any reference to another document defining these terms. The document > proceeds to freely use the term "snooped state", without any definition. > I have added a reference to RFC 4541 for IGMP snooping and clarified that PIM snooping procedures require future work. > Without a definition of (or normative reference to such a definition) > "snooping" and "snooped state", I don't see how this document can claim to > be implementable. > > 2. How does traffic get from a multicast source to the designated router? > > Consider group G. Suppose site 1 contains the DR (but no sources or > receivers), site 2 contains the source S, site 3 contains a receiver R. The > PE attached to site 2 might set up a selective tree for (S,G), and the PE > attached to site 3 will join the selective tree, no doubt due to it's having > "snooped state" indicating that there is a receiver at site 3. The PE > attached to site 1 also needs to join the selective tree, or S will be cut > off from its DR. However, I don't see where in the draft it provides a > procedure causing the site 1 PE to join the selective tree. > > Presumably there has to be some "snooping" of the DR election. But this > doesn't seem to be mentioned at all. > Please see response to your comment above - PIM snooping procedures require further work. > 3. Applicability Restrictions > > The following applicability restriction is stated: > > These procedures are applicable when IGMP is used as the multicast > routing protocol between the VPLS CEs. They are also applicable when > PIM is used as the multicast routing protocol between the VPLS CEs > and PIM join suppression is disabled on all the CEs. However these > procedures do not apply when PIM is used as the multicast routing > protocol between the VPLS CEs and it not possible to disable PIM join > suppression on all the CEs > > This suggests, incorrectly, that PIM and IGMP will not be running on the > same LAN. (Not sure whether that is the intention or not.) I think the > correct statement of the applicability restriction is the following: > That is not the intent. I think the text is clear as it stands. > These procedures are not applicable if any VPLS CE, or any other host or > router that is bridged to the VPLS, uses a multicast control protocol > that does not periodically retransmit control messages stating the set of > (S,G) and (*,G) flows in which it is interested. > > Among such CEs are the following: > > - CEs that run PIM, but that have join suppression enabled (i.e., the > vast majority of systems running PIM). Note that the issue is not > whether it is "possible to disable PIM join suppression on all the > CEs", but whether it has actually been disabled. > > - CEs that run the protocol specified in draft-ietf-pim-port-06.txt. > > - CEs that run the protocol specified in draft-ietf-l3vpn-2547bis-mcast- > bgp. > The applicability is limited to IGMP and PIM as in RFC 4601. > There should also be a clear statement to SPs that if a customer deploys > such a CE, the VPLS multicast service will create black holes that are > going to be difficult for the SP to troubleshoot. > > If the document is going to recommend that join suppression be disabled (if > possible), there should be some discussion of the costs of disabling join > suppression. > > 4. Allowable P-Tunnel Technologies > > It is clear that the document allows the use of RSVP-TE P2MP and allows the > use of mLDP. It is very difficult to understand just what the intention is > with respect to other tunneling technologies. The document claims that the > architecture is flexible enough to support other technologies, but it also > says that other technologies are not supported. Right now the document does > not appear to make a consistent statement about this, leaving it unclear > whether the document means to prohibit other technologies or not. > The text has been clarified to limit support to P2MP RSVP-TE or P2MP LDP. > Perhaps what it should say is just that other technologies are outside the > scope of this document. > > 5. Options, models, variants > > The terminology in section 10 is very confusing. The terms "options", > "models", and "variants" are not used in a consistent manner. > > - Section 10 mentions "options" a, b, and c, then proceeds almost > immediately (section 10.2) to an option e, which is never explicitly > defined. > > - Options a, b, and c are called "three models", and there is a requirement > to support all three "models". Then the text goes on to say that options a > and b use a single "model" ("where inter-AS VPLS service can be offered > without requiring a single P-multicast tree to span multiple ASes".) Then > there are two "variants" of this "model". > > - I think the intention is that there are two "variants": "VSIs on the > ASBRs", and "Segmented Inter-AS Trees", and that these two variants > combine with the four "options" (a, b, c, and e) to make a total of 5 > models: > > * Model 1: Option (a) plus the variant "VSIs on the ASBRS" > > * Model 2: Option (e) plus the variant "VSIs on the ASBRS" > > * Model 3: Option (b) plus the variant "Segmented Inter-AS Trees" > > * Model 4: Option (c) plus the variant "Segmented Inter-AS Trees" > What you call Model 4 is not supported by this specification. > * Model 5: Option (c) plus non-segmented Inter-AS trees but without VSIs > on the ASBRs (not sure I got this one right, this seems like a hitherto > unmentioned "variant"). > > The terminology in section 10 really needs to be cleaned up for clarity > and consistency. > Done. > 6. Section 11.2.1 > > This section is referred to multiple times, as the place where the > explicit tracking procedures are specified. However, there is no section > 11.2.1. I suspect the proper reference is 11.3. > Fixed. > 6. Miscellaneous comments > >> From the introduction (section 4), page 5: > > [RFC4761] and [RFC4762] describe a solution for VPLS multicast that > relies on ingress replication. > > "Ingress replication" should be defined; I don't think this term appears in > either RFC4761 or RFC4762. > Done. > Also from the introduction, page 5: > > It provides mechanisms that allow a single multicast distribution > tree in the Service Provider (SP) network to carry all the multicast > traffic from one or VPLS sites connected to a given PE, irrespective > > "from one or VPLS" --> "from one or more VPLS" > Fixed. >> From the overview (section 6), page 6: > > This document describes procedures for using multicast trees for VPLS > multicast when the provider tunneling technology is either P2MP RSVP- > PE or mLDP [MLDP]. The protocol architecture described herein is > considered to be flexible to support other P-tunneling technologies > as well. > > The phrase "either P2MP RSVP-PE or mLDP" is mangled. I think what is > intended is "P2MP LSPs created either by RSVP-TE or mLDP". > Fixed. > Page 7 > > The ability to carry the traffic of more than one VPLS on the > same tree is termed of the VPLSes that are using the tree. This > > "is termed of the VPLSes", looks like a cut-and-paste error of some sort. > Fixed. > An Inclusive P-Multicast tree as defined in this document is a P2MP > tree. A P2MP tree is used to carry traffic only for VPLS sites that > are connected to the PE that is the root of the tree. > > I suggest "carry traffic only for" be replaced by "carry traffic only from", > as "for" could be taken to mean either "to" or "from" or "both" in this context. > Done. > Note that this paragraph seems to imply that MP2MP LSPs or PIM-BIDIR trees > would not be Inclusive P-multicast trees "as defined in this document". > Perhaps what it should say is "This document only defines procedures for > instantiating an inclusive P-multicast tree as a P2MP LSP; other possible > methods of instantiation are outside the scope of this document". This > would be more consistent with the prior statement that the protocol > architecture of the document is flexible enough to support other tunneling > technologies. > The text has been clarified to restrict the scope to P2MP RSVP-TE or P2MP LDP LSPs. > Also on page 7: > > 2. Selective trees. A Selective P-Multicast tree is used by a PE > to send IP multicast traffic for one or IP more specific multicast > streams, originated within sites connected to the PE, that belong to > the same or different VPLSes, to a subset of the PEs that belong to > those VPLSes. Each of the PEs in the subset should be on the path to > a receiver of one or more multicast streams that are mapped onto the > tree. The ability to use the same tree for multicast streams that > belong to different VPLSes is termed a PE the ability to create > > "Is termed a PE the ability to create"? Maybe this should be "gives a PE > the ability to create". > It was an error in the source formatting. Fixed. > I don't think it is correct to say that the traffic must have originated > within a site connected to the PE; the traffic could have originated > somewhere far away on the Internet, in a television studio, etc. Instead of > "originated within sites connected to the PE", maybe what is meant is > "received by the PE over a PE-CE interface". This error occurs in multiple > places. > Fixed. > Page 7 again: > > A SP can use both Inclusive P-Multicast trees and Selective P- > Multicast trees or either of them for a given VPLS on a PE, based on > local configuration. Inclusive P-Multicast trees can be used for > both IP and non-IP data multicast traffic, while Selective P- > Multicast trees can be used only for IP multicast data traffic. > > It might be better to say "using selective P-trees for anything other than > IP multicast data traffic is outside the scope of this spec." If this is > really meant to prohibit such use entirely, normative language ("MUST NOT") > should be used. > Fixed. > Once more, page 7: > > A variety of transport technologies may be used in the SP network. > For inclusive P-Multicast trees, these transport technologies include > point-to-multipoint LSPs created by RSVP-TE or mLDP. For selective P- > Multicast trees, only unicast PE-PE tunnels (using MPLS or IP/GRE > encapsulation) and P2MP LSPs are supported, and the supported P2MP > LSP signaling protocols are RSVP-TE, and mLDP. > > It's not very clear what this paragraph is saying. If a technology is "not > supported", does that mean it is outside the scope of this document, or that > it is prohibited for some unspecified reason. (If the latter, the reason > should be specified.) > > It's hard to understand why unicast tunnels are supported only for selective > tunnels, why GRE encaps is supported only for unicast tunnels, etc. > I clarified that other transport technologies are outside the scope. > Page 8: > > However these > procedures do not apply when PIM is used as the multicast routing > protocol between the VPLS CEs and it not possible to disable PIM join > suppression on all the CEs. Procedures for this case are for further > study. > > Change "it not possible to disable PIM Join suppression on all the CEs" to > "PIM Join Suppression is not disabled on all the CEs". Done. > But see also my > prior comment on other multicast protocols for which every CE does not > periodically retransmit every Join. > I commented on that above. > Page 10: > > Aggregation requires a mechanism for the egresses of the P-Multicast > tree to demultiplex the multicast traffic received over the P- > Multicast tree. This document describes how upstream-assigned labels > can be assigned and distributed by the root of aggregate P-Multicast > tree and then used by the egresses to perform this demultiplexing. > > I think it would be clearer to replace the last sentence by "To enable the > egress nodes to perform this demultiplexing, upstream-assigned labels > [RFC5331] MUST be assigned and distributed by the root of the aggregate > P-multicast tree". This would make it clear that upstream-assigned labels > are a mandatory feature if (and only if) aggregation is used. > Done. > Page 11: > > It is to be noted that BGP A-D is an inherent feature of BGP-VPLS. > However it is not an inherent feature of LDP-VPLS. Infact there are > deployments and/or implementations of LDP-VPLS that require > configuration to enable a PE in a particular VPLS to determine other > PEs in the VPLS and exchange PW labels using FEC 128 [RFC4447]. The > use of BGP A-D for LDP-VPLS [L2VPN-SIG], to enable automatic setup of > PWs, requires FEC 129 [RFC4447]. However FEC 129 is not required in > order to use BGP A-D for the setup of P-Multicast trees for LDP-VPLS > as described in this document. An LDP-VPLS implementation that > supports P-Multicast trees described in this document, MUST support > the BGP A-D procedures to setup P-Multicast trees and it MAY support > FEC 129 to automate the signaling of PWs. > > It's very unclear to me just what is and is not being required by this > paragraph. If it's just that an LDP-VPLS implementation may support the > procedures in this draft even if it doesn't support FEC 129, that seems fair > enough. That is what is being referred to. > If it's that an LDP-VPLS implementation that uses P-multicast trees > to optimize IP multicast MUST support the BGP A-D procedures described > herein, that seems gratuitous. The phrase "supports P-multicast trees > described in this document" is also unclear. > I clarified this. Please see new text. > Page 12: > > A PE that uses an Inclusive P-Multicast tree to instantiate the > provider tunnel MAY aggregate two or more VPLSes present on the PE > onto the same tree. If the PE decides to perform aggregation after it > has already advertised the intra-AS VPLS auto-discovery routes for > these VPLSes, then aggregation requires the PE to re-advertise these > routes. > > Should there be some statement about when it's okay to start sending the > data on the newly aggregated tunnel? Is it necessary or desirable to wait a > certain amount of time? > This is no different than sending data on a new P-Tunnel. I don't think any further clarification is necessary. > Page 12: > > The re-advertised routes MUST be the same as the original > ones, except for the PMSI Tunnel attribute. If the PE has not > previously advertised intra-AS auto-discovery routes for these > VPLSes, then the aggregation requires the PE to advertise (new) > intra-AS auto-discovery routes for these VPLSes. The P-Tunnel > attribute in the newly advertised/re-advertised routes MUST carry the > identity of the P-Multicast tree that aggregates the VPLSes, as well > as an MPLS upstream-assigned label [RFC5331]. Each re-advertised > route MUST have a distinct label. > > For consistency, "P-Tunnel attribute" --> "PMSI Tunnel attribute" > > The requirement for a distinct label applies to the newly advertised routes > as well as the re-advertised routes, no? > Done. > Page 13: > > + If the Tunnel Type in the PMSI Tunnel attribute is set to RSVP-TE > P2MP LSP, the receiving PE has to establish the appropriate state > to properly handle the traffic received over that LSP. The PE > that originated the route MUST establish an RSVP-TE P2MP LSP with > the local PE as a leaf. This LSP MAY have been established before > the local PE receives the route. > > Isn't a normative reference to draft-ietf-mpls-rsvp-te-no-php-oob-mapping- > 05.txt needed here, for the case where the TE tunnel is established before > its use has been communicated? > Section 9.2.1 describes this along with a normative reference to RSVP-OBB. > Page 14: > > When a P-Multicast tree is mapped to only one VPLS, determining the > tree on which the packet is received is sufficient to determine the > VPLS instance on which the packet is received. The tree is determined > based on the tree encapsulation. If MPLS encapsulation is used, eg: > RSVP-TE P2MP LSPs, the outer MPLS label is used to determine the > tree. Penultimate-hop-popping MUST be disabled on the MPLS LSP (RSVP- > TE P2MP LSP or LDP P2MP LSP). > > Doesn't this require a normative reference to draft-ietf-mpls-rsvp-te-no- > php-oob-mapping-05.txt? > Please see above. > Page 14, section 8.2: > > This document requires the use of upstream label assignment by the > ingress PE [RFC5331]. > > It might be better to use 2119 language here, "If traffic from multiple > VPLSes is carried on a single tree, upstream-assigned labels [RFC5331] MUST > be used. > Done. > Also page 14: > > If the tree uses MPLS encapsulation, as in RSVP-TE P2MP LSPs, the > outer MPLS label and the incoming interface provides the label space > of the label beneath it. This assumes that penultimate-hop-popping is > disabled. The egress PE MUST NOT advertise IMPLICIT NULL or EXPLICIT > NULL for that tree. > > If the P2MP LSP is signaled before the BGP route is received, how does the > egress PE know to avoid advertising NULL for that LSP? > Clarified this with following text: "The egress PE MUST NOT advertise IMPLICIT NULL or EXPLICIT NULL for that tree once its known to the egress PE that the tree is bound to one or more VPLSes." > Page 15: > > 9. Establishing P-Multicast Trees > > This document does not place any fundamental restrictions on the > multicast technology used to setup P-Multicast trees. However > specific procedures are specified only for RSVP-TE P2MP LSPs and LDP > P2MP LSPs. An implementation that supports this document MUST support > RSVP-TE P2MP LSPs and LDP P2MP LSPs. > > The P-Multicast trees supported in this document are P2MP trees. > > It would be less confusing to say that "specific procedures are specified > only for P2MP LSPs", otherwise it is hard to know what to make of these two > paragraphs together. > > A > P2MP tree is used to carry traffic originated in sites connected to > the PE which is the root of the tree, irrespective of whether these > sites belong to the same or different VPLSes. > > This suggests, incorrectly, that aggregation is always done. Maybe change > "is used" to "MAY be used". > The text has been clarified. > > 9.1. Common Procedures > > The following procedures apply to both RSVP-TE P2MP and LDP P2MP > LSPs. > > Demultiplexing the C-multicast data packets at the egress PE requires > that the PE must be able to determine the P2MP LSP that the packets are > received on. This enables the egress PE to determine the VPLS that the > packet belongs to. To achieve this the LSP MUST be signaled with > penultimate-hop-popping (PHP) off as described in section 8. In other > words an egress PE MUST NOT advertise IMPLICIT NULL or EXPLICIT NULL for > a P2MP LSP that is carrying traffic for one or more VPLSes. > > As I commented earlier, I don't think this draft explains how the egress > knows to do this in the case of RSVP-TE P2MP LSPs. > This just works if the LSP signaling is received after the BGP A-D route that carries the accompanying PMSI Tunnel attribute. If the LSP signaling is received earlier then section 9.2.1 has details. > Page 17: > > 9.4. Encapsulation of Aggregate P-Multicast Trees > > An Aggregate Inclusive P-Multicast tree or an Aggregate Selective P- > Multicast tree MUST use a MPLS encapsulation. The protocol type in > the data link header is as described in [RFC5332]. > > Presumably the encapsulation used to send data on a certain tunnel is > determined by the tunnel type. I'm not sure why this short section is > needed, there is no section on encapsulation of non-aggregate trees. > Its useful to refer to RC5332 regarding the encaps. > Page 27: > > These procedures are applicable when IGMP is used as the multicast > routing protocol between the VPLS CEs. They are also applicable when > PIM is used as the multicast routing protocol between the VPLS CEs > and PIM join suppression is disabled on all the CEs. However these > procedures do not apply when PIM is used as the multicast routing > protocol between the VPLS CEs and it not possible to disable PIM join > suppression on all the CEs. Procedures that allow the setup of > Selective trees for this case are for further study. > > This paragraph is just repeated from earlier in the document. See my > earlier comments. (Regardless of the disposition of those comments, this > paragraph should probably not be repeated here.) > Deleted the paragaraph here. > Page 28: > > If the Selective tree is instantiated by a RSVP-TE P2MP LSP the PE at > the root of the tree MUST establish the P2MP RSVP-TE LSP to the > leaves. This LSP MAY have been established before the leaves receive > the Selective tree binding, or MAY be established after the leaves > receives the binding. A leaf MUST not switch to the Selective tree > until it receives the binding and the RSVP-TE P2MP LSP is setup to > the leaf. > > This paragraph has already occurred before. > In this case its good to repeat it for context. > Page 31: > > + If as a result of IGMP or PIM snooping on the PE-CE interfaces, > the PE has snooped state for at least one multicast join that > matches the multicast source and group advertised in the S-PMSI > A-D route. Further if the oif (outgoing interfaces) for this > state contains one or more interfaces to the locally attached > CEs. > > > As previously pointed out, "IGMP or PIM snooping" has to be defined and > specified (perhaps via a normative reference). Otherwise there is no way to > know what is meant below by "snooped state" how such states are created > and destroyed, and exactly what states the PEs need to keep track of. > Fixed as stated in the response above. > Pages 31-32 > > The snooped state is said to "match" the S-PMSI A-D route if any of > the following is true: > > + The S-PMSI A-D route carries (C-S, C-G) and the snooped state is > for (C-S, C-G). OR > > + The S-PMSI A-D route carries (C-*, C-G) and (a) the snooped > state is for (C-*, C-G) OR (b) the snooped state is for at least > one multicast join with the multicast group address equal to C-G > and there doesn't exist another S-PMSI A-D route that carries (C- > S, C-G) where C-S is the source address of the snooped state. > > + The S-PMSI A-D route carries (C-S, C-*) and (a) the snooped > state is for at least one multicast join with the multicast > source address equal to C-S, and (b) there doesn't exist another > S-PMSI A-D route that carries (C-S, C-G) where C-G is the group > address of the snooped state. > > + The S-PMSI A-D route carries (C-*, C-*) > > As this algorithm is specified, every "snooped state" matches an S-PMSI A-D > route specifying (C-*,C-*), even if (C-*,C-*) is not the "longest match". I > think what is meant is that the snooped state matches the S-PMSI A-D route > that meets the first condition, if there is one; otherwise it matches the > S-PMSI A-D route that meets the second condition, if there is one; otherwise > it matches the S-PMSI A-D route that meets the third condition, if there is > one; otherwise it matches the S-PMSI A-D route that meets the fourth > condition, if there is one; otherwise there is no match. However, this is > not what it says. > Added text to fix this. > Something should be specified to cover the case where the S-PMSI A-D route > does not match any "snooped state", This is quite explicit as the text in the section applies only when matching snooped state exists. > and the case where a newly created > "snooped state" matches an S-PMSI A-D route that is already present. > Added text to cover this. > Page 36: > > 12.1. Inclusive Tree/Selective Tree Identifier > > Inclusive P-Multicast tree and Selective P-Multicast tree > advertisements carry the P-Multicast tree identifier. > > This document reuses the BGP attribute, called PMSI Tunnel Attribute > that is defined in [MVPN]. > > Only the following Tunnel Types MUST be used when PMSI Tunnel > attribute is carried in VPLS A-D or VPLS S-PMSI A-D routes: > > + 0 - No tunnel information present > + 1 - RSVP-TE P2MP LSP > + 2 - LDP P2MP LSP > + 6 - Ingress Replication > > If the protocol architecture is flexible enough to handle other tunnel > types, as is stated several times earlier, this should say that the use of > other tunnel types is outside the scope of the document, rather than saying > that other tunnel types MUST NOT be used. (Actually, the phrase "only the > following tunnel types MUST be used ..." is not really comprehensible, I'm > just guessing that it means that other tunnel types MUST NOT be used.) > Clarified the text. > Page 38: > > The Multicast Source field contains the C-S address i.e the address > of the multicast source. This may be 0 to indicate a wildcard. If the > Multicast Source field contains an IPv4 address, then the value of > the Multicast Source Length field is 32. If the Multicast Source > field contains an IPv6 address, then the value of the Multicast > Source Length field is 128. > > The Multicast Group field contains the C-G address i.e. the address > of the multicast group. This may be 0 to indicate a wildcard. If the > Multicast Group field contains an IPv4 address, then the value of the > Multicast Group Length field is 32. If the Multicast Group field > contains an IPv6 address, then the value of the Multicast Group > Length field is 128. > > The wildcard encoding does not appear to be consistent with that used in > MVPN. It is also not clear what the length of a wildcard field is supposed > to be, or whether a wildcard is a wildcard only for a particular address > family. > Fixed in the revised version. > Please state how to determine the address family of the "originating > router's IP address". > Added text on this. > Usage of Selective Tree auto-discovery routes is described in Section > 12. > > Well, this is section 12! > It should read section 11. Fixed. > > Page 38: > > A leaf auto-discovery route type specific MCAST-VPLS NLRI consists of > the following: > > +-----------------------------------+ > | Route Key (variable) | > +-----------------------------------+ > | Originating Router's IP Addr | > +-----------------------------------+ > > Usage of Leaf auto-discovery routes is described in sections "Inter- > AS Inclusive P-Multicast tree A-D/Binding" and "Optimizing Multicast > Distribution via Selective trees". > > Please state how to determine the address family of the "originating > router's IP address". > Added text on this. > Page 39: > > 13. Aggregation Methodology > > A better title would be "Aggregation Considerations", as this section > contains some discussion and observations, but does not specify a > methodology. > Done. > Page 41: > > If the destination MAC address of a VPLS packet received by a PE from > a VPLS site is a multicast adddress, a P-Multicast tree SHOULD be > used to transport the packet, if possible. If the packet is an IP > multicast packet and a Selective tree exists for that multicast > stream, the Selective tree SHOULD be used. Else if an Inclusive tree > exists for the VPLS, it SHOULD be used. > > So a transmitter is not required to use the selective tree for a given flow, > even if it exists? Is that really the intention? > No. Replaced with "Selective tree MUST be used" > It is not completely clear what the intention is for a packet that has an > ethernet multicast DA but is not an IP multicast packet. Would it ever be > sent on a selective tree (perhaps one bound to (C-*,C-*))? > Added text to clarify this. rahul From nabil.n.bitar@verizon.com Wed Jul 6 04:38:37 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE27E21F86B1 for ; Wed, 6 Jul 2011 04:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vc-Hrv7fNOrw for ; Wed, 6 Jul 2011 04:38:37 -0700 (PDT) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by ietfa.amsl.com (Postfix) with ESMTP id F1E8721F867C for ; Wed, 6 Jul 2011 04:38:36 -0700 (PDT) Received: from fldsmtpi03.verizon.com (fldsmtpi03.verizon.com [166.68.71.145]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p66BcEfs017549 for ; Wed, 6 Jul 2011 07:38:24 -0400 (EDT) From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.65,486,1304294400"; d="scan'208,217";a="87626656" Received: from fldp1lumxc7hb02.verizon.com (HELO FLDP1LUMXC7HB02.us.one.verizon.com) ([166.68.75.85]) by fldsmtpi03.verizon.com with ESMTP; 06 Jul 2011 11:38:13 +0000 Received: from FLDP1LUMXC7HB05.us.one.verizon.com (166.68.75.87) by FLDP1LUMXC7HB02.us.one.verizon.com (166.68.75.85) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 6 Jul 2011 07:38:13 -0400 Received: from fldp1lumxc7v63.us.one.verizon.com ([169.254.3.145]) by FLDP1LUMXC7HB05.us.one.verizon.com ([166.68.75.87]) with mapi; Wed, 6 Jul 2011 07:38:13 -0400 To: "l2vpn@ietf.org" Date: Wed, 6 Jul 2011 07:38:37 -0400 Subject: L2VPN Agenda Slot Call for IETF 81 - Quebec City Thread-Topic: L2VPN Agenda Slot Call for IETF 81 - Quebec City Thread-Index: Acw70T6EJmF1aZN8/UWy1L980Y7kOQ== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA39C17D156EEnabilnbitarverizoncom_" MIME-Version: 1.0 Cc: Giles Heron X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 11:38:37 -0000 --_000_CA39C17D156EEnabilnbitarverizoncom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi L2VPN WG. Please let us know if you have a time-slot request for the L2VPN sessions a= t IETF 81 - Quebec City. Please, email us your request by Sunday= July 10 2011 along with the following information: 1) Draft title 2) Presenter name 3) Requested duration Please note that priority will be given to drafts that are clearly within t= he scope of the current L2VPN charter. Key date to remember: 2011-07-11 (Monday): Internet Draft final submission cut-off by 17:00 PT (0= 0:00 UTC), Thanks, Giles and Nabil --_000_CA39C17D156EEnabilnbitarverizoncom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable L2VPN Agenda Slot Call for IETF 81 - Quebec City Hi L2VPN WG.

Please let us know if you have a time-slot request for the L2VPN sessions a= t IETF 81 – Quebec City. Please,  email us    &nb= sp;      your request by Sunday July 10 2011 = along with the following information:
1) Draft title
2) Presenter name
3) Requested duration



2011-07-11 (Monday): Internet Draft final submiss= ion cut-off by 17:00 PT (00:00 UTC),

Date: Wed, 06 Jul 2011 10:35:16 -0700 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 17:35:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 2 Virtual Private Networks Work= ing Group of the IETF. Title : BGP based Multi-homing in Virtual Private LAN Service Author(s) : Bhupesh Kothari Kireeti Kompella Wim Henderickx Florin Balus James Uttaro Filename : draft-ietf-l2vpn-vpls-multihoming-03.txt Pages : 26 Date : 2011-07-06 Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private Network (VPN) that gives its customers the appearance that their sites are connected via a Local Area Network (LAN). It is often required for the Service Provider (SP) to give the customer redundant connectivity to some sites, often called "multi-homing". This= memo shows how BGP-based multi-homing can be offered in the context of LDP and BGP VPLS solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-multihoming-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-multihoming-03.txt From nabil.n.bitar@verizon.com Wed Jul 6 15:36:27 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878B321F85DB for ; Wed, 6 Jul 2011 15:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqgyaGvyXLcw for ; Wed, 6 Jul 2011 15:36:26 -0700 (PDT) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by ietfa.amsl.com (Postfix) with ESMTP id 76B0921F85C7 for ; Wed, 6 Jul 2011 15:36:24 -0700 (PDT) Received: from fldsmtpi02.verizon.com (fldsmtpi02.verizon.com [166.68.71.144]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p66Ma9Ds014343 for ; Wed, 6 Jul 2011 18:36:14 -0400 (EDT) From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.65,489,1304294400"; d="scan'208,217";a="88063906" Received: from fldp1lumxc7hb03.verizon.com (HELO FLDP1LUMXC7HB03.us.one.verizon.com) ([166.68.75.86]) by fldsmtpi02.verizon.com with ESMTP; 06 Jul 2011 22:36:09 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([169.254.3.145]) by FLDP1LUMXC7HB03.us.one.verizon.com ([166.68.75.86]) with mapi; Wed, 6 Jul 2011 18:36:09 -0400 To: "l2vpn@ietf.org" Date: Wed, 6 Jul 2011 18:36:12 -0400 Subject: [l2vpn] WG last call for draft-ietf-l2vpn-vpls-macflush-ld-01 Thread-Topic: [l2vpn] WG last call for draft-ietf-l2vpn-vpls-macflush-ld-01 Thread-Index: Acw8LRuIA2DwM6YgZk6WyqTmP8RyFg== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA3A5B9C15797nabilnbitarverizoncom_" MIME-Version: 1.0 Cc: Giles Heron X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jul 2011 22:36:29 -0000 --_000_CA3A5B9C15797nabilnbitarverizoncom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, This is the start of a two-week working group last call on the draft "MAC F= lush Loop Detection in VPLS". The draft can be found at http://tools.ietf.= org/html/draft-ietf-l2vpn-vpls-macflush-ld-01 Please, review the draft and send any comments to the L2VPN working group e= mail list. This WG last call will close on Wednesday July 20th, 2011. Regards, Giles & Nabil --_000_CA3A5B9C15797nabilnbitarverizoncom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [l2vpn]  WG last call for draft-ietf-l2vpn-vpls-macflush-ld-01<= /TITLE> </HEAD> <BODY> <FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12pt'>Hi,<BR> This is the start of a two-week working group last call on the draft “= ;MAC Flush Loop Detection in VPLS”.  The draft can be found at <= FONT COLOR=3D"#0000FF"><U><a href=3D"http://tools.ietf.org/html/draft-ietf-= l2vpn-vpls-macflush-ld-01">http://tools.ietf.org/html/draft-ietf-l2vpn-vpls= -macflush-ld-01</a><BR> </U></FONT> <BR> Please, review the draft and send any comments to the L2VPN working group e= mail list. <BR> <BR> This WG last call will close on Wednesday July 20th, 2011.<BR>  <BR> Regards,<BR> Giles & Nabil<BR> </SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE= =3D'font-size:11pt'><BR> <BR> </SPAN></FONT> </BODY> </HTML> --_000_CA3A5B9C15797nabilnbitarverizoncom_-- From internet-drafts@ietf.org Mon Jul 11 05:54:17 2011 Return-Path: <internet-drafts@ietf.org> X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FEF721F8B53; Mon, 11 Jul 2011 05:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBdbd43fPat5; Mon, 11 Jul 2011 05:54:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3D221F869F; Mon, 11 Jul 2011 05:54:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l2vpn-vpms-frmwk-requirements-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711125416.22771.76604.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 05:54:16 -0700 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: <l2vpn.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn> List-Post: <mailto:l2vpn@ietf.org> List-Help: <mailto:l2vpn-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 11 Jul 2011 12:54:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 2 Virtual Private Networks Work= ing Group of the IETF. Title : Framework and Requirements for Virtual Private Multicast= Service (VPMS) Author(s) : Yuji Kamite Frederic Jounay Ben Niven-Jenkins Deborah Brungard Lizhong Jin Filename : draft-ietf-l2vpn-vpms-frmwk-requirements-04.txt Pages : 27 Date : 2011-07-11 This document provides a framework and service level requirements for Virtual Private Multicast Service (VPMS). VPMS is defined as a Layer 2 VPN service that provides point-to-multipoint connectivity for a variety of Layer 2 link layers across an IP or MPLS-enabled PSN. This document outlines architectural service models of VPMS and states generic and high level requirements. This is intended to aid in developing protocols and mechanisms to support VPMS. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpms-frmwk-requirement= s-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-l2vpn-vpms-frmwk-requirements= -04.txt From internet-drafts@ietf.org Mon Jul 11 12:29:31 2011 Return-Path: <internet-drafts@ietf.org> X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35AA511E8189; Mon, 11 Jul 2011 12:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9M4fGoeyJ59p; Mon, 11 Jul 2011 12:29:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95B111E8185; Mon, 11 Jul 2011 12:29:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l2vpn-pbb-vpls-interop-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711192930.22045.18677.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 12:29:30 -0700 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: <l2vpn.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn> List-Post: <mailto:l2vpn@ietf.org> List-Help: <mailto:l2vpn-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe> X-List-Received-Date: Mon, 11 Jul 2011 19:29:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 2 Virtual Private Networks Work= ing Group of the IETF. Title : VPLS Interoperability with Provider Backbone Bridges Author(s) : Ali Sajassi Samer Salam Chris Metz Nabil Bitar Dinesh Mohan Filename : draft-ietf-l2vpn-pbb-vpls-interop-02.txt Pages : 23 Date : 2011-07-11 The scalability of H-VPLS with Ethernet access network can be improved by incorporating Provider Backbone Bridge functionality in VPLS access. Provider Backbone Bridging has been standardized as IEEE 802.1ah-2008, and aims to improve the scalability of MAC addresses and service instances in Provider Ethernet networks. This document describes different interoperability scenarios where Provider Backbone Bridge functionality is used in H-VPLS with Ethernet or MPLS access network to attain better scalability in terms of number of customer MAC addresses and number of service instances. The document also describes the scenarios and the mechanisms for incorporating Provider Backbone Bridge functionality within H-VPLS with existing Ethernet access and interoperability among them. Furthermore, the document discusses the migration mechanisms and scenarios by which Provider Backbone Bridge functionality can be incorporated into H-VPLS with existing MPLS access. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-pbb-vpls-interop-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-l2vpn-pbb-vpls-interop-02.txt From erosen@cisco.com Wed Jul 13 06:45:12 2011 Return-Path: <erosen@cisco.com> X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C66821F88E1 for <l2vpn@ietfa.amsl.com>; Wed, 13 Jul 2011 06:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.932 X-Spam-Level: X-Spam-Status: No, score=-7.932 tagged_above=-999 required=5 tests=[AWL=2.667, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqSrKmN9PfLb for <l2vpn@ietfa.amsl.com>; Wed, 13 Jul 2011 06:45:08 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id D771411E80E0 for <l2vpn@ietf.org>; Wed, 13 Jul 2011 06:45:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=1336; q=dns/txt; s=iport; t=1310564708; x=1311774308; h=to:cc:subject:in-reply-to:reply-to:date:message-id:from; bh=aMW+FOeOkGAaEOfZh1J4LGNNVGP0AwMIk/0O6dBP+Xw=; b=XFLbHo3RVrcpG60aNfV5ZZpSN4nsRkBp9Ec/W9jrkbklLZgULZvTNLUm C2AQr8D6oZYTEwTfxwrOZO/7yc5M9SKWXUy0uv++xGTKDte4U7MRUCcbh dXsKnBo3I1fRZ0TOqSrqUl5m1z5llCvZKzVPLFPCgrAcn0We0/5oa9ECY w=; X-IronPort-AV: E=Sophos;i="4.65,525,1304294400"; d="scan'208";a="42662374" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 13 Jul 2011 13:45:07 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p6DDj6NS003092; Wed, 13 Jul 2011 13:45:06 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id p6DDj62G028478; Wed, 13 Jul 2011 09:45:06 -0400 To: Rahul Aggarwal <rahul@juniper.net> Subject: Re: Comments on draft-ietf-l2vpn-vpls-mcast-08 In-reply-to: Your message of Tue, 05 Jul 2011 04:14:01 -0700. <20110704094331.C67332@sapphire.juniper.net> Date: Wed, 13 Jul 2011 09:45:06 -0400 Message-ID: <28477.1310564706@erosen-linux> From: Eric Rosen <erosen@cisco.com> Cc: l2vpn@ietf.org, Eric Rosen <erosen@cisco.com> X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: <l2vpn.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn> List-Post: <mailto:l2vpn@ietf.org> List-Help: <mailto:l2vpn-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 13 Jul 2011 13:45:12 -0000 Rahul, Thanks for making the changes. I think there is only one issue remaining. Section 11.3 says: When the multicast signaling protocol between PE state when PE-CE protocol and CE is IGMP, then snooping and associated procedures are defined in [RFC 4541].When the multicast signaling protocol between PE and CE is PIM, the procedures in RFC4541 are not sufficient to determine the snooped state. The additional details required to determine the snooped state when PE-CE protocol is PIM are for further study. I think this should say "among the CEs" rather than "between PE and CE", and should refer to the "CE-CE protocol" rather than PE-CE protocol. Even so, this is buried rather deep in the document. Would you consider putting something like the following at the end of the "Introduction" section: The procedures of this document require the PEs to "snoop" the CE-CE multicast signaling. When the multicast signaling protocol IGMP, the snooping and associated procedures are defined in [RFC 4541]. When the multicast signaling protocol is PIM the, procedures in RFC4541 are not sufficient to determine the snooped state. The additional details required to determine the snooped state for PIM are for further study. Eric P.S.: You need to run idnits. From nabil.n.bitar@verizon.com Thu Jul 14 09:03:45 2011 Return-Path: <nabil.n.bitar@verizon.com> X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10F021F8CEC for <l2vpn@ietfa.amsl.com>; Thu, 14 Jul 2011 09:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsRpHqFPvrSd for <l2vpn@ietfa.amsl.com>; Thu, 14 Jul 2011 09:03:44 -0700 (PDT) Received: from sacmail2.verizon.com (sacmail2.verizon.com [192.76.84.41]) by ietfa.amsl.com (Postfix) with ESMTP id C71C021F8CC6 for <l2vpn@ietf.org>; Thu, 14 Jul 2011 09:03:43 -0700 (PDT) Received: from fldsmtpi03.verizon.com (fldsmtpi03.verizon.com [166.68.71.145]) by sacmail2.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p6EG3eiH029717 for <l2vpn@ietf.org>; Thu, 14 Jul 2011 12:03:43 -0400 (EDT) From: "Bitar, Nabil N" <nabil.n.bitar@verizon.com> X-IronPort-AV: E=Sophos;i="4.65,529,1304294400"; d="scan'208,217";a="93100545" Received: from fldp1lumxc7hb01.verizon.com (HELO FLDP1LUMXC7HB01.us.one.verizon.com) ([166.68.45.78]) by fldsmtpi03.verizon.com with ESMTP; 14 Jul 2011 16:03:40 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([169.254.3.145]) by FLDP1LUMXC7HB01.us.one.verizon.com ([166.68.45.78]) with mapi; Thu, 14 Jul 2011 12:03:41 -0400 To: "l2vpn@ietf.org" <l2vpn@ietf.org> Date: Thu, 14 Jul 2011 12:03:44 -0400 Subject: L2VPN Agenda Slot Call for IETF 81 - Quebec City: A reminder and last chance Thread-Topic: L2VPN Agenda Slot Call for IETF 81 - Quebec City: A reminder and last chance Thread-Index: Acw70T6EJmF1aZN8/UWy1L980Y7kOQGblyfJ Message-ID: <CA448BA0.15B88%nabil.n.bitar@verizon.com> In-Reply-To: <CA39C17D.156EE%nabil.n.bitar@verizon.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA448BA015B88nabilnbitarverizoncom_" MIME-Version: 1.0 Cc: Giles Heron <giheron@cisco.com> X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: <l2vpn.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/options/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn> List-Post: <mailto:l2vpn@ietf.org> List-Help: <mailto:l2vpn-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe> X-List-Received-Date: Thu, 14 Jul 2011 16:03:45 -0000 --_000_CA448BA015B88nabilnbitarverizoncom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, As we are finalizing the agenda, if you have a time-slot request for the th= e L2VPN sessions at IETF 81 - Quebec City and you have not requested a slot= already or your request to us has not been acknowledged, please email us y= our request by Friday July 15 2011, 17:00PT (00:00 UTC) along with the foll= owing information: 1) Draft title 2) Presenter name 3) Requested duration Please note that priority will be given to drafts that are clearly within t= he scope of the current L2VPN WG charter. Thanks, Nabil & Giles --_000_CA448BA015B88nabilnbitarverizoncom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <HTML> <HEAD> <TITLE>L2VPN Agenda Slot Call for IETF 81 - Quebec City: A reminder and las= t chance Hi,
As we are finalizing the agenda, if you have a time-slot request for the th= e L2VPN sessions at IETF 81 – Quebec City and you have not requested = a slot already or your request to us has not been acknowledged, please emai= l us your request by Friday July 15 2011, 17:00PT (00:00 UTC) along with th= e following information:
1) Draft title
2) Presenter name
3) Requested duration

Please note that priority wil= l be given to drafts that are clearly within the scope of the current L2VPN= WG charter.

Thanks,
Nabil & Giles
 --_000_CA448BA015B88nabilnbitarverizoncom_-- From giles.heron@gmail.com Tue Jul 19 04:01:23 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22CFD21F8510 for ; Tue, 19 Jul 2011 04:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USxqDd8xOnci for ; Tue, 19 Jul 2011 04:01:22 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id BA99921F8508 for ; Tue, 19 Jul 2011 04:01:21 -0700 (PDT) Received: by wwe5 with SMTP id 5so2747279wwe.13 for ; Tue, 19 Jul 2011 04:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:mime-version:content-type:content-transfer-encoding; bh=Xbqwze7M+i9VE1ZBQfUvq7209Xi8qDfWuxrLu+n0wpM=; b=eehcqWDlbL4hePZ3M+YaIzQs/ml1sS64367nD7Lhd74gmoBkVjjlRqClpMLA32HbtA NFZVg/86/1lcqlCkYIVhFKQncpb3Qt4xuGGj36UGWXayWlmUY6weRedlaV/UofN3NGC5 FXvvJ5aSYlL6b5IBZIAT1D3nNMc3PK5MUSb3o= Received: by 10.216.170.149 with SMTP id p21mr567326wel.51.1311073280386; Tue, 19 Jul 2011 04:01:20 -0700 (PDT) Received: from [10.61.96.208] (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id t63sm2930148wec.40.2011.07.19.04.01.17 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jul 2011 04:01:19 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Tue, 19 Jul 2011 12:02:57 +0100 Subject: L2VPN minutes... From: Giles Heron To: Message-ID: Thread-Topic: L2VPN minutes... Thread-Index: AcxGA2pZbOLnm64znE+NpieAIGtzEQ== Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 11:01:23 -0000 Hi everyone, First off an apology that I didn't manage to get the minutes out from the Prague IETF out before the deadline. I've included them below in this message... Secondly a promise from Nabil and I that we'll get the minutes out on time after Quebec City. This time I won't rush off on holiday immediately after IETF and forget all about the minutes ;-) And thirdly a call for volunteers to take minutes or jabber scribe in Quebe= c City. There are a few gaps from our minutes in Prague, as we only had one minute taker. At a minimum I'd like to see one minute taker and one jabber scribe so we can use the jabber transcript to fill in any gaps in the minutes. Thanks! Giles ------ L2VPN Minutes - IETF 80 (Prague) 1) Working Group Status Update - Giles a) 2 RFCs published nice the last meeting, RFC 6074 and 6136 There is another in the queue, draft-ietf-l2vpn-vpls-bridge-interop-06 on which there are a few comments from the mailing list, to be addressed and will be fixed in the next week. b) ARP mediation draft - Giles asks Himanshu tasked to finish this draft= ; agreed c) Nabil: OAM VPWS. ATM interworking is not seem as significant, only vendor response was for FRF5. Next Steps - plan to wrap up the document as soon as the vendor survey is completed. d) Giles - remaining draft updates. Multicast - VPLS, looking for more debate around this draft VPMS, looking for a republish from Yuji. VMPS, will cover multi-source but not multi-coverage e) multihoming02 - Wim at the mic saying it is ready for last call. Giles - Please can we have more comments on existing drafts. 2) Re-Charter of L2VPN - Giles a) Who has read it? A show of 6 or so hands of people who have read it. Giles encouraging people to read the re-charter.=A0 b) puts charter up on the screen and has fun with text sizing, then does a quick overview as to the nature of L2VPN charter.=A0 c) E-Tree competing approaches and needs to be resolved. E-VPN, same, a few drafts so a need to resolve this. d) Are the milestones realistic? Need for everyone to think on this and comment back to the group. Milestones for new work, and also for old/existing work. Stewart Bryant arrives. Giles - Again comments requested, deletions comments are as welcome as additions. Giles - Anyone interested in MIB work is welcome also. Giles - Work being done in the data-center area by L2VPN Mic comments: Luca - are we looking at this in both L2VPN and TRILL? Exactly what area is L2 looking at? Nabil - we need to ensure that work that gets picked up is real L2VPN work, this can include data-center to data-center, but not a flat L2 network, VLA= N etc. Rahul, couple of things to add. He likes the charter, the milestones are missing VPMS auto discovery there is a draft for this he will resurrect. Stewart, anyone doing MIBs? Call from Giles again for MIB people. Stewart a= s a concern as to are there enough people prepared to do the work? Do we take things off the charter if people are not interested in the work. Sharam from Broadcom - Is VLAN in the charter or not? Stewart reply, if it is a L2VPN then it is in. Giles - can we also discuss E-Tree? Luca - Are we going back to look at all the ways and details of doing Ethernet frames (IEEE) over L2?=A0 Ali - If IEEE has done the work we should not duplicate, we should interoperate.=A0 Unknown speaker (Broadcom) - QCN question, will L2VPN do interworking with this?=20 Giles - PWE drafts have this in the control word so do we need this again a= s it is already done? Is GRE based VPN in the scope, is there any interest? Giles (continuing with the charter) New E-VPN and E-Tree in as items 7 and 10. Not seeing this group doing work on TP or static VPLS Milestones, some are done and the bad news is many have not. Mic comments: Stewart - do we have doc authors for July docs? 3) VPLS analysis - Jie Dong Overview of the ways to deploy VPLS and select the correct mechanism. Mic Comments: Ali - what is the point of this draft? Concern over the lack of detail of doing a draft with less details, if you need the details then you still nee= d to read the drafts=8A Unknown speaker - Similar comment Luca - no draft needed on having a comparison between methods. How about a draft on what operators thing is missing and or need to be improved. Sasha - agrees with Luca, and perhaps an operators survey would be helpful instead. Unknown speaker (China Telecom) - does not see that there is enough detail and gave some examples. Nabil - anyone read the draft? Looks like it is going to the mailing list. Market has asked for 2 solutions, they have been delivered, we don't track the solutions in this group. 4) VPLS IS-IS - Xiaohu Xu Overview of the notion of adding IS-IS extension to support lightweight VPL= S without other protocols. (BGP/LDP etc) Mic comments: Ali - is this learning Mac addresses against IP addresses? If this is pure data centre then should this be in TRILL. Giles - is this a VPN? Ali - existing solution can be used. Ali - how is multicast done? Xia - use ingress multicast Ali - not efficient Sasha - is this MPLS over IP or GRE Unknown speaker - saying this is already done with TRILL and L2, this draft needs to define exactly what space this is for. Giles - in summary can we define the problem space and perhaps take this to the mailing list? 5) LDP Extensions for Optimized MAC Address Withdrawal in VPLS - Ran Che= n Mic comments: Ali - not sure what the problem actually is, Giles -=A0can we see what in 4762 is broken via the mailing list. 6) BGP MPLS Based Ethernet VPN - Rahul Aggarwal Mic comments: Unknown speaker - Interesting work Giles - sounds like Rahul is ready for final comments on version 2. 7) PBB E-VPN Ali Sajassi Mic comments: Luca - just to clarify the purpose. Florin - comment on the TRILL part, TRILL interworking will be challenging. Ali - TRILL interop is TBD and we need to work out how. 8) VPLS Active/Active Multi-homing - Clarence Filsfils Mic comments: Unknown speaker - Very useful draft, but can we break the text in the draft in 2, can we look at E-VPN and then the changes to VPLS signalling. Clarence - only draft 1 so we can make these types of changes Wim - there are 2 potential solutions, can we combine this one with PBB vpn one, but perhaps analysis needed. Rahul - thinks we need to combine what we mean by VPLS in this draft, and i= s concerned that this draft might change the data plane Clarence - disagrees Lucy - wonders how we will do the signaling in the control plane Clarence - early draft Robert Raszuk - likes the draft Unknown Speaker - question on how would we signal the MHID label under the PW label. Rahul - still thinks this changes the data plane in VPLS, and thinks that w= e can use existing VPLS technology rather than changing the data plane. Nabil - goes to mailing list to continue discussion. VPLS bridge model seem= s to be changed here so this needs to be discussed. Unknown speaker (Ericsson) - wanted to clarify the use of the labels 30 and 31 in the slides Clarence - they are just examples, not proposed reserved labels. 9) Extension to LDP-VPLS for E-Tree using Two PW - Daniel Cohn Mic comments: Florin - root and leaf PEs need to co-ordinate Unknown speaker - Comment this breaks the bridge model Sharam - backwards compatibility, legacy limitations if root and leaf not support on legacy. Unknown speaker - this could be done with a existing PW label instead Luca - thinks the idea is possible, but doing this with interface parameter= s would make this possible. 10) VPLS PE model for E-Tree Support - Yuanlong Jiang Mic comments: Ali - are you suggesting mapping all C-VLAN in to a S-VLAN? If so this will complicate this on bridging side of things. Once it is received you need to double tag and or the VPLS instance? Currently we map PW into the Bridge ID, not the tag as well. Unknown speaker - If the CE is tagged twice or QinQ, are we adding a tag of modifying a tag? Yuanlong - we could do both. 11) Requirement and Framework of VPN-Oriented Cloud Services - Ning So Mic comments: Ali - are we saying that not all the requirements in this draft are for L2VPN? Things like disk space are not part of this working group. Lucy - On slide 3 are these functions done at operator layer of customer level Ning - can be done on both, depends on the tools made available by the operator. Himanshu - the dynamic creation of VPN via an operator is very interesting and should be considered. Giles - this if is an ops work then the requirements might want to be feed back to the L2 group via the Ops WG. 12) Wrap up from Giles and Nabil.=A0 Please can we see active mailing lists and the completion of some of the drafts. From giles.heron@gmail.com Tue Jul 19 05:03:34 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E57B21F85DB for ; Tue, 19 Jul 2011 05:03:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.819 X-Spam-Level: X-Spam-Status: No, score=-2.819 tagged_above=-999 required=5 tests=[AWL=-0.780, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MLB_Stock6=1.56] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id glSHbQ5agb01 for ; Tue, 19 Jul 2011 05:03:33 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id EE71C21F858E for ; Tue, 19 Jul 2011 05:03:32 -0700 (PDT) Received: by wwe5 with SMTP id 5so2782025wwe.13 for ; Tue, 19 Jul 2011 05:03:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:mime-version:content-type:content-transfer-encoding; bh=VGW7iE4WOYTuVIVwtBVJBLMdk1U90YC2uzFPGGC4S9I=; b=yCtxJAUEaCrd7LOQZBWZ8HqrYzEeEvIJiiK1Xd9zm0ps3CMCuFk5P+m5z9Mb/+KzLR 0NG0IJEdlmBqde1j84AboLTLQz7MRH2SPUDRqsGHuD+lxbBCVjZNnlGE+7TXMo6TKgPP jargIu4FV0KhZkuIaJqv5zVeTylUtk4YGLcNA= Received: by 10.216.132.214 with SMTP id o64mr6280793wei.75.1311077012089; Tue, 19 Jul 2011 05:03:32 -0700 (PDT) Received: from [10.61.96.208] (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id c5sm2975652wed.30.2011.07.19.05.03.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 19 Jul 2011 05:03:31 -0700 (PDT) User-Agent: Microsoft-Entourage/12.30.0.110427 Date: Tue, 19 Jul 2011 13:05:03 +0100 Subject: Draft of new L2VPN charter From: Giles Heron To: Message-ID: Thread-Topic: Draft of new L2VPN charter Thread-Index: AcxGDBc4ryMiFbJh/EuVS1imklfgjw== Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: Stewart Bryant X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2011 12:03:34 -0000 Hi everyone, We've reworked the proposed charter, hopefully for the final time. The changes from the last version we sent out are: 1) we removed the reference to control plane distribution of MAC addresses and IP to MAC bindings for E-VPN (since this starts to define solutions rather than requirements). 2) we pushed most of the milestones back and broke out the E-Tree milestone= s into separate lines. Please do take a look and let us know if you have any major objections. If there are no such objections then Stewart will take the charter to the IESG in Quebec City. If, however there are objections then we'll debate them at the WG meeting next week. Nabil and Giles ------ The L2VPN working group is responsible for defining and specifying a limited number of solutions for supporting provider-provisioned Layer-2 Virtual Private Networks (L2VPNs). It will also address requirements driven by cloud computing services and data centers as they apply to Layer-2 VPN services. Layer-2 VPNs defined by L2VPN operate over pseudowires (PWs) as defined by the PWE3 WG or over MPLS PSN tunnels. A L2VPN emulates a "native" service over a PSN that is adequately faithful to, but may not be entirely indistinguishable from the native service itself. Further, following in the "edge-to-edge" nature of the service, the L2VPN WG will not define any mechanisms which exert control over the underlying PSN. When necessary it may, however, recommend or require the use of existing PSN QoS and path control mechanisms between the PEs which provide the L2VPN connectivity. Layer-2 VPNs comprise the following: 1. Virtual Private LAN Service (VPLS) -- A Layer-2 service that emulates a switched Ethernet (V)LAN across an MPLS PSN. 2. Virtual Private Wire Service (VPWS) -- A Layer-2 service that provides point-to-point connectivity for a variety of link layers, including Frame Relay, ATM, Ethernet, PPP, etc., across an MPLS PSN. 3. Virtual Private Multicast Service (VPMS) -- A Layer-2 service that provides point-to-multipoint connectivity for a variety of link layers across an MPLS PSN. 4. IP-only L2VPN =AD An IP-only service over an MPLS PSN. The WG will address two specific types of IP-only L2VPN: a) Point-to-point Layer-2 VPN. This service is similar to VPWS, but also supports heterogenous Attachment Circuits at either end of a single point-to-point service. b) Multipoint-to-multipoint Layer-2 VPN. This service is similar to VPLS, but learns IP and MAC address bindings from ARPs and broadcast/multicast IP packets. 5. Ethernet VPN (E-VPN) - A Layer-2 service that emulates an Ethernet (V)LAN across an MPLS PSN. E-VPN supports load-sharing across multiple connections from a Layer-2 site to an L2VPN service. E-VPN is primarily targeted to support large-scale L2VPNs with resiliency requirements not satisfied by other L2VPN solutions. 6. E-Tree =AD a Layer-2 service defined by the MEF, which provides connectivity between one or more =B3root=B2 nodes and one or more =B3leaf=B2 nodes, with the restriction that leaves may only communicate with roots (and not with each other). L2VPNs will make use of existing IETF specified mechanisms unless there are technical reasons why the existing mechanisms are insufficient or unnecessary. The L2VPN WG is responsible for specification of the discovery and membership of PEs participating in a Layer-2 VPN as well as the membership of CE devices for a specific instance of an L2VPN. The L2VPN WG will provide extensions of existing protocols that will be discussed in protocol-specific WGs. In particular, the L2VPN WG may define extensions to pseudowire management mechanisms for VPLS. Those extensions will be reviewed by the PWE3 WG to ensure they are aligned with the overall design/architecture of PWE3. The L2VPN WG will not define new encapsulations, control, or resiliency mechanisms specifically related to pseudowires. Furthermore, when the L2VPN solution is based on PWs, the L2VPN WG will not define protocol inter-working between an L2VPN and native service Layer-2 OAM or resiliency mechanisms. The L2VPN WG may define how to operate native service-layer control, OAM or resiliency mechanisms on top of an L2VPN. In addition, it may define native data plane and/or control plane interworking between an L2VPN and an associated native Layer-2 service. The L2VPN WG scope includes the following: 1. Discovery of PEs participating in a Layer-2 VPN and the associated topology required for connectivity of the VPLS, VPWS, VPMS or E-VPN service. 2. Signaling of information related to the discovery and membership of PEs within a L2VPN. These procedures must use PWE3 control and management procedures, or define requirements for extensions of PWE3 protocols to suit the needs of an L2VPN, when the L2VPN operates over PWs. Once those requirements have been reviewed by the L2VPN WG, they should be provided to the PWE3 WG to derive solutions. 3. MIBs for Layer-2 VPN solutions. 4. Specification of requirements, framework and solutions that facilitate Operations Administration and Management (OAM) of any type of L2VPN. 5. Mechanisms to permit optimization of multicast data traffic within an L2VPN. 6. If transport does not involve PWs, mechanisms that support load-balancing/multipathing between PEs interconnecting a Layer-2 service using an L2VPN across the MPLS PSN. 7. requirements for the multi-homing of CEs to several VPLS or E-VPN PEs, inclusive of active/backup and active/active (load-sharing) configurations. Based on these requirements define VPLS or E-VPN control plane solutions for achieving fast convergence after failure of an active path in the PSN or on the AC side. 8. Enhancements to increase the scalability of the Control Plane and Data Plane of L2VPN PE nodes, and of core nodes that provide transport services for L2VPN. 9. Requirements and solutions for Auto-Discovery and Signaling of Inter-AS L2VPNs, in addition to Inter-AS solutions for multicast-optimized L2VPNs. 10. Requirements and solutions for supporting "E-Tree" services using VPLS.=20 11. Extensions to L2VPN protocols and RFCs necessary to create an MPLS Transport Profile (MPLS-TP). The work on the MPLS TP will be coordinated between four primary working groups (MPLS, PWE3, L2VPN and CCAMP) that are chartered to do MPLS TP work. Milestones: Done Submit an I-D describing MIB for VPLS Done Submit an I-D describing MIB for VPWS Done Submit an I-D on OAM requirements for VPLS Done Submit an I-D on OAM requirements for VPWS Done Submit L2 requirements to IESG for publication as Informational RFC Done Submit L2 framework to IESG for publication as Informational RF= C Done Identify VPLS and VPWS solutions for the WG Done Submit VPLS solution documents to IESG Done Submit VPWS solution documents to IESG Done Submit Auto-Discovery and Signaling for Intra-AS and Inter-AS VPLS and VPWS Layer-2 VPNs Jul 2011 Submit IP-only L2VPN solution documents to IESG Nov 2011 Submit OAM solutions for VPWS to IESG Nov 2011 Submit OAM solutions for VPLS to IESG Nov 2011 Submit signaling solution for multicast-optimized VPLS to IESG Nov 2011 Submit I-D on Virtual Private Multicast Service (VPMS) requirements to IESG Nov 2011 Submit MIB for VPLS to IESG Nov 2011 Submit MIB for VPWS to IESG Mar 2012 Submit scalability solutions for VPLS Data-Plane to IESG Mar 2012 Submit scalability solutions for VPLS Control-Plane to IESG Mar 2012 Submit E-Tree requirements/framework to IESG Jul 2012 Submit MIB for IP-only L2VPN to IESG Jul 2012 Submit OAM solutions for IP-only L2VPN to IESG Jul 2012 Submit Auto-Discovery solution for VPMS to IESG Jul 2012 Submit VPLS service convergence improvement solutions to IESG Jul 2012 Submit VPLS multi-homing solutions to IESG Jul 2012 Submit E-Tree solution to IESG Jul 2012 Submit E-VPN requirements/framework to IESG Nov 2012 Submit E-Tree MIB/OAM to IESG Nov 2012 Submit E-VPN solution to IESG Mar 2013 Submit E-VPN MIB/OAM to IESG From nabil.n.bitar@verizon.com Wed Jul 20 05:29:32 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E80C21F8757 for ; Wed, 20 Jul 2011 05:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ep9st3mNAyQZ for ; Wed, 20 Jul 2011 05:29:31 -0700 (PDT) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE2421F8753 for ; Wed, 20 Jul 2011 05:29:31 -0700 (PDT) Received: from fldsmtpi03.verizon.com (fldsmtpi03.verizon.com [166.68.71.145]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p6KCTS7G013199 for ; Wed, 20 Jul 2011 08:29:28 -0400 (EDT) From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.67,235,1309737600"; d="scan'208,217";a="96922387" Received: from fldp1lumxc7hb01.verizon.com (HELO FLDP1LUMXC7HB01.us.one.verizon.com) ([166.68.45.78]) by fldsmtpi03.verizon.com with ESMTP; 20 Jul 2011 12:29:28 +0000 Received: from FLDP1LUMXC7HB05.us.one.verizon.com (166.68.75.87) by FLDP1LUMXC7HB01.us.one.verizon.com (166.68.45.78) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 20 Jul 2011 08:29:28 -0400 Received: from fldp1lumxc7v63.us.one.verizon.com ([169.254.3.145]) by FLDP1LUMXC7HB05.us.one.verizon.com ([166.68.75.87]) with mapi; Wed, 20 Jul 2011 08:29:27 -0400 To: "l2vpn@ietf.org" Date: Wed, 20 Jul 2011 08:29:28 -0400 Subject: L2VPN WG Meeting in IETF-81 Quebec City: Updated L2VVPN WG meeting time slot Thread-Topic: L2VPN WG Meeting in IETF-81 Quebec City: Updated L2VVPN WG meeting time slot Thread-Index: AQHMRtiqz/ExOR8rhEieKFfijLSPVQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EE3DB9B68D417942A9B1863918E159FA115D51032BFLDP1LUMXC7V6_" MIME-Version: 1.0 Cc: Giles Heron X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2011 12:29:32 -0000 --_000_EE3DB9B68D417942A9B1863918E159FA115D51032BFLDP1LUMXC7V6_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Please note that the L2VPN WG meeting is now on Thursday, July 28, 2011 13:= 00-15:00. As a result of this time slot update, and based on the agenda we have, ther= e will be no L2VPN WG meeting on Friday July 29, 2011. Regards, Giles & Nabil --_000_EE3DB9B68D417942A9B1863918E159FA115D51032BFLDP1LUMXC7V6_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
Please note that the L2VP= N WG meeting is now on Thursday, July 28, 2011 13:00-15:00.
As a result of this time = slot update, and based on the agenda we have, there will be no L2VPN WG mee= ting on Friday July 29, 2011.
 
Regards,
Giles & Nabil<= /div>
--_000_EE3DB9B68D417942A9B1863918E159FA115D51032BFLDP1LUMXC7V6_-- From nabil.n.bitar@verizon.com Thu Jul 21 07:44:50 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6070621F8AFD for ; Thu, 21 Jul 2011 07:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKv78HT6-rDp for ; Thu, 21 Jul 2011 07:44:49 -0700 (PDT) Received: from sacmail4.verizon.com (sacmail4.verizon.com [192.76.84.42]) by ietfa.amsl.com (Postfix) with ESMTP id DF20D21F8AFB for ; Thu, 21 Jul 2011 07:44:49 -0700 (PDT) Received: from fldsmtpi03.verizon.com (fldsmtpi03.verizon.com [166.68.71.145]) by sacmail4.verizon.com (8.13.7+Sun/8.13.3) with ESMTP id p6LEilia003192 for ; Thu, 21 Jul 2011 10:44:47 -0400 (EDT) From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.67,240,1309737600"; d="scan'208,217";a="97834766" Received: from fldp1lumxc7hb03.verizon.com (HELO FLDP1LUMXC7HB03.us.one.verizon.com) ([166.68.75.86]) by fldsmtpi03.verizon.com with ESMTP; 21 Jul 2011 14:44:46 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([169.254.3.145]) by FLDP1LUMXC7HB03.us.one.verizon.com ([166.68.75.86]) with mapi; Thu, 21 Jul 2011 10:44:46 -0400 To: "l2vpn@ietf.org" Date: Thu, 21 Jul 2011 10:44:42 -0400 Subject: [l2vpn] Presenters' slides for the L2VPN WG session at IETF-81 Quebec City by Wednesday 07/27/2011 9PM Thread-Topic: [l2vpn] Presenters' slides for the L2VPN WG session at IETF-81 Quebec City by Wednesday 07/27/2011 9PM Thread-Index: AcxHtLwAnm6VCNGiR1+oEMQlmreqDQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.10.0.110310 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CA4DB39AD82Cnabilnbitarverizoncom_" MIME-Version: 1.0 Cc: Giles Heron X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2011 14:44:50 -0000 --_000_CA4DB39AD82Cnabilnbitarverizoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, If you have a time slot to present at the L2VPN WG meeting in Quebec city, = please send the slides to me and Giles by Wednesday 07/27/2011 9PM. Your help is appreciated in getting your slides to us in time. Thanks, Giles & Nabil --_000_CA4DB39AD82Cnabilnbitarverizoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
= If you have a time slot to present at the L2VPN WG meeting in Quebec city, = please send the slides to me and Giles by Wednesday 07/27/2011 9PM.
Your help is appreciated in getting your slides to us in time. 

Thanks,
Giles & Nabil
--_000_CA4DB39AD82Cnabilnbitarverizoncom_--