From y.kamite@ntt.com  Tue Jul  7 04:14:59 2009
Return-Path: <y.kamite@ntt.com>
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 56CCA3A6E59 for <l2vpn@core3.amsl.com>; Tue,  7 Jul 2009 04:14:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=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 rfjikIHx7mF3 for <l2vpn@core3.amsl.com>; Tue,  7 Jul 2009 04:14:58 -0700 (PDT)
Received: from mgw4.noc.ntt.com (mgw4.noc.ntt.com [210.160.15.15]) by core3.amsl.com (Postfix) with ESMTP id D947C3A6A95 for <l2vpn@ietf.org>; Tue,  7 Jul 2009 04:14:57 -0700 (PDT)
Received: from mop1.noc.ntt.com by mgw4.noc.ntt.com (NTT-Com MailSV) with ESMTP id n67BEjSO003983; Tue, 7 Jul 2009 20:14:45 +0900 (JST)
Received: from mip01.noc.ntt.com (mvi2.noc.ntt.com) by mop1.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0KME00MIDSKK4M@ntt.com>; Tue, 07 Jul 2009 20:14:45 +0900 (JST)
Date: Tue, 07 Jul 2009 20:14:45 +0900
From: "Yuji KAMITE" <y.kamite@ntt.com>
Subject: RE: Comments on "draft-ietf-l2vpn-vpms-frmwk-requirements"
In-reply-to: <4A2E45A8.9080306@jp.fujitsu.com>
To: tochio@labs.fujitsu.com, l2vpn@ietf.org
Message-id: <03a801c9fef4$21f772b0$b3d80e0a@coe.ntt.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1933
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=iso-2022-jp
Content-transfer-encoding: 7bit
Thread-index: Acno9HF22RyjaEt/TzOkSMhWnoSeBAV/xJWg
References: <4A2E45A8.9080306@jp.fujitsu.com>
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jul 2009 11:14:59 -0000

Hi, Mr. Tochio,

Thank you for your interest and reviewing.
I wrote comments below inline.

> 
> Dear Editors and all,
> 
> FYI:
> Here are my comments on this I-D through offline discussion 
> with Yuji (Mr. Kamite) though some had been posted by Greg
> 
> <<Clause 4.3>>
> I-D says:
> As far as synchronization in a PSN environment is concerned, 
> different mechanisms can be considered to provide frequency 
> and phase clock
> 
> "clock" should be replaced by "synchronization"
> Or in generic manner, "to provide frequency and phase clock " 
> may be removed.
> 

Ok, I'll change the word to avoid confusion.


> 
> <<Clause 6.1.2 (& 6.4)>>
> In general, It seems that contents of those clauses are 
> overlapped to each other so that editorial clean up should be 
> required.
> 
> I think first these sentences are enough in 6.1.2 and the 
> rest of those in 6.1.2 with figure 2 should be merged to 6.4
> 

I'm going to merge it.


> A solution MUST support multiple sender topologies in one 
> VPMS instance, where a common receiver group is reachable 
> from two or more senders. This means that a solution needs to 
> support having multiple P2MP topologies in the backbone whose 
> roots are located apart in a common service. Thus a solution 
> will also need to support protection and restoration 
> mechanism combining these multiple P2MP topologies. (See 
> section 6.4 too).
> 
> 
> And even if in clause 6.1.2., more clarification of Figure 2 
> should be considered. The most important is to clarify AC3 & 
> 4 or PE3 & PE4.
> AC3 or 4 seems to share VPMS instance from either PE1 or PE2. 
> This point should be clarified.
> 
> For example, proposed is
> 
> Replace
> 
> Note that every receiver has only to have one AC connected to 
> each PE to receive traffic. (in Figure 2, AC3 and AC4 respectively).
> Thus a solution will also need to support protection and 
> restoration mechanism combining these multiple P2MP 
> topologies. (See section 6.4 too).
> 
> by
> 
> Note that every receiver has only to have one AC connected to 
> each PE to receive traffic. In the case of Figure 2, PE3 and 
> PE4 should select traffic from PE1 or PE2 and AC3 and AC4 
> should be single as attached to PE3 and PE4 respectively.
> Thus a solution will also need to support protection and 
> restoration mechanism combining these multiple P2MP 
> topologies. (See section 6.4.2 too).
> 
> Of cource, this could be better in align with 6.4.1.2
> 

What you mean by "traffic selection" makes sense. 
This point will be described in the next revision.
It will still need some of wording arrangement though.


> 
> <<Clause 6.1.3>>
> I-D says:
> 　The simplest way to accomplish this is to provide
> 　different VPMS instances for reverse traffic, i.e. a sender CE is a
> 　receiver of another VPMS instance.
> 
> Since there are some alternatives for this way such that 
> providing multiple VPWS (as reverse) or mp2p instance So I 
> ask for relaxing the descrption, i.e. replace "the simplest 
> way" by "the example"
> 

Agreed.

> I-D says:
> Such bi-directional instances can be easily created if two 
> distinct ACs are provisioned for sending and receiving exclusively
> 
> I am not sure this assumption (= exclusively) is easiest.
> I also ask for relaxing the descrption.
> 
> 

It mostly depends on the implementation matter if a particular
approach is the easiest or not, so I'll edit it
not to cause misunderstanding.

Basically, I guess exlusive using (Tx and Rx) might be easy from
PE perspective, but from CE's view it could not be so simple.

Anyway, authors now think that the consideration of reverse traffic
needs more study.  We're proposing new text in the next revision.


> <<Clause 6.1.4>>
> In general, I think these subclauses should focus on
> - Protetion/redundancy topology support as 6.1.4.1
> - Traffic support in Protetion/redundancy as 6.1.4.1 As I 
> wrote above, this is overlapped with 6.1.2 Figure 2 should be 
> moved here and text should be merged with latter of 6.1.2
> 

Agreed with your idea in general.

I'd appreciate it if you could check again
when we submit the next version.


> 
> <<Clause 6.1.4.1>>
> There are some areas that form protection/redundancy:
> (1) (Sender) CE to (Sender/Ingress) PEs
> (2) VPMS instances or inside PSN
> (3) (Receiver) PEs to Receiver CE
> 
> This clause should indicate this point, where 
> protection/redundancy is required. (The use of dual home may miss (2))
> 

I'll make sure the next revision will explain
the category of the protection briefly .  

Regarding (2), I think it needs to describe something for detail:

 "VPMS instance": This requirement is related to the PW signaling
(and discovery etc) between PE nodes.
Hence this will have common aspect of (1)/(3) in terms of solution level.

 "Inside PSN": This requirement will be satisfied by PSN protection mechanism.


> 
> <<Clause 6.1.4.2>>
> As I wrote above, this is overlapped with 6.1.2 Figure 2 
> should be moved to this clause here and text should be merged 
> with latter of 6.1.2
> 

All right.


> 
> Regards,
> Yuji Tochio
> 
> 

Thanks.

Best ragards,
Yuji Kamite


> -----Original Message-----
> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] 
> On Behalf Of Yuji Tochio
> Sent: Tuesday, June 09, 2009 8:21 PM
> To: l2vpn@ietf.org
> Subject: Comments on "draft-ietf-l2vpn-vpms-frmwk-requirements"
> 
> Dear Editors and all,
> 
> FYI:
> Here are my comments on this I-D through offline discussion 
> with Yuji (Mr. Kamite) though some had been posted by Greg
> 
> <<Clause 4.3>>
> I-D says:
> As far as synchronization in a PSN environment is concerned, 
> different mechanisms can be considered to provide frequency 
> and phase clock
> 
> "clock" should be replaced by "synchronization"
> Or in generic manner, "to provide frequency and phase clock " 
> may be removed.
> 
> 
> <<Clause 6.1.2 (& 6.4)>>
> In general, It seems that contents of those clauses are 
> overlapped to each other so that editorial clean up should be 
> required.
> 
> I think first these sentences are enough in 6.1.2 and the 
> rest of those in 6.1.2 with figure 2 should be merged to 6.4
> 
> A solution MUST support multiple sender topologies in one 
> VPMS instance, where a common receiver group is reachable 
> from two or more senders. This means that a solution needs to 
> support having multiple P2MP topologies in the backbone whose 
> roots are located apart in a common service. Thus a solution 
> will also need to support protection and restoration 
> mechanism combining these multiple P2MP topologies. (See 
> section 6.4 too).
> 
> 
> And even if in clause 6.1.2., more clarification of Figure 2 
> should be considered. The most important is to clarify AC3 & 
> 4 or PE3 & PE4.
> AC3 or 4 seems to share VPMS instance from either PE1 or PE2. 
> This point should be clarified.
> 
> For example, proposed is
> 
> Replace
> 
> Note that every receiver has only to have one AC connected to 
> each PE to receive traffic. (in Figure 2, AC3 and AC4 respectively).
> Thus a solution will also need to support protection and 
> restoration mechanism combining these multiple P2MP 
> topologies. (See section 6.4 too).
> 
> by
> 
> Note that every receiver has only to have one AC connected to 
> each PE to receive traffic. In the case of Figure 2, PE3 and 
> PE4 should select traffic from PE1 or PE2 and AC3 and AC4 
> should be single as attached to PE3 and PE4 respectively.
> Thus a solution will also need to support protection and 
> restoration mechanism combining these multiple P2MP 
> topologies. (See section 6.4.2 too).
> 
> Of cource, this could be better in align with 6.4.1.2
> 
> 
> <<Clause 6.1.3>>
> I-D says:
> 　The simplest way to accomplish this is to provide
> 　different VPMS instances for reverse traffic, i.e. a sender CE is a
> 　receiver of another VPMS instance.
> 
> Since there are some alternatives for this way such that 
> providing multiple VPWS (as reverse) or mp2p instance So I 
> ask for relaxing the descrption, i.e. replace "the simplest 
> way" by "the example"
> 
> I-D says:
> Such bi-directional instances can be easily created if two 
> distinct ACs are provisioned for sending and receiving exclusively
> 
> I am not sure this assumption (= exclusively) is easiest.
> I also ask for relaxing the descrption.
> 
> 
> <<Clause 6.1.4>>
> In general, I think these subclauses should focus on
> - Protetion/redundancy topology support as 6.1.4.1
> - Traffic support in Protetion/redundancy as 6.1.4.1 As I 
> wrote above, this is overlapped with 6.1.2 Figure 2 should be 
> moved here and text should be merged with latter of 6.1.2
> 
> 
> <<Clause 6.1.4.1>>
> There are some areas that form protection/redundancy:
> (1) (Sender) CE to (Sender/Ingress) PEs
> (2) VPMS instances or inside PSN
> (3) (Receiver) PEs to Receiver CE
> 
> This clause should indicate this point, where 
> protection/redundancy is required. (The use of dual home may miss (2))
> 
> 
> <<Clause 6.1.4.2>>
> As I wrote above, this is overlapped with 6.1.2 Figure 2 
> should be moved to this clause here and text should be merged 
> with latter of 6.1.2
> 
> 
> Regards,
> Yuji Tochio
> 
> 


From frederic.jounay@orange-ftgroup.com  Tue Jul  7 06:05:21 2009
Return-Path: <frederic.jounay@orange-ftgroup.com>
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 2A6543A6E42 for <l2vpn@core3.amsl.com>; Tue,  7 Jul 2009 06:05:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level: 
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599, HELO_EQ_FR=0.35]
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 PlZxUshL7wRP for <l2vpn@core3.amsl.com>; Tue,  7 Jul 2009 06:05:20 -0700 (PDT)
Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id E3C4D3A6E5C for <l2vpn@ietf.org>; Tue,  7 Jul 2009 06:05:19 -0700 (PDT)
Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959);  Tue, 7 Jul 2009 11:24:56 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: New draft submitted: draft-jounay-delord-l2vpn-ms-pw-provisioning-00
Date: Tue, 7 Jul 2009 11:24:55 +0200
Message-ID: <AFC377AFCC0FBD4DABE49F4B81EC4F1A416C07@ftrdmel1>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: New draft submitted: draft-jounay-delord-l2vpn-ms-pw-provisioning-00
Thread-Index: Acn+rjAV7kkXhLaLRh6WWTCReCmKXQAM4v6Q
From: <frederic.jounay@orange-ftgroup.com>
To: <l2vpn@ietf.org>
X-OriginalArrivalTime: 07 Jul 2009 09:24:56.0282 (UTC) FILETIME=[CAA8ABA0:01C9FEE4]
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Jul 2009 13:05:21 -0000

Dear all,

We submitted a new draft about MS-PW-based L2VPN. The purpose is to give
end to end view by presenting how the tools so far defined relating to
provisioning, auto-discovery and signaling can be used in carrier
networks to allow the dynamic setup of MS-PWs. This document aims at
providing this view by describing the different stages required for an
end to end L2VPN service setup relying on MS-PWs.

Please find the draft via the link below. We will appreciate any
comments and suggestions

http://tools.ietf.org/html/draft-jounay-delord-l2vpn-ms-pw-provisioning-
00


Best Regards,
Fred


