From amirh@orckit.com Mon Oct 4 06:16:39 2010 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9AF773A6FA5; Mon, 4 Oct 2010 06:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Plft56TvBQuO; Mon, 4 Oct 2010 06:16:38 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by core3.amsl.com (Postfix) with ESMTP id 1619C3A6FA4; Mon, 4 Oct 2010 06:16:34 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB63C6.7E4B54BD" Subject: New draft-ram-l2vpn-ldp-vpls-etree-2pw-00 Date: Mon, 4 Oct 2010 15:17:27 +0200 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130617FB1A@tlvmail1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New draft-ram-l2vpn-ldp-vpls-etree-2pw-00 Thread-Index: Actjxn3uJZaOLErzTpaXGCVvPL9l8g== From: "Amir Halperin" To: , , Cc: Rafi Ram X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Oct 2010 13:16:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB63C6.7E4B54BD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all. =20 Your comments regarding l2vpn-ldp-vpls-etree-2pw draft are more then welcomed. =20 Draft location: http://tools.ietf.org/html/draft-ram-l2vpn-ldp-vpls-etree-2pw-00 =20 Thanks in advance, =20 Amir Halperin System Engineer Orckit-Corrigent Systems Ltd Office: +972-3-694-5379 Fax: +972-3-694-3222 Mobile: +972-54-4323-815 mailto:amirh@corrigent.com =20 =20 ------_=_NextPart_001_01CB63C6.7E4B54BD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all.

 

Your comments regarding l2vpn-ldp-vpls-etree-2pw = draft are more then welcomed.

 

Draft location:

http://tools.ietf.org/html/draft-ram-l2vpn-ldp-vpls-etree-2pw-00

 

Thanks in advance,

 

Amir Halperin
System Engineer
Orckit-Corrigent Systems Ltd
Office:  +972-3-694-5379

Fax:    = +972-3-694-3222
Mobile: +972-54-4323-815
mailto:amirh@corrigent.com

 

------_=_NextPart_001_01CB63C6.7E4B54BD-- From pagarwal@broadcom.com Tue Oct 5 00:12:04 2010 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C65E3A6CC4; Tue, 5 Oct 2010 00:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ivR05Oz8wZsq; Tue, 5 Oct 2010 00:11:57 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 659FE3A6B2A; Tue, 5 Oct 2010 00:11:57 -0700 (PDT) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 05 Oct 2010 00:12:44 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR01.corp.ad.broadcom.com ([10.252.49.131]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Tue, 5 Oct 2010 00:12:44 -0700 From: "Puneet Agarwal" To: "Amir Halperin" , "L2vpn@ietf.org" , "mpls@ietf.org" , "pwe3@ietf.org" Date: Tue, 5 Oct 2010 00:12:42 -0700 Subject: RE: New draft-ram-l2vpn-ldp-vpls-etree-2pw-00 Thread-Topic: New draft-ram-l2vpn-ldp-vpls-etree-2pw-00 Thread-Index: Actjxn3uJZaOLErzTpaXGCVvPL9l8gAkyJvA Message-ID: <387E37DE9CCBE9488874DE90FEF401530426387156@SJEXCHCCR01.corp.ad.broadcom.com> References: <44F4E579A764584EA9BDFD07D0CA08130617FB1A@tlvmail1> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130617FB1A@tlvmail1> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 60B410663KC125378183-01-01 Content-Type: multipart/alternative; boundary=_000_387E37DE9CCBE9488874DE90FEF401530426387156SJEXCHCCR01co_ Cc: Rafi Ram X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 07:12:04 -0000 --_000_387E37DE9CCBE9488874DE90FEF401530426387156SJEXCHCCR01co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Amir/Rafi, As I see it, the problem really devolves into the following: For every packet that enters the network, you need to carry (with the packe= t) which interface type (root vs leaf) the packet entered the network. Thi= s property is independent of the PW between any 2 PEs. Doubling the number = of PWs just to carry this information is not very scalable as the number of= managed objects doubles (along with OAM observation points). It seems a be= tter approach would be to carry an additional label below the PW label (or = potentially in the control word) to carry this network ingress interface pr= operty (root vs leaf). A potential hack would be to generalize the entropy label to carry not just= the entropy label but also network ingress interface properties and requir= e entropy label for these PWs (with an option to disable the entropy for lo= ad distribution). I list this only as an option - but I am not too thrilled= about this. Moreover, if you look Ali's preso at the IETF78 on Routed VPLS, it seem to = need not just a single attribute of the network ingress interface but poten= tially may need to carry the network ingress interface id itself (which btw= will have its own naming and scaling challenges - solvable but still a cha= llenge). Architecturally I would hope that the Etree becomes a special case= of Ali's work (and we add a label below the PW label to carry these attrib= utes/id) rather than creating point solutions and blowing out the number of= PWs. Thanks. -Puneet From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ami= r Halperin Sent: Monday, October 04, 2010 6:17 AM To: L2vpn@ietf.org; mpls@ietf.org; pwe3@ietf.org Cc: Rafi Ram Subject: [mpls] New draft-ram-l2vpn-ldp-vpls-etree-2pw-00 Hi all. Your comments regarding l2vpn-ldp-vpls-etree-2pw draft are more then welcom= ed. Draft location: http://tools.ietf.org/html/draft-ram-l2vpn-ldp-vpls-etree-2pw-00 Thanks in advance, Amir Halperin System Engineer Orckit-Corrigent Systems Ltd Office: +972-3-694-5379 Fax: +972-3-694-3222 Mobile: +972-54-4323-815 mailto:amirh@corrigent.com --_000_387E37DE9CCBE9488874DE90FEF401530426387156SJEXCHCCR01co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hi Amir/Rafi,

 

As I see it, the problem really devolves into the following:

For every packet that enters the network, you need to carry (wi= th the packet) which interface type (root  vs leaf) the packet entered th= e network. This property is independent of the PW between any 2 PEs. Doubling= the number of PWs just to carry this information is not very scalable as the nu= mber of managed objects doubles (along with OAM observation points). It seems a better approach would be to carry an additional label below the PW label (o= r potentially in the control word) to carry this network ingress interface property (root vs leaf).

 

A potential hack would be to generalize the entropy label to ca= rry not just the entropy label but also network ingress interface properties an= d require entropy label for these PWs (with an option to disable the entropy = for load distribution). I list this only as an option - but I am not too thrill= ed about this.

 

Moreover, if you look Ali’s preso at the IETF78 on Routed VPLS, it seem to need not just a single attribute of the network ingress interface but potentially may need to carry the network ingress interface i= d itself (which btw will have its own naming and scaling challenges – solvable= but still a challenge). Architecturally I would hope that the Etree becomes a s= pecial case of Ali’s work (and we add a label below the PW label to carry th= ese attributes/id) rather than creating point solutions and blowing out the num= ber of PWs.

 

Thanks.

 

-Puneet

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Am= ir Halperin
Sent: Monday, October 04, 2010 6:17 AM
To: L2vpn@ietf.org; mpls@ietf.org; pwe3@ietf.org
Cc: Rafi Ram
Subject: [mpls] New draft-ram-l2vpn-ldp-vpls-etree-2pw-00=

 

Hi all.

 

Your comments regarding l2vpn-ldp-vpls-etree-2pw draft are more then welcomed.

 

Draft location:

h= ttp://tools.ietf.org/html/draft-ram-l2vpn-ldp-vpls-etree-2pw-00

 

Thanks in advance,

 

Amir Halperin
System Engineer
Orckit-Corrigent Systems Ltd
Office:  +972-3-694-5379

Fax:     +972-3-694-3222
Mobile: +972-54-4323-815
mailto:amirh@corrigent.= com

 

--_000_387E37DE9CCBE9488874DE90FEF401530426387156SJEXCHCCR01co_-- From ju1738@att.com Tue Oct 5 07:46:46 2010 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 50FB93A6F57; Tue, 5 Oct 2010 07:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.404 X-Spam-Level: X-Spam-Status: No, score=-105.404 tagged_above=-999 required=5 tests=[AWL=-0.406, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_22=1, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pWGd+b6YV0A1; Tue, 5 Oct 2010 07:46:35 -0700 (PDT) Received: from mail129.messagelabs.com (mail129.messagelabs.com [216.82.250.147]) by core3.amsl.com (Postfix) with ESMTP id ACA353A6F99; Tue, 5 Oct 2010 07:46:31 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ju1738@att.com X-Msg-Ref: server-9.tower-129.messagelabs.com!1286290047!46432523!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 26767 invoked from network); 5 Oct 2010 14:47:28 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-9.tower-129.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 5 Oct 2010 14:47:28 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o95EkqTX018245; Tue, 5 Oct 2010 10:46:52 -0400 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o95EkmIl018186; Tue, 5 Oct 2010 10:46:49 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB649C.385C39F2" Subject: RE: New draft-ram-l2vpn-ldp-vpls-etree-2pw-00 Date: Tue, 5 Oct 2010 10:47:23 -0400 Message-ID: <1477DEAE19DD884CB004730D0FD77FD7041A8CF1@misout7msgusr7e.ugd.att.com> In-Reply-To: <387E37DE9CCBE9488874DE90FEF401530426387156@SJEXCHCCR01.corp.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New draft-ram-l2vpn-ldp-vpls-etree-2pw-00 Thread-Index: Actjxn3uJZaOLErzTpaXGCVvPL9l8gAkyJvAAA2dHeA= References: <44F4E579A764584EA9BDFD07D0CA08130617FB1A@tlvmail1> <387E37DE9CCBE9488874DE90FEF401530426387156@SJEXCHCCR01.corp.ad.broadcom.com> From: "UTTARO, JAMES (ATTLABS)" To: "Puneet Agarwal" , "Amir Halperin" , , , Cc: Rafi Ram X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Oct 2010 14:46:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB649C.385C39F2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We should take a fresh look at what VPLS deployed on wired networks drives as requirements. The way VPLS is actually realized in the network requires specialized PWs on a per VPN basis, all of our other services use the underlying LSPs built between PEs. This drives unique network/ops models for this service. We want to re-use our existing infrastructure and NM. As VPLS grows I come to the realization that a better paradigm is to treat L2VPN more like L3VPN and carry MAC state in the control plane, re-using data plane learning technology is well suited for LANs and CE<->PE but not for L2VPN over WANs. Specific to E-Tree I believe at best the solutions based on inferring topology information based on examination of a data packet is flawed as it blurs the line between control and data plane functions.. Below find reqs I have socialized before on this forum.. =20 a) Spokes on the same PE that are home into the same VRF are not precluded from communication. There is "special" configuration needed by vendors to preclude intra-spoke communication. Again the control plane semantic is not enforced in the data plane forcing band-aid type solutions. I want the definition of the spoke to preclude the ability to communicate with other spokes. b) Intra-PE PW construction/behavior does not exist.. This means the semantics needed to preclude leaking between Hub and Spoke sites on the same PE needs to have some 'special" config. By definition a Hub and Spoke on the same PE should not be able to communicate, we should not need to configure what is needed on a per vendor basis. This causes much pain in our Ops/System models.. Open Kimono.. BGP signaling and using RTs should be useful here. I am not well versed in LDP signaling but there should be the same requirement there.. No special configuration outside the scope of VPLS signaling. c) Multiple PWs may be useful to restrict data learning inter-PE. This is but based upon how different vendors construct the PW topology. We may find this to be untenable if we have lots of E-Tree and lots of Hubs.. We then have spaghetti... =20 All of the concerns above speak to the same issue.. We are trying to force fit ethernet LAN technology over a WAN by constructing PWs.. =20 Jim Uttaro =20 From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Puneet Agarwal Sent: Tuesday, October 05, 2010 3:13 AM To: Amir Halperin; L2vpn@ietf.org; mpls@ietf.org; pwe3@ietf.org Cc: Rafi Ram Subject: RE: New draft-ram-l2vpn-ldp-vpls-etree-2pw-00 =20 Hi Amir/Rafi, =20 As I see it, the problem really devolves into the following: For every packet that enters the network, you need to carry (with the packet) which interface type (root vs leaf) the packet entered the network. This property is independent of the PW between any 2 PEs. Doubling the number of PWs just to carry this information is not very scalable as the number of managed objects doubles (along with OAM observation points). It seems a better approach would be to carry an additional label below the PW label (or potentially in the control word) to carry this network ingress interface property (root vs leaf).=20 =20 A potential hack would be to generalize the entropy label to carry not just the entropy label but also network ingress interface properties and require entropy label for these PWs (with an option to disable the entropy for load distribution). I list this only as an option - but I am not too thrilled about this. =20 Moreover, if you look Ali's preso at the IETF78 on Routed VPLS, it seem to need not just a single attribute of the network ingress interface but potentially may need to carry the network ingress interface id itself (which btw will have its own naming and scaling challenges - solvable but still a challenge). Architecturally I would hope that the Etree becomes a special case of Ali's work (and we add a label below the PW label to carry these attributes/id) rather than creating point solutions and blowing out the number of PWs.=20 =20 Thanks. =20 -Puneet From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Amir Halperin Sent: Monday, October 04, 2010 6:17 AM To: L2vpn@ietf.org; mpls@ietf.org; pwe3@ietf.org Cc: Rafi Ram Subject: [mpls] New draft-ram-l2vpn-ldp-vpls-etree-2pw-00 =20 Hi all. =20 Your comments regarding l2vpn-ldp-vpls-etree-2pw draft are more then welcomed. =20 Draft location: http://tools.ietf.org/html/draft-ram-l2vpn-ldp-vpls-etree-2pw-00 =20 Thanks in advance, =20 Amir Halperin System Engineer Orckit-Corrigent Systems Ltd Office: +972-3-694-5379 Fax: +972-3-694-3222 Mobile: +972-54-4323-815 mailto:amirh@corrigent.com =20 =20 ------_=_NextPart_001_01CB649C.385C39F2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We should take a fresh look at what VPLS deployed on = wired networks drives as requirements. The way VPLS is actually realized in = the network requires specialized PWs on a per VPN basis, all of our other = services use the underlying LSPs built between PEs. This drives unique = network/ops models for this service. We want to re-use our existing infrastructure = and NM. As VPLS grows I come to the realization that a better paradigm is to treat = L2VPN more like L3VPN and carry MAC state in the control plane, re-using data = plane learning technology is well suited for LANs and CE<->PE but not for L2VPN = over WANs. Specific to E-Tree I believe at best the solutions based on = inferring topology information based on examination of a data packet is flawed as = it blurs the line between control and data plane functions.. Below find = reqs I have socialized before on this forum..

 

