From jorge.rabadan@alcatel-lucent.com Wed Nov 6 12:09:22 2013 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 82EF421E81A2 for ; Wed, 6 Nov 2013 12:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 uQmk2qClBAsu for ; Wed, 6 Nov 2013 12:09:13 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 095F921E818D for ; Wed, 6 Nov 2013 12:09:11 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id rA6K994K021855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 6 Nov 2013 14:09:10 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rA6K97Vs020978 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 6 Nov 2013 21:09:08 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.70]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 6 Nov 2013 21:09:08 +0100 From: "Rabadan, Jorge (Jorge)" To: "l2vpn@ietf.org" Subject: About draft-sajassi-l2vpn-evpn-vpls-integration-00 Thread-Topic: About draft-sajassi-l2vpn-evpn-vpls-integration-00 Thread-Index: AQHO2abn5Bvj2w9IKEq2BOsck9lkHJoYDekA Date: Wed, 6 Nov 2013 20:09:08 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-ID: <057787753C66F340910831596DEE18FF@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 20:09:22 -0000 Ali and draft authors, Some comments about the draft. General comments: 1) Very good draft and very well explained, as expected. The first thing that I thought when I was beginning to read it is that the draft proposed a sort of gateway function between EVPN and VPLS, which is not the case as later explained. I believe a diagram would help clarifying this to the reader. It would also help when describing what kind of multi-homing is expected to work or not. Specific comments: 2) Page 3: "When a (PBB-)EVPN PE receives both a VPLS AD route as well as an EVPN Inclusive Multicast route from a given remote PE for the same VPN instance, it MUST give preference to the EVPN route for the purpose of discovery." This is confusing. VPLS AD and EVPN incl. mcast routes belong to separate families, BGP will not compare them for any purposes. 3) Page 4 "- If a (PBB-)EVPN PE receives a VPLS AD route followed by an EVPN AD route from the same PE and a pseudowire is setup to that PE, then the (PBB-)EVPN PE MUST deactivate that pseudowire. - If a (PBB-)EVPN PE receives an EVPN AD route followed by a VPLS AD route from the same PE, then the (PBB-)EVPN PE MUST ignore the VPLS AD route." Suggested text: "- If a (PBB-)EVPN PE receives a VPLS AD route followed by an EVPN AD route from the same PE and a pseudowire is setup to that PE, then the (PBB-)EVPN PE MUST bring that pseudowire operationally down. - If a (PBB-)EVPN PE receives an EVPN AD route followed by a VPLS AD route from the same PE, then the (PBB-)EVPN PE will setup the pseudowire but MUST keep it operationally down" Reason: consistency. The same behavior must be observed for potential FEC128 pseudowires between (PBB-)EVPN PEs. It also simplifies procedures when the EVPN route is withdrawn but not the BGP-AD route. 4) Page 4: "When the (PBB-)EVPN PE receives traffic over the pseudowires, it learns the associated MAC addresses in the data-plane. This is analogous to dynamic learning in IEEE bridges." Suggested additional text: "The MAC addresses learnt and associated to the pseudowires will NOT be advertised in the control plane to any remote (PBB-)EVPN PE." Reason: this has to be clearly stated. Otherwise MAC duplication might occur. 5) Page 5: "3.3.1 Ingress Replication The procedures for multicast operation on the (PBB-)VPLS PE, using ingress replication, are per [RFC4447] and [PBB- VPLS]." - need to modify format - Wrong reference -> ingress replication is not an RFC4447 concept but RFC4761/4762. 6) Page 3: "In case of single-active redundancy, the participant VPN instances MAY span across both (PBB-)EVPN PEs and (PBB-)VPLS PEs as long as single-active redundancy is employed by (PBB-)EVPN PEs" - need to clarify that, in case of ESI link failure, the (PBB-)EVPN PEs will send a BGP mass-withdraw to the EVPN peers OR MAC advertisement with mac-mobility ext-comm for PBB-EVPN AND an LDP MAC withdrawal to the VPLS peers. - also, single-active mh should also be possible in this scenario for BGP-AD PEs. 7) Page 3: "8. In case of all-active redundancy, the participant VPN instances MAY span across (PBB-)EVPN and (PBB-)VPLS PEs." - requirement 8 is contradicting 7 and making both statements confusing. 8 should be removed or explained with clarity. (PBB-)VPLS PEs do not support all-active MH today. Thank you. Jorge From sajassi@cisco.com Wed Nov 6 20:08:17 2013 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 251E011E81B8 for ; Wed, 6 Nov 2013 20:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.311 X-Spam-Level: X-Spam-Status: No, score=-10.311 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 BLddd79iMezS for ; Wed, 6 Nov 2013 20:08:11 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id DBC6711E80F5 for ; Wed, 6 Nov 2013 20:08:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4270; q=dns/txt; s=iport; t=1383797290; x=1385006890; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=JvW39a5Aqx2ZaqHF7eW5I9B4UXTog4ZdbK50bmuajWs=; b=ioFIFF79xeB8ENr5oXje4fZM2c+QOxVbv5px1X6hmLQwb6uolY1jNQ/L A1LOchnoA5Lr+PuD/hsqelUZ48tpv24cAVYFpzBor5J00CJh+4cumopaW 9y1iI+GDgCacLY4lQBkBbqVUQ4ujdroZIKPje1Q59LB54sexAhpgl/mpm M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFACMHe1KtJV2Z/2dsb2JhbABagmYhgQu/HIEpFnSCLCcTMx4BCDZCJQIEARKIAQG+aY9ghDADmAySCoMmgio X-IronPort-AV: E=Sophos;i="4.93,648,1378857600"; d="scan'208";a="278748414" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 07 Nov 2013 04:08:05 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rA7484jg027240 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 04:08:04 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 22:08:04 -0600 From: "Ali Sajassi (sajassi)" To: "Rabadan, Jorge (Jorge)" , "l2vpn@ietf.org" Subject: Re: About draft-sajassi-l2vpn-evpn-vpls-integration-00 Thread-Topic: About draft-sajassi-l2vpn-evpn-vpls-integration-00 Thread-Index: AQHO2abn5Bvj2w9IKEq2BOsck9lkHJoYDekAgAD7KoA= Date: Thu, 7 Nov 2013 04:08:04 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.89.2.233] Content-Type: text/plain; charset="us-ascii" Content-ID: <276345A42C0D704798F321AB242C7EEE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 04:08:17 -0000 Hi Jorge, Thanks for your comments. Please refer to my responses in line ... On 11/6/13 12:09 PM, "Rabadan, Jorge (Jorge)" wrote: >Ali and draft authors, > >Some comments about the draft. > >General comments: > >1) Very good draft and very well explained, as expected. The first thing >that I thought when I was beginning to read it is that the draft proposed >a sort of gateway function between EVPN and VPLS, which is not the case as >later explained. I believe a diagram would help clarifying this to the >reader. It would also help when describing what kind of multi-homing is >expected to work or not. Sure, we can add a diagram to it. > >Specific comments: > >2) Page 3: >"When a (PBB-)EVPN PE receives both a VPLS AD route as well as an EVPN > Inclusive Multicast route from a given remote PE for the same VPN > instance, it MUST give preference to the EVPN route for the purpose > of discovery." > >This is confusing. VPLS AD and EVPN incl. mcast routes belong to separate >families, BGP will not compare them for any purposes. The text doesn't say "BGP" should give preference. It says "PE" should give preference. > >3) Page 4 >"- If a (PBB-)EVPN PE receives a VPLS AD route followed by an EVPN AD > route from the same PE and a pseudowire is setup to that PE, then the > (PBB-)EVPN PE MUST deactivate that pseudowire. > - If a (PBB-)EVPN PE receives an EVPN AD route followed by a VPLS AD > route from the same PE, then the (PBB-)EVPN PE MUST ignore the VPLS > AD route." > >Suggested text: >"- If a (PBB-)EVPN PE receives a VPLS AD route followed by an EVPN AD >route from the same PE and a pseudowire is setup to that PE, then the >(PBB-)EVPN PE MUST bring that pseudowire operationally down. >- If a (PBB-)EVPN PE receives an EVPN AD route followed by a VPLS AD >route from the same PE, then the (PBB-)EVPN PE will setup the pseudowire >but MUST keep it operationally down" > >Reason: consistency. The same behavior must be observed for potential >FEC128 pseudowires between (PBB-)EVPN PEs. It also simplifies procedures >when the EVPN route is withdrawn but not the BGP-AD route. That's fine. > >4) Page 4: >"When the (PBB-)EVPN PE receives traffic over the pseudowires, it > learns the associated MAC addresses in the data-plane. This is > analogous to dynamic learning in IEEE bridges." > >Suggested additional text: >"The MAC addresses learnt and associated to the pseudowires will NOT be >advertised in the control plane to any remote (PBB-)EVPN PE." > >Reason: this has to be clearly stated. Otherwise MAC duplication might >occur. We will add this sentence. > >5) Page 5: >"3.3.1 Ingress Replication The procedures for multicast operation on the > (PBB-)VPLS PE, using ingress replication, are per [RFC4447] and [PBB- > VPLS]." > >- need to modify format >- Wrong reference -> ingress replication is not an RFC4447 concept but >RFC4761/4762. OK. > >6) Page 3: >"In case of single-active redundancy, the participant VPN instances > MAY span across both (PBB-)EVPN PEs and (PBB-)VPLS PEs as long as > single-active redundancy is employed by (PBB-)EVPN PEs" > >- need to clarify that, in case of ESI link failure, the (PBB-)EVPN PEs >will send a BGP mass-withdraw to the EVPN peers OR MAC advertisement with >mac-mobility ext-comm for PBB-EVPN AND an LDP MAC withdrawal to the VPLS >peers. OK. > >- also, single-active mh should also be possible in this scenario for >BGP-AD PEs. If you're referring to VPLS PEs, then that imposes the VPLS-MH mechanism to be implemented on EVPN PEs which we don't want to impose this burden. > >7) Page 3: > >"8. In case of all-active redundancy, the participant VPN instances > MAY span across (PBB-)EVPN and (PBB-)VPLS PEs." > >- requirement 8 is contradicting 7 and making both statements confusing. 8 >should be removed or explained with clarity. (PBB-)VPLS PEs do not support >all-active MH today. It is possible to do that and that's why it is "MAY". But it adds considerable complexity on PBB-EVPN PEs. So, I will take it out. Cheers, Ali > >Thank you. > >Jorge > > > > > From jakob.heitz@ericsson.com Thu Nov 7 15:28:27 2013 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 4519521E8094 for ; Thu, 7 Nov 2013 15:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 5QOknBFQ29aA for ; Thu, 7 Nov 2013 15:28:19 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id E82AE11E8103 for ; Thu, 7 Nov 2013 15:28:10 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-e1-527c22048b98 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 99.55.23183.4022C725; Fri, 8 Nov 2013 00:28:04 +0100 (CET) Received: from [IPv6:::1] (147.117.188.135) by smtp-am.internal.ericsson.com (147.117.188.80) with Microsoft SMTP Server id 14.2.328.9; Thu, 7 Nov 2013 18:28:03 -0500 Message-ID: <527C2205.9040203@ericsson.com> Date: Thu, 7 Nov 2013 15:28:05 -0800 From: Jakob Heitz User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Subject: EVPN: Setting RD in an IPv6 world Content-Type: multipart/alternative; boundary="------------080404010704070306010802" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDJMWRmVeSWpSXmKPExsUyuXSPny6LUk2QwaXlxhaPvx1id2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqaeH2wFhywrnrQeZmlgnGLQxcjJISFgItG3cykjhC0mceHe ejYQW0jgCKPE8YcZXYxcQPYqRokbE66ygyR4BbQlLk5ZywpiswioSMz53M4EYrMJ6Eh8u97F 3MXIwSEqECXR0C8JUS4ocXLmExYQW0RAROLj9S9gtrCAlkTbgV+MIOXMAmES2/fmQqxVlVhy 7iHTBEbeWUi6ZyFUgYSZBWwlLsy5zgJhy0tsfzuHGcLWlbjwfwqK+AJGtlWMHKXFqWW56UYG mxiBIXZMgk13B+Oel5aHGKU5WJTEeb+8dQ4SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwMip O0VDZU9m09H+czachxvfKJS4Xko/PvmXxrQdJ7ZcOL/hs/9y30r3v/ukUvIfnyloDrXwe3X7 wtHceY27ot60/P3s8yQga5rmiVtzLBOtsl6v2rWm/JKXjYb9vD1PHXsZbyc9epgoPSHcZkby rAl6576fzVa5qfjkFK9X6vGUw4YVO55Pnc+ixFKckWioxVxUnAgAHYlKEP8BAAA= X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 23:28:27 -0000 --------------080404010704070306010802 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit In each of the below cases, an IPv6 address is too large to fill an RD. A suggested text change: The RD must be unique for each PE in the EVPN. An IPv4 address of the PE, followed by 0 MAY be used to construct the value field of the RD. vvvvvvvvvvvvvvvvv 9.1.1 Constructing the Ethernet Segment Route The Route-Distinguisher (RD) MUST be a Type 1 RD [RFC4364 ]. The value field comprises an IP address of the MES (typically, the loopback address) followed by 0's. ^^^^^^^^^^^^^^^^^^^^^^ vvvvvvvvvvvvvvvvvvvvvv 9.2.1 Constructing the Ethernet A-D Route per Ethernet Segment ... Route-Distinguisher (RD) MUST be a Type 1 RD [RFC4364 ]. The value field comprises an IP address of the PE (typically, the loopback address) followed by 0. ^^^^^^^^^^^^^^^^^^^^^^ vvvvvvvvvvvvvvvvvvvvvv 9.4.1 Constructing the Ethernet A-D Route per EVI Route-Distinguisher (RD) MUST be set to the RD of the EVI that is advertising the NLRI. An RD MUST be assigned for a given EVI on an PE. This RD MUST be unique across all EVIs on an PE. It is RECOMMENDED to use the Type 1 RD [RFC4364 ]. The value field comprises an IP address of the PE (typically, the loopback address) followed by a number unique to the PE. This number may be generated by the PE. ^^^^^^^^^^^^^^^^^^^^^^^ --------------080404010704070306010802 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit In each of the below cases, an IPv6 address is too large to fill an RD.
A suggested text change:
The RD must be unique for each PE in the EVPN.
An IPv4 address of the PE, followed by 0 MAY be used to construct the value field of the RD.

vvvvvvvvvvvvvvvvv
 
9.1.1 Constructing the Ethernet Segment Route


   The Route-Distinguisher (RD) MUST be a Type 1 RD [RFC4364]. The value
   field comprises an IP address of the MES (typically, the loopback
   address) followed by 0's.

^^^^^^^^^^^^^^^^^^^^^^
vvvvvvvvvvvvvvvvvvvvvv
9.2.1 Constructing the Ethernet A-D Route per Ethernet Segment

...
   Route-Distinguisher (RD) MUST be a Type 1 RD [RFC4364]. The value
     field comprises an IP address of the PE (typically, the loopback address) followed by 0.
^^^^^^^^^^^^^^^^^^^^^^
vvvvvvvvvvvvvvvvvvvvvv
9.4.1 Constructing the Ethernet A-D Route per EVI 



   Route-Distinguisher (RD) MUST be set to the RD of the EVI that is
   advertising the NLRI. An RD MUST be assigned for a given EVI on an
   PE. This RD MUST be unique across all EVIs on an PE. It is
   RECOMMENDED to use the Type 1 RD [RFC4364]. The value field comprises
   an IP address of the PE (typically, the loopback address) followed by
   a number unique to the PE.  This number may be generated by the PE.

^^^^^^^^^^^^^^^^^^^^^^^

--------------080404010704070306010802-- From lucy.yong@huawei.com Fri Nov 8 12:11:16 2013 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 3947521F99BD for ; Fri, 8 Nov 2013 12:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.198 X-Spam-Level: X-Spam-Status: No, score=-6.198 tagged_above=-999 required=5 tests=[AWL=0.400, 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 njj6002mMld4 for ; Fri, 8 Nov 2013 12:11:11 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB8A21E819E for ; Fri, 8 Nov 2013 12:10:25 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXR63473; Fri, 08 Nov 2013 20:10:19 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 20:10:16 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 20:10:18 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Fri, 8 Nov 2013 12:10:13 -0800 From: Lucy yong To: "l2vpn@ietf.org" Subject: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Thread-Topic: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Thread-Index: Ac7cvqYcD4BB2/82Q4+fCPK55cREGA== Date: Fri, 8 Nov 2013 20:10:12 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452EBE6D@dfweml509-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.144.215] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D452EBE6Ddfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 20:11:17 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D452EBE6Ddfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Authors, I am not convinced if RT 5 is necessary for the use cases you specified in = the draft (or presentation). IMO: RT2 is sufficient to support all the case= s. There is a draft-yong-nvo3-nve, which covers all the L2 overlay cases, whic= h can be implemented by EVPN with RT2. One question, why EVPN service allow to VAP being an IP interface? Thanks, Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D452EBE6Ddfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Authors,

 

I am not convinced if RT 5 is necessary for the use = cases you specified in the draft (or presentation). IMO: RT2 is sufficient = to support all the cases.

There is a draft-yong-nvo3-nve, which covers all the= L2 overlay cases, which can be implemented by EVPN with RT2.

 

One question, why EVPN service allow to VAP being an= IP interface?

 

Thanks,

Lucy

--_000_2691CE0099834E4A9C5044EEC662BB9D452EBE6Ddfweml509mbxchi_-- From wim.henderickx@alcatel-lucent.com Fri Nov 8 12:18:07 2013 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 0BF6F21E8139 for ; Fri, 8 Nov 2013 12:18:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 4cd3qXiUASu3 for ; Fri, 8 Nov 2013 12:18:00 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 6A78621E8195 for ; Fri, 8 Nov 2013 12:18:00 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id rA8KHsgP027682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 8 Nov 2013 14:17:56 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rA8KHmuI002016 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Nov 2013 21:17:54 +0100 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.193]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Fri, 8 Nov 2013 21:17:53 +0100 From: "Henderickx, Wim (Wim)" To: Lucy yong , "l2vpn@ietf.org" Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Thread-Topic: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Thread-Index: Ac7cvqYcD4BB2/82Q4+fCPK55cREGP//WkCA Date: Fri, 8 Nov 2013 20:17:52 +0000 Message-ID: In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452EBE6D@dfweml509-mbx.china.huawei.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_CEA28635912BDwimhenderickxalcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 20:18:07 -0000 --_000_CEA28635912BDwimhenderickxalcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Lucy, did you read the draft and is explained in section 6. Show an example on how you do the scenario=92s with RT2 and you will see wh= y this is less efficient/scalable + does not support all scenario=92s in th= e draft like ESI NH. E-VPN distributes host routes using RT-2: (IP) + MAC and these can be an in= terface e.g. And prefixes can exists behind them. From: Lucy yong > Date: Friday 8 November 2013 22:10 To: "l2vpn@ietf.org" > Subject: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Hi Authors, I am not convinced if RT 5 is necessary for the use cases you specified in = the draft (or presentation). IMO: RT2 is sufficient to support all the case= s. There is a draft-yong-nvo3-nve, which covers all the L2 overlay cases, whic= h can be implemented by EVPN with RT2. One question, why EVPN service allow to VAP being an IP interface? Thanks, Lucy --_000_CEA28635912BDwimhenderickxalcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Lucy, did you read the draft and is explained in section 6.
Show an example on how you do the scenario=92s with RT2 and you will s= ee why this is less efficient/scalable + does not support all scenario= =92s in the draft like ESI NH.

E-VPN distributes host routes using RT-2: (IP) + MAC and these can= be an interface e.g. And prefixes can exists behind them.

From: Lucy yong <lucy.yong@huawei.com>
Date: Friday 8 November 2013 22:10<= br> To: "l2vpn@ietf.org" <l2v= pn@ietf.org>
Subject: comment on draft-rabadan-l= 2vpn-evpn-prefix-advertisement

Hi Authors,

 

I am not convinced if RT 5 is necessary for the use = cases you specified in the draft (or presentation). IMO: RT2 is sufficient = to support all the cases.

There is a draft-yong-nvo3-nve, which covers all the= L2 overlay cases, which can be implemented by EVPN with RT2.

 

One question, why EVPN service allow to VAP being an= IP interface?

 

Thanks,

Lucy

 --_000_CEA28635912BDwimhenderickxalcatellucentcom_-- From xuxiaohu@huawei.com Fri Nov 8 12:25:34 2013 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 23DA111E810E for ; Fri, 8 Nov 2013 12:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.87 X-Spam-Level: X-Spam-Status: No, score=0.87 tagged_above=-999 required=5 tests=[AWL=-2.180, 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 fepFls9HNgiJ for ; Fri, 8 Nov 2013 12:25:28 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 38F7711E823A for ; Fri, 8 Nov 2013 12:25:28 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXR64060; Fri, 08 Nov 2013 20:25:27 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 20:25:24 +0000 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 20:25:22 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.193]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.03.0158.001; Sat, 9 Nov 2013 04:25:10 +0800 From: Xuxiaohu To: "Henderickx, Wim (Wim)" , Lucy yong , "l2vpn@ietf.org" Subject: =?gb2312?B?tPC4tDogY29tbWVudCBvbiBkcmFmdC1yYWJhZGFuLWwydnBuLWV2cG4tcHJl?= =?gb2312?Q?fix-advertisement?= Thread-Topic: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Thread-Index: Ac7cvqYcD4BB2/82Q4+fCPK55cREGP//WkCAgAComOA= Date: Fri, 8 Nov 2013 20:25:09 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227AC5@NKGEML512-MBS.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D452EBE6D@dfweml509-mbx.china.huawei.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.129.94] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227AC5NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 20:25:34 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227AC5NKGEML512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 V2ltLA0KDQoNCg0KU2luY2UgeW91IG1lbnRpb25lZCB0aGF0IEUtVlBOIGRpc3RyaWJ1dGVzIGhv c3Qgcm91dGVzLCBJIHdvbmRlciB3aGV0aGVyIHRob3NlIGhvc3Qgcm91dGVzIHdvdWxkIGJlIHVz ZWQgZm9yIElQIGZvcndhcmRpbmcuIElmIHNvLCBzaG91bGQgdGhpcyBleHRlbnNpb24gc3BlY2lm aWNhdGlvbiBiZWxvbmcgdG8gdGhlIEwzVlBOIHNjb3BlPw0KDQoNCg0KWGlhb2h1DQoNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IGwydnBuLWJvdW5jZXNAaWV0Zi5v cmcgW2wydnBuLWJvdW5jZXNAaWV0Zi5vcmddILT6se0gSGVuZGVyaWNreCwgV2ltIChXaW0pIFt3 aW0uaGVuZGVyaWNreEBhbGNhdGVsLWx1Y2VudC5jb21dDQq3osvNyrG85DogMjAxM8TqMTHUwjnI 1SA0OjE3DQrK1bz+yMs6IEx1Y3kgeW9uZzsgbDJ2cG5AaWV0Zi5vcmcNCtb3zOI6IFJlOiBjb21t ZW50IG9uIGRyYWZ0LXJhYmFkYW4tbDJ2cG4tZXZwbi1wcmVmaXgtYWR2ZXJ0aXNlbWVudA0KDQpM dWN5LCBkaWQgeW91IHJlYWQgdGhlIGRyYWZ0IGFuZCBpcyBleHBsYWluZWQgaW4gc2VjdGlvbiA2 Lg0KU2hvdyBhbiBleGFtcGxlIG9uIGhvdyB5b3UgZG8gdGhlIHNjZW5hcmlvoa9zIHdpdGggUlQy IGFuZCB5b3Ugd2lsbCBzZWUgd2h5IHRoaXMgaXMgbGVzcyBlZmZpY2llbnQvc2NhbGFibGUgKyBk b2VzIG5vdCBzdXBwb3J0IGFsbCBzY2VuYXJpb6GvcyBpbiB0aGUgZHJhZnQgbGlrZSBFU0kgTkgu DQoNCkUtVlBOIGRpc3RyaWJ1dGVzIGhvc3Qgcm91dGVzIHVzaW5nIFJULTI6IChJUCkgKyBNQUMg YW5kIHRoZXNlIGNhbiBiZSBhbiBpbnRlcmZhY2UgZS5nLiBBbmQgcHJlZml4ZXMgY2FuIGV4aXN0 cyBiZWhpbmQgdGhlbS4NCg0KRnJvbTogTHVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxt YWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+Pg0KRGF0ZTogRnJpZGF5IDggTm92ZW1iZXIgMjAx MyAyMjoxMA0KVG86ICJsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+IiA8bDJ2 cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPj4NClN1YmplY3Q6IGNvbW1lbnQgb24g ZHJhZnQtcmFiYWRhbi1sMnZwbi1ldnBuLXByZWZpeC1hZHZlcnRpc2VtZW50DQoNCkhpIEF1dGhv cnMsDQoNCkkgYW0gbm90IGNvbnZpbmNlZCBpZiBSVCA1IGlzIG5lY2Vzc2FyeSBmb3IgdGhlIHVz ZSBjYXNlcyB5b3Ugc3BlY2lmaWVkIGluIHRoZSBkcmFmdCAob3IgcHJlc2VudGF0aW9uKS4gSU1P OiBSVDIgaXMgc3VmZmljaWVudCB0byBzdXBwb3J0IGFsbCB0aGUgY2FzZXMuDQpUaGVyZSBpcyBh IGRyYWZ0LXlvbmctbnZvMy1udmUsIHdoaWNoIGNvdmVycyBhbGwgdGhlIEwyIG92ZXJsYXkgY2Fz ZXMsIHdoaWNoIGNhbiBiZSBpbXBsZW1lbnRlZCBieSBFVlBOIHdpdGggUlQyLg0KDQpPbmUgcXVl c3Rpb24sIHdoeSBFVlBOIHNlcnZpY2UgYWxsb3cgdG8gVkFQIGJlaW5nIGFuIElQIGludGVyZmFj ZT8NCg0KVGhhbmtzLA0KTHVjeQ0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227AC5NKGEML512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Wim,

 

Since you mentioned that E-VPN distributes host routes, I wond= er whether those host routes would be used for IP forwarding. If so, should= this extension specification belong to the L3VPN scope?

 

Xiaohu

=B7=A2=BC=FE=C8=CB: l2vpn-bounces@ietf.org= [l2vpn-bounces@ietf.org] =B4=FA=B1=ED Henderickx, Wim (Wim) [wim.henderick= x@alcatel-lucent.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C29=C8=D5 4:17
=CA=D5=BC=FE=C8=CB: Lucy yong; l2vpn@ietf.org
=D6=F7=CC=E2: Re: comment on draft-rabadan-l2vpn-evpn-prefix-adverti= sement

Lucy, did you read the draft and is explained in section 6.
Show an example on how you do the scenario=A1=AFs with RT2 and you wil= l see why this is less efficient/scalable + does not support all scenar= io=A1=AFs in the draft like ESI NH.

E-VPN distributes host routes using RT-2: (IP) + MAC and these can= be an interface e.g. And prefixes can exists behind them.

From: Lucy yong <lucy.yong@huawei.com> Date: Friday 8 November 2013 22:10=
To: "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: comment on draft-rabadan-= l2vpn-evpn-prefix-advertisement

Hi Authors,

 

I am not convinced if RT 5 is necessary for the use = cases you specified in the draft (or presentation). IMO: RT2 is sufficient = to support all the cases.

There is a draft-yong-nvo3-nve, which covers all the= L2 overlay cases, which can be implemented by EVPN with RT2.

 

One question, why EVPN service allow to VAP being an= IP interface?

 

Thanks,

Lucy

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227AC5NKGEML512MBSchi_-- From wim.henderickx@alcatel-lucent.com Fri Nov 8 12:37:58 2013 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 4B07211E80E9 for ; Fri, 8 Nov 2013 12:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.774 X-Spam-Level: X-Spam-Status: No, score=-5.774 tagged_above=-999 required=5 tests=[AWL=-4.824, 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_HI=-8, 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 BjSue43GN+ON for ; Fri, 8 Nov 2013 12:37:39 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 711EC21E80E8 for ; Fri, 8 Nov 2013 12:37:06 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rA8Kawj3007144 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 8 Nov 2013 14:37:00 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rA8KawUT010289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Nov 2013 21:36:58 +0100 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.193]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 8 Nov 2013 21:36:58 +0100 From: "Henderickx, Wim (Wim)" To: Xuxiaohu , Lucy yong , "l2vpn@ietf.org" Subject: =?gb2312?B?UmU6ILTwuLQ6IGNvbW1lbnQgb24gZHJhZnQtcmFiYWRhbi1sMnZwbi1ldnBu?= =?gb2312?Q?-prefix-advertisement?= Thread-Topic: =?gb2312?B?tPC4tDogY29tbWVudCBvbiBkcmFmdC1yYWJhZGFuLWwydnBuLWV2cG4tcHJl?= =?gb2312?Q?fix-advertisement?= Thread-Index: Ac7cvqYcD4BB2/82Q4+fCPK55cREGP//WkCAgAComOD//1y+gA== Date: Fri, 8 Nov 2013 20:36:57 +0000 Message-ID: In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227AC5@NKGEML512-MBS.china.huawei.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_CEA28A79912E2wimhenderickxalcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 20:37:58 -0000 --_000_CEA28A79912E2wimhenderickxalcatellucentcom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSBkb26hr3Qgc2VlIHdoeSB0aGlzIHNob3VsZCBiZSBkaXNjdXNzZWQgd2l0aCBMM1ZQTiBiZWNh dXNlIEUtVnBuIGZyb20gdGhlIGJlZ2lubmluZyBhbGxvd2VkIHRoaXMgY2FwYWJpbGl0eS4gVGhl IG1lY2hhbmlzbSBkZXNjcmliZWQgaGVyZSBhbGxvd3MgdG8gb3B0aW1pc2UgdGhlIHNjZW5hcmlv oa9zLiBXZSBsb29rIGF0IHJldXNpbmcgTDNWUG4gQUZJL1NBRkkgYW5kIGdpdmVuIHRoZXJlIGlz IG5vIE1BQyBvciBFU0kgTkggaXQgaXMgbm90IHN1aXRlZCBmb3IgYWxsIHNjZW5hcmlvoa9zLg0K SGVuY2UgdGhlIHByb3Bvc2FsLg0KDQoNCkZyb206IFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWku Y29tPG1haWx0bzp4dXhpYW9odUBodWF3ZWkuY29tPj4NCkRhdGU6IEZyaWRheSA4IE5vdmVtYmVy IDIwMTMgMjI6MjUNClRvOiBXaW0gSGVuZGVyaWNreCA8d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1s dWNlbnQuY29tPG1haWx0bzp3aW0uaGVuZGVyaWNreEBhbGNhdGVsLWx1Y2VudC5jb20+PiwgTHVj eSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+ PiwgImwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4iIDxsMnZwbkBpZXRmLm9y ZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+Pg0KU3ViamVjdDogtPC4tDogY29tbWVudCBvbiBkcmFm dC1yYWJhZGFuLWwydnBuLWV2cG4tcHJlZml4LWFkdmVydGlzZW1lbnQNCg0KDQpXaW0sDQoNCg0K DQpTaW5jZSB5b3UgbWVudGlvbmVkIHRoYXQgRS1WUE4gZGlzdHJpYnV0ZXMgaG9zdCByb3V0ZXMs IEkgd29uZGVyIHdoZXRoZXIgdGhvc2UgaG9zdCByb3V0ZXMgd291bGQgYmUgdXNlZCBmb3IgSVAg Zm9yd2FyZGluZy4gSWYgc28sIHNob3VsZCB0aGlzIGV4dGVuc2lvbiBzcGVjaWZpY2F0aW9uIGJl bG9uZyB0byB0aGUgTDNWUE4gc2NvcGU/DQoNCg0KDQpYaWFvaHUNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCreivP7IyzogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 bDJ2cG4tYm91bmNlc0BpZXRmLm9yZz4gW2wydnBuLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmwy dnBuLWJvdW5jZXNAaWV0Zi5vcmc+XSC0+rHtIEhlbmRlcmlja3gsIFdpbSAoV2ltKSBbd2ltLmhl bmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzp3aW0uaGVuZGVyaWNreEBhbGNhdGVs LWx1Y2VudC5jb20+XQ0Kt6LLzcqxvOQ6IDIwMTPE6jEx1MI5yNUgNDoxNw0KytW8/sjLOiBMdWN5 IHlvbmc7IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4NCtb3zOI6IFJlOiBj b21tZW50IG9uIGRyYWZ0LXJhYmFkYW4tbDJ2cG4tZXZwbi1wcmVmaXgtYWR2ZXJ0aXNlbWVudA0K DQpMdWN5LCBkaWQgeW91IHJlYWQgdGhlIGRyYWZ0IGFuZCBpcyBleHBsYWluZWQgaW4gc2VjdGlv biA2Lg0KU2hvdyBhbiBleGFtcGxlIG9uIGhvdyB5b3UgZG8gdGhlIHNjZW5hcmlvoa9zIHdpdGgg UlQyIGFuZCB5b3Ugd2lsbCBzZWUgd2h5IHRoaXMgaXMgbGVzcyBlZmZpY2llbnQvc2NhbGFibGUg KyBkb2VzIG5vdCBzdXBwb3J0IGFsbCBzY2VuYXJpb6GvcyBpbiB0aGUgZHJhZnQgbGlrZSBFU0kg TkguDQoNCkUtVlBOIGRpc3RyaWJ1dGVzIGhvc3Qgcm91dGVzIHVzaW5nIFJULTI6IChJUCkgKyBN QUMgYW5kIHRoZXNlIGNhbiBiZSBhbiBpbnRlcmZhY2UgZS5nLiBBbmQgcHJlZml4ZXMgY2FuIGV4 aXN0cyBiZWhpbmQgdGhlbS4NCg0KRnJvbTogTHVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNv bTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+Pg0KRGF0ZTogRnJpZGF5IDggTm92ZW1iZXIg MjAxMyAyMjoxMA0KVG86ICJsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+IiA8 bDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPj4NClN1YmplY3Q6IGNvbW1lbnQg b24gZHJhZnQtcmFiYWRhbi1sMnZwbi1ldnBuLXByZWZpeC1hZHZlcnRpc2VtZW50DQoNCkhpIEF1 dGhvcnMsDQoNCkkgYW0gbm90IGNvbnZpbmNlZCBpZiBSVCA1IGlzIG5lY2Vzc2FyeSBmb3IgdGhl IHVzZSBjYXNlcyB5b3Ugc3BlY2lmaWVkIGluIHRoZSBkcmFmdCAob3IgcHJlc2VudGF0aW9uKS4g SU1POiBSVDIgaXMgc3VmZmljaWVudCB0byBzdXBwb3J0IGFsbCB0aGUgY2FzZXMuDQpUaGVyZSBp cyBhIGRyYWZ0LXlvbmctbnZvMy1udmUsIHdoaWNoIGNvdmVycyBhbGwgdGhlIEwyIG92ZXJsYXkg Y2FzZXMsIHdoaWNoIGNhbiBiZSBpbXBsZW1lbnRlZCBieSBFVlBOIHdpdGggUlQyLg0KDQpPbmUg cXVlc3Rpb24sIHdoeSBFVlBOIHNlcnZpY2UgYWxsb3cgdG8gVkFQIGJlaW5nIGFuIElQIGludGVy ZmFjZT8NCg0KVGhhbmtzLA0KTHVjeQ0K --_000_CEA28A79912E2wimhenderickxalcatellucentcom_ Content-Type: text/html; charset="gb2312" Content-ID: Content-Transfer-Encoding: quoted-printable
I don=A1=AFt see why this should be discussed with L3VPN because E-Vpn= from the beginning allowed this capability. The mechanism described here a= llows to optimise the scenario=A1=AFs. We look at reusing L3VPn AFI/SAFI an= d given there is no MAC or ESI NH it is not suited for all scenario=A1=AFs.
Hence the proposal.


From: Xuxiaohu <xuxiaohu@huawei.com>
Date: Friday 8 November 2013 22:25<= br> To: Wim Henderickx <wim.henderickx@alcatel-lucent.com<= /a>>, Lucy yong <lucy.yong@hu= awei.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: =B4=F0=B8=B4: comment on d= raft-rabadan-l2vpn-evpn-prefix-advertisement

Wim,

 

Since you mentioned that E-VPN distributes host routes, I wond= er whether those host routes would be used for IP forwarding. If so, should= this extension specification belong to the L3VPN scope?

 

Xiaohu

=B7=A2=BC=FE=C8=CB: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] =B4=FA=B1= =ED Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C29=C8=D5 4:17
=CA=D5=BC=FE=C8=CB: Lucy yong; l2v= pn@ietf.org
=D6=F7=CC=E2: Re: comment on draft-rabadan-l2vpn-evpn-prefix-adverti= sement

Lucy, did you read the draft and is explained in section 6.
Show an example on how you do the scenario=A1=AFs with RT2 and you wil= l see why this is less efficient/scalable + does not support all scenar= io=A1=AFs in the draft like ESI NH.

E-VPN distributes host routes using RT-2: (IP) + MAC and these can= be an interface e.g. And prefixes can exists behind them.

From: Lucy yong <lucy.yong@huawei.com> Date: Friday 8 November 2013 22:10=
To: "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: comment on draft-rabadan-= l2vpn-evpn-prefix-advertisement

Hi Authors,

 

I am not convinced if RT 5 is necessary for the use = cases you specified in the draft (or presentation). IMO: RT2 is sufficient = to support all the cases.

There is a draft-yong-nvo3-nve, which covers all the= L2 overlay cases, which can be implemented by EVPN with RT2.

 

One question, why EVPN service allow to VAP being an= IP interface?

 

Thanks,

Lucy

 --_000_CEA28A79912E2wimhenderickxalcatellucentcom_-- From xuxiaohu@huawei.com Fri Nov 8 12:59:37 2013 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 26DBB21E8121 for ; Fri, 8 Nov 2013 12:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.293 X-Spam-Level: * X-Spam-Status: No, score=1.293 tagged_above=-999 required=5 tests=[AWL=-2.357, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_23=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 5JoWHuZAvJzl for ; Fri, 8 Nov 2013 12:59:32 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 49B8B11E80FB for ; Fri, 8 Nov 2013 12:59:31 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXR65413; Fri, 08 Nov 2013 20:59:29 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 20:58:43 +0000 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 8 Nov 2013 20:59:28 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.193]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Sat, 9 Nov 2013 04:59:16 +0800 From: Xuxiaohu To: "Henderickx, Wim (Wim)" , Lucy yong , "l2vpn@ietf.org" Subject: =?gb2312?B?tPC4tDogtPC4tDogY29tbWVudCBvbiBkcmFmdC1yYWJhZGFuLWwydnBuLWV2?= =?gb2312?Q?pn-prefix-advertisement?= Thread-Topic: =?gb2312?B?tPC4tDogY29tbWVudCBvbiBkcmFmdC1yYWJhZGFuLWwydnBuLWV2cG4tcHJl?= =?gb2312?Q?fix-advertisement?= Thread-Index: Ac7cvqYcD4BB2/82Q4+fCPK55cREGP//WkCAgAComOD//1y+gIAAq9wA Date: Fri, 8 Nov 2013 20:59:15 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227B05@NKGEML512-MBS.china.huawei.com> References: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227AC5@NKGEML512-MBS.china.huawei.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.129.94] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227B05NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 20:59:37 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227B05NKGEML512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 QmVjYXVzZSB0aGlzIGV4dGVuc2lvbiBpcyBpbnRlbmRlZCBmb3IgTDMgZm9yd2FyZGluZywgcmF0 aGVyIHRoYW4gTDIgZm9yd2FyZGluZyBhbnltb3JlLiBGdXJ0aGVybW9yZSwgdGhhdCBMMyBmb3J3 YXJkaW5nIGlzIHVzZWQgZm9yIGludGVyLXN1Ym5ldCB0cmFmZmljLg0KDQoNCg0KQWx0aG91Z2gg RS1WcG4gZnJvbSB0aGUgYmVnaW5uaW5nIGFsbG93ZWQgdGhpcyBjYXBhYmlsaXR5IG9mIGFkdmVy dGlzaW5nIElQK01BQywgdGhlIElQIGFkZHJlc3MgaXMgbm90IHVzZWQgZm9yIEwzIGZvcndhcmRp bmcuDQoNCg0KDQpYaWFvaHUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCrei vP7IyzogSGVuZGVyaWNreCwgV2ltIChXaW0pIFt3aW0uaGVuZGVyaWNreEBhbGNhdGVsLWx1Y2Vu dC5jb21dDQq3osvNyrG85DogMjAxM8TqMTHUwjnI1SA0OjM2DQrK1bz+yMs6IFh1eGlhb2h1OyBM dWN5IHlvbmc7IGwydnBuQGlldGYub3JnDQrW98ziOiBSZTogtPC4tDogY29tbWVudCBvbiBkcmFm dC1yYWJhZGFuLWwydnBuLWV2cG4tcHJlZml4LWFkdmVydGlzZW1lbnQNCg0KSSBkb26hr3Qgc2Vl IHdoeSB0aGlzIHNob3VsZCBiZSBkaXNjdXNzZWQgd2l0aCBMM1ZQTiBiZWNhdXNlIEUtVnBuIGZy b20gdGhlIGJlZ2lubmluZyBhbGxvd2VkIHRoaXMgY2FwYWJpbGl0eS4gVGhlIG1lY2hhbmlzbSBk ZXNjcmliZWQgaGVyZSBhbGxvd3MgdG8gb3B0aW1pc2UgdGhlIHNjZW5hcmlvoa9zLiBXZSBsb29r IGF0IHJldXNpbmcgTDNWUG4gQUZJL1NBRkkgYW5kIGdpdmVuIHRoZXJlIGlzIG5vIE1BQyBvciBF U0kgTkggaXQgaXMgbm90IHN1aXRlZCBmb3IgYWxsIHNjZW5hcmlvoa9zLg0KSGVuY2UgdGhlIHBy b3Bvc2FsLg0KDQoNCkZyb206IFh1eGlhb2h1IDx4dXhpYW9odUBodWF3ZWkuY29tPG1haWx0bzp4 dXhpYW9odUBodWF3ZWkuY29tPj4NCkRhdGU6IEZyaWRheSA4IE5vdmVtYmVyIDIwMTMgMjI6MjUN ClRvOiBXaW0gSGVuZGVyaWNreCA8d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuY29tPG1h aWx0bzp3aW0uaGVuZGVyaWNreEBhbGNhdGVsLWx1Y2VudC5jb20+PiwgTHVjeSB5b25nIDxsdWN5 LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+PiwgImwydnBuQGll dGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4iIDxsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2 cG5AaWV0Zi5vcmc+Pg0KU3ViamVjdDogtPC4tDogY29tbWVudCBvbiBkcmFmdC1yYWJhZGFuLWwy dnBuLWV2cG4tcHJlZml4LWFkdmVydGlzZW1lbnQNCg0KDQpXaW0sDQoNCg0KDQpTaW5jZSB5b3Ug bWVudGlvbmVkIHRoYXQgRS1WUE4gZGlzdHJpYnV0ZXMgaG9zdCByb3V0ZXMsIEkgd29uZGVyIHdo ZXRoZXIgdGhvc2UgaG9zdCByb3V0ZXMgd291bGQgYmUgdXNlZCBmb3IgSVAgZm9yd2FyZGluZy4g SWYgc28sIHNob3VsZCB0aGlzIGV4dGVuc2lvbiBzcGVjaWZpY2F0aW9uIGJlbG9uZyB0byB0aGUg TDNWUE4gc2NvcGU/DQoNCg0KDQpYaWFvaHUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCreivP7IyzogbDJ2cG4tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bDJ2cG4tYm91bmNl c0BpZXRmLm9yZz4gW2wydnBuLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmwydnBuLWJvdW5jZXNA aWV0Zi5vcmc+XSC0+rHtIEhlbmRlcmlja3gsIFdpbSAoV2ltKSBbd2ltLmhlbmRlcmlja3hAYWxj YXRlbC1sdWNlbnQuY29tPG1haWx0bzp3aW0uaGVuZGVyaWNreEBhbGNhdGVsLWx1Y2VudC5jb20+ XQ0Kt6LLzcqxvOQ6IDIwMTPE6jEx1MI5yNUgNDoxNw0KytW8/sjLOiBMdWN5IHlvbmc7IGwydnBu QGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4NCtb3zOI6IFJlOiBjb21tZW50IG9uIGRy YWZ0LXJhYmFkYW4tbDJ2cG4tZXZwbi1wcmVmaXgtYWR2ZXJ0aXNlbWVudA0KDQpMdWN5LCBkaWQg eW91IHJlYWQgdGhlIGRyYWZ0IGFuZCBpcyBleHBsYWluZWQgaW4gc2VjdGlvbiA2Lg0KU2hvdyBh biBleGFtcGxlIG9uIGhvdyB5b3UgZG8gdGhlIHNjZW5hcmlvoa9zIHdpdGggUlQyIGFuZCB5b3Ug d2lsbCBzZWUgd2h5IHRoaXMgaXMgbGVzcyBlZmZpY2llbnQvc2NhbGFibGUgKyBkb2VzIG5vdCBz dXBwb3J0IGFsbCBzY2VuYXJpb6GvcyBpbiB0aGUgZHJhZnQgbGlrZSBFU0kgTkguDQoNCkUtVlBO IGRpc3RyaWJ1dGVzIGhvc3Qgcm91dGVzIHVzaW5nIFJULTI6IChJUCkgKyBNQUMgYW5kIHRoZXNl IGNhbiBiZSBhbiBpbnRlcmZhY2UgZS5nLiBBbmQgcHJlZml4ZXMgY2FuIGV4aXN0cyBiZWhpbmQg dGhlbS4NCg0KRnJvbTogTHVjeSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVj eS55b25nQGh1YXdlaS5jb20+Pg0KRGF0ZTogRnJpZGF5IDggTm92ZW1iZXIgMjAxMyAyMjoxMA0K VG86ICJsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+IiA8bDJ2cG5AaWV0Zi5v cmc8bWFpbHRvOmwydnBuQGlldGYub3JnPj4NClN1YmplY3Q6IGNvbW1lbnQgb24gZHJhZnQtcmFi YWRhbi1sMnZwbi1ldnBuLXByZWZpeC1hZHZlcnRpc2VtZW50DQoNCkhpIEF1dGhvcnMsDQoNCkkg YW0gbm90IGNvbnZpbmNlZCBpZiBSVCA1IGlzIG5lY2Vzc2FyeSBmb3IgdGhlIHVzZSBjYXNlcyB5 b3Ugc3BlY2lmaWVkIGluIHRoZSBkcmFmdCAob3IgcHJlc2VudGF0aW9uKS4gSU1POiBSVDIgaXMg c3VmZmljaWVudCB0byBzdXBwb3J0IGFsbCB0aGUgY2FzZXMuDQpUaGVyZSBpcyBhIGRyYWZ0LXlv bmctbnZvMy1udmUsIHdoaWNoIGNvdmVycyBhbGwgdGhlIEwyIG92ZXJsYXkgY2FzZXMsIHdoaWNo IGNhbiBiZSBpbXBsZW1lbnRlZCBieSBFVlBOIHdpdGggUlQyLg0KDQpPbmUgcXVlc3Rpb24sIHdo eSBFVlBOIHNlcnZpY2UgYWxsb3cgdG8gVkFQIGJlaW5nIGFuIElQIGludGVyZmFjZT8NCg0KVGhh bmtzLA0KTHVjeQ0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227B05NKGEML512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Because this extension is intended for L3 forwarding, rather than L2 for= warding anymore. Furthermore, that L3 forwarding is used for inter-subnet t= raffic.

 

Although E-Vpn from the beginning allowed this capability of advertising= IP+MAC, the IP address is not used for L3 forwarding.

 

Xiaohu

=B7=A2=BC=FE=C8=CB: Henderickx, Wim (Wim) = [wim.henderickx@alcatel-lucent.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C29=C8=D5 4:36
=CA=D5=BC=FE=C8=CB: Xuxiaohu; Lucy yong; l2vpn@ietf.org
=D6=F7=CC=E2: Re: =B4=F0=B8=B4: comment on draft-rabadan-l2vpn-evpn-= prefix-advertisement

I don=A1=AFt see why this should be discussed with L3VPN because E-Vpn= from the beginning allowed this capability. The mechanism described here a= llows to optimise the scenario=A1=AFs. We look at reusing L3VPn AFI/SAFI an= d given there is no MAC or ESI NH it is not suited for all scenario=A1=AFs.
Hence the proposal.


From: Xuxiaohu <xuxiaohu@huawei.com>
Date: Friday 8 November 2013 22:25=
To: Wim Henderickx <wim.henderickx@= alcatel-lucent.com>, Lucy yong <lucy.yong@huawei.com>, "l2vpn@ietf.org" <l2vpn@ietf= .org>
Subject: =B4=F0=B8=B4: comment on = draft-rabadan-l2vpn-evpn-prefix-advertisement

Wim,

 

Since you mentioned that E-VPN distributes host routes, I wond= er whether those host routes would be used for IP forwarding. If so, should= this extension specification belong to the L3VPN scope?

 

Xiaohu

=B7=A2=BC=FE=C8=CB: l2vpn-bounces@i= etf.org [l2= vpn-bounces@ietf.org] =B4=FA=B1=ED Henderickx, Wim (Wim) [wim.henderickx@al= catel-lucent.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C29=C8=D5 4:17
=CA=D5=BC=FE=C8=CB: Lucy yong; l2vpn@ietf.org
=D6=F7=CC=E2: Re: comment on draft-rabadan-l2vpn-evpn-prefix-adverti= sement

Lucy, did you read the draft and is explained in section 6.
Show an example on how you do the scenario=A1=AFs with RT2 and you wil= l see why this is less efficient/scalable + does not support all scenar= io=A1=AFs in the draft like ESI NH.

E-VPN distributes host routes using RT-2: (IP) + MAC and these can= be an interface e.g. And prefixes can exists behind them.

From: Lucy yong <lucy.yong@huawei.com> Date: Friday 8 November 2013 22:10=
To: "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: comment on draft-rabadan-= l2vpn-evpn-prefix-advertisement

Hi Authors,

 

I am not convinced if RT 5 is necessary for the use = cases you specified in the draft (or presentation). IMO: RT2 is sufficient = to support all the cases.

There is a draft-yong-nvo3-nve, which covers all the= L2 overlay cases, which can be implemented by EVPN with RT2.

 

One question, why EVPN service allow to VAP being an= IP interface?

 

Thanks,

Lucy

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227B05NKGEML512MBSchi_-- From wim.henderickx@alcatel-lucent.com Fri Nov 8 13:03:42 2013 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 B0E7221E8146 for ; Fri, 8 Nov 2013 13:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.67 X-Spam-Level: X-Spam-Status: No, score=-4.67 tagged_above=-999 required=5 tests=[AWL=-4.320, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, 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 uRqqkZ9efQld for ; Fri, 8 Nov 2013 13:03:37 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 0376411E80DE for ; Fri, 8 Nov 2013 13:03:36 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id rA8L3V0f021608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 8 Nov 2013 15:03:32 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rA8L3V7e016893 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Nov 2013 22:03:31 +0100 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.193]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 8 Nov 2013 22:03:31 +0100 From: "Henderickx, Wim (Wim)" To: Xuxiaohu , Lucy yong , "l2vpn@ietf.org" Subject: =?gb2312?B?UmU6ILTwuLQ6ICC08Li0OiBjb21tZW50IG9uIGRyYWZ0LXJhYmFkYW4tbDJ2?= =?gb2312?Q?pn-evpn-prefix-advertisement?= Thread-Topic: =?gb2312?B?tPC4tDogILTwuLQ6IGNvbW1lbnQgb24gZHJhZnQtcmFiYWRhbi1sMnZwbi1l?= =?gb2312?Q?vpn-prefix-advertisement?= Thread-Index: Ac7cvqYcD4BB2/82Q4+fCPK55cREGP//WkCAgAComOD//1y+gIAAq9wA//9bjQA= Date: Fri, 8 Nov 2013 21:03:29 +0000 Message-ID: In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE08227B05@NKGEML512-MBS.china.huawei.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_CEA2918B91319wimhenderickxalcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 21:03:42 -0000 --_000_CEA2918B91319wimhenderickxalcatellucentcom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGF2ZSBhIGxvb2sgYXQgdGhpcyBkcmFmdCB3aGljaCBleHBsYWlucyBob3cgSSB3b3JrczoNCmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zYWphc3NpLWwydnBuLWV2cG4taW50ZXIt c3VibmV0LWZvcndhcmRpbmctMDINCg0KDQpGcm9tOiBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2Vp LmNvbTxtYWlsdG86eHV4aWFvaHVAaHVhd2VpLmNvbT4+DQpEYXRlOiBGcmlkYXkgOCBOb3ZlbWJl ciAyMDEzIDIyOjU5DQpUbzogV2ltIEhlbmRlcmlja3ggPHdpbS5oZW5kZXJpY2t4QGFsY2F0ZWwt bHVjZW50LmNvbTxtYWlsdG86d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuY29tPj4sIEx1 Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29t Pj4sICJsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+IiA8bDJ2cG5AaWV0Zi5v cmc8bWFpbHRvOmwydnBuQGlldGYub3JnPj4NClN1YmplY3Q6ILTwuLQ6ILTwuLQ6IGNvbW1lbnQg b24gZHJhZnQtcmFiYWRhbi1sMnZwbi1ldnBuLXByZWZpeC1hZHZlcnRpc2VtZW50DQoNCg0KQmVj YXVzZSB0aGlzIGV4dGVuc2lvbiBpcyBpbnRlbmRlZCBmb3IgTDMgZm9yd2FyZGluZywgcmF0aGVy IHRoYW4gTDIgZm9yd2FyZGluZyBhbnltb3JlLiBGdXJ0aGVybW9yZSwgdGhhdCBMMyBmb3J3YXJk aW5nIGlzIHVzZWQgZm9yIGludGVyLXN1Ym5ldCB0cmFmZmljLg0KDQoNCg0KQWx0aG91Z2ggRS1W cG4gZnJvbSB0aGUgYmVnaW5uaW5nIGFsbG93ZWQgdGhpcyBjYXBhYmlsaXR5IG9mIGFkdmVydGlz aW5nIElQK01BQywgdGhlIElQIGFkZHJlc3MgaXMgbm90IHVzZWQgZm9yIEwzIGZvcndhcmRpbmcu DQoNCg0KDQpYaWFvaHUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7I yzogSGVuZGVyaWNreCwgV2ltIChXaW0pIFt3aW0uaGVuZGVyaWNreEBhbGNhdGVsLWx1Y2VudC5j b208bWFpbHRvOndpbS5oZW5kZXJpY2t4QGFsY2F0ZWwtbHVjZW50LmNvbT5dDQq3osvNyrG85Dog MjAxM8TqMTHUwjnI1SA0OjM2DQrK1bz+yMs6IFh1eGlhb2h1OyBMdWN5IHlvbmc7IGwydnBuQGll dGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4NCtb3zOI6IFJlOiC08Li0OiBjb21tZW50IG9u IGRyYWZ0LXJhYmFkYW4tbDJ2cG4tZXZwbi1wcmVmaXgtYWR2ZXJ0aXNlbWVudA0KDQpJIGRvbqGv dCBzZWUgd2h5IHRoaXMgc2hvdWxkIGJlIGRpc2N1c3NlZCB3aXRoIEwzVlBOIGJlY2F1c2UgRS1W cG4gZnJvbSB0aGUgYmVnaW5uaW5nIGFsbG93ZWQgdGhpcyBjYXBhYmlsaXR5LiBUaGUgbWVjaGFu aXNtIGRlc2NyaWJlZCBoZXJlIGFsbG93cyB0byBvcHRpbWlzZSB0aGUgc2NlbmFyaW+hr3MuIFdl IGxvb2sgYXQgcmV1c2luZyBMM1ZQbiBBRkkvU0FGSSBhbmQgZ2l2ZW4gdGhlcmUgaXMgbm8gTUFD IG9yIEVTSSBOSCBpdCBpcyBub3Qgc3VpdGVkIGZvciBhbGwgc2NlbmFyaW+hr3MuDQpIZW5jZSB0 aGUgcHJvcG9zYWwuDQoNCg0KRnJvbTogWHV4aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb208bWFp bHRvOnh1eGlhb2h1QGh1YXdlaS5jb20+Pg0KRGF0ZTogRnJpZGF5IDggTm92ZW1iZXIgMjAxMyAy MjoyNQ0KVG86IFdpbSBIZW5kZXJpY2t4IDx3aW0uaGVuZGVyaWNreEBhbGNhdGVsLWx1Y2VudC5j b208bWFpbHRvOndpbS5oZW5kZXJpY2t4QGFsY2F0ZWwtbHVjZW50LmNvbT4+LCBMdWN5IHlvbmcg PGx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+LCAibDJ2 cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPiIgPGwydnBuQGlldGYub3JnPG1haWx0 bzpsMnZwbkBpZXRmLm9yZz4+DQpTdWJqZWN0OiC08Li0OiBjb21tZW50IG9uIGRyYWZ0LXJhYmFk YW4tbDJ2cG4tZXZwbi1wcmVmaXgtYWR2ZXJ0aXNlbWVudA0KDQoNCldpbSwNCg0KDQoNClNpbmNl IHlvdSBtZW50aW9uZWQgdGhhdCBFLVZQTiBkaXN0cmlidXRlcyBob3N0IHJvdXRlcywgSSB3b25k ZXIgd2hldGhlciB0aG9zZSBob3N0IHJvdXRlcyB3b3VsZCBiZSB1c2VkIGZvciBJUCBmb3J3YXJk aW5nLiBJZiBzbywgc2hvdWxkIHRoaXMgZXh0ZW5zaW9uIHNwZWNpZmljYXRpb24gYmVsb25nIHRv IHRoZSBMM1ZQTiBzY29wZT8NCg0KDQoNClhpYW9odQ0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0Kt6K8/sjLOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmwydnBuLWJv dW5jZXNAaWV0Zi5vcmc+IFtsMnZwbi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpsMnZwbi1ib3Vu Y2VzQGlldGYub3JnPl0gtPqx7SBIZW5kZXJpY2t4LCBXaW0gKFdpbSkgW3dpbS5oZW5kZXJpY2t4 QGFsY2F0ZWwtbHVjZW50LmNvbTxtYWlsdG86d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQu Y29tPl0NCreiy83KsbzkOiAyMDEzxOoxMdTCOcjVIDQ6MTcNCsrVvP7IyzogTHVjeSB5b25nOyBs MnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+DQrW98ziOiBSZTogY29tbWVudCBv biBkcmFmdC1yYWJhZGFuLWwydnBuLWV2cG4tcHJlZml4LWFkdmVydGlzZW1lbnQNCg0KTHVjeSwg ZGlkIHlvdSByZWFkIHRoZSBkcmFmdCBhbmQgaXMgZXhwbGFpbmVkIGluIHNlY3Rpb24gNi4NClNo b3cgYW4gZXhhbXBsZSBvbiBob3cgeW91IGRvIHRoZSBzY2VuYXJpb6GvcyB3aXRoIFJUMiBhbmQg eW91IHdpbGwgc2VlIHdoeSB0aGlzIGlzIGxlc3MgZWZmaWNpZW50L3NjYWxhYmxlICsgZG9lcyBu b3Qgc3VwcG9ydCBhbGwgc2NlbmFyaW+hr3MgaW4gdGhlIGRyYWZ0IGxpa2UgRVNJIE5ILg0KDQpF LVZQTiBkaXN0cmlidXRlcyBob3N0IHJvdXRlcyB1c2luZyBSVC0yOiAoSVApICsgTUFDIGFuZCB0 aGVzZSBjYW4gYmUgYW4gaW50ZXJmYWNlIGUuZy4gQW5kIHByZWZpeGVzIGNhbiBleGlzdHMgYmVo aW5kIHRoZW0uDQoNCkZyb206IEx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5jb208bWFpbHRv Omx1Y3kueW9uZ0BodWF3ZWkuY29tPj4NCkRhdGU6IEZyaWRheSA4IE5vdmVtYmVyIDIwMTMgMjI6 MTANClRvOiAibDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPiIgPGwydnBuQGll dGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4+DQpTdWJqZWN0OiBjb21tZW50IG9uIGRyYWZ0 LXJhYmFkYW4tbDJ2cG4tZXZwbi1wcmVmaXgtYWR2ZXJ0aXNlbWVudA0KDQpIaSBBdXRob3JzLA0K DQpJIGFtIG5vdCBjb252aW5jZWQgaWYgUlQgNSBpcyBuZWNlc3NhcnkgZm9yIHRoZSB1c2UgY2Fz ZXMgeW91IHNwZWNpZmllZCBpbiB0aGUgZHJhZnQgKG9yIHByZXNlbnRhdGlvbikuIElNTzogUlQy IGlzIHN1ZmZpY2llbnQgdG8gc3VwcG9ydCBhbGwgdGhlIGNhc2VzLg0KVGhlcmUgaXMgYSBkcmFm dC15b25nLW52bzMtbnZlLCB3aGljaCBjb3ZlcnMgYWxsIHRoZSBMMiBvdmVybGF5IGNhc2VzLCB3 aGljaCBjYW4gYmUgaW1wbGVtZW50ZWQgYnkgRVZQTiB3aXRoIFJUMi4NCg0KT25lIHF1ZXN0aW9u LCB3aHkgRVZQTiBzZXJ2aWNlIGFsbG93IHRvIFZBUCBiZWluZyBhbiBJUCBpbnRlcmZhY2U/DQoN ClRoYW5rcywNCkx1Y3kNCg== --_000_CEA2918B91319wimhenderickxalcatellucentcom_ Content-Type: text/html; charset="gb2312" Content-ID: Content-Transfer-Encoding: quoted-printable
Have a look at this draft which explains how I works:


From: Xuxiaohu <xuxiaohu@huawei.com>
Date: Friday 8 November 2013 22:59<= br> To: Wim Henderickx <wim.henderickx@alcatel-lucent.com<= /a>>, Lucy yong <lucy.yong@hu= awei.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: =B4=F0=B8=B4: =B4=F0=B8=B4= : comment on draft-rabadan-l2vpn-evpn-prefix-advertisement

Because this extension is intended for L3 forwarding, rather than L2 for= warding anymore. Furthermore, that L3 forwarding is used for inter-subnet t= raffic.

 

Although E-Vpn from the beginning allowed this capability of advertising= IP+MAC, the IP address is not used for L3 forwarding.

 

Xiaohu

=B7=A2=BC=FE=C8=CB: Henderickx, Wim (Wim) = [wim.henderickx@alcate= l-lucent.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C29=C8=D5 4:36
=CA=D5=BC=FE=C8=CB: Xuxiaohu; Lucy yong; l2vpn@ietf.org
=D6=F7=CC=E2: Re: =B4=F0=B8=B4: comment on draft-rabadan-l2vpn-evpn-= prefix-advertisement

I don=A1=AFt see why this should be discussed with L3VPN because E-Vpn= from the beginning allowed this capability. The mechanism described here a= llows to optimise the scenario=A1=AFs. We look at reusing L3VPn AFI/SAFI an= d given there is no MAC or ESI NH it is not suited for all scenario=A1=AFs.
Hence the proposal.


From: Xuxiaohu <xuxiaohu@huawei.com>
Date: Friday 8 November 2013 22:25=
To: Wim Henderickx <wim.henderickx@= alcatel-lucent.com>, Lucy yong <lucy.yong@huawei.com>, "l2vpn@ietf.org" <l2vpn@ietf= .org>
Subject: =B4=F0=B8=B4: comment on = draft-rabadan-l2vpn-evpn-prefix-advertisement

Wim,

 

Since you mentioned that E-VPN distributes host routes, I wond= er whether those host routes would be used for IP forwarding. If so, should= this extension specification belong to the L3VPN scope?

 

Xiaohu

=B7=A2=BC=FE=C8=CB:l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] =B4=FA=B1=ED Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA11=D4=C29=C8=D5 4:17
=CA=D5=BC=FE=C8=CB: Lucy yong; l2vpn@ietf.org
=D6=F7=CC=E2: Re: comment on draft-rabadan-l2vpn-evpn-prefix-adverti= sement

Lucy, did you read the draft and is explained in section 6.
Show an example on how you do the scenario=A1=AFs with RT2 and you wil= l see why this is less efficient/scalable + does not support all scenar= io=A1=AFs in the draft like ESI NH.

E-VPN distributes host routes using RT-2: (IP) + MAC and these can= be an interface e.g. And prefixes can exists behind them.

From: Lucy yong <lucy.yong@huawei.com> Date: Friday 8 November 2013 22:10=
To: "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: comment on draft-rabadan-= l2vpn-evpn-prefix-advertisement

Hi Authors,

 

I am not convinced if RT 5 is necessary for the use = cases you specified in the draft (or presentation). IMO: RT2 is sufficient = to support all the cases.

There is a draft-yong-nvo3-nve, which covers all the= L2 overlay cases, which can be implemented by EVPN with RT2.

 

One question, why EVPN service allow to VAP being an= IP interface?

 

Thanks,

Lucy

 --_000_CEA2918B91319wimhenderickxalcatellucentcom_-- From lucy.yong@huawei.com Sun Nov 10 22:44:02 2013 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 CA9D011E80ED for ; Sun, 10 Nov 2013 22:44:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.908 X-Spam-Level: X-Spam-Status: No, score=-5.908 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=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 Az9eXjDpqmW1 for ; Sun, 10 Nov 2013 22:43:57 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2C01311E8146 for ; Sun, 10 Nov 2013 22:43:56 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAC99451; Mon, 11 Nov 2013 06:43:54 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 11 Nov 2013 06:43:42 +0000 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 11 Nov 2013 06:43:51 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.03.0158.001; Sun, 10 Nov 2013 22:43:42 -0800 From: Lucy yong To: "Henderickx, Wim (Wim)" , Lucy yong , "l2vpn@ietf.org" Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Thread-Topic: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Thread-Index: Ac7cvqYcD4BB2/82Q4+fCPK55cREGP//WkCA//ukXXA= Date: Mon, 11 Nov 2013 06:43:41 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452EC21B@dfweml509-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D452EBE6D@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.129] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D452EC21Bdfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 06:44:02 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D452EC21Bdfweml509mbxchi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Wim, I read the draft and still think that all the use cases work well with RT2.= Here are my views how these use cases in section 5 can be implemented wit= hout RT5 Use case 1 can be done by an L3 VN overlay, say VN10, and a gateway at DCGW= 1 and DCGW2. The gateway is used to interconnect the VN 10 and WAN. The VN10 route the traffic on SN 1 and SN2, SN3, and IP2-IP5. I call this = implementation =93L3VN plus a gateway=94 Why do you want to use an L2 VN ov= erlay here? Use case 2 and use case 4 are about multi-homing. In the case 2, TS and NVE= are co-located; in the case 4, TS and NVE are physically separated. First= of all, IMO, when TS and NVE co-locate on the same server, multi-homed TS = is not necessary. The use case 4 is just the use case 1 with multi-homing. = Thus, it can be implemented by =93L3VN plus a gateway=94 w/ VRRP. In your use case 3, EVI10 should be replaced by an L3 overlay. The VRF on t= he NVE1 acts as the L3 distributed gateway for the EVN1 and EVN2. The VRF = on the NVE2 acts as the L3 distributed gateway for the EVN2 and EVN3. The V= RFs on DGW1 and DGW2 act as the gateway between the L3 overlay and WAN. If = NVE1 and NVE2 use RT2 advertises TS IP/MAC, NVE1 will know IP subnet/prefi= x associating to EVN1 and EVN2, and IP subnet/prefix associating to the L3 = overlay. When NVE1 receives a packet from IP1 and the packet has the destin= ation to SN1, the packet dMAC address will be the MAC address for the distr= ibuted gateway that is the same for all the NVEs. When NVE sees this addres= s, it will perform the VRF table lookup by using the destination IP addr on= the packet, which results the IP addr is associated to the EVN2, then NVE = performs the table look-up in EVI-2 that has both IP/MAC to outer (or VAP) = address mapping, so it will replace the dMAC addr on the packet with the re= al destination MAC addr and send to the VAP that SN1 associated to. When N= VE1 receives a packet from IP1 and the packet has the destination in the WA= N network, the dMAC on the packet is also the MAC address for the distribut= ed gateway. So NVE will perform the VRF table look-up by using the destinat= ion IP on the packet, which results to the outer IP address on one of DGWs,= say DGW1. NVE1 adds the L3 VN ID and the outer header on the packet prior = sending it out. When DGW1 receives the packet, it removes the tunnel header= and uses the L3 VN ID on the packet to reach the vGW on DGW1. The vGW perf= orm the packet treatment before sending to the WAN. L2/L3 NVE service type described in draft-yong-nv03-nve is for this use cas= e. When L2/L3 NVE service type is used, NVE maintains both TS IP/MAC addres= ses but may advertise both IP/MAC addresses or one of the address depending= on the remote NVE service type. When L2 NVE service type is used, NVE just= maintains TS MAC addresses. Both cases can be implemented by EVPN solution= . There are places we need to use L2 VNs. For example, all TSes in a VN have = the same IP address but different MAC addresses; there is broadcast/multic= ast traffic in a VN; non-IP packet. However, we don=92t want to make a comp= lex EVPN solution to solve the case that L3VN can easily address. Regards, Lucy From: HenderickxHi Win,, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.co= m] Sent: Friday, November 08, 2013 2:18 PM To: Lucy yong; l2vpn@ietf.org Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Lucy, did you read the draft and is explained in section 6. Show an example on how you do the scenario=92s with RT2 and you will see wh= y this is less efficient/scalable + does not support all scenario=92s in th= e draft like ESI NH. E-VPN distributes host routes using RT-2: (IP) + MAC and these can be an in= terface e.g. And prefixes can exists behind them. From: Lucy yong > Date: Friday 8 November 2013 22:10 To: "l2vpn@ietf.org" > Subject: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Hi Authors, I am not convinced if RT 5 is necessary for the use cases you specified in = the draft (or presentation). IMO: RT2 is sufficient to support all the case= s. There is a draft-yong-nvo3-nve, which covers all the L2 overlay cases, whic= h can be implemented by EVPN with RT2. One question, why EVPN service allow to VAP being an IP interface? Thanks, Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D452EC21Bdfweml509mbxchi_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Wim,=

 

I read the draft and s= till think that all the use cases work well with RT2.  Here are my vie= ws how these use cases in section 5 can be implemented without RT5

 

Use case 1 can be done= by an L3 VN overlay, say VN10, and a gateway at DCGW1 and DCGW2. The gatew= ay is used to interconnect the VN 10 and WAN.

The VN10 route the tra= ffic on SN 1 and SN2, SN3, and IP2-IP5.  I call this implementation = =93L3VN plus a gateway=94 Why do you want to use an L2 VN overlay here?

 

Use case 2 and use cas= e 4 are about multi-homing. In the case 2, TS and NVE are co-located; in th= e case 4, TS and NVE are physically separated.  First of all, IMO, whe= n TS and NVE co-locate on the same server, multi-homed TS is not necessary. The use case 4 is just the use case 1 wit= h multi-homing. Thus, it can be implemented by =93L3VN plus a gateway=94 w/= VRRP.  

 

In your use case 3, EV= I10 should be replaced by an L3 overlay. The VRF on the NVE1 acts as the L3= distributed gateway for the EVN1 and EVN2.  The VRF on the NVE2 acts = as the L3 distributed gateway for the EVN2 and EVN3. The VRFs on DGW1 and DGW2 act as the gateway between the L3 over= lay and WAN. If NVE1 and NVE2 use RT2 advertises TS IP/MAC,  NVE1 will= know IP subnet/prefix associating to EVN1 and EVN2, and IP subnet/prefix a= ssociating to the L3 overlay. When NVE1 receives a packet from IP1 and the packet has the destination to SN1, the = packet dMAC address will be the MAC address for the distributed gateway tha= t is the same for all the NVEs. When NVE sees this address, it will perform= the VRF table lookup by using the destination IP addr on the packet, which results the IP addr is associated= to the EVN2, then NVE performs the table look-up in EVI-2 that has both IP= /MAC to outer (or VAP) address mapping, so it will replace the dMAC addr on= the packet with the real destination MAC addr and send to the VAP that SN1 associated to.  When NVE1 recei= ves a packet from IP1 and the packet has the destination in the WAN network= , the dMAC on the packet is also the MAC address for the distributed gatewa= y. So NVE will perform the VRF table look-up by using the destination IP on the packet, which results to the ou= ter IP address on one of DGWs, say DGW1. NVE1 adds the L3 VN ID and the out= er header on the packet prior sending it out. When DGW1 receives the packet= , it removes the tunnel header and uses the L3 VN ID on the packet to reach the vGW on DGW1. The vGW perform = the packet treatment before sending to the WAN.

 

L2/L3 NVE service type= described in draft-yong-nv03-nve is for this use case. When L2/L3 NVE serv= ice type is used, NVE maintains both TS IP/MAC addresses but may advertise = both IP/MAC addresses or one of the address depending on the remote NVE service type. When L2 NVE service type= is used, NVE just maintains TS MAC addresses. Both cases can be implemente= d by EVPN solution.

 

There are places we ne= ed to use L2 VNs. For example, all TSes in a VN have the same IP address bu= t different MAC addresses;  there is broadcast/multicast traffic in a = VN; non-IP packet. However, we don=92t want to make a complex EVPN solution to solve the case that L3VN can easily add= ress.  

 

Regards,

Lucy=

 

 

 

 

 

 

 

From: Henderic= kxHi Win,, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]
Sent: Friday, November 08, 2013 2:18 PM
To: Lucy yong; l2vpn@ietf.org
Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t

 

Lucy, d= id you read the draft and is explained in section 6.

Show an= example on how you do the scenario=92s with RT2 and you will see why this = is less efficient/scalable + does not support all scenario=92s in the d= raft like ESI NH.

&n= bsp;

E-VPN d= istributes host routes using RT-2: (IP) + MAC and these can be an inter= face e.g. And prefixes can exists behind them.

&n= bsp;

From: Lucy yong <lucy.yong@huawei.com>
Date: Friday 8 November 2013 22:10
To: "l2vpn@ietf.org"= <l2vpn@ietf.org>
Subject: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement

&n= bsp;

Hi Authors,

 =

I am not convinced if RT= 5 is necessary for the use cases you specified in the draft (or presentati= on). IMO: RT2 is sufficient to support all the cases.

There is a draft-yong-nv= o3-nve, which covers all the L2 overlay cases, which can be implemented by = EVPN with RT2.

 =

One question, why EVPN s= ervice allow to VAP being an IP interface?

 =

Thanks,

Lucy

--_000_2691CE0099834E4A9C5044EEC662BB9D452EC21Bdfweml509mbxchi_-- From wim.henderickx@alcatel-lucent.com Mon Nov 11 00:22:27 2013 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 9591121E8134 for ; Mon, 11 Nov 2013 00:22:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.577 X-Spam-Level: X-Spam-Status: No, score=-8.577 tagged_above=-999 required=5 tests=[AWL=0.821, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] 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 1cQBX5lndG79 for ; Mon, 11 Nov 2013 00:22:21 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 6A8C121E812C for ; Mon, 11 Nov 2013 00:22:19 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id rAB8MEk1021550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 Nov 2013 02:22:15 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rAB8MDuB021705 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Nov 2013 09:22:13 +0100 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.146]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 11 Nov 2013 09:22:13 +0100 From: "Henderickx, Wim (Wim)" To: Lucy yong , "l2vpn@ietf.org" Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Thread-Topic: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Thread-Index: Ac7cvqYcD4BB2/82Q4+fCPK55cREGP//WkCA//ukXXCACOGNgA== Date: Mon, 11 Nov 2013 08:22:13 +0000 Message-ID: In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452EC21B@dfweml509-mbx.china.huawei.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_CEA6503E9170Ewimhenderickxalcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 08:22:27 -0000 --_000_CEA6503E9170Ewimhenderickxalcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable In-line From: Lucy yong > Date: Monday 11 November 2013 08:43 To: Wim Henderickx >, Lucy yong >, "l2vpn@ietf.org" > Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Wim, I read the draft and still think that all the use cases work well with RT2.= Here are my views how these use cases in section 5 can be implemented wit= hout RT5 Use case 1 can be done by an L3 VN overlay, say VN10, and a gateway at DCGW= 1 and DCGW2. The gateway is used to interconnect the VN 10 and WAN. The VN10 route the traffic on SN 1 and SN2, SN3, and IP2-IP5. I call this = implementation =93L3VN plus a gateway=94 Why do you want to use an L2 VN ov= erlay here? WH> you don=92t have a GW IP in the L3VPN AFI/SAFI, so you will need to def= ine a new route to do this efficiently Use case 2 and use case 4 are about multi-homing. In the case 2, TS and NVE= are co-located; in the case 4, TS and NVE are physically separated. First= of all, IMO, when TS and NVE co-locate on the same server, multi-homed TS = is not necessary. The use case 4 is just the use case 1 with multi-homing. = Thus, it can be implemented by =93L3VN plus a gateway=94 w/ VRRP. WH> there is no VRRP in these cases since the appliance is a bump in the wi= re for use case 4 so they don=92t even speak IP, so you have an undefined N= H, which is also not evadable in the L3VPn AFI/SAFI and there is no ESI NH = possible In your use case 3, EVI10 should be replaced by an L3 overlay. The VRF on t= he NVE1 acts as the L3 distributed gateway for the EVN1 and EVN2. The VRF = on the NVE2 acts as the L3 distributed gateway for the EVN2 and EVN3. The V= RFs on DGW1 and DGW2 act as the gateway between the L3 overlay and WAN. If = NVE1 and NVE2 use RT2 advertises TS IP/MAC, NVE1 will know IP subnet/prefi= x associating to EVN1 and EVN2, and IP subnet/prefix associating to the L3 = overlay. When NVE1 receives a packet from IP1 and the packet has the destin= ation to SN1, the packet dMAC address will be the MAC address for the distr= ibuted gateway that is the same for all the NVEs. When NVE sees this addres= s, it will perform the VRF table lookup by using the destination IP addr on= the packet, which results the IP addr is associated to the EVN2, then NVE = performs the table look-up in EVI-2 that has both IP/MAC to outer (or VAP) = address mapping, so it will replace the dMAC addr on the packet with the re= al destination MAC addr and send to the VAP that SN1 associated to. When N= VE1 receives a packet from IP1 and the packet has the destination in the WA= N network, the dMAC on the packet is also the MAC address for the distribut= ed gateway. So NVE will perform the VRF table look-up by using the destinat= ion IP on the packet, which results to the outer IP address on one of DGWs,= say DGW1. NVE1 adds the L3 VN ID and the outer header on the packet prior = sending it out. When DGW1 receives the packet, it removes the tunnel header= and uses the L3 VN ID on the packet to reach the vGW on DGW1. The vGW perf= orm the packet treatment before sending to the WAN. WH> it depends how you want to do this, you can either go route from ingres= s w/o IP lookup on ingress or do a lookup on egress. Both options are possi= ble and required for some HW in the market. EVPN supports both already, wha= t this draft is doing is how prefixes should be used in this environment L2/L3 NVE service type described in draft-yong-nv03-nve is for this use cas= e. When L2/L3 NVE service type is used, NVE maintains both TS IP/MAC addres= ses but may advertise both IP/MAC addresses or one of the address depending= on the remote NVE service type. When L2 NVE service type is used, NVE just= maintains TS MAC addresses. Both cases can be implemented by EVPN solution= . WH> draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 describes the IRB c= ase There are places we need to use L2 VNs. For example, all TSes in a VN have = the same IP address but different MAC addresses; there is broadcast/multic= ast traffic in a VN; non-IP packet. However, we don=92t want to make a comp= lex EVPN solution to solve the case that L3VN can easily address. WH> see draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 it describes it= all. As I said not all use case can be done with L3VPN and this is require= d. Regards, Lucy From: HenderickxHi Win,, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.co= m] Sent: Friday, November 08, 2013 2:18 PM To: Lucy yong; l2vpn@ietf.org Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Lucy, did you read the draft and is explained in section 6. Show an example on how you do the scenario=92s with RT2 and you will see wh= y this is less efficient/scalable + does not support all scenario=92s in th= e draft like ESI NH. E-VPN distributes host routes using RT-2: (IP) + MAC and these can be an in= terface e.g. And prefixes can exists behind them. From: Lucy yong > Date: Friday 8 November 2013 22:10 To: "l2vpn@ietf.org" > Subject: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Hi Authors, I am not convinced if RT 5 is necessary for the use cases you specified in = the draft (or presentation). IMO: RT2 is sufficient to support all the case= s. There is a draft-yong-nvo3-nve, which covers all the L2 overlay cases, whic= h can be implemented by EVPN with RT2. One question, why EVPN service allow to VAP being an IP interface? Thanks, Lucy --_000_CEA6503E9170Ewimhenderickxalcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0A904D8E90901A48BD447542B097217E@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
In-line

From: Lucy yong <lucy.yong@huawei.com>
Date: Monday 11 November 2013 08:43=
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com<= /a>>, Lucy yong <lucy.yong@hu= awei.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: RE: comment on draft-rabad= an-l2vpn-evpn-prefix-advertisement

Wim,=

 

I read the draft and s= till think that all the use cases work well with RT2.  Here are my vie= ws how these use cases in section 5 can be implemented without RT5

 

Use case 1 can be done= by an L3 VN overlay, say VN10, and a gateway at DCGW1 and DCGW2. The gatew= ay is used to interconnect the VN 10 and WAN.

The VN10 route the tra= ffic on SN 1 and SN2, SN3, and IP2-IP5.  I call this implementation = =93L3VN plus a gateway=94 Why do you want to use an L2 VN overlay here?

WH> you don=92t have a GW IP in the L3VPN AFI/SAFI, so you will nee= d to define a new route to do this efficiently

 

Use case 2 and use cas= e 4 are about multi-homing. In the case 2, TS and NVE are co-located; in th= e case 4, TS and NVE are physically separated.  First of all, IMO, whe= n TS and NVE co-locate on the same server, multi-homed TS is not necessary. The use case 4 is just the use case 1 wit= h multi-homing. Thus, it can be implemented by =93L3VN plus a gateway=94 w/= VRRP.  

WH> there is no VRRP in these cases since the appliance is a bump i= n the wire for use case 4 so they don=92t even speak IP, so you have an und= efined NH, which is also not evadable in the L3VPn AFI/SAFI and there is no= ESI NH possible

 

In your use case 3, EV= I10 should be replaced by an L3 overlay. The VRF on the NVE1 acts as the L3= distributed gateway for the EVN1 and EVN2.  The VRF on the NVE2 acts = as the L3 distributed gateway for the EVN2 and EVN3. The VRFs on DGW1 and DGW2 act as the gateway between the L3 over= lay and WAN. If NVE1 and NVE2 use RT2 advertises TS IP/MAC,  NVE1 will= know IP subnet/prefix associating to EVN1 and EVN2, and IP subnet/prefix a= ssociating to the L3 overlay. When NVE1 receives a packet from IP1 and the packet has the destination to SN1, the = packet dMAC address will be the MAC address for the distributed gateway tha= t is the same for all the NVEs. When NVE sees this address, it will perform= the VRF table lookup by using the destination IP addr on the packet, which results the IP addr is associated= to the EVN2, then NVE performs the table look-up in EVI-2 that has both IP= /MAC to outer (or VAP) address mapping, so it will replace the dMAC addr on= the packet with the real destination MAC addr and send to the VAP that SN1 associated to.  When NVE1 recei= ves a packet from IP1 and the packet has the destination in the WAN network= , the dMAC on the packet is also the MAC address for the distributed gatewa= y. So NVE will perform the VRF table look-up by using the destination IP on the packet, which results to the ou= ter IP address on one of DGWs, say DGW1. NVE1 adds the L3 VN ID and the out= er header on the packet prior sending it out. When DGW1 receives the packet= , it removes the tunnel header and uses the L3 VN ID on the packet to reach the vGW on DGW1. The vGW perform = the packet treatment before sending to the WAN.

WH> it depends how you want to do this, you can either go route fro= m ingress w/o IP lookup on ingress or do a lookup on egress. Both options a= re possible and required for some HW in the market. EVPN supports both alre= ady, what this draft is doing is how prefixes should be used in this environment

 

L2/L3 NVE service type= described in draft-yong-nv03-nve is for this use case. When L2/L3 NVE serv= ice type is used, NVE maintains both TS IP/MAC addresses but may advertise = both IP/MAC addresses or one of the address depending on the remote NVE service type. When L2 NVE service type= is used, NVE just maintains TS MAC addresses. Both cases can be implemente= d by EVPN solution.

WH> draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 descri= bes the IRB case

 

There are places we ne= ed to use L2 VNs. For example, all TSes in a VN have the same IP address bu= t different MAC addresses;  there is broadcast/multicast traffic in a = VN; non-IP packet. However, we don=92t want to make a complex EVPN solution to solve the case that L3VN can easily add= ress.  

WH> see draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 it= describes it all. As I said not all use case can be done with L3VPN and th= is is required.

 

Regards,

Lucy=

 

 

 

 

 

 

 

From: HenderickxHi Win,, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]
Sent: Friday, November 08, 2013 2:18 PM
To: Lucy yong; l2vpn@ietf.org<= br> Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t

 

Lucy, d= id you read the draft and is explained in section 6.

Show an= example on how you do the scenario=92s with RT2 and you will see why this = is less efficient/scalable + does not support all scenario=92s in the d= raft like ESI NH.

&n= bsp;

E-VPN d= istributes host routes using RT-2: (IP) + MAC and these can be an inter= face e.g. And prefixes can exists behind them.

&n= bsp;

From: Lucy yong <lucy.yong@huawei.com>
Date: Friday 8 November 2013 22:10
To: "l2vpn@ietf.org"= <l2vpn@ietf.org>
Subject: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement

&n= bsp;

Hi Authors,

 =

I am not convinced if RT= 5 is necessary for the use cases you specified in the draft (or presentati= on). IMO: RT2 is sufficient to support all the cases.

There is a draft-yong-nv= o3-nve, which covers all the L2 overlay cases, which can be implemented by = EVPN with RT2.

 =

One question, why EVPN s= ervice allow to VAP being an IP interface?

 =

Thanks,

Lucy

--_000_CEA6503E9170Ewimhenderickxalcatellucentcom_-- From amclachl@cisco.com Mon Nov 11 05:36:57 2013 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 1950711E8172 for ; Mon, 11 Nov 2013 05:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] 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 E4M6nIoDdYcq for ; Mon, 11 Nov 2013 05:36:45 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1778811E80FA for ; Mon, 11 Nov 2013 05:36:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22795; q=dns/txt; s=iport; t=1384177005; x=1385386605; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=LSHEv41xesdwRdkrNZLGzYG/A2asi2J/3kMAzf9WguE=; b=LJRymrLQS+xTGmqwnRmCWCZSM0n5ShOAbgj5Zp8Qge3Yad0GkZiIRuAX UiP7YyULEi7QkRZEcrYlRr06lBzRMvYmuZxkQF6Un3jRU19Uj2+4Ew/uM NNGCup7W00rOftF/mjCh8QuyVj/Dgc9EJ1A8RVDkEG8UAdzPqGRr+bXo7 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjAFABzdgFKtJV2Y/2dsb2JhbABZgkNEOL9qgToWdIIlAQEBBC1MEAIBCBEDAQEBIQcHMhQJCAEBBA4FGwOHY75Kj1YRBgGDIIEQA5gPkgqDJg X-IronPort-AV: E=Sophos;i="4.93,677,1378857600"; d="scan'208,217";a="280255479" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 11 Nov 2013 13:36:22 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rABDaL9q023553 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Nov 2013 13:36:21 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.191]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Mon, 11 Nov 2013 07:36:21 -0600 From: "Andrew McLachlan (amclachl)" To: "Henderickx, Wim (Wim)" Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Thread-Topic: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Thread-Index: Ac7cvqYcD4BB2/82Q4+fCPK55cREGP//WkCA//ukXXCACOGNgIAAaI3R Date: Mon, 11 Nov 2013 13:36:21 +0000 Message-ID: <1A914EDF-7BE7-4AFA-AFFA-7068DCF22FFB@cisco.com> References: <2691CE0099834E4A9C5044EEC662BB9D452EC21B@dfweml509-mbx.china.huawei.com>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_1A914EDF7BE74AFAAFFA7068DCF22FFBciscocom_" MIME-Version: 1.0 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 13:36:58 -0000 --_000_1A914EDF7BE74AFAAFFA7068DCF22FFBciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Wim, thank you for clarifying this. I just read your comments and drafts yo= u refer to, and what you detail would be the right approach imo. On 11 Nov 2013, at 08:22, "Henderickx, Wim (Wim)" > wrote: In-line From: Lucy yong > Date: Monday 11 November 2013 08:43 To: Wim Henderickx >, Lucy yong >, "l2vpn@ietf.org" > Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Wim, I read the draft and still think that all the use cases work well with RT2.= Here are my views how these use cases in section 5 can be implemented wit= hout RT5 Use case 1 can be done by an L3 VN overlay, say VN10, and a gateway at DCGW= 1 and DCGW2. The gateway is used to interconnect the VN 10 and WAN. The VN10 route the traffic on SN 1 and SN2, SN3, and IP2-IP5. I call this = implementation =93L3VN plus a gateway=94 Why do you want to use an L2 VN ov= erlay here? WH> you don=92t have a GW IP in the L3VPN AFI/SAFI, so you will need to def= ine a new route to do this efficiently Use case 2 and use case 4 are about multi-homing. In the case 2, TS and NVE= are co-located; in the case 4, TS and NVE are physically separated. First= of all, IMO, when TS and NVE co-locate on the same server, multi-homed TS = is not necessary. The use case 4 is just the use case 1 with multi-homing. = Thus, it can be implemented by =93L3VN plus a gateway=94 w/ VRRP. WH> there is no VRRP in these cases since the appliance is a bump in the wi= re for use case 4 so they don=92t even speak IP, so you have an undefined N= H, which is also not evadable in the L3VPn AFI/SAFI and there is no ESI NH = possible In your use case 3, EVI10 should be replaced by an L3 overlay. The VRF on t= he NVE1 acts as the L3 distributed gateway for the EVN1 and EVN2. The VRF = on the NVE2 acts as the L3 distributed gateway for the EVN2 and EVN3. The V= RFs on DGW1 and DGW2 act as the gateway between the L3 overlay and WAN. If = NVE1 and NVE2 use RT2 advertises TS IP/MAC, NVE1 will know IP subnet/prefi= x associating to EVN1 and EVN2, and IP subnet/prefix associating to the L3 = overlay. When NVE1 receives a packet from IP1 and the packet has the destin= ation to SN1, the packet dMAC address will be the MAC address for the distr= ibuted gateway that is the same for all the NVEs. When NVE sees this addres= s, it will perform the VRF table lookup by using the destination IP addr on= the packet, which results the IP addr is associated to the EVN2, then NVE = performs the table look-up in EVI-2 that has both IP/MAC to outer (or VAP) = address mapping, so it will replace the dMAC addr on the packet with the re= al destination MAC addr and send to the VAP that SN1 associated to. When N= VE1 receives a packet from IP1 and the packet has the destination in the WA= N network, the dMAC on the packet is also the MAC address for the distribut= ed gateway. So NVE will perform the VRF table look-up by using the destinat= ion IP on the packet, which results to the outer IP address on one of DGWs,= say DGW1. NVE1 adds the L3 VN ID and the outer header on the packet prior = sending it out. When DGW1 receives the packet, it removes the tunnel header= and uses the L3 VN ID on the packet to reach the vGW on DGW1. The vGW perf= orm the packet treatment before sending to the WAN. WH> it depends how you want to do this, you can either go route from ingres= s w/o IP lookup on ingress or do a lookup on egress. Both options are possi= ble and required for some HW in the market. EVPN supports both already, wha= t this draft is doing is how prefixes should be used in this environment L2/L3 NVE service type described in draft-yong-nv03-nve is for this use cas= e. When L2/L3 NVE service type is used, NVE maintains both TS IP/MAC addres= ses but may advertise both IP/MAC addresses or one of the address depending= on the remote NVE service type. When L2 NVE service type is used, NVE just= maintains TS MAC addresses. Both cases can be implemented by EVPN solution= . WH> draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 describes the IRB c= ase There are places we need to use L2 VNs. For example, all TSes in a VN have = the same IP address but different MAC addresses; there is broadcast/multic= ast traffic in a VN; non-IP packet. However, we don=92t want to make a comp= lex EVPN solution to solve the case that L3VN can easily address. WH> see draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 it describes it= all. As I said not all use case can be done with L3VPN and this is require= d. Regards, Lucy From: HenderickxHi Win,, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.co= m] Sent: Friday, November 08, 2013 2:18 PM To: Lucy yong; l2vpn@ietf.org Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Lucy, did you read the draft and is explained in section 6. Show an example on how you do the scenario=92s with RT2 and you will see wh= y this is less efficient/scalable + does not support all scenario=92s in th= e draft like ESI NH. E-VPN distributes host routes using RT-2: (IP) + MAC and these can be an in= terface e.g. And prefixes can exists behind them. From: Lucy yong > Date: Friday 8 November 2013 22:10 To: "l2vpn@ietf.org" > Subject: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Hi Authors, I am not convinced if RT 5 is necessary for the use cases you specified in = the draft (or presentation). IMO: RT2 is sufficient to support all the case= s. There is a draft-yong-nvo3-nve, which covers all the L2 overlay cases, whic= h can be implemented by EVPN with RT2. One question, why EVPN service allow to VAP being an IP interface? Thanks, Lucy --_000_1A914EDF7BE74AFAAFFA7068DCF22FFBciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Wim, thank you for clarifying this. I just read your comments and draf= ts you refer to, and what you detail would be the right approach imo.



On 11 Nov 2013, at 08:22, "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com= > wrote:

In-line

From: Lucy yong <lucy.yong@huawei.com>
Date: Monday 11 November 2013 08:43=
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com<= /a>>, Lucy yong <lucy.yong@hu= awei.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: RE: comment on draft-rabad= an-l2vpn-evpn-prefix-advertisement

Wim,=

 

I read the draft and s= till think that all the use cases work well with RT2.  Here are my vie= ws how these use cases in section 5 can be implemented without RT5

 

Use case 1 can be done= by an L3 VN overlay, say VN10, and a gateway at DCGW1 and DCGW2. The gatew= ay is used to interconnect the VN 10 and WAN.

The VN10 route the tra= ffic on SN 1 and SN2, SN3, and IP2-IP5.  I call this implementation = =93L3VN plus a gateway=94 Why do you want to use an L2 VN overlay here?

WH> you don=92t have a GW IP in the L3VPN AFI/SAFI, so you will nee= d to define a new route to do this efficiently

 

Use case 2 and use cas= e 4 are about multi-homing. In the case 2, TS and NVE are co-located; in th= e case 4, TS and NVE are physically separated.  First of all, IMO, whe= n TS and NVE co-locate on the same server, multi-homed TS is not necessary. The use case 4 is just the use case 1 wit= h multi-homing. Thus, it can be implemented by =93L3VN plus a gateway=94 w/= VRRP.  

WH> there is no VRRP in these cases since the appliance is a bump i= n the wire for use case 4 so they don=92t even speak IP, so you have an und= efined NH, which is also not evadable in the L3VPn AFI/SAFI and there is no= ESI NH possible

 

In your use case 3, EV= I10 should be replaced by an L3 overlay. The VRF on the NVE1 acts as the L3= distributed gateway for the EVN1 and EVN2.  The VRF on the NVE2 acts = as the L3 distributed gateway for the EVN2 and EVN3. The VRFs on DGW1 and DGW2 act as the gateway between the L3 over= lay and WAN. If NVE1 and NVE2 use RT2 advertises TS IP/MAC,  NVE1 will= know IP subnet/prefix associating to EVN1 and EVN2, and IP subnet/prefix a= ssociating to the L3 overlay. When NVE1 receives a packet from IP1 and the packet has the destination to SN1, the = packet dMAC address will be the MAC address for the distributed gateway tha= t is the same for all the NVEs. When NVE sees this address, it will perform= the VRF table lookup by using the destination IP addr on the packet, which results the IP addr is associated= to the EVN2, then NVE performs the table look-up in EVI-2 that has both IP= /MAC to outer (or VAP) address mapping, so it will replace the dMAC addr on= the packet with the real destination MAC addr and send to the VAP that SN1 associated to.  When NVE1 recei= ves a packet from IP1 and the packet has the destination in the WAN network= , the dMAC on the packet is also the MAC address for the distributed gatewa= y. So NVE will perform the VRF table look-up by using the destination IP on the packet, which results to the ou= ter IP address on one of DGWs, say DGW1. NVE1 adds the L3 VN ID and the out= er header on the packet prior sending it out. When DGW1 receives the packet= , it removes the tunnel header and uses the L3 VN ID on the packet to reach the vGW on DGW1. The vGW perform = the packet treatment before sending to the WAN.

WH> it depends how you want to do this, you can either go route fro= m ingress w/o IP lookup on ingress or do a lookup on egress. Both options a= re possible and required for some HW in the market. EVPN supports both alre= ady, what this draft is doing is how prefixes should be used in this environment

 

L2/L3 NVE service type= described in draft-yong-nv03-nve is for this use case. When L2/L3 NVE serv= ice type is used, NVE maintains both TS IP/MAC addresses but may advertise = both IP/MAC addresses or one of the address depending on the remote NVE service type. When L2 NVE service type= is used, NVE just maintains TS MAC addresses. Both cases can be implemente= d by EVPN solution.

WH> draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 descri= bes the IRB case

 

There are places we ne= ed to use L2 VNs. For example, all TSes in a VN have the same IP address bu= t different MAC addresses;  there is broadcast/multicast traffic in a = VN; non-IP packet. However, we don=92t want to make a complex EVPN solution to solve the case that L3VN can easily add= ress.  

WH> see draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 it= describes it all. As I said not all use case can be done with L3VPN and th= is is required.

 

Regards,

Lucy=

 

 

 

 

 

 

 

From: HenderickxHi Win,, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]
Sent: Friday, November 08, 2013 2:18 PM
To: Lucy yong; l2vpn@ietf.org<= br> Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t

 

Lucy, d= id you read the draft and is explained in section 6.

Show an= example on how you do the scenario=92s with RT2 and you will see why this = is less efficient/scalable + does not support all scenario=92s in the d= raft like ESI NH.

&n= bsp;

E-VPN d= istributes host routes using RT-2: (IP) + MAC and these can be an inter= face e.g. And prefixes can exists behind them.

&n= bsp;

From: Lucy yong <lucy.yong@huawei.com>
Date: Friday 8 November 2013 22:10
To: "l2vpn@ietf.org"= <l2vpn@ietf.org>
Subject: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement

&n= bsp;

Hi Authors,

 =

I am not convinced if RT= 5 is necessary for the use cases you specified in the draft (or presentati= on). IMO: RT2 is sufficient to support all the cases.

There is a draft-yong-nv= o3-nve, which covers all the L2 overlay cases, which can be implemented by = EVPN with RT2.

 =

One question, why EVPN s= ervice allow to VAP being an IP interface?

 =

Thanks,

Lucy

--_000_1A914EDF7BE74AFAAFFA7068DCF22FFBciscocom_-- From jorge.rabadan@alcatel-lucent.com Mon Nov 11 07:52:35 2013 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 1C70B11E8107 for ; Mon, 11 Nov 2013 07:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.998 X-Spam-Level: X-Spam-Status: No, score=-9.998 tagged_above=-999 required=5 tests=[AWL=-0.601, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] 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 sH5tIGhWy9mj for ; Mon, 11 Nov 2013 07:52:28 -0800 (PST) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 561B411E818D for ; Mon, 11 Nov 2013 07:52:28 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id rABFqOge029765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 Nov 2013 09:52:26 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rABFqOsi006898 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Nov 2013 16:52:24 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.151]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Mon, 11 Nov 2013 16:52:24 +0100 From: "Rabadan, Jorge (Jorge)" To: "Andrew McLachlan (amclachl)" , "Henderickx, Wim (Wim)" Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Thread-Topic: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Thread-Index: Ac7cvqYcD4BB2/82Q4+fCPK55cREGP//WkCA//ukXXCACOGNgIAAaI3R//+PIQA= Date: Mon, 11 Nov 2013 15:52:24 +0000 Message-ID: In-Reply-To: <1A914EDF-7BE7-4AFA-AFFA-7068DCF22FFB@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [135.239.27.41] Content-Type: multipart/alternative; boundary="_000_CEA63B0728F00jorgerabadanalcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 15:52:35 -0000 --_000_CEA63B0728F00jorgerabadanalcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Besides Wim=92s comments, section 2.2 tries to summarize why L3VPN does not= meet all the requirements in this environment. We need the flexibility given by the overlay next-hops within the NLRI: GW = IP and ESI. Section 2.3 gives some of the reason why a new EVPN route type is needed. Thanks. Jorge From: "Andrew McLachlan (amclachl)" > Date: Monday, November 11, 2013 at 5:36 AM To: "Henderickx, Wim (Wim)" > Cc: "l2vpn@ietf.org" > Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Wim, thank you for clarifying this. I just read your comments and drafts yo= u refer to, and what you detail would be the right approach imo. On 11 Nov 2013, at 08:22, "Henderickx, Wim (Wim)" > wrote: In-line From: Lucy yong > Date: Monday 11 November 2013 08:43 To: Wim Henderickx >, Lucy yong >, "l2vpn@ietf.org" > Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Wim, I read the draft and still think that all the use cases work well with RT2.= Here are my views how these use cases in section 5 can be implemented wit= hout RT5 Use case 1 can be done by an L3 VN overlay, say VN10, and a gateway at DCGW= 1 and DCGW2. The gateway is used to interconnect the VN 10 and WAN. The VN10 route the traffic on SN 1 and SN2, SN3, and IP2-IP5. I call this = implementation =93L3VN plus a gateway=94 Why do you want to use an L2 VN ov= erlay here? WH> you don=92t have a GW IP in the L3VPN AFI/SAFI, so you will need to def= ine a new route to do this efficiently Use case 2 and use case 4 are about multi-homing. In the case 2, TS and NVE= are co-located; in the case 4, TS and NVE are physically separated. First= of all, IMO, when TS and NVE co-locate on the same server, multi-homed TS = is not necessary. The use case 4 is just the use case 1 with multi-homing. = Thus, it can be implemented by =93L3VN plus a gateway=94 w/ VRRP. WH> there is no VRRP in these cases since the appliance is a bump in the wi= re for use case 4 so they don=92t even speak IP, so you have an undefined N= H, which is also not evadable in the L3VPn AFI/SAFI and there is no ESI NH = possible In your use case 3, EVI10 should be replaced by an L3 overlay. The VRF on t= he NVE1 acts as the L3 distributed gateway for the EVN1 and EVN2. The VRF = on the NVE2 acts as the L3 distributed gateway for the EVN2 and EVN3. The V= RFs on DGW1 and DGW2 act as the gateway between the L3 overlay and WAN. If = NVE1 and NVE2 use RT2 advertises TS IP/MAC, NVE1 will know IP subnet/prefi= x associating to EVN1 and EVN2, and IP subnet/prefix associating to the L3 = overlay. When NVE1 receives a packet from IP1 and the packet has the destin= ation to SN1, the packet dMAC address will be the MAC address for the distr= ibuted gateway that is the same for all the NVEs. When NVE sees this addres= s, it will perform the VRF table lookup by using the destination IP addr on= the packet, which results the IP addr is associated to the EVN2, then NVE = performs the table look-up in EVI-2 that has both IP/MAC to outer (or VAP) = address mapping, so it will replace the dMAC addr on the packet with the re= al destination MAC addr and send to the VAP that SN1 associated to. When N= VE1 receives a packet from IP1 and the packet has the destination in the WA= N network, the dMAC on the packet is also the MAC address for the distribut= ed gateway. So NVE will perform the VRF table look-up by using the destinat= ion IP on the packet, which results to the outer IP address on one of DGWs,= say DGW1. NVE1 adds the L3 VN ID and the outer header on the packet prior = sending it out. When DGW1 receives the packet, it removes the tunnel header= and uses the L3 VN ID on the packet to reach the vGW on DGW1. The vGW perf= orm the packet treatment before sending to the WAN. WH> it depends how you want to do this, you can either go route from ingres= s w/o IP lookup on ingress or do a lookup on egress. Both options are possi= ble and required for some HW in the market. EVPN supports both already, wha= t this draft is doing is how prefixes should be used in this environment L2/L3 NVE service type described in draft-yong-nv03-nve is for this use cas= e. When L2/L3 NVE service type is used, NVE maintains both TS IP/MAC addres= ses but may advertise both IP/MAC addresses or one of the address depending= on the remote NVE service type. When L2 NVE service type is used, NVE just= maintains TS MAC addresses. Both cases can be implemented by EVPN solution= . WH> draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 describes the IRB c= ase There are places we need to use L2 VNs. For example, all TSes in a VN have = the same IP address but different MAC addresses; there is broadcast/multic= ast traffic in a VN; non-IP packet. However, we don=92t want to make a comp= lex EVPN solution to solve the case that L3VN can easily address. WH> see draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 it describes it= all. As I said not all use case can be done with L3VPN and this is require= d. Regards, Lucy From: HenderickxHi Win,, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.co= m] Sent: Friday, November 08, 2013 2:18 PM To: Lucy yong; l2vpn@ietf.org Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Lucy, did you read the draft and is explained in section 6. Show an example on how you do the scenario=92s with RT2 and you will see wh= y this is less efficient/scalable + does not support all scenario=92s in th= e draft like ESI NH. E-VPN distributes host routes using RT-2: (IP) + MAC and these can be an in= terface e.g. And prefixes can exists behind them. From: Lucy yong > Date: Friday 8 November 2013 22:10 To: "l2vpn@ietf.org" > Subject: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Hi Authors, I am not convinced if RT 5 is necessary for the use cases you specified in = the draft (or presentation). IMO: RT2 is sufficient to support all the case= s. There is a draft-yong-nvo3-nve, which covers all the L2 overlay cases, whic= h can be implemented by EVPN with RT2. One question, why EVPN service allow to VAP being an IP interface? Thanks, Lucy --_000_CEA63B0728F00jorgerabadanalcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <7B8762A7CF0D3846A69B171F82901E6F@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
Besides Wim=92s comments, section 2.2 tries to summarize why L3VPN doe= s not meet all the requirements in this environment. 
We need the flexibility given by the overlay next-hops within the NLRI= : GW IP and ESI.

Section 2.3 gives some of the reason why a new EVPN route type is need= ed.

Thanks.
Jorge

From: "Andrew McLachlan (amcla= chl)" <amclachl@cisco.com= >
Date: Monday, November 11, 2013 at = 5:36 AM
To: "Henderickx, Wim (Wim)&quo= t; <wim.henderickx@= alcatel-lucent.com>
Cc: "l2vpn@ietf.org" <l2v= pn@ietf.org>
Subject: Re: comment on draft-rabad= an-l2vpn-evpn-prefix-advertisement


Wim, thank you for clarifying this. I just read your comments and draf= ts you refer to, and what you detail would be the right approach imo.



On 11 Nov 2013, at 08:22, "Henderickx, Wim (Wim)" <wim.henderickx@alcatel-lucent.com= > wrote:

In-line

From: Lucy yong <lucy.yong@huawei.com>
Date: Monday 11 November 2013 08:43=
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com<= /a>>, Lucy yong <lucy.yong@hu= awei.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: RE: comment on draft-rabad= an-l2vpn-evpn-prefix-advertisement

Wim,=

 

I read the draft and s= till think that all the use cases work well with RT2.  Here are my vie= ws how these use cases in section 5 can be implemented without RT5

 

Use case 1 can be done= by an L3 VN overlay, say VN10, and a gateway at DCGW1 and DCGW2. The gatew= ay is used to interconnect the VN 10 and WAN.

The VN10 route the tra= ffic on SN 1 and SN2, SN3, and IP2-IP5.  I call this implementation = =93L3VN plus a gateway=94 Why do you want to use an L2 VN overlay here?

WH> you don=92t have a GW IP in the L3VPN AFI/SAFI, so you will nee= d to define a new route to do this efficiently

 

Use case 2 and use cas= e 4 are about multi-homing. In the case 2, TS and NVE are co-located; in th= e case 4, TS and NVE are physically separated.  First of all, IMO, whe= n TS and NVE co-locate on the same server, multi-homed TS is not necessary. The use case 4 is just the use case 1 wit= h multi-homing. Thus, it can be implemented by =93L3VN plus a gateway=94 w/= VRRP.  

WH> there is no VRRP in these cases since the appliance is a bump i= n the wire for use case 4 so they don=92t even speak IP, so you have an und= efined NH, which is also not evadable in the L3VPn AFI/SAFI and there is no= ESI NH possible

 

In your use case 3, EV= I10 should be replaced by an L3 overlay. The VRF on the NVE1 acts as the L3= distributed gateway for the EVN1 and EVN2.  The VRF on the NVE2 acts = as the L3 distributed gateway for the EVN2 and EVN3. The VRFs on DGW1 and DGW2 act as the gateway between the L3 over= lay and WAN. If NVE1 and NVE2 use RT2 advertises TS IP/MAC,  NVE1 will= know IP subnet/prefix associating to EVN1 and EVN2, and IP subnet/prefix a= ssociating to the L3 overlay. When NVE1 receives a packet from IP1 and the packet has the destination to SN1, the = packet dMAC address will be the MAC address for the distributed gateway tha= t is the same for all the NVEs. When NVE sees this address, it will perform= the VRF table lookup by using the destination IP addr on the packet, which results the IP addr is associated= to the EVN2, then NVE performs the table look-up in EVI-2 that has both IP= /MAC to outer (or VAP) address mapping, so it will replace the dMAC addr on= the packet with the real destination MAC addr and send to the VAP that SN1 associated to.  When NVE1 recei= ves a packet from IP1 and the packet has the destination in the WAN network= , the dMAC on the packet is also the MAC address for the distributed gatewa= y. So NVE will perform the VRF table look-up by using the destination IP on the packet, which results to the ou= ter IP address on one of DGWs, say DGW1. NVE1 adds the L3 VN ID and the out= er header on the packet prior sending it out. When DGW1 receives the packet= , it removes the tunnel header and uses the L3 VN ID on the packet to reach the vGW on DGW1. The vGW perform = the packet treatment before sending to the WAN.

WH> it depends how you want to do this, you can either go route fro= m ingress w/o IP lookup on ingress or do a lookup on egress. Both options a= re possible and required for some HW in the market. EVPN supports both alre= ady, what this draft is doing is how prefixes should be used in this environment

 

L2/L3 NVE service type= described in draft-yong-nv03-nve is for this use case. When L2/L3 NVE serv= ice type is used, NVE maintains both TS IP/MAC addresses but may advertise = both IP/MAC addresses or one of the address depending on the remote NVE service type. When L2 NVE service type= is used, NVE just maintains TS MAC addresses. Both cases can be implemente= d by EVPN solution.

WH> draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 descri= bes the IRB case

 

There are places we ne= ed to use L2 VNs. For example, all TSes in a VN have the same IP address bu= t different MAC addresses;  there is broadcast/multicast traffic in a = VN; non-IP packet. However, we don=92t want to make a complex EVPN solution to solve the case that L3VN can easily add= ress.  

WH> see draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 it= describes it all. As I said not all use case can be done with L3VPN and th= is is required.

 

Regards,

Lucy=

 

 

 

 

 

 

 

From: HenderickxHi Win,, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]
Sent: Friday, November 08, 2013 2:18 PM
To: Lucy yong; l2vpn@ietf.org<= br> Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t

 

Lucy, d= id you read the draft and is explained in section 6.

Show an= example on how you do the scenario=92s with RT2 and you will see why this = is less efficient/scalable + does not support all scenario=92s in the d= raft like ESI NH.

&n= bsp;

E-VPN d= istributes host routes using RT-2: (IP) + MAC and these can be an inter= face e.g. And prefixes can exists behind them.

&n= bsp;

From: Lucy yong <lucy.yong@huawei.com>
Date: Friday 8 November 2013 22:10
To: "l2vpn@ietf.org"= <l2vpn@ietf.org>
Subject: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement

&n= bsp;

Hi Authors,

 =

I am not convinced if RT= 5 is necessary for the use cases you specified in the draft (or presentati= on). IMO: RT2 is sufficient to support all the cases.

There is a draft-yong-nv= o3-nve, which covers all the L2 overlay cases, which can be implemented by = EVPN with RT2.

 =

One question, why EVPN s= ervice allow to VAP being an IP interface?

 =

Thanks,

Lucy

--_000_CEA63B0728F00jorgerabadanalcatellucentcom_-- From lucy.yong@huawei.com Mon Nov 11 19:11:43 2013 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 5971311E81AB for ; Mon, 11 Nov 2013 19:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.071 X-Spam-Level: X-Spam-Status: No, score=-5.071 tagged_above=-999 required=5 tests=[AWL=-0.673, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, 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 Ju+1koS5xRcu for ; Mon, 11 Nov 2013 19:11:38 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B0A7611E81A8 for ; Mon, 11 Nov 2013 19:11:36 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXT99636; Tue, 12 Nov 2013 03:11:35 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 03:11:22 +0000 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 03:11:34 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.03.0158.001; Mon, 11 Nov 2013 19:11:24 -0800 From: Lucy yong To: "Henderickx, Wim (Wim)" , Lucy yong , "l2vpn@ietf.org" Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Thread-Topic: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Thread-Index: Ac7cvqYcD4BB2/82Q4+fCPK55cREGP//WkCA//ukXXCACOGNgP/+4T1A Date: Tue, 12 Nov 2013 03:11:23 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452ECD3F@dfweml509-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D452EC21B@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.47.139.132] Content-Type: multipart/related; boundary="_005_2691CE0099834E4A9C5044EEC662BB9D452ECD3Fdfweml509mbxchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 03:11:43 -0000 --_005_2691CE0099834E4A9C5044EEC662BB9D452ECD3Fdfweml509mbxchi_ Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D452ECD3Fdfweml509mbxchi_" --_000_2691CE0099834E4A9C5044EEC662BB9D452ECD3Fdfweml509mbxchi_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Wim, When using a (centralized) gateway to provide external network connection f= or an L2 VN, I agree, it is necessary for the gateway to advertise its IP h= ost address and MAC to all the NVEs in the L2VN. This can be done by the RT= 2, right? NVEs also use RT2 tenant IP/MAC addresses. Thus, each NVE will kn= ow the gateway IP host and MAC address and perform the proxy ARP function, = i.e. terminate the ARP requests if the requested tenant systems (including = gateway) is not in local, and send back the requested MAC in ARP reply. Th= us, tenant system will send an L2 frame with designation tenant system or g= ateway MAC in dMAC to attached NVE, the NVE just performs the table lookup = to obtain the outer address. There is no IP routing table on NVEs because o= f the L2VN. What is the problem here? Why need to use RT5 to convey the GW= IP/MAC info? Please explain, I may miss some part in nutshell. When using a gateway to provide external network connection for an L3 VN, N= VEs use their MAC address in ARP reply if VAP is L2 access interface. The L= 2 frame from a tenant system will be terminated at NVEs regardless the dest= ination tenant system is in the same VN or not. NVEs should have all the IP= routes in the VN. When NVE performs a lookup and is not able to find the m= atching one, it means the packet for the external. Since the gateway adver= tises its IP host address to NVEs as the gateway for the L3VN, NVEs will fo= rward the packets going to external to the gateway. In this case, the NVE = acts as the first-hop router, the gateway is the last-hop in the VN. You a= re right, it is necessary for a gateway to advertise its role besides its I= P address. If this is not there, should improve the protocol. Regarding the IRB capability, this is my view about IRB implementation in v= irtual overlay environment. [cid:image001.png@01CEDF20.763D4F00] Figure shows two L2VNs, VNx and VNz. NVE1 and NVE2 are member of both VNs.= If NVE1 and NVE2 implement L3 distributed gateway functions and have the s= ame MAC address for the L3dGW. When NVEs advertise both Tenant system IP an= d MAC addresses, each NVE have all the information about tenant systems in = both VNs. NVEs still terminates the ARP requests and provide the MAC for th= e remote tenant system in the same VN. NVEs returns L3dGW addresses for the= GW ARP request or if no matching MAC are founded. Thus, only the L3dGW at= ingress NVE process inter-VN traffic forwarding, i.e. the traffic from VNx= TS on NVE1 goes through the L3dGW on NVE1 to reach the VNy TS on NVE1 or V= Ny TS on NVE2. Will this make sense to you? Thanks, Lucy From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Monday, November 11, 2013 2:22 AM To: Lucy yong; l2vpn@ietf.org Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement In-line From: Lucy yong > Date: Monday 11 November 2013 08:43 To: Wim Henderickx >, Lucy yong >, "l2vpn@ietf.org" > Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Wim, I read the draft and still think that all the use cases work well with RT2.= Here are my views how these use cases in section 5 can be implemented wit= hout RT5 Use case 1 can be done by an L3 VN overlay, say VN10, and a gateway at DCGW= 1 and DCGW2. The gateway is used to interconnect the VN 10 and WAN. The VN10 route the traffic on SN 1 and SN2, SN3, and IP2-IP5. I call this = implementation =93L3VN plus a gateway=94 Why do you want to use an L2 VN ov= erlay here? WH> you don=92t have a GW IP in the L3VPN AFI/SAFI, so you will need to def= ine a new route to do this efficiently Use case 2 and use case 4 are about multi-homing. In the case 2, TS and NVE= are co-located; in the case 4, TS and NVE are physically separated. First= of all, IMO, when TS and NVE co-locate on the same server, multi-homed TS = is not necessary. The use case 4 is just the use case 1 with multi-homing. = Thus, it can be implemented by =93L3VN plus a gateway=94 w/ VRRP. WH> there is no VRRP in these cases since the appliance is a bump in the wi= re for use case 4 so they don=92t even speak IP, so you have an undefined N= H, which is also not evadable in the L3VPn AFI/SAFI and there is no ESI NH = possible In your use case 3, EVI10 should be replaced by an L3 overlay. The VRF on t= he NVE1 acts as the L3 distributed gateway for the EVN1 and EVN2. The VRF = on the NVE2 acts as the L3 distributed gateway for the EVN2 and EVN3. The V= RFs on DGW1 and DGW2 act as the gateway between the L3 overlay and WAN. If = NVE1 and NVE2 use RT2 advertises TS IP/MAC, NVE1 will know IP subnet/prefi= x associating to EVN1 and EVN2, and IP subnet/prefix associating to the L3 = overlay. When NVE1 receives a packet from IP1 and the packet has the destin= ation to SN1, the packet dMAC address will be the MAC address for the distr= ibuted gateway that is the same for all the NVEs. When NVE sees this addres= s, it will perform the VRF table lookup by using the destination IP addr on= the packet, which results the IP addr is associated to the EVN2, then NVE = performs the table look-up in EVI-2 that has both IP/MAC to outer (or VAP) = address mapping, so it will replace the dMAC addr on the packet with the re= al destination MAC addr and send to the VAP that SN1 associated to. When N= VE1 receives a packet from IP1 and the packet has the destination in the WA= N network, the dMAC on the packet is also the MAC address for the distribut= ed gateway. So NVE will perform the VRF table look-up by using the destinat= ion IP on the packet, which results to the outer IP address on one of DGWs,= say DGW1. NVE1 adds the L3 VN ID and the outer header on the packet prior = sending it out. When DGW1 receives the packet, it removes the tunnel header= and uses the L3 VN ID on the packet to reach the vGW on DGW1. The vGW perf= orm the packet treatment before sending to the WAN. WH> it depends how you want to do this, you can either go route from ingres= s w/o IP lookup on ingress or do a lookup on egress. Both options are possi= ble and required for some HW in the market. EVPN supports both already, wha= t this draft is doing is how prefixes should be used in this environment L2/L3 NVE service type described in draft-yong-nv03-nve is for this use cas= e. When L2/L3 NVE service type is used, NVE maintains both TS IP/MAC addres= ses but may advertise both IP/MAC addresses or one of the address depending= on the remote NVE service type. When L2 NVE service type is used, NVE just= maintains TS MAC addresses. Both cases can be implemented by EVPN solution= . WH> draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 describes the IRB c= ase There are places we need to use L2 VNs. For example, all TSes in a VN have = the same IP address but different MAC addresses; there is broadcast/multic= ast traffic in a VN; non-IP packet. However, we don=92t want to make a comp= lex EVPN solution to solve the case that L3VN can easily address. WH> see draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 it describes it= all. As I said not all use case can be done with L3VPN and this is require= d. Regards, Lucy From: HenderickxHi Win,, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.co= m] Sent: Friday, November 08, 2013 2:18 PM To: Lucy yong; l2vpn@ietf.org Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Lucy, did you read the draft and is explained in section 6. Show an example on how you do the scenario=92s with RT2 and you will see wh= y this is less efficient/scalable + does not support all scenario=92s in th= e draft like ESI NH. E-VPN distributes host routes using RT-2: (IP) + MAC and these can be an in= terface e.g. And prefixes can exists behind them. From: Lucy yong > Date: Friday 8 November 2013 22:10 To: "l2vpn@ietf.org" > Subject: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Hi Authors, I am not convinced if RT 5 is necessary for the use cases you specified in = the draft (or presentation). IMO: RT2 is sufficient to support all the case= s. There is a draft-yong-nvo3-nve, which covers all the L2 overlay cases, whic= h can be implemented by EVPN with RT2. One question, why EVPN service allow to VAP being an IP interface? Thanks, Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D452ECD3Fdfweml509mbxchi_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Wim,=

 

When using a (centrali= zed) gateway to provide external network connection for an L2 VN, I agree, = it is necessary for the gateway to advertise its IP host address and MAC to= all the NVEs in the L2VN. This can be done by the RT2, right? NVEs also use RT2 tenant IP/MAC addresses. Thus= , each NVE will know the gateway IP host and MAC address and perform the pr= oxy ARP function, i.e. terminate the ARP requests if the requested tenant s= ystems (including gateway) is not in local, and send back the requested  MAC in ARP reply. Thus, tenant= system will send an L2 frame with designation tenant system or gateway MAC= in dMAC to attached NVE, the NVE just performs the table lookup to obtain = the outer address. There is no IP routing table on NVEs because of the L2VN.  What is the problem here? Why nee= d to use RT5 to convey the GW IP/MAC info?  Please explain, I may miss= some part in nutshell.

 

When using a gateway t= o provide external network connection for an L3 VN, NVEs use their MAC addr= ess in ARP reply if VAP is L2 access interface. The L2 frame from a tenant = system will be terminated at NVEs regardless the destination tenant system is in the same VN or not. NVEs should have a= ll the IP routes in the VN. When NVE performs a lookup and is not able to f= ind the matching one, it means the packet for the external.  Since the= gateway advertises its IP host address to NVEs as the gateway for the L3VN, NVEs will forward the packets going t= o external to the gateway.  In this case, the NVE acts as the first-ho= p router, the gateway is the last-hop in the VN.  You are right, it is= necessary for a gateway to advertise its role besides its IP address.  If this is not there, should improve th= e protocol.

 

Regarding the IRB capa= bility, this is my view about IRB implementation in virtual overlay environ= ment.

 

 

Figure shows two L2VNs= , VNx and VNz.  NVE1 and NVE2 are member of both VNs. If NVE1 and NVE2= implement L3 distributed gateway functions and have the same MAC address f= or the L3dGW. When NVEs advertise both Tenant system IP and MAC addresses, each NVE have all the information about tenan= t systems in both VNs. NVEs still terminates the ARP requests and provide t= he MAC for the remote tenant system in the same VN. NVEs returns L3dGW addr= esses for the GW ARP request or if no matching MAC are founded.  Thus, only the L3dGW at ingress NVE = process inter-VN traffic forwarding, i.e. the traffic from VNx TS on NVE1 g= oes through the L3dGW on NVE1 to reach the VNy TS on NVE1 or VNy TS on NVE2= .  Will this make sense to you?

 

 

Thanks,

Lucy=

 

 

 

 

 

 

 

From: Henderic= kx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]
Sent: Monday, November 11, 2013 2:22 AM
To: Lucy yong; l2vpn@ietf.org
Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t

 

In-line=

&n= bsp;

From: Lucy yong <lucy.yong@huawei.com>
Date: Monday 11 November 2013 08:43
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com>, Lucy yong <lucy.yong@huawei.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t

&n= bsp;

Wim,

 

I read the draft and s= till think that all the use cases work well with RT2.  Here are my vie= ws how these use cases in section 5 can be implemented without RT5

 

Use case 1 can be done= by an L3 VN overlay, say VN10, and a gateway at DCGW1 and DCGW2. The gatew= ay is used to interconnect the VN 10 and WAN.

The VN10 route the tra= ffic on SN 1 and SN2, SN3, and IP2-IP5.  I call this implementation = =93L3VN plus a gateway=94 Why do you want to use an L2 VN overlay here?

&n= bsp;

WH> = you don=92t have a GW IP in the L3VPN AFI/SAFI, so you will need to define = a new route to do this efficiently

 

Use case 2 and use cas= e 4 are about multi-homing. In the case 2, TS and NVE are co-located; in th= e case 4, TS and NVE are physically separated.  First of all, IMO, whe= n TS and NVE co-locate on the same server, multi-homed TS is not necessary. The use case 4 is just the use case 1 wit= h multi-homing. Thus, it can be implemented by =93L3VN plus a gateway=94 w/= VRRP.  

&n= bsp;

WH> = there is no VRRP in these cases since the appliance is a bump in the wire f= or use case 4 so they don=92t even speak IP, so you have an undefined NH, w= hich is also not evadable in the L3VPn AFI/SAFI and there is no ESI NH possible

 

In your use case 3, EV= I10 should be replaced by an L3 overlay. The VRF on the NVE1 acts as the L3= distributed gateway for the EVN1 and EVN2.  The VRF on the NVE2 acts = as the L3 distributed gateway for the EVN2 and EVN3. The VRFs on DGW1 and DGW2 act as the gateway between the L3 over= lay and WAN. If NVE1 and NVE2 use RT2 advertises TS IP/MAC,  NVE1 will= know IP subnet/prefix associating to EVN1 and EVN2, and IP subnet/prefix a= ssociating to the L3 overlay. When NVE1 receives a packet from IP1 and the packet has the destination to SN1, the = packet dMAC address will be the MAC address for the distributed gateway tha= t is the same for all the NVEs. When NVE sees this address, it will perform= the VRF table lookup by using the destination IP addr on the packet, which results the IP addr is associated= to the EVN2, then NVE performs the table look-up in EVI-2 that has both IP= /MAC to outer (or VAP) address mapping, so it will replace the dMAC addr on= the packet with the real destination MAC addr and send to the VAP that SN1 associated to.  When NVE1 recei= ves a packet from IP1 and the packet has the destination in the WAN network= , the dMAC on the packet is also the MAC address for the distributed gatewa= y. So NVE will perform the VRF table look-up by using the destination IP on the packet, which results to the ou= ter IP address on one of DGWs, say DGW1. NVE1 adds the L3 VN ID and the out= er header on the packet prior sending it out. When DGW1 receives the packet= , it removes the tunnel header and uses the L3 VN ID on the packet to reach the vGW on DGW1. The vGW perform = the packet treatment before sending to the WAN.

&n= bsp;

WH> = it depends how you want to do this, you can either go route from ingress w/= o IP lookup on ingress or do a lookup on egress. Both options are possible = and required for some HW in the market. EVPN supports both already, what this draft is doing is how prefixes shoul= d be used in this environment

 

L2/L3 NVE service type= described in draft-yong-nv03-nve is for this use case. When L2/L3 NVE serv= ice type is used, NVE maintains both TS IP/MAC addresses but may advertise = both IP/MAC addresses or one of the address depending on the remote NVE service type. When L2 NVE service type= is used, NVE just maintains TS MAC addresses. Both cases can be implemente= d by EVPN solution.

&n= bsp;

WH>&= nbsp;draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 describes the IRB = case

 

There are places we ne= ed to use L2 VNs. For example, all TSes in a VN have the same IP address bu= t different MAC addresses;  there is broadcast/multicast traffic in a = VN; non-IP packet. However, we don=92t want to make a complex EVPN solution to solve the case that L3VN can easily add= ress.  

&n= bsp;

WH> = see draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 it describes i= t all. As I said not all use case can be done with L3VPN and this is requir= ed.

 

Regards,

Lucy

 

 

 

 

 

 

 

From: HenderickxHi Win,, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]
Sent: Friday, November 08, 2013 2:18 PM
To: Lucy yong; l2vpn@ietf.org<= br> Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t

 =

Lucy, d= id you read the draft and is explained in section 6.

Show an= example on how you do the scenario=92s with RT2 and you will see why this = is less efficient/scalable + does not support all scenario=92s in the d= raft like ESI NH.

 <= /span>

E-VPN d= istributes host routes using RT-2: (IP) + MAC and these can be an inter= face e.g. And prefixes can exists behind them.

 <= /span>

From: Lucy yong <lucy.yong@huawei.com>
Date: Friday 8 November 2013 22:10
To: "l2vpn@ietf.org"= <l2vpn@ietf.org>
Subject: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement

 <= /span>

Hi Authors,

 =

I am not convinced if RT= 5 is necessary for the use cases you specified in the draft (or presentati= on). IMO: RT2 is sufficient to support all the cases.

There is a draft-yong-nv= o3-nve, which covers all the L2 overlay cases, which can be implemented by = EVPN with RT2.

 =

One question, why EVPN s= ervice allow to VAP being an IP interface?

 =

Thanks,

Lucy

--_000_2691CE0099834E4A9C5044EEC662BB9D452ECD3Fdfweml509mbxchi_-- --_005_2691CE0099834E4A9C5044EEC662BB9D452ECD3Fdfweml509mbxchi_ Content-Type: application/octet-stream; name="oledata.mso" Content-Description: oledata.mso Content-Disposition: inline; filename="oledata.mso"; size=29348; creation-date="Tue, 12 Nov 2013 03:11:22 GMT"; modification-date="Tue, 12 Nov 2013 03:11:22 GMT" Content-ID: Content-Transfer-Encoding: base64 AHgAAHic7NRlbB3BmiZgM5zYjpntmJnpmDGGGGOMmSGGGI/ZMcUcMzMzMzMzMzMzs+fcuzPSaFba mdHun5XmLT2q6q7uLrW+Uk1OoG1mVeFvQfyHCEJAQ7x/IELA/bt7kP/qn0GFAM9/fPxj+G/9P/Lx P/n/Km9g/6gfNLh2MGCwYP+oOTwYAhgiGADsExgSGDIYCtjn/7UFINDA0MEwwDDBsMCwwXDAcMHw wPDBCMAIwYjAiMG+gJGAkYKRgZGDUYBRglGBUYPRgNGC0YHRgzGAMYIxgTGDsYCxgrGBsYNxgHGC cYEBwbjBeMB4/3WP/k/+9yhB2IAbCFwLcQhrcG8P4fofj4L/Y7DBO+bfvgX5nzxbqZcn+W1jHPLf nxd64ApygBsnuGIs/xwB/1nX/2pwIaAg//3//FfegQKDtPtvLPKf5L+7/v/r/F+tHwAB4ZJ6muio QuDecvEHk1FzFYDJ3JfHXfu9VMrOWcZn87zWHwo2BNOZBjOQrCvvdNsaEgqG/hxTjoR67eX3xdqJ jvua+7j7B+/Dqc28mSlbTGnSBv/Ew5MA+44RBf1THUeJt1cUBwS0bWAvrP6b+ZdloUedXgiIZ6H2 DdKoQa9zifeyD7VmcbsH6vMsw0f6/UUa2++b2Z1iPhHbggAoTD+aoHcpSAhEgBLm5++RWSSSIj6+ 6LBYAAtMDpqfipNZmZJd3tukAAlMWZpERX7RLl9fLFgCgBMmIQ23om2WS6gvQR8GJj+Ni+Jl1qYk qbcoqj8qwACTjOarIr84aYAooT8M4BumUscBFwTJH1Fs/1Wh6wev4loIpsIIajpsAASqxRnK5cuC 0qUXJuzm+sf1a4Vb5NP0yUFTWKnFrcKLig+A4VToo36/UlgRjyskwGcZ5W1AkMMbrhNR/0WP9yDD P7BY1It4wuvey/hD3RKKAXIeQnJ2+n2jGWAIwbtcgf9oKfuxdGOU3fnwYUQAzelJ32npzXZ8vpJF dqWHddTB+q638DLR/K6w8VH2kST6YoT/8eAffuUuCL5Mn1bp66QQU/2j5yCA4X287MODHYcep95h CiIE7RwwkShoRRY0hWeUlAXSRlTUYBhBUvFKrn8YTb+WfdwXLxApXWyRW7uDRGO/j21x+fXHavuN ZT6Kv+NDaJQXBNmnB4rqOw5/J8wPfaClGgVg5PTk5GQO+UiUi26VtA77NBXM1nF/OVZlw3LLO3NR yDWcvALs+cBwyS8aWBS476WHEfeOmpDJzhdfJ+h4flHtGKRX1ecHDqy4E947JNijPSTHZI+IV333 LVAKjxjmrX+5NWPIt6E0gtP1cIRkF5MsWxoCkpMCqLBH233bSZTrrN5VY6YnqnNzInEaQqvGKwht 4eEdsUCxiPXLgmg5wMPfSv2fpz09qfAw30tF98RQGgeXKNmUINDcBa0fTpVPF5LNiRUEFSoT8h+M 5Y3oaeRs0RIvub12sZSS1uWdc/mK8GmVZaeymTdM6KgqXKdm32cMNdU0QpYkeSYUytboraQnvqLf /C20UueYjB53dnvti0Om4s3BhhjRf45qEfTIVVPTbqZ3OBkOCaIas2JJtb3eq7RQXlakW2W/jWzl OsW3tsP1tfvK21RkgIkusvbDrDBCFlNPgjvt/dg3SirUy45VDAr5EakuL/y9xGZABOjc4Hi9ufdU 97rS5nWSIEghqsqyey5JuPZH4x4+WPQqkfogIe76d+IDy3r+Rc4TKgoOI6gWh63+p+gYl5c1svmo aftQajxNVG9xPUfqUMpI7Xc/nmfeP0aVnMgvYezdZ4iYkpbeJAkaukN+ux5Dn1/3YC0d0ewZpked fDn9qS6e+UCagtO0OxYD1Egz6V40NkeHL0URUVG6rfpSELVC0b8O2VFZMyg5sPIQ+2v4kglCyC4G 6kFJB1Xb9krnjhG/x1zH5XZ6gf3JafqqPtTVUAyJPAmSyQO9bTv9YwNh+Hyfboe7WdjIr1OZL09K 4l0GjQfl0DAhvN7zwxdE8M8q+Mmyb4d80BxzoW8WHGhRkiP+tiBffJGosqu6t5eQc+swbfFKhkM2 wa/9ONF5+9DGmiE/tjEOrorQygk3Zna5dBx5knt7Wlpuym2ZdMfcwPeMm7z7pI8zxUD+c8O5pabq s3wHNZRAMVnkufXRGLljTgjUZTBd69NXt1p2DqUgMfjdexCFfP5xiL3TZ4tL94KHzayWBRXLn5bp TpAr1tZRBV9E6p3fUZbr2CaLKKTnXDqtTgw+uTmARMTe8KBrFlHuBIlPPOeG78Yfl/q/tyRnBSUa m5Ig/WJLo7A7X8+mwlSgBThJr47cvqblyszwTKreAwsTDG3wgYhiJEXDKbtrIafSJYeY2wNN3CET gS4F/EXkbz4+L8TRgWUPTWNe7n0Fmc/tItAzZAyGM4l0wXdaLf3sm29a7wkYuZY5p5aPel2kTRtN R4nywOIYVO+OYRaG0mZS1OMqlujHiAaKDrPFDAfLnk4N6GFJD2rkr2zI8bsOvzziOWMjDAgImYvp Fk7KPqOHDnN81zl54OJ6xkb6stfnWI/UVvwA154dyKjRw3/6sB2dz0Z5cjq9mt6nQkQIy9H+13VD K3fWHpI45EuZo9Onv/nVZRdsyAiWKJoI3jbLLLcAEysuNOXB6G+m/ohROKtAOdVdQkqfuMrrQcGx A7WvQHbtFQ+vlKhsJi+JkJNyqk5ZSM0rZSukESAybihxwm86bPG7npgmKY3gN8iivaR6OzkL8SeM xrVJS//ZuRec6kee4GDUQMuB4PKLO/UjJSHPHWL3tXPnNG4jrKpvhMw8sGNT+VJvl2Rj5GedU9dj Tt4SeezybHanznP9ySgt9xTNfr6Vfk+a6BQpzKnqSh3Pwnsy3oY/kXr6c20Z9mgbPWPMewBTm7iR OzVrJCIbyTUt4SkGDfE2PUroQDq7F7iddF3tZWAyrn+Q9UdQhaqS+EkuoNqcqUyTbkrlepZHutpQ qP2M6Sc+QDrMgsqPrZUFUbvrlrdybYws6CzRpW+8EZKETKb9gtUK6PxTqrjPAG0kyi1Fg5P8qfcd /ruLRa+o89LgY9JHlUy3KoH6RDxvdeHrjEZnUv0W5XqolKX3ItWVdgiXiMuTBeLZuGseI+Qzcfs3 6jpFLfqx6/YsBV1InoVGHJ0xX53gBSu8uGKZ8UDNtiYdusGtGpEoMTQrlrrSEBrdEzqpxawI9Pul 11mTt7nZTzJTfSvjUK+gc4qeVJM+8hcFPjoidozxwHu5byVbphtSy3J8DkrQHs27I8q31Arxmva/ c91sTqkOmmBp7esb6cabhCNUm5zHI5xxDOSKUB14qDaeh+IKciNuaX4ED0c8vtydgabYBHM1L8Ul EDZR93+Ph+y+CmN6yddlDkeVStj0x6eQKHzbn/CLddyVYYA67SYfQU3rm+AgCkDTeWQwV/2EbsDs xuM2wGpK8KWw9QaHiHDyaTunhXX+Zj08/MoE+nNHOMzOy7tR+I95FPlWlQqUSe6IjY6Bq4Bvn4yN exeipvRHUzw4Gkm2Y+bkJ5NPajJdla4qdc179qFNMcJsWG4pDodP9wsLoqa9NIzyaxkHXCi8dC17 lRhnqrm8csfsthzD1RRMPX9VOaAHn9Q4ILco9e3/gFIwxz40k6drn/+0K1k7arS6PrhZO/Kax/Ng e5rkU+i7Hno1cDKyMWZ+sL2NaH9Ve/e4N579dU7v7Vdv3jTZTBEI2tOlC8dE0f4UC9j5PKPu/6ZJ fe9R+WYeFc7k6mwzOz8UJDv+ahBI3XSZuyHANS9wLYkoenhe75fqSQpp1yRNgJttOKfzNgTKWNJ6 YD7NtHowfgr6uy2kCSe/X7d+YSpz75XHZv/3B2nt2BqsMfc65exVI4cfvh+XtCfpNKMj4/UTSZyU b5dGctmraPt2zIm0YHgRoFn0XYsX7wzBiDHjvQ+oh+93XRJXTc/BWjjadL/Ifk6MgetQQ++qItE2 ucBlJzuHl+1sZ2SVVQVZ0XgxREckV8s/ig4iKEo2cFG/8UjUjINVpOznMYiWF1BdAkYsapaB7u5e s6lYy64OQww9hYW7kjjCRZdGDydxMrl1QcmvK+m3j/g86txf8RbchKyGxHtV1k0MaAizX257ZyBF mXHNzFohBMo7xOcfFJe3L4fyGhKpRfhjH0yyXdFLZDKcqY924QxeVfXbj11c3wCyRP0ZxfmMg/te A5SIgGODr45Mp/C3o4HLK31xyzPi2exI2FGL2Db+hJPErCir2i69jHFx4sDpaF7ScnHxTJkiVVjm 3pKWEKvlMnV0vUE1ZPYq4qbQNP4ggLbBClmBtALDq3lMc+0pTNyEeuwbzdvpWfB1ignkqOyYDqz8 1sgAZ4yrozd6R7k04lgUpbuZZa3/DL952sQGevwTc6zuKjPdtWkOVdHcCzb20OmQn8x9+CzRVTRM buvorrwKC9+T2nPUwoIZDLZPHlYTCnBOdLVOI5QceZQj30JLooyhP7CdtWGHPbTsQSmsKuNpYGK9 3Ficx02o6RY5pyGEXV/3Dk81fJmQUB46OGJ9MKi5lYDWA0Vz8IdXg6GFsiFuW6foA0VrmecVDGpC wesfdoA9PbZRKucffZO373/P1nguhs6FTCSm1O7CpMSm3L/pr2VdOfD5CGLiVRAVvmJfkjRhyp9R iz+t6Gxh3zjWBoV/dd8RPNPro8zLsmeE/QQxmfu2Q/RxYXcFqnSsfzMa+qDnegnAZ/qOVi2fzfNF QgHH0skG36risGl5lNqitsOHDM9bkdYhGbY6Zlik9tNJ1k8BxvioXYfxqPh+A0yHjC3Rm2352505 zhDN4A3kUXTx/Wz6PA2pioUtqYDAvL3InvaX21zZVPxPpg3n5BMa8q/GMRYo8bhMLvRvsY3VLDPy 6/MNDlQMwF7dbs0c0uZrtS1skVFU4E/ZagAFZ15Q4UCnVYzyEhRH6aVPK+NyXMwjwKxlAXGx1MwK f6yCKqlVdK5DFkOvmLU86Va597ccoISXbqpjZJ1O4cnnrcWawapiMWL5pv7wVq0GJwtf5wqNgKig V0Bz7Xry+lbbti0Fx7rut2yyopzR7ziZS4+/MamWYTE2tSUoenuUv/aMdtxFcLEr8EjcDxjP3u2N vJNzgH1utFDkzKJ0CfDetNU41jzrm0sAg5jOwpau0i3pu2ha6pUKOFh1rs/mAuX42Lpa7qPOM56v TM2OhHwW8NZrOqSHejMbvO2/tXkw0MiTHzwNe3wroz23Bj3xO4TKzoX3QvI/XSfzspCt+uQI14Uf y75/A0FjWbV5IwjrG7H4aABUjtL+7nJr35hsJbZ5May/JWkaGhUmmcPoLXloF2SlSb0Icnpt7Z3f mTiGh4p+UURpG50bn7OY4K0PnaqZYjsobRACufLZPAw8E2MP78JkpMl/H3/EvyezcVvkQ0MQMtj+ 5l4/hbuu3dv3Lixbd3v2q4TsqUozMftsbkD3yXcUOfUPOx2biABQ7V7SmmhXgFu5YIqcYUihhV3l Ym3/68wb4VatzEMWBsZHmYE/8ZkkabpN5AtuMLOdigqka7xCF+Fy1kthY3B4VN423o/mDeU9mwpg Wa3b51Jo5PaGfv7DE6sf/TfoFEqq/JBDM1d6SkUxaHRC5Cm3wn6evXzcs8tpN9JtiD/i5lf2FTO9 ntTlMg/R3AN0ZMkvPW2b18ff+GwKmiGsKgr2Yt5ZQYzSby492jZfoq3z04IObCePqCfL8n6TIfTT fGRPb5Q5mFhmdzmeFn3NWyQuNl6sTIJCUFINdLSct2d0RMJa6I8UZz+UrfUPvhKE0hsK9nRgd5MU Gu82YbxBS2n0Pu6UeyA+hacxXDnAFUvLhpUfxF8oVgyDhbPuwOmmjken0JCaYxjpz0lZ5sbfZZ4N dW63MSTD9vGsq1+QTLddl6rK50pQodJHTOjg+k1vcLhk4ft0k9m8tAi0y4A5OOV1GgGRSG20EeFx 6yfzm37ktltDTqh9RGdGKe8Gu2uNOcCd6ZYu/HmD6UQi0G58dcnVfvmJnVWdEjdMvrG1Fg98fPhK KFR+KkhHH+lecva9JqFHgvexK2ZnjoR+7b2SvsTBiiLlqLUu716MjrooAg6+QMdvbqUEAWMs4rXM AsWvydB/14Ieq8dNlevaHh5VRmCw5hS0k/fgRLckEJc866NQYn6uPNre1x37J/skqY3Psp6805Ol NNYZollb12P6r0JTj2wbvgW5wJEQ3AfUsPT5X+t+5DR6AfnI9cF6CxLYgsquKmzJhRAYTfepthTm BC/lux5CS3relkicD83YuD7GgkNtASOo64sLaFFz92la3PmhZZfWfjJkO5oM58iQU8vCJco3VJA5 6KN98DpP8lEHmv8khbdtmo/I6A8OmWgPL+bhKoYGVhApZ7sArPxfyYZucbgAG4ZyEnGI4Hi6ecd3 jLWnpwmKcfTLUAXN6YrdC5zSzd7xoQutFif04/Cagyi1qjYV3APHMOZyEJOu9oghZ1s7rvaSlwW8 h9aBbjkjh+kf5mOzaZuq0mpsuOfbuPuBn46115zt82bNurmZ5xP6oCn3iB4m0WASucOI6pK0nauh tXZ+6OENJ797JwWM9oKfIa7wvVsWbrS+rdRcYSBizlyDEu0zuiaI9gEP55Jc1HfFELG4M4m0bzan vpKcU/dnMk8KHb/pKD9HUvfmreWZ07XcUimRrDOOV1adaSpejPkfLIY7yJYU/e2q/ll7vyJeeeEk 8bIIw+M5qikfZqN9Ofxj9Ij4ceFbN1RAdkMOErvZ88nkjCBnwEmetoqDJwY0Ad6CNSDJh6vDX9Ea URKEw1JU6qR/MThLolcG6P6V0eThui4yK7xOFJzn9EGg1iWXXbMrmR6xXp5Y9e32bk18OEDZKe5b mARRwH45Zf+AUry8wj4ymsjxfCz5kVgO9IaRX+sZw4tpW9q1TMvJYt0QmVvFnlvGPZy8vb9LGRZc qZWQue/edVXxlePf6oC9jJm8bwHW3kcSVEZ8H9U37k+3xM1Y9BCXjc8KyAGBZQXUqMYf7n+i4s4O u7MvdFeHtP6MXhDTe5nkp7OPKlm1sCovfv+qxMDfcvdsKUN1BeGgcXviM76pXd4LRfph41GjLq/7 wMGV4p7jsWD0wneR2Sqon7C5J0Y2pcadeB3oCgqlwdRtBwnar8DnfyVjsPmk+Vsg3RelRLyr7BL6 ZygPNxsVTDuBb+k50nkkKORH64pQ+Hdtj8Gdne4RW9ckfI1yyF9EGmHmYwwdAqU+LWTzui+PHD0R P4B6PWhS6YQ7vxM1Mrl7xNLle81v/JqAaBwkB93oq4h55IAkoUjE9nQnPa44TSfBEOCCstShNsgO TRXzc+s1v8PdnZa6KLHc03hsrgQZKotvXZnaTwvqVT+oJmMmOZArHKCJM1yETq8Yg0W7Nv5LqRMy M/M3DG1ffv7IAnMB+EFk1rCakyi0xzIi+4ugrViPw+5WR3NaB4Y4BDeZd32WP9cvDyr35/qPSwiR 2FWc9qS424B0yfdW3nZ19ls9UBGg/YhvJI+AsvDah6h3yBiWvI15gqm8Cz6K/ASeOorcNqOdMvTR suPganLNcpyxHvXx6XhWvHIg283UODjdszxo13RGyawzFfGDdpLa+ArBOD3KsnR+GZ/2btPKTRca 6mEIi9RX9wJGXG2jrlbaFBYIu1EWHponOlYUz2zN9ULrm5LMlxk08xeKqQz1w6aoqVWq96VqNnC9 7KQhUK6hixQPsYgU4yrJXV/6xjgsp2V2tergxLOVjQ1ZZmQ/bXpl4XNUgQabM7DAnE2U4CVa3i5N Uiw7aV/w6jdT5qZ/C73ll5qgGnyKbasbQwcdi4k6VYDB76PAR7/bxhsSv1uiVOPw0nn6u9PeCMOL t1C+mK/pc6uiwfpdZkoRCmu8b+V+FHge/QGrIqSQgTpsZE1GRs7UKcAffIJpTaQEzVEl8Y5sPA/b 5J+3Hx54rYHAP5QoXUlNztTSlDl6Ez8HeG1etJCXZRD44BMStHF9D6y3nFOA7rb6wsLCAB1yXM32 8y+2LYL2bHt61GKBp5GktpXZv3Cionm72g+Xgy8QzE9uN4jwsrNbP3k2H4KCXku558tZ8mvmpqjs DjbwQbarzu4ucB6kbUGo5tfXI8KpJlAX8bHQ8faZcWUN2dlRbEQ/3G0HpigXSnpierQuWFsYt6Kb Z4Y6qYpa2qO0RkaKug0G9/0f9hwFkGvZe3FWkcZ80tIVEEH9pPHz7uUdUvUXarZJHQSWG24KH6AQ 982f9Jeyhe9ZD/FZtMUj6Icl3E5TEnREOr4nn0j2WboQBofQiXoIfyGAWCkqGQeXmBOFWB3errcS 62ezXc/7GB5l6L6+OY3wfb0+fFEJ5X3vI/2+fFp9cWha2C17PE1TMIJo55agifOcBjDRMj5Dl7VF 2mcbaIItwWad8pUlcmNmykZaCTrsQIm21w715o48YiFXCAK197E4iOMknNfDyBlWXsR2UE6WV+vx pglSSGMmLP+NMc9MX560XR1ZUOKSnTKlJTJ2KLxh+jE3bO5QtcaY4Q04IqPvj6qPbjaEGf6e5iBI TGxylpOj9DBOsMEWpTC9qHsj6khEqaopGXF3JyCPl9+2XIVOvvwj3LuGkXg4E4nS55N5sBI+4Eab aPhepn/ivMBQmpzKVq+suIy/LtWbnPnsaJgV/tdEOn+EXXUmnXJZQKJFJpfP0WOKBKHNWtE2/6lp ABCJYMit0qlqcZiVOXJ+/NkbXyyzgS9C2tppflba9T4JgnABhVmbIN4wbVfVhDDBfklp6YVRv3WT LtJWRLKgx8xgSrBXystIzIi5+Ymj62VgIFNq4os5VUTrrD7QTvK8LDE4zPwXk4jh+jQPUYU5CYEI 8vqacgzcQhXGvdPxM0n4TB2vCNtAoPQfqJXJCNr3gQRR3XKOKCp1QeidGgOuVeCnZ5JzzHtcPziX mc3st8JQoYwSYkNGbvqwX8hsbo079NagHxuP0dQCmlapp5CpdjbFi0LIOkkBcKL5aUN3tgO52UzO eUlM/N5qS5yO6g+O2/4dz9PlX1kONoWF+ZaIi6b1R/LKu/R3xKEmPpM/ti5ZDzThXTzNlIB2Qt9x JPCmFxSOr9vJU4u9Vo270ULCy+NMckIY3VJtzaELJ607r/xYKb4XqY9TT9ou20xfPBlb9tCHKEEr dHdBiV1BM4sBDo6vJ8nCTC4XUoXrstg+YZndY64phLCjaq2NFCuIaZe8LShrOq50RYz8FfhJsPcw mFvlv4KoMYsAvDnllZlresBO2emxCqdMpsuELThb3kx6k4ybxJZKo13pe2E1sPmC3RSTpqR7Rqtz NLRr7/OL5/u0okY1DC5XUFzbmawR0I12QRlrDL23owFpdU8aGudPt40ZcLXOV7ZjmFHawViplB7G I5eJyGGz6JOLT2Q5wNoqnzVMwc7a5YmXrSIa2+Ptaq9llQCtTt+4uubqt3nQEUz97zgLaI5JrjvQ D4sU0ykO92zAIxSVwbKYgqoNdyz8t0Yzlyujhimn97Ee+rs3+46bpB6BdAj1mUmyaAwm37MqGEGa 66zM75FN1uSXw419FFCCiK2h5A/f8Ne4Js+octeh3QYAWCtE1IgVJs9dbuSbN5BZysa/KPNxLabD 9iANhUDRIvtFyzczRJXbFeO/UM9MbY5Ef9GfEG1sbz/u5eL+FUQWgso6Me/mnt5twkQdygGZakvb tv6OSyPb0K95LmBd7k0aOWNwv+yMVHfcwwXZOVD+HZinuZwuHijHSDye8LbdZszjmvPaRmo6aIXg xWJPpC+VdsFXPnRZvpx2bU2MUQuJk3a2q0LL9yQzZXLSIyuH0162VDm6U153uQhAw7mK1ECX4x+m mvc6KjjibrTLFdcEDvMvKE/P14p3UWR07v6kxNN35YyrirqRbkDjFqnYU/tjdjyq1Fgu4/na95h0 zmcBCa+etOYfG3UuMjMGDzIS/disxub/Bow/uI1WQPAlfdYV8Jwxnd83ImIRlBcostYp+YKgfwQZ NjIL6nkmcf0ku+iR//MWcVtEdQz5B80PiwEon6nLxP5Y57jPCZZkw1fmf+9Nzm+2tZuFdHdctFSb ktxgEX/Wf0Gr6V06VHopVAnYTmNsbKpp9WGjHeOV4jVrZb3JZE3TXnnMvi/eWu1swD++CM0qZcvg kymXKLp1S6Vyr7DIvKzuq1Ln2n/l01Czhk8D9NJJhQzoiepZ8GH104n/5AvvW8+hSV8txZv5yo7Q OlEth8jjKvj4yl3wKJodbFq48jRwEhYb41oLTL+UBmUW2IlLJCAbavY4WY6LqgOLInJaMcPMonWF cR8djotsTb544VE38hndvgC+EaZ7rO3tVTLteTo13ytKkNC4CQt5h9mk3bKYXldrlZBa4SEnzqEo Ir/z/xXOKZO66od+s9pUpytKfQvZETDyi+veO/2MzWyzmRVRlJx2Tz0CHCYU1hn9nI54PIxLb4P9 6qNTzKcdxx5sn55MQHS/5I6Izi4r/R6Jf+/jG62ZHuovAz/zvOjtkXeZ/xI83S7RyKV1krqXx74E h8ul8OqM4SkvK3duVnsle2YND+8/IJsQh8I5XW+gPAcXeBFHNK1a8S1ClfbaKI5AsMhiqyv6SC0b gv58CiYRoEdf8SRFyRbSyo5F+eCcyjnoCTRN/fUZJYiOmhJDp9vZ0710OHG8tLULJpjsnCMZlSq8 XHmlD+YsNa9RplOGU1DWhpWrld1z3z+rwQlmNc2ZL++qLiOO5mKN8PrARDYiXg5Efl98zZKTUXjJ gl2AwGi/gPAhv3j/urKutQd3Kn5UvNIGb65FSaFcSW5GuRxBJ5Qna1YpE6LSYQMf2wpZWu9NdLVN byqXta2JXw2bzjORQDLugZScnPDaQiQcuqIxRfG5QcdcOvJLwDoCtKWJsU8KnavjmQLKbe8bHzKt 9wondJuJrgPrnHyikSLjXPazTQI3LPcBXJUdSs381qM/5KKimY2zJfKbgf98W9BIdECtVfntAwUz OoH8BIwj2hVbHLz2BqezTE2eSmh/KiHpHwdO/wRs/pCr9hri3SV6Q4XmihkFiXyHkbMNGUfUPI++ DWajO8PIwkwkTD9xPO+dadNLPdrd9upnNGcEOwoD/h+GuWtEpbFmOrFctuRIgGSsbjZ7Q8ZlTCtS Tn6bCktZpdMZtz2ifwEFIPrfHPzxZfayoeuXcF1ZATG8DFk51Rls3NDGqey0aDvvfU5yalDWiLAc zG5arEs2nU74JTF/TJ5aEj34JSuXvD4PSTR34HJo1hL2S/LNsCogOthTLUeWRoomhmWFgM2gYPS1 spfZUp+SE2ZfE+kGm31YFgtotWQ6mQHjeeKioiKpAz9LueAHuZxjdK/IIop9HVZiW3pDpRr5N0Gy TvO1o5ilAon1VxbLGMRqMGwLharnOC4/R+c37zIXG19SCYdJb39jIIaeP32wvzfTEIKu6jHGQXLu NYuZyD8nIR+U/R1ffqnVOR3rWWQHERZVYpVPhDth7xvWjcsx3FyvVi4CJ1gedpqVv/1nNL4x6Ae+ rvaR998fKGVszGKZrE4+eg0sw1M8I6VZTn+kNOfWUh11ID6aumlFqD5rQhRHUpKOPH8gac8huYBR U69SGSsE/gSVUBIHw0ivMgXxEri7CXBEq3/Oo9meGXC0ve1+QsZinXfdBcvaS9CTfHCAppO3H4yb OHokVjXMuffhWWOu4owVwXaqhxtNeC1D+1vie1WOjgvJHKey4e2FYA9t8qvIGyGWETqlYxn0gd0r dW3dd7nNEYDsvd+KnxU/vUcaSnQkl7NU9RoQTn/usMsscTENqPsPRr4qKA6g6xIfHAIEn8EGCRLc BgaXgeBOSIAEQggEBncnuFsIAQZNcHeH4EkYnMEhSHCXwbP837cPu1X7sC/3oe/t26dP3a66XXW6 W8girUltAFJ90ICQ6OxBBYYvASBVuAAAaNoNwXfRS6xHMitM4J7NdM/NSDX3yDkvJsdy2xa1Er6p NJwUqfDFxVELRt1/+B3/skmad/UJm+miVTDSWLKAnGCs9hJDdJeYdb77/FIsdog9KPxFhQPGN2kO eT1isBF8khex40bIIgUv2Il+1lK5u8s6G/WaRBfmO9bTr6tdtTM/fVL6nf9nribZ9I+VyVA9QLId 6QwVz4jg2vcq6iZfAtUU0jy2g5OyaWHWL08XFzD2hqHOYMwuQjXLwd6tIM9Cf4bcyyvuRO81hLmw XJjp3YfYqSNcl8/S9iV0f2Ku94PUW9DyMwBppYOeLy/fv5dDM2bTxFm7p7bSZf4s2Bx5FtNXERTF s3SB/ER4kqT1WFs2z2+HVSHGGzK7jOTsDv6cyIu1ZaosFEdz3VBa7LyIZHNT1Btfxo4MluKrOMHe vGx3aaJzDqZnWz8rFsL3SdGEX9m35Np4+UChl5bsL//4uFVsrQ5g+LowNJqO18gg0ijLy7IlvyND cTqQSBtmEImW5frwuwxg0erXvUWXoNPJVmCINdDdI7IaBy2W3P/ku0bpW72D5D2h5uw8giciE0lv oZKg5BpcM2hcC/KVyIOICw+rWtMN49TB6nsp7BFvDVbsWMk6Eex3mjJSzEKVVa761KG7obHyuzKQ 5OUaEnCBa0AiL6LH82fopXCEdbGfyvCexwaVzOD+JWkUyeaaPeH1XAYBnVn5ub5CbfTChqT+025j lnWBYg6APckXdRjWIvuWDf4MVVbfyXhsn8M7hdSgvtYqM0bjBqyhF0CVaUMJ2dAVWtiMCt/0Ypqy ETDhk36R/54lVakR3vFfCa9MjqFmjnSuiSgg9ziqns1/HkUVteW3lfJt1yFRgofY2srxVcS54V4A dWsy47tsbHAPiH1h1pTPG6a8V+QMyzbrqyfw4srgRVl6DOS78PCljDJk6fO2rdrQU0ppbWH8QhZE e/8OVeU/gxXPo7ky6B3/bJXgsU6DNPq+T2nhlGQsto7oL6Q/iLAmgRSRwqjvR8BZt3jqTUlNJMmo tQ7O1wTpqNXvuFtE5SRgUAeYV8kxG8mQkR7f9e5UcDFaRUhCKMLaHcyTor+PeDLPHHmyxT6qW7XQ TYZ8QaRtoNpK4Xi+1LamiZusz9ybMyOGMAxvijNzcHj5ox7EHtYa8mTPYch/3H+EmPznsdgHpwE3 s+4J3duKsL+r+MzJy2zNfCVGyAl5IRFIAd+duCp1Ik4spk7gdgpEL1cErf2h7nlpVZRnY+d60u/Q UVHJicp7s4nxezH7Mrz5skt6P7dxqS9iKeswBxJNmLuhmXG2angizvv4ZLaprvHO6Q2qsjCFt9xP KOEpoVlwwi9uyAhcgT0guy2BMqRx/HujGz8VwUPeJYnXChsWeUkmUnXeoOy2yOl9yK4SrcfGvB2Z DkvoKMNAbl38/Cs8v/TPfrFyTJZoCOnC22UfxuqR/ScdI1oUg/uJuRRuhQ7yBzTpBqFn62qJ4b27 DtXNIWiRuBX2jVR35AQLFcNBNmltRBeAsdGsHj414Tz6dGZyVRfRyFY0eyHqJzNo17xDNGiQVB6v 1wTcfOZn4entwVRwQKSQCZno3MbiCz+gWmSHnqigUNANDlkif9ydAV+M5M2v7XDO0VG7krnJ5gC2 hP6Tq8/4vmP2Qq/UVwCwLIJJ0um1a1e+Fn5QD24Xc5XplmW3HslAL3Rr6z3vX0uVYTxPDhspsWB0 MDjyRBHEHvXalyRd6vrrDzUPMXIeCOAMr3RP2vDuuH8vtV4/PGHXn61/YMvHTmoLt144S3IFcEXU kEB1Pmt1dKCBMX2LhxKo3v8MGer4OOxE4LiVdspdSWb0haEySSs5V5Pjd4Fwq81sLsfO6nffTNKU xQNzMNjqdtLEoYFPdyPUHkxx5dM0nPQbgVJhaZhxdul+aus430TxN+2Qex7HnpBZMVspkP7i0/lH z3f0jPoHGFkdhMoRFfvbzsbfpiWJEpsFcurh7sKQCIJq23NiGnBZXfKzX5QmpDAsqSdqOkCsNT/K 3/J2MLapk+4RV/CXfM6xsA6SmS+jpJfFZolU6mrmanEKz3QCL6BFAo1Hia/eUNozHOuqkkjZsUA8 cdV0/OP6/4xd+86PJ1nOa5ifYAvAT7jfAg0JFgMUJ3w+VfcOH+OzJL/yrlJ7Rvo3LjLptqfQiLcn Y0+ix+7I7bUU7pnK/tL4cWXR+ZejJkSquIXDF71DXQ8DXHeRKjYjYPkoxtmHsWnQV2TZxOqaiPwK nlj+PBz4lHKxSlXIu1ND3MXPz0PFyUSW3UrfB/xNcQ3NmPrwk++IdGrFWxvYgFp0yS2HbXXSHZ6s SliIZ6vL73An7u2Ng6k5KzrX33OZB9jr9fbbl8uzhl8UQHMp8nzblhQUIm+CgJKBjgTufYlLP44+ M1Zrtj7dG0Zvv6wIzVHJ7wT9YTaQOx9TmcfObXNQu7E/hREiqQh+PIgcSr7GnajDwntCgaHsT39O PljGvJP7s4OkTKe0MP8hvlIMt/7YtZ0kzZiVoCG8nSSjsZTMCVNqiyIrutunHEPtMhKDota7HcAc 1ynjRPI64XIscskiF8P+oJgKNz8y2p7MLqRSnswl6A961hD0K1hHmyKsE3D63ZcCGkVhzkeptlqA zYEFufKNNL95he2A48/2osehEKRVcLsN/WQyOIExES65LU/K65dMmzmxFffDP946qW9Wgj7+075J NnAIhBDHvS4//xoDw5++maQQZX+FtWQhyhQ8xDwwQUmBf4OnOeQvPP87ZXShBPz9iHy30msZ8IGi MHTPC+NAmia+ttBrZ/57mVGToo9H5hYKDRWtakdBPyqi3goQLqUHF0tJNo6j+Z6W16MU1aaG2Esq /D3wCMHeVX8wjExzxJJ51tA/TCp7MhjKZgTbAojhdBLM8dBxjmI6VIJt54Cv5kCD/a+kgz2ppPng w39O999WrTUNel2AIaK7M8ws19yzBZQxq3vCf6RuD7O5QgV3GTWeuBZyUrI0a3MKNfmhXXxCXCFP ZC+gPgpdfh42a7QPIK9EBHC6txvfxi28iaa9qCIkjS3h3YV/h5OVUvK4N8NY1y85Nr59e1nTF1A8 z3uFh69Vz6hrrK6odEyxbzG6ROk/vHhefwgU+iC9Nlflt/9jdPTn4PNXbBXMyGgMBBeysj8xFtks X+sTvqmTGrMiiy3W8h5CMlVzMksVhoNljUlA5yYG54xakNJpJGoajqglnuVIbEmxDwT30EC4bpQ1 Xt6qUC3Vbedd62oaLBiwG4W9KO2mZuAWypuepw1CSOvFgoduGKpnXkDjCrnx5sLABeIpdi/AMesn 2JtvGa+Dn+tAsGDqG2vj4KGXcoUQeFQptQzoNDR7DrtZr7kLWq18/135h9o0KDeFIW6RpJCvJYAh 8q2vyOd8nG+3F9js6+1a0OT++2TMt/Wu3/Cl3AJGWeiyMEm7P0kWu2L4Cps4kGuqlgDyZ5FXOJVr e8AbkDqtrx+mAOLn4HK4r1bF1zyekObfGJFHYvtyDofTaEyv/K10Ypg0NURnpd8ZDC5YuVDUJuFH wbiUq/KliS/WPqPllKkHm8NZrFL3Ykn7Ms5t8kf27/YwyyahHW/W7CYYyIf3Y3eCIUHxTMymIS3f hbLZenpxRpAoN/VU+IQks76MSU7UdswKcuo1AXLxd9yfG4fwqB1XErIJHmdi4VQHi5aMr7wyqCsc 8x3Hbi037SztytXovX1ew6PP6Opuiou6jkShjTO8gjHdsWANW9XGJJzlwW6HXeqNaiPmWQjiqd7n hFSznifdwVcpriQAac0m1aTYeOuTHe6fniYrzLSAayKYzUoBl+6nB5FOa/J2TkDAMMywRA3enUSy 1kCepNHp6UXQDj1gaJEO2FUtJfSZ2qVaPR7iLgHO1WwnMcxekCZPCN492Z+pIAGnrCwkyhl1ban8 bER2yoAjJekFjfq0/Z9yHwNzxiGnpYNfp2Q6RFVlYlanYVzuoKlARb22v9jd29AZsdNv1Kq91zBq eeollihilxzxfaWuQK4QzKeTOeEJoPaIL812JsW3Ma4xKl6Jh0BW05DpgXCtXbVYqp2LUnrYZ8vl r/V4PKig2mtYjwHQ4VvsyyfnQYVS6ECd9QJ7GULyuJij5UWNnvbgEkhIANa3LKYQ6/MsQ3CMFSkb lVUTXhIOYnzI+DCrRqzRS98UbWYs94kYLN8wV1NWaxyRa0LymySQvtC5wXOAlKI9B9fORuqfw36x 4Or74O6MAj0r7fY+UYqWTe8p85TNdZlV2Kcl7w+wkCp5VlNuFNyyr+ce22DtKZGKJdbgcRLOShQj gKLUr1BitAHtAEtZ2GBDZqgeJvLGM8UqtuG8/Kgx/IQjekiH3AK1de4v18TIkWW3wkKZo3wMJXSh X6Q92xGmncc+1k3olFuM6NpxgOnr3PpkPTaJ0mzeKqAVFSFccciKU4lfQ4n8hu7Hn/CUV386/tp/ GGYvctJjVgvuqEuMP6zrpSO4XPhRJNUOeLEgQS9YGRS6HM4dZf7G5pW26Cd36akzj32PV5mLV4zl hcTXdlW20bmaG6Nxx3xA1TU78yzjUOsLYVXBsO7GwnL+b40OpLCtb1d1L2CgSHAvxJuhs7J8Bg8z kzkwPgHKF6AOY8laslekGCGNGC94Sm4WesSvUXgDOaImUHZ0KyTPAF5gzA7FH8nxvfTr0l0tJ5hJ hSwgaCDTs/DWFdhJHnnKJX147MJP/aXn8bln1+VynFoGpk78gDErwuWUr+N0SpTyeigYbFYaAqr1 k/4XcXyzMQf0+xJcVbUz6UJnHatF9zdtdzxqAh+k/KU48MB7DRaizuinhHH14naAhmmJMueKPH+h Wt+YswuTkztZMto1GWcPm0xoDFANhDqqsCyPX1frM5lmw4y22jTG3KR5bOhXA0qUpYO5fbOo1Y6m qxOJQWUIfKiX9B6YQKRfRxEwLaq8lrUaJX0ip5+YspM0/WG1V9oOykKw+0cfB6j48jbcam0WMiw0 bldwE5IULur7PYpeOIA+CcdeHdn0HqKp1Jmd8Ak81CqhhrVEtLzvhZ9zReAym4Qj+r0o45Wt7MIG XEq9m1MeoBrwHdetX5Riu+F9leZvNyer7mhSJBbtY8szqe4uzUT2NCirRULXf56vLYofcm1nVa6f P3y5rTHO99jQ4uj2Z5D9gXTREIjKnkP9EKPeCjg0IUc1GMn6Ij05Rvp9fewEI+vJHJYao8yuoS8x 5a6oxlFFJy1YqmPvKSShrEHgK4oj4vvujDlONQHQT1uIcLDYBo1PVUle1de3A36uDJ/JgEn+Jdps Wnu843QB+e8pWViE1rVD4TuuS4kklYir2D7nQKxnc/c+WM8wsbxIa4pHPJObOVQnJF1BEcna0Xsw 4QZuf/9qRMgkPuZiTb0kqhgnUJuQm17XyNNtoNvvRudLldgcMh4D6WDgGsAB/qNRm5FFVdUeW+gK QhFrTh85gOXD5OROkXvq2TLdu4hxDaFGNnZXY74Y+3RSyhnjTP5VyRlJK5LWCOmUk4Ok5+AX6+/z iijyjkIRN2GV9760q88x351l+cmIvDA0XYILUDMu5GoeLR8S/+mHC1dqJJPeQVPBZ4a0XExPYwEy OTmSb52QnhmDdiQzqYRyPQQgBkudgwuDoJnmTxTEldc2lbgo1Kud+BAkLCtK0nXcm6QqIwbZ8RpM ftiAWiVEvsnv43JTdVAsn1+npRLNKptY0HGbNWagzi/QEzb0CGGw+tOWHhBAXbsRAjpOU2myo/7B L88A+ivlPFxg5SFsIeacRTbMuL2clqB+vV/up/3Dt5oCdS76eg4inykiIdRERfVpCvqTU374ab3o u1Cc8gJckzlBFmK/IJNA+t88ryfD3oLNKW2e/Zqv+Br2SRytgHk8aCkNnr/58GrI3glMO7zdSKRl tApkzdPKR2K6j72ffk4eqKq6S9NZtCXOPGyfqoBGK62osaxCpHi8WYSHrPRTxcwZn5leXX197Ads eQ7MsiO03KWj315IMHNLFh/VJubuN9El23JycBiI4m5szZ0khkGaEU9qLS18oalhkfW+Ko9nrReL HDt7t103bXLPcoxjFcqSJyB3LML6/jlm7sUSUZmQicPxmeVgL4OzNea3339mQDr702ffqTun9719 XnC4v3BnpSC0v/Jl9rhhtLQAOFRntyPJDNAf3EdU5QXQhEH+Ia9A6p8Kx9G2qpdxXUUFvA0JEW7+ 6PnP8RCUDBxoNF94pvKz2CybCN1y9izRusowChwp/vwYAjwzv6HykyIc3l6sCuNqtGp6oX3BldMU XDVfmt0sR+PBQSwfu0xnTiRSKnebsvDEVpCVqeeG3JbQ0c0rG6HcFWQGyWFUY7Il7EykXaT18x5w KMQdKLp1hWEFxvOEv1RsXSkmplpcmColridCuub6logegmYVEM2uY88EgFPTUDXpt9g1kcl9EBA4 3mIyPPvAQesPON1Jwz9BL2nCXo53tSA4PIydfh/bJD9e6zmPztcVWgOHCx/Meswy1Ek1HlLWxEjI 57VxhWQxfHgQ7+T6AFqElXnYUJFbUVmFmtwKnCpTqW3GVfsTG4QiaBErdmw//caO1r4eYyoZgyBK mVv3kl2cNGt+NJ3bMiX3b/lUcG9fPoC4ku3mdB8wInoWnJx5kpVZigeEU5OIHdGn8q567OdQUUMK 9y75r1z+Caw97hdFuqgxNGbL6aGUK0xlqzKLLKoLUDCwh/tYtqPXAJ7rbcSt9vWBnIVrtTrqM+zK 8RMSk2n6QorIzmEzLZcrWIm6TYZEeoBu1V7rvtqLAStJBg5m9LIBRmM1pspWvF7iz/OCkadZ5ElI mdGqnd50cEad9RuFbB4Gs2RIl8Va6m1eE/EcF1stc0YZi4Sc/nwf4e4BOS4VTUysX0/mvrrsVm/v 1GegVjvuL0ubMIpXrjJpildmY7Hov1Xh28tFHdupOyjiJRur5+mY1Ny06+72dJSk5ROAOpQmwB3a KJDEIvtUMsMrHrKnzh+Bo2PESLYBCVqoWSCw+Gz9awJjuSVnvJN1O3wjsfldk97eUJ2hUamWj7+M jCuV3yYg32DnZDWNq2Lw3cwzTnRGYizoiRyFn6Cj8l5zROynUcvtm6zd1tvsflR+qFlKOfugLypj KPRI9+O70SkTApGWiHYsTLw9xelBuS4+v/6Jg9Cw2Yg9L/ChbqXSKXSFjkCSClJA1B/lRzpTHP3P J3oD4BD07c66YkpRN9PvtX5hUnNzaErY5ulGTsD1tUtgc4uM3wWq7VfbyMkk+jb930tP9KC4Z7os 3HHFXCOzDX2bOZIJv46Z5F183bnyT2R5sWtoBS67f7mw8mIZ2hn4JOCkP2XVqaml4zU6s4ym57A3 gnP4YuTPm+UACdmry4WRh/W9lNEUZ88WlEVVE9PDEVy7bX6Zqek2cOUIxIRA3Hh3eV/dPHzNsTAf en+KyPF0Dbz7+/dwE927fuvJX3EofmsRyOnT3vVwO3o7id3ll507mp4gPnl4+MZ1f4HJ41O7/UYO f0JOo+fCZL1/Xcu/q79nk1MOR11XW21EDw1LjPG9f2zOLte6ZPwF/T19NrZ+lS3ct5Xp18HFycjE t4yOZD/D+R3hMgGQz0U2qg/uHXP/3B4GbxOm68ohv65Qah4Pg393RbDvLs4Csx5Wd2Svy7b+ed1X BFxXBNzzddx9Ng+0f7yXmwf+4u/anITnBPjPHsLhh4E+vicLgYiAf9VtHUv+y+b/DgwfinIQHH98 0EuHVxf30wfrF5/9XTvaIH7+/w6bJUFIV7ereu/ZWqhYQpPq5c7h6R22feD/1r/Ew/kbUeKDMeIR EZl7bSP8cP7I+Cx4w1ZX59Jdq6/0wx+4tjbk/qSXKeAxo2St0tbCzS9ZERuAX4DPhb2FjIU5vMpx FnUU0OHb1fZuamv9NL3IeWmZMf6okSzz/m/zQtfQw6g3/0nhwclQCFPnTSDW/1OQtUwRWhH36Fpm /u+vDP8RZHm+e6v/f2iy9l9qJmQKkHcY7wZG+h2tkX3ct01Jy59G+Ng1yQYFpTBjqjSKu6FRnmI5 iQelf8jTQrVZhBvp7rzOBsTQZF1lLrXTM0+/I1hcIsaVUBnDMT5QxS5ETqeaiLNMxVm9SAMiz/hg rPduL/3WY353U/sAWu9GSfvNQ19KkeEo8wNVy8eCsqmlDBXUqhmd2TfQw7y7tVEZ62QCh2+J2wFb dE1k+XN9sifNmuMSbrQVHTb1M7PtNRyTSHlmwxamKvUY+hGWgfbZ1t6jwmzqa2Ln/jT11MWWdI5A f97G1fnv7NIy0csMxiX3lcYPtv2cewlvO65jrudEmBaex6K/t1YrSsQsdq705txOCdTg07c20YXs RMRwjFiWeqIynpFo2N+sjcjE1lLOVSN+mSv13swfppDt0B8IzELPH2oT8N6o4/9WYlylPaVYJCZF CCBxBlG98rknSaLQADcgMNxtxD8+SzqYfUHmRXF3iD4LNm+EEhSM3TBpVhNGWIrDItiF4Mtx2vx4 KLD5cf9sw5KMt8WSoDdaICqiekO6v2PKXQwgIVOl/MByEMtOEJOmgSU1wHzAzIxD1APodqaw5or0 vduGQIh3vt4+29sgUNtj/YDJS2z1PaQ+QX1+03ctPzZyLwW1AyT72GLaj0tHPHMU60TtNAc3jS2g 4FASGn6TRnElVCqC19xHGHoM8KajeZ6aTEtEd77ZLA9JllZ5Q6BGkC6y/av4nP3vFx3e2SCHW52E bDISxwZsFYqnL56/ozBKW5+gyeirWdUrThxUSRukGiTmlCZwP22+yqeixIjFvzldcZ6D8xxpHSRY sDLG9F1QNFpvPzSPi3QWR4vfW+//+DrzgagocazpzPDHHdn/s3y3/mmEl9FjYESf/vdTnP/qCd28 P/73ucL+65GERQmPLsDQP51ifZfj5rKbhVmEsueCOcPezsHB6T4IsMvd8MIqzSCpdPEyC3vjCwZm MqMLfghjyvCzdGvxQE0PoVuLjZMTxTuq4eTW9yHjb76/Zv2G7hlkGh5ED+Xc361zM/nDyiA8MXUn G3UdJ1x8fzdZeZaz47r8bk+Hh70M4MlvkzbeJSHiZL9dXG3l/NvJudt/MO24Ti26wJfRmRotrTtx qTOV9b2pR/BPGuoFGlVOYv08/GmX9nH1/cXhB2/P9JHJrU2/NvWYkcmd5eXxSe6RFBLyqvS5VlBd 1VKE30FnOfVeaVaRO8lipctNh2Hy0/XR4A5lyUDEMvuCn35KzrR7f0CtxdXWO9OPu+P3dYWI93Nz Vw6NWFGVE7fjmi3q0YKphWodklV1Gx+lfxnV8cmYIWgaOi7bxWRPU3V+pqwB/Q4Uk3PiJteG04Uv FlZ4c16ZJ6k2zWF1Zhlo22xZeZ08E0L+U8cqD5Oo/8zBt00lIl3Ah9MKO1pOPUPvvG0MDqkTrBeS uTu9cE9LM2y8dhOTgb4je7/D7ZvGR/1MEN+8xsQm5rzpV/1VrRbNyJlFV9/fdxZZ6QtvXcUQIKAV 0cbFWv+gdyvHCNF5tDVuYdUQkeT1R75x+fBG014S/1zd/ojAHjWtyBC5OjHuXyIsHNIKD0yhY+c1 4Hk0xQ+PRQ+jpR6rJxA/XgXVBOXtqxp8TAnfG13tgaCcDweqQAKHn5IH5UL4+zmNbs6neJetxeLV t0odwffMuyQi28XiY0IFy3KUMT7YDuy7JPOFFFxNjYDgxXpWvGeUc/YferxDFENR4VLxuPA6TYRP lAZE743V2TakJNnTsNY8fmhRwVh14YvowrLjD5N+XQfPTzkOpbVeW9NDqZeV2YBkmrILoRLhL1Pe Anbzuhcoyd/XKvDJhPDWhfIjB5fMogILg7kfv1bzsBcXz8gsPyCe/2L0Uer9kqeGvjXetG3U+isQ diKEGqddtj76nDn+MeqMnb+GTVW/hT1vJTBlelaiQnEoSZFqZTB0/njozchhQmDS89qD6DIOS25v JUB6pM0MjDnmgBvCrGnt4V9FVYipoJRrZdyOf3WP8bADo/nnPzHAcjfp7Dx4BDjWVh0Hdh3ltDEp s42cFfrIEu6aD477o2t//9p1zDyTWQ2LWN8G8cI+RZEvRfWjQ+XWJFoBPMeSkJzRN3PAt0XjDuOr tjhp239zDarrwn5RLHHR72uygqMdmeNmREKMxMvjmKlIWsV3ImK99t8CsJU+CCpeeGz5R+BZ4hOe /rjzMXO8EwA5IMbfPirBPlMoaX/ejTIsKhCwu41H0KjHzVECj1jnmxe6aeSLF/BpH40OrfzQG6ZD yQRayt4oNyZGNlvl3lra/rH9kKRrCfoM3LxmltwiZ2HLh83tDkczgcERDO5xEuv4TEyDfDNVhl99 zXRyZU3OwkGfraacmpJiSwQVlBMyhVgEKfETi5mOSZmnyLwA5LuAdmx8dwBcNumhWyrISEQMXyOt RyqI3CjKdJdIQegxInoAL9rj9/u+QeidettZPuCYNJdiSY7DC6AT5Qik8QKM/eAW/Jw7TqFDI1f2 f6e9wF7G/HSDeYShsNSzoF0o+zjzaRwJlv67xygqErKQROJHf7U6sZhJD4PvfWioJ0baNp7Q4+rq bnu2QdwcJZj1+QywAvZHYNRGUYJ4KkRxUirFAd1ScvmPJkhHdhUo99+dANvvlW6wjzBejs8yCxji Pa44fsyMP/zo56JnKF+Nyz7p+U9a7IzHIfZWdxG5pxI0cjytwSIvsdqxbfM63P5njsk7YwVBiv9B TfH/BT2/podweVYVxNiOXawknkiw/B/msQ0wl/838NznQUb/AxKfpE74kZQf3FLkP8ypJjXugzyD lB4NRt7h6gHnBNMjiY8sB5f8h+5wgDzsPzuYlct3ZTEXkSh2XxMIGZPABk2Tazjt2hbqhGh0Z54/ r2DG5b1QjXADD7HH5m4LJOg84f95es/Fy+i38oa5p7B2QZpHkPyOUmVn6M35IJ/8CTzQXdJHuS49 Fj1WODXEACNPce2AKVD93cTMydS2H2p6eebldio6hM1G4MwbSMTTGf7x+ecUZXMOtZc6T86m/hcA UyCs39hj3LdlVPHfkHtGqm6SW8ysg7/8jTy92xA66xLy4A72p1ROV4WTo4P2CpPp6ZGnxvH0pL3G dAIxy8i2i43p4amH0f29qYfT/YNDD6f7JyceTkFfHk4Pjg89nB5OTjycHh5NPJwe7R14OD06OPFw enQ68XB6vH/g4fT4+NjD6cl0z8MpmJiH09M9iJJptY/Twz0Pp6en+8gpdEbeKWoavQ99IbnbpJAd OwVG4FeekSxa6cfNNocH6cdkvqFsZMWC1IOeJLoQfJf1OchiJV2v0vJWL8ttlUGqAWSuEiJNzupF Arm778gzlrOq1ST5qvIjVET9DdRHBOBmX39zSbJklWcso7WhRdNa4QtS0ipCjAeUBAwx2Jtg8qgM RE02J/J3m0AO6q9ISqkBUwUkgdieW+DrfZqur6A6frLYrqhm4R+vif7xy9jsII0oLbcb0oBvPuS8 CloXbx/4u4vAU6fAzDIfUuAsb4Rh2UmxOsDXuA5YwrJko8TGzqsMkn5p613W+DdjfxXbwu4Mn0I7 31Gd+0517jMOHtB+ZHWy1otVJ74WrU5FjRyNuqjxwKlGhoaPZZWs1WLViK8Zarx9KKs7dKrr8HGt jrVOrLo41qkDDVeXtbP2YWVHTrWxsf+xrIy1Uqza8LUwK+P9ukunpAcr2MZGtqZ4LHWx1olVFzcZ tLId8f3EaTJsMvhYOmAqj9UBvmaYDO1h8LiLeZw6VcMy6R9LNawlYlXDh38VhMRsV5tJKENeYO+a L2E9PIcZOZkTO5bDLJVb5MlgIre+OHbke+PUJskzmGKIGfPoEohq/6NjQuP3h/fc3QEWFTSD3cHw W1LeuogfYRVKtEnP55NYOPoF+VbY0dNMscbmNmeL/9v8NS5U4KgeXNhQb8PiY0I/BRUv0zz/IqnQ VVCugZajKlnq0NIJLOfgX9qnbsvNply5368wgxk/b/sAqFVmhv4kQrj1DWZ7m1Ys+dqh86uSuDaN /gaJ2/gctbW7pt28Kf4cZekENq0bKTuTAZlp6fqsu/G1K/wFbeMKaJ6nCXYVp0dHrWFz6ag1rD4d rYrNqaNWsXp1tCo2t45axerX0arYHDtaFZtnR61ide1oVWy+HbWK1bmjVbF5d9QqVveOVsXm39Gq 2Bw8ahWrh0erYnPxqFWsPh6tis3Jo1axenm0KjY3j1aF+XnQzSO6CGT80uEE+wh8xfQ4IUQRaMMq kz3m6SNYxJyohr+IfUT2BnXyNbwsIRfTRIg7+tiGEMQdA29gkTYy4ByFeJ7xULPGBfS+fPLLG/IG SLbTPAa836b7h54NZGNR9lC7XD/JdlPepIDi4LjBb5iozM+1GXDQCf1WB7faO6webrXKgIMCNZSB 1erqVlX3o8dBgXEgGeDG2XhRNntBk709umXghTyooM7+i/K6Ksu7bqBiuljp8WEDqFimecPkyt5L rVtnai8dJld21Vn30FTV8U00ZXLVE6jcP5PnUWyR8jBIY+4+EKTZfedhmL5YdudVyxmWcfZOZ92m V1Vn3adXq/xElnEPgjTc2dECNQ+0ijJ37wgM7b5zZ8CQtiIclk7D0kl2FQ7YY8fkx5vlTJgXlWMP /I0KTgFXjLmnTUBk9/3sAUTsRjFMYOx6GUDErpfHAxHuCugAImaEBwGR3aM7BhCxG8UAIna9DCBi 18sjggjbie0AImbcEwGR3WOeBhCxG8UAIna9DCBi18vjgQi3zA4gYgYOEhDZPWhwABG7UfCmUjz5 qlNx2E62q27wx3K9PIg/lptdBxAxQ2wJiOweXjuACG9xDSFsOZdalSE2zxqmOYAIN6mHAREW77kr iFzkcBUn3lalh+tiCb0vyheYYt9+MaIIJzylWN7/nhzQXFTUDuSCk580vAZ3cUCuKEfxRbn4ZBcH Ch5CmkjFz7c1xI/PyF2oeuL7zcvLV5MnRQm+7qKEqG8jgBoqjF5NRk9GRTkimfnwh1SztQ7/lih3 BSTam85MLcUxpX9ZfWIK/lsCxuNEUzJtZUNkMa6m6Io9slBS+MOznpuAU/3CXtowmOMHmtspBJUE yhYQK2s1aRIuSwpHG3LbnM0M5JBUraVZ1KyUXs0UoCSycNk9zCuJLCIP4EWxIOw1R2roEJPSCqNK HPNhE4Ilt6gZMFjRLhJcIL05z7N3Iieb2A7JlO4SC3zJrofUReDXRtoYl7XvMlJLLjjYvCX9G45w ARpgR6L46zkfWcg9TzQ4mvdQYaY8Z7K/VuUm6W5WYZcP3K71dg13hc+rbI3WH9nH2pFYSFeTc1pW cK+ZFY6baiNRz2YKgMdNVdpVWZCCaE74R5Psr7c2b1f4GzIchsrmkcmLKUwGgqlvoIPRXHqHRDw5 VRTzbANnrILtzBZ10t0Ez9GP9aomejaP3uHJIExLbO0sd3mmHGMaJPJZgjpw2DjTq+2/LupNtZ2T m9Jrq4UoFXxqcCGfHbxvKch5xhsl76zd2EkC3BWm0KULqzB4KJio4ZMmxuJ5bi2z+F6N83y9tkpD nttkCJ4QMgHXybv0okqT9xfpXVnRXBXRc+EfElTxPNkHEvOVmYND+iAICpPhXmQVcsnnZdiOH5lo ot4/M2eLyvkjvcA1SPrKTBkQOsBc4/tn2gQ5tr2tOmCfbm1umw7wvUhzF7NGvoIzRSYluISDq9Zt Ni6Dr4YuLiwmS1KYRdGDkAgwsx/0ICTiDiOUuopihmE3oviDsSNEkXgVM8Bmhs/P2pLngvQZCBiD uEZbvcyqevO6WMA81EClRlSsNWLVbA3Im562rl1uumS7IwTJlAOOr4LL0iW5A7ucIYKX+xa+dzQ8 VAGVh56wtU9Ph+tqblJrtHUiuTkcPYo3iCz7D9EsbWJQ3hwC7NgyfkhQkzh6ajgqShtaMGH7Bo1W aR4FSS7zsiZnHOjTbf7cBhf+xs3U4+s6AcXzBK6P1dnDhz7egmbAsbj14skqyfIZuDmSzbYyOaPl o6aCj0ulX7u5cbh6VutlUmfmckGcGGsj7/bsyG4R5qnK8AvdTqZ5UXxI83Kdni8WVVqb3KasfJSw Cjau/WZ3V8HBpdcVoAicMnJ8SucYS/D3ntIZxlI+ZxFqLWdwQCPxB9Pi+ypZn41x8kEKz4v5soQU VjIlJ/OTj+jcOhszrw88+cSe0MNJ6Ogpm/70ROS7sokQ06lYXCb1PMv4yXiUaC3/Vg67AePYabbA tX+TgsUWRl8Syq9oeaTuO4kEbpXmnEmECfJEOmeSQ4dHcHvveFnmeXmfLl7BIbgVzDVNX5JZwya9 u78onVcA9rzMS2KFmFZ7ssfTnuEwHf6QYC6c5gPE/I1ql+3V2y/enM+rsvhkbliQMriRkRZ2EMiN RoojQMzpkCdHF6c87da9mYnFIZFbbZeZZURB/rCkg8KEBfTGarkwhxjKKinpg1Udi+STYBtE0p76 joztvSsTmaEbZkVG3GMGhqFKpPI+FNNXG/4y/XRbJpXpBUOmRWkfLP/Y2tINE9cV8W+tks3G4h5E xSg1bMqR5wPmcS6O48wYlDzkqEO4nyWrNeC7Pm1FwViZTaTYgaav9u4yCL2FwfW+Akit7OJK5T8m kR925kEa+jcJnHdMzuyzWoEo7UMpvUCVc5LUTJ/64FWZHMHcaO/lSzqO9Tg5Ih6qK9x8MJRPXI4k fAPO9usyfMZOjaznBDaHBGpeZBnatCkmW0jIywziBSEjNRzEBdPKs3FHrwjhynT84HbNrv5fmdtj tizrkVvTc4Pc7uqtkbmFwyR7V66Zlo/s+vPy/abAo7r6tIVDow8hu7ivbOx/xFkuLLx71+7FNs9T 0x2OPLMyG4zJjAeG44q9G2WjRttvB6DALrsLYFB2HX2RFgb4XztJw89qZrJ2l8bRV5k0/i7bSZpu O8NinUtsiTLs6MpMGn+P7iSNtivavW0cPZ1J4+/wnaTR4qy6SHNZFpus2JozLwQBUeqDATvcGnEl 1vDaHsZgzqej//PiAAToIggZrkFRfTSHo+sLQfydv4sgOJL3JImj2wtJ/B2/kyQdY7VJL+CsOro8 Lw4456OTJGT879gmV/Z5PnZ1VrZbR2dDHkZ+SmE3nOEeRkTKnqN/08Kde7eDex4m0xv3jk7NuN+1 Szu45wEuvXHv6MiM+127sYN7VAYAaW/cOzov494/Xtu7roN7VEZ37r+A/T/YUGPnSuuuEVaKlx86 FujyRN0uwPpiUZEPb/DCAdyEYfstsEquvzkb06tB2d4fWTqjT4Jt/SFYsOsIdnpXXFWw09uYjwMs 7fAyGaOZ6PVS3F+2nm/oilsWEgjcZXkui9y66tUHT7HRoXsg6R1f8Hl21Zz43ctOJm3736a3xpKU loz+DMr+3OrXaTEbxw6mnlbSCGUpIeLpj+nA5tm5tLvIKbev7ZFdTFZWutvgJrd2xyneFeSakO5s CyMhZeImUx+nHeM17Bt+1wA2FBANmyEb+z+AK3CW5NtNYt3GkooeWFl2s2uiVnRgbkp8jNkxWbY3 fgC8f01hb9LZBna2zZAl9tjGn3tfxRLwcku/0Cl/jNyjnMFV0YbNiQIbmzJGyYy5omj5pba2hAZb fDCf/P2QwSj27I6wzI5WndxiwLy4VpXduBqrIj6770NF4ByVTOn+2fu0Erlx/MbiZiOSX5Qsh7/Q Z9BPYgaR9ryMl9k7W9gaCWtnRT7LZKpREjrVTCTDRaJoFcRBTxqBGPwHDKz0ticFlNrFaFxwRhcj ouDqj/qtvLMBSR6yb9SaTNXNHdouEsk3MFdTIt/AvpTqJd+AfRom/tI6V/Mu2vCEL2hQg700K9GB uSYTOrAvyHrRAft0tA74sqhfHZgrO6ED+7KuFx2wT0frAN/zj+YR3fuizPK0WpNb7a39Wy734VXH aaXCtdgCuEggtLAsrPnhrGynUw+M+BSa+0TWrU1UpMiH8gwL9unTZblaQcKIyIs1FJwUkD6OE9Se M8SbwW7K0rxkqeizyMFONAiTytogkkDxKfuBuKYzAhO9r1O4zl2fSEu81KyKzYBlcbBctmKjUJtz MyOSZx+7qvV5Od8Sa/kiMfMeedmIFNqEkOezGots0JX8FCLD2OqnIIEiajC1u10Us28Zc5cTM8WR PLOJ4l5BMGXrjhAtYJK5Q7SnehglcTFkxQauTUrvkm2+YaxQhtil1R+SIquXUBM9RDizgnj39PZV toA8MO251OPYAKf0OP5snc5/Y3420mZaNH0Jd5+S/4ze0FyIatW634Dus0V5T3YrqjLXZO8vz73l DDt+uUNbleEmS+sJVcNNltxgBfThzZBwuALr1c4TGvq9yRL6Oe8rlpUbMEli5sTCmvy42ZJjlMh2 P+22sneH8d74JMAfviTVgAxDfQdk6v5ToNwc8jPLVrNtgXFu5wXJkbHUVnzM2nqbMirhIcN54/rK b5ZPLq8Yv575lTI1bIE/CmPokbB7hWiFr7DGV7SKbRCS4VCeD8jPmYp5gzpNKPiQjzZkm56yI9yd ZPgFFC1f4cfLt1UZrvG1Quhw05wdQne9aY5s+xGIQRw+PmXTI8m4lQqTySkDEWeNwxN0oyimrX7j 9ISvnuEjNVktlHCQ1h3krV1vizm5E12e5xHIxaTF5y+cJVd6yeJrOPzuhlyQDltGWmED+Nx/yqKJ mf9UnMzw/wX/9WEBcVSZ9LIBigE/ajctnvziol/Mv0nndlc3FHwV5u5mUN7iaOUmI9mfOpcYUJ52 H1UrwyXFHAVUvfxEbvlTAPiHQnkTeKf0QNb+gLfleELdW6GjJtgH81hYShyxDny7C45mpHsoYagL pJpZ/q53x7dMvq+TKrH6Hv74X//w/bf/8t23//H93/z+D//29//z+78dkbrokqCrheisnMEbUYnp 03ABgB1kh1tE7Hrht4gM3ggZECO8EaFu73dV+slwxOJDm8/B5fiGZsItD88uvtgWuc6TzL5dhiVh m2VsRjzA7ACz5rpancsOMPvoMOt18DY+3GbGx54h9CgBUrrD1rYRzreRuzhxQ2FzuU3u08wAzhd4 HBi5V2DCz3lM8gxOPq+5/i01tImlC2MBYtNVRjf2UEHk3O2ySHLlB+wGg7+KHhXr8KyLKGxD78Bk a6Q2i43nsjQu/8aTbm0YdLKAQfTkQZ9dH+1P98nGiL6fPrv+7OgzVmYbv2TfuMdnPgwrw7AyDCvo EFXH0gh3ujR7f0BfdTcfiXecsvg8WoDTUtvpIekyUIXuNlKsPIR9BRdWkrIBKyFjZ9h65AO72uEP j/hcxrmzMGw92lU3YKXkzm0m/Dt4kx8TK8376fm88vCEhThoc/ZhXplA+qgKG9MhTGMI0wBYxPCJ B4tRG+aV4Fu4Su9HN+UqKehErgtWhjpAZpdHJ0d7UwtUXsISnBbhrJI5IYyD/uhZHySVgQ+d9GwZ NblBnDfjcR2Esr3ct0R5wzPbBNjtiHE4VrR47p92lDfTnrHs4M9R434Xfs/927vaE86xGEcYyUew 2DMPqJeSdab4zO8KC7VncrTopS2WHg+X/eM//+X33/73d//0uz/87q/dO9luO489SFcPJNA6RLNs vkg2cOKjFL+r1dRTIdBYDFiDQK0vZ6Tr9qdPqy7/9z///bu/+6vv/vFfd9GhAyuMyXCIBnZ0ifvV E+pNuMJ4QzjbwUTRq3JEYhGxDJvLNB4Gs3LidlVnTRDi3vHp3sFzFpHnDl1WInZsMW1KBXY7YUvQ pS1uWfmENWxZqWF1Hag1bLNhpYY1REKtYbvdXK3BLqJ2S8uPW2ipcXzITnaVlvsKFWuuhlrD5jJQ alg9BmoNcUWjiw/rrebKN6wxbGqN42Mzal2pcTLdM/3Aag1bjoZSwzr9VWsc7nkCjC0hEXKmBesI 3gFOw5mOmCzN3pyjHaSMANjDLK+h1YLcIACGCdSf/58AAAAA//8DAFBLAwQUAAYACAAAACEAHz+E o+cTAADRyAAAEgAAAHdvcmQvbnVtYmVyaW5nLnhtbOxdWY7jyJl+H2DuUBAgoOehK7mIlJRwtqHU gi6j3NPo6oEND+ZBKTEzidIGUsp0+dGX8RF8LF/BfwQXBWOPYDCLjakGutXJTfrX+OLf+Lvf/3W/ e/eSZHl6PNwN/Pfe4F1y2By36eHpbvA/v66+nwze5ef1YbveHQ/J3eBLkg9+/8N//sfvXm8Pl/1D ksGF7+AZh/z2BU4/n8+n25ubfPOc7Nf5++MpOcDJx2O2X5/hz+zpZr/OPl9O32+O+9P6nD6ku/T8 5SbwvHhQPuZ4N7hkh9vyEd/v0012zI+PZ3TL7fHxMd0k5Ud1R6bzvcWdi+Pmsk8OZ/yNN1myg99w POTP6Smvnra3fRqQ+Fw95EVGxMt+V133etL5tm22fgU+73fFz349ZttTdtwkeQ5HF8XJ+om+J/vu koHoEfUdOj+h+Z3VL9mv00P9GKQelPxr4b0H4d0U332DHnUlBHjxAyjT+iE/Z+vN+afL/l3jrw/b u4GHLznk6RbOvax3d4MV/mc8H9ygm/eX3Tn9mLwku1+/nJLqGsScXYIPF5ed96dddXI2jWbj6Swo zuxe0IkUPqovA53PztXFfnEVKPxqXx/cJpt0v94Vp06fzl929Tf/hPR99+GwBU2rv+DX5K/1vUP/ fX38D5vqa3bJY3n56ecM0XUGrpSf1TXwGwbw/6djDtY68Tz0mJvrlekBsQg9qDwNfz2vD0/AirtB GFeX4+fDbUAwvp3gvlIYvkgYi4IkC2GM7/147EWjmifwqx0L40/JQ/30DiQxGlWsrWTWkAQ67V4S gUgSS3tJrJazeTDuRhJ/BIe1fkp+TNbbJOtSGt5EKg102r00QpE0VtbSWM1GXhDMMTHYWF3axcc0 R94WlvCoQ1mMA5ko0Fn3khgJJFFohdVy4XvLyRL+rTllLImHy26XVO69sVogQcyPh3N6uCRh/QWk k/rX3/9ZH/9qy8XrbVasStkKfmwODFjnmzS9G3z6sn84AqKBlWYGazR5YAOr1Kd0/+kCKAFOpwdY lrbJ4xrWa0QQrED4mZYrUSSSc7leW6xEgTedhcEyrtndkZyvuKMDObdbjPon51gk55KLFnKOVst5 tPQ7t+dajzoQc7tVrn9iHovEXDpFCzEvJ7P4Pu7Obd9jp85fP9047VbrZ/9kPBHJuLRECxnPJt58 PI1bmLJkJ3cFSVdITJqym43cdWPG2z2gs2j1dLuNm4okMS18loUkPH8+WwWjclNus6eWg6TC2viC cGNtrQTRP2vz2cCJF/qTsX8vDZw8f3nI0u0fUVBlh4IqhUKQ0ROInYxm3uoqCgImwf+eT7vN3WA+ my0Df1Ss3up4Cil70B3Syo71MmqPficx/rWCWAk6S9rYKMTYAq4uQzEC7Ds/XrI0yd79lLwSAJg+ qsK9zb2dj55UsNAbeVPP84qt5Vdnod8RsKTZVewiqKNoKzHLUgi4ITmZcTS4cjQKvPkqWHGUskQZ zSCfRCm/d6CUgV+H5HieH58m1fLqn4zUMlnn51merhubMSGXKcYb8jq88rrU3iJg2Ep73Xj3YCKN C+HTNtyWbIANmYedEGX6yBlAHBkSFSjB4oCZLrwpKKIsroNP27CS1j2hktq6gohRz+KIUw7/6+// cOAcYA2S8RiftuHxnyAZgPJ7kPGqQzbNY2beFTJ31HpVrGCOWeoiBBaBS0KSEaAAfNqGpe48wJhh ZuFQnTLThQeIxtKlC5+2YWXnHgAS2pS69tYDxCPpgoVP2/C4ae2Fj20eU3kAMCCjnCGbNAxCiMAF sTRVhfeggi3IbD6djaKwxbb/cjol2cfkfK6SUc0k7v1x+wVtQsogY355fARe4+zz4XiGhf2p9vHk XmX288/LnxYf/vxu6N++q6+Q7FvIRCHe6D+mWX7+mKJ0euWsBGjPEF3oYgdJPKRiSgmWdZkCYZJh 8L5n7CjSp2pcqsGOFRIZme83Y8ww7BtvdHecDd4YEz0c9Y3uInVoqBM2dA+jvpFeZNPehvRh3Dfq OQEBbtXP7viaZL8c9+tD7dtJ7z8c/1d9/Orzs/Tp+VwcLz15tduHz3pRISt7gilOQQpwqo9Okws/ bF3R48XhKsOVokjFqHUBc4NcQqnA3XDipM5pHFTkVXwjF00cliK5oQzeGXKjSFpockOiG1MeM8x1 I5rIIpk+Ok1yA9jTUjdMwR5blxSMJyDDmTS1IAN7YRiPfPhPbVtAoFmBmCSQ5ya49OaJOkaJX2/z vwFfMEKtIweN+go6zoxq/dRq3VjjaQMPeDptXMjYLrAM+gk/CxEDH7VmWME7mrzQBXkto7x88qwQ Gk3eyAl57cKqfPKsgBhNXuSCvJahTj55VmCLJi92QV7LKCOfPF00JXUtYxfktYz48cnThUdS8pxA o5ZROD55unhHSh4X7JguDC0DYBV58GkUrWJLeYPpYjaKQ2kprzptvvBmQTyLZjwYA+tWlfgJ4snS tzKhZgTrl9V8djr9yK81dFO54jirzmAakJwUwRBcQ5lyf4qDu+bBcuVGps84h2bCfRsmSPYvXDBk vH8xRUPQ5ULuXyqbboI9Nuu8smSC1Kn1GS/RWtCZKfQZVdFM6MoUuNDL2BRMsZeWKbDp2E5Moc/o jNaCzkyhzxiOZkJXpsAFesamYIr0BKZgivTYVqHgfrIMFkWZgKhVSBaquo/GnjeFqkeIxzbXqKIY 0zDe0kR0qHUOEo9lZNog72CcekMxVNCguujYdUzVQS6yZIZhftYyFTmJcN1AZ/ywilZxlcMqNWuT gZyOu1URqwgXlyU4AA6hTs0UfqEiwBKb/GTXimIVGONypWxbseGKTfZyPO1WXaxCalzGlL7bkjE2 uc2uva2DYELpbcfFumbPm+HYPPXbNXus4nlc1SnLkVqxB5KmvVuurUKCXA6VOcC2HBpO+8AkU7jJ diyH0/nUC6Yt+3EWYThbjivQCnkCgG5VfpTaB3gr3PhlCEPp1IPe/JJGlt6Pmv5f2cvwWw8GNqiH /HcDT1PU86Na+JYqKozjm/eWUS1V2YpmaI8kKYioBV2wJWtugnoVqCPJCUPfQkJMw0Z3EWi9sBtJ 0sijNnFaSsd0SPhdKZ1mEK1B0pjyIlpK16uQGElONLJxC0yPQHdKpxfgIkmKfcotaCkdU5TfmdJp hqsaJE0p1yBQOlM0UKBycqxZuPAmgVcVteMwEzPWTJ1mnHrL0TKel6X1cjSgG4dpXz9FctTVndc/ Gw6gxX/23pQYtasUpUbsHatixExQiqD2pqhVam8xa5cosar23ntr1a6kUjVitLXH7f0f7ss9z9/H cz7fxwMkJtiDSrhv4/ut8FQ5FMlnNWjWzFf2sxDp057lurZOzzFXyynmTwLfanfVLyuonybj8WYt 053WrpzZLZIvOtAmeva8kGAf52Lqons2Zu3K9hYR/NJbKI3PgdJde8DM9EpNItH+u4WBsIcGb2M9 3Fu4bT92+GNDoWHjOpSdgDHkHxv9+H9ZDij7W1CInbc4lfrWDFovXUR+wvUzy+Wm8/ynCI+d2exy 0PzBglWg908HOiGois0vnujIhQc7h9Np/Ixzb2T6rNCTxAbxdcYdDqOz99S39zUGVpZhek84vJ+n tkkU/rpof7DZvkdVgY5uQC5httgQM9y2wtup+MD90WXKOFyPCXXMtyENiRLzhqfuMPJEw0KN6MKs kZdZQo8siOwuIY5eSPkvXxPHTcGuUY7KSSrDGjX/CRU7E0urqQwnu7hqHppo8F485s7XzIFVT6up ClQfVi5RxVwNEdbM8dhMUPb5IleD05VjssSXGBj+VSy0DBCK1WuWsn8rVEann0kLHpSJdCE40QRT HDhPj1mqQRpcgA3Jj+qw9rmhVDsGKhBffm6x5YLUKx57tjBaScsX/pGNnYUPPB1taMrijXdvY4qN zGt/PcMmB8C6kx+NLMloW/fc3sc/goCxHZQ+Tt6U1fsgNwJ3n2s3b0rhAx03e8lGv+06kZSYNMX4 R5rZdeuFw+K2TcwPmEmye66Sv8oQ154NodEfKyg8Pb0rx7I5TB9eeiu80ISXinKuTORLkrexZlWc TlO2b4oCaFIZSCIcV2Q3+ij61/1WBqhL9yJRZw/57hD6yZijUr/FOzjwh00GSg+OvBxFWjczcGFK iunZ+UCMNCdnJEdMMEKNwkXUYaGTufHa6jvuEu360icij/m1d+nTHpVGzxHoHpFHRfh9CKQXxNMA afwC50fQqmklMKqqaATX62byLCjgfuPE59jPngadN/fAk0Owk03Y0JF8+zrXKbm3U0qGCQPnIxSE BoPuPAU3DC3EH5BT8Hel3wV1TaEqKM46jR+4RAMChUGiBbHwT3bso6cHhp9dYP094Tb0pimQF04n maOERWFT2njOeqyPOubKpaJ5gLC/paca8KSMvdK4N26vpD2SWWZoQFJI51oqAUe5SZLB+Zn1GaVE wYkOlaIwvLtshb9mE2v6ViDyYmnbaS7HwwjEYErqN7NE8H4ITcPE3LtHRwDbeJ2+xILqwKWa7n1o zgURVUWcoUwInESbVPa7IsadW8UtmLEJL+UYYitivPRAuPim4xAvfHE4QDWwsv91atpjGVQ6FXJs G0vHC5oPW1OyqvtywZXsPkoeDKooGGlSJi/NozsLrvc8EkPYQvJij7FhO67oQVIohjgnjirk8QHE YxyecJD8oVIh3ivkGfSPh2zpwU5eYPOD1IzVM7JXij/zYRDLnrmdlS9XiZF4Lei5sNSXSPxNJjW5 eQMeAImqkGfEnuXPlF69/yrY26ro8U7nz8WlYNbUZOAVa0OtKddrX3npmOfVNKpYK794nR6+9LEU jk98Ugu+PupsULFqvimX+BLi5ow2VrktQ9XHJx8zcRxBRXSnvMjBDdlPs1rdDq5AMNGiqKDvXf4X 8kg5Vl3SWqu89yaOyuzvdrRGrIx0267q/0tUdkqRWUl59Y18dT2+kiFIMaWxk7PzXbZ6RYGyxdM2 dqBlsoUIVJ8yK7i+kxwChso6xtmf8gy4yByaXvhR+vt2ZbUXOOiU14Fzrj7+6VmcnNUX8vS4pBnZ x+Oijc311/WykugqSgVeWP8FFYzfaPVzSy/b2Fw/CwWY+yd7h54fuqWDfnzyRYEbmsXaziOeLQyf KRFhWKvBdBsLNfeVV/k97oFHKjcL8X0xsV/8qiZBMdLECeiqK8SUUifio7ZxDAlCf1WfPLIhgVmy 3/+fEABaxLs1itXbrsMCkFJ9lcYOrz9Rvqus4e14+Cr3+42EOf+0xjaogOLXK/spXiPYhSwId+Ww yjifMfzRhe1EQna+EeMaP76gbL+tTcKNnNn+FbbhqDZIDETxdbB2tllscnYHX4BzxzNvHGe/oqOG I2S0vlu6saTgY8fTJGmtnFD7k8uC9zvehnivgkZmTEP4Mjru2zIcYTlh/Ay0v7s8eC0oHrCxKQtq z6+QViCL2rnS3z1vkfQgyylzxicRg1Pktjbs3jSM4SKWacisaTGE2JnxDxKaiOZCVzdHaRKesa6k /ZKpr3p+UUXBbukMcpY1zM59cjY+yYJlPmtxwzwmA3kZfgl6dZs9bul3l902vF72hWUEH/GCVbNS uuTxaOGTn+mrBGASqOvcD3X/Blz6WTfZ6rbrkz0mMwGdWxVWx89pRlLfiUAdzg0k/OlUDva8vZGO bg7ynlziqHtNsPq7cYinkeCDKoLcJauXr1dc4ZMDZcshGxNp3wq2JmdCFvbnhEJUiAKPKdu9SER4 uN7rSwO35+qNC9c4N070gSj74kZBCthyEGy8NlsaT6BqByxUspYd++v53soyVKmVUCmsrlxx85lo T2vXjrSOdtZRW/fnzlaa3rhv5bigMLUOn9OqS9JGueMA1181qeEBVup0zYNkaLvUM+YJueHYOYJf +tWpgLc8q7ecFWbclrsbX+wqSlY9TUKGFlWxogPqjka+Vjcmf0votoSSc2r4fEBrQ5Z5yws9dbmS is4oZRVpi8SYpLMB3ga4vUVd5ISbBGkiq5ijiLxxk2RlaFbPjr73Vua+R2T26uZLGL6IIIuWJ5l5 rR97iUdAw8eDfnBr/DXk3ZYvgPszZwgd94/FxvyE6DNNcehaUnaGMtLwZlLFEy+ap7QpktArP89Q BAN2qFHCtxIsP5JLg1VFPBlKn5hXvvW61vdgOGhQDFxcVIhAvJxChW6qn8GXHDYIDMJe3+PXFkE0 WdUX1jwQD7ppwJoLBH6huzAOjJKvmRhPtlcq56q/4HKCdW192NOKSuD9iRYughJP2HuzXb/qcWv0 jXNgvqZiXQA2eTlUycTGjpoAYmMOQKFNOFNxCTmPlT8a6aGc647xdaY+mWGp6K3xdZgfRiKjA6pM xEpYpc1Gn1hVK6ihuMovjvcr5TCEArFmYZBQ1HLZK4BstdUvbbV58JCLm/lakmSPlJeNp6swv7pH LUXCRDInTC4Cr36fep7RQZmN8MrS9Xl584Z0Bv4UqWLDF4kvvA4WiuiU/L081oI58T+Vu4HjP/WS MO/QKx6iOvWWMZ72VsAX7YBx1haNRXgxp/K6RgLwPKbeJo9MzFCNgzgun/9Hecx1pGAgze5Uy8Gf nt8p+MEsRPwOVJuNFn6/SlcBGW6ISfFJ0g0xfWGRlG7TO3ASfLLvjBH8ejaCdkVgMFnD4m+SCckG BGooUTuq5Ge2oO68PyOujr0uk77d1aJ5iJ3XDn+5hKV3pwsuJXwmnj49n1dNv1NJwUDOZ+DFEhph JoFx55Inv6bkUTPl0z9xBwhhURO6GzcaoeFlx3HTOELq2b1Gw8DXf9S9+M0k41pfBLZIdsZKXhIW iRYadVXNlUgNEhWg951yUsBJc+RTV38zgy+MER2ja6ObgldaieWsb4BcuojfeDjXdRzZ8jNUacWk 0ONgleYG2W76BCXGzN76ga5B3vEhyMz8JXvToCOyIiDMGoEjp8/VcnIbMKarZjxGMKjHW7VxKS5J T/EpjzIt0L8f9ebxO3PtL43XSXrKjdfP3GdTPNut4rxvV47BovdE3TBox/NWTpwNlLrf5h2/e44h qe/1u5FNUHPybOnht99pdJru4nTZuFGGNkWCPEo9ptV72ovShoLqgEB4CBIjNiFNe+OVb/uHQyE2 FZHNHSQN8AUKNq0Wt5iP0qM4yfWo4UH2l6otLUaDWovAUaGfTK7wT/wqpk9P2Rgd0btxYYr2AzkD EAZcSxzb99o5WIXwy7xgsOwt42B4M/Qz4OaM58OunDvro6XZljAWTfBg2Nu0nNl5U/bu8f2qC4fG 1A+bioD3vrPeQQ22640ucm5wQ4RAydR2Xt234Nb9ur2e6VTP8i+o49Jz5zLRDmzUj2pbr9+ZwnlZ mJeC5gDjXkBCRhqdjD9fpm9q0huh96E42bUoH98kwExdLrBjcH/A6G0nKf943JxULxzm+zS5vilK bfwn/aoKyqiDMn4PdviwDLp9FzLAD9QVwhcH5sviQVCGCZ42+2ibnm9K57WiwZtmHxft5cDKXGG3 Xyosn5YoV4GCdSQ0XIJsaHt2/Kj3rnV9zLo3wxODTE5rzLrH7mjfyIRw1aIK7ywbalM7MRBuyvSt TJqqMgLtdZ32K1Voiepx4V2W2mgVstbPlCxfpIUhwAAHdajNOFpnk2I5ffHgtV2wUeZr5hLCPa+Y rpv2aSO0z/iuhzh5/DolVOInKyYb7ndkxyNnFdJpb+vKM7fNidxaX5HUsQeCXs5HdAdH5NcJFlML y3o1MW5m3/IwxIbRe+yMP1m1I6oEv3+p/Cvhuw6lZzHQjcnkBHreTktHgj4qBLTXiDoCFaK+PiYR +ptwYun0jOvhT5Yx0Km51mGYyMQBA5lEvs9l0lhL5hvXCeDaaaRUatz04oJ8pAZCcMBfsdvBPS8o UZ/gzF1kgL2KaBw2Duov4K74CSr297PxcDZ4LxXF7NOfywUPthtaAkGanYX7xR2kp/1S1OFmJp0L BTp5TQYQSnHT46D4NsSY/sqYfKfbafo3MQb5W7MGyGdlAfdFPd9XDFEXuTGdSy4BCw/lVAvK0qYD Zi7RpIcTtCIGA60Yssgeoh3/OxjF2yHHWBV6YKxBAYdBFZKVICG3p0aHhcJ3PCzOp97JPhJe4jzN /Cxk9DtawIRMT+wWk52yewKGwAe8HZwVQ3p96OLM6ztvsxcqtLxPaGQiHX1yNndGYEpvdI8Mc+lE c3bZtudY1tcQmY1vfFUlGQXG3yW4/NSocELWMKQ5RApvDb79MPyL0s8nicMxvOMyrSsIwSoqlJaH wCSCxe2+rtdCd52CnvSeG/GdEk4KTIve1tX/gdveGiwumJp8C9PPjYp2EKnFdW1PJedPUAEKggMm yQE+kN69eH/LKismMCbJoN56BKefg6LNbYsiAiApHsaoKLJdE5xOOQrVO6RlXjx8WHPhnWnK/yFm bOC/pIplo9T/nMUNPfTHMMN3TrVr3y+1as++vr+Vb8LNNmxPjHbkpSc7wab2pC1mh+87JGguJjVu 1tzcdvaujhxCJ3wVwYevSUGKszDDO4LfToq21P2vIRVi6me3Q+uPXl208bU6PoqrQjbyagn/NL1V POyrHiznDTiYP+2u1abLphqMmYJ20opshVQ24z8135Fn7Ww/NBN6IuBEPlpLGL2Gfh1q90M4ZGb/ yTMrEVxHx4/V0OdH6KIqvAWKX9/vv+CeNY3bucjbbGxuNKI8kDOcwp4Y+8+fflTt1n4ATe8/CDul zjN+SNm2nPnWQ3CIOCve8aUs1hO6R4DrmRL8mtSKo1xoJt/4IaFqwSBnpNf60UXpDZltp/ekJWPR umBgr3VHEv8pEzi9znlhf2XzZoePubUWLA9K53VB6kS4n19yjzv5/5mgN6pLObgBSEmTW+fpQxkZ sJnb2dAVd3pXcyjHLl4sDFy+xeT96lu6qKe3hVvp9Y9I5gDHP5Vdz0Hxb0z6xBy00MFDVUT+16sT 8WZPY1K1p1m8I1czPocmxI/VVGonsOU3M5+z7Vp7mpR3525nyIxsJFV8fDD59/DNtbRr+TUJFebT 78mWtyl+4e5SdzZ0DPjRpHc68omzAHrYDd6d5Is7fXk6vH7Pu+c334tZ+7agivfndic0EJWb9GN/ TySX9mxa7/boSYwJEmX4vgI5MIsJydQnq5AbLIvmHF2+fj+g+5vmE+cN9/EwOXJKvKgU2peK4SRQ GlY/O1Dvv+D9XjykANK7C5+Bo2NPWjsNuIFKrr/ZlO+dbG7k12cICe8X+TGjJ2tZxsRWsy6w49/h ooS9xti7ta37buFd5/fX9feFe8tMNzW2Ct2kdzv3Avd47x69mf2/vWL8f5f/ATmnWxk= --_005_2691CE0099834E4A9C5044EEC662BB9D452ECD3Fdfweml509mbxchi_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=3555; creation-date="Tue, 12 Nov 2013 03:11:23 GMT"; modification-date="Tue, 12 Nov 2013 03:11:23 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAArMAAADaCAMAAACCXTqSAAAAAXNSR0ICQMB9xQAAAGlQTFRFAAAA AAAAAwYLDQsKBAAACwYDAAAECgsNCgQAAAQKCAMAAAMIDQoIAwAADQgECAYDBAgNBAADCAoNAwAE AwMIBAAEBAQACAMDAAADAwADDQgKAwMDBAQEBAYICAgIAwQEBAQDCAYEAwQKoNCZ7QAAAAF0Uk5T AEDm2GYAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAAZdEVYdFNvZnR3YXJlAE1pY3Jvc29mdCBPZmZp Y2V/7TVxAAAM4UlEQVR42u2dC3uiOBuGAaXlYFnWdradnZ3v9P9/5EfOiUQMeCp6P9dcU0XMmzzc voQQTZYhhBBCCCGEEEIIfTOVxXPGXlet1+kUzMIsglmYhVmYxalra7PNpV5eK/WgzuyDLLIpsm3x /i72yh3L0sxYvv86nXrUTzB59rGdglmYRTALszALsziFEEIIIYQQQgghhBBKF+Oza6g147PTblzA n8QiHpDZK5kHszALszALszD7rMw2coLp9JbYpuW7zS8MZr8Xs9784qVzvmdMUVax/fJr88+Wb/7F NkW2efUZv3Oq/Mla+DGP8zNpXtqc72Pmwez3zbPyiLYnt8Q2Ld9tZmHkWZhdv2MwC7MwC7MwC7OP zexzxF5XrWEWZmEWIYQQQgghhBBCCCH0LXU4GLh7y/O7jQ8uDi6mSE2/sWtPlVEVd6j/E4zFClOE Wn2cXv6Y1eaIQ3JTJwvtZYB+KLjQpb/q6XK9DFyr3eR+823fbI9QEwnuqxlHXHD0N3/uYy0KvH0f T6hsJidZqpCj+rtAbVYuMC/BUI+DBRjcmNmPIR/08s9m2wu/LsLsUNqPV/dUFG9eKeshSGvT0PES TsaujwM1Du4OTqH/O4/Zsj3WIqdYoq36hJCj+ttA2RLzUpi1HCzB4G7MqpOdsmn41L38lZCMTjOr Ml+dWXg+98PTpghtHz7bX/shqsxC58+RiQQPOdr93IuMlfcqOVZ6ovSQuvouD2e6ygxU6yqKZ6q4 poi3yG9JF0mqVcocmVH9baBsiXmzmHUYJFNw5zyrLFMftYsxax6LHCMs6Wpx2gxTRSPm27epFs9g Njj+riqFedz0On/JQ14JMP9+PSxf1Exwbrux6km0Ra4leqfzmFWPTaBF5s3Ps/MouIMqW8lcHDHZ VzMvJf1Sv/fNjxizoldmM4Y0X33XJDy9VW118PP/k18xSWXWBnfHxr5ZJpMPs3envxkTO9LybZKK RhWnU2isRbolmZ8FDpmNfFfGb/m4/ibQpHlu0/RRivtpODAYOAq+MbPKInsJlZLtTuVZcTbzss3n Xm7uxCIe/WGXrGnT08LEFdjR4KM8K59UfXAd6nlhGrJ116i97WiY036kRa4lMWYnr8LCPBvUXwda ZF7iictru8QgmYL7MWs/xhOGL2C2+9p7r6nTcC1OdKHtw+Vx+fI6x+KTefYguJ/nzKm9kJ0i70w8 YlbZoC8iW9WldAXEWuRacmbfIKi/DrTIvFnMhhgkUXBHZqU/4olyp7kIs9JLc0be/Pi1N4Y0uW+7 PAXqI3Q5ZoPg5iDUbtxg9y4vMfRlRzTPyqJ0Ut9s/7Fdh6Y40iKvJWdegwX114EWmTePWYNBOgW3 ljr1yY7Vb32FLK+oz+sb6LHDoV/U2NOuNKTVxfeSGzvE2OXq0lf2+M9l9lhwQ5s3qFkpqkq9W+X6 CLanJ0v7/aYuyl3aLttoi4KWRMe6TjMbr7+5xlpgXoqhlgOLQToFq9fNbsRMjM/eIGTCFUrsnsL0 +Oya7IfZBZq8CrtORJ/TRfduN9trr4cIs8hDME+86YsQQgghhBBCVxK/ybGGWjOWMO3GiVmnC29U PAmzUy+e4QrMwizMwizMwuyzMvvQ6ynA7FWYnV5PITL7mPUU0sybngnPegorzrPZI6+nQJ59VGZX 6BjMwizMwizMwuxjM/scsddVa5iFWZhFCCGEEEIIIYQQQgjdX4zPrqHWjM+murH4LuLz3rud2o17 tzALszALszALszALszc8ArFf8b/Od2sekNmxUXy35kZHgDx70caRZ2EWZmEWZmEWZmEWZu93BB4u 9rpqDbMwC7MIIYQQQgghhFCK5o3Pivvh9l54c3QpVcZnx7sF1s01j3GDWcx2uVu9sBN/S+u8eF0c iq9/fYh1k9tMLDNcwGzMvAPrZpoHs7OYNeu6O33u3etyEffdW2vWq+/qM1LR4zF7aN7n3n893TyY PY/Z0qwdXwyv24Mw7LTZFjA7aV6pf3V5tnkwewazwwmsNeYPXTJvsfjP/e7Xh34LzEbM09YtMg9m z2B2UNWaLVWhT2rK9rL43Fc9zB43r2rdllnmwewiZl1XrOq126VMFXJufT1sFcbD7KR5wp4l5sHs ucwWNlXoreIwlP/+GDpk6jnMHmO28PLsDPNgdjGz8twmBmxKcbVQ5sNlQ2ts734VQ9ZQgzkwOzLP WpctMQ9mZzGrhhjz/GufqSte6az40l1bDme10rwmByCrhOWInolZz7zSfTVxvnkwO4vZ66eiB2b2 UuXDLMzCLEIIIYQQQgghhBBC6P7iNznWUGvGZ1Pd4Pe6Lto4fq8LZmEWZmEWZmEWZmH2hkeA9RTO qDXrKdztCJBnL9o48izMwizMwizMwizMwuz9jsDDxV5XrWEWZmEWIYQQQgghhBBKEeMGa6g14wbT bkz7c8mfR3kcZi95pyW2P8zCLMzCLMzC7LMy2+T1yS2xTct3m18YzH4vZr05x5GZyUlzvr1Np6Yy q9j+/rX5Zwsz/2KbItu8+ozfOVX+ZC38mNHF6g5nx4/MSJzzfcwxmP2+eVZy2J7cEtu0fLeZhZFn YXb9jsEszMIszMIszD42s88Re121hlmYhVmEEEIIIYQQQgghhNC31MRg4O4tz28yVLg0kJgPNf2+ rj1ZSFXcvyHZIw/KClOEWn3EXv6Y1dSTt1TVcu69jtUPMQoZ5lVPl+tlDWqz7Hs/I9BmG/LjQulA 4e7NVPGph3rz5z6L1t+39N3MmWwiv6KbcO921BAXsc1KG/OEZfPu3XocLMDgxsx+DImhl3822174 dVlmh2J/vPqviEhql1KQ2rrENOlsLNBoarUJZQP5x6TQ/53FbNm6fQ7rb+WeV/0SZiMNsRGzIGbi T/ylMGs5WILB3Zjt3PEQn7qXv5ZlpePMqiRSG5w+98OTpjhg1uav2YEOQnX1mKPdz/+Isk1qrPS0 6CFj9Z0615hSZd6pVX2+9uKpLK4psixW/6DWnU2vVdrMnqPMjh3LAs/0G6OeLWXWYZBMwZ3zrPZA ftSuwax6JvKP8KarxYk0ZFbsULYLAoWhYmHFoVaPmt6mLQlYJcD8+/Wg1KqVnEtS2sw+jtQ/qLXZ 6zLMho6FnhlmY56dlWfnUXAHVbaSuTh0qtemXxp9kWPyuzInmRUdNJ065FFQXzo57BtUof2JgYJQ OpB/SPR7ZAb5cHt3+gsxkeOr3iVr0/R+Bo3W39baffjNK6OvvMRcnGyIiRjG9CpbtfEPQtJ3dwIO DAaOgm/MrLJINFV27xdO6owzK09rLgN97uXmwf/hAB8yW9UpqWg7voJ3oVyqO8yz8qFssX/56SwI DnVrENQdDXvWj9Tf1doxG7kKm5Fng4boiGFM72NeTxSaOITgcSAxSKbgfszaj/HI+Usx233t7U7q xFyLM94BszFk5/QNRD/z6zBFmP7sXjxU+dM/ARwyqxqvs/Nw1lUfOUfQuP5erS/VNwgaoiOGnk19 zJcyG2KQRMEdmZX+iCfKnebSzJYi6Rhefu2NM00eMNvUsXJnMesFcrmvNieR3bu+rtBXG7E8K0sy qXyz/ccg0RQm0kH9/Vpf6hosaIiOGHpm3hjzbDGzBoN0Cm4tdRKUfbrf5lq5zC/WN9CDiLKD1NhT se5+lXqAs8jc+Kx+sIBZF8oPZOXGZyvDVKl3q/LggfBAFvb7Te1ZumxnCj2of1Brb6xrEbPxhugO 6yhmn8U9m8ms5cBikE7B6nWz+y9lnd08Usp1ibunEBuffbzjALPpil2FXSeQB+qce7ebbcJqkjCL Lq4qT7vpixBCCCGEEEIIIYRWLn77aA21Zqh22g1+F3E+P/wuIszCLMzCLMzC7HWYZd0amJ1rJOvW ZKxbQ56dlWcz1q0hz66P2RU6BrMwC7MwC7Mw+9jMPkfsddUaZmEWZhFCCCGEEEIIIYQeUYx1raHW jHXBLMzCLMziFMziGMzGtHgOd3b+/kemga/PsbQ53Nny/dfp1KN+gsmzj+0UzMIsglmYhVmYxSmE EEIIIYQQQgghhBBCCKGHkVqeHi3z7kmW/b6xSrVyu/5N1JdXMzVOLbPe5V//xfXT5uXGutasez+Y t3vrs80W+y6vTv7uqlxrW932Luts8+PVPu0wPcE8a13mzJPbdh+4dHnb66bQzCp/P/cwO9s8a10W mCf2wKUr2L57f1XMZlU/PG+l7cp5TE81z1gXmpe5R+iStsu1BArDpzBfdW1hdoZ5xrrQPNGlRdew fbPtFbPDyU0mBvLsfPO0dYF5u597PLqO7cNJTTNbFt5lBMzOMU9b55vXfYHs1WzPGj2OuPnxy11G 7P4Hs+nmaes880rRQ2Dc4PIqczXGqC9zK3EZYYYYazP2yNBBgnmVWqvJmdfIvy02IYQQQgghdHv9 H3y0r0/B5/9vAAAAAElFTkSuQmCC --_005_2691CE0099834E4A9C5044EEC662BB9D452ECD3Fdfweml509mbxchi_-- From wim.henderickx@alcatel-lucent.com Mon Nov 11 23:21:53 2013 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 75E6E21E80B5 for ; Mon, 11 Nov 2013 23:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.826 X-Spam-Level: X-Spam-Status: No, score=-8.826 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] 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 rW+KHE5W8UOW for ; Mon, 11 Nov 2013 23:21:47 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id B74B611E8121 for ; Mon, 11 Nov 2013 23:21:47 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id rAC7LeOD011138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Nov 2013 01:21:41 -0600 (CST) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rAC7Ldek020645 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 08:21:39 +0100 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.146]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 12 Nov 2013 08:21:39 +0100 From: "Henderickx, Wim (Wim)" To: Lucy yong , "l2vpn@ietf.org" Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Thread-Topic: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Thread-Index: Ac7cvqYcD4BB2/82Q4+fCPK55cREGP//WkCA//ukXXCACOGNgP/+4T1AgAKgCoA= Date: Tue, 12 Nov 2013 07:21:39 +0000 Message-ID: In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452ECD3F@dfweml509-mbx.china.huawei.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [135.239.27.39] Content-Type: multipart/mixed; boundary="_004_CEA7932E91C2Ewimhenderickxalcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 07:21:53 -0000 --_004_CEA7932E91C2Ewimhenderickxalcatellucentcom_ Content-Type: multipart/alternative; boundary="_000_CEA7932E91C2Ewimhenderickxalcatellucentcom_" --_000_CEA7932E91C2Ewimhenderickxalcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable From: Lucy yong > Date: Tuesday 12 November 2013 05:11 To: Wim Henderickx >, Lucy yong >, "l2vpn@ietf.org" > Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Wim, When using a (centralized) gateway to provide external network connection f= or an L2 VN, I agree, it is necessary for the gateway to advertise its IP h= ost address and MAC to all the NVEs in the L2VN. This can be done by the RT= 2, right? NVEs also use RT2 tenant IP/MAC addresses. Thus, each NVE will kn= ow the gateway IP host and MAC address and perform the proxy ARP function, = i.e. terminate the ARP requests if the requested tenant systems (including = gateway) is not in local, and send back the requested MAC in ARP reply. Th= us, tenant system will send an L2 frame with designation tenant system or g= ateway MAC in dMAC to attached NVE, the NVE just performs the table lookup = to obtain the outer address. There is no IP routing table on NVEs because o= f the L2VN. What is the problem here? Why need to use RT5 to convey the GW= IP/MAC info? Please explain, I may miss some part in nutshell. WH> if you look to the drawings in the slides the NVE(s) can also have IP p= refixes behind them. E.g. A firewall, etc. this is what we are referring to= in the draft. See fig 1/2/3/4/5. When using a gateway to provide external network connection for an L3 VN, N= VEs use their MAC address in ARP reply if VAP is L2 access interface. The L= 2 frame from a tenant system will be terminated at NVEs regardless the dest= ination tenant system is in the same VN or not. NVEs should have all the IP= routes in the VN. When NVE performs a lookup and is not able to find the m= atching one, it means the packet for the external. Since the gateway adver= tises its IP host address to NVEs as the gateway for the L3VN, NVEs will fo= rward the packets going to external to the gateway. In this case, the NVE = acts as the first-hop router, the gateway is the last-hop in the VN. You a= re right, it is necessary for a gateway to advertise its role besides its I= P address. If this is not there, should improve the protocol. Regarding the IRB capability, this is my view about IRB implementation in v= irtual overlay environment. [cid:image001.png@01CEDF20.763D4F00] Figure shows two L2VNs, VNx and VNz. NVE1 and NVE2 are member of both VNs.= If NVE1 and NVE2 implement L3 distributed gateway functions and have the s= ame MAC address for the L3dGW. When NVEs advertise both Tenant system IP an= d MAC addresses, each NVE have all the information about tenant systems in = both VNs. NVEs still terminates the ARP requests and provide the MAC for th= e remote tenant system in the same VN. NVEs returns L3dGW addresses for the= GW ARP request or if no matching MAC are founded. Thus, only the L3dGW at= ingress NVE process inter-VN traffic forwarding, i.e. the traffic from VNx= TS on NVE1 goes through the L3dGW on NVE1 to reach the VNy TS on NVE1 or V= Ny TS on NVE2. Will this make sense to you? WH> yes but the prefix draft is orthogonal to this. So lets not mix these t= hings. The draft describing IRB is the following for which you are a co-aut= hor and we are submitting an update to show the 2 architectures supporting = this: https://tools.ietf.org/html/draft-sajassi-l2vpn-evpn-inter-subnet-forwardin= g-02 Thanks, Lucy From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Monday, November 11, 2013 2:22 AM To: Lucy yong; l2vpn@ietf.org Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement In-line From: Lucy yong > Date: Monday 11 November 2013 08:43 To: Wim Henderickx >, Lucy yong >, "l2vpn@ietf.org" > Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Wim, I read the draft and still think that all the use cases work well with RT2.= Here are my views how these use cases in section 5 can be implemented wit= hout RT5 Use case 1 can be done by an L3 VN overlay, say VN10, and a gateway at DCGW= 1 and DCGW2. The gateway is used to interconnect the VN 10 and WAN. The VN10 route the traffic on SN 1 and SN2, SN3, and IP2-IP5. I call this = implementation =93L3VN plus a gateway=94 Why do you want to use an L2 VN ov= erlay here? WH> you don=92t have a GW IP in the L3VPN AFI/SAFI, so you will need to def= ine a new route to do this efficiently Use case 2 and use case 4 are about multi-homing. In the case 2, TS and NVE= are co-located; in the case 4, TS and NVE are physically separated. First= of all, IMO, when TS and NVE co-locate on the same server, multi-homed TS = is not necessary. The use case 4 is just the use case 1 with multi-homing. = Thus, it can be implemented by =93L3VN plus a gateway=94 w/ VRRP. WH> there is no VRRP in these cases since the appliance is a bump in the wi= re for use case 4 so they don=92t even speak IP, so you have an undefined N= H, which is also not evadable in the L3VPn AFI/SAFI and there is no ESI NH = possible In your use case 3, EVI10 should be replaced by an L3 overlay. The VRF on t= he NVE1 acts as the L3 distributed gateway for the EVN1 and EVN2. The VRF = on the NVE2 acts as the L3 distributed gateway for the EVN2 and EVN3. The V= RFs on DGW1 and DGW2 act as the gateway between the L3 overlay and WAN. If = NVE1 and NVE2 use RT2 advertises TS IP/MAC, NVE1 will know IP subnet/prefi= x associating to EVN1 and EVN2, and IP subnet/prefix associating to the L3 = overlay. When NVE1 receives a packet from IP1 and the packet has the destin= ation to SN1, the packet dMAC address will be the MAC address for the distr= ibuted gateway that is the same for all the NVEs. When NVE sees this addres= s, it will perform the VRF table lookup by using the destination IP addr on= the packet, which results the IP addr is associated to the EVN2, then NVE = performs the table look-up in EVI-2 that has both IP/MAC to outer (or VAP) = address mapping, so it will replace the dMAC addr on the packet with the re= al destination MAC addr and send to the VAP that SN1 associated to. When N= VE1 receives a packet from IP1 and the packet has the destination in the WA= N network, the dMAC on the packet is also the MAC address for the distribut= ed gateway. So NVE will perform the VRF table look-up by using the destinat= ion IP on the packet, which results to the outer IP address on one of DGWs,= say DGW1. NVE1 adds the L3 VN ID and the outer header on the packet prior = sending it out. When DGW1 receives the packet, it removes the tunnel header= and uses the L3 VN ID on the packet to reach the vGW on DGW1. The vGW perf= orm the packet treatment before sending to the WAN. WH> it depends how you want to do this, you can either go route from ingres= s w/o IP lookup on ingress or do a lookup on egress. Both options are possi= ble and required for some HW in the market. EVPN supports both already, wha= t this draft is doing is how prefixes should be used in this environment L2/L3 NVE service type described in draft-yong-nv03-nve is for this use cas= e. When L2/L3 NVE service type is used, NVE maintains both TS IP/MAC addres= ses but may advertise both IP/MAC addresses or one of the address depending= on the remote NVE service type. When L2 NVE service type is used, NVE just= maintains TS MAC addresses. Both cases can be implemented by EVPN solution= . WH> draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 describes the IRB c= ase There are places we need to use L2 VNs. For example, all TSes in a VN have = the same IP address but different MAC addresses; there is broadcast/multic= ast traffic in a VN; non-IP packet. However, we don=92t want to make a comp= lex EVPN solution to solve the case that L3VN can easily address. WH> see draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 it describes it= all. As I said not all use case can be done with L3VPN and this is require= d. Regards, Lucy From: HenderickxHi Win,, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.co= m] Sent: Friday, November 08, 2013 2:18 PM To: Lucy yong; l2vpn@ietf.org Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Lucy, did you read the draft and is explained in section 6. Show an example on how you do the scenario=92s with RT2 and you will see wh= y this is less efficient/scalable + does not support all scenario=92s in th= e draft like ESI NH. E-VPN distributes host routes using RT-2: (IP) + MAC and these can be an in= terface e.g. And prefixes can exists behind them. From: Lucy yong > Date: Friday 8 November 2013 22:10 To: "l2vpn@ietf.org" > Subject: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Hi Authors, I am not convinced if RT 5 is necessary for the use cases you specified in = the draft (or presentation). IMO: RT2 is sufficient to support all the case= s. There is a draft-yong-nvo3-nve, which covers all the L2 overlay cases, whic= h can be implemented by EVPN with RT2. One question, why EVPN service allow to VAP being an IP interface? Thanks, Lucy --_000_CEA7932E91C2Ewimhenderickxalcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable


From: Lucy yong <lucy.yong@huawei.com>
Date: Tuesday 12 November 2013 05:1= 1
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com<= /a>>, Lucy yong <lucy.yong@hu= awei.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: RE: comment on draft-rabad= an-l2vpn-evpn-prefix-advertisement

Wim,=

 

When using a (centrali= zed) gateway to provide external network connection for an L2 VN, I agree, = it is necessary for the gateway to advertise its IP host address and MAC to= all the NVEs in the L2VN. This can be done by the RT2, right? NVEs also use RT2 tenant IP/MAC addresses. Thus= , each NVE will know the gateway IP host and MAC address and perform the pr= oxy ARP function, i.e. terminate the ARP requests if the requested tenant s= ystems (including gateway) is not in local, and send back the requested  MAC in ARP reply. Thus, tenant= system will send an L2 frame with designation tenant system or gateway MAC= in dMAC to attached NVE, the NVE just performs the table lookup to obtain = the outer address. There is no IP routing table on NVEs because of the L2VN.  What is the problem here? Why nee= d to use RT5 to convey the GW IP/MAC info?  Please explain, I may miss= some part in nutshell.

WH> if you look to the drawings in the slides the NVE(s) can also h= ave IP prefixes behind them. E.g. A firewall, etc. this is what we are refe= rring to in the draft.
See fig 1/2/3/4/5.

 

When using a gateway t= o provide external network connection for an L3 VN, NVEs use their MAC addr= ess in ARP reply if VAP is L2 access interface. The L2 frame from a tenant = system will be terminated at NVEs regardless the destination tenant system is in the same VN or not. NVEs should have a= ll the IP routes in the VN. When NVE performs a lookup and is not able to f= ind the matching one, it means the packet for the external.  Since the= gateway advertises its IP host address to NVEs as the gateway for the L3VN, NVEs will forward the packets going t= o external to the gateway.  In this case, the NVE acts as the first-ho= p router, the gateway is the last-hop in the VN.  You are right, it is= necessary for a gateway to advertise its role besides its IP address.  If this is not there, should improve th= e protocol.

 

Regarding the IRB capa= bility, this is my view about IRB implementation in virtual overlay environ= ment.

 

 

Figure shows two L2VNs= , VNx and VNz.  NVE1 and NVE2 are member of both VNs. If NVE1 and NVE2= implement L3 distributed gateway functions and have the same MAC address f= or the L3dGW. When NVEs advertise both Tenant system IP and MAC addresses, each NVE have all the information about tenan= t systems in both VNs. NVEs still terminates the ARP requests and provide t= he MAC for the remote tenant system in the same VN. NVEs returns L3dGW addr= esses for the GW ARP request or if no matching MAC are founded.  Thus, only the L3dGW at ingress NVE = process inter-VN traffic forwarding, i.e. the traffic from VNx TS on NVE1 g= oes through the L3dGW on NVE1 to reach the VNy TS on NVE1 or VNy TS on NVE2= .  Will this make sense to you?

WH> yes but the prefix draft is orthogonal to this. So lets not mix= these things. The draft describing IRB is the following for which you are = a co-author and we are submitting an update to show the 2 architectures sup= porting this:


 

 

Thanks,

Lucy=

 

 

 

 

 

 

 

From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]
Sent: Monday, November 11, 2013 2:22 AM
To: Lucy yong; l2vpn@ietf.org<= br> Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t

 

In-line=

&n= bsp;

From: Lucy yong <lucy.yong@huawei.com>
Date: Monday 11 November 2013 08:43
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com>, Lucy yong <lucy.yong@huawei.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t

&n= bsp;

Wim,

 

I read the draft and s= till think that all the use cases work well with RT2.  Here are my vie= ws how these use cases in section 5 can be implemented without RT5

 

Use case 1 can be done= by an L3 VN overlay, say VN10, and a gateway at DCGW1 and DCGW2. The gatew= ay is used to interconnect the VN 10 and WAN.

The VN10 route the tra= ffic on SN 1 and SN2, SN3, and IP2-IP5.  I call this implementation = =93L3VN plus a gateway=94 Why do you want to use an L2 VN overlay here?

&n= bsp;

WH> = you don=92t have a GW IP in the L3VPN AFI/SAFI, so you will need to define = a new route to do this efficiently

 

Use case 2 and use cas= e 4 are about multi-homing. In the case 2, TS and NVE are co-located; in th= e case 4, TS and NVE are physically separated.  First of all, IMO, whe= n TS and NVE co-locate on the same server, multi-homed TS is not necessary. The use case 4 is just the use case 1 wit= h multi-homing. Thus, it can be implemented by =93L3VN plus a gateway=94 w/= VRRP.  

&n= bsp;

WH> = there is no VRRP in these cases since the appliance is a bump in the wire f= or use case 4 so they don=92t even speak IP, so you have an undefined NH, w= hich is also not evadable in the L3VPn AFI/SAFI and there is no ESI NH possible

 

In your use case 3, EV= I10 should be replaced by an L3 overlay. The VRF on the NVE1 acts as the L3= distributed gateway for the EVN1 and EVN2.  The VRF on the NVE2 acts = as the L3 distributed gateway for the EVN2 and EVN3. The VRFs on DGW1 and DGW2 act as the gateway between the L3 over= lay and WAN. If NVE1 and NVE2 use RT2 advertises TS IP/MAC,  NVE1 will= know IP subnet/prefix associating to EVN1 and EVN2, and IP subnet/prefix a= ssociating to the L3 overlay. When NVE1 receives a packet from IP1 and the packet has the destination to SN1, the = packet dMAC address will be the MAC address for the distributed gateway tha= t is the same for all the NVEs. When NVE sees this address, it will perform= the VRF table lookup by using the destination IP addr on the packet, which results the IP addr is associated= to the EVN2, then NVE performs the table look-up in EVI-2 that has both IP= /MAC to outer (or VAP) address mapping, so it will replace the dMAC addr on= the packet with the real destination MAC addr and send to the VAP that SN1 associated to.  When NVE1 recei= ves a packet from IP1 and the packet has the destination in the WAN network= , the dMAC on the packet is also the MAC address for the distributed gatewa= y. So NVE will perform the VRF table look-up by using the destination IP on the packet, which results to the ou= ter IP address on one of DGWs, say DGW1. NVE1 adds the L3 VN ID and the out= er header on the packet prior sending it out. When DGW1 receives the packet= , it removes the tunnel header and uses the L3 VN ID on the packet to reach the vGW on DGW1. The vGW perform = the packet treatment before sending to the WAN.

&n= bsp;

WH> = it depends how you want to do this, you can either go route from ingress w/= o IP lookup on ingress or do a lookup on egress. Both options are possible = and required for some HW in the market. EVPN supports both already, what this draft is doing is how prefixes shoul= d be used in this environment

 

L2/L3 NVE service type= described in draft-yong-nv03-nve is for this use case. When L2/L3 NVE serv= ice type is used, NVE maintains both TS IP/MAC addresses but may advertise = both IP/MAC addresses or one of the address depending on the remote NVE service type. When L2 NVE service type= is used, NVE just maintains TS MAC addresses. Both cases can be implemente= d by EVPN solution.

&n= bsp;

WH>&= nbsp;draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 describes the IRB = case

 

There are places we ne= ed to use L2 VNs. For example, all TSes in a VN have the same IP address bu= t different MAC addresses;  there is broadcast/multicast traffic in a = VN; non-IP packet. However, we don=92t want to make a complex EVPN solution to solve the case that L3VN can easily add= ress.  

&n= bsp;

WH> = see draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 it describes i= t all. As I said not all use case can be done with L3VPN and this is requir= ed.

 

Regards,

Lucy

 

 

 

 

 

 

 

From: HenderickxHi Win,, Wim= (Wim) [mailto:wim.hen= derickx@alcatel-lucent.com]
Sent: Friday, November 08, 2013 2:18 PM
To: Lucy yong; l2vpn@ietf.org<= br> Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t

 =

Lucy, d= id you read the draft and is explained in section 6.

Show an= example on how you do the scenario=92s with RT2 and you will see why this = is less efficient/scalable + does not support all scenario=92s in the d= raft like ESI NH.

 <= /span>

E-VPN d= istributes host routes using RT-2: (IP) + MAC and these can be an inter= face e.g. And prefixes can exists behind them.

 <= /span>

From: Lucy yong <lucy.yong@huawei.com>
Date: Friday 8 November 2013 22:10
To: "l2vpn@ietf.org"= <l2vpn@ietf.org>
Subject: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement

 <= /span>

Hi Authors,

 =

I am not convinced if RT= 5 is necessary for the use cases you specified in the draft (or presentati= on). IMO: RT2 is sufficient to support all the cases.

There is a draft-yong-nv= o3-nve, which covers all the L2 overlay cases, which can be implemented by = EVPN with RT2.

 =

One question, why EVPN s= ervice allow to VAP being an IP interface?

 =

Thanks,

Lucy

--_000_CEA7932E91C2Ewimhenderickxalcatellucentcom_-- --_004_CEA7932E91C2Ewimhenderickxalcatellucentcom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: attachment; filename="image001.png"; size=3555; creation-date="Tue, 12 Nov 2013 07:21:38 GMT"; modification-date="Tue, 12 Nov 2013 07:21:38 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAArMAAADaCAMAAACCXTqSAAAAAXNSR0ICQMB9xQAAAGlQTFRFAAAA AAAAAwYLDQsKBAAACwYDAAAECgsNCgQAAAQKCAMAAAMIDQoIAwAADQgECAYDBAgNBAADCAoNAwAE AwMIBAAEBAQACAMDAAADAwADDQgKAwMDBAQEBAYICAgIAwQEBAQDCAYEAwQKoNCZ7QAAAAF0Uk5T AEDm2GYAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAAZdEVYdFNvZnR3YXJlAE1pY3Jvc29mdCBPZmZp Y2V/7TVxAAAM4UlEQVR42u2dC3uiOBuGAaXlYFnWdradnZ3v9P9/5EfOiUQMeCp6P9dcU0XMmzzc voQQTZYhhBBCCCGEEEIIfTOVxXPGXlet1+kUzMIsglmYhVmYxalra7PNpV5eK/WgzuyDLLIpsm3x /i72yh3L0sxYvv86nXrUTzB59rGdglmYRTALszALsziFEEIIIYQQQgghhBBKF+Oza6g147PTblzA n8QiHpDZK5kHszALszALszD7rMw2coLp9JbYpuW7zS8MZr8Xs9784qVzvmdMUVax/fJr88+Wb/7F NkW2efUZv3Oq/Mla+DGP8zNpXtqc72Pmwez3zbPyiLYnt8Q2Ld9tZmHkWZhdv2MwC7MwC7MwC7OP zexzxF5XrWEWZmEWIYQQQgghhBBCCCH0LXU4GLh7y/O7jQ8uDi6mSE2/sWtPlVEVd6j/E4zFClOE Wn2cXv6Y1eaIQ3JTJwvtZYB+KLjQpb/q6XK9DFyr3eR+823fbI9QEwnuqxlHXHD0N3/uYy0KvH0f T6hsJidZqpCj+rtAbVYuMC/BUI+DBRjcmNmPIR/08s9m2wu/LsLsUNqPV/dUFG9eKeshSGvT0PES TsaujwM1Du4OTqH/O4/Zsj3WIqdYoq36hJCj+ttA2RLzUpi1HCzB4G7MqpOdsmn41L38lZCMTjOr Ml+dWXg+98PTpghtHz7bX/shqsxC58+RiQQPOdr93IuMlfcqOVZ6ovSQuvouD2e6ygxU6yqKZ6q4 poi3yG9JF0mqVcocmVH9baBsiXmzmHUYJFNw5zyrLFMftYsxax6LHCMs6Wpx2gxTRSPm27epFs9g Njj+riqFedz0On/JQ14JMP9+PSxf1Exwbrux6km0Ra4leqfzmFWPTaBF5s3Ps/MouIMqW8lcHDHZ VzMvJf1Sv/fNjxizoldmM4Y0X33XJDy9VW118PP/k18xSWXWBnfHxr5ZJpMPs3envxkTO9LybZKK RhWnU2isRbolmZ8FDpmNfFfGb/m4/ibQpHlu0/RRivtpODAYOAq+MbPKInsJlZLtTuVZcTbzss3n Xm7uxCIe/WGXrGnT08LEFdjR4KM8K59UfXAd6nlhGrJ116i97WiY036kRa4lMWYnr8LCPBvUXwda ZF7iictru8QgmYL7MWs/xhOGL2C2+9p7r6nTcC1OdKHtw+Vx+fI6x+KTefYguJ/nzKm9kJ0i70w8 YlbZoC8iW9WldAXEWuRacmbfIKi/DrTIvFnMhhgkUXBHZqU/4olyp7kIs9JLc0be/Pi1N4Y0uW+7 PAXqI3Q5ZoPg5iDUbtxg9y4vMfRlRzTPyqJ0Ut9s/7Fdh6Y40iKvJWdegwX114EWmTePWYNBOgW3 ljr1yY7Vb32FLK+oz+sb6LHDoV/U2NOuNKTVxfeSGzvE2OXq0lf2+M9l9lhwQ5s3qFkpqkq9W+X6 CLanJ0v7/aYuyl3aLttoi4KWRMe6TjMbr7+5xlpgXoqhlgOLQToFq9fNbsRMjM/eIGTCFUrsnsL0 +Oya7IfZBZq8CrtORJ/TRfduN9trr4cIs8hDME+86YsQQgghhBBCVxK/ybGGWjOWMO3GiVmnC29U PAmzUy+e4QrMwizMwizMwuyzMvvQ6ynA7FWYnV5PITL7mPUU0sybngnPegorzrPZI6+nQJ59VGZX 6BjMwizMwizMwuxjM/scsddVa5iFWZhFCCGEEEIIIYQQQgjdX4zPrqHWjM+murH4LuLz3rud2o17 tzALszALszALszALszc8ArFf8b/Od2sekNmxUXy35kZHgDx70caRZ2EWZmEWZmEWZmEWZu93BB4u 9rpqDbMwC7MIIYQQQgghhFCK5o3Pivvh9l54c3QpVcZnx7sF1s01j3GDWcx2uVu9sBN/S+u8eF0c iq9/fYh1k9tMLDNcwGzMvAPrZpoHs7OYNeu6O33u3etyEffdW2vWq+/qM1LR4zF7aN7n3n893TyY PY/Z0qwdXwyv24Mw7LTZFjA7aV6pf3V5tnkwewazwwmsNeYPXTJvsfjP/e7Xh34LzEbM09YtMg9m z2B2UNWaLVWhT2rK9rL43Fc9zB43r2rdllnmwewiZl1XrOq126VMFXJufT1sFcbD7KR5wp4l5sHs ucwWNlXoreIwlP/+GDpk6jnMHmO28PLsDPNgdjGz8twmBmxKcbVQ5sNlQ2ts734VQ9ZQgzkwOzLP WpctMQ9mZzGrhhjz/GufqSte6az40l1bDme10rwmByCrhOWInolZz7zSfTVxvnkwO4vZ66eiB2b2 UuXDLMzCLEIIIYQQQgghhBBC6P7iNznWUGvGZ1Pd4Pe6Lto4fq8LZmEWZmEWZmEWZmH2hkeA9RTO qDXrKdztCJBnL9o48izMwizMwizMwizMwuz9jsDDxV5XrWEWZmEWIYQQQgghhBBKEeMGa6g14wbT bkz7c8mfR3kcZi95pyW2P8zCLMzCLMzC7LMy2+T1yS2xTct3m18YzH4vZr05x5GZyUlzvr1Np6Yy q9j+/rX5Zwsz/2KbItu8+ozfOVX+ZC38mNHF6g5nx4/MSJzzfcwxmP2+eVZy2J7cEtu0fLeZhZFn YXb9jsEszMIszMIszD42s88Re121hlmYhVmEEEIIIYQQQgghhNC31MRg4O4tz28yVLg0kJgPNf2+ rj1ZSFXcvyHZIw/KClOEWn3EXv6Y1dSTt1TVcu69jtUPMQoZ5lVPl+tlDWqz7Hs/I9BmG/LjQulA 4e7NVPGph3rz5z6L1t+39N3MmWwiv6KbcO921BAXsc1KG/OEZfPu3XocLMDgxsx+DImhl3822174 dVlmh2J/vPqviEhql1KQ2rrENOlsLNBoarUJZQP5x6TQ/53FbNm6fQ7rb+WeV/0SZiMNsRGzIGbi T/ylMGs5WILB3Zjt3PEQn7qXv5ZlpePMqiRSG5w+98OTpjhg1uav2YEOQnX1mKPdz/+Isk1qrPS0 6CFj9Z0615hSZd6pVX2+9uKpLK4psixW/6DWnU2vVdrMnqPMjh3LAs/0G6OeLWXWYZBMwZ3zrPZA ftSuwax6JvKP8KarxYk0ZFbsULYLAoWhYmHFoVaPmt6mLQlYJcD8+/Wg1KqVnEtS2sw+jtQ/qLXZ 6zLMho6FnhlmY56dlWfnUXAHVbaSuTh0qtemXxp9kWPyuzInmRUdNJ065FFQXzo57BtUof2JgYJQ OpB/SPR7ZAb5cHt3+gsxkeOr3iVr0/R+Bo3W39baffjNK6OvvMRcnGyIiRjG9CpbtfEPQtJ3dwIO DAaOgm/MrLJINFV27xdO6owzK09rLgN97uXmwf/hAB8yW9UpqWg7voJ3oVyqO8yz8qFssX/56SwI DnVrENQdDXvWj9Tf1doxG7kKm5Fng4boiGFM72NeTxSaOITgcSAxSKbgfszaj/HI+Usx233t7U7q xFyLM94BszFk5/QNRD/z6zBFmP7sXjxU+dM/ARwyqxqvs/Nw1lUfOUfQuP5erS/VNwgaoiOGnk19 zJcyG2KQRMEdmZX+iCfKnebSzJYi6Rhefu2NM00eMNvUsXJnMesFcrmvNieR3bu+rtBXG7E8K0sy qXyz/ccg0RQm0kH9/Vpf6hosaIiOGHpm3hjzbDGzBoN0Cm4tdRKUfbrf5lq5zC/WN9CDiLKD1NhT se5+lXqAs8jc+Kx+sIBZF8oPZOXGZyvDVKl3q/LggfBAFvb7Te1ZumxnCj2of1Brb6xrEbPxhugO 6yhmn8U9m8ms5cBikE7B6nWz+y9lnd08Usp1ibunEBuffbzjALPpil2FXSeQB+qce7ebbcJqkjCL Lq4qT7vpixBCCCGEEEIIIYRWLn77aA21Zqh22g1+F3E+P/wuIszCLMzCLMzC7HWYZd0amJ1rJOvW ZKxbQ56dlWcz1q0hz66P2RU6BrMwC7MwC7Mw+9jMPkfsddUaZmEWZhFCCCGEEEIIIYQeUYx1raHW jHXBLMzCLMziFMziGMzGtHgOd3b+/kemga/PsbQ53Nny/dfp1KN+gsmzj+0UzMIsglmYhVmYxSmE EEIIIYQQQgghhBBCCKGHkVqeHi3z7kmW/b6xSrVyu/5N1JdXMzVOLbPe5V//xfXT5uXGutasez+Y t3vrs80W+y6vTv7uqlxrW932Luts8+PVPu0wPcE8a13mzJPbdh+4dHnb66bQzCp/P/cwO9s8a10W mCf2wKUr2L57f1XMZlU/PG+l7cp5TE81z1gXmpe5R+iStsu1BArDpzBfdW1hdoZ5xrrQPNGlRdew fbPtFbPDyU0mBvLsfPO0dYF5u597PLqO7cNJTTNbFt5lBMzOMU9b55vXfYHs1WzPGj2OuPnxy11G 7P4Hs+nmaes880rRQ2Dc4PIqczXGqC9zK3EZYYYYazP2yNBBgnmVWqvJmdfIvy02IYQQQgghdHv9 H3y0r0/B5/9vAAAAAElFTkSuQmCC --_004_CEA7932E91C2Ewimhenderickxalcatellucentcom_-- From lucy.yong@huawei.com Tue Nov 12 09:06:31 2013 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 DD60211E8122 for ; Tue, 12 Nov 2013 09:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.055 X-Spam-Level: X-Spam-Status: No, score=-5.055 tagged_above=-999 required=5 tests=[AWL=-0.657, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, 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 z6AgVrkaPfpt for ; Tue, 12 Nov 2013 09:06:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 70BB311E81E6 for ; Tue, 12 Nov 2013 09:06:09 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAE63911; Tue, 12 Nov 2013 17:06:01 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 17:05:46 +0000 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 17:05:59 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.03.0158.001; Tue, 12 Nov 2013 09:05:52 -0800 From: Lucy yong To: "Henderickx, Wim (Wim)" , "l2vpn@ietf.org" Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Thread-Topic: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Thread-Index: Ac7cvqYcD4BB2/82Q4+fCPK55cREGP//WkCA//ukXXCACOGNgP/+4T1AgAKgCoD//1O0EA== Date: Tue, 12 Nov 2013 17:05:51 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452ECEE8@dfweml509-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D452ECD3F@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.147] Content-Type: multipart/related; boundary="_004_2691CE0099834E4A9C5044EEC662BB9D452ECEE8dfweml509mbxchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 17:06:32 -0000 --_004_2691CE0099834E4A9C5044EEC662BB9D452ECEE8dfweml509mbxchi_ Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D452ECEE8dfweml509mbxchi_" --_000_2691CE0099834E4A9C5044EEC662BB9D452ECEE8dfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Wim, Please see below. From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Tuesday, November 12, 2013 1:22 AM To: Lucy yong; l2vpn@ietf.org Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement From: Lucy yong > Date: Tuesday 12 November 2013 05:11 To: Wim Henderickx >, Lucy yong >, "l2vpn@ietf.org" > Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Wim, When using a (centralized) gateway to provide external network connection f= or an L2 VN, I agree, it is necessary for the gateway to advertise its IP h= ost address and MAC to all the NVEs in the L2VN. This can be done by the RT= 2, right? NVEs also use RT2 tenant IP/MAC addresses. Thus, each NVE will kn= ow the gateway IP host and MAC address and perform the proxy ARP function, = i.e. terminate the ARP requests if the requested tenant systems (including = gateway) is not in local, and send back the requested MAC in ARP reply. Th= us, tenant system will send an L2 frame with designation tenant system or g= ateway MAC in dMAC to attached NVE, the NVE just performs the table lookup = to obtain the outer address. There is no IP routing table on NVEs because o= f the L2VN. What is the problem here? Why need to use RT5 to convey the GW= IP/MAC info? Please explain, I may miss some part in nutshell. WH> if you look to the drawings in the slides the NVE(s) can also have IP p= refixes behind them. E.g. A firewall, etc. this is what we are referring to= in the draft. See fig 1/2/3/4/5. [Lucy] OK, this is how to deal with network appliances. Do we want to treat= it as a middle box, or a tenant system that has multiple addresses? I gues= s, you want to address it as the latter. Even it is the latter, IMO, such t= enant system should not advertise the prefix in an L2 VN at all because it = serves middle box function only. If a tenant system is a gateway, it needs = to advertise itself as gateway (not the prefix from other VN). Then it will= be the same case as the following description. Does this make sense? When using a gateway to provide external network connection for an L3 VN, N= VEs use their MAC address in ARP reply if VAP is L2 access interface. The L= 2 frame from a tenant system will be terminated at NVEs regardless the dest= ination tenant system is in the same VN or not. NVEs should have all the IP= routes in the VN. When NVE performs a lookup and is not able to find the m= atching one, it means the packet for the external. Since the gateway adver= tises its IP host address to NVEs as the gateway for the L3VN, NVEs will fo= rward the packets going to external to the gateway. In this case, the NVE = acts as the first-hop router, the gateway is the last-hop in the VN. You a= re right, it is necessary for a gateway to advertise its role besides its I= P address. If this is not there, should improve the protocol. Regarding the IRB capability, this is my view about IRB implementation in v= irtual overlay environment. [cid:image001.png@01CEDF94.1548F5E0] Figure shows two L2VNs, VNx and VNz. NVE1 and NVE2 are member of both VNs.= If NVE1 and NVE2 implement L3 distributed gateway functions and have the s= ame MAC address for the L3dGW. When NVEs advertise both Tenant system IP an= d MAC addresses, each NVE have all the information about tenant systems in = both VNs. NVEs still terminates the ARP requests and provide the MAC for th= e remote tenant system in the same VN. NVEs returns L3dGW addresses for the= GW ARP request or if no matching MAC are founded. Thus, only the L3dGW at= ingress NVE process inter-VN traffic forwarding, i.e. the traffic from VNx= TS on NVE1 goes through the L3dGW on NVE1 to reach the VNy TS on NVE1 or V= Ny TS on NVE2. Will this make sense to you? WH> yes but the prefix draft is orthogonal to this. So lets not mix these t= hings. The draft describing IRB is the following for which you are a co-aut= hor and we are submitting an update to show the 2 architectures supporting = this: https://tools.ietf.org/html/draft-sajassi-l2vpn-evpn-inter-subnet-forwardin= g-02 [Lucy] yes, we provide a lot of inputs on evpn overlay and interworking dra= fts. Glad to continually work on these drafts. However, these drafts are st= ill individual drafts. As we are more and more clear on the network virtual= ization overlay for the cloud applications, we need update the descriptions= (an implementation) in these drafts to make it clear. As you aware, neithe= r of us works on these drafts recently. Thanks, Lucy From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Monday, November 11, 2013 2:22 AM To: Lucy yong; l2vpn@ietf.org Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement In-line From: Lucy yong > Date: Monday 11 November 2013 08:43 To: Wim Henderickx >, Lucy yong >, "l2vpn@ietf.org" > Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Wim, I read the draft and still think that all the use cases work well with RT2.= Here are my views how these use cases in section 5 can be implemented wit= hout RT5 Use case 1 can be done by an L3 VN overlay, say VN10, and a gateway at DCGW= 1 and DCGW2. The gateway is used to interconnect the VN 10 and WAN. The VN10 route the traffic on SN 1 and SN2, SN3, and IP2-IP5. I call this = implementation "L3VN plus a gateway" Why do you want to use an L2 VN overla= y here? WH> you don't have a GW IP in the L3VPN AFI/SAFI, so you will need to defin= e a new route to do this efficiently Use case 2 and use case 4 are about multi-homing. In the case 2, TS and NVE= are co-located; in the case 4, TS and NVE are physically separated. First= of all, IMO, when TS and NVE co-locate on the same server, multi-homed TS = is not necessary. The use case 4 is just the use case 1 with multi-homing. = Thus, it can be implemented by "L3VN plus a gateway" w/ VRRP. WH> there is no VRRP in these cases since the appliance is a bump in the wi= re for use case 4 so they don't even speak IP, so you have an undefined NH,= which is also not evadable in the L3VPn AFI/SAFI and there is no ESI NH po= ssible In your use case 3, EVI10 should be replaced by an L3 overlay. The VRF on t= he NVE1 acts as the L3 distributed gateway for the EVN1 and EVN2. The VRF = on the NVE2 acts as the L3 distributed gateway for the EVN2 and EVN3. The V= RFs on DGW1 and DGW2 act as the gateway between the L3 overlay and WAN. If = NVE1 and NVE2 use RT2 advertises TS IP/MAC, NVE1 will know IP subnet/prefi= x associating to EVN1 and EVN2, and IP subnet/prefix associating to the L3 = overlay. When NVE1 receives a packet from IP1 and the packet has the destin= ation to SN1, the packet dMAC address will be the MAC address for the distr= ibuted gateway that is the same for all the NVEs. When NVE sees this addres= s, it will perform the VRF table lookup by using the destination IP addr on= the packet, which results the IP addr is associated to the EVN2, then NVE = performs the table look-up in EVI-2 that has both IP/MAC to outer (or VAP) = address mapping, so it will replace the dMAC addr on the packet with the re= al destination MAC addr and send to the VAP that SN1 associated to. When N= VE1 receives a packet from IP1 and the packet has the destination in the WA= N network, the dMAC on the packet is also the MAC address for the distribut= ed gateway. So NVE will perform the VRF table look-up by using the destinat= ion IP on the packet, which results to the outer IP address on one of DGWs,= say DGW1. NVE1 adds the L3 VN ID and the outer header on the packet prior = sending it out. When DGW1 receives the packet, it removes the tunnel header= and uses the L3 VN ID on the packet to reach the vGW on DGW1. The vGW perf= orm the packet treatment before sending to the WAN. WH> it depends how you want to do this, you can either go route from ingres= s w/o IP lookup on ingress or do a lookup on egress. Both options are possi= ble and required for some HW in the market. EVPN supports both already, wha= t this draft is doing is how prefixes should be used in this environment L2/L3 NVE service type described in draft-yong-nv03-nve is for this use cas= e. When L2/L3 NVE service type is used, NVE maintains both TS IP/MAC addres= ses but may advertise both IP/MAC addresses or one of the address depending= on the remote NVE service type. When L2 NVE service type is used, NVE just= maintains TS MAC addresses. Both cases can be implemented by EVPN solution= . WH> draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 describes the IRB c= ase There are places we need to use L2 VNs. For example, all TSes in a VN have = the same IP address but different MAC addresses; there is broadcast/multic= ast traffic in a VN; non-IP packet. However, we don't want to make a comple= x EVPN solution to solve the case that L3VN can easily address. WH> see draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 it describes it= all. As I said not all use case can be done with L3VPN and this is require= d. Regards, Lucy From: HenderickxHi Win,, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.co= m] Sent: Friday, November 08, 2013 2:18 PM To: Lucy yong; l2vpn@ietf.org Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Lucy, did you read the draft and is explained in section 6. Show an example on how you do the scenario's with RT2 and you will see why = this is less efficient/scalable + does not support all scenario's in the dr= aft like ESI NH. E-VPN distributes host routes using RT-2: (IP) + MAC and these can be an in= terface e.g. And prefixes can exists behind them. From: Lucy yong > Date: Friday 8 November 2013 22:10 To: "l2vpn@ietf.org" > Subject: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Hi Authors, I am not convinced if RT 5 is necessary for the use cases you specified in = the draft (or presentation). IMO: RT2 is sufficient to support all the case= s. There is a draft-yong-nvo3-nve, which covers all the L2 overlay cases, whic= h can be implemented by EVPN with RT2. One question, why EVPN service allow to VAP being an IP interface? Thanks, Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D452ECEE8dfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Wim, Please see below.=

 

From: Henderic= kx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]
Sent: Tuesday, November 12, 2013 1:22 AM
To: Lucy yong; l2vpn@ietf.org
Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t

 

&n= bsp;

&n= bsp;

From: Lucy yong <lucy.yong@huawei.com>
Date: Tuesday 12 November 2013 05:11
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com>, Lucy yong <lucy.yong@huawei.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t

&n= bsp;

Wim,

 

When using a (centrali= zed) gateway to provide external network connection for an L2 VN, I agree, = it is necessary for the gateway to advertise its IP host address and MAC to= all the NVEs in the L2VN. This can be done by the RT2, right? NVEs also use RT2 tenant IP/MAC addresses. Thus= , each NVE will know the gateway IP host and MAC address and perform the pr= oxy ARP function, i.e. terminate the ARP requests if the requested tenant s= ystems (including gateway) is not in local, and send back the requested  MAC in ARP reply. Thus, tenant= system will send an L2 frame with designation tenant system or gateway MAC= in dMAC to attached NVE, the NVE just performs the table lookup to obtain = the outer address. There is no IP routing table on NVEs because of the L2VN.  What is the problem here? Why nee= d to use RT5 to convey the GW IP/MAC info?  Please explain, I may miss= some part in nutshell.

&n= bsp;

WH> = if you look to the drawings in the slides the NVE(s) can also have IP prefi= xes behind them. E.g. A firewall, etc. this is what we are referring to in = the draft.

See fig= 1/2/3/4/5.

[Lucy] OK, this = is how to deal with network appliances. Do we want to treat it as a middle = box, or a tenant system that has multiple addresses? I guess, you want to a= ddress it as the latter. Even it is the latter, IMO, such tenant system should not advertise the prefix in an = L2 VN at all because it serves middle box function only. If a tenant system= is a gateway, it needs to advertise itself as gateway (not the prefix from= other VN). Then it will be the same case as the following description. Does this make sense?

 

When using a gateway t= o provide external network connection for an L3 VN, NVEs use their MAC addr= ess in ARP reply if VAP is L2 access interface. The L2 frame from a tenant = system will be terminated at NVEs regardless the destination tenant system is in the same VN or not. NVEs should have a= ll the IP routes in the VN. When NVE performs a lookup and is not able to f= ind the matching one, it means the packet for the external.  Since the= gateway advertises its IP host address to NVEs as the gateway for the L3VN, NVEs will forward the packets going t= o external to the gateway.  In this case, the NVE acts as the first-ho= p router, the gateway is the last-hop in the VN.  You are right, it is= necessary for a gateway to advertise its role besides its IP address.  If this is not there, should improve th= e protocol.

 

Regarding the IRB capa= bility, this is my view about IRB implementation in virtual overlay environ= ment.

 

 

Figure shows two L2VNs= , VNx and VNz.  NVE1 and NVE2 are member of both VNs. If NVE1 and NVE2= implement L3 distributed gateway functions and have the same MAC address f= or the L3dGW. When NVEs advertise both Tenant system IP and MAC addresses, each NVE have all the information about tenan= t systems in both VNs. NVEs still terminates the ARP requests and provide t= he MAC for the remote tenant system in the same VN. NVEs returns L3dGW addr= esses for the GW ARP request or if no matching MAC are founded.  Thus, only the L3dGW at ingress NVE = process inter-VN traffic forwarding, i.e. the traffic from VNx TS on NVE1 g= oes through the L3dGW on NVE1 to reach the VNy TS on NVE1 or VNy TS on NVE2= .  Will this make sense to you?

&n= bsp;

WH> = yes but the prefix draft is orthogonal to this. So lets not mix these thing= s. The draft describing IRB is the following for which you are a co-author = and we are submitting an update to show the 2 architectures supporting this:

&n= bsp;

https://tools.ietf.org/html/draft-sajassi-l2vpn-evpn-inter-subnet= -forwarding-02

[Lucy] yes, we p= rovide a lot of inputs on evpn overlay and interworking drafts. Glad to con= tinually work on these drafts. However, these drafts are still individual d= rafts. As we are more and more clear on the network virtualization overlay for the cloud applications, we need = update the descriptions (an implementation) in these drafts to make it clea= r. As you aware, neither of us works on these drafts recently.

 =

 

Thanks,

Lucy

 

 

 

 

 

 

 

From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]
Sent: Monday, November 11, 2013 2:22 AM
To: Lucy yong; l2vpn@ietf.org<= br> Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t

 =

In-line=

 <= /span>

From: Lucy yong <lucy.yong@huawei.com>
Date: Monday 11 November 2013 08:43
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com>, Lucy yong <lucy.yong@huawei.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t

 <= /span>

Wim,

 

I read the draft and s= till think that all the use cases work well with RT2.  Here are my vie= ws how these use cases in section 5 can be implemented without RT5

 

Use case 1 can be done= by an L3 VN overlay, say VN10, and a gateway at DCGW1 and DCGW2. The gatew= ay is used to interconnect the VN 10 and WAN.

The VN10 route the tra= ffic on SN 1 and SN2, SN3, and IP2-IP5.  I call this implementation &#= 8220;L3VN plus a gateway” Why do you want to use an L2 VN overlay her= e?

 <= /span>

WH> = you don’t have a GW IP in the L3VPN AFI/SAFI, so you will need to def= ine a new route to do this efficiently

 

Use case 2 and use cas= e 4 are about multi-homing. In the case 2, TS and NVE are co-located; in th= e case 4, TS and NVE are physically separated.  First of all, IMO, whe= n TS and NVE co-locate on the same server, multi-homed TS is not necessary. The use case 4 is just the use case 1 wit= h multi-homing. Thus, it can be implemented by “L3VN plus a gateway&#= 8221; w/ VRRP.  <= /p>

 <= /span>

WH> = there is no VRRP in these cases since the appliance is a bump in the wire f= or use case 4 so they don’t even speak IP, so you have an undefined N= H, which is also not evadable in the L3VPn AFI/SAFI and there is no ESI NH possible

 

In your use case 3, EV= I10 should be replaced by an L3 overlay. The VRF on the NVE1 acts as the L3= distributed gateway for the EVN1 and EVN2.  The VRF on the NVE2 acts = as the L3 distributed gateway for the EVN2 and EVN3. The VRFs on DGW1 and DGW2 act as the gateway between the L3 over= lay and WAN. If NVE1 and NVE2 use RT2 advertises TS IP/MAC,  NVE1 will= know IP subnet/prefix associating to EVN1 and EVN2, and IP subnet/prefix a= ssociating to the L3 overlay. When NVE1 receives a packet from IP1 and the packet has the destination to SN1, the = packet dMAC address will be the MAC address for the distributed gateway tha= t is the same for all the NVEs. When NVE sees this address, it will perform= the VRF table lookup by using the destination IP addr on the packet, which results the IP addr is associated= to the EVN2, then NVE performs the table look-up in EVI-2 that has both IP= /MAC to outer (or VAP) address mapping, so it will replace the dMAC addr on= the packet with the real destination MAC addr and send to the VAP that SN1 associated to.  When NVE1 recei= ves a packet from IP1 and the packet has the destination in the WAN network= , the dMAC on the packet is also the MAC address for the distributed gatewa= y. So NVE will perform the VRF table look-up by using the destination IP on the packet, which results to the ou= ter IP address on one of DGWs, say DGW1. NVE1 adds the L3 VN ID and the out= er header on the packet prior sending it out. When DGW1 receives the packet= , it removes the tunnel header and uses the L3 VN ID on the packet to reach the vGW on DGW1. The vGW perform = the packet treatment before sending to the WAN.

 <= /span>

WH> = it depends how you want to do this, you can either go route from ingress w/= o IP lookup on ingress or do a lookup on egress. Both options are possible = and required for some HW in the market. EVPN supports both already, what this draft is doing is how prefixes shoul= d be used in this environment=

 

L2/L3 NVE service type= described in draft-yong-nv03-nve is for this use case. When L2/L3 NVE serv= ice type is used, NVE maintains both TS IP/MAC addresses but may advertise = both IP/MAC addresses or one of the address depending on the remote NVE service type. When L2 NVE service type= is used, NVE just maintains TS MAC addresses. Both cases can be implemente= d by EVPN solution.

 <= /span>

WH>&= nbsp;draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 describes the IRB = case

 

There are places we ne= ed to use L2 VNs. For example, all TSes in a VN have the same IP address bu= t different MAC addresses;  there is broadcast/multicast traffic in a = VN; non-IP packet. However, we don’t want to make a complex EVPN solution to solve the case that L3VN can easily add= ress.  

 <= /span>

WH> = see draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 it describes i= t all. As I said not all use case can be done with L3VPN and this is requir= ed.

 

Regards,

Lucy

 

 

 

 

 

 

 

From: HenderickxHi Win,, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]
Sent: Friday, November 08, 2013 2:18 PM
To: Lucy yong; l2vpn@ietf.org<= br> Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t

 =

Lucy, d= id you read the draft and is explained in section 6.

Show an= example on how you do the scenario’s with RT2 and you will see why t= his is less efficient/scalable + does not support all scenario’s = in the draft like ESI NH.

 <= /span>

E-VPN d= istributes host routes using RT-2: (IP) + MAC and these can be an inter= face e.g. And prefixes can exists behind them.

 <= /span>

From: Lucy yong <lucy.yong@huawei.com>
Date: Friday 8 November 2013 22:10
To: "l2vpn@ietf.org"= <l2vpn@ietf.org>
Subject: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement

 <= /span>

Hi Authors,

 =

I am not convinced if RT= 5 is necessary for the use cases you specified in the draft (or presentati= on). IMO: RT2 is sufficient to support all the cases.

There is a draft-yong-nv= o3-nve, which covers all the L2 overlay cases, which can be implemented by = EVPN with RT2.

 =

One question, why EVPN s= ervice allow to VAP being an IP interface?

 =

Thanks,

Lucy

--_000_2691CE0099834E4A9C5044EEC662BB9D452ECEE8dfweml509mbxchi_-- --_004_2691CE0099834E4A9C5044EEC662BB9D452ECEE8dfweml509mbxchi_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=3555; creation-date="Tue, 12 Nov 2013 17:05:51 GMT"; modification-date="Tue, 12 Nov 2013 17:05:51 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAArMAAADaCAMAAACCXTqSAAAAAXNSR0ICQMB9xQAAAGlQTFRFAAAA AAAAAwYLDQsKBAAACwYDAAAECgsNCgQAAAQKCAMAAAMIDQoIAwAADQgECAYDBAgNBAADCAoNAwAE AwMIBAAEBAQACAMDAAADAwADDQgKAwMDBAQEBAYICAgIAwQEBAQDCAYEAwQKoNCZ7QAAAAF0Uk5T AEDm2GYAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAAZdEVYdFNvZnR3YXJlAE1pY3Jvc29mdCBPZmZp Y2V/7TVxAAAM4UlEQVR42u2dC3uiOBuGAaXlYFnWdradnZ3v9P9/5EfOiUQMeCp6P9dcU0XMmzzc voQQTZYhhBBCCCGEEEIIfTOVxXPGXlet1+kUzMIsglmYhVmYxalra7PNpV5eK/WgzuyDLLIpsm3x /i72yh3L0sxYvv86nXrUTzB59rGdglmYRTALszALsziFEEIIIYQQQgghhBBKF+Oza6g147PTblzA n8QiHpDZK5kHszALszALszD7rMw2coLp9JbYpuW7zS8MZr8Xs9784qVzvmdMUVax/fJr88+Wb/7F NkW2efUZv3Oq/Mla+DGP8zNpXtqc72Pmwez3zbPyiLYnt8Q2Ld9tZmHkWZhdv2MwC7MwC7MwC7OP zexzxF5XrWEWZmEWIYQQQgghhBBCCCH0LXU4GLh7y/O7jQ8uDi6mSE2/sWtPlVEVd6j/E4zFClOE Wn2cXv6Y1eaIQ3JTJwvtZYB+KLjQpb/q6XK9DFyr3eR+823fbI9QEwnuqxlHXHD0N3/uYy0KvH0f T6hsJidZqpCj+rtAbVYuMC/BUI+DBRjcmNmPIR/08s9m2wu/LsLsUNqPV/dUFG9eKeshSGvT0PES TsaujwM1Du4OTqH/O4/Zsj3WIqdYoq36hJCj+ttA2RLzUpi1HCzB4G7MqpOdsmn41L38lZCMTjOr Ml+dWXg+98PTpghtHz7bX/shqsxC58+RiQQPOdr93IuMlfcqOVZ6ovSQuvouD2e6ygxU6yqKZ6q4 poi3yG9JF0mqVcocmVH9baBsiXmzmHUYJFNw5zyrLFMftYsxax6LHCMs6Wpx2gxTRSPm27epFs9g Njj+riqFedz0On/JQ14JMP9+PSxf1Exwbrux6km0Ra4leqfzmFWPTaBF5s3Ps/MouIMqW8lcHDHZ VzMvJf1Sv/fNjxizoldmM4Y0X33XJDy9VW118PP/k18xSWXWBnfHxr5ZJpMPs3envxkTO9LybZKK RhWnU2isRbolmZ8FDpmNfFfGb/m4/ibQpHlu0/RRivtpODAYOAq+MbPKInsJlZLtTuVZcTbzss3n Xm7uxCIe/WGXrGnT08LEFdjR4KM8K59UfXAd6nlhGrJ116i97WiY036kRa4lMWYnr8LCPBvUXwda ZF7iictru8QgmYL7MWs/xhOGL2C2+9p7r6nTcC1OdKHtw+Vx+fI6x+KTefYguJ/nzKm9kJ0i70w8 YlbZoC8iW9WldAXEWuRacmbfIKi/DrTIvFnMhhgkUXBHZqU/4olyp7kIs9JLc0be/Pi1N4Y0uW+7 PAXqI3Q5ZoPg5iDUbtxg9y4vMfRlRzTPyqJ0Ut9s/7Fdh6Y40iKvJWdegwX114EWmTePWYNBOgW3 ljr1yY7Vb32FLK+oz+sb6LHDoV/U2NOuNKTVxfeSGzvE2OXq0lf2+M9l9lhwQ5s3qFkpqkq9W+X6 CLanJ0v7/aYuyl3aLttoi4KWRMe6TjMbr7+5xlpgXoqhlgOLQToFq9fNbsRMjM/eIGTCFUrsnsL0 +Oya7IfZBZq8CrtORJ/TRfduN9trr4cIs8hDME+86YsQQgghhBBCVxK/ybGGWjOWMO3GiVmnC29U PAmzUy+e4QrMwizMwizMwuyzMvvQ6ynA7FWYnV5PITL7mPUU0sybngnPegorzrPZI6+nQJ59VGZX 6BjMwizMwizMwuxjM/scsddVa5iFWZhFCCGEEEIIIYQQQgjdX4zPrqHWjM+murH4LuLz3rud2o17 tzALszALszALszALszc8ArFf8b/Od2sekNmxUXy35kZHgDx70caRZ2EWZmEWZmEWZmEWZu93BB4u 9rpqDbMwC7MIIYQQQgghhFCK5o3Pivvh9l54c3QpVcZnx7sF1s01j3GDWcx2uVu9sBN/S+u8eF0c iq9/fYh1k9tMLDNcwGzMvAPrZpoHs7OYNeu6O33u3etyEffdW2vWq+/qM1LR4zF7aN7n3n893TyY PY/Z0qwdXwyv24Mw7LTZFjA7aV6pf3V5tnkwewazwwmsNeYPXTJvsfjP/e7Xh34LzEbM09YtMg9m z2B2UNWaLVWhT2rK9rL43Fc9zB43r2rdllnmwewiZl1XrOq126VMFXJufT1sFcbD7KR5wp4l5sHs ucwWNlXoreIwlP/+GDpk6jnMHmO28PLsDPNgdjGz8twmBmxKcbVQ5sNlQ2ts734VQ9ZQgzkwOzLP WpctMQ9mZzGrhhjz/GufqSte6az40l1bDme10rwmByCrhOWInolZz7zSfTVxvnkwO4vZ66eiB2b2 UuXDLMzCLEIIIYQQQgghhBBC6P7iNznWUGvGZ1Pd4Pe6Lto4fq8LZmEWZmEWZmEWZmH2hkeA9RTO qDXrKdztCJBnL9o48izMwizMwizMwizMwuz9jsDDxV5XrWEWZmEWIYQQQgghhBBKEeMGa6g14wbT bkz7c8mfR3kcZi95pyW2P8zCLMzCLMzC7LMy2+T1yS2xTct3m18YzH4vZr05x5GZyUlzvr1Np6Yy q9j+/rX5Zwsz/2KbItu8+ozfOVX+ZC38mNHF6g5nx4/MSJzzfcwxmP2+eVZy2J7cEtu0fLeZhZFn YXb9jsEszMIszMIszD42s88Re121hlmYhVmEEEIIIYQQQgghhNC31MRg4O4tz28yVLg0kJgPNf2+ rj1ZSFXcvyHZIw/KClOEWn3EXv6Y1dSTt1TVcu69jtUPMQoZ5lVPl+tlDWqz7Hs/I9BmG/LjQulA 4e7NVPGph3rz5z6L1t+39N3MmWwiv6KbcO921BAXsc1KG/OEZfPu3XocLMDgxsx+DImhl3822174 dVlmh2J/vPqviEhql1KQ2rrENOlsLNBoarUJZQP5x6TQ/53FbNm6fQ7rb+WeV/0SZiMNsRGzIGbi T/ylMGs5WILB3Zjt3PEQn7qXv5ZlpePMqiRSG5w+98OTpjhg1uav2YEOQnX1mKPdz/+Isk1qrPS0 6CFj9Z0615hSZd6pVX2+9uKpLK4psixW/6DWnU2vVdrMnqPMjh3LAs/0G6OeLWXWYZBMwZ3zrPZA ftSuwax6JvKP8KarxYk0ZFbsULYLAoWhYmHFoVaPmt6mLQlYJcD8+/Wg1KqVnEtS2sw+jtQ/qLXZ 6zLMho6FnhlmY56dlWfnUXAHVbaSuTh0qtemXxp9kWPyuzInmRUdNJ065FFQXzo57BtUof2JgYJQ OpB/SPR7ZAb5cHt3+gsxkeOr3iVr0/R+Bo3W39baffjNK6OvvMRcnGyIiRjG9CpbtfEPQtJ3dwIO DAaOgm/MrLJINFV27xdO6owzK09rLgN97uXmwf/hAB8yW9UpqWg7voJ3oVyqO8yz8qFssX/56SwI DnVrENQdDXvWj9Tf1doxG7kKm5Fng4boiGFM72NeTxSaOITgcSAxSKbgfszaj/HI+Usx233t7U7q xFyLM94BszFk5/QNRD/z6zBFmP7sXjxU+dM/ARwyqxqvs/Nw1lUfOUfQuP5erS/VNwgaoiOGnk19 zJcyG2KQRMEdmZX+iCfKnebSzJYi6Rhefu2NM00eMNvUsXJnMesFcrmvNieR3bu+rtBXG7E8K0sy qXyz/ccg0RQm0kH9/Vpf6hosaIiOGHpm3hjzbDGzBoN0Cm4tdRKUfbrf5lq5zC/WN9CDiLKD1NhT se5+lXqAs8jc+Kx+sIBZF8oPZOXGZyvDVKl3q/LggfBAFvb7Te1ZumxnCj2of1Brb6xrEbPxhugO 6yhmn8U9m8ms5cBikE7B6nWz+y9lnd08Usp1ibunEBuffbzjALPpil2FXSeQB+qce7ebbcJqkjCL Lq4qT7vpixBCCCGEEEIIIYRWLn77aA21Zqh22g1+F3E+P/wuIszCLMzCLMzC7HWYZd0amJ1rJOvW ZKxbQ56dlWcz1q0hz66P2RU6BrMwC7MwC7Mw+9jMPkfsddUaZmEWZhFCCCGEEEIIIYQeUYx1raHW jHXBLMzCLMziFMziGMzGtHgOd3b+/kemga/PsbQ53Nny/dfp1KN+gsmzj+0UzMIsglmYhVmYxSmE EEIIIYQQQgghhBBCCKGHkVqeHi3z7kmW/b6xSrVyu/5N1JdXMzVOLbPe5V//xfXT5uXGutasez+Y t3vrs80W+y6vTv7uqlxrW932Luts8+PVPu0wPcE8a13mzJPbdh+4dHnb66bQzCp/P/cwO9s8a10W mCf2wKUr2L57f1XMZlU/PG+l7cp5TE81z1gXmpe5R+iStsu1BArDpzBfdW1hdoZ5xrrQPNGlRdew fbPtFbPDyU0mBvLsfPO0dYF5u597PLqO7cNJTTNbFt5lBMzOMU9b55vXfYHs1WzPGj2OuPnxy11G 7P4Hs+nmaes880rRQ2Dc4PIqczXGqC9zK3EZYYYYazP2yNBBgnmVWqvJmdfIvy02IYQQQgghdHv9 H3y0r0/B5/9vAAAAAElFTkSuQmCC --_004_2691CE0099834E4A9C5044EEC662BB9D452ECEE8dfweml509mbxchi_-- From wim.henderickx@alcatel-lucent.com Tue Nov 12 09:11:55 2013 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 F11DA21E8091 for ; Tue, 12 Nov 2013 09:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.883 X-Spam-Level: X-Spam-Status: No, score=-8.883 tagged_above=-999 required=5 tests=[AWL=0.515, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] 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 KcjkpjCJGgUT for ; Tue, 12 Nov 2013 09:11:41 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 8E7AA21E82B6 for ; Tue, 12 Nov 2013 09:11:29 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rACHBLfk027884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Nov 2013 11:11:23 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rACHBJjp001831 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 18:11:21 +0100 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.146]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 12 Nov 2013 18:10:51 +0100 From: "Henderickx, Wim (Wim)" To: Lucy yong , "l2vpn@ietf.org" Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Thread-Topic: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Thread-Index: Ac7cvqYcD4BB2/82Q4+fCPK55cREGP//WkCA//ukXXCACOGNgP/+4T1AgAKgCoD//1O0EAAqIJsA Date: Tue, 12 Nov 2013 17:10:49 +0000 Message-ID: In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452ECEE8@dfweml509-mbx.china.huawei.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [135.239.27.40] Content-Type: multipart/mixed; boundary="_004_CEA81F3591EF9wimhenderickxalcatellucentcom_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 17:11:55 -0000 --_004_CEA81F3591EF9wimhenderickxalcatellucentcom_ Content-Type: multipart/alternative; boundary="_000_CEA81F3591EF9wimhenderickxalcatellucentcom_" --_000_CEA81F3591EF9wimhenderickxalcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable In-line From: Lucy yong > Date: Tuesday 12 November 2013 19:05 To: Wim Henderickx >, "l2vpn@ietf.org" > Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Wim, Please see below. From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Tuesday, November 12, 2013 1:22 AM To: Lucy yong; l2vpn@ietf.org Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement From: Lucy yong > Date: Tuesday 12 November 2013 05:11 To: Wim Henderickx >, Lucy yong >, "l2vpn@ietf.org" > Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Wim, When using a (centralized) gateway to provide external network connection f= or an L2 VN, I agree, it is necessary for the gateway to advertise its IP h= ost address and MAC to all the NVEs in the L2VN. This can be done by the RT= 2, right? NVEs also use RT2 tenant IP/MAC addresses. Thus, each NVE will kn= ow the gateway IP host and MAC address and perform the proxy ARP function, = i.e. terminate the ARP requests if the requested tenant systems (including = gateway) is not in local, and send back the requested MAC in ARP reply. Th= us, tenant system will send an L2 frame with designation tenant system or g= ateway MAC in dMAC to attached NVE, the NVE just performs the table lookup = to obtain the outer address. There is no IP routing table on NVEs because o= f the L2VN. What is the problem here? Why need to use RT5 to convey the GW= IP/MAC info? Please explain, I may miss some part in nutshell. WH> if you look to the drawings in the slides the NVE(s) can also have IP p= refixes behind them. E.g. A firewall, etc. this is what we are referring to= in the draft. See fig 1/2/3/4/5. [Lucy] OK, this is how to deal with network appliances. Do we want to treat= it as a middle box, or a tenant system that has multiple addresses? I gues= s, you want to address it as the latter. Even it is the latter, IMO, such t= enant system should not advertise the prefix in an L2 VN at all because it = serves middle box function only. If a tenant system is a gateway, it needs = to advertise itself as gateway (not the prefix from other VN). Then it will= be the same case as the following description. Does this make sense? WH2> there are real use cases as we describe which are required to be suppo= rted and hence this is what the draft is proposing and as we said before L3= VPN AFI/SAFI does not do the job. When using a gateway to provide external network connection for an L3 VN, N= VEs use their MAC address in ARP reply if VAP is L2 access interface. The L= 2 frame from a tenant system will be terminated at NVEs regardless the dest= ination tenant system is in the same VN or not. NVEs should have all the IP= routes in the VN. When NVE performs a lookup and is not able to find the m= atching one, it means the packet for the external. Since the gateway adver= tises its IP host address to NVEs as the gateway for the L3VN, NVEs will fo= rward the packets going to external to the gateway. In this case, the NVE = acts as the first-hop router, the gateway is the last-hop in the VN. You a= re right, it is necessary for a gateway to advertise its role besides its I= P address. If this is not there, should improve the protocol. Regarding the IRB capability, this is my view about IRB implementation in v= irtual overlay environment. [cid:image001.png@01CEDF94.1548F5E0] Figure shows two L2VNs, VNx and VNz. NVE1 and NVE2 are member of both VNs.= If NVE1 and NVE2 implement L3 distributed gateway functions and have the s= ame MAC address for the L3dGW. When NVEs advertise both Tenant system IP an= d MAC addresses, each NVE have all the information about tenant systems in = both VNs. NVEs still terminates the ARP requests and provide the MAC for th= e remote tenant system in the same VN. NVEs returns L3dGW addresses for the= GW ARP request or if no matching MAC are founded. Thus, only the L3dGW at= ingress NVE process inter-VN traffic forwarding, i.e. the traffic from VNx= TS on NVE1 goes through the L3dGW on NVE1 to reach the VNy TS on NVE1 or V= Ny TS on NVE2. Will this make sense to you? WH> yes but the prefix draft is orthogonal to this. So lets not mix these t= hings. The draft describing IRB is the following for which you are a co-aut= hor and we are submitting an update to show the 2 architectures supporting = this: https://tools.ietf.org/html/draft-sajassi-l2vpn-evpn-inter-subnet-forwardin= g-02 [Lucy] yes, we provide a lot of inputs on evpn overlay and interworking dra= fts. Glad to continually work on these drafts. However, these drafts are st= ill individual drafts. As we are more and more clear on the network virtual= ization overlay for the cloud applications, we need update the descriptions= (an implementation) in these drafts to make it clear. As you aware, neithe= r of us works on these drafts recently. WH2> we did in the last IETF and the updates will be reflected before the e= nd of the year Thanks, Lucy From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Monday, November 11, 2013 2:22 AM To: Lucy yong; l2vpn@ietf.org Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement In-line From: Lucy yong > Date: Monday 11 November 2013 08:43 To: Wim Henderickx >, Lucy yong >, "l2vpn@ietf.org" > Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Wim, I read the draft and still think that all the use cases work well with RT2.= Here are my views how these use cases in section 5 can be implemented wit= hout RT5 Use case 1 can be done by an L3 VN overlay, say VN10, and a gateway at DCGW= 1 and DCGW2. The gateway is used to interconnect the VN 10 and WAN. The VN10 route the traffic on SN 1 and SN2, SN3, and IP2-IP5. I call this = implementation =93L3VN plus a gateway=94 Why do you want to use an L2 VN ov= erlay here? WH> you don=92t have a GW IP in the L3VPN AFI/SAFI, so you will need to def= ine a new route to do this efficiently Use case 2 and use case 4 are about multi-homing. In the case 2, TS and NVE= are co-located; in the case 4, TS and NVE are physically separated. First= of all, IMO, when TS and NVE co-locate on the same server, multi-homed TS = is not necessary. The use case 4 is just the use case 1 with multi-homing. = Thus, it can be implemented by =93L3VN plus a gateway=94 w/ VRRP. WH> there is no VRRP in these cases since the appliance is a bump in the wi= re for use case 4 so they don=92t even speak IP, so you have an undefined N= H, which is also not evadable in the L3VPn AFI/SAFI and there is no ESI NH = possible In your use case 3, EVI10 should be replaced by an L3 overlay. The VRF on t= he NVE1 acts as the L3 distributed gateway for the EVN1 and EVN2. The VRF = on the NVE2 acts as the L3 distributed gateway for the EVN2 and EVN3. The V= RFs on DGW1 and DGW2 act as the gateway between the L3 overlay and WAN. If = NVE1 and NVE2 use RT2 advertises TS IP/MAC, NVE1 will know IP subnet/prefi= x associating to EVN1 and EVN2, and IP subnet/prefix associating to the L3 = overlay. When NVE1 receives a packet from IP1 and the packet has the destin= ation to SN1, the packet dMAC address will be the MAC address for the distr= ibuted gateway that is the same for all the NVEs. When NVE sees this addres= s, it will perform the VRF table lookup by using the destination IP addr on= the packet, which results the IP addr is associated to the EVN2, then NVE = performs the table look-up in EVI-2 that has both IP/MAC to outer (or VAP) = address mapping, so it will replace the dMAC addr on the packet with the re= al destination MAC addr and send to the VAP that SN1 associated to. When N= VE1 receives a packet from IP1 and the packet has the destination in the WA= N network, the dMAC on the packet is also the MAC address for the distribut= ed gateway. So NVE will perform the VRF table look-up by using the destinat= ion IP on the packet, which results to the outer IP address on one of DGWs,= say DGW1. NVE1 adds the L3 VN ID and the outer header on the packet prior = sending it out. When DGW1 receives the packet, it removes the tunnel header= and uses the L3 VN ID on the packet to reach the vGW on DGW1. The vGW perf= orm the packet treatment before sending to the WAN. WH> it depends how you want to do this, you can either go route from ingres= s w/o IP lookup on ingress or do a lookup on egress. Both options are possi= ble and required for some HW in the market. EVPN supports both already, wha= t this draft is doing is how prefixes should be used in this environment L2/L3 NVE service type described in draft-yong-nv03-nve is for this use cas= e. When L2/L3 NVE service type is used, NVE maintains both TS IP/MAC addres= ses but may advertise both IP/MAC addresses or one of the address depending= on the remote NVE service type. When L2 NVE service type is used, NVE just= maintains TS MAC addresses. Both cases can be implemented by EVPN solution= . WH> draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 describes the IRB c= ase There are places we need to use L2 VNs. For example, all TSes in a VN have = the same IP address but different MAC addresses; there is broadcast/multic= ast traffic in a VN; non-IP packet. However, we don=92t want to make a comp= lex EVPN solution to solve the case that L3VN can easily address. WH> see draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 it describes it= all. As I said not all use case can be done with L3VPN and this is require= d. Regards, Lucy From: HenderickxHi Win,, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.co= m] Sent: Friday, November 08, 2013 2:18 PM To: Lucy yong; l2vpn@ietf.org Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Lucy, did you read the draft and is explained in section 6. Show an example on how you do the scenario=92s with RT2 and you will see wh= y this is less efficient/scalable + does not support all scenario=92s in th= e draft like ESI NH. E-VPN distributes host routes using RT-2: (IP) + MAC and these can be an in= terface e.g. And prefixes can exists behind them. From: Lucy yong > Date: Friday 8 November 2013 22:10 To: "l2vpn@ietf.org" > Subject: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Hi Authors, I am not convinced if RT 5 is necessary for the use cases you specified in = the draft (or presentation). IMO: RT2 is sufficient to support all the case= s. There is a draft-yong-nvo3-nve, which covers all the L2 overlay cases, whic= h can be implemented by EVPN with RT2. One question, why EVPN service allow to VAP being an IP interface? Thanks, Lucy --_000_CEA81F3591EF9wimhenderickxalcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4058C842273C3B45AED8E7267E59E7D1@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
In-line

From: Lucy yong <lucy.yong@huawei.com>
Date: Tuesday 12 November 2013 19:0= 5
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com<= /a>>, "l2vpn@ietf.org" &= lt;l2vpn@ietf.org>
Subject: RE: comment on draft-rabad= an-l2vpn-evpn-prefix-advertisement

Wim, Please see below.=

 

From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]
Sent: Tuesday, November 12, 2013 1:22 AM
To: Lucy yong; l2vpn@ietf.org<= br> Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t

 

&n= bsp;

&n= bsp;

From: Lucy yong <lucy.yong@huawei.com>
Date: Tuesday 12 November 2013 05:11
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com>, Lucy yong <lucy.yong@huawei.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t

&n= bsp;

Wim,

 

When using a (centrali= zed) gateway to provide external network connection for an L2 VN, I agree, = it is necessary for the gateway to advertise its IP host address and MAC to= all the NVEs in the L2VN. This can be done by the RT2, right? NVEs also use RT2 tenant IP/MAC addresses. Thus= , each NVE will know the gateway IP host and MAC address and perform the pr= oxy ARP function, i.e. terminate the ARP requests if the requested tenant s= ystems (including gateway) is not in local, and send back the requested  MAC in ARP reply. Thus, tenant= system will send an L2 frame with designation tenant system or gateway MAC= in dMAC to attached NVE, the NVE just performs the table lookup to obtain = the outer address. There is no IP routing table on NVEs because of the L2VN.  What is the problem here? Why nee= d to use RT5 to convey the GW IP/MAC info?  Please explain, I may miss= some part in nutshell.

&n= bsp;

WH> = if you look to the drawings in the slides the NVE(s) can also have IP prefi= xes behind them. E.g. A firewall, etc. this is what we are referring to in = the draft.

See fig= 1/2/3/4/5.

[Lucy] OK, this = is how to deal with network appliances. Do we want to treat it as a middle = box, or a tenant system that has multiple addresses? I guess, you want to a= ddress it as the latter. Even it is the latter, IMO, such tenant system should not advertise the prefix in an = L2 VN at all because it serves middle box function only. If a tenant system= is a gateway, it needs to advertise itself as gateway (not the prefix from= other VN). Then it will be the same case as the following description. Does this make sense?

WH2> there are real use cases as we describe which are required to = be supported and hence this is what the draft is proposing and as we said b= efore L3VPN AFI/SAFI does not do the job. 

 

When using a gateway t= o provide external network connection for an L3 VN, NVEs use their MAC addr= ess in ARP reply if VAP is L2 access interface. The L2 frame from a tenant = system will be terminated at NVEs regardless the destination tenant system is in the same VN or not. NVEs should have a= ll the IP routes in the VN. When NVE performs a lookup and is not able to f= ind the matching one, it means the packet for the external.  Since the= gateway advertises its IP host address to NVEs as the gateway for the L3VN, NVEs will forward the packets going t= o external to the gateway.  In this case, the NVE acts as the first-ho= p router, the gateway is the last-hop in the VN.  You are right, it is= necessary for a gateway to advertise its role besides its IP address.  If this is not there, should improve th= e protocol.

 

Regarding the IRB capa= bility, this is my view about IRB implementation in virtual overlay environ= ment.

 

 

Figure shows two L2VNs= , VNx and VNz.  NVE1 and NVE2 are member of both VNs. If NVE1 and NVE2= implement L3 distributed gateway functions and have the same MAC address f= or the L3dGW. When NVEs advertise both Tenant system IP and MAC addresses, each NVE have all the information about tenan= t systems in both VNs. NVEs still terminates the ARP requests and provide t= he MAC for the remote tenant system in the same VN. NVEs returns L3dGW addr= esses for the GW ARP request or if no matching MAC are founded.  Thus, only the L3dGW at ingress NVE = process inter-VN traffic forwarding, i.e. the traffic from VNx TS on NVE1 g= oes through the L3dGW on NVE1 to reach the VNy TS on NVE1 or VNy TS on NVE2= .  Will this make sense to you?

&n= bsp;

WH> = yes but the prefix draft is orthogonal to this. So lets not mix these thing= s. The draft describing IRB is the following for which you are a co-author = and we are submitting an update to show the 2 architectures supporting this:

&n= bsp;

https://tools.ietf.org/html/draft-sajassi-l2vpn-evpn-inter-subnet= -forwarding-02

[Lucy] yes, we p= rovide a lot of inputs on evpn overlay and interworking drafts. Glad to con= tinually work on these drafts. However, these drafts are still individual d= rafts. As we are more and more clear on the network virtualization overlay for the cloud applications, we need = update the descriptions (an implementation) in these drafts to make it clea= r. As you aware, neither of us works on these drafts recently.

WH2> we did in the last IETF and the updates will be reflected befo= re the end of the year

 =

 

Thanks,

Lucy

 

 

 

 

 

 

 

From: Henderickx, Wim (Wim) = [mailto:wim.henderickx= @alcatel-lucent.com]
Sent: Monday, November 11, 2013 2:22 AM
To: Lucy yong; l2vpn@ietf.org<= br> Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t

 =

In-line=

 <= /span>

From: Lucy yong <lucy.yong@huawei.com>
Date: Monday 11 November 2013 08:43
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com>, Lucy yong <lucy.yong@huawei.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t

 <= /span>

Wim,

 

I read the draft and s= till think that all the use cases work well with RT2.  Here are my vie= ws how these use cases in section 5 can be implemented without RT5

 

Use case 1 can be done= by an L3 VN overlay, say VN10, and a gateway at DCGW1 and DCGW2. The gatew= ay is used to interconnect the VN 10 and WAN.

The VN10 route the tra= ffic on SN 1 and SN2, SN3, and IP2-IP5.  I call this implementation = =93L3VN plus a gateway=94 Why do you want to use an L2 VN overlay here?

 <= /span>

WH> = you don=92t have a GW IP in the L3VPN AFI/SAFI, so you will need to define = a new route to do this efficiently<= /o:p>

 

Use case 2 and use cas= e 4 are about multi-homing. In the case 2, TS and NVE are co-located; in th= e case 4, TS and NVE are physically separated.  First of all, IMO, whe= n TS and NVE co-locate on the same server, multi-homed TS is not necessary. The use case 4 is just the use case 1 wit= h multi-homing. Thus, it can be implemented by =93L3VN plus a gateway=94 w/= VRRP.  

 <= /span>

WH> = there is no VRRP in these cases since the appliance is a bump in the wire f= or use case 4 so they don=92t even speak IP, so you have an undefined NH, w= hich is also not evadable in the L3VPn AFI/SAFI and there is no ESI NH possible

 

In your use case 3, EV= I10 should be replaced by an L3 overlay. The VRF on the NVE1 acts as the L3= distributed gateway for the EVN1 and EVN2.  The VRF on the NVE2 acts = as the L3 distributed gateway for the EVN2 and EVN3. The VRFs on DGW1 and DGW2 act as the gateway between the L3 over= lay and WAN. If NVE1 and NVE2 use RT2 advertises TS IP/MAC,  NVE1 will= know IP subnet/prefix associating to EVN1 and EVN2, and IP subnet/prefix a= ssociating to the L3 overlay. When NVE1 receives a packet from IP1 and the packet has the destination to SN1, the = packet dMAC address will be the MAC address for the distributed gateway tha= t is the same for all the NVEs. When NVE sees this address, it will perform= the VRF table lookup by using the destination IP addr on the packet, which results the IP addr is associated= to the EVN2, then NVE performs the table look-up in EVI-2 that has both IP= /MAC to outer (or VAP) address mapping, so it will replace the dMAC addr on= the packet with the real destination MAC addr and send to the VAP that SN1 associated to.  When NVE1 recei= ves a packet from IP1 and the packet has the destination in the WAN network= , the dMAC on the packet is also the MAC address for the distributed gatewa= y. So NVE will perform the VRF table look-up by using the destination IP on the packet, which results to the ou= ter IP address on one of DGWs, say DGW1. NVE1 adds the L3 VN ID and the out= er header on the packet prior sending it out. When DGW1 receives the packet= , it removes the tunnel header and uses the L3 VN ID on the packet to reach the vGW on DGW1. The vGW perform = the packet treatment before sending to the WAN.

 <= /span>

WH> = it depends how you want to do this, you can either go route from ingress w/= o IP lookup on ingress or do a lookup on egress. Both options are possible = and required for some HW in the market. EVPN supports both already, what this draft is doing is how prefixes shoul= d be used in this environment=

 

L2/L3 NVE service type= described in draft-yong-nv03-nve is for this use case. When L2/L3 NVE serv= ice type is used, NVE maintains both TS IP/MAC addresses but may advertise = both IP/MAC addresses or one of the address depending on the remote NVE service type. When L2 NVE service type= is used, NVE just maintains TS MAC addresses. Both cases can be implemente= d by EVPN solution.

 <= /span>

WH>&= nbsp;draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 describes the IRB = case

 

There are places we ne= ed to use L2 VNs. For example, all TSes in a VN have the same IP address bu= t different MAC addresses;  there is broadcast/multicast traffic in a = VN; non-IP packet. However, we don=92t want to make a complex EVPN solution to solve the case that L3VN can easily add= ress.  

 <= /span>

WH> = see draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 it describes i= t all. As I said not all use case can be done with L3VPN and this is requir= ed.

 

Regards,

Lucy

 

 

 

 

 

 

 

From: HenderickxHi Win,, Wim= (Wim) [mailto:wim.hen= derickx@alcatel-lucent.com]
Sent: Friday, November 08, 2013 2:18 PM
To: Lucy yong; l2vpn@ietf.org<= br> Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t

 =

Lucy, d= id you read the draft and is explained in section 6.

Show an= example on how you do the scenario=92s with RT2 and you will see why this = is less efficient/scalable + does not support all scenario=92s in the d= raft like ESI NH.

 <= /span>

E-VPN d= istributes host routes using RT-2: (IP) + MAC and these can be an inter= face e.g. And prefixes can exists behind them.

 <= /span>

From: Lucy yong <lucy.yong@huawei.com>
Date: Friday 8 November 2013 22:10
To: "l2vpn@ietf.org"= <l2vpn@ietf.org>
Subject: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement

 <= /span>

Hi Authors,

 =

I am not convinced if RT= 5 is necessary for the use cases you specified in the draft (or presentati= on). IMO: RT2 is sufficient to support all the cases.

There is a draft-yong-nv= o3-nve, which covers all the L2 overlay cases, which can be implemented by = EVPN with RT2.

 =

One question, why EVPN s= ervice allow to VAP being an IP interface?

 =

Thanks,

Lucy

--_000_CEA81F3591EF9wimhenderickxalcatellucentcom_-- --_004_CEA81F3591EF9wimhenderickxalcatellucentcom_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: attachment; filename="image001.png"; size=3555; creation-date="Tue, 12 Nov 2013 17:10:49 GMT"; modification-date="Tue, 12 Nov 2013 17:10:49 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAArMAAADaCAMAAACCXTqSAAAAAXNSR0ICQMB9xQAAAGlQTFRFAAAA AAAAAwYLDQsKBAAACwYDAAAECgsNCgQAAAQKCAMAAAMIDQoIAwAADQgECAYDBAgNBAADCAoNAwAE AwMIBAAEBAQACAMDAAADAwADDQgKAwMDBAQEBAYICAgIAwQEBAQDCAYEAwQKoNCZ7QAAAAF0Uk5T AEDm2GYAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAAZdEVYdFNvZnR3YXJlAE1pY3Jvc29mdCBPZmZp Y2V/7TVxAAAM4UlEQVR42u2dC3uiOBuGAaXlYFnWdradnZ3v9P9/5EfOiUQMeCp6P9dcU0XMmzzc voQQTZYhhBBCCCGEEEIIfTOVxXPGXlet1+kUzMIsglmYhVmYxalra7PNpV5eK/WgzuyDLLIpsm3x /i72yh3L0sxYvv86nXrUTzB59rGdglmYRTALszALsziFEEIIIYQQQgghhBBKF+Oza6g147PTblzA n8QiHpDZK5kHszALszALszD7rMw2coLp9JbYpuW7zS8MZr8Xs9784qVzvmdMUVax/fJr88+Wb/7F NkW2efUZv3Oq/Mla+DGP8zNpXtqc72Pmwez3zbPyiLYnt8Q2Ld9tZmHkWZhdv2MwC7MwC7MwC7OP zexzxF5XrWEWZmEWIYQQQgghhBBCCCH0LXU4GLh7y/O7jQ8uDi6mSE2/sWtPlVEVd6j/E4zFClOE Wn2cXv6Y1eaIQ3JTJwvtZYB+KLjQpb/q6XK9DFyr3eR+823fbI9QEwnuqxlHXHD0N3/uYy0KvH0f T6hsJidZqpCj+rtAbVYuMC/BUI+DBRjcmNmPIR/08s9m2wu/LsLsUNqPV/dUFG9eKeshSGvT0PES TsaujwM1Du4OTqH/O4/Zsj3WIqdYoq36hJCj+ttA2RLzUpi1HCzB4G7MqpOdsmn41L38lZCMTjOr Ml+dWXg+98PTpghtHz7bX/shqsxC58+RiQQPOdr93IuMlfcqOVZ6ovSQuvouD2e6ygxU6yqKZ6q4 poi3yG9JF0mqVcocmVH9baBsiXmzmHUYJFNw5zyrLFMftYsxax6LHCMs6Wpx2gxTRSPm27epFs9g Njj+riqFedz0On/JQ14JMP9+PSxf1Exwbrux6km0Ra4leqfzmFWPTaBF5s3Ps/MouIMqW8lcHDHZ VzMvJf1Sv/fNjxizoldmM4Y0X33XJDy9VW118PP/k18xSWXWBnfHxr5ZJpMPs3envxkTO9LybZKK RhWnU2isRbolmZ8FDpmNfFfGb/m4/ibQpHlu0/RRivtpODAYOAq+MbPKInsJlZLtTuVZcTbzss3n Xm7uxCIe/WGXrGnT08LEFdjR4KM8K59UfXAd6nlhGrJ116i97WiY036kRa4lMWYnr8LCPBvUXwda ZF7iictru8QgmYL7MWs/xhOGL2C2+9p7r6nTcC1OdKHtw+Vx+fI6x+KTefYguJ/nzKm9kJ0i70w8 YlbZoC8iW9WldAXEWuRacmbfIKi/DrTIvFnMhhgkUXBHZqU/4olyp7kIs9JLc0be/Pi1N4Y0uW+7 PAXqI3Q5ZoPg5iDUbtxg9y4vMfRlRzTPyqJ0Ut9s/7Fdh6Y40iKvJWdegwX114EWmTePWYNBOgW3 ljr1yY7Vb32FLK+oz+sb6LHDoV/U2NOuNKTVxfeSGzvE2OXq0lf2+M9l9lhwQ5s3qFkpqkq9W+X6 CLanJ0v7/aYuyl3aLttoi4KWRMe6TjMbr7+5xlpgXoqhlgOLQToFq9fNbsRMjM/eIGTCFUrsnsL0 +Oya7IfZBZq8CrtORJ/TRfduN9trr4cIs8hDME+86YsQQgghhBBCVxK/ybGGWjOWMO3GiVmnC29U PAmzUy+e4QrMwizMwizMwuyzMvvQ6ynA7FWYnV5PITL7mPUU0sybngnPegorzrPZI6+nQJ59VGZX 6BjMwizMwizMwuxjM/scsddVa5iFWZhFCCGEEEIIIYQQQgjdX4zPrqHWjM+murH4LuLz3rud2o17 tzALszALszALszALszc8ArFf8b/Od2sekNmxUXy35kZHgDx70caRZ2EWZmEWZmEWZmEWZu93BB4u 9rpqDbMwC7MIIYQQQgghhFCK5o3Pivvh9l54c3QpVcZnx7sF1s01j3GDWcx2uVu9sBN/S+u8eF0c iq9/fYh1k9tMLDNcwGzMvAPrZpoHs7OYNeu6O33u3etyEffdW2vWq+/qM1LR4zF7aN7n3n893TyY PY/Z0qwdXwyv24Mw7LTZFjA7aV6pf3V5tnkwewazwwmsNeYPXTJvsfjP/e7Xh34LzEbM09YtMg9m z2B2UNWaLVWhT2rK9rL43Fc9zB43r2rdllnmwewiZl1XrOq126VMFXJufT1sFcbD7KR5wp4l5sHs ucwWNlXoreIwlP/+GDpk6jnMHmO28PLsDPNgdjGz8twmBmxKcbVQ5sNlQ2ts734VQ9ZQgzkwOzLP WpctMQ9mZzGrhhjz/GufqSte6az40l1bDme10rwmByCrhOWInolZz7zSfTVxvnkwO4vZ66eiB2b2 UuXDLMzCLEIIIYQQQgghhBBC6P7iNznWUGvGZ1Pd4Pe6Lto4fq8LZmEWZmEWZmEWZmH2hkeA9RTO qDXrKdztCJBnL9o48izMwizMwizMwizMwuz9jsDDxV5XrWEWZmEWIYQQQgghhBBKEeMGa6g14wbT bkz7c8mfR3kcZi95pyW2P8zCLMzCLMzC7LMy2+T1yS2xTct3m18YzH4vZr05x5GZyUlzvr1Np6Yy q9j+/rX5Zwsz/2KbItu8+ozfOVX+ZC38mNHF6g5nx4/MSJzzfcwxmP2+eVZy2J7cEtu0fLeZhZFn YXb9jsEszMIszMIszD42s88Re121hlmYhVmEEEIIIYQQQgghhNC31MRg4O4tz28yVLg0kJgPNf2+ rj1ZSFXcvyHZIw/KClOEWn3EXv6Y1dSTt1TVcu69jtUPMQoZ5lVPl+tlDWqz7Hs/I9BmG/LjQulA 4e7NVPGph3rz5z6L1t+39N3MmWwiv6KbcO921BAXsc1KG/OEZfPu3XocLMDgxsx+DImhl3822174 dVlmh2J/vPqviEhql1KQ2rrENOlsLNBoarUJZQP5x6TQ/53FbNm6fQ7rb+WeV/0SZiMNsRGzIGbi T/ylMGs5WILB3Zjt3PEQn7qXv5ZlpePMqiRSG5w+98OTpjhg1uav2YEOQnX1mKPdz/+Isk1qrPS0 6CFj9Z0615hSZd6pVX2+9uKpLK4psixW/6DWnU2vVdrMnqPMjh3LAs/0G6OeLWXWYZBMwZ3zrPZA ftSuwax6JvKP8KarxYk0ZFbsULYLAoWhYmHFoVaPmt6mLQlYJcD8+/Wg1KqVnEtS2sw+jtQ/qLXZ 6zLMho6FnhlmY56dlWfnUXAHVbaSuTh0qtemXxp9kWPyuzInmRUdNJ065FFQXzo57BtUof2JgYJQ OpB/SPR7ZAb5cHt3+gsxkeOr3iVr0/R+Bo3W39baffjNK6OvvMRcnGyIiRjG9CpbtfEPQtJ3dwIO DAaOgm/MrLJINFV27xdO6owzK09rLgN97uXmwf/hAB8yW9UpqWg7voJ3oVyqO8yz8qFssX/56SwI DnVrENQdDXvWj9Tf1doxG7kKm5Fng4boiGFM72NeTxSaOITgcSAxSKbgfszaj/HI+Usx233t7U7q xFyLM94BszFk5/QNRD/z6zBFmP7sXjxU+dM/ARwyqxqvs/Nw1lUfOUfQuP5erS/VNwgaoiOGnk19 zJcyG2KQRMEdmZX+iCfKnebSzJYi6Rhefu2NM00eMNvUsXJnMesFcrmvNieR3bu+rtBXG7E8K0sy qXyz/ccg0RQm0kH9/Vpf6hosaIiOGHpm3hjzbDGzBoN0Cm4tdRKUfbrf5lq5zC/WN9CDiLKD1NhT se5+lXqAs8jc+Kx+sIBZF8oPZOXGZyvDVKl3q/LggfBAFvb7Te1ZumxnCj2of1Brb6xrEbPxhugO 6yhmn8U9m8ms5cBikE7B6nWz+y9lnd08Usp1ibunEBuffbzjALPpil2FXSeQB+qce7ebbcJqkjCL Lq4qT7vpixBCCCGEEEIIIYRWLn77aA21Zqh22g1+F3E+P/wuIszCLMzCLMzC7HWYZd0amJ1rJOvW ZKxbQ56dlWcz1q0hz66P2RU6BrMwC7MwC7Mw+9jMPkfsddUaZmEWZhFCCCGEEEIIIYQeUYx1raHW jHXBLMzCLMziFMziGMzGtHgOd3b+/kemga/PsbQ53Nny/dfp1KN+gsmzj+0UzMIsglmYhVmYxSmE EEIIIYQQQgghhBBCCKGHkVqeHi3z7kmW/b6xSrVyu/5N1JdXMzVOLbPe5V//xfXT5uXGutasez+Y t3vrs80W+y6vTv7uqlxrW932Luts8+PVPu0wPcE8a13mzJPbdh+4dHnb66bQzCp/P/cwO9s8a10W mCf2wKUr2L57f1XMZlU/PG+l7cp5TE81z1gXmpe5R+iStsu1BArDpzBfdW1hdoZ5xrrQPNGlRdew fbPtFbPDyU0mBvLsfPO0dYF5u597PLqO7cNJTTNbFt5lBMzOMU9b55vXfYHs1WzPGj2OuPnxy11G 7P4Hs+nmaes880rRQ2Dc4PIqczXGqC9zK3EZYYYYazP2yNBBgnmVWqvJmdfIvy02IYQQQgghdHv9 H3y0r0/B5/9vAAAAAElFTkSuQmCC --_004_CEA81F3591EF9wimhenderickxalcatellucentcom_-- From lucy.yong@huawei.com Tue Nov 12 10:14:55 2013 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 B9B5F11E810A for ; Tue, 12 Nov 2013 10:14:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.039 X-Spam-Level: X-Spam-Status: No, score=-5.039 tagged_above=-999 required=5 tests=[AWL=-0.641, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, 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 JhTG4n74ZlAH for ; Tue, 12 Nov 2013 10:14:48 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9A37D21F9D52 for ; Tue, 12 Nov 2013 10:14:47 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id AXU77102; Tue, 12 Nov 2013 18:14:46 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 18:14:31 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 18:14:45 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0158.001; Tue, 12 Nov 2013 10:14:41 -0800 From: Lucy yong To: "Henderickx, Wim (Wim)" , "l2vpn@ietf.org" Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Thread-Topic: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Thread-Index: Ac7cvqYcD4BB2/82Q4+fCPK55cREGP//WkCA//ukXXCACOGNgP/+4T1AgAKgCoD//1O0EAAqIJsA///eghA= Date: Tue, 12 Nov 2013 18:14:39 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452ECFCD@dfweml509-mbx.china.huawei.com> References: <2691CE0099834E4A9C5044EEC662BB9D452ECEE8@dfweml509-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.147] Content-Type: multipart/related; boundary="_004_2691CE0099834E4A9C5044EEC662BB9D452ECFCDdfweml509mbxchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 18:14:55 -0000 --_004_2691CE0099834E4A9C5044EEC662BB9D452ECFCDdfweml509mbxchi_ Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D452ECFCDdfweml509mbxchi_" --_000_2691CE0099834E4A9C5044EEC662BB9D452ECFCDdfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Wim, Please clarify your real use case. In your real use case, when using a fir= ewall, does it use with a gateway together or not. If not, the firewall is = a just middle box (wired) and does not participate in the L2VN routing. If = it works with the gateway, only gateway participates in the L2VN, not the = firewall. The configuration between gateway and firewall is local, not rela= ted to the L2VN. Lucy From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Tuesday, November 12, 2013 11:11 AM To: Lucy yong; l2vpn@ietf.org Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement In-line From: Lucy yong > Date: Tuesday 12 November 2013 19:05 To: Wim Henderickx >, "l2vpn@ietf.org" > Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Wim, Please see below. From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Tuesday, November 12, 2013 1:22 AM To: Lucy yong; l2vpn@ietf.org Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement From: Lucy yong > Date: Tuesday 12 November 2013 05:11 To: Wim Henderickx >, Lucy yong >, "l2vpn@ietf.org" > Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Wim, When using a (centralized) gateway to provide external network connection f= or an L2 VN, I agree, it is necessary for the gateway to advertise its IP h= ost address and MAC to all the NVEs in the L2VN. This can be done by the RT= 2, right? NVEs also use RT2 tenant IP/MAC addresses. Thus, each NVE will kn= ow the gateway IP host and MAC address and perform the proxy ARP function, = i.e. terminate the ARP requests if the requested tenant systems (including = gateway) is not in local, and send back the requested MAC in ARP reply. Th= us, tenant system will send an L2 frame with designation tenant system or g= ateway MAC in dMAC to attached NVE, the NVE just performs the table lookup = to obtain the outer address. There is no IP routing table on NVEs because o= f the L2VN. What is the problem here? Why need to use RT5 to convey the GW= IP/MAC info? Please explain, I may miss some part in nutshell. WH> if you look to the drawings in the slides the NVE(s) can also have IP p= refixes behind them. E.g. A firewall, etc. this is what we are referring to= in the draft. See fig 1/2/3/4/5. [Lucy] OK, this is how to deal with network appliances. Do we want to treat= it as a middle box, or a tenant system that has multiple addresses? I gues= s, you want to address it as the latter. Even it is the latter, IMO, such t= enant system should not advertise the prefix in an L2 VN at all because it = serves middle box function only. If a tenant system is a gateway, it needs = to advertise itself as gateway (not the prefix from other VN). Then it will= be the same case as the following description. Does this make sense? WH2> there are real use cases as we describe which are required to be suppo= rted and hence this is what the draft is proposing and as we said before L3= VPN AFI/SAFI does not do the job. When using a gateway to provide external network connection for an L3 VN, N= VEs use their MAC address in ARP reply if VAP is L2 access interface. The L= 2 frame from a tenant system will be terminated at NVEs regardless the dest= ination tenant system is in the same VN or not. NVEs should have all the IP= routes in the VN. When NVE performs a lookup and is not able to find the m= atching one, it means the packet for the external. Since the gateway adver= tises its IP host address to NVEs as the gateway for the L3VN, NVEs will fo= rward the packets going to external to the gateway. In this case, the NVE = acts as the first-hop router, the gateway is the last-hop in the VN. You a= re right, it is necessary for a gateway to advertise its role besides its I= P address. If this is not there, should improve the protocol. Regarding the IRB capability, this is my view about IRB implementation in v= irtual overlay environment. [cid:image001.png@01CEDFA0.E94DBB30] Figure shows two L2VNs, VNx and VNz. NVE1 and NVE2 are member of both VNs.= If NVE1 and NVE2 implement L3 distributed gateway functions and have the s= ame MAC address for the L3dGW. When NVEs advertise both Tenant system IP an= d MAC addresses, each NVE have all the information about tenant systems in = both VNs. NVEs still terminates the ARP requests and provide the MAC for th= e remote tenant system in the same VN. NVEs returns L3dGW addresses for the= GW ARP request or if no matching MAC are founded. Thus, only the L3dGW at= ingress NVE process inter-VN traffic forwarding, i.e. the traffic from VNx= TS on NVE1 goes through the L3dGW on NVE1 to reach the VNy TS on NVE1 or V= Ny TS on NVE2. Will this make sense to you? WH> yes but the prefix draft is orthogonal to this. So lets not mix these t= hings. The draft describing IRB is the following for which you are a co-aut= hor and we are submitting an update to show the 2 architectures supporting = this: https://tools.ietf.org/html/draft-sajassi-l2vpn-evpn-inter-subnet-forwardin= g-02 [Lucy] yes, we provide a lot of inputs on evpn overlay and interworking dra= fts. Glad to continually work on these drafts. However, these drafts are st= ill individual drafts. As we are more and more clear on the network virtual= ization overlay for the cloud applications, we need update the descriptions= (an implementation) in these drafts to make it clear. As you aware, neithe= r of us works on these drafts recently. WH2> we did in the last IETF and the updates will be reflected before the e= nd of the year Thanks, Lucy From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Monday, November 11, 2013 2:22 AM To: Lucy yong; l2vpn@ietf.org Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement In-line From: Lucy yong > Date: Monday 11 November 2013 08:43 To: Wim Henderickx >, Lucy yong >, "l2vpn@ietf.org" > Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Wim, I read the draft and still think that all the use cases work well with RT2.= Here are my views how these use cases in section 5 can be implemented wit= hout RT5 Use case 1 can be done by an L3 VN overlay, say VN10, and a gateway at DCGW= 1 and DCGW2. The gateway is used to interconnect the VN 10 and WAN. The VN10 route the traffic on SN 1 and SN2, SN3, and IP2-IP5. I call this = implementation "L3VN plus a gateway" Why do you want to use an L2 VN overla= y here? WH> you don't have a GW IP in the L3VPN AFI/SAFI, so you will need to defin= e a new route to do this efficiently Use case 2 and use case 4 are about multi-homing. In the case 2, TS and NVE= are co-located; in the case 4, TS and NVE are physically separated. First= of all, IMO, when TS and NVE co-locate on the same server, multi-homed TS = is not necessary. The use case 4 is just the use case 1 with multi-homing. = Thus, it can be implemented by "L3VN plus a gateway" w/ VRRP. WH> there is no VRRP in these cases since the appliance is a bump in the wi= re for use case 4 so they don't even speak IP, so you have an undefined NH,= which is also not evadable in the L3VPn AFI/SAFI and there is no ESI NH po= ssible In your use case 3, EVI10 should be replaced by an L3 overlay. The VRF on t= he NVE1 acts as the L3 distributed gateway for the EVN1 and EVN2. The VRF = on the NVE2 acts as the L3 distributed gateway for the EVN2 and EVN3. The V= RFs on DGW1 and DGW2 act as the gateway between the L3 overlay and WAN. If = NVE1 and NVE2 use RT2 advertises TS IP/MAC, NVE1 will know IP subnet/prefi= x associating to EVN1 and EVN2, and IP subnet/prefix associating to the L3 = overlay. When NVE1 receives a packet from IP1 and the packet has the destin= ation to SN1, the packet dMAC address will be the MAC address for the distr= ibuted gateway that is the same for all the NVEs. When NVE sees this addres= s, it will perform the VRF table lookup by using the destination IP addr on= the packet, which results the IP addr is associated to the EVN2, then NVE = performs the table look-up in EVI-2 that has both IP/MAC to outer (or VAP) = address mapping, so it will replace the dMAC addr on the packet with the re= al destination MAC addr and send to the VAP that SN1 associated to. When N= VE1 receives a packet from IP1 and the packet has the destination in the WA= N network, the dMAC on the packet is also the MAC address for the distribut= ed gateway. So NVE will perform the VRF table look-up by using the destinat= ion IP on the packet, which results to the outer IP address on one of DGWs,= say DGW1. NVE1 adds the L3 VN ID and the outer header on the packet prior = sending it out. When DGW1 receives the packet, it removes the tunnel header= and uses the L3 VN ID on the packet to reach the vGW on DGW1. The vGW perf= orm the packet treatment before sending to the WAN. WH> it depends how you want to do this, you can either go route from ingres= s w/o IP lookup on ingress or do a lookup on egress. Both options are possi= ble and required for some HW in the market. EVPN supports both already, wha= t this draft is doing is how prefixes should be used in this environment L2/L3 NVE service type described in draft-yong-nv03-nve is for this use cas= e. When L2/L3 NVE service type is used, NVE maintains both TS IP/MAC addres= ses but may advertise both IP/MAC addresses or one of the address depending= on the remote NVE service type. When L2 NVE service type is used, NVE just= maintains TS MAC addresses. Both cases can be implemented by EVPN solution= . WH> draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 describes the IRB c= ase There are places we need to use L2 VNs. For example, all TSes in a VN have = the same IP address but different MAC addresses; there is broadcast/multic= ast traffic in a VN; non-IP packet. However, we don't want to make a comple= x EVPN solution to solve the case that L3VN can easily address. WH> see draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 it describes it= all. As I said not all use case can be done with L3VPN and this is require= d. Regards, Lucy From: HenderickxHi Win,, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.co= m] Sent: Friday, November 08, 2013 2:18 PM To: Lucy yong; l2vpn@ietf.org Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Lucy, did you read the draft and is explained in section 6. Show an example on how you do the scenario's with RT2 and you will see why = this is less efficient/scalable + does not support all scenario's in the dr= aft like ESI NH. E-VPN distributes host routes using RT-2: (IP) + MAC and these can be an in= terface e.g. And prefixes can exists behind them. From: Lucy yong > Date: Friday 8 November 2013 22:10 To: "l2vpn@ietf.org" > Subject: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Hi Authors, I am not convinced if RT 5 is necessary for the use cases you specified in = the draft (or presentation). IMO: RT2 is sufficient to support all the case= s. There is a draft-yong-nvo3-nve, which covers all the L2 overlay cases, whic= h can be implemented by EVPN with RT2. One question, why EVPN service allow to VAP being an IP interface? Thanks, Lucy --_000_2691CE0099834E4A9C5044EEC662BB9D452ECFCDdfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Wim,=

 

Please clarify your re= al use case.  In your real use case, when using a firewall, does it us= e with a gateway together or not. If not, the firewall is a just middle box= (wired) and does not participate in the L2VN routing. If it works with the gateway, only gateway participates in t= he L2VN,  not the firewall. The configuration between gateway and fire= wall is local, not related to the L2VN.

 

Lucy=

 

From: Henderic= kx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]
Sent: Tuesday, November 12, 2013 11:11 AM
To: Lucy yong; l2vpn@ietf.org
Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t

 

In-line=

&n= bsp;

From: Lucy yong <lucy.yong@huawei.com>
Date: Tuesday 12 November 2013 19:05
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t

&n= bsp;

Wim, Please see below.=

 

From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]
Sent: Tuesday, November 12, 2013 1:22 AM
To: Lucy yong; l2vpn@ietf.org<= br> Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t

 =

 <= /span>

 <= /span>

From: Lucy yong <lucy.yong@huawei.com>
Date: Tuesday 12 November 2013 05:11
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com>, Lucy yong <lucy.yong@huawei.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t

 <= /span>

Wim,

 

When using a (centrali= zed) gateway to provide external network connection for an L2 VN, I agree, = it is necessary for the gateway to advertise its IP host address and MAC to= all the NVEs in the L2VN. This can be done by the RT2, right? NVEs also use RT2 tenant IP/MAC addresses. Thus= , each NVE will know the gateway IP host and MAC address and perform the pr= oxy ARP function, i.e. terminate the ARP requests if the requested tenant s= ystems (including gateway) is not in local, and send back the requested  MAC in ARP reply. Thus, tenant= system will send an L2 frame with designation tenant system or gateway MAC= in dMAC to attached NVE, the NVE just performs the table lookup to obtain = the outer address. There is no IP routing table on NVEs because of the L2VN.  What is the problem here? Why nee= d to use RT5 to convey the GW IP/MAC info?  Please explain, I may miss= some part in nutshell.

 <= /span>

WH> = if you look to the drawings in the slides the NVE(s) can also have IP prefi= xes behind them. E.g. A firewall, etc. this is what we are referring to in = the draft.

See fig= 1/2/3/4/5.

[Lucy] OK, this = is how to deal with network appliances. Do we want to treat it as a middle = box, or a tenant system that has multiple addresses? I guess, you want to a= ddress it as the latter. Even it is the latter, IMO, such tenant system should not advertise the prefix in an = L2 VN at all because it serves middle box function only. If a tenant system= is a gateway, it needs to advertise itself as gateway (not the prefix from= other VN). Then it will be the same case as the following description. Does this make sense?

&n= bsp;

WH2>= there are real use cases as we describe which are required to be supported= and hence this is what the draft is proposing and as we said before L3VPN = AFI/SAFI does not do the job. 

 

When using a gateway t= o provide external network connection for an L3 VN, NVEs use their MAC addr= ess in ARP reply if VAP is L2 access interface. The L2 frame from a tenant = system will be terminated at NVEs regardless the destination tenant system is in the same VN or not. NVEs should have a= ll the IP routes in the VN. When NVE performs a lookup and is not able to f= ind the matching one, it means the packet for the external.  Since the= gateway advertises its IP host address to NVEs as the gateway for the L3VN, NVEs will forward the packets going t= o external to the gateway.  In this case, the NVE acts as the first-ho= p router, the gateway is the last-hop in the VN.  You are right, it is= necessary for a gateway to advertise its role besides its IP address.  If this is not there, should improve th= e protocol.

 

Regarding the IRB capa= bility, this is my view about IRB implementation in virtual overlay environ= ment.

 

 

Figure shows two L2VNs= , VNx and VNz.  NVE1 and NVE2 are member of both VNs. If NVE1 and NVE2= implement L3 distributed gateway functions and have the same MAC address f= or the L3dGW. When NVEs advertise both Tenant system IP and MAC addresses, each NVE have all the information about tenan= t systems in both VNs. NVEs still terminates the ARP requests and provide t= he MAC for the remote tenant system in the same VN. NVEs returns L3dGW addr= esses for the GW ARP request or if no matching MAC are founded.  Thus, only the L3dGW at ingress NVE = process inter-VN traffic forwarding, i.e. the traffic from VNx TS on NVE1 g= oes through the L3dGW on NVE1 to reach the VNy TS on NVE1 or VNy TS on NVE2= .  Will this make sense to you?

 <= /span>

WH> = yes but the prefix draft is orthogonal to this. So lets not mix these thing= s. The draft describing IRB is the following for which you are a co-author = and we are submitting an update to show the 2 architectures supporting this:

 <= /span>

https://tools.ietf.org/html/draft-sajassi-l2vpn-evpn-inter-subnet= -forwarding-02

[Lucy] yes, we p= rovide a lot of inputs on evpn overlay and interworking drafts. Glad to con= tinually work on these drafts. However, these drafts are still individual d= rafts. As we are more and more clear on the network virtualization overlay for the cloud applications, we need = update the descriptions (an implementation) in these drafts to make it clea= r. As you aware, neither of us works on these drafts recently.

&n= bsp;

WH2>= we did in the last IETF and the updates will be reflected before the end o= f the year

 =

 

Thanks,

Lucy

 

 

 

 

 

 

 

From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]
Sent: Monday, November 11, 2013 2:22 AM
To: Lucy yong; l2vpn@ietf.org<= br> Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t

 =

In-line=

 <= /span>

From: Lucy yong <lucy.yong@huawei.com>
Date: Monday 11 November 2013 08:43
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com>, Lucy yong <lucy.yong@huawei.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t

 <= /span>

Wim,

 

I read the draft and s= till think that all the use cases work well with RT2.  Here are my vie= ws how these use cases in section 5 can be implemented without RT5

 

Use case 1 can be done= by an L3 VN overlay, say VN10, and a gateway at DCGW1 and DCGW2. The gatew= ay is used to interconnect the VN 10 and WAN.

The VN10 route the tra= ffic on SN 1 and SN2, SN3, and IP2-IP5.  I call this implementation &#= 8220;L3VN plus a gateway” Why do you want to use an L2 VN overlay her= e?

 <= /span>

WH> = you don’t have a GW IP in the L3VPN AFI/SAFI, so you will need to def= ine a new route to do this efficiently

 

Use case 2 and use cas= e 4 are about multi-homing. In the case 2, TS and NVE are co-located; in th= e case 4, TS and NVE are physically separated.  First of all, IMO, whe= n TS and NVE co-locate on the same server, multi-homed TS is not necessary. The use case 4 is just the use case 1 wit= h multi-homing. Thus, it can be implemented by “L3VN plus a gateway&#= 8221; w/ VRRP.  <= /p>

 <= /span>

WH> = there is no VRRP in these cases since the appliance is a bump in the wire f= or use case 4 so they don’t even speak IP, so you have an undefined N= H, which is also not evadable in the L3VPn AFI/SAFI and there is no ESI NH possible

 

In your use case 3, EV= I10 should be replaced by an L3 overlay. The VRF on the NVE1 acts as the L3= distributed gateway for the EVN1 and EVN2.  The VRF on the NVE2 acts = as the L3 distributed gateway for the EVN2 and EVN3. The VRFs on DGW1 and DGW2 act as the gateway between the L3 over= lay and WAN. If NVE1 and NVE2 use RT2 advertises TS IP/MAC,  NVE1 will= know IP subnet/prefix associating to EVN1 and EVN2, and IP subnet/prefix a= ssociating to the L3 overlay. When NVE1 receives a packet from IP1 and the packet has the destination to SN1, the = packet dMAC address will be the MAC address for the distributed gateway tha= t is the same for all the NVEs. When NVE sees this address, it will perform= the VRF table lookup by using the destination IP addr on the packet, which results the IP addr is associated= to the EVN2, then NVE performs the table look-up in EVI-2 that has both IP= /MAC to outer (or VAP) address mapping, so it will replace the dMAC addr on= the packet with the real destination MAC addr and send to the VAP that SN1 associated to.  When NVE1 recei= ves a packet from IP1 and the packet has the destination in the WAN network= , the dMAC on the packet is also the MAC address for the distributed gatewa= y. So NVE will perform the VRF table look-up by using the destination IP on the packet, which results to the ou= ter IP address on one of DGWs, say DGW1. NVE1 adds the L3 VN ID and the out= er header on the packet prior sending it out. When DGW1 receives the packet= , it removes the tunnel header and uses the L3 VN ID on the packet to reach the vGW on DGW1. The vGW perform = the packet treatment before sending to the WAN.

 <= /span>

WH> = it depends how you want to do this, you can either go route from ingress w/= o IP lookup on ingress or do a lookup on egress. Both options are possible = and required for some HW in the market. EVPN supports both already, what this draft is doing is how prefixes shoul= d be used in this environment=

 

L2/L3 NVE service type= described in draft-yong-nv03-nve is for this use case. When L2/L3 NVE serv= ice type is used, NVE maintains both TS IP/MAC addresses but may advertise = both IP/MAC addresses or one of the address depending on the remote NVE service type. When L2 NVE service type= is used, NVE just maintains TS MAC addresses. Both cases can be implemente= d by EVPN solution.

 <= /span>

WH>&= nbsp;draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 describes the IRB = case

 

There are places we ne= ed to use L2 VNs. For example, all TSes in a VN have the same IP address bu= t different MAC addresses;  there is broadcast/multicast traffic in a = VN; non-IP packet. However, we don’t want to make a complex EVPN solution to solve the case that L3VN can easily add= ress.  

 <= /span>

WH> = see draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 it describes i= t all. As I said not all use case can be done with L3VPN and this is requir= ed.

 

Regards,

Lucy

 

 

 

 

 

 

 

From: HenderickxHi Win,, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com]
Sent: Friday, November 08, 2013 2:18 PM
To: Lucy yong; l2vpn@ietf.org<= br> Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t

 =

Lucy, d= id you read the draft and is explained in section 6.

Show an= example on how you do the scenario’s with RT2 and you will see why t= his is less efficient/scalable + does not support all scenario’s = in the draft like ESI NH.

 <= /span>

E-VPN d= istributes host routes using RT-2: (IP) + MAC and these can be an inter= face e.g. And prefixes can exists behind them.

 <= /span>

From: Lucy yong <lucy.yong@huawei.com>
Date: Friday 8 November 2013 22:10
To: "l2vpn@ietf.org"= <l2vpn@ietf.org>
Subject: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement

 <= /span>

Hi Authors,

 =

I am not convinced if RT= 5 is necessary for the use cases you specified in the draft (or presentati= on). IMO: RT2 is sufficient to support all the cases.

There is a draft-yong-nv= o3-nve, which covers all the L2 overlay cases, which can be implemented by = EVPN with RT2.

 =

One question, why EVPN s= ervice allow to VAP being an IP interface?

 =

Thanks,

Lucy

--_000_2691CE0099834E4A9C5044EEC662BB9D452ECFCDdfweml509mbxchi_-- --_004_2691CE0099834E4A9C5044EEC662BB9D452ECFCDdfweml509mbxchi_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=3555; creation-date="Tue, 12 Nov 2013 18:14:39 GMT"; modification-date="Tue, 12 Nov 2013 18:14:39 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAArMAAADaCAMAAACCXTqSAAAAAXNSR0ICQMB9xQAAAGlQTFRFAAAA AAAAAwYLDQsKBAAACwYDAAAECgsNCgQAAAQKCAMAAAMIDQoIAwAADQgECAYDBAgNBAADCAoNAwAE AwMIBAAEBAQACAMDAAADAwADDQgKAwMDBAQEBAYICAgIAwQEBAQDCAYEAwQKoNCZ7QAAAAF0Uk5T AEDm2GYAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAAZdEVYdFNvZnR3YXJlAE1pY3Jvc29mdCBPZmZp Y2V/7TVxAAAM4UlEQVR42u2dC3uiOBuGAaXlYFnWdradnZ3v9P9/5EfOiUQMeCp6P9dcU0XMmzzc voQQTZYhhBBCCCGEEEIIfTOVxXPGXlet1+kUzMIsglmYhVmYxalra7PNpV5eK/WgzuyDLLIpsm3x /i72yh3L0sxYvv86nXrUTzB59rGdglmYRTALszALsziFEEIIIYQQQgghhBBKF+Oza6g147PTblzA n8QiHpDZK5kHszALszALszD7rMw2coLp9JbYpuW7zS8MZr8Xs9784qVzvmdMUVax/fJr88+Wb/7F NkW2efUZv3Oq/Mla+DGP8zNpXtqc72Pmwez3zbPyiLYnt8Q2Ld9tZmHkWZhdv2MwC7MwC7MwC7OP zexzxF5XrWEWZmEWIYQQQgghhBBCCCH0LXU4GLh7y/O7jQ8uDi6mSE2/sWtPlVEVd6j/E4zFClOE Wn2cXv6Y1eaIQ3JTJwvtZYB+KLjQpb/q6XK9DFyr3eR+823fbI9QEwnuqxlHXHD0N3/uYy0KvH0f T6hsJidZqpCj+rtAbVYuMC/BUI+DBRjcmNmPIR/08s9m2wu/LsLsUNqPV/dUFG9eKeshSGvT0PES TsaujwM1Du4OTqH/O4/Zsj3WIqdYoq36hJCj+ttA2RLzUpi1HCzB4G7MqpOdsmn41L38lZCMTjOr Ml+dWXg+98PTpghtHz7bX/shqsxC58+RiQQPOdr93IuMlfcqOVZ6ovSQuvouD2e6ygxU6yqKZ6q4 poi3yG9JF0mqVcocmVH9baBsiXmzmHUYJFNw5zyrLFMftYsxax6LHCMs6Wpx2gxTRSPm27epFs9g Njj+riqFedz0On/JQ14JMP9+PSxf1Exwbrux6km0Ra4leqfzmFWPTaBF5s3Ps/MouIMqW8lcHDHZ VzMvJf1Sv/fNjxizoldmM4Y0X33XJDy9VW118PP/k18xSWXWBnfHxr5ZJpMPs3envxkTO9LybZKK RhWnU2isRbolmZ8FDpmNfFfGb/m4/ibQpHlu0/RRivtpODAYOAq+MbPKInsJlZLtTuVZcTbzss3n Xm7uxCIe/WGXrGnT08LEFdjR4KM8K59UfXAd6nlhGrJ116i97WiY036kRa4lMWYnr8LCPBvUXwda ZF7iictru8QgmYL7MWs/xhOGL2C2+9p7r6nTcC1OdKHtw+Vx+fI6x+KTefYguJ/nzKm9kJ0i70w8 YlbZoC8iW9WldAXEWuRacmbfIKi/DrTIvFnMhhgkUXBHZqU/4olyp7kIs9JLc0be/Pi1N4Y0uW+7 PAXqI3Q5ZoPg5iDUbtxg9y4vMfRlRzTPyqJ0Ut9s/7Fdh6Y40iKvJWdegwX114EWmTePWYNBOgW3 ljr1yY7Vb32FLK+oz+sb6LHDoV/U2NOuNKTVxfeSGzvE2OXq0lf2+M9l9lhwQ5s3qFkpqkq9W+X6 CLanJ0v7/aYuyl3aLttoi4KWRMe6TjMbr7+5xlpgXoqhlgOLQToFq9fNbsRMjM/eIGTCFUrsnsL0 +Oya7IfZBZq8CrtORJ/TRfduN9trr4cIs8hDME+86YsQQgghhBBCVxK/ybGGWjOWMO3GiVmnC29U PAmzUy+e4QrMwizMwizMwuyzMvvQ6ynA7FWYnV5PITL7mPUU0sybngnPegorzrPZI6+nQJ59VGZX 6BjMwizMwizMwuxjM/scsddVa5iFWZhFCCGEEEIIIYQQQgjdX4zPrqHWjM+murH4LuLz3rud2o17 tzALszALszALszALszc8ArFf8b/Od2sekNmxUXy35kZHgDx70caRZ2EWZmEWZmEWZmEWZu93BB4u 9rpqDbMwC7MIIYQQQgghhFCK5o3Pivvh9l54c3QpVcZnx7sF1s01j3GDWcx2uVu9sBN/S+u8eF0c iq9/fYh1k9tMLDNcwGzMvAPrZpoHs7OYNeu6O33u3etyEffdW2vWq+/qM1LR4zF7aN7n3n893TyY PY/Z0qwdXwyv24Mw7LTZFjA7aV6pf3V5tnkwewazwwmsNeYPXTJvsfjP/e7Xh34LzEbM09YtMg9m z2B2UNWaLVWhT2rK9rL43Fc9zB43r2rdllnmwewiZl1XrOq126VMFXJufT1sFcbD7KR5wp4l5sHs ucwWNlXoreIwlP/+GDpk6jnMHmO28PLsDPNgdjGz8twmBmxKcbVQ5sNlQ2ts734VQ9ZQgzkwOzLP WpctMQ9mZzGrhhjz/GufqSte6az40l1bDme10rwmByCrhOWInolZz7zSfTVxvnkwO4vZ66eiB2b2 UuXDLMzCLEIIIYQQQgghhBBC6P7iNznWUGvGZ1Pd4Pe6Lto4fq8LZmEWZmEWZmEWZmH2hkeA9RTO qDXrKdztCJBnL9o48izMwizMwizMwizMwuz9jsDDxV5XrWEWZmEWIYQQQgghhBBKEeMGa6g14wbT bkz7c8mfR3kcZi95pyW2P8zCLMzCLMzC7LMy2+T1yS2xTct3m18YzH4vZr05x5GZyUlzvr1Np6Yy q9j+/rX5Zwsz/2KbItu8+ozfOVX+ZC38mNHF6g5nx4/MSJzzfcwxmP2+eVZy2J7cEtu0fLeZhZFn YXb9jsEszMIszMIszD42s88Re121hlmYhVmEEEIIIYQQQgghhNC31MRg4O4tz28yVLg0kJgPNf2+ rj1ZSFXcvyHZIw/KClOEWn3EXv6Y1dSTt1TVcu69jtUPMQoZ5lVPl+tlDWqz7Hs/I9BmG/LjQulA 4e7NVPGph3rz5z6L1t+39N3MmWwiv6KbcO921BAXsc1KG/OEZfPu3XocLMDgxsx+DImhl3822174 dVlmh2J/vPqviEhql1KQ2rrENOlsLNBoarUJZQP5x6TQ/53FbNm6fQ7rb+WeV/0SZiMNsRGzIGbi T/ylMGs5WILB3Zjt3PEQn7qXv5ZlpePMqiRSG5w+98OTpjhg1uav2YEOQnX1mKPdz/+Isk1qrPS0 6CFj9Z0615hSZd6pVX2+9uKpLK4psixW/6DWnU2vVdrMnqPMjh3LAs/0G6OeLWXWYZBMwZ3zrPZA ftSuwax6JvKP8KarxYk0ZFbsULYLAoWhYmHFoVaPmt6mLQlYJcD8+/Wg1KqVnEtS2sw+jtQ/qLXZ 6zLMho6FnhlmY56dlWfnUXAHVbaSuTh0qtemXxp9kWPyuzInmRUdNJ065FFQXzo57BtUof2JgYJQ OpB/SPR7ZAb5cHt3+gsxkeOr3iVr0/R+Bo3W39baffjNK6OvvMRcnGyIiRjG9CpbtfEPQtJ3dwIO DAaOgm/MrLJINFV27xdO6owzK09rLgN97uXmwf/hAB8yW9UpqWg7voJ3oVyqO8yz8qFssX/56SwI DnVrENQdDXvWj9Tf1doxG7kKm5Fng4boiGFM72NeTxSaOITgcSAxSKbgfszaj/HI+Usx233t7U7q xFyLM94BszFk5/QNRD/z6zBFmP7sXjxU+dM/ARwyqxqvs/Nw1lUfOUfQuP5erS/VNwgaoiOGnk19 zJcyG2KQRMEdmZX+iCfKnebSzJYi6Rhefu2NM00eMNvUsXJnMesFcrmvNieR3bu+rtBXG7E8K0sy qXyz/ccg0RQm0kH9/Vpf6hosaIiOGHpm3hjzbDGzBoN0Cm4tdRKUfbrf5lq5zC/WN9CDiLKD1NhT se5+lXqAs8jc+Kx+sIBZF8oPZOXGZyvDVKl3q/LggfBAFvb7Te1ZumxnCj2of1Brb6xrEbPxhugO 6yhmn8U9m8ms5cBikE7B6nWz+y9lnd08Usp1ibunEBuffbzjALPpil2FXSeQB+qce7ebbcJqkjCL Lq4qT7vpixBCCCGEEEIIIYRWLn77aA21Zqh22g1+F3E+P/wuIszCLMzCLMzC7HWYZd0amJ1rJOvW ZKxbQ56dlWcz1q0hz66P2RU6BrMwC7MwC7Mw+9jMPkfsddUaZmEWZhFCCCGEEEIIIYQeUYx1raHW jHXBLMzCLMziFMziGMzGtHgOd3b+/kemga/PsbQ53Nny/dfp1KN+gsmzj+0UzMIsglmYhVmYxSmE EEIIIYQQQgghhBBCCKGHkVqeHi3z7kmW/b6xSrVyu/5N1JdXMzVOLbPe5V//xfXT5uXGutasez+Y t3vrs80W+y6vTv7uqlxrW932Luts8+PVPu0wPcE8a13mzJPbdh+4dHnb66bQzCp/P/cwO9s8a10W mCf2wKUr2L57f1XMZlU/PG+l7cp5TE81z1gXmpe5R+iStsu1BArDpzBfdW1hdoZ5xrrQPNGlRdew fbPtFbPDyU0mBvLsfPO0dYF5u597PLqO7cNJTTNbFt5lBMzOMU9b55vXfYHs1WzPGj2OuPnxy11G 7P4Hs+nmaes880rRQ2Dc4PIqczXGqC9zK3EZYYYYazP2yNBBgnmVWqvJmdfIvy02IYQQQgghdHv9 H3y0r0/B5/9vAAAAAElFTkSuQmCC --_004_2691CE0099834E4A9C5044EEC662BB9D452ECFCDdfweml509mbxchi_-- From wim.henderickx@alcatel-lucent.com Tue Nov 12 10:21:47 2013 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 AD20C21E8093 for ; Tue, 12 Nov 2013 10:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.43 X-Spam-Level: X-Spam-Status: No, score=-8.43 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] 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 VGfmEb5n-1wv for ; Tue, 12 Nov 2013 10:21:42 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id DF07D21E8091 for ; Tue, 12 Nov 2013 10:21:41 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rACILYN2024504 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Nov 2013 12:21:35 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rACILXot012626 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 19:21:33 +0100 Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([169.254.1.146]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Tue, 12 Nov 2013 19:21:33 +0100 From: "Henderickx, Wim (Wim)" To: "'lucy.yong@huawei.com'" , "'l2vpn@ietf.org'" Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Thread-Topic: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Thread-Index: AQHO39QDaEHbGYN+REaqkdhodCHOfQ== Date: Tue, 12 Nov 2013 18:21:33 +0000 Message-ID: <82FB08F009780940837EB830C283F28408E8C1AD@FR711WXCHMBA05.zeu.alcatel-lucent.com> In-Reply-To: <2691CE0099834E4A9C5044EEC662BB9D452ECFCD@dfweml509-mbx.china.huawei.com> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/related; boundary="_004_82FB08F009780940837EB830C283F28408E8C1ADFR711WXCHMBA05z_"; type="multipart/alternative" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 18:21:47 -0000 --_004_82FB08F009780940837EB830C283F28408E8C1ADFR711WXCHMBA05z_ Content-Type: multipart/alternative; boundary="_000_82FB08F009780940837EB830C283F28408E8C1ADFR711WXCHMBA05z_" --_000_82FB08F009780940837EB830C283F28408E8C1ADFR711WXCHMBA05z_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhleSBhcmUgZGVzY3JpYmVkIGluIHRoZSBkcmFmdC4NCg0KQ2hlZXJzLA0KV2ltDQpfX19fX19f X19fX19fX19fXw0Kc2VudCBmcm9tIGJsYWNrYmVycnkNCg0KRnJvbTogTHVjeSB5b25nIFttYWls dG86bHVjeS55b25nQGh1YXdlaS5jb21dDQpTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAxMiwgMjAx MyAwNzoxNCBQTQ0KVG86IEhlbmRlcmlja3gsIFdpbSAoV2ltKTsgbDJ2cG5AaWV0Zi5vcmcgPGwy dnBuQGlldGYub3JnPg0KU3ViamVjdDogUkU6IGNvbW1lbnQgb24gZHJhZnQtcmFiYWRhbi1sMnZw bi1ldnBuLXByZWZpeC1hZHZlcnRpc2VtZW50DQoNCldpbSwNCg0KUGxlYXNlIGNsYXJpZnkgeW91 ciByZWFsIHVzZSBjYXNlLiAgSW4geW91ciByZWFsIHVzZSBjYXNlLCB3aGVuIHVzaW5nIGEgZmly ZXdhbGwsIGRvZXMgaXQgdXNlIHdpdGggYSBnYXRld2F5IHRvZ2V0aGVyIG9yIG5vdC4gSWYgbm90 LCB0aGUgZmlyZXdhbGwgaXMgYSBqdXN0IG1pZGRsZSBib3ggKHdpcmVkKSBhbmQgZG9lcyBub3Qg cGFydGljaXBhdGUgaW4gdGhlIEwyVk4gcm91dGluZy4gSWYgaXQgd29ya3Mgd2l0aCB0aGUgZ2F0 ZXdheSwgb25seSBnYXRld2F5IHBhcnRpY2lwYXRlcyBpbiB0aGUgTDJWTiwgIG5vdCB0aGUgZmly ZXdhbGwuIFRoZSBjb25maWd1cmF0aW9uIGJldHdlZW4gZ2F0ZXdheSBhbmQgZmlyZXdhbGwgaXMg bG9jYWwsIG5vdCByZWxhdGVkIHRvIHRoZSBMMlZOLg0KDQpMdWN5DQoNCkZyb206IEhlbmRlcmlj a3gsIFdpbSAoV2ltKSBbbWFpbHRvOndpbS5oZW5kZXJpY2t4QGFsY2F0ZWwtbHVjZW50LmNvbV0N ClNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDEyLCAyMDEzIDExOjExIEFNDQpUbzogTHVjeSB5b25n OyBsMnZwbkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IGNvbW1lbnQgb24gZHJhZnQtcmFiYWRhbi1s MnZwbi1ldnBuLXByZWZpeC1hZHZlcnRpc2VtZW50DQoNCkluLWxpbmUNCg0KRnJvbTogTHVjeSB5 b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+Pg0K RGF0ZTogVHVlc2RheSAxMiBOb3ZlbWJlciAyMDEzIDE5OjA1DQpUbzogV2ltIEhlbmRlcmlja3gg PHdpbS5oZW5kZXJpY2t4QGFsY2F0ZWwtbHVjZW50LmNvbTxtYWlsdG86d2ltLmhlbmRlcmlja3hA YWxjYXRlbC1sdWNlbnQuY29tPj4sICJsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5v cmc+IiA8bDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPj4NClN1YmplY3Q6IFJF OiBjb21tZW50IG9uIGRyYWZ0LXJhYmFkYW4tbDJ2cG4tZXZwbi1wcmVmaXgtYWR2ZXJ0aXNlbWVu dA0KDQpXaW0sIFBsZWFzZSBzZWUgYmVsb3cuDQoNCkZyb206IEhlbmRlcmlja3gsIFdpbSAoV2lt KSBbbWFpbHRvOndpbS5oZW5kZXJpY2t4QGFsY2F0ZWwtbHVjZW50LmNvbV0NClNlbnQ6IFR1ZXNk YXksIE5vdmVtYmVyIDEyLCAyMDEzIDE6MjIgQU0NClRvOiBMdWN5IHlvbmc7IGwydnBuQGlldGYu b3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBjb21tZW50IG9uIGRyYWZ0 LXJhYmFkYW4tbDJ2cG4tZXZwbi1wcmVmaXgtYWR2ZXJ0aXNlbWVudA0KDQoNCg0KRnJvbTogTHVj eSB5b25nIDxsdWN5LnlvbmdAaHVhd2VpLmNvbTxtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20+ Pg0KRGF0ZTogVHVlc2RheSAxMiBOb3ZlbWJlciAyMDEzIDA1OjExDQpUbzogV2ltIEhlbmRlcmlj a3ggPHdpbS5oZW5kZXJpY2t4QGFsY2F0ZWwtbHVjZW50LmNvbTxtYWlsdG86d2ltLmhlbmRlcmlj a3hAYWxjYXRlbC1sdWNlbnQuY29tPj4sIEx1Y3kgeW9uZyA8bHVjeS55b25nQGh1YXdlaS5jb208 bWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tPj4sICJsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2 cG5AaWV0Zi5vcmc+IiA8bDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPj4NClN1 YmplY3Q6IFJFOiBjb21tZW50IG9uIGRyYWZ0LXJhYmFkYW4tbDJ2cG4tZXZwbi1wcmVmaXgtYWR2 ZXJ0aXNlbWVudA0KDQpXaW0sDQoNCldoZW4gdXNpbmcgYSAoY2VudHJhbGl6ZWQpIGdhdGV3YXkg dG8gcHJvdmlkZSBleHRlcm5hbCBuZXR3b3JrIGNvbm5lY3Rpb24gZm9yIGFuIEwyIFZOLCBJIGFn cmVlLCBpdCBpcyBuZWNlc3NhcnkgZm9yIHRoZSBnYXRld2F5IHRvIGFkdmVydGlzZSBpdHMgSVAg aG9zdCBhZGRyZXNzIGFuZCBNQUMgdG8gYWxsIHRoZSBOVkVzIGluIHRoZSBMMlZOLiBUaGlzIGNh biBiZSBkb25lIGJ5IHRoZSBSVDIsIHJpZ2h0PyBOVkVzIGFsc28gdXNlIFJUMiB0ZW5hbnQgSVAv TUFDIGFkZHJlc3Nlcy4gVGh1cywgZWFjaCBOVkUgd2lsbCBrbm93IHRoZSBnYXRld2F5IElQIGhv c3QgYW5kIE1BQyBhZGRyZXNzIGFuZCBwZXJmb3JtIHRoZSBwcm94eSBBUlAgZnVuY3Rpb24sIGku ZS4gdGVybWluYXRlIHRoZSBBUlAgcmVxdWVzdHMgaWYgdGhlIHJlcXVlc3RlZCB0ZW5hbnQgc3lz dGVtcyAoaW5jbHVkaW5nIGdhdGV3YXkpIGlzIG5vdCBpbiBsb2NhbCwgYW5kIHNlbmQgYmFjayB0 aGUgcmVxdWVzdGVkICBNQUMgaW4gQVJQIHJlcGx5LiBUaHVzLCB0ZW5hbnQgc3lzdGVtIHdpbGwg c2VuZCBhbiBMMiBmcmFtZSB3aXRoIGRlc2lnbmF0aW9uIHRlbmFudCBzeXN0ZW0gb3IgZ2F0ZXdh eSBNQUMgaW4gZE1BQyB0byBhdHRhY2hlZCBOVkUsIHRoZSBOVkUganVzdCBwZXJmb3JtcyB0aGUg dGFibGUgbG9va3VwIHRvIG9idGFpbiB0aGUgb3V0ZXIgYWRkcmVzcy4gVGhlcmUgaXMgbm8gSVAg cm91dGluZyB0YWJsZSBvbiBOVkVzIGJlY2F1c2Ugb2YgdGhlIEwyVk4uICBXaGF0IGlzIHRoZSBw cm9ibGVtIGhlcmU/IFdoeSBuZWVkIHRvIHVzZSBSVDUgdG8gY29udmV5IHRoZSBHVyBJUC9NQUMg aW5mbz8gIFBsZWFzZSBleHBsYWluLCBJIG1heSBtaXNzIHNvbWUgcGFydCBpbiBudXRzaGVsbC4N Cg0KV0g+IGlmIHlvdSBsb29rIHRvIHRoZSBkcmF3aW5ncyBpbiB0aGUgc2xpZGVzIHRoZSBOVkUo cykgY2FuIGFsc28gaGF2ZSBJUCBwcmVmaXhlcyBiZWhpbmQgdGhlbS4gRS5nLiBBIGZpcmV3YWxs LCBldGMuIHRoaXMgaXMgd2hhdCB3ZSBhcmUgcmVmZXJyaW5nIHRvIGluIHRoZSBkcmFmdC4NClNl ZSBmaWcgMS8yLzMvNC81Lg0KW0x1Y3ldIE9LLCB0aGlzIGlzIGhvdyB0byBkZWFsIHdpdGggbmV0 d29yayBhcHBsaWFuY2VzLiBEbyB3ZSB3YW50IHRvIHRyZWF0IGl0IGFzIGEgbWlkZGxlIGJveCwg b3IgYSB0ZW5hbnQgc3lzdGVtIHRoYXQgaGFzIG11bHRpcGxlIGFkZHJlc3Nlcz8gSSBndWVzcywg eW91IHdhbnQgdG8gYWRkcmVzcyBpdCBhcyB0aGUgbGF0dGVyLiBFdmVuIGl0IGlzIHRoZSBsYXR0 ZXIsIElNTywgc3VjaCB0ZW5hbnQgc3lzdGVtIHNob3VsZCBub3QgYWR2ZXJ0aXNlIHRoZSBwcmVm aXggaW4gYW4gTDIgVk4gYXQgYWxsIGJlY2F1c2UgaXQgc2VydmVzIG1pZGRsZSBib3ggZnVuY3Rp b24gb25seS4gSWYgYSB0ZW5hbnQgc3lzdGVtIGlzIGEgZ2F0ZXdheSwgaXQgbmVlZHMgdG8gYWR2 ZXJ0aXNlIGl0c2VsZiBhcyBnYXRld2F5IChub3QgdGhlIHByZWZpeCBmcm9tIG90aGVyIFZOKS4g VGhlbiBpdCB3aWxsIGJlIHRoZSBzYW1lIGNhc2UgYXMgdGhlIGZvbGxvd2luZyBkZXNjcmlwdGlv bi4gRG9lcyB0aGlzIG1ha2Ugc2Vuc2U/DQoNCldIMj4gdGhlcmUgYXJlIHJlYWwgdXNlIGNhc2Vz IGFzIHdlIGRlc2NyaWJlIHdoaWNoIGFyZSByZXF1aXJlZCB0byBiZSBzdXBwb3J0ZWQgYW5kIGhl bmNlIHRoaXMgaXMgd2hhdCB0aGUgZHJhZnQgaXMgcHJvcG9zaW5nIGFuZCBhcyB3ZSBzYWlkIGJl Zm9yZSBMM1ZQTiBBRkkvU0FGSSBkb2VzIG5vdCBkbyB0aGUgam9iLg0KDQpXaGVuIHVzaW5nIGEg Z2F0ZXdheSB0byBwcm92aWRlIGV4dGVybmFsIG5ldHdvcmsgY29ubmVjdGlvbiBmb3IgYW4gTDMg Vk4sIE5WRXMgdXNlIHRoZWlyIE1BQyBhZGRyZXNzIGluIEFSUCByZXBseSBpZiBWQVAgaXMgTDIg YWNjZXNzIGludGVyZmFjZS4gVGhlIEwyIGZyYW1lIGZyb20gYSB0ZW5hbnQgc3lzdGVtIHdpbGwg YmUgdGVybWluYXRlZCBhdCBOVkVzIHJlZ2FyZGxlc3MgdGhlIGRlc3RpbmF0aW9uIHRlbmFudCBz eXN0ZW0gaXMgaW4gdGhlIHNhbWUgVk4gb3Igbm90LiBOVkVzIHNob3VsZCBoYXZlIGFsbCB0aGUg SVAgcm91dGVzIGluIHRoZSBWTi4gV2hlbiBOVkUgcGVyZm9ybXMgYSBsb29rdXAgYW5kIGlzIG5v dCBhYmxlIHRvIGZpbmQgdGhlIG1hdGNoaW5nIG9uZSwgaXQgbWVhbnMgdGhlIHBhY2tldCBmb3Ig dGhlIGV4dGVybmFsLiAgU2luY2UgdGhlIGdhdGV3YXkgYWR2ZXJ0aXNlcyBpdHMgSVAgaG9zdCBh ZGRyZXNzIHRvIE5WRXMgYXMgdGhlIGdhdGV3YXkgZm9yIHRoZSBMM1ZOLCBOVkVzIHdpbGwgZm9y d2FyZCB0aGUgcGFja2V0cyBnb2luZyB0byBleHRlcm5hbCB0byB0aGUgZ2F0ZXdheS4gIEluIHRo aXMgY2FzZSwgdGhlIE5WRSBhY3RzIGFzIHRoZSBmaXJzdC1ob3Agcm91dGVyLCB0aGUgZ2F0ZXdh eSBpcyB0aGUgbGFzdC1ob3AgaW4gdGhlIFZOLiAgWW91IGFyZSByaWdodCwgaXQgaXMgbmVjZXNz YXJ5IGZvciBhIGdhdGV3YXkgdG8gYWR2ZXJ0aXNlIGl0cyByb2xlIGJlc2lkZXMgaXRzIElQIGFk ZHJlc3MuICBJZiB0aGlzIGlzIG5vdCB0aGVyZSwgc2hvdWxkIGltcHJvdmUgdGhlIHByb3RvY29s Lg0KDQpSZWdhcmRpbmcgdGhlIElSQiBjYXBhYmlsaXR5LCB0aGlzIGlzIG15IHZpZXcgYWJvdXQg SVJCIGltcGxlbWVudGF0aW9uIGluIHZpcnR1YWwgb3ZlcmxheSBlbnZpcm9ubWVudC4NCltjaWQ6 aW1hZ2UwMDEucG5nQDAxQ0VERkEwLkU5NERCQjMwXQ0KDQoNCkZpZ3VyZSBzaG93cyB0d28gTDJW TnMsIFZOeCBhbmQgVk56LiAgTlZFMSBhbmQgTlZFMiBhcmUgbWVtYmVyIG9mIGJvdGggVk5zLiBJ ZiBOVkUxIGFuZCBOVkUyIGltcGxlbWVudCBMMyBkaXN0cmlidXRlZCBnYXRld2F5IGZ1bmN0aW9u cyBhbmQgaGF2ZSB0aGUgc2FtZSBNQUMgYWRkcmVzcyBmb3IgdGhlIEwzZEdXLiBXaGVuIE5WRXMg YWR2ZXJ0aXNlIGJvdGggVGVuYW50IHN5c3RlbSBJUCBhbmQgTUFDIGFkZHJlc3NlcywgZWFjaCBO VkUgaGF2ZSBhbGwgdGhlIGluZm9ybWF0aW9uIGFib3V0IHRlbmFudCBzeXN0ZW1zIGluIGJvdGgg Vk5zLiBOVkVzIHN0aWxsIHRlcm1pbmF0ZXMgdGhlIEFSUCByZXF1ZXN0cyBhbmQgcHJvdmlkZSB0 aGUgTUFDIGZvciB0aGUgcmVtb3RlIHRlbmFudCBzeXN0ZW0gaW4gdGhlIHNhbWUgVk4uIE5WRXMg cmV0dXJucyBMM2RHVyBhZGRyZXNzZXMgZm9yIHRoZSBHVyBBUlAgcmVxdWVzdCBvciBpZiBubyBt YXRjaGluZyBNQUMgYXJlIGZvdW5kZWQuICBUaHVzLCBvbmx5IHRoZSBMM2RHVyBhdCBpbmdyZXNz IE5WRSBwcm9jZXNzIGludGVyLVZOIHRyYWZmaWMgZm9yd2FyZGluZywgaS5lLiB0aGUgdHJhZmZp YyBmcm9tIFZOeCBUUyBvbiBOVkUxIGdvZXMgdGhyb3VnaCB0aGUgTDNkR1cgb24gTlZFMSB0byBy ZWFjaCB0aGUgVk55IFRTIG9uIE5WRTEgb3IgVk55IFRTIG9uIE5WRTIuICBXaWxsIHRoaXMgbWFr ZSBzZW5zZSB0byB5b3U/DQoNCldIPiB5ZXMgYnV0IHRoZSBwcmVmaXggZHJhZnQgaXMgb3J0aG9n b25hbCB0byB0aGlzLiBTbyBsZXRzIG5vdCBtaXggdGhlc2UgdGhpbmdzLiBUaGUgZHJhZnQgZGVz Y3JpYmluZyBJUkIgaXMgdGhlIGZvbGxvd2luZyBmb3Igd2hpY2ggeW91IGFyZSBhIGNvLWF1dGhv ciBhbmQgd2UgYXJlIHN1Ym1pdHRpbmcgYW4gdXBkYXRlIHRvIHNob3cgdGhlIDIgYXJjaGl0ZWN0 dXJlcyBzdXBwb3J0aW5nIHRoaXM6DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1zYWphc3NpLWwydnBuLWV2cG4taW50ZXItc3VibmV0LWZvcndhcmRpbmctMDINCltMdWN5XSB5 ZXMsIHdlIHByb3ZpZGUgYSBsb3Qgb2YgaW5wdXRzIG9uIGV2cG4gb3ZlcmxheSBhbmQgaW50ZXJ3 b3JraW5nIGRyYWZ0cy4gR2xhZCB0byBjb250aW51YWxseSB3b3JrIG9uIHRoZXNlIGRyYWZ0cy4g SG93ZXZlciwgdGhlc2UgZHJhZnRzIGFyZSBzdGlsbCBpbmRpdmlkdWFsIGRyYWZ0cy4gQXMgd2Ug YXJlIG1vcmUgYW5kIG1vcmUgY2xlYXIgb24gdGhlIG5ldHdvcmsgdmlydHVhbGl6YXRpb24gb3Zl cmxheSBmb3IgdGhlIGNsb3VkIGFwcGxpY2F0aW9ucywgd2UgbmVlZCB1cGRhdGUgdGhlIGRlc2Ny aXB0aW9ucyAoYW4gaW1wbGVtZW50YXRpb24pIGluIHRoZXNlIGRyYWZ0cyB0byBtYWtlIGl0IGNs ZWFyLiBBcyB5b3UgYXdhcmUsIG5laXRoZXIgb2YgdXMgd29ya3Mgb24gdGhlc2UgZHJhZnRzIHJl Y2VudGx5Lg0KDQpXSDI+IHdlIGRpZCBpbiB0aGUgbGFzdCBJRVRGIGFuZCB0aGUgdXBkYXRlcyB3 aWxsIGJlIHJlZmxlY3RlZCBiZWZvcmUgdGhlIGVuZCBvZiB0aGUgeWVhcg0KDQoNClRoYW5rcywN Ckx1Y3kNCg0KDQoNCg0KDQoNCg0KRnJvbTogSGVuZGVyaWNreCwgV2ltIChXaW0pIFttYWlsdG86 d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuY29tXQ0KU2VudDogTW9uZGF5LCBOb3ZlbWJl ciAxMSwgMjAxMyAyOjIyIEFNDQpUbzogTHVjeSB5b25nOyBsMnZwbkBpZXRmLm9yZzxtYWlsdG86 bDJ2cG5AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogY29tbWVudCBvbiBkcmFmdC1yYWJhZGFuLWwy dnBuLWV2cG4tcHJlZml4LWFkdmVydGlzZW1lbnQNCg0KSW4tbGluZQ0KDQpGcm9tOiBMdWN5IHlv bmcgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+DQpE YXRlOiBNb25kYXkgMTEgTm92ZW1iZXIgMjAxMyAwODo0Mw0KVG86IFdpbSBIZW5kZXJpY2t4IDx3 aW0uaGVuZGVyaWNreEBhbGNhdGVsLWx1Y2VudC5jb208bWFpbHRvOndpbS5oZW5kZXJpY2t4QGFs Y2F0ZWwtbHVjZW50LmNvbT4+LCBMdWN5IHlvbmcgPGx1Y3kueW9uZ0BodWF3ZWkuY29tPG1haWx0 bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+LCAibDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGll dGYub3JnPiIgPGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4+DQpTdWJqZWN0 OiBSRTogY29tbWVudCBvbiBkcmFmdC1yYWJhZGFuLWwydnBuLWV2cG4tcHJlZml4LWFkdmVydGlz ZW1lbnQNCg0KV2ltLA0KDQpJIHJlYWQgdGhlIGRyYWZ0IGFuZCBzdGlsbCB0aGluayB0aGF0IGFs bCB0aGUgdXNlIGNhc2VzIHdvcmsgd2VsbCB3aXRoIFJUMi4gIEhlcmUgYXJlIG15IHZpZXdzIGhv dyB0aGVzZSB1c2UgY2FzZXMgaW4gc2VjdGlvbiA1IGNhbiBiZSBpbXBsZW1lbnRlZCB3aXRob3V0 IFJUNQ0KDQpVc2UgY2FzZSAxIGNhbiBiZSBkb25lIGJ5IGFuIEwzIFZOIG92ZXJsYXksIHNheSBW TjEwLCBhbmQgYSBnYXRld2F5IGF0IERDR1cxIGFuZCBEQ0dXMi4gVGhlIGdhdGV3YXkgaXMgdXNl ZCB0byBpbnRlcmNvbm5lY3QgdGhlIFZOIDEwIGFuZCBXQU4uDQpUaGUgVk4xMCByb3V0ZSB0aGUg dHJhZmZpYyBvbiBTTiAxIGFuZCBTTjIsIFNOMywgYW5kIElQMi1JUDUuICBJIGNhbGwgdGhpcyBp bXBsZW1lbnRhdGlvbiDigJxMM1ZOIHBsdXMgYSBnYXRld2F54oCdIFdoeSBkbyB5b3Ugd2FudCB0 byB1c2UgYW4gTDIgVk4gb3ZlcmxheSBoZXJlPw0KDQpXSD4geW91IGRvbuKAmXQgaGF2ZSBhIEdX IElQIGluIHRoZSBMM1ZQTiBBRkkvU0FGSSwgc28geW91IHdpbGwgbmVlZCB0byBkZWZpbmUgYSBu ZXcgcm91dGUgdG8gZG8gdGhpcyBlZmZpY2llbnRseQ0KDQpVc2UgY2FzZSAyIGFuZCB1c2UgY2Fz ZSA0IGFyZSBhYm91dCBtdWx0aS1ob21pbmcuIEluIHRoZSBjYXNlIDIsIFRTIGFuZCBOVkUgYXJl IGNvLWxvY2F0ZWQ7IGluIHRoZSBjYXNlIDQsIFRTIGFuZCBOVkUgYXJlIHBoeXNpY2FsbHkgc2Vw YXJhdGVkLiAgRmlyc3Qgb2YgYWxsLCBJTU8sIHdoZW4gVFMgYW5kIE5WRSBjby1sb2NhdGUgb24g dGhlIHNhbWUgc2VydmVyLCBtdWx0aS1ob21lZCBUUyBpcyBub3QgbmVjZXNzYXJ5LiBUaGUgdXNl IGNhc2UgNCBpcyBqdXN0IHRoZSB1c2UgY2FzZSAxIHdpdGggbXVsdGktaG9taW5nLiBUaHVzLCBp dCBjYW4gYmUgaW1wbGVtZW50ZWQgYnkg4oCcTDNWTiBwbHVzIGEgZ2F0ZXdheeKAnSB3LyBWUlJQ Lg0KDQpXSD4gdGhlcmUgaXMgbm8gVlJSUCBpbiB0aGVzZSBjYXNlcyBzaW5jZSB0aGUgYXBwbGlh bmNlIGlzIGEgYnVtcCBpbiB0aGUgd2lyZSBmb3IgdXNlIGNhc2UgNCBzbyB0aGV5IGRvbuKAmXQg ZXZlbiBzcGVhayBJUCwgc28geW91IGhhdmUgYW4gdW5kZWZpbmVkIE5ILCB3aGljaCBpcyBhbHNv IG5vdCBldmFkYWJsZSBpbiB0aGUgTDNWUG4gQUZJL1NBRkkgYW5kIHRoZXJlIGlzIG5vIEVTSSBO SCBwb3NzaWJsZQ0KDQpJbiB5b3VyIHVzZSBjYXNlIDMsIEVWSTEwIHNob3VsZCBiZSByZXBsYWNl ZCBieSBhbiBMMyBvdmVybGF5LiBUaGUgVlJGIG9uIHRoZSBOVkUxIGFjdHMgYXMgdGhlIEwzIGRp c3RyaWJ1dGVkIGdhdGV3YXkgZm9yIHRoZSBFVk4xIGFuZCBFVk4yLiAgVGhlIFZSRiBvbiB0aGUg TlZFMiBhY3RzIGFzIHRoZSBMMyBkaXN0cmlidXRlZCBnYXRld2F5IGZvciB0aGUgRVZOMiBhbmQg RVZOMy4gVGhlIFZSRnMgb24gREdXMSBhbmQgREdXMiBhY3QgYXMgdGhlIGdhdGV3YXkgYmV0d2Vl biB0aGUgTDMgb3ZlcmxheSBhbmQgV0FOLiBJZiBOVkUxIGFuZCBOVkUyIHVzZSBSVDIgYWR2ZXJ0 aXNlcyBUUyBJUC9NQUMsICBOVkUxIHdpbGwga25vdyBJUCBzdWJuZXQvcHJlZml4IGFzc29jaWF0 aW5nIHRvIEVWTjEgYW5kIEVWTjIsIGFuZCBJUCBzdWJuZXQvcHJlZml4IGFzc29jaWF0aW5nIHRv IHRoZSBMMyBvdmVybGF5LiBXaGVuIE5WRTEgcmVjZWl2ZXMgYSBwYWNrZXQgZnJvbSBJUDEgYW5k IHRoZSBwYWNrZXQgaGFzIHRoZSBkZXN0aW5hdGlvbiB0byBTTjEsIHRoZSBwYWNrZXQgZE1BQyBh ZGRyZXNzIHdpbGwgYmUgdGhlIE1BQyBhZGRyZXNzIGZvciB0aGUgZGlzdHJpYnV0ZWQgZ2F0ZXdh eSB0aGF0IGlzIHRoZSBzYW1lIGZvciBhbGwgdGhlIE5WRXMuIFdoZW4gTlZFIHNlZXMgdGhpcyBh ZGRyZXNzLCBpdCB3aWxsIHBlcmZvcm0gdGhlIFZSRiB0YWJsZSBsb29rdXAgYnkgdXNpbmcgdGhl IGRlc3RpbmF0aW9uIElQIGFkZHIgb24gdGhlIHBhY2tldCwgd2hpY2ggcmVzdWx0cyB0aGUgSVAg YWRkciBpcyBhc3NvY2lhdGVkIHRvIHRoZSBFVk4yLCB0aGVuIE5WRSBwZXJmb3JtcyB0aGUgdGFi bGUgbG9vay11cCBpbiBFVkktMiB0aGF0IGhhcyBib3RoIElQL01BQyB0byBvdXRlciAob3IgVkFQ KSBhZGRyZXNzIG1hcHBpbmcsIHNvIGl0IHdpbGwgcmVwbGFjZSB0aGUgZE1BQyBhZGRyIG9uIHRo ZSBwYWNrZXQgd2l0aCB0aGUgcmVhbCBkZXN0aW5hdGlvbiBNQUMgYWRkciBhbmQgc2VuZCB0byB0 aGUgVkFQIHRoYXQgU04xIGFzc29jaWF0ZWQgdG8uICBXaGVuIE5WRTEgcmVjZWl2ZXMgYSBwYWNr ZXQgZnJvbSBJUDEgYW5kIHRoZSBwYWNrZXQgaGFzIHRoZSBkZXN0aW5hdGlvbiBpbiB0aGUgV0FO IG5ldHdvcmssIHRoZSBkTUFDIG9uIHRoZSBwYWNrZXQgaXMgYWxzbyB0aGUgTUFDIGFkZHJlc3Mg Zm9yIHRoZSBkaXN0cmlidXRlZCBnYXRld2F5LiBTbyBOVkUgd2lsbCBwZXJmb3JtIHRoZSBWUkYg dGFibGUgbG9vay11cCBieSB1c2luZyB0aGUgZGVzdGluYXRpb24gSVAgb24gdGhlIHBhY2tldCwg d2hpY2ggcmVzdWx0cyB0byB0aGUgb3V0ZXIgSVAgYWRkcmVzcyBvbiBvbmUgb2YgREdXcywgc2F5 IERHVzEuIE5WRTEgYWRkcyB0aGUgTDMgVk4gSUQgYW5kIHRoZSBvdXRlciBoZWFkZXIgb24gdGhl IHBhY2tldCBwcmlvciBzZW5kaW5nIGl0IG91dC4gV2hlbiBER1cxIHJlY2VpdmVzIHRoZSBwYWNr ZXQsIGl0IHJlbW92ZXMgdGhlIHR1bm5lbCBoZWFkZXIgYW5kIHVzZXMgdGhlIEwzIFZOIElEIG9u IHRoZSBwYWNrZXQgdG8gcmVhY2ggdGhlIHZHVyBvbiBER1cxLiBUaGUgdkdXIHBlcmZvcm0gdGhl IHBhY2tldCB0cmVhdG1lbnQgYmVmb3JlIHNlbmRpbmcgdG8gdGhlIFdBTi4NCg0KV0g+IGl0IGRl cGVuZHMgaG93IHlvdSB3YW50IHRvIGRvIHRoaXMsIHlvdSBjYW4gZWl0aGVyIGdvIHJvdXRlIGZy b20gaW5ncmVzcyB3L28gSVAgbG9va3VwIG9uIGluZ3Jlc3Mgb3IgZG8gYSBsb29rdXAgb24gZWdy ZXNzLiBCb3RoIG9wdGlvbnMgYXJlIHBvc3NpYmxlIGFuZCByZXF1aXJlZCBmb3Igc29tZSBIVyBp biB0aGUgbWFya2V0LiBFVlBOIHN1cHBvcnRzIGJvdGggYWxyZWFkeSwgd2hhdCB0aGlzIGRyYWZ0 IGlzIGRvaW5nIGlzIGhvdyBwcmVmaXhlcyBzaG91bGQgYmUgdXNlZCBpbiB0aGlzIGVudmlyb25t ZW50DQoNCkwyL0wzIE5WRSBzZXJ2aWNlIHR5cGUgZGVzY3JpYmVkIGluIGRyYWZ0LXlvbmctbnYw My1udmUgaXMgZm9yIHRoaXMgdXNlIGNhc2UuIFdoZW4gTDIvTDMgTlZFIHNlcnZpY2UgdHlwZSBp cyB1c2VkLCBOVkUgbWFpbnRhaW5zIGJvdGggVFMgSVAvTUFDIGFkZHJlc3NlcyBidXQgbWF5IGFk dmVydGlzZSBib3RoIElQL01BQyBhZGRyZXNzZXMgb3Igb25lIG9mIHRoZSBhZGRyZXNzIGRlcGVu ZGluZyBvbiB0aGUgcmVtb3RlIE5WRSBzZXJ2aWNlIHR5cGUuIFdoZW4gTDIgTlZFIHNlcnZpY2Ug dHlwZSBpcyB1c2VkLCBOVkUganVzdCBtYWludGFpbnMgVFMgTUFDIGFkZHJlc3Nlcy4gQm90aCBj YXNlcyBjYW4gYmUgaW1wbGVtZW50ZWQgYnkgRVZQTiBzb2x1dGlvbi4NCg0KV0g+IGRyYWZ0LXNh amFzc2ktbDJ2cG4tZXZwbi1pbnRlci1zdWJuZXQtZm9yd2FyZGluZy0wMiBkZXNjcmliZXMgdGhl IElSQiBjYXNlDQoNClRoZXJlIGFyZSBwbGFjZXMgd2UgbmVlZCB0byB1c2UgTDIgVk5zLiBGb3Ig ZXhhbXBsZSwgYWxsIFRTZXMgaW4gYSBWTiBoYXZlIHRoZSBzYW1lIElQIGFkZHJlc3MgYnV0IGRp ZmZlcmVudCBNQUMgYWRkcmVzc2VzOyAgdGhlcmUgaXMgYnJvYWRjYXN0L211bHRpY2FzdCB0cmFm ZmljIGluIGEgVk47IG5vbi1JUCBwYWNrZXQuIEhvd2V2ZXIsIHdlIGRvbuKAmXQgd2FudCB0byBt YWtlIGEgY29tcGxleCBFVlBOIHNvbHV0aW9uIHRvIHNvbHZlIHRoZSBjYXNlIHRoYXQgTDNWTiBj YW4gZWFzaWx5IGFkZHJlc3MuDQoNCldIPiBzZWUgZHJhZnQtc2FqYXNzaS1sMnZwbi1ldnBuLWlu dGVyLXN1Ym5ldC1mb3J3YXJkaW5nLTAyIGl0IGRlc2NyaWJlcyBpdCBhbGwuIEFzIEkgc2FpZCBu b3QgYWxsIHVzZSBjYXNlIGNhbiBiZSBkb25lIHdpdGggTDNWUE4gYW5kIHRoaXMgaXMgcmVxdWly ZWQuDQoNClJlZ2FyZHMsDQpMdWN5DQoNCg0KDQoNCg0KDQoNCkZyb206IEhlbmRlcmlja3hIaSBX aW4sLCBXaW0gKFdpbSkgW21haWx0bzp3aW0uaGVuZGVyaWNreEBhbGNhdGVsLWx1Y2VudC5jb21d DQpTZW50OiBGcmlkYXksIE5vdmVtYmVyIDA4LCAyMDEzIDI6MTggUE0NClRvOiBMdWN5IHlvbmc7 IGwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBjb21t ZW50IG9uIGRyYWZ0LXJhYmFkYW4tbDJ2cG4tZXZwbi1wcmVmaXgtYWR2ZXJ0aXNlbWVudA0KDQpM dWN5LCBkaWQgeW91IHJlYWQgdGhlIGRyYWZ0IGFuZCBpcyBleHBsYWluZWQgaW4gc2VjdGlvbiA2 Lg0KU2hvdyBhbiBleGFtcGxlIG9uIGhvdyB5b3UgZG8gdGhlIHNjZW5hcmlv4oCZcyB3aXRoIFJU MiBhbmQgeW91IHdpbGwgc2VlIHdoeSB0aGlzIGlzIGxlc3MgZWZmaWNpZW50L3NjYWxhYmxlICsg ZG9lcyBub3Qgc3VwcG9ydCBhbGwgc2NlbmFyaW/igJlzIGluIHRoZSBkcmFmdCBsaWtlIEVTSSBO SC4NCg0KRS1WUE4gZGlzdHJpYnV0ZXMgaG9zdCByb3V0ZXMgdXNpbmcgUlQtMjogKElQKSArIE1B QyBhbmQgdGhlc2UgY2FuIGJlIGFuIGludGVyZmFjZSBlLmcuIEFuZCBwcmVmaXhlcyBjYW4gZXhp c3RzIGJlaGluZCB0aGVtLg0KDQpGcm9tOiBMdWN5IHlvbmcgPGx1Y3kueW9uZ0BodWF3ZWkuY29t PG1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbT4+DQpEYXRlOiBGcmlkYXkgOCBOb3ZlbWJlciAy MDEzIDIyOjEwDQpUbzogImwydnBuQGlldGYub3JnPG1haWx0bzpsMnZwbkBpZXRmLm9yZz4iIDxs MnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5vcmc+Pg0KU3ViamVjdDogY29tbWVudCBv biBkcmFmdC1yYWJhZGFuLWwydnBuLWV2cG4tcHJlZml4LWFkdmVydGlzZW1lbnQNCg0KSGkgQXV0 aG9ycywNCg0KSSBhbSBub3QgY29udmluY2VkIGlmIFJUIDUgaXMgbmVjZXNzYXJ5IGZvciB0aGUg dXNlIGNhc2VzIHlvdSBzcGVjaWZpZWQgaW4gdGhlIGRyYWZ0IChvciBwcmVzZW50YXRpb24pLiBJ TU86IFJUMiBpcyBzdWZmaWNpZW50IHRvIHN1cHBvcnQgYWxsIHRoZSBjYXNlcy4NClRoZXJlIGlz IGEgZHJhZnQteW9uZy1udm8zLW52ZSwgd2hpY2ggY292ZXJzIGFsbCB0aGUgTDIgb3ZlcmxheSBj YXNlcywgd2hpY2ggY2FuIGJlIGltcGxlbWVudGVkIGJ5IEVWUE4gd2l0aCBSVDIuDQoNCk9uZSBx dWVzdGlvbiwgd2h5IEVWUE4gc2VydmljZSBhbGxvdyB0byBWQVAgYmVpbmcgYW4gSVAgaW50ZXJm YWNlPw0KDQpUaGFua3MsDQpMdWN5DQo= --_000_82FB08F009780940837EB830C283F28408E8C1ADFR711WXCHMBA05z_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNl dGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9v biBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi QmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxT dHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzAwNzBDMDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMwMDcwQzA7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjojMDA3MEMwO30NCnNwYW4uRW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzAw NzBDMDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8Zm9udCBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+VGhleSBhcmUgZGVzY3JpYmVkIGluIHRoZSBkcmFmdC4NCjxicj4NCjxicj4N CkNoZWVycywgPGJyPg0KV2ltIDxicj4NCl9fX19fX19fX19fX19fX19fIDxicj4NCnNlbnQgZnJv bSBibGFja2JlcnJ5PC9mb250Pjxicj4NCiZuYnNwOzxicj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxmb250IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48Yj5Gcm9tPC9iPjogTHVjeSB5b25n IFttYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb21dDQo8YnI+DQo8Yj5TZW50PC9iPjogVHVlc2Rh eSwgTm92ZW1iZXIgMTIsIDIwMTMgMDc6MTQgUE08YnI+DQo8Yj5UbzwvYj46IEhlbmRlcmlja3gs IFdpbSAoV2ltKTsgbDJ2cG5AaWV0Zi5vcmcgJmx0O2wydnBuQGlldGYub3JnJmd0OyA8YnI+DQo8 Yj5TdWJqZWN0PC9iPjogUkU6IGNvbW1lbnQgb24gZHJhZnQtcmFiYWRhbi1sMnZwbi1ldnBuLXBy ZWZpeC1hZHZlcnRpc2VtZW50IDxicj4NCjwvZm9udD4mbmJzcDs8YnI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzAwNzBDMCI+V2ltLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+ UGxlYXNlIGNsYXJpZnkgeW91ciByZWFsIHVzZSBjYXNlLiAmbmJzcDtJbiB5b3VyIHJlYWwgdXNl IGNhc2UsIHdoZW4gdXNpbmcgYSBmaXJld2FsbCwgZG9lcyBpdCB1c2Ugd2l0aCBhIGdhdGV3YXkg dG9nZXRoZXIgb3Igbm90LiBJZiBub3QsIHRoZSBmaXJld2FsbCBpcyBhIGp1c3QgbWlkZGxlIGJv eCAod2lyZWQpIGFuZCBkb2VzIG5vdCBwYXJ0aWNpcGF0ZSBpbiB0aGUNCiBMMlZOIHJvdXRpbmcu IElmIGl0IHdvcmtzIHdpdGggdGhlIGdhdGV3YXksIG9ubHkgZ2F0ZXdheSBwYXJ0aWNpcGF0ZXMg aW4gdGhlIEwyVk4sICZuYnNwO25vdCB0aGUgZmlyZXdhbGwuIFRoZSBjb25maWd1cmF0aW9uIGJl dHdlZW4gZ2F0ZXdheSBhbmQgZmlyZXdhbGwgaXMgbG9jYWwsIG5vdCByZWxhdGVkIHRvIHRoZSBM MlZOLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMDA3MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+THVjeTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3 MEMwIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEhlbmRl cmlja3gsIFdpbSAoV2ltKSBbbWFpbHRvOndpbS5oZW5kZXJpY2t4QGFsY2F0ZWwtbHVjZW50LmNv bV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBOb3ZlbWJlciAxMiwgMjAxMyAxMToxMSBB TTxicj4NCjxiPlRvOjwvYj4gTHVjeSB5b25nOyBsMnZwbkBpZXRmLm9yZzxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogY29tbWVudCBvbiBkcmFmdC1yYWJhZGFuLWwydnBuLWV2cG4tcHJlZml4LWFk dmVydGlzZW1lbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPkluLWxp bmU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZyb206IDwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5MdWN5IHlvbmcgJmx0OzxhIGhyZWY9 Im1haWx0bzpsdWN5LnlvbmdAaHVhd2VpLmNvbSI+bHVjeS55b25nQGh1YXdlaS5jb208L2E+Jmd0 Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5IDEyIE5vdmVtYmVyIDIwMTMgMTk6MDU8YnI+DQo8 Yj5UbzogPC9iPldpbSBIZW5kZXJpY2t4ICZsdDs8YSBocmVmPSJtYWlsdG86d2ltLmhlbmRlcmlj a3hAYWxjYXRlbC1sdWNlbnQuY29tIj53aW0uaGVuZGVyaWNreEBhbGNhdGVsLWx1Y2VudC5jb208 L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmwydnBuQGlldGYub3JnIj5sMnZwbkBpZXRm Lm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpsMnZwbkBpZXRmLm9yZyI+bDJ2cG5A aWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SRTogY29tbWVudCBvbiBkcmFm dC1yYWJhZGFuLWwydnBuLWV2cG4tcHJlZml4LWFkdmVydGlzZW1lbnQ8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDA3MEMwIj5XaW0sIFBsZWFzZSBzZWUgYmVsb3cuPC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsYWNrIj4gSGVuZGVyaWNreCwgV2ltIChXaW0pIFs8YSBocmVmPSJtYWls dG86d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuY29tIj5tYWlsdG86d2ltLmhlbmRlcmlj a3hAYWxjYXRlbC1sdWNlbnQuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBO b3ZlbWJlciAxMiwgMjAxMyAxOjIyIEFNPGJyPg0KPGI+VG86PC9iPiBMdWN5IHlvbmc7IDxhIGhy ZWY9Im1haWx0bzpsMnZwbkBpZXRmLm9yZyI+bDJ2cG5AaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBjb21tZW50IG9uIGRyYWZ0LXJhYmFkYW4tbDJ2cG4tZXZwbi1wcmVmaXgt YWR2ZXJ0aXNlbWVudDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+THVj eSB5b25nICZsdDs8YSBocmVmPSJtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20iPmx1Y3kueW9u Z0BodWF3ZWkuY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VHVlc2RheSAxMiBOb3ZlbWJl ciAyMDEzIDA1OjExPGJyPg0KPGI+VG86IDwvYj5XaW0gSGVuZGVyaWNreCAmbHQ7PGEgaHJlZj0i bWFpbHRvOndpbS5oZW5kZXJpY2t4QGFsY2F0ZWwtbHVjZW50LmNvbSI+d2ltLmhlbmRlcmlja3hA YWxjYXRlbC1sdWNlbnQuY29tPC9hPiZndDssIEx1Y3kgeW9uZyAmbHQ7PGEgaHJlZj0ibWFpbHRv Omx1Y3kueW9uZ0BodWF3ZWkuY29tIj5sdWN5LnlvbmdAaHVhd2VpLmNvbTwvYT4mZ3Q7LCAmcXVv dDs8YSBocmVmPSJtYWlsdG86bDJ2cG5AaWV0Zi5vcmciPmwydnBuQGlldGYub3JnPC9hPiZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmwydnBuQGlldGYub3JnIj5sMnZwbkBpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJFOiBjb21tZW50IG9uIGRyYWZ0LXJhYmFkYW4tbDJ2 cG4tZXZwbi1wcmVmaXgtYWR2ZXJ0aXNlbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPldpbSw8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPldoZW4gdXNpbmcgYSAoY2VudHJhbGl6ZWQp IGdhdGV3YXkgdG8gcHJvdmlkZSBleHRlcm5hbCBuZXR3b3JrIGNvbm5lY3Rpb24gZm9yIGFuIEwy IFZOLCBJIGFncmVlLCBpdCBpcyBuZWNlc3NhcnkgZm9yIHRoZSBnYXRld2F5IHRvIGFkdmVydGlz ZSBpdHMgSVAgaG9zdCBhZGRyZXNzIGFuZCBNQUMgdG8gYWxsIHRoZSBOVkVzIGluIHRoZSBMMlZO LiBUaGlzIGNhbg0KIGJlIGRvbmUgYnkgdGhlIFJUMiwgcmlnaHQ/IE5WRXMgYWxzbyB1c2UgUlQy IHRlbmFudCBJUC9NQUMgYWRkcmVzc2VzLiBUaHVzLCBlYWNoIE5WRSB3aWxsIGtub3cgdGhlIGdh dGV3YXkgSVAgaG9zdCBhbmQgTUFDIGFkZHJlc3MgYW5kIHBlcmZvcm0gdGhlIHByb3h5IEFSUCBm dW5jdGlvbiwgaS5lLiB0ZXJtaW5hdGUgdGhlIEFSUCByZXF1ZXN0cyBpZiB0aGUgcmVxdWVzdGVk IHRlbmFudCBzeXN0ZW1zIChpbmNsdWRpbmcgZ2F0ZXdheSkgaXMgbm90DQogaW4gbG9jYWwsIGFu ZCBzZW5kIGJhY2sgdGhlIHJlcXVlc3RlZCAmbmJzcDtNQUMgaW4gQVJQIHJlcGx5LiBUaHVzLCB0 ZW5hbnQgc3lzdGVtIHdpbGwgc2VuZCBhbiBMMiBmcmFtZSB3aXRoIGRlc2lnbmF0aW9uIHRlbmFu dCBzeXN0ZW0gb3IgZ2F0ZXdheSBNQUMgaW4gZE1BQyB0byBhdHRhY2hlZCBOVkUsIHRoZSBOVkUg anVzdCBwZXJmb3JtcyB0aGUgdGFibGUgbG9va3VwIHRvIG9idGFpbiB0aGUgb3V0ZXIgYWRkcmVz cy4gVGhlcmUgaXMgbm8gSVAgcm91dGluZw0KIHRhYmxlIG9uIE5WRXMgYmVjYXVzZSBvZiB0aGUg TDJWTi4gJm5ic3A7V2hhdCBpcyB0aGUgcHJvYmxlbSBoZXJlPyBXaHkgbmVlZCB0byB1c2UgUlQ1 IHRvIGNvbnZleSB0aGUgR1cgSVAvTUFDIGluZm8/ICZuYnNwO1BsZWFzZSBleHBsYWluLCBJIG1h eSBtaXNzIHNvbWUgcGFydCBpbiBudXRzaGVsbC48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+V0gmZ3Q7IGlmIHlvdSBsb29rIHRvIHRoZSBk cmF3aW5ncyBpbiB0aGUgc2xpZGVzIHRoZSBOVkUocykgY2FuIGFsc28gaGF2ZSBJUCBwcmVmaXhl cyBiZWhpbmQgdGhlbS4gRS5nLiBBIGZpcmV3YWxsLCBldGMuIHRoaXMgaXMgd2hhdCB3ZSBhcmUg cmVmZXJyaW5nIHRvIGluIHRoZSBkcmFmdC48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+U2VlIGZpZyAx LzIvMy80LzUuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDcwQzAiPltMdWN5XSBPSywgdGhpcyBpcyBob3cgdG8gZGVhbCB3aXRoIG5ldHdvcmsgYXBwbGlh bmNlcy4gRG8gd2Ugd2FudCB0byB0cmVhdCBpdCBhcyBhIG1pZGRsZSBib3gsIG9yIGEgdGVuYW50 IHN5c3RlbSB0aGF0IGhhcyBtdWx0aXBsZSBhZGRyZXNzZXM/IEkgZ3Vlc3MsIHlvdSB3YW50IHRv IGFkZHJlc3MgaXQgYXMgdGhlIGxhdHRlci4gRXZlbiBpdCBpcw0KIHRoZSBsYXR0ZXIsIElNTywg c3VjaCB0ZW5hbnQgc3lzdGVtIHNob3VsZCBub3QgYWR2ZXJ0aXNlIHRoZSBwcmVmaXggaW4gYW4g TDIgVk4gYXQgYWxsIGJlY2F1c2UgaXQgc2VydmVzIG1pZGRsZSBib3ggZnVuY3Rpb24gb25seS4g SWYgYSB0ZW5hbnQgc3lzdGVtIGlzIGEgZ2F0ZXdheSwgaXQgbmVlZHMgdG8gYWR2ZXJ0aXNlIGl0 c2VsZiBhcyBnYXRld2F5IChub3QgdGhlIHByZWZpeCBmcm9tIG90aGVyIFZOKS4gVGhlbiBpdCB3 aWxsIGJlIHRoZQ0KIHNhbWUgY2FzZSBhcyB0aGUgZm9sbG93aW5nIGRlc2NyaXB0aW9uLiBEb2Vz IHRoaXMgbWFrZSBzZW5zZT88L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2si PldIMiZndDsgdGhlcmUgYXJlIHJlYWwgdXNlIGNhc2VzIGFzIHdlIGRlc2NyaWJlIHdoaWNoIGFy ZSByZXF1aXJlZCB0byBiZSBzdXBwb3J0ZWQgYW5kIGhlbmNlIHRoaXMgaXMgd2hhdCB0aGUgZHJh ZnQgaXMgcHJvcG9zaW5nIGFuZCBhcyB3ZSBzYWlkIGJlZm9yZSBMM1ZQTiBBRkkvU0FGSSBkb2Vz IG5vdCBkbyB0aGUgam9iLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDA3MEMwIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzAwNzBDMCI+V2hlbiB1c2luZyBhIGdhdGV3YXkgdG8gcHJvdmlkZSBleHRlcm5hbCBu ZXR3b3JrIGNvbm5lY3Rpb24gZm9yIGFuIEwzIFZOLCBOVkVzIHVzZSB0aGVpciBNQUMgYWRkcmVz cyBpbiBBUlAgcmVwbHkgaWYgVkFQIGlzIEwyIGFjY2VzcyBpbnRlcmZhY2UuIFRoZSBMMiBmcmFt ZSBmcm9tIGEgdGVuYW50IHN5c3RlbSB3aWxsIGJlIHRlcm1pbmF0ZWQgYXQgTlZFcyByZWdhcmRs ZXNzDQogdGhlIGRlc3RpbmF0aW9uIHRlbmFudCBzeXN0ZW0gaXMgaW4gdGhlIHNhbWUgVk4gb3Ig bm90LiBOVkVzIHNob3VsZCBoYXZlIGFsbCB0aGUgSVAgcm91dGVzIGluIHRoZSBWTi4gV2hlbiBO VkUgcGVyZm9ybXMgYSBsb29rdXAgYW5kIGlzIG5vdCBhYmxlIHRvIGZpbmQgdGhlIG1hdGNoaW5n IG9uZSwgaXQgbWVhbnMgdGhlIHBhY2tldCBmb3IgdGhlIGV4dGVybmFsLiAmbmJzcDtTaW5jZSB0 aGUgZ2F0ZXdheSBhZHZlcnRpc2VzIGl0cyBJUCBob3N0IGFkZHJlc3MNCiB0byBOVkVzIGFzIHRo ZSBnYXRld2F5IGZvciB0aGUgTDNWTiwgTlZFcyB3aWxsIGZvcndhcmQgdGhlIHBhY2tldHMgZ29p bmcgdG8gZXh0ZXJuYWwgdG8gdGhlIGdhdGV3YXkuICZuYnNwO0luIHRoaXMgY2FzZSwgdGhlIE5W RSBhY3RzIGFzIHRoZSBmaXJzdC1ob3Agcm91dGVyLCB0aGUgZ2F0ZXdheSBpcyB0aGUgbGFzdC1o b3AgaW4gdGhlIFZOLiAmbmJzcDtZb3UgYXJlIHJpZ2h0LCBpdCBpcyBuZWNlc3NhcnkgZm9yIGEg Z2F0ZXdheSB0byBhZHZlcnRpc2UgaXRzDQogcm9sZSBiZXNpZGVzIGl0cyBJUCBhZGRyZXNzLiZu YnNwOyBJZiB0aGlzIGlzIG5vdCB0aGVyZSwgc2hvdWxkIGltcHJvdmUgdGhlIHByb3RvY29sLjwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+UmVnYXJkaW5nIHRo ZSBJUkIgY2FwYWJpbGl0eSwgdGhpcyBpcyBteSB2aWV3IGFib3V0IElSQiBpbXBsZW1lbnRhdGlv biBpbiB2aXJ0dWFsIG92ZXJsYXkgZW52aXJvbm1lbnQuPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iNjkxIiBoZWln aHQ9IjIxOCIgaWQ9IlBpY3R1cmVfeDAwMjBfMSIgc3JjPSJjaWQ6aW1hZ2UwMDEucG5nQDAxQ0VE RkEwLkU5NERCQjMwIj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw NzBDMCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcw QzAiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMw Ij5GaWd1cmUgc2hvd3MgdHdvIEwyVk5zLCBWTnggYW5kIFZOei4mbmJzcDsgTlZFMSBhbmQgTlZF MiBhcmUgbWVtYmVyIG9mIGJvdGggVk5zLiBJZiBOVkUxIGFuZCBOVkUyIGltcGxlbWVudCBMMyBk aXN0cmlidXRlZCBnYXRld2F5IGZ1bmN0aW9ucyBhbmQgaGF2ZSB0aGUgc2FtZSBNQUMgYWRkcmVz cyBmb3IgdGhlIEwzZEdXLiBXaGVuIE5WRXMgYWR2ZXJ0aXNlIGJvdGggVGVuYW50DQogc3lzdGVt IElQIGFuZCBNQUMgYWRkcmVzc2VzLCBlYWNoIE5WRSBoYXZlIGFsbCB0aGUgaW5mb3JtYXRpb24g YWJvdXQgdGVuYW50IHN5c3RlbXMgaW4gYm90aCBWTnMuIE5WRXMgc3RpbGwgdGVybWluYXRlcyB0 aGUgQVJQIHJlcXVlc3RzIGFuZCBwcm92aWRlIHRoZSBNQUMgZm9yIHRoZSByZW1vdGUgdGVuYW50 IHN5c3RlbSBpbiB0aGUgc2FtZSBWTi4gTlZFcyByZXR1cm5zIEwzZEdXIGFkZHJlc3NlcyBmb3Ig dGhlIEdXIEFSUCByZXF1ZXN0IG9yDQogaWYgbm8gbWF0Y2hpbmcgTUFDIGFyZSBmb3VuZGVkLiAm bmJzcDtUaHVzLCBvbmx5IHRoZSBMM2RHVyBhdCBpbmdyZXNzIE5WRSBwcm9jZXNzIGludGVyLVZO IHRyYWZmaWMgZm9yd2FyZGluZywgaS5lLiB0aGUgdHJhZmZpYyBmcm9tIFZOeCBUUyBvbiBOVkUx IGdvZXMgdGhyb3VnaCB0aGUgTDNkR1cgb24gTlZFMSB0byByZWFjaCB0aGUgVk55IFRTIG9uIE5W RTEgb3IgVk55IFRTIG9uIE5WRTIuICZuYnNwO1dpbGwgdGhpcyBtYWtlIHNlbnNlIHRvIHlvdT88 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+ V0gmZ3Q7IHllcyBidXQgdGhlIHByZWZpeCBkcmFmdCBpcyBvcnRob2dvbmFsIHRvIHRoaXMuIFNv IGxldHMgbm90IG1peCB0aGVzZSB0aGluZ3MuIFRoZSBkcmFmdCBkZXNjcmliaW5nIElSQiBpcyB0 aGUgZm9sbG93aW5nIGZvciB3aGljaCB5b3UgYXJlIGEgY28tYXV0aG9yIGFuZCB3ZSBhcmUgc3Vi bWl0dGluZyBhbiB1cGRhdGUgdG8gc2hvdw0KIHRoZSAyIGFyY2hpdGVjdHVyZXMgc3VwcG9ydGlu ZyB0aGlzOjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+ PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNhamFzc2ktbDJ2cG4t ZXZwbi1pbnRlci1zdWJuZXQtZm9yd2FyZGluZy0wMiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXNhamFzc2ktbDJ2cG4tZXZwbi1pbnRlci1zdWJuZXQtZm9yd2FyZGluZy0wMjwv YT48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+ W0x1Y3ldIHllcywgd2UgcHJvdmlkZSBhIGxvdCBvZiBpbnB1dHMgb24gZXZwbiBvdmVybGF5IGFu ZCBpbnRlcndvcmtpbmcgZHJhZnRzLiBHbGFkIHRvIGNvbnRpbnVhbGx5IHdvcmsgb24gdGhlc2Ug ZHJhZnRzLiBIb3dldmVyLCB0aGVzZSBkcmFmdHMgYXJlIHN0aWxsIGluZGl2aWR1YWwgZHJhZnRz LiBBcyB3ZSBhcmUgbW9yZSBhbmQgbW9yZSBjbGVhcg0KIG9uIHRoZSBuZXR3b3JrIHZpcnR1YWxp emF0aW9uIG92ZXJsYXkgZm9yIHRoZSBjbG91ZCBhcHBsaWNhdGlvbnMsIHdlIG5lZWQgdXBkYXRl IHRoZSBkZXNjcmlwdGlvbnMgKGFuIGltcGxlbWVudGF0aW9uKSBpbiB0aGVzZSBkcmFmdHMgdG8g bWFrZSBpdCBjbGVhci4gQXMgeW91IGF3YXJlLCBuZWl0aGVyIG9mIHVzIHdvcmtzIG9uIHRoZXNl IGRyYWZ0cyByZWNlbnRseS48L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2si PldIMiZndDsgd2UgZGlkIGluIHRoZSBsYXN0IElFVEYgYW5kIHRoZSB1cGRhdGVzIHdpbGwgYmUg cmVmbGVjdGVkIGJlZm9yZSB0aGUgZW5kIG9mIHRoZSB5ZWFyPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPlRoYW5rcyw8 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+THVjeTwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJzcDs8L3NwYW4+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+IEhlbmRlcmlja3gsIFdpbSAoV2ltKSBbPGEgaHJlZj0ibWFp bHRvOndpbS5oZW5kZXJpY2t4QGFsY2F0ZWwtbHVjZW50LmNvbSI+bWFpbHRvOndpbS5oZW5kZXJp Y2t4QGFsY2F0ZWwtbHVjZW50LmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBO b3ZlbWJlciAxMSwgMjAxMyAyOjIyIEFNPGJyPg0KPGI+VG86PC9iPiBMdWN5IHlvbmc7IDxhIGhy ZWY9Im1haWx0bzpsMnZwbkBpZXRmLm9yZyI+bDJ2cG5AaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBjb21tZW50IG9uIGRyYWZ0LXJhYmFkYW4tbDJ2cG4tZXZwbi1wcmVmaXgt YWR2ZXJ0aXNlbWVudDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpi bGFjayI+SW4tbGluZTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkx1 Y3kgeW9uZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmx1Y3kueW9uZ0BodWF3ZWkuY29tIj5sdWN5Lnlv bmdAaHVhd2VpLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSAxMSBOb3ZlbWJl ciAyMDEzIDA4OjQzPGJyPg0KPGI+VG86IDwvYj5XaW0gSGVuZGVyaWNreCAmbHQ7PGEgaHJlZj0i bWFpbHRvOndpbS5oZW5kZXJpY2t4QGFsY2F0ZWwtbHVjZW50LmNvbSI+d2ltLmhlbmRlcmlja3hA YWxjYXRlbC1sdWNlbnQuY29tPC9hPiZndDssIEx1Y3kgeW9uZyAmbHQ7PGEgaHJlZj0ibWFpbHRv Omx1Y3kueW9uZ0BodWF3ZWkuY29tIj5sdWN5LnlvbmdAaHVhd2VpLmNvbTwvYT4mZ3Q7LCAmcXVv dDs8YSBocmVmPSJtYWlsdG86bDJ2cG5AaWV0Zi5vcmciPmwydnBuQGlldGYub3JnPC9hPiZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmwydnBuQGlldGYub3JnIj5sMnZwbkBpZXRmLm9yZzwvYT4m Z3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJFOiBjb21tZW50IG9uIGRyYWZ0LXJhYmFkYW4tbDJ2 cG4tZXZwbi1wcmVmaXgtYWR2ZXJ0aXNlbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPldpbSw8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPkkgcmVhZCB0aGUgZHJhZnQgYW5kIHN0aWxs IHRoaW5rIHRoYXQgYWxsIHRoZSB1c2UgY2FzZXMgd29yayB3ZWxsIHdpdGggUlQyLiAmbmJzcDtI ZXJlIGFyZSBteSB2aWV3cyBob3cgdGhlc2UgdXNlIGNhc2VzIGluIHNlY3Rpb24gNSBjYW4gYmUg aW1wbGVtZW50ZWQgd2l0aG91dCBSVDU8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDcwQzAiPlVzZSBjYXNlIDEgY2FuIGJlIGRvbmUgYnkgYW4gTDMgVk4gb3ZlcmxheSwg c2F5IFZOMTAsIGFuZCBhIGdhdGV3YXkgYXQgRENHVzEgYW5kIERDR1cyLiBUaGUgZ2F0ZXdheSBp cyB1c2VkIHRvIGludGVyY29ubmVjdCB0aGUgVk4gMTAgYW5kIFdBTi48L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+VGhlIFZOMTAgcm91dGUgdGhlIHRyYWZm aWMgb24gU04gMSBhbmQgU04yLCBTTjMsIGFuZCBJUDItSVA1LiZuYnNwOyBJIGNhbGwgdGhpcyBp bXBsZW1lbnRhdGlvbiDigJxMM1ZOIHBsdXMgYSBnYXRld2F54oCdIFdoeSBkbyB5b3Ugd2FudCB0 byB1c2UgYW4gTDIgVk4gb3ZlcmxheSBoZXJlPzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2si PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5XSCZndDsgeW91IGRvbuKAmXQgaGF2ZSBhIEdX IElQIGluIHRoZSBMM1ZQTiBBRkkvU0FGSSwgc28geW91IHdpbGwgbmVlZCB0byBkZWZpbmUgYSBu ZXcgcm91dGUgdG8gZG8gdGhpcyBlZmZpY2llbnRseTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPlVzZSBjYXNlIDIgYW5k IHVzZSBjYXNlIDQgYXJlIGFib3V0IG11bHRpLWhvbWluZy4gSW4gdGhlIGNhc2UgMiwgVFMgYW5k IE5WRSBhcmUgY28tbG9jYXRlZDsgaW4gdGhlIGNhc2UgNCwgVFMgYW5kIE5WRSBhcmUgcGh5c2lj YWxseSBzZXBhcmF0ZWQuICZuYnNwO0ZpcnN0IG9mIGFsbCwgSU1PLCB3aGVuIFRTIGFuZCBOVkUg Y28tbG9jYXRlIG9uIHRoZSBzYW1lIHNlcnZlciwNCiBtdWx0aS1ob21lZCBUUyBpcyBub3QgbmVj ZXNzYXJ5LiBUaGUgdXNlIGNhc2UgNCBpcyBqdXN0IHRoZSB1c2UgY2FzZSAxIHdpdGggbXVsdGkt aG9taW5nLiBUaHVzLCBpdCBjYW4gYmUgaW1wbGVtZW50ZWQgYnkg4oCcTDNWTiBwbHVzIGEgZ2F0 ZXdheeKAnSB3LyBWUlJQLiAmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtjb2xvcjpibGFjayI+V0gmZ3Q7IHRoZXJlIGlzIG5vIFZSUlAgaW4gdGhlc2Ug Y2FzZXMgc2luY2UgdGhlIGFwcGxpYW5jZSBpcyBhIGJ1bXAgaW4gdGhlIHdpcmUgZm9yIHVzZSBj YXNlIDQgc28gdGhleSBkb27igJl0IGV2ZW4gc3BlYWsgSVAsIHNvIHlvdSBoYXZlIGFuIHVuZGVm aW5lZCBOSCwgd2hpY2ggaXMgYWxzbyBub3QgZXZhZGFibGUgaW4gdGhlIEwzVlBuIEFGSS9TQUZJ DQogYW5kIHRoZXJlIGlzIG5vIEVTSSBOSCBwb3NzaWJsZTwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPkluIHlvdXIgdXNl IGNhc2UgMywgRVZJMTAgc2hvdWxkIGJlIHJlcGxhY2VkIGJ5IGFuIEwzIG92ZXJsYXkuIFRoZSBW UkYgb24gdGhlIE5WRTEgYWN0cyBhcyB0aGUgTDMgZGlzdHJpYnV0ZWQgZ2F0ZXdheSBmb3IgdGhl IEVWTjEgYW5kIEVWTjIuICZuYnNwO1RoZSBWUkYgb24gdGhlIE5WRTIgYWN0cyBhcyB0aGUgTDMg ZGlzdHJpYnV0ZWQgZ2F0ZXdheSBmb3IgdGhlIEVWTjINCiBhbmQgRVZOMy4gVGhlIFZSRnMgb24g REdXMSBhbmQgREdXMiBhY3QgYXMgdGhlIGdhdGV3YXkgYmV0d2VlbiB0aGUgTDMgb3ZlcmxheSBh bmQgV0FOLiBJZiBOVkUxIGFuZCBOVkUyIHVzZSBSVDIgYWR2ZXJ0aXNlcyBUUyBJUC9NQUMsJm5i c3A7IE5WRTEgd2lsbCBrbm93IElQIHN1Ym5ldC9wcmVmaXggYXNzb2NpYXRpbmcgdG8gRVZOMSBh bmQgRVZOMiwgYW5kIElQIHN1Ym5ldC9wcmVmaXggYXNzb2NpYXRpbmcgdG8gdGhlIEwzIG92ZXJs YXkuIFdoZW4gTlZFMQ0KIHJlY2VpdmVzIGEgcGFja2V0IGZyb20gSVAxIGFuZCB0aGUgcGFja2V0 IGhhcyB0aGUgZGVzdGluYXRpb24gdG8gU04xLCB0aGUgcGFja2V0IGRNQUMgYWRkcmVzcyB3aWxs IGJlIHRoZSBNQUMgYWRkcmVzcyBmb3IgdGhlIGRpc3RyaWJ1dGVkIGdhdGV3YXkgdGhhdCBpcyB0 aGUgc2FtZSBmb3IgYWxsIHRoZSBOVkVzLiBXaGVuIE5WRSBzZWVzIHRoaXMgYWRkcmVzcywgaXQg d2lsbCBwZXJmb3JtIHRoZSBWUkYgdGFibGUgbG9va3VwIGJ5IHVzaW5nIHRoZQ0KIGRlc3RpbmF0 aW9uIElQIGFkZHIgb24gdGhlIHBhY2tldCwgd2hpY2ggcmVzdWx0cyB0aGUgSVAgYWRkciBpcyBh c3NvY2lhdGVkIHRvIHRoZSBFVk4yLCB0aGVuIE5WRSBwZXJmb3JtcyB0aGUgdGFibGUgbG9vay11 cCBpbiBFVkktMiB0aGF0IGhhcyBib3RoIElQL01BQyB0byBvdXRlciAob3IgVkFQKSBhZGRyZXNz IG1hcHBpbmcsIHNvIGl0IHdpbGwgcmVwbGFjZSB0aGUgZE1BQyBhZGRyIG9uIHRoZSBwYWNrZXQg d2l0aCB0aGUgcmVhbCBkZXN0aW5hdGlvbg0KIE1BQyBhZGRyIGFuZCBzZW5kIHRvIHRoZSBWQVAg dGhhdCBTTjEgYXNzb2NpYXRlZCB0by4gJm5ic3A7V2hlbiBOVkUxIHJlY2VpdmVzIGEgcGFja2V0 IGZyb20gSVAxIGFuZCB0aGUgcGFja2V0IGhhcyB0aGUgZGVzdGluYXRpb24gaW4gdGhlIFdBTiBu ZXR3b3JrLCB0aGUgZE1BQyBvbiB0aGUgcGFja2V0IGlzIGFsc28gdGhlIE1BQyBhZGRyZXNzIGZv ciB0aGUgZGlzdHJpYnV0ZWQgZ2F0ZXdheS4gU28gTlZFIHdpbGwgcGVyZm9ybSB0aGUgVlJGIHRh YmxlDQogbG9vay11cCBieSB1c2luZyB0aGUgZGVzdGluYXRpb24gSVAgb24gdGhlIHBhY2tldCwg d2hpY2ggcmVzdWx0cyB0byB0aGUgb3V0ZXIgSVAgYWRkcmVzcyBvbiBvbmUgb2YgREdXcywgc2F5 IERHVzEuIE5WRTEgYWRkcyB0aGUgTDMgVk4gSUQgYW5kIHRoZSBvdXRlciBoZWFkZXIgb24gdGhl IHBhY2tldCBwcmlvciBzZW5kaW5nIGl0IG91dC4gV2hlbiBER1cxIHJlY2VpdmVzIHRoZSBwYWNr ZXQsIGl0IHJlbW92ZXMgdGhlIHR1bm5lbCBoZWFkZXIgYW5kDQogdXNlcyB0aGUgTDMgVk4gSUQg b24gdGhlIHBhY2tldCB0byByZWFjaCB0aGUgdkdXIG9uIERHVzEuIFRoZSB2R1cgcGVyZm9ybSB0 aGUgcGFja2V0IHRyZWF0bWVudCBiZWZvcmUgc2VuZGluZyB0byB0aGUgV0FOLjwvc3Bhbj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5XSCZndDsgaXQg ZGVwZW5kcyBob3cgeW91IHdhbnQgdG8gZG8gdGhpcywgeW91IGNhbiBlaXRoZXIgZ28gcm91dGUg ZnJvbSBpbmdyZXNzIHcvbyBJUCBsb29rdXAgb24gaW5ncmVzcyBvciBkbyBhIGxvb2t1cCBvbiBl Z3Jlc3MuIEJvdGggb3B0aW9ucyBhcmUgcG9zc2libGUgYW5kIHJlcXVpcmVkIGZvciBzb21lIEhX IGluIHRoZSBtYXJrZXQuDQogRVZQTiBzdXBwb3J0cyBib3RoIGFscmVhZHksIHdoYXQgdGhpcyBk cmFmdCBpcyBkb2luZyBpcyBob3cgcHJlZml4ZXMgc2hvdWxkIGJlIHVzZWQgaW4gdGhpcyBlbnZp cm9ubWVudDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDcwQzAiPkwyL0wzIE5WRSBzZXJ2aWNlIHR5cGUgZGVzY3JpYmVkIGluIGRy YWZ0LXlvbmctbnYwMy1udmUgaXMgZm9yIHRoaXMgdXNlIGNhc2UuIFdoZW4gTDIvTDMgTlZFIHNl cnZpY2UgdHlwZSBpcyB1c2VkLCBOVkUgbWFpbnRhaW5zIGJvdGggVFMgSVAvTUFDIGFkZHJlc3Nl cyBidXQgbWF5IGFkdmVydGlzZSBib3RoIElQL01BQyBhZGRyZXNzZXMgb3Igb25lIG9mIHRoZQ0K IGFkZHJlc3MgZGVwZW5kaW5nIG9uIHRoZSByZW1vdGUgTlZFIHNlcnZpY2UgdHlwZS4gV2hlbiBM MiBOVkUgc2VydmljZSB0eXBlIGlzIHVzZWQsIE5WRSBqdXN0IG1haW50YWlucyBUUyBNQUMgYWRk cmVzc2VzLiBCb3RoIGNhc2VzIGNhbiBiZSBpbXBsZW1lbnRlZCBieSBFVlBOIHNvbHV0aW9uLjwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5X SCZndDsmbmJzcDtkcmFmdC1zYWphc3NpLWwydnBuLWV2cG4taW50ZXItc3VibmV0LWZvcndhcmRp bmctMDIgZGVzY3JpYmVzIHRoZSBJUkIgY2FzZTwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPlRoZXJlIGFyZSBwbGFjZXMg d2UgbmVlZCB0byB1c2UgTDIgVk5zLiBGb3IgZXhhbXBsZSwgYWxsIFRTZXMgaW4gYSBWTiBoYXZl IHRoZSBzYW1lIElQIGFkZHJlc3MgYnV0IGRpZmZlcmVudCBNQUMgYWRkcmVzc2VzOyAmbmJzcDt0 aGVyZSBpcyBicm9hZGNhc3QvbXVsdGljYXN0IHRyYWZmaWMgaW4gYSBWTjsgbm9uLUlQIHBhY2tl dC4gSG93ZXZlciwgd2UgZG9u4oCZdCB3YW50DQogdG8gbWFrZSBhIGNvbXBsZXggRVZQTiBzb2x1 dGlvbiB0byBzb2x2ZSB0aGUgY2FzZSB0aGF0IEwzVk4gY2FuIGVhc2lseSBhZGRyZXNzLiAmbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFj ayI+V0gmZ3Q7IHNlZSZuYnNwO2RyYWZ0LXNhamFzc2ktbDJ2cG4tZXZwbi1pbnRlci1zdWJuZXQt Zm9yd2FyZGluZy0wMiBpdCBkZXNjcmliZXMgaXQgYWxsLiBBcyBJIHNhaWQgbm90IGFsbCB1c2Ug Y2FzZSBjYW4gYmUgZG9uZSB3aXRoIEwzVlBOIGFuZCB0aGlzIGlzIHJlcXVpcmVkLjwvc3Bhbj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw NzBDMCI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcw QzAiPlJlZ2FyZHMsPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcw QzAiPkx1Y3k8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+ Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJz cDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDcwQzAiPiZuYnNwOzwv c3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiBIZW5kZXJpY2t4SGkgV2luLCwgV2lt IChXaW0pIFs8YSBocmVmPSJtYWlsdG86d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuY29t Ij5tYWlsdG86d2ltLmhlbmRlcmlja3hAYWxjYXRlbC1sdWNlbnQuY29tPC9hPl0NCjxicj4NCjxi PlNlbnQ6PC9iPiBGcmlkYXksIE5vdmVtYmVyIDA4LCAyMDEzIDI6MTggUE08YnI+DQo8Yj5Ubzo8 L2I+IEx1Y3kgeW9uZzsgPGEgaHJlZj0ibWFpbHRvOmwydnBuQGlldGYub3JnIj5sMnZwbkBpZXRm Lm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IGNvbW1lbnQgb24gZHJhZnQtcmFiYWRh bi1sMnZwbi1ldnBuLXByZWZpeC1hZHZlcnRpc2VtZW50PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5MdWN5LCBkaWQgeW91IHJlYWQgdGhlIGRyYWZ0IGFu ZCBpcyBleHBsYWluZWQgaW4gc2VjdGlvbiA2Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5TaG93IGFu IGV4YW1wbGUgb24gaG93IHlvdSBkbyB0aGUgc2NlbmFyaW/igJlzIHdpdGggUlQyIGFuZCB5b3Ug d2lsbCBzZWUgd2h5IHRoaXMgaXMgbGVzcyBlZmZpY2llbnQvc2NhbGFibGUgJiM0MzsgZG9lcyBu b3Qgc3VwcG9ydCBhbGwgc2NlbmFyaW/igJlzIGluIHRoZSBkcmFmdCBsaWtlIEVTSSBOSC48L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPkUtVlBOIGRpc3Ry aWJ1dGVzIGhvc3Qgcm91dGVzIHVzaW5nIFJULTI6IChJUCkgJiM0MzsgTUFDIGFuZCB0aGVzZSBj YW4gYmUgYW4gaW50ZXJmYWNlIGUuZy4gQW5kIHByZWZpeGVzIGNhbiBleGlzdHMgYmVoaW5kIHRo ZW0uPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+THVjeSB5b25nICZs dDs8YSBocmVmPSJtYWlsdG86bHVjeS55b25nQGh1YXdlaS5jb20iPmx1Y3kueW9uZ0BodWF3ZWku Y29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+RnJpZGF5IDggTm92ZW1iZXIgMjAxMyAyMjox MDxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOmwydnBuQGlldGYub3JnIj5s MnZwbkBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpsMnZwbkBpZXRmLm9y ZyI+bDJ2cG5AaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5jb21tZW50IG9u IGRyYWZ0LXJhYmFkYW4tbDJ2cG4tZXZwbi1wcmVmaXgtYWR2ZXJ0aXNlbWVudDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5IaSBB dXRob3JzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JIGFtIG5vdCBjb252aW5j ZWQgaWYgUlQgNSBpcyBuZWNlc3NhcnkgZm9yIHRoZSB1c2UgY2FzZXMgeW91IHNwZWNpZmllZCBp biB0aGUgZHJhZnQgKG9yIHByZXNlbnRhdGlvbikuIElNTzogUlQyIGlzIHN1ZmZpY2llbnQgdG8g c3VwcG9ydCBhbGwgdGhlIGNhc2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhlcmUgaXMgYSBkcmFmdC15b25n LW52bzMtbnZlLCB3aGljaCBjb3ZlcnMgYWxsIHRoZSBMMiBvdmVybGF5IGNhc2VzLCB3aGljaCBj YW4gYmUgaW1wbGVtZW50ZWQgYnkgRVZQTiB3aXRoIFJUMi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5PbmUgcXVlc3Rpb24sIHdoeSBFVlBOIHNlcnZpY2UgYWxsb3cgdG8gVkFQ IGJlaW5nIGFuIElQIGludGVyZmFjZT88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+THVjeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_82FB08F009780940837EB830C283F28408E8C1ADFR711WXCHMBA05z_-- --_004_82FB08F009780940837EB830C283F28408E8C1ADFR711WXCHMBA05z_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=3555; creation-date="Tue, 12 Nov 2013 18:14:39 GMT"; modification-date="Tue, 12 Nov 2013 18:14:39 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAArMAAADaCAMAAACCXTqSAAAAAXNSR0ICQMB9xQAAAGlQTFRFAAAA AAAAAwYLDQsKBAAACwYDAAAECgsNCgQAAAQKCAMAAAMIDQoIAwAADQgECAYDBAgNBAADCAoNAwAE AwMIBAAEBAQACAMDAAADAwADDQgKAwMDBAQEBAYICAgIAwQEBAQDCAYEAwQKoNCZ7QAAAAF0Uk5T AEDm2GYAAAAJcEhZcwAADsQAAA7EAZUrDhsAAAAZdEVYdFNvZnR3YXJlAE1pY3Jvc29mdCBPZmZp Y2V/7TVxAAAM4UlEQVR42u2dC3uiOBuGAaXlYFnWdradnZ3v9P9/5EfOiUQMeCp6P9dcU0XMmzzc voQQTZYhhBBCCCGEEEIIfTOVxXPGXlet1+kUzMIsglmYhVmYxalra7PNpV5eK/WgzuyDLLIpsm3x /i72yh3L0sxYvv86nXrUTzB59rGdglmYRTALszALsziFEEIIIYQQQgghhBBKF+Oza6g147PTblzA n8QiHpDZK5kHszALszALszD7rMw2coLp9JbYpuW7zS8MZr8Xs9784qVzvmdMUVax/fJr88+Wb/7F NkW2efUZv3Oq/Mla+DGP8zNpXtqc72Pmwez3zbPyiLYnt8Q2Ld9tZmHkWZhdv2MwC7MwC7MwC7OP zexzxF5XrWEWZmEWIYQQQgghhBBCCCH0LXU4GLh7y/O7jQ8uDi6mSE2/sWtPlVEVd6j/E4zFClOE Wn2cXv6Y1eaIQ3JTJwvtZYB+KLjQpb/q6XK9DFyr3eR+823fbI9QEwnuqxlHXHD0N3/uYy0KvH0f T6hsJidZqpCj+rtAbVYuMC/BUI+DBRjcmNmPIR/08s9m2wu/LsLsUNqPV/dUFG9eKeshSGvT0PES TsaujwM1Du4OTqH/O4/Zsj3WIqdYoq36hJCj+ttA2RLzUpi1HCzB4G7MqpOdsmn41L38lZCMTjOr Ml+dWXg+98PTpghtHz7bX/shqsxC58+RiQQPOdr93IuMlfcqOVZ6ovSQuvouD2e6ygxU6yqKZ6q4 poi3yG9JF0mqVcocmVH9baBsiXmzmHUYJFNw5zyrLFMftYsxax6LHCMs6Wpx2gxTRSPm27epFs9g Njj+riqFedz0On/JQ14JMP9+PSxf1Exwbrux6km0Ra4leqfzmFWPTaBF5s3Ps/MouIMqW8lcHDHZ VzMvJf1Sv/fNjxizoldmM4Y0X33XJDy9VW118PP/k18xSWXWBnfHxr5ZJpMPs3envxkTO9LybZKK RhWnU2isRbolmZ8FDpmNfFfGb/m4/ibQpHlu0/RRivtpODAYOAq+MbPKInsJlZLtTuVZcTbzss3n Xm7uxCIe/WGXrGnT08LEFdjR4KM8K59UfXAd6nlhGrJ116i97WiY036kRa4lMWYnr8LCPBvUXwda ZF7iictru8QgmYL7MWs/xhOGL2C2+9p7r6nTcC1OdKHtw+Vx+fI6x+KTefYguJ/nzKm9kJ0i70w8 YlbZoC8iW9WldAXEWuRacmbfIKi/DrTIvFnMhhgkUXBHZqU/4olyp7kIs9JLc0be/Pi1N4Y0uW+7 PAXqI3Q5ZoPg5iDUbtxg9y4vMfRlRzTPyqJ0Ut9s/7Fdh6Y40iKvJWdegwX114EWmTePWYNBOgW3 ljr1yY7Vb32FLK+oz+sb6LHDoV/U2NOuNKTVxfeSGzvE2OXq0lf2+M9l9lhwQ5s3qFkpqkq9W+X6 CLanJ0v7/aYuyl3aLttoi4KWRMe6TjMbr7+5xlpgXoqhlgOLQToFq9fNbsRMjM/eIGTCFUrsnsL0 +Oya7IfZBZq8CrtORJ/TRfduN9trr4cIs8hDME+86YsQQgghhBBCVxK/ybGGWjOWMO3GiVmnC29U PAmzUy+e4QrMwizMwizMwuyzMvvQ6ynA7FWYnV5PITL7mPUU0sybngnPegorzrPZI6+nQJ59VGZX 6BjMwizMwizMwuxjM/scsddVa5iFWZhFCCGEEEIIIYQQQgjdX4zPrqHWjM+murH4LuLz3rud2o17 tzALszALszALszALszc8ArFf8b/Od2sekNmxUXy35kZHgDx70caRZ2EWZmEWZmEWZmEWZu93BB4u 9rpqDbMwC7MIIYQQQgghhFCK5o3Pivvh9l54c3QpVcZnx7sF1s01j3GDWcx2uVu9sBN/S+u8eF0c iq9/fYh1k9tMLDNcwGzMvAPrZpoHs7OYNeu6O33u3etyEffdW2vWq+/qM1LR4zF7aN7n3n893TyY PY/Z0qwdXwyv24Mw7LTZFjA7aV6pf3V5tnkwewazwwmsNeYPXTJvsfjP/e7Xh34LzEbM09YtMg9m z2B2UNWaLVWhT2rK9rL43Fc9zB43r2rdllnmwewiZl1XrOq126VMFXJufT1sFcbD7KR5wp4l5sHs ucwWNlXoreIwlP/+GDpk6jnMHmO28PLsDPNgdjGz8twmBmxKcbVQ5sNlQ2ts734VQ9ZQgzkwOzLP WpctMQ9mZzGrhhjz/GufqSte6az40l1bDme10rwmByCrhOWInolZz7zSfTVxvnkwO4vZ66eiB2b2 UuXDLMzCLEIIIYQQQgghhBBC6P7iNznWUGvGZ1Pd4Pe6Lto4fq8LZmEWZmEWZmEWZmH2hkeA9RTO qDXrKdztCJBnL9o48izMwizMwizMwizMwuz9jsDDxV5XrWEWZmEWIYQQQgghhBBKEeMGa6g14wbT bkz7c8mfR3kcZi95pyW2P8zCLMzCLMzC7LMy2+T1yS2xTct3m18YzH4vZr05x5GZyUlzvr1Np6Yy q9j+/rX5Zwsz/2KbItu8+ozfOVX+ZC38mNHF6g5nx4/MSJzzfcwxmP2+eVZy2J7cEtu0fLeZhZFn YXb9jsEszMIszMIszD42s88Re121hlmYhVmEEEIIIYQQQgghhNC31MRg4O4tz28yVLg0kJgPNf2+ rj1ZSFXcvyHZIw/KClOEWn3EXv6Y1dSTt1TVcu69jtUPMQoZ5lVPl+tlDWqz7Hs/I9BmG/LjQulA 4e7NVPGph3rz5z6L1t+39N3MmWwiv6KbcO921BAXsc1KG/OEZfPu3XocLMDgxsx+DImhl3822174 dVlmh2J/vPqviEhql1KQ2rrENOlsLNBoarUJZQP5x6TQ/53FbNm6fQ7rb+WeV/0SZiMNsRGzIGbi T/ylMGs5WILB3Zjt3PEQn7qXv5ZlpePMqiRSG5w+98OTpjhg1uav2YEOQnX1mKPdz/+Isk1qrPS0 6CFj9Z0615hSZd6pVX2+9uKpLK4psixW/6DWnU2vVdrMnqPMjh3LAs/0G6OeLWXWYZBMwZ3zrPZA ftSuwax6JvKP8KarxYk0ZFbsULYLAoWhYmHFoVaPmt6mLQlYJcD8+/Wg1KqVnEtS2sw+jtQ/qLXZ 6zLMho6FnhlmY56dlWfnUXAHVbaSuTh0qtemXxp9kWPyuzInmRUdNJ065FFQXzo57BtUof2JgYJQ OpB/SPR7ZAb5cHt3+gsxkeOr3iVr0/R+Bo3W39baffjNK6OvvMRcnGyIiRjG9CpbtfEPQtJ3dwIO DAaOgm/MrLJINFV27xdO6owzK09rLgN97uXmwf/hAB8yW9UpqWg7voJ3oVyqO8yz8qFssX/56SwI DnVrENQdDXvWj9Tf1doxG7kKm5Fng4boiGFM72NeTxSaOITgcSAxSKbgfszaj/HI+Usx233t7U7q xFyLM94BszFk5/QNRD/z6zBFmP7sXjxU+dM/ARwyqxqvs/Nw1lUfOUfQuP5erS/VNwgaoiOGnk19 zJcyG2KQRMEdmZX+iCfKnebSzJYi6Rhefu2NM00eMNvUsXJnMesFcrmvNieR3bu+rtBXG7E8K0sy qXyz/ccg0RQm0kH9/Vpf6hosaIiOGHpm3hjzbDGzBoN0Cm4tdRKUfbrf5lq5zC/WN9CDiLKD1NhT se5+lXqAs8jc+Kx+sIBZF8oPZOXGZyvDVKl3q/LggfBAFvb7Te1ZumxnCj2of1Brb6xrEbPxhugO 6yhmn8U9m8ms5cBikE7B6nWz+y9lnd08Usp1ibunEBuffbzjALPpil2FXSeQB+qce7ebbcJqkjCL Lq4qT7vpixBCCCGEEEIIIYRWLn77aA21Zqh22g1+F3E+P/wuIszCLMzCLMzC7HWYZd0amJ1rJOvW ZKxbQ56dlWcz1q0hz66P2RU6BrMwC7MwC7Mw+9jMPkfsddUaZmEWZhFCCCGEEEIIIYQeUYx1raHW jHXBLMzCLMziFMziGMzGtHgOd3b+/kemga/PsbQ53Nny/dfp1KN+gsmzj+0UzMIsglmYhVmYxSmE EEIIIYQQQgghhBBCCKGHkVqeHi3z7kmW/b6xSrVyu/5N1JdXMzVOLbPe5V//xfXT5uXGutasez+Y t3vrs80W+y6vTv7uqlxrW932Luts8+PVPu0wPcE8a13mzJPbdh+4dHnb66bQzCp/P/cwO9s8a10W mCf2wKUr2L57f1XMZlU/PG+l7cp5TE81z1gXmpe5R+iStsu1BArDpzBfdW1hdoZ5xrrQPNGlRdew fbPtFbPDyU0mBvLsfPO0dYF5u597PLqO7cNJTTNbFt5lBMzOMU9b55vXfYHs1WzPGj2OuPnxy11G 7P4Hs+nmaes880rRQ2Dc4PIqczXGqC9zK3EZYYYYazP2yNBBgnmVWqvJmdfIvy02IYQQQgghdHv9 H3y0r0/B5/9vAAAAAElFTkSuQmCC --_004_82FB08F009780940837EB830C283F28408E8C1ADFR711WXCHMBA05z_-- From amclachl@cisco.com Tue Nov 12 10:48:09 2013 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 77D0311E8187 for ; Tue, 12 Nov 2013 10:48:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.798 X-Spam-Level: X-Spam-Status: No, score=-9.798 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8] 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 kIrxqubcriVq for ; Tue, 12 Nov 2013 10:48:01 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E8FCB21E80C3 for ; Tue, 12 Nov 2013 10:47:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=55315; q=dns/txt; s=iport; t=1384282044; x=1385491644; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=FYmNBbCEJije+PrNk6uI0re0d6Emexma4lSbrXBmq54=; b=a0+pN/S0HAeA9GrzQyUDQ6gMw65/nb2pYMqexarNbrx9YHSIar0VtJnL drsfIWMSD6jSvMliytf2EYSfeEYBqMMGGU9Mj3QF80OA13jI20GjdltyV nrBjdsdunw0wP38WbGLKwrap7ZMYSFuDSZlvIxyTIyxBQTdUGmLMJvzb1 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFADJ3glKtJV2c/2dsb2JhbABagkNEOFO/F4EqFnSCJQEBAQQaXxACAQgRAwEBASEBBgcyFAkIAgQOBRsDh2MNvyAEjhWBOQ0EBgGDIIERA5gPkgqDJoFoBzs X-IronPort-AV: E=Sophos;i="4.93,686,1378857600"; d="scan'208,217";a="283844268" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP; 12 Nov 2013 18:47:22 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rACIlMB9012003 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 18:47:22 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.191]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Tue, 12 Nov 2013 12:47:22 -0600 From: "Andrew McLachlan (amclachl)" To: "Henderickx, Wim (Wim)" Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Thread-Topic: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Thread-Index: Ac7cvqYcD4BB2/82Q4+fCPK55cREGP//WkCA//ukXXCACOGNgP/+4T1AgAKgCoD//1O0EAAqIJsA///eghD//1VbgP/+o4IA Date: Tue, 12 Nov 2013 18:47:21 +0000 Message-ID: References: <82FB08F009780940837EB830C283F28408E8C1AD@FR711WXCHMBA05.zeu.alcatel-lucent.com> In-Reply-To: <82FB08F009780940837EB830C283F28408E8C1AD@FR711WXCHMBA05.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.92.63] Content-Type: multipart/alternative; boundary="_000_F708544EB6D648A2AC9F9AE735B432B8ciscocom_" MIME-Version: 1.0 Cc: "l2vpn@ietf.org" X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 18:48:09 -0000 --_000_F708544EB6D648A2AC9F9AE735B432B8ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable just to emphasise =85.they are clearly described in the draft On 12 Nov 2013, at 18:21, Henderickx, Wim (Wim) > wrote: They are described in the draft. Cheers, Wim _________________ sent from blackberry From: Lucy yong [mailto:lucy.yong@huawei.com] Sent: Tuesday, November 12, 2013 07:14 PM To: Henderickx, Wim (Wim); l2vpn@ietf.org > Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Wim, Please clarify your real use case. In your real use case, when using a fir= ewall, does it use with a gateway together or not. If not, the firewall is = a just middle box (wired) and does not participate in the L2VN routing. If = it works with the gateway, only gateway participates in the L2VN, not the = firewall. The configuration between gateway and firewall is local, not rela= ted to the L2VN. Lucy From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Tuesday, November 12, 2013 11:11 AM To: Lucy yong; l2vpn@ietf.org Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement In-line From: Lucy yong > Date: Tuesday 12 November 2013 19:05 To: Wim Henderickx >, "l2vpn@ietf.org" > Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Wim, Please see below. From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Tuesday, November 12, 2013 1:22 AM To: Lucy yong; l2vpn@ietf.org Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement From: Lucy yong > Date: Tuesday 12 November 2013 05:11 To: Wim Henderickx >, Lucy yong >, "l2vpn@ietf.org" > Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Wim, When using a (centralized) gateway to provide external network connection f= or an L2 VN, I agree, it is necessary for the gateway to advertise its IP h= ost address and MAC to all the NVEs in the L2VN. This can be done by the RT= 2, right? NVEs also use RT2 tenant IP/MAC addresses. Thus, each NVE will kn= ow the gateway IP host and MAC address and perform the proxy ARP function, = i.e. terminate the ARP requests if the requested tenant systems (including = gateway) is not in local, and send back the requested MAC in ARP reply. Th= us, tenant system will send an L2 frame with designation tenant system or g= ateway MAC in dMAC to attached NVE, the NVE just performs the table lookup = to obtain the outer address. There is no IP routing table on NVEs because o= f the L2VN. What is the problem here? Why need to use RT5 to convey the GW= IP/MAC info? Please explain, I may miss some part in nutshell. WH> if you look to the drawings in the slides the NVE(s) can also have IP p= refixes behind them. E.g. A firewall, etc. this is what we are referring to= in the draft. See fig 1/2/3/4/5. [Lucy] OK, this is how to deal with network appliances. Do we want to treat= it as a middle box, or a tenant system that has multiple addresses? I gues= s, you want to address it as the latter. Even it is the latter, IMO, such t= enant system should not advertise the prefix in an L2 VN at all because it = serves middle box function only. If a tenant system is a gateway, it needs = to advertise itself as gateway (not the prefix from other VN). Then it will= be the same case as the following description. Does this make sense? WH2> there are real use cases as we describe which are required to be suppo= rted and hence this is what the draft is proposing and as we said before L3= VPN AFI/SAFI does not do the job. When using a gateway to provide external network connection for an L3 VN, N= VEs use their MAC address in ARP reply if VAP is L2 access interface. The L= 2 frame from a tenant system will be terminated at NVEs regardless the dest= ination tenant system is in the same VN or not. NVEs should have all the IP= routes in the VN. When NVE performs a lookup and is not able to find the m= atching one, it means the packet for the external. Since the gateway adver= tises its IP host address to NVEs as the gateway for the L3VN, NVEs will fo= rward the packets going to external to the gateway. In this case, the NVE = acts as the first-hop router, the gateway is the last-hop in the VN. You a= re right, it is necessary for a gateway to advertise its role besides its I= P address. If this is not there, should improve the protocol. Regarding the IRB capability, this is my view about IRB implementation in v= irtual overlay environment. Figure shows two L2VNs, VNx and VNz. NVE1 and NVE2 are member of both VNs.= If NVE1 and NVE2 implement L3 distributed gateway functions and have the s= ame MAC address for the L3dGW. When NVEs advertise both Tenant system IP an= d MAC addresses, each NVE have all the information about tenant systems in = both VNs. NVEs still terminates the ARP requests and provide the MAC for th= e remote tenant system in the same VN. NVEs returns L3dGW addresses for the= GW ARP request or if no matching MAC are founded. Thus, only the L3dGW at= ingress NVE process inter-VN traffic forwarding, i.e. the traffic from VNx= TS on NVE1 goes through the L3dGW on NVE1 to reach the VNy TS on NVE1 or V= Ny TS on NVE2. Will this make sense to you? WH> yes but the prefix draft is orthogonal to this. So lets not mix these t= hings. The draft describing IRB is the following for which you are a co-aut= hor and we are submitting an update to show the 2 architectures supporting = this: https://tools.ietf.org/html/draft-sajassi-l2vpn-evpn-inter-subnet-forwardin= g-02 [Lucy] yes, we provide a lot of inputs on evpn overlay and interworking dra= fts. Glad to continually work on these drafts. However, these drafts are st= ill individual drafts. As we are more and more clear on the network virtual= ization overlay for the cloud applications, we need update the descriptions= (an implementation) in these drafts to make it clear. As you aware, neithe= r of us works on these drafts recently. WH2> we did in the last IETF and the updates will be reflected before the e= nd of the year Thanks, Lucy From: Henderickx, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.com] Sent: Monday, November 11, 2013 2:22 AM To: Lucy yong; l2vpn@ietf.org Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement In-line From: Lucy yong > Date: Monday 11 November 2013 08:43 To: Wim Henderickx >, Lucy yong >, "l2vpn@ietf.org" > Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Wim, I read the draft and still think that all the use cases work well with RT2.= Here are my views how these use cases in section 5 can be implemented wit= hout RT5 Use case 1 can be done by an L3 VN overlay, say VN10, and a gateway at DCGW= 1 and DCGW2. The gateway is used to interconnect the VN 10 and WAN. The VN10 route the traffic on SN 1 and SN2, SN3, and IP2-IP5. I call this = implementation =93L3VN plus a gateway=94 Why do you want to use an L2 VN ov= erlay here? WH> you don=92t have a GW IP in the L3VPN AFI/SAFI, so you will need to def= ine a new route to do this efficiently Use case 2 and use case 4 are about multi-homing. In the case 2, TS and NVE= are co-located; in the case 4, TS and NVE are physically separated. First= of all, IMO, when TS and NVE co-locate on the same server, multi-homed TS = is not necessary. The use case 4 is just the use case 1 with multi-homing. = Thus, it can be implemented by =93L3VN plus a gateway=94 w/ VRRP. WH> there is no VRRP in these cases since the appliance is a bump in the wi= re for use case 4 so they don=92t even speak IP, so you have an undefined N= H, which is also not evadable in the L3VPn AFI/SAFI and there is no ESI NH = possible In your use case 3, EVI10 should be replaced by an L3 overlay. The VRF on t= he NVE1 acts as the L3 distributed gateway for the EVN1 and EVN2. The VRF = on the NVE2 acts as the L3 distributed gateway for the EVN2 and EVN3. The V= RFs on DGW1 and DGW2 act as the gateway between the L3 overlay and WAN. If = NVE1 and NVE2 use RT2 advertises TS IP/MAC, NVE1 will know IP subnet/prefi= x associating to EVN1 and EVN2, and IP subnet/prefix associating to the L3 = overlay. When NVE1 receives a packet from IP1 and the packet has the destin= ation to SN1, the packet dMAC address will be the MAC address for the distr= ibuted gateway that is the same for all the NVEs. When NVE sees this addres= s, it will perform the VRF table lookup by using the destination IP addr on= the packet, which results the IP addr is associated to the EVN2, then NVE = performs the table look-up in EVI-2 that has both IP/MAC to outer (or VAP) = address mapping, so it will replace the dMAC addr on the packet with the re= al destination MAC addr and send to the VAP that SN1 associated to. When N= VE1 receives a packet from IP1 and the packet has the destination in the WA= N network, the dMAC on the packet is also the MAC address for the distribut= ed gateway. So NVE will perform the VRF table look-up by using the destinat= ion IP on the packet, which results to the outer IP address on one of DGWs,= say DGW1. NVE1 adds the L3 VN ID and the outer header on the packet prior = sending it out. When DGW1 receives the packet, it removes the tunnel header= and uses the L3 VN ID on the packet to reach the vGW on DGW1. The vGW perf= orm the packet treatment before sending to the WAN. WH> it depends how you want to do this, you can either go route from ingres= s w/o IP lookup on ingress or do a lookup on egress. Both options are possi= ble and required for some HW in the market. EVPN supports both already, wha= t this draft is doing is how prefixes should be used in this environment L2/L3 NVE service type described in draft-yong-nv03-nve is for this use cas= e. When L2/L3 NVE service type is used, NVE maintains both TS IP/MAC addres= ses but may advertise both IP/MAC addresses or one of the address depending= on the remote NVE service type. When L2 NVE service type is used, NVE just= maintains TS MAC addresses. Both cases can be implemented by EVPN solution= . WH> draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 describes the IRB c= ase There are places we need to use L2 VNs. For example, all TSes in a VN have = the same IP address but different MAC addresses; there is broadcast/multic= ast traffic in a VN; non-IP packet. However, we don=92t want to make a comp= lex EVPN solution to solve the case that L3VN can easily address. WH> see draft-sajassi-l2vpn-evpn-inter-subnet-forwarding-02 it describes it= all. As I said not all use case can be done with L3VPN and this is require= d. Regards, Lucy From: HenderickxHi Win,, Wim (Wim) [mailto:wim.henderickx@alcatel-lucent.co= m] Sent: Friday, November 08, 2013 2:18 PM To: Lucy yong; l2vpn@ietf.org Subject: Re: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Lucy, did you read the draft and is explained in section 6. Show an example on how you do the scenario=92s with RT2 and you will see wh= y this is less efficient/scalable + does not support all scenario=92s in th= e draft like ESI NH. E-VPN distributes host routes using RT-2: (IP) + MAC and these can be an in= terface e.g. And prefixes can exists behind them. From: Lucy yong > Date: Friday 8 November 2013 22:10 To: "l2vpn@ietf.org" > Subject: comment on draft-rabadan-l2vpn-evpn-prefix-advertisement Hi Authors, I am not convinced if RT 5 is necessary for the use cases you specified in = the draft (or presentation). IMO: RT2 is sufficient to support all the case= s. There is a draft-yong-nvo3-nve, which covers all the L2 overlay cases, whic= h can be implemented by EVPN with RT2. One question, why EVPN service allow to VAP being an IP interface? Thanks, Lucy --_000_F708544EB6D648A2AC9F9AE735B432B8ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable

just to emphasise  =85.they are = clearly described in the draft

On 12 Nov 2013, at 18:21, Henderickx, Wim (Wim) <wim.henderickx@alcatel-lucent.com>= ; wrote:

They are described in the draft. 

Cheers, 
Wim 
_________________ 
sent from blackberry
 
From: Lucy yong [mailto:lucy.yong@hua= wei.com] 
Sent: Tuesday, November 12, 2013 07:14 PM
To: Henderickx, Wim (Wim); l2vpn@i= etf.org <l2vpn@ietf.org> 
Subject: RE: comment on draft-rabadan-l2vpn-evpn-prefix-advertisemen= t 
 
Wim,
 
Please clarify your real use case.=  In your real use case, when using a firewall, does it use with a gat= eway together or not. If not, the firewall is a just middle box (wired) and= does not participate in the L2VN routing. If it works with the gateway, only gateway participates in the L2VN,  = ;not the firewall. The configuration between gateway and firewall is local,= not related to the L2VN.
 
Lucy
 
From:<= /span> Henderickx, Wim (Wim) [= mailto:wim.henderickx@= alcatel-lucent.com] <= br> Sent: Tuesday, Nov= ember 12, 2013 11:11 AM
To: Lucy yong; l2vpn@ietf.org
Subject: Re: comme= nt on draft-rabadan-l2vpn-evpn-prefix-advertisement
 
In-line
 
From: Lucy yong <lucy.yong@huaw= ei.com>
Date: Tuesday 12 N= ovember 2013 19:05
To: Wim Henderickx= <wim.henderickx@alcatel-lucent.com&g= t;, "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: RE: comme= nt on draft-rabadan-l2vpn-evpn-prefix-advertisement
 
Wim, Please see below.
 
From:<= /span> Henderickx, Wim (Wim) [= mailto:wim.henderickx@alcatel-lucent.com= ] 
Sent: Tuesday, Nov= ember 12, 2013 1:22 AM
To: Lucy yong; l2vpn@ietf.org
Subject: Re: comme= nt on draft-rabadan-l2vpn-evpn-prefix-advertisement=
 
 
 
 
Wim,<= /o:p>
 
When using a (centralized) gateway= to provide external network connection for an L2 VN, I agree, it is necess= ary for the gateway to advertise its IP host address and MAC to all the NVE= s in the L2VN. This can be done by the RT2, right? NVEs also use RT2 tenant IP/MAC addresses. Thus, each NVE = will know the gateway IP host and MAC address and perform the proxy ARP fun= ction, i.e. terminate the ARP requests if the requested tenant systems (inc= luding gateway) is not in local, and send back the requested  MAC in ARP reply. Thus, tenant system wi= ll send an L2 frame with designation tenant system or gateway MAC in dMAC t= o attached NVE, the NVE just performs the table lookup to obtain the outer = address. There is no IP routing table on NVEs because of the L2VN.  What is the problem here? Why need to u= se RT5 to convey the GW IP/MAC info?  Please explain, I may miss some = part in nutshell.
 
WH> if you look to the drawings in th= e slides the NVE(s) can also have IP prefixes behind them. E.g. A firewall,= etc. this is what we are referring to in the draft.
See fig 1/2/3/4/5.
[Lucy] OK, this is how to de= al with network appliances. Do we want to treat it as a middle box, or a te= nant system that has multiple addresses? I guess, you want to address it as= the latter. Even it is the latter, IMO, such tenant system should not advertise the prefix in an L2 VN at all= because it serves middle box function only. If a tenant system is a gatewa= y, it needs to advertise itself as gateway (not the prefix from other VN). = Then it will be the same case as the following description. Does this make sense?
 
WH2> there are real use cases as we d= escribe which are required to be supported and hence this is what the draft= is proposing and as we said before L3VPN AFI/SAFI does not do the job.&nbs= p;
 
When using a gateway to provide ex= ternal network connection for an L3 VN, NVEs use their MAC address in ARP r= eply if VAP is L2 access interface. The L2 frame from a tenant system will = be terminated at NVEs regardless the destination tenant system is in the same VN or not. NVEs should have all t= he IP routes in the VN. When NVE performs a lookup and is not able to find = the matching one, it means the packet for the external.  Since the gat= eway advertises its IP host address to NVEs as the gateway for the L3VN, NVEs will forward the packets going to e= xternal to the gateway.  In this case, the NVE acts as the first-hop r= outer, the gateway is the last-hop in the VN.  You are right, it is ne= cessary for a gateway to advertise its role besides its IP address.  If this is not there, should improve the pro= tocol.
 
Regarding the IRB capability, this= is my view about IRB implementation in virtual overlay environment.=
<image001.png>
 
 
Figure shows two L2VNs, VNx and VN= z.  NVE1 and NVE2 are member of both VNs. If NVE1 and NVE2 implement L= 3 distributed gateway functions and have the same MAC address for the L3dGW= . When NVEs advertise both Tenant system IP and MAC addresses, each NVE have all the information about tenant syste= ms in both VNs. NVEs still terminates the ARP requests and provide the MAC = for the remote tenant system in the same VN. NVEs returns L3dGW addresses f= or the GW ARP request or if no matching MAC are founded.  Thus, only the L3dGW at ingress NVE process inter-V= N traffic forwarding, i.e. the traffic from VNx TS on NVE1 goes through the= L3dGW on NVE1 to reach the VNy TS on NVE1 or VNy TS on NVE2.  Will th= is make sense to you?
 
WH> yes but the prefix draft is ortho= gonal to this. So lets not mix these things. The draft describing IRB is th= e following for which you are a co-author and we are submitting an update t= o show the 2 architectures supporting this:
 
[Lucy] yes, we provide a lot= of inputs on evpn overlay and interworking drafts. Glad to continually wor= k on these drafts. However, these drafts are still individual drafts. As we= are more and more clear on the network virtualization overlay for the cloud applications, we need update the desc= riptions (an implementation) in these drafts to make it clear. As you aware= , neither of us works on these drafts recently.
 
WH2> we did in the last IETF and the = updates will be reflected before the end of the year
 
 
Thanks,
Lucy<= /o:p>
 
 
 
 
 
 
 
From:<= /span> Henderickx, Wim (Wim) [= mailto:wim.henderickx@alcatel-lucent.com= ] 
Sent: Monday, Nove= mber 11, 2013 2:22 AM
To: Lucy yong; l2vpn@ietf.org
Subject: Re: comme= nt on draft-rabadan-l2vpn-evpn-prefix-advertisement=
 
In-line
 
 
Wim,<= /o:p>
 
I read the draft and still think t= hat all the use cases work well with RT2.  Here are my views how these= use cases in section 5 can be implemented without RT5
 
Use case 1 can be done by an L3 VN= overlay, say VN10, and a gateway at DCGW1 and DCGW2. The gateway is used t= o interconnect the VN 10 and WAN.=
The VN10 route the traffic on SN 1= and SN2, SN3, and IP2-IP5.  I call this implementation =93L3VN plus a= gateway=94 Why do you want to use an L2 VN overlay here?
 
WH> you don=92t have a GW IP in the L= 3VPN AFI/SAFI, so you will need to define a new route to do this efficientl= y
 
Use case 2 and use case 4 are abou= t multi-homing. In the case 2, TS and NVE are co-located; in the case 4, TS= and NVE are physically separated.  First of all, IMO, when TS and NVE= co-locate on the same server, multi-homed TS is not necessary. The use case 4 is just the use case 1 with multi-homi= ng. Thus, it can be implemented by =93L3VN plus a gateway=94 w/ VRRP.  = ;
 
WH> there is no VRRP in these cases s= ince the appliance is a bump in the wire for use case 4 so they don=92t eve= n speak IP, so you have an undefined NH, which is also not evadable in the = L3VPn AFI/SAFI and there is no ESI NH possible=
 
In your use case 3, EVI10 should b= e replaced by an L3 overlay. The VRF on the NVE1 acts as the L3 distributed= gateway for the EVN1 and EVN2.  The VRF on the NVE2 acts as the L3 di= stributed gateway for the EVN2 and EVN3. The VRFs on DGW1 and DGW2 act as the gateway between the L3 overlay and WA= N. If NVE1 and NVE2 use RT2 advertises TS IP/MAC,  NVE1 will know IP s= ubnet/prefix associating to EVN1 and EVN2, and IP subnet/prefix associating= to the L3 overlay. When NVE1 receives a packet from IP1 and the packet has the destination to SN1, the packet dM= AC address will be the MAC address for the distributed gateway that is the = same for all the NVEs. When NVE sees this address, it will perform the VRF = table lookup by using the destination IP addr on the packet, which results the IP addr is associated to the EVN2= , then NVE performs the table look-up in EVI-2 that has both IP/MAC to oute= r (or VAP) address mapping, so it will replace the dMAC addr on the packet = with the real destination MAC addr and send to the VAP that SN1 associated to.  When NVE1 receives a pac= ket from IP1 and the packet has the destination in the WAN network, the dMA= C on the packet is also the MAC address for the distributed gateway. So NVE= will perform the VRF table look-up by using the destination IP on the packet, which results to the outer IP addr= ess on one of DGWs, say DGW1. NVE1 adds the L3 VN ID and the outer header o= n the packet prior sending it out. When DGW1 receives the packet, it remove= s the tunnel header and uses the L3 VN ID on the packet to reach the vGW on DGW1. The vGW perform the packe= t treatment before sending to the WAN.
 
WH> it depends how you want to do thi= s, you can either go route from ingress w/o IP lookup on ingress or do a lo= okup on egress. Both options are possible and required for some HW in the m= arket. EVPN supports both already, what this draft is doing is how prefixes should be used in this environment
 
L2/L3 NVE service type described i= n draft-yong-nv03-nve is for this use case. When L2/L3 NVE service type is = used, NVE maintains both TS IP/MAC addresses but may advertise both IP/MAC = addresses or one of the address depending on the remote NVE service type. When L2 NVE service type is used, NVE just= maintains TS MAC addresses. Both cases can be implemented by EVPN solution= .
 
WH> draft-sajassi-l2vpn-evpn-int= er-subnet-forwarding-02 describes the IRB case=
 
There are places we need to use L2= VNs. For example, all TSes in a VN have the same IP address but different = MAC addresses;  there is broadcast/multicast traffic in a VN; non-IP p= acket. However, we don=92t want to make a complex EVPN solution to solve the case that L3VN can easily address. &nbs= p;
 
WH> see draft-sajassi-l2vpn-evpn= -inter-subnet-forwarding-02 it describes it all. As I said not all use case= can be done with L3VPN and this is required.<= /o:p>
 
Regards,
Lucy<= /o:p>
 
 
 
 
 
 
 
 
Lucy, did you read the draft and is expl= ained in section 6.
Show an example on how you do the scenar= io=92s with RT2 and you will see why this is less efficient/scalable + = does not support all scenario=92s in the draft like ESI NH.
 
E-VPN distributes host routes using RT-2= : (IP) + MAC and these can be an interface e.g. And prefixes can exists= behind them.
 
From: Lucy yong <lucy.yong@huaw= ei.com>
Date: Friday 8 Nov= ember 2013 22:10
To: "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: comment o= n draft-rabadan-l2vpn-evpn-prefix-advertisement
 
Hi Authors,
 
I am not convinced if RT 5 is necessary for the use cases = you specified in the draft (or presentation). IMO: RT2 is sufficient to sup= port all the cases.
There is a draft-yong-nvo3-nve, which covers all the L2 ov= erlay cases, which can be implemented by EVPN with RT2.
 
One question, why EVPN service allow to VAP being an IP in= terface?
 
Thanks,
Lucy

--_000_F708544EB6D648A2AC9F9AE735B432B8ciscocom_-- From lucy.yong@huawei.com Tue Nov 12 12:25:54 2013 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 BDE8E21E80F9; Tue, 12 Nov 2013 12:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.836 X-Spam-Level: X-Spam-Status: No, score=-5.836 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, 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 KHg9FU4g4R7N; Tue, 12 Nov 2013 12:25:45 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9AB21F9C6A; Tue, 12 Nov 2013 12:25:32 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAE73950; Tue, 12 Nov 2013 20:25:31 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 20:24:33 +0000 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 12 Nov 2013 20:25:29 +0000 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.113]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.03.0158.001; Tue, 12 Nov 2013 12:25:24 -0800 From: Lucy yong To: "l2vpn@ietf.org" , "l3vpn@ietf.org" , "lisp@ietf.org" , "trill@ietf.org" Subject: FW: New Version Notification for draft-yong-nvo3-nve-01.txt Thread-Topic: New Version Notification for draft-yong-nvo3-nve-01.txt Thread-Index: AQHO39Rm8NXMttcE5UeGJuimDcGum5oh/RIggAAMXZA= Date: Tue, 12 Nov 2013 20:25:23 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D452ED194@dfweml509-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.136.214] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 20:25:54 -0000 VGhpcyBpcyBmb3IgdGhvc2Ugd2hvIGFyZSBub3QgaW4gTlZPMyBtYWlsaW5nIGxpc3QuIFNpbmNl IHRoZXJlIGFyZSBwb3RlbnRpYWwgdG8gdXNlIGwydnBuLCBsM3ZwbiwgbGlzcCwgdHJpbGwgc29s dXRpb24gZm9yIE5WTzMsIGl0IGlzIGJlbmVmaWNpYWwgdG8gbGV0IHRoZXNlIGNvbW11bml0aWVz IGF3YXJlIG9mIHRoaXMgZHJhZnQuDQoNClNvcnJ5IGlmIHRob3NlIGdldCBtdWx0aXBsZSBvZiB0 aGlzLg0KDQpSZWdhcmRzLA0KTHVjeQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogTHVjeSB5b25nIA0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMTIsIDIwMTMgMTo0NCBQTQ0K VG86IG52bzNAaWV0Zi5vcmcNClN1YmplY3Q6IEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LXlvbmctbnZvMy1udmUtMDEudHh0DQoNCkhlbGxvIE5WTzMgQ29tbXVuaXR5LA0K DQpUaGlzIGlzIGEgbmV3IGRyYWZ0LiBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBOVkUgZGF0YSBw bGFuZSBmdW5jdGlvbmFsaXR5LiBUaGVzZSBmdW5jdGlvbmFsaXR5IHNwZWNpZmljYXRpb25zIGFy ZSBuZWNlc3NhcnkgZm9yIHRoZSBpbnRlcm9wZXJhYmlsaXR5IGJldHdlZW4gYW4gTlZFIGFuZCBp dHMgYXR0YWNoZWQgdGVuYW50IHN5c3RlbXMgYW5kIGJldHdlZW4gdGhlIE5WRXMuIFRoZSBkYXRh IHBsYW5lIGZ1bmN0aW9uYWxpdHkgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgaXMgaW5kZXBl bmRlbnQgb2YgTlZFIG9yIE5WTzMgY29udHJvbCBwbGFuZSBmdW5jdGlvbmFsaXR5LiBIb3dldmVy IHRoZSBzcGVjaWZpY2F0aW9ucyBpbiB0aGlzIGRvY3VtZW50IGNhbiBzdXBwb3J0IGFueSBjb250 cm9sIHBsYW5lIHNvbHV0aW9uIGFuZCBhcmUgaGVscGZ1bCBpbiB0aGUgY29udHJvbCBwbGFuZSBw cm90b2NvbCBkZXZlbG9wbWVudC4NCg0KV2UgbG92ZSB0byBoZWFyIHBlb3BsZSBmZWVkYmFja3Mg b24gdGhlIGRyYWZ0LiBTb21lIHNlY3Rpb25zIGluIHRoZSBkcmFmdCBhcmUgbm90IGNvbXBsZXRl ZCB5ZXQgYW5kIHdpbGwgYmUgdXBkYXRlZCBpbiBuZXh0IHZlcnNpb24uDQoNClJlZ2FyZHMsDQpM dWN5DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogVHVlc2Rh eSwgTm92ZW1iZXIgMTIsIDIwMTMgMTI6MjQgUE0NClRvOiBMdWN5IHlvbmcNClN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQteW9uZy1udm8zLW52ZS0wMS50eHQNCg0K DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQteW9uZy1udm8zLW52ZS0wMS50eHQgaGFzIGJl ZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBMdWN5IFlvbmcgYW5kIHBvc3RlZCB0byB0aGUg SUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LXlvbmctbnZvMy1udmUNClJldmlz aW9uOgkgMDENClRpdGxlOgkJIE5ldHdvcmsgVmlydHVhbGl6YXRpb24gRWRnZSAoTlZFKQ0KQ3Jl YXRpb24gZGF0ZToJIDIwMTMtMTEtMTENCkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0K TnVtYmVyIG9mIHBhZ2VzOiAxNw0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC15b25nLW52bzMtbnZlLTAxLnR4dA0KU3RhdHVzOiAgICAg ICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXlvbmctbnZvMy1udmUN Ckh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteW9uZy1u dm8zLW52ZS0wMQ0KRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/ dXJsMj1kcmFmdC15b25nLW52bzMtbnZlLTAxDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVu dCBzcGVjaWZpZXMgTmV0d29yayBWaXJ0dWFsaXphdGlvbiBFZGdlIChOVkUpIGRhdGEgcGxhbmUN CiAgIGZ1bmN0aW9uYWxpdHkgZm9yIE5ldHdvcmsgVmlydHVhbGl6YXRpb24gT3ZlcmxheXMgKE5W TzMpLiBUaGVzZQ0KICAgZnVuY3Rpb25hbGl0eSBzcGVjaWZpY2F0aW9ucyBhcmUgbmVjZXNzYXJ5 IGZvciB0aGUgaW50ZXJvcGVyYWJpbGl0eQ0KICAgYmV0d2VlbiBhbiBOVkUgYW5kIGl0cyBhdHRh Y2hlZCB0ZW5hbnQgc3lzdGVtcyBhbmQgYmV0d2VlbiB0aGUgTlZFcy4NCg0KDQoNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoN ClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From loa@pi.nu Tue Nov 12 13:59:48 2013 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 248E311E810B; Tue, 12 Nov 2013 13:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 0Qn+RDHoi6yV; Tue, 12 Nov 2013 13:59:43 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id DE7B611E80E6; Tue, 12 Nov 2013 13:59:39 -0800 (PST) Received: from [192.168.252.96] (107-1-141-74-ip-static.hfc.comcastbusiness.net [107.1.141.74]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 93B2B1802038; Tue, 12 Nov 2013 22:59:37 +0100 (CET) Message-ID: <5282A4C9.4080603@pi.nu> Date: Tue, 12 Nov 2013 13:59:37 -0800 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: "mpls@ietf.org" , "ccamp@ietf.org" , "pwe3@ietf.org" , "nvo3@ietf.org" , l2vpn@ietf.org, L3VPN , Vero Zheng , Adrian Farrel , "stbryant@cisco.com" Subject: MPLS VPN Scaling Bof in London Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 21:59:48 -0000 Working Groups, We will run a non-Working Group forming BoF in London to discuss issues around Scaling of MPLS VPNs. Lou Berger and i have accepted to chair this BoF, Vero Zheng will take on the role as list admin and secretary. We plan to kick-off the discussion on a problem statement as soon as we have enough participants on the mailing list We gave a heads up for this BoF in Vancouver - these slides were presented in the RTG Area Open Meeting. http://www.ietf.org/proceedings/88/slides/slides-88-rtgarea-5.pptx We have started to prepare the BoF, and the discussion on how we set it up will take place on a new mailing list: scale-request@ietf.org Please subscribe to this list through: https://www.ietf.org/mailman/listinfo/scale /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From ietf-ipr@ietf.org Wed Nov 13 09:45:17 2013 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 1FD6A21E8151; Wed, 13 Nov 2013 09:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.319 X-Spam-Level: X-Spam-Status: No, score=-102.319 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, NO_RELAYS=-0.001, 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 2IagsFXFmq-y; Wed, 13 Nov 2013 09:45:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ACBFA21E80BE; Wed, 13 Nov 2013 09:45:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: jiangyuanlong@huawei.com, lucyyong@huawei.com, Manuel.Paul@telekom.de, frederic.jounay@orange.ch, florin.balus@alcatel-lucent.com, wim.henderickx@alcatel-lucent.com, sajassi@cisco.com Subject: IPR Disclosure: Huawei Technologies Co., Ltd's Statement about IPR related to draft-ietf-l2vpn-vpls-pe-etree-02 X-Test-IDTracker: no X-IETF-IDTracker: 4.83 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131113174516.23150.9453.idtracker@ietfa.amsl.com> Date: Wed, 13 Nov 2013 09:45:16 -0800 X-Mailman-Approved-At: Wed, 13 Nov 2013 10:09:22 -0800 Cc: l2vpn@ietf.org, giheron@cisco.com, ipr-announce@ietf.org, stbryant@cisco.com X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.12 List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 17:45:17 -0000 Dear Yuanlong Jiang, Lucy Yong, Manuel Paul, Frederic JOUNAY, Florin Balus,= Wim Henderickx, Ali Sajassi: An IPR disclosure that pertains to your Internet-Draft entitled "VPLS PE M= odel for E-Tree Support" (draft-ietf-l2vpn-vpls-pe-etree) was submitted to the I= ETF Secretariat on 2013-11-13 and has been posted on the "IETF Page of Intellec= tual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2250/). The = title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-l2vpn-vpls-pe-etree-02.""); The IETF Secretariat From gregory.mirsky@ericsson.com Tue Nov 19 04:56:32 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E44F1ADF80 for ; Tue, 19 Nov 2013 04:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YlX9YVPNJHax for ; Tue, 19 Nov 2013 04:56:28 -0800 (PST) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 46B141ADF94 for ; Tue, 19 Nov 2013 04:56:28 -0800 (PST) X-AuditID: c618062d-b7f278e000005a8f-a4-528b5ff154d6 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 25.D4.23183.1FF5B825; Tue, 19 Nov 2013 13:56:18 +0100 (CET) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Tue, 19 Nov 2013 07:56:18 -0500 From: Gregory Mirsky To: "ssalam@cisco.com" , "sajassi@cisco.com" , "Sam Aldrin (aldrin.ietf@gmail.com)" , "John E Drake (jdrake@juniper.net)" , "venggovi@cisco.com" , "l2vpn@ietf.org" Subject: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and draft-vgovindan-l2vpn-evpn-bfd Thread-Topic: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and draft-vgovindan-l2vpn-evpn-bfd Thread-Index: Ac7lDSTCOfeFij7fTiOpIkx3ocp0YQ== Date: Tue, 19 Nov 2013 12:56:17 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B71E5A9@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B71E5A9eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyuXRPiO6n+O4gg5PdghYTWr8wWsy562zx +Nshdot3Z5tZLJ7MW8luMfPDJmYHNo8pvzeyeuycdZfdY8mSn0we15uusgewRHHZpKTmZJal FunbJXBlPP6/jLngzm3GirkN/g2M9/YydjFyckgImEicunuEDcIWk7hwbz2QzcUhJHCEUeLy 4jmsEM5yRon7m5ewgFSxCRhJvNjYww6SEBFYwCRx59hUJpCEsECcxNx1U8CKRASSJRovfGSG sPUklqz+ClbDIqAqMfX6VXYQm1fAV+Jpy0Ow1YxAq7+fWgNWwywgLnHryXwmiJMEJJbsOc8M YYtKvHz8jxXCVpZY8mQ/C0R9vsTs6y1sEDMFJU7OfMIygVFoFpJRs5CUzUJSBhHXkViw+xMb hK0tsWzha2YY+8yBx0zI4gsY2VcxcpQWp5blphsZbGIERtMxCTbdHYx7XloeYpTmYFES5/3y 1jlISCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUAyN3RwZjtFbE2i6NQ5vb73/RarQVn/t2Jivr pWg/09D0e0aThS7OWFVwacPtQywZ4b2aJxdb7eXrEtt1+p3hzhtTw+w9wyc4cc3Ji9aY/6dR Ov3P45SKeKMnm+S+7+oINX3EE3VbULnK+GB/oaP4+mndXo+/igVrtNf0hJdYfIm7/fjSpwDz m0osxRmJhlrMRcWJAB40f1F0AgAA X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 12:56:32 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B71E5A9eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et. al, very useful and timely raised questions. Please find my comments to both do= cuments below. Greatly appreciate your kind consideration and am looking fo= rward to the discussion. Regards, Greg draft-salam-l2vpn-evpn-oam-req-frmwk-01 * Use cases. Multi-carrier E-VPN. Ethernet Service OAM is instrumented,= through MEG Level hierarchy, to present customer, provider, and operator s= copes of OAM. If multi-carrier E-VPN is viable use case, then support of ME= P and its functionalities becomes a MUST for provider and operator scopes. = Then, if multi-carrier E-VPN is viable use case, there might be new require= ments towards E-VPN Network OAM. * Sec.1.1 s/Public/Packet/ * CFM ... defines concept ... Maintenance Association ... * Sec.1.3 MEG, Maintenance Entity Group, is object of Y.1731 equivalent= to MA of CFM. Note that MEG is used in MPLS-TP OAM as well. * Definition of MIP is not correct. MIP can terminate certain OAM, both= Ethernet and MPLS-TP, frames, e.g. ETH-LB. * Maintenance Domain, as mentioned in 1.1, is object of CFM and is not = used in Y.1731. Suggest use consistent terminology, either CFM or Y.1731. * Figure 2, can use EFM (Ethernet First Mile) OAM instead of 802.3 OAM.= (Note that there are two Figure 2 in the document - Section 2.1 and Sectio= n 3.1.1.2.1) * Section 2.2 * Characterize whether MEP on PEs SHOULD be Up, Down or both. * Section 2.4 * Would BFD (RFC 5880, RFC 5881, RFC 5883, RFC 5884, and RFC 5885) b= e applicable as well as RFC 6428? * Section 2.6 * I think that OAM interworking is most useful when it exists betwee= n proactive OAM mechanisms whether it in peer-to-peer or client-server mode= l. I don't see that there's requirement of proactive Network OAM. Should th= ere be one? E.g. "E-VPN Network OAM SHOULD provide both proactive and on-de= mand mechanisms of monitoring its data plane operation and data plane confo= rmance to state of its control plane." * Section 3.1.1 * Please consider splitting the sentence in two with the second bein= g like "... without time bound. Certain actions, e.g. protection switchover= or alarm indication signaling, could be associated with events of entering= and clearing fault state". * Section 3.1.1.1 * I think that another term for "a specified path taken by a particu= lar user data flow" is "in-band monitoring". * I think that monitoring of "representative path" may not be reliab= le test of MEP hosting node liveliness. As I understand, it still verificat= ion of the MEP liveliness but out-band. Or it is implied that the target of= this monitoring is not the MEP but an ID associated with the node where th= e MEP defined? Then wouldn't that be verification of a control plane rather= than data plane operation? * What is understood as "test flow"? Is that using methods of active= monitoring/measurements when specifically constructed test packets being i= njected vs. passive monitoring/measurements when data flow(s) used to monit= or and measure performance? * "Monitoring of all ECMP paths between MEPs is not a requirement fo= r E-VPN OAM." Is in regard to concurrent monitoring all paths between two (= ?) MEPs or to problem of exercising particular paths at-will? * I'm not sure that the last requirement is applicable to E-VPN Serv= ice OAM. CFM and/or Y.1731 would not be used differently when monitoring un= icast only or unicast and multicast services. * Section 3.1.1.2.2 * What is understood by "support RDI"? Is it merely ability to signa= l LoC defect to remote MEP(s) or ability, as well, to recognize RDI from a = remote MEP? Should note that in multipoint MA RDI is not really useful as i= ndicator of unidirectional fault since there's no indication of with which = MEP the sender detected LoC defect. If unidirectional LoC is likely not gua= rantee of bi-directional fault, then MA MUST be p2p. * Section 3.1.2.2 * Connectivity Verification vs. Continuity Check. There's reference = to "connectivity faults" in the first paragraph. Should it be changed to "c= ontinuity" or on-demand OAM, at least in E-VPN Service OAM, required to det= ect mis-connectivity? If "yes", why the same is not applicable to proactive= OAM for E-VPN Service? * Section 3.2 * I wouldn't refer to scheduled on-demand PM tests as "proactive" si= nce these are still bound in time unlike proactive that are not bound in ti= me. * But there is at least one example of truly proactive LM in Y.1731 = that uses ETH-CC frames. So, there's a distinction between proactive and on= -demand PM. * Section 3.2.1 * Use of Synthetic LM is usually in out-of-service state as test fra= mes expected to be statistically representative of real data flow. LM in mp= 2mp network can be constructed of set of p2p LM metrics. draft-vgovindan-l2vpn-evpn-bfd-00 * Section 2.1.1 o If there's a need to have BFD session per ECMP path/EL how such session= can be demuxed at the tail if at the bootstrap it would allocate only one = myDiscriminator per source IP/FEC combination? o Effectively, IMO, there are separate p2p BFD sessions between head and = tail of mp2p tunnel. Right? * Section 3 o Since two types of BFD encapsulation available, I think it would be bet= ter to require that only one type be used to monitor particular E-VPN at it= s Network level. Should it say "The same type of BFD encapsulation, either = IP or VCCV, MUST be used to monitor all tunnels of the particular E-VPN at = its Network level." o s/G-Ach/G-ACh/ * Section 4 o Not clear which BFD modes can be used and in what manner as on-demand O= AM to troubleshoot and localize fault. AFAIK, BFD-based OAM used primarily = as proactive continuity check and LSP Ping as on-demand troubleshooting too= l. --_000_7347100B5761DC41A166AC17F22DF1121B71E5A9eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Authors, et. al,

very useful and timely raised questions. Please find= my comments to both documents below. Greatly appreciate your kind consider= ation and am looking forward to the discussion.

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

 

draft-salam-l2vpn-evpn-oam-req-frmwk-01

  • Use cases. Multi-carrier E-VPN. Ethernet Service OAM is instrumented, throu= gh MEG Level hierarchy, to present customer, provider, and operator scopes = of OAM. If multi-carrier E-VPN is viable use case, then support of MEP and = its functionalities becomes a MUST for provider and operator scopes. Then, if multi-carrier E-VPN is viable u= se case, there might be new requirements towards E-VPN Network OAM.
  • Sec.1.1 s/Public/Packet/
  • CFM … defines concept … Maintenance Association …
  • Sec.1.3 MEG, Maintenance Entity Group, is object of Y.1731 equivalent to MA= of CFM. Note that MEG is used in MPLS-TP OAM as well.
  • Definition of MIP is not correct. MIP can terminate certain OAM, both Ether= net and MPLS-TP, frames, e.g. ETH-LB.
  • Maintenance Domain, as mentioned in 1.1, is object of CFM and is not used i= n Y.1731. Suggest use consistent terminology, either CFM or Y.1731.
  • Figure 2, can use EFM (Ethernet First Mile) OAM instead of 802.3 OAM. (Note= that there are two Figure 2 in the document – Section 2.1 and Sectio= n 3.1.1.2.1)
  • Section 2.2
    • Characterize whether MEP on PEs SHOULD be Up, Down or both.
      • =
  • Section 2.4
    • Would BFD (RFC 5880, RFC 5881, RFC 5883, RFC 5884, and RFC 5885) be applica= ble as well as RFC 6428?
  • Section 2.6
    • I think that OAM interworking is most useful when it exists between proacti= ve OAM mechanisms whether it in peer-to-peer or client-server model. I don&= #8217;t see that there’s requirement of proactive Network OAM. Should= there be one? E.g. “E-VPN Network OAM SHOULD provide both proactive and on-demand mechanisms of monitoring its data pla= ne operation and data plane conformance to state of its control plane.̶= 1;
  • Section 3.1.1
    • Please consider splitting the sentence in two with the second being like &#= 8220;… without time bound. Certain actions, e.g. protection switchove= r or alarm indication signaling, could be associated with events of enterin= g and clearing fault state”.
  • Section 3.1.1.1
    • I think that another term for “a specified path taken by a particular= user data flow” is “in-band monitoring”.
      • =
    • I think that monitoring of “representative path” may not be rel= iable test of MEP hosting node liveliness. As I understand, it still verifi= cation of the MEP liveliness but out-band. Or it is implied that the target= of this monitoring is not the MEP but an ID associated with the node where the MEP defined? Then wouldn’t that b= e verification of a control plane rather than data plane operation?
    • What is understood as “test flow”? Is that using methods of act= ive monitoring/measurements when specifically constructed test packets bein= g injected vs. passive monitoring/measurements when data flow(s) used to mo= nitor and measure performance?
    • “Monitoring of all ECMP paths between MEPs is not a requirement for E= -VPN OAM.” Is in regard to concurrent monitoring all paths between tw= o (?) MEPs or to problem of exercising particular paths at-will?=
    • I’m not sure that the last requirement is applicable to E-VPN Service= OAM. CFM and/or Y.1731 would not be used differently when monitoring unica= st only or unicast and multicast services.
  • Section 3.1.1.2.2
    • What is understood by “support RDI”? Is it merely ability to si= gnal LoC defect to remote MEP(s) or ability, as well, to recognize RDI from= a remote MEP? Should note that in multipoint MA RDI is not really useful a= s indicator of unidirectional fault since there’s no indication of with which MEP the sender detected LoC defect. If unidire= ctional LoC is likely not guarantee of bi-directional fault, then MA MUST b= e p2p.
  • Section 3.1.2.2
    • Connectivity Verification vs. Continuity Check. There’s reference to = “connectivity faults” in the first paragraph. Should it be chan= ged to “continuity” or on-demand OAM, at least in E-VPN Service= OAM, required to detect mis-connectivity? If “yes”, why the sa= me is not applicable to proactive OAM for E-VPN Service?
  • Section 3.2
    • I wouldn’t refer to scheduled on-demand PM tests as “proactive&= #8221; since these are still bound in time unlike proactive that are not bo= und in time.
    • But there is at least one example of truly proactive LM in Y.1731 that uses= ETH-CC frames. So, there’s a distinction between proactive and on-de= mand PM.
  • Section 3.2.1
    • Use of Synthetic LM is usually in out-of-service state as test frames expec= ted to be statistically representative of real data flow. LM in mp2mp netwo= rk can be constructed of set of p2p LM metrics.

draft-vgovindan-l2vpn-ev= pn-bfd-00

·         Section 2.1.1

o   If there’s a need to have BFD session = per ECMP path/EL how such session can be demuxed at the tail if at the boot= strap it would allocate only one myDiscriminator per source IP/FEC combinat= ion?

o   Effectively, IMO, there are separate p2p BFD= sessions between head and tail of mp2p tunnel. Right?

·         Section 3

o   Since two types of BFD encapsulation availab= le, I think it would be better to require that only one type be used to mon= itor particular E-VPN at its Network level. Should it say “The same t= ype of BFD encapsulation, either IP or VCCV, MUST be used to monitor all tunnels of the particular E-VPN at its N= etwork level.”

o   s/G-Ach/G-ACh/

·         Section 4

o   Not clear which BFD modes can be used and in= what manner as on-demand OAM to troubleshoot and localize fault. AFAIK, BF= D-based OAM used primarily as proactive continuity check and LSP Ping as on= -demand troubleshooting tool.

 

--_000_7347100B5761DC41A166AC17F22DF1121B71E5A9eusaamb103erics_-- From ssalam@cisco.com Wed Nov 20 14:25:43 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58AAD1AE435 for ; Wed, 20 Nov 2013 14:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.025 X-Spam-Level: X-Spam-Status: No, score=-10.025 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LW5RXLkq6Si7 for ; Wed, 20 Nov 2013 14:25:40 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id D4CF51AE419 for ; Wed, 20 Nov 2013 14:25:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31715; q=dns/txt; s=iport; t=1384986333; x=1386195933; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=RTmgVwlGmzIQ3omzWQ6IXohwL985+BuWKhatReIXFWw=; b=SWZSGrgLnQq4a9JAkJfoorqGJjuMjDnpehFga0q4t+y/hhLYaKmx4JKx p0aqQiOjnoRNPeeD5uFo2iKt7mbIUOUyndKpjCrNhrm2CI5Tg36xvhQ7B g6H5wjWHi3zpa8xfrLiWCE4GUFcFBVkN7EP3NIowL2LklqXUVKxEd3obf g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAOE1jVKtJV2b/2dsb2JhbABZgkMjIThTvXqBGhZ0giUBAgQtOiQBCBEDAQIhAQYoERQJCAEBBAESh28DDwG4Ow2ILheMcoJoGIQyA5YngWuMVYU4gWqBPoIq X-IronPort-AV: E=Sophos;i="4.93,739,1378857600"; d="scan'208,217";a="1059069" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP; 20 Nov 2013 22:25:32 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rAKMPWx4016247 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Nov 2013 22:25:32 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Wed, 20 Nov 2013 16:25:32 -0600 From: "Samer Salam (ssalam)" To: Gregory Mirsky , "Ali Sajassi (sajassi)" , "Sam Aldrin (aldrin.ietf@gmail.com)" , "John E Drake (jdrake@juniper.net)" , "Vengada Prasad Govindan (venggovi)" , "l2vpn@ietf.org" Subject: Re: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and draft-vgovindan-l2vpn-evpn-bfd Thread-Topic: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and draft-vgovindan-l2vpn-evpn-bfd Thread-Index: Ac7lDSTCOfeFij7fTiOpIkx3ocp0YQBIYKKA Date: Wed, 20 Nov 2013 22:25:32 +0000 Message-ID: In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B71E5A9@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [161.44.210.138] Content-Type: multipart/alternative; boundary="_000_CEB27671165BFssalamciscocom_" MIME-Version: 1.0 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 22:25:43 -0000 --_000_CEB27671165BFssalamciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thank you Greg for your review and comments. Will incorporate them in the n= ext revision of the oam-req-frmwk draft. Regards, Samer From: Gregory Mirsky > Date: Tuesday, 19 November, 2013 4:56 AM To: Samer Salam >, "Ali Sajassi (= sajassi)" >, "Sam Aldrin (aldri= n.ietf@gmail.com)" >, "John E Drake (jdrake@juniper.net)" >, "Vengada = Prasad Govindan (venggovi)" >= , "l2vpn@ietf.org" > Subject: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and draft-vgovind= an-l2vpn-evpn-bfd Dear Authors, et. al, very useful and timely raised questions. Please find my comments to both do= cuments below. Greatly appreciate your kind consideration and am looking fo= rward to the discussion. Regards, Greg draft-salam-l2vpn-evpn-oam-req-frmwk-01 * Use cases. Multi-carrier E-VPN. Ethernet Service OAM is instrumented,= through MEG Level hierarchy, to present customer, provider, and operator s= copes of OAM. If multi-carrier E-VPN is viable use case, then support of ME= P and its functionalities becomes a MUST for provider and operator scopes. = Then, if multi-carrier E-VPN is viable use case, there might be new require= ments towards E-VPN Network OAM. * Sec.1.1 s/Public/Packet/ * CFM =85 defines concept =85 Maintenance Association =85 * Sec.1.3 MEG, Maintenance Entity Group, is object of Y.1731 equivalent= to MA of CFM. Note that MEG is used in MPLS-TP OAM as well. * Definition of MIP is not correct. MIP can terminate certain OAM, both= Ethernet and MPLS-TP, frames, e.g. ETH-LB. * Maintenance Domain, as mentioned in 1.1, is object of CFM and is not = used in Y.1731. Suggest use consistent terminology, either CFM or Y.1731. * Figure 2, can use EFM (Ethernet First Mile) OAM instead of 802.3 OAM.= (Note that there are two Figure 2 in the document =96 Section 2.1 and Sect= ion 3.1.1.2.1) * Section 2.2 * Characterize whether MEP on PEs SHOULD be Up, Down or both. * Section 2.4 * Would BFD (RFC 5880, RFC 5881, RFC 5883, RFC 5884, and RFC 5885) b= e applicable as well as RFC 6428? * Section 2.6 * I think that OAM interworking is most useful when it exists betwee= n proactive OAM mechanisms whether it in peer-to-peer or client-server mode= l. I don=92t see that there=92s requirement of proactive Network OAM. Shoul= d there be one? E.g. =93E-VPN Network OAM SHOULD provide both proactive and= on-demand mechanisms of monitoring its data plane operation and data plane= conformance to state of its control plane.=94 * Section 3.1.1 * Please consider splitting the sentence in two with the second bein= g like =93=85 without time bound. Certain actions, e.g. protection switchov= er or alarm indication signaling, could be associated with events of enteri= ng and clearing fault state=94. * Section 3.1.1.1 * I think that another term for =93a specified path taken by a parti= cular user data flow=94 is =93in-band monitoring=94. * I think that monitoring of =93representative path=94 may not be re= liable test of MEP hosting node liveliness. As I understand, it still verif= ication of the MEP liveliness but out-band. Or it is implied that the targe= t of this monitoring is not the MEP but an ID associated with the node wher= e the MEP defined? Then wouldn=92t that be verification of a control plane = rather than data plane operation? * What is understood as =93test flow=94? Is that using methods of ac= tive monitoring/measurements when specifically constructed test packets bei= ng injected vs. passive monitoring/measurements when data flow(s) used to m= onitor and measure performance? * =93Monitoring of all ECMP paths between MEPs is not a requirement = for E-VPN OAM.=94 Is in regard to concurrent monitoring all paths between t= wo (?) MEPs or to problem of exercising particular paths at-will? * I=92m not sure that the last requirement is applicable to E-VPN Se= rvice OAM. CFM and/or Y.1731 would not be used differently when monitoring = unicast only or unicast and multicast services. * Section 3.1.1.2.2 * What is understood by =93support RDI=94? Is it merely ability to s= ignal LoC defect to remote MEP(s) or ability, as well, to recognize RDI fro= m a remote MEP? Should note that in multipoint MA RDI is not really useful = as indicator of unidirectional fault since there=92s no indication of with = which MEP the sender detected LoC defect. If unidirectional LoC is likely n= ot guarantee of bi-directional fault, then MA MUST be p2p. * Section 3.1.2.2 * Connectivity Verification vs. Continuity Check. There=92s referenc= e to =93connectivity faults=94 in the first paragraph. Should it be changed= to =93continuity=94 or on-demand OAM, at least in E-VPN Service OAM, requi= red to detect mis-connectivity? If =93yes=94, why the same is not applicabl= e to proactive OAM for E-VPN Service? * Section 3.2 * I wouldn=92t refer to scheduled on-demand PM tests as =93proactive= =94 since these are still bound in time unlike proactive that are not bound= in time. * But there is at least one example of truly proactive LM in Y.1731 = that uses ETH-CC frames. So, there=92s a distinction between proactive and = on-demand PM. * Section 3.2.1 * Use of Synthetic LM is usually in out-of-service state as test fra= mes expected to be statistically representative of real data flow. LM in mp= 2mp network can be constructed of set of p2p LM metrics. draft-vgovindan-l2vpn-evpn-bfd-00 =B7 Section 2.1.1 o If there=92s a need to have BFD session per ECMP path/EL how such sessi= on can be demuxed at the tail if at the bootstrap it would allocate only on= e myDiscriminator per source IP/FEC combination? o Effectively, IMO, there are separate p2p BFD sessions between head and = tail of mp2p tunnel. Right? =B7 Section 3 o Since two types of BFD encapsulation available, I think it would be bet= ter to require that only one type be used to monitor particular E-VPN at it= s Network level. Should it say =93The same type of BFD encapsulation, eithe= r IP or VCCV, MUST be used to monitor all tunnels of the particular E-VPN a= t its Network level.=94 o s/G-Ach/G-ACh/ =B7 Section 4 o Not clear which BFD modes can be used and in what manner as on-demand O= AM to troubleshoot and localize fault. AFAIK, BFD-based OAM used primarily = as proactive continuity check and LSP Ping as on-demand troubleshooting too= l. --_000_CEB27671165BFssalamciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <94208F4A92DCE94E98579C14067BFED7@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Thank you Greg for your review and comments. Will incorporate them in = the next revision of the oam-req-frmwk draft.

Regards,
Samer

From: Gregory Mirsky <gregory.mirsky@ericsson.com> Date: Tuesday, 19 November, 2013 4:= 56 AM
To: Samer Salam <ssalam@cisco.com>, "Ali Sajassi (sajassi)&= quot; <sajassi@cisco.com>, &= quot;Sam Aldrin (aldrin.ietf@gmail= .com)" <aldrin.ietf@gmail.com>= , "John E Drake (jdrake@juniper.= net)" <jdrake@juniper.net= >, "Vengada Prasad Govindan (venggovi)" <venggovi@cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: Comments on draft-salam-l2= vpn-evpn-oam-req-frmwk and draft-vgovindan-l2vpn-evpn-bfd

Dear Authors, et. al,

very useful and timely raised questions. Please find= my comments to both documents below. Greatly appreciate your kind consider= ation and am looking forward to the discussion.

 

        &nbs= p;       Regards,

        &nbs= p;            &= nbsp;          Greg=

 

draft-salam-l2vpn-evpn-oam-req-frmwk-01

  • Use cases. Multi-carrier E-VPN. Ethernet Service OAM is instrumented, throu= gh MEG Level hierarchy, to present customer, provider, and operator scopes = of OAM. If multi-carrier E-VPN is viable use case, then support of MEP and = its functionalities becomes a MUST for provider and operator scopes. Then, if multi-carrier E-VPN is viable u= se case, there might be new requirements towards E-VPN Network OAM.
  • Sec.1.1 s/Public/Packet/
  • CFM =85 defines concept =85 Maintenance Association =85
  • Sec.1.3 MEG, Maintenance Entity Group, is object of Y.1731 equivalent to MA= of CFM. Note that MEG is used in MPLS-TP OAM as well.
  • Definition of MIP is not correct. MIP can terminate certain OAM, both Ether= net and MPLS-TP, frames, e.g. ETH-LB.
  • Maintenance Domain, as mentioned in 1.1, is object of CFM and is not used i= n Y.1731. Suggest use consistent terminology, either CFM or Y.1731.
  • Figure 2, can use EFM (Ethernet First Mile) OAM instead of 802.3 OAM. (Note= that there are two Figure 2 in the document =96 Section 2.1 and Section 3.= 1.1.2.1)
  • Section 2.2
    • Characterize whether MEP on PEs SHOULD be Up, Down or both.
      • =
  • Section 2.4
    • Would BFD (RFC 5880, RFC 5881, RFC 5883, RFC 5884, and RFC 5885) be applica= ble as well as RFC 6428?
  • Section 2.6
    • I think that OAM interworking is most useful when it exists between proacti= ve OAM mechanisms whether it in peer-to-peer or client-server model. I don= =92t see that there=92s requirement of proactive Network OAM. Should there = be one? E.g. =93E-VPN Network OAM SHOULD provide both proactive and on-demand mechanisms of monitoring its data pla= ne operation and data plane conformance to state of its control plane.=94
  • Section 3.1.1
    • Please consider splitting the sentence in two with the second being like = =93=85 without time bound. Certain actions, e.g. protection switchover or a= larm indication signaling, could be associated with events of entering and = clearing fault state=94.
  • Section 3.1.1.1
    • I think that another term for =93a specified path taken by a particular use= r data flow=94 is =93in-band monitoring=94.
    • I think that monitoring of =93representative path=94 may not be reliable te= st of MEP hosting node liveliness. As I understand, it still verification o= f the MEP liveliness but out-band. Or it is implied that the target of this= monitoring is not the MEP but an ID associated with the node where the MEP defined? Then wouldn=92t that be ve= rification of a control plane rather than data plane operation?<= /li>
    • What is understood as =93test flow=94? Is that using methods of active moni= toring/measurements when specifically constructed test packets being inject= ed vs. passive monitoring/measurements when data flow(s) used to monitor an= d measure performance?
    • =93Monitoring of all ECMP paths between MEPs is not a requirement for E-VPN= OAM.=94 Is in regard to concurrent monitoring all paths between two (?) ME= Ps or to problem of exercising particular paths at-will?
      • I=92m not sure that the last requirement is applicable to E-VPN Service OAM= . CFM and/or Y.1731 would not be used differently when monitoring unicast o= nly or unicast and multicast services.
  • Section 3.1.1.2.2
    • What is understood by =93support RDI=94? Is it merely ability to signal LoC= defect to remote MEP(s) or ability, as well, to recognize RDI from a remot= e MEP? Should note that in multipoint MA RDI is not really useful as indica= tor of unidirectional fault since there=92s no indication of with which MEP the sender detected LoC defect. If unidire= ctional LoC is likely not guarantee of bi-directional fault, then MA MUST b= e p2p.
  • Section 3.1.2.2
    • Connectivity Verification vs. Continuity Check. There=92s reference to =93c= onnectivity faults=94 in the first paragraph. Should it be changed to =93co= ntinuity=94 or on-demand OAM, at least in E-VPN Service OAM, required to de= tect mis-connectivity? If =93yes=94, why the same is not applicable to proactive OAM for E-VPN Service?
  • Section 3.2
    • I wouldn=92t refer to scheduled on-demand PM tests as =93proactive=94 since= these are still bound in time unlike proactive that are not bound in time.=
    • But there is at least one example of truly proactive LM in Y.1731 that uses= ETH-CC frames. So, there=92s a distinction between proactive and on-demand= PM.
  • Section 3.2.1
    • Use of Synthetic LM is usually in out-of-service state as test frames expec= ted to be statistically representative of real data flow. LM in mp2mp netwo= rk can be constructed of set of p2p LM metrics.

draft-vgovindan-l2vpn-ev= pn-bfd-00

= =B7 o   If there=92s a need to have BFD session = per ECMP path/EL how such session can be demuxed at the tail if at the boot= strap it would allocate only one myDiscriminator per source IP/FEC combinat= ion?

o   Effectively, IMO, there are separate p2p= BFD sessions between head and tail of mp2p tunnel. Right?

= =B7 o   Since two types of BFD encapsulation ava= ilable, I think it would be better to require that only one type be used to= monitor particular E-VPN at its Network level. Should it say =93The same t= ype of BFD encapsulation, either IP or VCCV, MUST be used to monitor all tunnels of the particular E-VPN at it= s Network level.=94

o   s/G-Ach/G-ACh/

= =B7 o   Not clear which BFD modes can be used an= d in what manner as on-demand OAM to troubleshoot and localize fault. AFAIK= , BFD-based OAM used primarily as proactive continuity check and LSP Ping a= s on-demand troubleshooting tool.

 

 --_000_CEB27671165BFssalamciscocom_-- From venggovi@cisco.com Thu Nov 21 08:36:16 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2E11AE1D5 for ; Thu, 21 Nov 2013 08:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.025 X-Spam-Level: X-Spam-Status: No, score=-10.025 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yOYDavAWD2U for ; Thu, 21 Nov 2013 08:36:11 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 387671AE1D4 for ; Thu, 21 Nov 2013 08:36:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39104; q=dns/txt; s=iport; t=1385051764; x=1386261364; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=i+aTtOKnQQq/GtsELUZKaBBOlfRctfGAq/mdQAwKL6s=; b=CbESw1nCbp50nNceUdGabaQk9FGtbcQTYyAAolXqLj59HOyviMKwb4wx crdF4vJiN7XxGS2bw3cQG5gSOWbV/MT9F7V6MixIEHjKZTzmPhrHLCDsA LQ9gzMyJbkjqGV9N7FGq3itrs9EAmFJivhUdTL8IkVwMKfd91/yE5nZVO 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhsFAEs1jlKtJV2a/2dsb2JhbABZgkNEOFO8VYEkFnSCJQEBAQQtOiICAQgRAwEBAQsWAQYHIREUCQgBAQQBEgiHZwMPuGYNiC0XjHKCSCAXAYMggRIDlieOQ4U4gWqBPoIq X-IronPort-AV: E=Sophos;i="4.93,745,1378857600"; d="scan'208,217";a="1250848" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP; 21 Nov 2013 16:36:03 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id rALGa32o026282 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Nov 2013 16:36:03 GMT Received: from xmb-rcd-x15.cisco.com ([169.254.5.54]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Thu, 21 Nov 2013 10:36:02 -0600 From: "Vengada Prasad Govindan (venggovi)" To: "Samer Salam (ssalam)" , Gregory Mirsky , "Ali Sajassi (sajassi)" , "Sam Aldrin (aldrin.ietf@gmail.com)" , "John E Drake (jdrake@juniper.net)" , "l2vpn@ietf.org" Subject: RE: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and draft-vgovindan-l2vpn-evpn-bfd Thread-Topic: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and draft-vgovindan-l2vpn-evpn-bfd Thread-Index: Ac7lDSTCOfeFij7fTiOpIkx3ocp0YQBIYKKAACnc4DA= Date: Thu, 21 Nov 2013 16:36:02 +0000 Message-ID: <315041E4211CB84E86EF7C25A2AB583D33843129@xmb-rcd-x15.cisco.com> References: <7347100B5761DC41A166AC17F22DF1121B71E5A9@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.51.249] Content-Type: multipart/alternative; boundary="_000_315041E4211CB84E86EF7C25A2AB583D33843129xmbrcdx15ciscoc_" MIME-Version: 1.0 X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Nov 2013 16:36:16 -0000 --_000_315041E4211CB84E86EF7C25A2AB583D33843129xmbrcdx15ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Greg, Thanks for your comments, please find replies inlined with GVP1> Prasad From: Samer Salam (ssalam) Sent: Thursday, November 21, 2013 3:56 AM To: Gregory Mirsky; Ali Sajassi (sajassi); Sam Aldrin (aldrin.ietf@gmail.co= m); John E Drake (jdrake@juniper.net); Vengada Prasad Govindan (venggovi); = l2vpn@ietf.org Subject: Re: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and draft-vgo= vindan-l2vpn-evpn-bfd Thank you Greg for your review and comments. Will incorporate them in the n= ext revision of the oam-req-frmwk draft. Regards, Samer From: Gregory Mirsky > Date: Tuesday, 19 November, 2013 4:56 AM To: Samer Salam >, "Ali Sajassi (= sajassi)" >, "Sam Aldrin (aldri= n.ietf@gmail.com)" >, "John E Drake (jdrake@juniper.net)" >, "Vengada = Prasad Govindan (venggovi)" >= , "l2vpn@ietf.org" > Subject: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and draft-vgovind= an-l2vpn-evpn-bfd Dear Authors, et. al, very useful and timely raised questions. Please find my comments to both do= cuments below. Greatly appreciate your kind consideration and am looking fo= rward to the discussion. Regards, Greg draft-salam-l2vpn-evpn-oam-req-frmwk-01 * Use cases. Multi-carrier E-VPN. Ethernet Service OAM is instrumented,= through MEG Level hierarchy, to present customer, provider, and operator s= copes of OAM. If multi-carrier E-VPN is viable use case, then support of ME= P and its functionalities becomes a MUST for provider and operator scopes. = Then, if multi-carrier E-VPN is viable use case, there might be new require= ments towards E-VPN Network OAM. * Sec.1.1 s/Public/Packet/ * CFM ... defines concept ... Maintenance Association ... * Sec.1.3 MEG, Maintenance Entity Group, is object of Y.1731 equivalent= to MA of CFM. Note that MEG is used in MPLS-TP OAM as well. * Definition of MIP is not correct. MIP can terminate certain OAM, both= Ethernet and MPLS-TP, frames, e.g. ETH-LB. * Maintenance Domain, as mentioned in 1.1, is object of CFM and is not = used in Y.1731. Suggest use consistent terminology, either CFM or Y.1731. * Figure 2, can use EFM (Ethernet First Mile) OAM instead of 802.3 OAM.= (Note that there are two Figure 2 in the document - Section 2.1 and Sectio= n 3.1.1.2.1) * Section 2.2 * Characterize whether MEP on PEs SHOULD be Up, Down or both. * Section 2.4 * Would BFD (RFC 5880, RFC 5881, RFC 5883, RFC 5884, and RFC 5885) b= e applicable as well as RFC 6428? * Section 2.6 * I think that OAM interworking is most useful when it exists betwee= n proactive OAM mechanisms whether it in peer-to-peer or client-server mode= l. I don't see that there's requirement of proactive Network OAM. Should th= ere be one? E.g. "E-VPN Network OAM SHOULD provide both proactive and on-de= mand mechanisms of monitoring its data plane operation and data plane confo= rmance to state of its control plane." * Section 3.1.1 * Please consider splitting the sentence in two with the second bein= g like "... without time bound. Certain actions, e.g. protection switchover= or alarm indication signaling, could be associated with events of entering= and clearing fault state". * Section 3.1.1.1 * I think that another term for "a specified path taken by a particu= lar user data flow" is "in-band monitoring". * I think that monitoring of "representative path" may not be reliab= le test of MEP hosting node liveliness. As I understand, it still verificat= ion of the MEP liveliness but out-band. Or it is implied that the target of= this monitoring is not the MEP but an ID associated with the node where th= e MEP defined? Then wouldn't that be verification of a control plane rather= than data plane operation? * What is understood as "test flow"? Is that using methods of active= monitoring/measurements when specifically constructed test packets being i= njected vs. passive monitoring/measurements when data flow(s) used to monit= or and measure performance? * "Monitoring of all ECMP paths between MEPs is not a requirement fo= r E-VPN OAM." Is in regard to concurrent monitoring all paths between two (= ?) MEPs or to problem of exercising particular paths at-will? * I'm not sure that the last requirement is applicable to E-VPN Serv= ice OAM. CFM and/or Y.1731 would not be used differently when monitoring un= icast only or unicast and multicast services. * Section 3.1.1.2.2 * What is understood by "support RDI"? Is it merely ability to signa= l LoC defect to remote MEP(s) or ability, as well, to recognize RDI from a = remote MEP? Should note that in multipoint MA RDI is not really useful as i= ndicator of unidirectional fault since there's no indication of with which = MEP the sender detected LoC defect. If unidirectional LoC is likely not gua= rantee of bi-directional fault, then MA MUST be p2p. * Section 3.1.2.2 * Connectivity Verification vs. Continuity Check. There's reference = to "connectivity faults" in the first paragraph. Should it be changed to "c= ontinuity" or on-demand OAM, at least in E-VPN Service OAM, required to det= ect mis-connectivity? If "yes", why the same is not applicable to proactive= OAM for E-VPN Service? * Section 3.2 * I wouldn't refer to scheduled on-demand PM tests as "proactive" si= nce these are still bound in time unlike proactive that are not bound in ti= me. * But there is at least one example of truly proactive LM in Y.1731 = that uses ETH-CC frames. So, there's a distinction between proactive and on= -demand PM. * Section 3.2.1 * Use of Synthetic LM is usually in out-of-service state as test fra= mes expected to be statistically representative of real data flow. LM in mp= 2mp network can be constructed of set of p2p LM metrics. draft-vgovindan-l2vpn-evpn-bfd-00 * Section 2.1.1 o If there's a need to have BFD session per ECMP path/EL how such session= can be demuxed at the tail if at the bootstrap it would allocate only one = myDiscriminator per source IP/FEC combination? o Effectively, IMO, there are separate p2p BFD sessions between head and = tail of mp2p tunnel. Right? GVP1> Agreed, separate P2P BFD session(s) are needed between the head and t= he tail of a MP2P tunnel. If entropy labels are used one BFD session and he= nce one discriminator is needed for each entropy label used by the Source I= P/FEC combination. This text would be clarified in the next revision. * Section 3 o Since two types of BFD encapsulation available, I think it would be bet= ter to require that only one type be used to monitor particular E-VPN at it= s Network level. Should it say "The same type of BFD encapsulation, either = IP or VCCV, MUST be used to monitor all tunnels of the particular E-VPN at = its Network level." o s/G-Ach/G-ACh/ GVP1> Agreed. Will clarify the text. * Section 4 o Not clear which BFD modes can be used and in what manner as on-demand O= AM to troubleshoot and localize fault. AFAIK, BFD-based OAM used primarily = as proactive continuity check and LSP Ping as on-demand troubleshooting too= l. GVP1> The intent of this Section is to highlight the possible scalability = issues that could arise. The term demand-driven manner was used to imply th= at BFD could be turned ON and OFF as desired, instead of an ALWAYS-ON mode.= Do you have any suggestions to improve the text here? Please let us know. --_000_315041E4211CB84E86EF7C25A2AB583D33843129xmbrcdx15ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Greg,=

  Thanks for your= comments, please find replies inlined with GVP1>

Prasad

 

From: Samer Sa= lam (ssalam)
Sent: Thursday, November 21, 2013 3:56 AM
To: Gregory Mirsky; Ali Sajassi (sajassi); Sam Aldrin (aldrin.ietf@g= mail.com); John E Drake (jdrake@juniper.net); Vengada Prasad Govindan (veng= govi); l2vpn@ietf.org
Subject: Re: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and dr= aft-vgovindan-l2vpn-evpn-bfd

 

Thank y= ou Greg for your review and comments. Will incorporate them in the next rev= ision of the oam-req-frmwk draft.

&n= bsp;

Regards= ,

Samer

&n= bsp;

From: Gregory Mirsky <gregory.mirsky@ericsson.com>
Date: Tuesday, 19 November, 2013 4:56 AM
To: Samer Salam <ssalam@cisco= .com>, "Ali Sajassi (sajassi)" <sajassi@cisco.com>, "Sam Aldrin (aldrin.ietf@gmail.com)" <aldrin.ietf@gmail.com>, "John E Drake (jdrake@juniper.n= et)" <jdrake@juniper.net<= /a>>, "Vengada Prasad Govindan (venggovi)" <venggovi@cisco.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: Comments on draft-salam-l2vpn-evpn-oam-req-frmwk and draft-= vgovindan-l2vpn-evpn-bfd

&n= bsp;

Dear Authors, et. al,

very useful and timely r= aised questions. Please find my comments to both documents below. Greatly a= ppreciate your kind consideration and am looking forward to the discussion.=

 =

    =             Regards,=

    =             &nb= sp;            =    Greg

 =

draft-salam-l2vpn-evpn-o= am-req-frmwk-01

  • Use cases. Multi-carrier E-VPN. Ethernet Service OAM is instrumented, throu= gh MEG Level hierarchy, to present customer, provider, and operator scopes = of OAM. If multi-carrier E-VPN is viable use case, then support of MEP and = its functionalities becomes a MUST for provider and operator scopes. Then, if multi-carrier E-VPN is viable u= se case, there might be new requirements towards E-VPN Network OAM.
  • Sec.1.1 s/Public/Packet/
  • CFM … defines concept … Maintenance Association …
  • Sec.1.3 MEG, Maintenance Entity Group, is object of Y.1731 equivalent to MA= of CFM. Note that MEG is used in MPLS-TP OAM as well.
  • Definition of MIP is not correct. MIP can terminate certain OAM, both Ether= net and MPLS-TP, frames, e.g. ETH-LB.
  • Maintenance Domain, as mentioned in 1.1, is object of CFM and is not used i= n Y.1731. Suggest use consistent terminology, either CFM or Y.1731.
  • Figure 2, can use EFM (Ethernet First Mile) OAM instead of 802.3 OAM. (Note= that there are two Figure 2 in the document – Section 2.1 and Sectio= n 3.1.1.2.1)
  • Section 2.2
    • Characterize whether MEP on PEs SHOULD be Up, Down or both.
      • =
  • Section 2.4
    • Would BFD (RFC 5880, RFC 5881, RFC 5883, RFC 5884, and RFC 5885) be applica= ble as well as RFC 6428?
  • Section 2.6
    • I think that OAM interworking is most useful when it exists between proacti= ve OAM mechanisms whether it in peer-to-peer or client-server model. I don&= #8217;t see that there’s requirement of proactive Network OAM. Should= there be one? E.g. “E-VPN Network OAM SHOULD provide both proactive and on-demand mechanisms of monitoring its data pla= ne operation and data plane conformance to state of its control plane.̶= 1;
  • Section 3.1.1
    • Please consider splitting the sentence in two with the second being like &#= 8220;… without time bound. Certain actions, e.g. protection switchove= r or alarm indication signaling, could be associated with events of enterin= g and clearing fault state”.
  • Section 3.1.1.1
    • I think that another term for “a specified path taken by a particular= user data flow” is “in-band monitoring”.
      • =
    • I think that monitoring of “representative path” may not be rel= iable test of MEP hosting node liveliness. As I understand, it still verifi= cation of the MEP liveliness but out-band. Or it is implied that the target= of this monitoring is not the MEP but an ID associated with the node where the MEP defined? Then wouldn’t that b= e verification of a control plane rather than data plane operation?
    • What is understood as “test flow”? Is that using methods of act= ive monitoring/measurements when specifically constructed test packets bein= g injected vs. passive monitoring/measurements when data flow(s) used to mo= nitor and measure performance?
    • “Monitoring of all ECMP paths between MEPs is not a requirement for E= -VPN OAM.” Is in regard to concurrent monitoring all paths between tw= o (?) MEPs or to problem of exercising particular paths at-will?=
    • I’m not sure that the last requirement is applicable to E-VPN Service= OAM. CFM and/or Y.1731 would not be used differently when monitoring unica= st only or unicast and multicast services.
  • Section 3.1.1.2.2
    • What is understood by “support RDI”? Is it merely ability to si= gnal LoC defect to remote MEP(s) or ability, as well, to recognize RDI from= a remote MEP? Should note that in multipoint MA RDI is not really useful a= s indicator of unidirectional fault since there’s no indication of with which MEP the sender detected LoC defect. If unidire= ctional LoC is likely not guarantee of bi-directional fault, then MA MUST b= e p2p.
  • Section 3.1.2.2
    • Connectivity Verification vs. Continuity Check. There’s reference to = “connectivity faults” in the first paragraph. Should it be chan= ged to “continuity” or on-demand OAM, at least in E-VPN Service= OAM, required to detect mis-connectivity? If “yes”, why the sa= me is not applicable to proactive OAM for E-VPN Service?
  • Section 3.2
    • I wouldn’t refer to scheduled on-demand PM tests as “proactive&= #8221; since these are still bound in time unlike proactive that are not bo= und in time.
    • But there is at least one example of truly proactive LM in Y.1731 that uses= ETH-CC frames. So, there’s a distinction between proactive and on-de= mand PM.
  • Section 3.2.1
    • Use of Synthetic LM is usually in out-of-service state as test frames expec= ted to be statistically representative of real data flow. LM in mp2mp netwo= rk can be constructed of set of p2p LM metrics.

draft-vgovindan-l2vpn-evpn-bfd-00

·         Section 2.1.1

o   If there’s= a need to have BFD session per ECMP path/EL how such session can be demuxe= d at the tail if at the bootstrap it would allocate only one myDiscriminato= r per source IP/FEC combination?

o   Effectively, IMO= , there are separate p2p BFD sessions between head and tail of mp2p tunnel.= Right?

GVP1> Agreed, separate P2P BFD session(s) are = needed between the head and the tail of a MP2P tunnel. If entropy labels ar= e used one BFD session and hence one discriminator is needed for each entropy label used by the Source IP/FEC combination. Th= is text would be clarified in the next revision.

·         Section 3

o   Since two types = of BFD encapsulation available, I think it would be better to require that = only one type be used to monitor particular E-VPN at its Network level. Sho= uld it say “The same type of BFD encapsulation, either IP or VCCV, MUST be used to monitor all tunnels of the particular E= -VPN at its Network level.”

o   s/G-Ach/G-ACh/

GVP1> Agreed. Will clarify the text.

·         Section 4

o   Not clear which = BFD modes can be used and in what manner as on-demand OAM to troubleshoot a= nd localize fault. AFAIK, BFD-based OAM used primarily as proactive continu= ity check and LSP Ping as on-demand troubleshooting tool.

 GVP1> The intent of this Section is to highlight the = possible scalability issues that could arise. The term demand-driven manner= was used to imply that BFD could be turned ON and OFF as desired, instead of an ALWAYS-ON mode. Do you have any suggesti= ons to improve the text here? Please let us know.

 

--_000_315041E4211CB84E86EF7C25A2AB583D33843129xmbrcdx15ciscoc_-- From internet-drafts@ietf.org Fri Nov 22 08:34:18 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1D41AE18D; Fri, 22 Nov 2013 08:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CA-IWWzlnjZk; Fri, 22 Nov 2013 08:34:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 461FE1ADEA1; Fri, 22 Nov 2013 08:34:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l2vpn-vpls-mcast-16.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131122163417.16593.24719.idtracker@ietfa.amsl.com> Date: Fri, 22 Nov 2013 08:34:17 -0800 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 16:34:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 2 Virtual Private Networks Working = Group of the IETF. Title : Multicast in VPLS Author(s) : Rahul Aggarwal Juniper Networks Yuji Kamite Luyuan Fang Filename : draft-ietf-l2vpn-vpls-mcast-16.txt Pages : 51 Date : 2013-11-22 Abstract: [RFC4761] and [RFC4762] describe a solution for Virtual Private LAN Service (VPLS) multicast that relies on the use of point-to-point or multipoint-to-point unicast Label Switched Paths (LSPs) for carrying multicast traffic. This solution has certain limitations for certain VPLS multicast traffic profiles. For example, it may result in highly non-optimal bandwidth utilization when large amount of multicast traffic is to be transported. This document describes solutions for overcoming a subset of the limitations of existing VPLS multicast solution. It describes procedures for VPLS multicast that utilize multicast trees in the service provider (SP) network. The solution described in this document allows sharing of one such multicast tree among multiple VPLS instances. Furthermore, the solution described in this document allows a single multicast tree in the SP network to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLS instances. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-vpls-mcast There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-mcast-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2vpn-vpls-mcast-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wwwrun@rfc-editor.org Mon Nov 25 15:09:51 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396911AE092; Mon, 25 Nov 2013 15:09:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id loC4x5ESImyO; Mon, 25 Nov 2013 15:09:49 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:126c::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 835681AE089; Mon, 25 Nov 2013 15:09:49 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id A110275E016; Mon, 25 Nov 2013 15:09:46 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 7041 on Extensions to the Virtual Private LAN Service (VPLS) Provider Edge (PE) Model for Provider Backbone Bridging From: rfc-editor@rfc-editor.org Message-Id: <20131125230946.A110275E016@rfc-editor.org> Date: Mon, 25 Nov 2013 15:09:46 -0800 (PST) Cc: l2vpn@ietf.org, drafts-update-ref@iana.org, rfc-editor@rfc-editor.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 23:09:51 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7041 Title: Extensions to the Virtual Private LAN Service (VPLS) Provider Edge (PE) Model for Provider Backbone Bridging Author: F. Balus, Ed., A. Sajassi, Ed., N. Bitar, Ed. Status: Informational Stream: IETF Date: November 2013 Mailbox: florin.balus@alcatel-lucent.com, sajassi@cisco.com, nabil.n.bitar@verizon.com Pages: 15 Characters: 31236 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-l2vpn-pbb-vpls-pe-model-07.txt URL: http://www.rfc-editor.org/rfc/rfc7041.txt The IEEE 802.1 Provider Backbone Bridges (PBBs) specification defines an architecture and bridge protocols for interconnection of multiple Provider Bridged Networks (PBNs). Provider backbone bridging was defined by IEEE as a connectionless technology based on multipoint VLAN tunnels. PBB can be used to attain better scalability than Provider Bridges (PBs) in terms of the number of customer Media Access Control addresses and the number of service instances that can be supported. The Virtual Private LAN Service (VPLS) provides a framework for extending Ethernet LAN services, using MPLS tunneling capabilities, through a routed MPLS backbone without running the Rapid Spanning Tree Protocol (RSTP) or the Multiple Spanning Tree Protocol (MSTP) across the backbone. As a result, VPLS has been deployed on a large scale in service provider networks. This document discusses extensions to the VPLS Provider Edge (PE) model required to incorporate desirable PBB components while maintaining the service provider fit of the initial model. This document is a product of the Layer 2 Virtual Private Networks Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From iesg-secretary@ietf.org Tue Nov 26 09:33:57 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6801D1ADF78; Tue, 26 Nov 2013 09:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VhEYP6wwEvQ; Tue, 26 Nov 2013 09:33:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2522B1ADFAF; Tue, 26 Nov 2013 09:33:54 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Protocol Action: 'Multicast in VPLS' to Proposed Standard (draft-ietf-l2vpn-vpls-mcast-16.txt) X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131126173354.22383.61512.idtracker@ietfa.amsl.com> Date: Tue, 26 Nov 2013 09:33:54 -0800 Cc: l2vpn mailing list , l2vpn chair , RFC Editor X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 17:33:57 -0000 The IESG has approved the following document: - 'Multicast in VPLS' (draft-ietf-l2vpn-vpls-mcast-16.txt) as Proposed Standard This document is the product of the Layer 2 Virtual Private Networks Working Group. The IESG contact persons are Stewart Bryant and Adrian Farrel. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-l2vpn-vpls-mcast/ Technical Summary [RFC4761] and [RFC4762] describe a solution for Virtual Private LAN Service (VPLS) multicast that relies on the use of point-to-point or multipoint-to-point unicast Label Switched Paths (LSPs) for carrying multicast traffic. This solution has certain limitations for certain VPLS multicast traffic profiles. For example, it may result in highly non-optimal bandwidth utilization when large amount of multicast traffic is to be transported. This document describes solutions for overcoming a subset of the limitations of existing VPLS multicast solution. It describes procedures for VPLS multicast that utilize multicast trees in the service provider (SP) network. The solution described in this document allows sharing of one such multicast tree among multiple VPLS instances. Furthermore, the solution described in this document allows a single multicast tree in the SP network to carry traffic belonging only to a specified set of one or more IP multicast streams from one or more VPLS instances. Working Group Summary This document is an L2VPN Working Group document, and has been well reviewed in the working group through multiple iterations of the draft and WG last calls. The authors have addressed the comments received on the mailing list and the WG chairs. The draft was last-called after those comments were addressed and passed the WG last call. The document then received considerable review after it left the WG and has been updated accordingly. Document Quality The document has good quality. It is clear on the technical content and written with good English and layout. Personnel Document Shepherd: Nabil Bitar (nabil.n.bitar@verizon.com) Area Director: Stewart Bryant (stbryant@cisco.com) From internet-drafts@ietf.org Wed Nov 27 11:16:56 2013 Return-Path: X-Original-To: l2vpn@ietfa.amsl.com Delivered-To: l2vpn@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF631ADF6E; Wed, 27 Nov 2013 11:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EdQJVW3cIsQs; Wed, 27 Nov 2013 11:16:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 952A71AD8DA; Wed, 27 Nov 2013 11:16:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l2vpn-vpls-ldp-mac-opt-09.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131127191654.27764.87498.idtracker@ietfa.amsl.com> Date: Wed, 27 Nov 2013 11:16:54 -0800 Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Nov 2013 19:16:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Layer 2 Virtual Private Networks Working = Group of the IETF. Title : LDP Extensions for Optimized MAC Address Withdrawal in H= -VPLS Author(s) : Pranjal Kumar Dutta Florin Balus Olen Stokes Geraldine Calvinac Filename : draft-ietf-l2vpn-vpls-ldp-mac-opt-09.txt Pages : 22 Date : 2013-11-27 Abstract: RFC4762 describes a mechanism to remove or unlearn MAC addresses that have been dynamically learned in a VPLS Instance for faster convergence on topology change. The procedure also removes MAC addresses in the VPLS that do not require relearning due to such topology change. This document defines an enhancement to the MAC Address Withdrawal procedure with empty MAC List from RFC4762, which enables a Provider Edge(PE) device to remove only the MAC addresses that need to be relearned. Additional extensions to RFC4762 MAC Withdrawal procedures are specified to provide optimized MAC flushing for the PBB-VPLS specified in working group RFC7041. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-vpls-ldp-mac-opt There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-ldp-mac-opt-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-l2vpn-vpls-ldp-mac-opt-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/