From yljiang@huawei.com  Tue Jul  7 18:44:28 2009
Return-Path: <yljiang@huawei.com>
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 0CAE53A6891 for <l2vpn@core3.amsl.com>; Tue,  7 Jul 2009 18:44:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.547
X-Spam-Level: 
X-Spam-Status: No, score=0.547 tagged_above=-999 required=5 tests=[AWL=-0.448,  BAYES_05=-1.11, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  HTML_MESSAGE=0.001, 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 4DEXDDiwEfqg for <l2vpn@core3.amsl.com>; Tue,  7 Jul 2009 18:44:27 -0700 (PDT)
Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 460923A677C for <l2vpn@ietf.org>; Tue,  7 Jul 2009 18:44:27 -0700 (PDT)
Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMF0078PWUG6H@szxga03-in.huawei.com> for l2vpn@ietf.org; Wed, 08 Jul 2009 09:44:40 +0800 (CST)
Received: from huawei.com ([172.24.1.33]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMF00KOBWUGS8@szxga03-in.huawei.com> for l2vpn@ietf.org; Wed, 08 Jul 2009 09:44:40 +0800 (CST)
Received: from j59929 ([10.70.40.52]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KMF009RPWUGQS@szxml06-in.huawei.com> for l2vpn@ietf.org; Wed, 08 Jul 2009 09:44:40 +0800 (CST)
Date: Wed, 08 Jul 2009 09:44:40 +0800
From: Jiang Yuan-long <yljiang@huawei.com>
Subject: New version of draft-jiang-l2vpn-vpls-mac-operation
To: l2vpn@ietf.org
Message-id: <004501c9ff6d$a8ea3810$3428460a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
Content-type: multipart/alternative; boundary="Boundary_(ID_IvEW4sQ2OWAIMgswWiok0w)"
X-Priority: 3
X-MSMail-priority: Normal
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jul 2009 01:44:28 -0000

This is a multi-part message in MIME format.

--Boundary_(ID_IvEW4sQ2OWAIMgswWiok0w)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT

A new version of draft-jiang-l2vpn-vpls-mac-operation
is available, with substantial modifications:
1. Requirements more clarified;
2. Only one method - MAC switching is proposed instead of two;
3. PE addresses rather than PWs are included in the message,
   thus simpler configuration is needed.

You can access this document by the following link:
http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-vpls-mac-operation-01.txt
Any sugestions and comments are greatly appreciated.

   Thanks 
Yuanlong Jiang

--Boundary_(ID_IvEW4sQ2OWAIMgswWiok0w)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=gb2312">
<META content="MSHTML 6.00.2900.3562" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>A new version of 
draft-jiang-l2vpn-vpls-mac-operation<BR>is available, with substantial 
modifications:<BR>1. Requirements more clarified;<BR>2. Only one method - MAC 
switching is proposed instead of two;<BR>3. PE addresses rather than PWs are 
included in the message,<BR>&nbsp;&nbsp; thus simpler configuration is 
needed.<BR></FONT></DIV>
<DIV><FONT face=Arial size=2>You can access this document by the following 
link:</FONT></DIV>
<DIV><FONT face=Arial size=2><A 
href="http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-vpls-mac-operation-01.txt">http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-vpls-mac-operation-01.txt</A></FONT></DIV>
<DIV><FONT face=Arial size=2>Any sugestions and comments are greatly 
appreciated.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&nbsp;&nbsp; Thanks </FONT></DIV>
<DIV><FONT face=Arial size=2>Yuanlong Jiang</FONT></DIV></BODY></HTML>

--Boundary_(ID_IvEW4sQ2OWAIMgswWiok0w)--

From xueli@huawei.com  Tue Jul  7 19:00:23 2009
Return-Path: <xueli@huawei.com>
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 96B503A6A3F; Tue,  7 Jul 2009 19:00:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.705
X-Spam-Level: 
X-Spam-Status: No, score=0.705 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  J_CHICKENPOX_46=0.6, J_CHICKENPOX_47=0.6, 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 U+wOKqgo9-Yj; Tue,  7 Jul 2009 19:00:22 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id F1A373A6955; Tue,  7 Jul 2009 19:00:21 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMF00BFGXKW4Z@szxga04-in.huawei.com>; Wed, 08 Jul 2009 10:00:32 +0800 (CST)
Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMF00JYEXKV72@szxga04-in.huawei.com>; Wed, 08 Jul 2009 10:00:31 +0800 (CST)
Received: from x68103 ([10.111.12.100]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KMF00CPDXKVOE@szxml06-in.huawei.com>; Wed, 08 Jul 2009 10:00:31 +0800 (CST)
Date: Wed, 08 Jul 2009 10:00:31 +0800
From: Sherry Xue <xueli@huawei.com>
Subject: RE: Comments on "draft-ietf-l2vpn-vpms-frmwk-requirements"
In-reply-to: <03a801c9fef4$21f772b0$b3d80e0a@coe.ntt.com>
To: l2vpn@ietf.org, pwe3@ietf.org
Message-id: <!&!AAAAAAAAAAAYAAAAAAAAAPMlHu4Uz9lFgBeeMEjMDZDCgAAAEAAAAL9MXFo9LU1Jri9NfZlIVD0BAAAAAA==@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=gb2312
Content-transfer-encoding: quoted-printable
Thread-index: Acno9HF22RyjaEt/TzOkSMhWnoSeBAV/xJWgAB4DlyA=
Cc: 'Yuji KAMITE' <y.kamite@ntt.com>, tochio@labs.fujitsu.com
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Jul 2009 02:00:23 -0000

Hi, Tochio and Yuji Kamite,=20
I agree with the description of reverse traffic should be relaxed here, =
and=20
I appreciate the consideration of the reverse traffic requirements.
IMO, there are several options to achieve the reverse traffic in VPMS
instance, such as VPMS(forward traffic)+P2P(reverse traffic), =
VPMS(forward
traffic)+mp2p instance(reverse traffic), also may be bidirectional
VPMS(should redefine VPMS maybe).Actually, we have taken the =
implementation
of the reverse traffic into account. And a bidirectional VPMS instance
should be a better method IMO.=20
Here bidirectional VPMS should be defined as P2MP (forward
traffic)+multi-p2p(backward traffic).

What about your opinion?

Anyway, I appreciate the further work for reverse traffic and will be
concerned about it.

Regards
Sherry
 =20

Quote
{> <<Clause 6.1.3>>
> I-D says:
> =A1=A1The simplest way to accomplish this is to provide
> =A1=A1different VPMS instances for reverse traffic, i.e. a sender CE =
is a
> =A1=A1receiver of another VPMS instance.
>=20
> Since there are some alternatives for this way such that=20
> providing multiple VPWS (as reverse) or mp2p instance So I=20
> ask for relaxing the descrption, i.e. replace "the simplest=20
> way" by "the example"
>=20

>Agreed.

> I-D says:
> Such bi-directional instances can be easily created if two=20
> distinct ACs are provisioned for sending and receiving exclusively
>=20
> I am not sure this assumption (=3D exclusively) is easiest.
> I also ask for relaxing the descrption.
>=20
>=20

>It mostly depends on the implementation matter if a particular
>approach is the easiest or not, so I'll edit it
>not to cause misunderstanding.

Basically, I guess exlusive using (Tx and Rx) might be easy from
PE perspective, but from CE's view it could not be so simple.

Anyway, authors now think that the consideration of reverse traffic
needs more study.  We're proposing new text in the next revision.}

> -----Original Message-----
> From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf =
Of
> Yuji KAMITE
> Sent: Tuesday, July 07, 2009 7:15 PM
> To: tochio@labs.fujitsu.com; l2vpn@ietf.org
> Subject: RE: Comments on "draft-ietf-l2vpn-vpms-frmwk-requirements"
>=20
> Hi, Mr. Tochio,
>=20
> Thank you for your interest and reviewing.
> I wrote comments below inline.
>=20
> >
> > Dear Editors and all,
> >
> > FYI:
> > Here are my comments on this I-D through offline discussion
> > with Yuji (Mr. Kamite) though some had been posted by Greg
> >
> > <<Clause 4.3>>
> > I-D says:
> > As far as synchronization in a PSN environment is concerned,
> > different mechanisms can be considered to provide frequency
> > and phase clock
> >
> > "clock" should be replaced by "synchronization"
> > Or in generic manner, "to provide frequency and phase clock "
> > may be removed.
> >
>=20
> Ok, I'll change the word to avoid confusion.
>=20
>=20
> >
> > <<Clause 6.1.2 (& 6.4)>>
> > In general, It seems that contents of those clauses are
> > overlapped to each other so that editorial clean up should be
> > required.
> >
> > I think first these sentences are enough in 6.1.2 and the
> > rest of those in 6.1.2 with figure 2 should be merged to 6.4
> >
>=20
> I'm going to merge it.
>=20
>=20
> > A solution MUST support multiple sender topologies in one
> > VPMS instance, where a common receiver group is reachable
> > from two or more senders. This means that a solution needs to
> > support having multiple P2MP topologies in the backbone whose
> > roots are located apart in a common service. Thus a solution
> > will also need to support protection and restoration
> > mechanism combining these multiple P2MP topologies. (See
> > section 6.4 too).
> >
> >
> > And even if in clause 6.1.2., more clarification of Figure 2
> > should be considered. The most important is to clarify AC3 &
> > 4 or PE3 & PE4.
> > AC3 or 4 seems to share VPMS instance from either PE1 or PE2.
> > This point should be clarified.
> >
> > For example, proposed is
> >
> > Replace
> >
> > Note that every receiver has only to have one AC connected to
> > each PE to receive traffic. (in Figure 2, AC3 and AC4 respectively).
> > Thus a solution will also need to support protection and
> > restoration mechanism combining these multiple P2MP
> > topologies. (See section 6.4 too).
> >
> > by
> >
> > Note that every receiver has only to have one AC connected to
> > each PE to receive traffic. In the case of Figure 2, PE3 and
> > PE4 should select traffic from PE1 or PE2 and AC3 and AC4
> > should be single as attached to PE3 and PE4 respectively.
> > Thus a solution will also need to support protection and
> > restoration mechanism combining these multiple P2MP
> > topologies. (See section 6.4.2 too).
> >
> > Of cource, this could be better in align with 6.4.1.2
> >
>=20
> What you mean by "traffic selection" makes sense.
> This point will be described in the next revision.
> It will still need some of wording arrangement though.
>=20
>=20
> >
> > <<Clause 6.1.3>>
> > I-D says:
> > =A1=A1The simplest way to accomplish this is to provide
> > =A1=A1different VPMS instances for reverse traffic, i.e. a sender CE =
is a
> > =A1=A1receiver of another VPMS instance.
> >
> > Since there are some alternatives for this way such that
> > providing multiple VPWS (as reverse) or mp2p instance So I
> > ask for relaxing the descrption, i.e. replace "the simplest
> > way" by "the example"
> >
>=20
> Agreed.
>=20
> > I-D says:
> > Such bi-directional instances can be easily created if two
> > distinct ACs are provisioned for sending and receiving exclusively
> >
> > I am not sure this assumption (=3D exclusively) is easiest.
> > I also ask for relaxing the descrption.
> >
> >
>=20
> It mostly depends on the implementation matter if a particular
> approach is the easiest or not, so I'll edit it
> not to cause misunderstanding.
>=20
> Basically, I guess exlusive using (Tx and Rx) might be easy from
> PE perspective, but from CE's view it could not be so simple.
>=20
> Anyway, authors now think that the consideration of reverse traffic
> needs more study.  We're proposing new text in the next revision.
>=20
>=20
> > <<Clause 6.1.4>>
> > In general, I think these subclauses should focus on
> > - Protetion/redundancy topology support as 6.1.4.1
> > - Traffic support in Protetion/redundancy as 6.1.4.1 As I
> > wrote above, this is overlapped with 6.1.2 Figure 2 should be
> > moved here and text should be merged with latter of 6.1.2
> >
>=20
> Agreed with your idea in general.
>=20
> I'd appreciate it if you could check again
> when we submit the next version.
>=20
>=20
> >
> > <<Clause 6.1.4.1>>
> > There are some areas that form protection/redundancy:
> > (1) (Sender) CE to (Sender/Ingress) PEs
> > (2) VPMS instances or inside PSN
> > (3) (Receiver) PEs to Receiver CE
> >
> > This clause should indicate this point, where
> > protection/redundancy is required. (The use of dual home may miss =
(2))
> >
>=20
> I'll make sure the next revision will explain
> the category of the protection briefly .
>=20
> Regarding (2), I think it needs to describe something for detail:
>=20
>  "VPMS instance": This requirement is related to the PW signaling
> (and discovery etc) between PE nodes.
> Hence this will have common aspect of (1)/(3) in terms of solution =
level.
>=20
>  "Inside PSN": This requirement will be satisfied by PSN protection
mechanism.
>=20
>=20
> >
> > <<Clause 6.1.4.2>>
> > As I wrote above, this is overlapped with 6.1.2 Figure 2
> > should be moved to this clause here and text should be merged
> > with latter of 6.1.2
> >
>=20
> All right.
>=20
>=20
> >
> > Regards,
> > Yuji Tochio
> >
> >
>=20
> Thanks.
>=20
> Best ragards,
> Yuji Kamite
>=20
>=20
> > -----Original Message-----
> > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]
> > On Behalf Of Yuji Tochio
> > Sent: Tuesday, June 09, 2009 8:21 PM
> > To: l2vpn@ietf.org
> > Subject: Comments on "draft-ietf-l2vpn-vpms-frmwk-requirements"
> >
> > Dear Editors and all,
> >
> > FYI:
> > Here are my comments on this I-D through offline discussion
> > with Yuji (Mr. Kamite) though some had been posted by Greg
> >
> > <<Clause 4.3>>
> > I-D says:
> > As far as synchronization in a PSN environment is concerned,
> > different mechanisms can be considered to provide frequency
> > and phase clock
> >
> > "clock" should be replaced by "synchronization"
> > Or in generic manner, "to provide frequency and phase clock "
> > may be removed.
> >
> >
> > <<Clause 6.1.2 (& 6.4)>>
> > In general, It seems that contents of those clauses are
> > overlapped to each other so that editorial clean up should be
> > required.
> >
> > I think first these sentences are enough in 6.1.2 and the
> > rest of those in 6.1.2 with figure 2 should be merged to 6.4
> >
> > A solution MUST support multiple sender topologies in one
> > VPMS instance, where a common receiver group is reachable
> > from two or more senders. This means that a solution needs to
> > support having multiple P2MP topologies in the backbone whose
> > roots are located apart in a common service. Thus a solution
> > will also need to support protection and restoration
> > mechanism combining these multiple P2MP topologies. (See
> > section 6.4 too).
> >
> >
> > And even if in clause 6.1.2., more clarification of Figure 2
> > should be considered. The most important is to clarify AC3 &
> > 4 or PE3 & PE4.
> > AC3 or 4 seems to share VPMS instance from either PE1 or PE2.
> > This point should be clarified.
> >
> > For example, proposed is
> >
> > Replace
> >
> > Note that every receiver has only to have one AC connected to
> > each PE to receive traffic. (in Figure 2, AC3 and AC4 respectively).
> > Thus a solution will also need to support protection and
> > restoration mechanism combining these multiple P2MP
> > topologies. (See section 6.4 too).
> >
> > by
> >
> > Note that every receiver has only to have one AC connected to
> > each PE to receive traffic. In the case of Figure 2, PE3 and
> > PE4 should select traffic from PE1 or PE2 and AC3 and AC4
> > should be single as attached to PE3 and PE4 respectively.
> > Thus a solution will also need to support protection and
> > restoration mechanism combining these multiple P2MP
> > topologies. (See section 6.4.2 too).
> >
> > Of cource, this could be better in align with 6.4.1.2
> >
> >
> > <<Clause 6.1.3>>
> > I-D says:
> > =A1=A1The simplest way to accomplish this is to provide
> > =A1=A1different VPMS instances for reverse traffic, i.e. a sender CE =
is a
> > =A1=A1receiver of another VPMS instance.
> >
> > Since there are some alternatives for this way such that
> > providing multiple VPWS (as reverse) or mp2p instance So I
> > ask for relaxing the descrption, i.e. replace "the simplest
> > way" by "the example"
> >
> > I-D says:
> > Such bi-directional instances can be easily created if two
> > distinct ACs are provisioned for sending and receiving exclusively
> >
> > I am not sure this assumption (=3D exclusively) is easiest.
> > I also ask for relaxing the descrption.
> >
> >
> > <<Clause 6.1.4>>
> > In general, I think these subclauses should focus on
> > - Protetion/redundancy topology support as 6.1.4.1
> > - Traffic support in Protetion/redundancy as 6.1.4.1 As I
> > wrote above, this is overlapped with 6.1.2 Figure 2 should be
> > moved here and text should be merged with latter of 6.1.2
> >
> >
> > <<Clause 6.1.4.1>>
> > There are some areas that form protection/redundancy:
> > (1) (Sender) CE to (Sender/Ingress) PEs
> > (2) VPMS instances or inside PSN
> > (3) (Receiver) PEs to Receiver CE
> >
> > This clause should indicate this point, where
> > protection/redundancy is required. (The use of dual home may miss =
(2))
> >
> >
> > <<Clause 6.1.4.2>>
> > As I wrote above, this is overlapped with 6.1.2 Figure 2
> > should be moved to this clause here and text should be merged
> > with latter of 6.1.2
> >
> >
> > Regards,
> > Yuji Tochio
> >
> >


From shane@castlepoint.net  Wed Jul  8 19:07:21 2009
Return-Path: <shane@castlepoint.net>
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 17C2D3A6FD4 for <l2vpn@core3.amsl.com>; Wed,  8 Jul 2009 19:07:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Level: 
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[AWL=0.306,  BAYES_00=-2.599, SARE_MLH_Stock1=0.87]
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 kvJbHi2uaJ1p for <l2vpn@core3.amsl.com>; Wed,  8 Jul 2009 19:07:20 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 69D353A6FC4 for <l2vpn@ietf.org>; Wed,  8 Jul 2009 19:07:20 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id CBD1D2684EA; Wed,  8 Jul 2009 20:07:47 -0600 (MDT)
Received: from mbpw.castlepoint.net (71-215-80-228.hlrn.qwest.net [71.215.80.228]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for l2vpn@ietf.org; Wed, 08 Jul 2009 20:07:47 -0600 (MDT) (envelope-from shane@castlepoint.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.215.80.228; client-port=1323; syn-fingerprint=65535:55:1:64:M1452,N,W3,N,N,T,S; data-bytes=0
Message-Id: <59ADA35F-69BF-45EF-AA98-39A8A5BB5D4D@castlepoint.net>
From: Shane Amante <shane@castlepoint.net>
To: l2vpn@ietf.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Time slots for IETF 75 @ Stockholm?
Date: Wed, 8 Jul 2009 20:07:32 -0600
X-Mailer: Apple Mail (2.935.3)
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jul 2009 02:07:21 -0000

Hi All,

Please let the chairs know if you would like a time slot for the L2VPN  
WG meeting at IETF 75.  We have been allocated a 2.5 hour slot on  
THURSDAY, July 30, 2009:
0900-1130 Morning Session I
Congresshall B    INT    l2vpn   Layer 2 Virtual Private Networks WG

Please keep in mind, the WG meeting is not a place to just present  
your draft to the audience.  Rather, the intent is to bring up  
outstanding questions or areas that require input from WG members for  
further development.

Please include in your request for a slot:
1)  URL to your Internet Draft
2)  Amount of time requested
3)  Brief outline of your agenda, open questions & areas of further  
development you hope to solicit feedback from the WG

Thanks,

-shane & Vach
(co-chairs L2VPN WG)


From linux.yahoo@gmail.com  Thu Jul  9 07:10:05 2009
Return-Path: <linux.yahoo@gmail.com>
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 1C4003A689A for <l2vpn@core3.amsl.com>; Thu,  9 Jul 2009 07:10:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[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 fkwKSGGCc31y for <l2vpn@core3.amsl.com>; Thu,  9 Jul 2009 07:10:04 -0700 (PDT)
Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 024373A6B2D for <l2vpn@ietf.org>; Thu,  9 Jul 2009 07:10:03 -0700 (PDT)
Received: by fxm18 with SMTP id 18so199052fxm.37 for <l2vpn@ietf.org>; Thu, 09 Jul 2009 07:10:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=4koU8M4u+mO3KhCkcsUQ3YY9lgGfXGaQcOvUj6Lhocc=; b=O7ch5AU36DvSBj2KIcAXDLuwc+AoiWY9VQ6Ob7uckJlR6lEdfdGmpcv6IIWBGrEzBw yD3L9AqVCLEbnWfLvb/CASFrbOog2qri/pnXn56mVSOR8byJcNJolivWbkbTR4/SEAlF fc2m/DVYmHHBRJZmhaTT2LCMw0zpDajDR5k1w=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ksxVtSGRCkPeAb2AwNpd8JZK6wEfpA283PMzekzgdRBj5VrkaXG3apTYNrUrXw5qnY 4WFc6fU96L22R7jjW6vEYO88cQ9URP+PpWfEbXj5kDwluE7Sz+sPKgE9nEYUcHLZPA6P ZKIGcFtCtRtjGe1xL3udVyc+Mhs5NV+80mSyA=
MIME-Version: 1.0
Received: by 10.223.116.77 with SMTP id l13mr359704faq.106.1247148629141; Thu,  09 Jul 2009 07:10:29 -0700 (PDT)
Date: Thu, 9 Jul 2009 16:10:29 +0200
Message-ID: <7100ed370907090710m5214595fta2a8c3ba748271bf@mail.gmail.com>
Subject: VPLS Dual Homing
From: Manu Chao <linux.yahoo@gmail.com>
To: l2vpn@ietf.org
Content-Type: multipart/alternative; boundary=001636c5afb605a989046e466b0b
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jul 2009 14:10:05 -0000

--001636c5afb605a989046e466b0b
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Is there any draft/rfc coming about VPLS Dual Homing?

AFAIK when using BGP signaling, it was possible to connect a site to
muliples PEs by using the same site-id, BGP will choose.

AFAIK when using LDP signaling, STP between CEs/PEs can be used (option 1)
or ICCP betweens PEs (option 2) can be used.

Is there any way to have a common design? or is it the same debate than
previous one?

Thanks in advance

--001636c5afb605a989046e466b0b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>Is there any draft/rfc coming about=A0VPLS Dual Homing?</div>
<div>=A0</div>
<div>AFAIK when using BGP signaling, it was possible to connect a site to m=
uliples PEs by using the same site-id, BGP will choose.</div>
<div>=A0</div>
<div>AFAIK when using LDP=A0signaling, STP between CEs/PEs can be used (opt=
ion 1) or=A0ICCP betweens PEs (option 2) can be used.</div>
<div>
<div>=A0</div>
<div>Is there any way to have a common design? or is it the same debate tha=
n previous one?</div>
<div>=A0</div>
<div>Thanks in advance</div></div>

--001636c5afb605a989046e466b0b--

From wim.henderickx@alcatel-lucent.be  Thu Jul  9 07:15:43 2009
Return-Path: <wim.henderickx@alcatel-lucent.be>
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 5468A28C222 for <l2vpn@core3.amsl.com>; Thu,  9 Jul 2009 07:15:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.748
X-Spam-Level: 
X-Spam-Status: No, score=-5.748 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, 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 VluzFOB2WeRw for <l2vpn@core3.amsl.com>; Thu,  9 Jul 2009 07:15:42 -0700 (PDT)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 199F63A6AB0 for <l2vpn@ietf.org>; Thu,  9 Jul 2009 07:15:41 -0700 (PDT)
Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n69EFpaI024573;  Thu, 9 Jul 2009 16:16:07 +0200
Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS05.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Jul 2009 16:15:27 +0200
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_01CA009F.B50FA0E5"
Subject: Re: VPLS Dual Homing
Date: Thu, 9 Jul 2009 16:15:26 +0200
Message-ID: <B128F666D4C8BD4FBF56CEAFB2DB66D704912E68@FRVELSMBS22.ad2.ad.alcatel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: VPLS Dual Homing
Thread-Index: AcoAnw3e0SJuskVsSAqTq5ArkZVJYgAAKchx
From: "HENDERICKX Wim" <wim.henderickx@alcatel-lucent.be>
To: <linux.yahoo@gmail.com>, <l2vpn@ietf.org>
X-OriginalArrivalTime: 09 Jul 2009 14:15:27.0611 (UTC) FILETIME=[B55DE4B0:01CA009F]
X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jul 2009 14:15:43 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CA009F.B50FA0E5
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: base64

VGhlcmUgaXMgYSBjb21tb24gZHJhZnQgcG9zdGVkIHRoaXMgd2VlayB3aGljaCBhZGRyZXNzZXMg
bWggZm9yIGJvdGggbGRwIGFuZCBiZ3AgYmFzZWQgdnBscy4gSSBhbSBvbiBtb2JpbGUgbm93LCBi
dXQgY291bGQgc2VuZCBpdCBsYXRlciB0byB5b3UuIA0KDQpDaGVlcnMsIA0KV2ltIA0KX19fX19f
X19fX19fX19fX18gDQpzZW50IGZyb20gYmxhY2tiZXJyeQ0KDQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KDQpGcm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIDxsMnZwbi1ib3Vu
Y2VzQGlldGYub3JnPiANClRvOiBsMnZwbkBpZXRmLm9yZyA8bDJ2cG5AaWV0Zi5vcmc+IA0KU2Vu
dDogVGh1IEp1bCAwOSAxNjoxMDoyOSAyMDA5DQpTdWJqZWN0OiBWUExTIER1YWwgSG9taW5nIA0K
DQoNCklzIHRoZXJlIGFueSBkcmFmdC9yZmMgY29taW5nIGFib3V0IFZQTFMgRHVhbCBIb21pbmc/
DQogDQpBRkFJSyB3aGVuIHVzaW5nIEJHUCBzaWduYWxpbmcsIGl0IHdhcyBwb3NzaWJsZSB0byBj
b25uZWN0IGEgc2l0ZSB0byBtdWxpcGxlcyBQRXMgYnkgdXNpbmcgdGhlIHNhbWUgc2l0ZS1pZCwg
QkdQIHdpbGwgY2hvb3NlLg0KIA0KQUZBSUsgd2hlbiB1c2luZyBMRFAgc2lnbmFsaW5nLCBTVFAg
YmV0d2VlbiBDRXMvUEVzIGNhbiBiZSB1c2VkIChvcHRpb24gMSkgb3IgSUNDUCBiZXR3ZWVucyBQ
RXMgKG9wdGlvbiAyKSBjYW4gYmUgdXNlZC4NCiANCklzIHRoZXJlIGFueSB3YXkgdG8gaGF2ZSBh
IGNvbW1vbiBkZXNpZ24/IG9yIGlzIGl0IHRoZSBzYW1lIGRlYmF0ZSB0aGFuIHByZXZpb3VzIG9u
ZT8NCiANClRoYW5rcyBpbiBhZHZhbmNlDQo=

------_=_NextPart_001_01CA009F.B50FA0E5
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: base64

PGRpdj48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPg0KVGhlcmUgaXMgYSBjb21t
b24gZHJhZnQgcG9zdGVkIHRoaXMgd2VlayB3aGljaCBhZGRyZXNzZXMgbWggZm9yIGJvdGggbGRw
IGFuZCBiZ3AgYmFzZWQgdnBscy4gSSBhbSBvbiBtb2JpbGUgbm93LCBidXQgY291bGQgc2VuZCBp
dCBsYXRlciB0byB5b3UuDTxicj4NPGJyPkNoZWVycywNPGJyPldpbQ08YnI+X19fX19fX19fX19f
X19fX18NPGJyPnNlbnQgZnJvbSBibGFja2JlcnJ5PC9mb250PjwvZGl2Pg0KPGJyPjxkaXY+PGhy
IHNpemU9MiB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyIHRhYmluZGV4PS0xPg0KPGZvbnQgZmFj
ZT1UYWhvbWEgc2l6ZT0yPg0KPGI+RnJvbTwvYj46IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcgJmx0
O2wydnBuLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DTxicj48Yj5UbzwvYj46IGwydnBuQGlldGYub3Jn
ICZsdDtsMnZwbkBpZXRmLm9yZyZndDsNPGJyPjxiPlNlbnQ8L2I+OiBUaHUgSnVsIDA5IDE2OjEw
OjI5IDIwMDk8YnI+PGI+U3ViamVjdDwvYj46IFZQTFMgRHVhbCBIb21pbmcNPGJyPjwvZm9udD48
YnI+PC9kaXY+DQo8ZGl2PklzIHRoZXJlIGFueSBkcmFmdC9yZmMgY29taW5nIGFib3V0wqBWUExT
IER1YWwgSG9taW5nPzwvZGl2Pg0KPGRpdj7CoDwvZGl2Pg0KPGRpdj5BRkFJSyB3aGVuIHVzaW5n
IEJHUCBzaWduYWxpbmcsIGl0IHdhcyBwb3NzaWJsZSB0byBjb25uZWN0IGEgc2l0ZSB0byBtdWxp
cGxlcyBQRXMgYnkgdXNpbmcgdGhlIHNhbWUgc2l0ZS1pZCwgQkdQIHdpbGwgY2hvb3NlLjwvZGl2
Pg0KPGRpdj7CoDwvZGl2Pg0KPGRpdj5BRkFJSyB3aGVuIHVzaW5nIExEUMKgc2lnbmFsaW5nLCBT
VFAgYmV0d2VlbiBDRXMvUEVzIGNhbiBiZSB1c2VkIChvcHRpb24gMSkgb3LCoElDQ1AgYmV0d2Vl
bnMgUEVzIChvcHRpb24gMikgY2FuIGJlIHVzZWQuPC9kaXY+DQo8ZGl2Pg0KPGRpdj7CoDwvZGl2
Pg0KPGRpdj5JcyB0aGVyZSBhbnkgd2F5IHRvIGhhdmUgYSBjb21tb24gZGVzaWduPyBvciBpcyBp
dCB0aGUgc2FtZSBkZWJhdGUgdGhhbiBwcmV2aW91cyBvbmU/PC9kaXY+DQo8ZGl2PsKgPC9kaXY+
DQo8ZGl2PlRoYW5rcyBpbiBhZHZhbmNlPC9kaXY+PC9kaXY+DQo=

------_=_NextPart_001_01CA009F.B50FA0E5--

From kireeti@juniper.net  Thu Jul  9 07:20:43 2009
Return-Path: <kireeti@juniper.net>
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 CA31D3A6C23 for <l2vpn@core3.amsl.com>; Thu,  9 Jul 2009 07:20:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fC2aikaFCDyQ for <l2vpn@core3.amsl.com>; Thu,  9 Jul 2009 07:20:43 -0700 (PDT)
Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 7312B3A6B2D for <l2vpn@ietf.org>; Thu,  9 Jul 2009 07:20:41 -0700 (PDT)
Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKSlX81GhHb8gTRFKmn4pCY1HdMbTSVuNA@postini.com; Thu, 09 Jul 2009 07:21:11 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 9 Jul 2009 07:15:07 -0700
From: Kireeti Kompella <kireeti@juniper.net>
To: Manu Chao <linux.yahoo@gmail.com>
Date: Thu, 9 Jul 2009 07:15:02 -0700
Subject: Re: VPLS Dual Homing
Thread-Topic: VPLS Dual Homing
Thread-Index: AcoAn6kcYSlAGNYRRhSRPGyDXrhR4Q==
Message-ID: <EB21457B-12AA-47EC-AB4B-9F5FCA02F647@juniper.net>
References: <7100ed370907090710m5214595fta2a8c3ba748271bf@mail.gmail.com>
In-Reply-To: <7100ed370907090710m5214595fta2a8c3ba748271bf@mail.gmail.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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jul 2009 14:20:43 -0000

T24gSnVsIDksIDIwMDksIGF0IDc6MTAsICJNYW51IENoYW8iIDxsaW51eC55YWhvb0BnbWFpbC5j
b208bWFpbHRvOmxpbnV4LnlhaG9vQGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpJcyB0aGVyZSBhbnkg
ZHJhZnQvcmZjIGNvbWluZyBhYm91dCBWUExTIER1YWwgSG9taW5nPw0KDQpZZXMuDQoNCiBBRkFJ
SyB3aGVuIHVzaW5nIEJHUCBzaWduYWxpbmcsIGl0IHdhcyBwb3NzaWJsZSB0byBjb25uZWN0IGEg
c2l0ZSB0byBtdWxpcGxlcyBQRXMgYnkgdXNpbmcgdGhlIHNhbWUgc2l0ZS1pZCwgQkdQIHdpbGwg
Y2hvb3NlLg0KDQpBRkFJSyB3aGVuIHVzaW5nIExEUCBzaWduYWxpbmcsIFNUUCBiZXR3ZWVuIENF
cy9QRXMgY2FuIGJlIHVzZWQgKG9wdGlvbiAxKSBvciBJQ0NQIGJldHdlZW5zIFBFcyAob3B0aW9u
IDIpIGNhbiBiZSB1c2VkLg0KDQpJcyB0aGVyZSBhbnkgd2F5IHRvIGhhdmUgYSBjb21tb24gZGVz
aWduPyBvciBpcyBpdCB0aGUgc2FtZSBkZWJhdGUgdGhhbiBwcmV2aW91cyBvbmU/DQoNClRoZXJl
IHdpbGwgYmUgYSBjb21tb24gZGVzaWduIGJldHdlZW4gQkdQIFZQTFMgYW5kIEJHUCBBRA0KDQog
VGhhbmtzIGluIGFkdmFuY2UNCg0KS2lyZWV0aQ0K

From peng.he.2000@gmail.com  Thu Jul  9 08:48:10 2009
Return-Path: <peng.he.2000@gmail.com>
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 054473A683A for <l2vpn@core3.amsl.com>; Thu,  9 Jul 2009 08:48:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.49
X-Spam-Level: 
X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=1.110,  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 9s5nTHpoMltQ for <l2vpn@core3.amsl.com>; Thu,  9 Jul 2009 08:48:09 -0700 (PDT)
Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id E4AE03A6AA7 for <l2vpn@ietf.org>; Thu,  9 Jul 2009 08:48:08 -0700 (PDT)
Received: by ewy26 with SMTP id 26so323158ewy.37 for <l2vpn@ietf.org>; Thu, 09 Jul 2009 08:48:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=MRbzuh7OrJdPAJkvNma9X21u49qB5xCxO0jkqm088DU=; b=Kb/aW9gsDmYbp0NeMCnwSNz4XiyDvJlPXdxb53OPi30Wv0DCfd9bqHrKphh54C9dIN cKjXeXbwDLgjH1oGqluITUHeDiBjzoxiK5gjoW0/j3Wa0/27IjXMPoCx+K90YheEctEQ msUKGw/98CJxl19DLsqo+T7J7x6cxuXWE3yf4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=sU/URl5NGTjg1Y+VBvKrc0ZyM/e8BgJ+xaUS8DhjXtijRKAiHaidkMHWv87izbJtSH RkHD+ADtkeDKZ708if5JRfFkf5V3wa7nOUyLKnK7WjocKVYLlUKGKHxAs0NhPWpQxiLn nJXF0AOVdtpeOL9CLf2HfNWc/FqOsSIIFoQo4=
MIME-Version: 1.0
Received: by 10.210.82.2 with SMTP id f2mr7312754ebb.95.1247154514137; Thu, 09  Jul 2009 08:48:34 -0700 (PDT)
In-Reply-To: <EB21457B-12AA-47EC-AB4B-9F5FCA02F647@juniper.net>
References: <7100ed370907090710m5214595fta2a8c3ba748271bf@mail.gmail.com> <EB21457B-12AA-47EC-AB4B-9F5FCA02F647@juniper.net>
Date: Thu, 9 Jul 2009 11:48:34 -0400
Message-ID: <406e32c00907090848y4223aa6fue171bfca74bdce58@mail.gmail.com>
Subject: Re: VPLS Dual Homing
From: Peng He <peng.he.2000@gmail.com>
To: Kireeti Kompella <kireeti@juniper.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jul 2009 15:48:10 -0000

There could be another options for VPLS dual-homing, ring protocol.
You could use ring protocols between CEs and PEs, or, U-PEs and N-PEs.
There was a ring-based draft published before but no update yet; and
there is also at lease a vendor had implemented ring-protocol based
VPLS dual-homing beautifully.


Regards,
Peng

On Thu, Jul 9, 2009 at 10:15 AM, Kireeti Kompella<kireeti@juniper.net> wrot=
e:
> On Jul 9, 2009, at 7:10, "Manu Chao" <linux.yahoo@gmail.com<mailto:linux.=
yahoo@gmail.com>> wrote:
>
> Is there any draft/rfc coming about VPLS Dual Homing?
>
> Yes.
>
> =A0AFAIK when using BGP signaling, it was possible to connect a site to m=
uliples PEs by using the same site-id, BGP will choose.
>
> AFAIK when using LDP signaling, STP between CEs/PEs can be used (option 1=
) or ICCP betweens PEs (option 2) can be used.
>
> Is there any way to have a common design? or is it the same debate than p=
revious one?
>
> There will be a common design between BGP VPLS and BGP AD
>
> =A0Thanks in advance
>
> Kireeti
>

From root@core3.amsl.com  Mon Jul 13 05:45:01 2009
Return-Path: <root@core3.amsl.com>
X-Original-To: l2vpn@ietf.org
Delivered-To: l2vpn@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id 876EE3A6823; Mon, 13 Jul 2009 05:45:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D Action:draft-ietf-l2vpn-vpms-frmwk-requirements-01.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20090713124501.876EE3A6823@core3.amsl.com>
Date: Mon, 13 Jul 2009 05:45:01 -0700 (PDT)
Cc: l2vpn@ietf.org
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jul 2009 12: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           : Framework and Requirements for Virtual Private Multicast Service (VPMS)
	Author(s)       : Y. Kamite, et al.
	Filename        : draft-ietf-l2vpn-vpms-frmwk-requirements-01.txt
	Pages           : 26
	Date            : 2009-07-13

This document provides a framework and service level requirements for
Virtual Private Multicast Service (VPMS).  VPMS is defined as a Layer
2 VPN service that provides point-to-multipoint connectivity for a
variety of Layer 2 link layers across an IP or MPLS-enabled PSN.
This document outlines architectural service models of VPMS and
states generic and high level requirements.  This is intended to aid
in developing protocols and mechanisms to support VPMS.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-vpms-frmwk-requirements-01.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-vpms-frmwk-requirements-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2009-07-13053938.I-D@ietf.org>


--NextPart--

From root@core3.amsl.com  Mon Jul 13 14:45:01 2009
Return-Path: <root@core3.amsl.com>
X-Original-To: l2vpn@ietf.org
Delivered-To: l2vpn@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0) id C61C128C5C8; Mon, 13 Jul 2009 14:45:01 -0700 (PDT)
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
Subject: I-D Action:draft-ietf-l2vpn-vpls-mcast-05.txt 
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
Message-Id: <20090713214501.C61C128C5C8@core3.amsl.com>
Date: Mon, 13 Jul 2009 14:45:01 -0700 (PDT)
Cc: l2vpn@ietf.org
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 13 Jul 2009 21: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           : Multicast in VPLS
	Author(s)       : R. Aggarwal, et al.
	Filename        : draft-ietf-l2vpn-vpls-mcast-05.txt
	Pages           : 44
	Date            : 2009-07-13

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-05.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-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2009-07-13143353.I-D@ietf.org>


--NextPart--

From frederic.jounay@orange-ftgroup.com  Wed Jul 15 08:21:47 2009
Return-Path: <frederic.jounay@orange-ftgroup.com>
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 057BD3A6ECF for <l2vpn@core3.amsl.com>; Wed, 15 Jul 2009 08:21:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.257
X-Spam-Level: 
X-Spam-Status: No, score=-1.257 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_20=-0.74, HELO_EQ_FR=0.35]
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 HK1berLIXsMC for <l2vpn@core3.amsl.com>; Wed, 15 Jul 2009 08:21:45 -0700 (PDT)
Received: from R-MAIL1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 43A133A6CE9 for <l2vpn@ietf.org>; Wed, 15 Jul 2009 08:21:45 -0700 (PDT)
Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959);  Wed, 15 Jul 2009 17:21:16 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: MPLS 2009 Conference, Washington DC, October 25-28
Date: Wed, 15 Jul 2009 17:21:16 +0200
Message-ID: <AFC377AFCC0FBD4DABE49F4B81EC4F1A498CD4@ftrdmel1>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: MPLS 2009 Conference, Washington DC, October 25-28
Thread-Index: AcoBRAdJSDfnR90zTUSmpEzx31fl/wEGzRSgAAAOudA=
From: <frederic.jounay@orange-ftgroup.com>
To: <l2vpn@ietf.org>
X-OriginalArrivalTime: 15 Jul 2009 15:21:16.0841 (UTC) FILETIME=[E5C51190:01CA055F]
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jul 2009 15:21:47 -0000

Since many of the topics in the annual MPLS conference have been of
interest to members of the L2VPN working group in the past, I wanted to
share with you the fact that the conference program and registration has
been announced, as detailed below.

Fred.

PROGRAM ANNOUNCEMENT AND REGISTRATION FOR MPLS 2009 - OCTOBER 25-28,
WASHINGTON DC

Registration for MPLS2009 (October 25-28, Omni Shoreham Hotel in
Washington), the 12th annualInternational Conference on MPLS and related
new technologies is now open at:

http://www.isocore.com/mpls2009/registration/attendees.htm=20

MPLS 2009 will include an extensive four day program consisting of
tutorials, technical sessions, panels, and exhibits. The key topics to
be discussed at this year's conference include: Scaling MPLS, MPLS
transport profile, Carrier Ethernet/MPLS deployments and experiences,
Future technologies, Multicast and MPLS, Mobile and wireless backhaul,
Resiliency, and OAM aspects, GMPLS, and emerging applications. The
complete program is available at:

http://www.isocore.com/mpls2009/program/technical_sessions.htm=20

The event will also have an exhibit floor, where leading network
equipment manufacturers will showcase their new offerings, the list of
current sponsors is available at:

http://www.isocore.com/mpls2009/sponsors/sponsors.htm=20

The conference hotel is the Omni Shoreham Hotel in Washington DC. Please
note that there are only a limited number of rooms available this year
at a reduced rate. Reservations can be made at:

http://www.isocore.com/mpls2009/hotel.htm
<http://www.isocore.com/mpls2009/hotel.htm>=20

Isocore once again will showcase live the readiness of leading network
technologies at the Public Interop demonstration on October 29 at
Isocore Internetworking Lab. The details are available at -
http://www.isocore.com/mpls2009/program/inter_op.htm.=20

From shane@castlepoint.net  Sun Jul 19 15:13:54 2009
Return-Path: <shane@castlepoint.net>
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 5BF7128C12B for <l2vpn@core3.amsl.com>; Sun, 19 Jul 2009 15:13:54 -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 HqiQt1FQwtHV for <l2vpn@core3.amsl.com>; Sun, 19 Jul 2009 15:13:53 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id A54E53A6CC0 for <l2vpn@ietf.org>; Sun, 19 Jul 2009 15:13:53 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id AC9BC2684EA; Sun, 19 Jul 2009 16:13:53 -0600 (MDT)
Received: from mbpw.castlepoint.net (71-215-80-228.hlrn.qwest.net [71.215.80.228]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for l2vpn@ietf.org; Sun, 19 Jul 2009 16:13:53 -0600 (MDT) (envelope-from shane@castlepoint.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.215.80.228; client-port=4066; syn-fingerprint=65535:55:1:64:M1452,N,W3,N,N,T,S; data-bytes=0
Message-Id: <2D0E0DE9-9CA4-4845-BF34-BA1E1087C1CE@castlepoint.net>
From: Shane Amante <shane@castlepoint.net>
To: l2vpn@ietf.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: IETF 75: Agenda Posted
Date: Sun, 19 Jul 2009 16:13:37 -0600
X-Mailer: Apple Mail (2.935.3)
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 19 Jul 2009 22:13:54 -0000

Hi Everyone,

The agenda for the L2VPN WG meeting at IETF 75 has been posted:
http://www.ietf.org/proceedings/75/agenda/l2vpn.html

Would the presenters try to send us their presentations as soon as  
possible, in order that we may post them before the WG meeting?

-shane & Vach
(co-chairs L2VPN WG)

From shane@castlepoint.net  Wed Jul 29 05:39:15 2009
Return-Path: <shane@castlepoint.net>
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 F25B73A69BD for <l2vpn@core3.amsl.com>; Wed, 29 Jul 2009 05:39:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.11
X-Spam-Level: 
X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11]
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 n1vIuOsv6An6 for <l2vpn@core3.amsl.com>; Wed, 29 Jul 2009 05:39:14 -0700 (PDT)
Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id 4D60B3A684C for <l2vpn@ietf.org>; Wed, 29 Jul 2009 05:39:14 -0700 (PDT)
Received: by dog.tcb.net (Postfix, from userid 0) id F04F52684EA; Wed, 29 Jul 2009 06:39:15 -0600 (MDT)
Received: from host2.tcb.net (64.78.235.218 [64.78.235.218]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; for l2vpn@ietf.org; Wed, 29 Jul 2009 06:39:15 -0600 (MDT) (envelope-from shane@castlepoint.net)
X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.235.218; client-port=56443; data-bytes=0
Message-Id: <84801235-443F-4CCA-81FC-3EB68AD20638@castlepoint.net>
From: Shane Amante <shane@castlepoint.net>
To: l2vpn@ietf.org
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: IETF 75: Minutes Scibe?
Date: Wed, 29 Jul 2009 14:39:12 +0200
X-Mailer: Apple Mail (2.935.3)
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jul 2009 12:39:15 -0000

Hi Everyone,

We'd like to ask for a volunteer to take minutes for the L2VPN WG  
meeting tomorrow morning, in order that we can start on-time.  If  
there is a willing volunteer, or two, please e-mail the chairs.

Thanks,

-shane & Vach

From DALLAN@nortel.com  Thu Jul 30 00:49:13 2009
Return-Path: <DALLAN@nortel.com>
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 20C173A69AD for <l2vpn@core3.amsl.com>; Thu, 30 Jul 2009 00:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80yWT6Waf5Mn for <l2vpn@core3.amsl.com>; Thu, 30 Jul 2009 00:49:12 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 6BB8D3A7133 for <l2vpn@ietf.org>; Thu, 30 Jul 2009 00:48:39 -0700 (PDT)
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6U7kkN25407 for <l2vpn@ietf.org>; Thu, 30 Jul 2009 07:46:46 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: Extensions to LDP Signaling for PBB-VPLS - 
Date: Thu, 30 Jul 2009 03:48:34 -0400
Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE193A8BB7@zcarhxm2.corp.nortel.com>
In-Reply-To: <4A5028372622294A99B8FFF6BD06EB7B05432B65@USDALSMBS03.ad3.ad.alcatel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Extensions to LDP Signaling for PBB-VPLS - 
Thread-Index: Acmw4UKX3WFKeyIMSc+yTHe0JvOK0ABHnUKAAAFCbCAACfzoIAABKQPQAAHQSvAXq9/MsA==
References: <5ABF91A0-8CCF-40A2-AB7B-25F2060B23B8@castlepoint.net><6738A78F51650A4FAEDCF6844B26C21413461536F3@USEXCHANGE.corp.extremenetworks.com><042001c9b205$9fa23c40$dee6b4c0$@com><4A5028372622294A99B8FFF6BD06EB7B05432AFE@USDALSMBS03.ad3.ad.alcatel.com> <87AC5F88F03E6249AEA68D40BD3E00BE193A82DA@zcarhxm2.corp.nortel.com> <4A5028372622294A99B8FFF6BD06EB7B05432B65@USDALSMBS03.ad3.ad.alcatel.com>
From: "David Allan" <dallan@nortel.com>
To: "BALUS Florin" <Florin.Balus@alcatel-lucent.com>, <l2vpn@ietf.org>
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jul 2009 07:49:13 -0000

Hi Florin:

I understand the problem this proposes to solve, but I believe there is
a simpler way. If you assign a B-MAC to a multihomed customer site then
you never need to invalidate C-MAC to B-MAC bindings and a MAC
invalidate message for the B-MAC is sufficient to ensure no black holing
when an AC goes down, normal flooding and learning permitting remote PEs
to learn which PE the customer site is reachable via. This provides for
the possibility of localizing the blocked/unblocked decision for the ACs
(which IMO needs to be coordinated between the MH PEs in order to be
robustly loop free) as knowledge of the multi-homing does not need to be
propagated into the network.

WDYT?
Dave


From Florin.Balus@alcatel-lucent.com  Thu Jul 30 08:04:48 2009
Return-Path: <Florin.Balus@alcatel-lucent.com>
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 1923428C1AE for <l2vpn@core3.amsl.com>; Thu, 30 Jul 2009 08:04:48 -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 Lf-Fe6KfOYya for <l2vpn@core3.amsl.com>; Thu, 30 Jul 2009 08:04:47 -0700 (PDT)
Received: from audl751.usa.alcatel.com (audl751.usa.alcatel.com [143.209.238.164]) by core3.amsl.com (Postfix) with ESMTP id 234F528C189 for <l2vpn@ietf.org>; Thu, 30 Jul 2009 08:04:47 -0700 (PDT)
Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.usa.alcatel.com [172.22.216.13]) by audl751.usa.alcatel.com (ALCANET) with ESMTP id n6UF4llL028752; Thu, 30 Jul 2009 10:04:48 -0500
Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.6]) by usdalsbhs02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 10:04:46 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Extensions to LDP Signaling for PBB-VPLS - 
Date: Thu, 30 Jul 2009 10:04:07 -0500
Message-ID: <4A5028372622294A99B8FFF6BD06EB7B05A5B49C@USDALSMBS03.ad3.ad.alcatel.com>
In-Reply-To: <87AC5F88F03E6249AEA68D40BD3E00BE193A8BB7@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Extensions to LDP Signaling for PBB-VPLS - 
Thread-Index: Acmw4UKX3WFKeyIMSc+yTHe0JvOK0ABHnUKAAAFCbCAACfzoIAABKQPQAAHQSvAXq9/MsAAPi6KQ
References: <5ABF91A0-8CCF-40A2-AB7B-25F2060B23B8@castlepoint.net><6738A78F51650A4FAEDCF6844B26C21413461536F3@USEXCHANGE.corp.extremenetworks.com><042001c9b205$9fa23c40$dee6b4c0$@com><4A5028372622294A99B8FFF6BD06EB7B05432AFE@USDALSMBS03.ad3.ad.alcatel.com> <87AC5F88F03E6249AEA68D40BD3E00BE193A82DA@zcarhxm2.corp.nortel.com> <4A5028372622294A99B8FFF6BD06EB7B05432B65@USDALSMBS03.ad3.ad.alcatel.com> <87AC5F88F03E6249AEA68D40BD3E00BE193A8BB7@zcarhxm2.corp.nortel.com>
From: "BALUS Florin" <Florin.Balus@alcatel-lucent.com>
To: "David Allan" <dallan@nortel.com>, <l2vpn@ietf.org>
X-OriginalArrivalTime: 30 Jul 2009 15:04:46.0431 (UTC) FILETIME=[13A2BEF0:01CA1127]
X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jul 2009 15:04:48 -0000