a)      Spokes on the same PE that are home into the same VRF are = not precluded from communication. There is “special” = configuration needed by vendors to preclude intra-spoke communication. Again the = control plane semantic is not enforced in the data plane forcing band-aid type = solutions. I want the definition of the spoke to preclude the ability to = communicate with other spokes.

b)      Intra-PE PW construction/behavior does not exist.. This = means the semantics needed to preclude leaking between Hub and Spoke sites on = the same PE needs to have some ‘special” config. By definition a = Hub and Spoke on the same PE should not be able to communicate, we should = not need to configure what is needed on a per vendor basis. This causes much pain = in our Ops/System models.. Open Kimono.. BGP signaling and using RTs should be = useful here. I am not well versed in LDP signaling but there should be the same requirement there.. No special configuration outside the scope of VPLS = signaling.

c)       Multiple PWs may be useful to restrict data learning = inter-PE. This is but based upon how different vendors construct the PW topology. We = may find this to be untenable if we have lots of E-Tree and lots of Hubs.. We = then have spaghetti…

 

All of the concerns above speak to the same issue.. We = are trying to force fit ethernet LAN technology over a WAN by constructing = PWs..

 

Jim Uttaro

 

From:= l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of = Puneet Agarwal
Sent: Tuesday, October 05, 2010 3:13 AM
To: Amir Halperin; L2vpn@ietf.org; mpls@ietf.org; = pwe3@ietf.org
Cc: Rafi Ram
Subject: RE: New = draft-ram-l2vpn-ldp-vpls-etree-2pw-00

 

Hi Amir/Rafi,

 

As I see it, the problem really devolves into the = following:

For every packet that enters the network, you need to carry = (with the packet) which interface type (root  vs leaf) the packet entered = the network. This property is independent of the PW between any 2 PEs. = Doubling the number of PWs just to carry this information is not very scalable as the = number of managed objects doubles (along with OAM observation points). It seems = a better approach would be to carry an additional label below the PW label = (or potentially in the control word) to carry this network ingress interface property (root vs leaf).

 

A potential hack would be to generalize the entropy label to = carry not just the entropy label but also network ingress interface properties = and require entropy label for these PWs (with an option to disable the = entropy for load distribution). I list this only as an option - but I am not too = thrilled about this.

 

Moreover, if you look Ali’s preso at the IETF78 on = Routed VPLS, it seem to need not just a single attribute of the network ingress interface but potentially may need to carry the network ingress = interface id itself (which btw will have its own naming and scaling challenges = – solvable but still a challenge). Architecturally I would hope that the = Etree becomes a special case of Ali’s work (and we add a label below the = PW label to carry these attributes/id) rather than creating point solutions = and blowing out the number of PWs.

 

Thanks.

 

-Puneet

From:= mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Amir Halperin
Sent: Monday, October 04, 2010 6:17 AM
To: L2vpn@ietf.org; mpls@ietf.org; pwe3@ietf.org
Cc: Rafi Ram
Subject: [mpls] New = draft-ram-l2vpn-ldp-vpls-etree-2pw-00

 

Hi all.

 

Your comments regarding l2vpn-ldp-vpls-etree-2pw draft are more then = welcomed.

 

Draft location:

http://tools.ietf.org/html/draft-ram-l2vpn-ldp-vpls-etree-2pw-00

 

Thanks in advance,

 

Amir Halperin
System Engineer
Orckit-Corrigent Systems Ltd
Office:  +972-3-694-5379

Fax:     +972-3-694-3222
Mobile: +972-54-4323-815
mailto:amirh@corrigent.com

 

