From stbryant@cisco.com Wed Nov 2 04:44:54 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8EB61F0C97 for ; Wed, 2 Nov 2011 04:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.699 X-Spam-Level: X-Spam-Status: No, score=-107.699 tagged_above=-999 required=5 tests=[AWL=-1.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SewGyAtXKQXB for ; Wed, 2 Nov 2011 04:44:54 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 107641F0C8E for ; Wed, 2 Nov 2011 04:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=333; q=dns/txt; s=iport; t=1320234294; x=1321443894; h=message-id:date:from:reply-to:mime-version:to:cc:subject: content-transfer-encoding; bh=Ur94c5RO4dsJ1b6VVcGtOIMbSkjMkVocDAtmPnNjY4Q=; b=Qwa3NTZgXKdCeK0j0NHAz8nuUM6D+46t4cLzmnnKQ44p2AHaQEiSiuRI 8+1pwgNvY6AIw4MTjAvL45vpfYuBilGme4piy922k531B5/SMhiPBe2pE xk+IAs7xsWaJ8+oW9WaHk2a+GpYQC8+wrcdDvczD5z5+PYVI954L8x9J7 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioHAMossU6Q/khL/2dsb2JhbABDmjONd4EegQWCCwECASJAATwWGAMCAQIBWAEHAQEeh2iWPAGDKg8BmxqJEASUFJFl X-IronPort-AV: E=Sophos;i="4.69,443,1315180800"; d="scan'208";a="2253712" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 02 Nov 2011 11:44:52 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pA2Biqr4019298; Wed, 2 Nov 2011 11:44:52 GMT Received: from dhcp-gpk02-vlan300-64-103-65-29.cisco.com (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id pA2Bip2N007353; Wed, 2 Nov 2011 11:44:52 GMT Message-ID: <4EB12D33.9080706@cisco.com> Date: Wed, 02 Nov 2011 11:44:51 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: 6man@ietf.org Subject: draft-ietf-l2vpn-arp-mediation review request Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 6man-chairs@tools.ietf.org, "l2vpn@ietf.org" , "l2vpn-chairs@tools.ietf.org" , draft-ietf-l2vpn-arp-mediation@tools.ietf.org, "rtg-ads@tools.ietf.org" , int-ads@tools.ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 11:44:54 -0000 6-man WG, During the IESG review of draft-ietf-l2vpn-arp-mediation it was noted that the IPv6 elements of this draft would benefit from a review by the 6-man working group. http://datatracker.ietf.org/doc/draft-ietf-l2vpn-arp-mediation/ Please can we have review comments by Monday 28th November. Thank you Stewart From stbryant@cisco.com Wed Nov 2 05:17:59 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7967D1F0CAF; Wed, 2 Nov 2011 05:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.599 X-Spam-Level: X-Spam-Status: No, score=-107.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4X+M9mo+-y0; Wed, 2 Nov 2011 05:17:59 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id AB7A01F0C91; Wed, 2 Nov 2011 05:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=stbryant@cisco.com; l=389; q=dns/txt; s=iport; t=1320236279; x=1321445879; h=message-id:date:from:reply-to:mime-version:to:cc:subject: content-transfer-encoding; bh=JbZtyUf1mkcXteZHDeSQ48c+/bAPLQVnOj5nZXNe8kw=; b=E4kok0sA9jsZM5l+JQqa0Wz9HeAuvkD+DLYOHfMoB28Xq8F5tbl6jcUu Ib9c0mioiDAeuXk0VcTtdZdRq8TnmAWWOZcVPKZo2GOnO1T1r5sUP6qaa ZmL/BUerAR5qfqK0Ut3QxXUk3jem8AuySr+m90iH+tdPbbNzbxGplAybM Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AioHALozsU6Q/khL/2dsb2JhbABDmjONd4EegQWCCwECASJAATwWGAMCAQIBWAEHAQEeh2iWQAGDKg8BmyCJEASUFJFl X-IronPort-AV: E=Sophos;i="4.69,443,1315180800"; d="scan'208";a="2256358" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 02 Nov 2011 12:17:57 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pA2CHsu8026977; Wed, 2 Nov 2011 12:17:57 GMT Received: from dhcp-gpk02-vlan300-64-103-65-29.cisco.com (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id pA2CHr24009800; Wed, 2 Nov 2011 12:17:53 GMT Message-ID: <4EB134F1.3070408@cisco.com> Date: Wed, 02 Nov 2011 12:17:53 +0000 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: ipv6@ietf.org Subject: draft-ietf-l2vpn-arp-mediation review request Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "l2vpn@ietf.org" , "l2vpn-chairs@tools.ietf.org" , Brian Haberman , Bob Hinden , draft-ietf-l2vpn-arp-mediation@tools.ietf.org, "rtg-ads@tools.ietf.org" , int-ads@tools.ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 12:17:59 -0000 Resending to the correct 6-man WG list email address 6-man WG, During the IESG review of draft-ietf-l2vpn-arp-mediation it was noted that the IPv6 elements of this draft would benefit from a review by the 6-man working group. http://datatracker.ietf.org/doc/draft-ietf-l2vpn-arp-mediation/ Please can we have review comments by Monday 28th November. Thank you Stewart From lucy.yong@huawei.com Wed Nov 2 08:22:26 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1000921F8F55; Wed, 2 Nov 2011 08:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.261 X-Spam-Level: X-Spam-Status: No, score=-6.261 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vluj2LkYqMMm; Wed, 2 Nov 2011 08:22:24 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6706721F8F36; Wed, 2 Nov 2011 08:22:24 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU100CW1GVZ0C@usaga02-in.huawei.com>; Wed, 02 Nov 2011 10:12:00 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LU100JTEGVZ3J@usaga02-in.huawei.com>; Wed, 02 Nov 2011 10:11:59 -0500 (CDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 02 Nov 2011 08:12:00 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Wed, 02 Nov 2011 08:11:50 -0700 Date: Wed, 02 Nov 2011 15:11:50 +0000 From: Lucy yong Subject: RE: L2VPN Agenda Slot Call for IETF 82 - Taipei In-reply-to: X-Originating-IP: [10.192.11.76] To: "Bitar, Nabil N" , "l2vpn@ietf.org" Message-id: <2691CE0099834E4A9C5044EEC662BB9D118D684A@dfweml505-mbx> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_58YMG1BTfhFKq/dWTfPGbQ)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: L2VPN Agenda Slot Call for IETF 82 - Taipei Thread-index: AcyR1ogbDHaJgFPbQg+vurpVXnT+0wHmnFXg X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Cc: Thomas Narten , Giles Heron , "nvo3@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 15:22:26 -0000 --Boundary_(ID_58YMG1BTfhFKq/dWTfPGbQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Nabil, I would like to present two drafts in L2VPN. Both drafts are new and informational. Draft-yong-trill-trill-o-mpls-00, Lucy Yong, 5min Draft-yong-l2vpn-spb-o-mpls-00, Lucy Yong, 5min Very sorry for the late notice. I was on trip last week and e-mails piles up. Please give slots to present these. Thanks, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Bitar, Nabil N Sent: Sunday, October 23, 2011 5:53 PM To: l2vpn@ietf.org Cc: Thomas Narten; Giles Heron; nvo3@ietf.org Subject: L2VPN Agenda Slot Call for IETF 82 - Taipei Hi, Please let us know if you have a time-slot request for the L2VPN sessions at IETF 82- Taipei. Please, email us your request by Sunday October 30, 2011 along with the following information: 1) Draft title 2) Presenter name 3) Requested duration Please remember that we have the following sessions as previously communicated l2vpn Session 1 (2 hours) Monday, Afternoon Session I 1300-1500 Room Name: 201 ABC l2vpn Session 2 (2.5 hours) Thursday, Morning Session I 0900-1130 Room Name: 3F Banquet Please note that the main priority in the first session on Monday will be given to drafts that are clearly within the scope of the current L2VPN charter . The second session on Thursday will be mainly focused on discussing and defining the problem that new drafts related to providing a layer2 service in a Data center environment are trying to address. There have been email exchanges on that. For some, it may be known as NV03 work. We will be co-ordinating/deciding on what will be presented in that session with the focus as stated in mind. Following are additional key dates to remember : * 2011-10-24 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (00:00 UTC). * 2011-10-31 (Monday): Internet Draft final submission cut-off by 17:00 PT (00:00 UTC). Thanks, Giles and Nabil --Boundary_(ID_58YMG1BTfhFKq/dWTfPGbQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi Nabil,

 <= /p>

I would like to present t= wo drafts in L2VPN. Both drafts are new and informational.

 <= /p>

Draft-yong-trill-trill-o-= mpls-00,   Lucy Yong, 5min

Draft-yong-l2vpn-spb-o-mp= ls-00,  Lucy Yong, 5min

 <= /p>

Very sorry for the late n= otice. I was on trip last week and e-mails piles up. Please give slots to p= resent these.

 <= /p>

Thanks,=

Lucy

 <= /p>

From: l2vpn-bo= unces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Bitar, Nabil N
Sent: Sunday, October 23, 2011 5:53 PM
To: l2vpn@ietf.org
Cc: Thomas Narten; Giles Heron; nvo3@ietf.org
Subject: L2VPN Agenda Slot Call for IETF 82 - Taipei

 

Hi,
Please let us know if you have a time-slot= request for the L2VPN sessions at IETF 82– Taipei. Please, email us = your request by Sunday October 30, 2011 along with the following informatio= n:
1) Draft title
2) Presenter name
3) Requested duration

Please remember that we have the following sessions as previously com= municated

 

    l2vpn Ses= sion 1 (2 hours)

    Monday, Afternoon Session I 1300-1500=

    Room Name: 201 ABC<= /p>

  

    l2vpn Session 2 (2.5 hours)

    Thursday, Morning Session I 0900-1130=

    Room Name: 3F Banquet

 

Please note that the main priority in the first session on Monday wil= l be given to drafts that are clearly within the scope of the current L2VPN charter . 

 

The second session on Thursday will be mainly focused on discussing a= nd defining the problem that new drafts related to providing a layer2 service in a Data center environment are trying to address. There= have been email exchanges on that. For some, it may be known as NV03 work.= We will be co-ordinating/deciding on what will be presented in that sessio= n with the focus as stated in mind. 


Following are additional  key dates t= o remember :

  • 2011-10-24 (Mo= nday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (00:00 UTC= ).
  • 2011-10-31 (Monday): Internet Dr= aft final submission cut-off by 17:00 PT (00:00 UTC).


Thanks,
Giles and Nabil

--Boundary_(ID_58YMG1BTfhFKq/dWTfPGbQ)-- From lucy.yong@huawei.com Wed Nov 2 08:22:26 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 464F921F8F36; Wed, 2 Nov 2011 08:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kANuJUyWvWGi; Wed, 2 Nov 2011 08:22:24 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 9672421F8F42; Wed, 2 Nov 2011 08:22:24 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LU100DHUH2ZEU@usaga02-in.huawei.com>; Wed, 02 Nov 2011 10:16:11 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LU100JHBH2Z3J@usaga02-in.huawei.com>; Wed, 02 Nov 2011 10:16:11 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 02 Nov 2011 08:16:12 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Wed, 02 Nov 2011 08:16:00 -0700 Date: Wed, 02 Nov 2011 15:16:00 +0000 From: Lucy yong Subject: RE: L2VPN Agenda Slot Call for IETF 82 - Taipei X-Originating-IP: [10.192.11.76] To: Lucy yong , "Bitar, Nabil N" , "l2vpn@ietf.org" Message-id: <2691CE0099834E4A9C5044EEC662BB9D118D685B@dfweml505-mbx> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_BsgiA3KB+jswcrSSZl+WmA)" Content-language: en-US Accept-Language: en-US Thread-topic: L2VPN Agenda Slot Call for IETF 82 - Taipei Thread-index: AcyR1ogbDHaJgFPbQg+vurpVXnT+0wHmnFXgAABJ4hA= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Cc: Thomas Narten , Giles Heron , "nvo3@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Nov 2011 15:22:26 -0000 --Boundary_(ID_BsgiA3KB+jswcrSSZl+WmA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Sorry, one mistake in last e-mail. It should be. Draft-mack-crane-l2von-sbp-o-mpls, Lucy Yong, 5min Lucy From: Lucy yong Sent: Wednesday, November 02, 2011 10:12 AM To: 'Bitar, Nabil N'; l2vpn@ietf.org Cc: Thomas Narten; Giles Heron; nvo3@ietf.org Subject: RE: L2VPN Agenda Slot Call for IETF 82 - Taipei Hi Nabil, I would like to present two drafts in L2VPN. Both drafts are new and informational. Draft-yong-trill-trill-o-mpls-00, Lucy Yong, 5min Draft-yong-l2vpn-spb-o-mpls-00, Lucy Yong, 5min Very sorry for the late notice. I was on trip last week and e-mails piles up. Please give slots to present these. Thanks, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Bitar, Nabil N Sent: Sunday, October 23, 2011 5:53 PM To: l2vpn@ietf.org Cc: Thomas Narten; Giles Heron; nvo3@ietf.org Subject: L2VPN Agenda Slot Call for IETF 82 - Taipei Hi, Please let us know if you have a time-slot request for the L2VPN sessions at IETF 82- Taipei. Please, email us your request by Sunday October 30, 2011 along with the following information: 1) Draft title 2) Presenter name 3) Requested duration Please remember that we have the following sessions as previously communicated l2vpn Session 1 (2 hours) Monday, Afternoon Session I 1300-1500 Room Name: 201 ABC l2vpn Session 2 (2.5 hours) Thursday, Morning Session I 0900-1130 Room Name: 3F Banquet Please note that the main priority in the first session on Monday will be given to drafts that are clearly within the scope of the current L2VPN charter . The second session on Thursday will be mainly focused on discussing and defining the problem that new drafts related to providing a layer2 service in a Data center environment are trying to address. There have been email exchanges on that. For some, it may be known as NV03 work. We will be co-ordinating/deciding on what will be presented in that session with the focus as stated in mind. Following are additional key dates to remember : * 2011-10-24 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (00:00 UTC). * 2011-10-31 (Monday): Internet Draft final submission cut-off by 17:00 PT (00:00 UTC). Thanks, Giles and Nabil --Boundary_(ID_BsgiA3KB+jswcrSSZl+WmA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Sorry, one mistake in las= t e-mail. It should be.

 <= /p>

Draft-mack-crane-l2von-sb= p-o-mpls, Lucy Yong, 5min

 <= /p>

Lucy

 <= /p>

From: Lucy yon= g
Sent: Wednesday, November 02, 2011 10:12 AM
To: 'Bitar, Nabil N'; l2vpn@ietf.org
Cc: Thomas Narten; Giles Heron; nvo3@ietf.org
Subject: RE: L2VPN Agenda Slot Call for IETF 82 - Taipei<= /span>

 

Hi Nabil,

 <= /p>

I would like to present t= wo drafts in L2VPN. Both drafts are new and informational.

 <= /p>

Draft-yong-trill-trill-o-= mpls-00,   Lucy Yong, 5min

Draft-yong-l2vpn-spb-o-mp= ls-00,  Lucy Yong, 5min

 <= /p>

Very sorry for the late n= otice. I was on trip last week and e-mails piles up. Please give slots to p= resent these.

 <= /p>

Thanks,=

Lucy

 <= /p>

From: l2vpn-bo= unces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Bitar, Nabil N
Sent: Sunday, October 23, 2011 5:53 PM
To: l2vpn@ietf.org
Cc: Thomas Narten; Giles Heron; nvo3@ietf.org
Subject: L2VPN Agenda Slot Call for IETF 82 - Taipei

 

Hi,
Please let us know if you have a time-slot= request for the L2VPN sessions at IETF 82– Taipei. Please, email us = your request by Sunday October 30, 2011 along with the following informatio= n:
1) Draft title
2) Presenter name
3) Requested duration

Please remember that we have the following sessions as previously com= municated

 

    l2vpn Ses= sion 1 (2 hours)

    Monday, Afternoon Session I 1300-1500=

    Room Name: 201 ABC<= /p>

  

    l2vpn Session 2 (2.5 hours)

    Thursday, Morning Session I 0900-1130=

    Room Name: 3F Banquet

 

Please note that the main priority in the first session on Monday wil= l be given to drafts that are clearly within the scope of the current L2VPN charter . 

 

The second session on Thursday will be mainly focused on discussing a= nd defining the problem that new drafts related to providing a layer2 service in a Data center environment are trying to address. There= have been email exchanges on that. For some, it may be known as NV03 work.= We will be co-ordinating/deciding on what will be presented in that sessio= n with the focus as stated in mind. 


Following are additional  key dates t= o remember :

  • 2011-10-24 (Mo= nday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PT (00:00 UTC= ).
  • 2011-10-31 (Monday): Internet Dr= aft final submission cut-off by 17:00 PT (00:00 UTC).


Thanks,
Giles and Nabil

--Boundary_(ID_BsgiA3KB+jswcrSSZl+WmA)-- From giles.heron@gmail.com Thu Nov 3 17:30:42 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B02C1F0CCF for ; Thu, 3 Nov 2011 17:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atY9Rp5UxP7R for ; Thu, 3 Nov 2011 17:30:41 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 16B651F0C59 for ; Thu, 3 Nov 2011 17:30:37 -0700 (PDT) Received: by wyg30 with SMTP id 30so2121496wyg.31 for ; Thu, 03 Nov 2011 17:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:mime-version:content-type:content-transfer-encoding; bh=c/hNx4SubyH/c/GBN23PjPlQSNhNi82k11D93Upv78E=; b=p5xLDISuGpXDYIeHnbvdjNPpsboiXWa/DP5XOr6RxjiDqfdBaQMX2GZMBQCKBBPcOU xQy93ogTthSrvOFNUm9L8Rvp++b47cS4Qbx5ouO/twnuHjnDMUbfp6txubsuu70ppp/G F/57ujgKRpWd58dUkjv5JZtzT8HRprgbuwCwM= Received: by 10.216.80.86 with SMTP id j64mr2156324wee.85.1320366637195; Thu, 03 Nov 2011 17:30:37 -0700 (PDT) Received: from [10.61.102.26] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id y38sm13191099wbm.2.2011.11.03.17.30.35 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 Nov 2011 17:30:36 -0700 (PDT) User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Fri, 04 Nov 2011 00:30:33 +0000 Subject: Draft L2VPN Agenda for IETF82 From: Giles Heron To: Message-ID: Thread-Topic: Draft L2VPN Agenda for IETF82 Thread-Index: AcyaiPaTZ05wMU9EVUWCr1VkOln5tw== Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 00:30:42 -0000 The draft L2VPN WG agenda has now been posted: http://www.ietf.org/proceedings/82/agenda/l2vpn.txt Nabil and Giles From thomas.morin@orange.com Fri Nov 4 07:11:09 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3755B21F8C5E for ; Fri, 4 Nov 2011 07:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuVE8qVjKOWZ for ; Fri, 4 Nov 2011 07:11:08 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8A521F8B64 for ; Fri, 4 Nov 2011 07:11:08 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AF33AB58005 for ; Fri, 4 Nov 2011 15:21:11 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id AAA08858001 for ; Fri, 4 Nov 2011 15:21:11 +0100 (CET) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Nov 2011 15:11:07 +0100 Received: from [10.193.71.23] ([10.193.71.23]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Nov 2011 15:11:07 +0100 Message-ID: <4EB3F285.40709@orange.com> Date: Fri, 04 Nov 2011 15:11:17 +0100 From: Thomas Morin Organization: France Telecom Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: l2vpn@ietf.org Subject: Re: WG adoption of draft-sajassi-raggarwa-l2vpn-evpn-req-01 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 04 Nov 2011 14:11:07.0179 (UTC) FILETIME=[986F1FB0:01CC9AFB] X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2011 14:11:09 -0000 Support! (I've read the document and find it is a solid basis for Ethernet-VPN work.) -Thomas Giles Heron a écrit : > This is a request to gauge consensus as to whether: > > http://tools.ietf.org/html/draft-sajassi-raggarwa-l2vpn-evpn-req-01 > > should be accepted as an L2VPN WG draft. > > Now that we've adopted the new charter E-VPN is in scope, and we have a > milestone item to submit a requirements draft for E-VPN to IESG by July > 2012. If you think this draft is a good starting point for those > requirements then please reply indicating your support for the draft. If > not then please reply giving some reasons why you think this draft shouldn't > be adopted - which we can then debate. > > Please respond by Friday 4th of November. > > Thanks! > > Giles > > From giles.heron@gmail.com Mon Nov 7 02:09:27 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2772421F8A58 for ; Mon, 7 Nov 2011 02:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56VOsrzHa+Jp for ; Mon, 7 Nov 2011 02:09:26 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5FCBF21F8ABB for ; Mon, 7 Nov 2011 02:09:26 -0800 (PST) Received: by wwi36 with SMTP id 36so4590294wwi.13 for ; Mon, 07 Nov 2011 02:09:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; bh=eQJUOTo/+WY1P5Ix0KoObCqd9K+rMOZAR3s59s98UR8=; b=GKwe7v+OCIqU/7fSed3h+TDxe6ExUsqAIamopb9p6r+AE+/XoU8lyYQOPvhqoA+iNe DN5a+rw6U7rPlZHBHLCbImV7nkv3TXjqnh7NZKSvEWvAS8BtDKxoMacVpMWYlUQCL7LN sG/YuuSOWOCUq/JxB3njsJSMq8zDIjT4g0taY= Received: by 10.180.75.204 with SMTP id e12mr7269559wiw.61.1320660565023; Mon, 07 Nov 2011 02:09:25 -0800 (PST) Received: from [10.55.80.36] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id v10sm424800wiy.23.2011.11.07.02.09.22 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Nov 2011 02:09:23 -0800 (PST) User-Agent: Microsoft-Entourage/12.31.0.110725 Date: Mon, 07 Nov 2011 10:09:22 +0000 Subject: Re: WG adoption of draft-sajassi-raggarwa-l2vpn-evpn-req-01 From: Giles Heron To: Message-ID: Thread-Topic: WG adoption of draft-sajassi-raggarwa-l2vpn-evpn-req-01 Thread-Index: AcyQBRR+BnU8yNibqEe6U5jsOUZ2XwNMD1rJ In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 10:09:27 -0000 Hi everyone, Just a quick note to say that I think we have good consensus to progress this draft as a WG doc. Florin raised a good point about datacenter requirements during the last call, and that's something we may want to discuss during and after Taipei - do we want to focus E-VPN on inter-datacenter requirements, or do we want to include intra-datacenter requirements? Authors - please go ahead and reissue this as: draft-ietf-l2vpn-evpn-req-00 You'll probably need to wait now until after Taipei because of the draft cut-off. Thanks! Giles On 21/10/2011 16:21, "Giles Heron" wrote: > This is a request to gauge consensus as to whether: > > http://tools.ietf.org/html/draft-sajassi-raggarwa-l2vpn-evpn-req-01 > > should be accepted as an L2VPN WG draft. > > Now that we've adopted the new charter E-VPN is in scope, and we have a > milestone item to submit a requirements draft for E-VPN to IESG by July > 2012. If you think this draft is a good starting point for those > requirements then please reply indicating your support for the draft. If > not then please reply giving some reasons why you think this draft shouldn't > be adopted - which we can then debate. > > Please respond by Friday 4th of November. > > Thanks! > > Giles > > From N.Leymann@telekom.de Mon Nov 7 02:56:22 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4133821F8449 for ; Mon, 7 Nov 2011 02:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LeulRkuUwOn for ; Mon, 7 Nov 2011 02:56:21 -0800 (PST) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by ietfa.amsl.com (Postfix) with ESMTP id 8489A21F86C3 for ; Mon, 7 Nov 2011 02:56:20 -0800 (PST) Received: from he101250.emea1.cds.t-internal.com ([10.125.92.153]) by tcmail81.telekom.de with ESMTP/TLS/AES128-SHA; 07 Nov 2011 11:56:19 +0100 Received: from HE111543.emea1.cds.t-internal.com ([169.254.4.54]) by HE101250.emea1.cds.t-internal.com ([fe80::e439:4046:12e2:e37%15]) with mapi; Mon, 7 Nov 2011 11:56:18 +0100 From: To: , Date: Mon, 7 Nov 2011 11:56:17 +0100 Subject: AW: WG adoption of draft-sajassi-raggarwa-l2vpn-evpn-req-01 Thread-Topic: WG adoption of draft-sajassi-raggarwa-l2vpn-evpn-req-01 Thread-Index: AcyQBRR+BnU8yNibqEe6U5jsOUZ2XwNNkmng Message-ID: <9762ACF04FA26B4388476841256BDE0201159EEEA66A@HE111543.emea1.cds.t-internal.com> References: In-Reply-To: Accept-Language: de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Nov 2011 10:56:22 -0000 Hi, I know, I'm to late (at least in order to meet the official time line) but = not to late to express my opinion regarding the draft. I also support the document becoming a WG document. I think it provides a g= ood set of requirements as basis for the ongoing E-VPN work moving towards = a commonly supported solution. regards Nic -----Urspr=FCngliche Nachricht----- Von: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] Im Auftrag von = Giles Heron Gesendet: Freitag, 21. Oktober 2011 17:21 An: l2vpn@ietf.org Betreff: WG adoption of draft-sajassi-raggarwa-l2vpn-evpn-req-01 This is a request to gauge consensus as to whether: http://tools.ietf.org/html/draft-sajassi-raggarwa-l2vpn-evpn-req-01 should be accepted as an L2VPN WG draft. Now that we've adopted the new charter E-VPN is in scope, and we have a milestone item to submit a requirements draft for E-VPN to IESG by July 2012. If you think this draft is a good starting point for those requirements then please reply indicating your support for the draft. If not then please reply giving some reasons why you think this draft shouldn'= t be adopted - which we can then debate. Please respond by Friday 4th of November. Thanks! Giles From aldrin.isaac@gmail.com Mon Nov 7 18:54:21 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC7E11E80B9 for ; Mon, 7 Nov 2011 18:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MncDbxm+oxLH for ; Mon, 7 Nov 2011 18:54:20 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3B82F11E80D5 for ; Mon, 7 Nov 2011 18:54:20 -0800 (PST) Received: by vws5 with SMTP id 5so35604vws.31 for ; Mon, 07 Nov 2011 18:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=ftkLlwi7qfuagUuZMIws1WgFBsSd/ekEOfqRbdYb2hQ=; b=egZAbSS8dUOzbM2whVM9G/Zgxr1T5j4SZwM6uroYeCTHaEKEUQVcAXNC9vK89on8zW tP62JuYGGaYF8I1zff6Dkz2GqGwSUGLfQHVL90huvZxvftOi157BXQ6gD3fnEvqNhdOG +UV9GYjiV13NZypQXHRAQ7Oon1TG5yi8KAZdo= Received: by 10.52.26.47 with SMTP id i15mr27302816vdg.0.1320720859702; Mon, 07 Nov 2011 18:54:19 -0800 (PST) Received: from mymac.home (ool-44c1c730.dyn.optonline.net. [68.193.199.48]) by mx.google.com with ESMTPS id cp16sm71029vdb.20.2011.11.07.18.54.16 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 07 Nov 2011 18:54:16 -0800 (PST) Subject: Re: WG adoption of draft-sajassi-raggarwa-l2vpn-evpn-req-01 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Aldrin Isaac In-Reply-To: Date: Mon, 7 Nov 2011 21:54:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Giles Heron X-Mailer: Apple Mail (2.1251.1) Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 02:54:21 -0000 I have inter AND intra site scenarios that I expect to leverage E-VPN = for as part of a unified wide area data center architecture. This is an = original requirement at the inception of E-VPN. Please keep intra-DC = part of the requirements. On Nov 7, 2011, at 5:09 AM, Giles Heron wrote: > Hi everyone, >=20 > Just a quick note to say that I think we have good consensus to = progress > this draft as a WG doc. >=20 > Florin raised a good point about datacenter requirements during the = last > call, and that's something we may want to discuss during and after = Taipei - > do we want to focus E-VPN on inter-datacenter requirements, or do we = want to > include intra-datacenter requirements? >=20 > Authors - please go ahead and reissue this as: >=20 > draft-ietf-l2vpn-evpn-req-00 >=20 > You'll probably need to wait now until after Taipei because of the = draft > cut-off. >=20 > Thanks! >=20 > Giles >=20 > On 21/10/2011 16:21, "Giles Heron" wrote: >=20 >> This is a request to gauge consensus as to whether: >>=20 >> http://tools.ietf.org/html/draft-sajassi-raggarwa-l2vpn-evpn-req-01 >>=20 >> should be accepted as an L2VPN WG draft. >>=20 >> Now that we've adopted the new charter E-VPN is in scope, and we have = a >> milestone item to submit a requirements draft for E-VPN to IESG by = July >> 2012. If you think this draft is a good starting point for those >> requirements then please reply indicating your support for the draft. = If >> not then please reply giving some reasons why you think this draft = shouldn't >> be adopted - which we can then debate. >>=20 >> Please respond by Friday 4th of November. >>=20 >> Thanks! >>=20 >> Giles >>=20 >>=20 >=20 >=20 From nabil.n.bitar@verizon.com Mon Nov 7 21:41:58 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C8B11E80F9; Mon, 7 Nov 2011 21:41:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.907 X-Spam-Level: X-Spam-Status: No, score=-2.907 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60V5Aa6djadN; Mon, 7 Nov 2011 21:41:57 -0800 (PST) Received: from fldsmtpe02.verizon.com (fldsmtpe02.verizon.com [140.108.26.141]) by ietfa.amsl.com (Postfix) with ESMTP id B33CC11E80F4; Mon, 7 Nov 2011 21:41:56 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe02.verizon.com with ESMTP; 08 Nov 2011 05:41:55 +0000 From: "Bitar, Nabil N" X-IronPort-AV: E=Sophos;i="4.69,475,1315180800"; d="scan'208,217";a="175610936" Received: from fldp1lumxc7hb02.verizon.com (HELO FLDP1LUMXC7HB02.us.one.verizon.com) ([166.68.75.85]) by fldsmtpi03.verizon.com with ESMTP; 08 Nov 2011 05:41:55 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([169.254.3.102]) by FLDP1LUMXC7HB02.us.one.verizon.com ([166.68.75.85]) with mapi; Tue, 8 Nov 2011 00:41:55 -0500 To: "l3vpn@ietf.org" , "l2vpn@ietf.org" Date: Tue, 8 Nov 2011 00:41:54 -0500 Subject: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-Topic: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-Index: Acyd2R8rhSQNYlfHQ16DQ3Td7RyeUQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CADE2A322CAF3nabilnbitarverizoncom_" MIME-Version: 1.0 Cc: Sagessi , "mircea.pisica@bt.com" , "Luyuan Fang \(lufang\)" , "y.ikejiri@ntt.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 05:41:58 -0000 --_000_CADE2A322CAF3nabilnbitarverizoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We had submitted the following draft on vpn applicability for data center. = Your input on the draft is appreciated in light of some of the ongoing disc= ussion. The draft is targeted for l3vpn and l2vpn. Here is the link: http://tools.ietf.org/html/draft-bitar-datacenter-vpn-applicability-01 Abstract Cloud Computing has been attracting a lot of attention from the networking industry. Some of the most publicized requirements are related to the evolution of the Cloud Networking Infrastructure to accommodate a large number of tenants, efficient network utilization, scalable loop avoidance, and Virtual Machine Mobility. This draft describes a framework for cloud networking, highlighting the applicability of existing work in various IETF Working Groups (e.g., RFCs and drafts developed in IETF L2VPN and L3VPN Working Groups) to cloud networking, and the gaps and problems that need to be further addressed. That is, the goal is to understand what may be re-used from the current protocols and call out requirements specific to the Cloud space that need to be addressed by new standardization work with proposed solutions in certain cases. Thanks, Nabil --_000_CADE2A322CAF3nabilnbitarverizoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
We had sub= mitted the following draft on vpn applicability for data center. Your input= on the draft is appreciated in light of some of the ongoing discussion. Th= e draft is targeted for l3vpn and l2vpn.
Here is the link: <= /div>


Abstract

   Cloud Computing has been attracting a lot of attention from the
   networking industry. Some of the most publicized requirements are
   related to the evolution of the Cloud Networking Infrastructure to
   accommodate a large number of tenants, efficient network utilization,
   scalable loop avoidance, and Virtual Machine Mobility.

   This draft describes a framework for cloud networking, highlighting
   the applicability of existing work in various IETF Working Groups
   (e.g., RFCs and drafts developed in IETF L2VPN and L3VPN Working
   Groups) to cloud networking, and the gaps and problems that need to
   be further addressed. That is, the goal is to understand what may be
   re-used from the current protocols and call out requirements specific
   to the Cloud space that need to be addressed by new standardization
   work with proposed solutions in certain cases.

Thanks,=

Nabil
--_000_CADE2A322CAF3nabilnbitarverizoncom_-- From xuxiaohu@huawei.com Mon Nov 7 23:55:05 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E141921F8B45; Mon, 7 Nov 2011 23:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.687 X-Spam-Level: X-Spam-Status: No, score=-1.687 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C+Fv+wWXLbTo; Mon, 7 Nov 2011 23:55:05 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 83E8E21F8B72; Mon, 7 Nov 2011 23:55:04 -0800 (PST) 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 <0LUC00EXG0KTBP@szxga03-in.huawei.com>; Tue, 08 Nov 2011 15:53:18 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUC00KLN0K69B@szxga03-in.huawei.com>; Tue, 08 Nov 2011 15:53:17 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEV09745; Tue, 08 Nov 2011 15:53:17 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 08 Nov 2011 15:53:14 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0270.001; Tue, 08 Nov 2011 15:53:09 +0800 Date: Tue, 08 Nov 2011 07:53:09 +0000 From: Xuxiaohu Subject: re: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt In-reply-to: X-Originating-IP: [10.108.4.59] To: "Bitar, Nabil N" , "l3vpn@ietf.org" , "l2vpn@ietf.org" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74774D@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_cqqGcxB/wl2CapfjX1xEoA)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-index: Acyd2R8rhSQNYlfHQ16DQ3Td7RyeUQAC+Spw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: Cc: "Luyuan Fang \(lufang\)" , Sagessi , "y.ikejiri@ntt.com" , "mircea.pisica@bt.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 07:55:06 -0000 --Boundary_(ID_cqqGcxB/wl2CapfjX1xEoA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgTmFiaWwsDQoNCkl0oa9zIGEgdmVyeSBjb21wcmVoZW5zaXZlIGRvYy4NCg0KU29tZSBjb21t b25zOg0KDQoxoaIgIEluIHNlY3Rpb24gNi4xLCBpdCBzYWlkOiChsEFzIHRoZSBudW1iZXIgb2Yg dGVuYW50cyBpbiBpbmRpdmlkdWFsIFZMQU4gaXNsYW5kcyBzdXJwYXNzZXMgNEssIHRoZSBvcGVy YXRvciBjb3VsZCBwdXNoIFZQTFMgZGVwbG95bWVudCBkZWVwZXIgaW4gdGhlIERDIG5ldHdvcmuh rS4gVGhlIFRvUiBhbmQgREMgY29yZSBlbGVtZW50cyBuZWVkIHRvIGJlIE1QTFMgZW5hYmxlZCB3 aXRoIGV4aXN0aW5nIFZQTFMgc29sdXRpb25zobEsIElNSE8sIERDIGNvcmUgc3dpdGNoZXMgZG9u oa90IG5lZWQgdG8gYmUgTVBMUyBlbmFibGVkIHNpbmNlIElQIGJhc2VkIHR1bm5lbCBpcyBhbHNv IGF2YWlsYWJsZS4NCg0KMqGiICBTdGlsbCBpbiBzZWN0aW9uIDYuMSwgaXQgc2FpZDogobEgoa1I b3dldmVyLCB0aGlzIG1vZGVsIGRvZXMgbm90IHNvbHZlIHRoZSBNQUMgZXhwbG9zaW9uIGlzc3Vl IGFzIFRvUnMgc3RpbGwgbmVlZCB0byBsZWFybiBWTSBNQUMgYWRkcmVzc2VzLqGxIEhvd2V2ZXIs IGluIHNlY3Rpb24gNi4yLjEsIGl0IHNhaWQ6obGhrUFsdGVybmF0aXZlbHksIHRoZSBQQkIgZW5j YXBzdWxhdGlvbiBjYW4gYmUgZG9uZSBhdCB0aGUgVG9SLqGxICBJdCBpcyBjb25mdXNlZCBzaW5j ZSBwZXJmb3JtaW5nIFBCQiBlbmNhcHN1bGF0aW9uIGF0IHRoZSBUb1Igd291bGQgbm90IGFsbGV2 aWF0ZSB0aGUgTUFDLWxlYXJuaW5nIGJ1cmRlbiBvbiB0aGF0IFRvUi4NCg0KM6GiICBJbiA2LjIu Ni4yLiBQQkJOIGluIFZTdywgTDJWUE4gaW4gdGhlIFRvUiwgaXQgc2FpZDqhsSBUaGUgcHJvY2Vk dXJlcyBmcm9tIHRoZSBwcmV2aW91cyBzZWN0aW9uIGFyZSB1c2VkIGF0IHRoZSBWU3c6IFBCQiBl bmNhcHN1bGF0aW9uIGFuZCBFdGhlcm5ldCBCVkxBTnMgY2FuIGJlIHVzZWQgb24gdGhlIFZTdyB1 cGxpbmsuIEwyVlBOIGluZnJhc3RydWN0dXJlIGlzIHJlcGxhY2luZyB0aGUgQlZMQU4gYXQgdGhl IFRvUiBlbmFibGluZyB0aGUgdXNlIG9mIElQIChHUkUgb3IgTDJUUCkgb3IgTVBMUyB0dW5uZWxp bmcuICBMMiBuZXR3b3JraW5nIHN0aWxsIGhhcyB0aGUgc2FtZSBjb250cm9sIHBsYW5lIGNob2lj ZXM6IElTLUlTIFs4MDIuMWFxXSBhbmQvb3IgQkdQIFtQQkItRVZQTl0sIGluZGVwZW5kZW50bHkg ZnJvbSB0aGUgdHVubmVsaW5nIGNob2ljZS6hsSBTaW5jZSBQQkIgZW5jYXBzdWxhdGlvbiBoYXMg YWxyZWFkeSBiZWVuIGRvbmUgb24gdGhlIFZTdywgd2h5IGRvIHdlIHN0aWxsIG5lZWQgdG8gcnVu IDgwMi4xYXEgYW5kIFBCQi1FVlBOIHdpdGggYW5vdGhlciBQQkIgZW5jYXBzdWxhdGlvbiBsYXll cj8gQ2Fuoa90IHdlIHNpbXBseSB1c2UgYW55IEwyVlBOIHRlY2hub2xvZ3ksIGUuZy4sIFZQTFMu IEluIGFkZGl0aW9uLCBub3RlIHRoYXQgaW4gRmlndXJlIDUsIGl0IHNhaWQgobBpbnRyYS1EQyBM MlZQTiBvdmVyIElQIG9yIE1QTFMgdHVubmVsaW5nobEuDQoNCg0KQmVzdCByZWdhcmRzLA0KWGlh b2h1DQoNCreivP7IyzogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5j ZXNAaWV0Zi5vcmddILT6se0gQml0YXIsIE5hYmlsIE4NCreiy83KsbzkOiAyMDExxOoxMdTCOMjV IDEzOjQyDQrK1bz+yMs6IGwzdnBuQGlldGYub3JnOyBsMnZwbkBpZXRmLm9yZw0Ks63LzTogU2Fn ZXNzaTsgbWlyY2VhLnBpc2ljYUBidC5jb207IEx1eXVhbiBGYW5nIChsdWZhbmcpOyB5LmlrZWpp cmlAbnR0LmNvbQ0K1vfM4jogWW91ciBpbnB1dCBvbiB0aGUgZm9sbG93aW5nIGRyYWZ0IGlzIGFw cHJlY2lhdGVkOiBkcmFmdC1iaXRhci1kYXRhY2VudGVyLXZwbi1hcHBsaWNhYmlsaXR5LTAxLnR4 dA0KDQpIaSwNCldlIGhhZCBzdWJtaXR0ZWQgdGhlIGZvbGxvd2luZyBkcmFmdCBvbiB2cG4gYXBw bGljYWJpbGl0eSBmb3IgZGF0YSBjZW50ZXIuIFlvdXIgaW5wdXQgb24gdGhlIGRyYWZ0IGlzIGFw cHJlY2lhdGVkIGluIGxpZ2h0IG9mIHNvbWUgb2YgdGhlIG9uZ29pbmcgZGlzY3Vzc2lvbi4gVGhl IGRyYWZ0IGlzIHRhcmdldGVkIGZvciBsM3ZwbiBhbmQgbDJ2cG4uDQpIZXJlIGlzIHRoZSBsaW5r Og0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaXRhci1kYXRhY2VudGVyLXZw bi1hcHBsaWNhYmlsaXR5LTAxDQoNCg0KQWJzdHJhY3QNCg0KDQoNCiAgIENsb3VkIENvbXB1dGlu ZyBoYXMgYmVlbiBhdHRyYWN0aW5nIGEgbG90IG9mIGF0dGVudGlvbiBmcm9tIHRoZQ0KDQogICBu ZXR3b3JraW5nIGluZHVzdHJ5LiBTb21lIG9mIHRoZSBtb3N0IHB1YmxpY2l6ZWQgcmVxdWlyZW1l bnRzIGFyZQ0KDQogICByZWxhdGVkIHRvIHRoZSBldm9sdXRpb24gb2YgdGhlIENsb3VkIE5ldHdv cmtpbmcgSW5mcmFzdHJ1Y3R1cmUgdG8NCg0KICAgYWNjb21tb2RhdGUgYSBsYXJnZSBudW1iZXIg b2YgdGVuYW50cywgZWZmaWNpZW50IG5ldHdvcmsgdXRpbGl6YXRpb24sDQoNCiAgIHNjYWxhYmxl IGxvb3AgYXZvaWRhbmNlLCBhbmQgVmlydHVhbCBNYWNoaW5lIE1vYmlsaXR5Lg0KDQoNCg0KICAg VGhpcyBkcmFmdCBkZXNjcmliZXMgYSBmcmFtZXdvcmsgZm9yIGNsb3VkIG5ldHdvcmtpbmcsIGhp Z2hsaWdodGluZw0KDQogICB0aGUgYXBwbGljYWJpbGl0eSBvZiBleGlzdGluZyB3b3JrIGluIHZh cmlvdXMgSUVURiBXb3JraW5nIEdyb3Vwcw0KDQogICAoZS5nLiwgUkZDcyBhbmQgZHJhZnRzIGRl dmVsb3BlZCBpbiBJRVRGIEwyVlBOIGFuZCBMM1ZQTiBXb3JraW5nDQoNCiAgIEdyb3VwcykgdG8g Y2xvdWQgbmV0d29ya2luZywgYW5kIHRoZSBnYXBzIGFuZCBwcm9ibGVtcyB0aGF0IG5lZWQgdG8N Cg0KICAgYmUgZnVydGhlciBhZGRyZXNzZWQuIFRoYXQgaXMsIHRoZSBnb2FsIGlzIHRvIHVuZGVy c3RhbmQgd2hhdCBtYXkgYmUNCg0KICAgcmUtdXNlZCBmcm9tIHRoZSBjdXJyZW50IHByb3RvY29s cyBhbmQgY2FsbCBvdXQgcmVxdWlyZW1lbnRzIHNwZWNpZmljDQoNCiAgIHRvIHRoZSBDbG91ZCBz cGFjZSB0aGF0IG5lZWQgdG8gYmUgYWRkcmVzc2VkIGJ5IG5ldyBzdGFuZGFyZGl6YXRpb24NCg0K ICAgd29yayB3aXRoIHByb3Bvc2VkIHNvbHV0aW9ucyBpbiBjZXJ0YWluIGNhc2VzLg0KDQoNClRo YW5rcywNCg0KTmFiaWwNCg== --Boundary_(ID_cqqGcxB/wl2CapfjX1xEoA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

Hi Nabil,<= o:p>

 = ;

It=A1=AFs = a very comprehensive doc.

 = ;

Some commo= ns:

1=A1=A2  In section 6.1, it said: =A1=B0As t=
he number of tenants in individual VLAN islands surpasses 4K, the operator =
could push VPLS deployment deeper in the DC network=A1=AD. The ToR and DC c=
ore elements need to be MPLS enabled with existing VPLS solutions=A1=B1, IM=
HO, DC core switches don=A1=AFt need to be MPLS enabled since IP based tunn=
el is also available.
2=A1=A2  Still in section 6.1, it said: =A1=
=B1 =A1=ADHowever, this model does not solve the MAC explosion issue as ToR=
s still need to learn VM MAC addresses.=A1=B1 However, in section 6.2.1, it=
 said:=A1=B1=A1=ADAlternatively, the PBB encapsulation can be done at the T=
oR.=A1=B1  It is confused since performing PBB encapsulation at the To=
R would not alleviate the MAC-learning burden on that ToR. 
3=A1=A2  In 6.2.=
6.2. PBBN in VSw, L2VPN in the ToR, it said:=A1=B1 The procedures fro=
m the previous section are used at the VSw: PBB encapsulation and Ethernet =
BVLANs can be used on the VSw uplink. L2VPN infrastructure is replacing the=
 BVLAN at the ToR enabling the use of IP (GRE or L2TP) or MPLS tunneling.&n=
bsp; L2 networking still has the same control plane choices: IS-IS [802.1aq=
] and/or BGP [PBB-EVPN], independently from the tunneling choice.=A1=B1 Sin=
ce PBB encapsulation has already been done on the VSw, why do we still need=
 to run 802.1aq and PBB-EVPN with another PBB encapsulation layer? Can=A1=
=AFt we simply use any L2VPN technology, e.g., VPLS. In addition, note that=
 in Figure 5, it said =A1=B0intra-DC L2VPN over IP or MPLS tunneling=A1=B1.=

=  

Best regar= ds,

Xiaohu

 = ;

=B7=A2=BC=FE=C8=CB: l2vpn-b= ounces@ietf.org [mailto:l2vpn-bounces@ietf.org] =B4=FA= =B1=ED Bitar, Nabil N
=B7=A2= =CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C28=C8=D5 13:42
=CA=D5=BC=FE=C8=CB: l3vpn@ietf.org; l2vpn@ietf.org
=B3=AD=CB=CD: Sagessi; mircea.pisica@bt.com; Luyuan Fang (lufang); y.ikejiri@ntt.com =D6=F7=CC=E2: Your input on the following draft is appreciated: draft-bitar-datacenter-= vpn-applicability-01.txt

 

Hi,

We had submi= tted the following draft on vpn applicability for data center. Your input o= n the draft is appreciated in light of some of the ongoing discussion. The draft is targeted for l3vpn and l2vpn.

Here is the = link: 

 <= /o:p>

 <= /o:p>

Abstract
 
   Cloud Computing has been attracting a=
 lot of attention from the
   networking industry. Some of the most=
 publicized requirements are
   related to the evolution of the Cloud=
 Networking Infrastructure to
   accommodate a large number of tenants=
, efficient network utilization,
   scalable loop avoidance, and Virtual =
Machine Mobility.
 
   This draft describes a framework for =
cloud networking, highlighting
   the applicability of existing work in=
 various IETF Working Groups
   (e.g., RFCs and drafts developed in I=
ETF L2VPN and L3VPN Working
   Groups) to cloud networking, and the =
gaps and problems that need to
   be further addressed. That is, the go=
al is to understand what may be
   re-used from the current protocols an=
d call out requirements specific
   to the Cloud space that need to be ad=
dressed by new standardization
   work with proposed solutions in certa=
in cases.

 
Thanks,
Nabil
--Boundary_(ID_cqqGcxB/wl2CapfjX1xEoA)-- From xuxiaohu@huawei.com Tue Nov 8 01:41:59 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0792F21F8CC5; Tue, 8 Nov 2011 01:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.693 X-Spam-Level: X-Spam-Status: No, score=-1.693 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qppoG-hgNHou; Tue, 8 Nov 2011 01:41:58 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id AD92521F8CC4; Tue, 8 Nov 2011 01:41:57 -0800 (PST) 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 <0LUC003HP5J7D2@szxga04-in.huawei.com>; Tue, 08 Nov 2011 17:40:19 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUC00CQP5J6V0@szxga04-in.huawei.com>; Tue, 08 Nov 2011 17:40:19 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEX20235; Tue, 08 Nov 2011 17:39:52 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 08 Nov 2011 17:39:21 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Tue, 08 Nov 2011 17:39:15 +0800 Date: Tue, 08 Nov 2011 09:39:14 +0000 From: Xuxiaohu Subject: re: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt In-reply-to: X-Originating-IP: [10.108.4.59] To: "Bitar, Nabil N" , "l3vpn@ietf.org" , "l2vpn@ietf.org" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE7477A2@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_ajcU9sdPc9Yi7uJ41c3fGA)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-index: Acyd2R8rhSQNYlfHQ16DQ3Td7RyeUQAFQgBA X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: LbQp RpvY VwYt WDYs XiTN aUgq awRA clfy jLbR kfYn lpGT qGQT sBNe u4HK 01Uu 1HGw; 7; bAAyAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAbAAzAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAbAB1AGYAYQBuAGcAQABjAGkAcwBjAG8ALgBjAG8AbQA7AG0AaQByAGMAZQBhAC4AcABpAHMAaQBjAGEAQABiAHQALgBjAG8AbQA7AG4AYQBiAGkAbAAuAG4ALgBiAGkAdABhAHIAQAB2AGUAcgBpAHoAbwBuAC4AYwBvAG0AOwBzAGEAagBhAHMAcwBpAEAAYwBpAHMAYwBvAC4AYwBvAG0AOwB5AC4AaQBrAGUAagBpAHIAaQBAAG4AdAB0AC4AYwBvAG0A; Sosha1_v1; 7; {0532F2EF-C25D-480F-BF96-05B2C724DE96}; eAB1AHgAaQBhAG8AaAB1AEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Tue, 08 Nov 2011 09:53:11 GMT; cgBlADoAIABZAG8AdQByACAAaQBuAHAAdQB0ACAAbwBuACAAdABoAGUAIABmAG8AbABsAG8AdwBpAG4AZwAgAGQAcgBhAGYAdAAgAGkAcwAgAGEAcABwAHIAZQBjAGkAYQB0AGUAZAA6AAkAZAByAGEAZgB0AC0AYgBpAHQAYQByAC0AZABhAHQAYQBjAGUAbgB0AGUAcgAtAHYAcABuAC0AYQBwAHAAbABpAGMAYQBiAGkAbABpAHQAeQAtADAAMQAuAHQAeAB0AA== x-cr-puzzleid: {0532F2EF-C25D-480F-BF96-05B2C724DE96} X-CFilter-Loop: Reflected References: Cc: "Luyuan Fang \(lufang\)" , Sagessi , "y.ikejiri@ntt.com" , "mircea.pisica@bt.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 09:41:59 -0000 --Boundary_(ID_ajcU9sdPc9Yi7uJ41c3fGA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 DQoNCkhpLA0KDQpTb21lIGNvbW1lbnRzIGFib3V0IHBhdGggb3B0aW1pemF0aW9uOg0KDQoxo65J biBzZWN0aW9uIDUuNSwgIGl0IHNhaWQgobBJUC1iYXNlZCBmb3J3YXJkaW5nIHJlbGllcyBvbiB0 aGUgZGVzdGluYXRpb24gSVAgYWRkcmVzc6GtSG93ZXZlciwgd2hlbiBWTXMsIGFzIElQIGhvc3Rz IGFjcm9zcyBsYXllcjIgdmlydHVhbA0KICAgZG9tYWlucywgbmVlZCB0byBjb21tdW5pY2F0ZSB0 aGV5IHJlbHkgb24gdGhlIHVuZGVybHlpbmcgSVAgcm91dGluZyBpbmZyYXN0cnVjdHVyZS6hsSAg Q291bGQgeW91IGV4cGxhaW4gbW9yZSBhYm91dCChsGxheWVyMiB2aXJ0dWFsIGRvbWFpbnOhsT8N Cg0KMi4gICBJbiBzZWN0aW9uIDUuNSwgaXQgc2FpZCChsG9wdGltYWxpdHkgaW4gdHJhZmZpYyBm b3J3YXJkaW5nIHRvIGEgVk0gd2lsbCByZXF1aXJlIHJlYWNoYWJpbGl0eSB0byB0aGUgVk0gaG9z dCBhZGRyZXNzIHJhdGhlciB0aGFuIG9ubHkgdGhlIHN1Ym5ldC6hsSBJTUhPLCBwcm9wYWdhdGlu ZyBob3N0IHJvdXRlcyBmb3IgVk1zIGlzIG9ubHkgdXNlZnVsIGZvciBvcHRpbWl6aW5nIHRoZSBw YXRoIGZvciBWUE4gYWNjZXNzLCByYXRoZXIgdGhhbiBmb3IgSW50ZXJuZXQgYWNjZXNzIHNpbmNl IHByb3BhZ2F0aW5nIGhvc3Qgcm91dGUgdG8gdGhlIEludGVybmV0IHdpbGwgZGFtYWdlIHRoZSBJ bnRlcm5ldCByb3V0aW5nIHNjYWxhYmlsaXR5IHNlcmlvdXNseS4gIFRvIG9wdGltaXplIHRoZSBw YXRoIGZvciBJbnRlcm5ldCBhY2Nlc3MsICBJTUhPLCBETlMtYmFzZWQgR0xTQiBpcyBhIG1vcmUg cHJhY3RpY2FsIGFwcHJvYWNoIGluc3RlYWQuIFdpdGggdGhpcyBhcHByb2FjaCwgc2luY2UgdGhl IGNvbm5lY3Rpb25zIGVzdGFibGlzaGVkIGJlZm9yZSB0aGUgVk0gbW92ZW1lbnQgdXNlIHRoZSBv bGQgTkFUZWQgYWRkcmVzcyBvZiB0aGUgVk0sIHRoZSBpbmJvdW5kIHRyYWZmaWMgb2YgdGhvc2Ug Y29ubmVjdGlvbnMgd2lsbCBzdGlsbCB0cmF2ZWwgdGhyb3VnaCB0aGUgb2xkIGdhdGV3YXkgd2hl cmUgdGhlIFZNIHVzZWQgdG8gYmUgYXR0YWNoZWQuIEl0oa9zIGVhc3kgZm9yIHRoZSBvbGQgZ2F0 ZXdheSB0byBmb3J3YXJkIHRoZSB0cmFmZmljIGZ1cnRoZXIgdG8gdGhlIG5ldyBsb2NhdGlvbi4g SG93ZXZlciwgdGhlIGhhcmQgaXNzdWUgaXMgaG93IHRvIGd1YXJhbnRlZSB0aGUgb3V0Ym91bmQg dHJhZmZpYyBvZiB0aG9zZSBjb25uZWN0aW9ucyB0cmF2ZWwgdGhyb3VnaCB0aGUgc2FtZSBnYXRl d2F5IGFzIHRoZSBpbmJvdW5kIHRyYWZmaWMgZG9lcyAoaS5lLiwgcGF0aCBzeW1tZXRyeSkgaW4g dGhlIHNjZW5hcmlvIHdoZXJlIHN0YXRlZnVsIGRldmljZXMgc3VjaCBhcyBOQVRzLCBmaXJld2Fs bHMgZXRjLiBhcmUgZGVwbG95ZWQgYXQgdGhlIERDIGV4aXRzLg0KDQpCZXN0IHJlZ2FyZHMsDQpY aWFvaHUNCg0Kt6K8/sjLOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91 bmNlc0BpZXRmLm9yZ10gtPqx7SBCaXRhciwgTmFiaWwgTg0Kt6LLzcqxvOQ6IDIwMTHE6jEx1MI4 yNUgMTM6NDINCsrVvP7IyzogbDN2cG5AaWV0Zi5vcmc7IGwydnBuQGlldGYub3JnDQqzrcvNOiBT YWdlc3NpOyBtaXJjZWEucGlzaWNhQGJ0LmNvbTsgTHV5dWFuIEZhbmcgKGx1ZmFuZyk7IHkuaWtl amlyaUBudHQuY29tDQrW98ziOiBZb3VyIGlucHV0IG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQgaXMg YXBwcmVjaWF0ZWQ6IGRyYWZ0LWJpdGFyLWRhdGFjZW50ZXItdnBuLWFwcGxpY2FiaWxpdHktMDEu dHh0DQoNCkhpLA0KV2UgaGFkIHN1Ym1pdHRlZCB0aGUgZm9sbG93aW5nIGRyYWZ0IG9uIHZwbiBh cHBsaWNhYmlsaXR5IGZvciBkYXRhIGNlbnRlci4gWW91ciBpbnB1dCBvbiB0aGUgZHJhZnQgaXMg YXBwcmVjaWF0ZWQgaW4gbGlnaHQgb2Ygc29tZSBvZiB0aGUgb25nb2luZyBkaXNjdXNzaW9uLiBU aGUgZHJhZnQgaXMgdGFyZ2V0ZWQgZm9yIGwzdnBuIGFuZCBsMnZwbi4NCkhlcmUgaXMgdGhlIGxp bms6DQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJpdGFyLWRhdGFjZW50ZXIt dnBuLWFwcGxpY2FiaWxpdHktMDENCg0KDQpBYnN0cmFjdA0KDQoNCg0KICAgQ2xvdWQgQ29tcHV0 aW5nIGhhcyBiZWVuIGF0dHJhY3RpbmcgYSBsb3Qgb2YgYXR0ZW50aW9uIGZyb20gdGhlDQoNCiAg IG5ldHdvcmtpbmcgaW5kdXN0cnkuIFNvbWUgb2YgdGhlIG1vc3QgcHVibGljaXplZCByZXF1aXJl bWVudHMgYXJlDQoNCiAgIHJlbGF0ZWQgdG8gdGhlIGV2b2x1dGlvbiBvZiB0aGUgQ2xvdWQgTmV0 d29ya2luZyBJbmZyYXN0cnVjdHVyZSB0bw0KDQogICBhY2NvbW1vZGF0ZSBhIGxhcmdlIG51bWJl ciBvZiB0ZW5hbnRzLCBlZmZpY2llbnQgbmV0d29yayB1dGlsaXphdGlvbiwNCg0KICAgc2NhbGFi bGUgbG9vcCBhdm9pZGFuY2UsIGFuZCBWaXJ0dWFsIE1hY2hpbmUgTW9iaWxpdHkuDQoNCg0KDQog ICBUaGlzIGRyYWZ0IGRlc2NyaWJlcyBhIGZyYW1ld29yayBmb3IgY2xvdWQgbmV0d29ya2luZywg aGlnaGxpZ2h0aW5nDQoNCiAgIHRoZSBhcHBsaWNhYmlsaXR5IG9mIGV4aXN0aW5nIHdvcmsgaW4g dmFyaW91cyBJRVRGIFdvcmtpbmcgR3JvdXBzDQoNCiAgIChlLmcuLCBSRkNzIGFuZCBkcmFmdHMg ZGV2ZWxvcGVkIGluIElFVEYgTDJWUE4gYW5kIEwzVlBOIFdvcmtpbmcNCg0KICAgR3JvdXBzKSB0 byBjbG91ZCBuZXR3b3JraW5nLCBhbmQgdGhlIGdhcHMgYW5kIHByb2JsZW1zIHRoYXQgbmVlZCB0 bw0KDQogICBiZSBmdXJ0aGVyIGFkZHJlc3NlZC4gVGhhdCBpcywgdGhlIGdvYWwgaXMgdG8gdW5k ZXJzdGFuZCB3aGF0IG1heSBiZQ0KDQogICByZS11c2VkIGZyb20gdGhlIGN1cnJlbnQgcHJvdG9j b2xzIGFuZCBjYWxsIG91dCByZXF1aXJlbWVudHMgc3BlY2lmaWMNCg0KICAgdG8gdGhlIENsb3Vk IHNwYWNlIHRoYXQgbmVlZCB0byBiZSBhZGRyZXNzZWQgYnkgbmV3IHN0YW5kYXJkaXphdGlvbg0K DQogICB3b3JrIHdpdGggcHJvcG9zZWQgc29sdXRpb25zIGluIGNlcnRhaW4gY2FzZXMuDQoNCg0K VGhhbmtzLA0KDQpOYWJpbA0K --Boundary_(ID_ajcU9sdPc9Yi7uJ41c3fGA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

 = ;

 = ;

Hi,

 = ;

Some comme= nts about path optimization:

 = ;

1=A3= =AEIn section 5.5,  it said =A1=B0IP-based forwarding relies on the destina= tion IP address=A1=ADHowever, when VMs, as IP hosts across layer2 virtual

 &nbs= p; domains, need to communicate they rely on the underlying IP routing infr= astructure.=A1=B1  Could you explain more about =A1=B0layer2 virtual d= omains=A1=B1?  

 = ;

2. &n= bsp; In section 5.5, it said =A1=B0optimality in traffic forwarding to a VM= will require reachability to the VM host address rather than only the subn= et.=A1=B1 IMHO, propagating host routes for VMs is only useful for optimizing the pa= th for VPN access, rather than for Internet access since propagating host r= oute to the Internet will damage the Internet routing scalability seriously= .  To optimize the path for Internet access,  IMHO, DNS-based GLSB is a more practical approach instead. W= ith this approach, since the connections established before the VM movement= use the old NATed address of the VM, the inbound traffic of those connecti= ons will still travel through the old gateway where the VM used to be attached. It=A1=AFs easy for the old gatew= ay to forward the traffic further to the new location. However, the hard is= sue is how to guarantee the outbound traffic of those connections travel th= rough the same gateway as the inbound traffic does (i.e., path symmetry) in the scenario where stateful devices = such as NATs, firewalls etc. are deployed at the DC exits.

 = ;

Best regar= ds,

Xiaohu

 = ;

=B7=A2=BC=FE=C8=CB: l2vpn-b= ounces@ietf.org [mailto:l2vpn-bounces@ietf.org] =B4=FA= =B1=ED Bitar, Nabil N
=B7=A2= =CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C28=C8=D5 13:42
=CA=D5=BC=FE=C8=CB: l3vpn@ietf.org; l2vpn@ietf.org
=B3=AD=CB=CD: Sagessi; mircea.pisica@bt.com; Luyuan Fang (lufang); y.ikejiri@ntt.com =D6=F7=CC=E2: Your input on the following draft is appreciated: draft-bitar-datacenter-= vpn-applicability-01.txt

 

Hi,

We had submi= tted the following draft on vpn applicability for data center. Your input o= n the draft is appreciated in light of some of the ongoing discussion. The draft is targeted for l3vpn and l2vpn.

Here is the = link: 

 <= /o:p>

 <= /o:p>

Abstract
 
   Cloud Computing has been attracting a=
 lot of attention from the
   networking industry. Some of the most=
 publicized requirements are
   related to the evolution of the Cloud=
 Networking Infrastructure to
   accommodate a large number of tenants=
, efficient network utilization,
   scalable loop avoidance, and Virtual =
Machine Mobility.
 
   This draft describes a framework for =
cloud networking, highlighting
   the applicability of existing work in=
 various IETF Working Groups
   (e.g., RFCs and drafts developed in I=
ETF L2VPN and L3VPN Working
   Groups) to cloud networking, and the =
gaps and problems that need to
   be further addressed. That is, the go=
al is to understand what may be
   re-used from the current protocols an=
d call out requirements specific
   to the Cloud space that need to be ad=
dressed by new standardization
   work with proposed solutions in certa=
in cases.

 
Thanks,
Nabil
--Boundary_(ID_ajcU9sdPc9Yi7uJ41c3fGA)-- From ju1738@att.com Tue Nov 8 05:12:55 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E011921F8B29 for ; Tue, 8 Nov 2011 05:12:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1gQZvaeZxXs for ; Tue, 8 Nov 2011 05:12:55 -0800 (PST) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id C59E521F8AD8 for ; Tue, 8 Nov 2011 05:12:54 -0800 (PST) X-Env-Sender: ju1738@att.com X-Msg-Ref: server-6.tower-119.messagelabs.com!1320757971!101412!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 12938 invoked from network); 8 Nov 2011 13:12:51 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-6.tower-119.messagelabs.com with AES256-SHA encrypted SMTP; 8 Nov 2011 13:12:51 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pA8DDIqT032742; Tue, 8 Nov 2011 08:13:18 -0500 Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pA8DDCib032675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Nov 2011 08:13:13 -0500 Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([169.254.1.231]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.01.0339.001; Tue, 8 Nov 2011 08:12:43 -0500 From: "UTTARO, JAMES" To: "'Aldrin Isaac'" , Giles Heron Subject: RE: WG adoption of draft-sajassi-raggarwa-l2vpn-evpn-req-01 Thread-Topic: WG adoption of draft-sajassi-raggarwa-l2vpn-evpn-req-01 Thread-Index: AcyQBRR+BnU8yNibqEe6U5jsOUZ2XwNMD1rJAC2SkYAACx5lQA== Date: Tue, 8 Nov 2011 13:12:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 13:12:56 -0000 +1 Jim Uttaro -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of A= ldrin Isaac Sent: Monday, November 07, 2011 9:54 PM To: Giles Heron Cc: l2vpn@ietf.org Subject: Re: WG adoption of draft-sajassi-raggarwa-l2vpn-evpn-req-01 I have inter AND intra site scenarios that I expect to leverage E-VPN for a= s part of a unified wide area data center architecture. This is an origina= l requirement at the inception of E-VPN. Please keep intra-DC part of the = requirements. On Nov 7, 2011, at 5:09 AM, Giles Heron wrote: > Hi everyone, >=20 > Just a quick note to say that I think we have good consensus to progress > this draft as a WG doc. >=20 > Florin raised a good point about datacenter requirements during the last > call, and that's something we may want to discuss during and after Taipei= - > do we want to focus E-VPN on inter-datacenter requirements, or do we want= to > include intra-datacenter requirements? >=20 > Authors - please go ahead and reissue this as: >=20 > draft-ietf-l2vpn-evpn-req-00 >=20 > You'll probably need to wait now until after Taipei because of the draft > cut-off. >=20 > Thanks! >=20 > Giles >=20 > On 21/10/2011 16:21, "Giles Heron" wrote: >=20 >> This is a request to gauge consensus as to whether: >>=20 >> http://tools.ietf.org/html/draft-sajassi-raggarwa-l2vpn-evpn-req-01 >>=20 >> should be accepted as an L2VPN WG draft. >>=20 >> Now that we've adopted the new charter E-VPN is in scope, and we have a >> milestone item to submit a requirements draft for E-VPN to IESG by July >> 2012. If you think this draft is a good starting point for those >> requirements then please reply indicating your support for the draft. I= f >> not then please reply giving some reasons why you think this draft shoul= dn't >> be adopted - which we can then debate. >>=20 >> Please respond by Friday 4th of November. >>=20 >> Thanks! >>=20 >> Giles >>=20 >>=20 >=20 >=20 From thomas.morin@orange.com Tue Nov 8 05:16:01 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03BEB21F8C8F for ; Tue, 8 Nov 2011 05:16:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzCNWVLFkrSU for ; Tue, 8 Nov 2011 05:16:00 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 3B38F21F8C73 for ; Tue, 8 Nov 2011 05:16:00 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2BF2CB5800B for ; Tue, 8 Nov 2011 14:26:08 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 27805B58008 for ; Tue, 8 Nov 2011 14:26:08 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Nov 2011 14:15:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from 10.193.21.179 ([10.193.21.179]) by ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) via Exchange Front-End Server owa.rd.francetelecom.fr ([10.192.128.53]) with Microsoft Exchange Server HTTP-DAV ; Tue, 8 Nov 2011 13:15:59 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Organization: France Telecom Orange user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 Content-class: urn:content-classes:message Subject: Re: WG adoption of draft-sajassi-raggarwa-l2vpn-evpn-req-01 Date: Tue, 8 Nov 2011 14:16:11 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: WG adoption of draft-sajassi-raggarwa-l2vpn-evpn-req-01 Thread-Index: AcyeGI55iDc1Gy54QQ6mRY5aKqEFZQ== References: From: To: X-OriginalArrivalTime: 08 Nov 2011 13:15:59.0510 (UTC) FILETIME=[8E8FE360:01CC9E18] X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 13:16:01 -0000 SGkgR2lsZXMsDQoNCkdpbGVzIEhlcm9uOg0KPiBGbG9yaW4gcmFpc2VkIGEgZ29vZCBwb2ludCBh Ym91dCBkYXRhY2VudGVyIHJlcXVpcmVtZW50cyBkdXJpbmcgdGhlIGxhc3QNCj4gY2FsbCwgYW5k IHRoYXQncyBzb21ldGhpbmcgd2UgbWF5IHdhbnQgdG8gZGlzY3VzcyBkdXJpbmcgYW5kIGFmdGVy IFRhaXBlaSAtDQo+IGRvIHdlIHdhbnQgdG8gZm9jdXMgRS1WUE4gb24gaW50ZXItZGF0YWNlbnRl ciByZXF1aXJlbWVudHMsIG9yIGRvIHdlIHdhbnQgdG8NCj4gaW5jbHVkZSBpbnRyYS1kYXRhY2Vu dGVyIHJlcXVpcmVtZW50cz8NCg0KSSBzdXBwb3J0IHRoZSBpZGVhIHRoYXQgRS1WUE4gcmVxdWly ZW1lbnRzIHNob3VsZCBjb3ZlciBpbnRyYS1EQyBhcyB3ZWxsLg0KDQpUaGFua3MsDQoNCi1UaG9t YXMNCg0KDQpPbiAyMS8xMC8yMDExIDE2OjIxLCAiR2lsZXMgSGVyb24iIDxnaWxlcy5oZXJvbkBn bWFpbC5jb20+IHdyb3RlOg0KPj4gVGhpcyBpcyBhIHJlcXVlc3QgdG8gZ2F1Z2UgY29uc2Vuc3Vz IGFzIHRvIHdoZXRoZXI6DQo+Pg0KPj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt c2FqYXNzaS1yYWdnYXJ3YS1sMnZwbi1ldnBuLXJlcS0wMQ0KPj4NCj4+IHNob3VsZCBiZSBhY2Nl cHRlZCBhcyBhbiBMMlZQTiBXRyBkcmFmdC4NCj4+DQo+PiBOb3cgdGhhdCB3ZSd2ZSBhZG9wdGVk IHRoZSBuZXcgY2hhcnRlciBFLVZQTiBpcyBpbiBzY29wZSwgYW5kIHdlIGhhdmUgYQ0KPj4gbWls ZXN0b25lIGl0ZW0gdG8gc3VibWl0IGEgcmVxdWlyZW1lbnRzIGRyYWZ0IGZvciBFLVZQTiB0byBJ RVNHIGJ5IEp1bHkNCj4+IDIwMTIuICBJZiB5b3UgdGhpbmsgdGhpcyBkcmFmdCBpcyBhIGdvb2Qg c3RhcnRpbmcgcG9pbnQgZm9yIHRob3NlDQo+PiByZXF1aXJlbWVudHMgdGhlbiBwbGVhc2UgcmVw bHkgaW5kaWNhdGluZyB5b3VyIHN1cHBvcnQgZm9yIHRoZSBkcmFmdC4gIElmDQo+PiBub3QgdGhl biBwbGVhc2UgcmVwbHkgZ2l2aW5nIHNvbWUgcmVhc29ucyB3aHkgeW91IHRoaW5rIHRoaXMgZHJh ZnQgc2hvdWxkbid0DQo+PiBiZSBhZG9wdGVkIC0gd2hpY2ggd2UgY2FuIHRoZW4gZGViYXRlLg0K Pj4NCj4+IFBsZWFzZSByZXNwb25kIGJ5IEZyaWRheSA0dGggb2YgTm92ZW1iZXIuDQo+Pg0KPj4g VGhhbmtzIQ0KPj4NCj4+IEdpbGVzDQo+Pg0KPj4NCj4NCg== From lucy.yong@huawei.com Tue Nov 8 09:48:13 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B172011E80B3; Tue, 8 Nov 2011 09:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.934 X-Spam-Level: X-Spam-Status: No, score=-5.934 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sNSAF5cn3EPE; Tue, 8 Nov 2011 09:48:12 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id CCECE11E80CB; Tue, 8 Nov 2011 09:48:12 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUC00181RQRMU@usaga02-in.huawei.com>; Tue, 08 Nov 2011 11:40:03 -0600 (CST) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LUC00EDURQRDF@usaga02-in.huawei.com>; Tue, 08 Nov 2011 11:40:03 -0600 (CST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 08 Nov 2011 09:39:59 -0800 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Tue, 08 Nov 2011 09:39:53 -0800 Date: Tue, 08 Nov 2011 17:39:52 +0000 From: Lucy yong Subject: RE: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt In-reply-to: X-Originating-IP: [10.47.146.243] To: "Bitar, Nabil N" , "l3vpn@ietf.org" , "l2vpn@ietf.org" Message-id: <2691CE0099834E4A9C5044EEC662BB9D118E00D4@dfweml506-mbx> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_vBvrhMipwuzr1ZzOQUpRkg)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-index: Acyd2R8rhSQNYlfHQ16DQ3Td7RyeUQAYBJpg X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: A9LN Dtqg HscH TN1Y VEuD bTnc hK+U szZg tYLv 659x 9Cme AAr8GA== AAyK1A== ABp8Tg== ACKOZQ== ADO+DA==; 7; bAAyAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAbAAzAHYAcABuAEAAaQBlAHQAZgAuAG8AcgBnADsAbAB1AGYAYQBuAGcAQABjAGkAcwBjAG8ALgBjAG8AbQA7AG0AaQByAGMAZQBhAC4AcABpAHMAaQBjAGEAQABiAHQALgBjAG8AbQA7AG4AYQBiAGkAbAAuAG4ALgBiAGkAdABhAHIAQAB2AGUAcgBpAHoAbwBuAC4AYwBvAG0AOwBzAGEAagBhAHMAcwBpAEAAYwBpAHMAYwBvAC4AYwBvAG0AOwB5AC4AaQBrAGUAagBpAHIAaQBAAG4AdAB0AC4AYwBvAG0A; Sosha1_v1; 7; {315816D8-2381-4DE2-894F-8D3771369BFA}; bAB1AGMAeQAuAHkAbwBuAGcAQABoAHUAYQB3AGUAaQAuAGMAbwBtAA==; Tue, 08 Nov 2011 17:39:40 GMT; UgBFADoAIABZAG8AdQByACAAaQBuAHAAdQB0ACAAbwBuACAAdABoAGUAIABmAG8AbABsAG8AdwBpAG4AZwAgAGQAcgBhAGYAdAAgAGkAcwAgAGEAcABwAHIAZQBjAGkAYQB0AGUAZAA6AAkAZAByAGEAZgB0AC0AYgBpAHQAYQByAC0AZABhAHQAYQBjAGUAbgB0AGUAcgAtAHYAcABuAC0AYQBwAHAAbABpAGMAYQBiAGkAbABpAHQAeQAtADAAMQAuAHQAeAB0AA== x-cr-puzzleid: {315816D8-2381-4DE2-894F-8D3771369BFA} References: Cc: "Luyuan Fang \(lufang\)" , Sagessi , "y.ikejiri@ntt.com" , "mircea.pisica@bt.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 17:48:13 -0000 --Boundary_(ID_vBvrhMipwuzr1ZzOQUpRkg) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Nabil and other co-authors, First of all, this is a very good draft to gather DC problem statements and explore VPN applicability for cloud networking. Good information for the community. Thank you very much. Some comments: 1) The document has heavy amount portion to describe all different use cases for PBB but few sentence for TRILL and L3VPN applicability in DC. Suggest to elaborate more on TRILL and L3VPN cases. 2) It is very possible that DC use L2VPN and WAN use L3VPN. It is nice that document this applicability. 3) Provider DC and enterprise DC may implement different L2VPN or L3VPN technologies, it is valuable to describe what kind of interworking scenarios is allowed or not allowed. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Bitar, Nabil N Sent: Monday, November 07, 2011 11:42 PM To: l3vpn@ietf.org; l2vpn@ietf.org Cc: Sagessi; mircea.pisica@bt.com; Luyuan Fang (lufang); y.ikejiri@ntt.com Subject: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Hi, We had submitted the following draft on vpn applicability for data center. Your input on the draft is appreciated in light of some of the ongoing discussion. The draft is targeted for l3vpn and l2vpn. Here is the link: http://tools.ietf.org/html/draft-bitar-datacenter-vpn-applicability-01 Abstract Cloud Computing has been attracting a lot of attention from the networking industry. Some of the most publicized requirements are related to the evolution of the Cloud Networking Infrastructure to accommodate a large number of tenants, efficient network utilization, scalable loop avoidance, and Virtual Machine Mobility. This draft describes a framework for cloud networking, highlighting the applicability of existing work in various IETF Working Groups (e.g., RFCs and drafts developed in IETF L2VPN and L3VPN Working Groups) to cloud networking, and the gaps and problems that need to be further addressed. That is, the goal is to understand what may be re-used from the current protocols and call out requirements specific to the Cloud space that need to be addressed by new standardization work with proposed solutions in certain cases. Thanks, Nabil --Boundary_(ID_vBvrhMipwuzr1ZzOQUpRkg) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Hi Nabil  and other co-authors,

 

First of all, this is a very good draft to gather DC problem statements and explore VPN applicability for cloud networking.  Good information for the community. Thank you very much.

 

Some comments:

 

1)      The document has heavy amount portion to describe all different use cases for PBB but few sentence for TRILL and L3VPN applicability in DC. Suggest to elaborate more on TRILL and L3VPN cases.

2)      It is very possible that DC use L2VPN and WAN use L3VPN.  It is nice that document this applicability.

3)      Provider DC and enterprise DC may implement different L2VPN or L3VPN technologies, it is valuable to describe what kind of interworking scenarios is allowed or not allowed.

 

Best Regards,

Lucy

 

 

 

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Bitar, Nabil N
Sent: Monday, November 07, 2011 11:42 PM
To: l3vpn@ietf.org; l2vpn@ietf.org
Cc: Sagessi; mircea.pisica@bt.com; Luyuan Fang (lufang); y.ikejiri@ntt.com
Subject: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt

 

Hi,

We had submitted the following draft on vpn applicability for data center. Your input on the draft is appreciated in light of some of the ongoing discussion. The draft is targeted for l3vpn and l2vpn.

Here is the link: 

 

 

Abstract
 
   Cloud Computing has been attracting a lot of attention from the
   networking industry. Some of the most publicized requirements are
   related to the evolution of the Cloud Networking Infrastructure to
   accommodate a large number of tenants, efficient network utilization,
   scalable loop avoidance, and Virtual Machine Mobility.
 
   This draft describes a framework for cloud networking, highlighting
   the applicability of existing work in various IETF Working Groups
   (e.g., RFCs and drafts developed in IETF L2VPN and L3VPN Working
   Groups) to cloud networking, and the gaps and problems that need to
   be further addressed. That is, the goal is to understand what may be
   re-used from the current protocols and call out requirements specific
   to the Cloud space that need to be addressed by new standardization
   work with proposed solutions in certain cases.

 
Thanks,
Nabil
--Boundary_(ID_vBvrhMipwuzr1ZzOQUpRkg)-- From nabil.n.bitar@verizon.com Tue Nov 8 12:19:10 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F41A01F0C62; Tue, 8 Nov 2011 12:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EImih4yJ1brZ; Tue, 8 Nov 2011 12:19:06 -0800 (PST) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id 170EC1F0C65; Tue, 8 Nov 2011 12:19:04 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi01.verizon.com) ([166.68.71.143]) by fldsmtpe01.verizon.com with ESMTP; 08 Nov 2011 20:18:50 +0000 From: "Bitar, Nabil N" To: Xuxiaohu , "Bitar, Nabil N" , "l3vpn@ietf.org" , "l2vpn@ietf.org" X-IronPort-AV: E=Sophos;i="4.69,478,1315180800"; d="scan'208,217";a="176108808" Received: from fldp1lumxc7hb02.verizon.com (HELO FLDP1LUMXC7HB02.us.one.verizon.com) ([166.68.75.85]) by fldsmtpi01.verizon.com with ESMTP; 08 Nov 2011 20:18:49 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([169.254.3.102]) by FLDP1LUMXC7HB02.us.one.verizon.com ([166.68.75.85]) with mapi; Tue, 8 Nov 2011 15:18:49 -0500 Date: Tue, 8 Nov 2011 15:18:48 -0500 Subject: Re: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-Topic: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-Index: AcyeU5+fYUMrNyT1Tce5gwm9rg/XnA== Message-ID: In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74774D@szxeml525-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CADE5C802D069nabilnbitarverizoncom_" MIME-Version: 1.0 Cc: "Luyuan Fang \(lufang\)" , Sagessi , "y.ikejiri@ntt.com" , "mircea.pisica@bt.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 20:19:10 -0000 --_000_CADE5C802D069nabilnbitarverizoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpUaGFua3MuIFBsZWFzZSBzZWUgaW5saW5lLg0KDQpUaGFua3MsDQpOYWJpbA0KDQpGcm9t OiBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbTxtYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNv bT4+DQpEYXRlOiBUdWUsIDggTm92IDIwMTEgMDI6NTM6MDkgLTA1MDANClRvOiAiQml0YXIsIE5h YmlsIE4iIDxuYWJpbC5uLmJpdGFyQG9uZS52ZXJpem9uLmNvbTxtYWlsdG86bmFiaWwubi5iaXRh ckBvbmUudmVyaXpvbi5jb20+PiwgImwzdnBuQGlldGYub3JnPG1haWx0bzpsM3ZwbkBpZXRmLm9y Zz4iIDxsM3ZwbkBpZXRmLm9yZzxtYWlsdG86bDN2cG5AaWV0Zi5vcmc+PiwgImwydnBuQGlldGYu b3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4iIDxsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5A aWV0Zi5vcmc+Pg0KQ2M6IFNhZ2Vzc2kgPHNhamFzc2lAY2lzY28uY29tPG1haWx0bzpzYWphc3Np QGNpc2NvLmNvbT4+LCAibWlyY2VhLnBpc2ljYUBidC5jb208bWFpbHRvOm1pcmNlYS5waXNpY2FA YnQuY29tPiIgPG1pcmNlYS5waXNpY2FAYnQuY29tPG1haWx0bzptaXJjZWEucGlzaWNhQGJ0LmNv bT4+LCAiTHV5dWFuIEZhbmcgKGx1ZmFuZykiIDxsdWZhbmdAY2lzY28uY29tPG1haWx0bzpsdWZh bmdAY2lzY28uY29tPj4sICJ5LmlrZWppcmlAbnR0LmNvbTxtYWlsdG86eS5pa2VqaXJpQG50dC5j b20+IiA8eS5pa2VqaXJpQG50dC5jb208bWFpbHRvOnkuaWtlamlyaUBudHQuY29tPj4NClN1Ympl Y3Q6IHJlOiBZb3VyIGlucHV0IG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQgaXMgYXBwcmVjaWF0ZWQ6 IGRyYWZ0LWJpdGFyLWRhdGFjZW50ZXItdnBuLWFwcGxpY2FiaWxpdHktMDEudHh0DQoNCkhpIE5h YmlsLA0KDQpJdOKAmXMgYSB2ZXJ5IGNvbXByZWhlbnNpdmUgZG9jLg0KDQoNClNvbWUgY29tbW9u czoNCg0KMeOAgSAgSW4gc2VjdGlvbiA2LjEsIGl0IHNhaWQ6IOKAnEFzIHRoZSBudW1iZXIgb2Yg dGVuYW50cyBpbiBpbmRpdmlkdWFsIFZMQU4gaXNsYW5kcyBzdXJwYXNzZXMgNEssIHRoZSBvcGVy YXRvciBjb3VsZCBwdXNoIFZQTFMgZGVwbG95bWVudCBkZWVwZXIgaW4gdGhlIERDIG5ldHdvcmvi gKYuIFRoZSBUb1IgYW5kIERDIGNvcmUgZWxlbWVudHMgbmVlZCB0byBiZSBNUExTIGVuYWJsZWQg d2l0aCBleGlzdGluZyBWUExTIHNvbHV0aW9uc+KAnSwgSU1ITywgREMgY29yZSBzd2l0Y2hlcyBk b27igJl0IG5lZWQgdG8gYmUgTVBMUyBlbmFibGVkIHNpbmNlIElQIGJhc2VkIHR1bm5lbCBpcyBh bHNvIGF2YWlsYWJsZS4NCg0KPE5CPiBJdCBpcyBvbmUgc2NlbmFyaW8gYW5kIGl0IGlzIG9uZSBk ZXBsb3ltZW50IGNob2ljZS4NCg0KMuOAgSAgU3RpbGwgaW4gc2VjdGlvbiA2LjEsIGl0IHNhaWQ6 IOKAnSDigKZIb3dldmVyLCB0aGlzIG1vZGVsIGRvZXMgbm90IHNvbHZlIHRoZSBNQUMgZXhwbG9z aW9uIGlzc3VlIGFzIFRvUnMgc3RpbGwgbmVlZCB0byBsZWFybiBWTSBNQUMgYWRkcmVzc2VzLuKA nSBIb3dldmVyLCBpbiBzZWN0aW9uIDYuMi4xLCBpdCBzYWlkOuKAneKApkFsdGVybmF0aXZlbHks IHRoZSBQQkIgZW5jYXBzdWxhdGlvbiBjYW4gYmUgZG9uZSBhdCB0aGUgVG9SLuKAnSAgSXQgaXMg Y29uZnVzZWQgc2luY2UgcGVyZm9ybWluZyBQQkIgZW5jYXBzdWxhdGlvbiBhdCB0aGUgVG9SIHdv dWxkIG5vdCBhbGxldmlhdGUgdGhlIE1BQy1sZWFybmluZyBidXJkZW4gb24gdGhhdCBUb1IuDQoN ClNlY3Rpb24gMi4xLCB0byBoYW5kbGUgdGhlIE1BQyBzY2FsZSwgYW5kIGxldmlhdGluZyBWTSBN QUNzIGZyb20gVG9ycyBhbmQgY29yZSBzd2l0Y2hlcywgUEJCIHdvdWxkIHN0YXJ0IGF0IHRoZSBW c3cuIEhlcmUgaXMgdGhlIHRleHQ6DQoNCg0KDQoiSW4gYSBEQyBlbnZpcm9ubWVudCwgUEJCIG1h aW50YWlucyB0cmFkaXRpb25hbCBFdGhlcm5ldCBmb3J3YXJkaW5nDQogICBwbGFuZSBhbmQgb3Bl cmF0aW9uYWwgbW9kZWwuIEZvciBleGFtcGxlLCBhIFZTdyBpbXBsZW1lbnRhdGlvbiBvZiBQQkIN CiAgIGNhbiBtYWtlIHVzZSBvZiB0aGUgMjQgYml0IElTSUQgdGFnIGluc3RlYWQgb2YgdGhlIDEy IGJpdCBWTEFOIHRhZyB0bw0KICAgaWRlbnRpZnkgdGhlIHZpcnR1YWwgYnJpZGdpbmcgZG9tYWlu cyBhc3NvY2lhdGVkIHdpdGggZGlmZmVyZW50IFZNDQogICBncm91cHMuIFRoZSBWU3cgdXBsaW5r IHRvd2FyZHMgdGhlIFRvUiBpbiBGaWd1cmUgMSBjYW4gc3RpbGwgYmUNCiAgIHRyZWF0ZWQgYXMg YW4gRXRoZXJuZXQgYmFja2JvbmUgaW50ZXJmYWNlLiBBIGZyYW1lIG9yaWdpbmF0ZWQgYnkgYSBW TQ0KICAgY2FuIGJlIGVuY2Fwc3VsYXRlZCB3aXRoIHRoZSBJU0lEIGFzc2lnbmVkIHRvIHRoZSBW TSBWU3cgaW50ZXJmYWNlDQogICBhbmQgd2l0aCB0aGUgb3V0ZXIgREEgYW5kIFNBIE1BQ3MgYXNz b2NpYXRlZCB3aXRoIHRoZSByZXNwZWN0aXZlDQogICBkZXN0aW5hdGlvbiBhbmQgc291cmNlIHNl cnZlciBibGFkZXMsIGFuZCB0aGVuIHNlbnQgdG8gdGhlIFRvUg0KICAgU3dpdGNoLg0KDQoNCiAg IDxzbmFwPg0KDQoNCiJXaXRoIFBCQiBlbmNhcHN1bGF0aW9uLCBUb1JzIGFuZCBDb3JlIFNXcyBk byBub3QgaGF2ZSB0byBoYW5kbGUgVk0gTUFDIGFkZHJlc3NlcyBzbyB0aGUgc2l6ZSBvZiB0aGVp ciBNQUMgRklCIHRhYmxlcyBtYXkgZGVjcmVhc2UiDQoNCg0KDQoz44CBICBJbiA2LjIuNi4yLiBQ QkJOIGluIFZTdywgTDJWUE4gaW4gdGhlIFRvUiwgaXQgc2FpZDrigJ0gVGhlIHByb2NlZHVyZXMg ZnJvbSB0aGUgcHJldmlvdXMgc2VjdGlvbiBhcmUgdXNlZCBhdCB0aGUgVlN3OiBQQkIgZW5jYXBz dWxhdGlvbiBhbmQgRXRoZXJuZXQgQlZMQU5zIGNhbiBiZSB1c2VkIG9uIHRoZSBWU3cgdXBsaW5r LiBMMlZQTiBpbmZyYXN0cnVjdHVyZSBpcyByZXBsYWNpbmcgdGhlIEJWTEFOIGF0IHRoZSBUb1Ig ZW5hYmxpbmcgdGhlIHVzZSBvZiBJUCAoR1JFIG9yIEwyVFApIG9yIE1QTFMgdHVubmVsaW5nLiAg TDIgbmV0d29ya2luZyBzdGlsbCBoYXMgdGhlIHNhbWUgY29udHJvbCBwbGFuZSBjaG9pY2VzOiBJ Uy1JUyBbODAyLjFhcV0gYW5kL29yIEJHUCBbUEJCLUVWUE5dLCBpbmRlcGVuZGVudGx5IGZyb20g dGhlIHR1bm5lbGluZyBjaG9pY2Uu4oCdIFNpbmNlIFBCQiBlbmNhcHN1bGF0aW9uIGhhcyBhbHJl YWR5IGJlZW4gZG9uZSBvbiB0aGUgVlN3LCB3aHkgZG8gd2Ugc3RpbGwgbmVlZCB0byBydW4gODAy LjFhcSBhbmQgUEJCLUVWUE4gd2l0aCBhbm90aGVyIFBCQiBlbmNhcHN1bGF0aW9uIGxheWVyPyBD YW7igJl0IHdlIHNpbXBseSB1c2UgYW55IEwyVlBOIHRlY2hub2xvZ3ksIGUuZy4sIFZQTFMuIElu IGFkZGl0aW9uLCBub3RlIHRoYXQgaW4gRmlndXJlIDUsIGl0IHNhaWQg4oCcaW50cmEtREMgTDJW UE4gb3ZlciBJUCBvciBNUExTIHR1bm5lbGluZ+KAnS4NCg0KPE5CPiBJIGFncmVlIHdlIG5lZWQg dG8gbWFrZSB0aGlzIGNsZWFyZXIuIEhvd2V2ZXIsIFBCQi1FVlBOIGlzIHN0aWxsIGFwcGxpY2Fi bGUgZXNwZWNpYWxseSBpbiB0aGUgV0FOIGFzIGluZGljYXRlZCBhbmQgY2FuIGJlIGluIHRoZSBM QU4gYXMgaW5kaWNhdGVkLiA4MDIuMWFxIGlzIGxlc3Mgb2YgYW4gaXNzdWUgaW4gdGhpcyBzY2Vu YXJpbyBhcyBkZXBpY3RlZCBidXQgY2FuIGV4aXRlZCBpbiBvdGhlciBEY3Mvb3RoZXIgY3VzdG9t ZXIgc2l0ZXMgY29tbXVuaWNhdGluZyB0byB0aGUgZGVpY3RlZCBEQyBpcyBydW5uaW5nIG9yIGlm IHRoZXJlIGlzIGEgc2VnbWVudCBpbiB0aGUgc2FtZSBEQyBydW5uaW5nIDgwMi4xYXEgc2ltdWx0 YW5lb3VzbHkuDQoNCg0KQmVzdCByZWdhcmRzLA0KWGlhb2h1DQoNCuWPkeS7tuS6ujogbDJ2cG4t Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzps MnZwbi1ib3VuY2VzQGlldGYub3JnXSDku6PooaggQml0YXIsIE5hYmlsIE4NCuWPkemAgeaXtumX tDogMjAxMeW5tDEx5pyIOOaXpSAxMzo0Mg0K5pS25Lu25Lq6OiBsM3ZwbkBpZXRmLm9yZzxtYWls dG86bDN2cG5AaWV0Zi5vcmc+OyBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+ DQrmioTpgIE6IFNhZ2Vzc2k7IG1pcmNlYS5waXNpY2FAYnQuY29tPG1haWx0bzptaXJjZWEucGlz aWNhQGJ0LmNvbT47IEx1eXVhbiBGYW5nIChsdWZhbmcpOyB5LmlrZWppcmlAbnR0LmNvbTxtYWls dG86eS5pa2VqaXJpQG50dC5jb20+DQrkuLvpopg6IFlvdXIgaW5wdXQgb24gdGhlIGZvbGxvd2lu ZyBkcmFmdCBpcyBhcHByZWNpYXRlZDogZHJhZnQtYml0YXItZGF0YWNlbnRlci12cG4tYXBwbGlj YWJpbGl0eS0wMS50eHQNCg0KSGksDQpXZSBoYWQgc3VibWl0dGVkIHRoZSBmb2xsb3dpbmcgZHJh ZnQgb24gdnBuIGFwcGxpY2FiaWxpdHkgZm9yIGRhdGEgY2VudGVyLiBZb3VyIGlucHV0IG9uIHRo ZSBkcmFmdCBpcyBhcHByZWNpYXRlZCBpbiBsaWdodCBvZiBzb21lIG9mIHRoZSBvbmdvaW5nIGRp c2N1c3Npb24uIFRoZSBkcmFmdCBpcyB0YXJnZXRlZCBmb3IgbDN2cG4gYW5kIGwydnBuLg0KSGVy ZSBpcyB0aGUgbGluazoNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYml0YXIt ZGF0YWNlbnRlci12cG4tYXBwbGljYWJpbGl0eS0wMQ0KDQoNCkFic3RyYWN0DQoNCg0KDQogICBD bG91ZCBDb21wdXRpbmcgaGFzIGJlZW4gYXR0cmFjdGluZyBhIGxvdCBvZiBhdHRlbnRpb24gZnJv bSB0aGUNCg0KICAgbmV0d29ya2luZyBpbmR1c3RyeS4gU29tZSBvZiB0aGUgbW9zdCBwdWJsaWNp emVkIHJlcXVpcmVtZW50cyBhcmUNCg0KICAgcmVsYXRlZCB0byB0aGUgZXZvbHV0aW9uIG9mIHRo ZSBDbG91ZCBOZXR3b3JraW5nIEluZnJhc3RydWN0dXJlIHRvDQoNCiAgIGFjY29tbW9kYXRlIGEg bGFyZ2UgbnVtYmVyIG9mIHRlbmFudHMsIGVmZmljaWVudCBuZXR3b3JrIHV0aWxpemF0aW9uLA0K DQogICBzY2FsYWJsZSBsb29wIGF2b2lkYW5jZSwgYW5kIFZpcnR1YWwgTWFjaGluZSBNb2JpbGl0 eS4NCg0KDQoNCiAgIFRoaXMgZHJhZnQgZGVzY3JpYmVzIGEgZnJhbWV3b3JrIGZvciBjbG91ZCBu ZXR3b3JraW5nLCBoaWdobGlnaHRpbmcNCg0KICAgdGhlIGFwcGxpY2FiaWxpdHkgb2YgZXhpc3Rp bmcgd29yayBpbiB2YXJpb3VzIElFVEYgV29ya2luZyBHcm91cHMNCg0KICAgKGUuZy4sIFJGQ3Mg YW5kIGRyYWZ0cyBkZXZlbG9wZWQgaW4gSUVURiBMMlZQTiBhbmQgTDNWUE4gV29ya2luZw0KDQog ICBHcm91cHMpIHRvIGNsb3VkIG5ldHdvcmtpbmcsIGFuZCB0aGUgZ2FwcyBhbmQgcHJvYmxlbXMg dGhhdCBuZWVkIHRvDQoNCiAgIGJlIGZ1cnRoZXIgYWRkcmVzc2VkLiBUaGF0IGlzLCB0aGUgZ29h bCBpcyB0byB1bmRlcnN0YW5kIHdoYXQgbWF5IGJlDQoNCiAgIHJlLXVzZWQgZnJvbSB0aGUgY3Vy cmVudCBwcm90b2NvbHMgYW5kIGNhbGwgb3V0IHJlcXVpcmVtZW50cyBzcGVjaWZpYw0KDQogICB0 byB0aGUgQ2xvdWQgc3BhY2UgdGhhdCBuZWVkIHRvIGJlIGFkZHJlc3NlZCBieSBuZXcgc3RhbmRh cmRpemF0aW9uDQoNCiAgIHdvcmsgd2l0aCBwcm9wb3NlZCBzb2x1dGlvbnMgaW4gY2VydGFpbiBj YXNlcy4NCg0KDQpUaGFua3MsDQoNCk5hYmlsDQo= --_000_CADE5C802D069nabilnbitarverizoncom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PC9oZWFkPjxib2R5IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyB3b3JkLXdyYXA6 IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFr OiBhZnRlci13aGl0ZS1zcGFjZTsgIj48ZGl2PkhpLDwvZGl2PjxkaXY+VGhhbmtzLiBQbGVhc2Ug c2VlIGlubGluZS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoYW5rcyw8L2Rpdj48ZGl2Pk5h YmlsPC9kaXY+PGRpdj48YnI+PC9kaXY+PHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj48 ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGln bjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1M RUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47 IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRF Ui1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPjxzcGFuIHN0eWxlPSJmb250 LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+IFh1eGlhb2h1ICZsdDs8YSBocmVmPSJtYWlsdG86 eHV4aWFvaHVAaHVhd2VpLmNvbSI+eHV4aWFvaHVAaHVhd2VpLmNvbTwvYT4mZ3Q7PGJyPjxzcGFu IHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRlOiA8L3NwYW4+IFR1ZSwgOCBOb3YgMjAxMSAw Mjo1MzowOSAtMDUwMDxicj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bh bj4gIkJpdGFyLCBOYWJpbCBOIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5hYmlsLm4uYml0YXJAb25l LnZlcml6b24uY29tIj5uYWJpbC5uLmJpdGFyQG9uZS52ZXJpem9uLmNvbTwvYT4mZ3Q7LCAiPGEg aHJlZj0ibWFpbHRvOmwzdnBuQGlldGYub3JnIj5sM3ZwbkBpZXRmLm9yZzwvYT4iICZsdDs8YSBo cmVmPSJtYWlsdG86bDN2cG5AaWV0Zi5vcmciPmwzdnBuQGlldGYub3JnPC9hPiZndDssICI8YSBo cmVmPSJtYWlsdG86bDJ2cG5AaWV0Zi5vcmciPmwydnBuQGlldGYub3JnPC9hPiIgJmx0OzxhIGhy ZWY9Im1haWx0bzpsMnZwbkBpZXRmLm9yZyI+bDJ2cG5AaWV0Zi5vcmc8L2E+Jmd0Ozxicj48c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4gU2FnZXNzaSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNhamFzc2lAY2lzY28uY29tIj5zYWphc3NpQGNpc2NvLmNvbTwvYT4mZ3Q7LCAi PGEgaHJlZj0ibWFpbHRvOm1pcmNlYS5waXNpY2FAYnQuY29tIj5taXJjZWEucGlzaWNhQGJ0LmNv bTwvYT4iICZsdDs8YSBocmVmPSJtYWlsdG86bWlyY2VhLnBpc2ljYUBidC5jb20iPm1pcmNlYS5w aXNpY2FAYnQuY29tPC9hPiZndDssICJMdXl1YW4gRmFuZyAobHVmYW5nKSIgJmx0OzxhIGhyZWY9 Im1haWx0bzpsdWZhbmdAY2lzY28uY29tIj5sdWZhbmdAY2lzY28uY29tPC9hPiZndDssICI8YSBo cmVmPSJtYWlsdG86eS5pa2VqaXJpQG50dC5jb20iPnkuaWtlamlyaUBudHQuY29tPC9hPiIgJmx0 OzxhIGhyZWY9Im1haWx0bzp5LmlrZWppcmlAbnR0LmNvbSI+eS5pa2VqaXJpQG50dC5jb208L2E+ Jmd0Ozxicj48c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPiBy ZTogWW91ciBpbnB1dCBvbiB0aGUgZm9sbG93aW5nIGRyYWZ0IGlzIGFwcHJlY2lhdGVkOiBkcmFm dC1iaXRhci1kYXRhY2VudGVyLXZwbi1hcHBsaWNhYmlsaXR5LTAxLnR4dDxicj48L2Rpdj48ZGl2 Pjxicj48L2Rpdj48ZGl2IHhtbG5zOnY9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4 bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOnc9 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOndvcmQiIHhtbG5zOm09Imh0dHA6Ly9z Y2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93 d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+PG1ldGEgbmFtZT0iR2VuZXJhdG9y IiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwh LS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk65a6L 5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAy IDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJcGFu b3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRN TCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAu TXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3Jh cGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCXRleHQtaW5kZW50OjIxLjBwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1z cGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNwYW47fQ0Kc3Bhbi5IVE1MQ2hhcg0K CXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyI7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5oNTENCgl7bXNvLXN0eWxlLW5hbWU6aDUxOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0 IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6 ODI1Nzk1NDY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz OjIwMDc1MTYyIC0yMTI2OTk1NjI4IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEz IDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0K CXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJbWFyZ2luLWxlZnQ6MTguMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDENCgl7bXNvLWxpc3QtaWQ6OTI1NjUyOTI0Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1z by1saXN0LXRlbXBsYXRlLWlkczoxNDAwNTY1NDA2IDE1MTAxMDM5OTQgNjc2OTg3MTMgNjc2OTg3 MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7 fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC10ZXh0OiUx44CBOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4t bGVmdDoxOC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9t OjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PGRpdiBsYW5nPSJaSC1DTiIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDstd2Vi a2l0LW5ic3AtbW9kZTogc3BhY2U7LXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFj ZSI+PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBjb2xvcjogcmdiKDMxLCA3Mywg MTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+SGkgTmFiaWwsPG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 IDEwLjVwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyAiPkl0JiM4MjE3O3MgYSB2ZXJ5IGNvbXByZWhlbnNpdmUgZG9jLjwvc3Bhbj48 L3A+PC9kaXY+PC9kaXY+PC9kaXY+PC9zcGFuPjxkaXY+PGJyPjwvZGl2PjxzcGFuIGlkPSJPTEtf U1JDX0JPRFlfU0VDVElPTiI+PGRpdiB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29t OnZtbCIgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj48ZGl2IGxhbmc9IlpILUNOIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOy13ZWJraXQt bmJzcC1tb2RlOiBzcGFjZTstd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlIj48 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUp OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6IDEwLjVwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+ U29tZSBjb21tb25zOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cHJlIHN0eWxlPSJtYXJnaW4tbGVm dDoxOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXM7bXNv LWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjwhLS1baWYgIXN1cHBvcnRMaXN0c10tLT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPjHjgIE8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlm XS0tPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj5JbiBz ZWN0aW9uIDYuMSwgaXQgc2FpZDogJiM4MjIwO0FzIHRoZSBudW1iZXIgb2YgdGVuYW50cyBpbiBp bmRpdmlkdWFsIFZMQU4gaXNsYW5kcyBzdXJwYXNzZXMgNEssIHRoZSBvcGVyYXRvciBjb3VsZCBw dXNoIFZQTFMgZGVwbG95bWVudCBkZWVwZXIgaW4gdGhlIERDIG5ldHdvcmsmIzgyMzA7LiBUaGUg VG9SIGFuZCBEQyBjb3JlIGVsZW1lbnRzIG5lZWQgdG8gYmUgTVBMUyBlbmFibGVkIHdpdGggZXhp c3RpbmcgVlBMUyBzb2x1dGlvbnMmIzgyMjE7LCBJTUhPLCBEQyBjb3JlIHN3aXRjaGVzIGRvbiYj ODIxNzt0IG5lZWQgdG8gYmUgTVBMUyBlbmFibGVkIHNpbmNlIElQIGJhc2VkIHR1bm5lbCBpcyBh bHNvIGF2YWlsYWJsZS48L3NwYW4+PC9wcmU+PC9kaXY+PC9kaXY+PC9kaXY+PC9zcGFuPjxkaXY+ Jmx0O05CJmd0OyBJdCBpcyBvbmUgc2NlbmFyaW8gYW5kIGl0IGlzIG9uZSBkZXBsb3ltZW50IGNo b2ljZS4mbmJzcDs8L2Rpdj48c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPjxkaXYgeG1s bnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hlbWFz LW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNv bS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0 bWw0MCI+PGRpdiBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9 IndvcmQtd3JhcDogYnJlYWstd29yZDstd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7LXdlYmtpdC1s aW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZSI+PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj48 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDtwYWdlLWJy ZWFrLWJlZm9yZTphbHdheXM7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT48cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDtwYWdl LWJyZWFrLWJlZm9yZTphbHdheXM7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPjwhLS1baWYgIXN1 cHBvcnRMaXN0c10tLT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjLjgIE8c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyA8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IS0tW2VuZGlmXS0tPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOiAxMC41cHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgIj5TdGlsbCBpbiBzZWN0aW9uIDYuMSwgaXQgc2FpZDogJiM4MjIx OyAmIzgyMzA7SG93ZXZlciwgdGhpcyBtb2RlbCBkb2VzIG5vdCBzb2x2ZSB0aGUgTUFDIGV4cGxv c2lvbiBpc3N1ZSBhcyBUb1JzIHN0aWxsIG5lZWQgdG8gbGVhcm4gVk0gTUFDIGFkZHJlc3Nlcy4m IzgyMjE7IEhvd2V2ZXIsIGluIHNlY3Rpb24gNi4yLjEsIGl0IHNhaWQ6JiM4MjIxOyYjODIzMDtB bHRlcm5hdGl2ZWx5LCB0aGUgUEJCIGVuY2Fwc3VsYXRpb24gY2FuIGJlIGRvbmUgYXQgdGhlIFRv Ui4mIzgyMjE7ICZuYnNwO0l0IGlzIGNvbmZ1c2VkIHNpbmNlIHBlcmZvcm1pbmcgUEJCIGVuY2Fw c3VsYXRpb24gYXQgdGhlIFRvUiB3b3VsZCBub3QgYWxsZXZpYXRlIHRoZSBNQUMtbGVhcm5pbmcg YnVyZGVuIG9uIHRoYXQgVG9SLiA8L3NwYW4+PC9wcmU+PC9kaXY+PC9kaXY+PC9kaXY+PC9zcGFu PjxkaXY+PGJyPjwvZGl2PjxkaXY+U2VjdGlvbiAyLjEsIHRvIGhhbmRsZSB0aGUgTUFDIHNjYWxl LCBhbmQgbGV2aWF0aW5nIFZNIE1BQ3MgZnJvbSBUb3JzIGFuZCBjb3JlIHN3aXRjaGVzLCBQQkIg d291bGQgc3RhcnQgYXQgdGhlIFZzdy4gSGVyZSBpcyB0aGUgdGV4dDo8L2Rpdj48ZGl2PjxzcGFu IGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0iZm9udC1zaXplOiAxNnB4OyBmb250LWZh bWlseTogVGltZXM7ICI+PHByZSBjbGFzcz0ibmV3cGFnZSIgc3R5bGU9ImZvbnQtc2l6ZTogMWVt OyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgcGFnZS1icmVhay1iZWZvcmU6 IGFsd2F5czsgIj4gICZuYnNwOzwvcHJlPjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJmb250 LXNpemU6IDFlbTsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IHBhZ2UtYnJl YWstYmVmb3JlOiBhbHdheXM7ICI+IkluIGEgREMgZW52aXJvbm1lbnQsIFBCQiBtYWludGFpbnMg dHJhZGl0aW9uYWwgRXRoZXJuZXQgZm9yd2FyZGluZw0KICAgcGxhbmUgYW5kIG9wZXJhdGlvbmFs IG1vZGVsLiBGb3IgZXhhbXBsZSwgYSBWU3cgaW1wbGVtZW50YXRpb24gb2YgUEJCDQogICBjYW4g bWFrZSB1c2Ugb2YgdGhlIDI0IGJpdCBJU0lEIHRhZyBpbnN0ZWFkIG9mIHRoZSAxMiBiaXQgVkxB TiB0YWcgdG8NCiAgIGlkZW50aWZ5IHRoZSB2aXJ0dWFsIGJyaWRnaW5nIGRvbWFpbnMgYXNzb2Np YXRlZCB3aXRoIGRpZmZlcmVudCBWTQ0KICAgZ3JvdXBzLiBUaGUgVlN3IHVwbGluayB0b3dhcmRz IHRoZSBUb1IgaW4gRmlndXJlIDEgY2FuIHN0aWxsIGJlDQogICB0cmVhdGVkIGFzIGFuIEV0aGVy bmV0IGJhY2tib25lIGludGVyZmFjZS4gQSBmcmFtZSBvcmlnaW5hdGVkIGJ5IGEgVk0NCiAgIGNh biBiZSBlbmNhcHN1bGF0ZWQgd2l0aCB0aGUgSVNJRCBhc3NpZ25lZCB0byB0aGUgVk0gVlN3IGlu dGVyZmFjZQ0KICAgYW5kIHdpdGggdGhlIG91dGVyIERBIGFuZCBTQSBNQUNzIGFzc29jaWF0ZWQg d2l0aCB0aGUgcmVzcGVjdGl2ZQ0KICAgZGVzdGluYXRpb24gYW5kIHNvdXJjZSBzZXJ2ZXIgYmxh ZGVzLCBhbmQgdGhlbiBzZW50IHRvIHRoZSBUb1INCiAgIFN3aXRjaC48L3ByZT48cHJlIGNsYXNz PSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOiAxZW07IG1hcmdpbi10b3A6IDBweDsgbWFyZ2lu LWJvdHRvbTogMHB4OyBwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyAiPjxicj48L3ByZT48cHJl IGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOiAxZW07IG1hcmdpbi10b3A6IDBweDsg bWFyZ2luLWJvdHRvbTogMHB4OyBwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyAiPiAgICZsdDtz bmFwJmd0OzwvcHJlPjxwcmUgY2xhc3M9Im5ld3BhZ2UiIHN0eWxlPSJmb250LXNpemU6IDFlbTsg bWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAwcHg7IHBhZ2UtYnJlYWstYmVmb3JlOiBh bHdheXM7ICI+PGJyPjwvcHJlPjwvc3Bhbj48c3BhbiBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIg c3R5bGU9ImZvbnQtc2l6ZTogMTZweDsgd2hpdGUtc3BhY2U6IHByZTsgZm9udC1mYW1pbHk6ICdD b3VyaWVyIE5ldyc7ICI+IldpdGggUEJCIGVuY2Fwc3VsYXRpb24sIFRvUnMgYW5kIENvcmUgU1dz IGRvIG5vdCBoYXZlIHRvIGhhbmRsZSBWTSA8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxl LXNwYW4iIHN0eWxlPSJmb250LXNpemU6IDE2cHg7IHdoaXRlLXNwYWNlOiBwcmU7IGZvbnQtZmFt aWx5OiAnQ291cmllciBOZXcnOyAiPiBNQUMgYWRkcmVzc2VzIHNvIHRoZSBzaXplIG9mIHRoZWly IE1BQyBGSUIgdGFibGVzIG1heSBkZWNyZWFzZSI8L3NwYW4+PHNwYW4gY2xhc3M9IkFwcGxlLXN0 eWxlLXNwYW4iIHN0eWxlPSJmb250LXNpemU6IDE2cHg7IGZvbnQtZmFtaWx5OiBUaW1lczsgIj48 cHJlIGNsYXNzPSJuZXdwYWdlIiBzdHlsZT0iZm9udC1zaXplOiAxZW07IG1hcmdpbi10b3A6IDBw eDsgbWFyZ2luLWJvdHRvbTogMHB4OyBwYWdlLWJyZWFrLWJlZm9yZTogYWx3YXlzOyAiPjxzcGFu IGNsYXNzPSJBcHBsZS10YWItc3BhbiIgc3R5bGU9IndoaXRlLXNwYWNlOnByZSI+CTwvc3Bhbj48 L3ByZT48L3NwYW4+PC9kaXY+PHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj48ZGl2IHht bG5zOnY9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1h cy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jv c29mdC1jb206b2ZmaWNlOndvcmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPjxkaXYgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxl PSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOy13ZWJraXQt bGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2UiPjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7cGFnZS1i cmVhay1iZWZvcmU6YWx3YXlzO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+PG86cD48L286cD48L3NwYW4+PC9w cmU+PHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7cGFn ZS1icmVhay1iZWZvcmU6YWx3YXlzO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48IS0tW2lmICFz dXBwb3J0TGlzdHNdLS0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4z44CBPHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsgPC9zcGFu Pjwvc3Bhbj48L3NwYW4+PCEtLVtlbmRpZl0tLT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTogMTAuNXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7ICI+SW4gPGEgbmFtZT0ic2VjdGlvbi02LjIuNi4yIj42LjIuNi4y PC9hPi4gUEJCTiBpbiBWU3csIEwyVlBOIGluIHRoZSBUb1IsIGl0IHNhaWQ6JiM4MjIxOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTogMTAuNXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7ICI+VGhlIHByb2NlZHVyZXMgZnJvbSB0aGUgcHJldmlvdXMgc2Vj dGlvbiBhcmUgdXNlZCBhdCB0aGUgVlN3OiBQQkIgZW5jYXBzdWxhdGlvbiBhbmQgRXRoZXJuZXQg QlZMQU5zIGNhbiBiZSB1c2VkIG9uIHRoZSBWU3cgdXBsaW5rLiBMMlZQTiBpbmZyYXN0cnVjdHVy ZSBpcyByZXBsYWNpbmcgdGhlIEJWTEFOIGF0IHRoZSBUb1IgZW5hYmxpbmcgdGhlIHVzZSBvZiBJ UCAoR1JFIG9yIEwyVFApIG9yIE1QTFMgdHVubmVsaW5nLiZuYnNwOyBMMiBuZXR3b3JraW5nIHN0 aWxsIGhhcyB0aGUgc2FtZSBjb250cm9sIHBsYW5lIGNob2ljZXM6IElTLUlTIFs4MDIuMWFxXSBh bmQvb3IgQkdQIFtQQkItRVZQTl0sIGluZGVwZW5kZW50bHkgZnJvbSB0aGUgdHVubmVsaW5nIGNo b2ljZS4mIzgyMjE7IFNpbmNlIFBCQiBlbmNhcHN1bGF0aW9uIGhhcyBhbHJlYWR5IGJlZW4gZG9u ZSBvbiB0aGUgVlN3LCB3aHkgZG8gd2Ugc3RpbGwgbmVlZCB0byBydW4gODAyLjFhcSBhbmQgUEJC LUVWUE4gd2l0aCBhbm90aGVyIFBCQiBlbmNhcHN1bGF0aW9uIGxheWVyPyBDYW4mIzgyMTc7dCB3 ZSBzaW1wbHkgdXNlIGFueSBMMlZQTiB0ZWNobm9sb2d5LCBlLmcuLCBWUExTLiBJbiBhZGRpdGlv biwgbm90ZSB0aGF0IGluIEZpZ3VyZSA1LCBpdCBzYWlkICYjODIyMDtpbnRyYS1EQyBMMlZQTiBv dmVyIElQIG9yIE1QTFMgdHVubmVsaW5nJiM4MjIxOy48L3NwYW4+PC9wcmU+PC9kaXY+PC9kaXY+ PC9kaXY+PC9zcGFuPjxkaXY+Jmx0O05CJmd0OyBJIGFncmVlIHdlIG5lZWQgdG8gbWFrZSB0aGlz IGNsZWFyZXIuIEhvd2V2ZXIsIFBCQi1FVlBOIGlzIHN0aWxsIGFwcGxpY2FibGUgZXNwZWNpYWxs eSBpbiB0aGUgV0FOIGFzIGluZGljYXRlZCBhbmQgY2FuIGJlIGluIHRoZSBMQU4gYXMgaW5kaWNh dGVkLiA4MDIuMWFxIGlzIGxlc3Mgb2YgYW4gaXNzdWUgaW4gdGhpcyBzY2VuYXJpbyBhcyBkZXBp Y3RlZCBidXQgY2FuIGV4aXRlZCBpbiBvdGhlciBEY3Mvb3RoZXIgY3VzdG9tZXIgc2l0ZXMgY29t bXVuaWNhdGluZyB0byB0aGUgZGVpY3RlZCBEQyBpcyBydW5uaW5nIG9yIGlmIHRoZXJlIGlzIGEg c2VnbWVudCBpbiB0aGUgc2FtZSBEQyBydW5uaW5nIDgwMi4xYXEgc2ltdWx0YW5lb3VzbHkuPC9k aXY+PHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj48ZGl2IHhtbG5zOnY9InVybjpzY2hl bWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29t Om9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNl OndvcmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDQv MTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPjxkaXYgbGFu Zz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6IGJy ZWFrLXdvcmQ7LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOy13ZWJraXQtbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2UiPjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+PHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6MTguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7cGFnZS1icmVhay1iZWZvcmU6YWx3 YXlzO21zby1saXN0OmwxIGxldmVsMSBsZm8yIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTogMTAuNXB0OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7ICI+PG86cD48L286cD48L3NwYW4+PC9wcmU+PHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6MGNt Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0OyBjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj5CZXN0IHJlZ2FyZHMsPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOiAxMC41cHQ7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj5YaWFvaHU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEw LjVwdDsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4w cHQiPjxkaXY+PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+5Y+R5Lu2 5Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TIj4gPGEgaHJlZj0i bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmciPmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ IFs8YSBocmVmPSJtYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmwydnBuLWJv dW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+5Luj6KGoIDwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kyI+Qml0YXIsIE5h YmlsIE48YnI+PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OuWui+S9kyI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk65a6L5L2TIj4gMjAxMTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTrlrovkvZMiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj4xMTwvc3Bhbj7mnIg8c3BhbiBs YW5nPSJFTi1VUyI+ODwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+DQogMTM6NDI8YnI+PC9z cGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyI+IDxhIGhyZWY9Im1haWx0bzpsM3ZwbkBpZXRmLm9yZyI+bDN2cG5AaWV0Zi5vcmc8 L2E+OyA8YSBocmVmPSJtYWlsdG86bDJ2cG5AaWV0Zi5vcmciPmwydnBuQGlldGYub3JnPC9hPjxi cj48L3NwYW4+PGI+5oqE6YCBPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIj4gU2FnZXNzaTsgPGEgaHJlZj0ibWFpbHRvOm1pcmNlYS5waXNpY2FAYnQuY29t Ij5taXJjZWEucGlzaWNhQGJ0LmNvbTwvYT47IEx1eXVhbiBGYW5nIChsdWZhbmcpOyA8YSBocmVm PSJtYWlsdG86eS5pa2VqaXJpQG50dC5jb20iPnkuaWtlamlyaUBudHQuY29tPC9hPjxicj48L3Nw YW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIj4gWW91ciBpbnB1dCBvbiB0aGUgZm9sbG93aW5nIGRyYWZ0IGlzIGFwcHJlY2lhdGVkOiBk cmFmdC1iaXRhci1kYXRhY2VudGVyLXZwbi1hcHBsaWNhYmlsaXR5LTAxLnR4dDxvOnA+PC9vOnA+ PC9zcGFuPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGNv bG9yOiBibGFjazsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+SGksPG86cD48 L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgY29sb3I6IGJsYWNrOyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj5XZSBoYWQgc3VibWl0dGVkIHRoZSBmb2xsb3dp bmcgZHJhZnQgb24gdnBuIGFwcGxpY2FiaWxpdHkgZm9yIGRhdGEgY2VudGVyLiBZb3VyIGlucHV0 IG9uIHRoZSBkcmFmdCBpcyBhcHByZWNpYXRlZCBpbiBsaWdodCBvZiBzb21lIG9mIHRoZSBvbmdv aW5nDQogZGlzY3Vzc2lvbi4gVGhlIGRyYWZ0IGlzIHRhcmdldGVkIGZvciBsM3ZwbiBhbmQgbDJ2 cG4uPG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgY29sb3I6IGJsYWNr OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgIj5IZXJlIGlzIHRoZSBsaW5rOiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGNvbG9yOiBibGFj azsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6IDEwLjVwdDsgY29sb3I6IGJsYWNrOyBmb250LWZhbWlseTog Q2FsaWJyaSwgc2Fucy1zZXJpZjsgIj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1iaXRhci1kYXRhY2VudGVyLXZwbi1hcHBsaWNhYmlsaXR5LTAxIj5odHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaXRhci1kYXRhY2VudGVyLXZwbi1hcHBsaWNhYmlsaXR5 LTAxPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOiAxMC41cHQ7IGNvbG9yOiBi bGFjazsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7ICI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3 YXlzIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPkFic3RyYWN0PG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0icGFnZS1icmVh ay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5bGU9 InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgQ2xvdWQgQ29tcHV0aW5nIGhh cyBiZWVuIGF0dHJhY3RpbmcgYSBsb3Qgb2YgYXR0ZW50aW9uIGZyb20gdGhlPG86cD48L286cD48 L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyBuZXR3b3JraW5nIGluZHVzdHJ5LiBTb21lIG9mIHRoZSBtb3N0IHB1YmxpY2l6ZWQgcmVx dWlyZW1lbnRzIGFyZTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5bGU9InBhZ2UtYnJl YWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgcmVsYXRlZCB0byB0aGUgZXZvbHV0aW9uIG9m IHRoZSBDbG91ZCBOZXR3b3JraW5nIEluZnJhc3RydWN0dXJlIHRvPG86cD48L286cD48L3NwYW4+ PC9wcmU+PHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBh Y2NvbW1vZGF0ZSBhIGxhcmdlIG51bWJlciBvZiB0ZW5hbnRzLCBlZmZpY2llbnQgbmV0d29yayB1 dGlsaXphdGlvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlIHN0eWxlPSJwYWdlLWJyZWFr LWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHNjYWxhYmxlIGxvb3AgYXZvaWRhbmNlLCBhbmQg VmlydHVhbCBNYWNoaW5lIE1vYmlsaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5 bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By ZT48cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IFRoaXMg ZHJhZnQgZGVzY3JpYmVzIGEgZnJhbWV3b3JrIGZvciBjbG91ZCBuZXR3b3JraW5nLCBoaWdobGln aHRpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT48cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9y ZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7IHRoZSBhcHBsaWNhYmlsaXR5IG9mIGV4aXN0aW5nIHdvcmsg aW4gdmFyaW91cyBJRVRGIFdvcmtpbmcgR3JvdXBzPG86cD48L286cD48L3NwYW4+PC9wcmU+PHBy ZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyAoZS5nLiwgUkZD cyBhbmQgZHJhZnRzIGRldmVsb3BlZCBpbiBJRVRGIEwyVlBOIGFuZCBMM1ZQTiBXb3JraW5nPG86 cD48L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlz Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PiZuYnNwOyZuYnNwOyBHcm91cHMpIHRvIGNsb3VkIG5ldHdvcmtpbmcsIGFuZCB0aGUgZ2FwcyBh bmQgcHJvYmxlbXMgdGhhdCBuZWVkIHRvPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHls ZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBiZSBmdXJ0aGVyIGFkZHJl c3NlZC4gVGhhdCBpcywgdGhlIGdvYWwgaXMgdG8gdW5kZXJzdGFuZCB3aGF0IG1heSBiZTxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgcmUtdXNlZCBmcm9tIHRoZSBjdXJyZW50IHByb3RvY29scyBhbmQgY2FsbCBv dXQgcmVxdWlyZW1lbnRzIHNwZWNpZmljPG86cD48L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHls ZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB0byB0aGUgQ2xvdWQgc3Bh Y2UgdGhhdCBuZWVkIHRvIGJlIGFkZHJlc3NlZCBieSBuZXcgc3RhbmRhcmRpemF0aW9uPG86cD48 L286cD48L3NwYW4+PC9wcmU+PHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyB3b3JrIHdpdGggcHJvcG9zZWQgc29sdXRpb25zIGluIGNlcnRhaW4gY2FzZXMu PG86cD48L286cD48L3NwYW4+PC9wcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6IDEycHQ7IGNvbG9yOiBibGFjazsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7ICI+PGJy IGNsZWFyPSJhbGwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjwvc3Bhbj48cHJl IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5OYWJpbDxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2Pjwvc3Bhbj48L2Jv ZHk+PC9odG1sPg0K --_000_CADE5C802D069nabilnbitarverizoncom_-- From florin.balus@alcatel-lucent.com Tue Nov 8 13:34:34 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D6D11E80B1; Tue, 8 Nov 2011 13:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[AWL=-2.402, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nDoJaWIN+Y3S; Tue, 8 Nov 2011 13:34:33 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id E93F611E80AD; Tue, 8 Nov 2011 13:34:32 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id pA8LYJlu007812 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Nov 2011 15:34:19 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pA8LYH57002179 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 8 Nov 2011 15:34:18 -0600 Received: from USNAVSXCHMBSC3.ndc.alcatel-lucent.com ([135.3.39.144]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Tue, 8 Nov 2011 15:34:18 -0600 From: "Balus, Florin Stelian (Florin)" To: Xuxiaohu , "Bitar, Nabil N" , "l3vpn@ietf.org" , "l2vpn@ietf.org" Date: Tue, 8 Nov 2011 15:34:10 -0600 Subject: RE: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-Topic: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-Index: Acyd2R8rhSQNYlfHQ16DQ3Td7RyeUQAC+SpwABxhHfA= Message-ID: <2073A6C5467C99478898544C6EBA3F4602BD5D2CF4@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74774D@szxeml525-mbs.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74774D@szxeml525-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2073A6C5467C99478898544C6EBA3F4602BD5D2CF4USNAVSXCHMBSC_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "y.ikejiri@ntt.com" , "Luyuan Fang \(lufang\)" , Sagessi , "mircea.pisica@bt.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Nov 2011 21:34:34 -0000 --_000_2073A6C5467C99478898544C6EBA3F4602BD5D2CF4USNAVSXCHMBSC_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgY29tbWVudHMsIHNlZSBpbi1saW5loa0NCg0KRnJvbTogbDJ2cG4tYm91 bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBYdXhpYW9odQ0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAwNywgMjAxMSAxMTo1MyBQTQ0KVG86 IEJpdGFyLCBOYWJpbCBOOyBsM3ZwbkBpZXRmLm9yZzsgbDJ2cG5AaWV0Zi5vcmcNCkNjOiBMdXl1 YW4gRmFuZyAobHVmYW5nKTsgU2FnZXNzaTsgeS5pa2VqaXJpQG50dC5jb207IG1pcmNlYS5waXNp Y2FAYnQuY29tDQpTdWJqZWN0OiByZTogWW91ciBpbnB1dCBvbiB0aGUgZm9sbG93aW5nIGRyYWZ0 IGlzIGFwcHJlY2lhdGVkOiBkcmFmdC1iaXRhci1kYXRhY2VudGVyLXZwbi1hcHBsaWNhYmlsaXR5 LTAxLnR4dA0KDQpIaSBOYWJpbCwNCg0KSXShr3MgYSB2ZXJ5IGNvbXByZWhlbnNpdmUgZG9jLg0K DQpTb21lIGNvbW1vbnM6DQoNCjGhoiAgSW4gc2VjdGlvbiA2LjEsIGl0IHNhaWQ6IKGwQXMgdGhl IG51bWJlciBvZiB0ZW5hbnRzIGluIGluZGl2aWR1YWwgVkxBTiBpc2xhbmRzIHN1cnBhc3NlcyA0 SywgdGhlIG9wZXJhdG9yIGNvdWxkIHB1c2ggVlBMUyBkZXBsb3ltZW50IGRlZXBlciBpbiB0aGUg REMgbmV0d29ya6GtLiBUaGUgVG9SIGFuZCBEQyBjb3JlIGVsZW1lbnRzIG5lZWQgdG8gYmUgTVBM UyBlbmFibGVkIHdpdGggZXhpc3RpbmcgVlBMUyBzb2x1dGlvbnOhsSwgSU1ITywgREMgY29yZSBz d2l0Y2hlcyBkb26hr3QgbmVlZCB0byBiZSBNUExTIGVuYWJsZWQgc2luY2UgSVAgYmFzZWQgdHVu bmVsIGlzIGFsc28gYXZhaWxhYmxlLg0KDQoNCg0KRkI+IFlvdSBhcmUgcmlnaHQgd2Ugc2hvdWxk IGhhdmUgc2FpZCChsElQIG9yIE1QTFMgZW5hYmxlZKGxIGFzIGJvdGggY2FzZXMgYXJlIHBvc3Np Ymxloa0NCg0KDQoNCjKhoiAgU3RpbGwgaW4gc2VjdGlvbiA2LjEsIGl0IHNhaWQ6IKGxIKGtSG93 ZXZlciwgdGhpcyBtb2RlbCBkb2VzIG5vdCBzb2x2ZSB0aGUgTUFDIGV4cGxvc2lvbiBpc3N1ZSBh cyBUb1JzIHN0aWxsIG5lZWQgdG8gbGVhcm4gVk0gTUFDIGFkZHJlc3Nlcy6hsSBIb3dldmVyLCBp biBzZWN0aW9uIDYuMi4xLCBpdCBzYWlkOqGxoa1BbHRlcm5hdGl2ZWx5LCB0aGUgUEJCIGVuY2Fw c3VsYXRpb24gY2FuIGJlIGRvbmUgYXQgdGhlIFRvUi6hsSAgSXQgaXMgY29uZnVzZWQgc2luY2Ug cGVyZm9ybWluZyBQQkIgZW5jYXBzdWxhdGlvbiBhdCB0aGUgVG9SIHdvdWxkIG5vdCBhbGxldmlh dGUgdGhlIE1BQy1sZWFybmluZyBidXJkZW4gb24gdGhhdCBUb1IuDQoNCg0KDQpGQj4gTWF5YmUg dGhlIHBocmFzZSBsb2NhdGlvbiBpcyBwdXp6bGluZy4gVGhlIGZvY3VzIG9mIHNlY3Rpb24gNi4y IGlzIHRoZSB1c2Ugb2YgYW4gZXh0ZW5kZWQgMjRiIFBCQiBJLUlTSUQgdGFnIHN0YXJ0aW5nIGF0 IHRoZSBWU3cgdG8gaWRlbnRpZnkgdGhlIEVMQU4gYnJvYWRjYXN0IGRvbWFpbi4NCg0KVGhpcyB3 aWxsIG1heGltaXplIHRoZSBiZW5lZml0cy4gSG93ZXZlciBpbiByZWFsaXR5IGl0IGlzIHZlcnkg bGlrZWx5IHRoZXJlIHdpbGwgYmUgbGVnYWN5IERDIHJlZ2lvbnMgc3RpbGwgcnVubmluZyBWTEFO cyB3aGljaCByZXF1aXJlIGEgR2F0ZXdheSBmdW5jdGlvbiBkdXJpbmcgdGhlIG1pZ3JhdGlvbi4g U2VlIHRoZSBWTEFOIEludGVyb3AgZGlzY3Vzc2lvbiBpbiBzZWN0aW9uIDYuMi45Lg0KDQoNCg0K M6GiICBJbiA2LjIuNi4yLiBQQkJOIGluIFZTdywgTDJWUE4gaW4gdGhlIFRvUiwgaXQgc2FpZDqh sSBUaGUgcHJvY2VkdXJlcyBmcm9tIHRoZSBwcmV2aW91cyBzZWN0aW9uIGFyZSB1c2VkIGF0IHRo ZSBWU3c6IFBCQiBlbmNhcHN1bGF0aW9uIGFuZCBFdGhlcm5ldCBCVkxBTnMgY2FuIGJlIHVzZWQg b24gdGhlIFZTdyB1cGxpbmsuIEwyVlBOIGluZnJhc3RydWN0dXJlIGlzIHJlcGxhY2luZyB0aGUg QlZMQU4gYXQgdGhlIFRvUiBlbmFibGluZyB0aGUgdXNlIG9mIElQIChHUkUgb3IgTDJUUCkgb3Ig TVBMUyB0dW5uZWxpbmcuDQoNCg0KDQpGQj4gVGhpcyBpcyBhYm91dCB0aGUgdHVubmVsaW5nIGVu Y2Fwc3VsYXRpb24gb3B0aW9ucyB0byBiZSB1c2VkIGluIHRoZSBjb3JlOiAyNGIgSS1TSUQgdGFn IGlzIHRoZSBjb21tb24gdGVuYW50IElEIHdoaWNoIGNhbiBiZSB0cmFuc3BvcnRlZCBvdmVyIGFu IEV0aGVybmV0IG9yIGFuIElQIG9yIGFuIE1QTFMgYmFzZWQgREMgbmV0d29yay4gQ29tYmluYXRp b25zIG9mIHRoZXNlIHR1bm5lbGluZyBvcHRpb25zIGFyZSBhbHNvIHBvc3NpYmxlOiBlLmcuIG9u ZSBEQyBtYXkgYmUgRXRoZXJuZXQgYmFzZWQgdGhlIG90aGVyIElQIGJhc2VkOyBvciB0aGUgVlN3 IG1heSB1c2UgRXRoZXJuZXQgVkxBTiB0dW5uZWxzIHdoaWxlIElQIHR1bm5lbHMgbWF5IHN0YXJ0 IGF0IHRoZSBUb1IuDQoNCg0KDQogTDIgbmV0d29ya2luZyBzdGlsbCBoYXMgdGhlIHNhbWUgY29u dHJvbCBwbGFuZSBjaG9pY2VzOiBJUy1JUyBbODAyLjFhcV0gYW5kL29yIEJHUCBbUEJCLUVWUE5d LCBpbmRlcGVuZGVudGx5IGZyb20gdGhlIHR1bm5lbGluZyBjaG9pY2UuobEgU2luY2UgUEJCIGVu Y2Fwc3VsYXRpb24gaGFzIGFscmVhZHkgYmVlbiBkb25lIG9uIHRoZSBWU3csIHdoeSBkbyB3ZSBz dGlsbCBuZWVkIHRvIHJ1biA4MDIuMWFxIGFuZCBQQkItRVZQTiB3aXRoIGFub3RoZXIgUEJCIGVu Y2Fwc3VsYXRpb24gbGF5ZXI/DQoNCg0KDQpGQj4gTm8gbmVlZCBmb3IgYW4gYWRkaXRpb25hbCBQ QkIgZW5jYXBzdWxhdGlvbiBsYXllciEgVGhpcyBpcyBzdHJpY3RseSBhYm91dCBjb250cm9sIHBs YW5lIG9wdGlvbnM6IElTLUlTIGFuZCBCR1AgYXJlIHVzZWQgdGhlIHNhbWUgd2F5IGFzIGluIHJl Z3VsYXIgSVAgcm91dGluZyB0byBwZXJmb3JtIE11bHRpcGF0aGluZywgRmFzdCBDb252ZXJnZW5j ZSwgc2VydmljZSBBRCwgcHJvZ3JhbSB0aGUgY29yZSBGSUJzIGV0Y6GtDQoNCg0KDQogQ2Fuoa90 IHdlIHNpbXBseSB1c2UgYW55IEwyVlBOIHRlY2hub2xvZ3ksIGUuZy4sIFZQTFMuIEluIGFkZGl0 aW9uLCBub3RlIHRoYXQgaW4gRmlndXJlIDUsIGl0IHNhaWQgobBpbnRyYS1EQyBMMlZQTiBvdmVy IElQIG9yIE1QTFMgdHVubmVsaW5nobEuDQoNCg0KRkI+IHllcyB5b3UgY2FuLiBXZSBqdXN0IGZv Y3VzZWQgaGVyZSBvbiB0aGUgb3B0aW9ucyB0aGF0IHdpbGwgYWRkcmVzcyB0aGUgY2hhbGxlbmdl cyBkZXNjcmliZWQgaW4gdGhlIHByb2JsZW0gc3RhdGVtZW50IHNlY3Rpb24uIE90aGVyd2lzZSB0 aGUgY29udGVudCB3aWxsIGhhdmUgZ3Jvd24gdG9vIG11Y2guDQoNCg0KQmVzdCByZWdhcmRzLA0K WGlhb2h1DQoNCreivP7IyzogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJv dW5jZXNAaWV0Zi5vcmddILT6se0gQml0YXIsIE5hYmlsIE4NCreiy83KsbzkOiAyMDExxOoxMdTC OMjVIDEzOjQyDQrK1bz+yMs6IGwzdnBuQGlldGYub3JnOyBsMnZwbkBpZXRmLm9yZw0Ks63LzTog U2FnZXNzaTsgbWlyY2VhLnBpc2ljYUBidC5jb207IEx1eXVhbiBGYW5nIChsdWZhbmcpOyB5Lmlr ZWppcmlAbnR0LmNvbQ0K1vfM4jogWW91ciBpbnB1dCBvbiB0aGUgZm9sbG93aW5nIGRyYWZ0IGlz IGFwcHJlY2lhdGVkOiBkcmFmdC1iaXRhci1kYXRhY2VudGVyLXZwbi1hcHBsaWNhYmlsaXR5LTAx LnR4dA0KDQpIaSwNCldlIGhhZCBzdWJtaXR0ZWQgdGhlIGZvbGxvd2luZyBkcmFmdCBvbiB2cG4g YXBwbGljYWJpbGl0eSBmb3IgZGF0YSBjZW50ZXIuIFlvdXIgaW5wdXQgb24gdGhlIGRyYWZ0IGlz IGFwcHJlY2lhdGVkIGluIGxpZ2h0IG9mIHNvbWUgb2YgdGhlIG9uZ29pbmcgZGlzY3Vzc2lvbi4g VGhlIGRyYWZ0IGlzIHRhcmdldGVkIGZvciBsM3ZwbiBhbmQgbDJ2cG4uDQpIZXJlIGlzIHRoZSBs aW5rOg0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaXRhci1kYXRhY2VudGVy LXZwbi1hcHBsaWNhYmlsaXR5LTAxDQoNCg0KQWJzdHJhY3QNCg0KDQoNCiAgIENsb3VkIENvbXB1 dGluZyBoYXMgYmVlbiBhdHRyYWN0aW5nIGEgbG90IG9mIGF0dGVudGlvbiBmcm9tIHRoZQ0KDQog ICBuZXR3b3JraW5nIGluZHVzdHJ5LiBTb21lIG9mIHRoZSBtb3N0IHB1YmxpY2l6ZWQgcmVxdWly ZW1lbnRzIGFyZQ0KDQogICByZWxhdGVkIHRvIHRoZSBldm9sdXRpb24gb2YgdGhlIENsb3VkIE5l dHdvcmtpbmcgSW5mcmFzdHJ1Y3R1cmUgdG8NCg0KICAgYWNjb21tb2RhdGUgYSBsYXJnZSBudW1i ZXIgb2YgdGVuYW50cywgZWZmaWNpZW50IG5ldHdvcmsgdXRpbGl6YXRpb24sDQoNCiAgIHNjYWxh YmxlIGxvb3AgYXZvaWRhbmNlLCBhbmQgVmlydHVhbCBNYWNoaW5lIE1vYmlsaXR5Lg0KDQoNCg0K ICAgVGhpcyBkcmFmdCBkZXNjcmliZXMgYSBmcmFtZXdvcmsgZm9yIGNsb3VkIG5ldHdvcmtpbmcs IGhpZ2hsaWdodGluZw0KDQogICB0aGUgYXBwbGljYWJpbGl0eSBvZiBleGlzdGluZyB3b3JrIGlu IHZhcmlvdXMgSUVURiBXb3JraW5nIEdyb3Vwcw0KDQogICAoZS5nLiwgUkZDcyBhbmQgZHJhZnRz IGRldmVsb3BlZCBpbiBJRVRGIEwyVlBOIGFuZCBMM1ZQTiBXb3JraW5nDQoNCiAgIEdyb3Vwcykg dG8gY2xvdWQgbmV0d29ya2luZywgYW5kIHRoZSBnYXBzIGFuZCBwcm9ibGVtcyB0aGF0IG5lZWQg dG8NCg0KICAgYmUgZnVydGhlciBhZGRyZXNzZWQuIFRoYXQgaXMsIHRoZSBnb2FsIGlzIHRvIHVu ZGVyc3RhbmQgd2hhdCBtYXkgYmUNCg0KICAgcmUtdXNlZCBmcm9tIHRoZSBjdXJyZW50IHByb3Rv Y29scyBhbmQgY2FsbCBvdXQgcmVxdWlyZW1lbnRzIHNwZWNpZmljDQoNCiAgIHRvIHRoZSBDbG91 ZCBzcGFjZSB0aGF0IG5lZWQgdG8gYmUgYWRkcmVzc2VkIGJ5IG5ldyBzdGFuZGFyZGl6YXRpb24N Cg0KICAgd29yayB3aXRoIHByb3Bvc2VkIHNvbHV0aW9ucyBpbiBjZXJ0YWluIGNhc2VzLg0KDQoN ClRoYW5rcywNCg0KTmFiaWwNCg== --_000_2073A6C5467C99478898544C6EBA3F4602BD5D2CF4USNAVSXCHMBSC_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Thanks for the comments, see in-line=A1=AD=

 

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of = Xuxiaohu
Sent: Monday, November 07, 2011 11:53 PM
To: Bitar, Nabil N; l3vpn@ietf.org; l2vpn@ietf.org
Cc: Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com; mircea.pisica@bt.com
Subject: re: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt

 

Hi Nabil,

 

It=A1=AFs a very comprehensive doc.

 

Some commons:

1=A1=A2  In section 6.1, it said: =A1=B0As the number of tenants in individual VLAN=
 islands surpasses 4K, the operator could push VPLS deployment deeper in th=
e DC network=A1=AD. The ToR and DC core elements need to be MPLS enabled wi=
th existing VPLS solutions=A1=B1, IMHO, DC core switches don=A1=AFt need to=
 be MPLS enabled since IP based tunnel is also available.=

 
FB> You are right we should hav= e said =A1=B0IP or MPLS enabled=A1=B1 as both cases are possible=A1=AD 
 
2=A1=A2  Still in section 6.1, it said: =A1=B1 =A1=ADHowever, this model does not s= olve the MAC explosion issue as ToRs still need to learn VM MAC addresses.= =A1=B1 However, in section 6.2.1, it said:=A1=B1=A1=ADAlternatively, the PB= B encapsulation can be done at the ToR.=A1=B1  It is confused since pe= rforming PBB encapsulation at the ToR would not alleviate the MAC-learning = burden on that ToR.
 
FB> Maybe the phrase location i= s puzzling. The focus of section 6.2 is the use of an extended 24b PBB I-IS= ID tag starting at the VSw to identify the ELAN broadcast domain. 
This will maximize the benefits. H=
owever in reality it is very likely there will be legacy DC regions still r=
unning VLANs which require a Gateway function during the migration. See the=
 VLAN Interop discussion in section 6.2.9. 
 <=
/pre>
3=A1=A2  In 6.2.6.2. PBBN in VSw, L2VPN in the ToR, it said:=
=A1=B1 The procedures from the previous section are used at the VSw: PBB encapsul=
ation and Ethernet BVLANs can be used on the VSw uplink. L2VPN infrastructu=
re is replacing the BVLAN at the ToR enabling the use of IP (GRE or L2TP) o=
r MPLS tunneling. 
 
FB> This is about the tunneling=
 encapsulation options to be used in the core: 24b I-SID tag is the common =
tenant ID which can be transported over an Ethernet or an IP or an MPLS bas=
ed DC network. Combinations of these tunneling options are also possible: e=
.g. one DC may be Ethernet based the other IP based; or the VSw may use Eth=
ernet VLAN tunnels while IP tunnels may start at the ToR.=

 
L2 networking still has = the same control plane choices: IS-IS [802.1aq] and/or BGP [PBB-EVPN], inde= pendently from the tunneling choice.=A1=B1 Since PBB encapsulation has alre= ady been done on the VSw, why do we still need to run 802.1aq and PBB-EVPN = with another PBB encapsulation layer?
 
FB> No need for an additional P= BB encapsulation layer! This is strictly about control plane options: IS-IS= and BGP are used the same way as in regular IP routing to perform Multipat= hing, Fast Convergence, service AD, program the core FIBs etc=A1=AD
 <=
/pre>
 Can=A1=AFt we simply use=
 any L2VPN technology, e.g., VPLS. In addition, note that in Figure 5, it s=
aid =A1=B0intra-DC L2VPN over IP or MPLS tunneling=A1=B1.=




 



FB> yes you can. We just focused here on the options that will addre=
ss the challenges described in the problem statement section. Otherwise the=
 content will have grown too much.



 



 



Best regards,



Xiaohu



 












=B7=A2=BC=FE=C8=CB:
l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] =B4=FA=
=B1=ED Bitar, Nabil N

=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C28=C8=D5 13:42

=CA=D5=BC=FE=C8=CB: l3vpn@ietf.org; l2vpn@ietf.org

=B3=AD=CB=CD: Sagessi; mircea.pisica@bt.com; Luyuan Fang
(lufang); y.ikejiri@ntt.com

=D6=F7=CC=E2: Your input on the following draft is appreciate=
d:
draft-bitar-datacenter-vpn-applicability-01.txt









 






Hi,









We had submitted the following draft on vpn applicability for =
data
center. Your input on the draft is appreciated in light of some of the ongo=
ing
discussion. The draft is targeted for l3vpn and l2vpn.








Here is the link: 









 











 






Abstract
 
   Cloud Computing has been attracting a lot of attention fr=
om the
   networking industry. Some of the most publicized requirem=
ents are
   related to the evolution of the Cloud Networking Infrastr=
ucture to
   accommodate a large number of tenants, efficient network =
utilization,
   scalable loop avoidance, and Virtual Machine Mobility.
 
   This draft describes a framework for cloud networking, hi=
ghlighting
   the applicability of existing work in various IETF Workin=
g Groups
   (e.g., RFCs and drafts developed in IETF L2VPN and L3VPN =
Working
   Groups) to cloud networking, and the gaps and problems th=
at need to
   be further addressed. That is, the goal is to understand =
what may be
   re-used from the current protocols and call out requireme=
nts specific
   to the Cloud space that need to be addressed by new stand=
ardization
   work with proposed solutions in certain cases.=




Thanks,
Nabil
--_000_2073A6C5467C99478898544C6EBA3F4602BD5D2CF4USNAVSXCHMBSC_-- From xuxiaohu@huawei.com Tue Nov 8 17:55:00 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7451921F893C; Tue, 8 Nov 2011 17:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8yG6NV1-QEF; Tue, 8 Nov 2011 17:54:59 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8A4EC21F8922; Tue, 8 Nov 2011 17:54:58 -0800 (PST) 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 <0LUD00FPSEN13D@szxga03-in.huawei.com>; Wed, 09 Nov 2011 09:54:37 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUD00DK0EN14A@szxga03-in.huawei.com>; Wed, 09 Nov 2011 09:54:37 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEV51330; Wed, 09 Nov 2011 09:54:34 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 09 Nov 2011 09:54:28 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0270.001; Wed, 09 Nov 2011 09:54:22 +0800 Date: Wed, 09 Nov 2011 01:54:22 +0000 From: Xuxiaohu Subject: re: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt In-reply-to: <2073A6C5467C99478898544C6EBA3F4602BD5D2CF4@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> X-Originating-IP: [10.108.4.59] To: "Balus, Florin Stelian (Florin)" , "Bitar, Nabil N" , "l3vpn@ietf.org" , "l2vpn@ietf.org" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE747C00@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_MJVV+Xg41PwZ5j6Kuj9Qhw)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-index: Acyd2R8rhSQNYlfHQ16DQ3Td7RyeUQAC+SpwABxhHfAACrvcUA== X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Bt1U EXY7 MTnc NOSF TZfN Y6wx dEGO dVPN gTEc kYLh 3TCM 6xTX ACIKHA== ADE1vw== ADc1hg== AFePCw==; 8; ZgBsAG8AcgBpAG4ALgBiAGEAbAB1AHMAQABhAGwAYwBhAHQAZQBsAC0AbAB1AGMAZQBuAHQALgBjAG8AbQA7AGwAMgB2AHAAbgBAAGkAZQB0AGYALgBvAHIAZwA7AGwAMwB2AHAAbgBAAGkAZQB0AGYALgBvAHIAZwA7AGwAdQBmAGEAbgBnAEAAYwBpAHMAYwBvAC4AYwBvAG0AOwBtAGkAcgBjAGUAYQAuAHAAaQBzAGkAYwBhAEAAYgB0AC4AYwBvAG0AOwBuAGEAYgBpAGwALgBuAC4AYgBpAHQAYQByAEAAdgBlAHIAaQB6AG8AbgAuAGMAbwBtADsAcwBhAGoAYQBzAHMAaQBAAGMAaQBzAGMAbwAuAGMAbwBtADsAeQAuAGkAawBlAGoAaQByAGkAQABuAHQAdAAuAGMAbwBtAA==; Sosha1_v1; 7; {4EC2E246-5519-4E3C-B755-44DA9563B63A}; eAB1AHgAaQBhAG8AaAB1AEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Wed, 09 Nov 2011 02:08:14 GMT; cgBlADoAIABZAG8AdQByACAAaQBuAHAAdQB0ACAAbwBuACAAdABoAGUAIABmAG8AbABsAG8AdwBpAG4AZwAgAGQAcgBhAGYAdAAgAGkAcwAgAGEAcABwAHIAZQBjAGkAYQB0AGUAZAA6AAkAZAByAGEAZgB0AC0AYgBpAHQAYQByAC0AZABhAHQAYQBjAGUAbgB0AGUAcgAtAHYAcABuAC0AYQBwAHAAbABpAGMAYQBiAGkAbABpAHQAeQAtADAAMQAuAHQAeAB0AA== x-cr-puzzleid: {4EC2E246-5519-4E3C-B755-44DA9563B63A} X-CFilter-Loop: Reflected References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74774D@szxeml525-mbs.china.huawei.com> <2073A6C5467C99478898544C6EBA3F4602BD5D2CF4@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> Cc: "y.ikejiri@ntt.com" , "Luyuan Fang \(lufang\)" , Sagessi , "mircea.pisica@bt.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 01:55:00 -0000 --Boundary_(ID_MJVV+Xg41PwZ5j6Kuj9Qhw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 t6K8/sjLOiBCYWx1cywgRmxvcmluIFN0ZWxpYW4gKEZsb3JpbikgW21haWx0bzpmbG9yaW4uYmFs dXNAYWxjYXRlbC1sdWNlbnQuY29tXQ0Kt6LLzcqxvOQ6IDIwMTHE6jEx1MI5yNUgNTozNA0KytW8 /sjLOiBYdXhpYW9odTsgQml0YXIsIE5hYmlsIE47IGwzdnBuQGlldGYub3JnOyBsMnZwbkBpZXRm Lm9yZw0Ks63LzTogTHV5dWFuIEZhbmcgKGx1ZmFuZyk7IFNhZ2Vzc2k7IHkuaWtlamlyaUBudHQu Y29tOyBtaXJjZWEucGlzaWNhQGJ0LmNvbQ0K1vfM4jogUkU6IFlvdXIgaW5wdXQgb24gdGhlIGZv bGxvd2luZyBkcmFmdCBpcyBhcHByZWNpYXRlZDogZHJhZnQtYml0YXItZGF0YWNlbnRlci12cG4t YXBwbGljYWJpbGl0eS0wMS50eHQNCg0KVGhhbmtzIGZvciB0aGUgY29tbWVudHMsIHNlZSBpbi1s aW5loa0NCg0KRnJvbTogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBYdXhpYW9odQ0KU2VudDogTW9uZGF5LCBOb3ZlbWJl ciAwNywgMjAxMSAxMTo1MyBQTQ0KVG86IEJpdGFyLCBOYWJpbCBOOyBsM3ZwbkBpZXRmLm9yZzsg bDJ2cG5AaWV0Zi5vcmcNCkNjOiBMdXl1YW4gRmFuZyAobHVmYW5nKTsgU2FnZXNzaTsgeS5pa2Vq aXJpQG50dC5jb207IG1pcmNlYS5waXNpY2FAYnQuY29tDQpTdWJqZWN0OiByZTogWW91ciBpbnB1 dCBvbiB0aGUgZm9sbG93aW5nIGRyYWZ0IGlzIGFwcHJlY2lhdGVkOiBkcmFmdC1iaXRhci1kYXRh Y2VudGVyLXZwbi1hcHBsaWNhYmlsaXR5LTAxLnR4dA0KDQpIaSBOYWJpbCwNCg0KSXShr3MgYSB2 ZXJ5IGNvbXByZWhlbnNpdmUgZG9jLg0KDQpTb21lIGNvbW1vbnM6DQoNCjGhoiAgSW4gc2VjdGlv biA2LjEsIGl0IHNhaWQ6IKGwQXMgdGhlIG51bWJlciBvZiB0ZW5hbnRzIGluIGluZGl2aWR1YWwg VkxBTiBpc2xhbmRzIHN1cnBhc3NlcyA0SywgdGhlIG9wZXJhdG9yIGNvdWxkIHB1c2ggVlBMUyBk ZXBsb3ltZW50IGRlZXBlciBpbiB0aGUgREMgbmV0d29ya6GtLiBUaGUgVG9SIGFuZCBEQyBjb3Jl IGVsZW1lbnRzIG5lZWQgdG8gYmUgTVBMUyBlbmFibGVkIHdpdGggZXhpc3RpbmcgVlBMUyBzb2x1 dGlvbnOhsSwgSU1ITywgREMgY29yZSBzd2l0Y2hlcyBkb26hr3QgbmVlZCB0byBiZSBNUExTIGVu YWJsZWQgc2luY2UgSVAgYmFzZWQgdHVubmVsIGlzIGFsc28gYXZhaWxhYmxlLg0KDQoNCg0KRkI+ IFlvdSBhcmUgcmlnaHQgd2Ugc2hvdWxkIGhhdmUgc2FpZCChsElQIG9yIE1QTFMgZW5hYmxlZKGx IGFzIGJvdGggY2FzZXMgYXJlIHBvc3NpYmxloa0NCg0KDQoNCjxYWEg+IEdvb2QgcG9pbnQuDQoN Cg0KDQoyoaIgIFN0aWxsIGluIHNlY3Rpb24gNi4xLCBpdCBzYWlkOiChsSChrUhvd2V2ZXIsIHRo aXMgbW9kZWwgZG9lcyBub3Qgc29sdmUgdGhlIE1BQyBleHBsb3Npb24gaXNzdWUgYXMgVG9ScyBz dGlsbCBuZWVkIHRvIGxlYXJuIFZNIE1BQyBhZGRyZXNzZXMuobEgSG93ZXZlciwgaW4gc2VjdGlv biA2LjIuMSwgaXQgc2FpZDqhsaGtQWx0ZXJuYXRpdmVseSwgdGhlIFBCQiBlbmNhcHN1bGF0aW9u IGNhbiBiZSBkb25lIGF0IHRoZSBUb1IuobEgIEl0IGlzIGNvbmZ1c2VkIHNpbmNlIHBlcmZvcm1p bmcgUEJCIGVuY2Fwc3VsYXRpb24gYXQgdGhlIFRvUiB3b3VsZCBub3QgYWxsZXZpYXRlIHRoZSBN QUMtbGVhcm5pbmcgYnVyZGVuIG9uIHRoYXQgVG9SLg0KDQoNCg0KRkI+IE1heWJlIHRoZSBwaHJh c2UgbG9jYXRpb24gaXMgcHV6emxpbmcuIFRoZSBmb2N1cyBvZiBzZWN0aW9uIDYuMiBpcyB0aGUg dXNlIG9mIGFuIGV4dGVuZGVkIDI0YiBQQkIgSS1JU0lEIHRhZyBzdGFydGluZyBhdCB0aGUgVlN3 IHRvIGlkZW50aWZ5IHRoZSBFTEFOIGJyb2FkY2FzdCBkb21haW4uDQoNCg0KDQo8WFhIPiBUaGUg dGl0bGUgb2Ygc2VjdGlvbiA2LjIuMSBpcyChsEFkZHJlc3NpbmcgVkxBTiBzcGFjZSBleGhhdXN0 aW9uIGFuZCBNQUMgZXhwbG9zaW9uobEuIFNvIEkgdGhpbmsgc2F5aW5nIG1vcmUgd29yZHMgYWZ0 ZXIgdGhhdCBzZW50ZW5jZSBpcyBtdWNoIGhlbHBmdWwgaW4gYXZvaWRpbmcgY29uZnVzaW9uLg0K DQoNCg0KDQoNClRoaXMgd2lsbCBtYXhpbWl6ZSB0aGUgYmVuZWZpdHMuIEhvd2V2ZXIgaW4gcmVh bGl0eSBpdCBpcyB2ZXJ5IGxpa2VseSB0aGVyZSB3aWxsIGJlIGxlZ2FjeSBEQyByZWdpb25zIHN0 aWxsIHJ1bm5pbmcgVkxBTnMgd2hpY2ggcmVxdWlyZSBhIEdhdGV3YXkgZnVuY3Rpb24gZHVyaW5n IHRoZSBtaWdyYXRpb24uIFNlZSB0aGUgVkxBTiBJbnRlcm9wIGRpc2N1c3Npb24gaW4gc2VjdGlv biA2LjIuOS4NCg0KDQoNCjOhoiAgSW4gNi4yLjYuMi4gUEJCTiBpbiBWU3csIEwyVlBOIGluIHRo ZSBUb1IsIGl0IHNhaWQ6obEgVGhlIHByb2NlZHVyZXMgZnJvbSB0aGUgcHJldmlvdXMgc2VjdGlv biBhcmUgdXNlZCBhdCB0aGUgVlN3OiBQQkIgZW5jYXBzdWxhdGlvbiBhbmQgRXRoZXJuZXQgQlZM QU5zIGNhbiBiZSB1c2VkIG9uIHRoZSBWU3cgdXBsaW5rLiBMMlZQTiBpbmZyYXN0cnVjdHVyZSBp cyByZXBsYWNpbmcgdGhlIEJWTEFOIGF0IHRoZSBUb1IgZW5hYmxpbmcgdGhlIHVzZSBvZiBJUCAo R1JFIG9yIEwyVFApIG9yIE1QTFMgdHVubmVsaW5nLg0KDQoNCg0KRkI+IFRoaXMgaXMgYWJvdXQg dGhlIHR1bm5lbGluZyBlbmNhcHN1bGF0aW9uIG9wdGlvbnMgdG8gYmUgdXNlZCBpbiB0aGUgY29y ZTogMjRiIEktU0lEIHRhZyBpcyB0aGUgY29tbW9uIHRlbmFudCBJRCB3aGljaCBjYW4gYmUgdHJh bnNwb3J0ZWQgb3ZlciBhbiBFdGhlcm5ldCBvciBhbiBJUCBvciBhbiBNUExTIGJhc2VkIERDIG5l dHdvcmsuIENvbWJpbmF0aW9ucyBvZiB0aGVzZSB0dW5uZWxpbmcgb3B0aW9ucyBhcmUgYWxzbyBw b3NzaWJsZTogZS5nLiBvbmUgREMgbWF5IGJlIEV0aGVybmV0IGJhc2VkIHRoZSBvdGhlciBJUCBi YXNlZDsgb3IgdGhlIFZTdyBtYXkgdXNlIEV0aGVybmV0IFZMQU4gdHVubmVscyB3aGlsZSBJUCB0 dW5uZWxzIG1heSBzdGFydCBhdCB0aGUgVG9SLg0KDQoNCg0KPFhYSD4gWWVzLCBJIGFncmVlIHdp dGggeW91ciBzdGF0ZW1lbnQgYWJvdmUuIEFkZGluZyB0aGUgYWJvdmUgdGV4dCBpbnRvIHRoZSBk cmFmdCB3b3VsZCBiZSBtdWNoIGhlbHBmdWw6KQ0KDQoNCg0KIEwyIG5ldHdvcmtpbmcgc3RpbGwg aGFzIHRoZSBzYW1lIGNvbnRyb2wgcGxhbmUgY2hvaWNlczogSVMtSVMgWzgwMi4xYXFdIGFuZC9v ciBCR1AgW1BCQi1FVlBOXSwgaW5kZXBlbmRlbnRseSBmcm9tIHRoZSB0dW5uZWxpbmcgY2hvaWNl LqGxIFNpbmNlIFBCQiBlbmNhcHN1bGF0aW9uIGhhcyBhbHJlYWR5IGJlZW4gZG9uZSBvbiB0aGUg VlN3LCB3aHkgZG8gd2Ugc3RpbGwgbmVlZCB0byBydW4gODAyLjFhcSBhbmQgUEJCLUVWUE4gd2l0 aCBhbm90aGVyIFBCQiBlbmNhcHN1bGF0aW9uIGxheWVyPw0KDQoNCg0KRkI+IE5vIG5lZWQgZm9y IGFuIGFkZGl0aW9uYWwgUEJCIGVuY2Fwc3VsYXRpb24gbGF5ZXIhIFRoaXMgaXMgc3RyaWN0bHkg YWJvdXQgY29udHJvbCBwbGFuZSBvcHRpb25zOiBJUy1JUyBhbmQgQkdQIGFyZSB1c2VkIHRoZSBz YW1lIHdheSBhcyBpbiByZWd1bGFyIElQIHJvdXRpbmcgdG8gcGVyZm9ybSBNdWx0aXBhdGhpbmcs IEZhc3QgQ29udmVyZ2VuY2UsIHNlcnZpY2UgQUQsIHByb2dyYW0gdGhlIGNvcmUgRklCcyBldGOh rQ0KDQoNCg0KPFhYSD4gQWJzb2x1dGVseSBhZ3JlZS4gU3VjaCBiZWluZyB0aGUgY2FzZSwgd2h5 IG5vdCByZW1vdmUgdGhlIHR3byBzcGVjaWZpYyBleGFtcGxlcyAoYm90aCBvZiB0aGVtIGFkZCBh bm90aGVyIFBCQiBsYXllcikgZnJvbSB0aGF0IHNlbnRlbmNlIHNvIGFzIHRvIGVsaW1pbmF0ZSB0 aGUgcG9zc2libGUgY29uZnVzaW9uPw0KDQoNCg0KIENhbqGvdCB3ZSBzaW1wbHkgdXNlIGFueSBM MlZQTiB0ZWNobm9sb2d5LCBlLmcuLCBWUExTLiBJbiBhZGRpdGlvbiwgbm90ZSB0aGF0IGluIEZp Z3VyZSA1LCBpdCBzYWlkIKGwaW50cmEtREMgTDJWUE4gb3ZlciBJUCBvciBNUExTIHR1bm5lbGlu Z6GxLg0KDQoNCkZCPiB5ZXMgeW91IGNhbi4gV2UganVzdCBmb2N1c2VkIGhlcmUgb24gdGhlIG9w dGlvbnMgdGhhdCB3aWxsIGFkZHJlc3MgdGhlIGNoYWxsZW5nZXMgZGVzY3JpYmVkIGluIHRoZSBw cm9ibGVtIHN0YXRlbWVudCBzZWN0aW9uLiBPdGhlcndpc2UgdGhlIGNvbnRlbnQgd2lsbCBoYXZl IGdyb3duIHRvbyBtdWNoLg0KDQo8WFhIPiBUaGFua3MgZm9yIHlvdXIgZXhwbGFuYXRpb24uDQoN CkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQq3orz+yMs6IGwydnBuLWJvdW5jZXNAaWV0Zi5vcmcg W21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEJpdGFyLCBOYWJpbCBODQq3osvN yrG85DogMjAxMcTqMTHUwjjI1SAxMzo0Mg0KytW8/sjLOiBsM3ZwbkBpZXRmLm9yZzsgbDJ2cG5A aWV0Zi5vcmcNCrOty806IFNhZ2Vzc2k7IG1pcmNlYS5waXNpY2FAYnQuY29tOyBMdXl1YW4gRmFu ZyAobHVmYW5nKTsgeS5pa2VqaXJpQG50dC5jb20NCtb3zOI6IFlvdXIgaW5wdXQgb24gdGhlIGZv bGxvd2luZyBkcmFmdCBpcyBhcHByZWNpYXRlZDogZHJhZnQtYml0YXItZGF0YWNlbnRlci12cG4t YXBwbGljYWJpbGl0eS0wMS50eHQNCg0KSGksDQpXZSBoYWQgc3VibWl0dGVkIHRoZSBmb2xsb3dp bmcgZHJhZnQgb24gdnBuIGFwcGxpY2FiaWxpdHkgZm9yIGRhdGEgY2VudGVyLiBZb3VyIGlucHV0 IG9uIHRoZSBkcmFmdCBpcyBhcHByZWNpYXRlZCBpbiBsaWdodCBvZiBzb21lIG9mIHRoZSBvbmdv aW5nIGRpc2N1c3Npb24uIFRoZSBkcmFmdCBpcyB0YXJnZXRlZCBmb3IgbDN2cG4gYW5kIGwydnBu Lg0KSGVyZSBpcyB0aGUgbGluazoNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt Yml0YXItZGF0YWNlbnRlci12cG4tYXBwbGljYWJpbGl0eS0wMQ0KDQoNCkFic3RyYWN0DQoNCg0K DQogICBDbG91ZCBDb21wdXRpbmcgaGFzIGJlZW4gYXR0cmFjdGluZyBhIGxvdCBvZiBhdHRlbnRp b24gZnJvbSB0aGUNCg0KICAgbmV0d29ya2luZyBpbmR1c3RyeS4gU29tZSBvZiB0aGUgbW9zdCBw dWJsaWNpemVkIHJlcXVpcmVtZW50cyBhcmUNCg0KICAgcmVsYXRlZCB0byB0aGUgZXZvbHV0aW9u IG9mIHRoZSBDbG91ZCBOZXR3b3JraW5nIEluZnJhc3RydWN0dXJlIHRvDQoNCiAgIGFjY29tbW9k YXRlIGEgbGFyZ2UgbnVtYmVyIG9mIHRlbmFudHMsIGVmZmljaWVudCBuZXR3b3JrIHV0aWxpemF0 aW9uLA0KDQogICBzY2FsYWJsZSBsb29wIGF2b2lkYW5jZSwgYW5kIFZpcnR1YWwgTWFjaGluZSBN b2JpbGl0eS4NCg0KDQoNCiAgIFRoaXMgZHJhZnQgZGVzY3JpYmVzIGEgZnJhbWV3b3JrIGZvciBj bG91ZCBuZXR3b3JraW5nLCBoaWdobGlnaHRpbmcNCg0KICAgdGhlIGFwcGxpY2FiaWxpdHkgb2Yg ZXhpc3Rpbmcgd29yayBpbiB2YXJpb3VzIElFVEYgV29ya2luZyBHcm91cHMNCg0KICAgKGUuZy4s IFJGQ3MgYW5kIGRyYWZ0cyBkZXZlbG9wZWQgaW4gSUVURiBMMlZQTiBhbmQgTDNWUE4gV29ya2lu Zw0KDQogICBHcm91cHMpIHRvIGNsb3VkIG5ldHdvcmtpbmcsIGFuZCB0aGUgZ2FwcyBhbmQgcHJv YmxlbXMgdGhhdCBuZWVkIHRvDQoNCiAgIGJlIGZ1cnRoZXIgYWRkcmVzc2VkLiBUaGF0IGlzLCB0 aGUgZ29hbCBpcyB0byB1bmRlcnN0YW5kIHdoYXQgbWF5IGJlDQoNCiAgIHJlLXVzZWQgZnJvbSB0 aGUgY3VycmVudCBwcm90b2NvbHMgYW5kIGNhbGwgb3V0IHJlcXVpcmVtZW50cyBzcGVjaWZpYw0K DQogICB0byB0aGUgQ2xvdWQgc3BhY2UgdGhhdCBuZWVkIHRvIGJlIGFkZHJlc3NlZCBieSBuZXcg c3RhbmRhcmRpemF0aW9uDQoNCiAgIHdvcmsgd2l0aCBwcm9wb3NlZCBzb2x1dGlvbnMgaW4gY2Vy dGFpbiBjYXNlcy4NCg0KDQpUaGFua3MsDQoNCk5hYmlsDQo= --Boundary_(ID_MJVV+Xg41PwZ5j6Kuj9Qhw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

=B7=A2=BC=FE=C8=CB: Balus, = Florin Stelian (Florin) [mailto:florin.balus@alcatel-lucent.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C29=C8=D5 5:34
=CA=D5=BC=FE=C8=CB: Xuxiaohu; Bitar, Nabil N; l3vpn@ietf.org; l2vpn@ietf.org
=B3=AD=CB=CD: Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com; mircea.pisica@bt.com =D6=F7=CC=E2: RE: Your input on the following draft is appreciated: draft-bitar-datacen= ter-vpn-applicability-01.txt

 

Thank= s for the comments, see in-line=A1=AD

=  

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org= ] On Behalf Of Xuxiaohu
Sent: Monday, November 07, 2011 11:53 PM
To: Bitar, Nabil N; l3vpn@ietf.org; l2vpn@ietf.org
Cc: Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com; mircea.pisica@= bt.com
Subject: re: Your input on the following draft is appreciated: draft= -bitar-datacenter-vpn-applicability-01.txt

 

Hi Nabil,<= o:p>

 = ;

It=A1=AFs = a very comprehensive doc.

 = ;

Some commo= ns:

1=A1=A2  In section 6.1, it said: =A1=B0As t=
he number of tenants in individual VLAN islands surpasses 4K, the operator =
could push VPLS deployment deeper in the DC network=A1=AD. The ToR and DC c=
ore elements need to be MPLS enabled with existing VPLS solutions=A1=B1, IM=
HO, DC core switches don=A1=AFt need to be MPLS enabled since IP based tunn=
el is also available.
 
FB> You are right we should have said =A1=B0IP or MPLS enabled=
=A1=B1 as both cases are possible=A1=AD 
 
<XXH> Good point.
 
2=A1=A2  Still in section 6.1, it said: =A1=
=B1 =A1=ADHowever, this model does not solve the MAC explosion issue as ToR=
s still need to learn VM MAC addresses.=A1=B1 However, in section 6.2.1, it=
 said:=A1=B1=A1=ADAlternatively, the PBB encapsulation can be done at the T=
oR.=A1=B1  It is confused since performing PBB encapsulation at the To=
R would not alleviate the MAC-learning burden on that ToR.
 
FB> Maybe the phrase location is puzzling. The focus of sectio=
n 6.2 is the use of an extended 24b PBB I-ISID tag starting at the VSw to i=
dentify the ELAN broadcast domain. 
 
<XXH> The title of section 6.2.1 is =A1=B0Addressing VLAN spac=
e exhaustion and MAC explosion=A1=B1. So I think saying more words after th=
at sentence is much helpful in avoiding confusion.
 
 
This will maximize the benefits. However in reality it is very li=
kely there will be legacy DC regions still running VLANs which require a Ga=
teway function during the migration. See the VLAN Interop discussion in sec=
tion 6.2.9. 
 
3=A1=A2  In 6.2.=
6.2. PBBN in VSw, L2VPN in the ToR, it said:=A1=B1 The procedures from the previo=
us section are used at the VSw: PBB encapsulation and Ethernet BVLANs can b=
e used on the VSw uplink. L2VPN infrastructure is replacing the BVLAN at th=
e ToR enabling the use of IP (GRE or L2TP) or MPLS tunneling. 
 
FB> This is about the tunneling encapsulation options to be us=
ed in the core: 24b I-SID tag is the common tenant ID which can be transpor=
ted over an Ethernet or an IP or an MPLS based DC network. Combinations of =
these tunneling options are also possible: e.g. one DC may be Ethernet base=
d the other IP based; or the VSw may use Ethernet VLAN tunnels while IP tun=
nels may start at the ToR.
 
<XXH> Yes, I agree with your statement above. Adding the above=
 text into the draft would be much helpfulJ
 
 L2 networking still has the same control plane c=
hoices: IS-IS [802.1aq] and/or BGP [PBB-EVPN], independently from the tunne=
ling choice.=A1=B1 Since PBB encapsulation has already been done on the VSw=
, why do we still need to run 802.1aq and PBB-EVPN with another PBB encapsu=
lation layer?
 
FB> No need for an additional PBB encapsulation layer! This is=
 strictly about control plane options: IS-IS and BGP are used the same way =
as in regular IP routing to perform Multipathing, Fast Convergence, service=
 AD, program the core FIBs etc=A1=AD
 
<XXH> Absolutely agree. Such being the case, why not remove th=
e two specific examples (both of them add another PBB layer) from that sent=
ence so as to eliminate the possible confusion?
 
 Can=A1=AFt we simply use any L2VPN technology, e=
.g., VPLS. In addition, note that in Figure 5, it said =A1=B0intra-DC L2VPN=
 over IP or MPLS tunneling=A1=B1.

 = ;

FB> yes you can. We just focused here on th=
e options that will address the challenges described in the problem stateme=
nt section. Otherwise the content will have grown too much.

 = ;

<XXH>= ; Thanks for your explanation.

=  

Best regar= ds,

Xiaohu

 = ;

=B7=A2=BC=FE=C8=CB: l2vpn-b= ounces@ietf.org [mailto:l2vpn-bounces@ietf.org] =B4=FA= =B1=ED Bitar, Nabil N
=B7=A2= =CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C28=C8=D5 13:42
=CA=D5=BC=FE=C8=CB: l3vpn@ietf.org; l2vpn@ietf.org
=B3=AD=CB=CD: Sagessi; mircea.pisica@bt.com; Luyuan Fang (lufang); y.ikejiri@ntt.com =D6=F7=CC=E2: Your input on the following draft is appreciated: draft-bitar-datacenter-= vpn-applicability-01.txt

 

Hi,

We had submi= tted the following draft on vpn applicability for data center. Your input o= n the draft is appreciated in light of some of the ongoing discussion. The draft is targeted for l3vpn and l2vpn.

Here is the = link: 

 <= /o:p>

 <= /o:p>

Abstract

 


   Cloud Computing ha=
s been attracting a lot of attention from the


   networking industr=
y. Some of the most publicized requirements are


   related to the evo=
lution of the Cloud Networking Infrastructure to


   accommodate a larg=
e number of tenants, efficient network utilization,


   scalable loop avoi=
dance, and Virtual Machine Mobility.


 


   This draft describ=
es a framework for cloud networking, highlighting


   the applicability =
of existing work in various IETF Working Groups


   (e.g., RFCs and dr=
afts developed in IETF L2VPN and L3VPN Working


   Groups) to cloud n=
etworking, and the gaps and problems that need to


   be further address=
ed. That is, the goal is to understand what may be


   re-used from the c=
urrent protocols and call out requirements specific


   to the Cloud space=
 that need to be addressed by new standardization


   work with proposed=
 solutions in certain cases.





Thanks,


Nabil
--Boundary_(ID_MJVV+Xg41PwZ5j6Kuj9Qhw)-- From xuxiaohu@huawei.com Tue Nov 8 18:51:00 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C77C1F0C5C; Tue, 8 Nov 2011 18:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.927 X-Spam-Level: X-Spam-Status: No, score=-1.927 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+eUVwmgWfaP; Tue, 8 Nov 2011 18:50:59 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3134D1F0C54; Tue, 8 Nov 2011 18:50:58 -0800 (PST) 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 <0LUD00APWH8NK4@szxga04-in.huawei.com>; Wed, 09 Nov 2011 10:50:47 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUD00AIWH8NKM@szxga04-in.huawei.com>; Wed, 09 Nov 2011 10:50:47 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEV56594; Wed, 09 Nov 2011 10:50:46 +0800 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 09 Nov 2011 10:50:41 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml403-hub.china.huawei.com ([10.82.67.35]) with mapi id 14.01.0270.001; Wed, 09 Nov 2011 10:50:37 +0800 Date: Wed, 09 Nov 2011 02:50:36 +0000 From: Xuxiaohu Subject: re: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt X-Originating-IP: [10.108.4.59] To: Xuxiaohu , "Balus, Florin Stelian (Florin)" , "Bitar, Nabil N" , "l3vpn@ietf.org" , "l2vpn@ietf.org" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE747C3A@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_rOt2fZb4QA4ok2JU0SxtNw)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-index: Acyd2R8rhSQNYlfHQ16DQ3Td7RyeUQAC+SpwABxhHfAACrvcUAAB0LLw X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: HVh2 I6zi RCGE hQEV jBB2 oA1n qDE6 xVJ2 z92/ 2jLD 4zSa 60CV 63jf ABI2pw== AEn4Iw== AE5BRA==; 8; ZgBsAG8AcgBpAG4ALgBiAGEAbAB1AHMAQABhAGwAYwBhAHQAZQBsAC0AbAB1AGMAZQBuAHQALgBjAG8AbQA7AGwAMgB2AHAAbgBAAGkAZQB0AGYALgBvAHIAZwA7AGwAMwB2AHAAbgBAAGkAZQB0AGYALgBvAHIAZwA7AGwAdQBmAGEAbgBnAEAAYwBpAHMAYwBvAC4AYwBvAG0AOwBtAGkAcgBjAGUAYQAuAHAAaQBzAGkAYwBhAEAAYgB0AC4AYwBvAG0AOwBuAGEAYgBpAGwALgBuAC4AYgBpAHQAYQByAEAAdgBlAHIAaQB6AG8AbgAuAGMAbwBtADsAcwBhAGoAYQBzAHMAaQBAAGMAaQBzAGMAbwAuAGMAbwBtADsAeQAuAGkAawBlAGoAaQByAGkAQABuAHQAdAAuAGMAbwBtAA==; Sosha1_v1; 7; {4D51806C-0CA1-4CC8-8A08-99645B9F24FA}; eAB1AHgAaQBhAG8AaAB1AEAAaAB1AGEAdwBlAGkALgBjAG8AbQA=; Wed, 09 Nov 2011 03:03:31 GMT; cgBlADoAIABZAG8AdQByACAAaQBuAHAAdQB0ACAAbwBuACAAdABoAGUAIABmAG8AbABsAG8AdwBpAG4AZwAgAGQAcgBhAGYAdAAgAGkAcwAgAGEAcABwAHIAZQBjAGkAYQB0AGUAZAA6AAkAZAByAGEAZgB0AC0AYgBpAHQAYQByAC0AZABhAHQAYQBjAGUAbgB0AGUAcgAtAHYAcABuAC0AYQBwAHAAbABpAGMAYQBiAGkAbABpAHQAeQAtADAAMQAuAHQAeAB0AA== x-cr-puzzleid: {4D51806C-0CA1-4CC8-8A08-99645B9F24FA} X-CFilter-Loop: Reflected References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74774D@szxeml525-mbs.china.huawei.com> <2073A6C5467C99478898544C6EBA3F4602BD5D2CF4@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> Cc: "y.ikejiri@ntt.com" , "Luyuan Fang \(lufang\)" , Sagessi , "mircea.pisica@bt.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 02:51:00 -0000 --Boundary_(ID_rOt2fZb4QA4ok2JU0SxtNw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 QnkgdGhlIHdheSwgaXQgd291bGQgYmUgYmV0dGVyIHRvIHB1c2ggdGhlIFBCQiBhcyBjbG9zZSB0 byB0aGUgZW5kLXN5c3RlbXMgYXMgcG9zc2libGUgZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgTUFD IGZvcndhcmRpbmcgdGFibGUgc2NhbGFiaWxpdHkuIEhvd2V2ZXIsIHRoZSB1bmtub3duIHVuaWNh c3QgZmxvb2QgaW1wYWN0IGlzc3VlIHdvdWxkIGJlIHdvcnNlbiBhY2NvcmRpbmdseS4gRm9yIGV4 YW1wbGUsIGluIGEgbm9ybWFsIExheWVyMiBuZXR3b3JrLCBpZiB0d28gVk1zIGF0dGFjaGVkIHRv IHRoZSBnaXZlbiBUb1IgYXJlIGZyZXF1ZW50bHkgY29tbXVuaWNhdGVkIHdpdGggZWFjaCBvdGhl ciBhbmQgaGVuY2UgdGhlaXIgTUFDIGFkZHJlc3MgZW50cmllcyBvbiB0aGlzIFRvUiB3aWxsIG5v dCBiZSBleHBpcmVkLCB0aGUgdHJhZmZpYyBkZXN0aW5lZCBmb3IgYW55IG9mIHRob3NlIHR3byBW TXMgZnJvbSBhIHJlbW90ZSBWTSBjb3VsZCBiZSBmbG9vZGVkIGFzIHVua25vd24gdW5pY2FzdCB1 bnRpbCB0aGUgdHJhZmZpYyByZWFjaCB0aGlzIFRvUiB3aGljaCBpbiB0dXJuIGZvcndhcmQgdGhl IHRyYWZmaWMgdG8gdGhlIGRlc3RpbmF0aW9uIFZNIGluIHVuaWNhc3QuICBIb3dldmVyLCBvbmNl IFBCQiBpcyBwZXJmb3JtZWQgYXQgZWFjaCBWU3csIHRoYXQgdHJhZmZpYyB3b3VsZCBiZSBmbG9v ZGVkIHVudGlsIGl0IHJlYWNoIHRoZSBmaW5hbCBkZXN0aW5hdGlvbiBwaHlzaWNhbCBzZXJ2ZXIu ICBJdKGvcyBhIGhhcmQgdHJhZGVvZmYsIGlzbqGvdCBpdD8NCg0KWGlhb2h1DQoNCg0Kt6K8/sjL OiBYdXhpYW9odQ0Kt6LLzcqxvOQ6IDIwMTHE6jEx1MI5yNUgMTA6MDgNCsrVvP7IyzogJ0JhbHVz LCBGbG9yaW4gU3RlbGlhbiAoRmxvcmluKSc7IEJpdGFyLCBOYWJpbCBOOyBsM3ZwbkBpZXRmLm9y ZzsgbDJ2cG5AaWV0Zi5vcmcNCrOty806IEx1eXVhbiBGYW5nIChsdWZhbmcpOyBTYWdlc3NpOyB5 LmlrZWppcmlAbnR0LmNvbTsgbWlyY2VhLnBpc2ljYUBidC5jb20NCtb3zOI6IHJlOiBZb3VyIGlu cHV0IG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQgaXMgYXBwcmVjaWF0ZWQ6IGRyYWZ0LWJpdGFyLWRh dGFjZW50ZXItdnBuLWFwcGxpY2FiaWxpdHktMDEudHh0DQoNCreivP7IyzogQmFsdXMsIEZsb3Jp biBTdGVsaWFuIChGbG9yaW4pIFttYWlsdG86ZmxvcmluLmJhbHVzQGFsY2F0ZWwtbHVjZW50LmNv bV0NCreiy83KsbzkOiAyMDExxOoxMdTCOcjVIDU6MzQNCsrVvP7IyzogWHV4aWFvaHU7IEJpdGFy LCBOYWJpbCBOOyBsM3ZwbkBpZXRmLm9yZzsgbDJ2cG5AaWV0Zi5vcmcNCrOty806IEx1eXVhbiBG YW5nIChsdWZhbmcpOyBTYWdlc3NpOyB5LmlrZWppcmlAbnR0LmNvbTsgbWlyY2VhLnBpc2ljYUBi dC5jb20NCtb3zOI6IFJFOiBZb3VyIGlucHV0IG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQgaXMgYXBw cmVjaWF0ZWQ6IGRyYWZ0LWJpdGFyLWRhdGFjZW50ZXItdnBuLWFwcGxpY2FiaWxpdHktMDEudHh0 DQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLCBzZWUgaW4tbGluZaGtDQoNCkZyb206IGwydnBu LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgWHV4aWFvaHUNClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMDcsIDIwMTEgMTE6NTMgUE0N ClRvOiBCaXRhciwgTmFiaWwgTjsgbDN2cG5AaWV0Zi5vcmc7IGwydnBuQGlldGYub3JnDQpDYzog THV5dWFuIEZhbmcgKGx1ZmFuZyk7IFNhZ2Vzc2k7IHkuaWtlamlyaUBudHQuY29tOyBtaXJjZWEu cGlzaWNhQGJ0LmNvbQ0KU3ViamVjdDogcmU6IFlvdXIgaW5wdXQgb24gdGhlIGZvbGxvd2luZyBk cmFmdCBpcyBhcHByZWNpYXRlZDogZHJhZnQtYml0YXItZGF0YWNlbnRlci12cG4tYXBwbGljYWJp bGl0eS0wMS50eHQNCg0KSGkgTmFiaWwsDQoNCkl0oa9zIGEgdmVyeSBjb21wcmVoZW5zaXZlIGRv Yy4NCg0KU29tZSBjb21tb25zOg0KDQoxoaIgIEluIHNlY3Rpb24gNi4xLCBpdCBzYWlkOiChsEFz IHRoZSBudW1iZXIgb2YgdGVuYW50cyBpbiBpbmRpdmlkdWFsIFZMQU4gaXNsYW5kcyBzdXJwYXNz ZXMgNEssIHRoZSBvcGVyYXRvciBjb3VsZCBwdXNoIFZQTFMgZGVwbG95bWVudCBkZWVwZXIgaW4g dGhlIERDIG5ldHdvcmuhrS4gVGhlIFRvUiBhbmQgREMgY29yZSBlbGVtZW50cyBuZWVkIHRvIGJl IE1QTFMgZW5hYmxlZCB3aXRoIGV4aXN0aW5nIFZQTFMgc29sdXRpb25zobEsIElNSE8sIERDIGNv cmUgc3dpdGNoZXMgZG9uoa90IG5lZWQgdG8gYmUgTVBMUyBlbmFibGVkIHNpbmNlIElQIGJhc2Vk IHR1bm5lbCBpcyBhbHNvIGF2YWlsYWJsZS4NCg0KDQoNCkZCPiBZb3UgYXJlIHJpZ2h0IHdlIHNo b3VsZCBoYXZlIHNhaWQgobBJUCBvciBNUExTIGVuYWJsZWShsSBhcyBib3RoIGNhc2VzIGFyZSBw b3NzaWJsZaGtDQoNCg0KDQo8WFhIPiBHb29kIHBvaW50Lg0KDQoNCg0KMqGiICBTdGlsbCBpbiBz ZWN0aW9uIDYuMSwgaXQgc2FpZDogobEgoa1Ib3dldmVyLCB0aGlzIG1vZGVsIGRvZXMgbm90IHNv bHZlIHRoZSBNQUMgZXhwbG9zaW9uIGlzc3VlIGFzIFRvUnMgc3RpbGwgbmVlZCB0byBsZWFybiBW TSBNQUMgYWRkcmVzc2VzLqGxIEhvd2V2ZXIsIGluIHNlY3Rpb24gNi4yLjEsIGl0IHNhaWQ6obGh rUFsdGVybmF0aXZlbHksIHRoZSBQQkIgZW5jYXBzdWxhdGlvbiBjYW4gYmUgZG9uZSBhdCB0aGUg VG9SLqGxICBJdCBpcyBjb25mdXNlZCBzaW5jZSBwZXJmb3JtaW5nIFBCQiBlbmNhcHN1bGF0aW9u IGF0IHRoZSBUb1Igd291bGQgbm90IGFsbGV2aWF0ZSB0aGUgTUFDLWxlYXJuaW5nIGJ1cmRlbiBv biB0aGF0IFRvUi4NCg0KDQoNCkZCPiBNYXliZSB0aGUgcGhyYXNlIGxvY2F0aW9uIGlzIHB1enps aW5nLiBUaGUgZm9jdXMgb2Ygc2VjdGlvbiA2LjIgaXMgdGhlIHVzZSBvZiBhbiBleHRlbmRlZCAy NGIgUEJCIEktSVNJRCB0YWcgc3RhcnRpbmcgYXQgdGhlIFZTdyB0byBpZGVudGlmeSB0aGUgRUxB TiBicm9hZGNhc3QgZG9tYWluLg0KDQoNCg0KPFhYSD4gVGhlIHRpdGxlIG9mIHNlY3Rpb24gNi4y LjEgaXMgobBBZGRyZXNzaW5nIFZMQU4gc3BhY2UgZXhoYXVzdGlvbiBhbmQgTUFDIGV4cGxvc2lv bqGxLiBTbyBJIHRoaW5rIHNheWluZyBtb3JlIHdvcmRzIGFmdGVyIHRoYXQgc2VudGVuY2UgaXMg bXVjaCBoZWxwZnVsIGluIGF2b2lkaW5nIGNvbmZ1c2lvbi4NCg0KDQoNCg0KDQpUaGlzIHdpbGwg bWF4aW1pemUgdGhlIGJlbmVmaXRzLiBIb3dldmVyIGluIHJlYWxpdHkgaXQgaXMgdmVyeSBsaWtl bHkgdGhlcmUgd2lsbCBiZSBsZWdhY3kgREMgcmVnaW9ucyBzdGlsbCBydW5uaW5nIFZMQU5zIHdo aWNoIHJlcXVpcmUgYSBHYXRld2F5IGZ1bmN0aW9uIGR1cmluZyB0aGUgbWlncmF0aW9uLiBTZWUg dGhlIFZMQU4gSW50ZXJvcCBkaXNjdXNzaW9uIGluIHNlY3Rpb24gNi4yLjkuDQoNCg0KDQozoaIg IEluIDYuMi42LjIuIFBCQk4gaW4gVlN3LCBMMlZQTiBpbiB0aGUgVG9SLCBpdCBzYWlkOqGxIFRo ZSBwcm9jZWR1cmVzIGZyb20gdGhlIHByZXZpb3VzIHNlY3Rpb24gYXJlIHVzZWQgYXQgdGhlIFZT dzogUEJCIGVuY2Fwc3VsYXRpb24gYW5kIEV0aGVybmV0IEJWTEFOcyBjYW4gYmUgdXNlZCBvbiB0 aGUgVlN3IHVwbGluay4gTDJWUE4gaW5mcmFzdHJ1Y3R1cmUgaXMgcmVwbGFjaW5nIHRoZSBCVkxB TiBhdCB0aGUgVG9SIGVuYWJsaW5nIHRoZSB1c2Ugb2YgSVAgKEdSRSBvciBMMlRQKSBvciBNUExT IHR1bm5lbGluZy4NCg0KDQoNCkZCPiBUaGlzIGlzIGFib3V0IHRoZSB0dW5uZWxpbmcgZW5jYXBz dWxhdGlvbiBvcHRpb25zIHRvIGJlIHVzZWQgaW4gdGhlIGNvcmU6IDI0YiBJLVNJRCB0YWcgaXMg dGhlIGNvbW1vbiB0ZW5hbnQgSUQgd2hpY2ggY2FuIGJlIHRyYW5zcG9ydGVkIG92ZXIgYW4gRXRo ZXJuZXQgb3IgYW4gSVAgb3IgYW4gTVBMUyBiYXNlZCBEQyBuZXR3b3JrLiBDb21iaW5hdGlvbnMg b2YgdGhlc2UgdHVubmVsaW5nIG9wdGlvbnMgYXJlIGFsc28gcG9zc2libGU6IGUuZy4gb25lIERD IG1heSBiZSBFdGhlcm5ldCBiYXNlZCB0aGUgb3RoZXIgSVAgYmFzZWQ7IG9yIHRoZSBWU3cgbWF5 IHVzZSBFdGhlcm5ldCBWTEFOIHR1bm5lbHMgd2hpbGUgSVAgdHVubmVscyBtYXkgc3RhcnQgYXQg dGhlIFRvUi4NCg0KDQoNCjxYWEg+IFllcywgSSBhZ3JlZSB3aXRoIHlvdXIgc3RhdGVtZW50IGFi b3ZlLiBBZGRpbmcgdGhlIGFib3ZlIHRleHQgaW50byB0aGUgZHJhZnQgd291bGQgYmUgbXVjaCBo ZWxwZnVsOikNCg0KDQoNCiBMMiBuZXR3b3JraW5nIHN0aWxsIGhhcyB0aGUgc2FtZSBjb250cm9s IHBsYW5lIGNob2ljZXM6IElTLUlTIFs4MDIuMWFxXSBhbmQvb3IgQkdQIFtQQkItRVZQTl0sIGlu ZGVwZW5kZW50bHkgZnJvbSB0aGUgdHVubmVsaW5nIGNob2ljZS6hsSBTaW5jZSBQQkIgZW5jYXBz dWxhdGlvbiBoYXMgYWxyZWFkeSBiZWVuIGRvbmUgb24gdGhlIFZTdywgd2h5IGRvIHdlIHN0aWxs IG5lZWQgdG8gcnVuIDgwMi4xYXEgYW5kIFBCQi1FVlBOIHdpdGggYW5vdGhlciBQQkIgZW5jYXBz dWxhdGlvbiBsYXllcj8NCg0KDQoNCkZCPiBObyBuZWVkIGZvciBhbiBhZGRpdGlvbmFsIFBCQiBl bmNhcHN1bGF0aW9uIGxheWVyISBUaGlzIGlzIHN0cmljdGx5IGFib3V0IGNvbnRyb2wgcGxhbmUg b3B0aW9uczogSVMtSVMgYW5kIEJHUCBhcmUgdXNlZCB0aGUgc2FtZSB3YXkgYXMgaW4gcmVndWxh ciBJUCByb3V0aW5nIHRvIHBlcmZvcm0gTXVsdGlwYXRoaW5nLCBGYXN0IENvbnZlcmdlbmNlLCBz ZXJ2aWNlIEFELCBwcm9ncmFtIHRoZSBjb3JlIEZJQnMgZXRjoa0NCg0KDQoNCjxYWEg+IEFic29s dXRlbHkgYWdyZWUuIFN1Y2ggYmVpbmcgdGhlIGNhc2UsIHdoeSBub3QgcmVtb3ZlIHRoZSB0d28g c3BlY2lmaWMgZXhhbXBsZXMgKGJvdGggb2YgdGhlbSBhZGQgYW5vdGhlciBQQkIgbGF5ZXIpIGZy b20gdGhhdCBzZW50ZW5jZSBzbyBhcyB0byBlbGltaW5hdGUgdGhlIHBvc3NpYmxlIGNvbmZ1c2lv bj8NCg0KDQoNCiBDYW6hr3Qgd2Ugc2ltcGx5IHVzZSBhbnkgTDJWUE4gdGVjaG5vbG9neSwgZS5n LiwgVlBMUy4gSW4gYWRkaXRpb24sIG5vdGUgdGhhdCBpbiBGaWd1cmUgNSwgaXQgc2FpZCChsGlu dHJhLURDIEwyVlBOIG92ZXIgSVAgb3IgTVBMUyB0dW5uZWxpbmehsS4NCg0KDQpGQj4geWVzIHlv dSBjYW4uIFdlIGp1c3QgZm9jdXNlZCBoZXJlIG9uIHRoZSBvcHRpb25zIHRoYXQgd2lsbCBhZGRy ZXNzIHRoZSBjaGFsbGVuZ2VzIGRlc2NyaWJlZCBpbiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgc2Vj dGlvbi4gT3RoZXJ3aXNlIHRoZSBjb250ZW50IHdpbGwgaGF2ZSBncm93biB0b28gbXVjaC4NCg0K PFhYSD4gVGhhbmtzIGZvciB5b3VyIGV4cGxhbmF0aW9uLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFv aHUNCg0Kt6K8/sjLOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNl c0BpZXRmLm9yZ10gtPqx7SBCaXRhciwgTmFiaWwgTg0Kt6LLzcqxvOQ6IDIwMTHE6jEx1MI4yNUg MTM6NDINCsrVvP7IyzogbDN2cG5AaWV0Zi5vcmc7IGwydnBuQGlldGYub3JnDQqzrcvNOiBTYWdl c3NpOyBtaXJjZWEucGlzaWNhQGJ0LmNvbTsgTHV5dWFuIEZhbmcgKGx1ZmFuZyk7IHkuaWtlamly aUBudHQuY29tDQrW98ziOiBZb3VyIGlucHV0IG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQgaXMgYXBw cmVjaWF0ZWQ6IGRyYWZ0LWJpdGFyLWRhdGFjZW50ZXItdnBuLWFwcGxpY2FiaWxpdHktMDEudHh0 DQoNCkhpLA0KV2UgaGFkIHN1Ym1pdHRlZCB0aGUgZm9sbG93aW5nIGRyYWZ0IG9uIHZwbiBhcHBs aWNhYmlsaXR5IGZvciBkYXRhIGNlbnRlci4gWW91ciBpbnB1dCBvbiB0aGUgZHJhZnQgaXMgYXBw cmVjaWF0ZWQgaW4gbGlnaHQgb2Ygc29tZSBvZiB0aGUgb25nb2luZyBkaXNjdXNzaW9uLiBUaGUg ZHJhZnQgaXMgdGFyZ2V0ZWQgZm9yIGwzdnBuIGFuZCBsMnZwbi4NCkhlcmUgaXMgdGhlIGxpbms6 DQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJpdGFyLWRhdGFjZW50ZXItdnBu LWFwcGxpY2FiaWxpdHktMDENCg0KDQpBYnN0cmFjdA0KDQoNCg0KICAgQ2xvdWQgQ29tcHV0aW5n IGhhcyBiZWVuIGF0dHJhY3RpbmcgYSBsb3Qgb2YgYXR0ZW50aW9uIGZyb20gdGhlDQoNCiAgIG5l dHdvcmtpbmcgaW5kdXN0cnkuIFNvbWUgb2YgdGhlIG1vc3QgcHVibGljaXplZCByZXF1aXJlbWVu dHMgYXJlDQoNCiAgIHJlbGF0ZWQgdG8gdGhlIGV2b2x1dGlvbiBvZiB0aGUgQ2xvdWQgTmV0d29y a2luZyBJbmZyYXN0cnVjdHVyZSB0bw0KDQogICBhY2NvbW1vZGF0ZSBhIGxhcmdlIG51bWJlciBv ZiB0ZW5hbnRzLCBlZmZpY2llbnQgbmV0d29yayB1dGlsaXphdGlvbiwNCg0KICAgc2NhbGFibGUg bG9vcCBhdm9pZGFuY2UsIGFuZCBWaXJ0dWFsIE1hY2hpbmUgTW9iaWxpdHkuDQoNCg0KDQogICBU aGlzIGRyYWZ0IGRlc2NyaWJlcyBhIGZyYW1ld29yayBmb3IgY2xvdWQgbmV0d29ya2luZywgaGln aGxpZ2h0aW5nDQoNCiAgIHRoZSBhcHBsaWNhYmlsaXR5IG9mIGV4aXN0aW5nIHdvcmsgaW4gdmFy aW91cyBJRVRGIFdvcmtpbmcgR3JvdXBzDQoNCiAgIChlLmcuLCBSRkNzIGFuZCBkcmFmdHMgZGV2 ZWxvcGVkIGluIElFVEYgTDJWUE4gYW5kIEwzVlBOIFdvcmtpbmcNCg0KICAgR3JvdXBzKSB0byBj bG91ZCBuZXR3b3JraW5nLCBhbmQgdGhlIGdhcHMgYW5kIHByb2JsZW1zIHRoYXQgbmVlZCB0bw0K DQogICBiZSBmdXJ0aGVyIGFkZHJlc3NlZC4gVGhhdCBpcywgdGhlIGdvYWwgaXMgdG8gdW5kZXJz dGFuZCB3aGF0IG1heSBiZQ0KDQogICByZS11c2VkIGZyb20gdGhlIGN1cnJlbnQgcHJvdG9jb2xz IGFuZCBjYWxsIG91dCByZXF1aXJlbWVudHMgc3BlY2lmaWMNCg0KICAgdG8gdGhlIENsb3VkIHNw YWNlIHRoYXQgbmVlZCB0byBiZSBhZGRyZXNzZWQgYnkgbmV3IHN0YW5kYXJkaXphdGlvbg0KDQog ICB3b3JrIHdpdGggcHJvcG9zZWQgc29sdXRpb25zIGluIGNlcnRhaW4gY2FzZXMuDQoNCg0KVGhh bmtzLA0KDQpOYWJpbA0K --Boundary_(ID_rOt2fZb4QA4ok2JU0SxtNw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

By the way= , it would be better to push the PBB as close to the end-systems as possibl= e from the perspective of MAC forwarding table scalability. However, the unknown unicast flood impact issue would be worsen accordingl= y. For example, in a normal Layer2 network, if two VMs attached to the give= n ToR are frequently communicated with each other and hence their MAC addre= ss entries on this ToR will not be expired, the traffic destined for any of those two VMs from a remote VM= could be flooded as unknown unicast until the traffic reach this ToR which= in turn forward the traffic to the destination VM in unicast.  Howeve= r, once PBB is performed at each VSw, that traffic would be flooded until it reach the final destination physica= l server.  It=A1=AFs a hard tradeoff, isn=A1=AFt it?=

 = ;

Xiaohu

 = ;

 = ;

=B7=A2=BC=FE=C8=CB: Xuxiaoh= u
=B7=A2= =CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C29=C8=D5 10:08
=CA=D5=BC=FE=C8=CB: 'Balus, Florin Stelian (Florin)'; Bitar, Nabil N; l3vpn@ietf.org; l= 2vpn@ietf.org
=B3=AD=CB=CD: Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com; mircea.pisica@bt.com =D6=F7=CC=E2: re: Your input on the following draft is appreciated: draft-bitar-datacen= ter-vpn-applicability-01.txt

 

=B7=A2=BC=FE=C8=CB: Balus, = Florin Stelian (Florin) [mailto:florin.balus@alcatel-lucent.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C29=C8=D5 5:34
=CA=D5=BC=FE=C8=CB: Xuxiaohu; Bitar, Nabil N; l3vpn@ietf.org; l2vpn@ietf.org
=B3=AD=CB=CD: Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com; mircea.pisica@bt.com =D6=F7=CC=E2: RE: Your input on the following draft is appreciated: draft-bitar-datacen= ter-vpn-applicability-01.txt

 

Thank= s for the comments, see in-line=A1=AD

=  

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org= ] On Behalf Of Xuxiaohu
Sent: Monday, November 07, 2011 11:53 PM
To: Bitar, Nabil N; l3vpn@ietf.org; l2vpn@ietf.org
Cc: Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com; mircea.pisica@= bt.com
Subject: re: Your input on the following draft is appreciated: draft= -bitar-datacenter-vpn-applicability-01.txt

 

Hi Nabil,<= o:p>

 = ;

It=A1=AFs = a very comprehensive doc.

 = ;

Some commo= ns:

1=A1=A2  In section 6.1, it said: =A1=B0As t=
he number of tenants in individual VLAN islands surpasses 4K, the operator =
could push VPLS deployment deeper in the DC network=A1=AD. The ToR and DC c=
ore elements need to be MPLS enabled with existing VPLS solutions=A1=B1, IM=
HO, DC core switches don=A1=AFt need to be MPLS enabled since IP based tunn=
el is also available.
 
FB> You are right we should have said =A1=B0IP or MPLS enabled=
=A1=B1 as both cases are possible=A1=AD 
 
<XXH> Good point.
 
2=A1=A2  Still in section 6.1, it said: =A1=
=B1 =A1=ADHowever, this model does not solve the MAC explosion issue as ToR=
s still need to learn VM MAC addresses.=A1=B1 However, in section 6.2.1, it=
 said:=A1=B1=A1=ADAlternatively, the PBB encapsulation can be done at the T=
oR.=A1=B1  It is confused since performing PBB encapsulation at the To=
R would not alleviate the MAC-learning burden on that ToR.
 
FB> Maybe the phrase location is puzzling. The focus of sectio=
n 6.2 is the use of an extended 24b PBB I-ISID tag starting at the VSw to i=
dentify the ELAN broadcast domain. 
 
<XXH> The title of section 6.2.1 is =A1=B0Addressing VLAN spac=
e exhaustion and MAC explosion=A1=B1. So I think saying more words after th=
at sentence is much helpful in avoiding confusion.
 
 
This will maximize the benefits. However in reality it is very li=
kely there will be legacy DC regions still running VLANs which require a Ga=
teway function during the migration. See the VLAN Interop discussion in sec=
tion 6.2.9. 
 
3=A1=A2  In 6.2.=
6.2. PBBN in VSw, L2VPN in the ToR, it said:=A1=B1 The procedures from the previo=
us section are used at the VSw: PBB encapsulation and Ethernet BVLANs can b=
e used on the VSw uplink. L2VPN infrastructure is replacing the BVLAN at th=
e ToR enabling the use of IP (GRE or L2TP) or MPLS tunneling. 
 
FB> This is about the tunneling encapsulation options to be us=
ed in the core: 24b I-SID tag is the common tenant ID which can be transpor=
ted over an Ethernet or an IP or an MPLS based DC network. Combinations of =
these tunneling options are also possible: e.g. one DC may be Ethernet base=
d the other IP based; or the VSw may use Ethernet VLAN tunnels while IP tun=
nels may start at the ToR.
 
<XXH> Yes, I agree with your statement above. Adding the above=
 text into the draft would be much helpfulJ
 
 L2 networking still has the same control plane c=
hoices: IS-IS [802.1aq] and/or BGP [PBB-EVPN], independently from the tunne=
ling choice.=A1=B1 Since PBB encapsulation has already been done on the VSw=
, why do we still need to run 802.1aq and PBB-EVPN with another PBB encapsu=
lation layer?
 
FB> No need for an additional PBB encapsulation layer! This is=
 strictly about control plane options: IS-IS and BGP are used the same way =
as in regular IP routing to perform Multipathing, Fast Convergence, service=
 AD, program the core FIBs etc=A1=AD
 
<XXH> Absolutely agree. Such being the case, why not remove th=
e two specific examples (both of them add another PBB layer) from that sent=
ence so as to eliminate the possible confusion?
 
 Can=A1=AFt we simply use any L2VPN technology, e=
.g., VPLS. In addition, note that in Figure 5, it said =A1=B0intra-DC L2VPN=
 over IP or MPLS tunneling=A1=B1.

 = ;

FB> yes you can. We just focused here on th=
e options that will address the challenges described in the problem stateme=
nt section. Otherwise the content will have grown too much.

 = ;

<XXH>= ; Thanks for your explanation.

=  

Best regar= ds,

Xiaohu

 = ;

=B7=A2=BC=FE=C8=CB: l2vpn-b= ounces@ietf.org [mailto:l2vpn-bounces@ietf.org] =B4=FA= =B1=ED Bitar, Nabil N
=B7=A2= =CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C28=C8=D5 13:42
=CA=D5=BC=FE=C8=CB: l3vpn@ietf.org; l2vpn@ietf.org
=B3=AD=CB=CD: Sagessi; mircea.pisica@bt.com; Luyuan Fang (lufang); y.ikejiri@ntt.com =D6=F7=CC=E2: Your input on the following draft is appreciated: draft-bitar-datacenter-= vpn-applicability-01.txt

 

Hi,

We had submi= tted the following draft on vpn applicability for data center. Your input o= n the draft is appreciated in light of some of the ongoing discussion. The draft is targeted for l3vpn and l2vpn.

Here is the = link: 

 <= /o:p>

 <= /o:p>

Abstract

 


   Cloud Computing ha=
s been attracting a lot of attention from the


   networking industr=
y. Some of the most publicized requirements are


   related to the evo=
lution of the Cloud Networking Infrastructure to


   accommodate a larg=
e number of tenants, efficient network utilization,


   scalable loop avoi=
dance, and Virtual Machine Mobility.


 


   This draft describ=
es a framework for cloud networking, highlighting


   the applicability =
of existing work in various IETF Working Groups


   (e.g., RFCs and dr=
afts developed in IETF L2VPN and L3VPN Working


   Groups) to cloud n=
etworking, and the gaps and problems that need to


   be further address=
ed. That is, the goal is to understand what may be


   re-used from the c=
urrent protocols and call out requirements specific


   to the Cloud space=
 that need to be addressed by new standardization


   work with proposed=
 solutions in certain cases.





Thanks,


Nabil
--Boundary_(ID_rOt2fZb4QA4ok2JU0SxtNw)-- From vishwas.ietf@gmail.com Tue Nov 8 19:03:22 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667E01F0C56; Tue, 8 Nov 2011 19:03:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=-1.825, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDELVFigurGt; Tue, 8 Nov 2011 19:03:17 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 39EF81F0C47; Tue, 8 Nov 2011 19:03:17 -0800 (PST) Received: by yenl7 with SMTP id l7so275806yen.31 for ; Tue, 08 Nov 2011 19:03:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ClBisjTdPmkJLpFx4p+gafoP76IqdMDQ57g+psliHNc=; b=slsTUmM75PnM4ZLiMNoWawsq8xKU9syBa6USs+m2T9tgiSOIyrN07HPgzsZKjhcqNt RHOJYXMnyI20CKaMZ/wacf9HA4vONceAhyYtE4BPIfOIHRUhIVuJ8TdI9O8gRD7DK6gZ EplYAt4U/OPOok7PUvNfLzIFVqGRsxqjpDULk= MIME-Version: 1.0 Received: by 10.182.31.15 with SMTP id w15mr118562obh.7.1320807796598; Tue, 08 Nov 2011 19:03:16 -0800 (PST) Received: by 10.182.75.105 with HTTP; Tue, 8 Nov 2011 19:03:16 -0800 (PST) In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE747C3A@szxeml525-mbs.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74774D@szxeml525-mbs.china.huawei.com> <2073A6C5467C99478898544C6EBA3F4602BD5D2CF4@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE747C3A@szxeml525-mbs.china.huawei.com> Date: Tue, 8 Nov 2011 19:03:16 -0800 Message-ID: Subject: Re: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt From: Vishwas Manral To: Xuxiaohu Content-Type: multipart/alternative; boundary=14dae9398f5d88678c04b144876f Cc: "l2vpn@ietf.org" , Sagessi , "l3vpn@ietf.org" , "mircea.pisica@bt.com" , "Luyuan Fang \(lufang\)" , "y.ikejiri@ntt.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 03:03:22 -0000 --14dae9398f5d88678c04b144876f Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Xiaohu, For the purpose of reducing unkown unicast/ multicast you could use some off path learning and then discard the unknowns. Ofcourse the MAC tables in edge device need to big enough to learn the MAC addresses of all the end systems. Thanks, Vishwas 2011/11/8 Xuxiaohu > By the way, it would be better to push the PBB as close to the > end-systems as possible from the perspective of MAC forwarding table > scalability. However, the unknown unicast flood impact issue would be > worsen accordingly. For example, in a normal Layer2 network, if two VMs > attached to the given ToR are frequently communicated with each other and > hence their MAC address entries on this ToR will not be expired, the > traffic destined for any of those two VMs from a remote VM could be flood= ed > as unknown unicast until the traffic reach this ToR which in turn forward > the traffic to the destination VM in unicast. However, once PBB is > performed at each VSw, that traffic would be flooded until it reach the > final destination physical server. It=A1=AFs a hard tradeoff, isn=A1=AFt= it?**** > > ** ** > > Xiaohu**** > > ** ** > > ** ** > > *=B7=A2=BC=FE=C8=CB:* Xuxiaohu > *=B7=A2=CB=CD=CA=B1=BC=E4:* 2011=C4=EA11=D4=C29=C8=D5 10:08 > *=CA=D5=BC=FE=C8=CB:* 'Balus, Florin Stelian (Florin)'; Bitar, Nabil N; l= 3vpn@ietf.org; > l2vpn@ietf.org > *=B3=AD=CB=CD:* Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com; > mircea.pisica@bt.com > *=D6=F7=CC=E2:* re: Your input on the following draft is appreciated: > draft-bitar-datacenter-vpn-applicability-01.txt**** > > ** ** > > *=B7=A2=BC=FE=C8=CB:* Balus, Florin Stelian (Florin) [mailto: > florin.balus@alcatel-lucent.com] > *=B7=A2=CB=CD=CA=B1=BC=E4:* 2011 > =C4=EA11=D4=C29=C8=D5 5:34 > *=CA=D5=BC=FE=C8=CB:* Xuxiaohu; Bitar, Nabil N; l3vpn@ietf.org; l2vpn@iet= f.org > *=B3=AD=CB=CD:* Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com; > mircea.pisica@bt.com > *=D6=F7=CC=E2:* RE: Your input on the following draft is appreciated: > draft-bitar-datacenter-vpn-applicability-01.txt**** > > ** ** > > Thanks for the comments, see in-line=A1=AD**** > > ** ** > > *From:* l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] *On Behalf > Of *Xuxiaohu > *Sent:* Monday, November 07, 2011 11:53 PM > *To:* Bitar, Nabil N; l3vpn@ietf.org; l2vpn@ietf.org > *Cc:* Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com; > mircea.pisica@bt.com > *Subject:* re: Your input on the following draft is appreciated: > draft-bitar-datacenter-vpn-applicability-01.txt**** > > ** ** > > Hi Nabil,**** > > ** ** > > It=A1=AFs a very comprehensive doc.**** > > ** ** > > Some commons:**** > > **1=A1=A2 **In section 6.1, it said: =A1=B0As the number of tenants in i= ndividual VLAN islands surpasses 4K, the operator could push VPLS deploymen= t deeper in the DC network=A1=AD. The ToR and DC core elements need to be M= PLS enabled with existing VPLS solutions=A1=B1, IMHO, DC core switches don= =A1=AFt need to be MPLS enabled since IP based tunnel is also available.***= * > > ** ** > > FB> You are right we should have said =A1=B0IP or MPLS enabled=A1=B1 as b= oth cases are possible=A1=AD **** > > ** ** > > Good point.**** > > ** ** > > **2=A1=A2 **Still in section 6.1, it said: =A1=B1 =A1=ADHowever, this mo= del does not solve the MAC explosion issue as ToRs still need to learn VM M= AC addresses.=A1=B1 However, in section 6.2.1, it said:=A1=B1=A1=ADAlternat= ively, the PBB encapsulation can be done at the ToR.=A1=B1 It is confused = since performing PBB encapsulation at the ToR would not alleviate the MAC-l= earning burden on that ToR.**** > > ** ** > > FB> Maybe the phrase location is puzzling. The focus of section 6.2 is th= e use of an extended 24b PBB I-ISID tag starting at the VSw to identify the= ELAN broadcast domain. **** > > ** ** > > The title of section 6.2.1 is =A1=B0Addressing VLAN space exhaustio= n and MAC explosion=A1=B1. So I think saying more words after that sentence= is much helpful in avoiding confusion.**** > > ** ** > > ** ** > > This will maximize the benefits. However in reality it is very likely the= re will be legacy DC regions still running VLANs which require a Gateway fu= nction during the migration. See the VLAN Interop discussion in section 6.2= .9. **** > > **** > > **3=A1=A2 **In 6.2.6.2. PBBN in VSw, L2VPN in the ToR, it said:=A1=B1 Th= e procedures from the previous section are used at the VSw: PBB encapsulati= on and Ethernet BVLANs can be used on the VSw uplink. L2VPN infrastructure = is replacing the BVLAN at the ToR enabling the use of IP (GRE or L2TP) or M= PLS tunneling. **** > > ** ** > > FB> This is about the tunneling encapsulation options to be used in the c= ore: 24b I-SID tag is the common tenant ID which can be transported over an= Ethernet or an IP or an MPLS based DC network. Combinations of these tunne= ling options are also possible: e.g. one DC may be Ethernet based the other= IP based; or the VSw may use Ethernet VLAN tunnels while IP tunnels may st= art at the ToR.**** > > ** ** > > Yes, I agree with your statement above. Adding the above text into = the draft would be much helpfulJ**** > > ** ** > > L2 networking still has the same control plane choices: IS-IS [802.1aq] = and/or BGP [PBB-EVPN], independently from the tunneling choice.=A1=B1 Since= PBB encapsulation has already been done on the VSw, why do we still need t= o run 802.1aq and PBB-EVPN with another PBB encapsulation layer?**** > > ** ** > > FB> No need for an additional PBB encapsulation layer! This is strictly a= bout control plane options: IS-IS and BGP are used the same way as in regul= ar IP routing to perform Multipathing, Fast Convergence, service AD, progra= m the core FIBs etc=A1=AD**** > > ** ** > > Absolutely agree. Such being the case, why not remove the two speci= fic examples (both of them add another PBB layer) from that sentence so as = to eliminate the possible confusion?**** > > ** ** > > Can=A1=AFt we simply use any L2VPN technology, e.g., VPLS. In addition, = note that in Figure 5, it said =A1=B0intra-DC L2VPN over IP or MPLS tunneli= ng=A1=B1.**** > > ** ** > > FB> yes you can. We just focused here on the options that will address th= e challenges described in the problem statement section. Otherwise the cont= ent will have grown too much.**** > > ** ** > > Thanks for your explanation.**** > > ** ** > > Best regards,**** > > Xiaohu**** > > ** ** > > *=B7=A2=BC=FE=C8=CB:* l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.o= rg] *=B4=FA=B1=ED *Bitar, > Nabil N > *=B7=A2=CB=CD=CA=B1=BC=E4:* 2011=C4=EA11=D4=C28=C8=D5 13:42 > *=CA=D5=BC=FE=C8=CB:* l3vpn@ietf.org; l2vpn@ietf.org > *=B3=AD=CB=CD:* Sagessi; mircea.pisica@bt.com; Luyuan Fang (lufang); > y.ikejiri@ntt.com > *=D6=F7=CC=E2:* Your input on the following draft is appreciated: > draft-bitar-datacenter-vpn-applicability-01.txt**** > > ** ** > > Hi,**** > > We had submitted the following draft on vpn applicability for data center= . > Your input on the draft is appreciated in light of some of the ongoing > discussion. The draft is targeted for l3vpn and l2vpn.**** > > Here is the link: **** > > ** ** > > http://tools.ietf.org/html/draft-bitar-datacenter-vpn-applicability-01***= * > > ** ** > > Abstract**** > > ** ** > > Cloud Computing has been attracting a lot of attention from the**** > > networking industry. Some of the most publicized requirements are**** > > related to the evolution of the Cloud Networking Infrastructure to**** > > accommodate a large number of tenants, efficient network utilization,*= *** > > scalable loop avoidance, and Virtual Machine Mobility.**** > > ** ** > > This draft describes a framework for cloud networking, highlighting***= * > > the applicability of existing work in various IETF Working Groups**** > > (e.g., RFCs and drafts developed in IETF L2VPN and L3VPN Working**** > > Groups) to cloud networking, and the gaps and problems that need to***= * > > be further addressed. That is, the goal is to understand what may be**= ** > > re-used from the current protocols and call out requirements specific*= *** > > to the Cloud space that need to be addressed by new standardization***= * > > work with proposed solutions in certain cases.**** > > > Thanks,**** > > Nabil**** > > --14dae9398f5d88678c04b144876f Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Xiaohu,
 
For the purpose of reducing unkown unicast/ multicast you could use so= me off path learning and then discard the unknowns.
 
Ofcourse the MAC tables in edge device need to big enough to learn the= MAC addresses of all the end systems.
 
Thanks,
Vishwas
2011/11/8 Xuxiaohu <xuxiaohu@huawei.com>

By the way, it would be better to push the PBB as close to the= end-systems as possible from the perspective of MAC forwarding table scala= bility. However, the unknown unicast flood impact issue would be worsen acc= ordingly. For example, in a normal Layer2 network, if two VMs attached to t= he given ToR are frequently communicated with each other and hence their MA= C address entries on this ToR will not be expired, the traffic destined for= any of those two VMs from a remote VM could be flooded as unknown unicast = until the traffic reach this ToR which in turn forward the traffic to the d= estination VM in unicast.  However, once PBB is performed at each VSw,= that traffic would be flooded until it reach the final destination physica= l server.  It’s a hard tradeoff, isn’t it?

 

Xiaohu

 

 

=B7=A2=BC=FE=C8= =CB: Xuxiaohu
=B7= =A2=CB=CD=CA=B1=BC=E4: 201111=D4=C29= =C8=D5 10:08
=CA=D5=BC=FE=C8=CB: 'Balus, Florin Stelian (Florin)'; Bitar, Nabil N; l3vpn@ietf.org; l2vpn@ietf.org
=B3=AD=CB=CD: Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com; mircea.pisica@bt.com
=D6=F7=CC=E2: re: Your input on the following draft is appreciated: draft-bitar-datacen= ter-vpn-applicability-01.txt

 

=B7=A2=BC=FE=C8=CB: Balus, Florin Stelian (Florin) [mailto:florin.balus@alcatel-lucent.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011
=C4=EA11=D4=C29=C8=D5 5:34
=CA=D5=BC=FE=C8=CB: Xuxiaohu; Bitar, Nabil N; l3vpn@ietf.org; l2vpn@ietf.org
=B3=AD=CB=CD: Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com; mircea.pisica@bt.com
=D6=F7=CC=E2: RE: Your input on the following draft is appreciated: draft-bitar-datacen= ter-vpn-applicability-01.txt=20

 

Thanks for the comments, see in-line…

 

Fr= om: l2vpn-bounces@ietf.org [= mailto:l2vpn-bo= unces@ietf.org] On Behalf Of Xuxiaohu
Sent: Monday, November 07, 2011 11:53 PM
To: Bitar, Nabil = N; l3vpn@ietf.org; = l2vpn@ietf.org
<= b>Cc: Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com; mircea.pisica@bt.com
Subject: re: Your input on the following draft is appreciated: draft= -bitar-datacenter-vpn-applicability-01.txt

 

Hi Nabil,

 

It’s a very comprehensive doc.

 

Some commons:

1=A1=A2&nbs=
p; In section 6.1, it said: “As the number of tenan=
ts in individual VLAN islands surpasses 4K, the operator could push VPLS de=
ployment deeper in the DC network…. The ToR and DC core elements nee=
d to be MPLS enabled with existing VPLS solutions”, IMHO, DC core swi=
tches don’t need to be MPLS enabled since IP based tunnel is also ava=
ilable.
=
 
FB> You are right we should have said “IP or MPLS=
 enabled” as both cases are possible… 

 
<XXH> Good point.

 
<=
span>2=A1=A2  Still in section 6.1, it said: ” …However, this =
model does not solve the MAC explosion issue as ToRs still need to learn VM=
 MAC addresses.” However, in section 6.2.1, it said:”…Al=
ternatively, the PBB encapsulation can be done at the ToR.”  It =
is confused since performing PBB encapsulation at the ToR would not allevia=
te the MAC-learning burden on that ToR.


=
 
FB> Maybe the phrase location is puzzling. The focus of=
 section 6.2 is the use of an extended 24b PBB I-ISID tag starting at the V=
Sw to identify the ELAN broadcast domain. 


 
<XXH> The title of section 6.2.1 is &ldq=
uo;Addressing VLAN space exhaustion and MAC explosion”. So I think sa=
ying more words after that sentence is much helpful in avoiding confusion.<=
u>


 
 
This will maximize the benef=
its. However in reality it is very likely there will be legacy DC regions s=
till running VLANs which require a Gateway function during the migration. S=
ee the VLAN Interop discussion in section 6.2.9. 


 
<=
pre style=3D"MARGIN-LEFT: 18pt">3=A1=A2  In 6.2.6.2. PBBN in VSw, L2VPN in the ToR, it said:&rdquo=
; The procedures from the previous section are used at the VSw:=
 PBB encapsulation and Ethernet BVLANs can be used on the VSw uplink. L2VPN=
 infrastructure is replacing the BVLAN at the ToR enabling the use of IP (G=
RE or L2TP) or MPLS tunneling. 


=
 
FB> This is about the tunneling encapsulation options t=
o be used in the core: 24b I-SID tag is the common tenant ID which can be t=
ransported over an Ethernet or an IP or an MPLS based DC network. Combinati=
ons of these tunneling options are also possible: e.g. one DC may be Ethern=
et based the other IP based; or the VSw may use Ethernet VLAN tunnels while=
 IP tunnels may start at the ToR.


 
<XXH> Yes, I agree with your statement a=
bove. Adding the above text into the draft would be much helpfulJ
=
 
 L2 networking still has t=
he same control plane choices: IS-IS [802.1aq] and/or BGP [PBB-EVPN], indep=
endently from the tunneling choice.” Since PBB encapsulation has alre=
ady been done on the VSw, why do we still need to run 802.1aq and PBB-EVPN =
with another PBB encapsulation layer?
 
FB> No need for an additional PBB enc=
apsulation layer! This is strictly about control plane options: IS-IS and B=
GP are used the same way as in regular IP routing to perform Multipathing, =
Fast Convergence, service AD, program the core FIBs etc…
 
<XXH> Absolutely agree. Such being the c=
ase, why not remove the two specific examples (both of them add another PBB=
 layer) from that sentence so as to eliminate the possible confusion?
 
 Can’t we simply use any L2VPN technology, e.g., VPLS. In additio=
n, note that in Figure 5, it said “intra-DC L2VPN over IP or MPLS tun=
neling”.

 

FB> yes=
 you can. We just focused here on the options that will address the challen=
ges described in the problem statement section. Otherwise the content will =
have grown too much.

 

<XXH> Thanks for your explanation.<= /p>

 

Best regards,

Xiaohu

 

=B7=A2=BC=FE=C8= =CB: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] =B4=FA=B1=ED Bitar, Nabil N
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA1= 1=D4=C28=C8=D5 13:4= 2
=CA=D5=BC=FE=C8=CB: l3vpn@ietf.org<= /a>; l2vpn@ietf.org=
=B3=AD=CB=CD: Sagessi; mi= rcea.pisica@bt.com; Luyuan Fang (lufang); y.ikejiri@ntt.com
=D6=F7=CC=E2: Your input on the following draft is appreciated: draft-bitar-datacenter-= vpn-applicability-01.txt

 

Hi,

We had submitted the following draft on vpn applicability for da= ta center. Your input on the draft is appreciated in light of some of the o= ngoing discussion. The draft is targeted for l3vpn and l2vpn.=

Here is the link: 

 

 

Abstract
 
   Cloud Computing has been attracting a lot of attenti=
on from the
   networking ind=
ustry. Some of the most publicized requirements are

   related to the evolution of the Cloud Networking Inf=
rastructure to
   accommodate=
 a large number of tenants, efficient network utilization,


   scalable loop avoidance, and Virtual Machine Mobilit=
y.
 


   This draft describes a framework for cloud networkin=
g, highlighting
   the appl=
icability of existing work in various IETF Working Groups


   (e.g., RFCs and drafts developed in IETF L2VPN and L=
3VPN Working
   Groups) to cl=
oud networking, and the gaps and problems that need to=



   be further addressed. That is, the goal is to unders=
tand what may be
   re-used =
from the current protocols and call out requirements specific=



   to the Cloud space that need to be addressed by new =
standardization
   work wit=
h proposed solutions in certain cases.


Thanks,<=
/u>


Nabil

--14dae9398f5d88678c04b144876f-- From paul@unbehagen.net Tue Nov 8 19:24:57 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 246E711E8091; Tue, 8 Nov 2011 19:24:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.602 X-Spam-Level: X-Spam-Status: No, score=-1.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4AVVGJCyJCN; Tue, 8 Nov 2011 19:24:55 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 201CE1F0C44; Tue, 8 Nov 2011 19:24:37 -0800 (PST) Received: by gye5 with SMTP id 5so1536807gye.31 for ; Tue, 08 Nov 2011 19:24:35 -0800 (PST) Received: by 10.68.35.103 with SMTP id g7mr237443pbj.53.1320809075162; Tue, 08 Nov 2011 19:24:35 -0800 (PST) Received: from [10.176.94.219] ([175.103.22.126]) by mx.google.com with ESMTPS id lk8sm9331192pbb.4.2011.11.08.19.24.31 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 08 Nov 2011 19:24:32 -0800 (PST) References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74774D@szxeml525-mbs.china.huawei.com> <2073A6C5467C99478898544C6EBA3F4602BD5D2CF4@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE747C3A@szxeml525-mbs.china.huawei.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-5B35E0CF-3588-4501-B530-5562A333D92A Message-Id: <35DD67BC-C829-47FF-BFE1-47880518B504@unbehagen.net> X-Mailer: iPad Mail (9A334) From: Paul Unbehagen Subject: Re: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Date: Wed, 9 Nov 2011 14:24:28 +1100 To: Vishwas Manral Cc: "l2vpn@ietf.org" , Sagessi , "l3vpn@ietf.org" , "mircea.pisica@bt.com" , "Luyuan Fang \(lufang\)" , "y.ikejiri@ntt.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 03:24:57 -0000 --Apple-Mail-5B35E0CF-3588-4501-B530-5562A333D92A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Just to be clear wrt PBB, the MAC tables only need to be large enough to lea= rn the Mac's of the end systems in the same ISID that exist on that edge swi= tch, not all MAC's in the network. This is what makes PBB scale so well in t= hese types of environments.=20 -- Paul Unbehagen Sent from my iPad On Nov 9, 2011, at 2:03 PM, Vishwas Manral wrote: > Xiaohu, > =20 > For the purpose of reducing unkown unicast/ multicast you could use some o= ff path learning and then discard the unknowns. > =20 > Ofcourse the MAC tables in edge device need to big enough to learn the MAC= addresses of all the end systems. > =20 > Thanks, > Vishwas > 2011/11/8 Xuxiaohu > By the way, it would be better to push the PBB as close to the end-systems= as possible from the perspective of MAC forwarding table scalability. Howev= er, the unknown unicast flood impact issue would be worsen accordingly. For e= xample, in a normal Layer2 network, if two VMs attached to the given ToR are= frequently communicated with each other and hence their MAC address entries= on this ToR will not be expired, the traffic destined for any of those two V= Ms from a remote VM could be flooded as unknown unicast until the traffic re= ach this ToR which in turn forward the traffic to the destination VM in unic= ast. However, once PBB is performed at each VSw, that traffic would be floo= ded until it reach the final destination physical server. It=E2=80=99s a ha= rd tradeoff, isn=E2=80=99t it? >=20 > =20 >=20 > Xiaohu >=20 > =20 >=20 > =20 >=20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: Xuxiaohu=20 > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B411=E6=9C=889=E6=97=A5 1= 0:08 > =E6=94=B6=E4=BB=B6=E4=BA=BA: 'Balus, Florin Stelian (Florin)'; Bitar, Nabi= l N; l3vpn@ietf.org; l2vpn@ietf.org > =E6=8A=84=E9=80=81: Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com; mirc= ea.pisica@bt.com > =E4=B8=BB=E9=A2=98: re: Your input on the following draft is appreciated: d= raft-bitar-datacenter-vpn-applicability-01.txt >=20 > =20 >=20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: Balus, Florin Stelian (Florin) [mailto:florin= .balus@alcatel-lucent.com]=20 > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011 > =E5=B9=B411=E6=9C=889=E6=97=A5 5:34 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; Bitar, Nabil N; l3vpn@ietf.org; l2v= pn@ietf.org > =E6=8A=84=E9=80=81: Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com; mirc= ea.pisica@bt.com > =E4=B8=BB=E9=A2=98: RE: Your input on the following draft is appreciated: d= raft-bitar-datacenter-vpn-applicability-01.txt > =20 >=20 > Thanks for the comments, see in-line=E2=80=A6 >=20 > =20 >=20 > From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of X= uxiaohu > Sent: Monday, November 07, 2011 11:53 PM > To: Bitar, Nabil N; l3vpn@ietf.org; l2vpn@ietf.org > Cc: Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com; mircea.pisica@bt.com= > Subject: re: Your input on the following draft is appreciated: draft-bitar= -datacenter-vpn-applicability-01.txt >=20 > =20 >=20 > Hi Nabil, >=20 > =20 >=20 > It=E2=80=99s a very comprehensive doc. >=20 > =20 >=20 > Some commons: >=20 > 1=E3=80=81 In section 6.1, it said: =E2=80=9CAs the number of tenants in i= ndividual VLAN islands surpasses 4K, the operator could push VPLS deployment= deeper in the DC network=E2=80=A6. The ToR and DC core elements need to be M= PLS enabled with existing VPLS solutions=E2=80=9D, IMHO, DC core switches do= n=E2=80=99t need to be MPLS enabled since IP based tunnel is also available.= > =20 > FB> You are right we should have said =E2=80=9CIP or MPLS enabled=E2=80=9D= as both cases are possible=E2=80=A6=20 > =20 > Good point. > =20 > 2=E3=80=81 Still in section 6.1, it said: =E2=80=9D =E2=80=A6However, thi= s model does not solve the MAC explosion issue as ToRs still need to learn V= M MAC addresses.=E2=80=9D However, in section 6.2.1, it said:=E2=80=9D=E2=80= =A6Alternatively, the PBB encapsulation can be done at the ToR.=E2=80=9D It= is confused since performing PBB encapsulation at the ToR would not allevia= te the MAC-learning burden on that ToR. > =20 > FB> Maybe the phrase location is puzzling. The focus of section 6.2 is the= use of an extended 24b PBB I-ISID tag starting at the VSw to identify the E= LAN broadcast domain.=20 > =20 > The title of section 6.2.1 is =E2=80=9CAddressing VLAN space exhaust= ion and MAC explosion=E2=80=9D. So I think saying more words after that sent= ence is much helpful in avoiding confusion. > =20 > =20 > This will maximize the benefits. However in reality it is very likely ther= e will be legacy DC regions still running VLANs which require a Gateway func= tion during the migration. See the VLAN Interop discussion in section 6.2.9.= =20 > =20 > 3=E3=80=81 In 6.2.6.2. PBBN in VSw, L2VPN in the ToR, it said:=E2=80=9D T= he procedures from the previous section are used at the VSw: PBB encapsulati= on and Ethernet BVLANs can be used on the VSw uplink. L2VPN infrastructure i= s replacing the BVLAN at the ToR enabling the use of IP (GRE or L2TP) or MPL= S tunneling.=20 > =20 > FB> This is about the tunneling encapsulation options to be used in the co= re: 24b I-SID tag is the common tenant ID which can be transported over an E= thernet or an IP or an MPLS based DC network. Combinations of these tunnelin= g options are also possible: e.g. one DC may be Ethernet based the other IP b= ased; or the VSw may use Ethernet VLAN tunnels while IP tunnels may start at= the ToR. > =20 > Yes, I agree with your statement above. Adding the above text into t= he draft would be much helpfulJ > =20 > L2 networking still has the same control plane choices: IS-IS [802.1aq] a= nd/or BGP [PBB-EVPN], independently from the tunneling choice.=E2=80=9D Sinc= e PBB encapsulation has already been done on the VSw, why do we still need t= o run 802.1aq and PBB-EVPN with another PBB encapsulation layer? > =20 > FB> No need for an additional PBB encapsulation layer! This is strictly ab= out control plane options: IS-IS and BGP are used the same way as in regular= IP routing to perform Multipathing, Fast Convergence, service AD, program t= he core FIBs etc=E2=80=A6 > =20 > Absolutely agree. Such being the case, why not remove the two specif= ic examples (both of them add another PBB layer) from that sentence so as to= eliminate the possible confusion? > =20 > Can=E2=80=99t we simply use any L2VPN technology, e.g., VPLS. In addition= , note that in Figure 5, it said =E2=80=9Cintra-DC L2VPN over IP or MPLS tun= neling=E2=80=9D. > =20 >=20 > FB> yes you can. We just focused here on the options that will address the= challenges described in the problem statement section. Otherwise the conten= t will have grown too much. > =20 >=20 > Thanks for your explanation. >=20 > =20 >=20 > Best regards, >=20 > Xiaohu >=20 > =20 >=20 > =E5=8F=91=E4=BB=B6=E4=BA=BA: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@= ietf.org] =E4=BB=A3=E8=A1=A8 Bitar, Nabil N > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B411=E6=9C=888=E6=97=A5 1= 3:42 > =E6=94=B6=E4=BB=B6=E4=BA=BA: l3vpn@ietf.org; l2vpn@ietf.org > =E6=8A=84=E9=80=81: Sagessi; mircea.pisica@bt.com; Luyuan Fang (lufang); y= .ikejiri@ntt.com > =E4=B8=BB=E9=A2=98: Your input on the following draft is appreciated: draf= t-bitar-datacenter-vpn-applicability-01.txt >=20 > =20 >=20 > Hi, >=20 > We had submitted the following draft on vpn applicability for data center.= Your input on the draft is appreciated in light of some of the ongoing disc= ussion. The draft is targeted for l3vpn and l2vpn. >=20 > Here is the link:=20 >=20 > =20 >=20 > http://tools.ietf.org/html/draft-bitar-datacenter-vpn-applicability-01 >=20 > =20 >=20 > Abstract > =20 > Cloud Computing has been attracting a lot of attention from the > networking industry. Some of the most publicized requirements are > related to the evolution of the Cloud Networking Infrastructure to > accommodate a large number of tenants, efficient network utilization, > scalable loop avoidance, and Virtual Machine Mobility. > =20 > This draft describes a framework for cloud networking, highlighting > the applicability of existing work in various IETF Working Groups > (e.g., RFCs and drafts developed in IETF L2VPN and L3VPN Working > Groups) to cloud networking, and the gaps and problems that need to > be further addressed. That is, the goal is to understand what may be > re-used from the current protocols and call out requirements specific > to the Cloud space that need to be addressed by new standardization > work with proposed solutions in certain cases. >=20 > Thanks, > Nabil >=20 --Apple-Mail-5B35E0CF-3588-4501-B530-5562A333D92A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Just to be clear wrt PBB, t= he MAC tables only need to be large enough to learn the Mac's of the end sys= tems in the same ISID that exist on that edge switch, not all MAC's in the n= etwork. This is what makes PBB scale so well in these types of environments.=  

--
Paul Unbehagen

Sent from my iPad

On Nov 9, 2011, at 2= :03 PM, Vishwas Manral <vishwas= .ietf@gmail.com> wrote:

Xiaohu,
 
For the purpose of reducing unkown unicast/ multicast you could use som= e off path learning and then discard the unknowns.
 
Ofcourse the MAC tables in edge device need to big enough to learn the M= AC addresses of all the end systems.
 
Thanks,
Vishwas
2011/11/8 Xuxiaohu <xuxiaohu@huawei.com>

By the way, it would be better to push the PBB as close to the e= nd-systems as possible from the perspective of MAC forwarding table scalabil= ity. However, the unknown unicast flood impact issue would be worsen accordi= ngly. For example, in a normal Layer2 network, if two VMs attached to the gi= ven ToR are frequently communicated with each other and hence their MAC addr= ess entries on this ToR will not be expired, the traffic destined for any of= those two VMs from a remote VM could be flooded as unknown unicast until th= e traffic reach this ToR which in turn forward the traffic to the destinatio= n VM in unicast.  However, once PBB is performed at each VSw, that traf= fic would be flooded until it reach the final destination physical server.&n= bsp; It=E2=80=99s a hard tradeoff, isn=E2=80=99t it?

 

Xiaohu

 

 

=E5=8F=91=E4=BB=B6= =E4=BA=BA: Xuxiaohu
=E5= =8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2011=E5=B9=B411=E6=9C=889=E6=97=A5 10:08
=E6=94=B6=E4=BB=B6=E4=BA=BA: 'Balus, Florin Stelian (Florin)'; Bitar, Nabil N; l3vpn@ietf.org; l2vpn@ietf.org
=E6=8A=84=E9=80=81: Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com; mircea.pisica@bt.com
=E4=B8=BB=E9=A2=98: re: Your input on the following draft is appreciated: draft-bitar-dat= acenter-vpn-applicability-01.txt

=

 

=E5=8F=91=E4=BB=B6=E4= =BA=BA: Balus, Florin Stelian (Florin) [mailto:florin.balus@alcatel-lucen= t.com]
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4= : 2011
=E5=B9=B411=E6=9C=889=E6=97=A5 5:34
=E6=94=B6=E4=BB=B6=E4=BA=BA: Xuxiaohu; Bitar, Nabil N; l3vpn@ietf.org; l2vpn@ietf.org
=E6=8A=84=E9=80=81: Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com; mircea.pisica@bt.com
=E4=B8=BB=E9=A2=98: RE: Your input on the following draft is appreciated: draft-bitar-dat= acenter-vpn-applicability-01.txt=20

 

Thanks for the comments, see in-line=E2=80=A6=

 

From:= l2vpn-bounces@ietf.org [mailt= o:l2vpn-bounces@= ietf.org] On Behalf Of Xuxiaohu
Sent: Monday, November 07, 2011 11:53 PM
To: Bitar, Nabil N= ; l3vpn@ietf.org; l2vpn@ietf.org
C= c: Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com; mircea.pisica@bt.com
Subject: re: Your input on the following draft is appreciated: draft-= bitar-datacenter-vpn-applicability-01.txt

 

Hi Nabil,

 

It=E2=80=99s a very comprehensive doc.

 

Some commons:

1=E3=80=81  In section 6.1, it said: =E2=80=9CAs the number of tenants in ind=
ividual VLAN islands surpasses 4K, the operator could push VPLS deployment d=
eeper in the DC network=E2=80=A6. The ToR and DC core elements need to be MP=
LS enabled with existing VPLS solutions=E2=80=9D, IMHO, DC core switches don=
=E2=80=99t need to be MPLS enabled since IP based tunnel is also available.<=
u>
&=
nbsp;
FB> You are right we should have said =E2=80=9CIP or MPLS e=
nabled=E2=80=9D as both cases are possible=E2=80=A6 

 
<XXH> Good point.

 
=
2=E3=80=81  Still in section 6.1, it said: =E2=80=9D =E2=80=A6However, this model do=
es not solve the MAC explosion issue as ToRs still need to learn VM MAC addr=
esses.=E2=80=9D However, in section 6.2.1, it said:=E2=80=9D=E2=80=A6Alterna=
tively, the PBB encapsulation can be done at the ToR.=E2=80=9D  It is c=
onfused since performing PBB encapsulation at the ToR would not alleviate th=
e MAC-learning burden on that ToR.


&=
nbsp;
FB> Maybe the phrase location is puzzling. The focus of se=
ction 6.2 is the use of an extended 24b PBB I-ISID tag starting at the VSw t=
o identify the ELAN broadcast domain. 


 
<XXH> The title of section 6.2.1 is =E2=80=9C=
Addressing VLAN space exhaustion and MAC explosion=E2=80=9D. So I think sayi=
ng more words after that sentence is much helpful in avoiding confusion.<=
/u>


 
 
This will maximize the benefits.=
 However in reality it is very likely there will be legacy DC regions still r=
unning VLANs which require a Gateway function during the migration. See the V=
LAN Interop discussion in section 6.2.9. 



 
3=E3=80=81  In 6.2.6.2. PBBN in VSw, L2VPN in the ToR, it said:=E2=80=9D The pro=
cedures from the previous section are used at the VSw: PBB encapsulation and=
 Ethernet BVLANs can be used on the VSw uplink. L2VPN infrastructure is repl=
acing the BVLAN at the ToR enabling the use of IP (GRE or L2TP) or MPLS tunn=
eling. 
&=
nbsp;
FB> This is about the tunneling encapsulation options to b=
e used in the core: 24b I-SID tag is the common tenant ID which can be trans=
ported over an Ethernet or an IP or an MPLS based DC network. Combinations o=
f these tunneling options are also possible: e.g. one DC may be Ethernet bas=
ed the other IP based; or the VSw may use Ethernet VLAN tunnels while IP tun=
nels may start at the ToR.
 
<XXH> Yes, I agree with your statement abov=
e. Adding the above text into the draft would be much helpfulJ&=
nbsp;
 L2 networking still has the s=
ame control plane choices: IS-IS [802.1aq] and/or BGP [PBB-EVPN], independen=
tly from the tunneling choice.=E2=80=9D Since PBB encapsulation has already b=
een done on the VSw, why do we still need to run 802.1aq and PBB-EVPN with a=
nother PBB encapsulation layer?
 
FB> No need for an additional PBB encapsu=
lation layer! This is strictly about control plane options: IS-IS and BGP ar=
e used the same way as in regular IP routing to perform Multipathing, Fast C=
onvergence, service AD, program the core FIBs etc=E2=80=A6
 
<XXH> Absolutely agree. Such being the case=
, why not remove the two specific examples (both of them add another PBB lay=
er) from that sentence so as to eliminate the possible confusion?<=
/u>
 
 Can=E2=80=99t we simply use any L2VPN technology, e.g., VPLS. In addition,=
 note that in Figure 5, it said =E2=80=9Cintra-DC L2VPN over IP or MPLS tunn=
eling=E2=80=9D.

 

FB> yes yo=
u can. We just focused here on the options that will address the challenges d=
escribed in the problem statement section. Otherwise the content will have g=
rown too much.

 

<XXH> Thanks for your explanation.

 

Best regards,

Xiaohu

 

=E5=8F=91=E4=BB=B6= =E4=BA=BA: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Bitar, Nabil N
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4= : 2011=E5=B9=B411=E6=9C=888=E6=97=A5 13:42
=E6=94=B6=E4=BB=B6=E4=BA=BA: l3vpn@iet= f.org; l2vpn@ietf.or= g
=E6=8A=84=E9=80=81: Sagessi; mircea.pisica@bt.com; Luyuan Fang (lufang); y.ikejiri@ntt.com
=E4=B8=BB=E9=A2=98: Your input on the following draft is appreciated: draft-bitar-datacen= ter-vpn-applicability-01.txt

 

Hi,

We had submitted the following draft on vpn applicability for data= center. Your input on the draft is appreciated in light of some of the ongo= ing discussion. The draft is targeted for l3vpn and l2vpn.

Here is the link: 

 

 

Abstract
 
   Cloud Computing has been attracting a lot of attention from th=
e
   networking industry. Some of the m=
ost publicized requirements are
   related to the evolution of the Cloud Networking Infrastructur=
e to
   accommodate a large number of t=
enants, efficient network utilization,
   scalable loop avoidance, and Virtual Machine Mobility.<=
u>
 
   This draft describes a framework for cloud networking, highlig=
hting
   the applicability of existing w=
ork in various IETF Working Groups
   (e.g., RFCs and drafts developed in IETF L2VPN and L3VPN Worki=
ng
   Groups) to cloud networking, and t=
he gaps and problems that need to
   be further addressed. That is, the goal is to understand what m=
ay be
   re-used from the current proto=
cols and call out requirements specific
   to the Cloud space that need to be addressed by new standardiz=
ation
   work with proposed solutions i=
n certain cases.

Thanks,
Nabil
<= /div>

= --Apple-Mail-5B35E0CF-3588-4501-B530-5562A333D92A-- From xuxiaohu@huawei.com Tue Nov 8 19:29:58 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383D31F0C51; Tue, 8 Nov 2011 19:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.502 X-Spam-Level: X-Spam-Status: No, score=0.502 tagged_above=-999 required=5 tests=[AWL=-2.548, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnhU3J+lv2Ws; Tue, 8 Nov 2011 19:29:57 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id D38341F0C4D; Tue, 8 Nov 2011 19:29:56 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUD00CQFIYOMH@szxga05-in.huawei.com>; Wed, 09 Nov 2011 11:28:00 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUD00GCWIYMN3@szxga05-in.huawei.com>; Wed, 09 Nov 2011 11:28:00 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEX43420; Wed, 09 Nov 2011 11:27:58 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 09 Nov 2011 11:27:53 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0270.001; Wed, 09 Nov 2011 11:27:49 +0800 Date: Wed, 09 Nov 2011 03:27:47 +0000 From: Xuxiaohu Subject: =?gb2312?B?tPC4tDogWW91ciBpbnB1dCBvbiB0aGUgZm9sbG93aW5nIGRyYWZ0IGlzIGFw?= =?gb2312?B?cHJlY2lhdGVkOglkcmFmdC1iaXRhci1kYXRhY2VudGVyLXZwbi1hcHBsaWNh?= =?gb2312?Q?bility-01.txt?= In-reply-to: <2691CE0099834E4A9C5044EEC662BB9D118E00D4@dfweml506-mbx> X-Originating-IP: [10.108.4.59] To: Lucy yong , "Bitar, Nabil N" , "l3vpn@ietf.org" , "l2vpn@ietf.org" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE747C99@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_FHfWXvmU2MRDXXUc1vGA/w)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-index: Acyd2R8rhSQNYlfHQ16DQ3Td7RyeUQAYBJpgABUayqA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <2691CE0099834E4A9C5044EEC662BB9D118E00D4@dfweml506-mbx> Cc: Sagessi , "y.ikejiri@ntt.com" , "mircea.pisica@bt.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 03:29:58 -0000 --Boundary_(ID_FHfWXvmU2MRDXXUc1vGA/w) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 DQoNCreivP7IyzogbDN2cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwzdnBuLWJvdW5jZXNA aWV0Zi5vcmddILT6se0gTHVjeSB5b25nDQq3osvNyrG85DogMjAxMcTqMTHUwjnI1SAxOjQwDQrK 1bz+yMs6IEJpdGFyLCBOYWJpbCBOOyBsM3ZwbkBpZXRmLm9yZzsgbDJ2cG5AaWV0Zi5vcmcNCrOt y806IFNhZ2Vzc2k7IHkuaWtlamlyaUBudHQuY29tOyBtaXJjZWEucGlzaWNhQGJ0LmNvbQ0K1vfM 4jogUkU6IFlvdXIgaW5wdXQgb24gdGhlIGZvbGxvd2luZyBkcmFmdCBpcyBhcHByZWNpYXRlZDog ZHJhZnQtYml0YXItZGF0YWNlbnRlci12cG4tYXBwbGljYWJpbGl0eS0wMS50eHQNCg0KSGkgTmFi aWwgIGFuZCBvdGhlciBjby1hdXRob3JzLA0KDQpGaXJzdCBvZiBhbGwsIHRoaXMgaXMgYSB2ZXJ5 IGdvb2QgZHJhZnQgdG8gZ2F0aGVyIERDIHByb2JsZW0gc3RhdGVtZW50cyBhbmQgZXhwbG9yZSBW UE4gYXBwbGljYWJpbGl0eSBmb3IgY2xvdWQgbmV0d29ya2luZy4gIEdvb2QgaW5mb3JtYXRpb24g Zm9yIHRoZSBjb21tdW5pdHkuIFRoYW5rIHlvdSB2ZXJ5IG11Y2guDQoNClNvbWUgY29tbWVudHM6 DQoNCg0KMSkgICAgICBUaGUgZG9jdW1lbnQgaGFzIGhlYXZ5IGFtb3VudCBwb3J0aW9uIHRvIGRl c2NyaWJlIGFsbCBkaWZmZXJlbnQgdXNlIGNhc2VzIGZvciBQQkIgYnV0IGZldyBzZW50ZW5jZSBm b3IgVFJJTEwgYW5kIEwzVlBOIGFwcGxpY2FiaWxpdHkgaW4gREMuIFN1Z2dlc3QgdG8gZWxhYm9y YXRlIG1vcmUgb24gVFJJTEwgYW5kIEwzVlBOIGNhc2VzLg0KDQo8WFhIPiBJIGd1ZXNzIHBhcnRp YWwgcGFyYWdyYXBocyBpbiBzZWN0aW9uIDUuNS4gobBPcHRpbWFsIHRyYWZmaWMgZm9yd2FyZGlu Z6GxIGRpZCBtZW50aW9uIEwzVlBOIGFwcGxpY2FiaWxpdHkgaW4gREMuIFNwZWNpZmljYWxseSwg dGhlIHBhcmFncmFwaCBzdGFydGluZyB3aXRoIKGwSVAtYmFzZWQgZm9yd2FyZGluZyByZWxpZXMg b24gdGhlIGRlc3RpbmF0aW9uIElQIGFkZHJlc3OhrSBkZXNjcmliZXMgYSBMM1ZQTiBhcHBsaWNh dGlvbiBhcHByb2FjaCBsaWtlIFZpcnR1YWwgU3VibmV0IChodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC14dS12aXJ0dWFsLXN1Ym5ldC0wNikgYW5kIHRoZSBmb2xsb3dpbmcgcGFyYWdy YXBoIGRlc2NyaWJlcyBhbm90aGVyIEwzVlBOIGFwcGxpY2F0aW9uIGxpa2UgbDN2cG4tZW5kLXN5 c3RlbSAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFycXVlcy1sM3Zwbi1lbmQt c3lzdGVtLTAyKS4gTm90ZSB0aGF0IGl0oa9zIGp1c3QgbXkgZ3Vlc3MgdGhhdCBoYXMgbm90IGJl IGNvbmZpcm1lZCB5ZXQgYnkgY28tYXV0aG9ycyBvZiBkcmFmdC1iaXRhci1kYXRhY2VudGVyLXZw bi1hcHBsaWNhYmlsaXR5LTAxOikNCg0KDQoyKSAgICAgIEl0IGlzIHZlcnkgcG9zc2libGUgdGhh dCBEQyB1c2UgTDJWUE4gYW5kIFdBTiB1c2UgTDNWUE4uICBJdCBpcyBuaWNlIHRoYXQgZG9jdW1l bnQgdGhpcyBhcHBsaWNhYmlsaXR5Lg0KDQo8WFhIPiBpdKGvcyBhIGdvb2Qgb3Bpbmlvbi4gQXMg Zm9yIERDSSwgaG9zdCByb3V0ZSBiYXNlZCBMM1ZQTiBhcHByb2FjaGVzIHdpbGwgYnJpbmcgb3Bl cmF0b3JzIG1vcmUgYXR0cmFjdGl2ZSBhZHZhbnRhZ2VzIGNvbXBhcmVkIHRvIHRob3NlIE1BQyBm b3J3YXJkaW5nIGJhc2VkIEwyVlBOIGFwcHJvYWNoLCBzdWNoIGFzIGJyb2FkY2FzdC9mbG9vZCBp bXBhY3QgZWxpbWluYXRpb24sIE1BQyB0YWJsZSBzY2FsYWJpbGl0eSBvbiBkYXRhIGNlbnRlciBz d2l0Y2hlcywgYW5kIGVzcGVjaWFsbHkgcGF0aCBvcHRpbWl6YXRpb24uDQoNCkJlc3QgcmVnYXJk cywNClhpYW9odQ0KDQoNCjMpICAgICAgUHJvdmlkZXIgREMgYW5kIGVudGVycHJpc2UgREMgbWF5 IGltcGxlbWVudCBkaWZmZXJlbnQgTDJWUE4gb3IgTDNWUE4gdGVjaG5vbG9naWVzLCBpdCBpcyB2 YWx1YWJsZSB0byBkZXNjcmliZSB3aGF0IGtpbmQgb2YgaW50ZXJ3b3JraW5nIHNjZW5hcmlvcyBp cyBhbGxvd2VkIG9yIG5vdCBhbGxvd2VkLg0KDQpCZXN0IFJlZ2FyZHMsDQpMdWN5DQoNCg0KDQpG cm9tOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9y Z10gT24gQmVoYWxmIE9mIEJpdGFyLCBOYWJpbCBODQpTZW50OiBNb25kYXksIE5vdmVtYmVyIDA3 LCAyMDExIDExOjQyIFBNDQpUbzogbDN2cG5AaWV0Zi5vcmc7IGwydnBuQGlldGYub3JnDQpDYzog U2FnZXNzaTsgbWlyY2VhLnBpc2ljYUBidC5jb207IEx1eXVhbiBGYW5nIChsdWZhbmcpOyB5Lmlr ZWppcmlAbnR0LmNvbQ0KU3ViamVjdDogWW91ciBpbnB1dCBvbiB0aGUgZm9sbG93aW5nIGRyYWZ0 IGlzIGFwcHJlY2lhdGVkOiBkcmFmdC1iaXRhci1kYXRhY2VudGVyLXZwbi1hcHBsaWNhYmlsaXR5 LTAxLnR4dA0KDQpIaSwNCldlIGhhZCBzdWJtaXR0ZWQgdGhlIGZvbGxvd2luZyBkcmFmdCBvbiB2 cG4gYXBwbGljYWJpbGl0eSBmb3IgZGF0YSBjZW50ZXIuIFlvdXIgaW5wdXQgb24gdGhlIGRyYWZ0 IGlzIGFwcHJlY2lhdGVkIGluIGxpZ2h0IG9mIHNvbWUgb2YgdGhlIG9uZ29pbmcgZGlzY3Vzc2lv bi4gVGhlIGRyYWZ0IGlzIHRhcmdldGVkIGZvciBsM3ZwbiBhbmQgbDJ2cG4uDQpIZXJlIGlzIHRo ZSBsaW5rOg0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaXRhci1kYXRhY2Vu dGVyLXZwbi1hcHBsaWNhYmlsaXR5LTAxDQoNCg0KQWJzdHJhY3QNCg0KDQoNCiAgIENsb3VkIENv bXB1dGluZyBoYXMgYmVlbiBhdHRyYWN0aW5nIGEgbG90IG9mIGF0dGVudGlvbiBmcm9tIHRoZQ0K DQogICBuZXR3b3JraW5nIGluZHVzdHJ5LiBTb21lIG9mIHRoZSBtb3N0IHB1YmxpY2l6ZWQgcmVx dWlyZW1lbnRzIGFyZQ0KDQogICByZWxhdGVkIHRvIHRoZSBldm9sdXRpb24gb2YgdGhlIENsb3Vk IE5ldHdvcmtpbmcgSW5mcmFzdHJ1Y3R1cmUgdG8NCg0KICAgYWNjb21tb2RhdGUgYSBsYXJnZSBu dW1iZXIgb2YgdGVuYW50cywgZWZmaWNpZW50IG5ldHdvcmsgdXRpbGl6YXRpb24sDQoNCiAgIHNj YWxhYmxlIGxvb3AgYXZvaWRhbmNlLCBhbmQgVmlydHVhbCBNYWNoaW5lIE1vYmlsaXR5Lg0KDQoN Cg0KICAgVGhpcyBkcmFmdCBkZXNjcmliZXMgYSBmcmFtZXdvcmsgZm9yIGNsb3VkIG5ldHdvcmtp bmcsIGhpZ2hsaWdodGluZw0KDQogICB0aGUgYXBwbGljYWJpbGl0eSBvZiBleGlzdGluZyB3b3Jr IGluIHZhcmlvdXMgSUVURiBXb3JraW5nIEdyb3Vwcw0KDQogICAoZS5nLiwgUkZDcyBhbmQgZHJh ZnRzIGRldmVsb3BlZCBpbiBJRVRGIEwyVlBOIGFuZCBMM1ZQTiBXb3JraW5nDQoNCiAgIEdyb3Vw cykgdG8gY2xvdWQgbmV0d29ya2luZywgYW5kIHRoZSBnYXBzIGFuZCBwcm9ibGVtcyB0aGF0IG5l ZWQgdG8NCg0KICAgYmUgZnVydGhlciBhZGRyZXNzZWQuIFRoYXQgaXMsIHRoZSBnb2FsIGlzIHRv IHVuZGVyc3RhbmQgd2hhdCBtYXkgYmUNCg0KICAgcmUtdXNlZCBmcm9tIHRoZSBjdXJyZW50IHBy b3RvY29scyBhbmQgY2FsbCBvdXQgcmVxdWlyZW1lbnRzIHNwZWNpZmljDQoNCiAgIHRvIHRoZSBD bG91ZCBzcGFjZSB0aGF0IG5lZWQgdG8gYmUgYWRkcmVzc2VkIGJ5IG5ldyBzdGFuZGFyZGl6YXRp b24NCg0KICAgd29yayB3aXRoIHByb3Bvc2VkIHNvbHV0aW9ucyBpbiBjZXJ0YWluIGNhc2VzLg0K DQoNClRoYW5rcywNCg0KTmFiaWwNCg== --Boundary_(ID_FHfWXvmU2MRDXXUc1vGA/w) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

 = ;

 = ;

=B7=A2=BC=FE=C8=CB: l3vpn-b= ounces@ietf.org [mailto:l3vpn-bounces@ietf.org] =B4=FA= =B1=ED Lucy yong
=B7=A2= =CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C29=C8=D5 1:40
=CA=D5=BC=FE=C8=CB: Bitar, Nabil N; l3vpn@ietf.org; l2vpn@ietf.org
=B3=AD=CB=CD: Sagessi; y.ikejiri@ntt.com; mircea.pisica@bt.com
=D6=F7=CC=E2: RE: Your input on the following draft is appreciated: draft-bitar-datacen= ter-vpn-applicability-01.txt

 

Hi Nabil&n= bsp; and other co-authors,

 = ;

First of a= ll, this is a very good draft to gather DC problem statements and explore V= PN applicability for cloud networking.  Good information for the community. Thank you very much.

 = ;

Some comme= nts:

 = ;

1)      Th= e document has heavy amount portion to describe all different use cases for= PBB but few sentence for TRILL and L3VPN applicability in DC. Suggest to elaborate more on TRILL and L3VPN cases.

 = ;

<XXH>= ; I guess partial paragraphs in section 5.5. =A1=B0Optimal traffic forwarding=A1=B1 did= mention L3VPN applicability in DC. Specifically, the paragraph starting wi= th =A1=B0IP-based forwarding relies on the destination IP address=A1=AD des= cribes a L3VPN application approach like Virtual Subnet (http://tools.ietf.org/html/draft-xu-virtual-subnet-06) and the following = paragraph describes another L3VPN application like l3vpn-end-system (http://t= ools.ietf.org/html/draft-marques-l3vpn-end-system-02). Note that it=A1=AFs just my guess that has not be confirmed yet by co-auth= ors of draft-bitar-datacenter-vpn-applicability-01J<= span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:"Calibri&quo= t;,"sans-serif";color:#1F497D">

 = ;

2)      It= is very possible that DC use L2VPN and WAN use L3VPN.  It is nice tha= t document this applicability.

 = ;

<XXH>= ; it=A1=AFs a good opinion. As for DCI, host route based L3VPN approaches w= ill bring operators more attractive advantages compared to those MAC forwarding based L2VPN approach, such as broadcast/flood impact eliminatio= n, MAC table scalability on data center switches, and especially path optim= ization.

 = ;

Best regar= ds,

Xiaohu

 = ;

3)      Pr= ovider DC and enterprise DC may implement different L2VPN or L3VPN technolo= gies, it is valuable to describe what kind of interworking scenarios is allowed or not allowed.

 = ;

Best Regar= ds,

Lucy<= /o:p>

 = ;

 = ;

 = ;

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org= ] On Behalf Of Bitar, Nabil N
Sent: Monday, November 07, 2011 11:42 PM
To: l3vpn@ietf.org; l2vpn@ietf.org
Cc: Sagessi; mircea.pisica@bt.com; Luyuan Fang (lufang); y.ikejiri@n= tt.com
Subject: Your input on the following draft is appreciated: draft-bit= ar-datacenter-vpn-applicability-01.txt

 

Hi,

We had submi= tted the following draft on vpn applicability for data center. Your input o= n the draft is appreciated in light of some of the ongoing discussion. The draft is targeted for l3vpn and l2vpn.

Here is the = link: 

 <= /o:p>

 <= /o:p>

Abstract
 
   Cloud Computing has been attracting a=
 lot of attention from the
   networking industry. Some of the most=
 publicized requirements are
   related to the evolution of the Cloud=
 Networking Infrastructure to
   accommodate a large number of tenants=
, efficient network utilization,
   scalable loop avoidance, and Virtual =
Machine Mobility.
 
   This draft describes a framework for =
cloud networking, highlighting
   the applicability of existing work in=
 various IETF Working Groups
   (e.g., RFCs and drafts developed in I=
ETF L2VPN and L3VPN Working
   Groups) to cloud networking, and the =
gaps and problems that need to
   be further addressed. That is, the go=
al is to understand what may be
   re-used from the current protocols an=
d call out requirements specific
   to the Cloud space that need to be ad=
dressed by new standardization
   work with proposed solutions in certa=
in cases.

 
Thanks,
Nabil
--Boundary_(ID_FHfWXvmU2MRDXXUc1vGA/w)-- From xuxiaohu@huawei.com Tue Nov 8 17:32:28 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A71E31F0C45; Tue, 8 Nov 2011 17:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=2.066, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijYV9kShNGTg; Tue, 8 Nov 2011 17:32:27 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id B22481F0C3B; Tue, 8 Nov 2011 17:32:26 -0800 (PST) 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 <0LUD00DZLDM129@szxga03-in.huawei.com>; Wed, 09 Nov 2011 09:32:26 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUD0022PDM1P0@szxga03-in.huawei.com>; Wed, 09 Nov 2011 09:32:25 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEX37024; Wed, 09 Nov 2011 09:32:25 +0800 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 09 Nov 2011 09:32:20 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0270.001; Wed, 09 Nov 2011 09:32:14 +0800 Date: Wed, 09 Nov 2011 01:32:13 +0000 From: Xuxiaohu Subject: re: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt In-reply-to: X-Originating-IP: [10.108.4.59] To: "Bitar, Nabil N" , "l3vpn@ietf.org" , "l2vpn@ietf.org" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE747B0F@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_DQOuIZmy4fHOFNEOX6ABdQ)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-index: AQHMnlOsw6+dbhn2JkyxTDO+jl5CM5Wjv/MA X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74774D@szxeml525-mbs.china.huawei.com> X-Mailman-Approved-At: Wed, 09 Nov 2011 02:31:01 -0800 Cc: "Luyuan Fang \(lufang\)" , Sagessi , "y.ikejiri@ntt.com" , "mircea.pisica@bt.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 01:32:28 -0000 --Boundary_(ID_DQOuIZmy4fHOFNEOX6ABdQ) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 SGkgTmFiaWwsDQoNCuWPkeS7tuS6ujogQml0YXIsIE5hYmlsIE4gW21haWx0bzpuYWJpbC5uLmJp dGFyQHZlcml6b24uY29tXQ0K5Y+R6YCB5pe26Ze0OiAyMDEx5bm0MTHmnIg55pelIDQ6MTkNCuaU tuS7tuS6ujogWHV4aWFvaHU7IEJpdGFyLCBOYWJpbCBOOyBsM3ZwbkBpZXRmLm9yZzsgbDJ2cG5A aWV0Zi5vcmcNCuaKhOmAgTogU2FnZXNzaTsgbWlyY2VhLnBpc2ljYUBidC5jb207IEx1eXVhbiBG YW5nIChsdWZhbmcpOyB5LmlrZWppcmlAbnR0LmNvbQ0K5Li76aKYOiBSZTogWW91ciBpbnB1dCBv biB0aGUgZm9sbG93aW5nIGRyYWZ0IGlzIGFwcHJlY2lhdGVkOiBkcmFmdC1iaXRhci1kYXRhY2Vu dGVyLXZwbi1hcHBsaWNhYmlsaXR5LTAxLnR4dA0KDQpIaSwNClRoYW5rcy4gUGxlYXNlIHNlZSBp bmxpbmUuDQoNClRoYW5rcywNCk5hYmlsDQoNCkZyb206IFh1eGlhb2h1IDx4dXhpYW9odUBodWF3 ZWkuY29tPG1haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tPj4NCkRhdGU6IFR1ZSwgOCBOb3YgMjAx MSAwMjo1MzowOSAtMDUwMA0KVG86ICJCaXRhciwgTmFiaWwgTiIgPG5hYmlsLm4uYml0YXJAb25l LnZlcml6b24uY29tPG1haWx0bzpuYWJpbC5uLmJpdGFyQG9uZS52ZXJpem9uLmNvbT4+LCAibDN2 cG5AaWV0Zi5vcmc8bWFpbHRvOmwzdnBuQGlldGYub3JnPiIgPGwzdnBuQGlldGYub3JnPG1haWx0 bzpsM3ZwbkBpZXRmLm9yZz4+LCAibDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3Jn PiIgPGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4+DQpDYzogU2FnZXNzaSA8 c2FqYXNzaUBjaXNjby5jb208bWFpbHRvOnNhamFzc2lAY2lzY28uY29tPj4sICJtaXJjZWEucGlz aWNhQGJ0LmNvbTxtYWlsdG86bWlyY2VhLnBpc2ljYUBidC5jb20+IiA8bWlyY2VhLnBpc2ljYUBi dC5jb208bWFpbHRvOm1pcmNlYS5waXNpY2FAYnQuY29tPj4sICJMdXl1YW4gRmFuZyAobHVmYW5n KSIgPGx1ZmFuZ0BjaXNjby5jb208bWFpbHRvOmx1ZmFuZ0BjaXNjby5jb20+PiwgInkuaWtlamly aUBudHQuY29tPG1haWx0bzp5LmlrZWppcmlAbnR0LmNvbT4iIDx5LmlrZWppcmlAbnR0LmNvbTxt YWlsdG86eS5pa2VqaXJpQG50dC5jb20+Pg0KU3ViamVjdDogcmU6IFlvdXIgaW5wdXQgb24gdGhl IGZvbGxvd2luZyBkcmFmdCBpcyBhcHByZWNpYXRlZDogZHJhZnQtYml0YXItZGF0YWNlbnRlci12 cG4tYXBwbGljYWJpbGl0eS0wMS50eHQNCg0KSGkgTmFiaWwsDQoNCkl04oCZcyBhIHZlcnkgY29t cHJlaGVuc2l2ZSBkb2MuDQoNCg0KU29tZSBjb21tb25zOg0KDQox44CBIEluIHNlY3Rpb24gNi4x LCBpdCBzYWlkOiDigJxBcyB0aGUgbnVtYmVyIG9mIHRlbmFudHMgaW4gaW5kaXZpZHVhbCBWTEFO IGlzbGFuZHMgc3VycGFzc2VzIDRLLCB0aGUgb3BlcmF0b3IgY291bGQgcHVzaCBWUExTIGRlcGxv eW1lbnQgZGVlcGVyIGluIHRoZSBEQyBuZXR3b3Jr4oCmLiBUaGUgVG9SIGFuZCBEQyBjb3JlIGVs ZW1lbnRzIG5lZWQgdG8gYmUgTVBMUyBlbmFibGVkIHdpdGggZXhpc3RpbmcgVlBMUyBzb2x1dGlv bnPigJ0sIElNSE8sIERDIGNvcmUgc3dpdGNoZXMgZG9u4oCZdCBuZWVkIHRvIGJlIE1QTFMgZW5h YmxlZCBzaW5jZSBJUCBiYXNlZCB0dW5uZWwgaXMgYWxzbyBhdmFpbGFibGUuDQo8TkI+IEl0IGlz IG9uZSBzY2VuYXJpbyBhbmQgaXQgaXMgb25lIGRlcGxveW1lbnQgY2hvaWNlLg0KDQo8WFhIPiBZ ZXMsIEkgYWdyZWUuIEkganVzdCBzdWdnZXN0IGl0IGNvdWxkIGJlIG1vcmUgY29tcHJlaGVuc2l2 ZS4NCg0KDQoy44CBIFN0aWxsIGluIHNlY3Rpb24gNi4xLCBpdCBzYWlkOiDigJ0g4oCmSG93ZXZl ciwgdGhpcyBtb2RlbCBkb2VzIG5vdCBzb2x2ZSB0aGUgTUFDIGV4cGxvc2lvbiBpc3N1ZSBhcyBU b1JzIHN0aWxsIG5lZWQgdG8gbGVhcm4gVk0gTUFDIGFkZHJlc3Nlcy7igJ0gSG93ZXZlciwgaW4g c2VjdGlvbiA2LjIuMSwgaXQgc2FpZDrigJ3igKZBbHRlcm5hdGl2ZWx5LCB0aGUgUEJCIGVuY2Fw c3VsYXRpb24gY2FuIGJlIGRvbmUgYXQgdGhlIFRvUi7igJ0gIEl0IGlzIGNvbmZ1c2VkIHNpbmNl IHBlcmZvcm1pbmcgUEJCIGVuY2Fwc3VsYXRpb24gYXQgdGhlIFRvUiB3b3VsZCBub3QgYWxsZXZp YXRlIHRoZSBNQUMtbGVhcm5pbmcgYnVyZGVuIG9uIHRoYXQgVG9SLg0KDQpTZWN0aW9uIDIuMSwg dG8gaGFuZGxlIHRoZSBNQUMgc2NhbGUsIGFuZCBsZXZpYXRpbmcgVk0gTUFDcyBmcm9tIFRvcnMg YW5kIGNvcmUgc3dpdGNoZXMsIFBCQiB3b3VsZCBzdGFydCBhdCB0aGUgVnN3LiBIZXJlIGlzIHRo ZSB0ZXh0Og0KDQoNCg0KIkluIGEgREMgZW52aXJvbm1lbnQsIFBCQiBtYWludGFpbnMgdHJhZGl0 aW9uYWwgRXRoZXJuZXQgZm9yd2FyZGluZw0KDQogICBwbGFuZSBhbmQgb3BlcmF0aW9uYWwgbW9k ZWwuIEZvciBleGFtcGxlLCBhIFZTdyBpbXBsZW1lbnRhdGlvbiBvZiBQQkINCg0KICAgY2FuIG1h a2UgdXNlIG9mIHRoZSAyNCBiaXQgSVNJRCB0YWcgaW5zdGVhZCBvZiB0aGUgMTIgYml0IFZMQU4g dGFnIHRvDQoNCiAgIGlkZW50aWZ5IHRoZSB2aXJ0dWFsIGJyaWRnaW5nIGRvbWFpbnMgYXNzb2Np YXRlZCB3aXRoIGRpZmZlcmVudCBWTQ0KDQogICBncm91cHMuIFRoZSBWU3cgdXBsaW5rIHRvd2Fy ZHMgdGhlIFRvUiBpbiBGaWd1cmUgMSBjYW4gc3RpbGwgYmUNCg0KICAgdHJlYXRlZCBhcyBhbiBF dGhlcm5ldCBiYWNrYm9uZSBpbnRlcmZhY2UuIEEgZnJhbWUgb3JpZ2luYXRlZCBieSBhIFZNDQoN CiAgIGNhbiBiZSBlbmNhcHN1bGF0ZWQgd2l0aCB0aGUgSVNJRCBhc3NpZ25lZCB0byB0aGUgVk0g VlN3IGludGVyZmFjZQ0KDQogICBhbmQgd2l0aCB0aGUgb3V0ZXIgREEgYW5kIFNBIE1BQ3MgYXNz b2NpYXRlZCB3aXRoIHRoZSByZXNwZWN0aXZlDQoNCiAgIGRlc3RpbmF0aW9uIGFuZCBzb3VyY2Ug c2VydmVyIGJsYWRlcywgYW5kIHRoZW4gc2VudCB0byB0aGUgVG9SDQoNCiAgIFN3aXRjaC4NCg0K DQogICA8c25hcD4NCg0KIldpdGggUEJCIGVuY2Fwc3VsYXRpb24sIFRvUnMgYW5kIENvcmUgU1dz IGRvIG5vdCBoYXZlIHRvIGhhbmRsZSBWTSAgTUFDIGFkZHJlc3NlcyBzbyB0aGUgc2l6ZSBvZiB0 aGVpciBNQUMgRklCIHRhYmxlcyBtYXkgZGVjcmVhc2UiDQoNCjxYWEg+IEkgdG90YWxseSBhZ3Jl ZSB3aXRoIHRoZSBhYm92ZSBzdGF0ZW1lbnQuIEkganVzdCBzdWdnZXN0IHdoZXRoZXIgeW91IGNv dWxkIGV4cGxhaW4gbW9yZSBhZnRlciB0aGUgc2VudGVuY2Ugb2Yg4oCd4oCmQWx0ZXJuYXRpdmVs eSwgdGhlIFBCQiBlbmNhcHN1bGF0aW9uIGNhbiBiZSBkb25lIGF0IHRoZSBUb1Iu4oCdIHNvIGFz IHRvIGVsaW1pbmF0ZSB0aGUgcG9zc2libGUgY29uZnVzaW9uLg0KDQoNCg0KM+OAgSBJbiA2LjIu Ni4yLiBQQkJOIGluIFZTdywgTDJWUE4gaW4gdGhlIFRvUiwgaXQgc2FpZDrigJ0gVGhlIHByb2Nl ZHVyZXMgZnJvbSB0aGUgcHJldmlvdXMgc2VjdGlvbiBhcmUgdXNlZCBhdCB0aGUgVlN3OiBQQkIg ZW5jYXBzdWxhdGlvbiBhbmQgRXRoZXJuZXQgQlZMQU5zIGNhbiBiZSB1c2VkIG9uIHRoZSBWU3cg dXBsaW5rLiBMMlZQTiBpbmZyYXN0cnVjdHVyZSBpcyByZXBsYWNpbmcgdGhlIEJWTEFOIGF0IHRo ZSBUb1IgZW5hYmxpbmcgdGhlIHVzZSBvZiBJUCAoR1JFIG9yIEwyVFApIG9yIE1QTFMgdHVubmVs aW5nLiAgTDIgbmV0d29ya2luZyBzdGlsbCBoYXMgdGhlIHNhbWUgY29udHJvbCBwbGFuZSBjaG9p Y2VzOiBJUy1JUyBbODAyLjFhcV0gYW5kL29yIEJHUCBbUEJCLUVWUE5dLCBpbmRlcGVuZGVudGx5 IGZyb20gdGhlIHR1bm5lbGluZyBjaG9pY2Uu4oCdIFNpbmNlIFBCQiBlbmNhcHN1bGF0aW9uIGhh cyBhbHJlYWR5IGJlZW4gZG9uZSBvbiB0aGUgVlN3LCB3aHkgZG8gd2Ugc3RpbGwgbmVlZCB0byBy dW4gODAyLjFhcSBhbmQgUEJCLUVWUE4gd2l0aCBhbm90aGVyIFBCQiBlbmNhcHN1bGF0aW9uIGxh eWVyPyBDYW7igJl0IHdlIHNpbXBseSB1c2UgYW55IEwyVlBOIHRlY2hub2xvZ3ksIGUuZy4sIFZQ TFMuIEluIGFkZGl0aW9uLCBub3RlIHRoYXQgaW4gRmlndXJlIDUsIGl0IHNhaWQg4oCcaW50cmEt REMgTDJWUE4gb3ZlciBJUCBvciBNUExTIHR1bm5lbGluZ+KAnS4NCjxOQj4gSSBhZ3JlZSB3ZSBu ZWVkIHRvIG1ha2UgdGhpcyBjbGVhcmVyLiBIb3dldmVyLCBQQkItRVZQTiBpcyBzdGlsbCBhcHBs aWNhYmxlIGVzcGVjaWFsbHkgaW4gdGhlIFdBTiBhcyBpbmRpY2F0ZWQgYW5kIGNhbiBiZSBpbiB0 aGUgTEFOIGFzIGluZGljYXRlZC4gODAyLjFhcSBpcyBsZXNzIG9mIGFuIGlzc3VlIGluIHRoaXMg c2NlbmFyaW8gYXMgZGVwaWN0ZWQgYnV0IGNhbiBleGl0ZWQgaW4gb3RoZXIgRGNzL290aGVyIGN1 c3RvbWVyIHNpdGVzIGNvbW11bmljYXRpbmcgdG8gdGhlIGRlaWN0ZWQgREMgaXMgcnVubmluZyBv ciBpZiB0aGVyZSBpcyBhIHNlZ21lbnQgaW4gdGhlIHNhbWUgREMgcnVubmluZyA4MDIuMWFxIHNp bXVsdGFuZW91c2x5Lg0KDQo8WFhIPiBZZXMsIEkgYWdyZWUgdGhhdCBQQkItRVZQTiBhbmQgU1BC IGNhbiBiZSB1c2VkIGhlcmUuIEhvd2V2ZXIsIHNpbmNlIGFueSBvdGhlciBMMlZQTiB0ZWNobm9s b2dpZXMgY291bGQgYWxzbyBiZWVuIHVzZWQgaGVyZSBhcyB3ZWxsLCBJTUhPLCB0aGVyZSBpcyBh YnNvbHV0ZWx5IG5vIG5lZWQgdG8gZ2l2ZSB0aGVzZSB0d28gY29uY3JldGUgYW5kIHNwZWNpZmlj IGV4YW1wbGVzIGhlcmUuIFlvdSBqdXN0IG5lZWQgdG8gc2F5IOKAnOKApkwyIG5ldHdvcmtpbmcg c3RpbGwgaGFzIHRoZSBzYW1lIGNvbnRyb2wgcGxhbmUgY2hvaWNlczogSVMtSVMgYW5kL29yIEJH UCwgaW5kZXBlbmRlbnRseSBmcm9tIHRoZSB0dW5uZWxpbmcgY2hvaWNlLuKAnSAgSXQgc2VlbXMg bW9yZSBjb21wcmVoZW5zaXZlIHdpdGhvdXQgYW55IGNvbmZ1c2lvbi4NCg0KDQpCZXN0IHJlZ2Fy ZHMsDQpYaWFvaHUNCg0K5Y+R5Lu25Lq6OiBsMnZwbi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzps MnZwbi1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIOS7 o+ihqCBCaXRhciwgTmFiaWwgTg0K5Y+R6YCB5pe26Ze0OiAyMDEx5bm0MTHmnIg45pelIDEzOjQy DQrmlLbku7bkuro6IGwzdnBuQGlldGYub3JnPG1haWx0bzpsM3ZwbkBpZXRmLm9yZz47IGwydnBu QGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4NCuaKhOmAgTogU2FnZXNzaTsgbWlyY2Vh LnBpc2ljYUBidC5jb208bWFpbHRvOm1pcmNlYS5waXNpY2FAYnQuY29tPjsgTHV5dWFuIEZhbmcg KGx1ZmFuZyk7IHkuaWtlamlyaUBudHQuY29tPG1haWx0bzp5LmlrZWppcmlAbnR0LmNvbT4NCuS4 u+mimDogWW91ciBpbnB1dCBvbiB0aGUgZm9sbG93aW5nIGRyYWZ0IGlzIGFwcHJlY2lhdGVkOiBk cmFmdC1iaXRhci1kYXRhY2VudGVyLXZwbi1hcHBsaWNhYmlsaXR5LTAxLnR4dA0KDQpIaSwNCldl IGhhZCBzdWJtaXR0ZWQgdGhlIGZvbGxvd2luZyBkcmFmdCBvbiB2cG4gYXBwbGljYWJpbGl0eSBm b3IgZGF0YSBjZW50ZXIuIFlvdXIgaW5wdXQgb24gdGhlIGRyYWZ0IGlzIGFwcHJlY2lhdGVkIGlu IGxpZ2h0IG9mIHNvbWUgb2YgdGhlIG9uZ29pbmcgZGlzY3Vzc2lvbi4gVGhlIGRyYWZ0IGlzIHRh cmdldGVkIGZvciBsM3ZwbiBhbmQgbDJ2cG4uDQpIZXJlIGlzIHRoZSBsaW5rOg0KDQpodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaXRhci1kYXRhY2VudGVyLXZwbi1hcHBsaWNhYmls aXR5LTAxDQoNCg0KQWJzdHJhY3QNCg0KDQoNCiAgIENsb3VkIENvbXB1dGluZyBoYXMgYmVlbiBh dHRyYWN0aW5nIGEgbG90IG9mIGF0dGVudGlvbiBmcm9tIHRoZQ0KDQogICBuZXR3b3JraW5nIGlu ZHVzdHJ5LiBTb21lIG9mIHRoZSBtb3N0IHB1YmxpY2l6ZWQgcmVxdWlyZW1lbnRzIGFyZQ0KDQog ICByZWxhdGVkIHRvIHRoZSBldm9sdXRpb24gb2YgdGhlIENsb3VkIE5ldHdvcmtpbmcgSW5mcmFz dHJ1Y3R1cmUgdG8NCg0KICAgYWNjb21tb2RhdGUgYSBsYXJnZSBudW1iZXIgb2YgdGVuYW50cywg ZWZmaWNpZW50IG5ldHdvcmsgdXRpbGl6YXRpb24sDQoNCiAgIHNjYWxhYmxlIGxvb3AgYXZvaWRh bmNlLCBhbmQgVmlydHVhbCBNYWNoaW5lIE1vYmlsaXR5Lg0KDQoNCg0KICAgVGhpcyBkcmFmdCBk ZXNjcmliZXMgYSBmcmFtZXdvcmsgZm9yIGNsb3VkIG5ldHdvcmtpbmcsIGhpZ2hsaWdodGluZw0K DQogICB0aGUgYXBwbGljYWJpbGl0eSBvZiBleGlzdGluZyB3b3JrIGluIHZhcmlvdXMgSUVURiBX b3JraW5nIEdyb3Vwcw0KDQogICAoZS5nLiwgUkZDcyBhbmQgZHJhZnRzIGRldmVsb3BlZCBpbiBJ RVRGIEwyVlBOIGFuZCBMM1ZQTiBXb3JraW5nDQoNCiAgIEdyb3VwcykgdG8gY2xvdWQgbmV0d29y a2luZywgYW5kIHRoZSBnYXBzIGFuZCBwcm9ibGVtcyB0aGF0IG5lZWQgdG8NCg0KICAgYmUgZnVy dGhlciBhZGRyZXNzZWQuIFRoYXQgaXMsIHRoZSBnb2FsIGlzIHRvIHVuZGVyc3RhbmQgd2hhdCBt YXkgYmUNCg0KICAgcmUtdXNlZCBmcm9tIHRoZSBjdXJyZW50IHByb3RvY29scyBhbmQgY2FsbCBv dXQgcmVxdWlyZW1lbnRzIHNwZWNpZmljDQoNCiAgIHRvIHRoZSBDbG91ZCBzcGFjZSB0aGF0IG5l ZWQgdG8gYmUgYWRkcmVzc2VkIGJ5IG5ldyBzdGFuZGFyZGl6YXRpb24NCg0KICAgd29yayB3aXRo IHByb3Bvc2VkIHNvbHV0aW9ucyBpbiBjZXJ0YWluIGNhc2VzLg0KDQoNClRoYW5rcywNCg0KTmFi aWwNCg== --Boundary_(ID_DQOuIZmy4fHOFNEOX6ABdQ) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJh Z3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCXRleHQtaW5kZW50OjIxLjBwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5IVE1MQ2hhcg0K CXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyI7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLmFwcGxlLXN0eWxlLXNwYW4NCgl7bXNvLXN0eWxl LW5hbWU6YXBwbGUtc3R5bGUtc3Bhbjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5oNTENCgl7bXNvLXN0eWxlLW5hbWU6aDUxOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7DQoJZm9udC13ZWlnaHQ6Ym9sZDt9DQpzcGFuLmFwcGxlLXRhYi1z cGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNwYW4uRW1haWxTdHlsZTI0 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3 Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6OTI1NjUyOTI0 Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNDAwNTY1 NDA2IDE1MTAxMDM5OTQgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3 MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1s ZXZlbC10ZXh0OiUx44CBOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDoxOC4wcHQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9 DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVs NQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNv LWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10 YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOy13 ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2UiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgTmFiaWwsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OuWui+S9kyI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk65a6L5L2TIj4gQml0YXIsIE5hYmlsIE4gW21haWx0bzpuYWJpbC5uLmJpdGFyQHZlcml6 b24uY29tXQ0KPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OuWui+S9kyI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+ PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk65a6L5L2TIj4gMjAxMTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTrlrovkvZMiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj4xMTwvc3Bhbj7mnIg8 c3BhbiBsYW5nPSJFTi1VUyI+OTwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+DQogNDoxOTxi cj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiPiBYdXhpYW9odTsgQml0YXIsIE5hYmlsIE47IGwzdnBuQGlldGYub3Jn OyBsMnZwbkBpZXRmLm9yZzxicj4NCjwvc3Bhbj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+ Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBTYWdlc3NpOyBtaXJjZWEucGlzaWNhQGJ0 LmNvbTsgTHV5dWFuIEZhbmcgKGx1ZmFuZyk7IHkuaWtlamlyaUBudHQuY29tPGJyPg0KPC9zcGFu PjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyI+IFJlOiBZb3VyIGlucHV0IG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQgaXMgYXBwcmVjaWF0ZWQ6 IGRyYWZ0LWJpdGFyLWRhdGFjZW50ZXItdnBuLWFwcGxpY2FiaWxpdHktMDEudHh0PG86cD48L286 cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2siPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPlRoYW5rcy4gUGxlYXNlIHNlZSBpbmxpbmUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhh bmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPk5hYmlsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5YdXhp YW9odSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnh1eGlhb2h1QGh1YXdlaS5jb20iPnh1eGlhb2h1QGh1 YXdlaS5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWUsIDggTm92IDIwMTEgMDI6NTM6 MDkgLTA1MDA8YnI+DQo8Yj5UbzogPC9iPiZxdW90O0JpdGFyLCBOYWJpbCBOJnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86bmFiaWwubi5iaXRhckBvbmUudmVyaXpvbi5jb20iPm5hYmlsLm4uYml0 YXJAb25lLnZlcml6b24uY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpsM3ZwbkBp ZXRmLm9yZyI+bDN2cG5AaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bDN2 cG5AaWV0Zi5vcmciPmwzdnBuQGlldGYub3JnPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0 bzpsMnZwbkBpZXRmLm9yZyI+bDJ2cG5AaWV0Zi5vcmc8L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9 Im1haWx0bzpsMnZwbkBpZXRmLm9yZyI+bDJ2cG5AaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNj OiA8L2I+U2FnZXNzaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNhamFzc2lAY2lzY28uY29tIj5zYWph c3NpQGNpc2NvLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86bWlyY2VhLnBpc2lj YUBidC5jb20iPm1pcmNlYS5waXNpY2FAYnQuY29tPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1pcmNlYS5waXNpY2FAYnQuY29tIj5taXJjZWEucGlzaWNhQGJ0LmNvbTwvYT4mZ3Q7LCAm cXVvdDtMdXl1YW4gRmFuZyAobHVmYW5nKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmx1ZmFu Z0BjaXNjby5jb20iPmx1ZmFuZ0BjaXNjby5jb208L2E+Jmd0OywNCiAmcXVvdDs8YSBocmVmPSJt YWlsdG86eS5pa2VqaXJpQG50dC5jb20iPnkuaWtlamlyaUBudHQuY29tPC9hPiZxdW90OyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnkuaWtlamlyaUBudHQuY29tIj55LmlrZWppcmlAbnR0LmNvbTwvYT4m Z3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPnJlOiBZb3VyIGlucHV0IG9uIHRoZSBmb2xsb3dpbmcg ZHJhZnQgaXMgYXBwcmVjaWF0ZWQ6IGRyYWZ0LWJpdGFyLWRhdGFjZW50ZXItdnBuLWFwcGxpY2Fi aWxpdHktMDEudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgTmFiaWwsPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SXTigJlz IGEgdmVyeSBjb21wcmVoZW5zaXZlIGRvYy48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5Tb21lIGNvbW1vbnM6PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmUgc3R5bGU9 Im1hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O3BhZ2UtYnJlYWstYmVmb3Jl OmFsd2F5czttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+MeOAgTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+IDwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluIHNlY3Rpb24gNi4xLCBp dCBzYWlkOiDigJxBcyB0aGUgbnVtYmVyIG9mIHRlbmFudHMgaW4gaW5kaXZpZHVhbCBWTEFOIGlz bGFuZHMgc3VycGFzc2VzIDRLLCB0aGUgb3BlcmF0b3IgY291bGQgcHVzaCBWUExTIGRlcGxveW1l bnQgZGVlcGVyIGluIHRoZSBEQyBuZXR3b3Jr4oCmLiBUaGUgVG9SIGFuZCBEQyBjb3JlIGVsZW1l bnRzIG5lZWQgdG8gYmUgTVBMUyBlbmFibGVkIHdpdGggZXhpc3RpbmcgVlBMUyBzb2x1dGlvbnPi gJ0sIElNSE8sIERDIGNvcmUgc3dpdGNoZXMgZG9u4oCZdCBuZWVkIHRvIGJlIE1QTFMgZW5hYmxl ZCBzaW5jZSBJUCBiYXNlZCB0dW5uZWwgaXMgYWxzbyBhdmFpbGFibGUuPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbHQ7TkImZ3Q7IEl0IGlz IG9uZSBzY2VuYXJpbyBhbmQgaXQgaXMgb25lIGRlcGxveW1lbnQgY2hvaWNlLiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbHQ7WFhIJmd0OyBZZXMsIEkgYWdyZWUu IEkganVzdCBzdWdnZXN0IGl0IGNvdWxkIGJlIG1vcmUgY29tcHJlaGVuc2l2ZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4w cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDtwYWdlLWJyZWFrLWJlZm9yZTphbHdheXM7bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjLjgIE8c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiA8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TdGlsbCBpbiBzZWN0aW9uIDYuMSwgaXQgc2FpZDog4oCd IOKApkhvd2V2ZXIsIHRoaXMgbW9kZWwgZG9lcyBub3Qgc29sdmUgdGhlIE1BQyBleHBsb3Npb24g aXNzdWUgYXMgVG9ScyBzdGlsbCBuZWVkIHRvIGxlYXJuIFZNIE1BQyBhZGRyZXNzZXMu4oCdIEhv d2V2ZXIsIGluIHNlY3Rpb24gNi4yLjEsIGl0IHNhaWQ64oCd4oCmQWx0ZXJuYXRpdmVseSwgdGhl IFBCQiBlbmNhcHN1bGF0aW9uIGNhbiBiZSBkb25lIGF0IHRoZSBUb1Iu4oCdICZuYnNwO0l0IGlz IGNvbmZ1c2VkIHNpbmNlIHBlcmZvcm1pbmcgUEJCIGVuY2Fwc3VsYXRpb24gYXQgdGhlIFRvUiB3 b3VsZCBub3QgYWxsZXZpYXRlIHRoZSBNQUMtbGVhcm5pbmcgYnVyZGVuIG9uIHRoYXQgVG9SLiA8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPlNlY3Rpb24gMi4xLCB0byBoYW5kbGUgdGhlIE1BQyBzY2FsZSwgYW5kIGxldmlhdGluZyBW TSBNQUNzIGZyb20gVG9ycyBhbmQgY29yZSBzd2l0Y2hlcywgUEJCIHdvdWxkIHN0YXJ0IGF0IHRo ZSBWc3cuIEhlcmUgaXMgdGhlIHRleHQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBjbGFzcz0i YXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0i YXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJy ZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZxdW90O0lu IGEgREMgZW52aXJvbm1lbnQsIFBCQiBtYWludGFpbnMgdHJhZGl0aW9uYWwgRXRoZXJuZXQgZm9y d2FyZGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2Ut YnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7IHBsYW5lIGFuZCBvcGVyYXRpb25hbCBtb2RlbC4gRm9yIGV4YW1wbGUsIGEgVlN3IGlt cGxlbWVudGF0aW9uIG9mIFBCQjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3ByZT4NCjxwcmUg c3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxl LXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7IGNhbiBtYWtlIHVzZSBvZiB0aGUgMjQgYml0IElTSUQgdGFnIGlu c3RlYWQgb2YgdGhlIDEyIGJpdCBWTEFOIHRhZyB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48 L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gY2xhc3M9 ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGlkZW50aWZ5IHRoZSB2aXJ0dWFsIGJyaWRn aW5nIGRvbWFpbnMgYXNzb2NpYXRlZCB3aXRoIGRpZmZlcmVudCBWTTxvOnA+PC9vOnA+PC9zcGFu Pjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNw YW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGdyb3Vwcy4gVGhlIFZTdyB1 cGxpbmsgdG93YXJkcyB0aGUgVG9SIGluIEZpZ3VyZSAxIGNhbiBzdGlsbCBiZTxvOnA+PC9vOnA+ PC9zcGFuPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5 cyI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHRyZWF0ZWQgYXMg YW4gRXRoZXJuZXQgYmFja2JvbmUgaW50ZXJmYWNlLiBBIGZyYW1lIG9yaWdpbmF0ZWQgYnkgYSBW TTxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWst YmVmb3JlOmFsd2F5cyI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 IGNhbiBiZSBlbmNhcHN1bGF0ZWQgd2l0aCB0aGUgSVNJRCBhc3NpZ25lZCB0byB0aGUgVk0gVlN3 IGludGVyZmFjZTxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBh Z2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7IGFuZCB3aXRoIHRoZSBvdXRlciBEQSBhbmQgU0EgTUFDcyBhc3NvY2lhdGVkIHdp dGggdGhlIHJlc3BlY3RpdmU8bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wcmU+DQo8cHJlIHN0 eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1z cGFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyBkZXN0aW5hdGlvbiBhbmQgc291cmNlIHNlcnZlciBibGFkZXMsIGFu ZCB0aGVuIHNlbnQgdG8gdGhlIFRvUjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3ByZT4NCjxw cmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0 eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7IFN3aXRjaC48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9w cmU+DQo8c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj48YnIgY2xlYXI9ImFsbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFs d2F5cyI+DQo8L3NwYW4+PC9zcGFuPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3 YXlzIj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgJmx0O3NuYXAm Z3Q7PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcHJlPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXN0 eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxiciBjbGVhcj0iYWxsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlz Ij4NCjwvc3Bhbj48L3NwYW4+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBw bGUtc3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+JnF1b3Q7V2l0aCBQQkIgZW5jYXBzdWxh dGlvbiwgVG9ScyBhbmQgQ29yZSBTV3MgZG8gbm90IGhhdmUgdG8gaGFuZGxlIFZNJm5ic3A7IE1B QyBhZGRyZXNzZXMgc28gdGhlIHNpemUgb2YgdGhlaXIgTUFDIEZJQiB0YWJsZXMgbWF5IGRlY3Jl YXNlJnF1b3Q7PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGNsYXNzPSJhcHBsZS1zdHlsZS1zcGFuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtc3R5 bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbHQ7WFhIJmd0OyBJIHRvdGFsbHkgYWdyZWUgd2l0aCB0aGUgYWJvdmUgc3RhdGVt ZW50LiBJIGp1c3Qgc3VnZ2VzdCB3aGV0aGVyIHlvdSBjb3VsZCBleHBsYWluIG1vcmUgYWZ0ZXIg dGhlIHNlbnRlbmNlDQogb2YgPC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPuKAneKApkFsdGVybmF0aXZlbHksIHRoZSBQ QkIgZW5jYXBzdWxhdGlvbiBjYW4gYmUgZG9uZSBhdCB0aGUgVG9SLuKAnSBzbyBhcyB0byBlbGlt aW5hdGUgdGhlIHBvc3NpYmxlIGNvbmZ1c2lvbi4NCjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUt c3R5bGUtc3BhbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPHByZSBzdHlsZT0icGFn ZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxl LXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O3Bh Z2UtYnJlYWstYmVmb3JlOmFsd2F5czttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25v cmUiPjPjgIE8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JbiA8YSBuYW1lPSJzZWN0aW9uLTYu Mi42LjIiPjYuMi42LjI8L2E+LiBQQkJOIGluIFZTdywgTDJWUE4gaW4gdGhlIFRvUiwgaXQgc2Fp ZDrigJ08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+IDwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlRoZSBwcm9jZWR1cmVzIGZyb20gdGhlIHByZXZpb3VzIHNlY3Rpb24gYXJlIHVzZWQgYXQgdGhl IFZTdzogUEJCIGVuY2Fwc3VsYXRpb24gYW5kIEV0aGVybmV0IEJWTEFOcyBjYW4gYmUgdXNlZCBv biB0aGUgVlN3IHVwbGluay4gTDJWUE4gaW5mcmFzdHJ1Y3R1cmUgaXMgcmVwbGFjaW5nIHRoZSBC VkxBTiBhdCB0aGUgVG9SIGVuYWJsaW5nIHRoZSB1c2Ugb2YgSVAgKEdSRSBvciBMMlRQKSBvciBN UExTIHR1bm5lbGluZy4mbmJzcDsgTDIgbmV0d29ya2luZyBzdGlsbCBoYXMgdGhlIHNhbWUgY29u dHJvbCBwbGFuZSBjaG9pY2VzOiBJUy1JUyBbODAyLjFhcV0gYW5kL29yIEJHUCBbUEJCLUVWUE5d LCBpbmRlcGVuZGVudGx5IGZyb20gdGhlIHR1bm5lbGluZyBjaG9pY2Uu4oCdIFNpbmNlIFBCQiBl bmNhcHN1bGF0aW9uIGhhcyBhbHJlYWR5IGJlZW4gZG9uZSBvbiB0aGUgVlN3LCB3aHkgZG8gd2Ug c3RpbGwgbmVlZCB0byBydW4gODAyLjFhcSBhbmQgUEJCLUVWUE4gd2l0aCBhbm90aGVyIFBCQiBl bmNhcHN1bGF0aW9uIGxheWVyPyBDYW7igJl0IHdlIHNpbXBseSB1c2UgYW55IEwyVlBOIHRlY2hu b2xvZ3ksIGUuZy4sIFZQTFMuIEluIGFkZGl0aW9uLCBub3RlIHRoYXQgaW4gRmlndXJlIDUsIGl0 IHNhaWQg4oCcaW50cmEtREMgTDJWUE4gb3ZlciBJUCBvciBNUExTIHR1bm5lbGluZ+KAnS48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbHQ7TkImZ3Q7IEkgYWdyZWUgd2UgbmVl ZCB0byBtYWtlIHRoaXMgY2xlYXJlci4gSG93ZXZlciwgUEJCLUVWUE4gaXMgc3RpbGwgYXBwbGlj YWJsZSBlc3BlY2lhbGx5IGluIHRoZSBXQU4gYXMgaW5kaWNhdGVkIGFuZCBjYW4gYmUgaW4gdGhl IExBTiBhcyBpbmRpY2F0ZWQuDQogODAyLjFhcSBpcyBsZXNzIG9mIGFuIGlzc3VlIGluIHRoaXMg c2NlbmFyaW8gYXMgZGVwaWN0ZWQgYnV0IGNhbiBleGl0ZWQgaW4gb3RoZXIgRGNzL290aGVyIGN1 c3RvbWVyIHNpdGVzIGNvbW11bmljYXRpbmcgdG8gdGhlIGRlaWN0ZWQgREMgaXMgcnVubmluZyBv ciBpZiB0aGVyZSBpcyBhIHNlZ21lbnQgaW4gdGhlIHNhbWUgREMgcnVubmluZyA4MDIuMWFxIHNp bXVsdGFuZW91c2x5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbHQ7WFhI Jmd0OyBZZXMsIEkgYWdyZWUgdGhhdCBQQkItRVZQTiBhbmQgU1BCIGNhbiBiZSB1c2VkIGhlcmUu IEhvd2V2ZXIsIHNpbmNlIGFueSBvdGhlciBMMlZQTiB0ZWNobm9sb2dpZXMgY291bGQgYWxzbyBi ZWVuIHVzZWQgaGVyZSBhcyB3ZWxsLCBJTUhPLA0KIHRoZXJlIGlzIGFic29sdXRlbHkgbm8gbmVl ZCB0byBnaXZlIHRoZXNlIHR3byBjb25jcmV0ZSBhbmQgc3BlY2lmaWMgZXhhbXBsZXMgaGVyZS4g WW91IGp1c3QgbmVlZCB0byBzYXkg4oCc4oCmPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+TDIgbmV0d29ya2luZyBzdGlsbCBoYXMg dGhlIHNhbWUgY29udHJvbCBwbGFuZSBjaG9pY2VzOg0KIElTLUlTIGFuZC9vciBCR1AsIGluZGVw ZW5kZW50bHkgZnJvbSB0aGUgdHVubmVsaW5nIGNob2ljZS7igJ0gPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7SXQgc2Vl bXMgbW9yZSBjb21wcmVoZW5zaXZlIHdpdGhvdXQgYW55IGNvbmZ1c2lvbi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7dGV4dC1pbmRlbnQ6MGNtIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5YaWFvaHU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6YmxhY2siPuWPkeS7tuS6 ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjpibGFjayI+ DQo8YSBocmVmPSJtYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZyI+bDJ2cG4tYm91bmNlc0Bp ZXRmLm9yZzwvYT4gWzxhIGhyZWY9Im1haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnIj5tYWls dG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOmJsYWNrIj7ku6PooaggPC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk65a6L5L2TO2NvbG9yOmJsYWNrIj5CaXRhciwgTmFiaWwgTjxicj4NCjwvc3Bhbj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6Ymxh Y2siPuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OuWui+S9 kztjb2xvcjpibGFjayI+IDIwMTE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOmJsYWNrIj7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+MTE8 L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjg8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMi Pg0KIDEzOjQyPGJyPg0KPC9zcGFuPjxiPuaUtuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IDxhIGhyZWY9Im1haWx0bzpsM3ZwbkBpZXRmLm9y ZyI+DQpsM3ZwbkBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpsMnZwbkBpZXRmLm9yZyI+ bDJ2cG5AaWV0Zi5vcmc8L2E+PGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVT Ij46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFNhZ2Vzc2k7IDxhIGhyZWY9Im1haWx0 bzptaXJjZWEucGlzaWNhQGJ0LmNvbSI+DQptaXJjZWEucGlzaWNhQGJ0LmNvbTwvYT47IEx1eXVh biBGYW5nIChsdWZhbmcpOyA8YSBocmVmPSJtYWlsdG86eS5pa2VqaXJpQG50dC5jb20iPg0KeS5p a2VqaXJpQG50dC5jb208L2E+PGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVT Ij46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFlvdXIgaW5wdXQgb24gdGhlIGZvbGxv d2luZyBkcmFmdCBpcyBhcHByZWNpYXRlZDogZHJhZnQtYml0YXItZGF0YWNlbnRlci12cG4tYXBw bGljYWJpbGl0eS0wMS50eHQ8L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SGks PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPldlIGhhZCBzdWJt aXR0ZWQgdGhlIGZvbGxvd2luZyBkcmFmdCBvbiB2cG4gYXBwbGljYWJpbGl0eSBmb3IgZGF0YSBj ZW50ZXIuIFlvdXIgaW5wdXQgb24gdGhlIGRyYWZ0IGlzIGFwcHJlY2lhdGVkIGluIGxpZ2h0IG9m IHNvbWUgb2YgdGhlIG9uZ29pbmcNCiBkaXNjdXNzaW9uLiBUaGUgZHJhZnQgaXMgdGFyZ2V0ZWQg Zm9yIGwzdnBuIGFuZCBsMnZwbi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+SGVyZSBpcyB0aGUgbGluazombmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWJpdGFyLWRhdGFjZW50ZXItdnBuLWFwcGxpY2FiaWxpdHktMDEiPmh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWJpdGFyLWRhdGFjZW50ZXItdnBuLWFwcGxpY2FiaWxpdHktMDE8L2E+ PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdh eXMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+QWJzdHJhY3Q8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTph bHdheXMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6 YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyBDbG91ZCBDb21wdXRpbmcgaGFzIGJlZW4gYXR0cmFjdGluZyBh IGxvdCBvZiBhdHRlbnRpb24gZnJvbSB0aGU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdl LWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IG5ldHdvcmtpbmcgaW5kdXN0cnkuIFNv bWUgb2YgdGhlIG1vc3QgcHVibGljaXplZCByZXF1aXJlbWVudHMgYXJlPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyByZWxhdGVk IHRvIHRoZSBldm9sdXRpb24gb2YgdGhlIENsb3VkIE5ldHdvcmtpbmcgSW5mcmFzdHJ1Y3R1cmUg dG88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7IGFjY29tbW9kYXRlIGEgbGFyZ2UgbnVtYmVyIG9mIHRlbmFudHMsIGVmZmljaWVu dCBuZXR3b3JrIHV0aWxpemF0aW9uLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJl YWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgc2NhbGFibGUgbG9vcCBhdm9pZGFuY2UsIGFu ZCBWaXJ0dWFsIE1hY2hpbmUgTW9iaWxpdHkuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFn ZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBh Z2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgVGhpcyBkcmFmdCBkZXNjcmliZXMg YSBmcmFtZXdvcmsgZm9yIGNsb3VkIG5ldHdvcmtpbmcsIGhpZ2hsaWdodGluZzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgdGhl IGFwcGxpY2FiaWxpdHkgb2YgZXhpc3Rpbmcgd29yayBpbiB2YXJpb3VzIElFVEYgV29ya2luZyBH cm91cHM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7IChlLmcuLCBSRkNzIGFuZCBkcmFmdHMgZGV2ZWxvcGVkIGluIElFVEYgTDJW UE4gYW5kIEwzVlBOIFdvcmtpbmc8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFr LWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEdyb3VwcykgdG8gY2xvdWQgbmV0d29ya2luZywg YW5kIHRoZSBnYXBzIGFuZCBwcm9ibGVtcyB0aGF0IG5lZWQgdG88L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGJlIGZ1cnRoZXIg YWRkcmVzc2VkLiBUaGF0IGlzLCB0aGUgZ29hbCBpcyB0byB1bmRlcnN0YW5kIHdoYXQgbWF5IGJl PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyByZS11c2VkIGZyb20gdGhlIGN1cnJlbnQgcHJvdG9jb2xzIGFuZCBjYWxsIG91dCBy ZXF1aXJlbWVudHMgc3BlY2lmaWM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFr LWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHRvIHRoZSBDbG91ZCBzcGFjZSB0aGF0IG5lZWQg dG8gYmUgYWRkcmVzc2VkIGJ5IG5ldyBzdGFuZGFyZGl6YXRpb248L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHdvcmsgd2l0aCBw cm9wb3NlZCBzb2x1dGlvbnMgaW4gY2VydGFpbiBjYXNlcy48L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxiciBjbGVhcj0iYWxsIiBzdHlsZT0icGFnZS1i cmVhay1iZWZvcmU6YWx3YXlzIj4NCjwvc3Bhbj4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVm b3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj5UaGFua3MsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1i ZWZvcmU6YWx3YXlzIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPk5hYmlsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --Boundary_(ID_DQOuIZmy4fHOFNEOX6ABdQ)-- From xuxiaohu@huawei.com Tue Nov 8 19:54:51 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5642E11E80CE; Tue, 8 Nov 2011 19:54:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.962 X-Spam-Level: X-Spam-Status: No, score=-1.962 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQDW4ZGpICVo; Tue, 8 Nov 2011 19:54:50 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 302B711E80C0; Tue, 8 Nov 2011 19:54:49 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUD00C2ZK4KMH@szxga05-in.huawei.com>; Wed, 09 Nov 2011 11:53:09 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUD00F8YK4JWB@szxga05-in.huawei.com>; Wed, 09 Nov 2011 11:53:08 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEV62809; Wed, 09 Nov 2011 11:53:06 +0800 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 09 Nov 2011 11:53:02 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Wed, 09 Nov 2011 11:52:59 +0800 Date: Wed, 09 Nov 2011 03:52:59 +0000 From: Xuxiaohu Subject: re: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt In-reply-to: <35DD67BC-C829-47FF-BFE1-47880518B504@unbehagen.net> X-Originating-IP: [10.108.4.59] To: Paul Unbehagen , Vishwas Manral Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE747CCE@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_Sn0TYnmoj1gFVIWr3jV68g)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-index: AQHMnowp5M4qVC+j2UuxqjGSM1MjpZWjWvgAgACLffA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74774D@szxeml525-mbs.china.huawei.com> <2073A6C5467C99478898544C6EBA3F4602BD5D2CF4@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE747C3A@szxeml525-mbs.china.huawei.com> <35DD67BC-C829-47FF-BFE1-47880518B504@unbehagen.net> X-Mailman-Approved-At: Wed, 09 Nov 2011 02:31:01 -0800 Cc: "l2vpn@ietf.org" , Sagessi , "l3vpn@ietf.org" , "mircea.pisica@bt.com" , "Luyuan Fang \(lufang\)" , "y.ikejiri@ntt.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 03:54:51 -0000 --Boundary_(ID_Sn0TYnmoj1gFVIWr3jV68g) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 SSBhZ3JlZSB0aGF0IFBCQiBjb3VsZCBzY2FsZSB2ZXJ5IHdlbGwgaWYgaXQgaXMgcGVyZm9ybWVk IGF0IHByb3BlciBsb2NhdGlvbnMgd2hlcmUgdGhlIE1BQyB0YWJsZSBpcyDigJxsYXJnZSBlbm91 Z2jigJ0uDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCuWPkeS7tuS6ujogUGF1bCBVbmJlaGFnZW4g W21haWx0bzpwYXVsQHVuYmVoYWdlbi5uZXRdDQrlj5HpgIHml7bpl7Q6IDIwMTHlubQxMeaciDnm l6UgMTE6MjQNCuaUtuS7tuS6ujogVmlzaHdhcyBNYW5yYWwNCuaKhOmAgTogWHV4aWFvaHU7IGwy dnBuQGlldGYub3JnOyBTYWdlc3NpOyBsM3ZwbkBpZXRmLm9yZzsgbWlyY2VhLnBpc2ljYUBidC5j b207IEx1eXVhbiBGYW5nIChsdWZhbmcpOyB5LmlrZWppcmlAbnR0LmNvbQ0K5Li76aKYOiBSZTog WW91ciBpbnB1dCBvbiB0aGUgZm9sbG93aW5nIGRyYWZ0IGlzIGFwcHJlY2lhdGVkOiBkcmFmdC1i aXRhci1kYXRhY2VudGVyLXZwbi1hcHBsaWNhYmlsaXR5LTAxLnR4dA0KDQpKdXN0IHRvIGJlIGNs ZWFyIHdydCBQQkIsIHRoZSBNQUMgdGFibGVzIG9ubHkgbmVlZCB0byBiZSBsYXJnZSBlbm91Z2gg dG8gbGVhcm4gdGhlIE1hYydzIG9mIHRoZSBlbmQgc3lzdGVtcyBpbiB0aGUgc2FtZSBJU0lEIHRo YXQgZXhpc3Qgb24gdGhhdCBlZGdlIHN3aXRjaCwgbm90IGFsbCBNQUMncyBpbiB0aGUgbmV0d29y ay4gVGhpcyBpcyB3aGF0IG1ha2VzIFBCQiBzY2FsZSBzbyB3ZWxsIGluIHRoZXNlIHR5cGVzIG9m IGVudmlyb25tZW50cy4NCi0tDQpQYXVsIFVuYmVoYWdlbg0KDQpTZW50IGZyb20gbXkgaVBhZA0K DQpPbiBOb3YgOSwgMjAxMSwgYXQgMjowMyBQTSwgVmlzaHdhcyBNYW5yYWwgPHZpc2h3YXMuaWV0 ZkBnbWFpbC5jb208bWFpbHRvOnZpc2h3YXMuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToNClhpYW9o dSwNCg0KRm9yIHRoZSBwdXJwb3NlIG9mIHJlZHVjaW5nIHVua293biB1bmljYXN0LyBtdWx0aWNh c3QgeW91IGNvdWxkIHVzZSBzb21lIG9mZiBwYXRoIGxlYXJuaW5nIGFuZCB0aGVuIGRpc2NhcmQg dGhlIHVua25vd25zLg0KDQpPZmNvdXJzZSB0aGUgTUFDIHRhYmxlcyBpbiBlZGdlIGRldmljZSBu ZWVkIHRvIGJpZyBlbm91Z2ggdG8gbGVhcm4gdGhlIE1BQyBhZGRyZXNzZXMgb2YgYWxsIHRoZSBl bmQgc3lzdGVtcy4NCg0KVGhhbmtzLA0KVmlzaHdhcw0KMjAxMS8xMS84IFh1eGlhb2h1IDx4dXhp YW9odUBodWF3ZWkuY29tPG1haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tPj4NCkJ5IHRoZSB3YXks IGl0IHdvdWxkIGJlIGJldHRlciB0byBwdXNoIHRoZSBQQkIgYXMgY2xvc2UgdG8gdGhlIGVuZC1z eXN0ZW1zIGFzIHBvc3NpYmxlIGZyb20gdGhlIHBlcnNwZWN0aXZlIG9mIE1BQyBmb3J3YXJkaW5n IHRhYmxlIHNjYWxhYmlsaXR5LiBIb3dldmVyLCB0aGUgdW5rbm93biB1bmljYXN0IGZsb29kIGlt cGFjdCBpc3N1ZSB3b3VsZCBiZSB3b3JzZW4gYWNjb3JkaW5nbHkuIEZvciBleGFtcGxlLCBpbiBh IG5vcm1hbCBMYXllcjIgbmV0d29yaywgaWYgdHdvIFZNcyBhdHRhY2hlZCB0byB0aGUgZ2l2ZW4g VG9SIGFyZSBmcmVxdWVudGx5IGNvbW11bmljYXRlZCB3aXRoIGVhY2ggb3RoZXIgYW5kIGhlbmNl IHRoZWlyIE1BQyBhZGRyZXNzIGVudHJpZXMgb24gdGhpcyBUb1Igd2lsbCBub3QgYmUgZXhwaXJl ZCwgdGhlIHRyYWZmaWMgZGVzdGluZWQgZm9yIGFueSBvZiB0aG9zZSB0d28gVk1zIGZyb20gYSBy ZW1vdGUgVk0gY291bGQgYmUgZmxvb2RlZCBhcyB1bmtub3duIHVuaWNhc3QgdW50aWwgdGhlIHRy YWZmaWMgcmVhY2ggdGhpcyBUb1Igd2hpY2ggaW4gdHVybiBmb3J3YXJkIHRoZSB0cmFmZmljIHRv IHRoZSBkZXN0aW5hdGlvbiBWTSBpbiB1bmljYXN0LiAgSG93ZXZlciwgb25jZSBQQkIgaXMgcGVy Zm9ybWVkIGF0IGVhY2ggVlN3LCB0aGF0IHRyYWZmaWMgd291bGQgYmUgZmxvb2RlZCB1bnRpbCBp dCByZWFjaCB0aGUgZmluYWwgZGVzdGluYXRpb24gcGh5c2ljYWwgc2VydmVyLiAgSXTigJlzIGEg aGFyZCB0cmFkZW9mZiwgaXNu4oCZdCBpdD8NCg0KWGlhb2h1DQoNCg0K5Y+R5Lu25Lq6OiBYdXhp YW9odQ0K5Y+R6YCB5pe26Ze0OiAyMDEx5bm0MTHmnIg55pelIDEwOjA4DQrmlLbku7bkuro6ICdC YWx1cywgRmxvcmluIFN0ZWxpYW4gKEZsb3JpbiknOyBCaXRhciwgTmFiaWwgTjsgbDN2cG5AaWV0 Zi5vcmc8bWFpbHRvOmwzdnBuQGlldGYub3JnPjsgbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBu QGlldGYub3JnPg0K5oqE6YCBOiBMdXl1YW4gRmFuZyAobHVmYW5nKTsgU2FnZXNzaTsgeS5pa2Vq aXJpQG50dC5jb208bWFpbHRvOnkuaWtlamlyaUBudHQuY29tPjsgbWlyY2VhLnBpc2ljYUBidC5j b208bWFpbHRvOm1pcmNlYS5waXNpY2FAYnQuY29tPg0K5Li76aKYOiByZTogWW91ciBpbnB1dCBv biB0aGUgZm9sbG93aW5nIGRyYWZ0IGlzIGFwcHJlY2lhdGVkOiBkcmFmdC1iaXRhci1kYXRhY2Vu dGVyLXZwbi1hcHBsaWNhYmlsaXR5LTAxLnR4dA0KDQrlj5Hku7bkuro6IEJhbHVzLCBGbG9yaW4g U3RlbGlhbiAoRmxvcmluKSBbbWFpbHRvOmZsb3Jpbi5iYWx1c0BhbGNhdGVsLWx1Y2VudC5jb208 bWFpbHRvOmZsb3Jpbi5iYWx1c0BhbGNhdGVsLWx1Y2VudC5jb20+XQ0K5Y+R6YCB5pe26Ze0OiAy MDExDQrlubQxMeaciDnml6UgNTozNA0K5pS25Lu25Lq6OiBYdXhpYW9odTsgQml0YXIsIE5hYmls IE47IGwzdnBuQGlldGYub3JnPG1haWx0bzpsM3ZwbkBpZXRmLm9yZz47IGwydnBuQGlldGYub3Jn PG1haWx0bzpsMnZwbkBpZXRmLm9yZz4NCuaKhOmAgTogTHV5dWFuIEZhbmcgKGx1ZmFuZyk7IFNh Z2Vzc2k7IHkuaWtlamlyaUBudHQuY29tPG1haWx0bzp5LmlrZWppcmlAbnR0LmNvbT47IG1pcmNl YS5waXNpY2FAYnQuY29tPG1haWx0bzptaXJjZWEucGlzaWNhQGJ0LmNvbT4NCuS4u+mimDogUkU6 IFlvdXIgaW5wdXQgb24gdGhlIGZvbGxvd2luZyBkcmFmdCBpcyBhcHByZWNpYXRlZDogZHJhZnQt Yml0YXItZGF0YWNlbnRlci12cG4tYXBwbGljYWJpbGl0eS0wMS50eHQNCg0KVGhhbmtzIGZvciB0 aGUgY29tbWVudHMsIHNlZSBpbi1saW5l4oCmDQoNCkZyb206IGwydnBuLWJvdW5jZXNAaWV0Zi5v cmc8bWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bDJ2cG4tYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBYdXhp YW9odQ0KU2VudDogTW9uZGF5LCBOb3ZlbWJlciAwNywgMjAxMSAxMTo1MyBQTQ0KVG86IEJpdGFy LCBOYWJpbCBOOyBsM3ZwbkBpZXRmLm9yZzxtYWlsdG86bDN2cG5AaWV0Zi5vcmc+OyBsMnZwbkBp ZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+DQpDYzogTHV5dWFuIEZhbmcgKGx1ZmFuZyk7 IFNhZ2Vzc2k7IHkuaWtlamlyaUBudHQuY29tPG1haWx0bzp5LmlrZWppcmlAbnR0LmNvbT47IG1p cmNlYS5waXNpY2FAYnQuY29tPG1haWx0bzptaXJjZWEucGlzaWNhQGJ0LmNvbT4NClN1YmplY3Q6 IHJlOiBZb3VyIGlucHV0IG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQgaXMgYXBwcmVjaWF0ZWQ6IGRy YWZ0LWJpdGFyLWRhdGFjZW50ZXItdnBuLWFwcGxpY2FiaWxpdHktMDEudHh0DQoNCkhpIE5hYmls LA0KDQpJdOKAmXMgYSB2ZXJ5IGNvbXByZWhlbnNpdmUgZG9jLg0KDQpTb21lIGNvbW1vbnM6DQoN CjHjgIEgIEluIHNlY3Rpb24gNi4xLCBpdCBzYWlkOiDigJxBcyB0aGUgbnVtYmVyIG9mIHRlbmFu dHMgaW4gaW5kaXZpZHVhbCBWTEFOIGlzbGFuZHMgc3VycGFzc2VzIDRLLCB0aGUgb3BlcmF0b3Ig Y291bGQgcHVzaCBWUExTIGRlcGxveW1lbnQgZGVlcGVyIGluIHRoZSBEQyBuZXR3b3Jr4oCmLiBU aGUgVG9SIGFuZCBEQyBjb3JlIGVsZW1lbnRzIG5lZWQgdG8gYmUgTVBMUyBlbmFibGVkIHdpdGgg ZXhpc3RpbmcgVlBMUyBzb2x1dGlvbnPigJ0sIElNSE8sIERDIGNvcmUgc3dpdGNoZXMgZG9u4oCZ dCBuZWVkIHRvIGJlIE1QTFMgZW5hYmxlZCBzaW5jZSBJUCBiYXNlZCB0dW5uZWwgaXMgYWxzbyBh dmFpbGFibGUuDQoNCg0KDQpGQj4gWW91IGFyZSByaWdodCB3ZSBzaG91bGQgaGF2ZSBzYWlkIOKA nElQIG9yIE1QTFMgZW5hYmxlZOKAnSBhcyBib3RoIGNhc2VzIGFyZSBwb3NzaWJsZeKApg0KDQoN Cg0KPFhYSD4gR29vZCBwb2ludC4NCg0KDQoNCjLjgIEgIFN0aWxsIGluIHNlY3Rpb24gNi4xLCBp dCBzYWlkOiDigJ0g4oCmSG93ZXZlciwgdGhpcyBtb2RlbCBkb2VzIG5vdCBzb2x2ZSB0aGUgTUFD IGV4cGxvc2lvbiBpc3N1ZSBhcyBUb1JzIHN0aWxsIG5lZWQgdG8gbGVhcm4gVk0gTUFDIGFkZHJl c3Nlcy7igJ0gSG93ZXZlciwgaW4gc2VjdGlvbiA2LjIuMSwgaXQgc2FpZDrigJ3igKZBbHRlcm5h dGl2ZWx5LCB0aGUgUEJCIGVuY2Fwc3VsYXRpb24gY2FuIGJlIGRvbmUgYXQgdGhlIFRvUi7igJ0g IEl0IGlzIGNvbmZ1c2VkIHNpbmNlIHBlcmZvcm1pbmcgUEJCIGVuY2Fwc3VsYXRpb24gYXQgdGhl IFRvUiB3b3VsZCBub3QgYWxsZXZpYXRlIHRoZSBNQUMtbGVhcm5pbmcgYnVyZGVuIG9uIHRoYXQg VG9SLg0KDQoNCg0KRkI+IE1heWJlIHRoZSBwaHJhc2UgbG9jYXRpb24gaXMgcHV6emxpbmcuIFRo ZSBmb2N1cyBvZiBzZWN0aW9uIDYuMiBpcyB0aGUgdXNlIG9mIGFuIGV4dGVuZGVkIDI0YiBQQkIg SS1JU0lEIHRhZyBzdGFydGluZyBhdCB0aGUgVlN3IHRvIGlkZW50aWZ5IHRoZSBFTEFOIGJyb2Fk Y2FzdCBkb21haW4uDQoNCg0KDQo8WFhIPiBUaGUgdGl0bGUgb2Ygc2VjdGlvbiA2LjIuMSBpcyDi gJxBZGRyZXNzaW5nIFZMQU4gc3BhY2UgZXhoYXVzdGlvbiBhbmQgTUFDIGV4cGxvc2lvbuKAnS4g U28gSSB0aGluayBzYXlpbmcgbW9yZSB3b3JkcyBhZnRlciB0aGF0IHNlbnRlbmNlIGlzIG11Y2gg aGVscGZ1bCBpbiBhdm9pZGluZyBjb25mdXNpb24uDQoNCg0KDQoNCg0KVGhpcyB3aWxsIG1heGlt aXplIHRoZSBiZW5lZml0cy4gSG93ZXZlciBpbiByZWFsaXR5IGl0IGlzIHZlcnkgbGlrZWx5IHRo ZXJlIHdpbGwgYmUgbGVnYWN5IERDIHJlZ2lvbnMgc3RpbGwgcnVubmluZyBWTEFOcyB3aGljaCBy ZXF1aXJlIGEgR2F0ZXdheSBmdW5jdGlvbiBkdXJpbmcgdGhlIG1pZ3JhdGlvbi4gU2VlIHRoZSBW TEFOIEludGVyb3AgZGlzY3Vzc2lvbiBpbiBzZWN0aW9uIDYuMi45Lg0KDQoNCg0KM+OAgSAgSW4g Ni4yLjYuMi4gUEJCTiBpbiBWU3csIEwyVlBOIGluIHRoZSBUb1IsIGl0IHNhaWQ64oCdIFRoZSBw cm9jZWR1cmVzIGZyb20gdGhlIHByZXZpb3VzIHNlY3Rpb24gYXJlIHVzZWQgYXQgdGhlIFZTdzog UEJCIGVuY2Fwc3VsYXRpb24gYW5kIEV0aGVybmV0IEJWTEFOcyBjYW4gYmUgdXNlZCBvbiB0aGUg VlN3IHVwbGluay4gTDJWUE4gaW5mcmFzdHJ1Y3R1cmUgaXMgcmVwbGFjaW5nIHRoZSBCVkxBTiBh dCB0aGUgVG9SIGVuYWJsaW5nIHRoZSB1c2Ugb2YgSVAgKEdSRSBvciBMMlRQKSBvciBNUExTIHR1 bm5lbGluZy4NCg0KDQoNCkZCPiBUaGlzIGlzIGFib3V0IHRoZSB0dW5uZWxpbmcgZW5jYXBzdWxh dGlvbiBvcHRpb25zIHRvIGJlIHVzZWQgaW4gdGhlIGNvcmU6IDI0YiBJLVNJRCB0YWcgaXMgdGhl IGNvbW1vbiB0ZW5hbnQgSUQgd2hpY2ggY2FuIGJlIHRyYW5zcG9ydGVkIG92ZXIgYW4gRXRoZXJu ZXQgb3IgYW4gSVAgb3IgYW4gTVBMUyBiYXNlZCBEQyBuZXR3b3JrLiBDb21iaW5hdGlvbnMgb2Yg dGhlc2UgdHVubmVsaW5nIG9wdGlvbnMgYXJlIGFsc28gcG9zc2libGU6IGUuZy4gb25lIERDIG1h eSBiZSBFdGhlcm5ldCBiYXNlZCB0aGUgb3RoZXIgSVAgYmFzZWQ7IG9yIHRoZSBWU3cgbWF5IHVz ZSBFdGhlcm5ldCBWTEFOIHR1bm5lbHMgd2hpbGUgSVAgdHVubmVscyBtYXkgc3RhcnQgYXQgdGhl IFRvUi4NCg0KDQoNCjxYWEg+IFllcywgSSBhZ3JlZSB3aXRoIHlvdXIgc3RhdGVtZW50IGFib3Zl LiBBZGRpbmcgdGhlIGFib3ZlIHRleHQgaW50byB0aGUgZHJhZnQgd291bGQgYmUgbXVjaCBoZWxw ZnVs4pi6DQoNCg0KDQogTDIgbmV0d29ya2luZyBzdGlsbCBoYXMgdGhlIHNhbWUgY29udHJvbCBw bGFuZSBjaG9pY2VzOiBJUy1JUyBbODAyLjFhcV0gYW5kL29yIEJHUCBbUEJCLUVWUE5dLCBpbmRl cGVuZGVudGx5IGZyb20gdGhlIHR1bm5lbGluZyBjaG9pY2Uu4oCdIFNpbmNlIFBCQiBlbmNhcHN1 bGF0aW9uIGhhcyBhbHJlYWR5IGJlZW4gZG9uZSBvbiB0aGUgVlN3LCB3aHkgZG8gd2Ugc3RpbGwg bmVlZCB0byBydW4gODAyLjFhcSBhbmQgUEJCLUVWUE4gd2l0aCBhbm90aGVyIFBCQiBlbmNhcHN1 bGF0aW9uIGxheWVyPw0KDQoNCg0KRkI+IE5vIG5lZWQgZm9yIGFuIGFkZGl0aW9uYWwgUEJCIGVu Y2Fwc3VsYXRpb24gbGF5ZXIhIFRoaXMgaXMgc3RyaWN0bHkgYWJvdXQgY29udHJvbCBwbGFuZSBv cHRpb25zOiBJUy1JUyBhbmQgQkdQIGFyZSB1c2VkIHRoZSBzYW1lIHdheSBhcyBpbiByZWd1bGFy IElQIHJvdXRpbmcgdG8gcGVyZm9ybSBNdWx0aXBhdGhpbmcsIEZhc3QgQ29udmVyZ2VuY2UsIHNl cnZpY2UgQUQsIHByb2dyYW0gdGhlIGNvcmUgRklCcyBldGPigKYNCg0KDQoNCjxYWEg+IEFic29s dXRlbHkgYWdyZWUuIFN1Y2ggYmVpbmcgdGhlIGNhc2UsIHdoeSBub3QgcmVtb3ZlIHRoZSB0d28g c3BlY2lmaWMgZXhhbXBsZXMgKGJvdGggb2YgdGhlbSBhZGQgYW5vdGhlciBQQkIgbGF5ZXIpIGZy b20gdGhhdCBzZW50ZW5jZSBzbyBhcyB0byBlbGltaW5hdGUgdGhlIHBvc3NpYmxlIGNvbmZ1c2lv bj8NCg0KDQoNCiBDYW7igJl0IHdlIHNpbXBseSB1c2UgYW55IEwyVlBOIHRlY2hub2xvZ3ksIGUu Zy4sIFZQTFMuIEluIGFkZGl0aW9uLCBub3RlIHRoYXQgaW4gRmlndXJlIDUsIGl0IHNhaWQg4oCc aW50cmEtREMgTDJWUE4gb3ZlciBJUCBvciBNUExTIHR1bm5lbGluZ+KAnS4NCg0KDQpGQj4geWVz IHlvdSBjYW4uIFdlIGp1c3QgZm9jdXNlZCBoZXJlIG9uIHRoZSBvcHRpb25zIHRoYXQgd2lsbCBh ZGRyZXNzIHRoZSBjaGFsbGVuZ2VzIGRlc2NyaWJlZCBpbiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQg c2VjdGlvbi4gT3RoZXJ3aXNlIHRoZSBjb250ZW50IHdpbGwgaGF2ZSBncm93biB0b28gbXVjaC4N Cg0KPFhYSD4gVGhhbmtzIGZvciB5b3VyIGV4cGxhbmF0aW9uLg0KDQpCZXN0IHJlZ2FyZHMsDQpY aWFvaHUNCg0K5Y+R5Lu25Lq6OiBsMnZwbi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpsMnZwbi1i b3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmwy dnBuLWJvdW5jZXNAaWV0Zi5vcmc+XSDku6PooaggQml0YXIsIE5hYmlsIE4NCuWPkemAgeaXtumX tDogMjAxMeW5tDEx5pyIOOaXpSAxMzo0Mg0K5pS25Lu25Lq6OiBsM3ZwbkBpZXRmLm9yZzxtYWls dG86bDN2cG5AaWV0Zi5vcmc+OyBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+ DQrmioTpgIE6IFNhZ2Vzc2k7IG1pcmNlYS5waXNpY2FAYnQuY29tPG1haWx0bzptaXJjZWEucGlz aWNhQGJ0LmNvbT47IEx1eXVhbiBGYW5nIChsdWZhbmcpOyB5LmlrZWppcmlAbnR0LmNvbTxtYWls dG86eS5pa2VqaXJpQG50dC5jb20+DQrkuLvpopg6IFlvdXIgaW5wdXQgb24gdGhlIGZvbGxvd2lu ZyBkcmFmdCBpcyBhcHByZWNpYXRlZDogZHJhZnQtYml0YXItZGF0YWNlbnRlci12cG4tYXBwbGlj YWJpbGl0eS0wMS50eHQNCg0KSGksDQpXZSBoYWQgc3VibWl0dGVkIHRoZSBmb2xsb3dpbmcgZHJh ZnQgb24gdnBuIGFwcGxpY2FiaWxpdHkgZm9yIGRhdGEgY2VudGVyLiBZb3VyIGlucHV0IG9uIHRo ZSBkcmFmdCBpcyBhcHByZWNpYXRlZCBpbiBsaWdodCBvZiBzb21lIG9mIHRoZSBvbmdvaW5nIGRp c2N1c3Npb24uIFRoZSBkcmFmdCBpcyB0YXJnZXRlZCBmb3IgbDN2cG4gYW5kIGwydnBuLg0KSGVy ZSBpcyB0aGUgbGluazoNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYml0YXIt ZGF0YWNlbnRlci12cG4tYXBwbGljYWJpbGl0eS0wMQ0KDQoNCkFic3RyYWN0DQoNCg0KDQogICBD bG91ZCBDb21wdXRpbmcgaGFzIGJlZW4gYXR0cmFjdGluZyBhIGxvdCBvZiBhdHRlbnRpb24gZnJv bSB0aGUNCg0KICAgbmV0d29ya2luZyBpbmR1c3RyeS4gU29tZSBvZiB0aGUgbW9zdCBwdWJsaWNp emVkIHJlcXVpcmVtZW50cyBhcmUNCg0KICAgcmVsYXRlZCB0byB0aGUgZXZvbHV0aW9uIG9mIHRo ZSBDbG91ZCBOZXR3b3JraW5nIEluZnJhc3RydWN0dXJlIHRvDQoNCiAgIGFjY29tbW9kYXRlIGEg bGFyZ2UgbnVtYmVyIG9mIHRlbmFudHMsIGVmZmljaWVudCBuZXR3b3JrIHV0aWxpemF0aW9uLA0K DQogICBzY2FsYWJsZSBsb29wIGF2b2lkYW5jZSwgYW5kIFZpcnR1YWwgTWFjaGluZSBNb2JpbGl0 eS4NCg0KDQoNCiAgIFRoaXMgZHJhZnQgZGVzY3JpYmVzIGEgZnJhbWV3b3JrIGZvciBjbG91ZCBu ZXR3b3JraW5nLCBoaWdobGlnaHRpbmcNCg0KICAgdGhlIGFwcGxpY2FiaWxpdHkgb2YgZXhpc3Rp bmcgd29yayBpbiB2YXJpb3VzIElFVEYgV29ya2luZyBHcm91cHMNCg0KICAgKGUuZy4sIFJGQ3Mg YW5kIGRyYWZ0cyBkZXZlbG9wZWQgaW4gSUVURiBMMlZQTiBhbmQgTDNWUE4gV29ya2luZw0KDQog ICBHcm91cHMpIHRvIGNsb3VkIG5ldHdvcmtpbmcsIGFuZCB0aGUgZ2FwcyBhbmQgcHJvYmxlbXMg dGhhdCBuZWVkIHRvDQoNCiAgIGJlIGZ1cnRoZXIgYWRkcmVzc2VkLiBUaGF0IGlzLCB0aGUgZ29h bCBpcyB0byB1bmRlcnN0YW5kIHdoYXQgbWF5IGJlDQoNCiAgIHJlLXVzZWQgZnJvbSB0aGUgY3Vy cmVudCBwcm90b2NvbHMgYW5kIGNhbGwgb3V0IHJlcXVpcmVtZW50cyBzcGVjaWZpYw0KDQogICB0 byB0aGUgQ2xvdWQgc3BhY2UgdGhhdCBuZWVkIHRvIGJlIGFkZHJlc3NlZCBieSBuZXcgc3RhbmRh cmRpemF0aW9uDQoNCiAgIHdvcmsgd2l0aCBwcm9wb3NlZCBzb2x1dGlvbnMgaW4gY2VydGFpbiBj YXNlcy4NCg0KDQpUaGFua3MsDQoNCk5hYmlsDQoNCg== --Boundary_(ID_Sn0TYnmoj1gFVIWr3jV68g) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30N CnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE 6K6+5qC85byPIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnNwYW4uSFRNTENoYXIN Cgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8iOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tcmlnaHQ6MzYuMHB0O21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjojMUY0OTdEIj5JIGFncmVlIHRoYXQgUEJCIGNvdWxkIHNjYWxlIHZlcnkgd2Vs bCBpZiBpdCBpcyBwZXJmb3JtZWQgYXQgcHJvcGVyIGxvY2F0aW9ucyB3aGVyZSB0aGUgTUFDIHRh YmxlIGlzIOKAnGxhcmdlIGVub3VnaOKAnS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tcmln aHQ6MzYuMHB0O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2FyZHMsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21hcmdpbi1yaWdodDozNi4wcHQ7bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9y OiMxRjQ5N0QiPlhpYW9odTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNt IDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPuWPkeS7tuS6ujxz cGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gUGF1bCBVbmJlaGFnZW4gW21haWx0bzpwYXVsQHVuYmVo YWdlbi5uZXRdDQo8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gMjAxMTwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5bm0PHNwYW4gbGFuZz0iRU4tVVMiPjExPC9zcGFuPuac iDxzcGFuIGxhbmc9IkVOLVVTIj45PC9zcGFuPuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4gMTE6MjQ8 YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIj4gVmlzaHdhcyBNYW5yYWw8YnI+DQo8L3NwYW4+PGI+5oqE6YCBPHNw YW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gWHV4aWFvaHU7 IGwydnBuQGlldGYub3JnOyBTYWdlc3NpOyBsM3ZwbkBpZXRmLm9yZzsgbWlyY2VhLnBpc2ljYUBi dC5jb207IEx1eXVhbiBGYW5nIChsdWZhbmcpOyB5LmlrZWppcmlAbnR0LmNvbTxicj4NCjwvc3Bh bj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiPiBSZTogWW91ciBpbnB1dCBvbiB0aGUgZm9sbG93aW5nIGRyYWZ0IGlzIGFwcHJlY2lhdGVk OiBkcmFmdC1iaXRhci1kYXRhY2VudGVyLXZwbi1hcHBsaWNhYmlsaXR5LTAxLnR4dDxvOnA+PC9v OnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFu IGxhbmc9IkVOLVVTIj5KdXN0IHRvIGJlIGNsZWFyIHdydCBQQkIsIHRoZSBNQUMgdGFibGVzIG9u bHkgbmVlZCB0byBiZSBsYXJnZSBlbm91Z2ggdG8gbGVhcm4gdGhlIE1hYydzIG9mIHRoZSBlbmQg c3lzdGVtcyBpbiB0aGUgc2FtZSBJU0lEIHRoYXQgZXhpc3Qgb24gdGhhdCBlZGdlIHN3aXRjaCwg bm90IGFsbCBNQUMncyBpbiB0aGUgbmV0d29yay4gVGhpcw0KIGlzIHdoYXQgbWFrZXMgUEJCIHNj YWxlIHNvIHdlbGwgaW4gdGhlc2UgdHlwZXMgb2YgZW52aXJvbm1lbnRzLiZuYnNwOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPi0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlBhdWwgVW5iZWhhZ2VuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5TZW50IGZyb20gbXkgaVBhZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQpPbiBOb3YgOSwgMjAxMSwgYXQgMjow MyBQTSwgVmlzaHdhcyBNYW5yYWwgJmx0OzxhIGhyZWY9Im1haWx0bzp2aXNod2FzLmlldGZAZ21h aWwuY29tIj52aXNod2FzLmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPlhpYW9odSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkZvciB0aGUgcHVycG9zZSBvZiByZWR1Y2luZyB1bmtvd24gdW5p Y2FzdC8gbXVsdGljYXN0IHlvdSBjb3VsZCB1c2Ugc29tZSBvZmYgcGF0aCBsZWFybmluZyBhbmQg dGhlbiBkaXNjYXJkIHRoZSB1bmtub3ducy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+T2Zjb3Vyc2UgdGhlIE1BQyB0YWJsZXMgaW4gZWRnZSBkZXZp Y2UgbmVlZCB0byBiaWcgZW5vdWdoIHRvIGxlYXJuIHRoZSBNQUMgYWRkcmVzc2VzIG9mIGFsbCB0 aGUgZW5kIHN5c3RlbXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlZpc2h3YXM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+MjAxMS8xMS84IFh1eGlhb2h1ICZsdDs8YSBocmVmPSJtYWlsdG86eHV4aWFvaHVA aHVhd2VpLmNvbSI+eHV4aWFvaHVAaHVhd2VpLmNvbTwvYT4mZ3Q7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj5CeSB0aGUgd2F5LCBp dCB3b3VsZCBiZSBiZXR0ZXIgdG8gcHVzaCB0aGUgUEJCIGFzIGNsb3NlIHRvIHRoZSBlbmQtc3lz dGVtcyBhcyBwb3NzaWJsZSBmcm9tIHRoZSBwZXJzcGVjdGl2ZSBvZiBNQUMgZm9yd2FyZGluZw0K IHRhYmxlIHNjYWxhYmlsaXR5LiBIb3dldmVyLCB0aGUgdW5rbm93biB1bmljYXN0IGZsb29kIGlt cGFjdCBpc3N1ZSB3b3VsZCBiZSB3b3JzZW4gYWNjb3JkaW5nbHkuIEZvciBleGFtcGxlLCBpbiBh IG5vcm1hbCBMYXllcjIgbmV0d29yaywgaWYgdHdvIFZNcyBhdHRhY2hlZCB0byB0aGUgZ2l2ZW4g VG9SIGFyZSBmcmVxdWVudGx5IGNvbW11bmljYXRlZCB3aXRoIGVhY2ggb3RoZXIgYW5kIGhlbmNl IHRoZWlyIE1BQyBhZGRyZXNzIGVudHJpZXMgb24NCiB0aGlzIFRvUiB3aWxsIG5vdCBiZSBleHBp cmVkLCB0aGUgdHJhZmZpYyBkZXN0aW5lZCBmb3IgYW55IG9mIHRob3NlIHR3byBWTXMgZnJvbSBh IHJlbW90ZSBWTSBjb3VsZCBiZSBmbG9vZGVkIGFzIHVua25vd24gdW5pY2FzdCB1bnRpbCB0aGUg dHJhZmZpYyByZWFjaCB0aGlzIFRvUiB3aGljaCBpbiB0dXJuIGZvcndhcmQgdGhlIHRyYWZmaWMg dG8gdGhlIGRlc3RpbmF0aW9uIFZNIGluIHVuaWNhc3QuICZuYnNwO0hvd2V2ZXIsIG9uY2UgUEJC IGlzIHBlcmZvcm1lZA0KIGF0IGVhY2ggVlN3LCB0aGF0IHRyYWZmaWMgd291bGQgYmUgZmxvb2Rl ZCB1bnRpbCBpdCByZWFjaCB0aGUgZmluYWwgZGVzdGluYXRpb24gcGh5c2ljYWwgc2VydmVyLiZu YnNwOyBJdOKAmXMgYSBoYXJkIHRyYWRlb2ZmLCBpc27igJl0IGl0Pzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtjb2xvcjojMUY0OTdEIj5YaWFvaHU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPuWPkeS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gWHV4aWFvaHUN Cjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R6YCB5pe2 6Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiAyMDExPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0Ij7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+MTE8L3NwYW4+5pyIPHNwYW4gbGFu Zz0iRU4tVVMiPjk8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPiAxMDowODxicj4NCjwvc3Bh bj48Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiPiAnQmFsdXMsIEZsb3JpbiBTdGVsaWFuIChGbG9yaW4pJzsgQml0YXIsIE5hYmlsIE47 DQo8YSBocmVmPSJtYWlsdG86bDN2cG5AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5sM3ZwbkBp ZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpsMnZwbkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPg0KbDJ2cG5AaWV0Zi5vcmc8L2E+PGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9 IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IEx1eXVhbiBGYW5nIChsdWZh bmcpOyBTYWdlc3NpOw0KPGEgaHJlZj0ibWFpbHRvOnkuaWtlamlyaUBudHQuY29tIiB0YXJnZXQ9 Il9ibGFuayI+eS5pa2VqaXJpQG50dC5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86bWlyY2VhLnBp c2ljYUBidC5jb20iIHRhcmdldD0iX2JsYW5rIj4NCm1pcmNlYS5waXNpY2FAYnQuY29tPC9hPjxi cj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiPiByZTogWW91ciBpbnB1dCBvbiB0aGUgZm9sbG93aW5nIGRyYWZ0IGlzIGFw cHJlY2lhdGVkOiBkcmFmdC1iaXRhci1kYXRhY2VudGVyLXZwbi1hcHBsaWNhYmlsaXR5LTAxLnR4 dDwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R5Lu25Lq6PHNwYW4gbGFu Zz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPiBCYWx1cywgRmxvcmluIFN0ZWxpYW4gKEZsb3JpbikgW21haWx0bzo8 YSBocmVmPSJtYWlsdG86ZmxvcmluLmJhbHVzQGFsY2F0ZWwtbHVjZW50LmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmZsb3Jpbi5iYWx1c0BhbGNhdGVsLWx1Y2VudC5jb208L2E+XQ0KPGJyPg0KPC9zcGFu PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lj5HpgIHml7bpl7Q8c3BhbiBsYW5n PSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdCI+IDIwMTE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPuW5tDxzcGFuIGxhbmc9IkVOLVVTIj4xMTwvc3Bhbj7mnIg8c3BhbiBs YW5nPSJFTi1VUyI+OTwvc3Bhbj7ml6U8c3BhbiBsYW5nPSJFTi1VUyI+IDU6MzQ8YnI+DQo8L3Nw YW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIj4gWHV4aWFvaHU7IEJpdGFyLCBOYWJpbCBOOw0KPGEgaHJlZj0ibWFpbHRvOmwzdnBu QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bDN2cG5AaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJt YWlsdG86bDJ2cG5AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmwydnBuQGlldGYub3JnPC9h Pjxicj4NCjwvc3Bhbj48Yj7mioTpgIE8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNw YW4gbGFuZz0iRU4tVVMiPiBMdXl1YW4gRmFuZyAobHVmYW5nKTsgU2FnZXNzaTsNCjxhIGhyZWY9 Im1haWx0bzp5LmlrZWppcmlAbnR0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnkuaWtlamlyaUBudHQu Y29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm1pcmNlYS5waXNpY2FAYnQuY29tIiB0YXJnZXQ9Il9i bGFuayI+DQptaXJjZWEucGlzaWNhQGJ0LmNvbTwvYT48YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNw YW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUkU6IFlvdXIg aW5wdXQgb24gdGhlIGZvbGxvd2luZyBkcmFmdCBpcyBhcHByZWNpYXRlZDogZHJhZnQtYml0YXIt ZGF0YWNlbnRlci12cG4tYXBwbGljYWJpbGl0eS0wMS50eHQ8L3NwYW4+PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB0aGUg Y29tbWVudHMsIHNlZSBpbi1saW5l4oCmPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQiPg0KPGEgaHJlZj0ibWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5sMnZwbi1ib3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhy ZWY9Im1haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bDJ2cG4t Ym91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlh1eGlhb2h1PGJyPg0K PGI+U2VudDo8L2I+IE1vbmRheSwgTm92ZW1iZXIgMDcsIDIwMTEgMTE6NTMgUE08YnI+DQo8Yj5U bzo8L2I+IEJpdGFyLCBOYWJpbCBOOyA8YSBocmVmPSJtYWlsdG86bDN2cG5AaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5sM3ZwbkBpZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86bDJ2cG5A aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5sMnZwbkBpZXRmLm9yZzwvYT48YnI+DQo8Yj5DYzo8 L2I+IEx1eXVhbiBGYW5nIChsdWZhbmcpOyBTYWdlc3NpOyA8YSBocmVmPSJtYWlsdG86eS5pa2Vq aXJpQG50dC5jb20iIHRhcmdldD0iX2JsYW5rIj4NCnkuaWtlamlyaUBudHQuY29tPC9hPjsgPGEg aHJlZj0ibWFpbHRvOm1pcmNlYS5waXNpY2FAYnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWlyY2Vh LnBpc2ljYUBidC5jb208L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IHJlOiBZb3VyIGlucHV0IG9u IHRoZSBmb2xsb3dpbmcgZHJhZnQgaXMgYXBwcmVjaWF0ZWQ6IGRyYWZ0LWJpdGFyLWRhdGFjZW50 ZXItdnBuLWFwcGxpY2FiaWxpdHktMDEudHh0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6IzFGNDk3RCI+SGkgTmFiaWwsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9y OiMxRjQ5N0QiPkl04oCZcyBhIHZlcnkgY29tcHJlaGVuc2l2ZSBkb2MuPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPlNvbWUgY29tbW9uczo8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4 LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMx RjQ5N0QiPjE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3 RCI+44CBPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj4mbmJzcDsgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj5JbiBzZWN0aW9uIDYuMSwgaXQgc2FpZDogPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPuKAnDxzcGFu IGxhbmc9IkVOLVVTIj5BcyB0aGUgbnVtYmVyIG9mIHRlbmFudHMgaW4gaW5kaXZpZHVhbCBWTEFO IGlzbGFuZHMgc3VycGFzc2VzIDRLLCB0aGUgb3BlcmF0b3IgY291bGQgcHVzaCBWUExTIGRlcGxv eW1lbnQgZGVlcGVyIGluIHRoZSBEQyBuZXR3b3JrPC9zcGFuPuKApjxzcGFuIGxhbmc9IkVOLVVT Ij4uIFRoZSBUb1IgYW5kIERDIGNvcmUgZWxlbWVudHMgbmVlZCB0byBiZSBNUExTIGVuYWJsZWQg d2l0aCBleGlzdGluZyBWUExTIHNvbHV0aW9uczwvc3Bhbj7igJ08c3BhbiBsYW5nPSJFTi1VUyI+ LCBJTUhPLCBEQyBjb3JlIHN3aXRjaGVzIGRvbjwvc3Bhbj7igJk8c3BhbiBsYW5nPSJFTi1VUyI+ dCBuZWVkIHRvIGJlIE1QTFMgZW5hYmxlZCBzaW5jZSBJUCBiYXNlZCB0dW5uZWwgaXMgYWxzbyBh dmFpbGFibGUuPC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Y29sb3I6YmxhY2siPkZCJmd0OyBZb3UgYXJlIHJpZ2h0IHdlIHNob3VsZCBoYXZl IHNhaWQgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj7i gJw8c3BhbiBsYW5nPSJFTi1VUyI+SVAgb3IgTVBMUyBlbmFibGVkPC9zcGFuPuKAnTxzcGFuIGxh bmc9IkVOLVVTIj4gYXMgYm90aCBjYXNlcyBhcmUgcG9zc2libGU8L3NwYW4+4oCmIDwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjoj MUY0OTdEIj4mbHQ7WFhIJmd0OyBHb29kIHBvaW50Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8ZGl2Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdp bi1sZWZ0OjE4LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2NvbG9yOiMxRjQ5N0QiPjI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29s b3I6IzFGNDk3RCI+44CBPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsgPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj5TdGlsbCBpbiBzZWN0aW9uIDYu MSwgaXQgc2FpZDogPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMx RjQ5N0QiPuKAnSDigKY8c3BhbiBsYW5nPSJFTi1VUyI+SG93ZXZlciwgdGhpcyBtb2RlbCBkb2Vz IG5vdCBzb2x2ZSB0aGUgTUFDIGV4cGxvc2lvbiBpc3N1ZSBhcyBUb1JzIHN0aWxsIG5lZWQgdG8g bGVhcm4gVk0gTUFDIGFkZHJlc3Nlcy48L3NwYW4+4oCdPHNwYW4gbGFuZz0iRU4tVVMiPiBIb3dl dmVyLCBpbiBzZWN0aW9uIDYuMi4xLCBpdCBzYWlkOjwvc3Bhbj7igJ3igKY8c3BhbiBsYW5nPSJF Ti1VUyI+QWx0ZXJuYXRpdmVseSwgdGhlIFBCQiBlbmNhcHN1bGF0aW9uIGNhbiBiZSBkb25lIGF0 IHRoZSBUb1IuPC9zcGFuPuKAnTxzcGFuIGxhbmc9IkVOLVVTIj4gJm5ic3A7SXQgaXMgY29uZnVz ZWQgc2luY2UgcGVyZm9ybWluZyBQQkIgZW5jYXBzdWxhdGlvbiBhdCB0aGUgVG9SIHdvdWxkIG5v dCBhbGxldmlhdGUgdGhlIE1BQy1sZWFybmluZyBidXJkZW4gb24gdGhhdCBUb1IuPC9zcGFuPjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6Ymxh Y2siPkZCJmd0OyBNYXliZSB0aGUgcGhyYXNlIGxvY2F0aW9uIGlzIHB1enpsaW5nLiBUaGUgZm9j dXMgb2Ygc2VjdGlvbiA2LjIgaXMgdGhlIHVzZSBvZiBhbiBleHRlbmRlZCAyNGIgUEJCIEktSVNJ RCB0YWcgc3RhcnRpbmcgYXQgdGhlIFZTdyB0byBpZGVudGlmeSB0aGUgRUxBTiBicm9hZGNhc3Qg ZG9tYWluLiA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjwvZGl2Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+Jmx0O1hYSCZndDsgVGhlIHRpdGxlIG9mIHNlY3Rpb24g Ni4yLjEgaXMgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5 N0QiPuKAnDxzcGFuIGxhbmc9IkVOLVVTIj5BZGRyZXNzaW5nIFZMQU4gc3BhY2UgZXhoYXVzdGlv biBhbmQgTUFDIGV4cGxvc2lvbjwvc3Bhbj7igJ08c3BhbiBsYW5nPSJFTi1VUyI+LiBTbyBJIHRo aW5rIHNheWluZyBtb3JlIHdvcmRzIGFmdGVyIHRoYXQgc2VudGVuY2UgaXMgbXVjaCBoZWxwZnVs IGluIGF2b2lkaW5nIGNvbmZ1c2lvbi48L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPlRoaXMgd2lsbCBtYXhp bWl6ZSB0aGUgYmVuZWZpdHMuIEhvd2V2ZXIgaW4gcmVhbGl0eSBpdCBpcyB2ZXJ5IGxpa2VseSB0 aGVyZSB3aWxsIGJlIGxlZ2FjeSBEQyByZWdpb25zIHN0aWxsIHJ1bm5pbmcgVkxBTnMgd2hpY2gg cmVxdWlyZSBhIEdhdGV3YXkgZnVuY3Rpb24gZHVyaW5nIHRoZSBtaWdyYXRpb24uIFNlZSB0aGUg VkxBTiBJbnRlcm9wIGRpc2N1c3Npb24gaW4gc2VjdGlvbiA2LjIuOS4gPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxkaXY+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDoxOC4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0Ij48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+Mzwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj7jgIE8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2NvbG9yOiMxRjQ5N0QiPkluIDxhIG5hbWU9IjEzMzg2M2M5ZjNkZDdjODFfc2VjdGlvbi02 LjIuNi4yIj42LjIuNi4yPC9hPi4gUEJCTiBpbiBWU3csIEwyVlBOIGluIHRoZSBUb1IsIGl0IHNh aWQ6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPuKA nTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+VGhlIHByb2NlZHVyZXMgZnJvbSB0aGUgcHJldmlv dXMgc2VjdGlvbiBhcmUgdXNlZCBhdCB0aGUgVlN3OiBQQkIgZW5jYXBzdWxhdGlvbiBhbmQgRXRo ZXJuZXQgQlZMQU5zIGNhbiBiZSB1c2VkIG9uIHRoZSBWU3cgdXBsaW5rLiBMMlZQTiBpbmZyYXN0 cnVjdHVyZSBpcyByZXBsYWNpbmcgdGhlIEJWTEFOIGF0IHRoZSBUb1IgZW5hYmxpbmcgdGhlIHVz ZSBvZiBJUCAoR1JFIG9yIEwyVFApIG9yIE1QTFMgdHVubmVsaW5nLiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6YmxhY2siPkZCJmd0 OyBUaGlzIGlzIGFib3V0IHRoZSB0dW5uZWxpbmcgZW5jYXBzdWxhdGlvbiBvcHRpb25zIHRvIGJl IHVzZWQgaW4gdGhlIGNvcmU6IDI0YiBJLVNJRCB0YWcgaXMgdGhlIGNvbW1vbiB0ZW5hbnQgSUQg d2hpY2ggY2FuIGJlIHRyYW5zcG9ydGVkIG92ZXIgYW4gRXRoZXJuZXQgb3IgYW4gSVAgb3IgYW4g TVBMUyBiYXNlZCBEQyBuZXR3b3JrLiBDb21iaW5hdGlvbnMgb2YgdGhlc2UgdHVubmVsaW5nIG9w dGlvbnMgYXJlIGFsc28gcG9zc2libGU6IGUuZy4gb25lIERDIG1heSBiZSBFdGhlcm5ldCBiYXNl ZCB0aGUgb3RoZXIgSVAgYmFzZWQ7IG9yIHRoZSBWU3cgbWF5IHVzZSBFdGhlcm5ldCBWTEFOIHR1 bm5lbHMgd2hpbGUgSVAgdHVubmVscyBtYXkgc3RhcnQgYXQgdGhlIFRvUi48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPHBy ZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3 RCI+Jmx0O1hYSCZndDsgWWVzLCBJIGFncmVlIHdpdGggeW91ciBzdGF0ZW1lbnQgYWJvdmUuIEFk ZGluZyB0aGUgYWJvdmUgdGV4dCBpbnRvIHRoZSBkcmFmdCB3b3VsZCBiZSBtdWNoIGhlbHBmdWw8 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj5KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDox OC4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjoj MUY0OTdEIj4gTDIgbmV0d29ya2luZyBzdGlsbCBoYXMgdGhlIHNhbWUgY29udHJvbCBwbGFuZSBj aG9pY2VzOiBJUy1JUyBbODAyLjFhcV0gYW5kL29yIEJHUCBbUEJCLUVWUE5dLCBpbmRlcGVuZGVu dGx5IGZyb20gdGhlIHR1bm5lbGluZyBjaG9pY2UuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPuKAnTxzcGFuIGxhbmc9IkVOLVVTIj4gU2luY2UgUEJC IGVuY2Fwc3VsYXRpb24gaGFzIGFscmVhZHkgYmVlbiBkb25lIG9uIHRoZSBWU3csIHdoeSBkbyB3 ZSBzdGlsbCBuZWVkIHRvIHJ1biA4MDIuMWFxIGFuZCBQQkItRVZQTiB3aXRoIGFub3RoZXIgUEJC IGVuY2Fwc3VsYXRpb24gbGF5ZXI/PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8ZGl2Pg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5GQiZndDsgTm8gbmVlZCBm b3IgYW4gYWRkaXRpb25hbCBQQkIgZW5jYXBzdWxhdGlvbiBsYXllciEgVGhpcyBpcyBzdHJpY3Rs eSBhYm91dCBjb250cm9sIHBsYW5lIG9wdGlvbnM6IElTLUlTIGFuZCBCR1AgYXJlIHVzZWQgdGhl IHNhbWUgd2F5IGFzIGluIHJlZ3VsYXIgSVAgcm91dGluZyB0byBwZXJmb3JtIE11bHRpcGF0aGlu ZywgRmFzdCBDb252ZXJnZW5jZSwgc2VydmljZSBBRCwgcHJvZ3JhbSB0aGUgY29yZSBGSUJzIGV0 Yzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjpibGFjayI+4oCmPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 L2Rpdj4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Nv bG9yOiMxRjQ5N0QiPiZsdDtYWEgmZ3Q7IEFic29sdXRlbHkgYWdyZWUuIFN1Y2ggYmVpbmcgdGhl IGNhc2UsIHdoeSBub3QgcmVtb3ZlIHRoZSB0d28gc3BlY2lmaWMgZXhhbXBsZXMgKGJvdGggb2Yg dGhlbSBhZGQgYW5vdGhlciBQQkIgbGF5ZXIpIGZyb20gdGhhdCBzZW50ZW5jZSBzbyBhcyB0byBl bGltaW5hdGUgdGhlIHBvc3NpYmxlIGNvbmZ1c2lvbj88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MTguMHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPiBDYW48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+4oCZPHNwYW4gbGFuZz0iRU4tVVMi PnQgd2Ugc2ltcGx5IHVzZSBhbnkgTDJWUE4gdGVjaG5vbG9neSwgZS5nLiwgVlBMUy4gSW4gYWRk aXRpb24sIG5vdGUgdGhhdCBpbiBGaWd1cmUgNSwgaXQgc2FpZCA8L3NwYW4+4oCcPHNwYW4gbGFu Zz0iRU4tVVMiPmludHJhLURDIEwyVlBOIG92ZXIgSVAgb3IgTVBMUyB0dW5uZWxpbmc8L3NwYW4+ 4oCdPHNwYW4gbGFuZz0iRU4tVVMiPi48L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuMjVwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2NvbG9yOmJsYWNrIj5GQiZndDsgeWVzIHlvdSBjYW4uIFdlIGp1c3Qg Zm9jdXNlZCBoZXJlIG9uIHRoZSBvcHRpb25zIHRoYXQgd2lsbCBhZGRyZXNzIHRoZSBjaGFsbGVu Z2VzIGRlc2NyaWJlZCBpbiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgc2VjdGlvbi4gT3RoZXJ3aXNl IHRoZSBjb250ZW50IHdpbGwgaGF2ZSBncm93biB0b28gbXVjaC48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2NvbG9yOiMxRjQ5N0QiPiZsdDtYWEgmZ3Q7IFRoYW5rcyBmb3IgeW91 ciBleHBsYW5hdGlvbi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6IzFGNDk3RCI+QmVz dCByZWdhcmRzLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjojMUY0OTdEIj5YaWFvaHU8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+DQo8YSBocmVmPSJtYWls dG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmwydnBuLWJvdW5jZXNA aWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5sMnZwbi1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjwvc3Bhbj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Luj6KGoIDwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5CaXRhciwgTmFiaWwgTjxicj4N Cjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R6YCB5pe26Ze0PHNw YW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiAyMDExPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+MTE8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4t VVMiPjg8L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPiAxMzo0Mjxicj4NCjwvc3Bhbj48Yj7m lLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMi PiA8YSBocmVmPSJtYWlsdG86bDN2cG5AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmwzdnBu QGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmwydnBuQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+bDJ2cG5AaWV0Zi5vcmc8L2E+PGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9 IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFNhZ2Vzc2k7IDxhIGhyZWY9 Im1haWx0bzptaXJjZWEucGlzaWNhQGJ0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPg0KbWlyY2VhLnBp c2ljYUBidC5jb208L2E+OyBMdXl1YW4gRmFuZyAobHVmYW5nKTsgPGEgaHJlZj0ibWFpbHRvOnku aWtlamlyaUBudHQuY29tIiB0YXJnZXQ9Il9ibGFuayI+DQp5LmlrZWppcmlAbnR0LmNvbTwvYT48 YnI+DQo8L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIj4gWW91ciBpbnB1dCBvbiB0aGUgZm9sbG93aW5nIGRyYWZ0IGlzIGFwcHJl Y2lhdGVkOiBkcmFmdC1iaXRhci1kYXRhY2VudGVyLXZwbi1hcHBsaWNhYmlsaXR5LTAxLnR4dDwv c3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2si PkhpLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPldlIGhhZCBzdWJtaXR0ZWQgdGhlIGZv bGxvd2luZyBkcmFmdCBvbiB2cG4gYXBwbGljYWJpbGl0eSBmb3IgZGF0YSBjZW50ZXIuIFlvdXIg aW5wdXQgb24gdGhlIGRyYWZ0IGlzIGFwcHJlY2lhdGVkIGluIGxpZ2h0DQogb2Ygc29tZSBvZiB0 aGUgb25nb2luZyBkaXNjdXNzaW9uLiBUaGUgZHJhZnQgaXMgdGFyZ2V0ZWQgZm9yIGwzdnBuIGFu ZCBsMnZwbi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5IZXJlIGlzIHRoZSBsaW5rOiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Y29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJp dGFyLWRhdGFjZW50ZXItdnBuLWFwcGxpY2FiaWxpdHktMDEiIHRhcmdldD0iX2JsYW5rIj5odHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaXRhci1kYXRhY2VudGVyLXZwbi1hcHBsaWNh YmlsaXR5LTAxPC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5BYnN0cmFjdDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBDbG91ZCBDb21wdXRpbmcgaGFzIGJlZW4gYXR0 cmFjdGluZyBhIGxvdCBvZiBhdHRlbnRpb24gZnJvbSB0aGU8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsgbmV0d29ya2luZyBpbmR1c3RyeS4gU29tZSBvZiB0aGUgbW9zdCBwdWJsaWNpemVk IHJlcXVpcmVtZW50cyBhcmU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgcmVsYXRlZCB0 byB0aGUgZXZvbHV0aW9uIG9mIHRoZSBDbG91ZCBOZXR3b3JraW5nIEluZnJhc3RydWN0dXJlIHRv PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGFjY29tbW9kYXRlIGEgbGFyZ2UgbnVtYmVy IG9mIHRlbmFudHMsIGVmZmljaWVudCBuZXR3b3JrIHV0aWxpemF0aW9uLDwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPiZuYnNwOyZuYnNwOyBzY2FsYWJsZSBsb29wIGF2b2lkYW5jZSwgYW5kIFZpcnR1YWwgTWFj aGluZSBNb2JpbGl0eS48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgVGhpcyBkcmFmdCBkZXNjcmliZXMgYSBmcmFtZXdvcmsgZm9yIGNsb3VkIG5l dHdvcmtpbmcsIGhpZ2hsaWdodGluZzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyB0aGUg YXBwbGljYWJpbGl0eSBvZiBleGlzdGluZyB3b3JrIGluIHZhcmlvdXMgSUVURiBXb3JraW5nIEdy b3Vwczwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyAoZS5nLiwgUkZDcyBhbmQgZHJhZnRz IGRldmVsb3BlZCBpbiBJRVRGIEwyVlBOIGFuZCBMM1ZQTiBXb3JraW5nPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IEdyb3VwcykgdG8gY2xvdWQgbmV0d29ya2luZywgYW5kIHRoZSBnYXBz IGFuZCBwcm9ibGVtcyB0aGF0IG5lZWQgdG88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsg YmUgZnVydGhlciBhZGRyZXNzZWQuIFRoYXQgaXMsIHRoZSBnb2FsIGlzIHRvIHVuZGVyc3RhbmQg d2hhdCBtYXkgYmU8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgcmUtdXNlZCBmcm9tIHRo ZSBjdXJyZW50IHByb3RvY29scyBhbmQgY2FsbCBvdXQgcmVxdWlyZW1lbnRzIHNwZWNpZmljPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IHRvIHRoZSBDbG91ZCBzcGFjZSB0aGF0IG5lZWQg dG8gYmUgYWRkcmVzc2VkIGJ5IG5ldyBzdGFuZGFyZGl6YXRpb248L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsgd29yayB3aXRoIHByb3Bvc2VkIHNvbHV0aW9ucyBpbiBjZXJ0YWluIGNhc2Vz Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxiciBj bGVhcj0iYWxsIj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGFua3MsPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+TmFi aWw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --Boundary_(ID_Sn0TYnmoj1gFVIWr3jV68g)-- From david.i.allan@ericsson.com Wed Nov 9 07:32:07 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D405E21F8B06; Wed, 9 Nov 2011 07:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[AWL=-2.402, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmgPv+fV0wPw; Wed, 9 Nov 2011 07:32:03 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 8735821F8469; Wed, 9 Nov 2011 07:32:03 -0800 (PST) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pA9FVJ95005875; Wed, 9 Nov 2011 09:31:21 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.174]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 9 Nov 2011 10:31:15 -0500 From: David Allan I To: Xuxiaohu , "Balus, Florin Stelian (Florin)" , "Bitar, Nabil N" , "l3vpn@ietf.org" , "l2vpn@ietf.org" Date: Wed, 9 Nov 2011 10:31:15 -0500 Subject: RE: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-Topic: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-Index: Acyd2R8rhSQNYlfHQ16DQ3Td7RyeUQAC+SpwABxhHfAACrvcUAAB0LLwAARv2GA= Message-ID: <60C093A41B5E45409A19D42CF7786DFD52261A095C@EUSAACMS0703.eamcs.ericsson.se> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74774D@szxeml525-mbs.china.huawei.com> <2073A6C5467C99478898544C6EBA3F4602BD5D2CF4@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE747C3A@szxeml525-mbs.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE747C3A@szxeml525-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_60C093A41B5E45409A19D42CF7786DFD52261A095CEUSAACMS0703e_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 09 Nov 2011 07:36:36 -0800 Cc: Sagessi , "Luyuan Fang \(lufang\)" , "y.ikejiri@ntt.com" , "mircea.pisica@bt.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 15:32:08 -0000 --_000_60C093A41B5E45409A19D42CF7786DFD52261A095CEUSAACMS0703e_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgWHV4YW9odToNCg0KSSB3b3VsZCBvYmplY3QgdG8geW91ciBzdWdnZXN0aW9uIG9mICJhcyBj bG9zZSB0byB0aGUgZW5kLXN5c3RlbXMgYXMgcG9zc2libGUiLiBQQkIgaXMgaGllcmFyY2hpY2Fs IHN1bW1hcml6YXRpb24sIHNvIHRoZSBudW1iZXIgb2YgQy1NQUNzIHN1bW1hcml6ZWQgZm9yIHJl YWNoYWJpbGl0eSB0byBCLU1BQ3MgaXMgYSBmdW5jdGlvbiBvZiBob3cgY2xvc2UgdGhlIEJFQiBp cyBwbGFjZWQgdG8gdGhlIGVuZCBzeXN0ZW0uIElmIGl0IGlzICJjby1sb2NhdGVkIiB3aXRoIHRo ZSBlbmQgc3lzdGVtIChhLmsuYSBhcyBjbG9zZSBhcyBwb3NzaWJsZSkgdGhlcmUgaXMgbm8gc3Vt bWFyaXphdGlvbi4gMSAgQi1NQUMgY29ycmVzcG9uZHMgdG8gMSBDLU1BQyBhbmQgdGhlIGVuY2Fw c3VsYXRpb24gYXQgdGhhdCBwb2ludCBpcyBzaW1wbHkgYSBncmF0dWl0b3VzIGluY3JlYXNlIGlu IGJhbmR3aWR0aCBjb25zdW1wdGlvbi4gV2hpY2ggdGVuZHMgdG8gc3VnZ2VzdCB0aGVyZSBpcyBh IG5hdHVyYWwgbG9jYXRpb24gZm9yIHBsYWNlbWVudCBvZiB0aGUgQkVCIGZ1bmN0aW9uIHdoaWNo IHBlcm1pdHMgc29tZSBvcmRlcnMgb2YgbWFnbml0dWRlIHN0YXRlIGltcHJvdmVtZW50IGluIHRo ZSBjb3JlIHN3aXRjaGVzLg0KDQpTaW1pbGFybHkgLCBib3RoIFBCQiBhbmQgU1BCTSBib3VuZCB0 aGUgYnJvYWRjYXN0IGRvbWFpbnMgZm9yIGEgY3VzdG9tZXIgVkxBTiB0byB0aGUgY29tbXVuaXR5 IG9mIGludGVyZXN0IHdpdGhvdXQgc2ltcGx5IGVtcGxveWluZyB0aGUgcmF0aGVyIHdhc3RlZnVs ICJlZ3Jlc3MgZGlzY2FyZCIsIHNvIHRoZSBwZXJpb2RpYyBmbG9vZGluZyBvZiB1bmtub3ducyBJ TU8gaXMgbm90IHRoZSBpc3N1ZSB5b3UgdGhpbmsgaXQgaXMuIFNpbWlsYXJseSBpdCBpcyB1bnJl bGF0ZWQgdG8gaG93IGNsb3NlIHRoZSBCRUIgaXMgcGxhY2VkIHRvIHRoZSBWTS4gRmxvb2Rpbmcg aXMgZWl0aGVyIGJvdW5kZWQgYnkgUy10YWcgb3IgYm91bmRlZCBieSBwZXIgSS1TSUQgbXVsdGlj YXN0IHRyZWVzLiBTbyBJJ20gbm90IHN1cmUgd2hhdCB5b3UgbWVhbiBieSB0aGUgInVua25vd24g dW5pY2FzdCBmbG9vZCBpbXBhY3QgaXNzdWUiLCBsb2NhdGlvbiBvZiB0aGUgQkVCIGRvZXMgbm90 IGNvbmZsYXRlIHVua25vd24gZmxvb2RpbmcuDQoNClRvIHN1bW1hcml6ZSwgSSdtIG5vdCB1bmRl cnN0YW5kaW5nIHlvdXIgcG9zdCBhbmQgYW0gc2Vla2luZyBjbGFyaWZpY2F0aW9uDQoNCnRoYW5r cw0KRGF2ZQ0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IGwy dnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgWHV4aWFvaHUNClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDA4LCAyMDExIDY6NTEg UE0NClRvOiBYdXhpYW9odTsgQmFsdXMsIEZsb3JpbiBTdGVsaWFuIChGbG9yaW4pOyBCaXRhciwg TmFiaWwgTjsgbDN2cG5AaWV0Zi5vcmc7IGwydnBuQGlldGYub3JnDQpDYzogeS5pa2VqaXJpQG50 dC5jb207IEx1eXVhbiBGYW5nIChsdWZhbmcpOyBTYWdlc3NpOyBtaXJjZWEucGlzaWNhQGJ0LmNv bQ0KU3ViamVjdDogcmU6IFlvdXIgaW5wdXQgb24gdGhlIGZvbGxvd2luZyBkcmFmdCBpcyBhcHBy ZWNpYXRlZDogZHJhZnQtYml0YXItZGF0YWNlbnRlci12cG4tYXBwbGljYWJpbGl0eS0wMS50eHQN Cg0KQnkgdGhlIHdheSwgaXQgd291bGQgYmUgYmV0dGVyIHRvIHB1c2ggdGhlIFBCQiBhcyBjbG9z ZSB0byB0aGUgZW5kLXN5c3RlbXMgYXMgcG9zc2libGUgZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2Yg TUFDIGZvcndhcmRpbmcgdGFibGUgc2NhbGFiaWxpdHkuIEhvd2V2ZXIsIHRoZSB1bmtub3duIHVu aWNhc3QgZmxvb2QgaW1wYWN0IGlzc3VlIHdvdWxkIGJlIHdvcnNlbiBhY2NvcmRpbmdseS4gRm9y IGV4YW1wbGUsIGluIGEgbm9ybWFsIExheWVyMiBuZXR3b3JrLCBpZiB0d28gVk1zIGF0dGFjaGVk IHRvIHRoZSBnaXZlbiBUb1IgYXJlIGZyZXF1ZW50bHkgY29tbXVuaWNhdGVkIHdpdGggZWFjaCBv dGhlciBhbmQgaGVuY2UgdGhlaXIgTUFDIGFkZHJlc3MgZW50cmllcyBvbiB0aGlzIFRvUiB3aWxs IG5vdCBiZSBleHBpcmVkLCB0aGUgdHJhZmZpYyBkZXN0aW5lZCBmb3IgYW55IG9mIHRob3NlIHR3 byBWTXMgZnJvbSBhIHJlbW90ZSBWTSBjb3VsZCBiZSBmbG9vZGVkIGFzIHVua25vd24gdW5pY2Fz dCB1bnRpbCB0aGUgdHJhZmZpYyByZWFjaCB0aGlzIFRvUiB3aGljaCBpbiB0dXJuIGZvcndhcmQg dGhlIHRyYWZmaWMgdG8gdGhlIGRlc3RpbmF0aW9uIFZNIGluIHVuaWNhc3QuICBIb3dldmVyLCBv bmNlIFBCQiBpcyBwZXJmb3JtZWQgYXQgZWFjaCBWU3csIHRoYXQgdHJhZmZpYyB3b3VsZCBiZSBm bG9vZGVkIHVudGlsIGl0IHJlYWNoIHRoZSBmaW5hbCBkZXN0aW5hdGlvbiBwaHlzaWNhbCBzZXJ2 ZXIuICBJdKGvcyBhIGhhcmQgdHJhZGVvZmYsIGlzbqGvdCBpdD8NCg0KWGlhb2h1DQoNCg0Kt6K8 /sjLOiBYdXhpYW9odQ0Kt6LLzcqxvOQ6IDIwMTHE6jEx1MI5yNUgMTA6MDgNCsrVvP7IyzogJ0Jh bHVzLCBGbG9yaW4gU3RlbGlhbiAoRmxvcmluKSc7IEJpdGFyLCBOYWJpbCBOOyBsM3ZwbkBpZXRm Lm9yZzsgbDJ2cG5AaWV0Zi5vcmcNCrOty806IEx1eXVhbiBGYW5nIChsdWZhbmcpOyBTYWdlc3Np OyB5LmlrZWppcmlAbnR0LmNvbTsgbWlyY2VhLnBpc2ljYUBidC5jb20NCtb3zOI6IHJlOiBZb3Vy IGlucHV0IG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQgaXMgYXBwcmVjaWF0ZWQ6IGRyYWZ0LWJpdGFy LWRhdGFjZW50ZXItdnBuLWFwcGxpY2FiaWxpdHktMDEudHh0DQoNCreivP7IyzogQmFsdXMsIEZs b3JpbiBTdGVsaWFuIChGbG9yaW4pIFttYWlsdG86ZmxvcmluLmJhbHVzQGFsY2F0ZWwtbHVjZW50 LmNvbV0NCreiy83KsbzkOiAyMDExxOoxMdTCOcjVIDU6MzQNCsrVvP7IyzogWHV4aWFvaHU7IEJp dGFyLCBOYWJpbCBOOyBsM3ZwbkBpZXRmLm9yZzsgbDJ2cG5AaWV0Zi5vcmcNCrOty806IEx1eXVh biBGYW5nIChsdWZhbmcpOyBTYWdlc3NpOyB5LmlrZWppcmlAbnR0LmNvbTsgbWlyY2VhLnBpc2lj YUBidC5jb20NCtb3zOI6IFJFOiBZb3VyIGlucHV0IG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQgaXMg YXBwcmVjaWF0ZWQ6IGRyYWZ0LWJpdGFyLWRhdGFjZW50ZXItdnBuLWFwcGxpY2FiaWxpdHktMDEu dHh0DQoNClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLCBzZWUgaW4tbGluZaGtDQoNCkZyb206IGwy dnBuLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgWHV4aWFvaHUNClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMDcsIDIwMTEgMTE6NTMg UE0NClRvOiBCaXRhciwgTmFiaWwgTjsgbDN2cG5AaWV0Zi5vcmc7IGwydnBuQGlldGYub3JnDQpD YzogTHV5dWFuIEZhbmcgKGx1ZmFuZyk7IFNhZ2Vzc2k7IHkuaWtlamlyaUBudHQuY29tOyBtaXJj ZWEucGlzaWNhQGJ0LmNvbQ0KU3ViamVjdDogcmU6IFlvdXIgaW5wdXQgb24gdGhlIGZvbGxvd2lu ZyBkcmFmdCBpcyBhcHByZWNpYXRlZDogZHJhZnQtYml0YXItZGF0YWNlbnRlci12cG4tYXBwbGlj YWJpbGl0eS0wMS50eHQNCg0KSGkgTmFiaWwsDQoNCkl0oa9zIGEgdmVyeSBjb21wcmVoZW5zaXZl IGRvYy4NCg0KU29tZSBjb21tb25zOg0KDQoxoaIgIEluIHNlY3Rpb24gNi4xLCBpdCBzYWlkOiCh sEFzIHRoZSBudW1iZXIgb2YgdGVuYW50cyBpbiBpbmRpdmlkdWFsIFZMQU4gaXNsYW5kcyBzdXJw YXNzZXMgNEssIHRoZSBvcGVyYXRvciBjb3VsZCBwdXNoIFZQTFMgZGVwbG95bWVudCBkZWVwZXIg aW4gdGhlIERDIG5ldHdvcmuhrS4gVGhlIFRvUiBhbmQgREMgY29yZSBlbGVtZW50cyBuZWVkIHRv IGJlIE1QTFMgZW5hYmxlZCB3aXRoIGV4aXN0aW5nIFZQTFMgc29sdXRpb25zobEsIElNSE8sIERD IGNvcmUgc3dpdGNoZXMgZG9uoa90IG5lZWQgdG8gYmUgTVBMUyBlbmFibGVkIHNpbmNlIElQIGJh c2VkIHR1bm5lbCBpcyBhbHNvIGF2YWlsYWJsZS4NCg0KDQoNCkZCPiBZb3UgYXJlIHJpZ2h0IHdl IHNob3VsZCBoYXZlIHNhaWQgobBJUCBvciBNUExTIGVuYWJsZWShsSBhcyBib3RoIGNhc2VzIGFy ZSBwb3NzaWJsZaGtDQoNCg0KDQo8WFhIPiBHb29kIHBvaW50Lg0KDQoNCg0KMqGiICBTdGlsbCBp biBzZWN0aW9uIDYuMSwgaXQgc2FpZDogobEgoa1Ib3dldmVyLCB0aGlzIG1vZGVsIGRvZXMgbm90 IHNvbHZlIHRoZSBNQUMgZXhwbG9zaW9uIGlzc3VlIGFzIFRvUnMgc3RpbGwgbmVlZCB0byBsZWFy biBWTSBNQUMgYWRkcmVzc2VzLqGxIEhvd2V2ZXIsIGluIHNlY3Rpb24gNi4yLjEsIGl0IHNhaWQ6 obGhrUFsdGVybmF0aXZlbHksIHRoZSBQQkIgZW5jYXBzdWxhdGlvbiBjYW4gYmUgZG9uZSBhdCB0 aGUgVG9SLqGxICBJdCBpcyBjb25mdXNlZCBzaW5jZSBwZXJmb3JtaW5nIFBCQiBlbmNhcHN1bGF0 aW9uIGF0IHRoZSBUb1Igd291bGQgbm90IGFsbGV2aWF0ZSB0aGUgTUFDLWxlYXJuaW5nIGJ1cmRl biBvbiB0aGF0IFRvUi4NCg0KDQoNCkZCPiBNYXliZSB0aGUgcGhyYXNlIGxvY2F0aW9uIGlzIHB1 enpsaW5nLiBUaGUgZm9jdXMgb2Ygc2VjdGlvbiA2LjIgaXMgdGhlIHVzZSBvZiBhbiBleHRlbmRl ZCAyNGIgUEJCIEktSVNJRCB0YWcgc3RhcnRpbmcgYXQgdGhlIFZTdyB0byBpZGVudGlmeSB0aGUg RUxBTiBicm9hZGNhc3QgZG9tYWluLg0KDQoNCg0KPFhYSD4gVGhlIHRpdGxlIG9mIHNlY3Rpb24g Ni4yLjEgaXMgobBBZGRyZXNzaW5nIFZMQU4gc3BhY2UgZXhoYXVzdGlvbiBhbmQgTUFDIGV4cGxv c2lvbqGxLiBTbyBJIHRoaW5rIHNheWluZyBtb3JlIHdvcmRzIGFmdGVyIHRoYXQgc2VudGVuY2Ug aXMgbXVjaCBoZWxwZnVsIGluIGF2b2lkaW5nIGNvbmZ1c2lvbi4NCg0KDQoNCg0KDQpUaGlzIHdp bGwgbWF4aW1pemUgdGhlIGJlbmVmaXRzLiBIb3dldmVyIGluIHJlYWxpdHkgaXQgaXMgdmVyeSBs aWtlbHkgdGhlcmUgd2lsbCBiZSBsZWdhY3kgREMgcmVnaW9ucyBzdGlsbCBydW5uaW5nIFZMQU5z IHdoaWNoIHJlcXVpcmUgYSBHYXRld2F5IGZ1bmN0aW9uIGR1cmluZyB0aGUgbWlncmF0aW9uLiBT ZWUgdGhlIFZMQU4gSW50ZXJvcCBkaXNjdXNzaW9uIGluIHNlY3Rpb24gNi4yLjkuDQoNCg0KDQoz oaIgIEluIDYuMi42LjIuIFBCQk4gaW4gVlN3LCBMMlZQTiBpbiB0aGUgVG9SLCBpdCBzYWlkOqGx IFRoZSBwcm9jZWR1cmVzIGZyb20gdGhlIHByZXZpb3VzIHNlY3Rpb24gYXJlIHVzZWQgYXQgdGhl IFZTdzogUEJCIGVuY2Fwc3VsYXRpb24gYW5kIEV0aGVybmV0IEJWTEFOcyBjYW4gYmUgdXNlZCBv biB0aGUgVlN3IHVwbGluay4gTDJWUE4gaW5mcmFzdHJ1Y3R1cmUgaXMgcmVwbGFjaW5nIHRoZSBC VkxBTiBhdCB0aGUgVG9SIGVuYWJsaW5nIHRoZSB1c2Ugb2YgSVAgKEdSRSBvciBMMlRQKSBvciBN UExTIHR1bm5lbGluZy4NCg0KDQoNCkZCPiBUaGlzIGlzIGFib3V0IHRoZSB0dW5uZWxpbmcgZW5j YXBzdWxhdGlvbiBvcHRpb25zIHRvIGJlIHVzZWQgaW4gdGhlIGNvcmU6IDI0YiBJLVNJRCB0YWcg aXMgdGhlIGNvbW1vbiB0ZW5hbnQgSUQgd2hpY2ggY2FuIGJlIHRyYW5zcG9ydGVkIG92ZXIgYW4g RXRoZXJuZXQgb3IgYW4gSVAgb3IgYW4gTVBMUyBiYXNlZCBEQyBuZXR3b3JrLiBDb21iaW5hdGlv bnMgb2YgdGhlc2UgdHVubmVsaW5nIG9wdGlvbnMgYXJlIGFsc28gcG9zc2libGU6IGUuZy4gb25l IERDIG1heSBiZSBFdGhlcm5ldCBiYXNlZCB0aGUgb3RoZXIgSVAgYmFzZWQ7IG9yIHRoZSBWU3cg bWF5IHVzZSBFdGhlcm5ldCBWTEFOIHR1bm5lbHMgd2hpbGUgSVAgdHVubmVscyBtYXkgc3RhcnQg YXQgdGhlIFRvUi4NCg0KDQoNCjxYWEg+IFllcywgSSBhZ3JlZSB3aXRoIHlvdXIgc3RhdGVtZW50 IGFib3ZlLiBBZGRpbmcgdGhlIGFib3ZlIHRleHQgaW50byB0aGUgZHJhZnQgd291bGQgYmUgbXVj aCBoZWxwZnVsOikNCg0KDQoNCiBMMiBuZXR3b3JraW5nIHN0aWxsIGhhcyB0aGUgc2FtZSBjb250 cm9sIHBsYW5lIGNob2ljZXM6IElTLUlTIFs4MDIuMWFxXSBhbmQvb3IgQkdQIFtQQkItRVZQTl0s IGluZGVwZW5kZW50bHkgZnJvbSB0aGUgdHVubmVsaW5nIGNob2ljZS6hsSBTaW5jZSBQQkIgZW5j YXBzdWxhdGlvbiBoYXMgYWxyZWFkeSBiZWVuIGRvbmUgb24gdGhlIFZTdywgd2h5IGRvIHdlIHN0 aWxsIG5lZWQgdG8gcnVuIDgwMi4xYXEgYW5kIFBCQi1FVlBOIHdpdGggYW5vdGhlciBQQkIgZW5j YXBzdWxhdGlvbiBsYXllcj8NCg0KDQoNCkZCPiBObyBuZWVkIGZvciBhbiBhZGRpdGlvbmFsIFBC QiBlbmNhcHN1bGF0aW9uIGxheWVyISBUaGlzIGlzIHN0cmljdGx5IGFib3V0IGNvbnRyb2wgcGxh bmUgb3B0aW9uczogSVMtSVMgYW5kIEJHUCBhcmUgdXNlZCB0aGUgc2FtZSB3YXkgYXMgaW4gcmVn dWxhciBJUCByb3V0aW5nIHRvIHBlcmZvcm0gTXVsdGlwYXRoaW5nLCBGYXN0IENvbnZlcmdlbmNl LCBzZXJ2aWNlIEFELCBwcm9ncmFtIHRoZSBjb3JlIEZJQnMgZXRjoa0NCg0KDQoNCjxYWEg+IEFi c29sdXRlbHkgYWdyZWUuIFN1Y2ggYmVpbmcgdGhlIGNhc2UsIHdoeSBub3QgcmVtb3ZlIHRoZSB0 d28gc3BlY2lmaWMgZXhhbXBsZXMgKGJvdGggb2YgdGhlbSBhZGQgYW5vdGhlciBQQkIgbGF5ZXIp IGZyb20gdGhhdCBzZW50ZW5jZSBzbyBhcyB0byBlbGltaW5hdGUgdGhlIHBvc3NpYmxlIGNvbmZ1 c2lvbj8NCg0KDQoNCiBDYW6hr3Qgd2Ugc2ltcGx5IHVzZSBhbnkgTDJWUE4gdGVjaG5vbG9neSwg ZS5nLiwgVlBMUy4gSW4gYWRkaXRpb24sIG5vdGUgdGhhdCBpbiBGaWd1cmUgNSwgaXQgc2FpZCCh sGludHJhLURDIEwyVlBOIG92ZXIgSVAgb3IgTVBMUyB0dW5uZWxpbmehsS4NCg0KDQpGQj4geWVz IHlvdSBjYW4uIFdlIGp1c3QgZm9jdXNlZCBoZXJlIG9uIHRoZSBvcHRpb25zIHRoYXQgd2lsbCBh ZGRyZXNzIHRoZSBjaGFsbGVuZ2VzIGRlc2NyaWJlZCBpbiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQg c2VjdGlvbi4gT3RoZXJ3aXNlIHRoZSBjb250ZW50IHdpbGwgaGF2ZSBncm93biB0b28gbXVjaC4N Cg0KPFhYSD4gVGhhbmtzIGZvciB5b3VyIGV4cGxhbmF0aW9uLg0KDQpCZXN0IHJlZ2FyZHMsDQpY aWFvaHUNCg0Kt6K8/sjLOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91 bmNlc0BpZXRmLm9yZ10gtPqx7SBCaXRhciwgTmFiaWwgTg0Kt6LLzcqxvOQ6IDIwMTHE6jEx1MI4 yNUgMTM6NDINCsrVvP7IyzogbDN2cG5AaWV0Zi5vcmc7IGwydnBuQGlldGYub3JnDQqzrcvNOiBT YWdlc3NpOyBtaXJjZWEucGlzaWNhQGJ0LmNvbTsgTHV5dWFuIEZhbmcgKGx1ZmFuZyk7IHkuaWtl amlyaUBudHQuY29tDQrW98ziOiBZb3VyIGlucHV0IG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQgaXMg YXBwcmVjaWF0ZWQ6IGRyYWZ0LWJpdGFyLWRhdGFjZW50ZXItdnBuLWFwcGxpY2FiaWxpdHktMDEu dHh0DQoNCkhpLA0KV2UgaGFkIHN1Ym1pdHRlZCB0aGUgZm9sbG93aW5nIGRyYWZ0IG9uIHZwbiBh cHBsaWNhYmlsaXR5IGZvciBkYXRhIGNlbnRlci4gWW91ciBpbnB1dCBvbiB0aGUgZHJhZnQgaXMg YXBwcmVjaWF0ZWQgaW4gbGlnaHQgb2Ygc29tZSBvZiB0aGUgb25nb2luZyBkaXNjdXNzaW9uLiBU aGUgZHJhZnQgaXMgdGFyZ2V0ZWQgZm9yIGwzdnBuIGFuZCBsMnZwbi4NCkhlcmUgaXMgdGhlIGxp bms6DQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJpdGFyLWRhdGFjZW50ZXIt dnBuLWFwcGxpY2FiaWxpdHktMDENCg0KDQpBYnN0cmFjdA0KDQoNCg0KICAgQ2xvdWQgQ29tcHV0 aW5nIGhhcyBiZWVuIGF0dHJhY3RpbmcgYSBsb3Qgb2YgYXR0ZW50aW9uIGZyb20gdGhlDQoNCiAg IG5ldHdvcmtpbmcgaW5kdXN0cnkuIFNvbWUgb2YgdGhlIG1vc3QgcHVibGljaXplZCByZXF1aXJl bWVudHMgYXJlDQoNCiAgIHJlbGF0ZWQgdG8gdGhlIGV2b2x1dGlvbiBvZiB0aGUgQ2xvdWQgTmV0 d29ya2luZyBJbmZyYXN0cnVjdHVyZSB0bw0KDQogICBhY2NvbW1vZGF0ZSBhIGxhcmdlIG51bWJl ciBvZiB0ZW5hbnRzLCBlZmZpY2llbnQgbmV0d29yayB1dGlsaXphdGlvbiwNCg0KICAgc2NhbGFi bGUgbG9vcCBhdm9pZGFuY2UsIGFuZCBWaXJ0dWFsIE1hY2hpbmUgTW9iaWxpdHkuDQoNCg0KDQog ICBUaGlzIGRyYWZ0IGRlc2NyaWJlcyBhIGZyYW1ld29yayBmb3IgY2xvdWQgbmV0d29ya2luZywg aGlnaGxpZ2h0aW5nDQoNCiAgIHRoZSBhcHBsaWNhYmlsaXR5IG9mIGV4aXN0aW5nIHdvcmsgaW4g dmFyaW91cyBJRVRGIFdvcmtpbmcgR3JvdXBzDQoNCiAgIChlLmcuLCBSRkNzIGFuZCBkcmFmdHMg ZGV2ZWxvcGVkIGluIElFVEYgTDJWUE4gYW5kIEwzVlBOIFdvcmtpbmcNCg0KICAgR3JvdXBzKSB0 byBjbG91ZCBuZXR3b3JraW5nLCBhbmQgdGhlIGdhcHMgYW5kIHByb2JsZW1zIHRoYXQgbmVlZCB0 bw0KDQogICBiZSBmdXJ0aGVyIGFkZHJlc3NlZC4gVGhhdCBpcywgdGhlIGdvYWwgaXMgdG8gdW5k ZXJzdGFuZCB3aGF0IG1heSBiZQ0KDQogICByZS11c2VkIGZyb20gdGhlIGN1cnJlbnQgcHJvdG9j b2xzIGFuZCBjYWxsIG91dCByZXF1aXJlbWVudHMgc3BlY2lmaWMNCg0KICAgdG8gdGhlIENsb3Vk IHNwYWNlIHRoYXQgbmVlZCB0byBiZSBhZGRyZXNzZWQgYnkgbmV3IHN0YW5kYXJkaXphdGlvbg0K DQogICB3b3JrIHdpdGggcHJvcG9zZWQgc29sdXRpb25zIGluIGNlcnRhaW4gY2FzZXMuDQoNCg0K VGhhbmtzLA0KDQpOYWJpbA0K --_000_60C093A41B5E45409A19D42CF7786DFD52261A095CEUSAACMS0703e_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Xuxaohu:
 
I would object to your suggestion of "as cl= ose to=20 the end-systems as possible". PBB is hierarchical summarization, so the num= ber=20 of C-MACs summarized for reachability to B-MACs is a function of how close = the=20 BEB is placed to the end system. If it is "co-located" with the end system= =20 (a.k.a as close as possible) there is no summarization. 1  B-MAC=20 corresponds to 1 C-MAC and the encapsulation at that point is simply a=20 gratuitous increase in bandwidth consumption. Which tends to suggest there = is a=20 natural location for placement of the BEB function which permits some order= s of=20 magnitude state improvement in the core switches.=20
 
Similarly , both PBB and SPBM bound the broadcast dom= ains for=20 a customer VLAN to the community of interest without simply employing the r= ather=20 wasteful "egress discard", so the periodic flooding of unknowns IMO is not = the=20 issue you think it is. Similarly it is unrelated to how close the BEB = is=20 placed to the VM. Flooding is either bounded by S-tag or bounded by per I-S= ID=20 multicast trees. So I'm not sure what you mean by the "unknown unicast floo= d=20 impact issue", location of the BEB does not conflate unknown=20 flooding.
 
To summarize, I'm not understanding your post and am = seeking=20 clarification 
 <= /DIV>
thanks
Dave 
 
 

From: l2vpn-bounces@ietf.org=20 [mailto:l2vpn-bounces@ietf.org] On Behalf Of Xuxiaohu
Sent:=20 Tuesday, November 08, 2011 6:51 PM
To: Xuxiaohu; Balus, Florin St= elian=20 (Florin); Bitar, Nabil N; l3vpn@ietf.org; l2vpn@ietf.org
Cc:=20 y.ikejiri@ntt.com; Luyuan Fang (lufang); Sagessi;=20 mircea.pisica@bt.com
Subject: re: Your input on the following dra= ft is=20 appreciated:=20 draft-bitar-datacenter-vpn-applicability-01.txt

By the way, it would be better to push the PBB as close to the= =20 end-systems as possible from the perspective of MAC forwarding table=20 scalability. However, the unknown unicast flood impact issue would be worse= n=20 accordingly. For example, in a normal Layer2 network, if two VMs attached t= o the=20 given ToR are frequently communicated with each other and hence their MAC=20 address entries on this ToR will not be expired, the traffic destined for a= ny of=20 those two VMs from a remote VM could be flooded as unknown unicast until th= e=20 traffic reach this ToR which in turn forward the traffic to the destination= VM=20 in unicast.  However, once PBB is performed at each VSw, that traffic = would=20 be flooded until it reach the final destination physical server.  It= =A1=AFs a=20 hard tradeoff, isn=A1=AFt it?

 

Xiaohu

 

 

=B7=A2=BC=FE=C8=CB: Xuxiaohu
=B7=A2=CB=CD=CA=B1=BC= =E4: 2011=C4=EA11=D4=C29=C8=D5=20 10:08
=CA=D5=BC=FE=C8=CB: 'Balus,=20 Florin Stelian (Florin)'; Bitar, Nabil N; l3vpn@ietf.org;=20 l2vpn@ietf.org
=B3=AD=CB=CD:=20 Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com;=20 mircea.pisica@bt.com
=D6=F7=CC=E2: re: Your input on the following draft is appreciated:=20 draft-bitar-datacenter-vpn-applicability-01.txt

 

=B7=A2=BC=FE=C8=CB: Balus, Florin Stelian (Florin)=20 [mailto:florin.balus@alcatel-lucent.com]
=B7=A2=CB=CD=CA=B1=BC= =E4: 2011=C4=EA11=D4=C29=C8=D5=20 5:34
=CA=D5=BC=FE=C8=CB: Xuxiaohu;=20 Bitar, Nabil N; l3vpn@ietf.org; l2vpn@ietf.org
=B3=AD=CB=CD: Luyuan Fang (lufang); Sagessi;= =20 y.ikejiri@ntt.com; mircea.pisica@bt.com
=D6=F7=CC=E2: RE: Your input on the followin= g draft=20 is appreciated:=20 draft-bitar-datacenter-vpn-applicability-01.txt

 

Thanks for the comments, see in-line=A1=AD

 

From:= =20 l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of=20 Xuxiaohu
Sent: Monday, November 07, 2011 11:53 PM
To:=20 Bitar, Nabil N; l3vpn@ietf.org; l2vpn@ietf.org
Cc: Luyuan Fang=20 (lufang); Sagessi; y.ikejiri@ntt.com; mircea.pisica@bt.com
Subject:=20 re: Your input on the following draft is appreciated:=20 draft-bitar-datacenter-vpn-applicability-01.txt

=

 

Hi Nabil,

 

It=A1=AFs a very comprehensive doc.

 

Some commons:

1=A1=A2  In section 6.1, it said: =A1=
=B0As the number of tenants in individual VLAN islands surpasses 4K, the op=
erator could push VPLS deployment deeper in the DC network=A1=AD. The ToR a=
nd DC core elements need to be MPLS enabled with existing VPLS solutions=A1=
=B1, IMHO, DC core switches don=A1=AFt need to be MPLS enabled since IP bas=
ed tunnel is also available.
 
FB> =
You are right we should have said =A1=B0IP or MPLS enabled=A1=B1 as both ca=
ses are possible=A1=AD 
 
<XXH> Good=
 point.
 
2=A1=A2  Still in section 6.1,=
 it said: =A1=B1 =A1=ADHowever, this model does not solve the MAC explosion=
 issue as ToRs still need to learn VM MAC addresses.=A1=B1 However, in sect=
ion 6.2.1, it said:=A1=B1=A1=ADAlternatively, the PBB encapsulation can be =
done at the ToR.=A1=B1  It is confused since performing PBB encapsulat=
ion at the ToR would not alleviate the MAC-learning burden on that ToR.
 
FB> Maybe the phrase location is puz=
zling. The focus of section 6.2 is the use of an extended 24b PBB I-ISID ta=
g starting at the VSw to identify the ELAN broadcast domain. 
 
<XXH> The title of section 6.2.1 is =A1=B0Addre=
ssing VLAN space exhaustion and MAC explosion=A1=B1. So I think saying more=
 words after that sentence is much helpful in avoiding confusion.
 
 
This will maximize the bene=
fits. However in reality it is very likely there will be legacy DC regions =
still running VLANs which require a Gateway function during the migration. =
See the VLAN Interop discussion in section 6.2.9. 
<=
PRE style=3D"PAGE-BREAK-BEFORE: always; MARGIN-LEFT: 18pt"> 
3=
=A1=A2  In 6.2.6.2<=
/A>. PBBN in VSw, L2VPN in the ToR, it said:=A1=B1 The procedures from the previous section are used at the VSw:=
 PBB encapsulation and Ethernet BVLANs can be used on the VSw uplink. L2VPN=
 infrastructure is replacing the BVLAN at the ToR enabling the use of IP (G=
RE or L2TP) or MPLS tunneling. 
 
FB> This is about the tunneling encapsulation options to be used in the=
 core: 24b I-SID tag is the common tenant ID which can be transported over =
an Ethernet or an IP or an MPLS based DC network. Combinations of these tun=
neling options are also possible: e.g. one DC may be Ethernet based the oth=
er IP based; or the VSw may use Ethernet VLAN tunnels while IP tunnels may =
start at the ToR.
 
<XXH> Yes, I agr=
ee with your statement above. Adding the above text into the draft would be=
 much helpfulJ
 
 L2 networking still has t=
he same control plane choices: IS-IS [802.1aq] and/or BGP [PBB-EVPN], indep=
endently from the tunneling choice.=A1=B1 Since PBB encapsulation has alrea=
dy been done on the VSw, why do we still need to run 802.1aq and PBB-EVPN w=
ith another PBB encapsulation layer?
 
FB> No need for an additional PBB encapsulation layer! This is strictly=
 about control plane options: IS-IS and BGP are used the same way as in reg=
ular IP routing to perform Multipathing, Fast Convergence, service AD, prog=
ram the core FIBs etc=A1=AD
 
<XXH> = Absolutely agree. Such being the case, why not remove the two specific exam= ples (both of them add another PBB layer) from that sentence so as to elimi= nate the possible confusion?
 
 Can=A1=AFt we simply use any L2VPN technology, =
e.g., VPLS. In addition, note that in Figure 5, it said =A1=B0intra-DC L2VP=
N over IP or MPLS tunneling=A1=B1.

 

FB> yes you can. W=
e just focused here on the options that will address the challenges describ=
ed in the problem statement section. Otherwise the content will have grown =
too much.

 

<XXH> Thanks for your explanation.

 

Best regards,

Xiaohu

 

=B7=A2=BC=FE=C8=CB: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org]=20 =B4=FA= =B1=ED Bitar, Na= bil=20 N
= =B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C28=C8=D5=20 13:42
=CA=D5=BC=FE=C8=CB:=20 l3vpn@ietf.org; l2vpn@ietf.org
=B3=AD=CB=CD= : Sagessi; mircea.pisica@bt.com; Luyuan Fang (lufang);=20 y.ikejiri@ntt.com
=D6=F7=CC=E2:<= SPAN lang=3DEN-US>=20 Your input on the following draft is appreciated:=20 draft-bitar-datacenter-vpn-applicability-01.txt

 

Hi,

We had submitted the following draft on vpn applicability for = data=20 center. Your input on the draft is appreciated in light of some of the ongo= ing=20 discussion. The draft is targeted for l3vpn and=20 l2vpn.

Here is the link: 

 

 

Abstract
 
   Cloud Computing has been attracting =
a lot of attention from the
   networking industry. Some of the most publicized r=
equirements are
=
   related to the evolution of the Cloud Networking Infrastructur=
e to
  =
; accommodate a large number of tenants, efficient network utilization,
   scalab=
le loop avoidance, and Virtual Machine Mobility.
 
   This draft describes a framework for=
 cloud networking, highlighting
   the applicability of existing work in various =
IETF Working Groups
   (e.g., RFCs and drafts developed in IETF L2VPN and L3VPN W=
orking
 &nb=
sp; Groups) to cloud networking, and the gaps and problems that need to
   be fur=
ther addressed. That is, the goal is to understand what may be
   re-used from th=
e current protocols and call out requirements specific
   to the Cloud space that=
 need to be addressed by new standardization
   work with proposed solutions in c=
ertain cases.
Thanks,
Nabil
<= /BODY> --_000_60C093A41B5E45409A19D42CF7786DFD52261A095CEUSAACMS0703e_-- From linda.dunbar@huawei.com Wed Nov 9 11:32:06 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241BE11E808B; Wed, 9 Nov 2011 11:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.125 X-Spam-Level: X-Spam-Status: No, score=-6.125 tagged_above=-999 required=5 tests=[AWL=-0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHe7IPEz0YeJ; Wed, 9 Nov 2011 11:32:05 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 78E3E11E8089; Wed, 9 Nov 2011 11:32:05 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUE00B5VRLA9K@usaga04-in.huawei.com>; Wed, 09 Nov 2011 13:31:59 -0600 (CST) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUE009U3RKV0G@usaga04-in.huawei.com>; Wed, 09 Nov 2011 13:31:58 -0600 (CST) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 09 Nov 2011 11:31:39 -0800 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Wed, 09 Nov 2011 11:31:33 -0800 Date: Wed, 09 Nov 2011 19:31:33 +0000 From: Linda Dunbar Subject: Need your action to review draft-ietf-armd-problem-statement-00.txt X-Originating-IP: [10.192.11.155] To: "l2vpn@ietf.org" , L3VPN WG mailing list , "sdnp@lucidvision.com" Message-id: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_pqxZHOFXGA69gJuhLyEG+A)" Content-language: en-US Accept-Language: en-US Thread-topic: Need your action to review draft-ietf-armd-problem-statement-00.txt Thread-index: AQHMnxYw0sp2lA3FXUyNvGuBDlwwdw== X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 19:32:06 -0000 --Boundary_(ID_pqxZHOFXGA69gJuhLyEG+A) Content-type: multipart/alternative; boundary="Boundary_(ID_2xYEQabSJUJeXxiogMJ0fQ)" --Boundary_(ID_2xYEQabSJUJeXxiogMJ0fQ) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT For those of you who touch upon Data Center networking or server virtualization, be it Overlay, VPN4DC, or Application/Software driven Controller for Data Center, Address Resolution is something Data Center Gateways will encounter because hosts/applications in data centers do communicate with peers which are not in the same Overlay, outside the VPN domain, or from general public. ARMD has published its WG problem statement draft. Your comments and suggestions are appreciated (send to armd@ietf.org). Thanks, Linda Dunbar ----------------------------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Address Resolution for Massive numbers of hosts in the Data center Working Group of the IETF. Title : Problem Statement for ARMD Author(s) : Thomas Narten Filename : draft-ietf-armd-problem-statement-00.txt Pages : 11 Date : 2011-10-17 This document examines issues related to the massive scaling of data centers. Our initial scope is relatively narrow. Specifically, we focus on address resolution (ARP and ND) within the data center. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-armd-problem-statement-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-armd-problem-statement-00.txt --Boundary_(ID_2xYEQabSJUJeXxiogMJ0fQ) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

For those of you who t= ouch upon Data Center networking or server virtualization, be it Overlay, V= PN4DC, or Application/Software driven Controller for Data Center, Address R= esolution is something Data Center Gateways  will encounter because hosts/applications in data centers do communi= cate with peers which are not in the same Overlay, outside the VPN domain, = or from general public. ARMD has published its WG problem statement draft. = Your comments and suggestions are appreciated (send to armd@ietf.org). <= /span>

 

Thanks, Linda Dunbar

 

----------------------= -------------------------------------------------------------

 

 

A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories. This draft is a work item of the Address Resolution for Massive n=
umbers of hosts in the Data center Working Group of the IETF.

 


        Title   &nbs=
p;       : Problem Statement for ARMD


        Author(s)   =
    : Thomas Narten


        Filename   &=
nbsp;    : draft-ietf-armd-problem-statement-00.txt


        Pages   &nbs=
p;       : 11


        Date    =
;        : 2011-10-17


 


   This document examines issues related to the massive scal=
ing of data


   centers.  Our initial scope is relatively narrow.&nb=
sp; Specifically, we


   focus on address resolution (ARP and ND) within the data =
center.


 


 


A URL for this Internet-Draft is:


http://www.ietf.org/internet-drafts/draft-ietf-armd-prob=
lem-statement-00.txt


 


Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/int=
ernet-drafts/


 


This Internet-Draft can be retrieved at:


ftp://ftp.ietf.org/internet-drafts/draft-ietf-armd-proble=
m-statement-00.txt


 
--Boundary_(ID_2xYEQabSJUJeXxiogMJ0fQ)-- --Boundary_(ID_pqxZHOFXGA69gJuhLyEG+A) Content-id: <318D3282CFCD0C45A8C99283FF38289A@huawei.com> Content-type: text/plain; name=ATT00001.txt Content-transfer-encoding: 7BIT Content-disposition: attachment; filename=ATT00001.txt; size=127; creation-date="Fri, 04 Nov 2011 15:30:31 GMT"; modification-date="Fri, 04 Nov 2011 15:30:31 GMT" Content-description: ATT00001.txt _______________________________________________ armd mailing list armd@ietf.org https://www.ietf.org/mailman/listinfo/armd --Boundary_(ID_pqxZHOFXGA69gJuhLyEG+A)-- From pedro.r.marques@gmail.com Wed Nov 9 11:52:02 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB8C21F848C; Wed, 9 Nov 2011 11:52:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=0.389, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+0pq750uVCR; Wed, 9 Nov 2011 11:52:02 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 47F9621F848A; Wed, 9 Nov 2011 11:52:02 -0800 (PST) Received: by iaeo4 with SMTP id o4so2690124iae.31 for ; Wed, 09 Nov 2011 11:52:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=a79ejb1F58MgUgbAyMDMUHkCJYubn5OSVkDuL0yNKbs=; b=XrppjTzzMJG+jmuZ3DPrM1xm5EBhM+vIHQEBU9OPx74qEhYR9ITIqiWuzRJwGZGfNA UWuYx5MWFg7eEZ13QkN/KocjK+Cyz6dfRhxXW6R2Zz9zbopnnJH2M7q9EVIbj5tLFv2S ds0azcAWRSkK0tOBbH9G+gA3ETLr6ZdzhPmL8= MIME-Version: 1.0 Received: by 10.231.83.201 with SMTP id g9mr1053454ibl.68.1320868320096; Wed, 09 Nov 2011 11:52:00 -0800 (PST) Received: by 10.231.12.2 with HTTP; Wed, 9 Nov 2011 11:52:00 -0800 (PST) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> Date: Wed, 9 Nov 2011 11:52:00 -0800 Message-ID: Subject: Re: Need your action to review draft-ietf-armd-problem-statement-00.txt From: Pedro Marques To: Linda Dunbar Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 09 Nov 2011 11:52:57 -0800 Cc: "l2vpn@ietf.org" , "sdnp@lucidvision.com" , L3VPN WG mailing list , armd@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 19:52:03 -0000 Linda, I'd like to point out that the problem does not need to be solved if only IP connectivity is required. This I-D: http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 describes a solution in which address resolution is not required irrespective of the location of the traffic destination. Simply put, traffic can be routed at each hop. As per previous threads in this list, the concept of subnet which is of no practical usefulness in this space. Since VMs can be randomly distributed across the network the subnet does not provide any information aggregation value. Thus there is no need to do address resolution. Pedro. On Wed, Nov 9, 2011 at 11:31 AM, Linda Dunbar wro= te: > For those of you who touch upon Data Center networking or server > virtualization, be it Overlay, VPN4DC, or Application/Software driven > Controller for Data Center, Address Resolution is something Data Center > Gateways =A0will encounter because hosts/applications in data centers do > communicate with peers which are not in the same Overlay, outside the VPN > domain, or from general public. ARMD has published its WG problem stateme= nt > draft. Your comments and suggestions are appreciated (send to > armd@ietf.org). > > > > Thanks, Linda Dunbar > > > > -------------------------------------------------------------------------= ---------- > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Address Resolution for Mass= ive > numbers of hosts in the Data center Working Group of the IETF. > > > > =A0=A0=A0=A0=A0=A0=A0 Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : Problem State= ment for ARMD > > =A0=A0=A0=A0=A0=A0=A0 Author(s)=A0=A0=A0=A0=A0=A0 : Thomas Narten > > =A0=A0=A0=A0=A0=A0=A0 Filename=A0=A0=A0=A0=A0=A0=A0 : draft-ietf-armd-pro= blem-statement-00.txt > > =A0=A0=A0=A0=A0=A0=A0 Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 11 > > =A0=A0=A0=A0=A0=A0=A0 Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2011-10-17 > > > > =A0=A0 This document examines issues related to the massive scaling of da= ta > > =A0=A0 centers.=A0 Our initial scope is relatively narrow.=A0 Specificall= y, we > > =A0=A0 focus on address resolution (ARP and ND) within the data center. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-armd-problem-statement-00.= txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-armd-problem-statement-00.t= xt > > From linda.dunbar@huawei.com Wed Nov 9 12:12:26 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB191F0C43; Wed, 9 Nov 2011 12:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.821 X-Spam-Level: X-Spam-Status: No, score=-5.821 tagged_above=-999 required=5 tests=[AWL=-0.422, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kj6hzNo6IzUQ; Wed, 9 Nov 2011 12:12:25 -0800 (PST) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id DDE341F0C41; Wed, 9 Nov 2011 12:12:25 -0800 (PST) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUE00B35TGH9K@usaga04-in.huawei.com>; Wed, 09 Nov 2011 14:12:18 -0600 (CST) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUE0096HTGE0G@usaga04-in.huawei.com>; Wed, 09 Nov 2011 14:12:17 -0600 (CST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 09 Nov 2011 12:12:11 -0800 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Wed, 09 Nov 2011 12:11:58 -0800 Date: Wed, 09 Nov 2011 20:12:08 +0000 From: Linda Dunbar Subject: RE: Need your action to review draft-ietf-armd-problem-statement-00.txt In-reply-to: X-Originating-IP: [10.192.11.155] To: Pedro Marques Message-id: <4A95BA014132FF49AE685FAB4B9F17F6120BEC36@dfweml506-mbx> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-language: en-US Content-transfer-encoding: quoted-printable Accept-Language: en-US, zh-CN Thread-topic: Need your action to review draft-ietf-armd-problem-statement-00.txt Thread-index: AQHMnxkRlZozan+p5EmwsYAz13twApWk988g X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> Cc: "l2vpn@ietf.org" , "sdnp@lucidvision.com" , L3VPN WG mailing list , "armd@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 20:12:26 -0000 Pedro,=20 You are absolutely right that there is no ARP/ND scaling issue if IP can be= extended to hosts. Even if IP can be extended to Access switches, there is= not much ARP/ND issues.=20 The draft lists down several common data center network designs, and states= that some of the designs don't have ARP/ND scaling issues (but may have ot= her issues for data centers).=20 That is why I encourage people to read the draft and provides comments.=20 Linda=20 > -----Original Message----- > From: Pedro Marques [mailto:pedro.r.marques@gmail.com] > Sent: Wednesday, November 09, 2011 1:52 PM > To: Linda Dunbar > Cc: l2vpn@ietf.org; L3VPN WG mailing list; sdnp@lucidvision.com; > armd@ietf.org > Subject: Re: Need your action to review draft-ietf-armd-problem- > statement-00.txt >=20 > Linda, > I'd like to point out that the problem does not need to be solved if > only IP connectivity is required. This I-D: > http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 describes > a solution in which address resolution is not required irrespective of > the location of the traffic destination. Simply put, traffic can be > routed at each hop. >=20 > As per previous threads in this list, the concept of subnet which is > of no practical usefulness in this space. Since VMs can be randomly > distributed across the network the subnet does not provide any > information aggregation value. Thus there is no need to do address > resolution. >=20 > Pedro. >=20 > On Wed, Nov 9, 2011 at 11:31 AM, Linda Dunbar > wrote: > > For those of you who touch upon Data Center networking or server > > virtualization, be it Overlay, VPN4DC, or Application/Software driven > > Controller for Data Center, Address Resolution is something Data > Center > > Gateways =A0will encounter because hosts/applications in data centers > do > > communicate with peers which are not in the same Overlay, outside the > VPN > > domain, or from general public. ARMD has published its WG problem > statement > > draft. Your comments and suggestions are appreciated (send to > > armd@ietf.org). > > > > > > > > Thanks, Linda Dunbar > > > > > > > > --------------------------------------------------------------------- > -------------- > > > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. This draft is a work item of the Address Resolution for > Massive > > numbers of hosts in the Data center Working Group of the IETF. > > > > > > > > =A0=A0=A0=A0=A0=A0=A0 Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : Problem Sta= tement for ARMD > > > > =A0=A0=A0=A0=A0=A0=A0 Author(s)=A0=A0=A0=A0=A0=A0 : Thomas Narten > > > > =A0=A0=A0=A0=A0=A0=A0 Filename=A0=A0=A0=A0=A0=A0=A0 : draft-ietf-armd-p= roblem-statement-00.txt > > > > =A0=A0=A0=A0=A0=A0=A0 Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 11 > > > > =A0=A0=A0=A0=A0=A0=A0 Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2011-10-1= 7 > > > > > > > > =A0=A0 This document examines issues related to the massive scaling of > data > > > > =A0=A0 centers.=A0 Our initial scope is relatively narrow.=A0 Specifica= lly, > we > > > > =A0=A0 focus on address resolution (ARP and ND) within the data center. > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-armd-problem- > statement-00.txt > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > This Internet-Draft can be retrieved at: > > > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-armd-problem-statement- > 00.txt > > > > From skh@ndzh.com Wed Nov 9 12:27:48 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197171F0C74; Wed, 9 Nov 2011 12:27:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.618 X-Spam-Level: X-Spam-Status: No, score=0.618 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkKv3uVmYJ7D; Wed, 9 Nov 2011 12:27:47 -0800 (PST) Received: from hickoryhill-consulting.com (63-208-161-201.digitalrealm.net [63.208.161.201]) by ietfa.amsl.com (Postfix) with ESMTP id 42A561F0C4C; Wed, 9 Nov 2011 12:27:47 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=63.133.138.150; Received: from SKHPERSONALLT (unverified [63.133.138.150]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 2825941-1945496 for multiple; Wed, 09 Nov 2011 15:26:58 -0500 From: "Susan Hares" To: "'Linda Dunbar'" , "'Pedro Marques'" References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120BEC36@dfweml506-mbx> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6120BEC36@dfweml506-mbx> Subject: RE: [armd] Need your action to review draft-ietf-armd-problem-statement-00.txt Date: Wed, 9 Nov 2011 15:27:03 -0500 Message-ID: <000501cc9f1d$f16be5f0$d443b1d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHMnxkRlZozan+p5EmwsYAz13twApWk988ggAAFvLA= Content-Language: en-us X-Authenticated-User: skh@ndzh.com X-Mailman-Approved-At: Wed, 09 Nov 2011 12:41:42 -0800 Cc: l2vpn@ietf.org, sdnp@lucidvision.com, 'L3VPN WG mailing list' , armd@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 20:27:48 -0000 Pedro: Your review of the draft would be especially helpful in the L3 only = design.=20 Sue=20 -----Original Message----- From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Linda Dunbar Sent: Wednesday, November 09, 2011 3:12 PM To: Pedro Marques Cc: l2vpn@ietf.org; sdnp@lucidvision.com; L3VPN WG mailing list; armd@ietf.org Subject: Re: [armd] Need your action to review draft-ietf-armd-problem-statement-00.txt Pedro,=20 You are absolutely right that there is no ARP/ND scaling issue if IP can = be extended to hosts. Even if IP can be extended to Access switches, there = is not much ARP/ND issues.=20 The draft lists down several common data center network designs, and = states that some of the designs don't have ARP/ND scaling issues (but may have other issues for data centers).=20 That is why I encourage people to read the draft and provides comments.=20 Linda=20 > -----Original Message----- > From: Pedro Marques [mailto:pedro.r.marques@gmail.com] > Sent: Wednesday, November 09, 2011 1:52 PM > To: Linda Dunbar > Cc: l2vpn@ietf.org; L3VPN WG mailing list; sdnp@lucidvision.com; > armd@ietf.org > Subject: Re: Need your action to review draft-ietf-armd-problem- > statement-00.txt >=20 > Linda, > I'd like to point out that the problem does not need to be solved if > only IP connectivity is required. This I-D: > http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 describes > a solution in which address resolution is not required irrespective of > the location of the traffic destination. Simply put, traffic can be > routed at each hop. >=20 > As per previous threads in this list, the concept of subnet which is > of no practical usefulness in this space. Since VMs can be randomly > distributed across the network the subnet does not provide any > information aggregation value. Thus there is no need to do address > resolution. >=20 > Pedro. >=20 > On Wed, Nov 9, 2011 at 11:31 AM, Linda Dunbar = > wrote: > > For those of you who touch upon Data Center networking or server > > virtualization, be it Overlay, VPN4DC, or Application/Software = driven > > Controller for Data Center, Address Resolution is something Data > Center > > Gateways =A0will encounter because hosts/applications in data = centers > do > > communicate with peers which are not in the same Overlay, outside = the > VPN > > domain, or from general public. ARMD has published its WG problem > statement > > draft. Your comments and suggestions are appreciated (send to > > armd@ietf.org). > > > > > > > > Thanks, Linda Dunbar > > > > > > > > = --------------------------------------------------------------------- > -------------- > > > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. This draft is a work item of the Address Resolution for > Massive > > numbers of hosts in the Data center Working Group of the IETF. > > > > > > > > =A0=A0=A0=A0=A0=A0=A0 Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : Problem = Statement for ARMD > > > > =A0=A0=A0=A0=A0=A0=A0 Author(s)=A0=A0=A0=A0=A0=A0 : Thomas Narten > > > > =A0=A0=A0=A0=A0=A0=A0 Filename=A0=A0=A0=A0=A0=A0=A0 : = draft-ietf-armd-problem-statement-00.txt > > > > =A0=A0=A0=A0=A0=A0=A0 Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 11 > > > > =A0=A0=A0=A0=A0=A0=A0 Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : = 2011-10-17 > > > > > > > > =A0=A0 This document examines issues related to the massive scaling = of > data > > > > =A0=A0 centers.=A0 Our initial scope is relatively narrow.=A0 = Specifically, > we > > > > =A0=A0 focus on address resolution (ARP and ND) within the data = center. > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-armd-problem- > statement-00.txt > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > This Internet-Draft can be retrieved at: > > > > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-armd-problem-statement- > 00.txt > > > > _______________________________________________ armd mailing list armd@ietf.org https://www.ietf.org/mailman/listinfo/armd From pedro.r.marques@gmail.com Wed Nov 9 14:20:56 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F1C11E8090; Wed, 9 Nov 2011 14:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.931 X-Spam-Level: X-Spam-Status: No, score=-2.931 tagged_above=-999 required=5 tests=[AWL=0.668, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6eIqHnYlZcmd; Wed, 9 Nov 2011 14:20:55 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3D81611E8080; Wed, 9 Nov 2011 14:20:55 -0800 (PST) Received: by iaeo4 with SMTP id o4so2843009iae.31 for ; Wed, 09 Nov 2011 14:20:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oLwP+ID7yPLVTzPY5yfEGHdExfYTow5LSJdpXQW50Bc=; b=q9ndhoGRRWmmmWeaFlPgfndDnMilZljIqv1diOLeVSujVqVXKbU+IQvuGU1T7cVEKF 7lVlo2ZM6Bsrfjag/b17cGCzCkLb6eamGpxuIMZePTVtv6tCIYoCgM2OjHq3Thp8yQNm pcdkPoWZQJS6Epg1TICS3eZEWjU+Ozw5vD7R0= MIME-Version: 1.0 Received: by 10.42.72.135 with SMTP id o7mr5031566icj.45.1320877253259; Wed, 09 Nov 2011 14:20:53 -0800 (PST) Received: by 10.231.12.2 with HTTP; Wed, 9 Nov 2011 14:20:53 -0800 (PST) In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6120BEC36@dfweml506-mbx> References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120BEC36@dfweml506-mbx> Date: Wed, 9 Nov 2011 14:20:53 -0800 Message-ID: Subject: Re: Need your action to review draft-ietf-armd-problem-statement-00.txt From: Pedro Marques To: Linda Dunbar Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Wed, 09 Nov 2011 14:24:37 -0800 Cc: "l2vpn@ietf.org" , "sdnp@lucidvision.com" , L3VPN WG mailing list , "armd@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 22:20:56 -0000 Linda, Please see inline. On Wed, Nov 9, 2011 at 12:12 PM, Linda Dunbar wrote: > Pedro, > > You are absolutely right that there is no ARP/ND scaling issue if IP can be extended to hosts. Even if IP can be extended to Access switches, there is not much ARP/ND issues. The draft is a bit unclear in terms of its assumptions regarding the connectivity of the VMs. It does state that the VMs typically have their own IP and mac addresses but doesn't mention that these are typically also associated with different VLANs. There are multiple proposals (e.g. VXLAN) in which these VLANs are data-center wide. Thus if the VM sees a LAN adjacency to its "subnet" there is an ARP/ND issue to solve. VXLAN for instance assumes that ARP requests will be broadcasted using IP multicast groups per VLAN. You may want to characterize the several 'categories' of proposals that satisfy the requirements of VM mobility and closed user group isolation. For example: L2 approaches: (e.g. VXLAN) These tend towards creating a data-center wide broadcast domain. The broadcast domain can then be used to send ARP/ND requests. Routed L2/L3 approaches (e.g. EVPN): Present an L2 interface to the VM but transform it to a routed approach in a network element and advertise mac (optionally) + ip host prefixes from the network elements. An important sub category here is whether these solutions then assume multicast capability or not in the underlying network. Host based approaches. These can present either an L2 or L3 "service" and assume or not the presence of an underlying multicast service on the part of the underlying "fabric" network. Map service based approaches: Use a query based mechanism rather than a "push" based mechanism like routing to distributed the overlay network information. Each of these has its own way to address ARP/ND related issues. If you your intent is to document the possibilities there is plenty of options to choose from. :-) Pedro. From narten@us.ibm.com Thu Nov 10 07:49:49 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0E2D21F8B2F for ; Thu, 10 Nov 2011 07:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.274 X-Spam-Level: X-Spam-Status: No, score=-106.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAHdSFad0FqO for ; Thu, 10 Nov 2011 07:49:49 -0800 (PST) Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by ietfa.amsl.com (Postfix) with ESMTP id 16A0121F8B2A for ; Thu, 10 Nov 2011 07:49:48 -0800 (PST) Received: from /spool/local by e8.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 10 Nov 2011 10:49:47 -0500 Received: from d01relay03.pok.ibm.com ([9.56.227.235]) by e8.ny.us.ibm.com ([192.168.1.108]) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Thu, 10 Nov 2011 10:49:45 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pAAFniJO269046; Thu, 10 Nov 2011 10:49:44 -0500 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pAAFneMY021246; Thu, 10 Nov 2011 08:49:41 -0700 Received: from cichlid.raleigh.ibm.com (sig-9-65-211-231.mts.ibm.com [9.65.211.231]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id pAAFndTb021036 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Nov 2011 08:49:40 -0700 Received: from cichlid.raleigh.ibm.com (cichlid.raleigh.ibm.com [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.4/8.12.5) with ESMTP id pAAFnajV013933; Thu, 10 Nov 2011 10:49:37 -0500 Message-Id: <201111101549.pAAFnajV013933@cichlid.raleigh.ibm.com> To: Pedro Marques Subject: Re: Need your action to review draft-ietf-armd-problem-statement-00.txt In-reply-to: References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120BEC36@dfweml506-mbx> Comments: In-reply-to Pedro Marques message dated "Wed, 09 Nov 2011 14:20:53 -0800." Date: Thu, 10 Nov 2011 10:49:36 -0500 From: Thomas Narten x-cbid: 11111015-9360-0000-0000-0000007CF0E1 Cc: "l2vpn@ietf.org" , "sdnp@lucidvision.com" , "armd@ietf.org" , L3VPN WG mailing list X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 15:49:49 -0000 Hi Pedro. > The draft is a bit unclear in terms of its assumptions regarding the > connectivity of the VMs. It does state that the VMs typically have > their own IP and mac addresses but doesn't mention that these are > typically also associated with different VLANs. Fair enough. I'll look at clarifying this in the next version (though I'm not sure right off how it changes anything). > There are multiple proposals (e.g. VXLAN) in which these VLANs are > data-center wide. Thus if the VM sees a LAN adjacency to its "subnet" > there is an ARP/ND issue to solve. VXLAN for instance assumes that ARP > requests will be broadcasted using IP multicast groups per VLAN. I don't think it is quite right to say that VXLAN uses "data center wide VLANs". VXLAN (and overlay approaches in general) use their own instance identifier space. It is conceptually like a VLAN (in that it groups together related servers). But it is not the same as a VLAN, and using that terminology in the context of VXLAN is probably going to confuse folk. > You may want to characterize the several 'categories' of proposals > that satisfy the requirements of VM mobility and closed user group > isolation. > For example: > L2 approaches: (e.g. VXLAN) > These tend towards creating a data-center wide broadcast domain. The > broadcast domain can then be used to send ARP/ND requests. Correct. But there are also optimizations that can be done (like Proxy ARP) to limit the need to actually broadcast. > Routed L2/L3 approaches (e.g. EVPN): > Present an L2 interface to the VM but transform it to a routed > approach in a network element and advertise mac (optionally) + ip host > prefixes from the network elements. An important sub category here is > whether these solutions then assume multicast capability or not in the > underlying network. And how is VXLAN not a routed approach? It presents an L2 interface to the VM, but everything is routed at L3 from the switch on out. The main differences I see between EVPN and overlay approachs like VXLAN are: 1) VXLAN goes all the way to the hypervisor. It's only the VM->Hypervisor "link" that is L2. 2) VXLAN uses a different control plane (e.g., IEEE 802 approach) whereas EVPN appears to be BGP based. > Host based approaches. > These can present either an L2 or L3 "service" and assume or not the > presence of an underlying multicast service on the part of the > underlying "fabric" network. Not sure what you mean here. Is this where the Host (VM) itself is aware of the service and interacts directly with it? And wouldn't that require host changes, which IMO is pretty much a non-starter? > Map service based approaches: > Use a query based mechanism rather than a "push" based mechanism > like routing to distributed the overlay network information. > Each of these has its own way to address ARP/ND related issues. If you > your intent is to document the possibilities there is plenty of > options to choose from. :-) Indeed! Thomas From pedro.r.marques@gmail.com Thu Nov 10 08:59:39 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1805621F8AE6; Thu, 10 Nov 2011 08:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.964 X-Spam-Level: X-Spam-Status: No, score=-2.964 tagged_above=-999 required=5 tests=[AWL=0.635, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94guZtq+udAm; Thu, 10 Nov 2011 08:59:38 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABED21F8B30; Thu, 10 Nov 2011 08:59:37 -0800 (PST) Received: by iaeo4 with SMTP id o4so4079457iae.31 for ; Thu, 10 Nov 2011 08:59:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LU8FDDxDJ46LSZ4l5YTLLqvBzdTycUTucfP/wNvyHz0=; b=pd8QEP0XKG+x1SKbqvh95zxTV31M/PkgAVyDzq+j3sBC3UzxptgmdooDGdAGjH5rB+ kOdHosQNrm4F9//e9mf8hJ3q/KUOSUN5CTru8485wDg+jPGykvYYywepO04gGu+juijL CQc6O4L/gu9ORpgCkiObVcRNPOpn9jI5PmEjs= MIME-Version: 1.0 Received: by 10.231.84.135 with SMTP id j7mr1996731ibl.81.1320944377485; Thu, 10 Nov 2011 08:59:37 -0800 (PST) Received: by 10.231.12.2 with HTTP; Thu, 10 Nov 2011 08:59:37 -0800 (PST) In-Reply-To: <201111101549.pAAFnajV013933@cichlid.raleigh.ibm.com> References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120BEC36@dfweml506-mbx> <201111101549.pAAFnajV013933@cichlid.raleigh.ibm.com> Date: Thu, 10 Nov 2011 08:59:37 -0800 Message-ID: Subject: Re: Need your action to review draft-ietf-armd-problem-statement-00.txt From: Pedro Marques To: Thomas Narten Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 10 Nov 2011 09:05:00 -0800 Cc: "l2vpn@ietf.org" , "sdnp@lucidvision.com" , "armd@ietf.org" , L3VPN WG mailing list X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Nov 2011 16:59:39 -0000 Thomas, On Thu, Nov 10, 2011 at 7:49 AM, Thomas Narten wrote: >> There are multiple proposals (e.g. VXLAN) in which these VLANs are >> data-center wide. Thus if the VM sees a LAN adjacency to its "subnet" >> there is an ARP/ND issue to solve. VXLAN for instance assumes that ARP >> requests will be broadcasted using IP multicast groups per VLAN. > > I don't think it is quite right to say that VXLAN uses "data center > wide VLANs". =A0VXLAN (and overlay approaches in general) use their own > instance identifier space. It is conceptually like a VLAN (in that it > groups together related servers). But it is not the same as a VLAN, > and using that terminology in the context of VXLAN is probably going > to confuse folk. The proposal uses a data-center wide broadcast domain. In common terminology people often refer to a broadcast domain as a VLAN. > >> You may want to characterize the several 'categories' of proposals >> that satisfy the requirements of VM mobility and closed user group >> isolation. > >> For example: > >> L2 approaches: (e.g. VXLAN) >> =A0 These tend towards creating a data-center wide broadcast domain. The >> broadcast domain can then be used to send ARP/ND requests. > > Correct. But there are also optimizations that can be done (like Proxy > ARP) to limit the need to actually broadcast. It depends on what action is taken when a VM moves. In what i'm labeling as an "L2 based" approach a VM move is handled by generating a gratuitous ARP reply to update all ARP caches and learning tables. If that is the VM move update mechanism proxy ARP cannot be used. > >> Routed L2/L3 approaches (e.g. EVPN): > >> =A0 Present an L2 interface to the VM but transform it to a routed >> approach in a network element and advertise mac (optionally) + ip host >> prefixes from the network elements. An important sub category here is >> whether these solutions then assume multicast capability or not in the >> underlying network. > > And how is VXLAN not a routed approach? It presents an L2 interface to > the VM, but everything is routed at L3 from the switch on out. The addresses of the overlay network are learned by the egress switches and it depends on a broadcast domain. It sees the underlying "fabric" network as a LAN. This is in contrast with approach in which the information regarding the overlay network is advertised via routing protocols (your get your choice of ISIS variants and BGP). > > The main differences I see between EVPN and overlay approachs like > VXLAN are: > > 1) VXLAN goes all the way to the hypervisor. It's only the > VM->Hypervisor "link" that is L2. > > 2) VXLAN uses a different control plane (e.g., IEEE 802 approach) > whereas EVPN appears to be BGP based. VXLAN treats the underlying DC fabric network as a LAN. And uses learning on the data plane. EVPN only "learns" on the edge facing interface. This has consequences on VM moves for instance. In the second case the move can be done as a "route advertisement". It also has consequences on the operational state. With a learning based approach the actual state of the network is just valid at that precise moment. Which makes it very difficult to understand whether the state is correct or not. That is common with all data-driven approaches. > >> Host based approaches. >> =A0 These can present either an L2 or L3 "service" and assume or not the >> presence of an underlying multicast service on the part of the >> underlying "fabric" network. > > Not sure what you mean here. Is this where the Host (VM) itself is > aware of the service and interacts directly with it? And wouldn't that > require host changes, which IMO is pretty much a non-starter? The Host OS / hypervisor. Not the Guest VM. It is a common practice that the network stack of the host OS is a special purpose stack (e.g. vSwitch style approaches). The network stack is not the only aspect of the VM hosting software that is modified to support this class of applications. Pedro. From xuxiaohu@huawei.com Thu Nov 10 21:58:33 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 064EF1F0C35; Thu, 10 Nov 2011 21:58:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.816 X-Spam-Level: X-Spam-Status: No, score=-1.816 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-bu3csklYCL; Thu, 10 Nov 2011 21:58:31 -0800 (PST) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 9322E1F0C3D; Thu, 10 Nov 2011 21:58:30 -0800 (PST) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUH009ZHF9A9G@szxga05-in.huawei.com>; Fri, 11 Nov 2011 13:58:23 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUH008BDF9886@szxga05-in.huawei.com>; Fri, 11 Nov 2011 13:58:22 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AEY00476; Fri, 11 Nov 2011 13:58:18 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 11 Nov 2011 13:58:10 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0270.001; Fri, 11 Nov 2011 13:58:12 +0800 Date: Fri, 11 Nov 2011 05:58:12 +0000 From: Xuxiaohu Subject: re: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt In-reply-to: <60C093A41B5E45409A19D42CF7786DFD52261A095C@EUSAACMS0703.eamcs.ericsson.se> X-Originating-IP: [10.108.4.59] To: David Allan I , "Balus, Florin Stelian (Florin)" , "Bitar, Nabil N" , "l3vpn@ietf.org" , "l2vpn@ietf.org" Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74829E@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_dXVP9g843kwvwQT+ES1ekw)" Content-language: zh-CN Accept-Language: zh-CN, en-US Thread-topic: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-index: Acyd2R8rhSQNYlfHQ16DQ3Td7RyeUQAC+SpwABxhHfAACrvcUAAB0LLwAARv2GAAZvhIAA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74774D@szxeml525-mbs.china.huawei.com> <2073A6C5467C99478898544C6EBA3F4602BD5D2CF4@USNAVSXCHMBSC3.ndc.alcatel-lucent.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE747C3A@szxeml525-mbs.china.huawei.com> <60C093A41B5E45409A19D42CF7786DFD52261A095C@EUSAACMS0703.eamcs.ericsson.se> X-Mailman-Approved-At: Fri, 11 Nov 2011 02:47:27 -0800 Cc: Sagessi , "Luyuan Fang \(lufang\)" , "y.ikejiri@ntt.com" , "mircea.pisica@bt.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 05:58:33 -0000 --Boundary_(ID_dXVP9g843kwvwQT+ES1ekw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 DQpIaSBEYXZlLA0KDQpGaXJzdCwgdGhlIGVuZC1zeXN0ZW0gaGVyZSBtZWFucyB0aGUgcGh5c2lj YWwgc2VydmVycywgcmF0aGVyIHRoYW4gdGhlIFZNcy4gSW4gb3RoZXIgd29yZHMsIG5vIG9uZSBo YWQgc2FpZCBvbmUgQi1NQUMgY29ycmVzcG9uZHMgdG8gb25lIEMtTUFDLg0KU2Vjb25kLCB0aGUg Zm9yd2FyZGluZyB0YWJsZSBzY2FsYWJpbGl0eSBoZXJlIG1lYW5zIHRoZSBzd2l0Y2hlcyBiZWZv cmUgdGhlIFBCQiBlbmNhcHN1bGF0aW9uIGVudGl0aWVzIHdvdWxkIGhhdmUgdG8gbGVhcm4gQy1N QUMgYWRkcmVzc2VzIG9mIGFsbCBWTEFOcy4gVGhhdKGvcyB3aHkgUEJCIGRldmljZXMgc2hvdWxk IGJlIGRvbmUgYXQgdGhlIGxvY2F0aW9ucyBjbG9zZSB0byB0aGUgZW5kLXN5c3RlbXMsIHdoZXJl IHRoZSBzd2l0Y2hlcyBkbyBub3QgbmVlZCB0byBhdHRhY2ggYWxsIFZMQU5zLg0KDQpCZXN0IHJl Z2FyZHMsDQpYaWFvaHUNCg0Kt6K8/sjLOiBEYXZpZCBBbGxhbiBJIFttYWlsdG86ZGF2aWQuaS5h bGxhbkBlcmljc3Nvbi5jb21dDQq3osvNyrG85DogMjAxMcTqMTHUwjnI1SAyMzozMQ0KytW8/sjL OiBYdXhpYW9odTsgQmFsdXMsIEZsb3JpbiBTdGVsaWFuIChGbG9yaW4pOyBCaXRhciwgTmFiaWwg TjsgbDN2cG5AaWV0Zi5vcmc7IGwydnBuQGlldGYub3JnDQqzrcvNOiB5LmlrZWppcmlAbnR0LmNv bTsgTHV5dWFuIEZhbmcgKGx1ZmFuZyk7IFNhZ2Vzc2k7IG1pcmNlYS5waXNpY2FAYnQuY29tDQrW 98ziOiBSRTogWW91ciBpbnB1dCBvbiB0aGUgZm9sbG93aW5nIGRyYWZ0IGlzIGFwcHJlY2lhdGVk OiBkcmFmdC1iaXRhci1kYXRhY2VudGVyLXZwbi1hcHBsaWNhYmlsaXR5LTAxLnR4dA0KDQpIaSBY dXhhb2h1Og0KDQpJIHdvdWxkIG9iamVjdCB0byB5b3VyIHN1Z2dlc3Rpb24gb2YgImFzIGNsb3Nl IHRvIHRoZSBlbmQtc3lzdGVtcyBhcyBwb3NzaWJsZSIuIFBCQiBpcyBoaWVyYXJjaGljYWwgc3Vt bWFyaXphdGlvbiwgc28gdGhlIG51bWJlciBvZiBDLU1BQ3Mgc3VtbWFyaXplZCBmb3IgcmVhY2hh YmlsaXR5IHRvIEItTUFDcyBpcyBhIGZ1bmN0aW9uIG9mIGhvdyBjbG9zZSB0aGUgQkVCIGlzIHBs YWNlZCB0byB0aGUgZW5kIHN5c3RlbS4gSWYgaXQgaXMgImNvLWxvY2F0ZWQiIHdpdGggdGhlIGVu ZCBzeXN0ZW0gKGEuay5hIGFzIGNsb3NlIGFzIHBvc3NpYmxlKSB0aGVyZSBpcyBubyBzdW1tYXJp emF0aW9uLiAxICBCLU1BQyBjb3JyZXNwb25kcyB0byAxIEMtTUFDIGFuZCB0aGUgZW5jYXBzdWxh dGlvbiBhdCB0aGF0IHBvaW50IGlzIHNpbXBseSBhIGdyYXR1aXRvdXMgaW5jcmVhc2UgaW4gYmFu ZHdpZHRoIGNvbnN1bXB0aW9uLiBXaGljaCB0ZW5kcyB0byBzdWdnZXN0IHRoZXJlIGlzIGEgbmF0 dXJhbCBsb2NhdGlvbiBmb3IgcGxhY2VtZW50IG9mIHRoZSBCRUIgZnVuY3Rpb24gd2hpY2ggcGVy bWl0cyBzb21lIG9yZGVycyBvZiBtYWduaXR1ZGUgc3RhdGUgaW1wcm92ZW1lbnQgaW4gdGhlIGNv cmUgc3dpdGNoZXMuDQoNClNpbWlsYXJseSAsIGJvdGggUEJCIGFuZCBTUEJNIGJvdW5kIHRoZSBi cm9hZGNhc3QgZG9tYWlucyBmb3IgYSBjdXN0b21lciBWTEFOIHRvIHRoZSBjb21tdW5pdHkgb2Yg aW50ZXJlc3Qgd2l0aG91dCBzaW1wbHkgZW1wbG95aW5nIHRoZSByYXRoZXIgd2FzdGVmdWwgImVn cmVzcyBkaXNjYXJkIiwgc28gdGhlIHBlcmlvZGljIGZsb29kaW5nIG9mIHVua25vd25zIElNTyBp cyBub3QgdGhlIGlzc3VlIHlvdSB0aGluayBpdCBpcy4gU2ltaWxhcmx5IGl0IGlzIHVucmVsYXRl ZCB0byBob3cgY2xvc2UgdGhlIEJFQiBpcyBwbGFjZWQgdG8gdGhlIFZNLiBGbG9vZGluZyBpcyBl aXRoZXIgYm91bmRlZCBieSBTLXRhZyBvciBib3VuZGVkIGJ5IHBlciBJLVNJRCBtdWx0aWNhc3Qg dHJlZXMuIFNvIEknbSBub3Qgc3VyZSB3aGF0IHlvdSBtZWFuIGJ5IHRoZSAidW5rbm93biB1bmlj YXN0IGZsb29kIGltcGFjdCBpc3N1ZSIsIGxvY2F0aW9uIG9mIHRoZSBCRUIgZG9lcyBub3QgY29u ZmxhdGUgdW5rbm93biBmbG9vZGluZy4NCg0KVG8gc3VtbWFyaXplLCBJJ20gbm90IHVuZGVyc3Rh bmRpbmcgeW91ciBwb3N0IGFuZCBhbSBzZWVraW5nIGNsYXJpZmljYXRpb24NCg0KdGhhbmtzDQpE YXZlDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogbDJ2cG4t Ym91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBYdXhpYW9odQ0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMDgsIDIwMTEgNjo1MSBQTQ0K VG86IFh1eGlhb2h1OyBCYWx1cywgRmxvcmluIFN0ZWxpYW4gKEZsb3Jpbik7IEJpdGFyLCBOYWJp bCBOOyBsM3ZwbkBpZXRmLm9yZzsgbDJ2cG5AaWV0Zi5vcmcNCkNjOiB5LmlrZWppcmlAbnR0LmNv bTsgTHV5dWFuIEZhbmcgKGx1ZmFuZyk7IFNhZ2Vzc2k7IG1pcmNlYS5waXNpY2FAYnQuY29tDQpT dWJqZWN0OiByZTogWW91ciBpbnB1dCBvbiB0aGUgZm9sbG93aW5nIGRyYWZ0IGlzIGFwcHJlY2lh dGVkOiBkcmFmdC1iaXRhci1kYXRhY2VudGVyLXZwbi1hcHBsaWNhYmlsaXR5LTAxLnR4dA0KQnkg dGhlIHdheSwgaXQgd291bGQgYmUgYmV0dGVyIHRvIHB1c2ggdGhlIFBCQiBhcyBjbG9zZSB0byB0 aGUgZW5kLXN5c3RlbXMgYXMgcG9zc2libGUgZnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgTUFDIGZv cndhcmRpbmcgdGFibGUgc2NhbGFiaWxpdHkuIEhvd2V2ZXIsIHRoZSB1bmtub3duIHVuaWNhc3Qg Zmxvb2QgaW1wYWN0IGlzc3VlIHdvdWxkIGJlIHdvcnNlbiBhY2NvcmRpbmdseS4gRm9yIGV4YW1w bGUsIGluIGEgbm9ybWFsIExheWVyMiBuZXR3b3JrLCBpZiB0d28gVk1zIGF0dGFjaGVkIHRvIHRo ZSBnaXZlbiBUb1IgYXJlIGZyZXF1ZW50bHkgY29tbXVuaWNhdGVkIHdpdGggZWFjaCBvdGhlciBh bmQgaGVuY2UgdGhlaXIgTUFDIGFkZHJlc3MgZW50cmllcyBvbiB0aGlzIFRvUiB3aWxsIG5vdCBi ZSBleHBpcmVkLCB0aGUgdHJhZmZpYyBkZXN0aW5lZCBmb3IgYW55IG9mIHRob3NlIHR3byBWTXMg ZnJvbSBhIHJlbW90ZSBWTSBjb3VsZCBiZSBmbG9vZGVkIGFzIHVua25vd24gdW5pY2FzdCB1bnRp bCB0aGUgdHJhZmZpYyByZWFjaCB0aGlzIFRvUiB3aGljaCBpbiB0dXJuIGZvcndhcmQgdGhlIHRy YWZmaWMgdG8gdGhlIGRlc3RpbmF0aW9uIFZNIGluIHVuaWNhc3QuICBIb3dldmVyLCBvbmNlIFBC QiBpcyBwZXJmb3JtZWQgYXQgZWFjaCBWU3csIHRoYXQgdHJhZmZpYyB3b3VsZCBiZSBmbG9vZGVk IHVudGlsIGl0IHJlYWNoIHRoZSBmaW5hbCBkZXN0aW5hdGlvbiBwaHlzaWNhbCBzZXJ2ZXIuICBJ dKGvcyBhIGhhcmQgdHJhZGVvZmYsIGlzbqGvdCBpdD8NCg0KWGlhb2h1DQoNCg0Kt6K8/sjLOiBY dXhpYW9odQ0Kt6LLzcqxvOQ6IDIwMTHE6jEx1MI5yNUgMTA6MDgNCsrVvP7IyzogJ0JhbHVzLCBG bG9yaW4gU3RlbGlhbiAoRmxvcmluKSc7IEJpdGFyLCBOYWJpbCBOOyBsM3ZwbkBpZXRmLm9yZzsg bDJ2cG5AaWV0Zi5vcmcNCrOty806IEx1eXVhbiBGYW5nIChsdWZhbmcpOyBTYWdlc3NpOyB5Lmlr ZWppcmlAbnR0LmNvbTsgbWlyY2VhLnBpc2ljYUBidC5jb20NCtb3zOI6IHJlOiBZb3VyIGlucHV0 IG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQgaXMgYXBwcmVjaWF0ZWQ6IGRyYWZ0LWJpdGFyLWRhdGFj ZW50ZXItdnBuLWFwcGxpY2FiaWxpdHktMDEudHh0DQoNCreivP7IyzogQmFsdXMsIEZsb3JpbiBT dGVsaWFuIChGbG9yaW4pIFttYWlsdG86ZmxvcmluLmJhbHVzQGFsY2F0ZWwtbHVjZW50LmNvbV0N Creiy83KsbzkOiAyMDExxOoxMdTCOcjVIDU6MzQNCsrVvP7IyzogWHV4aWFvaHU7IEJpdGFyLCBO YWJpbCBOOyBsM3ZwbkBpZXRmLm9yZzsgbDJ2cG5AaWV0Zi5vcmcNCrOty806IEx1eXVhbiBGYW5n IChsdWZhbmcpOyBTYWdlc3NpOyB5LmlrZWppcmlAbnR0LmNvbTsgbWlyY2VhLnBpc2ljYUBidC5j b20NCtb3zOI6IFJFOiBZb3VyIGlucHV0IG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQgaXMgYXBwcmVj aWF0ZWQ6IGRyYWZ0LWJpdGFyLWRhdGFjZW50ZXItdnBuLWFwcGxpY2FiaWxpdHktMDEudHh0DQoN ClRoYW5rcyBmb3IgdGhlIGNvbW1lbnRzLCBzZWUgaW4tbGluZaGtDQoNCkZyb206IGwydnBuLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpsMnZwbi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgWHV4aWFvaHUNClNlbnQ6IE1vbmRheSwgTm92ZW1iZXIgMDcsIDIwMTEgMTE6NTMgUE0NClRv OiBCaXRhciwgTmFiaWwgTjsgbDN2cG5AaWV0Zi5vcmc7IGwydnBuQGlldGYub3JnDQpDYzogTHV5 dWFuIEZhbmcgKGx1ZmFuZyk7IFNhZ2Vzc2k7IHkuaWtlamlyaUBudHQuY29tOyBtaXJjZWEucGlz aWNhQGJ0LmNvbQ0KU3ViamVjdDogcmU6IFlvdXIgaW5wdXQgb24gdGhlIGZvbGxvd2luZyBkcmFm dCBpcyBhcHByZWNpYXRlZDogZHJhZnQtYml0YXItZGF0YWNlbnRlci12cG4tYXBwbGljYWJpbGl0 eS0wMS50eHQNCg0KSGkgTmFiaWwsDQoNCkl0oa9zIGEgdmVyeSBjb21wcmVoZW5zaXZlIGRvYy4N Cg0KU29tZSBjb21tb25zOg0KDQoxoaIgIEluIHNlY3Rpb24gNi4xLCBpdCBzYWlkOiChsEFzIHRo ZSBudW1iZXIgb2YgdGVuYW50cyBpbiBpbmRpdmlkdWFsIFZMQU4gaXNsYW5kcyBzdXJwYXNzZXMg NEssIHRoZSBvcGVyYXRvciBjb3VsZCBwdXNoIFZQTFMgZGVwbG95bWVudCBkZWVwZXIgaW4gdGhl IERDIG5ldHdvcmuhrS4gVGhlIFRvUiBhbmQgREMgY29yZSBlbGVtZW50cyBuZWVkIHRvIGJlIE1Q TFMgZW5hYmxlZCB3aXRoIGV4aXN0aW5nIFZQTFMgc29sdXRpb25zobEsIElNSE8sIERDIGNvcmUg c3dpdGNoZXMgZG9uoa90IG5lZWQgdG8gYmUgTVBMUyBlbmFibGVkIHNpbmNlIElQIGJhc2VkIHR1 bm5lbCBpcyBhbHNvIGF2YWlsYWJsZS4NCg0KDQoNCkZCPiBZb3UgYXJlIHJpZ2h0IHdlIHNob3Vs ZCBoYXZlIHNhaWQgobBJUCBvciBNUExTIGVuYWJsZWShsSBhcyBib3RoIGNhc2VzIGFyZSBwb3Nz aWJsZaGtDQoNCg0KDQo8WFhIPiBHb29kIHBvaW50Lg0KDQoNCg0KMqGiICBTdGlsbCBpbiBzZWN0 aW9uIDYuMSwgaXQgc2FpZDogobEgoa1Ib3dldmVyLCB0aGlzIG1vZGVsIGRvZXMgbm90IHNvbHZl IHRoZSBNQUMgZXhwbG9zaW9uIGlzc3VlIGFzIFRvUnMgc3RpbGwgbmVlZCB0byBsZWFybiBWTSBN QUMgYWRkcmVzc2VzLqGxIEhvd2V2ZXIsIGluIHNlY3Rpb24gNi4yLjEsIGl0IHNhaWQ6obGhrUFs dGVybmF0aXZlbHksIHRoZSBQQkIgZW5jYXBzdWxhdGlvbiBjYW4gYmUgZG9uZSBhdCB0aGUgVG9S LqGxICBJdCBpcyBjb25mdXNlZCBzaW5jZSBwZXJmb3JtaW5nIFBCQiBlbmNhcHN1bGF0aW9uIGF0 IHRoZSBUb1Igd291bGQgbm90IGFsbGV2aWF0ZSB0aGUgTUFDLWxlYXJuaW5nIGJ1cmRlbiBvbiB0 aGF0IFRvUi4NCg0KDQoNCkZCPiBNYXliZSB0aGUgcGhyYXNlIGxvY2F0aW9uIGlzIHB1enpsaW5n LiBUaGUgZm9jdXMgb2Ygc2VjdGlvbiA2LjIgaXMgdGhlIHVzZSBvZiBhbiBleHRlbmRlZCAyNGIg UEJCIEktSVNJRCB0YWcgc3RhcnRpbmcgYXQgdGhlIFZTdyB0byBpZGVudGlmeSB0aGUgRUxBTiBi cm9hZGNhc3QgZG9tYWluLg0KDQoNCg0KPFhYSD4gVGhlIHRpdGxlIG9mIHNlY3Rpb24gNi4yLjEg aXMgobBBZGRyZXNzaW5nIFZMQU4gc3BhY2UgZXhoYXVzdGlvbiBhbmQgTUFDIGV4cGxvc2lvbqGx LiBTbyBJIHRoaW5rIHNheWluZyBtb3JlIHdvcmRzIGFmdGVyIHRoYXQgc2VudGVuY2UgaXMgbXVj aCBoZWxwZnVsIGluIGF2b2lkaW5nIGNvbmZ1c2lvbi4NCg0KDQoNCg0KDQpUaGlzIHdpbGwgbWF4 aW1pemUgdGhlIGJlbmVmaXRzLiBIb3dldmVyIGluIHJlYWxpdHkgaXQgaXMgdmVyeSBsaWtlbHkg dGhlcmUgd2lsbCBiZSBsZWdhY3kgREMgcmVnaW9ucyBzdGlsbCBydW5uaW5nIFZMQU5zIHdoaWNo IHJlcXVpcmUgYSBHYXRld2F5IGZ1bmN0aW9uIGR1cmluZyB0aGUgbWlncmF0aW9uLiBTZWUgdGhl IFZMQU4gSW50ZXJvcCBkaXNjdXNzaW9uIGluIHNlY3Rpb24gNi4yLjkuDQoNCg0KDQozoaIgIElu IDYuMi42LjIuIFBCQk4gaW4gVlN3LCBMMlZQTiBpbiB0aGUgVG9SLCBpdCBzYWlkOqGxIFRoZSBw cm9jZWR1cmVzIGZyb20gdGhlIHByZXZpb3VzIHNlY3Rpb24gYXJlIHVzZWQgYXQgdGhlIFZTdzog UEJCIGVuY2Fwc3VsYXRpb24gYW5kIEV0aGVybmV0IEJWTEFOcyBjYW4gYmUgdXNlZCBvbiB0aGUg VlN3IHVwbGluay4gTDJWUE4gaW5mcmFzdHJ1Y3R1cmUgaXMgcmVwbGFjaW5nIHRoZSBCVkxBTiBh dCB0aGUgVG9SIGVuYWJsaW5nIHRoZSB1c2Ugb2YgSVAgKEdSRSBvciBMMlRQKSBvciBNUExTIHR1 bm5lbGluZy4NCg0KDQoNCkZCPiBUaGlzIGlzIGFib3V0IHRoZSB0dW5uZWxpbmcgZW5jYXBzdWxh dGlvbiBvcHRpb25zIHRvIGJlIHVzZWQgaW4gdGhlIGNvcmU6IDI0YiBJLVNJRCB0YWcgaXMgdGhl IGNvbW1vbiB0ZW5hbnQgSUQgd2hpY2ggY2FuIGJlIHRyYW5zcG9ydGVkIG92ZXIgYW4gRXRoZXJu ZXQgb3IgYW4gSVAgb3IgYW4gTVBMUyBiYXNlZCBEQyBuZXR3b3JrLiBDb21iaW5hdGlvbnMgb2Yg dGhlc2UgdHVubmVsaW5nIG9wdGlvbnMgYXJlIGFsc28gcG9zc2libGU6IGUuZy4gb25lIERDIG1h eSBiZSBFdGhlcm5ldCBiYXNlZCB0aGUgb3RoZXIgSVAgYmFzZWQ7IG9yIHRoZSBWU3cgbWF5IHVz ZSBFdGhlcm5ldCBWTEFOIHR1bm5lbHMgd2hpbGUgSVAgdHVubmVscyBtYXkgc3RhcnQgYXQgdGhl IFRvUi4NCg0KDQoNCjxYWEg+IFllcywgSSBhZ3JlZSB3aXRoIHlvdXIgc3RhdGVtZW50IGFib3Zl LiBBZGRpbmcgdGhlIGFib3ZlIHRleHQgaW50byB0aGUgZHJhZnQgd291bGQgYmUgbXVjaCBoZWxw ZnVsOikNCg0KDQoNCiBMMiBuZXR3b3JraW5nIHN0aWxsIGhhcyB0aGUgc2FtZSBjb250cm9sIHBs YW5lIGNob2ljZXM6IElTLUlTIFs4MDIuMWFxXSBhbmQvb3IgQkdQIFtQQkItRVZQTl0sIGluZGVw ZW5kZW50bHkgZnJvbSB0aGUgdHVubmVsaW5nIGNob2ljZS6hsSBTaW5jZSBQQkIgZW5jYXBzdWxh dGlvbiBoYXMgYWxyZWFkeSBiZWVuIGRvbmUgb24gdGhlIFZTdywgd2h5IGRvIHdlIHN0aWxsIG5l ZWQgdG8gcnVuIDgwMi4xYXEgYW5kIFBCQi1FVlBOIHdpdGggYW5vdGhlciBQQkIgZW5jYXBzdWxh dGlvbiBsYXllcj8NCg0KDQoNCkZCPiBObyBuZWVkIGZvciBhbiBhZGRpdGlvbmFsIFBCQiBlbmNh cHN1bGF0aW9uIGxheWVyISBUaGlzIGlzIHN0cmljdGx5IGFib3V0IGNvbnRyb2wgcGxhbmUgb3B0 aW9uczogSVMtSVMgYW5kIEJHUCBhcmUgdXNlZCB0aGUgc2FtZSB3YXkgYXMgaW4gcmVndWxhciBJ UCByb3V0aW5nIHRvIHBlcmZvcm0gTXVsdGlwYXRoaW5nLCBGYXN0IENvbnZlcmdlbmNlLCBzZXJ2 aWNlIEFELCBwcm9ncmFtIHRoZSBjb3JlIEZJQnMgZXRjoa0NCg0KDQoNCjxYWEg+IEFic29sdXRl bHkgYWdyZWUuIFN1Y2ggYmVpbmcgdGhlIGNhc2UsIHdoeSBub3QgcmVtb3ZlIHRoZSB0d28gc3Bl Y2lmaWMgZXhhbXBsZXMgKGJvdGggb2YgdGhlbSBhZGQgYW5vdGhlciBQQkIgbGF5ZXIpIGZyb20g dGhhdCBzZW50ZW5jZSBzbyBhcyB0byBlbGltaW5hdGUgdGhlIHBvc3NpYmxlIGNvbmZ1c2lvbj8N Cg0KDQoNCiBDYW6hr3Qgd2Ugc2ltcGx5IHVzZSBhbnkgTDJWUE4gdGVjaG5vbG9neSwgZS5nLiwg VlBMUy4gSW4gYWRkaXRpb24sIG5vdGUgdGhhdCBpbiBGaWd1cmUgNSwgaXQgc2FpZCChsGludHJh LURDIEwyVlBOIG92ZXIgSVAgb3IgTVBMUyB0dW5uZWxpbmehsS4NCg0KDQpGQj4geWVzIHlvdSBj YW4uIFdlIGp1c3QgZm9jdXNlZCBoZXJlIG9uIHRoZSBvcHRpb25zIHRoYXQgd2lsbCBhZGRyZXNz IHRoZSBjaGFsbGVuZ2VzIGRlc2NyaWJlZCBpbiB0aGUgcHJvYmxlbSBzdGF0ZW1lbnQgc2VjdGlv bi4gT3RoZXJ3aXNlIHRoZSBjb250ZW50IHdpbGwgaGF2ZSBncm93biB0b28gbXVjaC4NCg0KPFhY SD4gVGhhbmtzIGZvciB5b3VyIGV4cGxhbmF0aW9uLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUN Cg0Kt6K8/sjLOiBsMnZwbi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bDJ2cG4tYm91bmNlc0Bp ZXRmLm9yZ10gtPqx7SBCaXRhciwgTmFiaWwgTg0Kt6LLzcqxvOQ6IDIwMTHE6jEx1MI4yNUgMTM6 NDINCsrVvP7IyzogbDN2cG5AaWV0Zi5vcmc7IGwydnBuQGlldGYub3JnDQqzrcvNOiBTYWdlc3Np OyBtaXJjZWEucGlzaWNhQGJ0LmNvbTsgTHV5dWFuIEZhbmcgKGx1ZmFuZyk7IHkuaWtlamlyaUBu dHQuY29tDQrW98ziOiBZb3VyIGlucHV0IG9uIHRoZSBmb2xsb3dpbmcgZHJhZnQgaXMgYXBwcmVj aWF0ZWQ6IGRyYWZ0LWJpdGFyLWRhdGFjZW50ZXItdnBuLWFwcGxpY2FiaWxpdHktMDEudHh0DQoN CkhpLA0KV2UgaGFkIHN1Ym1pdHRlZCB0aGUgZm9sbG93aW5nIGRyYWZ0IG9uIHZwbiBhcHBsaWNh YmlsaXR5IGZvciBkYXRhIGNlbnRlci4gWW91ciBpbnB1dCBvbiB0aGUgZHJhZnQgaXMgYXBwcmVj aWF0ZWQgaW4gbGlnaHQgb2Ygc29tZSBvZiB0aGUgb25nb2luZyBkaXNjdXNzaW9uLiBUaGUgZHJh ZnQgaXMgdGFyZ2V0ZWQgZm9yIGwzdnBuIGFuZCBsMnZwbi4NCkhlcmUgaXMgdGhlIGxpbms6DQoN Cmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWJpdGFyLWRhdGFjZW50ZXItdnBuLWFw cGxpY2FiaWxpdHktMDENCg0KDQpBYnN0cmFjdA0KDQoNCg0KICAgQ2xvdWQgQ29tcHV0aW5nIGhh cyBiZWVuIGF0dHJhY3RpbmcgYSBsb3Qgb2YgYXR0ZW50aW9uIGZyb20gdGhlDQoNCiAgIG5ldHdv cmtpbmcgaW5kdXN0cnkuIFNvbWUgb2YgdGhlIG1vc3QgcHVibGljaXplZCByZXF1aXJlbWVudHMg YXJlDQoNCiAgIHJlbGF0ZWQgdG8gdGhlIGV2b2x1dGlvbiBvZiB0aGUgQ2xvdWQgTmV0d29ya2lu ZyBJbmZyYXN0cnVjdHVyZSB0bw0KDQogICBhY2NvbW1vZGF0ZSBhIGxhcmdlIG51bWJlciBvZiB0 ZW5hbnRzLCBlZmZpY2llbnQgbmV0d29yayB1dGlsaXphdGlvbiwNCg0KICAgc2NhbGFibGUgbG9v cCBhdm9pZGFuY2UsIGFuZCBWaXJ0dWFsIE1hY2hpbmUgTW9iaWxpdHkuDQoNCg0KDQogICBUaGlz IGRyYWZ0IGRlc2NyaWJlcyBhIGZyYW1ld29yayBmb3IgY2xvdWQgbmV0d29ya2luZywgaGlnaGxp Z2h0aW5nDQoNCiAgIHRoZSBhcHBsaWNhYmlsaXR5IG9mIGV4aXN0aW5nIHdvcmsgaW4gdmFyaW91 cyBJRVRGIFdvcmtpbmcgR3JvdXBzDQoNCiAgIChlLmcuLCBSRkNzIGFuZCBkcmFmdHMgZGV2ZWxv cGVkIGluIElFVEYgTDJWUE4gYW5kIEwzVlBOIFdvcmtpbmcNCg0KICAgR3JvdXBzKSB0byBjbG91 ZCBuZXR3b3JraW5nLCBhbmQgdGhlIGdhcHMgYW5kIHByb2JsZW1zIHRoYXQgbmVlZCB0bw0KDQog ICBiZSBmdXJ0aGVyIGFkZHJlc3NlZC4gVGhhdCBpcywgdGhlIGdvYWwgaXMgdG8gdW5kZXJzdGFu ZCB3aGF0IG1heSBiZQ0KDQogICByZS11c2VkIGZyb20gdGhlIGN1cnJlbnQgcHJvdG9jb2xzIGFu ZCBjYWxsIG91dCByZXF1aXJlbWVudHMgc3BlY2lmaWMNCg0KICAgdG8gdGhlIENsb3VkIHNwYWNl IHRoYXQgbmVlZCB0byBiZSBhZGRyZXNzZWQgYnkgbmV3IHN0YW5kYXJkaXphdGlvbg0KDQogICB3 b3JrIHdpdGggcHJvcG9zZWQgc29sdXRpb25zIGluIGNlcnRhaW4gY2FzZXMuDQoNCg0KVGhhbmtz LA0KDQpOYWJpbA0K --Boundary_(ID_dXVP9g843kwvwQT+ES1ekw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: quoted-printable

 = ;

Hi Dave,

 = ;

First, the= end-system here means the physical servers, rather than the VMs. In other = words, no one had said one B-MAC corresponds to one C-MAC.

Second, th= e forwarding table scalability here means the switches before the PBB encap= sulation entities would have to learn C-MAC addresses of all VLANs. That=A1=AFs why PBB devices should be done at the locations close t= o the end-systems, where the switches do not need to attach all VLANs.

 = ;

Best regar= ds,

Xiaohu

 = ;

=B7=A2=BC=FE=C8=CB: David A= llan I [mailto:david.i.allan@ericsson.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C29=C8=D5 23:31
=CA=D5=BC=FE=C8=CB: Xuxiaohu; Balus, Florin Stelian (Florin); Bitar, Nabil N; l3vpn@iet= f.org; l2vpn@ietf.org
=B3=AD=CB=CD: y.ikejiri@ntt.com; Luyuan Fang (lufang); Sagessi; mircea.pisica@bt.com =D6=F7=CC=E2: RE: Your input on the following draft is appreciated: draft-bitar-datacen= ter-vpn-applicability-01.txt

 

Hi Xuxaohu:

 

I would object = to your suggestion of "as close to the end-systems as possible&qu= ot;. PBB is hierarchical summarization, so the number of C-MACs summarized for reachability to B-MACs is a function of how close the BEB is placed to= the end system. If it is "co-located" with the end system (a.k.a= as close as possible) there is no summarization. 1  B-MAC corresponds= to 1 C-MAC and the encapsulation at that point is simply a gratuitous increase in bandwidth consumption. Which tends to s= uggest there is a natural location for placement of the BEB function which = permits some orders of magnitude state improvement in the core switches. <= /span>

 

Similarly , bot= h PBB and SPBM bound the broadcast domains for a customer VLAN to the commu= nity of interest without simply employing the rather wasteful "egress discard", so the periodic flooding of unknowns IMO is no= t the issue you think it is. Similarly it is unrelated to how close th= e BEB is placed to the VM. Flooding is either bounded by S-tag or bounded b= y per I-SID multicast trees. So I'm not sure what you mean by the "unknown unicast flood impact issue", location o= f the BEB does not conflate unknown flooding.

 

To summarize, I= 'm not understanding your post and am seeking clarification 

 

thanks

Dave 

 

 

 

From: l2vpn-bounces@ietf.org= [mailto:l2vpn-bounces@ietf.org] On Behalf Of Xuxiaohu
Sent: Tuesday, November 08, 2011 6:51 PM
To: Xuxiaohu; Balus, Florin Stelian (Florin); Bitar, Nabil N; l3vpn@= ietf.org; l2vpn@ietf.org
Cc: y.ikejiri@ntt.com; Luyuan Fang (lufang); Sagessi; mircea.pisica@= bt.com
Subject: re: Your input on the following draft is appreciated: draft= -bitar-datacenter-vpn-applicability-01.txt

By the way= , it would be better to push the PBB as close to the end-systems as possibl= e from the perspective of MAC forwarding table scalability. However, the unknown unicast flood impact issue would be worsen accordingl= y. For example, in a normal Layer2 network, if two VMs attached to the give= n ToR are frequently communicated with each other and hence their MAC addre= ss entries on this ToR will not be expired, the traffic destined for any of those two VMs from a remote VM= could be flooded as unknown unicast until the traffic reach this ToR which= in turn forward the traffic to the destination VM in unicast.  Howeve= r, once PBB is performed at each VSw, that traffic would be flooded until it reach the final destination physica= l server.  It=A1=AFs a hard tradeoff, isn=A1=AFt it?=

 = ;

Xiaohu

 = ;

 = ;

=B7=A2=BC=FE=C8=CB: Xuxiaoh= u
=B7=A2= =CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C29=C8=D5 10:08
=CA=D5=BC=FE=C8=CB: 'Balus, Florin Stelian (Florin)'; Bitar, Nabil N; l3vpn@ietf.org; l= 2vpn@ietf.org
=B3=AD=CB=CD: Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com; mircea.pisica@bt.com =D6=F7=CC=E2: re: Your input on the following draft is appreciated: draft-bitar-datacen= ter-vpn-applicability-01.txt

 

=B7=A2=BC=FE=C8=CB: Balus, = Florin Stelian (Florin) [mailto:florin.balus@alcatel-lucent.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C29=C8=D5 5:34
=CA=D5=BC=FE=C8=CB: Xuxiaohu; Bitar, Nabil N; l3vpn@ietf.org; l2vpn@ietf.org
=B3=AD=CB=CD: Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com; mircea.pisica@bt.com =D6=F7=CC=E2: RE: Your input on the following draft is appreciated: draft-bitar-datacen= ter-vpn-applicability-01.txt

 

Thank= s for the comments, see in-line=A1=AD

=  

From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org= ] On Behalf Of Xuxiaohu
Sent: Monday, November 07, 2011 11:53 PM
To: Bitar, Nabil N; l3vpn@ietf.org; l2vpn@ietf.org
Cc: Luyuan Fang (lufang); Sagessi; y.ikejiri@ntt.com; mircea.pisica@= bt.com
Subject: re: Your input on the following draft is appreciated: draft= -bitar-datacenter-vpn-applicability-01.txt

 

Hi Nabil,<= o:p>

 = ;

It=A1=AFs = a very comprehensive doc.

 = ;

Some commo= ns:

1=A1=A2  In section 6.1, it said: =A1=B0As the numbe=
r of tenants in individual VLAN islands surpasses 4K, the operator could pu=
sh VPLS deployment deeper in the DC network=A1=AD. The ToR and DC core elem=
ents need to be MPLS enabled with existing VPLS solutions=A1=B1, IMHO, DC c=
ore switches don=A1=AFt need to be MPLS enabled since IP based tunnel is al=
so available.
 
FB> You are right we should have said =A1=B0IP or MPLS enabled=
=A1=B1 as both cases are possible=A1=AD 
 
<XXH> Good point.
 
2=A1=A2  Still in section 6.1, it said: =A1=B1 =A1=
=ADHowever, this model does not solve the MAC explosion issue as ToRs still=
 need to learn VM MAC addresses.=A1=B1 However, in section 6.2.1, it said:=
=A1=B1=A1=ADAlternatively, the PBB encapsulation can be done at the ToR.=A1=
=B1  It is confused since performing PBB encapsulation at the ToR woul=
d not alleviate the MAC-learning burden on that ToR.

 


FB> Maybe the phrase location is puzzling. The focus of sectio=
n 6.2 is the use of an extended 24b PBB I-ISID tag starting at the VSw to i=
dentify the ELAN broadcast domain. 


 


<XXH> The title of section 6.2.1 is =A1=B0Addressing VLAN spac=
e exhaustion and MAC explosion=A1=B1. So I think saying more words after th=
at sentence is much helpful in avoiding confusion.


 


 


This will maximize the benefits. However in reality it is very li=
kely there will be legacy DC regions still running VLANs which require a Ga=
teway function during the migration. See the VLAN Interop discussion in sec=
tion 6.2.9. 


 


3=A1=A2  In 6.2.6.2.=
 PBBN in VSw, L2VPN in the ToR, it said:=A1=B1 The procedures from the previous secti=
on are used at the VSw: PBB encapsulation and Ethernet BVLANs can be used o=
n the VSw uplink. L2VPN infrastructure is replacing the BVLAN at the ToR en=
abling the use of IP (GRE or L2TP) or MPLS tunneling. 


 


FB> This is about the tunneling encapsulation options to be us=
ed in the core: 24b I-SID tag is the common tenant ID which can be transpor=
ted over an Ethernet or an IP or an MPLS based DC network. Combinations of =
these tunneling options are also possible: e.g. one DC may be Ethernet base=
d the other IP based; or the VSw may use Ethernet VLAN tunnels while IP tun=
nels may start at the ToR.


 


<XXH> Yes, I agree with your statement above. Adding the above=
 text into the draft would be much helpfulJ


 


 L2 networking still has the same control plane c=
hoices: IS-IS [802.1aq] and/or BGP [PBB-EVPN], independently from the tunne=
ling choice.=A1=B1 Since PBB encapsulation has already been done on the VSw=
, why do we still need to run 802.1aq and PBB-EVPN with another PBB encapsu=
lation layer?


 


FB> No need for an additional PBB encapsulation layer! This is=
 strictly about control plane options: IS-IS and BGP are used the same way =
as in regular IP routing to perform Multipathing, Fast Convergence, service=
 AD, program the core FIBs etc=A1=AD


 


<XXH> Absolutely agree. Such being the case, why not remove th=
e two specific examples (both of them add another PBB layer) from that sent=
ence so as to eliminate the possible confusion?


 


 Can=A1=AFt we simply use any L2VPN technology, e=
.g., VPLS. In addition, note that in Figure 5, it said =A1=B0intra-DC L2VPN=
 over IP or MPLS tunneling=A1=B1.


 =
;


FB> yes you can. We just focused here on th=
e options that will address the challenges described in the problem stateme=
nt section. Otherwise the content will have grown too much.


 =
;


<XXH>=
; Thanks for your explanation.


=
 


Best regar=
ds,


Xiaohu


 =
;








=B7=A2=BC=FE=C8=CB: l2vpn-b=
ounces@ietf.org [mailto:l2vpn-bounces@ietf.org]
=B4=FA=
=B1=ED Bitar, Nabil N

=B7=A2=
=CB=CD=CA=B1=BC=E4: 2011=C4=EA11=D4=C28=C8=D5
 13:42

=CA=D5=BC=FE=C8=CB: l3vpn@ietf.org; l2vpn@ietf.org

=B3=AD=CB=CD: Sagessi; mircea.pisica@bt.com; Luyuan Fang (lufang); y.ikejiri@ntt.com
=D6=F7=CC=E2: Your input on the following draft is appreciated: draft-bitar-datacenter-=
vpn-applicability-01.txt






 




Hi,






We had submi=
tted the following draft on vpn applicability for data center. Your input o=
n the draft is appreciated in light of some of the ongoing
 discussion. The draft is targeted for l3vpn and l2vpn.





Here is the =
link: 






 <=
/o:p>







 <=
/o:p>






Abstract

 


   Cloud Computing ha=
s been attracting a lot of attention from the


   networking industr=
y. Some of the most publicized requirements are


   related to the evo=
lution of the Cloud Networking Infrastructure to


   accommodate a larg=
e number of tenants, efficient network utilization,


   scalable loop avoi=
dance, and Virtual Machine Mobility.


 


   This draft describ=
es a framework for cloud networking, highlighting


   the applicability =
of existing work in various IETF Working Groups


   (e.g., RFCs and dr=
afts developed in IETF L2VPN and L3VPN Working


   Groups) to cloud n=
etworking, and the gaps and problems that need to


   be further address=
ed. That is, the goal is to understand what may be


   re-used from the c=
urrent protocols and call out requirements specific


   to the Cloud space=
 that need to be addressed by new standardization


   work with proposed=
 solutions in certain cases.





Thanks,


Nabil
--Boundary_(ID_dXVP9g843kwvwQT+ES1ekw)-- From nabil.n.bitar@verizon.com Sun Nov 13 17:20:02 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE58011E809F; Sun, 13 Nov 2011 17:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.929 X-Spam-Level: X-Spam-Status: No, score=-2.929 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dtTGxUaheZUw; Sun, 13 Nov 2011 17:20:01 -0800 (PST) Received: from fldsmtpe01.verizon.com (fldsmtpe01.verizon.com [140.108.26.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3A24621F877F; Sun, 13 Nov 2011 17:20:01 -0800 (PST) X-IronPort-Anti-Spam-Filtered: false Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by fldsmtpe01.verizon.com with ESMTP; 14 Nov 2011 01:20:00 +0000 From: "Bitar, Nabil N" To: Lucy yong , "Bitar, Nabil N" , "l3vpn@ietf.org" , "l2vpn@ietf.org" X-IronPort-AV: E=Sophos;i="4.69,504,1315180800"; d="scan'208,217";a="179278859" Received: from fldp1lumxc7hb03.verizon.com (HELO FLDP1LUMXC7HB03.us.one.verizon.com) ([166.68.75.86]) by fldsmtpi03.verizon.com with ESMTP; 14 Nov 2011 01:20:00 +0000 Received: from fldp1lumxc7v63.us.one.verizon.com ([169.254.3.102]) by FLDP1LUMXC7HB03.us.one.verizon.com ([166.68.75.86]) with mapi; Sun, 13 Nov 2011 20:20:00 -0500 Date: Sun, 13 Nov 2011 20:19:59 -0500 Subject: Re: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-Topic: Your input on the following draft is appreciated: draft-bitar-datacenter-vpn-applicability-01.txt Thread-Index: Acyia4brD/hAZroiQHC1PTxCHDHhsw== Message-ID: In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D118E00D4@dfweml506-mbx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.13.0.110805 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CADEF3C42D57Bnabilnbitarverizoncom_" MIME-Version: 1.0 Cc: "Luyuan Fang \(lufang\)" , Sagessi , "y.ikejiri@ntt.com" , "mircea.pisica@bt.com" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 01:20:02 -0000 --_000_CADEF3C42D57Bnabilnbitarverizoncom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Lucy, Thanks for the input/comments. Please, see inline. Thanks, Nabil From: Lucy yong > Date: Tue, 8 Nov 2011 12:39:52 -0500 To: "Bitar, Nabil N" >, "l3vpn@ietf.org" >, "l2vpn@ietf.org" > Cc: Sagessi >, "mircea.pisica@b= t.com" >, "Luyuan Fang (lufang)" >, "y.ikejiri@ntt.com" > Subject: RE: Your input on the following draft is appreciated: draft-bitar-= datacenter-vpn-applicability-01.txt Hi Nabil and other co-authors, First of all, this is a very good draft to gather DC problem statements and= explore VPN applicability for cloud networking. Good information for the = community. Thank you very much. Thanks Lucy. That is one of the purposes of the draft. Some comments: 1) The document has heavy amount portion to describe all different use= cases for PBB but few sentence for TRILL and L3VPN applicability in DC. Su= ggest to elaborate more on TRILL and L3VPN cases. Agree, it is more focused on PBB from layer2 aspect in addition to 802= .1aq in terms of the scenarios, but not neglecting TRILL as we state the ca= ses where TRILL also applies as it can be looked at as alternative to 802.1= aq/Qbp but and the co-authors will be adding more on that. L3VPN case is i= s in section 7. 2) It is very possible that DC use L2VPN and WAN use L3VPN. It is nic= e that document this applicability. These are documented in sections 3, 4, 5, and 7 in addition to some re= lated challenges that need to be addressed in section 8. In particular, we = talk about l3vpn within the data center, L3VPN starting at the DC GW with n= ative Ethernet in the lDC where a tenant is identfied by a layer2 service I= D that is used also as the interface to the tenant VRF at the DC GW. In add= ition, we discuss the different models where the WAN service provider and t= he DC provider are the same entities, and 2 different enetities (Ass) inter= connected via multi-AS backbone options A, B or C per RFC 4364. Finally, we= talk about the case of Integrated routing and bridging per tenant. 3) Provider DC and enterprise DC may implement different L2VPN or L3VP= N technologies, it is valuable to describe what kind of interworking scenar= ios is allowed or not allowed. I am not sure you can say "allowed" or "not allowed". The approach tha= t we took is to dsay: (1) what are the common practices, (2) what are the o= ptions, and (3) what are the tradeoffs among the different options. Best Regards, Lucy From: l2vpn-bounces@ietf.org [mailto:l2vpn-b= ounces@ietf.org] On Behalf Of Bitar, Nabil N Sent: Monday, November 07, 2011 11:42 PM To: l3vpn@ietf.org; l2vpn@ietf.org Cc: Sagessi; mircea.pisica@bt.com; Luyuan Fang= (lufang); y.ikejiri@ntt.com Subject: Your input on the following draft is appreciated: draft-bitar-data= center-vpn-applicability-01.txt Hi, We had submitted the following draft on vpn applicability for data center. = Your input on the draft is appreciated in light of some of the ongoing disc= ussion. The draft is targeted for l3vpn and l2vpn. Here is the link: http://tools.ietf.org/html/draft-bitar-datacenter-vpn-applicability-01 Abstract Cloud Computing has been attracting a lot of attention from the networking industry. Some of the most publicized requirements are related to the evolution of the Cloud Networking Infrastructure to accommodate a large number of tenants, efficient network utilization, scalable loop avoidance, and Virtual Machine Mobility. This draft describes a framework for cloud networking, highlighting the applicability of existing work in various IETF Working Groups (e.g., RFCs and drafts developed in IETF L2VPN and L3VPN Working Groups) to cloud networking, and the gaps and problems that need to be further addressed. That is, the goal is to understand what may be re-used from the current protocols and call out requirements specific to the Cloud space that need to be addressed by new standardization work with proposed solutions in certain cases. Thanks, Nabil --_000_CADEF3C42D57Bnabilnbitarverizoncom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Lucy,
Thank= s for the input/comments. Please, see inline.

Than= ks,
Nabil

<= div style=3D"font-family:Calibri; font-size:11pt; text-align:left; color:bl= ack; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: = 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; = BORDER-RIGHT: medium none; PADDING-TOP: 3pt">From: Lucy yong <lucy= .yong@huawei.com>
Date: = Tue, 8 Nov 2011 12:39:52 -0500
To: "Bitar, Nabil N" <n= abil.n.bitar@one.verizon.com>, "l3= vpn@ietf.org" <l3vpn@ietf.org&= gt;, "l2vpn@ietf.org" <l2vpn@ietf.org>
Cc: Sagessi <sajassi= @cisco.com>, "mircea.pisica@= bt.com" <mircea.pisica@bt.co= m>, "Luyuan Fang (lufang)" <l= ufang@cisco.com>, "y.ikejiri@nt= t.com" <y.ikejiri@ntt.com&g= t;
Subject: RE: Your input on t= he following draft is appreciated: draft-bitar-datacenter-vpn-applicability= -01.txt

Hi Nabil  and other co-authors,

 <= /p>

First of all, this is a very go= od draft to gather DC problem statements and explore VPN applicability for = cloud networking.  Good information for the community. Thank you very much.

<NB> Th= anks Lucy. That is one of the purposes of the draft.

 

Some comments:

=  

1)      The document has heavy= amount portion to describe all different use cases for PBB but few sentenc= e for TRILL and L3VPN applicability in DC. Suggest to elaborate more on TRILL and L3VPN cases.

<NB> Agree, it is more focused on PBB from layer2 aspect in= addition to 802.1aq in terms of the scenarios, but not neglecting TRILL as= we state the cases where TRILL also applies as it can be looked at as alte= rnative to 802.1aq/Qbp but  and the co-authors will be adding more on = that. L3VPN case is is in section 7. 

2)      It is very possible th= at DC use L2VPN and WAN use L3VPN.  It is nice that document this appl= icability.

<NB> These are doc= umented in sections 3, 4, 5, and 7 in addition to some related challenges t= hat need to be addressed in section 8. In particular, we talk about l3vpn w= ithin the data center, L3VPN starting at the DC GW with native Ethernet in = the lDC where a tenant is identfied by a layer2 service ID that is used als= o as the interface to the tenant VRF at the DC GW. In addition, we discuss = the different models where the WAN service provider and the DC provider are= the same entities, and 2 different enetities (Ass) interconnected via mult= i-AS backbone options A, B or C per RFC 4364. Finally, we talk about the ca= se of Integrated routing and bridging per tenant.

=

3)      Provider DC and enterp= rise DC may implement different L2VPN or L3VPN technologies, it is valuable= to describe what kind of interworking scenarios is allowed or not allowed.

<NB&= gt; I am not sure you can say "allowed" or "not allowed". The approach that= we took is to dsay: (1) what are the common practices, (2) what are the op= tions, and (3) what are the tradeoffs among the different options.

 

Best Regards,

<= span style=3D"font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibr= i, sans-serif; ">Lucy

 

 

 

<= /div>

http://tools.ietf.org/htm= l/draft-bitar-datacenter-vpn-applicability-01

 

Abstract
 
   Cloud Computing has been attracting a lot =
of attention from the
   network=
ing industry. Some of the most publicized requirements are
   related to the evolution of the Cloud Network=
ing Infrastructure to
   accommo=
date a large number of tenants, efficient network utilization,
   scalable loop avoidance, and Virtual Mach=
ine Mobility.
 
   This draft describes a framework for cloud network=
ing, highlighting
   the applica=
bility of existing work in various IETF Working Groups
   (e.g., RFCs and drafts developed in IETF L2VPN an=
d L3VPN Working
   Groups) to cl=
oud networking, and the gaps and problems that need to
   be further addressed. That is, the goal is to und=
erstand what may be
   re-used f=
rom the current protocols and call out requirements specific
   to the Cloud space that need to be addresse=
d by new standardization
   work=
 with proposed solutions in certain cases.

Thanks,<=
/o:p>
Nabil
=
--_000_CADEF3C42D57Bnabilnbitarverizoncom_-- From yakov@juniper.net Mon Nov 14 12:46:03 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8C01F0CE2; Mon, 14 Nov 2011 12:46:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.899 X-Spam-Level: X-Spam-Status: No, score=-105.899 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fF0u1QMKUvX8; Mon, 14 Nov 2011 12:46:02 -0800 (PST) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4681F0CD6; Mon, 14 Nov 2011 12:45:32 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTsF963T2URePAxuV5U/Y5Wq8bkaBAZfq@postini.com; Mon, 14 Nov 2011 12:46:02 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 14 Nov 2011 12:42:02 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id pAEKg1h21336; Mon, 14 Nov 2011 12:42:01 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201111142042.pAEKg1h21336@magenta.juniper.net> To: Linda Dunbar Subject: Re: Need your action to review draft-ietf-armd-problem-statement-00.txt In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6120BEC36@dfweml506-mbx> References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120BEC36@dfweml506-mbx> X-MH-In-Reply-To: Linda Dunbar message dated "Wed, 09 Nov 2011 20:12:08 +0000." MIME-Version: 1.0 Content-Type: text/plain; charset="x-unknown" Content-ID: <42954.1321303321.1@juniper.net> Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Nov 2011 12:42:01 -0800 From: Yakov Rekhter Cc: "l2vpn@ietf.org" , "sdnp@lucidvision.com" , L3VPN WG mailing list , "armd@ietf.org" , yakov@juniper.net, Pedro Marques X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 20:46:03 -0000 Linda, > Pedro, = > = > You are absolutely right that there is no ARP/ND scaling issue if > IP can be extended to hosts. Even if IP can be extended to Access > switches, there is not much ARP/ND issues. > = > The draft lists down several common data center network designs, > and states that some of the designs don't have ARP/ND scaling > issues (but may have other issues for data centers). > = > That is why I encourage people to read the draft and provides > comments. =46rom 4.2 of the draft: 4.2. Scenario 2: L3 Terminates at the Aggregation Switch In Scenario 2, the L3 network extends only to the aggregation switches (or perhaps to routers that connect to the aggregation switches). The aggregation switches (or the routers that connect to multiple aggregation switches) could terminate multiple distinct IP subnets (e.g., one per VLAN) or one large IP subnet. In order to let hosts belonging to different IP subnets be placed under any access switches, it is necessary for access switches to enable multiple VLANs and aggregation switches to enable some VLANs (or subnets) over many physical ports. This configuration breaks the confinement of the VLAN's broadcast domain and makes it equivalent to all the access switches being part of the same L2 broadcast domain (and IP subnet). Thus, this configuration allows VMs to be moved to servers connected to other access switches, but increases the size of the L2 broadcast domain, which can lead to difficulties outlined below. This is the scenario that is used to justify the need for large L2 domain. = The draft assumes that in order to move a given VM from one server to another, where these two servers are connected to different access switches, *all* the access switches must be configured with the VM's IP subnet, and thus *all* the access switches must be part of the VM's L2 broadcast domain. This is even if at any particular point in time the servers hosting all the VMs of that IP subnet are connected to only a subset of these switches. But is it truly necessary, or could the L2 broadcast domain span only the switches connected to the servers that presently host VMs of the IP subnet ? Moreover, even if all the access switches need to be part of the same L2 broadcast domain, the increase in the size of the L2 broadcast domain in the above scenario is caused by the access switches, not by the number of VMs per L2 domain. The difficulies mentioned in the last sentence of the quoted paragraph are due to ARP, but ARP is generated by VMs, not by the access switches. Given that, how the increase in the size of the L2 broadcast domain *due solely to the access switches*, could increase the amount of ARP traffic that routers have to process ? Yakov. > = > > -----Original Message----- > > From: Pedro Marques [mailto:pedro.r.marques@gmail.com] > > Sent: Wednesday, November 09, 2011 1:52 PM > > To: Linda Dunbar > > Cc: l2vpn@ietf.org; L3VPN WG mailing list; sdnp@lucidvision.com; > > armd@ietf.org > > Subject: Re: Need your action to review draft-ietf-armd-problem- > > statement-00.txt > > = > > Linda, > > I'd like to point out that the problem does not need to be solved if > > only IP connectivity is required. This I-D: > > http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 describes > > a solution in which address resolution is not required irrespective of > > the location of the traffic destination. Simply put, traffic can be > > routed at each hop. > > = > > As per previous threads in this list, the concept of subnet which is > > of no practical usefulness in this space. Since VMs can be randomly > distributed across the network the subnet does not provide any > > information aggregation value. Thus there is no need to do address > > resolution. > > = > > Pedro. > > = > > On Wed, Nov 9, 2011 at 11:31 AM, Linda Dunbar > > wrote: > > > For those of you who touch upon Data Center networking or server > > > virtualization, be it Overlay, VPN4DC, or Application/Software drive= n > > > Controller for Data Center, Address Resolution is something Data > > Center > > > Gateways =A0will encounter because hosts/applications in data center= s > > do > > > communicate with peers which are not in the same Overlay, outside th= e > > VPN > > > domain, or from general public. ARMD has published its WG problem > > statement > > > draft. Your comments and suggestions are appreciated (send to > > > armd@ietf.org). > > > > > > > > > > > > Thanks, Linda Dunbar > > > > > > > > > > > > --------------------------------------------------------------------= - > > -------------- > > > > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. This draft is a work item of the Address Resolution for > > Massive > > > numbers of hosts in the Data center Working Group of the IETF. > > > > > > > > > > > > =A0=A0=A0=A0=A0=A0=A0 Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : Problem = Statement for ARMD > > > > > > =A0=A0=A0=A0=A0=A0=A0 Author(s)=A0=A0=A0=A0=A0=A0 : Thomas Narten > > > > > > =A0=A0=A0=A0=A0=A0=A0 Filename=A0=A0=A0=A0=A0=A0=A0 : draft-ietf-arm= d-problem-statement-00.txt > > > > > > =A0=A0=A0=A0=A0=A0=A0 Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 11 > > > > > > =A0=A0=A0=A0=A0=A0=A0 Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2011-1= 0-17 > > > > > > > > > > > > =A0=A0 This document examines issues related to the massive scaling = of > > data > > > > > > =A0=A0 centers.=A0 Our initial scope is relatively narrow.=A0 Specif= ically, > > we > > > > > > =A0=A0 focus on address resolution (ARP and ND) within the data cent= er. > > > > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-armd-problem- > > statement-00.txt > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > > > This Internet-Draft can be retrieved at: > > > > > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-armd-problem-statement= - > > 00.txt > > > > > > > = From skh@ndzh.com Mon Nov 14 22:21:00 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F21A1F0CBB; Mon, 14 Nov 2011 22:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.618 X-Spam-Level: X-Spam-Status: No, score=0.618 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOsSRqIJe+tN; Mon, 14 Nov 2011 22:20:59 -0800 (PST) Received: from hickoryhill-consulting.com (63-208-161-201.digitalrealm.net [63.208.161.201]) by ietfa.amsl.com (Postfix) with ESMTP id E454D1F0C38; Mon, 14 Nov 2011 22:20:58 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=130.129.21.97; Received: from SKHPERSONALLT (unverified [130.129.21.97]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 2841903-1945496 for multiple; Tue, 15 Nov 2011 01:20:16 -0500 From: "Susan Hares" To: "'Yakov Rekhter'" , "'Linda Dunbar'" References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120BEC36@dfweml506-mbx> <201111142042.pAEKg1h21336@magenta.juniper.net> In-Reply-To: <201111142042.pAEKg1h21336@magenta.juniper.net> Subject: RE: [armd] Need your action to review draft-ietf-armd-problem-statement-00.txt Date: Tue, 15 Nov 2011 01:20:11 -0500 Message-ID: <011101cca35e$a93be5b0$fbb3b110$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyjMjzC4vOw03vySeSIsLrY/t0kawAIGRRw Content-language: en-us X-Authenticated-User: skh@ndzh.com X-Mailman-Approved-At: Mon, 14 Nov 2011 23:47:31 -0800 Cc: l2vpn@ietf.org, sdnp@lucidvision.com, 'Pedro Marques' , 'L3VPN WG mailing list' , armd@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 06:21:00 -0000 Yakov: We are not trying to justify any definition we have, but to report what DC operators have given as the problem in an OPS draft. In many ways, the text has been successful by having you comment on this point so that operators can consider in depth this scenario. With all due respect to you as a grand master of word-smithing, let me restate some of the argument so that I can attempt to inspire discussion. The "all" in this discussion indicates "all" within this domain which crosses the VLANs in the text. The 802.1q VLAN mechanism provides some scoping of broadcast and unicast for an L2 grouping. The IP Subset provides a scoping for scoping for IP (L3 grouping). ARP maps the L2 grouping to the l3 grouping. The growth in the number of nodes (VM or access) in the combined groupings of mapped nodes are the problem. If you want to restrict nodes within this at L2 or L3, you must find a means to determine the L2 grouping. The mapping of the IP to MAC Address is scoped by the combination of L2/L3 grouping. So.. at some point the VM or the real nodes reach an "aggregation grouping" at the access switch or the VMs forming an access switch. This grouping point is stressed by the underlying growth of L2/L3 node combination. On the ARMD BOF/List, Manish Karir (Merit) published a study in looking at the ARP problem using VMs groupings. Some large scale operators stated the VM aggregation I described above did not represent a case widely used. Therefore the discussion focused on the deployed access switches, servers, and VMs as described in the text. Please refer to past discussion from Igor G. on this list or his drafts on solutions/problems. Also, you can refer to NANOG session on this. Yakov - let me know of I am unclear or just misunderstood your discussion point. Linda, Manish, and Igor let me know if I was incorrect in anything I said. Hopefully, I've given the discussion a push. If nothing else, it will Sue -----Original Message----- From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of Yakov Rekhter Sent: Monday, November 14, 2011 3:42 PM To: Linda Dunbar Cc: l2vpn@ietf.org; sdnp@lucidvision.com; L3VPN WG mailing list; armd@ietf.org; yakov@juniper.net; Pedro Marques Subject: Re: [armd] Need your action to review draft-ietf-armd-problem-statement-00.txt Linda, > Pedro, > > You are absolutely right that there is no ARP/ND scaling issue if IP > can be extended to hosts. Even if IP can be extended to Access > switches, there is not much ARP/ND issues. > > The draft lists down several common data center network designs, and > states that some of the designs don't have ARP/ND scaling issues (but > may have other issues for data centers). > > That is why I encourage people to read the draft and provides > comments. >From 4.2 of the draft: 4.2. Scenario 2: L3 Terminates at the Aggregation Switch In Scenario 2, the L3 network extends only to the aggregation switches (or perhaps to routers that connect to the aggregation switches). The aggregation switches (or the routers that connect to multiple aggregation switches) could terminate multiple distinct IP subnets (e.g., one per VLAN) or one large IP subnet. In order to let hosts belonging to different IP subnets be placed under any access switches, it is necessary for access switches to enable multiple VLANs and aggregation switches to enable some VLANs (or subnets) over many physical ports. This configuration breaks the confinement of the VLAN's broadcast domain and makes it equivalent to all the access switches being part of the same L2 broadcast domain (and IP subnet). Thus, this configuration allows VMs to be moved to servers connected to other access switches, but increases the size of the L2 broadcast domain, which can lead to difficulties outlined below. This is the scenario that is used to justify the need for large L2 domain. The draft assumes that in order to move a given VM from one server to another, where these two servers are connected to different access switches, *all* the access switches must be configured with the VM's IP subnet, and thus *all* the access switches must be part of the VM's L2 broadcast domain. This is even if at any particular point in time the servers hosting all the VMs of that IP subnet are connected to only a subset of these switches. But is it truly necessary, or could the L2 broadcast domain span only the switches connected to the servers that presently host VMs of the IP subnet ? Moreover, even if all the access switches need to be part of the same L2 broadcast domain, the increase in the size of the L2 broadcast domain in the above scenario is caused by the access switches, not by the number of VMs per L2 domain. The difficulies mentioned in the last sentence of the quoted paragraph are due to ARP, but ARP is generated by VMs, not by the access switches. Given that, how the increase in the size of the L2 broadcast domain *due solely to the access switches*, could increase the amount of ARP traffic that routers have to process ? Yakov. > > > -----Original Message----- > > From: Pedro Marques [mailto:pedro.r.marques@gmail.com] > > Sent: Wednesday, November 09, 2011 1:52 PM > > To: Linda Dunbar > > Cc: l2vpn@ietf.org; L3VPN WG mailing list; sdnp@lucidvision.com; > > armd@ietf.org > > Subject: Re: Need your action to review draft-ietf-armd-problem- > > statement-00.txt > > > > Linda, > > I'd like to point out that the problem does not need to be solved if > > only IP connectivity is required. This I-D: > > http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 > > describes a solution in which address resolution is not required > > irrespective of the location of the traffic destination. Simply put, > > traffic can be routed at each hop. > > > > As per previous threads in this list, the concept of subnet which is > > of no practical usefulness in this space. Since VMs can be randomly > distributed across the network the subnet does not provide any > > information aggregation value. Thus there is no need to do address > > resolution. > > > > Pedro. > > > > On Wed, Nov 9, 2011 at 11:31 AM, Linda Dunbar > > > > wrote: > > > For those of you who touch upon Data Center networking or server > > > virtualization, be it Overlay, VPN4DC, or Application/Software > > > driven Controller for Data Center, Address Resolution is something > > > Data > > Center > > > Gateways will encounter because hosts/applications in data > > > centers > > do > > > communicate with peers which are not in the same Overlay, outside > > > the > > VPN > > > domain, or from general public. ARMD has published its WG problem > > statement > > > draft. Your comments and suggestions are appreciated (send to > > > armd@ietf.org). > > > > > > > > > > > > Thanks, Linda Dunbar > > > > > > > > > > > > ------------------------------------------------------------------ > > > --- > > -------------- > > > > > > > > > > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. This draft is a work item of the Address Resolution > > > for > > Massive > > > numbers of hosts in the Data center Working Group of the IETF. > > > > > > > > > > > > Title : Problem Statement for ARMD > > > > > > Author(s) : Thomas Narten > > > > > > Filename : draft-ietf-armd-problem-statement-00.txt > > > > > > Pages : 11 > > > > > > Date : 2011-10-17 > > > > > > > > > > > > This document examines issues related to the massive scaling of > > data > > > > > > centers. Our initial scope is relatively narrow. > > > Specifically, > > we > > > > > > focus on address resolution (ARP and ND) within the data center. > > > > > > > > > > > > > > > > > > A URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-armd-problem- > > statement-00.txt > > > > > > > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > > > > > > > This Internet-Draft can be retrieved at: > > > > > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-armd-problem-stateme > > > nt- > > 00.txt > > > > > > > From yakov@juniper.net Tue Nov 15 11:22:24 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDCC21F89B8; Tue, 15 Nov 2011 11:22:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.519 X-Spam-Level: X-Spam-Status: No, score=-103.519 tagged_above=-999 required=5 tests=[AWL=-2.720, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, J_CHICKENPOX_32=0.6, MANGLED_MEDS=2.3, MANGLED_PRBLMS=2.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFNrZaLhHhUF; Tue, 15 Nov 2011 11:22:18 -0800 (PST) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by ietfa.amsl.com (Postfix) with ESMTP id 564A711E8081; Tue, 15 Nov 2011 11:21:47 -0800 (PST) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTsK7yiEIkQhW7dGbkp4id8lgufQR/wuZ@postini.com; Tue, 15 Nov 2011 11:22:18 PST Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 15 Nov 2011 11:19:22 -0800 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id pAFJJJh74426; Tue, 15 Nov 2011 11:19:22 -0800 (PST) (envelope-from yakov@juniper.net) Message-ID: <201111151919.pAFJJJh74426@magenta.juniper.net> To: Linda Dunbar Subject: Re: Need your action to review draft-ietf-armd-problem-statement-00.txt In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> X-MH-In-Reply-To: Linda Dunbar message dated "Wed, 09 Nov 2011 19:31:33 +0000." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <93043.1321384759.1@juniper.net> Date: Tue, 15 Nov 2011 11:19:19 -0800 From: Yakov Rekhter Cc: "l2vpn@ietf.org" , "sdnp@lucidvision.com" , L3VPN WG mailing list , armd@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 19:22:24 -0000 Linda, > For those of you who touch upon Data Center networking or server > virtualization, be it Overlay, VPN4DC, or Application/Software > driven Controller for Data Center, Address Resolution is something > Data Center Gateways will encounter because hosts/applications > in data centers do communicate with peers which are not in the same > Overlay, outside the VPN domain, or from general public. ARMD has > published its WG problem statement draft. Your comments and suggestions > are app reciated (send to armd@ietf.org). Should the overhead due to the broadcast unknown be considered as yet another "pain point" associated with large L2 domains ? Yakov. > > Thanks, Linda Dunbar > > ----------------------------------------------------------------------------- ------ > > > > A New Internet-Draft is available from the on-line Internet-Drafts directorie s. This draft is a work item of the Address Resolution for Massive numbers of h osts in the Data center Working Group of the IETF. > > > > Title : Problem Statement for ARMD > > Author(s) : Thomas Narten > > Filename : draft-ietf-armd-problem-statement-00.txt > > Pages : 11 > > Date : 2011-10-17 > > > > This document examines issues related to the massive scaling of data > > centers. Our initial scope is relatively narrow. Specifically, we > > focus on address resolution (ARP and ND) within the data center. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-armd-problem-statement-00.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-armd-problem-statement-00.txt > > > --Boundary_(ID_2xYEQabSJUJeXxiogMJ0fQ) > Content-type: text/html; charset=us-ascii > Content-transfer-encoding: quoted-printable > > osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > xmlns:x=3D"urn:schemas-microsoft-com:office:excel" xmlns:p=3D"urn:schemas-m= > icrosoft-com:office:powerpoint" xmlns:a=3D"urn:schemas-microsoft-com:office= > :access" xmlns:dt=3D"uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s=3D"= > uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs=3D"urn:schemas-microsof= > t-com:rowset" xmlns:z=3D"#RowsetSchema" xmlns:b=3D"urn:schemas-microsoft-co= > m:office:publisher" xmlns:ss=3D"urn:schemas-microsoft-com:office:spreadshee= > t" xmlns:c=3D"urn:schemas-microsoft-com:office:component:spreadsheet" xmlns= > :odc=3D"urn:schemas-microsoft-com:office:odc" xmlns:oa=3D"urn:schemas-micro= > soft-com:office:activation" xmlns:html=3D"http://www.w3.org/TR/REC-html40" = > xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc=3D"http://m= > icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://= > schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share= > point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel= > /2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd" xmlns:ois= > =3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir=3D"http://= > schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3= > .org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint= > /dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc" xmlns:xsd=3D"http= > ://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha= > repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"= > xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xmlns:sps=3D"http://= > schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001= > /XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so= > ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udc= > p2p=3D"http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf=3D"http:/= > /schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche= > mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi= > crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat= > s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf= > ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c= > om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa= > ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web= > partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20= > 06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200= > 6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli= > deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal= > Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:= > st=3D"" xmlns=3D"http://www.w3.org/TR/REC-html40"> > > > > > > > >
>

For those of you who t= > ouch upon Data Center networking or server virtualization, be it Overlay, V= > PN4DC, or Application/Software driven Controller for Data Center, Address R= > esolution is something Data Center Gateways >  will encounter because hosts/applications in data centers do communi= > cate with peers which are not in the same Overlay, outside the VPN domain, = > or from general public. ARMD has published its WG problem statement draft. = > Your comments and suggestions are appreciated > (send to armd@ietf.org). <= > /span>

>

  n>

>

Thanks, Linda Dunbar :p>

>

  n>

>

----------------------= > ------------------------------------------------------------- pan>

>

  n>

>

 

> 
A New Internet-Draft is available from the on-line Internet-Drafts dir=
> ectories. This draft is a work item of the Address Resolution for Massive n=
> umbers of hosts in the Data center Working Group of the IETF. re>
> 
 

> 
        Title   &nbs=
> p;       : Problem Statement for ARMD :p>

> 
        Author(s)   =
>     : Thomas Narten

> 
        Filename   &=
> nbsp;    : draft-ietf-armd-problem-statement-00.txt p>

> 
        Pages   &nbs=
> p;       : 11

> 
        Date    =
> ;        : 2011-10-17

> 
 

> 
   This document examines issues related to the massive scal=
> ing of data

> 
   centers.  Our initial scope is relatively narrow.&nb=
> sp; Specifically, we

> 
   focus on address resolution (ARP and ND) within the data =
> center.

> 
 

> 
 

> 
A URL for this Internet-Draft is:

> 
 -statement-00.txt">http://www.ietf.org/internet-drafts/draft-ietf-armd-prob=
> lem-statement-00.txt

> 
 

> 
Internet-Drafts are also available by anonymous FTP at: e>
> 
ftp://ftp.ietf.org/int=
> ernet-drafts/

> 
 

> 
This Internet-Draft can be retrieved at:

> 
 statement-00.txt">ftp://ftp.ietf.org/internet-drafts/draft-ietf-armd-proble=
> m-statement-00.txt

> 
 

>
> > > > --Boundary_(ID_2xYEQabSJUJeXxiogMJ0fQ)-- > > --Boundary_(ID_pqxZHOFXGA69gJuhLyEG+A) > Content-id: <318D3282CFCD0C45A8C99283FF38289A@huawei.com> > Content-type: text/plain; name=ATT00001.txt > Content-transfer-encoding: 7BIT > Content-disposition: attachment; filename=ATT00001.txt; size=127; > creation-date="Fri, 04 Nov 2011 15:30:31 GMT"; > modification-date="Fri, 04 Nov 2011 15:30:31 GMT" > Content-description: ATT00001.txt > > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd > > --Boundary_(ID_pqxZHOFXGA69gJuhLyEG+A)-- From pedro.r.marques@gmail.com Tue Nov 15 09:47:02 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9834F1F0C3C; Tue, 15 Nov 2011 09:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIiJflHPKYg5; Tue, 15 Nov 2011 09:46:58 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 44DCE1F0C41; Tue, 15 Nov 2011 09:46:52 -0800 (PST) Received: by iaeo4 with SMTP id o4so11278303iae.31 for ; Tue, 15 Nov 2011 09:46:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=eQpeXGh8hWjyUGWx6RruiKeBml2xuTC5z7YrtWFs6kk=; b=A8SQVpxNKnZX3GvTxzZ8Os1IYGnye0VhfDCZ2vCBmbcZtcoJsNUvy5m09dmvXZMsew znXT2gPsT4c6tVDmo0v1ZaPKik7YZ4pnjpmnn74gWowQJX4WdJe6X+cxoP6HjaOENhw4 1xVOodN8nr+XcXVZkDyqzoA/2JK53Tsgs3qE8= MIME-Version: 1.0 Received: by 10.231.8.143 with SMTP id h15mr6454119ibh.94.1321379211837; Tue, 15 Nov 2011 09:46:51 -0800 (PST) Received: by 10.231.12.2 with HTTP; Tue, 15 Nov 2011 09:46:51 -0800 (PST) In-Reply-To: <011101cca35e$a93be5b0$fbb3b110$@com> References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120BEC36@dfweml506-mbx> <201111142042.pAEKg1h21336@magenta.juniper.net> <011101cca35e$a93be5b0$fbb3b110$@com> Date: Tue, 15 Nov 2011 09:46:51 -0800 Message-ID: Subject: Re: [armd] Need your action to review draft-ietf-armd-problem-statement-00.txt From: Pedro Marques To: Susan Hares Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 15 Nov 2011 15:21:50 -0800 Cc: l2vpn@ietf.org, sdnp@lucidvision.com, L3VPN WG mailing list , armd@ietf.org, Yakov Rekhter X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 17:47:02 -0000 Sue, I think the following statements capture a common configuration for small / low-bandwidth (1g) / private DCs: - VLANs are used for isolation. - These vlans are locally scoped to a pair of aggregation switches. - They are statically configured at the access switches. - Traffic exchange between vlans is done at the aggregation switches (often subject to service modules). The above is not contentious, i presume. I think that everyone would also agree that: - It is highly desirable to be able to have an application (a process running on a server) to be placed in an arbitrary location of the DC. (which conflicts with vlan locality). - It is expected that the number of application processes that participate in the same isolation domain will grow significantly (due to external factors related to application design). - It is expected that the bandwidth requirements for severs will increase by an order of magnitude (along with higher server utilization). I hope we all agree so far. Now from the 2 sets of premises above it does not directly follow that the answer is to build larger and larger L2 domains. I do understand that to be a common perception but that is actually not necessary and imho not useful. The fundamental misconception is that the application processes (in a VM or other wise) do need VLANs. They do not. They need connectivity; both within an inner level of isolation (today's vlan) and to other services in the data center (which today is routed often subject to security policies). An example of the later would be a set of database servers; database servers are often expensive and shared among different applications. In order to be able to place any VM anywhere, the VM needs to have direct connectivity to multiple isolation domains. isolation domains which are today modeled as L2 and isolation domains that are today modeled as L3. The concept of an L2/L3 boundary is not useful if you assume that a VM can be placed in an arbitrary location. Anywhere you choose to put that "boundary": top-of-rack, aggregation, etc, you are likely to find that the boundary gets in the way of the VMs being able to be located anywhere. At least without causing traffic to cross the core twice which is a non-starter. So to actually solve the problem according to requirements one needs to get rid of the boundary and move to a solution that is all L2 or all L3. And ARP/ND is really not a relevant problem. With an "L2" solution tends to come the assumption that there is a single "isolation" domain... and a single subnet, which doesn't really cut it. "L3" and specially BGP-based IP/VPNs natively support the concept of direct traffic exchanges between different isolation domains, subject to policy. Even if you do decide to select an L2 approach that limits an application to a single isolation domain, the L2 mac information will need to be present at every switch where that L2 VLAN is present. If you follow an approach where there is core-interface to core-interface mac-learning (VXLAN for instance) then indeed you do have ARP broadcasts being used to update forwarding tables. But approaches such as EVPN can perform learning on the edge interface only eliminating the need to generate ARP broadcasts. It is entirely likely that the approaches that attempt to provide for large broadcast domains already contain a solution for L2 address discovery. Conversely it is rather unclear that you can address the ARP/ND scaling issue independently of the design of the L2 solution itself. regards, Pedro. On Mon, Nov 14, 2011 at 10:20 PM, Susan Hares wrote: > Yakov: > > We are not trying to justify any definition we have, but to report what D= C > operators have given as the problem in an OPS draft. > > In many ways, the text has been successful by having you comment on this > point so that operators can consider in depth this scenario. > > With all due respect to you as a grand master of word-smithing, let me > restate some of the argument so that I can attempt to inspire discussion. > > The "all" in this discussion indicates "all" within this domain which > crosses the VLANs in the text. The 802.1q VLAN mechanism provides some > scoping of broadcast and unicast for an L2 grouping. The IP Subset provid= es > a scoping for scoping for IP (L3 grouping). ARP maps the L2 grouping to t= he > l3 grouping. The growth in the number of nodes (VM or access) in the > combined groupings of mapped nodes are the problem. > > If you want to restrict nodes within this at L2 or L3, you must find a me= ans > to determine the L2 grouping. The mapping of the IP to MAC Address is sco= ped > by the combination of L2/L3 grouping. > > So.. at some point the VM or the real nodes reach an "aggregation groupin= g" > at the access switch or the VMs forming an access switch. This grouping > point is stressed by the underlying growth of L2/L3 node combination. On = the > ARMD BOF/List, Manish Karir (Merit) published a study in looking at the A= RP > problem using VMs groupings. > > Some large scale operators stated the VM aggregation I described above di= d > not represent a case widely used. Therefore the discussion focused on the > deployed access switches, servers, and VMs as described in the text. =A0P= lease > refer to past discussion from Igor G. on this list or his drafts on > solutions/problems. Also, you can refer to NANOG session on this. > > Yakov - let me know of I am unclear or just misunderstood your discussion > point. Linda, Manish, and Igor let me know if I was incorrect in anything= I > said. > > Hopefully, I've given the discussion a push. If nothing else, it will > > Sue > > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of > Yakov Rekhter > Sent: Monday, November 14, 2011 3:42 PM > To: Linda Dunbar > Cc: l2vpn@ietf.org; sdnp@lucidvision.com; L3VPN WG mailing list; > armd@ietf.org; yakov@juniper.net; Pedro Marques > Subject: Re: [armd] Need your action to review > draft-ietf-armd-problem-statement-00.txt > > Linda, > >> Pedro, >> >> You are absolutely right that there is no ARP/ND scaling issue if IP >> can be extended to hosts. Even if IP can be extended to Access >> switches, there is not much ARP/ND issues. >> >> The draft lists down several common data center network designs, and >> states that some of the designs don't have ARP/ND scaling issues (but >> may have other issues for data centers). >> >> That is why I encourage people to read the draft and provides >> comments. > > From 4.2 of the draft: > > =A04.2. =A0Scenario 2: L3 Terminates at the Aggregation Switch > > =A0 In Scenario 2, the L3 network extends only to the aggregation > =A0 switches (or perhaps to routers that connect to the aggregation > =A0 switches). =A0The aggregation switches (or the routers that connect t= o > =A0 multiple aggregation switches) could terminate multiple distinct IP > =A0 subnets (e.g., one per VLAN) or one large IP subnet. =A0In order to l= et > =A0 hosts belonging to different IP subnets be placed under any access > =A0 switches, it is necessary for access switches to enable multiple > =A0 VLANs and aggregation switches to enable some VLANs (or subnets) over > =A0 many physical ports. =A0This configuration breaks the confinement of > =A0 the VLAN's broadcast domain and makes it equivalent to all the access > =A0 switches being part of the same L2 broadcast domain (and IP subnet). > =A0 Thus, this configuration allows VMs to be moved to servers connected > =A0 to other access switches, but increases the size of the L2 broadcast > =A0 domain, which can lead to difficulties outlined below. > > This is the scenario that is used to justify the need for large L2 domain= . > > The draft assumes that in order to move a given VM from one server to > another, where these two servers are connected to different access switch= es, > *all* the access switches must be configured with the VM's IP subnet, and > thus *all* the access switches must be part of the VM's L2 broadcast doma= in. > This is even if at any particular point in time the servers hosting all t= he > VMs of that IP subnet are connected to only a subset of these switches. B= ut > is it truly necessary, or could the L2 broadcast domain span only the > switches connected to the servers that presently host VMs of the IP subne= t ? > > Moreover, even if all the access switches need to be part of the same L2 > broadcast domain, the increase in the size of the L2 broadcast domain in = the > above scenario is caused by the access switches, not by the number of VMs > per L2 domain. The difficulies mentioned in the last sentence of the quot= ed > paragraph are due to ARP, but ARP is generated by VMs, not by the access > switches. Given that, how the increase in the size of the L2 broadcast > domain *due solely to the access switches*, could increase the amount of = ARP > traffic that routers have to process ? > > Yakov. > >> >> > -----Original Message----- >> > From: Pedro Marques [mailto:pedro.r.marques@gmail.com] >> > Sent: Wednesday, November 09, 2011 1:52 PM >> > To: Linda Dunbar >> > Cc: l2vpn@ietf.org; L3VPN WG mailing list; sdnp@lucidvision.com; >> > armd@ietf.org >> > Subject: Re: Need your action to review draft-ietf-armd-problem- >> > statement-00.txt >> > >> > Linda, >> > I'd like to point out that the problem does not need to be solved if >> > only IP connectivity is required. This I-D: >> > http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 >> > describes a solution in which address resolution is not required >> > irrespective of the location of the traffic destination. Simply put, >> > traffic can be routed at each hop. >> > >> > As per previous threads in this list, the concept of subnet which is >> > of no practical usefulness in this space. Since VMs can be randomly >> distributed across the network the subnet does not provide any >> > information aggregation value. Thus there is no need to do address >> > resolution. >> > >> > =A0 Pedro. >> > >> > On Wed, Nov 9, 2011 at 11:31 AM, Linda Dunbar >> > >> > wrote: >> > > For those of you who touch upon Data Center networking or server >> > > virtualization, be it Overlay, VPN4DC, or Application/Software >> > > driven Controller for Data Center, Address Resolution is something >> > > Data >> > Center >> > > Gateways =A0will encounter because hosts/applications in data >> > > centers >> > do >> > > communicate with peers which are not in the same Overlay, outside >> > > the >> > VPN >> > > domain, or from general public. ARMD has published its WG problem >> > statement >> > > draft. Your comments and suggestions are appreciated (send to >> > > armd@ietf.org). >> > > >> > > >> > > >> > > Thanks, Linda Dunbar >> > > >> > > >> > > >> > > ------------------------------------------------------------------ >> > > --- >> > -------------- >> > > >> > > >> > > >> > > >> > > >> > > A New Internet-Draft is available from the on-line Internet-Drafts >> > > directories. This draft is a work item of the Address Resolution >> > > for >> > Massive >> > > numbers of hosts in the Data center Working Group of the IETF. >> > > >> > > >> > > >> > > =A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Problem Statement for AR= MD >> > > >> > > =A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Thomas Narten >> > > >> > > =A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-armd-problem-st= atement-00.txt >> > > >> > > =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 11 >> > > >> > > =A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-10-17 >> > > >> > > >> > > >> > > =A0 =A0This document examines issues related to the massive scaling = of >> > data >> > > >> > > =A0 =A0centers. =A0Our initial scope is relatively narrow. >> > > Specifically, >> > we >> > > >> > > =A0 =A0focus on address resolution (ARP and ND) within the data cent= er. >> > > >> > > >> > > >> > > >> > > >> > > A URL for this Internet-Draft is: >> > > >> > > http://www.ietf.org/internet-drafts/draft-ietf-armd-problem- >> > statement-00.txt >> > > >> > > >> > > >> > > Internet-Drafts are also available by anonymous FTP at: >> > > >> > > ftp://ftp.ietf.org/internet-drafts/ >> > > >> > > >> > > >> > > This Internet-Draft can be retrieved at: >> > > >> > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-armd-problem-stateme >> > > nt- >> > 00.txt >> > > >> > > >> > > From skh@ndzh.com Tue Nov 15 10:58:41 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388C21F0C5B; Tue, 15 Nov 2011 10:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.237 X-Spam-Level: * X-Spam-Status: No, score=1.237 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_SORBS_WEB=0.619, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZUyBZjFMjyU; Tue, 15 Nov 2011 10:58:36 -0800 (PST) Received: from hickoryhill-consulting.com (63-208-161-201.digitalrealm.net [63.208.161.201]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9E01F0C4B; Tue, 15 Nov 2011 10:58:35 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=61.220.70.183; Received: from SKHPERSONALLT (unverified [61.220.70.183]) by hickoryhill-consulting.com (SurgeMail 5.2a) with ESMTP id 2843982-1945496 for multiple; Tue, 15 Nov 2011 13:57:54 -0500 From: "Susan Hares" To: "'Pedro Marques'" References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120BEC36@dfweml506-mbx> <201111142042.pAEKg1h21336@magenta.juniper.net> <011101cca35e$a93be5b0$fbb3b110$@com> In-Reply-To: Subject: RE: [armd] Need your action to review draft-ietf-armd-problem-statement-00.txt Date: Tue, 15 Nov 2011 13:57:52 -0500 Message-ID: <00b601cca3c8$7c40ccf0$74c266d0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyjvpU//bdJMvZzS0+sBxAD7KLNVAACXqtw Content-Language: en-us X-Authenticated-User: skh@ndzh.com X-Mailman-Approved-At: Tue, 15 Nov 2011 15:21:56 -0800 Cc: l2vpn@ietf.org, sdnp@lucidvision.com, 'L3VPN WG mailing list' , armd@ietf.org, 'Yakov Rekhter' X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Nov 2011 18:58:41 -0000 Pedro:=20 In all politeness, let me acknowledge your message. I will respond after = I see if Igor (Yahoo) or other DC/Carrier operators will comment on their viewpoints. Best wishes,=20 Sue=20 -----Original Message----- From: Pedro Marques [mailto:pedro.r.marques@gmail.com]=20 Sent: Tuesday, November 15, 2011 12:47 PM To: Susan Hares Cc: Yakov Rekhter; Linda Dunbar; l2vpn@ietf.org; sdnp@lucidvision.com; = L3VPN WG mailing list; armd@ietf.org Subject: Re: [armd] Need your action to review draft-ietf-armd-problem-statement-00.txt Sue, I think the following statements capture a common configuration for small / low-bandwidth (1g) / private DCs: - VLANs are used for isolation. - These vlans are locally scoped to a pair of aggregation switches. - They are statically configured at the access switches. - Traffic exchange between vlans is done at the aggregation switches (often subject to service modules). The above is not contentious, i presume. I think that everyone would also agree that: - It is highly desirable to be able to have an application (a process running on a server) to be placed in an arbitrary location of the DC. (which conflicts with vlan locality). - It is expected that the number of application processes that participate in the same isolation domain will grow significantly (due to external factors related to application design). - It is expected that the bandwidth requirements for severs will increase by an order of magnitude (along with higher server utilization). I hope we all agree so far. Now from the 2 sets of premises above it does not directly follow that the answer is to build larger and larger L2 domains. I do understand that to be a common perception but that is actually not necessary and imho not useful. The fundamental misconception is that the application processes (in a VM or other wise) do need VLANs. They do not. They need connectivity; both within an inner level of isolation (today's vlan) and to other services in the data center (which today is routed often subject to security policies). An example of the later would be a set of database servers; database servers are often expensive and shared among different applications. In order to be able to place any VM anywhere, the VM needs to have direct connectivity to multiple isolation domains. isolation domains which are today modeled as L2 and isolation domains that are today modeled as L3. The concept of an L2/L3 boundary is not useful if you assume that a VM can be placed in an arbitrary location. Anywhere you choose to put that "boundary": top-of-rack, aggregation, etc, you are likely to find that the boundary gets in the way of the VMs being able to be located anywhere. At least without causing traffic to cross the core twice which is a non-starter. So to actually solve the problem according to requirements one needs to get rid of the boundary and move to a solution that is all L2 or all L3. And ARP/ND is really not a relevant problem. With an "L2" solution tends to come the assumption that there is a single "isolation" domain... and a single subnet, which doesn't really cut it. "L3" and specially BGP-based IP/VPNs natively support the concept of direct traffic exchanges between different isolation domains, subject to policy. Even if you do decide to select an L2 approach that limits an application to a single isolation domain, the L2 mac information will need to be present at every switch where that L2 VLAN is present. If you follow an approach where there is core-interface to core-interface mac-learning (VXLAN for instance) then indeed you do have ARP broadcasts being used to update forwarding tables. But approaches such as EVPN can perform learning on the edge interface only eliminating the need to generate ARP broadcasts. It is entirely likely that the approaches that attempt to provide for large broadcast domains already contain a solution for L2 address discovery. Conversely it is rather unclear that you can address the ARP/ND scaling issue independently of the design of the L2 solution itself. regards, Pedro. On Mon, Nov 14, 2011 at 10:20 PM, Susan Hares wrote: > Yakov: > > We are not trying to justify any definition we have, but to report = what DC > operators have given as the problem in an OPS draft. > > In many ways, the text has been successful by having you comment on = this > point so that operators can consider in depth this scenario. > > With all due respect to you as a grand master of word-smithing, let me > restate some of the argument so that I can attempt to inspire = discussion. > > The "all" in this discussion indicates "all" within this domain which > crosses the VLANs in the text. The 802.1q VLAN mechanism provides some > scoping of broadcast and unicast for an L2 grouping. The IP Subset provides > a scoping for scoping for IP (L3 grouping). ARP maps the L2 grouping = to the > l3 grouping. The growth in the number of nodes (VM or access) in the > combined groupings of mapped nodes are the problem. > > If you want to restrict nodes within this at L2 or L3, you must find a means > to determine the L2 grouping. The mapping of the IP to MAC Address is scoped > by the combination of L2/L3 grouping. > > So.. at some point the VM or the real nodes reach an "aggregation grouping" > at the access switch or the VMs forming an access switch. This = grouping > point is stressed by the underlying growth of L2/L3 node combination. = On the > ARMD BOF/List, Manish Karir (Merit) published a study in looking at = the ARP > problem using VMs groupings. > > Some large scale operators stated the VM aggregation I described above = did > not represent a case widely used. Therefore the discussion focused on = the > deployed access switches, servers, and VMs as described in the text. =A0Please > refer to past discussion from Igor G. on this list or his drafts on > solutions/problems. Also, you can refer to NANOG session on this. > > Yakov - let me know of I am unclear or just misunderstood your = discussion > point. Linda, Manish, and Igor let me know if I was incorrect in = anything I > said. > > Hopefully, I've given the discussion a push. If nothing else, it will > > Sue > > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf = Of > Yakov Rekhter > Sent: Monday, November 14, 2011 3:42 PM > To: Linda Dunbar > Cc: l2vpn@ietf.org; sdnp@lucidvision.com; L3VPN WG mailing list; > armd@ietf.org; yakov@juniper.net; Pedro Marques > Subject: Re: [armd] Need your action to review > draft-ietf-armd-problem-statement-00.txt > > Linda, > >> Pedro, >> >> You are absolutely right that there is no ARP/ND scaling issue if IP >> can be extended to hosts. Even if IP can be extended to Access >> switches, there is not much ARP/ND issues. >> >> The draft lists down several common data center network designs, and >> states that some of the designs don't have ARP/ND scaling issues (but >> may have other issues for data centers). >> >> That is why I encourage people to read the draft and provides >> comments. > > From 4.2 of the draft: > > =A04.2. =A0Scenario 2: L3 Terminates at the Aggregation Switch > > =A0 In Scenario 2, the L3 network extends only to the aggregation > =A0 switches (or perhaps to routers that connect to the aggregation > =A0 switches). =A0The aggregation switches (or the routers that = connect to > =A0 multiple aggregation switches) could terminate multiple distinct = IP > =A0 subnets (e.g., one per VLAN) or one large IP subnet. =A0In order = to let > =A0 hosts belonging to different IP subnets be placed under any access > =A0 switches, it is necessary for access switches to enable multiple > =A0 VLANs and aggregation switches to enable some VLANs (or subnets) = over > =A0 many physical ports. =A0This configuration breaks the confinement = of > =A0 the VLAN's broadcast domain and makes it equivalent to all the = access > =A0 switches being part of the same L2 broadcast domain (and IP = subnet). > =A0 Thus, this configuration allows VMs to be moved to servers = connected > =A0 to other access switches, but increases the size of the L2 = broadcast > =A0 domain, which can lead to difficulties outlined below. > > This is the scenario that is used to justify the need for large L2 = domain. > > The draft assumes that in order to move a given VM from one server to > another, where these two servers are connected to different access switches, > *all* the access switches must be configured with the VM's IP subnet, = and > thus *all* the access switches must be part of the VM's L2 broadcast domain. > This is even if at any particular point in time the servers hosting = all the > VMs of that IP subnet are connected to only a subset of these = switches. But > is it truly necessary, or could the L2 broadcast domain span only the > switches connected to the servers that presently host VMs of the IP = subnet ? > > Moreover, even if all the access switches need to be part of the same = L2 > broadcast domain, the increase in the size of the L2 broadcast domain = in the > above scenario is caused by the access switches, not by the number of = VMs > per L2 domain. The difficulies mentioned in the last sentence of the quoted > paragraph are due to ARP, but ARP is generated by VMs, not by the = access > switches. Given that, how the increase in the size of the L2 broadcast > domain *due solely to the access switches*, could increase the amount = of ARP > traffic that routers have to process ? > > Yakov. > >> >> > -----Original Message----- >> > From: Pedro Marques [mailto:pedro.r.marques@gmail.com] >> > Sent: Wednesday, November 09, 2011 1:52 PM >> > To: Linda Dunbar >> > Cc: l2vpn@ietf.org; L3VPN WG mailing list; sdnp@lucidvision.com; >> > armd@ietf.org >> > Subject: Re: Need your action to review draft-ietf-armd-problem- >> > statement-00.txt >> > >> > Linda, >> > I'd like to point out that the problem does not need to be solved = if >> > only IP connectivity is required. This I-D: >> > http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 >> > describes a solution in which address resolution is not required >> > irrespective of the location of the traffic destination. Simply = put, >> > traffic can be routed at each hop. >> > >> > As per previous threads in this list, the concept of subnet which = is >> > of no practical usefulness in this space. Since VMs can be randomly >> distributed across the network the subnet does not provide any >> > information aggregation value. Thus there is no need to do address >> > resolution. >> > >> > =A0 Pedro. >> > >> > On Wed, Nov 9, 2011 at 11:31 AM, Linda Dunbar >> > >> > wrote: >> > > For those of you who touch upon Data Center networking or server >> > > virtualization, be it Overlay, VPN4DC, or Application/Software >> > > driven Controller for Data Center, Address Resolution is = something >> > > Data >> > Center >> > > Gateways =A0will encounter because hosts/applications in data >> > > centers >> > do >> > > communicate with peers which are not in the same Overlay, outside >> > > the >> > VPN >> > > domain, or from general public. ARMD has published its WG problem >> > statement >> > > draft. Your comments and suggestions are appreciated (send to >> > > armd@ietf.org). >> > > >> > > >> > > >> > > Thanks, Linda Dunbar >> > > >> > > >> > > >> > > = ------------------------------------------------------------------ >> > > --- >> > -------------- >> > > >> > > >> > > >> > > >> > > >> > > A New Internet-Draft is available from the on-line = Internet-Drafts >> > > directories. This draft is a work item of the Address Resolution >> > > for >> > Massive >> > > numbers of hosts in the Data center Working Group of the IETF. >> > > >> > > >> > > >> > > =A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Problem Statement for = ARMD >> > > >> > > =A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Thomas Narten >> > > >> > > =A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: = draft-ietf-armd-problem-statement-00.txt >> > > >> > > =A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 11 >> > > >> > > =A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-10-17 >> > > >> > > >> > > >> > > =A0 =A0This document examines issues related to the massive = scaling of >> > data >> > > >> > > =A0 =A0centers. =A0Our initial scope is relatively narrow. >> > > Specifically, >> > we >> > > >> > > =A0 =A0focus on address resolution (ARP and ND) within the data = center. >> > > >> > > >> > > >> > > >> > > >> > > A URL for this Internet-Draft is: >> > > >> > > http://www.ietf.org/internet-drafts/draft-ietf-armd-problem- >> > statement-00.txt >> > > >> > > >> > > >> > > Internet-Drafts are also available by anonymous FTP at: >> > > >> > > ftp://ftp.ietf.org/internet-drafts/ >> > > >> > > >> > > >> > > This Internet-Draft can be retrieved at: >> > > >> > > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-armd-problem-stateme >> > > nt- >> > 00.txt >> > > >> > > >> > > From xuxiaohu@huawei.com Tue Nov 15 17:30:49 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165031F0C93; Tue, 15 Nov 2011 17:30:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.079 X-Spam-Level: * X-Spam-Status: No, score=1.079 tagged_above=-999 required=5 tests=[AWL=-2.925, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_32=0.6, MANGLED_MEDS=2.3, MANGLED_PRBLMS=2.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QBj89QQ-GvW5; Tue, 15 Nov 2011 17:30:43 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8974B1F0C95; Tue, 15 Nov 2011 17:30:42 -0800 (PST) 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 <0LUQ00EUHC74J8@szxga04-in.huawei.com>; Wed, 16 Nov 2011 09:30:40 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ00DERC6TVQ@szxga04-in.huawei.com>; Wed, 16 Nov 2011 09:30:40 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFB62265; Wed, 16 Nov 2011 09:30:30 +0800 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 Nov 2011 09:30:25 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.003; Wed, 16 Nov 2011 09:30:23 +0800 Date: Wed, 16 Nov 2011 01:30:22 +0000 From: Xuxiaohu Subject: re: Need your action to review draft-ietf-armd-problem-statement-00.txt In-reply-to: <201111151919.pAFJJJh74426@magenta.juniper.net> X-Originating-IP: [172.24.2.41] To: Yakov Rekhter , Linda Dunbar Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BDCA@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: Need your action to review draft-ietf-armd-problem-statement-00.txt Thread-index: AQHMo8vtYH3v59PbJ0yNrS5G7pYICZWutQxx X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> <201111151919.pAFJJJh74426@magenta.juniper.net> Cc: "l2vpn@ietf.org" , "sdnp@lucidvision.com" , L3VPN WG mailing list , "armd@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 01:30:49 -0000 SGkgWWFrb3YsDQoNCkkgYmVsaWV2ZSB1bmtub3duIHVuaWNhc3QgZmxvb2Qgc2hvdWxkIGJlIGNv bnNpZGVyZWQgYXMgYW5vdGhlciBwYWluIHBvaW50IGFzc29jaWF0ZWQgd2l0aCBsYXJnZSBMMiBk b21haW5zIHdoaWNoIGFyZSBleHRlbmRlZCBhY3Jvc3MgbXVsdGlwbGUgZGF0YSBjZW50ZXJzLiBU aGUgcmVhc29uIGlzIHRoZSBXQU4gYmFuZHdpZHRoIGlzIG11Y2ggbGltaXRlZCBhbmQgZXhwZW5z aXZlLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUgDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQq3orz+yMs6IGwzdnBuLWJvdW5jZXNAaWV0Zi5vcmcgW2wzdnBuLWJv dW5jZXNAaWV0Zi5vcmddILT6se0gWWFrb3YgUmVraHRlciBbeWFrb3ZAanVuaXBlci5uZXRdDQq3 osvNyrG85DogMjAxMcTqMTHUwjE2yNUgMzoxOQ0Ktb06IExpbmRhIER1bmJhcg0KQ2M6IGwydnBu QGlldGYub3JnOyBzZG5wQGx1Y2lkdmlzaW9uLmNvbTsgTDNWUE4gV0cgbWFpbGluZyBsaXN0OyBh cm1kQGlldGYub3JnDQrW98ziOiBSZTogTmVlZCB5b3VyIGFjdGlvbiB0byByZXZpZXcgICAgICBk cmFmdC1pZXRmLWFybWQtcHJvYmxlbS1zdGF0ZW1lbnQtMDAudHh0DQoNCkxpbmRhLA0KDQo+IEZv ciB0aG9zZSBvZiB5b3Ugd2hvIHRvdWNoIHVwb24gRGF0YSBDZW50ZXIgbmV0d29ya2luZyBvciBz ZXJ2ZXINCj4gdmlydHVhbGl6YXRpb24sIGJlIGl0IE92ZXJsYXksIFZQTjREQywgb3IgQXBwbGlj YXRpb24vU29mdHdhcmUNCj4gZHJpdmVuIENvbnRyb2xsZXIgZm9yIERhdGEgQ2VudGVyLCBBZGRy ZXNzIFJlc29sdXRpb24gaXMgc29tZXRoaW5nDQo+IERhdGEgQ2VudGVyIEdhdGV3YXlzICB3aWxs IGVuY291bnRlciBiZWNhdXNlIGhvc3RzL2FwcGxpY2F0aW9ucw0KPiBpbiBkYXRhIGNlbnRlcnMg ZG8gY29tbXVuaWNhdGUgd2l0aCBwZWVycyB3aGljaCBhcmUgbm90IGluIHRoZSBzYW1lDQo+IE92 ZXJsYXksIG91dHNpZGUgdGhlIFZQTiBkb21haW4sIG9yIGZyb20gZ2VuZXJhbCBwdWJsaWMuIEFS TUQgaGFzDQo+IHB1Ymxpc2hlZCBpdHMgV0cgcHJvYmxlbSBzdGF0ZW1lbnQgZHJhZnQuIFlvdXIg Y29tbWVudHMgYW5kIHN1Z2dlc3Rpb25zDQo+IGFyZSBhcHAgcmVjaWF0ZWQgKHNlbmQgdG8gYXJt ZEBpZXRmLm9yZzxtYWlsdG86YXJtZEBpZXRmLm9yZz4pLg0KDQpTaG91bGQgdGhlIG92ZXJoZWFk IGR1ZSB0byB0aGUgYnJvYWRjYXN0IHVua25vd24gYmUgY29uc2lkZXJlZCBhcyB5ZXQNCmFub3Ro ZXIgInBhaW4gcG9pbnQiIGFzc29jaWF0ZWQgd2l0aCBsYXJnZSBMMiBkb21haW5zID8NCg0KWWFr b3YuDQoNCj4NCj4gVGhhbmtzLCBMaW5kYSBEdW5iYXINCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCi0tLS0tLQ0KPg0KPg0KPg0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUg ZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZQ0Kcy4gVGhpcyBkcmFm dCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQWRkcmVzcyBSZXNvbHV0aW9uIGZvciBNYXNzaXZlIG51 bWJlcnMgb2YgaA0Kb3N0cyBpbiB0aGUgRGF0YSBjZW50ZXIgV29ya2luZyBHcm91cCBvZiB0aGUg SUVURi4NCj4NCj4NCj4NCj4gICAgICAgICBUaXRsZSAgICAgICAgICAgOiBQcm9ibGVtIFN0YXRl bWVudCBmb3IgQVJNRA0KPg0KPiAgICAgICAgIEF1dGhvcihzKSAgICAgICA6IFRob21hcyBOYXJ0 ZW4NCj4NCj4gICAgICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWFybWQtcHJvYmxl bS1zdGF0ZW1lbnQtMDAudHh0DQo+DQo+ICAgICAgICAgUGFnZXMgICAgICAgICAgIDogMTENCj4N Cj4gICAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDExLTEwLTE3DQo+DQo+DQo+DQo+ICAgIFRo aXMgZG9jdW1lbnQgZXhhbWluZXMgaXNzdWVzIHJlbGF0ZWQgdG8gdGhlIG1hc3NpdmUgc2NhbGlu ZyBvZiBkYXRhDQo+DQo+ICAgIGNlbnRlcnMuICBPdXIgaW5pdGlhbCBzY29wZSBpcyByZWxhdGl2 ZWx5IG5hcnJvdy4gIFNwZWNpZmljYWxseSwgd2UNCj4NCj4gICAgZm9jdXMgb24gYWRkcmVzcyBy ZXNvbHV0aW9uIChBUlAgYW5kIE5EKSB3aXRoaW4gdGhlIGRhdGEgY2VudGVyLg0KPg0KPg0KPg0K Pg0KPg0KPiBBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCj4NCj4gaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1hcm1kLXByb2JsZW0tc3RhdGVt ZW50LTAwLnR4dA0KPg0KPg0KPg0KPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxl IGJ5IGFub255bW91cyBGVFAgYXQ6DQo+DQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvDQo+DQo+DQo+DQo+IFRoaXMgSW50ZXJuZXQtRHJhZnQgY2FuIGJlIHJldHJpZXZlZCBh dDoNCj4NCj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWFy bWQtcHJvYmxlbS1zdGF0ZW1lbnQtMDAudHh0DQo+DQo+DQo+IC0tQm91bmRhcnlfKElEXzJ4WUVR YWJTSlVKZVh4aW9nTUowZlEpDQo+IENvbnRlbnQtdHlwZTogdGV4dC9odG1sOyBjaGFyc2V0PXVz LWFzY2lpDQo+IENvbnRlbnQtdHJhbnNmZXItZW5jb2Rpbmc6IHF1b3RlZC1wcmludGFibGUNCj4N Cj4gPGh0bWwgeG1sbnM6dj0zRCJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6 bz0zRCJ1cm46c2NoZW1hcy1taWNyPQ0KPiBvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0zRCJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiA9DQo+IHhtbG5zOng9 M0QidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9M0QidXJu OnNjaGVtYXMtbT0NCj4gaWNyb3NvZnQtY29tOm9mZmljZTpwb3dlcnBvaW50IiB4bWxuczphPTNE InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlPQ0KPiA6YWNjZXNzIiB4bWxuczpkdD0z RCJ1dWlkOkMyRjQxMDEwLTY1QjMtMTFkMS1BMjlGLTAwQUEwMEMxNDg4MiIgeG1sbnM6cz0zRCI9 DQo+IHV1aWQ6QkRDNkUzRjAtNkRBMy0xMWQxLUEyQTMtMDBBQTAwQzE0ODgyIiB4bWxuczpycz0z RCJ1cm46c2NoZW1hcy1taWNyb3NvZj0NCj4gdC1jb206cm93c2V0IiB4bWxuczp6PTNEIiNSb3dz ZXRTY2hlbWEiIHhtbG5zOmI9M0QidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvPQ0KPiBtOm9mZmlj ZTpwdWJsaXNoZXIiIHhtbG5zOnNzPTNEInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNl OnNwcmVhZHNoZWU9DQo+IHQiIHhtbG5zOmM9M0QidXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpv ZmZpY2U6Y29tcG9uZW50OnNwcmVhZHNoZWV0IiB4bWxucz0NCj4gOm9kYz0zRCJ1cm46c2NoZW1h cy1taWNyb3NvZnQtY29tOm9mZmljZTpvZGMiIHhtbG5zOm9hPTNEInVybjpzY2hlbWFzLW1pY3Jv PQ0KPiBzb2Z0LWNvbTpvZmZpY2U6YWN0aXZhdGlvbiIgeG1sbnM6aHRtbD0zRCJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIiA9DQo+IHhtbG5zOnE9M0QiaHR0cDovL3NjaGVtYXMueG1s c29hcC5vcmcvc29hcC9lbnZlbG9wZS8iIHhtbG5zOnJ0Yz0zRCJodHRwOi8vbT0NCj4gaWNyb3Nv ZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9M0QiREFWOiIgeG1sbnM6UmVw bD0zRCJodHRwOi8vPQ0KPiBzY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5zOm10PTNE Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmU9DQo+IHBvaW50L3NvYXAvbWVldGlu Z3MvIiB4bWxuczp4Mj0zRCJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNl bD0NCj4gLzIwMDMveG1sIiB4bWxuczpwcGRhPTNEImh0dHA6Ly93d3cucGFzc3BvcnQuY29tL05h bWVTcGFjZS54c2QiIHhtbG5zOm9pcz0NCj4gPTNEImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vc2hhcmVwb2ludC9zb2FwL29pcy8iIHhtbG5zOmRpcj0zRCJodHRwOi8vPQ0KPiBzY2hlbWFz Lm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPTNEImh0 dHA6Ly93d3cudzM9DQo+IC5vcmcvMjAwMC8wOS94bWxkc2lnIyIgeG1sbnM6ZHNwPTNEImh0dHA6 Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludD0NCj4gL2RzcCIgeG1sbnM6dWRjPTNE Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZGF0YS91ZGMiIHhtbG5zOnhzZD0zRCJodHRw PQ0KPiA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hIiB4bWxuczpzdWI9M0QiaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9zaGE9DQo+IHJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRzLyIg eG1sbnM6ZWM9M0QiaHR0cDovL3d3dy53My5vcmcvMjAwMS8wNC94bWxlbmMjIj0NCj4gIHhtbG5z OnNwPTNEImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNw cz0zRCJodHRwOi8vPQ0KPiBzY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwLyIg eG1sbnM6eHNpPTNEImh0dHA6Ly93d3cudzMub3JnLzIwMDE9DQo+IC9YTUxTY2hlbWEtaW5zdGFu Y2UiIHhtbG5zOnVkY3M9M0QiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9z bz0NCj4gYXAiIHhtbG5zOnVkY3hmPTNEImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vZGF0 YS91ZGMveG1sZmlsZSIgeG1sbnM6dWRjPQ0KPiBwMnA9M0QiaHR0cDovL3NjaGVtYXMubWljcm9z b2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3Zj0zRCJodHRwOi89DQo+IC9zY2hl bWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL3dvcmtmbG93LyIgeG1sbnM6ZHNzcz0z RCJodHRwOi8vc2NoZT0NCj4gbWFzLm1pY3Jvc29mdC5jb20vb2ZmaWNlLzIwMDYvZGlnc2lnLXNl dHVwIiB4bWxuczpkc3NpPTNEImh0dHA6Ly9zY2hlbWFzLm1pPQ0KPiBjcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPTNEImh0dHA6Ly9zY2hlbWFzLm9wZW54bWxmb3Jt YXQ9DQo+IHMub3JnL3BhY2thZ2UvMjAwNi9kaWdpdGFsLXNpZ25hdHVyZSIgeG1sbnM6bXZlcj0z RCJodHRwOi8vc2NoZW1hcy5vcGVueG1sZj0NCj4gb3JtYXRzLm9yZy9tYXJrdXAtY29tcGF0aWJp bGl0eS8yMDA2IiB4bWxuczptPTNEImh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jPQ0KPiBvbS9v ZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxuczptcmVscz0zRCJodHRwOi8vc2NoZW1hcy5vcGVueG1s Zm9ybWF0cy5vcmcvcGE9DQo+IGNrYWdlLzIwMDYvcmVsYXRpb25zaGlwcyIgeG1sbnM6c3B3cD0z RCJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3dlYj0NCj4gcGFydHBhZ2VzIiB4bWxu czpleDEydD0zRCJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2V4Y2hhbmdlL3NlcnZpY2Vz LzIwPQ0KPiAwNi90eXBlcyIgeG1sbnM6ZXgxMm09M0QiaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0 LmNvbS9leGNoYW5nZS9zZXJ2aWNlcy8yMDA9DQo+IDYvbWVzc2FnZXMiIHhtbG5zOnBwdHNsPTNE Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaT0NCj4gZGVM aWJyYXJ5LyIgeG1sbnM6c3BzbD0zRCJodHRwOi8vbWljcm9zb2Z0LmNvbS93ZWJzZXJ2aWNlcy9T aGFyZVBvaW50UG9ydGFsPQ0KPiBTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpa PTNEInVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206IiB4bWxuczo9DQo+IHN0PTNEIiYjMTsiIHht bG5zPTNEImh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KPiA8aGVhZD4NCj4gPG1l dGEgaHR0cC1lcXVpdj0zRCJDb250ZW50LVR5cGUiIGNvbnRlbnQ9M0QidGV4dC9odG1sOyBjaGFy c2V0PTNEdXMtYXNjaWkiPQ0KPiA+DQo+IDxtZXRhIG5hbWU9M0QiR2VuZXJhdG9yIiBjb250ZW50 PTNEIk1pY3Jvc29mdCBXb3JkIDEyIChmaWx0ZXJlZCBtZWRpdW0pIj4NCj4gPHN0eWxlPjwhLS0N Cj4gLyogRm9udCBEZWZpbml0aW9ucyAqLw0KPiBAZm9udC1mYWNlDQo+ICAgICAgIHtmb250LWZh bWlseTpTaW1TdW47DQo+ICAgICAgIHBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KPiBA Zm9udC1mYWNlDQo+ICAgICAgIHtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCj4gICAgICAg cGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQo+IEBmb250LWZhY2UNCj4gICAgICAge2Zv bnQtZmFtaWx5OkNhbGlicmk7DQo+ICAgICAgIHBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0 O30NCj4gQGZvbnQtZmFjZQ0KPiAgICAgICB7Zm9udC1mYW1pbHk6U2ltU3VuOw0KPiAgICAgICBw YW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCj4gLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N Cj4gcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KPiAgICAgICB7bWFy Z2luOjBpbjsNCj4gICAgICAgbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KPiAgICAgICBmb250LXNp emU6MTEuMHB0Ow0KPiAgICAgICBmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N Cj4gYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KPiAgICAgICB7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KPiAgICAgICBjb2xvcjpibHVlOw0KPiAgICAgICB0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCj4gYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQo+ICAgICAgIHtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQo+ICAgICAgIGNvbG9yOnB1cnBsZTsNCj4gICAgICAgdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQo+IHByZQ0KPiAgICAgICB7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KPiAgICAgICBtc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7 DQo+ICAgICAgIG1hcmdpbjowaW47DQo+ICAgICAgIG1hcmdpbi1ib3R0b206LjAwMDFwdDsNCj4g ICAgICAgZm9udC1zaXplOjEwLjBwdDsNCj4gICAgICAgZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQo+IHNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCj4gICAgICAge21zby1zdHlsZS1uYW1l OiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCj4gICAgICAgbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KPiAgICAgICBtc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KPiAgICAgICBm b250LWZhbWlseToiQ291cmllciBOZXciO30NCj4gc3Bhbi5FbWFpbFN0eWxlMTkNCj4gICAgICAg e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KPiAgICAgICBmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KPiAgICAgICBjb2xvcjp3aW5kb3d0ZXh0O30NCj4gc3Bhbi5FbWFpbFN0 eWxlMjANCj4gICAgICAge21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KPiAgICAgICBm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KPiAgICAgICBjb2xvcjojMUY0OTdE O30NCj4gLk1zb0NocERlZmF1bHQNCj4gICAgICAge21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KPiAgICAgICBmb250LXNpemU6MTAuMHB0O30NCj4gQHBhZ2UgV29yZFNlY3Rpb24xDQo+ICAg ICAgIHtzaXplOjguNWluIDExLjBpbjsNCj4gICAgICAgbWFyZ2luOjEuMGluIDEuMjVpbiAxLjBp biAxLjI1aW47fQ0KPiBkaXYuV29yZFNlY3Rpb24xDQo+ICAgICAgIHtwYWdlOldvcmRTZWN0aW9u MTt9DQo+IC0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo+IDxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9M0QiZWRpdCIgc3BpZG1heD0zRCIxMDI2IiAvPg0KPiA8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCj4gPG86c2hhcGVsYXlvdXQgdjpleHQ9M0Qi ZWRpdCI+DQo+IDxvOmlkbWFwIHY6ZXh0PTNEImVkaXQiIGRhdGE9M0QiMSIgLz4NCj4gPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPiA8L2hlYWQ+DQo+IDxib2R5IGxhbmc9M0Qi RU4tVVMiIGxpbms9M0QiYmx1ZSIgdmxpbms9M0QicHVycGxlIj4NCj4gPGRpdiBjbGFzcz0zRCJX b3JkU2VjdGlvbjEiPg0KPiA8cCBjbGFzcz0zRCJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPTNEImNv bG9yOiMxRjQ5N0QiPkZvciB0aG9zZSBvZiB5b3Ugd2hvIHQ9DQo+IG91Y2ggdXBvbiBEYXRhIENl bnRlciBuZXR3b3JraW5nIG9yIHNlcnZlciB2aXJ0dWFsaXphdGlvbiwgYmUgaXQgT3ZlcmxheSwg Vj0NCj4gUE40REMsIG9yIEFwcGxpY2F0aW9uL1NvZnR3YXJlIGRyaXZlbiBDb250cm9sbGVyIGZv ciBEYXRhIENlbnRlciwgQWRkcmVzcyBSPQ0KPiBlc29sdXRpb24gaXMgc29tZXRoaW5nIERhdGEg Q2VudGVyIEdhdGV3YXlzDQo+ICAmbmJzcDt3aWxsIGVuY291bnRlciBiZWNhdXNlIGhvc3RzL2Fw cGxpY2F0aW9ucyBpbiBkYXRhIGNlbnRlcnMgZG8gY29tbXVuaT0NCj4gY2F0ZSB3aXRoIHBlZXJz IHdoaWNoIGFyZSBub3QgaW4gdGhlIHNhbWUgT3ZlcmxheSwgb3V0c2lkZSB0aGUgVlBOIGRvbWFp biwgPQ0KPiBvciBmcm9tIGdlbmVyYWwgcHVibGljLiBBUk1EIGhhcyBwdWJsaXNoZWQgaXRzIFdH IHByb2JsZW0gc3RhdGVtZW50IGRyYWZ0LiA9DQo+IFlvdXIgY29tbWVudHMgYW5kIHN1Z2dlc3Rp b25zIGFyZSBhcHByZWNpYXRlZA0KPiAgKHNlbmQgdG8gPGEgaHJlZj0zRCJtYWlsdG86YXJtZEBp ZXRmLm9yZyI+YXJtZEBpZXRmLm9yZzwvYT4pLiA8bzpwPjwvbzpwPjw9DQo+IC9zcGFuPjwvcD4N Cj4gPHAgY2xhc3M9M0QiTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0zRCJjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3BhPQ0KPiBuPjwvcD4NCj4gPHAgY2xhc3M9M0QiTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0zRCJjb2xvcjojMUY0OTdEIj5UaGFua3MsIExpbmRhIER1bmJhcjxvPQ0K PiA6cD48L286cD48L3NwYW4+PC9wPg0KPiA8cCBjbGFzcz0zRCJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPTNEImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGE9DQo+IG4+PC9wPg0K PiA8cCBjbGFzcz0zRCJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPTNEImNvbG9yOiMxRjQ5N0QiPi0t LS0tLS0tLS0tLS0tLS0tLS0tLS09DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcz0NCj4gcGFuPjwvcD4N Cj4gPHAgY2xhc3M9M0QiTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0zRCJjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3BhPQ0KPiBuPjwvcD4NCj4gPHAgY2xhc3M9M0QiTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCj4gPHByZT5BIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBh dmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyPQ0KPiBlY3Rvcmll cy4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQWRkcmVzcyBSZXNvbHV0aW9uIGZv ciBNYXNzaXZlIG49DQo+IHVtYmVycyBvZiBob3N0cyBpbiB0aGUgRGF0YSBjZW50ZXIgV29ya2lu ZyBHcm91cCBvZiB0aGUgSUVURi48bzpwPjwvbzpwPjwvcD0NCj4gcmU+DQo+IDxwcmU+PG86cD4m bmJzcDs8L286cD48L3ByZT4NCj4gPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgVGl0bGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzPQ0KPiBwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IFByb2JsZW0gU3RhdGVtZW50IGZvciBBUk1EPG86 cD48L289DQo+IDpwPjwvcHJlPg0KPiA8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyBBdXRob3IocykmbmJzcDsmbmJzcDsmbmJzcDs9DQo+ICZuYnNwOyZuYnNw OyZuYnNwOyA6IFRob21hcyBOYXJ0ZW48bzpwPjwvbzpwPjwvcHJlPg0KPiA8cHJlPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGaWxlbmFtZSZuYnNwOyZuYnNwOyZu YnNwOyY9DQo+IG5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogZHJhZnQtaWV0Zi1hcm1kLXByb2Js ZW0tc3RhdGVtZW50LTAwLnR4dDxvOnA+PC9vOj0NCj4gcD48L3ByZT4NCj4gPHByZT4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUGFnZXMmbmJzcDsmbmJzcDsmbmJz cDsmbmJzPQ0KPiBwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IDExPG86 cD48L286cD48L3ByZT4NCj4gPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgRGF0ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwPQ0KPiA7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogMjAxMS0xMC0xNzxvOnA+PC9vOnA+PC9wcmU+ DQo+IDxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCj4gPHByZT4mbmJzcDsmbmJzcDsgVGhp cyBkb2N1bWVudCBleGFtaW5lcyBpc3N1ZXMgcmVsYXRlZCB0byB0aGUgbWFzc2l2ZSBzY2FsPQ0K PiBpbmcgb2YgZGF0YTxvOnA+PC9vOnA+PC9wcmU+DQo+IDxwcmU+Jm5ic3A7Jm5ic3A7IGNlbnRl cnMuJm5ic3A7IE91ciBpbml0aWFsIHNjb3BlIGlzIHJlbGF0aXZlbHkgbmFycm93LiZuYj0NCj4g c3A7IFNwZWNpZmljYWxseSwgd2U8bzpwPjwvbzpwPjwvcHJlPg0KPiA8cHJlPiZuYnNwOyZuYnNw OyBmb2N1cyBvbiBhZGRyZXNzIHJlc29sdXRpb24gKEFSUCBhbmQgTkQpIHdpdGhpbiB0aGUgZGF0 YSA9DQo+IGNlbnRlci48bzpwPjwvbzpwPjwvcHJlPg0KPiA8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wcmU+DQo+IDxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCj4gPHByZT5BIFVSTCBmb3Ig dGhpcyBJbnRlcm5ldC1EcmFmdCBpczo8bzpwPjwvbzpwPjwvcHJlPg0KPiA8cHJlPjxhIGhyZWY9 M0QiaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1hcm1kLXBy b2JsZW09DQo+IC1zdGF0ZW1lbnQtMDAudHh0Ij5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1pZXRmLWFybWQtcHJvYj0NCj4gbGVtLXN0YXRlbWVudC0wMC50eHQ8L2E+ PG86cD48L286cD48L3ByZT4NCj4gPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPiA8cHJl PkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8 bzpwPjwvbzpwPjwvcHI9DQo+IGU+DQo+IDxwcmU+PGEgaHJlZj0zRCJmdHA6Ly9mdHAuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzLyI+ZnRwOi8vZnRwLmlldGYub3JnL2ludD0NCj4gZXJuZXQtZHJh ZnRzLzwvYT48bzpwPjwvbzpwPjwvcHJlPg0KPiA8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+ DQo+IDxwcmU+VGhpcyBJbnRlcm5ldC1EcmFmdCBjYW4gYmUgcmV0cmlldmVkIGF0OjxvOnA+PC9v OnA+PC9wcmU+DQo+IDxwcmU+PGEgaHJlZj0zRCJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWlldGYtYXJtZC1wcm9ibGVtLT0NCj4gc3RhdGVtZW50LTAwLnR4dCI+ZnRw Oi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWFybWQtcHJvYmxlPQ0K PiBtLXN0YXRlbWVudC0wMC50eHQ8L2E+PG86cD48L286cD48L3ByZT4NCj4gPHAgY2xhc3M9M0Qi TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCj4gPC9kaXY+DQo+IDwvYm9keT4NCj4g PC9odG1sPg0KPg0KPiAtLUJvdW5kYXJ5XyhJRF8yeFlFUWFiU0pVSmVYeGlvZ01KMGZRKS0tDQo+ DQo+IC0tQm91bmRhcnlfKElEX3BxeFpIT0ZYR0E2OWdKdWhMeUVHK0EpDQo+IENvbnRlbnQtaWQ6 IDwzMThEMzI4MkNGQ0QwQzQ1QThDOTkyODNGRjM4Mjg5QUBodWF3ZWkuY29tPg0KPiBDb250ZW50 LXR5cGU6IHRleHQvcGxhaW47IG5hbWU9QVRUMDAwMDEudHh0DQo+IENvbnRlbnQtdHJhbnNmZXIt ZW5jb2Rpbmc6IDdCSVQNCj4gQ29udGVudC1kaXNwb3NpdGlvbjogYXR0YWNobWVudDsgZmlsZW5h bWU9QVRUMDAwMDEudHh0OyBzaXplPTEyNzsNCj4gIGNyZWF0aW9uLWRhdGU9IkZyaSwgMDQgTm92 IDIwMTEgMTU6MzA6MzEgR01UIjsNCj4gIG1vZGlmaWNhdGlvbi1kYXRlPSJGcmksIDA0IE5vdiAy MDExIDE1OjMwOjMxIEdNVCINCj4gQ29udGVudC1kZXNjcmlwdGlvbjogQVRUMDAwMDEudHh0DQo+ DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGFy bWQgbWFpbGluZyBsaXN0DQo+IGFybWRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9hcm1kDQo+DQo+IC0tQm91bmRhcnlfKElEX3BxeFpIT0ZYR0E2OWdK dWhMeUVHK0EpLS0NCg== From xuxiaohu@huawei.com Tue Nov 15 18:03:41 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921C411E815B; Tue, 15 Nov 2011 18:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.514 X-Spam-Level: X-Spam-Status: No, score=-3.514 tagged_above=-999 required=5 tests=[AWL=1.885, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJsF3NXAw2Zm; Tue, 15 Nov 2011 18:03:37 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id F2BCF11E818E; Tue, 15 Nov 2011 18:03:36 -0800 (PST) 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 <0LUQ005KADORJ3@szxga03-in.huawei.com>; Wed, 16 Nov 2011 10:02:51 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ0061LDNZWM@szxga03-in.huawei.com>; Wed, 16 Nov 2011 10:02:51 +0800 (CST) Received: from szxeml207-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFB64641; Wed, 16 Nov 2011 10:02:51 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml207-edg.china.huawei.com (172.24.2.59) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 Nov 2011 10:02:47 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0323.003; Wed, 16 Nov 2011 10:02:45 +0800 Date: Wed, 16 Nov 2011 02:02:45 +0000 From: Xuxiaohu Subject: re: [armd] Need your action to review draft-ietf-armd-problem-statement-00.txt In-reply-to: X-Originating-IP: [172.24.2.41] To: Pedro Marques , Susan Hares Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BDE5@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [armd] Need your action to review draft-ietf-armd-problem-statement-00.txt Thread-index: AQHMo76d77GNeTc5a0yss6siAfODR5Wuu7sI X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120BEC36@dfweml506-mbx> <201111142042.pAEKg1h21336@magenta.juniper.net> <011101cca35e$a93be5b0$fbb3b110$@com> Cc: "l2vpn@ietf.org" , "sdnp@lucidvision.com" , Yakov Rekhter , L3VPN WG mailing list , "armd@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 02:03:41 -0000 The concept of an L2/L3 boundary is not useful if you assume that a VM can be placed in an arbitrary location. Anywhere you choose to put that "boundary": top-of-rack, aggregation, etc, you are likely to find that the boundary gets in the way of the VMs being able to be located anywhere. At least without causing traffic to cross the core twice which is a non-starter. Agree. So to actually solve the problem according to requirements one needs to get rid of the boundary and move to a solution that is all L2 or all L3. And ARP/ND is really not a relevant problem. With an "L2" solution tends to come the assumption that there is a single "isolation" domain... and a single subnet, which doesn't really cut it. "L3" and specially BGP-based IP/VPNs natively support the concept of direct traffic exchanges between different isolation domains, subject to policy. Even if you do decide to select an L2 approach that limits an application to a single isolation domain, the L2 mac information will need to be present at every switch where that L2 VLAN is present. If you follow an approach where there is core-interface to core-interface mac-learning (VXLAN for instance) then indeed you do have ARP broadcasts being used to update forwarding tables. But approaches such as EVPN can perform learning on the edge interface only eliminating the need to generate ARP broadcasts. It is entirely likely that the approaches that attempt to provide for large broadcast domains already contain a solution for L2 address discovery. Conversely it is rather unclear that you can address the ARP/ND scaling issue independently of the design of the L2 solution itself. Reasonable. However, the ARP cache mechanism is suitble for most MAC-forwarding based DCN solutions (e.g., VPLS) and much helpful for ARP broadcast reduction unless the L2VPN PE function is pushed to the physical server. Best regards, Xiaohu regards, Pedro. On Mon, Nov 14, 2011 at 10:20 PM, Susan Hares wrote: > Yakov: > > We are not trying to justify any definition we have, but to report what DC > operators have given as the problem in an OPS draft. > > In many ways, the text has been successful by having you comment on this > point so that operators can consider in depth this scenario. > > With all due respect to you as a grand master of word-smithing, let me > restate some of the argument so that I can attempt to inspire discussion. > > The "all" in this discussion indicates "all" within this domain which > crosses the VLANs in the text. The 802.1q VLAN mechanism provides some > scoping of broadcast and unicast for an L2 grouping. The IP Subset provides > a scoping for scoping for IP (L3 grouping). ARP maps the L2 grouping to the > l3 grouping. The growth in the number of nodes (VM or access) in the > combined groupings of mapped nodes are the problem. > > If you want to restrict nodes within this at L2 or L3, you must find a means > to determine the L2 grouping. The mapping of the IP to MAC Address is scoped > by the combination of L2/L3 grouping. > > So.. at some point the VM or the real nodes reach an "aggregation grouping" > at the access switch or the VMs forming an access switch. This grouping > point is stressed by the underlying growth of L2/L3 node combination. On the > ARMD BOF/List, Manish Karir (Merit) published a study in looking at the ARP > problem using VMs groupings. > > Some large scale operators stated the VM aggregation I described above did > not represent a case widely used. Therefore the discussion focused on the > deployed access switches, servers, and VMs as described in the text. Please > refer to past discussion from Igor G. on this list or his drafts on > solutions/problems. Also, you can refer to NANOG session on this. > > Yakov - let me know of I am unclear or just misunderstood your discussion > point. Linda, Manish, and Igor let me know if I was incorrect in anything I > said. > > Hopefully, I've given the discussion a push. If nothing else, it will > > Sue > > -----Original Message----- > From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf Of > Yakov Rekhter > Sent: Monday, November 14, 2011 3:42 PM > To: Linda Dunbar > Cc: l2vpn@ietf.org; sdnp@lucidvision.com; L3VPN WG mailing list; > armd@ietf.org; yakov@juniper.net; Pedro Marques > Subject: Re: [armd] Need your action to review > draft-ietf-armd-problem-statement-00.txt > > Linda, > >> Pedro, >> >> You are absolutely right that there is no ARP/ND scaling issue if IP >> can be extended to hosts. Even if IP can be extended to Access >> switches, there is not much ARP/ND issues. >> >> The draft lists down several common data center network designs, and >> states that some of the designs don't have ARP/ND scaling issues (but >> may have other issues for data centers). >> >> That is why I encourage people to read the draft and provides >> comments. > > From 4.2 of the draft: > > 4.2. Scenario 2: L3 Terminates at the Aggregation Switch > > In Scenario 2, the L3 network extends only to the aggregation > switches (or perhaps to routers that connect to the aggregation > switches). The aggregation switches (or the routers that connect to > multiple aggregation switches) could terminate multiple distinct IP > subnets (e.g., one per VLAN) or one large IP subnet. In order to let > hosts belonging to different IP subnets be placed under any access > switches, it is necessary for access switches to enable multiple > VLANs and aggregation switches to enable some VLANs (or subnets) over > many physical ports. This configuration breaks the confinement of > the VLAN's broadcast domain and makes it equivalent to all the access > switches being part of the same L2 broadcast domain (and IP subnet). > Thus, this configuration allows VMs to be moved to servers connected > to other access switches, but increases the size of the L2 broadcast > domain, which can lead to difficulties outlined below. > > This is the scenario that is used to justify the need for large L2 domain. > > The draft assumes that in order to move a given VM from one server to > another, where these two servers are connected to different access switches, > *all* the access switches must be configured with the VM's IP subnet, and > thus *all* the access switches must be part of the VM's L2 broadcast domain. > This is even if at any particular point in time the servers hosting all the > VMs of that IP subnet are connected to only a subset of these switches. But > is it truly necessary, or could the L2 broadcast domain span only the > switches connected to the servers that presently host VMs of the IP subnet ? > > Moreover, even if all the access switches need to be part of the same L2 > broadcast domain, the increase in the size of the L2 broadcast domain in the > above scenario is caused by the access switches, not by the number of VMs > per L2 domain. The difficulies mentioned in the last sentence of the quoted > paragraph are due to ARP, but ARP is generated by VMs, not by the access > switches. Given that, how the increase in the size of the L2 broadcast > domain *due solely to the access switches*, could increase the amount of ARP > traffic that routers have to process ? > > Yakov. > >> >> > -----Original Message----- >> > From: Pedro Marques [mailto:pedro.r.marques@gmail.com] >> > Sent: Wednesday, November 09, 2011 1:52 PM >> > To: Linda Dunbar >> > Cc: l2vpn@ietf.org; L3VPN WG mailing list; sdnp@lucidvision.com; >> > armd@ietf.org >> > Subject: Re: Need your action to review draft-ietf-armd-problem- >> > statement-00.txt >> > >> > Linda, >> > I'd like to point out that the problem does not need to be solved if >> > only IP connectivity is required. This I-D: >> > http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 >> > describes a solution in which address resolution is not required >> > irrespective of the location of the traffic destination. Simply put, >> > traffic can be routed at each hop. >> > >> > As per previous threads in this list, the concept of subnet which is >> > of no practical usefulness in this space. Since VMs can be randomly >> distributed across the network the subnet does not provide any >> > information aggregation value. Thus there is no need to do address >> > resolution. >> > >> > Pedro. >> > >> > On Wed, Nov 9, 2011 at 11:31 AM, Linda Dunbar >> > >> > wrote: >> > > For those of you who touch upon Data Center networking or server >> > > virtualization, be it Overlay, VPN4DC, or Application/Software >> > > driven Controller for Data Center, Address Resolution is something >> > > Data >> > Center >> > > Gateways will encounter because hosts/applications in data >> > > centers >> > do >> > > communicate with peers which are not in the same Overlay, outside >> > > the >> > VPN >> > > domain, or from general public. ARMD has published its WG problem >> > statement >> > > draft. Your comments and suggestions are appreciated (send to >> > > armd@ietf.org). >> > > >> > > >> > > >> > > Thanks, Linda Dunbar >> > > >> > > >> > > >> > > ------------------------------------------------------------------ >> > > --- >> > -------------- >> > > >> > > >> > > >> > > >> > > >> > > A New Internet-Draft is available from the on-line Internet-Drafts >> > > directories. This draft is a work item of the Address Resolution >> > > for >> > Massive >> > > numbers of hosts in the Data center Working Group of the IETF. >> > > >> > > >> > > >> > > Title : Problem Statement for ARMD >> > > >> > > Author(s) : Thomas Narten >> > > >> > > Filename : draft-ietf-armd-problem-statement-00.txt >> > > >> > > Pages : 11 >> > > >> > > Date : 2011-10-17 >> > > >> > > >> > > >> > > This document examines issues related to the massive scaling of >> > data >> > > >> > > centers. Our initial scope is relatively narrow. >> > > Specifically, >> > we >> > > >> > > focus on address resolution (ARP and ND) within the data center. >> > > >> > > >> > > >> > > >> > > >> > > A URL for this Internet-Draft is: >> > > >> > > http://www.ietf.org/internet-drafts/draft-ietf-armd-problem- >> > statement-00.txt >> > > >> > > >> > > >> > > Internet-Drafts are also available by anonymous FTP at: >> > > >> > > ftp://ftp.ietf.org/internet-drafts/ >> > > >> > > >> > > >> > > This Internet-Draft can be retrieved at: >> > > >> > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-armd-problem-stateme >> > > nt- >> > 00.txt >> > > >> > > >> > > _______________________________________________ armd mailing list armd@ietf.org https://www.ietf.org/mailman/listinfo/armd From linda.dunbar@huawei.com Tue Nov 15 18:16:29 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDE511E810A; Tue, 15 Nov 2011 18:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNB61oCxp4oC; Tue, 15 Nov 2011 18:16:28 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id CF4B221F8DEF; Tue, 15 Nov 2011 18:16:28 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ0033CEBFGC@usaga02-in.huawei.com>; Tue, 15 Nov 2011 20:16:28 -0600 (CST) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LUQ006O9EBFJF@usaga02-in.huawei.com>; Tue, 15 Nov 2011 20:16:27 -0600 (CST) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 15 Nov 2011 18:16:24 -0800 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Tue, 15 Nov 2011 18:16:02 -0800 Date: Wed, 16 Nov 2011 02:16:02 +0000 From: Linda Dunbar Subject: RE: Need your action to review draft-ietf-armd-problem-statement-00.txt In-reply-to: <201111151919.pAFJJJh74426@magenta.juniper.net> X-Originating-IP: [10.47.141.142] To: Yakov Rekhter Message-id: <4A95BA014132FF49AE685FAB4B9F17F6120C3809@dfweml506-mbx> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US, zh-CN Thread-topic: Need your action to review draft-ietf-armd-problem-statement-00.txt Thread-index: AQHMo8vVNnT5eJ8uDU6UO66dRJaZAJWvSePw X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> <201111151919.pAFJJJh74426@magenta.juniper.net> Cc: "l2vpn@ietf.org" , "sdnp@lucidvision.com" , L3VPN WG mailing list , "armd@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 02:16:29 -0000 Yakov, You are absolutely right. We will make sure it is properly captured in the document. Thanks, Linda > -----Original Message----- > > Should the overhead due to the broadcast unknown be considered as yet > another "pain point" associated with large L2 domains ? > > Yakov. > From xuxiaohu@huawei.com Tue Nov 15 19:24:11 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5EE11E809C; Tue, 15 Nov 2011 19:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.77 X-Spam-Level: X-Spam-Status: No, score=-1.77 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ob2Tcp76FL2j; Tue, 15 Nov 2011 19:24:11 -0800 (PST) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0305C11E8089; Tue, 15 Nov 2011 19:24:11 -0800 (PST) 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 <0LUQ00EJYHDDJG@szxga04-in.huawei.com>; Wed, 16 Nov 2011 11:22:25 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ00BQEHDDXF@szxga04-in.huawei.com>; Wed, 16 Nov 2011 11:22:25 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFA16627; Wed, 16 Nov 2011 11:22:25 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 Nov 2011 11:22:20 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml405-hub.china.huawei.com ([10.82.67.60]) with mapi id 14.01.0323.003; Wed, 16 Nov 2011 11:21:52 +0800 Date: Wed, 16 Nov 2011 03:22:13 +0000 From: Xuxiaohu Subject: re: Need your action to review draft-ietf-armd-problem-statement-00.txt In-reply-to: <4A95BA014132FF49AE685FAB4B9F17F6120C3809@dfweml506-mbx> X-Originating-IP: [172.24.2.41] To: Linda Dunbar , Yakov Rekhter Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BEA6@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: Need your action to review draft-ietf-armd-problem-statement-00.txt Thread-index: AQHMpAfDSj1Fik0WlEub2ME5FLnYWJWu1HW5 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> <201111151919.pAFJJJh74426@magenta.juniper.net> <4A95BA014132FF49AE685FAB4B9F17F6120C3809@dfweml506-mbx> Cc: "l2vpn@ietf.org" , "sdnp@lucidvision.com" , L3VPN WG mailing list , "armd@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 03:24:11 -0000 DQpCeSB0aGUgd2F5LCBJIGFsc28gbm90aWNlZCB0aGF0IHRoZSBNQUMgZm9yd2FyZGluZyB0YWJs ZSBzY2FsYWJpbGl0eSBpc3N1ZSBpcyBtZW50aW9uZWQgaW4gdGhlIEFSTUQgcHJvYmxlbSBzdGF0 ZW1lbnQgZG9jLiBTaG91bGQgd2UgZXh0ZW5kIHRoZSBjaGFydGVyIHNjb3BlIG9mIEFSTUQgV0cg b3IgcmUtZm9ybSB0aGUgRENPUFMgV0cgdG8gZGlzY3VzcyBzbyBtYW55IGNoYWxsZW5nZXMgYW5k IHJlcXVpcmVtZW50cyBpbiBkYXRhIGNlbnRlcnM/DQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBsMnZwbi1i b3VuY2VzQGlldGYub3JnIFtsMnZwbi1ib3VuY2VzQGlldGYub3JnXSC0+rHtIExpbmRhIER1bmJh ciBbbGluZGEuZHVuYmFyQGh1YXdlaS5jb21dDQq3osvNyrG85DogMjAxMcTqMTHUwjE2yNUgMTA6 MTYNCrW9OiBZYWtvdiBSZWtodGVyDQpDYzogbDJ2cG5AaWV0Zi5vcmc7IHNkbnBAbHVjaWR2aXNp b24uY29tOyBMM1ZQTiBXRyBtYWlsaW5nIGxpc3Q7IGFybWRAaWV0Zi5vcmcNCtb3zOI6IFJFOiBO ZWVkIHlvdXIgYWN0aW9uIHRvIHJldmlldyAgICAgIGRyYWZ0LWlldGYtYXJtZC1wcm9ibGVtLXN0 YXRlbWVudC0wMC50eHQNCg0KWWFrb3YsDQoNCllvdSBhcmUgYWJzb2x1dGVseSByaWdodC4gV2Ug d2lsbCBtYWtlIHN1cmUgaXQgaXMgcHJvcGVybHkgY2FwdHVyZWQgaW4gdGhlIGRvY3VtZW50Lg0K DQpUaGFua3MsIExpbmRhDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPg0KPiBT aG91bGQgdGhlIG92ZXJoZWFkIGR1ZSB0byB0aGUgYnJvYWRjYXN0IHVua25vd24gYmUgY29uc2lk ZXJlZCBhcyB5ZXQNCj4gYW5vdGhlciAicGFpbiBwb2ludCIgYXNzb2NpYXRlZCB3aXRoIGxhcmdl IEwyIGRvbWFpbnMgPw0KPg0KPiBZYWtvdi4NCj4NCg== From linda.dunbar@huawei.com Tue Nov 15 19:27:47 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D865811E80CC; Tue, 15 Nov 2011 19:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.004 X-Spam-Level: X-Spam-Status: No, score=-4.004 tagged_above=-999 required=5 tests=[AWL=-2.208, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rENoKzWDZ2q; Tue, 15 Nov 2011 19:27:47 -0800 (PST) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6338211E8081; Tue, 15 Nov 2011 19:27:47 -0800 (PST) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ003LZHMAGC@usaga02-in.huawei.com>; Tue, 15 Nov 2011 21:27:46 -0600 (CST) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LUQ00EF0HM9OQ@usaga02-in.huawei.com>; Tue, 15 Nov 2011 21:27:45 -0600 (CST) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 15 Nov 2011 19:27:42 -0800 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Tue, 15 Nov 2011 19:27:01 -0800 Date: Wed, 16 Nov 2011 03:27:33 +0000 From: Linda Dunbar Subject: RE: Need your action to review draft-ietf-armd-problem-statement-00.txt In-reply-to: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BEA6@szxeml525-mbs.china.huawei.com> X-Originating-IP: [10.47.141.142] To: Xuxiaohu , Yakov Rekhter Message-id: <4A95BA014132FF49AE685FAB4B9F17F6120C3940@dfweml506-mbx> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, zh-CN Thread-topic: Need your action to review draft-ietf-armd-problem-statement-00.txt Thread-index: AQHMpA7joFQ3R5rJREugHGM3mM6D1ZWu1wLA X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> <201111151919.pAFJJJh74426@magenta.juniper.net> <4A95BA014132FF49AE685FAB4B9F17F6120C3809@dfweml506-mbx> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BEA6@szxeml525-mbs.china.huawei.com> Cc: "l2vpn@ietf.org" , "sdnp@lucidvision.com" , L3VPN WG mailing list , "armd@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 03:27:48 -0000 WGlhb0h1LCANCg0KTUFDIGZvcndhcmRpbmcgdGFibGUgc2l6ZSBpc3N1ZXMgYXJlIGFkZHJlc3Nl ZCBieSBJRUVFODAyLjEuIFRoZXJlIGFyZSBzZXZlcmFsIHByb3Bvc2FscyB0aGVyZSB0YXJnZXRp bmcgYXQgdGhlIGlzc3Vlcy4gDQoNCkxpbmRhDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogWHV4aWFvaHUNCj4gU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAxNiwgMjAx MSAxMToyMiBBTQ0KPiBUbzogTGluZGEgRHVuYmFyOyBZYWtvdiBSZWtodGVyDQo+IENjOiBsMnZw bkBpZXRmLm9yZzsgc2RucEBsdWNpZHZpc2lvbi5jb207IEwzVlBOIFdHIG1haWxpbmcgbGlzdDsN Cj4gYXJtZEBpZXRmLm9yZw0KPiBTdWJqZWN0OiByZTogTmVlZCB5b3VyIGFjdGlvbiB0byByZXZp ZXcgZHJhZnQtaWV0Zi1hcm1kLXByb2JsZW0tDQo+IHN0YXRlbWVudC0wMC50eHQNCj4gDQo+IA0K PiBCeSB0aGUgd2F5LCBJIGFsc28gbm90aWNlZCB0aGF0IHRoZSBNQUMgZm9yd2FyZGluZyB0YWJs ZSBzY2FsYWJpbGl0eQ0KPiBpc3N1ZSBpcyBtZW50aW9uZWQgaW4gdGhlIEFSTUQgcHJvYmxlbSBz dGF0ZW1lbnQgZG9jLiBTaG91bGQgd2UgZXh0ZW5kDQo+IHRoZSBjaGFydGVyIHNjb3BlIG9mIEFS TUQgV0cgb3IgcmUtZm9ybSB0aGUgRENPUFMgV0cgdG8gZGlzY3VzcyBzbyBtYW55DQo+IGNoYWxs ZW5nZXMgYW5kIHJlcXVpcmVtZW50cyBpbiBkYXRhIGNlbnRlcnM/DQo+IA0KPiBCZXN0IHJlZ2Fy ZHMsDQo+IFhpYW9odQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ILeivP7IyzogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZyBbbDJ2cG4tYm91bmNlc0BpZXRmLm9y Z10gtPqx7SBMaW5kYQ0KPiBEdW5iYXIgW2xpbmRhLmR1bmJhckBodWF3ZWkuY29tXQ0KPiC3osvN yrG85DogMjAxMcTqMTHUwjE2yNUgMTA6MTYNCj4gtb06IFlha292IFJla2h0ZXINCj4gQ2M6IGwy dnBuQGlldGYub3JnOyBzZG5wQGx1Y2lkdmlzaW9uLmNvbTsgTDNWUE4gV0cgbWFpbGluZyBsaXN0 Ow0KPiBhcm1kQGlldGYub3JnDQo+INb3zOI6IFJFOiBOZWVkIHlvdXIgYWN0aW9uIHRvIHJldmll dyAgICAgIGRyYWZ0LWlldGYtYXJtZC1wcm9ibGVtLQ0KPiBzdGF0ZW1lbnQtMDAudHh0DQo+IA0K PiBZYWtvdiwNCj4gDQo+IFlvdSBhcmUgYWJzb2x1dGVseSByaWdodC4gV2Ugd2lsbCBtYWtlIHN1 cmUgaXQgaXMgcHJvcGVybHkgY2FwdHVyZWQgaW4NCj4gdGhlIGRvY3VtZW50Lg0KPiANCj4gVGhh bmtzLCBMaW5kYQ0KPiANCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPg0K PiA+IFNob3VsZCB0aGUgb3ZlcmhlYWQgZHVlIHRvIHRoZSBicm9hZGNhc3QgdW5rbm93biBiZSBj b25zaWRlcmVkIGFzIHlldA0KPiA+IGFub3RoZXIgInBhaW4gcG9pbnQiIGFzc29jaWF0ZWQgd2l0 aCBsYXJnZSBMMiBkb21haW5zID8NCj4gPg0KPiA+IFlha292Lg0KPiA+DQo= From xuxiaohu@huawei.com Tue Nov 15 19:37:44 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51CCB1F0C4B; Tue, 15 Nov 2011 19:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.771 X-Spam-Level: X-Spam-Status: No, score=-1.771 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67kbrdVb19nv; Tue, 15 Nov 2011 19:37:43 -0800 (PST) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 94A441F0C42; Tue, 15 Nov 2011 19:37:43 -0800 (PST) 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 <0LUQ00DKRHZL47@szxga03-in.huawei.com>; Wed, 16 Nov 2011 11:35:45 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LUQ00M83HZKX6@szxga03-in.huawei.com>; Wed, 16 Nov 2011 11:35:44 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id AFB72050; Wed, 16 Nov 2011 11:35:44 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 16 Nov 2011 11:35:39 +0800 Received: from SZXEML525-MBS.china.huawei.com ([169.254.8.177]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.003; Wed, 16 Nov 2011 11:35:38 +0800 Date: Wed, 16 Nov 2011 03:35:37 +0000 From: Xuxiaohu Subject: re: Need your action to review draft-ietf-armd-problem-statement-00.txt In-reply-to: <4A95BA014132FF49AE685FAB4B9F17F6120C3940@dfweml506-mbx> X-Originating-IP: [172.24.2.41] To: Linda Dunbar , Yakov Rekhter Message-id: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BEE9@szxeml525-mbs.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=gb2312 Content-language: zh-CN Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: Need your action to review draft-ietf-armd-problem-statement-00.txt Thread-index: AQHMpAfDSj1Fik0WlEub2ME5FLnYWJWu1HW5//98uoCAAIfTMw== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> <201111151919.pAFJJJh74426@magenta.juniper.net> <4A95BA014132FF49AE685FAB4B9F17F6120C3809@dfweml506-mbx> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BEA6@szxeml525-mbs.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F6120C3940@dfweml506-mbx> Cc: "l2vpn@ietf.org" , "sdnp@lucidvision.com" , L3VPN WG mailing list , "armd@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 03:37:44 -0000 DQpTbywgZGlkIHlvdSBtZWFuIHRoZSBkZXNjcmlwdGlvbiB0ZXh0IGZvciB0aGUgTUFDIHRhYmxl IHNjYWxhYmlsaXR5IGlzc3VlIHNob3VsZCBiZSByZW1vdmVkIGZyb20gdGhlIEFSTUQgcHJvYmxl bSBzdGF0ZW1lbnQgZG9jPw0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogTGluZGEgRHVuYmFyDQq3osvNyrG8 5DogMjAxMcTqMTHUwjE2yNUgMTE6MjcNCrW9OiBYdXhpYW9odTsgWWFrb3YgUmVraHRlcg0KQ2M6 IGwydnBuQGlldGYub3JnOyBzZG5wQGx1Y2lkdmlzaW9uLmNvbTsgTDNWUE4gV0cgbWFpbGluZyBs aXN0OyBhcm1kQGlldGYub3JnDQrW98ziOiBSRTogTmVlZCB5b3VyIGFjdGlvbiB0byByZXZpZXcg ICAgICBkcmFmdC1pZXRmLWFybWQtcHJvYmxlbS1zdGF0ZW1lbnQtMDAudHh0DQoNClhpYW9IdSwN Cg0KTUFDIGZvcndhcmRpbmcgdGFibGUgc2l6ZSBpc3N1ZXMgYXJlIGFkZHJlc3NlZCBieSBJRUVF ODAyLjEuIFRoZXJlIGFyZSBzZXZlcmFsIHByb3Bvc2FscyB0aGVyZSB0YXJnZXRpbmcgYXQgdGhl IGlzc3Vlcy4NCg0KTGluZGENCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBYdXhpYW9odQ0KPiBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDE2LCAyMDExIDExOjIyIEFN DQo+IFRvOiBMaW5kYSBEdW5iYXI7IFlha292IFJla2h0ZXINCj4gQ2M6IGwydnBuQGlldGYub3Jn OyBzZG5wQGx1Y2lkdmlzaW9uLmNvbTsgTDNWUE4gV0cgbWFpbGluZyBsaXN0Ow0KPiBhcm1kQGll dGYub3JnDQo+IFN1YmplY3Q6IHJlOiBOZWVkIHlvdXIgYWN0aW9uIHRvIHJldmlldyBkcmFmdC1p ZXRmLWFybWQtcHJvYmxlbS0NCj4gc3RhdGVtZW50LTAwLnR4dA0KPg0KPg0KPiBCeSB0aGUgd2F5 LCBJIGFsc28gbm90aWNlZCB0aGF0IHRoZSBNQUMgZm9yd2FyZGluZyB0YWJsZSBzY2FsYWJpbGl0 eQ0KPiBpc3N1ZSBpcyBtZW50aW9uZWQgaW4gdGhlIEFSTUQgcHJvYmxlbSBzdGF0ZW1lbnQgZG9j LiBTaG91bGQgd2UgZXh0ZW5kDQo+IHRoZSBjaGFydGVyIHNjb3BlIG9mIEFSTUQgV0cgb3IgcmUt Zm9ybSB0aGUgRENPUFMgV0cgdG8gZGlzY3VzcyBzbyBtYW55DQo+IGNoYWxsZW5nZXMgYW5kIHJl cXVpcmVtZW50cyBpbiBkYXRhIGNlbnRlcnM/DQo+DQo+IEJlc3QgcmVnYXJkcywNCj4gWGlhb2h1 DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gt6K8/sjLOiBs MnZwbi1ib3VuY2VzQGlldGYub3JnIFtsMnZwbi1ib3VuY2VzQGlldGYub3JnXSC0+rHtIExpbmRh DQo+IER1bmJhciBbbGluZGEuZHVuYmFyQGh1YXdlaS5jb21dDQo+ILeiy83KsbzkOiAyMDExxOox MdTCMTbI1SAxMDoxNg0KPiC1vTogWWFrb3YgUmVraHRlcg0KPiBDYzogbDJ2cG5AaWV0Zi5vcmc7 IHNkbnBAbHVjaWR2aXNpb24uY29tOyBMM1ZQTiBXRyBtYWlsaW5nIGxpc3Q7DQo+IGFybWRAaWV0 Zi5vcmcNCj4g1vfM4jogUkU6IE5lZWQgeW91ciBhY3Rpb24gdG8gcmV2aWV3ICAgICAgZHJhZnQt aWV0Zi1hcm1kLXByb2JsZW0tDQo+IHN0YXRlbWVudC0wMC50eHQNCj4NCj4gWWFrb3YsDQo+DQo+ IFlvdSBhcmUgYWJzb2x1dGVseSByaWdodC4gV2Ugd2lsbCBtYWtlIHN1cmUgaXQgaXMgcHJvcGVy bHkgY2FwdHVyZWQgaW4NCj4gdGhlIGRvY3VtZW50Lg0KPg0KPiBUaGFua3MsIExpbmRhDQo+DQo+ DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPg0KPiA+IFNob3VsZCB0aGUgb3Zl cmhlYWQgZHVlIHRvIHRoZSBicm9hZGNhc3QgdW5rbm93biBiZSBjb25zaWRlcmVkIGFzIHlldA0K PiA+IGFub3RoZXIgInBhaW4gcG9pbnQiIGFzc29jaWF0ZWQgd2l0aCBsYXJnZSBMMiBkb21haW5z ID8NCj4gPg0KPiA+IFlha292Lg0KPiA+DQo= From david.i.allan@ericsson.com Tue Nov 15 21:00:21 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C2C1F0CD1; Tue, 15 Nov 2011 21:00:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.957 X-Spam-Level: X-Spam-Status: No, score=-3.957 tagged_above=-999 required=5 tests=[AWL=-2.161, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5w7AMpy1d5L; Tue, 15 Nov 2011 21:00:21 -0800 (PST) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 152C21F0CD0; Tue, 15 Nov 2011 21:00:20 -0800 (PST) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id pAG50D1j026365; Tue, 15 Nov 2011 23:00:15 -0600 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.64]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Wed, 16 Nov 2011 00:00:10 -0500 From: David Allan I To: Xuxiaohu , Linda Dunbar , Yakov Rekhter Date: Wed, 16 Nov 2011 00:00:07 -0500 Subject: RE: Need your action to review draft-ietf-armd-problem-statement-00.txt Thread-Topic: Need your action to review draft-ietf-armd-problem-statement-00.txt Thread-Index: AQHMpAfDSj1Fik0WlEub2ME5FLnYWJWu1HW5//98uoCAAIfTM4AAFySQ Message-ID: <60C093A41B5E45409A19D42CF7786DFD52272BF746@EUSAACMS0703.eamcs.ericsson.se> References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> <201111151919.pAFJJJh74426@magenta.juniper.net> <4A95BA014132FF49AE685FAB4B9F17F6120C3809@dfweml506-mbx> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BEA6@szxeml525-mbs.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F6120C3940@dfweml506-mbx> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BEE9@szxeml525-mbs.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE74BEE9@szxeml525-mbs.china.huawei.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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "l2vpn@ietf.org" , "sdnp@lucidvision.com" , L3VPN WG mailing list , "armd@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 05:00:21 -0000 SU1PIHRoZSBpc3N1ZSBpcyBhbHdheXMgaW4gdGhlIGV5ZXMgb2YgdGhlIGJlaG9sZGVyLiBJRiB3 ZSB3ZXJlIG9ubHkgYWJsZSB0byBldmVyIGRlcGxveSBPTkUgYm94IGluIHNjZW5hcmlvIDIgdGhl cmUgd291bGQgYmUgYW4gaXNzdWUuIEZvcnR1bmF0ZWx5IHdlIGRvIG5vdCBoYXZlIHN1Y2ggYW4g aXJyYXRpb25hbCBsaW1pdGF0aW9uLiBTbyB0aGVyZSBhcmUgb2J2aW91cyBhbmQgdHJpdmlhbCBz b2x1dGlvbnMgdG8gYWRkcmVzc2luZyBNQUMgc2NhbGFiaWxpdHkgb24gYSBzaW5nbGUgcGxhdGZv cm0sIGRlcGxveSBtb3JlIHRoYW4gb25lIGJveCENCg0KU28gaWYgd2Ugd2FudCB0byBmaW5kIHRo aW5ncyB0byB3b3JyeSBhYm91dCwgcGVyaGFwcyB3ZSBzaG91bGQgY2FzdCBvdXIgbmV0cyBlbHNl d2hlcmUuLi4NCg0KRGF2ZQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbDJ2 cG4tYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBYdXhpYW9odQ0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAxNiwgMjAxMSAxMToz NiBBTQ0KVG86IExpbmRhIER1bmJhcjsgWWFrb3YgUmVraHRlcg0KQ2M6IGwydnBuQGlldGYub3Jn OyBzZG5wQGx1Y2lkdmlzaW9uLmNvbTsgTDNWUE4gV0cgbWFpbGluZyBsaXN0OyBhcm1kQGlldGYu b3JnDQpTdWJqZWN0OiByZTogTmVlZCB5b3VyIGFjdGlvbiB0byByZXZpZXcgZHJhZnQtaWV0Zi1h cm1kLXByb2JsZW0tc3RhdGVtZW50LTAwLnR4dA0KDQoNClNvLCBkaWQgeW91IG1lYW4gdGhlIGRl c2NyaXB0aW9uIHRleHQgZm9yIHRoZSBNQUMgdGFibGUgc2NhbGFiaWxpdHkgaXNzdWUgc2hvdWxk IGJlIHJlbW92ZWQgZnJvbSB0aGUgQVJNRCBwcm9ibGVtIHN0YXRlbWVudCBkb2M/DQoNCkJlc3Qg cmVnYXJkcywNClhpYW9odQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0Kt6K8/sjLOiBMaW5kYSBEdW5iYXINCreiy83KsbzkOiAyMDExxOoxMdTCMTbI1SAxMToyNw0K tb06IFh1eGlhb2h1OyBZYWtvdiBSZWtodGVyDQpDYzogbDJ2cG5AaWV0Zi5vcmc7IHNkbnBAbHVj aWR2aXNpb24uY29tOyBMM1ZQTiBXRyBtYWlsaW5nIGxpc3Q7IGFybWRAaWV0Zi5vcmcNCtb3zOI6 IFJFOiBOZWVkIHlvdXIgYWN0aW9uIHRvIHJldmlldyAgICAgIGRyYWZ0LWlldGYtYXJtZC1wcm9i bGVtLXN0YXRlbWVudC0wMC50eHQNCg0KWGlhb0h1LA0KDQpNQUMgZm9yd2FyZGluZyB0YWJsZSBz aXplIGlzc3VlcyBhcmUgYWRkcmVzc2VkIGJ5IElFRUU4MDIuMS4gVGhlcmUgYXJlIHNldmVyYWwg cHJvcG9zYWxzIHRoZXJlIHRhcmdldGluZyBhdCB0aGUgaXNzdWVzLg0KDQpMaW5kYQ0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFh1eGlhb2h1DQo+IFNlbnQ6IFdlZG5l c2RheSwgTm92ZW1iZXIgMTYsIDIwMTEgMTE6MjIgQU0NCj4gVG86IExpbmRhIER1bmJhcjsgWWFr b3YgUmVraHRlcg0KPiBDYzogbDJ2cG5AaWV0Zi5vcmc7IHNkbnBAbHVjaWR2aXNpb24uY29tOyBM M1ZQTiBXRyBtYWlsaW5nIGxpc3Q7IA0KPiBhcm1kQGlldGYub3JnDQo+IFN1YmplY3Q6IHJlOiBO ZWVkIHlvdXIgYWN0aW9uIHRvIHJldmlldyBkcmFmdC1pZXRmLWFybWQtcHJvYmxlbS0gDQo+IHN0 YXRlbWVudC0wMC50eHQNCj4NCj4NCj4gQnkgdGhlIHdheSwgSSBhbHNvIG5vdGljZWQgdGhhdCB0 aGUgTUFDIGZvcndhcmRpbmcgdGFibGUgc2NhbGFiaWxpdHkgDQo+IGlzc3VlIGlzIG1lbnRpb25l ZCBpbiB0aGUgQVJNRCBwcm9ibGVtIHN0YXRlbWVudCBkb2MuIFNob3VsZCB3ZSBleHRlbmQgDQo+ IHRoZSBjaGFydGVyIHNjb3BlIG9mIEFSTUQgV0cgb3IgcmUtZm9ybSB0aGUgRENPUFMgV0cgdG8g ZGlzY3VzcyBzbyANCj4gbWFueSBjaGFsbGVuZ2VzIGFuZCByZXF1aXJlbWVudHMgaW4gZGF0YSBj ZW50ZXJzPw0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+IFhpYW9odQ0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ILeivP7IyzogbDJ2cG4tYm91bmNlc0BpZXRmLm9y ZyBbbDJ2cG4tYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBMaW5kYSBEdW5iYXIgDQo+IFtsaW5kYS5k dW5iYXJAaHVhd2VpLmNvbV0NCj4gt6LLzcqxvOQ6IDIwMTHE6jEx1MIxNsjVIDEwOjE2DQo+ILW9 OiBZYWtvdiBSZWtodGVyDQo+IENjOiBsMnZwbkBpZXRmLm9yZzsgc2RucEBsdWNpZHZpc2lvbi5j b207IEwzVlBOIFdHIG1haWxpbmcgbGlzdDsgDQo+IGFybWRAaWV0Zi5vcmcNCj4g1vfM4jogUkU6 IE5lZWQgeW91ciBhY3Rpb24gdG8gcmV2aWV3ICAgICAgZHJhZnQtaWV0Zi1hcm1kLXByb2JsZW0t DQo+IHN0YXRlbWVudC0wMC50eHQNCj4NCj4gWWFrb3YsDQo+DQo+IFlvdSBhcmUgYWJzb2x1dGVs eSByaWdodC4gV2Ugd2lsbCBtYWtlIHN1cmUgaXQgaXMgcHJvcGVybHkgY2FwdHVyZWQgaW4gDQo+ IHRoZSBkb2N1bWVudC4NCj4NCj4gVGhhbmtzLCBMaW5kYQ0KPg0KPg0KPiA+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+ID4NCj4gPiBTaG91bGQgdGhlIG92ZXJoZWFkIGR1ZSB0byB0aGUg YnJvYWRjYXN0IHVua25vd24gYmUgY29uc2lkZXJlZCBhcyANCj4gPiB5ZXQgYW5vdGhlciAicGFp biBwb2ludCIgYXNzb2NpYXRlZCB3aXRoIGxhcmdlIEwyIGRvbWFpbnMgPw0KPiA+DQo+ID4gWWFr b3YuDQo+ID4NCg== From warren@kumari.net Sat Nov 19 09:41:02 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C894021F86EC; Sat, 19 Nov 2011 09:41:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.077 X-Spam-Level: X-Spam-Status: No, score=-105.077 tagged_above=-999 required=5 tests=[AWL=-0.322, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, J_CHICKENPOX_13=0.6, J_CHICKENPOX_32=0.6, J_CHICKENPOX_61=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cUXTVQEVPJI; Sat, 19 Nov 2011 09:41:01 -0800 (PST) Received: from vimes.kumari.net (vimes.kumari.net [198.186.192.250]) by ietfa.amsl.com (Postfix) with ESMTP id 4B89221F86DD; Sat, 19 Nov 2011 09:41:00 -0800 (PST) Received: from [10.242.59.163] (mbc0f36d0.tmodns.net [208.54.15.188]) by vimes.kumari.net (Postfix) with ESMTPSA id 7F7C61B404C7; Sat, 19 Nov 2011 12:40:32 -0500 (EST) Subject: Re: [armd] Need your action to review draft-ietf-armd-problem-statement-00.txt Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Warren Kumari In-Reply-To: <00b601cca3c8$7c40ccf0$74c266d0$@com> Date: Sat, 19 Nov 2011 20:32:19 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4D8C72F8-D64F-4707-9AA0-A3E9CA487127@kumari.net> References: <4A95BA014132FF49AE685FAB4B9F17F6120BEBC6@dfweml506-mbx> <4A95BA014132FF49AE685FAB4B9F17F6120BEC36@dfweml506-mbx> <201111142042.pAEKg1h21336@magenta.juniper.net> <011101cca35e$a93be5b0$fbb3b110$@com> <00b601cca3c8$7c40ccf0$74c266d0$@com> To: Susan Hares X-Mailer: Apple Mail (2.1084) X-Mailman-Approved-At: Sat, 19 Nov 2011 17:49:14 -0800 Cc: l2vpn@ietf.org, sdnp@lucidvision.com, 'L3VPN WG mailing list' , armd@ietf.org, 'Yakov Rekhter' , 'Pedro Marques' X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2011 17:41:02 -0000 On Nov 16, 2011, at 2:57 AM, Susan Hares wrote: > Pedro:=20 >=20 > In all politeness, let me acknowledge your message. I will respond = after I > see if Igor (Yahoo) or other DC/Carrier operators will comment on = their > viewpoints. Commenting (onna plane back from NRT->SFO so expect some decoherence.) >=20 > Best wishes,=20 >=20 > Sue=20 >=20 > -----Original Message----- > From: Pedro Marques [mailto:pedro.r.marques@gmail.com]=20 > Sent: Tuesday, November 15, 2011 12:47 PM > To: Susan Hares > Cc: Yakov Rekhter; Linda Dunbar; l2vpn@ietf.org; sdnp@lucidvision.com; = L3VPN > WG mailing list; armd@ietf.org > Subject: Re: [armd] Need your action to review > draft-ietf-armd-problem-statement-00.txt >=20 > Sue, >=20 > I think the following statements capture a common configuration for > small / low-bandwidth (1g) / private DCs: > - VLANs are used for isolation. > - These vlans are locally scoped to a pair of aggregation switches. > - They are statically configured at the access switches. > - Traffic exchange between vlans is done at the aggregation switches > (often subject to service modules). >=20 > The above is not contentious, i presume. Nope, not contentious (I personally would have worded bullets 2 and 3 as = one ("configured on the switching infrastructure") to better cover the = folk who collapse the aggregation / access into one device, etc... >=20 > I think that everyone would also agree that: > - It is highly desirable to be able to have an application (a > process running on a server) to be placed in an arbitrary location of > the DC. (which conflicts with vlan locality). > - It is expected that the number of application processes that > participate in the same isolation domain will grow significantly (due > to external factors related to application design). > - It is expected that the bandwidth requirements for severs will > increase by an order of magnitude (along with higher server > utilization). >=20 > I hope we all agree so far. Mostly=85. I question bullet 2 and the relevance to the argument, but not = important... >=20 > Now from the 2 sets of premises above it does not directly follow that > the answer is to build larger and larger L2 domains. Fully, 100% agree. > I do understand > that to be a common perception but that is actually not necessary and > imho not useful. >=20 > The fundamental misconception is that the application processes (in a > VM or other wise) do need VLANs. They do not. They need connectivity; > both within an inner level of isolation (today's vlan) and to other > services in the data center (which today is routed often subject to > security policies). An example of the later would be a set of database > servers; database servers are often expensive and shared among > different applications. >=20 > In order to be able to place any VM anywhere, the VM needs to have > direct connectivity to multiple isolation domains. isolation domains > which are today modeled as L2 and isolation domains that are today > modeled as L3. >=20 > The concept of an L2/L3 boundary is not useful if you assume that a VM > can be placed in an arbitrary location. Anywhere you choose to put > that "boundary": top-of-rack, aggregation, etc, you are likely to find > that the boundary gets in the way of the VMs being able to be located > anywhere. At least without causing traffic to cross the core twice > which is a non-starter. Not quite sure where the "crossing the core twice" pops up, but sure... >=20 > So to actually solve the problem according to requirements one needs > to get rid of the boundary and move to a solution that is all L2 or > all L3. Have to disagree here -- a hybrid approach with small L2 domains also = solves the issue. Not really pushing this, just a sayin'... > And ARP/ND is really not a relevant problem. In *this* design, with this set of problems and solutions, sure. If you have (e.g) already built your datacenter with 4 stinking huge L3 = (or L2) core switches and O(1000) ToR switches you may (do?) have ARP/ND = issues. Waving this away with the "Doctor, doctor" argument, while = tempting, doesn't actually solve the issue=85. >=20 > With an "L2" solution tends to come the assumption that there is a > single "isolation" domain... and a single subnet, which doesn't really > cut it. But, again, some folk have built to this design, and are familiar with = this design, and like this design, and have shown the ability to = actually operate this design at scale. It works for them and declaring = their design invalid because it doesn't match your (and, frankly my) = views of how to build things also doesn't cut it... > "L3" and specially BGP-based IP/VPNs natively support the > concept of direct traffic exchanges between different isolation > domains, subject to policy. As do many other overlay / tunneling solutions, and better design of end = applications (why exactly to customers purchasing VMs / machines in a = datacenter want all of their machines in the same "network"? Largely = because A: this is how they view the world and have the $$$ and B: some = of their apps want the things they talk to in the same subnet=85.) >=20 > Even if you do decide to select an L2 approach that limits an > application to a single isolation domain, the L2 mac information will > need to be present at every switch where that L2 VLAN is present. If > you follow an approach where there is core-interface to core-interface > mac-learning (VXLAN for instance) then indeed you do have ARP > broadcasts being used to update forwarding tables. But approaches such > as EVPN can perform learning on the edge interface only eliminating > the need to generate ARP broadcasts. >=20 > It is entirely likely that the approaches that attempt to provide for > large broadcast domains already contain a solution for L2 address > discovery. Conversely it is rather unclear that you can address the > ARP/ND scaling issue independently of the design of the L2 solution > itself. Hmmm. "unclear" is a squishy word -- I think that the ARP/ND scaling = issue *can* be addressed independently of the design of the L2 solution = -- for example, I can statically configure all ARP on all hosts in a = arbitrary large L2 domain... I guess in summary I largely agree with your mail, but feel that the ARP = scaling (and overlay ideas (and datacenter architecture)) questions are = worth addressing. While simply waving a magic wand and telling folk who have architectured = their datacenter as L2 that they are "doing it wrong" is fun (and Lord = knows I've done this and had some good fights^W debates with at least = one of the other active folk on this list) they may have valid reasons = for needing their design=85 W >=20 > regards, > Pedro. >=20 > On Mon, Nov 14, 2011 at 10:20 PM, Susan Hares wrote: >> Yakov: >>=20 >> We are not trying to justify any definition we have, but to report = what DC >> operators have given as the problem in an OPS draft. >>=20 >> In many ways, the text has been successful by having you comment on = this >> point so that operators can consider in depth this scenario. >>=20 >> With all due respect to you as a grand master of word-smithing, let = me >> restate some of the argument so that I can attempt to inspire = discussion. >>=20 >> The "all" in this discussion indicates "all" within this domain which >> crosses the VLANs in the text. The 802.1q VLAN mechanism provides = some >> scoping of broadcast and unicast for an L2 grouping. The IP Subset > provides >> a scoping for scoping for IP (L3 grouping). ARP maps the L2 grouping = to > the >> l3 grouping. The growth in the number of nodes (VM or access) in the >> combined groupings of mapped nodes are the problem. >>=20 >> If you want to restrict nodes within this at L2 or L3, you must find = a > means >> to determine the L2 grouping. The mapping of the IP to MAC Address is > scoped >> by the combination of L2/L3 grouping. >>=20 >> So.. at some point the VM or the real nodes reach an "aggregation > grouping" >> at the access switch or the VMs forming an access switch. This = grouping >> point is stressed by the underlying growth of L2/L3 node combination. = On > the >> ARMD BOF/List, Manish Karir (Merit) published a study in looking at = the > ARP >> problem using VMs groupings. >>=20 >> Some large scale operators stated the VM aggregation I described = above did >> not represent a case widely used. Therefore the discussion focused on = the >> deployed access switches, servers, and VMs as described in the text. > Please >> refer to past discussion from Igor G. on this list or his drafts on >> solutions/problems. Also, you can refer to NANOG session on this. >>=20 >> Yakov - let me know of I am unclear or just misunderstood your = discussion >> point. Linda, Manish, and Igor let me know if I was incorrect in = anything > I >> said. >>=20 >> Hopefully, I've given the discussion a push. If nothing else, it will >>=20 >> Sue >>=20 >> -----Original Message----- >> From: armd-bounces@ietf.org [mailto:armd-bounces@ietf.org] On Behalf = Of >> Yakov Rekhter >> Sent: Monday, November 14, 2011 3:42 PM >> To: Linda Dunbar >> Cc: l2vpn@ietf.org; sdnp@lucidvision.com; L3VPN WG mailing list; >> armd@ietf.org; yakov@juniper.net; Pedro Marques >> Subject: Re: [armd] Need your action to review >> draft-ietf-armd-problem-statement-00.txt >>=20 >> Linda, >>=20 >>> Pedro, >>>=20 >>> You are absolutely right that there is no ARP/ND scaling issue if IP >>> can be extended to hosts. Even if IP can be extended to Access >>> switches, there is not much ARP/ND issues. >>>=20 >>> The draft lists down several common data center network designs, and >>> states that some of the designs don't have ARP/ND scaling issues = (but >>> may have other issues for data centers). >>>=20 >>> That is why I encourage people to read the draft and provides >>> comments. >>=20 >> =46rom 4.2 of the draft: >>=20 >> 4.2. Scenario 2: L3 Terminates at the Aggregation Switch >>=20 >> In Scenario 2, the L3 network extends only to the aggregation >> switches (or perhaps to routers that connect to the aggregation >> switches). The aggregation switches (or the routers that connect = to >> multiple aggregation switches) could terminate multiple distinct IP >> subnets (e.g., one per VLAN) or one large IP subnet. In order to = let >> hosts belonging to different IP subnets be placed under any access >> switches, it is necessary for access switches to enable multiple >> VLANs and aggregation switches to enable some VLANs (or subnets) = over >> many physical ports. This configuration breaks the confinement of >> the VLAN's broadcast domain and makes it equivalent to all the = access >> switches being part of the same L2 broadcast domain (and IP = subnet). >> Thus, this configuration allows VMs to be moved to servers = connected >> to other access switches, but increases the size of the L2 = broadcast >> domain, which can lead to difficulties outlined below. >>=20 >> This is the scenario that is used to justify the need for large L2 = domain. >>=20 >> The draft assumes that in order to move a given VM from one server to >> another, where these two servers are connected to different access > switches, >> *all* the access switches must be configured with the VM's IP subnet, = and >> thus *all* the access switches must be part of the VM's L2 broadcast > domain. >> This is even if at any particular point in time the servers hosting = all > the >> VMs of that IP subnet are connected to only a subset of these = switches. > But >> is it truly necessary, or could the L2 broadcast domain span only the >> switches connected to the servers that presently host VMs of the IP = subnet > ? >>=20 >> Moreover, even if all the access switches need to be part of the same = L2 >> broadcast domain, the increase in the size of the L2 broadcast domain = in > the >> above scenario is caused by the access switches, not by the number of = VMs >> per L2 domain. The difficulies mentioned in the last sentence of the > quoted >> paragraph are due to ARP, but ARP is generated by VMs, not by the = access >> switches. Given that, how the increase in the size of the L2 = broadcast >> domain *due solely to the access switches*, could increase the amount = of > ARP >> traffic that routers have to process ? >>=20 >> Yakov. >>=20 >>>=20 >>>> -----Original Message----- >>>> From: Pedro Marques [mailto:pedro.r.marques@gmail.com] >>>> Sent: Wednesday, November 09, 2011 1:52 PM >>>> To: Linda Dunbar >>>> Cc: l2vpn@ietf.org; L3VPN WG mailing list; sdnp@lucidvision.com; >>>> armd@ietf.org >>>> Subject: Re: Need your action to review draft-ietf-armd-problem- >>>> statement-00.txt >>>>=20 >>>> Linda, >>>> I'd like to point out that the problem does not need to be solved = if >>>> only IP connectivity is required. This I-D: >>>> http://tools.ietf.org/html/draft-marques-l3vpn-end-system-02 >>>> describes a solution in which address resolution is not required >>>> irrespective of the location of the traffic destination. Simply = put, >>>> traffic can be routed at each hop. >>>>=20 >>>> As per previous threads in this list, the concept of subnet which = is >>>> of no practical usefulness in this space. Since VMs can be randomly >>> distributed across the network the subnet does not provide any >>>> information aggregation value. Thus there is no need to do address >>>> resolution. >>>>=20 >>>> Pedro. >>>>=20 >>>> On Wed, Nov 9, 2011 at 11:31 AM, Linda Dunbar >>>> >>>> wrote: >>>>> For those of you who touch upon Data Center networking or server >>>>> virtualization, be it Overlay, VPN4DC, or Application/Software >>>>> driven Controller for Data Center, Address Resolution is something >>>>> Data >>>> Center >>>>> Gateways will encounter because hosts/applications in data >>>>> centers >>>> do >>>>> communicate with peers which are not in the same Overlay, outside >>>>> the >>>> VPN >>>>> domain, or from general public. ARMD has published its WG problem >>>> statement >>>>> draft. Your comments and suggestions are appreciated (send to >>>>> armd@ietf.org). >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Thanks, Linda Dunbar >>>>>=20 >>>>>=20 >>>>>=20 >>>>> ------------------------------------------------------------------ >>>>> --- >>>> -------------- >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. This draft is a work item of the Address Resolution >>>>> for >>>> Massive >>>>> numbers of hosts in the Data center Working Group of the IETF. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Title : Problem Statement for ARMD >>>>>=20 >>>>> Author(s) : Thomas Narten >>>>>=20 >>>>> Filename : draft-ietf-armd-problem-statement-00.txt >>>>>=20 >>>>> Pages : 11 >>>>>=20 >>>>> Date : 2011-10-17 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> This document examines issues related to the massive scaling of >>>> data >>>>>=20 >>>>> centers. Our initial scope is relatively narrow. >>>>> Specifically, >>>> we >>>>>=20 >>>>> focus on address resolution (ARP and ND) within the data = center. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> A URL for this Internet-Draft is: >>>>>=20 >>>>> http://www.ietf.org/internet-drafts/draft-ietf-armd-problem- >>>> statement-00.txt >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>=20 >>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> This Internet-Draft can be retrieved at: >>>>>=20 >>>>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-armd-problem-stateme >>>>> nt- >>>> 00.txt >>>>>=20 >>>>>=20 >>>=20 >>=20 >>=20 >=20 > _______________________________________________ > armd mailing list > armd@ietf.org > https://www.ietf.org/mailman/listinfo/armd >=20 From jasmeetbagga@gmail.com Wed Nov 23 08:55:13 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB5511E807F for ; Wed, 23 Nov 2011 08:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 779B7-z75tjz for ; Wed, 23 Nov 2011 08:55:12 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C397921F8B6E for ; Wed, 23 Nov 2011 08:55:12 -0800 (PST) Received: by vbbez10 with SMTP id ez10so1783189vbb.31 for ; Wed, 23 Nov 2011 08:55:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=TlTUNFhYdBZ6UWPovdRm6e/R5ZX+4pylzlUIYRuDosU=; b=oCrSO60gHFlnVhqjtcaYfgXkQAOGHUHbf2gE1Ub3MsfJyouAxchh8O2daSBdzjvQor gzdOGCSrp6V1LX5B7cr7dBuD3RHckoTViCcTXsQVkSaNAPSDMcUV9OyDwK62XLFmnKOK mWsWfMSQ35zNaDl8CEor5ZAEeV2u8nL7es054= MIME-Version: 1.0 Received: by 10.182.193.99 with SMTP id hn3mr4982661obc.61.1322067311190; Wed, 23 Nov 2011 08:55:11 -0800 (PST) Received: by 10.182.16.202 with HTTP; Wed, 23 Nov 2011 08:55:11 -0800 (PST) Date: Wed, 23 Nov 2011 08:55:11 -0800 Message-ID: Subject: draft-raggarwa-sajassi-l2vpn-evpn-04, Designated forwarder vs Split Horizon From: Jasmeet Bagga To: l2vpn@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 16:55:13 -0000 Hi, The draft mentioned in ${SUBJECT} enlists 2 mechanisms (designated forwarder and split horizon) for preventing multicast, broadcast and unknown unicast traffic originated by multihomed CE from being forwarded back to the CE. Both these mechanism cause the MES to not forward the traffic onto the ethernet segment that the data originated from. My question is why do we need two mechanisms ? Both split horizon and designated forwarder seem to be individually capable of handling the above requirement ? I am sure I am missing something here. If so please advise. Thanks, Jasmeet From florin.balus@alcatel-lucent.com Wed Nov 23 09:28:03 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1542021F8AA8 for ; Wed, 23 Nov 2011 09:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.119 X-Spam-Level: X-Spam-Status: No, score=-6.119 tagged_above=-999 required=5 tests=[AWL=0.480, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hQU1EduOe0Z for ; Wed, 23 Nov 2011 09:28:02 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 82AF321F8A91 for ; Wed, 23 Nov 2011 09:28:02 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id pANHRvS7004699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Nov 2011 11:27:57 -0600 (CST) Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pANHRudK009704 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 23 Nov 2011 11:27:56 -0600 Received: from USNAVSXCHMBSC3.ndc.alcatel-lucent.com ([135.3.39.144]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Wed, 23 Nov 2011 11:27:56 -0600 From: "Balus, Florin Stelian (Florin)" To: Jasmeet Bagga Date: Wed, 23 Nov 2011 11:27:53 -0600 Subject: Re: draft-raggarwa-sajassi-l2vpn-evpn-04, Designated forwarder vs Split Horizon Thread-Topic: draft-raggarwa-sajassi-l2vpn-evpn-04, Designated forwarder vs Split Horizon Thread-Index: AcyqBT0pLpp596C3TKC+Et4RCBiiUg== Message-ID: <24EA05F7-9653-4B1A-AF00-ACFFDB1F3C28@alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 17:28:03 -0000 Split horizon label ensures that a BUM packet received from the non-DF is n= ot flooded back via the DF to the originator CE. On Nov 23, 2011, at 8:56 AM, "Jasmeet Bagga" wrote= : > Hi, >=20 > The draft mentioned in ${SUBJECT} enlists 2 mechanisms (designated forwar= der > and split horizon) for preventing multicast, broadcast and unknown > unicast traffic > originated by multihomed CE from being forwarded back to the CE. Both th= ese > mechanism cause the MES to not forward the traffic onto the ethernet segm= ent > that the data originated from. My question is why do we need two mechanis= ms ? > Both split horizon and designated forwarder seem to be individually capab= le of > handling the above requirement ? >=20 > I am sure I am missing something here. If so please advise. >=20 > Thanks, > Jasmeet From jasmeetbagga@gmail.com Wed Nov 23 12:16:49 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD96211E8103 for ; Wed, 23 Nov 2011 12:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gg3ROd23Q9vz for ; Wed, 23 Nov 2011 12:16:49 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 02B8011E80BB for ; Wed, 23 Nov 2011 12:16:48 -0800 (PST) Received: by vbbez10 with SMTP id ez10so2033133vbb.31 for ; Wed, 23 Nov 2011 12:16:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/BlMGNC98QmwHi4fW2Q3Dq0D8rVZcMjdGZi9VWyxy2g=; b=lDiQjg8k4ySxaImEtQAKKQlu4xqHxqDllCFB03KOWhmeOnebNTgX/hNpNXHgIipVM9 8+jIZvCvIh0Cc4sXg4Y6fWvj4pupjuMjlYlOrhwtywIsVM549SRNNeCl/qaURJLd9F2a TELeI3r64nUxZgRsIbOH1PmuQD/X9MjNoVwQ4= MIME-Version: 1.0 Received: by 10.182.188.34 with SMTP id fx2mr8835676obc.31.1322079408255; Wed, 23 Nov 2011 12:16:48 -0800 (PST) Received: by 10.182.16.202 with HTTP; Wed, 23 Nov 2011 12:16:48 -0800 (PST) In-Reply-To: <24EA05F7-9653-4B1A-AF00-ACFFDB1F3C28@alcatel-lucent.com> References: <24EA05F7-9653-4B1A-AF00-ACFFDB1F3C28@alcatel-lucent.com> Date: Wed, 23 Nov 2011 12:16:48 -0800 Message-ID: Subject: Re: draft-raggarwa-sajassi-l2vpn-evpn-04, Designated forwarder vs Split Horizon From: Jasmeet Bagga To: "Balus, Florin Stelian (Florin)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 20:16:49 -0000 Florin, Got it, thanks. Its probably a good idea to mention this case explicitly under the Split Horizon section. in the draft. For the other cases - BUM packets arriving at a multihomed MES from another MES not multihomed to the same CE - BUM packets arriving at a non-DF MES sent from the DF MES just dropping the packets at the non-DF seems enough. The draft sort of alludes to the case you mention but does not explicitly mention it. Thanks, Jasmeet On Wed, Nov 23, 2011 at 9:27 AM, Balus, Florin Stelian (Florin) wrote: > Split horizon label ensures that a BUM packet received from the non-DF is= not flooded back via the DF to the originator CE. > > On Nov 23, 2011, at 8:56 AM, "Jasmeet Bagga" wro= te: > >> Hi, >> >> The draft mentioned in ${SUBJECT} enlists 2 mechanisms (designated forwa= rder >> and =A0split horizon) for preventing multicast, broadcast and unknown >> unicast traffic >> originated by multihomed CE from being forwarded =A0back to the CE. Both= these >> mechanism cause the MES to not forward the traffic onto the ethernet seg= ment >> that the data originated from. My question is why do we need two mechani= sms ? >> Both split horizon and designated forwarder seem to be individually capa= ble of >> handling the above requirement ? >> >> I am sure I am missing something here. If so please advise. >> >> Thanks, >> Jasmeet > From aldrin.isaac@gmail.com Wed Nov 23 20:10:30 2011 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11BA821F84FB for ; Wed, 23 Nov 2011 20:10:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id on8rGtpaW8CD for ; Wed, 23 Nov 2011 20:10:29 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C28D121F84FD for ; Wed, 23 Nov 2011 20:10:27 -0800 (PST) Received: by vbbez10 with SMTP id ez10so2324845vbb.31 for ; Wed, 23 Nov 2011 20:09:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer; bh=Zz8wuHkXFQs1CjYVlwLf71OJOBl+xeNZ/gZFYYlFIgs=; b=K48Z0NcWBIPIsibB9rriHjfttECCNmnenQlMdTKnjrV7LFa42FctlpKWzxf6xZGg/w nF/xFAz7N8mTxDChcAFEYFqkNbi1+egMg0+X/auHj6s03TSeTQ65S2OrHqbkFWOziiie Q/ahPCogxlvHoc0ayW8mNGjMlzPYjLJBi8RR8= Received: by 10.52.90.77 with SMTP id bu13mr30038496vdb.34.1322107797635; Wed, 23 Nov 2011 20:09:57 -0800 (PST) Received: from mymac.home (ool-44c1c730.dyn.optonline.net. [68.193.199.48]) by mx.google.com with ESMTPS id c7sm27119117vdh.12.2011.11.23.20.09.53 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Nov 2011 20:09:54 -0800 (PST) Subject: Re: draft-raggarwa-sajassi-l2vpn-evpn-04, Designated forwarder vs Split Horizon Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_5B01FBA5-ED05-4CDA-9748-F74C566F7EE9" From: Aldrin Isaac In-Reply-To: Date: Wed, 23 Nov 2011 23:09:52 -0500 Message-Id: <6CD9E7C2-3926-4ADA-80C7-E21BE42CE8F7@gmail.com> References: <24EA05F7-9653-4B1A-AF00-ACFFDB1F3C28@alcatel-lucent.com> To: Jasmeet Bagga X-Mailer: Apple Mail (2.1251.1) Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Nov 2011 04:10:30 -0000 --Apple-Mail=_5B01FBA5-ED05-4CDA-9748-F74C566F7EE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Jasmeet, see my comments inline. On Nov 23, 2011, at 3:16 PM, Jasmeet Bagga wrote: > Florin, > Got it, thanks. > Its probably a good idea to mention this case explicitly under the > Split Horizon section. in the draft. > For the other cases > - BUM packets arriving at a multihomed MES from another MES not > multihomed to the same CE Currently some form of MLAG would be required for active-active = multihoming with a customer network across multiple CE. Other = possibilities are/need to be explored. > - BUM packets arriving at a non-DF MES sent from the DF MES > just dropping the packets at the non-DF seems enough. >=20 Yes -- see the following procedure for P2MP. 17.2. ESI MPLS Label: P2MP MPLS LSPs An MES that is using P2MP LSPs for sending broadcast, multicast or unknown unicast traffic, distributes to other MESes, that belong to the Ethernet segment or have an E-VPN in common with the Ethernet Segment, an upstream assigned "ESI MPLS label" in the Ethernet A-D route. This label is upstream assigned by the MES that advertises the route. This label MUST be programmed by the other MESes, that are connected to the ESI advertised in the route, in the context label space for the advertising MES. Further the forwarding entry for this label must result in NOT forwarding packets received with this label onto the Ethernet segment that the label was distributed for. This label MUST also be programmed by the other MESes, that import the route but are not connected to the ESI advertised in the route, in the context label space for the advertising MES. Further the forwarding entry for this label must be a POP with no other associated action. Another procedure exists for handling this for ingress replication. > The draft sort of alludes to the case you mention but does not > explicitly mention it. >=20 > Thanks, > Jasmeet >=20 > On Wed, Nov 23, 2011 at 9:27 AM, Balus, Florin Stelian (Florin) > wrote: >> Split horizon label ensures that a BUM packet received from the = non-DF is not flooded back via the DF to the originator CE. >>=20 >> On Nov 23, 2011, at 8:56 AM, "Jasmeet Bagga" = wrote: >>=20 >>> Hi, >>>=20 >>> The draft mentioned in ${SUBJECT} enlists 2 mechanisms (designated = forwarder >>> and split horizon) for preventing multicast, broadcast and unknown >>> unicast traffic >>> originated by multihomed CE from being forwarded back to the CE. = Both these >>> mechanism cause the MES to not forward the traffic onto the ethernet = segment >>> that the data originated from. My question is why do we need two = mechanisms ? >>> Both split horizon and designated forwarder seem to be individually = capable of >>> handling the above requirement ? >>>=20 >>> I am sure I am missing something here. If so please advise. >>>=20 >>> Thanks, >>> Jasmeet >>=20 --Apple-Mail=_5B01FBA5-ED05-4CDA-9748-F74C566F7EE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Jasmeet, see my comments inline.

On Nov 23, 2011, at = 3:16 PM, Jasmeet Bagga wrote:

Florin,
Got it, thanks.
Its probably a good = idea to mention this case explicitly under the
Split Horizon section. = in the draft.
For the other cases
- BUM packets arriving at a multihomed MES from = another MES not
multihomed to the same = CE

Currently some form of MLAG = would be required for active-active multihoming with a customer network = across multiple CE.  Other possibilities are/need to be = explored.


- BUM = packets arriving at a non-DF MES sent from the DF MES
just dropping = the packets at the non-DF seems = enough.


Yes -- see the = following procedure for P2MP.

17.2. ESI MPLS =
Label: P2MP MPLS LSPs


   An MES that is using P2MP LSPs for sending broadcast, multicast or
   unknown unicast traffic, distributes to other MESes, that belong to
   the Ethernet segment or have an E-VPN in common with the Ethernet
   Segment, an upstream assigned "ESI MPLS label" in the Ethernet A-D
   route. This label is upstream assigned by the MES that advertises the
   route. This label MUST be programmed by the other MESes, that are
   connected to the ESI advertised in the route, in the context label
   space for the advertising MES. Further the forwarding entry for this
   label must result in NOT forwarding packets received with this label
   onto the Ethernet segment that the label was distributed for. This
   label MUST also be programmed by the other MESes, that import the
   route but are not connected to the ESI advertised in the route, in
   the context label space for the advertising MES. Further the
   forwarding entry for this label must be a POP with no other
   associated action.

Another procedure exists = for handling this for ingress = replication.


The draft sort of alludes to the case you mention but = does not
explicitly mention it.

Thanks,
Jasmeet

On = Wed, Nov 23, 2011 at 9:27 AM, Balus, Florin Stelian (Florin)
<florin.balus@alcatel-lucen= t.com> wrote:
Split horizon label = ensures that a BUM packet received from the non-DF is not flooded back = via the DF to the originator CE.

On Nov 23, = 2011, at 8:56 AM, "Jasmeet Bagga" <jasmeetbagga@gmail.com> = wrote:

Hi,

The draft mentioned in = ${SUBJECT} enlists 2 mechanisms (designated = forwarder
and  split horizon) for = preventing multicast, broadcast and = unknown
unicast traffic
originated by multihomed CE from = being forwarded  back to the CE. Both = these
mechanism cause the MES to not forward the traffic onto = the ethernet segment
that the data originated from. = My question is why do we need two mechanisms = ?
Both split horizon and designated forwarder seem to be = individually capable of
handling the above requirement = ?

I am sure I am missing something = here. If so please advise.

Thanks,
Jasmeet


<= /html>= --Apple-Mail=_5B01FBA5-ED05-4CDA-9748-F74C566F7EE9--