Hi Dave,
As discussed after the session, we are proposing a generic solution that
does not depend on any special, locally configured, BMAC assignment
scheme.=20
Florin

> -----Original Message-----
> From: David Allan [mailto:dallan@nortel.com]
> Sent: Thursday, July 30, 2009 12:49 AM
> To: BALUS Florin; l2vpn@ietf.org
> Subject: Extensions to LDP Signaling for PBB-VPLS -
>=20
> Hi Florin:
>=20
> I understand the problem this proposes to solve, but I believe there
is
> a simpler way. If you assign a B-MAC to a multihomed customer site
then
> you never need to invalidate C-MAC to B-MAC bindings and a MAC
> invalidate message for the B-MAC is sufficient to ensure no black
> holing
> when an AC goes down, normal flooding and learning permitting remote
> PEs
> to learn which PE the customer site is reachable via. This provides
for
> the possibility of localizing the blocked/unblocked decision for the
> ACs
> (which IMO needs to be coordinated between the MH PEs in order to be
> robustly loop free) as knowledge of the multi-homing does not need to
> be
> propagated into the network.
>=20
> WDYT?
> Dave


From DALLAN@nortel.com  Thu Jul 30 08:22:54 2009
Return-Path: <DALLAN@nortel.com>
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 B247F28C210 for <l2vpn@core3.amsl.com>; Thu, 30 Jul 2009 08:22:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ucIsYf0EnlZ for <l2vpn@core3.amsl.com>; Thu, 30 Jul 2009 08:22:53 -0700 (PDT)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 9187F28C18D for <l2vpn@ietf.org>; Thu, 30 Jul 2009 08:22:53 -0700 (PDT)
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6UFMqh02551 for <l2vpn@ietf.org>; Thu, 30 Jul 2009 15:22:52 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Extensions to LDP Signaling for PBB-VPLS - 
Date: Thu, 30 Jul 2009 11:22:30 -0400
Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE193A8BCC@zcarhxm2.corp.nortel.com>
In-Reply-To: <4A5028372622294A99B8FFF6BD06EB7B05A5B49C@USDALSMBS03.ad3.ad.alcatel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Extensions to LDP Signaling for PBB-VPLS - 
Thread-Index: Acmw4UKX3WFKeyIMSc+yTHe0JvOK0ABHnUKAAAFCbCAACfzoIAABKQPQAAHQSvAXq9/MsAAPi6KQAABKCoA=
References: <5ABF91A0-8CCF-40A2-AB7B-25F2060B23B8@castlepoint.net><6738A78F51650A4FAEDCF6844B26C21413461536F3@USEXCHANGE.corp.extremenetworks.com><042001c9b205$9fa23c40$dee6b4c0$@com><4A5028372622294A99B8FFF6BD06EB7B05432AFE@USDALSMBS03.ad3.ad.alcatel.com> <87AC5F88F03E6249AEA68D40BD3E00BE193A82DA@zcarhxm2.corp.nortel.com> <4A5028372622294A99B8FFF6BD06EB7B05432B65@USDALSMBS03.ad3.ad.alcatel.com> <87AC5F88F03E6249AEA68D40BD3E00BE193A8BB7@zcarhxm2.corp.nortel.com> <4A5028372622294A99B8FFF6BD06EB7B05A5B49C@USDALSMBS03.ad3.ad.alcatel.com>
From: "David Allan" <dallan@nortel.com>
To: "BALUS Florin" <Florin.Balus@alcatel-lucent.com>, <l2vpn@ietf.org>
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jul 2009 15:22:54 -0000