------_=_NextPart_001_01CB649C.385C39F2-- From amirh@orckit.com Wed Oct 6 01:59:08 2010 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D21E3A6E4B; Wed, 6 Oct 2010 01:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.396 X-Spam-Level: X-Spam-Status: No, score=-1.396 tagged_above=-999 required=5 tests=[AWL=-0.398, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_22=1, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X0-VQ2GLfMXx; Wed, 6 Oct 2010 01:59:00 -0700 (PDT) Received: from tlvmail1.orckit.com (tlvmail1.orckit.com [213.31.203.2]) by core3.amsl.com (Postfix) with ESMTP id F413A3A6B2A; Wed, 6 Oct 2010 01:58:58 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB6534.D8939173" Subject: RE: New draft-ram-l2vpn-ldp-vpls-etree-2pw-00 Date: Wed, 6 Oct 2010 10:59:55 +0200 Message-ID: <44F4E579A764584EA9BDFD07D0CA08130617FF56@tlvmail1> In-reply-to: <1477DEAE19DD884CB004730D0FD77FD7041A8CF1@misout7msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New draft-ram-l2vpn-ldp-vpls-etree-2pw-00 Thread-Index: Actjxn3uJZaOLErzTpaXGCVvPL9l8gAkyJvAAA2dHeAAJl7vEA== References: <44F4E579A764584EA9BDFD07D0CA08130617FB1A@tlvmail1> <387E37DE9CCBE9488874DE90FEF401530426387156@SJEXCHCCR01.corp.ad.broadcom.com> <1477DEAE19DD884CB004730D0FD77FD7041A8CF1@misout7msgusr7e.ugd.att.com> From: "Amir Halperin" To: "UTTARO, JAMES (ATTLABS)" , "Puneet Agarwal" , , , Cc: Rafi Ram X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 08:59:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB6534.D8939173 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jim. =20 I want to make sure I understand your suggestion. Are you suggesting that root/leaf information should be per user i.e. per MAC address, and not per AC? =20 Amir Halperin amirh@orckit.com =20 ________________________________ From: UTTARO, JAMES (ATTLABS) [mailto:ju1738@att.com]=20 Sent: Tuesday, October 05, 2010 4:47 PM To: Puneet Agarwal; Amir Halperin; L2vpn@ietf.org; mpls@ietf.org; pwe3@ietf.org Cc: Rafi Ram Subject: RE: New draft-ram-l2vpn-ldp-vpls-etree-2pw-00 =20 We should take a fresh look at what VPLS deployed on wired networks drives as requirements. The way VPLS is actually realized in the network requires specialized PWs on a per VPN basis, all of our other services use the underlying LSPs built between PEs. This drives unique network/ops models for this service. We want to re-use our existing infrastructure and NM. As VPLS grows I come to the realization that a better paradigm is to treat L2VPN more like L3VPN and carry MAC state in the control plane, re-using data plane learning technology is well suited for LANs and CE<->PE but not for L2VPN over WANs. Specific to E-Tree I believe at best the solutions based on inferring topology information based on examination of a data packet is flawed as it blurs the line between control and data plane functions.. Below find reqs I have socialized before on this forum.. =20 a) Spokes on the same PE that are home into the same VRF are not precluded from communication. There is "special" configuration needed by vendors to preclude intra-spoke communication. Again the control plane semantic is not enforced in the data plane forcing band-aid type solutions. I want the definition of the spoke to preclude the ability to communicate with other spokes. b) Intra-PE PW construction/behavior does not exist.. This means the semantics needed to preclude leaking between Hub and Spoke sites on the same PE needs to have some 'special" config. By definition a Hub and Spoke on the same PE should not be able to communicate, we should not need to configure what is needed on a per vendor basis. This causes much pain in our Ops/System models.. Open Kimono.. BGP signaling and using RTs should be useful here. I am not well versed in LDP signaling but there should be the same requirement there.. No special configuration outside the scope of VPLS signaling. c) Multiple PWs may be useful to restrict data learning inter-PE. This is but based upon how different vendors construct the PW topology. We may find this to be untenable if we have lots of E-Tree and lots of Hubs.. We then have spaghetti... =20 All of the concerns above speak to the same issue.. We are trying to force fit ethernet LAN technology over a WAN by constructing PWs.. =20 Jim Uttaro =20 From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Puneet Agarwal Sent: Tuesday, October 05, 2010 3:13 AM To: Amir Halperin; L2vpn@ietf.org; mpls@ietf.org; pwe3@ietf.org Cc: Rafi Ram Subject: RE: New draft-ram-l2vpn-ldp-vpls-etree-2pw-00 =20 Hi Amir/Rafi, =20 As I see it, the problem really devolves into the following: For every packet that enters the network, you need to carry (with the packet) which interface type (root vs leaf) the packet entered the network. This property is independent of the PW between any 2 PEs. Doubling the number of PWs just to carry this information is not very scalable as the number of managed objects doubles (along with OAM observation points). It seems a better approach would be to carry an additional label below the PW label (or potentially in the control word) to carry this network ingress interface property (root vs leaf).=20 =20 A potential hack would be to generalize the entropy label to carry not just the entropy label but also network ingress interface properties and require entropy label for these PWs (with an option to disable the entropy for load distribution). I list this only as an option - but I am not too thrilled about this. =20 Moreover, if you look Ali's preso at the IETF78 on Routed VPLS, it seem to need not just a single attribute of the network ingress interface but potentially may need to carry the network ingress interface id itself (which btw will have its own naming and scaling challenges - solvable but still a challenge). Architecturally I would hope that the Etree becomes a special case of Ali's work (and we add a label below the PW label to carry these attributes/id) rather than creating point solutions and blowing out the number of PWs.=20 =20 Thanks. =20 -Puneet From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Amir Halperin Sent: Monday, October 04, 2010 6:17 AM To: L2vpn@ietf.org; mpls@ietf.org; pwe3@ietf.org Cc: Rafi Ram Subject: [mpls] New draft-ram-l2vpn-ldp-vpls-etree-2pw-00 =20 Hi all. =20 Your comments regarding l2vpn-ldp-vpls-etree-2pw draft are more then welcomed. =20 Draft location: http://tools.ietf.org/html/draft-ram-l2vpn-ldp-vpls-etree-2pw-00 =20 Thanks in advance, =20 Amir Halperin System Engineer Orckit-Corrigent Systems Ltd Office: +972-3-694-5379 Fax: +972-3-694-3222 Mobile: +972-54-4323-815 mailto:amirh@corrigent.com =20 =20 ------_=_NextPart_001_01CB6534.D8939173 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Jim.

 

I want to make sure I understand = your suggestion.

Are you suggesting that root/leaf information should be per user i.e. per MAC address, and not per = AC?

 

Amir = Halperin

amirh@orckit.com

From: = UTTARO, JAMES (ATTLABS) [mailto:ju1738@att.com]
Sent: Tuesday, October = 05, 2010 4:47 PM
To: Puneet Agarwal; Amir = Halperin; L2vpn@ietf.org; mpls@ietf.org; pwe3@ietf.org
Cc: Rafi Ram
Subject: RE: New draft-ram-l2vpn-ldp-vpls-etree-2pw-00

 

We should = take a fresh look at what VPLS deployed on wired networks drives as = requirements. The way VPLS is actually realized in the network requires specialized PWs on = a per VPN basis, all of our other services use the underlying LSPs built = between PEs. This drives unique network/ops models for this service. We want to = re-use our existing infrastructure and NM. As VPLS grows I come to the realization = that a better paradigm is to treat L2VPN more like L3VPN and carry MAC state in = the control plane, re-using data plane learning technology is well suited = for LANs and CE<->PE but not for L2VPN over WANs. Specific to E-Tree I = believe at best the solutions based on inferring topology information based on = examination of a data packet is flawed as it blurs the line between control and data = plane functions.. Below find reqs I have socialized before on this = forum..

 <= /o:p>

a)      Spokes on the same PE that are home into the same VRF are = not precluded from communication. There is “special” = configuration needed by vendors to preclude intra-spoke communication. Again the = control plane semantic is not enforced in the data plane forcing band-aid type solutions. I want the definition of the spoke to preclude the ability to communicate with other spokes.

b)      Intra-PE PW construction/behavior does not exist.. This = means the semantics needed to preclude leaking between Hub and Spoke sites on = the same PE needs to have some ‘special” config. By definition a = Hub and Spoke on the same PE should not be able to communicate, we should = not need to configure what is needed on a per vendor basis. This causes much pain = in our Ops/System models.. Open Kimono.. BGP signaling and using RTs should be = useful here. I am not well versed in LDP signaling but there should be the same requirement there.. No special configuration outside the scope of VPLS signaling.

c)       Multiple PWs may be useful to restrict data learning = inter-PE. This is but based upon how different vendors construct the PW topology. = We may find this to be untenable if we have lots of E-Tree and lots of Hubs.. = We then have spaghetti…

 <= /o:p>

All of the = concerns above speak to the same issue.. We are trying to force fit ethernet LAN technology over a WAN by constructing PWs..

 <= /o:p>

Jim = Uttaro

 <= /o:p>

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Puneet Agarwal
Sent: Tuesday, October = 05, 2010 3:13 AM
To: Amir Halperin; = L2vpn@ietf.org; mpls@ietf.org; pwe3@ietf.org
Cc: Rafi Ram
Subject: RE: New draft-ram-l2vpn-ldp-vpls-etree-2pw-00

 

Hi = Amir/Rafi,

 

As I see it, the problem really = devolves into the following:

For every packet that enters the = network, you need to carry (with the packet) which interface type (root  vs = leaf) the packet entered the network. This property is independent of the PW = between any 2 PEs. Doubling the number of PWs just to carry this information is = not very scalable as the number of managed objects doubles (along with OAM observation points). It seems a better approach would be to carry an = additional label below the PW label (or potentially in the control word) to carry = this network ingress interface property (root vs leaf). =

 

A potential hack would be to = generalize the entropy label to carry not just the entropy label but also network = ingress interface properties and require entropy label for these PWs (with an = option to disable the entropy for load distribution). I list this only as an = option - but I am not too thrilled about this.

 

Moreover, if you look Ali’s = preso at the IETF78 on Routed VPLS, it seem to need not just a single attribute = of the network ingress interface but potentially may need to carry the network = ingress interface id itself (which btw will have its own naming and scaling = challenges – solvable but still a challenge). Architecturally I would hope that the = Etree becomes a special case of Ali’s work (and we add a label below the = PW label to carry these attributes/id) rather than creating point solutions = and blowing out the number of PWs.

 

Thanks.

 

=

-Puneet

=

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Amir Halperin
Sent: Monday, October 04, = 2010 6:17 AM
To: L2vpn@ietf.org; = mpls@ietf.org; pwe3@ietf.org
Cc: Rafi Ram
Subject: [mpls] New draft-ram-l2vpn-ldp-vpls-etree-2pw-00

 

Hi all.

 

Your comments regarding l2vpn-ldp-vpls-etree-2pw = draft are more then welcomed.

 

Draft location:

http://tools.ietf.org/html/draft-ram-l2vpn-ldp-vpls-etree-2pw-00

 

Thanks in advance,

 

Amir Halperin
System Engineer
Orckit-Corrigent Systems Ltd
Office:  +972-3-694-5379

Fax:    = +972-3-694-3222
Mobile: +972-54-4323-815
mailto:amirh@corrigent.com<= /p>

 