Understood,

...but I don't see a difference between administering MH-IDs and
administering B-MACs, 1:1 cardinality for any incremental administration
...and such state needs to reside somewhere....you simply now have more
classes of it...

IMO if a dual homed network is given a PIP on each of the PEs it is
homed upon with the slight abuse of having a common B-MAC address, I
believe no changes to existing control plane procedures are required,
and the subtending Ethernet can then select the active port (via MC-LAG,
STP or whatever procedures) without requiring any VPLS procedures or
control plane interworking to speak of. I will see more B-MAC addresses
than I would see otherwise,  but IMO this is only really parsitic if the
dual homed customer network is a single C-MAC (router).=20

As for actual failure scenario, after the PIP B-MAC is withdrawn, there
will simply be a few flooded frames at the B-MAC layer until the new
path to the customer network is learned via the alternate PIP, the
customer network will not experience a lot of flooding of C-MAC frames
as the network convergence, in effect the fact there was a failure in
the network will not manifest itself in a lot of customer layer flooding
of frames...ergo, silently recovered ;-)

I like it...

Cheers
Dave

-----Original Message-----
From: BALUS Florin [mailto:Florin.Balus@alcatel-lucent.com]=20
Sent: Thursday, July 30, 2009 11:04 AM
To: Allan, David (CAR:NS00); l2vpn@ietf.org
Subject: RE: Extensions to LDP Signaling for PBB-VPLS -=20

Hi Dave,
As discussed after the session, we are proposing a generic solution that
does not depend on any special, locally configured, BMAC assignment
scheme.=20
Florin

> -----Original Message-----
> From: David Allan [mailto:dallan@nortel.com]
> Sent: Thursday, July 30, 2009 12:49 AM
> To: BALUS Florin; l2vpn@ietf.org
> Subject: Extensions to LDP Signaling for PBB-VPLS -
>=20
> Hi Florin:
>=20
> I understand the problem this proposes to solve, but I believe there
is
> a simpler way. If you assign a B-MAC to a multihomed customer site
then
> you never need to invalidate C-MAC to B-MAC bindings and a MAC=20
> invalidate message for the B-MAC is sufficient to ensure no black=20
> holing when an AC goes down, normal flooding and learning permitting=20
> remote PEs to learn which PE the customer site is reachable via. This=20
> provides
for
> the possibility of localizing the blocked/unblocked decision for the=20
> ACs (which IMO needs to be coordinated between the MH PEs in order to=20
> be robustly loop free) as knowledge of the multi-homing does not need=20
> to be propagated into the network.
>=20
> WDYT?
> Dave


From Florin.Balus@alcatel-lucent.com  Thu Jul 30 12:20:05 2009
Return-Path: <Florin.Balus@alcatel-lucent.com>
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 D1F743A6F44 for <l2vpn@core3.amsl.com>; Thu, 30 Jul 2009 12:20:05 -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 sWl7NmLSvBUv for <l2vpn@core3.amsl.com>; Thu, 30 Jul 2009 12:20:05 -0700 (PDT)
Received: from audl952.usa.alcatel.com (audl952.usa.alcatel.com [143.209.238.159]) by core3.amsl.com (Postfix) with ESMTP id CA1003A6BE0 for <l2vpn@ietf.org>; Thu, 30 Jul 2009 12:20:04 -0700 (PDT)
Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.usa.alcatel.com [172.22.216.13]) by audl952.usa.alcatel.com (ALCANET) with ESMTP id n6UJK6Zu000602; Thu, 30 Jul 2009 14:20:06 -0500
Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.6]) by usdalsbhs02.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 14:20:05 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Extensions to LDP Signaling for PBB-VPLS - 
Date: Thu, 30 Jul 2009 14:19:07 -0500
Message-ID: <4A5028372622294A99B8FFF6BD06EB7B05A5B55F@USDALSMBS03.ad3.ad.alcatel.com>
In-Reply-To: <87AC5F88F03E6249AEA68D40BD3E00BE193A8BCC@zcarhxm2.corp.nortel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Extensions to LDP Signaling for PBB-VPLS - 
Thread-Index: Acmw4UKX3WFKeyIMSc+yTHe0JvOK0ABHnUKAAAFCbCAACfzoIAABKQPQAAHQSvAXq9/MsAAPi6KQAABKCoAAA4L0sA==
References: <5ABF91A0-8CCF-40A2-AB7B-25F2060B23B8@castlepoint.net><6738A78F51650A4FAEDCF6844B26C21413461536F3@USEXCHANGE.corp.extremenetworks.com><042001c9b205$9fa23c40$dee6b4c0$@com><4A5028372622294A99B8FFF6BD06EB7B05432AFE@USDALSMBS03.ad3.ad.alcatel.com> <87AC5F88F03E6249AEA68D40BD3E00BE193A82DA@zcarhxm2.corp.nortel.com> <4A5028372622294A99B8FFF6BD06EB7B05432B65@USDALSMBS03.ad3.ad.alcatel.com> <87AC5F88F03E6249AEA68D40BD3E00BE193A8BB7@zcarhxm2.corp.nortel.com> <4A5028372622294A99B8FFF6BD06EB7B05A5B49C@USDALSMBS03.ad3.ad.alcatel.com> <87AC5F88F03E6249AEA68D40BD3E00BE193A8BCC@zcarhxm2.corp.nortel.com>
From: "BALUS Florin" <Florin.Balus@alcatel-lucent.com>
To: "David Allan" <dallan@nortel.com>, <l2vpn@ietf.org>
X-OriginalArrivalTime: 30 Jul 2009 19:20:05.0842 (UTC) FILETIME=[BEB75B20:01CA114A]
X-Scanned-By: MIMEDefang 2.64 on 143.209.238.34
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jul 2009 19:20:05 -0000

Dave,
I was under the impression we closed the item during our afternoon
discussion. But you seem in-love with your idea! :)=20
If you still think what you have in mind is sound, I suggest you put it
in a document and submit it to IEEE 802.1 for proper review in one of
the incoming IEEE sessions.=20

I believe the solution we presented today is addressing in a generic way
the operational environment which is in scope for L2VPN WG: deployed LDP
VPLS networks using the existing LDP MAC Flush toolset. In this
environment it makes sense to have consistent procedures for both VPLS
and PBB-VPLS.
Florin

> -----Original Message-----
> From: David Allan [mailto:dallan@nortel.com]
> Sent: Thursday, July 30, 2009 8:23 AM
> To: BALUS Florin; l2vpn@ietf.org
> Subject: RE: Extensions to LDP Signaling for PBB-VPLS -
>=20
> Understood,
>=20
> ...but I don't see a difference between administering MH-IDs and
> administering B-MACs, 1:1 cardinality for any incremental
> administration
> ...and such state needs to reside somewhere....you simply now have
more
> classes of it...
>=20
> IMO if a dual homed network is given a PIP on each of the PEs it is
> homed upon with the slight abuse of having a common B-MAC address, I
> believe no changes to existing control plane procedures are required,
> and the subtending Ethernet can then select the active port (via MC-
> LAG,
> STP or whatever procedures) without requiring any VPLS procedures or
> control plane interworking to speak of. I will see more B-MAC
addresses
> than I would see otherwise,  but IMO this is only really parsitic if
> the
> dual homed customer network is a single C-MAC (router).
>=20
> As for actual failure scenario, after the PIP B-MAC is withdrawn,
there
> will simply be a few flooded frames at the B-MAC layer until the new
> path to the customer network is learned via the alternate PIP, the
> customer network will not experience a lot of flooding of C-MAC frames
> as the network convergence, in effect the fact there was a failure in
> the network will not manifest itself in a lot of customer layer
> flooding
> of frames...ergo, silently recovered ;-)
>=20
> I like it...
>=20
> Cheers
> Dave
>=20
> -----Original Message-----
> From: BALUS Florin [mailto:Florin.Balus@alcatel-lucent.com]
> Sent: Thursday, July 30, 2009 11:04 AM
> To: Allan, David (CAR:NS00); l2vpn@ietf.org
> Subject: RE: Extensions to LDP Signaling for PBB-VPLS -
>=20
> Hi Dave,
> As discussed after the session, we are proposing a generic solution
> that
> does not depend on any special, locally configured, BMAC assignment
> scheme.
> Florin
>=20
> > -----Original Message-----
> > From: David Allan [mailto:dallan@nortel.com]
> > Sent: Thursday, July 30, 2009 12:49 AM
> > To: BALUS Florin; l2vpn@ietf.org
> > Subject: Extensions to LDP Signaling for PBB-VPLS -
> >
> > Hi Florin:
> >
> > I understand the problem this proposes to solve, but I believe there
> is
> > a simpler way. If you assign a B-MAC to a multihomed customer site
> then
> > you never need to invalidate C-MAC to B-MAC bindings and a MAC
> > invalidate message for the B-MAC is sufficient to ensure no black
> > holing when an AC goes down, normal flooding and learning permitting
> > remote PEs to learn which PE the customer site is reachable via.
This
> > provides
> for
> > the possibility of localizing the blocked/unblocked decision for the
> > ACs (which IMO needs to be coordinated between the MH PEs in order
to
> > be robustly loop free) as knowledge of the multi-homing does not
need
> > to be propagated into the network.
> >
> > WDYT?
> > Dave


From DALLAN@nortel.com  Fri Jul 31 00:37:51 2009
Return-Path: <DALLAN@nortel.com>
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 553403A6CB3 for <l2vpn@core3.amsl.com>; Fri, 31 Jul 2009 00:37:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MafcnUKoT2j for <l2vpn@core3.amsl.com>; Fri, 31 Jul 2009 00:37:50 -0700 (PDT)
Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 1A3A73A6BCD for <l2vpn@ietf.org>; Fri, 31 Jul 2009 00:37:49 -0700 (PDT)
Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6V7bmV26008 for <l2vpn@ietf.org>; Fri, 31 Jul 2009 07:37:49 GMT
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Extensions to LDP Signaling for PBB-VPLS - 
Date: Fri, 31 Jul 2009 03:37:33 -0400
Message-ID: <87AC5F88F03E6249AEA68D40BD3E00BE193A8BD5@zcarhxm2.corp.nortel.com>
In-Reply-To: <4A5028372622294A99B8FFF6BD06EB7B05A5B55F@USDALSMBS03.ad3.ad.alcatel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Extensions to LDP Signaling for PBB-VPLS - 
Thread-Index: Acmw4UKX3WFKeyIMSc+yTHe0JvOK0ABHnUKAAAFCbCAACfzoIAABKQPQAAHQSvAXq9/MsAAPi6KQAABKCoAAA4L0sAAeMNGg
References: <5ABF91A0-8CCF-40A2-AB7B-25F2060B23B8@castlepoint.net><6738A78F51650A4FAEDCF6844B26C21413461536F3@USEXCHANGE.corp.extremenetworks.com><042001c9b205$9fa23c40$dee6b4c0$@com><4A5028372622294A99B8FFF6BD06EB7B05432AFE@USDALSMBS03.ad3.ad.alcatel.com> <87AC5F88F03E6249AEA68D40BD3E00BE193A82DA@zcarhxm2.corp.nortel.com> <4A5028372622294A99B8FFF6BD06EB7B05432B65@USDALSMBS03.ad3.ad.alcatel.com> <87AC5F88F03E6249AEA68D40BD3E00BE193A8BB7@zcarhxm2.corp.nortel.com> <4A5028372622294A99B8FFF6BD06EB7B05A5B49C@USDALSMBS03.ad3.ad.alcatel.com> <87AC5F88F03E6249AEA68D40BD3E00BE193A8BCC@zcarhxm2.corp.nortel.com> <4A5028372622294A99B8FFF6BD06EB7B05A5B55F@USDALSMBS03.ad3.ad.alcatel.com>
From: "David Allan" <dallan@nortel.com>
To: "BALUS Florin" <Florin.Balus@alcatel-lucent.com>, <l2vpn@ietf.org>
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jul 2009 07:37:51 -0000

HI Florin:

> I was under the impression we closed the item during our afternoon
discussion.=20

I appreciated the opportunity to understand some of your motivations for
your technical choices...but we'd not closed on consensus...If I gave
you that impression, that was unfortunate...

> But you seem in-love with your idea! :)=20

Love is not the right term. I like the attributes of the solution, and
if those can be achieved by other means, I may like that as well...
There are two attributes I value here:

1) Knowledge of dual homing is local to the "homed upon" PEs, no broader
impacts on the network

2) C-MAC flush is not required at peer BEBs on a change of which PE/BEB
the CE is homed upon.

> If you still think what you have in mind is sound, I suggest you put
it in a document and submit it to IEEE 802.1 for=20
> proper review in one of the incoming IEEE sessions.=20

I understand that while this is not a formal project at the IEEE, it is
a hot topic, and they consider C-MAC flushing undesirable. My
expectation being that if they go forward, they would produce a solution
of similar attributes to those I value, even if not the same in detail.
Progressing a solution now in L2VPN may have attriutes incompatible with
what the IEEE ultimately does...

Meanwhile, if the WG insists on a solution in advance if IEEE, the IETF
has not been shy about moving MACs for resiliency reasons, witness VRRP,
and that could be done without any control plane changes...If what the
IEEE produces requires changes, it could be addressed at that time...

> I believe the solution we presented today is addressing in a generic
way the operational environment which is in scope=20
> for L2VPN WG: deployed LDP VPLS networks using the existing LDP MAC
Flush toolset. In this environment it makes sense to=20
> have consistent procedures for both VPLS and PBB-VPLS.

I'm not quite parsing this, if consistent procedures, nothing new would
be needed. Can you clarify this...?

Best
Dave