------_=_NextPart_001_01CB6534.D8939173-- From ju1738@att.com Wed Oct 6 08:04:05 2010 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 761B23A70CF; Wed, 6 Oct 2010 08:04:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.336 X-Spam-Level: X-Spam-Status: No, score=-105.336 tagged_above=-999 required=5 tests=[AWL=-0.338, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_22=1, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aF7YBRbkerPL; Wed, 6 Oct 2010 08:03:57 -0700 (PDT) Received: from mail161.messagelabs.com (mail161.messagelabs.com [216.82.253.115]) by core3.amsl.com (Postfix) with ESMTP id 5435D3A6F7B; Wed, 6 Oct 2010 08:03:57 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ju1738@att.com X-Msg-Ref: server-4.tower-161.messagelabs.com!1286377496!27272680!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 10690 invoked from network); 6 Oct 2010 15:04:56 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-4.tower-161.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 6 Oct 2010 15:04:56 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o96F4KqL020806; Wed, 6 Oct 2010 11:04:21 -0400 Received: from misout7msgusr7e.ugd.att.com (misout7msgusr7e.ugd.att.com [144.155.43.107]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o96F4CKq020684; Wed, 6 Oct 2010 11:04:12 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB6567.D0F0A0E6" Subject: RE: New draft-ram-l2vpn-ldp-vpls-etree-2pw-00 Date: Wed, 6 Oct 2010 11:04:47 -0400 Message-ID: <1477DEAE19DD884CB004730D0FD77FD7041A8D05@misout7msgusr7e.ugd.att.com> In-Reply-To: <44F4E579A764584EA9BDFD07D0CA08130617FF56@tlvmail1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New draft-ram-l2vpn-ldp-vpls-etree-2pw-00 Thread-Index: Actjxn3uJZaOLErzTpaXGCVvPL9l8gAkyJvAAA2dHeAAJl7vEAAPf09w References: <44F4E579A764584EA9BDFD07D0CA08130617FB1A@tlvmail1> <387E37DE9CCBE9488874DE90FEF401530426387156@SJEXCHCCR01.corp.ad.broadcom.com> <1477DEAE19DD884CB004730D0FD77FD7041A8CF1@misout7msgusr7e.ugd.att.com> <44F4E579A764584EA9BDFD07D0CA08130617FF56@tlvmail1> From: "UTTARO, JAMES (ATTLABS)" To: "Amir Halperin" , "Puneet Agarwal" , , , Cc: Rafi Ram X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Oct 2010 15:04:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB6567.D0F0A0E6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Amir, =20 No.. I was commenting on the fact that notion of whether a packet is received from a Root/Leaf should not be determined by examination of the packet.. This blurs the line between control/data plane..=20 =20 Jim Uttaro =20 From: Amir Halperin [mailto:amirh@orckit.com]=20 Sent: Wednesday, October 06, 2010 5:00 AM To: UTTARO, JAMES (ATTLABS); Puneet Agarwal; L2vpn@ietf.org; mpls@ietf.org; pwe3@ietf.org Cc: Rafi Ram; raymond.key@ieee.org Subject: RE: New draft-ram-l2vpn-ldp-vpls-etree-2pw-00 =20 Hi Jim. =20 I want to make sure I understand your suggestion. Are you suggesting that root/leaf information should be per user i.e. per MAC address, and not per AC? =20 Amir Halperin amirh@orckit.com =20 ________________________________ From: UTTARO, JAMES (ATTLABS) [mailto:ju1738@att.com]=20 Sent: Tuesday, October 05, 2010 4:47 PM To: Puneet Agarwal; Amir Halperin; L2vpn@ietf.org; mpls@ietf.org; pwe3@ietf.org Cc: Rafi Ram Subject: RE: New draft-ram-l2vpn-ldp-vpls-etree-2pw-00 =20 We should take a fresh look at what VPLS deployed on wired networks drives as requirements. The way VPLS is actually realized in the network requires specialized PWs on a per VPN basis, all of our other services use the underlying LSPs built between PEs. This drives unique network/ops models for this service. We want to re-use our existing infrastructure and NM. As VPLS grows I come to the realization that a better paradigm is to treat L2VPN more like L3VPN and carry MAC state in the control plane, re-using data plane learning technology is well suited for LANs and CE<->PE but not for L2VPN over WANs. Specific to E-Tree I believe at best the solutions based on inferring topology information based on examination of a data packet is flawed as it blurs the line between control and data plane functions.. Below find reqs I have socialized before on this forum.. =20 a) Spokes on the same PE that are home into the same VRF are not precluded from communication. There is "special" configuration needed by vendors to preclude intra-spoke communication. Again the control plane semantic is not enforced in the data plane forcing band-aid type solutions. I want the definition of the spoke to preclude the ability to communicate with other spokes. b) Intra-PE PW construction/behavior does not exist.. This means the semantics needed to preclude leaking between Hub and Spoke sites on the same PE needs to have some 'special" config. By definition a Hub and Spoke on the same PE should not be able to communicate, we should not need to configure what is needed on a per vendor basis. This causes much pain in our Ops/System models.. Open Kimono.. BGP signaling and using RTs should be useful here. I am not well versed in LDP signaling but there should be the same requirement there.. No special configuration outside the scope of VPLS signaling. c) Multiple PWs may be useful to restrict data learning inter-PE. This is but based upon how different vendors construct the PW topology. We may find this to be untenable if we have lots of E-Tree and lots of Hubs.. We then have spaghetti... =20 All of the concerns above speak to the same issue.. We are trying to force fit ethernet LAN technology over a WAN by constructing PWs.. =20 Jim Uttaro =20 From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Puneet Agarwal Sent: Tuesday, October 05, 2010 3:13 AM To: Amir Halperin; L2vpn@ietf.org; mpls@ietf.org; pwe3@ietf.org Cc: Rafi Ram Subject: RE: New draft-ram-l2vpn-ldp-vpls-etree-2pw-00 =20 Hi Amir/Rafi, =20 As I see it, the problem really devolves into the following: For every packet that enters the network, you need to carry (with the packet) which interface type (root vs leaf) the packet entered the network. This property is independent of the PW between any 2 PEs. Doubling the number of PWs just to carry this information is not very scalable as the number of managed objects doubles (along with OAM observation points). It seems a better approach would be to carry an additional label below the PW label (or potentially in the control word) to carry this network ingress interface property (root vs leaf).=20 =20 A potential hack would be to generalize the entropy label to carry not just the entropy label but also network ingress interface properties and require entropy label for these PWs (with an option to disable the entropy for load distribution). I list this only as an option - but I am not too thrilled about this. =20 Moreover, if you look Ali's preso at the IETF78 on Routed VPLS, it seem to need not just a single attribute of the network ingress interface but potentially may need to carry the network ingress interface id itself (which btw will have its own naming and scaling challenges - solvable but still a challenge). Architecturally I would hope that the Etree becomes a special case of Ali's work (and we add a label below the PW label to carry these attributes/id) rather than creating point solutions and blowing out the number of PWs.=20 =20 Thanks. =20 -Puneet From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Amir Halperin Sent: Monday, October 04, 2010 6:17 AM To: L2vpn@ietf.org; mpls@ietf.org; pwe3@ietf.org Cc: Rafi Ram Subject: [mpls] New draft-ram-l2vpn-ldp-vpls-etree-2pw-00 =20 Hi all. =20 Your comments regarding l2vpn-ldp-vpls-etree-2pw draft are more then welcomed. =20 Draft location: http://tools.ietf.org/html/draft-ram-l2vpn-ldp-vpls-etree-2pw-00 =20 Thanks in advance, =20 Amir Halperin System Engineer Orckit-Corrigent Systems Ltd Office: +972-3-694-5379 Fax: +972-3-694-3222 Mobile: +972-54-4323-815 mailto:amirh@corrigent.com =20 =20 ------_=_NextPart_001_01CB6567.D0F0A0E6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Amir,

 

No.. I was commenting on the fact that notion of whether = a packet is received from a Root/Leaf should not be determined by = examination of the packet.. This blurs the line between control/data plane.. =

 

Jim Uttaro

 

From:= Amir = Halperin [mailto:amirh@orckit.com]
Sent: Wednesday, October 06, 2010 5:00 AM
To: UTTARO, JAMES (ATTLABS); Puneet Agarwal; L2vpn@ietf.org; mpls@ietf.org; pwe3@ietf.org
Cc: Rafi Ram; raymond.key@ieee.org
Subject: RE: New = draft-ram-l2vpn-ldp-vpls-etree-2pw-00

 

Hi Jim.

 

I want to make sure I understand your = suggestion.

Are you suggesting that root/leaf information should be per = user i.e. per MAC address, and not per AC?

 

Amir Halperin

amirh@orckit.com

From:= UTTARO, = JAMES (ATTLABS) [mailto:ju1738@att.com]
Sent: Tuesday, October 05, 2010 4:47 PM
To: Puneet Agarwal; Amir Halperin; L2vpn@ietf.org; mpls@ietf.org; pwe3@ietf.org
Cc: Rafi Ram
Subject: RE: New = draft-ram-l2vpn-ldp-vpls-etree-2pw-00

 

We should take a fresh look at what VPLS deployed on = wired networks drives as requirements. The way VPLS is actually realized in = the network requires specialized PWs on a per VPN basis, all of our other = services use the underlying LSPs built between PEs. This drives unique = network/ops models for this service. We want to re-use our existing infrastructure = and NM. As VPLS grows I come to the realization that a better paradigm is to = treat L2VPN more like L3VPN and carry MAC state in the control plane, re-using = data plane learning technology is well suited for LANs and CE<->PE but = not for L2VPN over WANs. Specific to E-Tree I believe at best the solutions = based on inferring topology information based on examination of a data packet is = flawed as it blurs the line between control and data plane functions.. Below = find reqs I have socialized before on this forum..

 

a)      Spokes on the same PE that are home into the same VRF are = not precluded from communication. There is “special” = configuration needed by vendors to preclude intra-spoke communication. Again the = control plane semantic is not enforced in the data plane forcing band-aid type solutions. I want the definition of the spoke to preclude the ability to communicate with other spokes.

b)      Intra-PE PW construction/behavior does not exist.. This = means the semantics needed to preclude leaking between Hub and Spoke sites on = the same PE needs to have some ‘special” config. By definition a = Hub and Spoke on the same PE should not be able to communicate, we should = not need to configure what is needed on a per vendor basis. This causes much pain = in our Ops/System models.. Open Kimono.. BGP signaling and using RTs should be = useful here. I am not well versed in LDP signaling but there should be the same requirement there.. No special configuration outside the scope of VPLS signaling.

c)       Multiple PWs may be useful to restrict data learning = inter-PE. This is but based upon how different vendors construct the PW topology. = We may find this to be untenable if we have lots of E-Tree and lots of Hubs.. = We then have spaghetti…

 

All of the concerns above speak to the same issue.. We = are trying to force fit ethernet LAN technology over a WAN by constructing = PWs..

 