> -----Original Message-----
> From: David Allan [mailto:dallan@nortel.com]
> Sent: Thursday, July 30, 2009 8:23 AM
> To: BALUS Florin; l2vpn@ietf.org
> Subject: RE: Extensions to LDP Signaling for PBB-VPLS -
>=20
> Understood,
>=20
> ...but I don't see a difference between administering MH-IDs and=20
> administering B-MACs, 1:1 cardinality for any incremental=20
> administration ...and such state needs to reside somewhere....you=20
> simply now have
more
> classes of it...
>=20
> IMO if a dual homed network is given a PIP on each of the PEs it is=20
> homed upon with the slight abuse of having a common B-MAC address, I=20
> believe no changes to existing control plane procedures are required,=20
> and the subtending Ethernet can then select the active port (via MC-=20
> LAG, STP or whatever procedures) without requiring any VPLS procedures

> or control plane interworking to speak of. I will see more B-MAC
addresses
> than I would see otherwise,  but IMO this is only really parsitic if=20
> the dual homed customer network is a single C-MAC (router).
>=20
> As for actual failure scenario, after the PIP B-MAC is withdrawn,
there
> will simply be a few flooded frames at the B-MAC layer until the new=20
> path to the customer network is learned via the alternate PIP, the=20
> customer network will not experience a lot of flooding of C-MAC frames

> as the network convergence, in effect the fact there was a failure in=20
> the network will not manifest itself in a lot of customer layer=20
> flooding of frames...ergo, silently recovered ;-)
>=20
> I like it...
>=20
> Cheers
> Dave
>=20
> -----Original Message-----
> From: BALUS Florin [mailto:Florin.Balus@alcatel-lucent.com]
> Sent: Thursday, July 30, 2009 11:04 AM
> To: Allan, David (CAR:NS00); l2vpn@ietf.org
> Subject: RE: Extensions to LDP Signaling for PBB-VPLS -
>=20
> Hi Dave,
> As discussed after the session, we are proposing a generic solution=20
> that does not depend on any special, locally configured, BMAC=20
> assignment scheme.
> Florin
>=20
> > -----Original Message-----
> > From: David Allan [mailto:dallan@nortel.com]
> > Sent: Thursday, July 30, 2009 12:49 AM
> > To: BALUS Florin; l2vpn@ietf.org
> > Subject: Extensions to LDP Signaling for PBB-VPLS -
> >
> > Hi Florin:
> >
> > I understand the problem this proposes to solve, but I believe there
> is
> > a simpler way. If you assign a B-MAC to a multihomed customer site
> then
> > you never need to invalidate C-MAC to B-MAC bindings and a MAC=20
> > invalidate message for the B-MAC is sufficient to ensure no black=20
> > holing when an AC goes down, normal flooding and learning permitting

> > remote PEs to learn which PE the customer site is reachable via.
This
> > provides
> for
> > the possibility of localizing the blocked/unblocked decision for the

> > ACs (which IMO needs to be coordinated between the MH PEs in order
to
> > be robustly loop free) as knowledge of the multi-homing does not
need
> > to be propagated into the network.
> >
> > WDYT?
> > Dave


From Florin.Balus@alcatel-lucent.com  Fri Jul 31 01:26:11 2009
Return-Path: <Florin.Balus@alcatel-lucent.com>
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 732443A6A6C for <l2vpn@core3.amsl.com>; Fri, 31 Jul 2009 01:26:11 -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 nYGbwWlcCQb3 for <l2vpn@core3.amsl.com>; Fri, 31 Jul 2009 01:26:10 -0700 (PDT)
Received: from audl951.usa.alcatel.com (audl951.usa.alcatel.com [143.209.238.161]) by core3.amsl.com (Postfix) with ESMTP id 7E34628C32B for <l2vpn@ietf.org>; Fri, 31 Jul 2009 01:24:47 -0700 (PDT)
Received: from usdalsbhs01.ad3.ad.alcatel.com (usdalsbhs01.usa.alcatel.com [172.22.216.19]) by audl951.usa.alcatel.com (ALCANET) with ESMTP id n6V8OmJA018295; Fri, 31 Jul 2009 03:24:48 -0500
Received: from USDALSMBS03.ad3.ad.alcatel.com ([172.22.216.6]) by usdalsbhs01.ad3.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Jul 2009 03:24:48 -0500
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_01CA11B8.52A5A94F"
Subject: Re: Extensions to LDP Signaling for PBB-VPLS -
Date: Fri, 31 Jul 2009 03:24:28 -0500
Message-ID: <4A5028372622294A99B8FFF6BD06EB7B04FBC09B@USDALSMBS03.ad3.ad.alcatel.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Extensions to LDP Signaling for PBB-VPLS - 
Thread-Index: Acmw4UKX3WFKeyIMSc+yTHe0JvOK0ABHnUKAAAFCbCAACfzoIAABKQPQAAHQSvAXq9/MsAAPi6KQAABKCoAAA4L0sAAeMNGgAAKE1o0=
From: "BALUS Florin" <Florin.Balus@alcatel-lucent.com>
To: <dallan@nortel.com>, <l2vpn@ietf.org>
X-OriginalArrivalTime: 31 Jul 2009 08:24:48.0733 (UTC) FILETIME=[5E4E60D0:01CA11B8]
X-Scanned-By: MIMEDefang 2.64 on 143.209.238.34
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 Jul 2009 08:26:11 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CA11B8.52A5A94F
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: base64

RGF2ZSwNCllvdSBhcmUgdGFsa2luZyBhYm91dCBzb21lIHVuZG9jdW1lbnRlZCBwcm9wb3NhbCB0
aGF0IHNlZW0gdG8gYmUgaW4gSUVFRSBzY29wZS4gQmVmb3JlIGRlY2xhcmluZyBpdCBhbiBhbGwg
ZW5jb21wYXNzaW5nIHNvbHV0aW9uIHRoYXQgY292ZXJzIGFsbCB1c2UgY2FzZXMgIHlvdSBuZWVk
IHRvIGRvY3VtZW50IGl0IGFuZCBzdWJtaXR0IGl0IHRvIElFRUUgZm9yIDgwMi4xIHNjcnV0aW55
LiBBcyBJIGV4cGxhaW5lZCB0byB5b3UsIGZyb20gdGhlIGxvb2tzIG9mIGl0IHlvdXIgcHJvcG9z
YWwgc2VlbXMgdW5uYWNjZXB0YWJsZSB0byBhdCBsZWFzdCBwYXJ0IG9mIHRoZSBsYXJnZSBWUExT
IGRlcGxveW1lbnRzICgxSysgUEVzKSB3aGVyZSBwZW9wbGUgdmFsdWUgc2ltcGxlIG9wZXJhdGlv
bnMgIGFuZCB3YW50IHRvIGxpbWl0IHRoZSBudW1iZXIgb2YgYm1hY3MgaW4gdGhlIG5ldHdvcmsu
DQoNClRoZSBzb2x1dGlvbiB3ZSBwcm9wb3NlIGlzIGdlbmVyaWMgYW5kIGRvZXMgbm90IHJlcXVp
cmUgYW55IGNoYW5nZSBpbiBvcGVyYXRpb24gb2YgZXhpc3RpbmcgVlBMUyBuZXR3b3Jrcy4gVGhh
dCBpcyB3aHlJIHNhaWQgaXMgY29uc2lzdGVudCB3aXRoIHdoYXQgaXMgaW4gdXNlLiBNb3Jlb3Zl
ciBpdCBpcyBiYXNlZCBvbiB0aGUgc2FtZSBsZHAgd2l0aGRyYXcgbWVzc2FnZSB3aGVyZSBwYmIg
dGx2IGlzIGFkZGVkIGF1dG9tYXRpY2FsbHkgYmFzZWQgb24gdGhlIHBsYWNlIHdoZXJlIHRoZSBl
dmVudCB0YWtlcyBwbGFjZS4gDQoNCkkgd2lsbCBiZSBpbiB2YWNhdGlvbiBmb3IgdGhlIG5leHQg
d2hpbGUgd2l0aG91dCBhY2Nlc3MgdG8gZW1haWwgc28gSXdpbGwgaGF2ZSBhIGhhcmQgdGltZSBj
b250aW51eWluZyB0aGlzIGRlYmF0ZS4gQW55aG93IGJhc2VkIG9uIHRoZSBhYm92ZSBhcmd1bWVu
dHMgSSB0aGluayB0aGlzIGlzIHRoZSB3cm9uZyBjb250ZXh0IGZvciBkaXNjdXNzaW5nIHRoZSB2
YWx1ZSBvZiB5b3VyIHByb3Bvc2FsIHdpdGhvdXQgYSB3ZWxsIGRvY3VtZW50ZWQgc29sdXRpb24g
ZG9jLiAgDQpGbG9yaW4gDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IGwy
dnBuLWJvdW5jZXNAaWV0Zi5vcmcgPGwydnBuLWJvdW5jZXNAaWV0Zi5vcmc+DQpUbzogQkFMVVMg
RmxvcmluOyBsMnZwbkBpZXRmLm9yZyA8bDJ2cG5AaWV0Zi5vcmc+DQpTZW50OiBGcmkgSnVsIDMx
IDAyOjM3OjMzIDIwMDkNClN1YmplY3Q6IFJFOiBFeHRlbnNpb25zIHRvIExEUCBTaWduYWxpbmcg
Zm9yIFBCQi1WUExTIC0gDQoNCkhJIEZsb3JpbjoNCg0KPiBJIHdhcyB1bmRlciB0aGUgaW1wcmVz
c2lvbiB3ZSBjbG9zZWQgdGhlIGl0ZW0gZHVyaW5nIG91ciBhZnRlcm5vb24NCmRpc2N1c3Npb24u
IA0KDQpJIGFwcHJlY2lhdGVkIHRoZSBvcHBvcnR1bml0eSB0byB1bmRlcnN0YW5kIHNvbWUgb2Yg
eW91ciBtb3RpdmF0aW9ucyBmb3INCnlvdXIgdGVjaG5pY2FsIGNob2ljZXMuLi5idXQgd2UnZCBu
b3QgY2xvc2VkIG9uIGNvbnNlbnN1cy4uLklmIEkgZ2F2ZQ0KeW91IHRoYXQgaW1wcmVzc2lvbiwg
dGhhdCB3YXMgdW5mb3J0dW5hdGUuLi4NCg0KPiBCdXQgeW91IHNlZW0gaW4tbG92ZSB3aXRoIHlv
dXIgaWRlYSEgOikgDQoNCkxvdmUgaXMgbm90IHRoZSByaWdodCB0ZXJtLiBJIGxpa2UgdGhlIGF0
dHJpYnV0ZXMgb2YgdGhlIHNvbHV0aW9uLCBhbmQNCmlmIHRob3NlIGNhbiBiZSBhY2hpZXZlZCBi
eSBvdGhlciBtZWFucywgSSBtYXkgbGlrZSB0aGF0IGFzIHdlbGwuLi4NClRoZXJlIGFyZSB0d28g
YXR0cmlidXRlcyBJIHZhbHVlIGhlcmU6DQoNCjEpIEtub3dsZWRnZSBvZiBkdWFsIGhvbWluZyBp
cyBsb2NhbCB0byB0aGUgImhvbWVkIHVwb24iIFBFcywgbm8gYnJvYWRlcg0KaW1wYWN0cyBvbiB0
aGUgbmV0d29yaw0KDQoyKSBDLU1BQyBmbHVzaCBpcyBub3QgcmVxdWlyZWQgYXQgcGVlciBCRUJz
IG9uIGEgY2hhbmdlIG9mIHdoaWNoIFBFL0JFQg0KdGhlIENFIGlzIGhvbWVkIHVwb24uDQoNCj4g
SWYgeW91IHN0aWxsIHRoaW5rIHdoYXQgeW91IGhhdmUgaW4gbWluZCBpcyBzb3VuZCwgSSBzdWdn
ZXN0IHlvdSBwdXQNCml0IGluIGEgZG9jdW1lbnQgYW5kIHN1Ym1pdCBpdCB0byBJRUVFIDgwMi4x
IGZvciANCj4gcHJvcGVyIHJldmlldyBpbiBvbmUgb2YgdGhlIGluY29taW5nIElFRUUgc2Vzc2lv
bnMuIA0KDQpJIHVuZGVyc3RhbmQgdGhhdCB3aGlsZSB0aGlzIGlzIG5vdCBhIGZvcm1hbCBwcm9q
ZWN0IGF0IHRoZSBJRUVFLCBpdCBpcw0KYSBob3QgdG9waWMsIGFuZCB0aGV5IGNvbnNpZGVyIEMt
TUFDIGZsdXNoaW5nIHVuZGVzaXJhYmxlLiBNeQ0KZXhwZWN0YXRpb24gYmVpbmcgdGhhdCBpZiB0
aGV5IGdvIGZvcndhcmQsIHRoZXkgd291bGQgcHJvZHVjZSBhIHNvbHV0aW9uDQpvZiBzaW1pbGFy
IGF0dHJpYnV0ZXMgdG8gdGhvc2UgSSB2YWx1ZSwgZXZlbiBpZiBub3QgdGhlIHNhbWUgaW4gZGV0
YWlsLg0KUHJvZ3Jlc3NpbmcgYSBzb2x1dGlvbiBub3cgaW4gTDJWUE4gbWF5IGhhdmUgYXR0cml1
dGVzIGluY29tcGF0aWJsZSB3aXRoDQp3aGF0IHRoZSBJRUVFIHVsdGltYXRlbHkgZG9lcy4uLg0K
DQpNZWFud2hpbGUsIGlmIHRoZSBXRyBpbnNpc3RzIG9uIGEgc29sdXRpb24gaW4gYWR2YW5jZSBp
ZiBJRUVFLCB0aGUgSUVURg0KaGFzIG5vdCBiZWVuIHNoeSBhYm91dCBtb3ZpbmcgTUFDcyBmb3Ig
cmVzaWxpZW5jeSByZWFzb25zLCB3aXRuZXNzIFZSUlAsDQphbmQgdGhhdCBjb3VsZCBiZSBkb25l
IHdpdGhvdXQgYW55IGNvbnRyb2wgcGxhbmUgY2hhbmdlcy4uLklmIHdoYXQgdGhlDQpJRUVFIHBy
b2R1Y2VzIHJlcXVpcmVzIGNoYW5nZXMsIGl0IGNvdWxkIGJlIGFkZHJlc3NlZCBhdCB0aGF0IHRp
bWUuLi4NCg0KPiBJIGJlbGlldmUgdGhlIHNvbHV0aW9uIHdlIHByZXNlbnRlZCB0b2RheSBpcyBh
ZGRyZXNzaW5nIGluIGEgZ2VuZXJpYw0Kd2F5IHRoZSBvcGVyYXRpb25hbCBlbnZpcm9ubWVudCB3
aGljaCBpcyBpbiBzY29wZSANCj4gZm9yIEwyVlBOIFdHOiBkZXBsb3llZCBMRFAgVlBMUyBuZXR3
b3JrcyB1c2luZyB0aGUgZXhpc3RpbmcgTERQIE1BQw0KRmx1c2ggdG9vbHNldC4gSW4gdGhpcyBl
bnZpcm9ubWVudCBpdCBtYWtlcyBzZW5zZSB0byANCj4gaGF2ZSBjb25zaXN0ZW50IHByb2NlZHVy
ZXMgZm9yIGJvdGggVlBMUyBhbmQgUEJCLVZQTFMuDQoNCkknbSBub3QgcXVpdGUgcGFyc2luZyB0
aGlzLCBpZiBjb25zaXN0ZW50IHByb2NlZHVyZXMsIG5vdGhpbmcgbmV3IHdvdWxkDQpiZSBuZWVk
ZWQuIENhbiB5b3UgY2xhcmlmeSB0aGlzLi4uPw0KDQpCZXN0DQpEYXZlDQoNCg0KPiAtLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEYXZpZCBBbGxhbiBbbWFpbHRvOmRhbGxhbkBu
b3J0ZWwuY29tXQ0KPiBTZW50OiBUaHVyc2RheSwgSnVseSAzMCwgMjAwOSA4OjIzIEFNDQo+IFRv
OiBCQUxVUyBGbG9yaW47IGwydnBuQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBFeHRlbnNpb25z
IHRvIExEUCBTaWduYWxpbmcgZm9yIFBCQi1WUExTIC0NCj4gDQo+IFVuZGVyc3Rvb2QsDQo+IA0K
PiAuLi5idXQgSSBkb24ndCBzZWUgYSBkaWZmZXJlbmNlIGJldHdlZW4gYWRtaW5pc3RlcmluZyBN
SC1JRHMgYW5kIA0KPiBhZG1pbmlzdGVyaW5nIEItTUFDcywgMToxIGNhcmRpbmFsaXR5IGZvciBh
bnkgaW5jcmVtZW50YWwgDQo+IGFkbWluaXN0cmF0aW9uIC4uLmFuZCBzdWNoIHN0YXRlIG5lZWRz
IHRvIHJlc2lkZSBzb21ld2hlcmUuLi4ueW91IA0KPiBzaW1wbHkgbm93IGhhdmUNCm1vcmUNCj4g
Y2xhc3NlcyBvZiBpdC4uLg0KPiANCj4gSU1PIGlmIGEgZHVhbCBob21lZCBuZXR3b3JrIGlzIGdp
dmVuIGEgUElQIG9uIGVhY2ggb2YgdGhlIFBFcyBpdCBpcyANCj4gaG9tZWQgdXBvbiB3aXRoIHRo
ZSBzbGlnaHQgYWJ1c2Ugb2YgaGF2aW5nIGEgY29tbW9uIEItTUFDIGFkZHJlc3MsIEkgDQo+IGJl
bGlldmUgbm8gY2hhbmdlcyB0byBleGlzdGluZyBjb250cm9sIHBsYW5lIHByb2NlZHVyZXMgYXJl
IHJlcXVpcmVkLCANCj4gYW5kIHRoZSBzdWJ0ZW5kaW5nIEV0aGVybmV0IGNhbiB0aGVuIHNlbGVj
dCB0aGUgYWN0aXZlIHBvcnQgKHZpYSBNQy0gDQo+IExBRywgU1RQIG9yIHdoYXRldmVyIHByb2Nl
ZHVyZXMpIHdpdGhvdXQgcmVxdWlyaW5nIGFueSBWUExTIHByb2NlZHVyZXMNCg0KPiBvciBjb250
cm9sIHBsYW5lIGludGVyd29ya2luZyB0byBzcGVhayBvZi4gSSB3aWxsIHNlZSBtb3JlIEItTUFD
DQphZGRyZXNzZXMNCj4gdGhhbiBJIHdvdWxkIHNlZSBvdGhlcndpc2UsICBidXQgSU1PIHRoaXMg
aXMgb25seSByZWFsbHkgcGFyc2l0aWMgaWYgDQo+IHRoZSBkdWFsIGhvbWVkIGN1c3RvbWVyIG5l
dHdvcmsgaXMgYSBzaW5nbGUgQy1NQUMgKHJvdXRlcikuDQo+IA0KPiBBcyBmb3IgYWN0dWFsIGZh
aWx1cmUgc2NlbmFyaW8sIGFmdGVyIHRoZSBQSVAgQi1NQUMgaXMgd2l0aGRyYXduLA0KdGhlcmUN
Cj4gd2lsbCBzaW1wbHkgYmUgYSBmZXcgZmxvb2RlZCBmcmFtZXMgYXQgdGhlIEItTUFDIGxheWVy
IHVudGlsIHRoZSBuZXcgDQo+IHBhdGggdG8gdGhlIGN1c3RvbWVyIG5ldHdvcmsgaXMgbGVhcm5l
ZCB2aWEgdGhlIGFsdGVybmF0ZSBQSVAsIHRoZSANCj4gY3VzdG9tZXIgbmV0d29yayB3aWxsIG5v
dCBleHBlcmllbmNlIGEgbG90IG9mIGZsb29kaW5nIG9mIEMtTUFDIGZyYW1lcw0KDQo+IGFzIHRo
ZSBuZXR3b3JrIGNvbnZlcmdlbmNlLCBpbiBlZmZlY3QgdGhlIGZhY3QgdGhlcmUgd2FzIGEgZmFp
bHVyZSBpbiANCj4gdGhlIG5ldHdvcmsgd2lsbCBub3QgbWFuaWZlc3QgaXRzZWxmIGluIGEgbG90
IG9mIGN1c3RvbWVyIGxheWVyIA0KPiBmbG9vZGluZyBvZiBmcmFtZXMuLi5lcmdvLCBzaWxlbnRs
eSByZWNvdmVyZWQgOy0pDQo+IA0KPiBJIGxpa2UgaXQuLi4NCj4gDQo+IENoZWVycw0KPiBEYXZl
DQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBCQUxVUyBGbG9yaW4g
W21haWx0bzpGbG9yaW4uQmFsdXNAYWxjYXRlbC1sdWNlbnQuY29tXQ0KPiBTZW50OiBUaHVyc2Rh
eSwgSnVseSAzMCwgMjAwOSAxMTowNCBBTQ0KPiBUbzogQWxsYW4sIERhdmlkIChDQVI6TlMwMCk7
IGwydnBuQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBFeHRlbnNpb25zIHRvIExEUCBTaWduYWxp
bmcgZm9yIFBCQi1WUExTIC0NCj4gDQo+IEhpIERhdmUsDQo+IEFzIGRpc2N1c3NlZCBhZnRlciB0
aGUgc2Vzc2lvbiwgd2UgYXJlIHByb3Bvc2luZyBhIGdlbmVyaWMgc29sdXRpb24gDQo+IHRoYXQg
ZG9lcyBub3QgZGVwZW5kIG9uIGFueSBzcGVjaWFsLCBsb2NhbGx5IGNvbmZpZ3VyZWQsIEJNQUMg
DQo+IGFzc2lnbm1lbnQgc2NoZW1lLg0KPiBGbG9yaW4NCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBEYXZpZCBBbGxhbiBbbWFpbHRvOmRhbGxhbkBub3J0ZWwu
Y29tXQ0KPiA+IFNlbnQ6IFRodXJzZGF5LCBKdWx5IDMwLCAyMDA5IDEyOjQ5IEFNDQo+ID4gVG86
IEJBTFVTIEZsb3JpbjsgbDJ2cG5AaWV0Zi5vcmcNCj4gPiBTdWJqZWN0OiBFeHRlbnNpb25zIHRv
IExEUCBTaWduYWxpbmcgZm9yIFBCQi1WUExTIC0NCj4gPg0KPiA+IEhpIEZsb3JpbjoNCj4gPg0K
PiA+IEkgdW5kZXJzdGFuZCB0aGUgcHJvYmxlbSB0aGlzIHByb3Bvc2VzIHRvIHNvbHZlLCBidXQg
SSBiZWxpZXZlIHRoZXJlDQo+IGlzDQo+ID4gYSBzaW1wbGVyIHdheS4gSWYgeW91IGFzc2lnbiBh
IEItTUFDIHRvIGEgbXVsdGlob21lZCBjdXN0b21lciBzaXRlDQo+IHRoZW4NCj4gPiB5b3UgbmV2
ZXIgbmVlZCB0byBpbnZhbGlkYXRlIEMtTUFDIHRvIEItTUFDIGJpbmRpbmdzIGFuZCBhIE1BQyAN
Cj4gPiBpbnZhbGlkYXRlIG1lc3NhZ2UgZm9yIHRoZSBCLU1BQyBpcyBzdWZmaWNpZW50IHRvIGVu
c3VyZSBubyBibGFjayANCj4gPiBob2xpbmcgd2hlbiBhbiBBQyBnb2VzIGRvd24sIG5vcm1hbCBm
bG9vZGluZyBhbmQgbGVhcm5pbmcgcGVybWl0dGluZw0KDQo+ID4gcmVtb3RlIFBFcyB0byBsZWFy
biB3aGljaCBQRSB0aGUgY3VzdG9tZXIgc2l0ZSBpcyByZWFjaGFibGUgdmlhLg0KVGhpcw0KPiA+
IHByb3ZpZGVzDQo+IGZvcg0KPiA+IHRoZSBwb3NzaWJpbGl0eSBvZiBsb2NhbGl6aW5nIHRoZSBi
bG9ja2VkL3VuYmxvY2tlZCBkZWNpc2lvbiBmb3IgdGhlDQoNCj4gPiBBQ3MgKHdoaWNoIElNTyBu
ZWVkcyB0byBiZSBjb29yZGluYXRlZCBiZXR3ZWVuIHRoZSBNSCBQRXMgaW4gb3JkZXINCnRvDQo+
ID4gYmUgcm9idXN0bHkgbG9vcCBmcmVlKSBhcyBrbm93bGVkZ2Ugb2YgdGhlIG11bHRpLWhvbWlu
ZyBkb2VzIG5vdA0KbmVlZA0KPiA+IHRvIGJlIHByb3BhZ2F0ZWQgaW50byB0aGUgbmV0d29yay4N
Cj4gPg0KPiA+IFdEWVQ/DQo+ID4gRGF2ZQ0KDQo=