Jim Uttaro

 

From:= l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of = Puneet Agarwal
Sent: Tuesday, October 05, 2010 3:13 AM
To: Amir Halperin; L2vpn@ietf.org; mpls@ietf.org; = pwe3@ietf.org
Cc: Rafi Ram
Subject: RE: New = draft-ram-l2vpn-ldp-vpls-etree-2pw-00

 

Hi Amir/Rafi,

 

As I see it, the problem really devolves into the = following:

For every packet that enters the network, you need to carry = (with the packet) which interface type (root  vs leaf) the packet entered = the network. This property is independent of the PW between any 2 PEs. = Doubling the number of PWs just to carry this information is not very scalable as the = number of managed objects doubles (along with OAM observation points). It seems = a better approach would be to carry an additional label below the PW label = (or potentially in the control word) to carry this network ingress interface property (root vs leaf).

 

A potential hack would be to generalize the entropy label to = carry not just the entropy label but also network ingress interface properties = and require entropy label for these PWs (with an option to disable the = entropy for load distribution). I list this only as an option - but I am not too = thrilled about this.

 

Moreover, if you look Ali’s preso at the IETF78 on = Routed VPLS, it seem to need not just a single attribute of the network ingress interface but potentially may need to carry the network ingress = interface id itself (which btw will have its own naming and scaling challenges = – solvable but still a challenge). Architecturally I would hope that the = Etree becomes a special case of Ali’s work (and we add a label below the = PW label to carry these attributes/id) rather than creating point solutions = and blowing out the number of PWs.

 

Thanks.

 

-Puneet

From:= mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of = Amir Halperin
Sent: Monday, October 04, 2010 6:17 AM
To: L2vpn@ietf.org; mpls@ietf.org; pwe3@ietf.org
Cc: Rafi Ram
Subject: [mpls] New = draft-ram-l2vpn-ldp-vpls-etree-2pw-00

 

Hi all.

 

Your comments regarding l2vpn-ldp-vpls-etree-2pw draft are more then = welcomed.

 

Draft location:

http://tools.ietf.org/html/draft-ram-l2vpn-ldp-vpls-etree-2pw-00

 

Thanks in advance,

 

Amir Halperin
System Engineer
Orckit-Corrigent Systems Ltd
Office:  +972-3-694-5379

Fax:     +972-3-694-3222
Mobile: +972-54-4323-815
mailto:amirh@corrigent.com

 

------_=_NextPart_001_01CB6567.D0F0A0E6-- From giles.heron@gmail.com Tue Oct 12 09:53:43 2010 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82BEE3A68E8 for ; Tue, 12 Oct 2010 09:53:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyedYc1X-5Se for ; Tue, 12 Oct 2010 09:53:42 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id D7CF53A6876 for ; Tue, 12 Oct 2010 09:53:41 -0700 (PDT) Received: by gwb20 with SMTP id 20so1820536gwb.31 for ; Tue, 12 Oct 2010 09:54:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:cc:message-id:thread-topic:thread-index:mime-version :content-type:content-transfer-encoding; bh=NiIgKYwB3gx6YMko77hzc35725aOv4Zfzp5ylyiUbIg=; b=pKb0b/e2ZF4Ddb+s1E9e86g6y+JCvFJ/PBI6HKvn6fLZAwz1xghOI0SStTW8UOHel8 bgEpSO5T+SZ5NEDYt3XtWc7diJjBzb4f/BI8LLyy1mO0vVlOK5KABFC6OfF7HHmT15hW iNyj/rXoMkMLb4eiS1ILXf/Zv5+fEivI9bsug= DomainKey-Signature: a=rsa-sha1; c=nofws; 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; b=qHz1CdN+XJH7DgJtaaWZPzIW6aKaFEWqyG51Z63/Xy8d3tO2l7XXS47b/ZKlks/pOu LYFGRQd34xiA43js84HU3m88pdSM0CqelKPOuyXUO/BfjZLXMSWnQ1MZfjNxsBFTqMff JaCH2sHhwQj6Ad+pUSd39FoJvS+PqJ4IOfefA= Received: by 10.151.40.18 with SMTP id s18mr8835291ybj.252.1286902495797; Tue, 12 Oct 2010 09:54:55 -0700 (PDT) Received: from [171.70.245.176] (dhcp-171-70-245-176.cisco.com [171.70.245.176]) by mx.google.com with ESMTPS id q18sm3995744ybk.15.2010.10.12.09.54.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 12 Oct 2010 09:54:55 -0700 (PDT) User-Agent: Microsoft-Entourage/12.26.0.100708 Date: Tue, 12 Oct 2010 17:56:10 +0100 Subject: Agenda requests for IETF 79 From: Giles Heron To: Message-ID: Thread-Topic: Agenda requests for IETF 79 Thread-Index: ActqLl6ybMmKVvr9rUutI0arJ7rf3g== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: shane@castlepoint.net X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Oct 2010 16:53:43 -0000 Hi L2VPN WG. Please let the chairs know if you have an agenda request for the L2VPN session at IETF 79. For each slot you request please email the chairs your: 1) Draft title 2) Requested duration 3) Presenter name Please let us have your requests by Sunday 24 October. Please note that priority will be given to drafts that are clearly within the scope of the current L2VPN charter. Key dates are: 2010-10-18 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (24:00 UTC). 2010-10-25 (Monday): Internet Draft final submission cut-off by 17:00 PT (24:00 UTC). The preliminary agenda has been posted: https://datatracker.ietf.org/meeting/79/agenda.html Our slot is scheduled for 3:20pm on Thursday November 11th. Shane and Giles From lucyyong@huawei.com Wed Oct 13 12:15:18 2010 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 031043A6A38 for ; Wed, 13 Oct 2010 12:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.522 X-Spam-Level: X-Spam-Status: No, score=-0.522 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GmabdBWJZBbe for ; Wed, 13 Oct 2010 12:15:17 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id E191F3A69D8 for ; Wed, 13 Oct 2010 12:15:16 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA8007RFTJB2W@szxga05-in.huawei.com> for l2vpn@ietf.org; Thu, 14 Oct 2010 03:16:23 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LA8001GGTJBSF@szxga05-in.huawei.com> for l2vpn@ietf.org; Thu, 14 Oct 2010 03:16:23 +0800 (CST) Received: from y736742 ([10.124.12.59]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LA800MCTTJ5KW@szxml04-in.huawei.com> for l2vpn@ietf.org; Thu, 14 Oct 2010 03:16:23 +0800 (CST) Date: Wed, 13 Oct 2010 14:16:16 -0500 From: Yong Lucy Subject: FW: New Version Notification for draft-yong-l2vpn-fat-pw-4-vpls-00 To: l2vpn@ietf.org Message-id: <001c01cb6b0b$1f0f9bc0$3b0c7c0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: ActnHD4rtFoFi8UjRLOZemoV96ld3QD7qgGw X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Oct 2010 19:15:18 -0000 WG: The new draft is submitted. Comments are welcome. Lucy -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Friday, October 08, 2010 2:07 PM To: lucyyong@huawei.com Subject: New Version Notification for draft-yong-l2vpn-fat-pw-4-vpls-00 A new version of I-D, draft-yong-l2vpn-fat-pw-4-vpls-00.txt has been successfully submitted by Lucy Yong and posted to the IETF repository. Filename: draft-yong-l2vpn-fat-pw-4-vpls Revision: 00 Title: Flow-Aware Pseudowire for the Virtual Private LAN Service Creation_date: 2010-10-08 WG ID: Independent Submission Number_of_pages: 9 Abstract: A pseudowire (PW) is used in Virtual Private LAN Service (VPLS) solutions to form any-to-any connections and provide service demuliplexing among Provider Edge routers (PEs), and is normally transported over one single network path. Flow-aware PW enable a PW to take advantage of Equal Cost Multipath (ECMP) and/or Link Aggregation Groups (LAG) in a packet switched network (PSN). PW packets with a flow label can be transported over multi-paths. This method can apply to the PWs in a VPLS service. This document describes how VPLS solutions utilize a PW with a flow label, and defines protocol extension for the provisioning of such PWs. The IETF Secretariat. From root@core3.amsl.com Sun Oct 24 23:00:02 2010 Return-Path: X-Original-To: l2vpn@ietf.org Delivered-To: l2vpn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8DF293A6943; Sun, 24 Oct 2010 23:00:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-l2vpn-oam-req-frmk-11.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101025060002.8DF293A6943@core3.amsl.com> Date: Sun, 24 Oct 2010 23:00:02 -0700 (PDT) Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 06:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : L2VPN OAM Requirements and Framework Author(s) : A. Sajassi, S. Salam Filename : draft-ietf-l2vpn-oam-req-frmk-11.txt Pages : 36 Date : 2010-10-24 This draft provides framework and requirements for Layer 2 Virtual Private Networks (L2VPN) Operation, Administration and Maintenance (OAM). The OAM framework is intended to provide OAM layering across L2VPN services, Pseudo Wires (PWs) and Packet Switched Network (PSN) tunnels. The requirements are intended to identify OAM requirement for L2VPN services (i.e. VPLS, VPWS, and IPLS). Furthermore, if L2VPN services OAM requirements impose specific requirements on PW OAM and/or PSN OAM, those specific PW and/or PSN OAM requirements are also identified. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-oam-req-frmk-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-l2vpn-oam-req-frmk-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-24225145.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 25 00:15:05 2010 Return-Path: X-Original-To: l2vpn@ietf.org Delivered-To: l2vpn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8C5953A67C3; Mon, 25 Oct 2010 00:15:04 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-l2vpn-vpls-bridge-interop-06.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101025071504.8C5953A67C3@core3.amsl.com> Date: Mon, 25 Oct 2010 00:15:04 -0700 (PDT) Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 07:15:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : VPLS Interoperability with CE Bridges Author(s) : A. Sajassi, F. Brockners Filename : draft-ietf-l2vpn-vpls-bridge-interop-06.txt Pages : 19 Date : 2010-10-25 One of the main motivations behind VPLS is its ability to provide connectivity not only among customer routers and servers/hosts but also among customer IEEE bridges. VPLS is expected to deliver the same level of service that current enterprise users are accustomed to from their own enterprise bridged networks or their Ethernet Service Providers. When CE devices are IEEE bridges, then there are certain issues and challenges that need to be accounted for in a VPLS network. The majority of these issues have been addressed in the IEEE 802.1ad standard for provider bridges and they can be leveraged for VPLS networks. This draft extends the PE model described in [RFC-4664] based on IEEE 802.1ad bridge module, and illustrates a clear demarcation between the IEEE bridge module and IETF LAN emulation module. By doing so, it shows that the majority of interoperability issues with CE bridges can be delegated to the 802.1ad bridge module, thus removing the burden on the IETF LAN emulation module within a VPLS PE. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-bridge-interop-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-l2vpn-vpls-bridge-interop-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-25000638.I-D@ietf.org> --NextPart-- From rahul@juniper.net Mon Oct 25 08:53:30 2010 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F0FF3A6A97 for ; Mon, 25 Oct 2010 08:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.599 X-Spam-Level: X-Spam-Status: No, score=-5.599 tagged_above=-999 required=5 tests=[AWL=-0.859, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8GTr-jGDtE1 for ; Mon, 25 Oct 2010 08:53:28 -0700 (PDT) Received: from exprod7og108.obsmtp.com (exprod7og108.obsmtp.com [64.18.2.169]) by core3.amsl.com (Postfix) with ESMTP id B8E583A6A56 for ; Mon, 25 Oct 2010 08:53:28 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob108.postini.com ([64.18.6.12]) with SMTP ID DSNKTMWoXtQb1t0ijjax46y7bQE6EZP4Eoxk@postini.com; Mon, 25 Oct 2010 08:55:14 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB03-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 25 Oct 2010 08:52:36 -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 o9PFqaU57758; Mon, 25 Oct 2010 08:52:36 -0700 (PDT) (envelope-from rahul@juniper.net) Date: Mon, 25 Oct 2010 08:52:36 -0700 From: Rahul Aggarwal To: Subject: RE: draft-ietf-l2vpn-vpls-mcast-06 In-Reply-To: Message-ID: <20101025085028.T89362@sapphire.juniper.net> References: <14C7F4F06DB5814AB0DE29716C4F6D670E804A53@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> <31005_1285119417_4C995DB9_31005_65656_1_20100921182819.H77381@sapphire.juniper.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="0-1138301127-1288021956=:89362" Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 15:53:30 -0000 --0-1138301127-1288021956=:89362 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi All, This has been addressed: http://www.ietf.org/id/draft-ietf-l2vpn-vpls-mcast-08.txt Can the chairs please start a WG last call on this draft? thanks, rahul On Wed, 22 Sep 2010 frederic.jounay@orange-ftgroup.com wrote: > Hi Rahul, > > I agree with the choice2 for the text update > ""An implementation that supports this document MUST support > RSVP-TE P2MP LSPs and MUST support LDP P2MP LSPs." > > Regards, > Fred > > > -----Message d'origine----- > De : l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] De la part de= Rahul Aggarwal > Envoy=E9 : mercredi 22 septembre 2010 03:36 > =C0 : Henderickx, Wim (Wim) > Cc : l2vpn@ietf.org > Objet : Re: draft-ietf-l2vpn-vpls-mcast-06 > > Attention, votre correspondant continue de vous ecrire a votre ancienne a= dresse en @francetelecom.com. > Veuillez lui demander de mettre a jour son carnet d'adresses avec votre n= ouvelle adresse en @orange-ftgroup.com. > Dans quelques semaines, nous refuserons definitivement les messages vers = ce domaine. > En savoir plus: > http://pratique.itn.ftgroup/= FR/catalogue/messagerie/boitesdemessagerie/Pages/fermeturedomainesftorange.= aspx > -------------------------------------------------------------------------= ------------------------------------------------ > > > > > Hi Wim, > > On Tue, 21 Sep 2010, Henderickx, Wim (Wim) wrote: > >> Rahul, >> >> On the draft-ietf-l2vpn-vpls-mcast-06 there is a mandatory requirement f= or P2MP RSVP and NOT for mLDP although it is possible. Some service provid= ers want to use mLDP iso RSVP here, so I believe we should be more flexible= in the draft and allow both. >> Is there a good reason to make only P2MP RSVP mandatory and not mLDP? >> > > This is a side effect of P2MP LDP being relatively immature technology wh= en this draft was originally written. While P2MP RSVP-TE was fairly mature = and deployed. Hence it seemed practically reasonable to mandate P2MP RSVP-T= E but not P2MP LDP. > > If the WG wishes I have no problems in changing the relevant text. The te= xt is: > > "An implementation that supports this document MUST support > RSVP-TE P2MP LSPs and MAY support LDP P2MP LSPs." > > We have two choices: > > 1. Remove the sentence. > > 2. Replace it with: > > ""An implementation that supports this document MUST support > RSVP-TE P2MP LSPs and MUST support LDP P2MP LSPs." > > Which of the above does the WG prefer? > > rahul > > > --0-1138301127-1288021956=:89362-- From root@core3.amsl.com Mon Oct 25 09:00:05 2010 Return-Path: X-Original-To: l2vpn@ietf.org Delivered-To: l2vpn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 75AF53A6A6B; Mon, 25 Oct 2010 09:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-l2vpn-vpls-mcast-08.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101025160003.75AF53A6A6B@core3.amsl.com> Date: Mon, 25 Oct 2010 09:00:02 -0700 (PDT) Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 16:00:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : Multicast in VPLS Author(s) : R. Aggarwal, et al. Filename : draft-ietf-l2vpn-vpls-mcast-08.txt Pages : 46 Date : 2010-10-25 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-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-l2vpn-vpls-mcast-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-25084652.I-D@ietf.org> --NextPart-- From giles.heron@gmail.com Mon Oct 25 09:56:16 2010 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 809253A685B for ; Mon, 25 Oct 2010 09:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNZDj-pOD6YF for ; Mon, 25 Oct 2010 09:56:15 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 6F3EB3A6B30 for ; Mon, 25 Oct 2010 09:56:11 -0700 (PDT) Received: by eyd10 with SMTP id 10so1640736eyd.31 for ; Mon, 25 Oct 2010 09:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:cc:message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type:content-transfer-encoding; bh=FQUt1qPRTn+MrPCxki7XxP44/uIZaE/7R2vfrLpvGrA=; b=xs8v/bjrWkrNevEJ7ZJ9AGyCmoBpK8mijK2Y/hZs56cTPJm4criXnmVi4Gf576rwOt zcxDtA+eLLJzSStwP/XbJpjP7o97rG/sNxUgcb9hT5t/dq9J5ShgKvnEJVTORcaJOlIA DDtcjvQnrif5meaNTb0pmOhaYY8ygqAUcx5S4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=u5LvUJL9X0jiSn2Rxdubkxdp7fr3rGi2xSB3v0IJI7C2pt5puvK2R2qK2d3WzKH2oA uAKio0PVaejPB8odnpxlvszrO3z47MtMaq7wtq+gLTSe0Db5HzvG3FybwH5QyDXGM1E9 MYnYAcvsjfLtFvcmnnZZNDyHBOLowrhHPC9Go= Received: by 10.213.20.136 with SMTP id f8mr569144ebb.8.1288025874971; Mon, 25 Oct 2010 09:57:54 -0700 (PDT) Received: from [192.168.1.164] (64-103-25-233.cisco.com [64.103.25.233]) by mx.google.com with ESMTPS id v51sm3218863eeh.10.2010.10.25.09.57.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 25 Oct 2010 09:57:53 -0700 (PDT) User-Agent: Microsoft-Entourage/12.27.0.100910 Date: Mon, 25 Oct 2010 17:57:53 +0100 Subject: Re: Agenda requests for IETF 79 From: Giles Heron To: Message-ID: Thread-Topic: Agenda requests for IETF 79 Thread-Index: ActqLl6ybMmKVvr9rUutI0arJ7rf3gKN2TDy In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: shane@castlepoint.net X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 16:56:16 -0000 The draft agenda has now been uploaded, at: http://www.ietf.org/proceedings/79/agenda/l2vpn.txt Shane & Giles On 12/10/2010 17:56, "Giles Heron" wrote: > Hi L2VPN WG. > > Please let the chairs know if you have an agenda request for the L2VPN > session at IETF 79. For each slot you request please email the chairs > your: > 1) Draft title > 2) Requested duration > 3) Presenter name > > Please let us have your requests by Sunday 24 October. > > Please note that priority will be given to drafts that are clearly within > the scope of the current L2VPN charter. > > Key dates are: > 2010-10-18 (Monday): Internet Draft Cut-off for initial document (-00) > submission by 17:00 PT (24:00 UTC). > 2010-10-25 (Monday): Internet Draft final submission cut-off by 17:00 PT > (24:00 UTC). > > The preliminary agenda has been posted: > > https://datatracker.ietf.org/meeting/79/agenda.html > > Our slot is scheduled for 3:20pm on Thursday November 11th. > > Shane and Giles > > From root@core3.amsl.com Mon Oct 25 10:15:04 2010 Return-Path: X-Original-To: l2vpn@ietf.org Delivered-To: l2vpn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 40AAD3A6B86; Mon, 25 Oct 2010 10:15:04 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-l2vpn-vpls-ldp-mac-opt-03.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101025171504.40AAD3A6B86@core3.amsl.com> Date: Mon, 25 Oct 2010 10:15:04 -0700 (PDT) Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 17:15:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS Author(s) : P. Dutta, et al. Filename : draft-ietf-l2vpn-vpls-ldp-mac-opt-03.txt Pages : 19 Date : 2010-10-25 [RFC4762] describes a mechanism to remove or unlearn MAC addresses that have been dynamically learned in a VPLS Instance for faster convergence on topology change. The procedure also removes MAC addresses in the VPLS that do not require relearning due to such topology change. This document defines an enhancement to the MAC Address Withdrawal procedure with empty MAC List [RFC4762], which enables a Provider Edge(PE) device to remove only the MAC addresses that need to be relearned. Additional extensions to [RFC4762] MAC Withdrawal procedures are specified to provide optimized MAC flushing for the PBB-VPLS specified in [PBB-VPLS Model]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpls-ldp-mac-opt-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-l2vpn-vpls-ldp-mac-opt-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-25100514.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 25 11:45:01 2010 Return-Path: X-Original-To: l2vpn@ietf.org Delivered-To: l2vpn@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id ADA573A6804; Mon, 25 Oct 2010 11:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action:draft-ietf-l2vpn-vpls-multihoming-02.txt Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20101025184501.ADA573A6804@core3.amsl.com> Date: Mon, 25 Oct 2010 11:45:01 -0700 (PDT) Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Oct 2010 18:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : BGP based Multi-homing in Virtual Private LAN Service Author(s) : B. Kothari, et al. Filename : draft-ietf-l2vpn-vpls-multihoming-02.txt Pages : 27 Date : 2010-10-25 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-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-l2vpn-vpls-multihoming-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-10-25113719.I-D@ietf.org> --NextPart-- From josh.rogers@twcable.com Mon Oct 25 19:48:37 2010 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A240A3A68D3 for ; Mon, 25 Oct 2010 19:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7OQ9Pqwgn2e for ; Mon, 25 Oct 2010 19:48:36 -0700 (PDT) Received: from cdpipgw02.twcable.com (cdpipgw02.twcable.com [165.237.59.23]) by core3.amsl.com (Postfix) with ESMTP id 4C5DC3A680D for ; Mon, 25 Oct 2010 19:48:36 -0700 (PDT) X-SENDER-IP: 10.136.163.14 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.58,239,1286164800"; d="scan'208";a="137896236" Received: from unknown (HELO PRVPEXHUB05.corp.twcable.com) ([10.136.163.14]) by cdpipgw02.twcable.com with ESMTP/TLS/RC4-MD5; 25 Oct 2010 22:50:22 -0400 Received: from PRVPEXVS08.corp.twcable.com ([10.136.163.36]) by PRVPEXHUB05.corp.twcable.com ([10.136.163.14]) with mapi; Mon, 25 Oct 2010 22:50:22 -0400 From: "Rogers, Josh" To: "l2vpn @ ietf . org" Date: Mon, 25 Oct 2010 22:50:21 -0400 Subject: Re: I-D Action:draft-ietf-l2vpn-vpls-multihoming-02.txt Thread-Topic: I-D Action:draft-ietf-l2vpn-vpls-multihoming-02.txt Thread-Index: Act0uIgmU9ZWMQapTXeh9An5iG2fUw== Message-ID: References: <20101025184501.ADA573A6804@core3.amsl.com> In-Reply-To: <20101025184501.ADA573A6804@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 02:48:37 -0000 I realize that it is probably too late to be discussing this for the purpos= e of honing the document, however I'd sure appreciate the edification. Can you tell me, in regards to the statement: In Figure 2, CE1 and CE4 must be dealt with independently, since CE1 is dual-homed, but CE4 is not. How is CE4 'dealt with independently' if its AC is in the same VPLS domain = as PE1-CE1 AC? I can't seem to find where this is explained. If there is= only one PW leading to PE1 from each of the other PE's, how do you 'deal w= ith the PE1-CE4 AC independently?' And if it is be preferring PE1 as the= DF, then how would that scale/work when adding a 5th CE single-homed to PE= 2? Thank you for your time, and explanation. -Josh On Oct 25, 2010, at 1:45 PM, > > w= rote: 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 Working G= roup of the IETF. Title : BGP based Multi-homing in Virtual Private LAN Service Author(s) : B. Kothari, et al. Filename : draft-ietf-l2vpn-vpls-multihoming-02.txt Pages : 27 Date : 2010-10-25 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-02.tx= t Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From wim.henderickx@alcatel-lucent.com Tue Oct 26 06:14:40 2010 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 257E83A67E5 for ; Tue, 26 Oct 2010 06:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.424 X-Spam-Level: X-Spam-Status: No, score=-5.424 tagged_above=-999 required=5 tests=[AWL=0.825, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kG7mTpUFHmqz for ; Tue, 26 Oct 2010 06:14:38 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 5824C3A6802 for ; Tue, 26 Oct 2010 06:14:38 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o9QDAiRD029909 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 26 Oct 2010 15:16:19 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 26 Oct 2010 15:16:12 +0200 From: "Henderickx, Wim (Wim)" To: "Rogers, Josh" , "l2vpn @ ietf . org" Date: Tue, 26 Oct 2010 15:16:10 +0200 Subject: RE: I-D Action:draft-ietf-l2vpn-vpls-multihoming-02.txt Thread-Topic: I-D Action:draft-ietf-l2vpn-vpls-multihoming-02.txt Thread-Index: Act0uIgmU9ZWMQapTXeh9An5iG2fUwAVydRQ Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D670EBCCAC1@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <20101025184501.ADA573A6804@core3.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Oct 2010 13:14:40 -0000 Josh, Each AC has a site id which is used to decide the MH decision upon. This is= described in section 3. So in essence CE4 has a different site id from CE1. Cheers, Wim -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of R= ogers, Josh Sent: dinsdag 26 oktober 2010 4:50 To: l2vpn @ ietf . org Subject: Re: I-D Action:draft-ietf-l2vpn-vpls-multihoming-02.txt=20 I realize that it is probably too late to be discussing this for the purpos= e of honing the document, however I'd sure appreciate the edification. Can you tell me, in regards to the statement: In Figure 2, CE1 and CE4 must be dealt with independently, since CE1 is dual-homed, but CE4 is not. How is CE4 'dealt with independently' if its AC is in the same VPLS domain = as PE1-CE1 AC? I can't seem to find where this is explained. If there is= only one PW leading to PE1 from each of the other PE's, how do you 'deal w= ith the PE1-CE4 AC independently?' And if it is be preferring PE1 as the= DF, then how would that scale/work when adding a 5th CE single-homed to PE= 2? Thank you for your time, and explanation. -Josh On Oct 25, 2010, at 1:45 PM, > > w= rote: 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 Working G= roup of the IETF. Title : BGP based Multi-homing in Virtual Private LAN Service Author(s) : B. Kothari, et al. Filename : draft-ietf-l2vpn-vpls-multihoming-02.txt Pages : 27 Date : 2010-10-25 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-02.tx= t Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ________________________________ This E-mail and any of its attachments may contain Time Warner Cable propri= etary information, which is privileged, confidential, or subject to copyrig= ht belonging to Time Warner Cable. This E-mail is intended solely for the u= se of the individual or entity to which it is addressed. If you are not the= intended recipient of this E-mail, you are hereby notified that any dissem= ination, distribution, copying, or action taken in relation to the contents= of and attachments to this E-mail is strictly prohibited and may be unlawf= ul. If you have received this E-mail in error, please notify the sender imm= ediately and permanently delete the original and any copy of this E-mail an= d any printout. From stbryant@cisco.com Fri Oct 29 07:45:40 2010 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 222583A6A51 for ; Fri, 29 Oct 2010 07:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.588 X-Spam-Level: X-Spam-Status: No, score=-110.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxGkQQ8rYWfR for ; Fri, 29 Oct 2010 07:45:33 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 19CCB3A6A42 for ; Fri, 29 Oct 2010 07:45:27 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.58,259,1286150400"; d="scan'208";a="176579304" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 29 Oct 2010 14:47:21 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.71.48]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o9TElKcm010637; Fri, 29 Oct 2010 14:47:20 GMT Received: from dhcp-gpk02-vlan300-64-103-65-105.cisco.com (localhost [127.0.0.1]) by cisco.com (8.11.7p3+Sun/8.8.8) with ESMTP id o9TElH809662; Fri, 29 Oct 2010 15:47:18 +0100 (BST) Message-ID: <4CCADE75.30600@cisco.com> Date: Fri, 29 Oct 2010 15:47:17 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: "l2vpn@ietf.org" , "Amante, Shane" , Giles Heron , "Bitar, Nabil N" , Adrian Farrel Subject: L2VPN Chairs Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 14:45:40 -0000 Shane Amante, who has been chair of L2VPN since it started in 2005, has unfortunately asked if he can step down from this role due to pressure of other work. Nabil Bitar has accepted the challenge of becoming the new working group chair. In order to achieve a smooth transition Shane has agreed to continue as chair until the end of IETF79, so we will temporarily operate with three chairs. Thanks to Shane for all his hard work over the last five years and welcome Nabil. - Stewart (RTG AD) From loa@pi.nu Fri Oct 29 07:58:18 2010 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC9B83A6A71; Fri, 29 Oct 2010 07:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AkQS-hYaZWua; Fri, 29 Oct 2010 07:58:17 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 8C7FD3A6944; Fri, 29 Oct 2010 07:58:17 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 6E6C0514027; Fri, 29 Oct 2010 17:00:10 +0200 (CEST) Message-ID: <4CCAE17A.1030606@pi.nu> Date: Fri, 29 Oct 2010 17:00:10 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "mpls@ietf.org" , pwe3@ietf.org Subject: change of meeting times for mpls and pwe3 in Beijing Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, CCAMP , MPLS-TP ad hoc team , "mpls-tp@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 14:58:18 -0000 MPLS and PWE3 wg, we are doing a late swap of agenda slots for the mpls and pwe3 working groups at the IETF in Beijing. The mpls working group will be meeting: Monday 15.10 - 16.10 Wednesday 9.00 - 11.30 The pwe3 working group will be meeting: Monday 9.00 - 11.30 Monday 13.00 - 15.00 We don't know if this will be captured on the printed agenda, but the online agenda has been changed and we will make sure that it will be on the IETF message board. Loa for the MPLS and PWE3 chairs -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From loa@pi.nu Fri Oct 29 08:05:54 2010 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0C2B3A684A; Fri, 29 Oct 2010 08:05:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeEL8C9+MqlC; Fri, 29 Oct 2010 08:05:54 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id D78A93A6831; Fri, 29 Oct 2010 08:05:53 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 97F7751403A; Fri, 29 Oct 2010 17:07:47 +0200 (CEST) Message-ID: <4CCAE343.5030809@pi.nu> Date: Fri, 29 Oct 2010 17:07:47 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "mpls@ietf.org" , pwe3@ietf.org Subject: Re: [mpls-tp] change of meeting times for mpls and pwe3 in Beijing References: <4CCAE17A.1030606@pi.nu> In-Reply-To: <4CCAE17A.1030606@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, CCAMP , MPLS-TP ad hoc team , "mpls-tp@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 15:05:55 -0000 All, I've obviously not be looking at the agenda closely enough! The second mpls wg meeting will Thursday - so: Monday 15.10 - 16.10 Thursday 9.00 - 11.30 for the mpls wg /Loa On 2010-10-29 17:00, Loa Andersson wrote: > MPLS and PWE3 wg, > > we are doing a late swap of agenda slots for the mpls and pwe3 > working groups at the IETF in Beijing. > > The mpls working group will be meeting: > > Monday 15.10 - 16.10 > Wednesday 9.00 - 11.30 > > The pwe3 working group will be meeting: > > Monday 9.00 - 11.30 > Monday 13.00 - 15.00 > > We don't know if this will be captured on the printed agenda, but the > online agenda has been changed and we will make sure that it will be > on the IETF message board. > > Loa > > for the MPLS and PWE3 chairs > > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From loa@pi.nu Fri Oct 29 09:45:40 2010 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7023A67FB; Fri, 29 Oct 2010 09:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyoX69Qtw0J5; Fri, 29 Oct 2010 09:45:37 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 814653A67DB; Fri, 29 Oct 2010 09:45:35 -0700 (PDT) Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 47A2D514027; Fri, 29 Oct 2010 18:47:29 +0200 (CEST) Message-ID: <4CCAFAA1.7050902@pi.nu> Date: Fri, 29 Oct 2010 18:47:29 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "mpls@ietf.org" , pwe3@ietf.org Subject: change of meeting times for mpls and pwe3 in Beijing - update References: <4CCAE17A.1030606@pi.nu> <4CCAE343.5030809@pi.nu> In-Reply-To: <4CCAE343.5030809@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: l2vpn@ietf.org, CCAMP , MPLS-TP ad hoc team , "mpls-tp@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Oct 2010 16:45:40 -0000 All, after further discussion we agreed that the PWE3 working group will meet on Monday morning 9.00 - 11.30. The MPLS working group will meet Monday afternoon 15.10 - 16.10 and Thursday morning 9.00 - 11.30. The first slot Monday afternoon (1-3pm) will bused by the secretariat to resolveremaining conflicts. /Loa On 2010-10-29 17:07, Loa Andersson wrote: > All, > > I've obviously not be looking at the agenda closely enough! > > The second mpls wg meeting will Thursday - so: > > Monday 15.10 - 16.10 > Thursday 9.00 - 11.30 > > for the mpls wg > > > /Loa > > > On 2010-10-29 17:00, Loa Andersson wrote: >> MPLS and PWE3 wg, >> >> we are doing a late swap of agenda slots for the mpls and pwe3 >> working groups at the IETF in Beijing. >> >> The mpls working group will be meeting: >> >> Monday 15.10 - 16.10 >> Wednesday 9.00 - 11.30 >> >> The pwe3 working group will be meeting: >> >> Monday 9.00 - 11.30 >> Monday 13.00 - 15.00 >> >> We don't know if this will be captured on the printed agenda, but the >> online agenda has been changed and we will make sure that it will be >> on the IETF message board. >> >> Loa >> >> for the MPLS and PWE3 chairs >> >> > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From wim.henderickx@alcatel-lucent.com Sun Oct 31 10:24:50 2010 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EA413A69B8 for ; Sun, 31 Oct 2010 10:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.589 X-Spam-Level: X-Spam-Status: No, score=-5.589 tagged_above=-999 required=5 tests=[AWL=0.660, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3C6NEK8iZKYX for ; Sun, 31 Oct 2010 10:24:49 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 7114A3A69B0 for ; Sun, 31 Oct 2010 10:24:49 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o9VHQgQ3018051 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 31 Oct 2010 18:26:43 +0100 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.40]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Sun, 31 Oct 2010 18:26:42 +0100 From: "Henderickx, Wim (Wim)" To: "stbryant@cisco.com" , "l2vpn@ietf.org" , "Amante, Shane" , Giles Heron , "Bitar, Nabil N" , Adrian Farrel Date: Sun, 31 Oct 2010 18:26:39 +0100 Subject: RE: L2VPN Chairs Thread-Topic: L2VPN Chairs Thread-Index: Act3eEdiIVAMs+iGRhmUqAlt+ff2bQBqHE1A Message-ID: <14C7F4F06DB5814AB0DE29716C4F6D6710AA6A88@FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com> References: <4CCADE75.30600@cisco.com> In-Reply-To: <4CCADE75.30600@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 17:24:50 -0000 Thanks Shane and welcome Nabil ! -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of S= tewart Bryant Sent: vrijdag 29 oktober 2010 16:47 To: l2vpn@ietf.org; Amante, Shane; Giles Heron; Bitar, Nabil N; Adrian Farr= el Subject: L2VPN Chairs Shane Amante, who has been chair of L2VPN since it started in 2005, has unfortunately asked if he can step down from this role due to pressure of other work. Nabil Bitar has accepted the challenge of becoming the new working group chair. In order to achieve a smooth transition Shane has agreed to continue as chair until the end of IETF79, so we will temporarily operate with three chairs. Thanks to Shane for all his hard work over the last five years and welcome Nabil. - Stewart (RTG AD) From lieven.levrau@alcatel-lucent.com Sun Oct 31 10:31:03 2010 Return-Path: X-Original-To: l2vpn@core3.amsl.com Delivered-To: l2vpn@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AE6E3A69C4 for ; Sun, 31 Oct 2010 10:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.124 X-Spam-Level: X-Spam-Status: No, score=-4.124 tagged_above=-999 required=5 tests=[AWL=2.125, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VAZXFtBD3nZT for ; Sun, 31 Oct 2010 10:31:01 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id A70983A684D for ; Sun, 31 Oct 2010 10:31:00 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o9VHWuCA019613 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 31 Oct 2010 18:32:56 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Sun, 31 Oct 2010 18:32:56 +0100 From: "LEVRAU, LIEVEN (LIEVEN)" To: "Henderickx, Wim (Wim)" , "'stbryant@cisco.com'" , "'l2vpn@ietf.org'" , "'Shane.Amante@Level3.com'" , "'giheron@cisco.com'" , "'nabil.n.bitar@verizon.com'" , "'adrian@olddog.co.uk'" Date: Sun, 31 Oct 2010 18:32:55 +0100 Subject: Re: L2VPN Chairs Thread-Topic: L2VPN Chairs Thread-Index: Act3eEdiIVAMs+iGRhmUqAlt+ff2bQBqHE1AAAA7jA0= Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Oct 2010 17:31:03 -0000 KzENCi4vDQpMaWV2ZW4NCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogbDJ2 cG4tYm91bmNlc0BpZXRmLm9yZyA8bDJ2cG4tYm91bmNlc0BpZXRmLm9yZz4NClRvOiBzdGJyeWFu dEBjaXNjby5jb20gPHN0YnJ5YW50QGNpc2NvLmNvbT47IGwydnBuQGlldGYub3JnIDxsMnZwbkBp ZXRmLm9yZz47IEFtYW50ZSwgU2hhbmUgPFNoYW5lLkFtYW50ZUBMZXZlbDMuY29tPjsgR2lsZXMg SGVyb24gPGdpaGVyb25AY2lzY28uY29tPjsgQml0YXIsIE5hYmlsIE4gPG5hYmlsLm4uYml0YXJA dmVyaXpvbi5jb20+OyBBZHJpYW4gRmFycmVsIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPg0KU2VudDog U3VuIE9jdCAzMSAxODoyNjozOSAyMDEwClN1YmplY3Q6IFJFOiBMMlZQTiBDaGFpcnMNCg0KVGhh bmtzIFNoYW5lIGFuZCB3ZWxjb21lIE5hYmlsICENCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgU3Rld2FydCBCcnlhbnQNClNlbnQ6IHZyaWpkYWcgMjkgb2t0 b2JlciAyMDEwIDE2OjQ3DQpUbzogbDJ2cG5AaWV0Zi5vcmc7IEFtYW50ZSwgU2hhbmU7IEdpbGVz IEhlcm9uOyBCaXRhciwgTmFiaWwgTjsgQWRyaWFuIEZhcnJlbA0KU3ViamVjdDogTDJWUE4gQ2hh aXJzDQoNCg0KU2hhbmUgQW1hbnRlLCB3aG8gaGFzIGJlZW4gY2hhaXIgb2YgTDJWUE4gc2luY2Ug aXQgc3RhcnRlZCBpbiAyMDA1LA0KaGFzIHVuZm9ydHVuYXRlbHkgYXNrZWQgaWYgaGUgY2FuIHN0 ZXAgZG93biBmcm9tIHRoaXMgcm9sZSBkdWUgdG8NCnByZXNzdXJlIG9mIG90aGVyIHdvcmsuDQoN Ck5hYmlsIEJpdGFyIGhhcyBhY2NlcHRlZCB0aGUgY2hhbGxlbmdlIG9mIGJlY29taW5nIHRoZSBu ZXcNCndvcmtpbmcgZ3JvdXAgY2hhaXIuDQoNCkluIG9yZGVyIHRvIGFjaGlldmUgYSBzbW9vdGgg dHJhbnNpdGlvbiBTaGFuZSBoYXMgYWdyZWVkIHRvDQpjb250aW51ZSBhcyBjaGFpciB1bnRpbCB0 aGUgZW5kIG9mIElFVEY3OSwgc28gd2Ugd2lsbCB0ZW1wb3JhcmlseQ0Kb3BlcmF0ZSB3aXRoIHRo cmVlIGNoYWlycy4NCg0KVGhhbmtzIHRvIFNoYW5lIGZvciBhbGwgaGlzIGhhcmQgd29yayBvdmVy IHRoZSBsYXN0IGZpdmUgeWVhcnMNCmFuZCB3ZWxjb21lIE5hYmlsLg0KDQotIFN0ZXdhcnQgKFJU RyBBRCkNCg==