------_=_NextPart_001_01CA11B8.52A5A94F
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+
DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o
dG1sOyBjaGFyc2V0PVVURi04Ij4NCjxNRVRBIE5BTUU9IkdlbmVyYXRvciIgQ09OVEVOVD0iTVMg
RXhjaGFuZ2UgU2VydmVyIHZlcnNpb24gNi41Ljc2NTQuMTIiPg0KPFRJVExFPlJlOiBFeHRlbnNp
b25zIHRvIExEUCBTaWduYWxpbmcgZm9yIFBCQi1WUExTIC08L1RJVExFPg0KPC9IRUFEPg0KPEJP
RFk+DQo8IS0tIENvbnZlcnRlZCBmcm9tIHRleHQvcGxhaW4gZm9ybWF0IC0tPg0KDQo8UD48Rk9O
VCBTSVpFPTI+RGF2ZSw8QlI+DQpZb3UgYXJlIHRhbGtpbmcgYWJvdXQgc29tZSB1bmRvY3VtZW50
ZWQgcHJvcG9zYWwgdGhhdCBzZWVtIHRvIGJlIGluIElFRUUgc2NvcGUuIEJlZm9yZSBkZWNsYXJp
bmcgaXQgYW4gYWxsIGVuY29tcGFzc2luZyBzb2x1dGlvbiB0aGF0IGNvdmVycyBhbGwgdXNlIGNh
c2VzJm5ic3A7IHlvdSBuZWVkIHRvIGRvY3VtZW50IGl0IGFuZCBzdWJtaXR0IGl0IHRvIElFRUUg
Zm9yIDgwMi4xIHNjcnV0aW55LiBBcyBJIGV4cGxhaW5lZCB0byB5b3UsIGZyb20gdGhlIGxvb2tz
IG9mIGl0IHlvdXIgcHJvcG9zYWwgc2VlbXMgdW5uYWNjZXB0YWJsZSB0byBhdCBsZWFzdCBwYXJ0
IG9mIHRoZSBsYXJnZSBWUExTIGRlcGxveW1lbnRzICgxSysgUEVzKSB3aGVyZSBwZW9wbGUgdmFs
dWUgc2ltcGxlIG9wZXJhdGlvbnMmbmJzcDsgYW5kIHdhbnQgdG8gbGltaXQgdGhlIG51bWJlciBv
ZiBibWFjcyBpbiB0aGUgbmV0d29yay48QlI+DQo8QlI+DQpUaGUgc29sdXRpb24gd2UgcHJvcG9z
ZSBpcyBnZW5lcmljIGFuZCBkb2VzIG5vdCByZXF1aXJlIGFueSBjaGFuZ2UgaW4gb3BlcmF0aW9u
IG9mIGV4aXN0aW5nIFZQTFMgbmV0d29ya3MuIFRoYXQgaXMgd2h5SSBzYWlkIGlzIGNvbnNpc3Rl
bnQgd2l0aCB3aGF0IGlzIGluIHVzZS4gTW9yZW92ZXIgaXQgaXMgYmFzZWQgb24gdGhlIHNhbWUg
bGRwIHdpdGhkcmF3IG1lc3NhZ2Ugd2hlcmUgcGJiIHRsdiBpcyBhZGRlZCBhdXRvbWF0aWNhbGx5
IGJhc2VkIG9uIHRoZSBwbGFjZSB3aGVyZSB0aGUgZXZlbnQgdGFrZXMgcGxhY2UuPEJSPg0KPEJS
Pg0KSSB3aWxsIGJlIGluIHZhY2F0aW9uIGZvciB0aGUgbmV4dCB3aGlsZSB3aXRob3V0IGFjY2Vz
cyB0byBlbWFpbCBzbyBJd2lsbCBoYXZlIGEgaGFyZCB0aW1lIGNvbnRpbnV5aW5nIHRoaXMgZGVi
YXRlLiBBbnlob3cgYmFzZWQgb24gdGhlIGFib3ZlIGFyZ3VtZW50cyBJIHRoaW5rIHRoaXMgaXMg
dGhlIHdyb25nIGNvbnRleHQgZm9yIGRpc2N1c3NpbmcgdGhlIHZhbHVlIG9mIHlvdXIgcHJvcG9z
YWwgd2l0aG91dCBhIHdlbGwgZG9jdW1lbnRlZCBzb2x1dGlvbiBkb2MuJm5ic3A7PEJSPg0KRmxv
cmluPEJSPg0KPEJSPg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLTxCUj4NCkZyb206IGwy
dnBuLWJvdW5jZXNAaWV0Zi5vcmcgJmx0O2wydnBuLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PEJSPg0K
VG86IEJBTFVTIEZsb3JpbjsgbDJ2cG5AaWV0Zi5vcmcgJmx0O2wydnBuQGlldGYub3JnJmd0OzxC
Uj4NClNlbnQ6IEZyaSBKdWwgMzEgMDI6Mzc6MzMgMjAwOTxCUj4NClN1YmplY3Q6IFJFOiBFeHRl
bnNpb25zIHRvIExEUCBTaWduYWxpbmcgZm9yIFBCQi1WUExTIC08QlI+DQo8QlI+DQpISSBGbG9y
aW46PEJSPg0KPEJSPg0KJmd0OyBJIHdhcyB1bmRlciB0aGUgaW1wcmVzc2lvbiB3ZSBjbG9zZWQg
dGhlIGl0ZW0gZHVyaW5nIG91ciBhZnRlcm5vb248QlI+DQpkaXNjdXNzaW9uLjxCUj4NCjxCUj4N
CkkgYXBwcmVjaWF0ZWQgdGhlIG9wcG9ydHVuaXR5IHRvIHVuZGVyc3RhbmQgc29tZSBvZiB5b3Vy
IG1vdGl2YXRpb25zIGZvcjxCUj4NCnlvdXIgdGVjaG5pY2FsIGNob2ljZXMuLi5idXQgd2UnZCBu
b3QgY2xvc2VkIG9uIGNvbnNlbnN1cy4uLklmIEkgZ2F2ZTxCUj4NCnlvdSB0aGF0IGltcHJlc3Np
b24sIHRoYXQgd2FzIHVuZm9ydHVuYXRlLi4uPEJSPg0KPEJSPg0KJmd0OyBCdXQgeW91IHNlZW0g
aW4tbG92ZSB3aXRoIHlvdXIgaWRlYSEgOik8QlI+DQo8QlI+DQpMb3ZlIGlzIG5vdCB0aGUgcmln
aHQgdGVybS4gSSBsaWtlIHRoZSBhdHRyaWJ1dGVzIG9mIHRoZSBzb2x1dGlvbiwgYW5kPEJSPg0K
aWYgdGhvc2UgY2FuIGJlIGFjaGlldmVkIGJ5IG90aGVyIG1lYW5zLCBJIG1heSBsaWtlIHRoYXQg
YXMgd2VsbC4uLjxCUj4NClRoZXJlIGFyZSB0d28gYXR0cmlidXRlcyBJIHZhbHVlIGhlcmU6PEJS
Pg0KPEJSPg0KMSkgS25vd2xlZGdlIG9mIGR1YWwgaG9taW5nIGlzIGxvY2FsIHRvIHRoZSAmcXVv
dDtob21lZCB1cG9uJnF1b3Q7IFBFcywgbm8gYnJvYWRlcjxCUj4NCmltcGFjdHMgb24gdGhlIG5l
dHdvcms8QlI+DQo8QlI+DQoyKSBDLU1BQyBmbHVzaCBpcyBub3QgcmVxdWlyZWQgYXQgcGVlciBC
RUJzIG9uIGEgY2hhbmdlIG9mIHdoaWNoIFBFL0JFQjxCUj4NCnRoZSBDRSBpcyBob21lZCB1cG9u
LjxCUj4NCjxCUj4NCiZndDsgSWYgeW91IHN0aWxsIHRoaW5rIHdoYXQgeW91IGhhdmUgaW4gbWlu
ZCBpcyBzb3VuZCwgSSBzdWdnZXN0IHlvdSBwdXQ8QlI+DQppdCBpbiBhIGRvY3VtZW50IGFuZCBz
dWJtaXQgaXQgdG8gSUVFRSA4MDIuMSBmb3I8QlI+DQomZ3Q7IHByb3BlciByZXZpZXcgaW4gb25l
IG9mIHRoZSBpbmNvbWluZyBJRUVFIHNlc3Npb25zLjxCUj4NCjxCUj4NCkkgdW5kZXJzdGFuZCB0
aGF0IHdoaWxlIHRoaXMgaXMgbm90IGEgZm9ybWFsIHByb2plY3QgYXQgdGhlIElFRUUsIGl0IGlz
PEJSPg0KYSBob3QgdG9waWMsIGFuZCB0aGV5IGNvbnNpZGVyIEMtTUFDIGZsdXNoaW5nIHVuZGVz
aXJhYmxlLiBNeTxCUj4NCmV4cGVjdGF0aW9uIGJlaW5nIHRoYXQgaWYgdGhleSBnbyBmb3J3YXJk
LCB0aGV5IHdvdWxkIHByb2R1Y2UgYSBzb2x1dGlvbjxCUj4NCm9mIHNpbWlsYXIgYXR0cmlidXRl
cyB0byB0aG9zZSBJIHZhbHVlLCBldmVuIGlmIG5vdCB0aGUgc2FtZSBpbiBkZXRhaWwuPEJSPg0K
UHJvZ3Jlc3NpbmcgYSBzb2x1dGlvbiBub3cgaW4gTDJWUE4gbWF5IGhhdmUgYXR0cml1dGVzIGlu
Y29tcGF0aWJsZSB3aXRoPEJSPg0Kd2hhdCB0aGUgSUVFRSB1bHRpbWF0ZWx5IGRvZXMuLi48QlI+
DQo8QlI+DQpNZWFud2hpbGUsIGlmIHRoZSBXRyBpbnNpc3RzIG9uIGEgc29sdXRpb24gaW4gYWR2
YW5jZSBpZiBJRUVFLCB0aGUgSUVURjxCUj4NCmhhcyBub3QgYmVlbiBzaHkgYWJvdXQgbW92aW5n
IE1BQ3MgZm9yIHJlc2lsaWVuY3kgcmVhc29ucywgd2l0bmVzcyBWUlJQLDxCUj4NCmFuZCB0aGF0
IGNvdWxkIGJlIGRvbmUgd2l0aG91dCBhbnkgY29udHJvbCBwbGFuZSBjaGFuZ2VzLi4uSWYgd2hh
dCB0aGU8QlI+DQpJRUVFIHByb2R1Y2VzIHJlcXVpcmVzIGNoYW5nZXMsIGl0IGNvdWxkIGJlIGFk
ZHJlc3NlZCBhdCB0aGF0IHRpbWUuLi48QlI+DQo8QlI+DQomZ3Q7IEkgYmVsaWV2ZSB0aGUgc29s
dXRpb24gd2UgcHJlc2VudGVkIHRvZGF5IGlzIGFkZHJlc3NpbmcgaW4gYSBnZW5lcmljPEJSPg0K
d2F5IHRoZSBvcGVyYXRpb25hbCBlbnZpcm9ubWVudCB3aGljaCBpcyBpbiBzY29wZTxCUj4NCiZn
dDsgZm9yIEwyVlBOIFdHOiBkZXBsb3llZCBMRFAgVlBMUyBuZXR3b3JrcyB1c2luZyB0aGUgZXhp
c3RpbmcgTERQIE1BQzxCUj4NCkZsdXNoIHRvb2xzZXQuIEluIHRoaXMgZW52aXJvbm1lbnQgaXQg
bWFrZXMgc2Vuc2UgdG88QlI+DQomZ3Q7IGhhdmUgY29uc2lzdGVudCBwcm9jZWR1cmVzIGZvciBi
b3RoIFZQTFMgYW5kIFBCQi1WUExTLjxCUj4NCjxCUj4NCkknbSBub3QgcXVpdGUgcGFyc2luZyB0
aGlzLCBpZiBjb25zaXN0ZW50IHByb2NlZHVyZXMsIG5vdGhpbmcgbmV3IHdvdWxkPEJSPg0KYmUg
bmVlZGVkLiBDYW4geW91IGNsYXJpZnkgdGhpcy4uLj88QlI+DQo8QlI+DQpCZXN0PEJSPg0KRGF2
ZTxCUj4NCjxCUj4NCjxCUj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+DQom
Z3Q7IEZyb206IERhdmlkIEFsbGFuIFs8QSBIUkVGPSJtYWlsdG86ZGFsbGFuQG5vcnRlbC5jb20i
Pm1haWx0bzpkYWxsYW5Abm9ydGVsLmNvbTwvQT5dPEJSPg0KJmd0OyBTZW50OiBUaHVyc2RheSwg
SnVseSAzMCwgMjAwOSA4OjIzIEFNPEJSPg0KJmd0OyBUbzogQkFMVVMgRmxvcmluOyBsMnZwbkBp
ZXRmLm9yZzxCUj4NCiZndDsgU3ViamVjdDogUkU6IEV4dGVuc2lvbnMgdG8gTERQIFNpZ25hbGlu
ZyBmb3IgUEJCLVZQTFMgLTxCUj4NCiZndDs8QlI+DQomZ3Q7IFVuZGVyc3Rvb2QsPEJSPg0KJmd0
OzxCUj4NCiZndDsgLi4uYnV0IEkgZG9uJ3Qgc2VlIGEgZGlmZmVyZW5jZSBiZXR3ZWVuIGFkbWlu
aXN0ZXJpbmcgTUgtSURzIGFuZDxCUj4NCiZndDsgYWRtaW5pc3RlcmluZyBCLU1BQ3MsIDE6MSBj
YXJkaW5hbGl0eSBmb3IgYW55IGluY3JlbWVudGFsPEJSPg0KJmd0OyBhZG1pbmlzdHJhdGlvbiAu
Li5hbmQgc3VjaCBzdGF0ZSBuZWVkcyB0byByZXNpZGUgc29tZXdoZXJlLi4uLnlvdTxCUj4NCiZn
dDsgc2ltcGx5IG5vdyBoYXZlPEJSPg0KbW9yZTxCUj4NCiZndDsgY2xhc3NlcyBvZiBpdC4uLjxC
Uj4NCiZndDs8QlI+DQomZ3Q7IElNTyBpZiBhIGR1YWwgaG9tZWQgbmV0d29yayBpcyBnaXZlbiBh
IFBJUCBvbiBlYWNoIG9mIHRoZSBQRXMgaXQgaXM8QlI+DQomZ3Q7IGhvbWVkIHVwb24gd2l0aCB0
aGUgc2xpZ2h0IGFidXNlIG9mIGhhdmluZyBhIGNvbW1vbiBCLU1BQyBhZGRyZXNzLCBJPEJSPg0K
Jmd0OyBiZWxpZXZlIG5vIGNoYW5nZXMgdG8gZXhpc3RpbmcgY29udHJvbCBwbGFuZSBwcm9jZWR1
cmVzIGFyZSByZXF1aXJlZCw8QlI+DQomZ3Q7IGFuZCB0aGUgc3VidGVuZGluZyBFdGhlcm5ldCBj
YW4gdGhlbiBzZWxlY3QgdGhlIGFjdGl2ZSBwb3J0ICh2aWEgTUMtPEJSPg0KJmd0OyBMQUcsIFNU
UCBvciB3aGF0ZXZlciBwcm9jZWR1cmVzKSB3aXRob3V0IHJlcXVpcmluZyBhbnkgVlBMUyBwcm9j
ZWR1cmVzPEJSPg0KPEJSPg0KJmd0OyBvciBjb250cm9sIHBsYW5lIGludGVyd29ya2luZyB0byBz
cGVhayBvZi4gSSB3aWxsIHNlZSBtb3JlIEItTUFDPEJSPg0KYWRkcmVzc2VzPEJSPg0KJmd0OyB0
aGFuIEkgd291bGQgc2VlIG90aGVyd2lzZSwmbmJzcDsgYnV0IElNTyB0aGlzIGlzIG9ubHkgcmVh
bGx5IHBhcnNpdGljIGlmPEJSPg0KJmd0OyB0aGUgZHVhbCBob21lZCBjdXN0b21lciBuZXR3b3Jr
IGlzIGEgc2luZ2xlIEMtTUFDIChyb3V0ZXIpLjxCUj4NCiZndDs8QlI+DQomZ3Q7IEFzIGZvciBh
Y3R1YWwgZmFpbHVyZSBzY2VuYXJpbywgYWZ0ZXIgdGhlIFBJUCBCLU1BQyBpcyB3aXRoZHJhd24s
PEJSPg0KdGhlcmU8QlI+DQomZ3Q7IHdpbGwgc2ltcGx5IGJlIGEgZmV3IGZsb29kZWQgZnJhbWVz
IGF0IHRoZSBCLU1BQyBsYXllciB1bnRpbCB0aGUgbmV3PEJSPg0KJmd0OyBwYXRoIHRvIHRoZSBj
dXN0b21lciBuZXR3b3JrIGlzIGxlYXJuZWQgdmlhIHRoZSBhbHRlcm5hdGUgUElQLCB0aGU8QlI+
DQomZ3Q7IGN1c3RvbWVyIG5ldHdvcmsgd2lsbCBub3QgZXhwZXJpZW5jZSBhIGxvdCBvZiBmbG9v
ZGluZyBvZiBDLU1BQyBmcmFtZXM8QlI+DQo8QlI+DQomZ3Q7IGFzIHRoZSBuZXR3b3JrIGNvbnZl
cmdlbmNlLCBpbiBlZmZlY3QgdGhlIGZhY3QgdGhlcmUgd2FzIGEgZmFpbHVyZSBpbjxCUj4NCiZn
dDsgdGhlIG5ldHdvcmsgd2lsbCBub3QgbWFuaWZlc3QgaXRzZWxmIGluIGEgbG90IG9mIGN1c3Rv
bWVyIGxheWVyPEJSPg0KJmd0OyBmbG9vZGluZyBvZiBmcmFtZXMuLi5lcmdvLCBzaWxlbnRseSBy
ZWNvdmVyZWQgOy0pPEJSPg0KJmd0OzxCUj4NCiZndDsgSSBsaWtlIGl0Li4uPEJSPg0KJmd0OzxC
Uj4NCiZndDsgQ2hlZXJzPEJSPg0KJmd0OyBEYXZlPEJSPg0KJmd0OzxCUj4NCiZndDsgLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+DQomZ3Q7IEZyb206IEJBTFVTIEZsb3JpbiBbPEEgSFJF
Rj0ibWFpbHRvOkZsb3Jpbi5CYWx1c0BhbGNhdGVsLWx1Y2VudC5jb20iPm1haWx0bzpGbG9yaW4u
QmFsdXNAYWxjYXRlbC1sdWNlbnQuY29tPC9BPl08QlI+DQomZ3Q7IFNlbnQ6IFRodXJzZGF5LCBK
dWx5IDMwLCAyMDA5IDExOjA0IEFNPEJSPg0KJmd0OyBUbzogQWxsYW4sIERhdmlkIChDQVI6TlMw
MCk7IGwydnBuQGlldGYub3JnPEJSPg0KJmd0OyBTdWJqZWN0OiBSRTogRXh0ZW5zaW9ucyB0byBM
RFAgU2lnbmFsaW5nIGZvciBQQkItVlBMUyAtPEJSPg0KJmd0OzxCUj4NCiZndDsgSGkgRGF2ZSw8
QlI+DQomZ3Q7IEFzIGRpc2N1c3NlZCBhZnRlciB0aGUgc2Vzc2lvbiwgd2UgYXJlIHByb3Bvc2lu
ZyBhIGdlbmVyaWMgc29sdXRpb248QlI+DQomZ3Q7IHRoYXQgZG9lcyBub3QgZGVwZW5kIG9uIGFu
eSBzcGVjaWFsLCBsb2NhbGx5IGNvbmZpZ3VyZWQsIEJNQUM8QlI+DQomZ3Q7IGFzc2lnbm1lbnQg
c2NoZW1lLjxCUj4NCiZndDsgRmxvcmluPEJSPg0KJmd0OzxCUj4NCiZndDsgJmd0OyAtLS0tLU9y
aWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj4NCiZndDsgJmd0OyBGcm9tOiBEYXZpZCBBbGxhbiBbPEEg
SFJFRj0ibWFpbHRvOmRhbGxhbkBub3J0ZWwuY29tIj5tYWlsdG86ZGFsbGFuQG5vcnRlbC5jb208
L0E+XTxCUj4NCiZndDsgJmd0OyBTZW50OiBUaHVyc2RheSwgSnVseSAzMCwgMjAwOSAxMjo0OSBB
TTxCUj4NCiZndDsgJmd0OyBUbzogQkFMVVMgRmxvcmluOyBsMnZwbkBpZXRmLm9yZzxCUj4NCiZn
dDsgJmd0OyBTdWJqZWN0OiBFeHRlbnNpb25zIHRvIExEUCBTaWduYWxpbmcgZm9yIFBCQi1WUExT
IC08QlI+DQomZ3Q7ICZndDs8QlI+DQomZ3Q7ICZndDsgSGkgRmxvcmluOjxCUj4NCiZndDsgJmd0
OzxCUj4NCiZndDsgJmd0OyBJIHVuZGVyc3RhbmQgdGhlIHByb2JsZW0gdGhpcyBwcm9wb3NlcyB0
byBzb2x2ZSwgYnV0IEkgYmVsaWV2ZSB0aGVyZTxCUj4NCiZndDsgaXM8QlI+DQomZ3Q7ICZndDsg
YSBzaW1wbGVyIHdheS4gSWYgeW91IGFzc2lnbiBhIEItTUFDIHRvIGEgbXVsdGlob21lZCBjdXN0
b21lciBzaXRlPEJSPg0KJmd0OyB0aGVuPEJSPg0KJmd0OyAmZ3Q7IHlvdSBuZXZlciBuZWVkIHRv
IGludmFsaWRhdGUgQy1NQUMgdG8gQi1NQUMgYmluZGluZ3MgYW5kIGEgTUFDPEJSPg0KJmd0OyAm
Z3Q7IGludmFsaWRhdGUgbWVzc2FnZSBmb3IgdGhlIEItTUFDIGlzIHN1ZmZpY2llbnQgdG8gZW5z
dXJlIG5vIGJsYWNrPEJSPg0KJmd0OyAmZ3Q7IGhvbGluZyB3aGVuIGFuIEFDIGdvZXMgZG93biwg
bm9ybWFsIGZsb29kaW5nIGFuZCBsZWFybmluZyBwZXJtaXR0aW5nPEJSPg0KPEJSPg0KJmd0OyAm
Z3Q7IHJlbW90ZSBQRXMgdG8gbGVhcm4gd2hpY2ggUEUgdGhlIGN1c3RvbWVyIHNpdGUgaXMgcmVh
Y2hhYmxlIHZpYS48QlI+DQpUaGlzPEJSPg0KJmd0OyAmZ3Q7IHByb3ZpZGVzPEJSPg0KJmd0OyBm
b3I8QlI+DQomZ3Q7ICZndDsgdGhlIHBvc3NpYmlsaXR5IG9mIGxvY2FsaXppbmcgdGhlIGJsb2Nr
ZWQvdW5ibG9ja2VkIGRlY2lzaW9uIGZvciB0aGU8QlI+DQo8QlI+DQomZ3Q7ICZndDsgQUNzICh3
aGljaCBJTU8gbmVlZHMgdG8gYmUgY29vcmRpbmF0ZWQgYmV0d2VlbiB0aGUgTUggUEVzIGluIG9y
ZGVyPEJSPg0KdG88QlI+DQomZ3Q7ICZndDsgYmUgcm9idXN0bHkgbG9vcCBmcmVlKSBhcyBrbm93
bGVkZ2Ugb2YgdGhlIG11bHRpLWhvbWluZyBkb2VzIG5vdDxCUj4NCm5lZWQ8QlI+DQomZ3Q7ICZn
dDsgdG8gYmUgcHJvcGFnYXRlZCBpbnRvIHRoZSBuZXR3b3JrLjxCUj4NCiZndDsgJmd0OzxCUj4N
CiZndDsgJmd0OyBXRFlUPzxCUj4NCiZndDsgJmd0OyBEYXZlPEJSPg0KPEJSPg0KPC9GT05UPg0K
PC9QPg0KDQo8L0JPRFk+DQo8L0hUTUw+

------_=_NextPart_001_01CA11B8.52A5A94F--