From nobody Tue Apr 1 09:55:27 2014 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 482711A096B; Tue, 1 Apr 2014 07:07:35 -0700 (PDT) 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 7Qi419FaI4s5; Tue, 1 Apr 2014 07:07:32 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 6434E1A092A; Tue, 1 Apr 2014 07:07:30 -0700 (PDT) Received: from host4.velocix.com ([81.134.152.4] helo=xxx.corp.velocix.com) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1WUzLZ-0006fy-Vb; Tue, 01 Apr 2014 15:07:26 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1085) Subject: Fwd: RtgDir review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt From: Ben Niven-Jenkins Date: Tue, 1 Apr 2014 15:07:22 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: rtg-ads@tools.ietf.org X-Mailer: Apple Mail (2.1085) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/UWI59BfGH-XUDvEemzZQgeRL6ls X-Mailman-Approved-At: Tue, 01 Apr 2014 09:55:26 -0700 Cc: l2vpn@ietf.org, rtg-dir@ietf.org, draft-ietf-l2vpn-vpls-ldp-mac-opt.all@tools.ietf.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: Tue, 01 Apr 2014 14:07:35 -0000 Colleagues, I am resending my Routing Directorate review below as I messed up the = e-mail address for the draft's authors. Ben Begin forwarded message: > From: Ben Niven-Jenkins > Date: 1 April 2014 15:02:25 GMT+01:00 > To: rtg-ads@tools.ietf.org > Cc: rtg-dir@ietf.org, l2vpn@ietf.org, = draft-ietf-l2vpn-vpls-ldp-mac-opt-11.all@tools.ietf.org > Subject: RtgDir review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt >=20 > Hello, >=20 > I have been selected as the Routing Directorate reviewer for this = draft. The Routing Directorate seeks to review all routing or = routing-related drafts as they pass through IETF last call and IESG = review, and sometimes on special request. The purpose of the review is = to provide assistance to the Routing ADs. For more information about the = Routing Directorate, please see = http://www.ietf.org/iesg/directorate/routing.html >=20 > Although these comments are primarily for the use of the Routing ADs, = it would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. >=20 > Document: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt > Reviewer: Ben Niven-Jenkins > Review Date: 1st April 2014 > IETF LC End Date: 8th April 2014 > Intended Status: Standards Track >=20 > Summary: > I have significant concerns about this document and recommend that the = Routing ADs discuss these issues further with the authors. >=20 > Comments: > Overall the document is reasonably well written, although many = cross-references to different sections in the draft appear to be wrong. = Where I've noticed incorrect cross-references I have noted them in the = nits section below but I would recommend someone doing a complete pass = of the document to ensure all cross-references refer to the correct = section(s). >=20 > =46rom reading the document my opinion is that it suitably describes = what is required to implement the newly proposed mechanism but it may be = hard for someone to read the document and determine what circumstances = would motivate using the new optimised MAC flush versus sticking with = the original RFC4627 MAC flush mechanism.=20 >=20 >=20 > Major issues: >=20 > I've raised this as a major issue as I think it may require AD = input/attention to resolve. It is not a technical issue but a suggestion = for including more explanatory text that I think would help improve the = document but which the AD may decide is not required. >=20 > The document specifies a solution to solve a problem with the = mechanism for MAC address withdrawal specified in RFC4762 but it doesn't = provide any indication of when the new optimised MAC flush that is = proposed should be used instead of the existing MAC flush mechanism = specified in RFC4627. >=20 > The downside of the existing RFC4627 MAC flush mechanism appears to be = that PEs can end up having to flush many more MAC addresses than = absolutely required when a dual homed CE/MTU switches from using the = primary spoke PW to the backup spoke PW. >=20 > The optimised MAC flush specified in the document solves the problem = by moving the initiation of the MAC flush message from the 'backup' = PE-rs to the 'primary' PE-rs and introducing a new message to allow the = primary PE-rs to request other PE-rs in the network flush all MAC = addresses learnt via the primary PE-rs. >=20 > While the new message means that the PE-rs in the network will flush = and relearn fewer MAC addresses on failure of the primary spoke PW = between the MTU-s & primary PE-rs, it is not clear to me whether it is = superior in all cases. >=20 > For example, the new optimised MAC flush relies on the primary PE-rs = to detect the failure of the spoke PW and initiate the optimised MAC = flush but the document doesn't discuss what happens if the failure isn't = detected (e.g. if PE-rs doesn't detect the failure or PE-rs itself = fails). My assumption is that the network falls back to relying on = aging/timeout of MAC entries, which presumably means that traffic is = blackholed for up to 5 minutes (using default timers). >=20 > It is also not clear whether this mechanism is designed to replace the = mechanism in RFC4627 or to augment it, although I have assumed the = former. >=20 > I therefore think that the document would benefit significantly from: >=20 > a) Some clear text/statement of when the new optimised MAC flush = mechanism should be used instead of the existing RFC4627 mechanism (e.g. = when is a full RFC4627 MAC flush "bad"). >=20 > b) Some discussion describing how the new optimised MAC flush = mechanism is equivalent to the existing mechanism and highlighting any = cases where it may not provide as rapid MAC table updates as the RFC4627 = mechanisms. >=20 >=20 > Minor issues: >=20 > 1) The first paragraph of section 3 states: >=20 > When the MTU-s switches over to the backup PW, the requirement is to > flush the MAC addresses learned in the corresponding Virtual Switch > Instance (VSI) in peer PE devices participating in the full mesh, to > avoid black holing of frames to those addresses. This is > accomplished by sending an LDP Address Withdraw Message from the PE > that is no longer connected to the MTU-s with the primary PW, with > the list of MAC addresses to be removed to all other PEs over the > corresponding LDP sessions [RFC4762]. >=20 > Comparing this against Figure 1, my understanding is that the "PE that = is no longer connected to the MTU-s with the primary PW" is PE1-rs. = However section 3.1.1 states: >=20 > [RFC4762] specifies that on failure of the primary PW, it is the > PE3-rs (Figure 1) that initiates MAC flush towards the core. >=20 > Which contradicts the first paragraph of section 3? >=20 > I think that the first paragraph of section 3 is describing the = behaviour when using the new mechanism described in the draft, but that = wasn't clear to me when I first read the draft, so I would suggest = re-wording or adding some text to make it more explicit when you are = describing new behaviour specified in the document versus existing = behaviour inherited from RFC4762. >=20 > 2) Section 3.2. I'm not sure what the significance of the native = ethernet segment is in this sentence "For example, the case of PE1-rs = initiated MAC flush on failure may arise when the dual-homing segment is = native ethernet as opposed to spoke PWs.". You may want to consider = stating what issue it is that the presence of native ethernet causes. >=20 > 3) Section 3.2 goes on to say "In this case the PE-rs devices > that receive the MAC flush from PE1-rs are required to flush all the > MAC addresses learned over the PW connected to PE1-rs. This cannot > be achieved with the MAC Address Withdraw Message defined in > [RFC4762]." >=20 > You may want to consider stating why MAC flush cannot be achieved with = the MAC Address Withdraw Message defined in RFC4762 (as the lack of = ability for performing MAC flush in this scenario is presumably the = motivation for defining the new MAC flush on failure mechanism in the = document?). >=20 > 4) Section 5.1.2 states >=20 > The MAC withdraw procedures defined in [RFC4762], MTU-s or PE2-rs > SHOULD be sent in cases where the network is being upgraded and > devices are not capable of understanding the optimized MAC flush. > This would result in the same flushing action as [RFC4762] at the > receiving PE-rs devices. >=20 > Which I am struggling to parse. Do you mean something along these = lines? >=20 > The MAC withdraw procedures defined in [RFC4762], where either > MTU-s or PE2-rs send the MAC Withdrawl message SHOULD be used > in cases where the network is being upgraded and devices are not > capable of understanding the optimized MAC flush. > This would result in the same flushing action as [RFC4762] at the > receiving PE-rs devices. >=20 > 5) Section 5.1.2 states >=20 > For the case of B-VPLS devices optimized MAC flush message SHOULD be > supported. >=20 > It's not clear to me what the purpose of this sentence is or what it = adds to the document. >=20 > 6) Section 5.1.4 states >=20 > This section explains the optimized MAC flush procedure in the > scenario in Figure 2. When the primary spoke PW transition (failure > or standby transition) is detected by PE1-rs, it MAY send MAC flush > messages to PE2-rs, PE3-rs and PE4-rs with MAC Flush TLV and N =3D = 1. >=20 > Use of MAY here seems a bit strange to me. I may have misunderstood = but it seems to me that the document is proposing replacing the existing = MAC withdraw mechanisms with this new mechanism, but when using this new = mechanism sending the optimised MAC flush is only a MAY, so what happens = when PE1-rs doesn't send the optimised MAC flush? I assume the fallback = is aging/timeout of MAC entries, or is it that the previous MAC withdraw = mechanism is also being used? >=20 > You may want to consider re-phrasing it along the lines of "When = optimised MAC flush is being used then " >=20 >=20 > nits: > 1) Section 4 states: > This section describes the problems in detail with respective to > various MAC flush actions described in section 2. >=20 > Section 2 is the terminology section and doesn't describe any MAC = flush actions, do you mean to reference section 3? >=20 > Also I'm not exactly sure what a MAC flush action is. I think you may = mean: >=20 > This section describes the problems in detail with respect to the > various MAC flush scenarios described in section 3. >=20 > And I think you mean to use 'respect' rather than 'respective'. >=20 > 2) Section 4.1.1, penultimate paragraph says "In the example above, = only the MAC addresses in set X and Y need to be flushed across the = core." Y is not used in the text which confused me for a while until I = realised you were referring to Figure 2. You may want to consider making = that more explicit, for example: >=20 > In the example above, only the MAC addresses in set X and Y > (shown in Figure 2) need to be flushed across the core. >=20 > 3) Section 4.1.2 starts >=20 > The analysis in section 3.1.1 applies also to the native Ethernet > access into a VPLS. >=20 > I think you may mean to reference section 4.1.1, not 3.1.1? >=20 > 4) Section 5 states >=20 > This section describes the solution for the requirements described = in > section 4. >=20 > Section 4 doesn't seem to list any requirements as such. Maybe = consider rewording to something like: >=20 > This section describes a solution for the problem space described in > section 4. >=20 > 5) Section 5.1 states >=20 > The optimization is achieved by > initiating MAC Flush on failure as described in section 2.2. >=20 > and >=20 > The MAC Flush TLV can also > be used for [RFC4762] style of MAC Flush as explained in section 2. >=20 > I think you mean section 3.2 and section 3 respectively. >=20 > 6) Section 5.1.1 & 5.1.2 cross-reference section 4.2 for details of = its usage in PBB-VPLS but I think you mean to cross-reference section = 5.2. >=20 > 7) Section 5.1.2, 5.1.3 & 5.2.2 cross-references section 5 for = operational considerations but I think you mean to cross-reference = section 6. >=20 > Regards > Ben >=20 From nobody Tue Apr 1 19:57:46 2014 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 6583A1A00BB; Tue, 1 Apr 2014 19:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.51 X-Spam-Level: X-Spam-Status: No, score=-9.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 3nu0EZf8ycVM; Tue, 1 Apr 2014 19:57:40 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id A878C1A00BA; Tue, 1 Apr 2014 19:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3842; q=dns/txt; s=iport; t=1396407457; x=1397617057; h=from:to:subject:date:message-id:mime-version; bh=VHJu5v0zp2IkyLZ0szLVQryycztIHWyEOdXSNYSpCD0=; b=jgjFaNqywYtEQFUmDB+xp6pLrNfBci05D/YHytuOk4zTJGvSQscmcLHI YbZrPw65t6pPjA1OAk4yKjpV1zqiDGdido2hmv6BiVgeAhQvDAqx62ddg uWtVOW0EUCr1jmnCcSQr7icQTAA34dG2zGV/BJSaVVweV/InCNOGSJz/i w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkAFAEF8O1OtJA2B/2dsb2JhbABZgkJEO1fDZYEfFnSCJwEELV4BDB5WJgEEARoBh3AN0C4Xjj+DXIEUBKsPgzCCKw X-IronPort-AV: E=Sophos; i="4.97,777,1389744000"; d="scan'208,217"; a="32155100" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-3.cisco.com with ESMTP; 02 Apr 2014 02:57:36 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s322vZEl014567 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Apr 2014 02:57:36 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.10]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0123.003; Tue, 1 Apr 2014 21:57:35 -0500 From: "Tissa Senevirathne (tsenevir)" To: "mpls@ietf.org" , "l2vpn@ietf.org" , "netmod@ietf.org" Subject: YANG model for protocol independent OAM Thread-Topic: YANG model for protocol independent OAM Thread-Index: Ac9OH0mrYZK4jD9HSc+SWDem67dVww== Date: Wed, 2 Apr 2014 02:57:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.69.164] Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE193562AFA7836xmbrcdx08ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/gia-eKGE3mPn33kL3jwYt1cF3cA 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, 02 Apr 2014 02:57:42 -0000 --_000_FBEA3E19AA24F847BA3AE74E2FE193562AFA7836xmbrcdx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All In the draft below we present YANG model to abstract protocol dependent asp= ects of OAM and create a unified OAM API set. In a nutshell, ping is ping a= nd traceroute is traceroute and so on. Protocol independent API 's allow us= ers to exercise these OAM tools in the same manner across different technol= ogies and allow to integrate to their operations platforms. Appreciate your time on reviewing and providing comments, both on API's and= YANG model as well as OAM framework in it self. http://www.ietf.org/id/draft-tissa-netmod-oam-00.txt Thanks Tissa --_000_FBEA3E19AA24F847BA3AE74E2FE193562AFA7836xmbrcdx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All

 

In the draft below we present YANG model to abstract= protocol dependent aspects of OAM and create a unified OAM API set. In a n= utshell, ping is ping and traceroute is traceroute and so on. Protocol inde= pendent API ‘s allow users to exercise these OAM tools in the same manner across different technologies and allow= to integrate to their operations platforms.

 

Appreciate your time on reviewing and providing comm= ents, both on API’s and YANG model as well as OAM framework in it sel= f.

 

http://www.ietf.org/id/draft-tissa-netmod-oam-00.txt<= /o:p>

 

Thanks

Tissa

--_000_FBEA3E19AA24F847BA3AE74E2FE193562AFA7836xmbrcdx08ciscoc_-- From nobody Tue Apr 1 20:03:01 2014 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 520C11A00AA for ; Tue, 1 Apr 2014 20:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Td_5hg2FTY6l for ; Tue, 1 Apr 2014 20:02:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 313651A00CA for ; Tue, 1 Apr 2014 20:02:45 -0700 (PDT) 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 BFE09868; Wed, 02 Apr 2014 03:02:41 +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; Wed, 2 Apr 2014 04:01:57 +0100 Received: from SZXEMA406-HUB.china.huawei.com (10.82.72.38) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 2 Apr 2014 04:02:39 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.203]) by SZXEMA406-HUB.china.huawei.com ([10.82.72.38]) with mapi id 14.03.0158.001; Wed, 2 Apr 2014 11:02:32 +0800 From: "Xialiang (Frank)" To: Sam Aldrin Subject: RE: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Thread-Topic: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Thread-Index: Ac9CeLdIKfj9gmHqQoGb/BpQJYep2gKmytoAAA23woD//4PFgP/92tGQ Date: Wed, 2 Apr 2014 03:02:31 +0000 Message-ID: References: <8D1DD6FA-2758-4F4A-BD41-E22B59D6843E@gmail.com> In-Reply-To: <8D1DD6FA-2758-4F4A-BD41-E22B59D6843E@gmail.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.135.42.220] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F10F3E1D9CSZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/E8ZipA8qEmei6JGT8EnPEtjVqis Cc: "l2vpn@ietf.org" , "Ali Sajassi \(sajassi\)" 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, 02 Apr 2014 03:02:54 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F10F3E1D9CSZXEMA502MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sam, Please see my response inline: From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] Sent: Tuesday, April 01, 2014 10:12 AM To: Xialiang (Frank) Cc: Samer Salam (ssalam); Ali Sajassi (sajassi); jdrake@juniper.net; l2vpn@= ietf.org Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Frank, Comments inline. On Mar 31, 2014, at 7:00 PM, Xialiang (Frank) > wrote: Hi Samer, Please see inline: From: Samer Salam (ssalam) [mailto:ssalam@cisco.com] Sent: Tuesday, April 01, 2014 5:03 AM To: Xialiang (Frank); Ali Sajassi (sajassi); aldrin.ietf@gmail.com; jdrake@juniper.net Cc: l2vpn@ietf.org Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Hi Frank, Thanks for your comments. Please find responses below: 1. In this draft, we cite RFC 6136 as reference, and hence we do not repeat= the definition of common OAM terms (MEP, MIP, Maintenance Domain, In-band = OAM, OAM layering etc.). Regarding Discovery, please note that E-VPN has au= tomatic discovery built-in via the Inclusive Multicast Route and the Ethern= et A-D Route. Hence, no further mechanisms are required. 2. Per user flow means a traffic stream that maps to actual user data, with= a specified N-tuple characteristics (MAC DA/SA, VLAN, IP DA/SA, Src/Dest P= ort...). The reason why this is different between Network & Service OAM is= because the Service OAM mechanisms may or may not be able to support per-f= low OAM, depending on the service layer and its associated OAM capabilitie= s. For instance, in the case where Ethernet CFM (IEEE 802.1ag) is the servi= ce OAM, it is not possible to perform per-flow continuity check, as the des= tination MAC address is set by the protocol to a multicast address. 3. Yes, a representative path maps to a test flow. This is a simple functio= n, and is actually a degenerate case of the per user-flow OAM, because test= fields are specified for the N-Tuple. That's why it is mandatory. As to th= e details of the mechanism, that is left to the solution draft - after all,= this is the requirements and framework draft, it does not cover the soluti= on details for implementation. [Frank] : From my personal view, I don't think the paragraph describing the= requirement of a representative path is clear enough. For example, why can= it be used for node failure detection but not path failure detection? Whether one uses for node or path failure detection is for the solution to = decide. This is requirements draft. If you think better wording is required= , please do propose, will consider that. [Frank] : I agree with the principle of requirement draft. Actually, What I= suggest is better wording for better understanding the goal of representat= ive path check. 4. Test packets can be either unicast or multicast. The problem we are desc= ribing here is that relying on normal packet counters in unreliable given t= hat E-VPN offers many-to-many connectivity. For e.g., consider 3 endpoints = A, B and C. Let's say we are interested in measuring the loss between A and= C. A sends a packet to C, but it gets dropped. Now B also sends to C and t= hat packet is delivered. If we were to examine the packet counter on C, we = will find that the counter shows 1 packet received. But that doesn't mean t= hat we have 100% packet delivery rate between A and C. The packet actually = came from another source and hence the packet counter on C is ambiguous. Un= less the implementation keeps packet counters per-flow (which will be expen= sive and impractical), it is not reliable to use packet counters to measure= loss in a technology that supports multipoint-to-multipoint connectivity. [Frank] : Yes. This clarification is more clear than the current content of= draft~~ Also, I think "a statistical means of approximating packet loss ra= te" you proposed in draft is not the suitable solution for this problem. Ac= tually, this is more an implementation issue, i.e., we can set the same val= ue of flow characteristics for a test flow to ensure all test flow packets = send/receive between 2 nodes exactly. Again, this is requirement draft only. What you are eluding to is how one s= hould perform, which clearly falls in solution category. As Samer clarified= earlier, using actual data packet counters doesn't meet the requirements, = hence 'synthetic' measurement is required. [Frank] : OK -sam Regards, Samer From: "Xialiang (Frank)" > Date: Tuesday, 18 March, 2014 12:07 AM To: Samer Salam >, "Ali Sajassi (= sajassi)" >, "aldrin.ietf@gmail= .com" >, "jdrake@juniper.net" > Cc: "l2vpn@ietf.org" > Subject: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Hi authors, I have reviewed this important draft, and have some comments as below: 1. By comparing with RFC6136 (L2VPN OAM req and frm), from the integrity po= int of view, I think there are some part missing: EVPN MEP and MIP, Discove= ry, Data Path Forwarding, Scalability, Transport/Application Independence; 2. In section 3.1.1.1, what is the definition of per user flow? Why is it d= ifferent to support it between E-VPN Network OAM and E-VPN Service OAM? 3. In section 3.1.1.1, does the section of "a representative path" mean usi= ng test flow to detect the node failure? if yes, how to do? Is it a necessa= ry requirement of proactive fault detection? 4. In section 3.2.1, I do not quite understand the describing reason for th= e inaccuracy of Loss Measurement. Do you mean that test packets of Loss Mea= surement are all BUM packets? Can you clarify why peer MEPs will receive so= me unnecessary packets? Why not use unicast packets for Loss Measurement? Hoping for your feedback~~ B.R. Frank --_000_C02846B1344F344EB4FAA6FA7AF481F10F3E1D9CSZXEMA502MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sam,<= /o:p>

Please see= my response inline:

 = ;

From: Sam Aldrin [mailto:aldrin.ietf@gmail.com]
Sent: Tuesday, April 01, 2014 10:12 AM
To: Xialiang (Frank)
Cc: Samer Salam (ssalam); Ali Sajassi (sajassi); jdrake@juniper.net;= l2vpn@ietf.org
Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-= 02":

 

Frank,

 

Comments inline.

On Mar 31, 2014, at 7:00 PM, Xi= aliang (Frank) <frank.xiali= ang@huawei.com> wrote:



Hi Samer,

Please see inline:

 

From: Samer Salam (ssalam) [mailto:ssalam@cisco.com] 
Sent: Tuesday, Apr= il 01, 2014 5:03 AM
To: Xialiang (Fran= k); Ali Sajassi (sajassi); ald= rin.ietf@gmail.com; <= /span>jd= rake@juniper.net
Cc: l2vpn@ietf.org<= br> Subject: Re: comme= nts on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

 =

Hi Frank,

 

Thanks for your comments. Please find res= ponses below:

 

1. In this draft, we cite RFC 6136 as ref= erence, and hence we do not repeat the definition of common OAM terms (MEP, MIP, Maintenance Domain, In-band OAM, OAM layering etc.). = Regarding Discovery, please note that E-VPN has automatic discovery built-i= n via the Inclusive Multicast Route and the Ethernet A-D Route. Hence, no f= urther mechanisms are required.

 

2. Per user flow means a traffic stream t= hat maps to actual user data, with a specified N-tuple characteristics (MAC DA/SA, VLAN, IP DA/SA, Src/Dest Port…).  The reason why th= is is different between Network & Service OAM is because the Service OA= M mechanisms may or may not be able to support per-flow OAM, depending on t= he  service layer and its associated OAM capabilities. For instance, in the case where Ethernet CFM (IEEE 802.1ag) is the service= OAM, it is not possible to perform per-flow continuity check, as the desti= nation MAC address is set by the protocol to a multicast address.

 

3. Yes, a representative path maps to a t= est flow. This is a simple function, and is actually a degenerate case of the per user-flow OAM, because test fields are specified for the N= -Tuple. That's why it is mandatory. As to the details of the mechanism, tha= t is left to the solution draft – after all, this is the requirements= and framework draft, it does not cover the solution details for implementation.

[Frank] : From my per= sonal view, I don’t think the paragraph describing the requirement of a representative path is clear enough. For example, why can it be used = for node failure detection but not path failure detection?

Whether one uses for node or pa= th failure detection is for the solution to decide. This is requirements dr= aft. If you think better wording is required, please do propose, will consi= der that.

[Fra= nk] : I agree with the principle of requirement draft. Actually, What I sug= gest is better wording for better understanding the goal of representative path check.



 

4. Test packets can be either unicast or = multicast. The problem we are describing here is that relying on normal packet counters in unreliable given that E-VPN offers many-to-ma= ny connectivity. For e.g., consider 3 endpoints A, B and C. Let's say we ar= e interested in measuring the loss between A and C. A sends a packet to C, = but it gets dropped. Now B also sends to C and that packet is delivered. If we were to examine the packet = counter on C, we will find that the counter shows 1 packet received. But th= at doesn't mean that we have 100% packet delivery rate between A and C. The= packet actually came from another source and hence the packet counter on C is ambiguous. Unless the implemen= tation keeps packet counters per-flow (which will be expensive and impracti= cal), it is not reliable to use packet counters to measure loss in a techno= logy that supports multipoint-to-multipoint connectivity.

[Frank] : Yes. This c= larification is more clear than the current content of draft~~ Also, I think “a statistical means of approximating packet loss rate= ” you proposed in draft is not the suitable solution for this problem= . Actually, this is more an implementation issue, i.e., we can set the same= value of flow characteristics for a test flow to ensure all test flow packets send/receive between 2 nodes exactly.

Again, this is requirement draf= t only. What you are eluding to is how one should perform, which clearly fa= lls in solution category. As Samer clarified earlier, using actual data pac= ket counters doesn’t meet the requirements, hence ‘synthetic' measurement is required. 

[Fra= nk] : OK

 

-sam

 

Regards,

Samer

 

From: "Xialiang (Frank)" <frank.xialiang@huawei.com>
Date: Tuesday, 18 = March, 2014 12:07 AM
To: Samer Salam &l= t;ssalam@c= isco.com>, "Ali Sajassi (sajassi)" <sajassi@cisco.com>, "aldrin.ietf@gmail.com" <aldrin.ietf@gmail.com>= ;, "jdrake@juniper.net" <jdr= ake@juniper.net>
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: comments = on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

 

Hi authors,

I have reviewed this important draft, and= have some comments as below:

1. By comparing with RFC6136 (L2VPN OAM r= eq and frm), from the integrity point of view, I think there are some part missing: EVPN MEP and MIP, Discovery, Data Path Forwarding, = Scalability, Transport/Application Independence;

2. In section 3.1.1.1, what is the defini= tion of per user flow? Why is it different to support it between E-VPN Network OAM and E-VPN Service OAM?

3. In section 3.1.1.1, does the section o= f "a representative path" mean using test flow to detect the node failure? if yes, how to do? Is it a necessary requirement of proactiv= e fault detection?

4. In section 3.2.1, I do not quite under= stand the describing reason for the inaccuracy of Loss Measurement. Do you mean that test packets of Loss Measurement are all BUM packets? Can= you clarify why peer MEPs will receive some unnecessary packets? Why not u= se unicast packets for Loss Measurement?

 

Hoping for your feedback~~

 

B.R.

Frank

 

--_000_C02846B1344F344EB4FAA6FA7AF481F10F3E1D9CSZXEMA502MBSchi_-- From nobody Tue Apr 1 20:20:38 2014 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 C855F1A00D5 for ; Tue, 1 Apr 2014 20:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 S7S2ehyiqmeF for ; Tue, 1 Apr 2014 20:20:28 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0DA1A00B6 for ; Tue, 1 Apr 2014 20:20:28 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id lf10so10781797pab.41 for ; Tue, 01 Apr 2014 20:20:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=cQgoAHHQCned5G0ytKl3fHcijggxpkyO2bq4FRULfjk=; b=q67JpFOurIlr2cjEsd4oAvFrxuxPDqI4pxDUw1LeGPTx55VxvJzKVfFOrxgfKWg0kt PdTiYr+w6+LyrGJLS2ns0INz5YPaaKGk66jL5XvpZIRRDqLQFgICIqfgd7LoioE8VCAJ h/RqwPdPEVgPEvO1WDdawAu/6U8VdviU8xgDnG+ICnutpFDO3t5bjZQIEuSYmSmFYtAO wOfwMHkgnBVPBP9yjl/CTnxmrzr22b813QDSBDGNhiTdgeMJSEzAHy8NV1wEUUMp9XRz Gg0nF5Ch36lkh8hJL78M+LscbSB9htzOuom4vjuqucfWjwrGyqsHHC8wwqjBh3/H5mkl XnhQ== X-Received: by 10.68.197.8 with SMTP id iq8mr17379496pbc.124.1396408824957; Tue, 01 Apr 2014 20:20:24 -0700 (PDT) Received: from [192.168.1.9] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id vo1sm2730508pab.32.2014.04.01.20.20.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Apr 2014 20:20:24 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_43B0EF78-7B56-4132-A75E-AB0F880DA5DB" Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": From: Sam Aldrin In-Reply-To: Date: Tue, 1 Apr 2014 20:20:25 -0700 Message-Id: References: <8D1DD6FA-2758-4F4A-BD41-E22B59D6843E@gmail.com> To: "Xialiang (Frank)" X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/-oqFVCDa7NW6xE6hSEKlVxODtxs Cc: "l2vpn@ietf.org" , "Ali Sajassi \(sajassi\)" 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, 02 Apr 2014 03:20:32 -0000 --Apple-Mail=_43B0EF78-7B56-4132-A75E-AB0F880DA5DB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Inline with %sam. On Apr 1, 2014, at 8:02 PM, Xialiang (Frank) = wrote: > Sam, > Please see my response inline: > =20 > From: Sam Aldrin [mailto:aldrin.ietf@gmail.com]=20 > Sent: Tuesday, April 01, 2014 10:12 AM > To: Xialiang (Frank) > Cc: Samer Salam (ssalam); Ali Sajassi (sajassi); jdrake@juniper.net; = l2vpn@ietf.org > Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": > =20 > Frank, > =20 > Comments inline. > On Mar 31, 2014, at 7:00 PM, Xialiang (Frank) = wrote: >=20 >=20 > Hi Samer, > Please see inline: > =20 > From: Samer Salam (ssalam) [mailto:ssalam@cisco.com]=20 > Sent: Tuesday, April 01, 2014 5:03 AM > To: Xialiang (Frank); Ali Sajassi (sajassi); aldrin.ietf@gmail.com; = jdrake@juniper.net > Cc: l2vpn@ietf.org > Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": > =20 > Hi Frank, > =20 > Thanks for your comments. Please find responses below: > =20 > 1. In this draft, we cite RFC 6136 as reference, and hence we do not = repeat the definition of common OAM terms (MEP, MIP, Maintenance Domain, = In-band OAM, OAM layering etc.). Regarding Discovery, please note that = E-VPN has automatic discovery built-in via the Inclusive Multicast Route = and the Ethernet A-D Route. Hence, no further mechanisms are required. > =20 > 2. Per user flow means a traffic stream that maps to actual user data, = with a specified N-tuple characteristics (MAC DA/SA, VLAN, IP DA/SA, = Src/Dest Port=85). The reason why this is different between Network & = Service OAM is because the Service OAM mechanisms may or may not be able = to support per-flow OAM, depending on the service layer and its = associated OAM capabilities. For instance, in the case where Ethernet = CFM (IEEE 802.1ag) is the service OAM, it is not possible to perform = per-flow continuity check, as the destination MAC address is set by the = protocol to a multicast address. > =20 > 3. Yes, a representative path maps to a test flow. This is a simple = function, and is actually a degenerate case of the per user-flow OAM, = because test fields are specified for the N-Tuple. That's why it is = mandatory. As to the details of the mechanism, that is left to the = solution draft =96 after all, this is the requirements and framework = draft, it does not cover the solution details for implementation. > [Frank] : =46rom my personal view, I don=92t think the paragraph = describing the requirement of a representative path is clear enough. For = example, why can it be used for node failure detection but not path = failure detection? > Whether one uses for node or path failure detection is for the = solution to decide. This is requirements draft. If you think better = wording is required, please do propose, will consider that. > [Frank] : I agree with the principle of requirement draft. Actually, = What I suggest is better wording for better understanding the goal of = representative path check. %sam - When continuity to a MEP is lost, one could conclude there is a = node failure, but IMO, one cannot conclude path has failed as there = could be a different load balanced path exist. That is the reason we = used the term =91conclusively=92. If one=92s implementation could = determine it is indeed path failure, so be it. But from requirement = point of view, we do not want to enforce node failure =3D path failure. = Which translates to, solution and implementations could innovate to = conclusively determine path failure. Hope this is clear.=20 cheers -sam >=20 >=20 > =20 > 4. Test packets can be either unicast or multicast. The problem we are = describing here is that relying on normal packet counters in unreliable = given that E-VPN offers many-to-many connectivity. For e.g., consider 3 = endpoints A, B and C. Let's say we are interested in measuring the loss = between A and C. A sends a packet to C, but it gets dropped. Now B also = sends to C and that packet is delivered. If we were to examine the = packet counter on C, we will find that the counter shows 1 packet = received. But that doesn't mean that we have 100% packet delivery rate = between A and C. The packet actually came from another source and hence = the packet counter on C is ambiguous. Unless the implementation keeps = packet counters per-flow (which will be expensive and impractical), it = is not reliable to use packet counters to measure loss in a technology = that supports multipoint-to-multipoint connectivity. > [Frank] : Yes. This clarification is more clear than the current = content of draft~~ Also, I think =93a statistical means of approximating = packet loss rate=94 you proposed in draft is not the suitable solution = for this problem. Actually, this is more an implementation issue, i.e., = we can set the same value of flow characteristics for a test flow to = ensure all test flow packets send/receive between 2 nodes exactly. > Again, this is requirement draft only. What you are eluding to is how = one should perform, which clearly falls in solution category. As Samer = clarified earlier, using actual data packet counters doesn=92t meet the = requirements, hence =91synthetic' measurement is required.=20 > [Frank] : OK > =20 > -sam >=20 > =20 > Regards, > Samer > =20 > From: "Xialiang (Frank)" > Date: Tuesday, 18 March, 2014 12:07 AM > To: Samer Salam , "Ali Sajassi (sajassi)" = , "aldrin.ietf@gmail.com" , = "jdrake@juniper.net" > Cc: "l2vpn@ietf.org" > Subject: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": > =20 > Hi authors, > I have reviewed this important draft, and have some comments as below: > 1. By comparing with RFC6136 (L2VPN OAM req and frm), from the = integrity point of view, I think there are some part missing: EVPN MEP = and MIP, Discovery, Data Path Forwarding, Scalability, = Transport/Application Independence; > 2. In section 3.1.1.1, what is the definition of per user flow? Why is = it different to support it between E-VPN Network OAM and E-VPN Service = OAM? > 3. In section 3.1.1.1, does the section of "a representative path" = mean using test flow to detect the node failure? if yes, how to do? Is = it a necessary requirement of proactive fault detection? > 4. In section 3.2.1, I do not quite understand the describing reason = for the inaccuracy of Loss Measurement. Do you mean that test packets of = Loss Measurement are all BUM packets? Can you clarify why peer MEPs will = receive some unnecessary packets? Why not use unicast packets for Loss = Measurement? > =20 > Hoping for your feedback~~ > =20 > B.R. > Frank > =20 --Apple-Mail=_43B0EF78-7B56-4132-A75E-AB0F880DA5DB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Inline = with %sam.

On Apr 1, 2014, at 8:02 PM, Xialiang = (Frank) <frank.xialiang@huawei.com>= ; wrote:

Sam,
Please see = my response inline:
 
From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] 
Sent: Tuesday, April 01, 2014 = 10:12 AM
To: Xialiang = (Frank)
Cc: Samer Salam (ssalam); Ali = Sajassi (sajassi); jdrake@juniper.net; l2vpn@ietf.org
Subject: Re: comments on = "draft-salam-l2vpn-evpn-oam-req-frmwk-02":
 
Frank,
 
Comments = inline.
On Mar 31, 2014, at 7:00 PM, Xialiang (Frank) <frank.xialiang@huawei.com> = wrote:


Hi = Samer,
Please see inline:
 
From: Samer Salam (ssalam) [mailto:ssalam@cisco.com] 
Sent: Tuesday, April 01, 2014 = 5:03 AM
To: Xialiang (Frank); Ali = Sajassi (sajassi); aldrin.ietf@gmail.com; jdrake@juniper.net
Cc: l2vpn@ietf.org
Subject: Re: comments on = "draft-salam-l2vpn-evpn-oam-req-frmwk-02":
 
Hi = Frank,
 
Thanks = for your comments. Please find responses = below:
 
1. In = this draft, we cite RFC 6136 as reference, and hence we do not repeat = the definition of common OAM terms (MEP, MIP, Maintenance Domain, = In-band OAM, OAM layering etc.). Regarding Discovery, please note that = E-VPN has automatic discovery built-in via the Inclusive Multicast Route = and the Ethernet A-D Route. Hence, no further mechanisms are = required.
 
2. Per = user flow means a traffic stream that maps to actual user data, with a = specified N-tuple characteristics (MAC DA/SA, VLAN, IP DA/SA, Src/Dest = Port=85).  The reason why this is different between Network & = Service OAM is because the Service OAM mechanisms may or may not be able = to support per-flow OAM, depending on the  service layer and its = associated OAM capabilities. For instance, in the case where Ethernet = CFM (IEEE 802.1ag) is the service OAM, it is not possible to perform = per-flow continuity check, as the destination MAC address is set by the = protocol to a multicast address.
 
3. Yes, a = representative path maps to a test flow. This is a simple function, and = is actually a degenerate case of the per user-flow OAM, because test = fields are specified for the N-Tuple. That's why it is mandatory. As to = the details of the mechanism, that is left to the solution draft =96 = after all, this is the requirements and framework draft, it does not = cover the solution details for = implementation.
[Frank] : =46rom my personal view, I don=92t think the paragraph = describing the requirement of a representative path is clear enough. For = example, why can it be used for node failure detection but not path = failure detection?
Whether one uses for node or = path failure detection is for the solution to decide. This is = requirements draft. If you think better wording is required, please do = propose, will consider that.
[Frank] : I = agree with the principle of requirement draft. Actually, What I suggest = is better wording for better understanding the goal of representative = path = check.
%sam= - When continuity to a MEP is lost, one could conclude there is a node = failure, but IMO, one cannot conclude path has failed as there could be = a different load balanced path exist. That is the reason we used the = term =91conclusively=92. If one=92s implementation could determine it is = indeed path failure, so be it. But from requirement point of view, we do = not want to enforce node failure =3D path failure. Which translates to, = solution and implementations could innovate to conclusively determine = path failure.

Hope this is = clear. 

cheers
-sam



 
4. Test = packets can be either unicast or multicast. The problem we are = describing here is that relying on normal packet counters in unreliable = given that E-VPN offers many-to-many connectivity. For e.g., consider 3 = endpoints A, B and C. Let's say we are interested in measuring the loss = between A and C. A sends a packet to C, but it gets dropped. Now B also = sends to C and that packet is delivered. If we were to examine the = packet counter on C, we will find that the counter shows 1 packet = received. But that doesn't mean that we have 100% packet delivery rate = between A and C. The packet actually came from another source and hence = the packet counter on C is ambiguous. Unless the implementation keeps = packet counters per-flow (which will be expensive and impractical), it = is not reliable to use packet counters to measure loss in a technology = that supports multipoint-to-multipoint = connectivity.
[Frank] : Yes. This clarification is more clear than the current = content of draft~~ Also, I think =93a statistical means of approximating = packet loss rate=94 you proposed in draft is not the suitable solution = for this problem. Actually, this is more an implementation issue, i.e., = we can set the same value of flow characteristics for a test flow to = ensure all test flow packets send/receive between 2 nodes = exactly.
Again, this is requirement = draft only. What you are eluding to is how one should perform, which = clearly falls in solution category. As Samer clarified earlier, using = actual data packet counters doesn=92t meet the requirements, hence = =91synthetic' measurement is required. 
[Frank] : = OK
 
-sam

 
Regards,
Samer
 
From: "Xialiang (Frank)" <frank.xialiang@huawei.com>
Date: Tuesday, 18 March, 2014 = 12:07 AM
To: Samer Salam <ssalam@cisco.com>, "Ali Sajassi (sajassi)" <sajassi@cisco.com>, "aldrin.ietf@gmail.com" <aldrin.ietf@gmail.com>, "jdrake@juniper.net" <jdrake@juniper.net>
Cc: "l2vpn@ietf.org" = <l2vpn@ietf.org>
Subject: comments on = "draft-salam-l2vpn-evpn-oam-req-frmwk-02":
 
Hi = authors,
I have reviewed this important draft, and have = some comments as below:
1. By comparing with RFC6136 (L2VPN = OAM req and frm), from the integrity point of view, I think there are = some part missing: EVPN MEP and MIP, Discovery, Data Path Forwarding, = Scalability, Transport/Application = Independence;
2. In section 3.1.1.1, what is the = definition of per user flow? Why is it different to support it between = E-VPN Network OAM and E-VPN Service OAM?
3. In = section 3.1.1.1, does the section of "a representative path" mean using = test flow to detect the node failure? if yes, how to do? Is it a = necessary requirement of proactive fault = detection?
4. In section 3.2.1, I do not quite = understand the describing reason for the inaccuracy of Loss Measurement. = Do you mean that test packets of Loss Measurement are all BUM packets? = Can you clarify why peer MEPs will receive some unnecessary packets? Why = not use unicast packets for Loss = Measurement?
 
Hoping = for your feedback~~
 
B.R.
Frank
 

= --Apple-Mail=_43B0EF78-7B56-4132-A75E-AB0F880DA5DB-- From nobody Tue Apr 1 20:51:21 2014 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 957741A00EA; Tue, 1 Apr 2014 20:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.74 X-Spam-Level: * X-Spam-Status: No, score=1.74 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 eqQPveb-UFwr; Tue, 1 Apr 2014 20:51:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EE6E11A00E1; Tue, 1 Apr 2014 20:51:12 -0700 (PDT) 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 BCQ67856; Wed, 02 Apr 2014 03:51:08 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 2 Apr 2014 04:50:14 +0100 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; Wed, 2 Apr 2014 04:51:07 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Wed, 2 Apr 2014 11:51:05 +0800 From: Haoweiguo To: "Tissa Senevirathne (tsenevir)" , "mpls@ietf.org" , "l2vpn@ietf.org" , "netmod@ietf.org" Subject: =?gb2312?B?tPC4tDogWUFORyBtb2RlbCBmb3IgcHJvdG9jb2wgaW5kZXBlbmRlbnQgT0FN?= Thread-Topic: YANG model for protocol independent OAM Thread-Index: Ac9OH0mrYZK4jD9HSc+SWDem67dVwwABSb29 Date: Wed, 2 Apr 2014 03:51:04 +0000 Message-ID: References: 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.135.22.248] Content-Type: multipart/alternative; boundary="_000_DD5FC8DE455C3348B94340C0AB5517334F7BBA41nkgeml501mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/Dl8TblIQCL_LeIn7AuIVCFFugu4 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, 02 Apr 2014 03:51:15 -0000 --_000_DD5FC8DE455C3348B94340C0AB5517334F7BBA41nkgeml501mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgVGlzc2EsDQoNClRoYW5rcyBmb3IgeW91ciBwcmVzZW50aW5nIHRoZSBkZXRhaWwgWWFuZyBt b2RlbCBvZiBUUklMTCBPQU0uIEFmdGVyIHJlYWQgdGhlIGRyYWZ0LCBpIGhhdmUgc29tZSBjb21t ZW50cyBhbmQgcHJvYmxlbXMgYXMgZm9sbG93cy4NCg0KDQoNCjEuIFRoZXJlIGlzIG5vIE1JUCBk YXRhIG1vZGVsIGluIHRoaXMgZHJhZnQsIGluIFRSSUxMIE9BTSBGcmFtZXdvcmsgTUlQIGlzIGRl ZmluaXRlbHkgZGVmaW5lZCB0byBmaWx0ZXIgT0FNIHBhY2tldCBiYXNlZCBvbiBNSVAgbGV2ZWwu DQoNCjIuIFRoZSByYW5nZSBvZiBNRVAgSUQgaXMgZnJvbSAxIHRvIDgxOTEuIEluIFRSSUxMIE9B TSBmcmFtZXdvcmssIHRyaWxsIGJhc2UgbW9kZSBpcyBkZWZpbmVkIHRvIGdlbmVyYXRlIE1ELCBN QSwgYW5kIE1FUCBhdXRvbWF0aWNhbGx5LCBNRVAgSUQgY2FuIHVzZSBSQidzIG5pY2tuYW1lIGFu ZCB3aWxsIGJlIGJleW9uZCA4MTkxLCBob3cgY2FuIGl0IGJlIG1hbmFnZWQgdGhyb3VnaCBZYW5n IG1vZGVsPw0KDQozLiBJbiB0cmlsbCBiYXNlIG1vZGUsIHRoZSBkZWZhdWx0IG5hbWUgZm9yIE1E IGlzICJUcmlsbEJhc2VNb2RlIiwgdGhlIGRlZmF1bHQgbmFtZSBmb3IgTUEgaXMgIkZGRkMiLiBJ ZiB0aGV5IGFyZSBjb25mbGljdGVkIHdpdGggdGhlIGNvbmZpZ3VyYXRpb24gZGF0YSwgaG93IGNh biB3ZSBzb2x2ZSB0aGlzIGlzc3VlPw0KDQpUaGFua3MNCg0Kd2VpZ3VvDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IG1wbHMgW21wbHMtYm91bmNlc0BpZXRmLm9y Z10gtPqx7SBUaXNzYSBTZW5ldmlyYXRobmUgKHRzZW5ldmlyKSBbdHNlbmV2aXJAY2lzY28uY29t XQ0Kt6LLzcqxvOQ6IDIwMTTE6jTUwjLI1SAxMDo1Nw0KytW8/sjLOiBtcGxzQGlldGYub3JnOyBs MnZwbkBpZXRmLm9yZzsgbmV0bW9kQGlldGYub3JnDQrW98ziOiBbbXBsc10gWUFORyBtb2RlbCBm b3IgcHJvdG9jb2wgaW5kZXBlbmRlbnQgT0FNDQoNCkFsbA0KDQpJbiB0aGUgZHJhZnQgYmVsb3cg d2UgcHJlc2VudCBZQU5HIG1vZGVsIHRvIGFic3RyYWN0IHByb3RvY29sIGRlcGVuZGVudCBhc3Bl Y3RzIG9mIE9BTSBhbmQgY3JlYXRlIGEgdW5pZmllZCBPQU0gQVBJIHNldC4gSW4gYSBudXRzaGVs bCwgcGluZyBpcyBwaW5nIGFuZCB0cmFjZXJvdXRlIGlzIHRyYWNlcm91dGUgYW5kIHNvIG9uLiBQ cm90b2NvbCBpbmRlcGVuZGVudCBBUEkgoa5zIGFsbG93IHVzZXJzIHRvIGV4ZXJjaXNlIHRoZXNl IE9BTSB0b29scyBpbiB0aGUgc2FtZSBtYW5uZXIgYWNyb3NzIGRpZmZlcmVudCB0ZWNobm9sb2dp ZXMgYW5kIGFsbG93IHRvIGludGVncmF0ZSB0byB0aGVpciBvcGVyYXRpb25zIHBsYXRmb3Jtcy4N Cg0KQXBwcmVjaWF0ZSB5b3VyIHRpbWUgb24gcmV2aWV3aW5nIGFuZCBwcm92aWRpbmcgY29tbWVu dHMsIGJvdGggb24gQVBJoa9zIGFuZCBZQU5HIG1vZGVsIGFzIHdlbGwgYXMgT0FNIGZyYW1ld29y ayBpbiBpdCBzZWxmLg0KDQpodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXRpc3NhLW5ldG1v ZC1vYW0tMDAudHh0DQoNClRoYW5rcw0KVGlzc2ENCg== --_000_DD5FC8DE455C3348B94340C0AB5517334F7BBA41nkgeml501mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Tissa,

Thanks for your presenting the detail Yang model of TRILL OAM. Afte= r read the draft, i have some comments and problems as follows.

 

1. There is no MIP data model in this draft, in TRILL OAM Framework MIP = is definitely defined to filter OAM packet based on MIP level.


2. The range of MEP ID is from 1 to 8191. In TRILL OAM framework, trill bas= e mode is defined to generate MD, MA, and MEP automatically, MEP ID can use= RB's nickname and will be beyond 8191, how can it be managed through Yang = model?


3. In trill base mode, the default name for MD is "TrillBaseMode"= , the default name for MA is "FFFC". If they are conflicted with = the configuration data, how can we solve this issue?


Thanks

weiguo

=B7=A2=BC=FE=C8=CB: mpls [mpls-bounces@iet= f.org] =B4=FA=B1=ED Tissa Senevirathne (tsenevir) [tsenevir@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA4=D4=C22=C8=D5 10:57
=CA=D5=BC=FE=C8=CB: mpls@ietf.org; l2vpn@ietf.org; netmod@ietf.org =D6=F7=CC=E2: [mpls] YANG model for protocol independent OAM

All

 

In the draft below we present YANG model to abstract= protocol dependent aspects of OAM and create a unified OAM API set. In a n= utshell, ping is ping and traceroute is traceroute and so on. Protocol inde= pendent API =A1=AEs allow users to exercise these OAM tools in the same manner across different technologies and allow= to integrate to their operations platforms.

 

Appreciate your time on reviewing and providing comm= ents, both on API=A1=AFs and YANG model as well as OAM framework in it self= .

 

http://www.ietf.org/id/draft-tissa-netmod-oa= m-00.txt

 

Thanks

Tissa

--_000_DD5FC8DE455C3348B94340C0AB5517334F7BBA41nkgeml501mbschi_-- From nobody Tue Apr 1 21:17:35 2014 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 EB4721A0108; Tue, 1 Apr 2014 21:17:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.06 X-Spam-Level: X-Spam-Status: No, score=-7.06 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, MIME_CHARSET_FARAWAY=2.45, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 TQTLPmWj_tqA; Tue, 1 Apr 2014 21:17:30 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4AC1A00F3; Tue, 1 Apr 2014 21:17:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17087; q=dns/txt; s=iport; t=1396412246; x=1397621846; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xWXJ7RvcF0N3JMtcWXFj31UtU/LN9QjMGl4pWG63fy8=; b=P97sM57NGxIYnJmU1RzFTF2nha0zuWthVdl/PbB04rsVmgIw9UEoijvI VA00S6HJ5Irhj1wyBgmSq37Ot1IG4nprqdypixOJbGL7V+C7HXmwtpEiV ig0f5qyY7CRhGUOCVzbnuJlotAiBduwzF/RlPDpS0/UEC5AONGs1rRXOG Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkkFAB6DO1OtJA2J/2dsb2JhbABZgkJEO1eDCsBbGYEGFnSCJQEBAQQtTBACAQYCEQQBAQsdBQICMBQJCAEBBAENBQgBh3ANkUScEgiiPxeOPxYbBgGCazmBFASrD4Mwgis X-IronPort-AV: E=Sophos; i="4.97,777,1389744000"; d="scan'208,217"; a="32171676" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-5.cisco.com with ESMTP; 02 Apr 2014 04:17:26 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s324HPlb032517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Apr 2014 04:17:25 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.10]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Tue, 1 Apr 2014 23:17:24 -0500 From: "Tissa Senevirathne (tsenevir)" To: Haoweiguo , "mpls@ietf.org" , "l2vpn@ietf.org" , "netmod@ietf.org" Subject: RE: YANG model for protocol independent OAM Thread-Topic: YANG model for protocol independent OAM Thread-Index: Ac9OH0mrYZK4jD9HSc+SWDem67dVwwABSb29AAESopA= Date: Wed, 2 Apr 2014 04:17:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.69.164] Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE193562AFA789Exmbrcdx08ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/IjHLiuWmafMCPpqvOOj-pSJYa-g Cc: "trill@ietf.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: Wed, 02 Apr 2014 04:17:33 -0000 --_000_FBEA3E19AA24F847BA3AE74E2FE193562AFA789Exmbrcdx08ciscoc_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgV2VpZ3VvDQoNClRoYW5rcyBmb3Igc29tZSB2ZXJ5IGdvb2Qgc2V0IG9mIHF1ZXN0aW9ucywg cGxlYXNlIHNlZSB0aGUgYW5zd2VycyBiZWxvdyBpbi1saW5lIHdpdGggW2Fuc3dlcl0NCg0KRnJv bTogSGFvd2VpZ3VvIFttYWlsdG86aGFvd2VpZ3VvQGh1YXdlaS5jb21dDQpTZW50OiBUdWVzZGF5 LCBBcHJpbCAwMSwgMjAxNCA4OjUxIFBNDQpUbzogVGlzc2EgU2VuZXZpcmF0aG5lICh0c2VuZXZp cik7IG1wbHNAaWV0Zi5vcmc7IGwydnBuQGlldGYub3JnOyBuZXRtb2RAaWV0Zi5vcmcNClN1Ympl Y3Q6ILTwuLQ6IFlBTkcgbW9kZWwgZm9yIHByb3RvY29sIGluZGVwZW5kZW50IE9BTQ0KDQoNCkhp IFRpc3NhLA0KDQpUaGFua3MgZm9yIHlvdXIgcHJlc2VudGluZyB0aGUgZGV0YWlsIFlhbmcgbW9k ZWwgb2YgVFJJTEwgT0FNLiBBZnRlciByZWFkIHRoZSBkcmFmdCwgaSBoYXZlIHNvbWUgY29tbWVu dHMgYW5kIHByb2JsZW1zIGFzIGZvbGxvd3MuDQoNCg0KDQoxLiBUaGVyZSBpcyBubyBNSVAgZGF0 YSBtb2RlbCBpbiB0aGlzIGRyYWZ0LCBpbiBUUklMTCBPQU0gRnJhbWV3b3JrIE1JUCBpcyBkZWZp bml0ZWx5IGRlZmluZWQgdG8gZmlsdGVyIE9BTSBwYWNrZXQgYmFzZWQgb24gTUlQIGxldmVsLg0K DQpbYW5zd2VyXSBJIGludGVudGlvbmFsbHkgc2tpcHBlZCB0aGlzIGZvciB0aGUgaW5pdGlhbCBy ZXYsIGl0IGlzIGFzc3VtZWQgYWxsIE1JUCBhcmUgYXV0byBjcmVhdGVkIG9uIGFwcGxpY2FibGUg aW50ZXJmYWNlcy4gSW4gdGhlIG5leHQgcmV2LCBhdCB0aGUgTUEgbGV2ZWwgd2lsbCBpbmNsdWRl IG5vZGUgbWEtYXV0b2NyZWF0ZS4gV2hlbiBkaXNhYmxlLCB3aWxsIGFkZCBhYmlsaXR5IHRvIGNy ZWF0ZSBNSVAgbWFudWFsbHkuIFRoZXJlIHdpbGwgYmUgbm8gc3BlY2lmaWMgTUlQIGFkZHJlc3Mg bGlrZSBpbiBNRVAsIGJ1dCBqdXN0IHRoZSBkaXJlY3Rpb24gYW5kIGF0dGFjaGVkIGludGVyZmFj ZS4NCg0KMi4gVGhlIHJhbmdlIG9mIE1FUCBJRCBpcyBmcm9tIDEgdG8gODE5MS4gSW4gVFJJTEwg T0FNIGZyYW1ld29yaywgdHJpbGwgYmFzZSBtb2RlIGlzIGRlZmluZWQgdG8gZ2VuZXJhdGUgTUQs IE1BLCBhbmQgTUVQIGF1dG9tYXRpY2FsbHksIE1FUCBJRCBjYW4gdXNlIFJCJ3Mgbmlja25hbWUg YW5kIHdpbGwgYmUgYmV5b25kIDgxOTEsIGhvdyBjYW4gaXQgYmUgbWFuYWdlZCB0aHJvdWdoIFlh bmcgbW9kZWw/DQoNClthbnN3ZXJdIG9uIGEgZGlmZmVyZW50IHRocmVhZCBZaSB6aG91IGFsc28g YXNrZWQgbWUgdGhlIHNhbWUgcXVlc3Rpb24uIDgxOTEgdGFrZW4gZnJvbSB0aGUgQ0ZNIE1JQi4g QWx0aG91Z2ggYWN0dWFsIE1FUC1JRCBvbiB0aGUgd2lyZSBpcyAyIGJ5dGVzLCAoU2VjdGlvbiAy MS42IDgwMi4xYWcsIFRhYmxlIDIxLTE1KSBJIHdpbGwgY2hhbmdlIHRoZSByYW5nZSB0byBmdWxs IHJhbmdlIHdoZW4gdGVjaG5vbG9neSBpcyBub3QgQ0ZNLg0KDQozLiBJbiB0cmlsbCBiYXNlIG1v ZGUsIHRoZSBkZWZhdWx0IG5hbWUgZm9yIE1EIGlzICJUcmlsbEJhc2VNb2RlIiwgdGhlIGRlZmF1 bHQgbmFtZSBmb3IgTUEgaXMgIkZGRkMiLiBJZiB0aGV5IGFyZSBjb25mbGljdGVkIHdpdGggdGhl IGNvbmZpZ3VyYXRpb24gZGF0YSwgaG93IGNhbiB3ZSBzb2x2ZSB0aGlzIGlzc3VlPw0KDQoNCg0K W2Fuc3dlcl0gQSBWZXJ5IGdvb2QgcXVlc3Rpb24sIEkgZGlkIG5vdCBpbmNsdWRlIHRoaXMgaW4g dGhlIGluaXRpYWwgdmVyc2lvbiB0byBrZWVwIGl0IHNpbXBsZSBidXQgeW91IGNhdWdodCBpdCA6 KS4NCg0KSW4gdGhlIG5leHQgcmV2IEkgd2lsbCBpbmNsdWRlIGFzIGZvbGxvd3MNCg0KVGhlcmUg Y2FuIGJlIG9uZSBhbmQgb25seSBvbmUgVHJpbGxCYXNlIG1vZGUgcGVyIE1BLg0KDQpJIHdpbGwg ZWl0aGVyIGludHJvZHVjZSB0cmlsbCBmZWF0dXJlIGFuZCBtYWtlIGlmLWZlYXR1cmUgb3Igd2hl biB0ZWNobm9sb2d5PXRyaWxsLCB0byBjcmVhdGUgQmFzZSBtb2RlIG5vZGUuICBNeSBjdXJyZW50 IHByZWZlcmVuY2UgaXMgdG8gdXNlIGlmLWZlYXR1cmUuDQoNClRoYW5rcw0KDQp3ZWlndW8NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogbXBscyBbbXBscy1ib3Vu Y2VzQGlldGYub3JnXSC0+rHtIFRpc3NhIFNlbmV2aXJhdGhuZSAodHNlbmV2aXIpIFt0c2VuZXZp ckBjaXNjby5jb21dDQq3osvNyrG85DogMjAxNMTqNNTCMsjVIDEwOjU3DQrK1bz+yMs6IG1wbHNA aWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+OyBsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2 cG5AaWV0Zi5vcmc+OyBuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCtb3 zOI6IFttcGxzXSBZQU5HIG1vZGVsIGZvciBwcm90b2NvbCBpbmRlcGVuZGVudCBPQU0NCkFsbA0K DQpJbiB0aGUgZHJhZnQgYmVsb3cgd2UgcHJlc2VudCBZQU5HIG1vZGVsIHRvIGFic3RyYWN0IHBy b3RvY29sIGRlcGVuZGVudCBhc3BlY3RzIG9mIE9BTSBhbmQgY3JlYXRlIGEgdW5pZmllZCBPQU0g QVBJIHNldC4gSW4gYSBudXRzaGVsbCwgcGluZyBpcyBwaW5nIGFuZCB0cmFjZXJvdXRlIGlzIHRy YWNlcm91dGUgYW5kIHNvIG9uLiBQcm90b2NvbCBpbmRlcGVuZGVudCBBUEkgoa5zIGFsbG93IHVz ZXJzIHRvIGV4ZXJjaXNlIHRoZXNlIE9BTSB0b29scyBpbiB0aGUgc2FtZSBtYW5uZXIgYWNyb3Nz IGRpZmZlcmVudCB0ZWNobm9sb2dpZXMgYW5kIGFsbG93IHRvIGludGVncmF0ZSB0byB0aGVpciBv cGVyYXRpb25zIHBsYXRmb3Jtcy4NCg0KQXBwcmVjaWF0ZSB5b3VyIHRpbWUgb24gcmV2aWV3aW5n IGFuZCBwcm92aWRpbmcgY29tbWVudHMsIGJvdGggb24gQVBJoa9zIGFuZCBZQU5HIG1vZGVsIGFz IHdlbGwgYXMgT0FNIGZyYW1ld29yayBpbiBpdCBzZWxmLg0KDQpodHRwOi8vd3d3LmlldGYub3Jn L2lkL2RyYWZ0LXRpc3NhLW5ldG1vZC1vYW0tMDAudHh0DQoNClRoYW5rcw0KVGlzc2ENCg== --_000_FBEA3E19AA24F847BA3AE74E2FE193562AFA789Exmbrcdx08ciscoc_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Weiguo

 

Thanks for some very g= ood set of questions, please see the answers below in-line with [answer]

 

From: Haoweigu= o [mailto:haoweiguo@huawei.com]
Sent: Tuesday, April 01, 2014 8:51 PM
To: Tissa Senevirathne (tsenevir); mpls@ietf.org; l2vpn@ietf.org; ne= tmod@ietf.org
Subject: =B4=F0=B8=B4: YANG model for protocol ind= ependent OAM

 

Hi Tissa,

Thanks for your presenting the detail Yang = model of TRILL OAM. After read the draft, i have some comments an= d problems as follows.

 

1. There is no MIP data model in this draft, in = TRILL OAM Framework MIP is definitely defined to filter OAM packet based on= MIP level.

[answer] I intentionally skipped this for the = initial rev, it is assumed all MIP are auto created on applicable interface= s. In the next rev, at the MA level will include node ma-autocreate. When disable, will add ability to create MIP manually. Ther= e will be no specific MIP address like in MEP, but just the direction and a= ttached interface.


2. The range of MEP ID is from 1 to 8191. In TRILL OAM framework, trill bas= e mode is defined to generate MD, MA, and MEP automatically, MEP ID can use= RB's nickname and will be beyond 8191, how can it be managed through Yang = model?

[answer] on a different thread Yi zhou also as= ked me the same question. 8191 taken from the CFM MIB. Although actual MEP-= ID on the wire is 2 bytes, (Section 21.6 802.1ag, Table 21-15) I will change the range to full range when technology is not CFM.


3. In trill base mode, the default name for MD is "TrillBaseMode"= , the default name for MA is "FFFC". If they are conflicted with = the configuration data, how can we solve this issue?

 

[answer] A Very good question, I did not incl= ude this in the initial version to keep it simple but you caught it J.

In the next rev I will include as follows

There can be one and only one TrillBase mode = per MA.

I will either introduce trill feature and mak= e if-feature or when technology=3Dtrill, to create Base mode node.  My= current preference is to use if-feature.


Thanks

weiguo

=B7=A2=BC=FE= =C8=CB: mpls [mpls-bounces@ietf.org] =B4=FA=B1=ED Tissa Senevirathne (tsenevir) [tsenevir@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2014=C4=EA4=D4=C22=C8=D5 10:57
=CA=D5=BC=FE=C8=CB: mpls@ietf.org; l2vpn@ietf.org; netmod@ietf.org<= br> =D6=F7=CC=E2: [mpls] YANG model for protocol independent OAM

All

 =

In the draft below we pr= esent YANG model to abstract protocol dependent aspects of OAM and create a= unified OAM API set. In a nutshell, ping is ping and traceroute is tracero= ute and so on. Protocol independent API =A1=AEs allow users to exercise these OAM tools in the same manner acr= oss different technologies and allow to integrate to their operations platf= orms.

 =

Appreciate your time on = reviewing and providing comments, both on API=A1=AFs and YANG model as well= as OAM framework in it self.

 =

http://www.ietf.= org/id/draft-tissa-netmod-oam-00.txt

 =

Thanks=

Tissa<= /p>

--_000_FBEA3E19AA24F847BA3AE74E2FE193562AFA789Exmbrcdx08ciscoc_-- From nobody Wed Apr 2 16:21:02 2014 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 920A41A0425 for ; Wed, 2 Apr 2014 16:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.51 X-Spam-Level: X-Spam-Status: No, score=-9.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 CxEzEXTjSwqK for ; Wed, 2 Apr 2014 16:20:56 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id CC47D1A0426 for ; Wed, 2 Apr 2014 16:20:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24391; q=dns/txt; s=iport; t=1396480852; x=1397690452; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=xS7qWRi7Oa4atPtZKL7qXOqksHt+HKkBedTmJuZvn5w=; b=HmuG2tnJVzcsqiqmYMmd9xDh+C7sEEJBFvOWhA1N2S9PXQEuB9SHvR49 rTxP8QN74MAnm9zwlNLhi2AwbpTmeQKk3VUtJlmUk7n8dwKTD+j9+bMnq gZStnNsvYUe3yhrEl51x86kijcyS8WnsDhSGVcxhIv4YlDNZYsyeko1lp w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FALWaPFOtJV2a/2dsb2JhbABZgkIjITtXw2aBGhZ0giUBAQEELUwSAQgRAwEBASEHKBEUCQgBAQQBDQUbh0oDEQHIBA2HNheMVoIJEQYBhDgElmuBbYxthUyDMIIr X-IronPort-AV: E=Sophos; i="4.97,783,1389744000"; d="scan'208,217"; a="32422954" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP; 02 Apr 2014 23:20:51 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s32NKpDX006723 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 2 Apr 2014 23:20:51 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0123.003; Wed, 2 Apr 2014 18:20:50 -0500 From: "Samer Salam (ssalam)" To: "Xialiang (Frank)" , "Ali Sajassi (sajassi)" , "aldrin.ietf@gmail.com" , "jdrake@juniper.net" Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Thread-Topic: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Thread-Index: Ac9CeLdIKfj9gmHqQoGb/BpQJYep2gKmytoAAA23woAAW6pZgA== Date: Wed, 2 Apr 2014 23:20:50 +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.2.130206 x-originating-ip: [10.21.100.108] Content-Type: multipart/alternative; boundary="_000_CF61E72C27F74ssalamciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/SFDB3ilSCWPh6sFibLVRCIR3-DU Cc: "l2vpn@ietf.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: Wed, 02 Apr 2014 23:21:00 -0000 --_000_CF61E72C27F74ssalamciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Frank, Please find my responses inline after yours=85 From: "Xialiang (Frank)" > Date: Monday, 31 March, 2014 7:00 PM To: Samer Salam >, "Ali Sajassi (= sajassi)" >, "aldrin.ietf@gmail= .com" >, "jdrake@juniper.net" > Cc: "l2vpn@ietf.org" > Subject: RE: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Hi Samer, Please see inline: From: Samer Salam (ssalam) [mailto:ssalam@cisco.com] Sent: Tuesday, April 01, 2014 5:03 AM To: Xialiang (Frank); Ali Sajassi (sajassi); aldrin.ietf@gmail.com; jdrake@juniper.net Cc: l2vpn@ietf.org Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Hi Frank, Thanks for your comments. Please find responses below: 1. In this draft, we cite RFC 6136 as reference, and hence we do not repeat= the definition of common OAM terms (MEP, MIP, Maintenance Domain, In-band = OAM, OAM layering etc.). Regarding Discovery, please note that E-VPN has au= tomatic discovery built-in via the Inclusive Multicast Route and the Ethern= et A-D Route. Hence, no further mechanisms are required. 2. Per user flow means a traffic stream that maps to actual user data, with= a specified N-tuple characteristics (MAC DA/SA, VLAN, IP DA/SA, Src/Dest P= ort=85). The reason why this is different between Network & Service OAM is= because the Service OAM mechanisms may or may not be able to support per-f= low OAM, depending on the service layer and its associated OAM capabilitie= s. For instance, in the case where Ethernet CFM (IEEE 802.1ag) is the servi= ce OAM, it is not possible to perform per-flow continuity check, as the des= tination MAC address is set by the protocol to a multicast address. 3. Yes, a representative path maps to a test flow. This is a simple functio= n, and is actually a degenerate case of the per user-flow OAM, because test= fields are specified for the N-Tuple. That's why it is mandatory. As to th= e details of the mechanism, that is left to the solution draft =96 after al= l, this is the requirements and framework draft, it does not cover the solu= tion details for implementation. [Frank] : From my personal view, I don=92t think the paragraph describing t= he requirement of a representative path is clear enough. For example, why c= an it be used for node failure detection but not path failure detection? It can be used for failure detection of that "representative" path, but the= point is that this lacks real practical benefit to the network operator: t= he path may have been chosen arbitrarily by an OAM solution that constructs= test flows using random or pseudo-random entropy generators. Hence, the fo= cus is on what practical information could the network operator glean from = this mode of operation, and the answer is: node failure detection. We can u= pdate the text to expand on this point. 4. Test packets can be either unicast or multicast. The problem we are desc= ribing here is that relying on normal packet counters in unreliable given t= hat E-VPN offers many-to-many connectivity. For e.g., consider 3 endpoints = A, B and C. Let's say we are interested in measuring the loss between A and= C. A sends a packet to C, but it gets dropped. Now B also sends to C and t= hat packet is delivered. If we were to examine the packet counter on C, we = will find that the counter shows 1 packet received. But that doesn't mean t= hat we have 100% packet delivery rate between A and C. The packet actually = came from another source and hence the packet counter on C is ambiguous. Un= less the implementation keeps packet counters per-flow (which will be expen= sive and impractical), it is not reliable to use packet counters to measure= loss in a technology that supports multipoint-to-multipoint connectivity. [Frank] : Yes. This clarification is more clear than the current content of= draft~~ Also, I think =93a statistical means of approximating packet loss = rate=94 you proposed in draft is not the suitable solution for this problem= . This is not a new problem. ITU-T Y.1731 and the Metro Ethernet Forum have t= ackled this very same problem in the recent past, and the approach converge= d on statistical approximation. Actually, this is more an implementation issue, i.e., we can set the same v= alue of flow characteristics for a test flow to ensure all test flow packet= s send/receive between 2 nodes exactly. The draft is not precluding other solutions. It is simply stating that a so= lution based on synthetic measurement is required. There is no statement th= at this shall be the only option offered. Regards, Samer Regards, Samer From: "Xialiang (Frank)" > Date: Tuesday, 18 March, 2014 12:07 AM To: Samer Salam >, "Ali Sajassi (= sajassi)" >, "aldrin.ietf@gmail= .com" >, "jdrake@juniper.net" > Cc: "l2vpn@ietf.org" > Subject: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Hi authors, I have reviewed this important draft, and have some comments as below: 1. By comparing with RFC6136 (L2VPN OAM req and frm), from the integrity po= int of view, I think there are some part missing: EVPN MEP and MIP, Discove= ry, Data Path Forwarding, Scalability, Transport/Application Independence; 2. In section 3.1.1.1, what is the definition of per user flow? Why is it d= ifferent to support it between E-VPN Network OAM and E-VPN Service OAM? 3. In section 3.1.1.1, does the section of "a representative path" mean usi= ng test flow to detect the node failure? if yes, how to do? Is it a necessa= ry requirement of proactive fault detection? 4. In section 3.2.1, I do not quite understand the describing reason for th= e inaccuracy of Loss Measurement. Do you mean that test packets of Loss Mea= surement are all BUM packets? Can you clarify why peer MEPs will receive so= me unnecessary packets? Why not use unicast packets for Loss Measurement? Hoping for your feedback~~ B.R. Frank --_000_CF61E72C27F74ssalamciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <631DE28A80C32A45B895DDCF5C1B8E84@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Frank,

Please find my responses inline after yours=85

From: "Xialiang (Frank)" = <frank.xialiang@huawei.com<= /a>>
Date: Monday, 31 March, 2014 7:00 P= M
To: Samer Salam <ssalam@cisco.com>, "Ali Sajassi (sajassi)&= quot; <sajassi@cisco.com>, &= quot;aldrin.ietf@gmail.com&quo= t; <aldrin.ietf@gmail.com>= , "jdrake@juniper.net" = <jdrake@juniper.net>
Cc: "l2vpn@ietf.org" <l2v= pn@ietf.org>
Subject: RE: comments on "draf= t-salam-l2vpn-evpn-oam-req-frmwk-02":

Hi Same= r,

Please = see inline:

&n= bsp;

F= rom: Samer Salam (ssalam) [mailto:ssalam@cisco.com]
Sent: Tuesday, April 01, 2014 5:03 AM
To: Xialiang (Frank); Ali Sajassi (sajassi); aldrin.ietf@gmail.com; jdrake@jun= iper.net
Cc: l2vpn@ietf.org
Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-= 02":

 

Hi Frank,=

&nbs= p;

Thanks fo= r your comments. Please find responses below:

&nbs= p;

1. In thi= s draft, we cite RFC 6136 as reference, and hence we do not repeat the defi= nition of common OAM terms (MEP, MIP, Maintenance Domain, In-band OAM, OAM = layering etc.). Regarding Discovery, please note that E-VPN has automatic discovery built-in via the Inclusive Multica= st Route and the Ethernet A-D Route. Hence, no further mechanisms are requi= red.

&nbs= p;

2. Per us= er flow means a traffic stream that maps to actual user data, with a specif= ied N-tuple characteristics (MAC DA/SA, VLAN, IP DA/SA, Src/Dest Port=85). =  The reason why this is different between Network & Service OAM is because the Service OAM mechanisms may or may= not be able to support per-flow OAM, depending on the  service layer = and its associated OAM capabilities. For instance, in the case where Ethern= et CFM (IEEE 802.1ag) is the service OAM, it is not possible to perform per-flow continuity check, as the destinatio= n MAC address is set by the protocol to a multicast address.

&nbs= p;

3. Yes, a= representative path maps to a test flow. This is a simple function, and is= actually a degenerate case of the per user-flow OAM, because test fields a= re specified for the N-Tuple. That's why it is mandatory. As to the details of the mechanism, that is left to the s= olution draft =96 after all, this is the requirements and framework draft, = it does not cover the solution details for implementation.

[= Frank] : From my personal view, I don=92t think the paragraph describing th= e requirement of a representative path is clear enough. For example, why ca= n it be used for node failure detection but not path failure detection?

It can be used for failure detection of that "representative"= ; path, but the point is that this lacks real practical benefit to the netw= ork operator: the path may have been chosen arbitrarily by an OAM solution = that constructs test flows using random or pseudo-random entropy generators. Hence, the focus is on what practical in= formation could the network operator glean from this mode of operation, and= the answer is: node failure detection. We can update the text to expand on= this point.

&nbs= p;

4. Test p= ackets can be either unicast or multicast. The problem we are describing he= re is that relying on normal packet counters in unreliable given that E-VPN= offers many-to-many connectivity. For e.g., consider 3 endpoints A, B and C. Let's say we are interested in meas= uring the loss between A and C. A sends a packet to C, but it gets dropped.= Now B also sends to C and that packet is delivered. If we were to examine = the packet counter on C, we will find that the counter shows 1 packet received. But that doesn't mean that = we have 100% packet delivery rate between A and C. The packet actually came= from another source and hence the packet counter on C is ambiguous. Unless= the implementation keeps packet counters per-flow (which will be expensive and impractical), it is not rel= iable to use packet counters to measure loss in a technology that supports = multipoint-to-multipoint connectivity.

[= Frank] : Yes. This clarification is more clear than the current content of = draft~~ Also, I think =93a statistical means of approximating packet loss r= ate=94 you proposed in draft is not the suitable solution for this problem.


This is not a new problem. ITU-T Y.1731 and the Metro Ethernet Forum h= ave tackled this very same problem in the recent past, and the approach con= verged on statistical approximation. 

A= ctually, this is more an implementation issue, i.e., we can set the same va= lue of flow characteristics for a test flow to ensure all test flow packets= send/receive between 2 nodes exactly.

&nbs= p;

The draft is not precluding other solutions. It is simply stating that= a solution based on synthetic measurement is required. There is no stateme= nt that this shall be the only option offered.

Regards,
Samer

Regards,<= o:p>

Samer

&nbs= p;

From: &quo= t;Xialiang (Frank)" <f= rank.xialiang@huawei.com>
Date: Tuesday, 18 March, 2014 12:07 AM
To: Samer Salam <ssalam@cisco= .com>, "Ali Sajassi (sajassi)" <sajassi@cisco.com>, "aldrin.ietf@gmail.com" <aldrin.ietf@gmail.com>, "jdrake@juniper.net" &= lt;jdrake@juniper.net>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>
Subject: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02&q= uot;:

&nbs= p;

Hi author= s,

I have re= viewed this important draft, and have some comments as below:

1. By com= paring with RFC6136 (L2VPN OAM req and frm), from the integrity point of vi= ew, I think there are some part missing: EVPN MEP and MIP, Discovery, Data = Path Forwarding, Scalability, Transport/Application Independence;

2. In sec= tion 3.1.1.1, what is the definition of per user flow? Why is it different = to support it between E-VPN Network OAM and E-VPN Service OAM?

3. In sec= tion 3.1.1.1, does the section of "a representative path" mean us= ing test flow to detect the node failure? if yes, how to do? Is it a necess= ary requirement of proactive fault detection?

4. In sec= tion 3.2.1, I do not quite understand the describing reason for the inaccur= acy of Loss Measurement. Do you mean that test packets of Loss Measurement = are all BUM packets? Can you clarify why peer MEPs will receive some unnecessary packets? Why not use unicast packe= ts for Loss Measurement?

 

Hoping fo= r your feedback~~

 

B.R.=

Frank

 --_000_CF61E72C27F74ssalamciscocom_-- From nobody Wed Apr 2 20:41:48 2014 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 57AEA1A00A8 for ; Wed, 2 Apr 2014 20:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 9AbZEnWmo7BJ for ; Wed, 2 Apr 2014 20:41:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E0A0A1A00A5 for ; Wed, 2 Apr 2014 20:41:39 -0700 (PDT) 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 BFF12675; Thu, 03 Apr 2014 03:41:34 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 3 Apr 2014 04:40:48 +0100 Received: from SZXEMA409-HUB.china.huawei.com (10.82.72.41) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 3 Apr 2014 04:41:33 +0100 Received: from SZXEMA502-MBS.china.huawei.com ([169.254.4.203]) by SZXEMA409-HUB.china.huawei.com ([10.82.72.41]) with mapi id 14.03.0158.001; Thu, 3 Apr 2014 11:41:29 +0800 From: "Xialiang (Frank)" To: "Samer Salam (ssalam)" , "Ali Sajassi (sajassi)" , "aldrin.ietf@gmail.com" , "jdrake@juniper.net" Subject: RE: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Thread-Topic: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Thread-Index: Ac9CeLdIKfj9gmHqQoGb/BpQJYep2gKmytoAAA23woAAW6pZgAAM+0XA Date: Thu, 3 Apr 2014 03:41:28 +0000 Message-ID: References: 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.135.42.220] Content-Type: multipart/alternative; boundary="_000_C02846B1344F344EB4FAA6FA7AF481F10F3E205ESZXEMA502MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/gLbDTmX__KcWuuhiU1yO_fIL4Ks Cc: "l2vpn@ietf.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: Thu, 03 Apr 2014 03:41:46 -0000 --_000_C02846B1344F344EB4FAA6FA7AF481F10F3E205ESZXEMA502MBSchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Samer, My suggestions are in line: From: Samer Salam (ssalam) [mailto:ssalam@cisco.com] Sent: Thursday, April 03, 2014 7:21 AM To: Xialiang (Frank); Ali Sajassi (sajassi); aldrin.ietf@gmail.com; jdrake@= juniper.net Cc: l2vpn@ietf.org Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Hi Frank, Please find my responses inline after yours... From: "Xialiang (Frank)" > Date: Monday, 31 March, 2014 7:00 PM To: Samer Salam >, "Ali Sajassi (= sajassi)" >, "aldrin.ietf@gmail= .com" >, "jdrake@juniper.net" > Cc: "l2vpn@ietf.org" > Subject: RE: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Hi Samer, Please see inline: From: Samer Salam (ssalam) [mailto:ssalam@cisco.com] Sent: Tuesday, April 01, 2014 5:03 AM To: Xialiang (Frank); Ali Sajassi (sajassi); aldrin.ietf@gmail.com; jdrake@juniper.net Cc: l2vpn@ietf.org Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Hi Frank, Thanks for your comments. Please find responses below: 1. In this draft, we cite RFC 6136 as reference, and hence we do not repeat= the definition of common OAM terms (MEP, MIP, Maintenance Domain, In-band = OAM, OAM layering etc.). Regarding Discovery, please note that E-VPN has au= tomatic discovery built-in via the Inclusive Multicast Route and the Ethern= et A-D Route. Hence, no further mechanisms are required. 2. Per user flow means a traffic stream that maps to actual user data, with= a specified N-tuple characteristics (MAC DA/SA, VLAN, IP DA/SA, Src/Dest P= ort...). The reason why this is different between Network & Service OAM is= because the Service OAM mechanisms may or may not be able to support per-f= low OAM, depending on the service layer and its associated OAM capabilitie= s. For instance, in the case where Ethernet CFM (IEEE 802.1ag) is the servi= ce OAM, it is not possible to perform per-flow continuity check, as the des= tination MAC address is set by the protocol to a multicast address. 3. Yes, a representative path maps to a test flow. This is a simple functio= n, and is actually a degenerate case of the per user-flow OAM, because test= fields are specified for the N-Tuple. That's why it is mandatory. As to th= e details of the mechanism, that is left to the solution draft - after all,= this is the requirements and framework draft, it does not cover the soluti= on details for implementation. [Frank] : From my personal view, I don't think the paragraph describing the= requirement of a representative path is clear enough. For example, why can= it be used for node failure detection but not path failure detection? It can be used for failure detection of that "representative" path, but the= point is that this lacks real practical benefit to the network operator: t= he path may have been chosen arbitrarily by an OAM solution that constructs= test flows using random or pseudo-random entropy generators. Hence, the fo= cus is on what practical information could the network operator glean from = this mode of operation, and the answer is: node failure detection. We can u= pdate the text to expand on this point. [Frank] :I suggests you give a clear clarification of the difference betwee= n node failure and path failure in this condition by your updates. I think = sam's response in previous email is a good reference. 4. Test packets can be either unicast or multicast. The problem we are desc= ribing here is that relying on normal packet counters in unreliable given t= hat E-VPN offers many-to-many connectivity. For e.g., consider 3 endpoints = A, B and C. Let's say we are interested in measuring the loss between A and= C. A sends a packet to C, but it gets dropped. Now B also sends to C and t= hat packet is delivered. If we were to examine the packet counter on C, we = will find that the counter shows 1 packet received. But that doesn't mean t= hat we have 100% packet delivery rate between A and C. The packet actually = came from another source and hence the packet counter on C is ambiguous. Un= less the implementation keeps packet counters per-flow (which will be expen= sive and impractical), it is not reliable to use packet counters to measure= loss in a technology that supports multipoint-to-multipoint connectivity. [Frank] : Yes. This clarification is more clear than the current content of= draft~~ Also, I think "a statistical means of approximating packet loss ra= te" you proposed in draft is not the suitable solution for this problem. This is not a new problem. ITU-T Y.1731 and the Metro Ethernet Forum have t= ackled this very same problem in the recent past, and the approach converge= d on statistical approximation. [Frank] :OK! Actually, this is more an implementation issue, i.e., we can set the same v= alue of flow characteristics for a test flow to ensure all test flow packet= s send/receive between 2 nodes exactly. The draft is not precluding other solutions. It is simply stating that a so= lution based on synthetic measurement is required. There is no statement th= at this shall be the only option offered. [Frank] : OK! Regards, Samer Regards, Samer From: "Xialiang (Frank)" > Date: Tuesday, 18 March, 2014 12:07 AM To: Samer Salam >, "Ali Sajassi (= sajassi)" >, "aldrin.ietf@gmail= .com" >, "jdrake@juniper.net" > Cc: "l2vpn@ietf.org" > Subject: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Hi authors, I have reviewed this important draft, and have some comments as below: 1. By comparing with RFC6136 (L2VPN OAM req and frm), from the integrity po= int of view, I think there are some part missing: EVPN MEP and MIP, Discove= ry, Data Path Forwarding, Scalability, Transport/Application Independence; 2. In section 3.1.1.1, what is the definition of per user flow? Why is it d= ifferent to support it between E-VPN Network OAM and E-VPN Service OAM? 3. In section 3.1.1.1, does the section of "a representative path" mean usi= ng test flow to detect the node failure? if yes, how to do? Is it a necessa= ry requirement of proactive fault detection? 4. In section 3.2.1, I do not quite understand the describing reason for th= e inaccuracy of Loss Measurement. Do you mean that test packets of Loss Mea= surement are all BUM packets? Can you clarify why peer MEPs will receive so= me unnecessary packets? Why not use unicast packets for Loss Measurement? Hoping for your feedback~~ B.R. Frank --_000_C02846B1344F344EB4FAA6FA7AF481F10F3E205ESZXEMA502MBSchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Same= r,

My sugg= estions are in line:

&n= bsp;

From: Samer Salam = (ssalam) [mailto:ssalam@cisco.com]
Sent: Thursday, April 03, 2014 7:21 AM
To: Xialiang (Frank); Ali Sajassi (sajassi); aldrin.ietf@gmail.com; = jdrake@juniper.net
Cc: l2vpn@ietf.org
Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-= 02":

 

Hi Frank,=

&nbs= p;

Please fi= nd my responses inline after yours…

&nbs= p;

From: &quo= t;Xialiang (Frank)" <f= rank.xialiang@huawei.com>
Date: Monday, 31 March, 2014 7:00 PM
To: Samer Salam <ssalam@cisco= .com>, "Ali Sajassi (sajassi)" <sajassi@cisco.com>, "aldrin.ietf@gmail.com" <aldrin.ietf@gmail.com>, "jdrake@juniper.net" &= lt;jdrake@juniper.net>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>
Subject: RE: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-= 02":

&nbs= p;

Hi Same= r,

Please = see inline:

 <= /span>

From: Samer Salam (ssalam) [mailto:ssalam@ci= sco.com]
Sent: Tuesday, April 01, 2014 5:03 AM
To: Xialiang (Frank); Ali Sajassi (sajassi); aldrin.ietf@gmail.com; jdrake@jun= iper.net
Cc: l2vpn@ietf.org
Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-= 02":

 

Hi Frank,=

 

Thanks fo= r your comments. Please find responses below:

 

1. In thi= s draft, we cite RFC 6136 as reference, and hence we do not repeat the defi= nition of common OAM terms (MEP, MIP, Maintenance Domain, In-band OAM, OAM = layering etc.). Regarding Discovery, please note that E-VPN has automatic discovery built-in via the Inclusive Multica= st Route and the Ethernet A-D Route. Hence, no further mechanisms are requi= red.

 

2. Per us= er flow means a traffic stream that maps to actual user data, with a specif= ied N-tuple characteristics (MAC DA/SA, VLAN, IP DA/SA, Src/Dest Port…= ;).  The reason why this is different between Network & Service OAM is because the Service OAM mechanisms may or may= not be able to support per-flow OAM, depending on the  service layer = and its associated OAM capabilities. For instance, in the case where Ethern= et CFM (IEEE 802.1ag) is the service OAM, it is not possible to perform per-flow continuity check, as the destinatio= n MAC address is set by the protocol to a multicast address.

 

3. Yes, a= representative path maps to a test flow. This is a simple function, and is= actually a degenerate case of the per user-flow OAM, because test fields a= re specified for the N-Tuple. That's why it is mandatory. As to the details of the mechanism, that is left to the s= olution draft – after all, this is the requirements and framework dra= ft, it does not cover the solution details for implementation.

[= Frank] : From my personal view, I don’t think the paragraph describin= g the requirement of a representative path is clear enough. For example, wh= y can it be used for node failure detection but not path failure detection?

 

It can be used for failure detection of th= at "representative" path, but the point is that this lacks real p= ractical benefit to the network operator: the path may have been chosen arbitrarily by an OAM solution that constructs test flows= using random or pseudo-random entropy generators. Hence, the focus is on w= hat practical information could the network operator glean from this mode o= f operation, and the answer is: node failure detection. We can update the text to expand on this point.

[Frank] :I suggests you give a clea= r clarification of the difference between node failure and path failure in = this condition by your updates. I think sam’s response in previous email is a good reference.

 

 

4. Test p= ackets can be either unicast or multicast. The problem we are describing he= re is that relying on normal packet counters in unreliable given that E-VPN= offers many-to-many connectivity. For e.g., consider 3 endpoints A, B and C. Let's say we are interested in meas= uring the loss between A and C. A sends a packet to C, but it gets dropped.= Now B also sends to C and that packet is delivered. If we were to examine = the packet counter on C, we will find that the counter shows 1 packet received. But that doesn't mean that = we have 100% packet delivery rate between A and C. The packet actually came= from another source and hence the packet counter on C is ambiguous. Unless= the implementation keeps packet counters per-flow (which will be expensive and impractical), it is not rel= iable to use packet counters to measure loss in a technology that supports = multipoint-to-multipoint connectivity.

[= Frank] : Yes. This clarification is more clear than the current content of = draft~~ Also, I think “a statistical means of approximating packet lo= ss rate” you proposed in draft is not the suitable solution for this problem.

 

This is not a new problem. ITU-T Y.1731 an= d the Metro Ethernet Forum have tackled this very same problem in the recen= t past, and the approach converged on statistical approximation. 

[Frank] :OK!

 

A= ctually, this is more an implementation issue, i.e., we can set the same va= lue of flow characteristics for a test flow to ensure all test flow packets= send/receive between 2 nodes exactly.

 

 

The draft is not precluding other solution= s. It is simply stating that a solution based on synthetic measurement is r= equired. There is no statement that this shall be the only option offered.

[Frank] : OK!

 

Regards,

Samer

 

Regards,<= o:p>

Samer

 

From: &quo= t;Xialiang (Frank)" <f= rank.xialiang@huawei.com>
Date: Tuesday, 18 March, 2014 12:07 AM
To: Samer Salam <ssalam@cisco= .com>, "Ali Sajassi (sajassi)" <sajassi@cisco.com>, "aldrin.ietf@gmail.com" <aldrin.ietf@gmail.com>, "jdrake@juniper.net" &= lt;jdrake@juniper.net>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>
Subject: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02&q= uot;:

 

Hi author= s,

I have re= viewed this important draft, and have some comments as below:

1. By com= paring with RFC6136 (L2VPN OAM req and frm), from the integrity point of vi= ew, I think there are some part missing: EVPN MEP and MIP, Discovery, Data = Path Forwarding, Scalability, Transport/Application Independence;

2. In sec= tion 3.1.1.1, what is the definition of per user flow? Why is it different = to support it between E-VPN Network OAM and E-VPN Service OAM?

3. In sec= tion 3.1.1.1, does the section of "a representative path" mean us= ing test flow to detect the node failure? if yes, how to do? Is it a necess= ary requirement of proactive fault detection?

4. In sec= tion 3.2.1, I do not quite understand the describing reason for the inaccur= acy of Loss Measurement. Do you mean that test packets of Loss Measurement = are all BUM packets? Can you clarify why peer MEPs will receive some unnecessary packets? Why not use unicast packe= ts for Loss Measurement?

 

Hoping fo= r your feedback~~

 

B.R.=

Frank

--_000_C02846B1344F344EB4FAA6FA7AF481F10F3E205ESZXEMA502MBSchi_-- From nobody Thu Apr 3 14:04:24 2014 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 DFE6D1A0172 for ; Thu, 3 Apr 2014 14:04:16 -0700 (PDT) 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 HzgWVz6A_LFd for ; Thu, 3 Apr 2014 14:04:10 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id B1E631A0181 for ; Thu, 3 Apr 2014 14:04:09 -0700 (PDT) X-AuditID: c618062d-b7fbd8e000003171-df-533dca721d91 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 65.83.12657.27ACD335; Thu, 3 Apr 2014 22:54:10 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Thu, 3 Apr 2014 17:04:04 -0400 From: Gregory Mirsky To: Sam Aldrin , "Xialiang (Frank)" Subject: RE: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Thread-Topic: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Thread-Index: Ac9CeLdIKfj9gmHqQoGb/BpQJYep2gKmytoAAA23woAACZ34gAA0EpSAAACgCoAATtvSsA== Date: Thu, 3 Apr 2014 21:04:03 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B78D90F@eusaamb103.ericsson.se> References: <8D1DD6FA-2758-4F4A-BD41-E22B59D6843E@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B78D90Feusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyuXRPiG7RKdtgg0vdehYTWr8wWvzpOsBs 8fjbIXaLd2ebWRxYPKb83sjqsXPWXXaPliNvWT2WLPnJFMASxWWTkpqTWZZapG+XwJXxse0q W8HF2UwVc75PZGlgnPOHsYuRk0NCwETiUfcddghbTOLCvfVsXYxcHEICRxkl+l7OZYZwljFK LFvwgBWkik3ASOLFxh6wDhGBCIlt73rBbGaBEIl3/T/AaoQFnCVOT5zMCFHjIrHh+lsmCDtM 4tDpdywgNouAisTc48vA4rwCvhLb579mhVj2nUni2qQ9zCAJTgFbidPfDoI1MAKd9/3UGiaI ZeISt57MZ4I4W0BiyZ7zzBC2qMTLx/9YIWxFiX3906GOy5e4dn8GK8QyQYmTM5+wTGAUnYVk 1CwkZbOQlEHEdSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZVjBylxalluelGBpsYgVF4TIJN dwfjnpeWhxilOViUxHm/vHUOEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDIlcYfqC27rqiH d1mLc/5h883+X1q7XP6xFv7RcOMqrF5z9ucZjwnl6V9rljxpsOIx+jpdoTbcgK94had3eyMr s3d71Nm9O2bwzPp8pvRizDMj765Spjmmj9jaz2byX1yvafBWtOF+h2LFDftFaZ2+b6OWZnzz YZJZrHJ1htwDYa2/d3TMXimxFGckGmoxFxUnAgAh0ob9kAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/0sdeL6SwKkBYgdhvqvf9P2Ozw2g Cc: "l2vpn@ietf.org" , "Ali Sajassi \(sajassi\)" 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, 03 Apr 2014 21:04:17 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B78D90Feusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear All, I think that case of e2e Continuity Check failure over path with multi-path= segment is an example of multi-layer OAM where fault detection and protect= ion switchover require careful coordination. If such coordination done prop= erly then e2e LoC fault would be informative and deterministic. Regards, Greg From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Sam Aldrin Sent: Tuesday, April 01, 2014 8:20 PM To: Xialiang (Frank) Cc: l2vpn@ietf.org; Ali Sajassi (sajassi) Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Inline with %sam. On Apr 1, 2014, at 8:02 PM, Xialiang (Frank) > wrote: Sam, Please see my response inline: From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] Sent: Tuesday, April 01, 2014 10:12 AM To: Xialiang (Frank) Cc: Samer Salam (ssalam); Ali Sajassi (sajassi); jdrake@juniper.net; l2vpn@ietf.org Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Frank, Comments inline. On Mar 31, 2014, at 7:00 PM, Xialiang (Frank) > wrote: Hi Samer, Please see inline: From: Samer Salam (ssalam) [mailto:ssalam@cisco.com] Sent: Tuesday, April 01, 2014 5:03 AM To: Xialiang (Frank); Ali Sajassi (sajassi); aldrin.ietf@gmail.com; jdrake@juniper.net Cc: l2vpn@ietf.org Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Hi Frank, Thanks for your comments. Please find responses below: 1. In this draft, we cite RFC 6136 as reference, and hence we do not repeat= the definition of common OAM terms (MEP, MIP, Maintenance Domain, In-band = OAM, OAM layering etc.). Regarding Discovery, please note that E-VPN has au= tomatic discovery built-in via the Inclusive Multicast Route and the Ethern= et A-D Route. Hence, no further mechanisms are required. 2. Per user flow means a traffic stream that maps to actual user data, with= a specified N-tuple characteristics (MAC DA/SA, VLAN, IP DA/SA, Src/Dest P= ort...). The reason why this is different between Network & Service OAM is= because the Service OAM mechanisms may or may not be able to support per-f= low OAM, depending on the service layer and its associated OAM capabilitie= s. For instance, in the case where Ethernet CFM (IEEE 802.1ag) is the servi= ce OAM, it is not possible to perform per-flow continuity check, as the des= tination MAC address is set by the protocol to a multicast address. 3. Yes, a representative path maps to a test flow. This is a simple functio= n, and is actually a degenerate case of the per user-flow OAM, because test= fields are specified for the N-Tuple. That's why it is mandatory. As to th= e details of the mechanism, that is left to the solution draft - after all,= this is the requirements and framework draft, it does not cover the soluti= on details for implementation. [Frank] : From my personal view, I don't think the paragraph describing the= requirement of a representative path is clear enough. For example, why can= it be used for node failure detection but not path failure detection? Whether one uses for node or path failure detection is for the solution to = decide. This is requirements draft. If you think better wording is required= , please do propose, will consider that. [Frank] : I agree with the principle of requirement draft. Actually, What I= suggest is better wording for better understanding the goal of representat= ive path check. %sam - When continuity to a MEP is lost, one could conclude there is a node= failure, but IMO, one cannot conclude path has failed as there could be a = different load balanced path exist. That is the reason we used the term 'co= nclusively'. If one's implementation could determine it is indeed path fail= ure, so be it. But from requirement point of view, we do not want to enforc= e node failure =3D path failure. Which translates to, solution and implemen= tations could innovate to conclusively determine path failure. Hope this is clear. cheers -sam 4. Test packets can be either unicast or multicast. The problem we are desc= ribing here is that relying on normal packet counters in unreliable given t= hat E-VPN offers many-to-many connectivity. For e.g., consider 3 endpoints = A, B and C. Let's say we are interested in measuring the loss between A and= C. A sends a packet to C, but it gets dropped. Now B also sends to C and t= hat packet is delivered. If we were to examine the packet counter on C, we = will find that the counter shows 1 packet received. But that doesn't mean t= hat we have 100% packet delivery rate between A and C. The packet actually = came from another source and hence the packet counter on C is ambiguous. Un= less the implementation keeps packet counters per-flow (which will be expen= sive and impractical), it is not reliable to use packet counters to measure= loss in a technology that supports multipoint-to-multipoint connectivity. [Frank] : Yes. This clarification is more clear than the current content of= draft~~ Also, I think "a statistical means of approximating packet loss ra= te" you proposed in draft is not the suitable solution for this problem. Ac= tually, this is more an implementation issue, i.e., we can set the same val= ue of flow characteristics for a test flow to ensure all test flow packets = send/receive between 2 nodes exactly. Again, this is requirement draft only. What you are eluding to is how one s= hould perform, which clearly falls in solution category. As Samer clarified= earlier, using actual data packet counters doesn't meet the requirements, = hence 'synthetic' measurement is required. [Frank] : OK -sam Regards, Samer From: "Xialiang (Frank)" > Date: Tuesday, 18 March, 2014 12:07 AM To: Samer Salam >, "Ali Sajassi (= sajassi)" >, "aldrin.ietf@gmail= .com" >, "jdrake@juniper.net" > Cc: "l2vpn@ietf.org" > Subject: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Hi authors, I have reviewed this important draft, and have some comments as below: 1. By comparing with RFC6136 (L2VPN OAM req and frm), from the integrity po= int of view, I think there are some part missing: EVPN MEP and MIP, Discove= ry, Data Path Forwarding, Scalability, Transport/Application Independence; 2. In section 3.1.1.1, what is the definition of per user flow? Why is it d= ifferent to support it between E-VPN Network OAM and E-VPN Service OAM? 3. In section 3.1.1.1, does the section of "a representative path" mean usi= ng test flow to detect the node failure? if yes, how to do? Is it a necessa= ry requirement of proactive fault detection? 4. In section 3.2.1, I do not quite understand the describing reason for th= e inaccuracy of Loss Measurement. Do you mean that test packets of Loss Mea= surement are all BUM packets? Can you clarify why peer MEPs will receive so= me unnecessary packets? Why not use unicast packets for Loss Measurement? Hoping for your feedback~~ B.R. Frank --_000_7347100B5761DC41A166AC17F22DF1121B78D90Feusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear All,

I think that case of e2e = Continuity Check failure over path with multi-path segment is an example of= multi-layer OAM where fault detection and protection switchover require careful coordination. If such coordination done properly then e2e = LoC fault would be informative and deterministic.

 <= /p>

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

From: L2vpn [m= ailto:l2vpn-bounces@ietf.org] On Behalf Of Sam Aldrin
Sent: Tuesday, April 01, 2014 8:20 PM
To: Xialiang (Frank)
Cc: l2vpn@ietf.org; Ali Sajassi (sajassi)
Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-= 02":

 

Inline with %sam.

 

On Apr 1, 2014, at 8:02 PM, Xialiang (Frank) <frank.xialiang@huawei.com>= wrote:



<= /p>

From: Sam Aldrin [mailto:aldrin.ietf@gmail.com] 
Sent: Tuesday, Apr= il 01, 2014 10:12 AM
To: Xialiang (Fran= k)
Cc: Samer Salam (s= salam); Ali Sajassi (sajassi); <= /span>jd= rake@juniper.net; l2vpn@ie= tf.org
Subject: Re: comme= nts on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

 

Frank,

 

Comments = inline.

On Mar 31= , 2014, at 7:00 PM, Xialiang (Frank) <frank.xialiang@huawei.com> wrote:




Hi Samer,

Please see inline:

 

From: Samer Salam (ssalam) [mailto:ssalam@cisco.com] 
Sent: Tuesday, Apr= il 01, 2014 5:03 AM
To: Xialiang (Fran= k); Ali Sajassi (sajassi); ald= rin.ietf@gmail.com; <= /span>jd= rake@juniper.net
Cc: l2vpn@ietf.org<= br> Subject: Re: comme= nts on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

 

Hi Frank,

 

Thanks for your comments. Please find responses below:

 

1. In this draft, we cite RFC 6136 as reference, and hence= we do not repeat the definition of common OAM terms (MEP, MIP, Maintenance Domain, In-band OAM, OAM layering etc.). Regarding Discov= ery, please note that E-VPN has automatic discovery built-in via the Inclus= ive Multicast Route and the Ethernet A-D Route. Hence, no further mechanism= s are required.

 

2. Per user flow means a traffic stream that maps to actua= l user data, with a specified N-tuple characteristics (MAC DA/SA, VLAN, IP DA/SA, Src/Dest Port…).  The reason why this is= different between Network & Service OAM is because the Service OAM mec= hanisms may or may not be able to support per-flow OAM, depending on the &n= bsp;service layer and its associated OAM capabilities. For instance, in the case where Ethernet CFM (IEEE 802.1ag) is the service= OAM, it is not possible to perform per-flow continuity check, as the desti= nation MAC address is set by the protocol to a multicast address.

 

3. Yes, a representative path maps to a test flow. This is= a simple function, and is actually a degenerate case of the per user-flow OAM, because test fields are specified for the N-Tuple. That= 's why it is mandatory. As to the details of the mechanism, that is left to= the solution draft – after all, this is the requirements and framewo= rk draft, it does not cover the solution details for implementation.

[Frank] : From my personal view, I don= ’t think the paragraph describing the requirement of a representative path is clear enough. For example, why can it be used for node failure det= ection but not path failure detection?

Whether o= ne uses for node or path failure detection is for the solution to decide. T= his is requirements draft. If you think better wording is required, please = do propose, will consider that.

[Frank] : I agree with the principle of requirement draft. Actually= , What I suggest is better wording for better understanding the goal of representative path check.

%sam - When continuity to a MEP is lost, one could c= onclude there is a node failure, but IMO, one cannot conclude path has fail= ed as there could be a different load balanced path exist. That is the reas= on we used the term ‘conclusively’. If one’s implementation could determine it is indeed path failure, s= o be it. But from requirement point of view, we do not want to enforce node= failure =3D path failure. Which translates to, solution and implementation= s could innovate to conclusively determine path failure.

 

Hope this is clear. 

 

cheers

-sam

 




 

4. Test packets can be either unicast or multicast. The pr= oblem we are describing here is that relying on normal packet counters in unreliable given that E-VPN offers many-to-many connectivity. = For e.g., consider 3 endpoints A, B and C. Let's say we are interested in m= easuring the loss between A and C. A sends a packet to C, but it gets dropp= ed. Now B also sends to C and that packet is delivered. If we were to examine the packet counter on C, we wil= l find that the counter shows 1 packet received. But that doesn't mean that= we have 100% packet delivery rate between A and C. The packet actually cam= e from another source and hence the packet counter on C is ambiguous. Unless the implementation keeps pack= et counters per-flow (which will be expensive and impractical), it is not r= eliable to use packet counters to measure loss in a technology that support= s multipoint-to-multipoint connectivity.

[Frank] : Yes. This clarification is m= ore clear than the current content of draft~~ Also, I think “a statistical means of approximating packet loss rate” you pr= oposed in draft is not the suitable solution for this problem. Actually, th= is is more an implementation issue, i.e., we can set the same value of flow= characteristics for a test flow to ensure all test flow packets send/receive between 2 nodes exactly.

Again, th= is is requirement draft only. What you are eluding to is how one should per= form, which clearly falls in solution category. As Samer clarified earlier,= using actual data packet counters doesn’t meet the requirements, hence ‘synthetic' measurement is required.&nb= sp;

[Frank] : OK

 

-sam


 

Regards,=

Samer

 

From: "Xialiang (Frank)" <frank.xialiang@huawei.com>
Date: Tuesday, 18 = March, 2014 12:07 AM
To: Samer Salam &l= t;ssalam@c= isco.com>, "Ali Sajassi (sajassi)" <sajassi@cisco.com>, "aldrin.ietf@gmail.com" <aldrin.ietf@gmail.com>= ;, "jdrake@juniper.net" <jdr= ake@juniper.net>
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: comments = on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

 

Hi authors,

I have reviewed this important draft, and have some commen= ts as below:

1. By comparing with RFC6136 (L2VPN OAM req and frm), from= the integrity point of view, I think there are some part missing: EVPN MEP and MIP, Discovery, Data Path Forwarding, Scalability, T= ransport/Application Independence;

2. In section 3.1.1.1, what is the definition of per user = flow? Why is it different to support it between E-VPN Network OAM and E-VPN Service OAM?

3. In section 3.1.1.1, does the section of "a represe= ntative path" mean using test flow to detect the node failure? if yes, how to do? Is it a necessary requirement of proactive fault detect= ion?

4. In section 3.2.1, I do not quite understand the describ= ing reason for the inaccuracy of Loss Measurement. Do you mean that test packets of Loss Measurement are all BUM packets? Can you cl= arify why peer MEPs will receive some unnecessary packets? Why not use unic= ast packets for Loss Measurement?

 

Hoping for your feedback~~

 

B.R.

Frank

 

 

--_000_7347100B5761DC41A166AC17F22DF1121B78D90Feusaamb103erics_-- From nobody Thu Apr 3 15:24:25 2014 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 11C8D1A02BB for ; Thu, 3 Apr 2014 15:24:23 -0700 (PDT) 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 L6dXpJL5cLXW for ; Thu, 3 Apr 2014 15:24:18 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 17E411A006E for ; Thu, 3 Apr 2014 15:24:18 -0700 (PDT) X-AuditID: c6180641-b7f768e000001855-64-533ddca63c3e Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 20.BB.06229.6ACDD335; Fri, 4 Apr 2014 00:11:50 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Thu, 3 Apr 2014 18:24:12 -0400 From: Gregory Mirsky To: Sam Aldrin , "Xialiang (Frank)" Subject: RE: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Thread-Topic: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Thread-Index: Ac9CeLdIKfj9gmHqQoGb/BpQJYep2gKmytoAAA23woAACZ34gACGY9WA Date: Thu, 3 Apr 2014 22:24:11 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B78D9A1@eusaamb103.ericsson.se> References: <8D1DD6FA-2758-4F4A-BD41-E22B59D6843E@gmail.com> In-Reply-To: <8D1DD6FA-2758-4F4A-BD41-E22B59D6843E@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B78D9A1eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyuXSPt+6yO7bBBj86VCwmtH5htPjTdYDZ 4vG3Q+wW7842sziweEz5vZHVY+esu+weLUfesnosWfKTKYAlissmJTUnsyy1SN8ugSuj+/h7 poLbbxkrGl7dYmxgXH+JsYuRk0NCwETi1vd5zBC2mMSFe+vZuhi5OIQEjjJK/N61hgXCWcYo MWvDAjaQKjYBI4kXG3vYQWwRgQiJbe96wWxmgRCJd/0/WEFsYQFnidMTJzNC1LhIbLj+lgnC dpNovdsPFOfgYBFQkTj62BEkzCvgKzHt/jOoXT8YJV4fOsMCkuAUsJXYMW8SWC8j0HXfT61h gtglLnHryXwmiKsFJJbsOQ/1gajEy8f/WCFsJYlJS8+xguxiFsiXeLjCCmKXoMTJmU9YJjCK zkIyaRZC1SwkVRAlOhILdn9ig7C1JZYtfM0MY5858JgJWXwBI/sqRo7S4tSy3HQjw02MwPg7 JsHmuINxwSfLQ4zSHCxK4rxf3joHCQmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamCMN/nc+ThL NO73K5mC3m+fS94JL6lTOHH9jWnEjyfOkW/mrOuRSvkvon7z1+6Cuv3SBrxFuXu+qNx+HbKd u+JJoehMed08iXU3fyfsv/Y6lbdmymuxFa2ZfR9Dns1KLilgfev6686EAp0X/adDLSbNK5lR wbfN9+aHtUssmy7f0l30edNzo4nvlViKMxINtZiLihMBfqWNgY0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/Ql5NIZOH3o17oHt1GWEDIXRPqhY Cc: "l2vpn@ietf.org" , "Ali Sajassi \(sajassi\)" 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, 03 Apr 2014 22:24:23 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B78D9A1eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Sam and Frank, even though we're discussing requirements and framework of EVPN OAM I wonde= r if you can give reference to OAM method that can differentiate or distin= guish between path and node failures as implied in: 3. Yes, a representative path maps to a test flow. This is a simple functio= n, and is actually a degenerate case of the per user-flow OAM, because test= fields are specified for the N-Tuple. That's why it is mandatory. As to th= e details of the mechanism, that is left to the solution draft - after all,= this is the requirements and framework draft, it does not cover the soluti= on details for implementation. [Frank] : From my personal view, I don't think the paragraph describing the= requirement of a representative path is clear enough. For example, why can= it be used for node failure detection but not path failure detection? Whether one uses for node or path failure detection is for the solution to = decide. This is requirements draft. If you think better wording is required= , please do propose, will consider that. Regards, Greg From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Sam Aldrin Sent: Monday, March 31, 2014 7:12 PM To: Xialiang (Frank) Cc: l2vpn@ietf.org; Ali Sajassi (sajassi) Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Frank, Comments inline. On Mar 31, 2014, at 7:00 PM, Xialiang (Frank) > wrote: Hi Samer, Please see inline: From: Samer Salam (ssalam) [mailto:ssalam@cisco.com] Sent: Tuesday, April 01, 2014 5:03 AM To: Xialiang (Frank); Ali Sajassi (sajassi); aldrin.ietf@gmail.com; jdrake@juniper.net Cc: l2vpn@ietf.org Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Hi Frank, Thanks for your comments. Please find responses below: 1. In this draft, we cite RFC 6136 as reference, and hence we do not repeat= the definition of common OAM terms (MEP, MIP, Maintenance Domain, In-band = OAM, OAM layering etc.). Regarding Discovery, please note that E-VPN has au= tomatic discovery built-in via the Inclusive Multicast Route and the Ethern= et A-D Route. Hence, no further mechanisms are required. 2. Per user flow means a traffic stream that maps to actual user data, with= a specified N-tuple characteristics (MAC DA/SA, VLAN, IP DA/SA, Src/Dest P= ort...). The reason why this is different between Network & Service OAM is= because the Service OAM mechanisms may or may not be able to support per-f= low OAM, depending on the service layer and its associated OAM capabilitie= s. For instance, in the case where Ethernet CFM (IEEE 802.1ag) is the servi= ce OAM, it is not possible to perform per-flow continuity check, as the des= tination MAC address is set by the protocol to a multicast address. 3. Yes, a representative path maps to a test flow. This is a simple functio= n, and is actually a degenerate case of the per user-flow OAM, because test= fields are specified for the N-Tuple. That's why it is mandatory. As to th= e details of the mechanism, that is left to the solution draft - after all,= this is the requirements and framework draft, it does not cover the soluti= on details for implementation. [Frank] : From my personal view, I don't think the paragraph describing the= requirement of a representative path is clear enough. For example, why can= it be used for node failure detection but not path failure detection? Whether one uses for node or path failure detection is for the solution to = decide. This is requirements draft. If you think better wording is required= , please do propose, will consider that. 4. Test packets can be either unicast or multicast. The problem we are desc= ribing here is that relying on normal packet counters in unreliable given t= hat E-VPN offers many-to-many connectivity. For e.g., consider 3 endpoints = A, B and C. Let's say we are interested in measuring the loss between A and= C. A sends a packet to C, but it gets dropped. Now B also sends to C and t= hat packet is delivered. If we were to examine the packet counter on C, we = will find that the counter shows 1 packet received. But that doesn't mean t= hat we have 100% packet delivery rate between A and C. The packet actually = came from another source and hence the packet counter on C is ambiguous. Un= less the implementation keeps packet counters per-flow (which will be expen= sive and impractical), it is not reliable to use packet counters to measure= loss in a technology that supports multipoint-to-multipoint connectivity. [Frank] : Yes. This clarification is more clear than the current content of= draft~~ Also, I think "a statistical means of approximating packet loss ra= te" you proposed in draft is not the suitable solution for this problem. Ac= tually, this is more an implementation issue, i.e., we can set the same val= ue of flow characteristics for a test flow to ensure all test flow packets = send/receive between 2 nodes exactly. Again, this is requirement draft only. What you are eluding to is how one s= hould perform, which clearly falls in solution category. As Samer clarified= earlier, using actual data packet counters doesn't meet the requirements, = hence 'synthetic' measurement is required. -sam Regards, Samer From: "Xialiang (Frank)" > Date: Tuesday, 18 March, 2014 12:07 AM To: Samer Salam >, "Ali Sajassi (= sajassi)" >, "aldrin.ietf@gmail= .com" >, "jdrake@juniper.net" > Cc: "l2vpn@ietf.org" > Subject: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Hi authors, I have reviewed this important draft, and have some comments as below: 1. By comparing with RFC6136 (L2VPN OAM req and frm), from the integrity po= int of view, I think there are some part missing: EVPN MEP and MIP, Discove= ry, Data Path Forwarding, Scalability, Transport/Application Independence; 2. In section 3.1.1.1, what is the definition of per user flow? Why is it d= ifferent to support it between E-VPN Network OAM and E-VPN Service OAM? 3. In section 3.1.1.1, does the section of "a representative path" mean usi= ng test flow to detect the node failure? if yes, how to do? Is it a necessa= ry requirement of proactive fault detection? 4. In section 3.2.1, I do not quite understand the describing reason for th= e inaccuracy of Loss Measurement. Do you mean that test packets of Loss Mea= surement are all BUM packets? Can you clarify why peer MEPs will receive so= me unnecessary packets? Why not use unicast packets for Loss Measurement? Hoping for your feedback~~ B.R. Frank --_000_7347100B5761DC41A166AC17F22DF1121B78D9A1eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Sam and Frank,<= /o:p>

even though we’re d= iscussing requirements and framework of EVPN OAM I wonder if you can give r= eference to  OAM method that can differentiate or distinguish between path and node failures as implied in:

3. Yes, a representative path maps to a t= est flow. This is a simple function, and is actually a degenerate case of the per user-flow OAM, because test fields are specified for the N= -Tuple. That's why it is mandatory. As to the details of the mechanism, tha= t is left to the solution draft – after all, this is the requirements= and framework draft, it does not cover the solution details for implementation.

= [Frank] : From my per= sonal view, I don’t think the paragraph describing the requirement of a representative path is clear enough. For example, why can it be used = for node failure detection but not path failure detection?

Whether one uses for node or path failure detection = is for the solution to decide. This is requirements draft. If you think bet= ter wording is required, please do propose, will consider that.<= /p>

 

    &= nbsp;           Regards,<= o:p>

    &= nbsp;           &nbs= p;            &= nbsp;  Greg

 <= /p>

From: L2vpn [m= ailto:l2vpn-bounces@ietf.org] On Behalf Of Sam Aldrin
Sent: Monday, March 31, 2014 7:12 PM
To: Xialiang (Frank)
Cc: l2vpn@ietf.org; Ali Sajassi (sajassi)
Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-= 02":

 

Frank,

 

Comments inline.

On Mar 31, 2014, at 7:00 PM, Xialiang (Frank) <frank.xialiang@huawei.com>= ; wrote:



Hi Samer,

Please see inline:

 

From: Samer Salam (ssalam) [mailto:ssalam@cisco.com] 
Sent: Tuesday, Apr= il 01, 2014 5:03 AM
To: Xialiang (Fran= k); Ali Sajassi (sajassi); ald= rin.ietf@gmail.com; <= /span>jd= rake@juniper.net
Cc: l2vpn@ietf.org<= br> Subject: Re: comme= nts on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

 <= /o:p>

Hi Frank,

 

Thanks for your comments. Please find responses below:

 

1. In this draft, we cite RFC 6136 as reference, and hence= we do not repeat the definition of common OAM terms (MEP, MIP, Maintenance Domain, In-band OAM, OAM layering etc.). Regarding Discov= ery, please note that E-VPN has automatic discovery built-in via the Inclus= ive Multicast Route and the Ethernet A-D Route. Hence, no further mechanism= s are required.

 

2. Per user flow means a traffic stream that maps to actua= l user data, with a specified N-tuple characteristics (MAC DA/SA, VLAN, IP DA/SA, Src/Dest Port…).  The reason why this is= different between Network & Service OAM is because the Service OAM mec= hanisms may or may not be able to support per-flow OAM, depending on the &n= bsp;service layer and its associated OAM capabilities. For instance, in the case where Ethernet CFM (IEEE 802.1ag) is the service= OAM, it is not possible to perform per-flow continuity check, as the desti= nation MAC address is set by the protocol to a multicast address.

 

3. Yes, a representative path maps to a test flow. This is= a simple function, and is actually a degenerate case of the per user-flow OAM, because test fields are specified for the N-Tuple. That= 's why it is mandatory. As to the details of the mechanism, that is left to= the solution draft – after all, this is the requirements and framewo= rk draft, it does not cover the solution details for implementation.

[Frank] : From my personal view, I don= ’t think the paragraph describing the requirement of a representative path is clear enough. For example, why can it be used for node failure det= ection but not path failure detection?

Whether one uses for node or path failure detection = is for the solution to decide. This is requirements draft. If you think bet= ter wording is required, please do propose, will consider that.

 

4. Test packets can be either unicast or multicast. The pr= oblem we are describing here is that relying on normal packet counters in unreliable given that E-VPN offers many-to-many connectivity. = For e.g., consider 3 endpoints A, B and C. Let's say we are interested in m= easuring the loss between A and C. A sends a packet to C, but it gets dropp= ed. Now B also sends to C and that packet is delivered. If we were to examine the packet counter on C, we wil= l find that the counter shows 1 packet received. But that doesn't mean that= we have 100% packet delivery rate between A and C. The packet actually cam= e from another source and hence the packet counter on C is ambiguous. Unless the implementation keeps pack= et counters per-flow (which will be expensive and impractical), it is not r= eliable to use packet counters to measure loss in a technology that support= s multipoint-to-multipoint connectivity.

[Frank] : Yes. This clarification is m= ore clear than the current content of draft~~ Also, I think “a statistical means of approximating packet loss rate” you pr= oposed in draft is not the suitable solution for this problem. Actually, th= is is more an implementation issue, i.e., we can set the same value of flow= characteristics for a test flow to ensure all test flow packets send/receive between 2 nodes exactly.

Again, this is requirement draft only. What you are = eluding to is how one should perform, which clearly falls in solution categ= ory. As Samer clarified earlier, using actual data packet counters doesn= 217;t meet the requirements, hence ‘synthetic' measurement is required. 

 

-sam

 

Regards,

Samer

 

From: "Xialiang (Frank)" <frank.xialiang@huawei.com>
Date: Tuesday, 18 = March, 2014 12:07 AM
To: Samer Salam &l= t;ssalam@c= isco.com>, "Ali Sajassi (sajassi)" <sajassi@cisco.com>, "aldrin.ietf@gmail.com" <aldrin.ietf@gmail.com>= ;, "jdrake@juniper.net" <jdr= ake@juniper.net>
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: comments = on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

 

Hi authors,

I have reviewed this important draft, and have some commen= ts as below:

1. By comparing with RFC6136 (L2VPN OAM req and frm), from= the integrity point of view, I think there are some part missing: EVPN MEP and MIP, Discovery, Data Path Forwarding, Scalability, T= ransport/Application Independence;

2. In section 3.1.1.1, what is the definition of per user = flow? Why is it different to support it between E-VPN Network OAM and E-VPN Service OAM?

3. In section 3.1.1.1, does the section of "a represe= ntative path" mean using test flow to detect the node failure? if yes, how to do? Is it a necessary requirement of proactive fault detect= ion?

4. In section 3.2.1, I do not quite understand the describ= ing reason for the inaccuracy of Loss Measurement. Do you mean that test packets of Loss Measurement are all BUM packets? Can you cl= arify why peer MEPs will receive some unnecessary packets? Why not use unic= ast packets for Loss Measurement?

 

Hoping for your feedback~~

 

B.R.

Frank

 

--_000_7347100B5761DC41A166AC17F22DF1121B78D9A1eusaamb103erics_-- From nobody Thu Apr 3 15:51:32 2014 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 552591A0337 for ; Thu, 3 Apr 2014 15:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 NnuD1F7R9-o3 for ; Thu, 3 Apr 2014 15:51:25 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2C67A1A0335 for ; Thu, 3 Apr 2014 15:51:18 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id kl14so2537767pab.4 for ; Thu, 03 Apr 2014 15:51:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=NVBjZ8V+FBRRk+NUHFnj+H8OU1zlB/MD6oJ4SDe2a6M=; b=vLkaivZwG6FJRKhYSdJJL++zxiBlG5NRiRVeDFOJzZlhLnztIkridbw1t5vE35KER8 JcwgyJzjJQWFFfmK1jrGYm6UpsWzzif1FgvMUAorW8RCDc/ZG2sITkuL2yfbHhnEp942 StMH6Tu6k9TSXE9a7w7jVJNSEOtLQEJ7UbZ178+VG23cRvp2G+dW1KZKsHuDTt6GpXfT Zp+qvAocInrV1KKTMPMbThYTYC16X9hIQslKX9fh3bz3GVMoqUkNisrggWVP7+LRT4Wb +otl3RC6CsACfL/7lIYTJf/GIh4rk5nWYTdYIVpmoQNDfbBsznnE9m1/g10aT1cJrebx r2PA== X-Received: by 10.68.237.38 with SMTP id uz6mr10739134pbc.72.1396565473886; Thu, 03 Apr 2014 15:51:13 -0700 (PDT) Received: from [10.237.97.128] (mobile-166-137-187-081.mycingular.net. [166.137.187.81]) by mx.google.com with ESMTPSA id qx11sm30983504pab.35.2014.04.03.15.51.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Apr 2014 15:51:12 -0700 (PDT) References: <8D1DD6FA-2758-4F4A-BD41-E22B59D6843E@gmail.com> <7347100B5761DC41A166AC17F22DF1121B78D9A1@eusaamb103.ericsson.se> Mime-Version: 1.0 (1.0) In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B78D9A1@eusaamb103.ericsson.se> Content-Type: multipart/alternative; boundary=Apple-Mail-82FF4227-BD5E-409C-9F64-3E598E2A5631 Content-Transfer-Encoding: 7bit Message-Id: <1DB6D64E-2254-40E8-9B68-EDE4DBB781F7@gmail.com> X-Mailer: iPhone Mail (11D167) From: Sam Aldrin Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Date: Thu, 3 Apr 2014 15:51:08 -0700 To: Gregory Mirsky Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/QYO772SeI3FjLZetTbCoqKcLidM Cc: "l2vpn@ietf.org" , "Ali Sajassi \(sajassi\)" 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, 03 Apr 2014 22:51:29 -0000 --Apple-Mail-82FF4227-BD5E-409C-9F64-3E598E2A5631 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Greg, Frank et al, Any proposal to have clear text is always welcome. So, kindly propose the te= xt on what you would like to see. Sam Sent from my iPhone > On Apr 3, 2014, at 3:24 PM, Gregory Mirsky w= rote: >=20 > Dear Sam and Frank, > even though we=E2=80=99re discussing requirements and framework of EVPN OA= M I wonder if you can give reference to OAM method that can differentiate o= r distinguish between path and node failures as implied in: > 3. Yes, a representative path maps to a test flow. This is a simple functi= on, and is actually a degenerate case of the per user-flow OAM, because test= fields are specified for the N-Tuple. That's why it is mandatory. As to the= details of the mechanism, that is left to the solution draft =E2=80=93 afte= r all, this is the requirements and framework draft, it does not cover the s= olution details for implementation. > [Frank] : =46rom my personal view, I don=E2=80=99t think the paragraph des= cribing the requirement of a representative path is clear enough. For exampl= e, why can it be used for node failure detection but not path failure detect= ion? > Whether one uses for node or path failure detection is for the solution to= decide. This is requirements draft. If you think better wording is required= , please do propose, will consider that. > =20 > Regards, > Greg > =20 > From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Sam Aldrin > Sent: Monday, March 31, 2014 7:12 PM > To: Xialiang (Frank) > Cc: l2vpn@ietf.org; Ali Sajassi (sajassi) > Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": > =20 > Frank, > =20 > Comments inline. > On Mar 31, 2014, at 7:00 PM, Xialiang (Frank) w= rote: >=20 >=20 > Hi Samer, > Please see inline: > =20 > From: Samer Salam (ssalam) [mailto:ssalam@cisco.com]=20 > Sent: Tuesday, April 01, 2014 5:03 AM > To: Xialiang (Frank); Ali Sajassi (sajassi); aldrin.ietf@gmail.com; jdrake= @juniper.net > Cc: l2vpn@ietf.org > Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": > =20 > Hi Frank, > =20 > Thanks for your comments. Please find responses below: > =20 > 1. In this draft, we cite RFC 6136 as reference, and hence we do not repea= t the definition of common OAM terms (MEP, MIP, Maintenance Domain, In-band O= AM, OAM layering etc.). Regarding Discovery, please note that E-VPN has auto= matic discovery built-in via the Inclusive Multicast Route and the Ethernet A= -D Route. Hence, no further mechanisms are required. > =20 > 2. Per user flow means a traffic stream that maps to actual user data, wit= h a specified N-tuple characteristics (MAC DA/SA, VLAN, IP DA/SA, Src/Dest P= ort=E2=80=A6). The reason why this is different between Network & Service O= AM is because the Service OAM mechanisms may or may not be able to support p= er-flow OAM, depending on the service layer and its associated OAM capabili= ties. For instance, in the case where Ethernet CFM (IEEE 802.1ag) is the ser= vice OAM, it is not possible to perform per-flow continuity check, as the de= stination MAC address is set by the protocol to a multicast address. > =20 > 3. Yes, a representative path maps to a test flow. This is a simple functi= on, and is actually a degenerate case of the per user-flow OAM, because test= fields are specified for the N-Tuple. That's why it is mandatory. As to the= details of the mechanism, that is left to the solution draft =E2=80=93 afte= r all, this is the requirements and framework draft, it does not cover the s= olution details for implementation. > [Frank] : =46rom my personal view, I don=E2=80=99t think the paragraph des= cribing the requirement of a representative path is clear enough. For exampl= e, why can it be used for node failure detection but not path failure detect= ion? > Whether one uses for node or path failure detection is for the solution to= decide. This is requirements draft. If you think better wording is required= , please do propose, will consider that. >=20 > =20 > 4. Test packets can be either unicast or multicast. The problem we are des= cribing here is that relying on normal packet counters in unreliable given t= hat E-VPN offers many-to-many connectivity. For e.g., consider 3 endpoints A= , B and C. Let's say we are interested in measuring the loss between A and C= . A sends a packet to C, but it gets dropped. Now B also sends to C and that= packet is delivered. If we were to examine the packet counter on C, we will= find that the counter shows 1 packet received. But that doesn't mean that w= e have 100% packet delivery rate between A and C. The packet actually came f= rom another source and hence the packet counter on C is ambiguous. Unless th= e implementation keeps packet counters per-flow (which will be expensive and= impractical), it is not reliable to use packet counters to measure loss in a= technology that supports multipoint-to-multipoint connectivity. > [Frank] : Yes. This clarification is more clear than the current content o= f draft~~ Also, I think =E2=80=9Ca statistical means of approximating packet= loss rate=E2=80=9D you proposed in draft is not the suitable solution for t= his problem. Actually, this is more an implementation issue, i.e., we can se= t the same value of flow characteristics for a test flow to ensure all test f= low packets send/receive between 2 nodes exactly. > Again, this is requirement draft only. What you are eluding to is how one s= hould perform, which clearly falls in solution category. As Samer clarified e= arlier, using actual data packet counters doesn=E2=80=99t meet the requireme= nts, hence =E2=80=98synthetic' measurement is required.=20 > =20 > -sam >=20 > =20 > Regards, > Samer > =20 > From: "Xialiang (Frank)" > Date: Tuesday, 18 March, 2014 12:07 AM > To: Samer Salam , "Ali Sajassi (sajassi)" , "aldrin.ietf@gmail.com" , "jdrake@juniper.net"= > Cc: "l2vpn@ietf.org" > Subject: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": > =20 > Hi authors, > I have reviewed this important draft, and have some comments as below: > 1. By comparing with RFC6136 (L2VPN OAM req and frm), from the integrity p= oint of view, I think there are some part missing: EVPN MEP and MIP, Discove= ry, Data Path Forwarding, Scalability, Transport/Application Independence; > 2. In section 3.1.1.1, what is the definition of per user flow? Why is it d= ifferent to support it between E-VPN Network OAM and E-VPN Service OAM? > 3. In section 3.1.1.1, does the section of "a representative path" mean us= ing test flow to detect the node failure? if yes, how to do? Is it a necessa= ry requirement of proactive fault detection? > 4. In section 3.2.1, I do not quite understand the describing reason for t= he inaccuracy of Loss Measurement. Do you mean that test packets of Loss Mea= surement are all BUM packets? Can you clarify why peer MEPs will receive som= e unnecessary packets? Why not use unicast packets for Loss Measurement? > =20 > Hoping for your feedback~~ > =20 > B.R. > Frank > =20 --Apple-Mail-82FF4227-BD5E-409C-9F64-3E598E2A5631 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Greg, Frank et al,

Any proposal to have clear text is always welcome. So, kindly propose t= he text on what you would like to see.

Sam

S= ent from my iPhone

On Apr 3, 2014, at 3:24 PM, Gregory Mirsky &= lt;gregory.mirsky@ericsson.co= m> wrote:

=

Dear Sam and Frank,

even though we=E2=80=99re d= iscussing requirements and framework of EVPN OAM I wonder if you can give re= ference to  OAM method that can differentiate or distinguish between path and node failures as implied in:

3. Yes, a representative path maps to a test= flow. This is a simple function, and is actually a degenerate case of the per user-flow OAM, because test fields are specified for the N-= Tuple. That's why it is mandatory. As to the details of the mechanism, that i= s left to the solution draft =E2=80=93 after all, this is the requirements a= nd framework draft, it does not cover the solution details for implementation.

<= span style=3D"font-size:10.5pt;font-family:"Calibri","sans-se= rif";color:#1F497D;mso-fareast-language:ZH-CN">[Frank] : =46rom my pers= onal view, I don=E2=80=99t think the paragraph describing the requirement of a representative path is clear enough. For example, why can it be used f= or node failure detection but not path failure detection?

Whether one uses for node or path failure detection i= s for the solution to decide. This is requirements draft. If you think bette= r wording is required, please do propose, will consider that.

=

 

    &nb= sp;           Regards,

    &nb= sp;            &= nbsp;            = ;  Greg

 

From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Sam Aldrin
Sent: Monday, March 31, 2014 7:12 PM
To: Xialiang (Frank)
Cc: l2vpn@ietf.org; Ali Sajassi= (sajassi)
Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

 

Frank,

 

Comments inline.

On Mar 31, 2014, at 7:00 PM, Xialiang (Frank) <frank.xialiang@huawei.com> w= rote:



Hi Samer,

Please see inline:

 

From:=  Samer Salam (ssalam) [mailto:ssalam@cisco.com] 
Sent: Tuesday, Apri= l 01, 2014 5:03 AM
To: Xialiang (Frank= ); Ali Sajassi (sajassi); = aldrin= .ietf@gmail.com; jdrake@= juniper.net
Cc: l2vpn@ietf.org Subject: Re: commen= ts on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

 

Hi Frank,

 

Thanks for your comments. Please find responses below:

 

1. In this draft, we cite RFC 6136 as reference, and hence we= do not repeat the definition of common OAM terms (MEP, MIP, Maintenance Domain, In-band OAM, OAM layering etc.). Regarding Discove= ry, please note that E-VPN has automatic discovery built-in via the Inclusiv= e Multicast Route and the Ethernet A-D Route. Hence, no further mechanisms a= re required.

 

2. Per user flow means a traffic stream that maps to actual u= ser data, with a specified N-tuple characteristics (MAC DA/SA, VLAN, IP DA/SA, Src/Dest Port=E2=80=A6).  The reason why this i= s different between Network & Service OAM is because the Service OAM mec= hanisms may or may not be able to support per-flow OAM, depending on the &nb= sp;service layer and its associated OAM capabilities. For instance, in the case where Ethernet CFM (IEEE 802.1ag) is the service O= AM, it is not possible to perform per-flow continuity check, as the destinat= ion MAC address is set by the protocol to a multicast address.

 

3. Yes, a representative path maps to a test flow. This is a s= imple function, and is actually a degenerate case of the per user-flow OAM, because test fields are specified for the N-Tuple. That'= s why it is mandatory. As to the details of the mechanism, that is left to t= he solution draft =E2=80=93 after all, this is the requirements and framewor= k draft, it does not cover the solution details for implementation.

[Frank] : =46rom my personal view, I don=E2= =80=99t think the paragraph describing the requirement of a representative path is clear enough. For example, why can it be used for node failure dete= ction but not path failure detection?

Whether one uses for node or path failure detection i= s for the solution to decide. This is requirements draft. If you think bette= r wording is required, please do propose, will consider that.

 

4. Test packets can be either unicast or multicast. The probl= em we are describing here is that relying on normal packet counters in unreliable given that E-VPN offers many-to-many connectivity. Fo= r e.g., consider 3 endpoints A, B and C. Let's say we are interested in meas= uring the loss between A and C. A sends a packet to C, but it gets dropped. N= ow B also sends to C and that packet is delivered. If we were to examine the packet counter on C, we will= find that the counter shows 1 packet received. But that doesn't mean that w= e have 100% packet delivery rate between A and C. The packet actually came f= rom another source and hence the packet counter on C is ambiguous. Unless the implementation keeps packe= t counters per-flow (which will be expensive and impractical), it is not rel= iable to use packet counters to measure loss in a technology that supports m= ultipoint-to-multipoint connectivity.

[Frank] : Yes. This clarification is more= clear than the current content of draft~~ Also, I think =E2=80=9Ca statistical means of approximating packet loss rate=E2=80=9D you= proposed in draft is not the suitable solution for this problem. Actually, t= his is more an implementation issue, i.e., we can set the same value of flow= characteristics for a test flow to ensure all test flow packets send/receive between 2 nodes exactly.

Again, this is requirement draft only. What you are e= luding to is how one should perform, which clearly falls in solution categor= y. As Samer clarified earlier, using actual data packet counters doesn=E2=80= =99t meet the requirements, hence =E2=80=98synthetic' measurement is required. 

 

-sam

 

Regards,

Samer

 

From: "Xialiang (Frank)" <frank.xialiang@huawei.com>
Date: Tuesday, 18 M= arch, 2014 12:07 AM
To: Samer Salam <= ;ssalam@cis= co.com>, "Ali Sajassi (sajassi)" <sajassi@cisco.com>, "aldr= in.ietf@gmail.com" <<= span style=3D"color:purple">aldrin.ietf@gmail.com>, "jdrake@juniper.net<= /span>" <jdra= ke@juniper.net>
Cc: "l2vpn@ietf.org" &= lt;l2vpn@ietf= .org>
Subject: comments o= n "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

 

Hi authors,

I have reviewed this important draft, and have some comments a= s below:

1. By comparing with RFC6136 (L2VPN OAM req and frm), from th= e integrity point of view, I think there are some part missing: EVPN MEP and MIP, Discovery, Data Path Forwarding, Scalability, Tr= ansport/Application Independence;

2. In section 3.1.1.1, what is the definition of per user flo= w? Why is it different to support it between E-VPN Network OAM and E-VPN Service OAM?

3. In section 3.1.1.1, does the section of "a representative p= ath" mean using test flow to detect the node failure? if yes, how to do? Is it a necessary requirement of proactive fault detecti= on?

4. In section 3.2.1, I do not quite understand the describing= reason for the inaccuracy of Loss Measurement. Do you mean that test packets of Loss Measurement are all BUM packets? Can you cla= rify why peer MEPs will receive some unnecessary packets? Why not use unicas= t packets for Loss Measurement?

 

Hoping for your feedback~~

 

B.R.

Frank

 

= --Apple-Mail-82FF4227-BD5E-409C-9F64-3E598E2A5631-- From nobody Thu Apr 3 16:28:00 2014 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 538F81A0233 for ; Thu, 3 Apr 2014 16:27:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.51 X-Spam-Level: X-Spam-Status: No, score=-9.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 luf6APhR_h87 for ; Thu, 3 Apr 2014 16:27:53 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id C8D771A02A0 for ; Thu, 3 Apr 2014 16:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1474; q=dns/txt; s=iport; t=1396567669; x=1397777269; h=from:to:cc:subject:date:message-id:mime-version; bh=U3gyO5DgY5WI5Zs4FBknIC0fsfpDP7i2O0IV/nPq94o=; b=kLndC1i8rtdhp/yPXU4hhuqaFZnARF2qwCKAsbpFM8Y2tKvITBA44SA4 EJgE9RQRsgcjPm6o4LHMbCpBVnjMWbAoXMf8IFZEu94G/w7njDqJAqtGN nUI8zjzzBprFKKB6g2kWGGJ3q4aCvPbLxTwrqhj6r/7NIWm1Ahzi5Ybih Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkoFAJLtPVOtJA2N/2dsb2JhbABXgkIjIYESwmGBHoEbFnSCHBB5EgELAXQnBA6HfgHPVReOcYQ/BJhbkj6DMIIr X-IronPort-AV: E=Sophos; i="4.97,791,1389744000"; d="scan'208,217"; a="32726862" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-1.cisco.com with ESMTP; 03 Apr 2014 23:27:49 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s33NRnUU008342 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 3 Apr 2014 23:27:49 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Thu, 3 Apr 2014 18:27:49 -0500 From: "Ali Sajassi (sajassi)" To: "l2vpn-chairs@tools.ietf.org" Subject: Request for WG LC of draft-ietf-l2vpn-pbb-evpn-06 Thread-Topic: Request for WG LC of draft-ietf-l2vpn-pbb-evpn-06 Thread-Index: AQHPT5RSz9VHAJ6wzkSrpQQFZ2vhcg== Date: Thu, 3 Apr 2014 23:27:47 +0000 Message-ID: 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.154.213.171] Content-Type: multipart/alternative; boundary="_000_CF633C82CB23Esajassiciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/Plvn7Whr5sQDlPjQ2tg7o-K9jnM Cc: "l2vpn@ietf.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: Thu, 03 Apr 2014 23:27:58 -0000 --_000_CF633C82CB23Esajassiciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Giles, Nabil: Just like its sibling evpn draft, this pbb-evpn draft has been around for o= ver two years and has gone through several revisions to incorporate WG comm= ents. The authors of this draft believe that this draft is ready for the WG= LC and thus would like to request the chairs to initiate the WG LC for it. Regards, Ali --_000_CF633C82CB23Esajassiciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <28D34C531769C44F89253AB9A5F1EB43@emea.cisco.com> Content-Transfer-Encoding: quoted-printable

Hi Giles, Nabil:

Just like its sibling evpn draft, this pbb-evpn draft has been around = for over two years and has gone through several revisions to incorporate WG= comments. The authors of this draft believe that this draft is ready for t= he WG LC and thus would like to request the chairs to initiate the WG LC for it.

Regards,
Ali
--_000_CF633C82CB23Esajassiciscocom_-- From nobody Thu Apr 3 17:01:58 2014 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 755CC1A03EC for ; Thu, 3 Apr 2014 17:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.51 X-Spam-Level: X-Spam-Status: No, score=-9.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 mUjRg3SRILi1 for ; Thu, 3 Apr 2014 17:01:53 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 746CC1A03E6 for ; Thu, 3 Apr 2014 17:01:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30849; q=dns/txt; s=iport; t=1396569707; x=1397779307; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=7cgBzbUFwig4/AqL2+oFq7v8FK827I342LYyuvoOJBg=; b=dMBqpz2v/K5nk7jnStSvyK8SsVV0tWqYMeX+JXGj9FcWaCqM3lq+VL4N 1v6b9aaMFeT3Cbv9hcILYQnRpCROw80JTWNHiNJflgL/9Ytm1W/TSDHYC R3oa48I+4DZngYLyF/vFXdkiPqF/XUAszq1hWTQvYfUXvRr+TtKeVqlvo s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkwFAJr1PVOtJA2M/2dsb2JhbABXgkIjITtXw3+BHBZ0giUBAQEELUwSAQgRAwEBASEBBigRFAkIAQEEAQ0FG4dKAxEByCMNhyIXjFeBOBEBPxEGAYQ4BJZugW2Mb4VPgzCBcjk X-IronPort-AV: E=Sophos; i="4.97,791,1389744000"; d="scan'208,217"; a="32736222" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP; 04 Apr 2014 00:01:46 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s3401kqc018997 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 4 Apr 2014 00:01:46 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Thu, 3 Apr 2014 19:01:46 -0500 From: "Samer Salam (ssalam)" To: "Xialiang (Frank)" , "Ali Sajassi (sajassi)" , "aldrin.ietf@gmail.com" , "jdrake@juniper.net" Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Thread-Topic: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Thread-Index: Ac9CeLdIKfj9gmHqQoGb/BpQJYep2gKmytoAAA23woAAW6pZgAAM+0XAACa9KAA= Date: Fri, 4 Apr 2014 00:01:45 +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.2.130206 x-originating-ip: [161.44.210.106] Content-Type: multipart/alternative; boundary="_000_CF634457280D9ssalamciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/awuGMErIati9kPOPR1iuLR9soAU Cc: "l2vpn@ietf.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: Fri, 04 Apr 2014 00:01:57 -0000 --_000_CF634457280D9ssalamciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Frank, We will add text to clarify in the next revision. Thank you for your commen= ts! Regards, Samer From: "Xialiang (Frank)" > Date: Wednesday, 2 April, 2014 8:41 PM To: Samer Salam >, "Ali Sajassi (= sajassi)" >, "aldrin.ietf@gmail= .com" >, "jdrake@juniper.net" > Cc: "l2vpn@ietf.org" > Subject: RE: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Hi Samer, My suggestions are in line: From: Samer Salam (ssalam) [mailto:ssalam@cisco.com] Sent: Thursday, April 03, 2014 7:21 AM To: Xialiang (Frank); Ali Sajassi (sajassi); aldrin.ietf@gmail.com; jdrake@juniper.net Cc: l2vpn@ietf.org Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Hi Frank, Please find my responses inline after yours=85 From: "Xialiang (Frank)" > Date: Monday, 31 March, 2014 7:00 PM To: Samer Salam >, "Ali Sajassi (= sajassi)" >, "aldrin.ietf@gmail= .com" >, "jdrake@juniper.net" > Cc: "l2vpn@ietf.org" > Subject: RE: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Hi Samer, Please see inline: From: Samer Salam (ssalam) [mailto:ssalam@cisco.com] Sent: Tuesday, April 01, 2014 5:03 AM To: Xialiang (Frank); Ali Sajassi (sajassi); aldrin.ietf@gmail.com; jdrake@juniper.net Cc: l2vpn@ietf.org Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Hi Frank, Thanks for your comments. Please find responses below: 1. In this draft, we cite RFC 6136 as reference, and hence we do not repeat= the definition of common OAM terms (MEP, MIP, Maintenance Domain, In-band = OAM, OAM layering etc.). Regarding Discovery, please note that E-VPN has au= tomatic discovery built-in via the Inclusive Multicast Route and the Ethern= et A-D Route. Hence, no further mechanisms are required. 2. Per user flow means a traffic stream that maps to actual user data, with= a specified N-tuple characteristics (MAC DA/SA, VLAN, IP DA/SA, Src/Dest P= ort=85). The reason why this is different between Network & Service OAM is= because the Service OAM mechanisms may or may not be able to support per-f= low OAM, depending on the service layer and its associated OAM capabilitie= s. For instance, in the case where Ethernet CFM (IEEE 802.1ag) is the servi= ce OAM, it is not possible to perform per-flow continuity check, as the des= tination MAC address is set by the protocol to a multicast address. 3. Yes, a representative path maps to a test flow. This is a simple functio= n, and is actually a degenerate case of the per user-flow OAM, because test= fields are specified for the N-Tuple. That's why it is mandatory. As to th= e details of the mechanism, that is left to the solution draft =96 after al= l, this is the requirements and framework draft, it does not cover the solu= tion details for implementation. [Frank] : From my personal view, I don=92t think the paragraph describing t= he requirement of a representative path is clear enough. For example, why c= an it be used for node failure detection but not path failure detection? It can be used for failure detection of that "representative" path, but the= point is that this lacks real practical benefit to the network operator: t= he path may have been chosen arbitrarily by an OAM solution that constructs= test flows using random or pseudo-random entropy generators. Hence, the fo= cus is on what practical information could the network operator glean from = this mode of operation, and the answer is: node failure detection. We can u= pdate the text to expand on this point. [Frank] :I suggests you give a clear clarification of the difference betwee= n node failure and path failure in this condition by your updates. I think = sam=92s response in previous email is a good reference. 4. Test packets can be either unicast or multicast. The problem we are desc= ribing here is that relying on normal packet counters in unreliable given t= hat E-VPN offers many-to-many connectivity. For e.g., consider 3 endpoints = A, B and C. Let's say we are interested in measuring the loss between A and= C. A sends a packet to C, but it gets dropped. Now B also sends to C and t= hat packet is delivered. If we were to examine the packet counter on C, we = will find that the counter shows 1 packet received. But that doesn't mean t= hat we have 100% packet delivery rate between A and C. The packet actually = came from another source and hence the packet counter on C is ambiguous. Un= less the implementation keeps packet counters per-flow (which will be expen= sive and impractical), it is not reliable to use packet counters to measure= loss in a technology that supports multipoint-to-multipoint connectivity. [Frank] : Yes. This clarification is more clear than the current content of= draft~~ Also, I think =93a statistical means of approximating packet loss = rate=94 you proposed in draft is not the suitable solution for this problem= . This is not a new problem. ITU-T Y.1731 and the Metro Ethernet Forum have t= ackled this very same problem in the recent past, and the approach converge= d on statistical approximation. [Frank] :OK! Actually, this is more an implementation issue, i.e., we can set the same v= alue of flow characteristics for a test flow to ensure all test flow packet= s send/receive between 2 nodes exactly. The draft is not precluding other solutions. It is simply stating that a so= lution based on synthetic measurement is required. There is no statement th= at this shall be the only option offered. [Frank] : OK! Regards, Samer Regards, Samer From: "Xialiang (Frank)" > Date: Tuesday, 18 March, 2014 12:07 AM To: Samer Salam >, "Ali Sajassi (= sajassi)" >, "aldrin.ietf@gmail= .com" >, "jdrake@juniper.net" > Cc: "l2vpn@ietf.org" > Subject: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Hi authors, I have reviewed this important draft, and have some comments as below: 1. By comparing with RFC6136 (L2VPN OAM req and frm), from the integrity po= int of view, I think there are some part missing: EVPN MEP and MIP, Discove= ry, Data Path Forwarding, Scalability, Transport/Application Independence; 2. In section 3.1.1.1, what is the definition of per user flow? Why is it d= ifferent to support it between E-VPN Network OAM and E-VPN Service OAM? 3. In section 3.1.1.1, does the section of "a representative path" mean usi= ng test flow to detect the node failure? if yes, how to do? Is it a necessa= ry requirement of proactive fault detection? 4. In section 3.2.1, I do not quite understand the describing reason for th= e inaccuracy of Loss Measurement. Do you mean that test packets of Loss Mea= surement are all BUM packets? Can you clarify why peer MEPs will receive so= me unnecessary packets? Why not use unicast packets for Loss Measurement? Hoping for your feedback~~ B.R. Frank --_000_CF634457280D9ssalamciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <44FBB1D23016AA4697CD0F0BD7FFBDB6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Frank,

We will add text to clarify in the next revision. Thank you for your c= omments!

Regards,
Samer

From: "Xialiang (Frank)" = <frank.xialiang@huawei.com<= /a>>
Date: Wednesday, 2 April, 2014 8:41= PM
To: Samer Salam <ssalam@cisco.com>, "Ali Sajassi (sajassi)&= quot; <sajassi@cisco.com>, &= quot;aldrin.ietf@gmail.com&quo= t; <aldrin.ietf@gmail.com>= , "jdrake@juniper.net" = <jdrake@juniper.net>
Cc: "l2vpn@ietf.org" <l2v= pn@ietf.org>
Subject: RE: comments on "draf= t-salam-l2vpn-evpn-oam-req-frmwk-02":

Hi Same= r,

My sugg= estions are in line:

&n= bsp;

F= rom: Samer Salam (ssalam) [mailto:ssalam@cisco.com]
Sent: Thursday, April 03, 2014 7:21 AM
To: Xialiang (Frank); Ali Sajassi (sajassi); aldrin.ietf@gmail.com; jdrake@jun= iper.net
Cc: l2vpn@ietf.org
Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-= 02":

 

Hi Frank,=

&nbs= p;

Please fi= nd my responses inline after yours=85

&nbs= p;

From: &quo= t;Xialiang (Frank)" <f= rank.xialiang@huawei.com>
Date: Monday, 31 March, 2014 7:00 PM
To: Samer Salam <ssalam@cisco= .com>, "Ali Sajassi (sajassi)" <sajassi@cisco.com>, "aldrin.ietf@gmail.com" <aldrin.ietf@gmail.com>, "jdrake@juniper.net" &= lt;jdrake@juniper.net>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>
Subject: RE: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-= 02":

&nbs= p;

Hi Same= r,

Please = see inline:

 <= /span>

From: Samer Salam (ssalam) [mailto:ssalam@ci= sco.com]
Sent: Tuesday, April 01, 2014 5:03 AM
To: Xialiang (Frank); Ali Sajassi (sajassi); aldrin.ietf@gmail.com; jdrake@jun= iper.net
Cc: l2vpn@ietf.org
Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-= 02":

 

Hi Frank,=

 

Thanks fo= r your comments. Please find responses below:

 

1. In thi= s draft, we cite RFC 6136 as reference, and hence we do not repeat the defi= nition of common OAM terms (MEP, MIP, Maintenance Domain, In-band OAM, OAM = layering etc.). Regarding Discovery, please note that E-VPN has automatic discovery built-in via the Inclusive Multica= st Route and the Ethernet A-D Route. Hence, no further mechanisms are requi= red.

 

2. Per us= er flow means a traffic stream that maps to actual user data, with a specif= ied N-tuple characteristics (MAC DA/SA, VLAN, IP DA/SA, Src/Dest Port=85). =  The reason why this is different between Network & Service OAM is because the Service OAM mechanisms may or may= not be able to support per-flow OAM, depending on the  service layer = and its associated OAM capabilities. For instance, in the case where Ethern= et CFM (IEEE 802.1ag) is the service OAM, it is not possible to perform per-flow continuity check, as the destinatio= n MAC address is set by the protocol to a multicast address.

 

3. Yes, a= representative path maps to a test flow. This is a simple function, and is= actually a degenerate case of the per user-flow OAM, because test fields a= re specified for the N-Tuple. That's why it is mandatory. As to the details of the mechanism, that is left to the s= olution draft =96 after all, this is the requirements and framework draft, = it does not cover the solution details for implementation.

[= Frank] : From my personal view, I don=92t think the paragraph describing th= e requirement of a representative path is clear enough. For example, why ca= n it be used for node failure detection but not path failure detection?

 

It can be used for failure detection of th= at "representative" path, but the point is that this lacks real p= ractical benefit to the network operator: the path may have been chosen arbitrarily by an OAM solution that constructs test flows= using random or pseudo-random entropy generators. Hence, the focus is on w= hat practical information could the network operator glean from this mode o= f operation, and the answer is: node failure detection. We can update the text to expand on this point.

[Frank] :I suggests you give a clea= r clarification of the difference between node failure and path failure in = this condition by your updates. I think sam=92s response in previous email is a good reference.

 

 

4. Test p= ackets can be either unicast or multicast. The problem we are describing he= re is that relying on normal packet counters in unreliable given that E-VPN= offers many-to-many connectivity. For e.g., consider 3 endpoints A, B and C. Let's say we are interested in meas= uring the loss between A and C. A sends a packet to C, but it gets dropped.= Now B also sends to C and that packet is delivered. If we were to examine = the packet counter on C, we will find that the counter shows 1 packet received. But that doesn't mean that = we have 100% packet delivery rate between A and C. The packet actually came= from another source and hence the packet counter on C is ambiguous. Unless= the implementation keeps packet counters per-flow (which will be expensive and impractical), it is not rel= iable to use packet counters to measure loss in a technology that supports = multipoint-to-multipoint connectivity.

[= Frank] : Yes. This clarification is more clear than the current content of = draft~~ Also, I think =93a statistical means of approximating packet loss r= ate=94 you proposed in draft is not the suitable solution for this problem.

 

This is not a new problem. ITU-T Y.1731 an= d the Metro Ethernet Forum have tackled this very same problem in the recen= t past, and the approach converged on statistical approximation. 

[Frank] :OK!

 

A= ctually, this is more an implementation issue, i.e., we can set the same va= lue of flow characteristics for a test flow to ensure all test flow packets= send/receive between 2 nodes exactly.

 

 

The draft is not precluding other solution= s. It is simply stating that a solution based on synthetic measurement is r= equired. There is no statement that this shall be the only option offered.

[Frank] : OK!

 

Regards,

Samer

 

Regards,<= o:p>

Samer

 

From: &quo= t;Xialiang (Frank)" <f= rank.xialiang@huawei.com>
Date: Tuesday, 18 March, 2014 12:07 AM
To: Samer Salam <ssalam@cisco= .com>, "Ali Sajassi (sajassi)" <sajassi@cisco.com>, "aldrin.ietf@gmail.com" <aldrin.ietf@gmail.com>, "jdrake@juniper.net" &= lt;jdrake@juniper.net>
Cc: "l2vpn@ietf.org"= <l2vpn@ietf.org>
Subject: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02&q= uot;:

 

Hi author= s,

I have re= viewed this important draft, and have some comments as below:

1. By com= paring with RFC6136 (L2VPN OAM req and frm), from the integrity point of vi= ew, I think there are some part missing: EVPN MEP and MIP, Discovery, Data = Path Forwarding, Scalability, Transport/Application Independence;

2. In sec= tion 3.1.1.1, what is the definition of per user flow? Why is it different = to support it between E-VPN Network OAM and E-VPN Service OAM?

3. In sec= tion 3.1.1.1, does the section of "a representative path" mean us= ing test flow to detect the node failure? if yes, how to do? Is it a necess= ary requirement of proactive fault detection?

4. In sec= tion 3.2.1, I do not quite understand the describing reason for the inaccur= acy of Loss Measurement. Do you mean that test packets of Loss Measurement = are all BUM packets? Can you clarify why peer MEPs will receive some unnecessary packets? Why not use unicast packe= ts for Loss Measurement?

 

Hoping fo= r your feedback~~

 

B.R.=

Frank

 --_000_CF634457280D9ssalamciscocom_-- From nobody Thu Apr 3 18:27:05 2014 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 8975E1A0430 for ; Thu, 3 Apr 2014 18:27:02 -0700 (PDT) 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 9JDOw7tDmGuB for ; Thu, 3 Apr 2014 18:26:58 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id B3DE41A042F for ; Thu, 3 Apr 2014 18:26:57 -0700 (PDT) X-AuditID: c6180641-b7f768e000001855-79-533e07742bc3 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 9A.9F.06229.4770E335; Fri, 4 Apr 2014 03:14:29 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.03.0174.001; Thu, 3 Apr 2014 21:26:51 -0400 From: Gregory Mirsky To: Sam Aldrin Subject: RE: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Thread-Topic: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Thread-Index: Ac9CeLdIKfj9gmHqQoGb/BpQJYep2gKmytoAAA23woAACZ34gACGY9WAAAl8aQAAAybP0A== Date: Fri, 4 Apr 2014 01:26:50 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B78DB2A@eusaamb103.ericsson.se> References: <8D1DD6FA-2758-4F4A-BD41-E22B59D6843E@gmail.com> <7347100B5761DC41A166AC17F22DF1121B78D9A1@eusaamb103.ericsson.se> <1DB6D64E-2254-40E8-9B68-EDE4DBB781F7@gmail.com> In-Reply-To: <1DB6D64E-2254-40E8-9B68-EDE4DBB781F7@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B78DB2Aeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXRPrG4pu12wQf8EJosJrV8YLf50HWC2 ePztELvFu7PNLA4sHlN+b2T12DnrLrtHy5G3rB5LlvxkCmCJ4rJJSc3JLEst0rdL4MpoX7+S peDRLaaKhj1TWBoY71xk6mLk5JAQMJHYcOQCM4QtJnHh3nq2LkYuDiGBo4wSHe//QDnLGCVW HzvKAlLFJmAk8WJjDzuILSKgJjF53k1mkCJmgRZGiXmr9oEVCQs4S5yeOJkRoshFYsP1t0wQ dpjE4a9HweIsAioSa9pmgK3mFfCVuLFyFTPEtvdMEntapoNt4BSwlWjf8YYVxGYEuu/7qTVg g5gFxCVuPZkP9YOAxJI956F+EJV4+fgfK4StKLGvH2QOB1B9vsTEe1IQuwQlTs58wjKBUXQW kkmzEKpmIamCCGtKrN+lD1GtKDGl+yE7hK0h0TpnLjuy+AJG9lWMHKXFqWW56UaGmxiBEXhM gs1xB+OCT5aHGKU5WJTEeb+8dQ4SEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwMimr8EhuUPO ZdtGTuMMiwlVJ1OuyB/h//6TbcHeBytXPSi5IfVra0Run8WUiT940lJlH2VKT5dcc/x25gyz HNX0YycfXXd4Zau5nnehcPKStju/AjxuJQeeXVq791/09swDa/Yp75ix6FiwZB4PS/ejm/yr p6nZfRHl5VLeUPTgl5GXd/i52IdKLMUZiYZazEXFiQBhUDgyjgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/sqpMKgdacH7mRPezxYrmy3f9EZ0 Cc: "l2vpn@ietf.org" , "Ali Sajassi \(sajassi\)" 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: Fri, 04 Apr 2014 01:27:02 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B78DB2Aeusaamb103erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2FtLCBldC4gYWwsDQpJIG9ubHkgbm90ZWQgdGhhdCBJIGRvbuKAmXQgYmVsaWV2ZSB0aGF0 IGl0IGlzIHBvc3NpYmxlIHRvIGRpc3Rpbmd1aXNoIGJldHdlZW4gcGF0aCBmYWlsdXJlIGFuZCBm YWlsdXJlIG9mIGEgbm9kZSBhbG9uZyB0aGF0IHBhdGggd2l0aG91dCB2ZXJ5IHNvcGhpc3RpY2F0 ZWQgZmF1bHQgY29ycmVsYXRpb24gaGV1cmlzdGljcyB1c3VhbGx5IGFzc29jaWF0ZWQgd2l0aCB0 aGUgTk1TLg0KV2l0aCBzbyBleHRlbnNpdmUgYW5kIGludGVyZXN0aW5nIGRpc2N1c3Npb24gaXQg aXMgYml0IGhhcmQgdG8gdW5kZXJzdGFuZCBjdXJyZW50IHN0YXRlIG9mIHRoZSBkb2N1bWVudCBh bmQgc3VnZ2VzdCBhbnkgc3BlY2lmaWMgdGV4dC4gSeKAmW0gbG9va2luZyBmb3J3YXJkIGZvciB0 aGUgdmVyc2lvbiB0aGF0IGluY29ycG9yYXRlcyB0aGlzIHJvdW5kIG9mIGRpc2N1c3Npb24uDQoN CiAgICAgICAgICAgICAgICBSZWdhcmRzLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBHcmVnDQoNCkZyb206IFNhbSBBbGRyaW4gW21haWx0bzphbGRyaW4uaWV0ZkBnbWFpbC5jb21d DQpTZW50OiBUaHVyc2RheSwgQXByaWwgMDMsIDIwMTQgMzo1MSBQTQ0KVG86IEdyZWdvcnkgTWly c2t5DQpDYzogWGlhbGlhbmcgKEZyYW5rKTsgbDJ2cG5AaWV0Zi5vcmc7IEFsaSBTYWphc3NpIChz YWphc3NpKQ0KU3ViamVjdDogUmU6IGNvbW1lbnRzIG9uICJkcmFmdC1zYWxhbS1sMnZwbi1ldnBu LW9hbS1yZXEtZnJtd2stMDIiOg0KDQpHcmVnLCBGcmFuayBldCBhbCwNCg0KQW55IHByb3Bvc2Fs IHRvIGhhdmUgY2xlYXIgdGV4dCBpcyBhbHdheXMgd2VsY29tZS4gU28sIGtpbmRseSBwcm9wb3Nl IHRoZSB0ZXh0IG9uIHdoYXQgeW91IHdvdWxkIGxpa2UgdG8gc2VlLg0KDQpTYW0NCg0KU2VudCBm cm9tIG15IGlQaG9uZQ0KDQpPbiBBcHIgMywgMjAxNCwgYXQgMzoyNCBQTSwgR3JlZ29yeSBNaXJz a3kgPGdyZWdvcnkubWlyc2t5QGVyaWNzc29uLmNvbTxtYWlsdG86Z3JlZ29yeS5taXJza3lAZXJp Y3Nzb24uY29tPj4gd3JvdGU6DQpEZWFyIFNhbSBhbmQgRnJhbmssDQpldmVuIHRob3VnaCB3ZeKA mXJlIGRpc2N1c3NpbmcgcmVxdWlyZW1lbnRzIGFuZCBmcmFtZXdvcmsgb2YgRVZQTiBPQU0gSSB3 b25kZXIgaWYgeW91IGNhbiBnaXZlIHJlZmVyZW5jZSB0byAgT0FNIG1ldGhvZCB0aGF0IGNhbiBk aWZmZXJlbnRpYXRlIG9yIGRpc3Rpbmd1aXNoIGJldHdlZW4gcGF0aCBhbmQgbm9kZSBmYWlsdXJl cyBhcyBpbXBsaWVkIGluOg0KMy4gWWVzLCBhIHJlcHJlc2VudGF0aXZlIHBhdGggbWFwcyB0byBh IHRlc3QgZmxvdy4gVGhpcyBpcyBhIHNpbXBsZSBmdW5jdGlvbiwgYW5kIGlzIGFjdHVhbGx5IGEg ZGVnZW5lcmF0ZSBjYXNlIG9mIHRoZSBwZXIgdXNlci1mbG93IE9BTSwgYmVjYXVzZSB0ZXN0IGZp ZWxkcyBhcmUgc3BlY2lmaWVkIGZvciB0aGUgTi1UdXBsZS4gVGhhdCdzIHdoeSBpdCBpcyBtYW5k YXRvcnkuIEFzIHRvIHRoZSBkZXRhaWxzIG9mIHRoZSBtZWNoYW5pc20sIHRoYXQgaXMgbGVmdCB0 byB0aGUgc29sdXRpb24gZHJhZnQg4oCTIGFmdGVyIGFsbCwgdGhpcyBpcyB0aGUgcmVxdWlyZW1l bnRzIGFuZCBmcmFtZXdvcmsgZHJhZnQsIGl0IGRvZXMgbm90IGNvdmVyIHRoZSBzb2x1dGlvbiBk ZXRhaWxzIGZvciBpbXBsZW1lbnRhdGlvbi4NCltGcmFua10gOiBGcm9tIG15IHBlcnNvbmFsIHZp ZXcsIEkgZG9u4oCZdCB0aGluayB0aGUgcGFyYWdyYXBoIGRlc2NyaWJpbmcgdGhlIHJlcXVpcmVt ZW50IG9mIGEgcmVwcmVzZW50YXRpdmUgcGF0aCBpcyBjbGVhciBlbm91Z2guIEZvciBleGFtcGxl LCB3aHkgY2FuIGl0IGJlIHVzZWQgZm9yIG5vZGUgZmFpbHVyZSBkZXRlY3Rpb24gYnV0IG5vdCBw YXRoIGZhaWx1cmUgZGV0ZWN0aW9uPw0KV2hldGhlciBvbmUgdXNlcyBmb3Igbm9kZSBvciBwYXRo IGZhaWx1cmUgZGV0ZWN0aW9uIGlzIGZvciB0aGUgc29sdXRpb24gdG8gZGVjaWRlLiBUaGlzIGlz IHJlcXVpcmVtZW50cyBkcmFmdC4gSWYgeW91IHRoaW5rIGJldHRlciB3b3JkaW5nIGlzIHJlcXVp cmVkLCBwbGVhc2UgZG8gcHJvcG9zZSwgd2lsbCBjb25zaWRlciB0aGF0Lg0KDQogICAgICAgICAg ICAgICAgUmVnYXJkcywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgR3JlZw0KDQpG cm9tOiBMMnZwbiBbbWFpbHRvOmwydnBuLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBT YW0gQWxkcmluDQpTZW50OiBNb25kYXksIE1hcmNoIDMxLCAyMDE0IDc6MTIgUE0NClRvOiBYaWFs aWFuZyAoRnJhbmspDQpDYzogbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPjsg QWxpIFNhamFzc2kgKHNhamFzc2kpDQpTdWJqZWN0OiBSZTogY29tbWVudHMgb24gImRyYWZ0LXNh bGFtLWwydnBuLWV2cG4tb2FtLXJlcS1mcm13ay0wMiI6DQoNCkZyYW5rLA0KDQpDb21tZW50cyBp bmxpbmUuDQpPbiBNYXIgMzEsIDIwMTQsIGF0IDc6MDAgUE0sIFhpYWxpYW5nIChGcmFuaykgPGZy YW5rLnhpYWxpYW5nQGh1YXdlaS5jb208bWFpbHRvOmZyYW5rLnhpYWxpYW5nQGh1YXdlaS5jb20+ PiB3cm90ZToNCg0KDQoNCkhpIFNhbWVyLA0KUGxlYXNlIHNlZSBpbmxpbmU6DQoNCkZyb206IFNh bWVyIFNhbGFtIChzc2FsYW0pIFttYWlsdG86c3NhbGFtQGNpc2NvLmNvbV0NClNlbnQ6IFR1ZXNk YXksIEFwcmlsIDAxLCAyMDE0IDU6MDMgQU0NClRvOiBYaWFsaWFuZyAoRnJhbmspOyBBbGkgU2Fq YXNzaSAoc2FqYXNzaSk7IGFsZHJpbi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86YWxkcmluLmlldGZA Z21haWwuY29tPjsgamRyYWtlQGp1bmlwZXIubmV0PG1haWx0bzpqZHJha2VAanVuaXBlci5uZXQ+ DQpDYzogbDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPg0KU3ViamVjdDogUmU6 IGNvbW1lbnRzIG9uICJkcmFmdC1zYWxhbS1sMnZwbi1ldnBuLW9hbS1yZXEtZnJtd2stMDIiOg0K DQpIaSBGcmFuaywNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBQbGVhc2UgZmluZCByZXNw b25zZXMgYmVsb3c6DQoNCjEuIEluIHRoaXMgZHJhZnQsIHdlIGNpdGUgUkZDIDYxMzYgYXMgcmVm ZXJlbmNlLCBhbmQgaGVuY2Ugd2UgZG8gbm90IHJlcGVhdCB0aGUgZGVmaW5pdGlvbiBvZiBjb21t b24gT0FNIHRlcm1zIChNRVAsIE1JUCwgTWFpbnRlbmFuY2UgRG9tYWluLCBJbi1iYW5kIE9BTSwg T0FNIGxheWVyaW5nIGV0Yy4pLiBSZWdhcmRpbmcgRGlzY292ZXJ5LCBwbGVhc2Ugbm90ZSB0aGF0 IEUtVlBOIGhhcyBhdXRvbWF0aWMgZGlzY292ZXJ5IGJ1aWx0LWluIHZpYSB0aGUgSW5jbHVzaXZl IE11bHRpY2FzdCBSb3V0ZSBhbmQgdGhlIEV0aGVybmV0IEEtRCBSb3V0ZS4gSGVuY2UsIG5vIGZ1 cnRoZXIgbWVjaGFuaXNtcyBhcmUgcmVxdWlyZWQuDQoNCjIuIFBlciB1c2VyIGZsb3cgbWVhbnMg YSB0cmFmZmljIHN0cmVhbSB0aGF0IG1hcHMgdG8gYWN0dWFsIHVzZXIgZGF0YSwgd2l0aCBhIHNw ZWNpZmllZCBOLXR1cGxlIGNoYXJhY3RlcmlzdGljcyAoTUFDIERBL1NBLCBWTEFOLCBJUCBEQS9T QSwgU3JjL0Rlc3QgUG9ydOKApikuICBUaGUgcmVhc29uIHdoeSB0aGlzIGlzIGRpZmZlcmVudCBi ZXR3ZWVuIE5ldHdvcmsgJiBTZXJ2aWNlIE9BTSBpcyBiZWNhdXNlIHRoZSBTZXJ2aWNlIE9BTSBt ZWNoYW5pc21zIG1heSBvciBtYXkgbm90IGJlIGFibGUgdG8gc3VwcG9ydCBwZXItZmxvdyBPQU0s IGRlcGVuZGluZyBvbiB0aGUgIHNlcnZpY2UgbGF5ZXIgYW5kIGl0cyBhc3NvY2lhdGVkIE9BTSBj YXBhYmlsaXRpZXMuIEZvciBpbnN0YW5jZSwgaW4gdGhlIGNhc2Ugd2hlcmUgRXRoZXJuZXQgQ0ZN IChJRUVFIDgwMi4xYWcpIGlzIHRoZSBzZXJ2aWNlIE9BTSwgaXQgaXMgbm90IHBvc3NpYmxlIHRv IHBlcmZvcm0gcGVyLWZsb3cgY29udGludWl0eSBjaGVjaywgYXMgdGhlIGRlc3RpbmF0aW9uIE1B QyBhZGRyZXNzIGlzIHNldCBieSB0aGUgcHJvdG9jb2wgdG8gYSBtdWx0aWNhc3QgYWRkcmVzcy4N Cg0KMy4gWWVzLCBhIHJlcHJlc2VudGF0aXZlIHBhdGggbWFwcyB0byBhIHRlc3QgZmxvdy4gVGhp cyBpcyBhIHNpbXBsZSBmdW5jdGlvbiwgYW5kIGlzIGFjdHVhbGx5IGEgZGVnZW5lcmF0ZSBjYXNl IG9mIHRoZSBwZXIgdXNlci1mbG93IE9BTSwgYmVjYXVzZSB0ZXN0IGZpZWxkcyBhcmUgc3BlY2lm aWVkIGZvciB0aGUgTi1UdXBsZS4gVGhhdCdzIHdoeSBpdCBpcyBtYW5kYXRvcnkuIEFzIHRvIHRo ZSBkZXRhaWxzIG9mIHRoZSBtZWNoYW5pc20sIHRoYXQgaXMgbGVmdCB0byB0aGUgc29sdXRpb24g ZHJhZnQg4oCTIGFmdGVyIGFsbCwgdGhpcyBpcyB0aGUgcmVxdWlyZW1lbnRzIGFuZCBmcmFtZXdv cmsgZHJhZnQsIGl0IGRvZXMgbm90IGNvdmVyIHRoZSBzb2x1dGlvbiBkZXRhaWxzIGZvciBpbXBs ZW1lbnRhdGlvbi4NCltGcmFua10gOiBGcm9tIG15IHBlcnNvbmFsIHZpZXcsIEkgZG9u4oCZdCB0 aGluayB0aGUgcGFyYWdyYXBoIGRlc2NyaWJpbmcgdGhlIHJlcXVpcmVtZW50IG9mIGEgcmVwcmVz ZW50YXRpdmUgcGF0aCBpcyBjbGVhciBlbm91Z2guIEZvciBleGFtcGxlLCB3aHkgY2FuIGl0IGJl IHVzZWQgZm9yIG5vZGUgZmFpbHVyZSBkZXRlY3Rpb24gYnV0IG5vdCBwYXRoIGZhaWx1cmUgZGV0 ZWN0aW9uPw0KV2hldGhlciBvbmUgdXNlcyBmb3Igbm9kZSBvciBwYXRoIGZhaWx1cmUgZGV0ZWN0 aW9uIGlzIGZvciB0aGUgc29sdXRpb24gdG8gZGVjaWRlLiBUaGlzIGlzIHJlcXVpcmVtZW50cyBk cmFmdC4gSWYgeW91IHRoaW5rIGJldHRlciB3b3JkaW5nIGlzIHJlcXVpcmVkLCBwbGVhc2UgZG8g cHJvcG9zZSwgd2lsbCBjb25zaWRlciB0aGF0Lg0KDQoNCg0KNC4gVGVzdCBwYWNrZXRzIGNhbiBi ZSBlaXRoZXIgdW5pY2FzdCBvciBtdWx0aWNhc3QuIFRoZSBwcm9ibGVtIHdlIGFyZSBkZXNjcmli aW5nIGhlcmUgaXMgdGhhdCByZWx5aW5nIG9uIG5vcm1hbCBwYWNrZXQgY291bnRlcnMgaW4gdW5y ZWxpYWJsZSBnaXZlbiB0aGF0IEUtVlBOIG9mZmVycyBtYW55LXRvLW1hbnkgY29ubmVjdGl2aXR5 LiBGb3IgZS5nLiwgY29uc2lkZXIgMyBlbmRwb2ludHMgQSwgQiBhbmQgQy4gTGV0J3Mgc2F5IHdl IGFyZSBpbnRlcmVzdGVkIGluIG1lYXN1cmluZyB0aGUgbG9zcyBiZXR3ZWVuIEEgYW5kIEMuIEEg c2VuZHMgYSBwYWNrZXQgdG8gQywgYnV0IGl0IGdldHMgZHJvcHBlZC4gTm93IEIgYWxzbyBzZW5k cyB0byBDIGFuZCB0aGF0IHBhY2tldCBpcyBkZWxpdmVyZWQuIElmIHdlIHdlcmUgdG8gZXhhbWlu ZSB0aGUgcGFja2V0IGNvdW50ZXIgb24gQywgd2Ugd2lsbCBmaW5kIHRoYXQgdGhlIGNvdW50ZXIg c2hvd3MgMSBwYWNrZXQgcmVjZWl2ZWQuIEJ1dCB0aGF0IGRvZXNuJ3QgbWVhbiB0aGF0IHdlIGhh dmUgMTAwJSBwYWNrZXQgZGVsaXZlcnkgcmF0ZSBiZXR3ZWVuIEEgYW5kIEMuIFRoZSBwYWNrZXQg YWN0dWFsbHkgY2FtZSBmcm9tIGFub3RoZXIgc291cmNlIGFuZCBoZW5jZSB0aGUgcGFja2V0IGNv dW50ZXIgb24gQyBpcyBhbWJpZ3VvdXMuIFVubGVzcyB0aGUgaW1wbGVtZW50YXRpb24ga2VlcHMg cGFja2V0IGNvdW50ZXJzIHBlci1mbG93ICh3aGljaCB3aWxsIGJlIGV4cGVuc2l2ZSBhbmQgaW1w cmFjdGljYWwpLCBpdCBpcyBub3QgcmVsaWFibGUgdG8gdXNlIHBhY2tldCBjb3VudGVycyB0byBt ZWFzdXJlIGxvc3MgaW4gYSB0ZWNobm9sb2d5IHRoYXQgc3VwcG9ydHMgbXVsdGlwb2ludC10by1t dWx0aXBvaW50IGNvbm5lY3Rpdml0eS4NCltGcmFua10gOiBZZXMuIFRoaXMgY2xhcmlmaWNhdGlv biBpcyBtb3JlIGNsZWFyIHRoYW4gdGhlIGN1cnJlbnQgY29udGVudCBvZiBkcmFmdH5+IEFsc28s IEkgdGhpbmsg4oCcYSBzdGF0aXN0aWNhbCBtZWFucyBvZiBhcHByb3hpbWF0aW5nIHBhY2tldCBs b3NzIHJhdGXigJ0geW91IHByb3Bvc2VkIGluIGRyYWZ0IGlzIG5vdCB0aGUgc3VpdGFibGUgc29s dXRpb24gZm9yIHRoaXMgcHJvYmxlbS4gQWN0dWFsbHksIHRoaXMgaXMgbW9yZSBhbiBpbXBsZW1l bnRhdGlvbiBpc3N1ZSwgaS5lLiwgd2UgY2FuIHNldCB0aGUgc2FtZSB2YWx1ZSBvZiBmbG93IGNo YXJhY3RlcmlzdGljcyBmb3IgYSB0ZXN0IGZsb3cgdG8gZW5zdXJlIGFsbCB0ZXN0IGZsb3cgcGFj a2V0cyBzZW5kL3JlY2VpdmUgYmV0d2VlbiAyIG5vZGVzIGV4YWN0bHkuDQpBZ2FpbiwgdGhpcyBp cyByZXF1aXJlbWVudCBkcmFmdCBvbmx5LiBXaGF0IHlvdSBhcmUgZWx1ZGluZyB0byBpcyBob3cg b25lIHNob3VsZCBwZXJmb3JtLCB3aGljaCBjbGVhcmx5IGZhbGxzIGluIHNvbHV0aW9uIGNhdGVn b3J5LiBBcyBTYW1lciBjbGFyaWZpZWQgZWFybGllciwgdXNpbmcgYWN0dWFsIGRhdGEgcGFja2V0 IGNvdW50ZXJzIGRvZXNu4oCZdCBtZWV0IHRoZSByZXF1aXJlbWVudHMsIGhlbmNlIOKAmHN5bnRo ZXRpYycgbWVhc3VyZW1lbnQgaXMgcmVxdWlyZWQuDQoNCi1zYW0NCg0KDQoNClJlZ2FyZHMsDQpT YW1lcg0KDQpGcm9tOiAiWGlhbGlhbmcgKEZyYW5rKSIgPGZyYW5rLnhpYWxpYW5nQGh1YXdlaS5j b208bWFpbHRvOmZyYW5rLnhpYWxpYW5nQGh1YXdlaS5jb20+Pg0KRGF0ZTogVHVlc2RheSwgMTgg TWFyY2gsIDIwMTQgMTI6MDcgQU0NClRvOiBTYW1lciBTYWxhbSA8c3NhbGFtQGNpc2NvLmNvbTxt YWlsdG86c3NhbGFtQGNpc2NvLmNvbT4+LCAiQWxpIFNhamFzc2kgKHNhamFzc2kpIiA8c2FqYXNz aUBjaXNjby5jb208bWFpbHRvOnNhamFzc2lAY2lzY28uY29tPj4sICJhbGRyaW4uaWV0ZkBnbWFp bC5jb208bWFpbHRvOmFsZHJpbi5pZXRmQGdtYWlsLmNvbT4iIDxhbGRyaW4uaWV0ZkBnbWFpbC5j b208bWFpbHRvOmFsZHJpbi5pZXRmQGdtYWlsLmNvbT4+LCAiamRyYWtlQGp1bmlwZXIubmV0PG1h aWx0bzpqZHJha2VAanVuaXBlci5uZXQ+IiA8amRyYWtlQGp1bmlwZXIubmV0PG1haWx0bzpqZHJh a2VAanVuaXBlci5uZXQ+Pg0KQ2M6ICJsMnZwbkBpZXRmLm9yZzxtYWlsdG86bDJ2cG5AaWV0Zi5v cmc+IiA8bDJ2cG5AaWV0Zi5vcmc8bWFpbHRvOmwydnBuQGlldGYub3JnPj4NClN1YmplY3Q6IGNv bW1lbnRzIG9uICJkcmFmdC1zYWxhbS1sMnZwbi1ldnBuLW9hbS1yZXEtZnJtd2stMDIiOg0KDQpI aSBhdXRob3JzLA0KSSBoYXZlIHJldmlld2VkIHRoaXMgaW1wb3J0YW50IGRyYWZ0LCBhbmQgaGF2 ZSBzb21lIGNvbW1lbnRzIGFzIGJlbG93Og0KMS4gQnkgY29tcGFyaW5nIHdpdGggUkZDNjEzNiAo TDJWUE4gT0FNIHJlcSBhbmQgZnJtKSwgZnJvbSB0aGUgaW50ZWdyaXR5IHBvaW50IG9mIHZpZXcs IEkgdGhpbmsgdGhlcmUgYXJlIHNvbWUgcGFydCBtaXNzaW5nOiBFVlBOIE1FUCBhbmQgTUlQLCBE aXNjb3ZlcnksIERhdGEgUGF0aCBGb3J3YXJkaW5nLCBTY2FsYWJpbGl0eSwgVHJhbnNwb3J0L0Fw cGxpY2F0aW9uIEluZGVwZW5kZW5jZTsNCjIuIEluIHNlY3Rpb24gMy4xLjEuMSwgd2hhdCBpcyB0 aGUgZGVmaW5pdGlvbiBvZiBwZXIgdXNlciBmbG93PyBXaHkgaXMgaXQgZGlmZmVyZW50IHRvIHN1 cHBvcnQgaXQgYmV0d2VlbiBFLVZQTiBOZXR3b3JrIE9BTSBhbmQgRS1WUE4gU2VydmljZSBPQU0/ DQozLiBJbiBzZWN0aW9uIDMuMS4xLjEsIGRvZXMgdGhlIHNlY3Rpb24gb2YgImEgcmVwcmVzZW50 YXRpdmUgcGF0aCIgbWVhbiB1c2luZyB0ZXN0IGZsb3cgdG8gZGV0ZWN0IHRoZSBub2RlIGZhaWx1 cmU/IGlmIHllcywgaG93IHRvIGRvPyBJcyBpdCBhIG5lY2Vzc2FyeSByZXF1aXJlbWVudCBvZiBw cm9hY3RpdmUgZmF1bHQgZGV0ZWN0aW9uPw0KNC4gSW4gc2VjdGlvbiAzLjIuMSwgSSBkbyBub3Qg cXVpdGUgdW5kZXJzdGFuZCB0aGUgZGVzY3JpYmluZyByZWFzb24gZm9yIHRoZSBpbmFjY3VyYWN5 IG9mIExvc3MgTWVhc3VyZW1lbnQuIERvIHlvdSBtZWFuIHRoYXQgdGVzdCBwYWNrZXRzIG9mIExv c3MgTWVhc3VyZW1lbnQgYXJlIGFsbCBCVU0gcGFja2V0cz8gQ2FuIHlvdSBjbGFyaWZ5IHdoeSBw ZWVyIE1FUHMgd2lsbCByZWNlaXZlIHNvbWUgdW5uZWNlc3NhcnkgcGFja2V0cz8gV2h5IG5vdCB1 c2UgdW5pY2FzdCBwYWNrZXRzIGZvciBMb3NzIE1lYXN1cmVtZW50Pw0KDQpIb3BpbmcgZm9yIHlv dXIgZmVlZGJhY2t+fg0KDQpCLlIuDQpGcmFuaw0KDQo= --_000_7347100B5761DC41A166AC17F22DF1121B78DB2Aeusaamb103erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2 Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9 DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBU ZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5hcHBsZS1j b252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30N CnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWls U3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSBTYW0sIGV0LiBhbCw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBvbmx5IG5vdGVkIHRoYXQgSSBkb27igJl0IGJl bGlldmUgdGhhdCBpdCBpcyBwb3NzaWJsZSB0byBkaXN0aW5ndWlzaCBiZXR3ZWVuIHBhdGggZmFp bHVyZSBhbmQgZmFpbHVyZSBvZiBhIG5vZGUgYWxvbmcgdGhhdCBwYXRoIHdpdGhvdXQgdmVyeSBz b3BoaXN0aWNhdGVkIGZhdWx0DQogY29ycmVsYXRpb24gaGV1cmlzdGljcyB1c3VhbGx5IGFzc29j aWF0ZWQgd2l0aCB0aGUgTk1TLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5XaXRoIHNv IGV4dGVuc2l2ZSBhbmQgaW50ZXJlc3RpbmcgZGlzY3Vzc2lvbiBpdCBpcyBiaXQgaGFyZCB0byB1 bmRlcnN0YW5kIGN1cnJlbnQgc3RhdGUgb2YgdGhlIGRvY3VtZW50IGFuZCBzdWdnZXN0IGFueSBz cGVjaWZpYyB0ZXh0LiBJ4oCZbSBsb29raW5nIGZvcndhcmQgZm9yDQogdGhlIHZlcnNpb24gdGhh dCBpbmNvcnBvcmF0ZXMgdGhpcyByb3VuZCBvZiBkaXNjdXNzaW9uLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBHcmVnPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gU2FtIEFs ZHJpbiBbbWFpbHRvOmFsZHJpbi5pZXRmQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBU aHVyc2RheSwgQXByaWwgMDMsIDIwMTQgMzo1MSBQTTxicj4NCjxiPlRvOjwvYj4gR3JlZ29yeSBN aXJza3k8YnI+DQo8Yj5DYzo8L2I+IFhpYWxpYW5nIChGcmFuayk7IGwydnBuQGlldGYub3JnOyBB bGkgU2FqYXNzaSAoc2FqYXNzaSk8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IGNvbW1lbnRzIG9u ICZxdW90O2RyYWZ0LXNhbGFtLWwydnBuLWV2cG4tb2FtLXJlcS1mcm13ay0wMiZxdW90Ozo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R3JlZywg RnJhbmsgZXQgYWwsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkFueSBwcm9wb3NhbCB0byBoYXZlIGNsZWFyIHRleHQgaXMgYWx3YXlzIHdlbGNv bWUuIFNvLCBraW5kbHkgcHJvcG9zZSB0aGUgdGV4dCBvbiB3aGF0IHlvdSB3b3VsZCBsaWtlIHRv IHNlZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+U2FtPGJyPg0KPGJyPg0KU2VudCBmcm9tIG15IGlQaG9uZTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48YnI+DQpPbiBBcHIgMywgMjAxNCwgYXQgMzoyNCBQTSwgR3JlZ29yeSBNaXJza3kgJmx0 OzxhIGhyZWY9Im1haWx0bzpncmVnb3J5Lm1pcnNreUBlcmljc3Nvbi5jb20iPmdyZWdvcnkubWly c2t5QGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+RGVhciBTYW0gYW5kIEZyYW5rLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5ldmVuIHRob3VnaCB3ZeKAmXJlIGRpc2N1c3NpbmcgcmVxdWlyZW1lbnRzIGFuZCBm cmFtZXdvcmsgb2YgRVZQTiBPQU0gSSB3b25kZXIgaWYgeW91IGNhbiBnaXZlIHJlZmVyZW5jZSB0 byZuYnNwOyBPQU0gbWV0aG9kIHRoYXQgY2FuIGRpZmZlcmVudGlhdGUgb3IgZGlzdGluZ3Vpc2gN CiBiZXR3ZWVuIHBhdGggYW5kIG5vZGUgZmFpbHVyZXMgYXMgaW1wbGllZCBpbjo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp bjt0ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+My4gWWVzLCBhIHJlcHJlc2VudGF0aXZlIHBhdGggbWFwcyB0 byBhIHRlc3QgZmxvdy4gVGhpcyBpcyBhIHNpbXBsZSBmdW5jdGlvbiwgYW5kIGlzIGFjdHVhbGx5 IGEgZGVnZW5lcmF0ZQ0KIGNhc2Ugb2YgdGhlIHBlciB1c2VyLWZsb3cgT0FNLCBiZWNhdXNlIHRl c3QgZmllbGRzIGFyZSBzcGVjaWZpZWQgZm9yIHRoZSBOLVR1cGxlLiBUaGF0J3Mgd2h5IGl0IGlz IG1hbmRhdG9yeS4gQXMgdG8gdGhlIGRldGFpbHMgb2YgdGhlIG1lY2hhbmlzbSwgdGhhdCBpcyBs ZWZ0IHRvIHRoZSBzb2x1dGlvbiBkcmFmdCDigJMgYWZ0ZXIgYWxsLCB0aGlzIGlzIHRoZSByZXF1 aXJlbWVudHMgYW5kIGZyYW1ld29yayBkcmFmdCwgaXQgZG9lcyBub3QgY292ZXINCiB0aGUgc29s dXRpb24gZGV0YWlscyBmb3IgaW1wbGVtZW50YXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1hbGlnbjpq dXN0aWZ5Ij48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDtt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+W0ZyYW5rXSA6IEZyb20gbXkgcGVyc29uYWwgdmll dywgSSBkb27igJl0IHRoaW5rIHRoZSBwYXJhZ3JhcGggZGVzY3JpYmluZyB0aGUgcmVxdWlyZW1l bnQNCiBvZiBhIHJlcHJlc2VudGF0aXZlIHBhdGggaXMgY2xlYXIgZW5vdWdoLiBGb3IgZXhhbXBs ZSwgd2h5IGNhbiBpdCBiZSB1c2VkIGZvciBub2RlIGZhaWx1cmUgZGV0ZWN0aW9uIGJ1dCBub3Qg cGF0aCBmYWlsdXJlIGRldGVjdGlvbj88L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPldoZXRoZXIgb25lIHVzZXMgZm9yIG5vZGUgb3IgcGF0aCBmYWls dXJlIGRldGVjdGlvbiBpcyBmb3IgdGhlIHNvbHV0aW9uIHRvIGRlY2lkZS4gVGhpcyBpcyByZXF1 aXJlbWVudHMgZHJhZnQuIElmIHlvdSB0aGluayBiZXR0ZXIgd29yZGluZyBpcyByZXF1aXJlZCwg cGxlYXNlIGRvIHByb3Bvc2UsIHdpbGwgY29uc2lkZXIgdGhhdC48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMwMDIwNjAiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MDAyMDYwIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3JlZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEwydnBuIFs8 YSBocmVmPSJtYWlsdG86bDJ2cG4tYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmwydnBuLWJvdW5j ZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5TYW0gQWxkcmluPGJyPg0KPGI+ U2VudDo8L2I+IE1vbmRheSwgTWFyY2ggMzEsIDIwMTQgNzoxMiBQTTxicj4NCjxiPlRvOjwvYj4g WGlhbGlhbmcgKEZyYW5rKTxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmwydnBuQGll dGYub3JnIj5sMnZwbkBpZXRmLm9yZzwvYT47IEFsaSBTYWphc3NpIChzYWphc3NpKTxicj4NCjxi PlN1YmplY3Q6PC9iPiBSZTogY29tbWVudHMgb24gJnF1b3Q7ZHJhZnQtc2FsYW0tbDJ2cG4tZXZw bi1vYW0tcmVxLWZybXdrLTAyJnF1b3Q7Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkZyYW5rLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Q29tbWVudHMgaW5saW5lLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNYXIgMzEsIDIwMTQsIGF0IDc6MDAgUE0sIFhpYWxp YW5nIChGcmFuaykgJmx0OzxhIGhyZWY9Im1haWx0bzpmcmFuay54aWFsaWFuZ0BodWF3ZWkuY29t Ij5mcmFuay54aWFsaWFuZ0BodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1 c3RpZnkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj5IaSBTYW1lciw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ UGxlYXNlIHNlZSBpbmxpbmU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDt6LWluZGV4OmF1dG8iPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPlNhbWVyDQogU2FsYW0gKHNzYWxhbSkgWzxhIGhyZWY9Im1haWx0bzpzc2FsYW1A Y2lzY28uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5tYWlsdG86c3NhbGFtQGNpc2Nv LmNvbTwvc3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+VHVlc2RheSwgQXByaWwgMDEsIDIwMTQgNTowMyBBTTxicj4NCjxi PlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ WGlhbGlhbmcgKEZyYW5rKTsgQWxpIFNhamFzc2kgKHNhamFzc2kpOzxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86YWxkcmluLmll dGZAZ21haWwuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5hbGRyaW4uaWV0ZkBnbWFp bC5jb208L3NwYW4+PC9hPjs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmpkcmFrZUBqdW5pcGVyLm5ldCI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+amRyYWtlQGp1bmlwZXIubmV0PC9zcGFuPjwvYT48YnI+DQo8Yj5DYzo8 L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhy ZWY9Im1haWx0bzpsMnZwbkBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bDJ2 cG5AaWV0Zi5vcmc8L3NwYW4+PC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogY29tbWVudHMgb24gJnF1b3Q7 ZHJhZnQtc2FsYW0tbDJ2cG4tZXZwbi1vYW0tcmVxLWZybXdrLTAyJnF1b3Q7Ojwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i dGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6WkgtQ04iPkhpIEZyYW5rLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5UaGFua3MgZm9yIHlvdXIgY29tbWVu dHMuIFBsZWFzZSBmaW5kIHJlc3BvbnNlcyBiZWxvdzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0 aWZ5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6Wkgt Q04iPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+MS4gSW4gdGhpcyBkcmFmdCwg d2UgY2l0ZSBSRkMgNjEzNiBhcyByZWZlcmVuY2UsIGFuZCBoZW5jZSB3ZSBkbyBub3QgcmVwZWF0 IHRoZSBkZWZpbml0aW9uIG9mIGNvbW1vbiBPQU0gdGVybXMgKE1FUCwNCiBNSVAsIE1haW50ZW5h bmNlIERvbWFpbiwgSW4tYmFuZCBPQU0sIE9BTSBsYXllcmluZyBldGMuKS4gUmVnYXJkaW5nIERp c2NvdmVyeSwgcGxlYXNlIG5vdGUgdGhhdCBFLVZQTiBoYXMgYXV0b21hdGljIGRpc2NvdmVyeSBi dWlsdC1pbiB2aWEgdGhlIEluY2x1c2l2ZSBNdWx0aWNhc3QgUm91dGUgYW5kIHRoZSBFdGhlcm5l dCBBLUQgUm91dGUuIEhlbmNlLCBubyBmdXJ0aGVyIG1lY2hhbmlzbXMgYXJlIHJlcXVpcmVkLjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVz dGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj4yLiBQZXIgdXNlciBmbG93IG1lYW5zIGEgdHJhZmZpYyBzdHJlYW0gdGhhdCBtYXBzIHRv IGFjdHVhbCB1c2VyIGRhdGEsIHdpdGggYSBzcGVjaWZpZWQgTi10dXBsZSBjaGFyYWN0ZXJpc3Rp Y3MgKE1BQw0KIERBL1NBLCBWTEFOLCBJUCBEQS9TQSwgU3JjL0Rlc3QgUG9ydOKApikuICZuYnNw O1RoZSByZWFzb24gd2h5IHRoaXMgaXMgZGlmZmVyZW50IGJldHdlZW4gTmV0d29yayAmYW1wOyBT ZXJ2aWNlIE9BTSBpcyBiZWNhdXNlIHRoZSBTZXJ2aWNlIE9BTSBtZWNoYW5pc21zIG1heSBvciBt YXkgbm90IGJlIGFibGUgdG8gc3VwcG9ydCBwZXItZmxvdyBPQU0sIGRlcGVuZGluZyBvbiB0aGUg Jm5ic3A7c2VydmljZSBsYXllciBhbmQgaXRzIGFzc29jaWF0ZWQgT0FNIGNhcGFiaWxpdGllcy4N CiBGb3IgaW5zdGFuY2UsIGluIHRoZSBjYXNlIHdoZXJlIEV0aGVybmV0IENGTSAoSUVFRSA4MDIu MWFnKSBpcyB0aGUgc2VydmljZSBPQU0sIGl0IGlzIG5vdCBwb3NzaWJsZSB0byBwZXJmb3JtIHBl ci1mbG93IGNvbnRpbnVpdHkgY2hlY2ssIGFzIHRoZSBkZXN0aW5hdGlvbiBNQUMgYWRkcmVzcyBp cyBzZXQgYnkgdGhlIHByb3RvY29sIHRvIGEgbXVsdGljYXN0IGFkZHJlc3MuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRl eHQtYWxpZ246anVzdGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjMuIFll cywgYSByZXByZXNlbnRhdGl2ZSBwYXRoIG1hcHMgdG8gYSB0ZXN0IGZsb3cuIFRoaXMgaXMgYSBz aW1wbGUgZnVuY3Rpb24sIGFuZCBpcyBhY3R1YWxseSBhIGRlZ2VuZXJhdGUgY2FzZSBvZiB0aGUN CiBwZXIgdXNlci1mbG93IE9BTSwgYmVjYXVzZSB0ZXN0IGZpZWxkcyBhcmUgc3BlY2lmaWVkIGZv ciB0aGUgTi1UdXBsZS4gVGhhdCdzIHdoeSBpdCBpcyBtYW5kYXRvcnkuIEFzIHRvIHRoZSBkZXRh aWxzIG9mIHRoZSBtZWNoYW5pc20sIHRoYXQgaXMgbGVmdCB0byB0aGUgc29sdXRpb24gZHJhZnQg 4oCTIGFmdGVyIGFsbCwgdGhpcyBpcyB0aGUgcmVxdWlyZW1lbnRzIGFuZCBmcmFtZXdvcmsgZHJh ZnQsIGl0IGRvZXMgbm90IGNvdmVyIHRoZSBzb2x1dGlvbg0KIGRldGFpbHMgZm9yIGltcGxlbWVu dGF0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5bRnJhbmtdIDogRnJvbSBt eSBwZXJzb25hbCB2aWV3LCBJIGRvbuKAmXQgdGhpbmsgdGhlIHBhcmFncmFwaCBkZXNjcmliaW5n IHRoZSByZXF1aXJlbWVudCBvZiBhIHJlcHJlc2VudGF0aXZlDQogcGF0aCBpcyBjbGVhciBlbm91 Z2guIEZvciBleGFtcGxlLCB3aHkgY2FuIGl0IGJlIHVzZWQgZm9yIG5vZGUgZmFpbHVyZSBkZXRl Y3Rpb24gYnV0IG5vdCBwYXRoIGZhaWx1cmUgZGV0ZWN0aW9uPzwvc3Bhbj48L2k+PC9iPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ V2hldGhlciBvbmUgdXNlcyBmb3Igbm9kZSBvciBwYXRoIGZhaWx1cmUgZGV0ZWN0aW9uIGlzIGZv ciB0aGUgc29sdXRpb24gdG8gZGVjaWRlLiBUaGlzIGlzIHJlcXVpcmVtZW50cyBkcmFmdC4gSWYg eW91IHRoaW5rIGJldHRlciB3b3JkaW5nIGlzIHJlcXVpcmVkLCBwbGVhc2UgZG8gcHJvcG9zZSwg d2lsbCBjb25zaWRlciB0aGF0Ljxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDt6LWluZGV4OmF1dG8iPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRl eHQtYWxpZ246anVzdGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj40LiBUZXN0IHBhY2tldHMgY2FuIGJlIGVpdGhlciB1bmljYXN0IG9y IG11bHRpY2FzdC4gVGhlIHByb2JsZW0gd2UgYXJlIGRlc2NyaWJpbmcgaGVyZSBpcyB0aGF0IHJl bHlpbmcgb24gbm9ybWFsIHBhY2tldA0KIGNvdW50ZXJzIGluIHVucmVsaWFibGUgZ2l2ZW4gdGhh dCBFLVZQTiBvZmZlcnMgbWFueS10by1tYW55IGNvbm5lY3Rpdml0eS4gRm9yIGUuZy4sIGNvbnNp ZGVyIDMgZW5kcG9pbnRzIEEsIEIgYW5kIEMuIExldCdzIHNheSB3ZSBhcmUgaW50ZXJlc3RlZCBp biBtZWFzdXJpbmcgdGhlIGxvc3MgYmV0d2VlbiBBIGFuZCBDLiBBIHNlbmRzIGEgcGFja2V0IHRv IEMsIGJ1dCBpdCBnZXRzIGRyb3BwZWQuIE5vdyBCIGFsc28gc2VuZHMgdG8gQyBhbmQgdGhhdA0K IHBhY2tldCBpcyBkZWxpdmVyZWQuIElmIHdlIHdlcmUgdG8gZXhhbWluZSB0aGUgcGFja2V0IGNv dW50ZXIgb24gQywgd2Ugd2lsbCBmaW5kIHRoYXQgdGhlIGNvdW50ZXIgc2hvd3MgMSBwYWNrZXQg cmVjZWl2ZWQuIEJ1dCB0aGF0IGRvZXNuJ3QgbWVhbiB0aGF0IHdlIGhhdmUgMTAwJSBwYWNrZXQg ZGVsaXZlcnkgcmF0ZSBiZXR3ZWVuIEEgYW5kIEMuIFRoZSBwYWNrZXQgYWN0dWFsbHkgY2FtZSBm cm9tIGFub3RoZXIgc291cmNlIGFuZCBoZW5jZQ0KIHRoZSBwYWNrZXQgY291bnRlciBvbiBDIGlz IGFtYmlndW91cy4gVW5sZXNzIHRoZSBpbXBsZW1lbnRhdGlvbiBrZWVwcyBwYWNrZXQgY291bnRl cnMgcGVyLWZsb3cgKHdoaWNoIHdpbGwgYmUgZXhwZW5zaXZlIGFuZCBpbXByYWN0aWNhbCksIGl0 IGlzIG5vdCByZWxpYWJsZSB0byB1c2UgcGFja2V0IGNvdW50ZXJzIHRvIG1lYXN1cmUgbG9zcyBp biBhIHRlY2hub2xvZ3kgdGhhdCBzdXBwb3J0cyBtdWx0aXBvaW50LXRvLW11bHRpcG9pbnQgY29u bmVjdGl2aXR5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5bRnJhbmtdIDogWWVz LiBUaGlzIGNsYXJpZmljYXRpb24gaXMgbW9yZSBjbGVhciB0aGFuIHRoZSBjdXJyZW50IGNvbnRl bnQgb2YgZHJhZnR+fiBBbHNvLCBJIHRoaW5rDQog4oCcYSBzdGF0aXN0aWNhbCBtZWFucyBvZiBh cHByb3hpbWF0aW5nIHBhY2tldCBsb3NzIHJhdGXigJ0geW91IHByb3Bvc2VkIGluIGRyYWZ0IGlz IG5vdCB0aGUgc3VpdGFibGUgc29sdXRpb24gZm9yIHRoaXMgcHJvYmxlbS4gQWN0dWFsbHksIHRo aXMgaXMgbW9yZSBhbiBpbXBsZW1lbnRhdGlvbiBpc3N1ZSwgaS5lLiwgd2UgY2FuIHNldCB0aGUg c2FtZSB2YWx1ZSBvZiBmbG93IGNoYXJhY3RlcmlzdGljcyBmb3IgYSB0ZXN0IGZsb3cgdG8gZW5z dXJlIGFsbA0KIHRlc3QgZmxvdyBwYWNrZXRzIHNlbmQvcmVjZWl2ZSBiZXR3ZWVuIDIgbm9kZXMg ZXhhY3RseS48L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFnYWluLCB0aGlzIGlzIHJlcXVpcmVtZW50IGRy YWZ0IG9ubHkuIFdoYXQgeW91IGFyZSBlbHVkaW5nIHRvIGlzIGhvdyBvbmUgc2hvdWxkIHBlcmZv cm0sIHdoaWNoIGNsZWFybHkgZmFsbHMgaW4gc29sdXRpb24gY2F0ZWdvcnkuIEFzIFNhbWVyIGNs YXJpZmllZCBlYXJsaWVyLCB1c2luZyBhY3R1YWwgZGF0YSBwYWNrZXQgY291bnRlcnMgZG9lc27i gJl0IG1lZXQgdGhlIHJlcXVpcmVtZW50cywgaGVuY2Ug4oCYc3ludGhldGljJw0KIG1lYXN1cmVt ZW50IGlzIHJlcXVpcmVkLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4tc2FtPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O3otaW5kZXg6YXV0byI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlm eSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij5TYW1lcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkZyb206PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mcXVvdDtYaWFsaWFu Zw0KIChGcmFuaykmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpmcmFuay54aWFsaWFuZ0BodWF3 ZWkuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5mcmFuay54aWFsaWFuZ0BodWF3ZWku Y29tPC9zcGFuPjwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlR1ZXNkYXksIDE4IE1hcmNoLCAyMDE0IDEyOjA3 IEFNPGJyPg0KPGI+VG86PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjwvYj5TYW1lciBTYWxhbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNzYWxhbUBjaXNjby5j b20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnNzYWxhbUBjaXNjby5jb208L3NwYW4+PC9h PiZndDssICZxdW90O0FsaSBTYWphc3NpIChzYWphc3NpKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnNhamFzc2lAY2lzY28uY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5zYWphc3Np QGNpc2NvLmNvbTwvc3Bhbj48L2E+Jmd0OywNCiAmcXVvdDs8YSBocmVmPSJtYWlsdG86YWxkcmlu LmlldGZAZ21haWwuY29tIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5hbGRyaW4uaWV0ZkBn bWFpbC5jb208L3NwYW4+PC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFsZHJpbi5pZXRm QGdtYWlsLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+YWxkcmluLmlldGZAZ21haWwu Y29tPC9zcGFuPjwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86amRyYWtlQGp1bmlwZXIu bmV0Ij48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5qZHJha2VAanVuaXBlci5uZXQ8L3NwYW4+ PC9hPiZxdW90Ow0KICZsdDs8YSBocmVmPSJtYWlsdG86amRyYWtlQGp1bmlwZXIubmV0Ij48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5qZHJha2VAanVuaXBlci5uZXQ8L3NwYW4+PC9hPiZndDs8 YnI+DQo8Yj5DYzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzpsMnZwbkBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+bDJ2cG5AaWV0Zi5vcmc8L3NwYW4+PC9hPiZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmwydnBuQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5sMnZw bkBpZXRmLm9yZzwvc3Bhbj48L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvYj5jb21tZW50cyBvbiAmcXVvdDtk cmFmdC1zYWxhbS1sMnZwbi1ldnBuLW9hbS1yZXEtZnJtd2stMDImcXVvdDs6PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRl eHQtYWxpZ246anVzdGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkhpIGF1 dGhvcnMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 InRleHQtYWxpZ246anVzdGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj5JIGhhdmUgcmV2aWV3ZWQgdGhpcyBpbXBvcnRhbnQgZHJhZnQs IGFuZCBoYXZlIHNvbWUgY29tbWVudHMgYXMgYmVsb3c6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4xLiBCeSBjb21w YXJpbmcgd2l0aCBSRkM2MTM2IChMMlZQTiBPQU0gcmVxIGFuZCBmcm0pLCBmcm9tIHRoZSBpbnRl Z3JpdHkgcG9pbnQgb2YgdmlldywgSSB0aGluayB0aGVyZSBhcmUgc29tZSBwYXJ0DQogbWlzc2lu ZzogRVZQTiBNRVAgYW5kIE1JUCwgRGlzY292ZXJ5LCBEYXRhIFBhdGggRm9yd2FyZGluZywgU2Nh bGFiaWxpdHksIFRyYW5zcG9ydC9BcHBsaWNhdGlvbiBJbmRlcGVuZGVuY2U7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlm eSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij4yLiBJbiBzZWN0aW9uIDMuMS4xLjEsIHdoYXQgaXMgdGhlIGRlZmluaXRpb24gb2YgcGVyIHVz ZXIgZmxvdz8gV2h5IGlzIGl0IGRpZmZlcmVudCB0byBzdXBwb3J0IGl0IGJldHdlZW4gRS1WUE4g TmV0d29yaw0KIE9BTSBhbmQgRS1WUE4gU2VydmljZSBPQU0/PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYWxpZ246anVzdGlmeSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4zLiBJbiBz ZWN0aW9uIDMuMS4xLjEsIGRvZXMgdGhlIHNlY3Rpb24gb2YgJnF1b3Q7YSByZXByZXNlbnRhdGl2 ZSBwYXRoJnF1b3Q7IG1lYW4gdXNpbmcgdGVzdCBmbG93IHRvIGRldGVjdCB0aGUgbm9kZSBmYWls dXJlPw0KIGlmIHllcywgaG93IHRvIGRvPyBJcyBpdCBhIG5lY2Vzc2FyeSByZXF1aXJlbWVudCBv ZiBwcm9hY3RpdmUgZmF1bHQgZGV0ZWN0aW9uPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmp1c3RpZnkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+NC4gSW4gc2VjdGlvbiAz LjIuMSwgSSBkbyBub3QgcXVpdGUgdW5kZXJzdGFuZCB0aGUgZGVzY3JpYmluZyByZWFzb24gZm9y IHRoZSBpbmFjY3VyYWN5IG9mIExvc3MgTWVhc3VyZW1lbnQuIERvIHlvdQ0KIG1lYW4gdGhhdCB0 ZXN0IHBhY2tldHMgb2YgTG9zcyBNZWFzdXJlbWVudCBhcmUgYWxsIEJVTSBwYWNrZXRzPyBDYW4g eW91IGNsYXJpZnkgd2h5IHBlZXIgTUVQcyB3aWxsIHJlY2VpdmUgc29tZSB1bm5lY2Vzc2FyeSBw YWNrZXRzPyBXaHkgbm90IHVzZSB1bmljYXN0IHBhY2tldHMgZm9yIExvc3MgTWVhc3VyZW1lbnQ/ PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQt YWxpZ246anVzdGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkhvcGluZyBmb3IgeW91ciBmZWVkYmFj a35+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRl eHQtYWxpZ246anVzdGlmeSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O21zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkIuUi48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4dC1hbGlnbjpqdXN0aWZ5Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkZy YW5rPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7347100B5761DC41A166AC17F22DF1121B78DB2Aeusaamb103erics_-- From nobody Thu Apr 3 19:01:47 2014 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 729E31A0055 for ; Thu, 3 Apr 2014 19:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 ZrxjGMXiEOhq for ; Thu, 3 Apr 2014 19:01:41 -0700 (PDT) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9661A048A for ; Thu, 3 Apr 2014 19:01:41 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id rd3so2721182pab.39 for ; Thu, 03 Apr 2014 19:01:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=p2H7CcIAh6z/9kPUWBg8n2V70HyssfU/sEgW/iuTrpY=; b=jZJYAumwqkAIZF1q/LzwuuDHSPFbdQB4QNPEN+tPFSLB+pJnAPq/h7zOfWZOenuvN7 dCJEZCbV5VmTejezQDqaT9ZWFQUxa9rhsxC+UH0bHbzB72LGHgl7gnNodmh2Tbj86nTL 4z+qscm580krjkeZM1tyU9ue3Mo86cY8F3JTm35zzmA/Z01LU2GK5ADqHOjX4MmFpu6k Dpaz72wVog4fzLjtVFxp0PPEND08Us6R3b6VhYLRK+rZ2R8tSw3CHy54xaR1+rwjiv/0 B3yApDe5yYJ7wFG2P29F1gdF9lckSrbZRIrPqOYzR8bbvDgfChJyoSUPbV2glSye7fdc 775w== X-Received: by 10.68.236.41 with SMTP id ur9mr11457846pbc.101.1396576896768; Thu, 03 Apr 2014 19:01:36 -0700 (PDT) Received: from [192.168.1.3] (c-107-3-154-60.hsd1.ca.comcast.net. [107.3.154.60]) by mx.google.com with ESMTPSA id el14sm32758867pac.31.2014.04.03.19.01.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Apr 2014 19:01:35 -0700 (PDT) References: <8D1DD6FA-2758-4F4A-BD41-E22B59D6843E@gmail.com> <7347100B5761DC41A166AC17F22DF1121B78D9A1@eusaamb103.ericsson.se> <1DB6D64E-2254-40E8-9B68-EDE4DBB781F7@gmail.com> <7347100B5761DC41A166AC17F22DF1121B78DB2A@eusaamb103.ericsson.se> Mime-Version: 1.0 (1.0) In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B78DB2A@eusaamb103.ericsson.se> Content-Type: multipart/alternative; boundary=Apple-Mail-06D0B82A-E6F5-47C0-9A8E-9B337D50E115 Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: iPhone Mail (11D167) From: Sam Aldrin Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": Date: Thu, 3 Apr 2014 19:01:32 -0700 To: Gregory Mirsky Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/Vm85-r5diiPrj-GUK_vRVXBHC9E Cc: "l2vpn@ietf.org" , "Ali Sajassi \(sajassi\)" 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: Fri, 04 Apr 2014 02:01:45 -0000 --Apple-Mail-06D0B82A-E6F5-47C0-9A8E-9B337D50E115 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sounds good, Greg and Frank. Will respin a new version based on your observations. Sam Sent from my iPhone > On Apr 3, 2014, at 6:26 PM, Gregory Mirsky w= rote: >=20 > Hi Sam, et. al, > I only noted that I don=E2=80=99t believe that it is possible to distingui= sh between path failure and failure of a node along that path without very s= ophisticated fault correlation heuristics usually associated with the NMS. > With so extensive and interesting discussion it is bit hard to understand c= urrent state of the document and suggest any specific text. I=E2=80=99m look= ing forward for the version that incorporates this round of discussion. > =20 > Regards, > Greg > =20 > From: Sam Aldrin [mailto:aldrin.ietf@gmail.com]=20 > Sent: Thursday, April 03, 2014 3:51 PM > To: Gregory Mirsky > Cc: Xialiang (Frank); l2vpn@ietf.org; Ali Sajassi (sajassi) > Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": > =20 > Greg, Frank et al, > =20 > Any proposal to have clear text is always welcome. So, kindly propose the t= ext on what you would like to see. > =20 > Sam >=20 > Sent from my iPhone >=20 > On Apr 3, 2014, at 3:24 PM, Gregory Mirsky w= rote: >=20 > Dear Sam and Frank, > even though we=E2=80=99re discussing requirements and framework of EVPN OA= M I wonder if you can give reference to OAM method that can differentiate o= r distinguish between path and node failures as implied in: > 3. Yes, a representative path maps to a test flow. This is a simple functi= on, and is actually a degenerate case of the per user-flow OAM, because test= fields are specified for the N-Tuple. That's why it is mandatory. As to the= details of the mechanism, that is left to the solution draft =E2=80=93 afte= r all, this is the requirements and framework draft, it does not cover the s= olution details for implementation. > [Frank] : =46rom my personal view, I don=E2=80=99t think the paragraph des= cribing the requirement of a representative path is clear enough. For exampl= e, why can it be used for node failure detection but not path failure detect= ion? > Whether one uses for node or path failure detection is for the solution to= decide. This is requirements draft. If you think better wording is required= , please do propose, will consider that. > =20 > Regards, > Greg > =20 > From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Sam Aldrin > Sent: Monday, March 31, 2014 7:12 PM > To: Xialiang (Frank) > Cc: l2vpn@ietf.org; Ali Sajassi (sajassi) > Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": > =20 > Frank, > =20 > Comments inline. > On Mar 31, 2014, at 7:00 PM, Xialiang (Frank) w= rote: >=20 >=20 >=20 > Hi Samer, > Please see inline: > =20 > From: Samer Salam (ssalam) [mailto:ssalam@cisco.com]=20 > Sent: Tuesday, April 01, 2014 5:03 AM > To: Xialiang (Frank); Ali Sajassi (sajassi); aldrin.ietf@gmail.com; jdrake= @juniper.net > Cc: l2vpn@ietf.org > Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": > =20 > Hi Frank, > =20 > Thanks for your comments. Please find responses below: > =20 > 1. In this draft, we cite RFC 6136 as reference, and hence we do not repea= t the definition of common OAM terms (MEP, MIP, Maintenance Domain, In-band O= AM, OAM layering etc.). Regarding Discovery, please note that E-VPN has auto= matic discovery built-in via the Inclusive Multicast Route and the Ethernet A= -D Route. Hence, no further mechanisms are required. > =20 > 2. Per user flow means a traffic stream that maps to actual user data, wit= h a specified N-tuple characteristics (MAC DA/SA, VLAN, IP DA/SA, Src/Dest P= ort=E2=80=A6). The reason why this is different between Network & Service O= AM is because the Service OAM mechanisms may or may not be able to support p= er-flow OAM, depending on the service layer and its associated OAM capabili= ties. For instance, in the case where Ethernet CFM (IEEE 802.1ag) is the ser= vice OAM, it is not possible to perform per-flow continuity check, as the de= stination MAC address is set by the protocol to a multicast address. > =20 > 3. Yes, a representative path maps to a test flow. This is a simple functi= on, and is actually a degenerate case of the per user-flow OAM, because test= fields are specified for the N-Tuple. That's why it is mandatory. As to the= details of the mechanism, that is left to the solution draft =E2=80=93 afte= r all, this is the requirements and framework draft, it does not cover the s= olution details for implementation. > [Frank] : =46rom my personal view, I don=E2=80=99t think the paragraph des= cribing the requirement of a representative path is clear enough. For exampl= e, why can it be used for node failure detection but not path failure detect= ion? > Whether one uses for node or path failure detection is for the solution to= decide. This is requirements draft. If you think better wording is required= , please do propose, will consider that. >=20 >=20 > =20 > 4. Test packets can be either unicast or multicast. The problem we are des= cribing here is that relying on normal packet counters in unreliable given t= hat E-VPN offers many-to-many connectivity. For e.g., consider 3 endpoints A= , B and C. Let's say we are interested in measuring the loss between A and C= . A sends a packet to C, but it gets dropped. Now B also sends to C and that= packet is delivered. If we were to examine the packet counter on C, we will= find that the counter shows 1 packet received. But that doesn't mean that w= e have 100% packet delivery rate between A and C. The packet actually came f= rom another source and hence the packet counter on C is ambiguous. Unless th= e implementation keeps packet counters per-flow (which will be expensive and= impractical), it is not reliable to use packet counters to measure loss in a= technology that supports multipoint-to-multipoint connectivity. > [Frank] : Yes. This clarification is more clear than the current content o= f draft~~ Also, I think =E2=80=9Ca statistical means of approximating packet= loss rate=E2=80=9D you proposed in draft is not the suitable solution for t= his problem. Actually, this is more an implementation issue, i.e., we can se= t the same value of flow characteristics for a test flow to ensure all test f= low packets send/receive between 2 nodes exactly. > Again, this is requirement draft only. What you are eluding to is how one s= hould perform, which clearly falls in solution category. As Samer clarified e= arlier, using actual data packet counters doesn=E2=80=99t meet the requireme= nts, hence =E2=80=98synthetic' measurement is required.=20 > =20 > -sam >=20 >=20 > =20 > Regards, > Samer > =20 > From: "Xialiang (Frank)" > Date: Tuesday, 18 March, 2014 12:07 AM > To: Samer Salam , "Ali Sajassi (sajassi)" , "aldrin.ietf@gmail.com" , "jdrake@juniper.net"= > Cc: "l2vpn@ietf.org" > Subject: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02": > =20 > Hi authors, > I have reviewed this important draft, and have some comments as below: > 1. By comparing with RFC6136 (L2VPN OAM req and frm), from the integrity p= oint of view, I think there are some part missing: EVPN MEP and MIP, Discove= ry, Data Path Forwarding, Scalability, Transport/Application Independence; > 2. In section 3.1.1.1, what is the definition of per user flow? Why is it d= ifferent to support it between E-VPN Network OAM and E-VPN Service OAM? > 3. In section 3.1.1.1, does the section of "a representative path" mean us= ing test flow to detect the node failure? if yes, how to do? Is it a necessa= ry requirement of proactive fault detection? > 4. In section 3.2.1, I do not quite understand the describing reason for t= he inaccuracy of Loss Measurement. Do you mean that test packets of Loss Mea= surement are all BUM packets? Can you clarify why peer MEPs will receive som= e unnecessary packets? Why not use unicast packets for Loss Measurement? > =20 > Hoping for your feedback~~ > =20 > B.R. > Frank > =20 --Apple-Mail-06D0B82A-E6F5-47C0-9A8E-9B337D50E115 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Sounds good, Greg and Frank.
Will respin a new version based on your observations.

<= div>Sam

Sent from my iPhone

On Apr 3, 2014, at 6:26 PM,= Gregory Mirsky <gregory.m= irsky@ericsson.com> wrote:

Hi Sam, et. al,<= /span>

I only noted that I don=E2=80= =99t believe that it is possible to distinguish between path failure and fai= lure of a node along that path without very sophisticated fault correlation heuristics usually associated with the NMS.

With so extensive and inter= esting discussion it is bit hard to understand current state of the document= and suggest any specific text. I=E2=80=99m looking forward for the version that incorporates this round of discussion.

 

    &nb= sp;           Regards,

    &nb= sp;            &= nbsp;            = ;  Greg

 

From: Sam Aldrin [= mailto:aldrin.ietf@gmail.com]
Sent: Thursday, April 03, 2014 3:51 PM
To: Gregory Mirsky
Cc: Xialiang (Frank); l2vpn@ietf.or= g; Ali Sajassi (sajassi)
Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

 

Greg, Frank et al,

 

Any proposal to have clear text is always welcome. So= , kindly propose the text on what you would like to see.

 

Sam

Sent from my iPhone


On Apr 3, 2014, at 3:24 PM, Gregory Mirsky <gregory.mirsky@ericsson.com> wrote:

Dear Sam and Frank,<= o:p>

even though we=E2=80=99re d= iscussing requirements and framework of EVPN OAM I wonder if you can give re= ference to  OAM method that can differentiate or distinguish between path and node failures as implied in:

3. Yes, a representative path maps to a test= flow. This is a simple function, and is actually a degenerate case of the per user-flow OAM, because test fields are specified for the N-= Tuple. That's why it is mandatory. As to the details of the mechanism, that i= s left to the solution draft =E2=80=93 after all, this is the requirements a= nd framework draft, it does not cover the solution details for implementation.

<= span style=3D"font-size:10.5pt;font-family:"Calibri","sans-se= rif";color:#1F497D;mso-fareast-language:ZH-CN">[Frank] : =46rom my pers= onal view, I don=E2=80=99t think the paragraph describing the requirement of a representative path is clear enough. For example, why can it be used f= or node failure detection but not path failure detection?

Whether one uses for node or path failure detection i= s for the solution to decide. This is requirements draft. If you think bette= r wording is required, please do propose, will consider that.

=

 

    &nb= sp;           Regards,

    &nb= sp;            &= nbsp;            = ;  Greg

 

From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Sam Aldrin
Sent: Monday, March 31, 2014 7:12 PM
To: Xialiang (Frank)
Cc: l2vpn@ietf.org; Ali Sajassi= (sajassi)
Subject: Re: comments on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

 

Frank,

 

Comments inline.

On Mar 31, 2014, at 7:00 PM, Xialiang (Frank) <frank.xialiang@huawei.com> w= rote:




Hi Samer,

Please see inline:

 

From:=  Samer Salam (ssalam) [mailto:ssalam@cisco.com] 
Sent: Tuesday, Apri= l 01, 2014 5:03 AM
To: Xialiang (Frank= ); Ali Sajassi (sajassi); = aldrin= .ietf@gmail.com; jdrake@= juniper.net
Cc: l2vpn@ietf.org Subject: Re: commen= ts on "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

 <= o:p>

Hi Frank,

 

Thanks for your comments. Please find responses below:=

 

1. In this draft, we cite RFC 6136 as reference, and hence we= do not repeat the definition of common OAM terms (MEP, MIP, Maintenance Domain, In-band OAM, OAM layering etc.). Regarding Discove= ry, please note that E-VPN has automatic discovery built-in via the Inclusiv= e Multicast Route and the Ethernet A-D Route. Hence, no further mechanisms a= re required.

 

2. Per user flow means a traffic stream that maps to actual u= ser data, with a specified N-tuple characteristics (MAC DA/SA, VLAN, IP DA/SA, Src/Dest Port=E2=80=A6).  The reason why this i= s different between Network & Service OAM is because the Service OAM mec= hanisms may or may not be able to support per-flow OAM, depending on the &nb= sp;service layer and its associated OAM capabilities. For instance, in the case where Ethernet CFM (IEEE 802.1ag) is the service O= AM, it is not possible to perform per-flow continuity check, as the destinat= ion MAC address is set by the protocol to a multicast address.

 

3. Yes, a representative path maps to a test flow. This is a s= imple function, and is actually a degenerate case of the per user-flow OAM, because test fields are specified for the N-Tuple. That'= s why it is mandatory. As to the details of the mechanism, that is left to t= he solution draft =E2=80=93 after all, this is the requirements and framewor= k draft, it does not cover the solution details for implementation.

[Frank] : =46rom my personal view, I don=E2= =80=99t think the paragraph describing the requirement of a representative path is clear enough. For example, why can it be used for node failure dete= ction but not path failure detection?

Whether one uses for node or path failure detection i= s for the solution to decide. This is requirements draft. If you think bette= r wording is required, please do propose, will consider that.


 

4. Test packets can be either unicast or multicast. The probl= em we are describing here is that relying on normal packet counters in unreliable given that E-VPN offers many-to-many connectivity. Fo= r e.g., consider 3 endpoints A, B and C. Let's say we are interested in meas= uring the loss between A and C. A sends a packet to C, but it gets dropped. N= ow B also sends to C and that packet is delivered. If we were to examine the packet counter on C, we will= find that the counter shows 1 packet received. But that doesn't mean that w= e have 100% packet delivery rate between A and C. The packet actually came f= rom another source and hence the packet counter on C is ambiguous. Unless the implementation keeps packe= t counters per-flow (which will be expensive and impractical), it is not rel= iable to use packet counters to measure loss in a technology that supports m= ultipoint-to-multipoint connectivity.

[Frank] : Yes. This clarification is more= clear than the current content of draft~~ Also, I think =E2=80=9Ca statistical means of approximating packet loss rate=E2=80=9D you= proposed in draft is not the suitable solution for this problem. Actually, t= his is more an implementation issue, i.e., we can set the same value of flow= characteristics for a test flow to ensure all test flow packets send/receive between 2 nodes exactly.=

Again, this is requirement draft only. What you are e= luding to is how one should perform, which clearly falls in solution categor= y. As Samer clarified earlier, using actual data packet counters doesn=E2=80= =99t meet the requirements, hence =E2=80=98synthetic' measurement is required. 

 

-sam


 

Regards,

Samer

 

From: "Xialiang (Frank)" <frank.xialiang@huawei.com>
Date: Tuesday, 18 M= arch, 2014 12:07 AM
To: Samer Salam <= ;ssalam@cis= co.com>, "Ali Sajassi (sajassi)" <sajassi@cisco.com>, "aldr= in.ietf@gmail.com" <<= span style=3D"color:purple">aldrin.ietf@gmail.com>, "jdrake@juniper.net<= /span>" <jdra= ke@juniper.net>
Cc: "l2vpn@ietf.org" &= lt;l2vpn@ietf= .org>
Subject: comments o= n "draft-salam-l2vpn-evpn-oam-req-frmwk-02":

 

Hi authors,

I have reviewed this important draft, and have some comments a= s below:

1. By comparing with RFC6136 (L2VPN OAM req and frm), from th= e integrity point of view, I think there are some part missing: EVPN MEP and MIP, Discovery, Data Path Forwarding, Scalability, Tr= ansport/Application Independence;

2. In section 3.1.1.1, what is the definition of per user flo= w? Why is it different to support it between E-VPN Network OAM and E-VPN Service OAM?

3. In section 3.1.1.1, does the section of "a representative p= ath" mean using test flow to detect the node failure? if yes, how to do? Is it a necessary requirement of proactive fault detecti= on?

4. In section 3.2.1, I do not quite understand the describing= reason for the inaccuracy of Loss Measurement. Do you mean that test packets of Loss Measurement are all BUM packets? Can you cla= rify why peer MEPs will receive some unnecessary packets? Why not use unicas= t packets for Loss Measurement?

 

Hoping for your feedback~~

 

B.R.

Frank

 

= --Apple-Mail-06D0B82A-E6F5-47C0-9A8E-9B337D50E115-- From nobody Mon Apr 7 06:07:44 2014 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 42EE71A0702; Mon, 7 Apr 2014 06:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.101 X-Spam-Level: *** X-Spam-Status: No, score=3.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MANGLED_LIPS=2.3, T_HTML_ATTACH=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no 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 5kt8sigF2RRK; Mon, 7 Apr 2014 06:04:49 -0700 (PDT) Received: from g6t1526.atlanta.hp.com (g6t1526.atlanta.hp.com [15.193.200.69]) by ietfa.amsl.com (Postfix) with ESMTP id 284AB1A03F5; Mon, 7 Apr 2014 06:04:47 -0700 (PDT) Received: from G6W4001.americas.hpqcorp.net (g6w4001.atlanta.hp.com [16.205.80.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t1526.atlanta.hp.com (Postfix) with ESMTPS id CD0FF111; Mon, 7 Apr 2014 13:04:38 +0000 (UTC) Received: from G6W3996.americas.hpqcorp.net (16.205.80.211) by G6W4001.americas.hpqcorp.net (16.205.80.210) with Microsoft SMTP Server (TLS) id 14.3.169.1; Mon, 7 Apr 2014 13:04:10 +0000 Received: from G6W2492.americas.hpqcorp.net ([169.254.8.28]) by G6W3996.americas.hpqcorp.net ([16.205.80.211]) with mapi id 14.03.0169.001; Mon, 7 Apr 2014 13:04:10 +0000 From: "Fedyk, Don" To: Ben Niven-Jenkins , "rtg-ads@tools.ietf.org" Subject: RE: RtgDir review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt Thread-Topic: RtgDir review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt Thread-Index: AQHPTcsuEp8NjP2MHUefw+jGDEpVuZsBd6Ow Date: Mon, 7 Apr 2014 13:04:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [16.201.12.26] Content-Type: multipart/mixed; boundary="_003_A46D9C092EA46F489F135060986AD9FFD0A81AG6W2492americashp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/Q4-UAgmomk41yMdWrl2cM_NgJTA X-Mailman-Approved-At: Mon, 07 Apr 2014 06:07:39 -0700 Cc: "l2vpn@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-l2vpn-vpls-ldp-mac-opt.all@tools.ietf.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, 07 Apr 2014 13:04:59 -0000 --_003_A46D9C092EA46F489F135060986AD9FFD0A81AG6W2492americashp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ben Thanks for your review. Attached are the changes so far. Inline [Don] are = my comments. You raise a couple of points that Adrian/Nabil/Giles, other authors should = review before I change anything else. Don -----Original Message----- From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Ben Niven-Jenkins Sent: Tuesday, April 01, 2014 10:07 AM To: rtg-ads@tools.ietf.org Cc: l2vpn@ietf.org; rtg-dir@ietf.org; draft-ietf-l2vpn-vpls-ldp-mac-opt.all= @tools.ietf.org Subject: Fwd: RtgDir review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt Colleagues, I am resending my Routing Directorate review below as I messed up the e-mai= l address for the draft's authors. Ben Begin forwarded message: > From: Ben Niven-Jenkins > Date: 1 April 2014 15:02:25 GMT+01:00 > To: rtg-ads@tools.ietf.org > Cc: rtg-dir@ietf.org, l2vpn@ietf.org, draft-ietf-l2vpn-vpls-ldp-mac-opt-1= 1.all@tools.ietf.org > Subject: RtgDir review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related draf= ts as they pass through IETF last call and IESG review, and sometimes on sp= ecial request. The purpose of the review is to provide assistance to the Ro= uting ADs. For more information about the Routing Directorate, please see h= ttp://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF Last = Call comments that you receive, and strive to resolve them through discussi= on or by updating the draft. > > Document: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt > Reviewer: Ben Niven-Jenkins > Review Date: 1st April 2014 > IETF LC End Date: 8th April 2014 > Intended Status: Standards Track > > Summary: > I have significant concerns about this document and recommend that the Ro= uting ADs discuss these issues further with the authors. > > Comments: > Overall the document is reasonably well written, although many cross-refe= rences to different sections in the draft appear to be wrong. Where I've no= ticed incorrect cross-references I have noted them in the nits section belo= w but I would recommend someone doing a complete pass of the document to en= sure all cross-references refer to the correct section(s). [Don] Updated cross refs to section3.1.1 should be 4.1.1, section 2 should= be section 3 (refers to paragraph 3) Operation considerations is section = 6 . > > From reading the document my opinion is that it suitably describes what i= s required to implement the newly proposed mechanism but it may be hard for= someone to read the document and determine what circumstances would motiva= te using the new optimised MAC flush versus sticking with the original RFC4= 627 [don] 4762 MAC flush mechanism. [Don] It is mentioned in section 3 overview that a simplified LDP MAC messa= ge while it speeds up LDP can adversely affect the native Ethernet forwardi= ng which reverts to flooding of unknown addresses. This is important in rea= l time Etehrnet networks. > > > Major issues: > > I've raised this as a major issue as I think it may require AD input/atte= ntion to resolve. It is not a technical issue but a suggestion for includin= g more explanatory text that I think would help improve the document but wh= ich the AD may decide is not required. > > The document specifies a solution to solve a problem with the mechanism f= or MAC address withdrawal specified in RFC4762 but it doesn't provide any i= ndication of when the new optimised MAC flush that is proposed should be us= ed instead of the existing MAC flush mechanism specified in RFC4627. [Don] One of the debates we had was that for backwards compatibly the worst= you get is the RFC4762 behavior. But if all nodes are updated you can use= the new message and get the optimized MAC flush. However during the cours= e of the draft a more explicit means of specifying the behavior was propose= d to signal compatibility that became its own draft. In order to resolve t= he MAC flush issues, without dependency on a capabilities draft, this draf= t specifies backwards compatibly by requiring the node that supports the o= ptimized MAC flush can also support the old MAC flush. > > The downside of the existing RFC4627 MAC flush mechanism appears to be th= at PEs can end up having to flush many more MAC addresses than absolutely r= equired when a dual homed CE/MTU switches from using the primary spoke PW t= o the backup spoke PW. [Don] Flushing more MACs causes issues with the side effect of traffic that= should not be affected being affected by a change. In order to decouple t= his effect, the optimization reduces unintentional disruption. > > The optimised MAC flush specified in the document solves the problem by m= oving the initiation of the MAC flush message from the 'backup' PE-rs to th= e 'primary' PE-rs and introducing a new message to allow the primary PE-rs = to request other PE-rs in the network flush all MAC addresses learnt via th= e primary PE-rs. > > While the new message means that the PE-rs in the network will flush and = relearn fewer MAC addresses on failure of the primary spoke PW between the = MTU-s & primary PE-rs, it is not clear to me whether it is superior in all = cases. [Don] It does solve cases where dual homing aware PE-rs connect to resilien= t Ethernet networks. This is a case worth solving because those type of net= work usually have strict SLAs. The other cases where other dual homing is= outside of the of the PE-rs was covered for completeness. > > For example, the new optimised MAC flush relies on the primary PE-rs to d= etect the failure of the spoke PW and initiate the optimised MAC flush but = the document doesn't discuss what happens if the failure isn't detected (e.= g. if PE-rs doesn't detect the failure or PE-rs itself fails). My assumptio= n is that the network falls back to relying on aging/timeout of MAC entries= , which presumably means that traffic is blackholed for up to 5 minutes (us= ing default timers). [Don] Yes as mentioned this is not the case this was designed for but was d= escribed for completeness. > > It is also not clear whether this mechanism is designed to replace the me= chanism in RFC4627 or to augment it, although I have assumed the former. [Don] In a case where all nodes supported the optimized flush RFC4627 would= be used but for backwards compatibility the mechanism in RFC4627 is recomm= ended to be retained. > > I therefore think that the document would benefit significantly from: > > a) Some clear text/statement of when the new optimised MAC flush mechanis= m should be used instead of the existing RFC4627 mechanism (e.g. when is a = full RFC4627 MAC flush "bad"). [Don] OK I'll ask Adrian if he would like this highlighted. > > b) Some discussion describing how the new optimised MAC flush mechanism i= s equivalent to the existing mechanism and highlighting any cases where it = may not provide as rapid MAC table updates as the RFC4627 mechanisms. [Don] I don't think we should get into operational specifics of timing. I = know for a fact that the mechanism has been deployed in dual homing aware n= etworks with tight SLAs. Flushing traffic that is unaffected is clearly un= desirable. It really depends on the network scenario where you are flushing= MACs. PBB networks can have 1000s of affected flows. > > > Minor issues: > > 1) The first paragraph of section 3 states: > > When the MTU-s switches over to the backup PW, the requirement is to > flush the MAC addresses learned in the corresponding Virtual Switch > Instance (VSI) in peer PE devices participating in the full mesh, to > avoid black holing of frames to those addresses. This is > accomplished by sending an LDP Address Withdraw Message from the PE > that is no longer connected to the MTU-s with the primary PW, with > the list of MAC addresses to be removed to all other PEs over the > corresponding LDP sessions [RFC4762]. > > Comparing this against Figure 1, my understanding is that the "PE that is= no longer connected to the MTU-s with the primary PW" is PE1-rs. However s= ection 3.1.1 states: > > [RFC4762] specifies that on failure of the primary PW, it is the > PE3-rs (Figure 1) that initiates MAC flush towards the core. > > Which contradicts the first paragraph of section 3? [Don] I see your point here, is what is being described. 1) PE-rs dual homing Aware - Control of dual homing by the PE-RS <- This is 3.1.1 - Control of dual homing by the MTUs <-This is 3. 2) PE-Rs dual homing unaware. [Don] It is up to you Ads & WG chairs to say if this should be highlighted,= I think it covers the cases and I can try make it clearer as above if tha= t helps. > > I think that the first paragraph of section 3 is describing the behaviour= when using the new mechanism described in the draft, but that wasn't clear= to me when I first read the draft, so I would suggest re-wording or adding= some text to make it more explicit when you are describing new behaviour s= pecified in the document versus existing behavior inherited from RFC4762. [Don] The first part of section 3 is describing an existing RFC 4762 messag= e a positive flush by a MTU-s that is dual homing and in control of the dua= l homing. However it is true that a MTU-s using LDP could use the new proc= edures to propagate a flush to the PE-RS in the case of some downstream Dua= l homing and that is not excluded. > > 2) Section 3.2. I'm not sure what the significance of the native ethernet= segment is in this sentence "For example, the case of PE1-rs initiated MAC= flush on failure may arise when the dual-homing segment is native ethernet= as opposed to spoke PWs.". You may want to consider stating what issue it = is that the presence of native ethernet causes. [Don] If the connection is MPLS then there are LDP control messages that c= an propagate MAC status messages and if it is native Ethernet then the PE-R= S has to interpret the messages and convert them to the LDP messages. I th= ink that is all native Ethernet is trying to say but there are multiple way= s Ethernet can do that RSTP, G.8031 etc. > > 3) Section 3.2 goes on to say "In this case the PE-rs devices > that receive the MAC flush from PE1-rs are required to flush all the > MAC addresses learned over the PW connected to PE1-rs. This cannot > be achieved with the MAC Address Withdraw Message defined in > [RFC4762]." > > You may want to consider stating why MAC flush cannot be achieved with th= e MAC Address Withdraw Message defined in RFC4762 (as the lack of ability f= or performing MAC flush in this scenario is presumably the motivation for d= efining the new MAC flush on failure mechanism in the document?). [Don] Reasons from the document are : Many implementations use an LDP withdraw message with an empty MAC list. (M= y interpretation is this is just the way it is.) Section 3.2 states the rational for the MAC flush on failure. That cannot b= e achieved with the RFC4762 message and procedures. > > 4) Section 5.1.2 states > > The MAC withdraw procedures defined in [RFC4762], MTU-s or PE2-rs > SHOULD be sent in cases where the network is being upgraded and > devices are not capable of understanding the optimized MAC flush. > This would result in the same flushing action as [RFC4762] at the > receiving PE-rs devices. > > Which I am struggling to parse. Do you mean something along these lines? > > The MAC withdraw procedures defined in [RFC4762], where either > MTU-s or PE2-rs send the MAC Withdrawl message SHOULD be used > in cases where the network is being upgraded and devices are not > capable of understanding the optimized MAC flush. > This would result in the same flushing action as [RFC4762] at the > receiving PE-rs devices. [Don] Your text is better. This is the recommendation for backward compati= bility since there is no capabilities exchange. > > 5) Section 5.1.2 states > > For the case of B-VPLS devices optimized MAC flush message SHOULD be > supported. > > It's not clear to me what the purpose of this sentence is or what it adds= to the document. [Don] It is historical. RFC 4762 VPLS preceded the deployment of PBB B-VPLS= . But B-VPLS was developed the same time as this draft and the procures h= elp in deployments where there are lots of I-SIDs . So the recommendation = is to use the optimization for PBB deployments. > > 6) Section 5.1.4 states > > This section explains the optimized MAC flush procedure in the > scenario in Figure 2. When the primary spoke PW transition (failure > or standby transition) is detected by PE1-rs, it MAY send MAC flush > messages to PE2-rs, PE3-rs and PE4-rs with MAC Flush TLV and N =3D 1. > > Use of MAY here seems a bit strange to me. I may have misunderstood but i= t seems to me that the document is proposing replacing the existing MAC wit= hdraw mechanisms with this new mechanism, but when using this new mechanism= sending the optimised MAC flush is only a MAY, so what happens when PE1-rs= doesn't send the optimised MAC flush? I assume the fallback is aging/timeo= ut of MAC entries, or is it that the previous MAC withdraw mechanism is als= o being used? [Don] How about: When Optimized MAC flush is being used a PE-rs that is dual homing aware SH= OULD send MAC address messages with MAC Flush TLV and N=3D1 provided the ot= her PEs understand the new messages. > > You may want to consider re-phrasing it along the lines of "When optimise= d MAC flush is being used then " > > > nits: > 1) Section 4 states: > This section describes the problems in detail with respective to > various MAC flush actions described in section 2. [Don] Yes s/2/3/ > Section 2 is the terminology section and doesn't describe any MAC flush a= ctions, do you mean to reference section 3? > > Also I'm not exactly sure what a MAC flush action is. I think you may mea= n: > > This section describes the problems in detail with respect to the > various MAC flush scenarios described in section 3. > > And I think you mean to use 'respect' rather than 'respective'. > > 2) Section 4.1.1, penultimate paragraph says "In the example above, only = the MAC addresses in set X and Y need to be flushed across the core." Y is = not used in the text which confused me for a while until I realised you wer= e referring to Figure 2. You may want to consider making that more explicit= , for example: > > In the example above, only the MAC addresses in set X and Y > (shown in Figure 2) need to be flushed across the core. [Don] Sure. > > 3) Section 4.1.2 starts > > The analysis in section 3.1.1 applies also to the native Ethernet > access into a VPLS. > > I think you may mean to reference section 4.1.1, not 3.1.1? > [Don] I believe you are correct is accurate. Section 3 and section 4 are r= oughly parallel a holdover from before I took over editing. > 4) Section 5 states > > This section describes the solution for the requirements described in > section 4. > > Section 4 doesn't seem to list any requirements as such. Maybe consider r= ewording to something like: > > This section describes a solution for the problem space described in > section 4. [Don] I like your suggestion. > > 5) Section 5.1 states > > The optimization is achieved by > initiating MAC Flush on failure as described in section 2.2. > > and > > The MAC Flush TLV can also > be used for [RFC4762] style of MAC Flush as explained in section 2. > > I think you mean section 3.2 and section 3 respectively. [Don] Yes I think we switched section 3 and section 2 and forgot the refere= nce. No smart tags just me. > > 6) Section 5.1.1 & 5.1.2 cross-reference section 4.2 for details of its u= sage in PBB-VPLS but I think you mean to cross-reference section 5.2. [Don] Changed 4.2 is not completely wrong but 5.2 gives more usage notes. = I'm tempted to reference both but I've change to 5.2. > > 7) Section 5.1.2, 5.1.3 & 5.2.2 cross-references section 5 for operationa= l considerations but I think you mean to cross-reference section 6. [Don] Yes. > > Regards > Ben > --_003_A46D9C092EA46F489F135060986AD9FFD0A81AG6W2492americashp_ Content-Type: text/plain; name="draft-ietf-l2vpn-vpls-ldp-mac-opt-12.txt" Content-Description: draft-ietf-l2vpn-vpls-ldp-mac-opt-12.txt Content-Disposition: attachment; filename="draft-ietf-l2vpn-vpls-ldp-mac-opt-12.txt"; size=57506; creation-date="Fri, 04 Apr 2014 15:16:14 GMT"; modification-date="Mon, 07 Apr 2014 12:59:26 GMT" Content-Transfer-Encoding: base64 IA0KDQoNCg0KTmV0d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFAuIER1dHRhDQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRi4gQmFsdXMNCkludGVuZGVkIHN0YXR1 czogU3RhbmRhcmRzIFRyYWNrICAgICAgICAgICAgICAgICAgICAgICAgICBBbGNhdGVsLUx1Y2Vu dA0KRXhwaXJlczogU2VwdGVtYmVyIDI2LCAyMDE0ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgTy4gU3Rva2VzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEV4dHJlbWUgTmV0d29ya3MNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHLiBDYWx2aW5hYw0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZy YW5jZSBUZWxlY29tDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgTWFyY2ggMjUsIDIwMTQNCg0KDQogICAgIExEUCBFeHRlbnNpb25zIGZv ciBPcHRpbWl6ZWQgTUFDIEFkZHJlc3MgV2l0aGRyYXdhbCBpbiBILVZQTFMNCiAgICAgICAgICAg ICAgICAgIGRyYWZ0LWlldGYtbDJ2cG4tdnBscy1sZHAtbWFjLW9wdC0xMg0KDQpBYnN0cmFjdA0K DQogICBSRkM0NzYyIGRlc2NyaWJlcyBhIG1lY2hhbmlzbSB0byByZW1vdmUgb3IgdW5sZWFybiBN QUMgYWRkcmVzc2VzIHRoYXQNCiAgIGhhdmUgYmVlbiBkeW5hbWljYWxseSBsZWFybmVkIGluIGEg VmlydHVhbCBQcml2YXRlIExBTiBTZXJ2aWNlIChWUExTKQ0KICAgSW5zdGFuY2UgZm9yIGZhc3Rl ciBjb252ZXJnZW5jZSBvbiB0b3BvbG9neSBjaGFuZ2UuICBUaGUgcHJvY2VkdXJlDQogICBhbHNv IHJlbW92ZXMgTUFDIGFkZHJlc3NlcyBpbiB0aGUgVlBMUyB0aGF0IGRvIG5vdCByZXF1aXJlIHJl bGVhcm5pbmcNCiAgIGR1ZSB0byBzdWNoIHRvcG9sb2d5IGNoYW5nZS4gIFRoaXMgZG9jdW1lbnQg ZGVmaW5lcyBhbiBlbmhhbmNlbWVudCB0bw0KICAgdGhlIE1BQyBBZGRyZXNzIFdpdGhkcmF3YWwg cHJvY2VkdXJlIHdpdGggZW1wdHkgTUFDIExpc3QgZnJvbQ0KICAgUkZDNDc2Miwgd2hpY2ggZW5h YmxlcyBhIFByb3ZpZGVyIEVkZ2UoUEUpIGRldmljZSB0byByZW1vdmUgb25seSB0aGUNCiAgIE1B QyBhZGRyZXNzZXMgdGhhdCBuZWVkIHRvIGJlIHJlbGVhcm5lZC4gIEFkZGl0aW9uYWwgZXh0ZW5z aW9ucyB0bw0KICAgUkZDNDc2MiBNQUMgV2l0aGRyYXdhbCBwcm9jZWR1cmVzIGFyZSBzcGVjaWZp ZWQgdG8gcHJvdmlkZSBvcHRpbWl6ZWQNCiAgIE1BQyBmbHVzaGluZyBmb3IgdGhlIFByb3ZpZGVy IEJhY2tib25lIEJyaWRnaW5nIChQQkIpVlBMUyBzcGVjaWZpZWQNCiAgIGluIFJGQzcwNDEuDQoN ClJlcXVpcmVtZW50cyBMYW5ndWFnZQ0KDQogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1Qg Tk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsDQogICAiU0hPVUxEIiwgIlNI T1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcw0K ICAgZG9jdW1lbnQgYXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBbUkZDMjEx OV0uDQoNClN0YXR1cyBvZiB0aGlzIE1lbW8NCg0KICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBz dWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQ0KICAgcHJvdmlzaW9ucyBvZiBC Q1AgNzggYW5kIEJDUCA3OS4NCg0KICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3Vt ZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcNCiAgIFRhc2sgRm9yY2UgKElFVEYpLiAg Tm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlDQogICB3b3JraW5nIGRv Y3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0 LQ0KICAgRHJhZnRzIGlzIGF0IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3Vy cmVudC8uDQoNCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZv ciBhIG1heGltdW0gb2Ygc2l4IG1vbnRocw0KICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNl ZCwgb3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkNCiAgIHRpbWUuICBJdCBp cyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlDQogICBt YXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4i DQoNCiANCg0KDQpEdXR0YSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDI2LCAy MDE0ICAgICAgICAgICAgICAgW1BhZ2UgMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICBPcHRpbWl6 ZWQgTUFDIFdpdGhkcmF3YWwgaW4gSC1WUExTICAgICBNYXJjaCAyNSwgMjAxNA0KDQoNCiAgIFRo aXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gTWF5IDMxLCAyMDE0Lg0KDQogICBDb3B5 cmlnaHQgTm90aWNlDQoNCiAgIENvcHlyaWdodCAoYykgMjAxNCBJRVRGIFRydXN0IGFuZCB0aGUg cGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQ0KICAgZG9jdW1lbnQgYXV0aG9ycy4gIEFsbCByaWdo dHMgcmVzZXJ2ZWQuDQoNCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5k IHRoZSBJRVRGIFRydXN0J3MgTGVnYWwNCiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBE b2N1bWVudHMNCiAgIChodHRwOi8vdHJ1c3RlZS5pZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVm ZmVjdCBvbiB0aGUgZGF0ZSBvZg0KICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBs ZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzDQogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3Jp YmUgeW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QNCiAgIHRvIHRoaXMg ZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudCBt dXN0DQogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQg aW4gU2VjdGlvbiA0LmUgb2YNCiAgIHRoZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUg cHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBhcw0KICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlm aWVkIEJTRCBMaWNlbnNlLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCiANCg0KDQpEdXR0YSwgZXQgYWwuICAgICAgICAgIEV4 cGlyZXMgU2VwdGVtYmVyIDI2LCAyMDE0ICAgICAgICAgICAgICAgW1BhZ2UgMl0NCgwNCkludGVy bmV0LURyYWZ0ICAgICBPcHRpbWl6ZWQgTUFDIFdpdGhkcmF3YWwgaW4gSC1WUExTICAgICBNYXJj aCAyNSwgMjAxNA0KDQoNClRhYmxlIG9mIENvbnRlbnRzDQoNCiAgIDEuICBJbnRyb2R1Y3Rpb24g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMw0KICAg Mi4gIFRlcm1pbm9sb2d5ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICA1DQogICAzLiAgT3ZlcnZpZXcgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDYNCiAgICAgMy4xLiAgTUFDIEZsdXNoIG9uIGFj dGl2YXRpb24gb2YgYmFja3VwIHNwb2tlIFBXIC4gLiAuIC4gLiAuIC4gLiAgNg0KICAgICAgIDMu MS4xLiAgUEUtcnMgaW5pdGlhdGVkIE1BQyBGbHVzaCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICA3DQogICAgICAgMy4xLjIuICBNVFUtcyBpbml0aWF0aWVkIE1BQyBmbHVzaCAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gIDcNCiAgICAgMy4yLiAgTUFDIEZsdXNoIG9uIGZhaWx1cmUg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgOA0KICAgICAzLjMuICBNQUMg Rmx1c2ggaW4gUEJCLVZQTFMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA4 DQogICA0LiAgUHJvYmxlbSBEZXNjcmlwdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gIDkNCiAgICAgNC4xLiAgTUFDIEZsdXNoIE9wdGltaXphdGlvbiBpbiBW UExTIFJlc2lsaWVuY3kgIC4gLiAuIC4gLiAuIC4gLiAgOQ0KICAgICAgIDQuMS4xLiAgTUFDIEZs dXNoIE9wdGltaXphdGlvbiBmb3IgcmVndWxhciBILVZQTFMgIC4gLiAuIC4gLiAuICA5DQogICAg ICAgNC4xLjIuICBNQUMgRmx1c2ggT3B0aW1pemF0aW9uIGZvciBuYXRpdmUgRXRoZXJuZXQgYWNj ZXNzICAuIC4gMTENCiAgICAgNC4yLiAgQmxhY2sgaG9saW5nIGlzc3VlIGluIFBCQi1WUExTIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAxMg0KICAgNS4gIFNvbHV0aW9uIERlc2NyaXB0aW9u IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDEzDQogICAgIDUuMS4g IE1BQyBGbHVzaCBPcHRpbWl6YXRpb24gZm9yIFZQTFMgUmVzaWxpZW5jeSAuIC4gLiAuIC4gLiAu IC4gMTMNCiAgICAgICA1LjEuMS4gIE1BQyBGbHVzaCBQYXJhbWV0ZXJzIFRMViAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAxNA0KICAgICAgIDUuMS4yLiAgQXBwbGljYXRpb24gb2YgTUFD IEZsdXNoIFRMViBpbiBPcHRpbWl6ZWQgTUFDIEZsdXNoICAuIDE1DQogICAgICAgNS4xLjMuICBN QUMgRmx1c2ggVExWIFByb2Nlc3NpbmcgUnVsZXMgZm9yIFJlZ3VsYXIgVlBMUyAgLiAuIC4gMTUN CiAgICAgICA1LjEuNC4gIE9wdGltaXplZCBNQUMgRmx1c2ggUHJvY2VkdXJlcyAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAxNg0KICAgICA1LjIuICBMRFAgTUFDIEZsdXNoIEV4dGVuc2lvbnMgZm9y IFBCQi1WUExTICAuIC4gLiAuIC4gLiAuIC4gLiAuIDE3DQogICAgICAgNS4yLjEuICBNQUMgRmx1 c2ggVExWIFByb2Nlc3NpbmcgUnVsZXMgZm9yIFBCQi1WUExTICAuIC4gLiAuIC4gMTgNCiAgICAg ICA1LjIuMi4gIEFwcGxpY2FiaWxpdHkgb2YgTUFDIEZsdXNoIFBhcmFtZXRlcnMgVExWICAuIC4g LiAuIC4gLiAyMA0KICAgNi4gIE9wZXJhdGlvbmFsIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDIwDQogICA3LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjENCiAgICAgNy4xIE5l dyBMRFAgVExWICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAyMQ0KICAgICA3LjIgTmV3IFJlZ2lzdHJ5IGZvciBNQUMgRmx1c2ggRmxhZ3MgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIDIxDQogICA4LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjENCiAgIDkuICBDb250cmlidXRp bmcgQXV0aG9ycyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMg0K ICAgMTAuICBBY2tub3dsZWRnZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIDIyDQogICAxMS4gIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjINCiAgICAgMTEuMS4gIE5vcm1hdGl2ZSBS ZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAyMg0KICAgICAx MS4yLiAgSW5mb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIDIyDQogICBBdXRob3JzJyBBZGRyZXNzZXMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMjMNCg0KDQoNCg0KMS4gIEludHJvZHVjdGlvbg0KDQog ICBBIG1ldGhvZCBvZiBWaXJ0dWFsIFByaXZhdGUgTEFOIFNlcnZpY2UgKFZQTFMpLCBhbHNvIGtu b3duIGFzDQogICBUcmFuc3BhcmVudCBMQU4gU2VydmljZSAoVExTKSBpcyBkZXNjcmliZWQgaW4g W1JGQzQ3NjJdLiAgQSBWUExTIGlzDQogICBjcmVhdGVkIHVzaW5nIGEgY29sbGVjdGlvbiBvZiBv bmUgb3IgbW9yZSBwb2ludC10by1wb2ludCBwc2V1ZG93aXJlcw0KICAgKFBXcykgW1JGQzQ2NjRd IGNvbmZpZ3VyZWQgaW4gYSBmbGF0LCBmdWxsLW1lc2ggdG9wb2xvZ3kuICBUaGUgbWVzaA0KICAg dG9wb2xvZ3kgcHJvdmlkZXMgYSBMQU4gc2VnbWVudCBvciBicm9hZGNhc3QgZG9tYWluIHRoYXQg aXMgZnVsbHkNCiAgIGNhcGFibGUgb2YgbGVhcm5pbmcgYW5kIGZvcndhcmRpbmcgb24gRXRoZXJu ZXQgTUFDIGFkZHJlc3NlcyBhdCB0aGUNCiAgIFBFIGRldmljZXMuDQogDQoNCg0KRHV0dGEsIGV0 IGFsLiAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyNiwgMjAxNCAgICAgICAgICAgICAgIFtQ YWdlIDNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgT3B0aW1pemVkIE1BQyBXaXRoZHJhd2FsIGlu IEgtVlBMUyAgICAgTWFyY2ggMjUsIDIwMTQNCg0KDQogICBUaGlzIFZQTFMgZnVsbCBtZXNoIGNv cmUgY29uZmlndXJhdGlvbiBjYW4gYmUgYXVnbWVudGVkIHdpdGgNCiAgIGFkZGl0aW9uYWwgbm9u LW1lc2hlZCBzcG9rZSBub2RlcyB0byBwcm92aWRlIGEgSGllcmFyY2hpY2FsIFZQTFMNCiAgIChI LVZQTFMpIHNlcnZpY2UgW1JGQzQ3NjJdLiAgVGhyb3VnaG91dCB0aGlzIGRvY3VtZW50IHRoaXMN CiAgIGNvbmZpZ3VyYXRpb24gaXMgcmVmZXJyZWQgdG8gYXMgInJlZ3VsYXIiIEgtVlBMUy4NCg0K ICAgW1JGQzcwNDFdIGRlc2NyaWJlcyBob3cgUHJvdmlkZXIgQmFja2JvbmUgQnJpZGdpbmcgKFBC QikgY2FuIGJlDQogICBpbnRlZ3JhdGVkIHdpdGggVlBMUyB0byBhbGxvdyBmb3IgdXNlZnVsIFBC QiBjYXBhYmlsaXRpZXMgd2hpbGUNCiAgIGNvbnRpbnVpbmcgdG8gYXZvaWQgdGhlIHVzZSBvZiBN dWx0aXBsZSBTcGFubmluZyBUcmVlIFByb3RvY29sIChNU1RQKQ0KICAgaW4gdGhlIGJhY2tib25l LiAgVGhlIGNvbWJpbmVkIHNvbHV0aW9uIHJlZmVycmVkIHRvIGFzIFBCQi1WUExTDQogICByZXN1 bHRzIGluIGJldHRlciBzY2FsYWJpbGl0eSBpbiB0ZXJtcyBvZiBudW1iZXIgb2Ygc2VydmljZQ0K ICAgaW5zdGFuY2VzLCBQV3MgYW5kIEMtTUFDIChDdXN0b21lciBNQUMpIEFkZHJlc3NlcyB0aGF0 IG5lZWQgdG8gYmUNCiAgIGhhbmRsZWQgaW4gdGhlIFZQTFMgUEVzIGRlcGVuZGluZyBvbiB0aGUg bG9jYXRpb24gb2YgdGhlIEktY29tcG9uZW50DQogICBpbiB0aGUgUEJCLVZQTFMgdG9wb2xvZ3ku DQoNCiAgIEEgTUFDIEFkZHJlc3MgV2l0aGRyYXdhbCBtZWNoYW5pc20gZm9yIFZQTFMgaXMgZGVz Y3JpYmVkIGluIFtSRkM0NzYyXQ0KICAgdG8gcmVtb3ZlIG9yIHVubGVhcm4gTUFDIGFkZHJlc3Nl cyBmb3IgZmFzdGVyIGNvbnZlcmdlbmNlIG9uIHRvcG9sb2d5DQogICBjaGFuZ2UgaW4gcmVzaWxp ZW50IEgtVlBMUyB0b3BvbG9naWVzLiAgTm90ZSB0aGF0IHRoZSBILVZQTFMgdG9wb2xvZ3kNCiAg IGluIFtSRkM0NzYyXSBkZXNjcmliZXMgdHdvIHRpZXIgaGllcmFyY2h5IHRvIFZQTFMgYXMgdGhl IGJhc2ljDQogICBidWlsZGluZyBibG9jayBvZiBILVZQTFMsIGJ1dCBpdCBpcyBwb3NzaWJsZSB0 byBoYXZlIG11bHRpLXRpZXINCiAgIGhpZXJhcmNoeSBpbiBhbiBILVZQTFMuDQoNCg0KICAgVGhl IGZpZ3VyZSAxLiBkZXNjcmliZWQgYmVsb3cgaXMgdGFrZW4gZnJvbSBbUkZDNDc2Ml0gdGhhdCBk ZXNjcmliZXMNCiAgIGR1YWwtaG9taW5nIGluIEgtVlBMUy4NCg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUEUyLXJzDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0t LS0tKw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgLS0gICB8DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgLyAgXCAgfA0KICAgICAgQ0UtMSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIFxTIC8gIHwN CiAgICAgICAgXCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8ICAgLS0gICB8DQogICAgICAgICBcICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKy0tLS0tLS0tKw0KICAgICAgICAgIFwgIE1UVS1zICAgICAgICAgICAg ICAgICAgICAgICAgICBQRTEtcnMgICAgICAgIC8gICB8DQogICAgICAgICAgKy0tLS0tLS0tKyAg ICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0rICAgICAvICAgIHwNCiAgICAgICAgICB8ICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgIHwgICAgLyAgICAgfA0KICAgICAg ICAgIHwgICAtLSAgIHwgICBQcmltYXJ5IFBXICAgICAgICAgfCAgIC0tICAgfC0tLS8gICAgICB8 DQogICAgICAgICAgfCAgLyAgXCAgfC0gLSAtIC0gLSAtIC0gLSAtIC0gLSB8ICAvICBcICB8ICAg ICAgICAgIHwNCiAgICAgICAgICB8ICBcUyAvICB8ICAgICAgICAgICAgICAgICAgICAgIHwgIFxT IC8gIHwgICAgICAgICAgfA0KICAgICAgICAgIHwgICAtLSAgIHwgICAgICAgICAgICAgICAgICAg ICAgfCAgIC0tICAgfC0tLVwgICAgICB8DQogICAgICAgICAgKy0tLS0tLS0tKyAgICAgICAgICAg ICAgICAgICAgICArLS0tLS0tLS0rICAgIFwgICAgIHwNCiAgICAgICAgICAgIC8gICAgICBcICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFwgICAgfA0KICAgICAgICAgICAvICAg ICAgICBcICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLSsNCiAg ICAgICAgICAvICAgICAgICAgIFwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICAgICAgICB8DQogICAgICAgICBDRS0yICAgICAgICAgXCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCAgLS0gICAgfA0KICAgICAgICAgICAgICAgICAgICAgICBcICAgICBTZWNv bmRhcnkgUFcgICAgICAgICAgICAgICAgIHwgLyAgXCAgIHwNCiAgICAgICAgICAgICAgICAgICAg ICAgIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSAtIC0gLSB8IFxTIC8gICB8DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgLS0g ICAgfA0KIA0KDQoNCkR1dHRhLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjYs IDIwMTQgICAgICAgICAgICAgICBbUGFnZSA0XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgIE9wdGlt aXplZCBNQUMgV2l0aGRyYXdhbCBpbiBILVZQTFMgICAgIE1hcmNoIDI1LCAyMDE0DQoNCg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICst LS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFBFMy1ycw0KICAgICAgICAgICAgICAgICBGaWd1cmUgMTogQW4gZXhhbXBs ZSBvZiBhIGR1YWwtaG9tZWQgTVRVLXMNCg0KICAgQW4gZXhhbXBsZSBvZiB1c2FnZSBvZiB0aGUg TUFDIEZsdXNoIG1lY2hhbmlzbSBpcyB0aGUgZHVhbC1ob21lZA0KICAgSC1WUExTIHdoZXJlIGFu IGVkZ2UgZGV2aWNlIHRlcm1lZCBhcyBNVFUtcyBpcyBjb25uZWN0ZWQgdG8gdHdvIFBFDQogICBk ZXZpY2VzIHZpYSBwcmltYXJ5IHNwb2tlIFBXIGFuZCBiYWNrdXAgc3Bva2UgUFcgcmVzcGVjdGl2 ZWx5LiAgU3VjaA0KICAgcmVkdW5kYW5jeSBpcyBkZXNpZ25lZCB0byBwcm90ZWN0IGFnYWluc3Qg dGhlIGZhaWx1cmUgb2YgcHJpbWFyeQ0KICAgc3Bva2UgUFcgb3IgcHJpbWFyeSBQRSBkZXZpY2Uu ICBUaGVyZSBjb3VsZCBiZSBtdWx0aXBsZSBtZXRob2RzIG9mDQogICBkdWFsIGhvbWluZyBpbiBI LVZQTFMgdGhhdCBhcmUgbm90IGRlc2NyaWJlZCBpbiBbUkZDNDc2Ml0uICBGb3INCiAgIGV4YW1w bGUsIG5vdGUgdGhlIGZvbGxvd2luZyBzdGF0ZW1lbnQgZnJvbSBzZWN0aW9uIDEwLjIuMSBpbg0K ICAgW1JGQzQ3NjJdLg0KDQogICAiSG93IGEgc3Bva2UgaXMgZGVzaWduYXRlZCBwcmltYXJ5IG9y IHNlY29uZGFyeSBpcyBvdXRzaWRlIHRoZSBzY29wZQ0KICAgb2YgdGhpcyBkb2N1bWVudC4gIEZv ciBleGFtcGxlLCBhIHNwYW5uaW5nIHRyZWUgaW5zdGFuY2UgcnVubmluZw0KICAgYmV0d2VlbiBv bmx5IHRoZSBNVFUtcyBhbmQgdGhlIHR3byBQRS1ycyBub2RlcyBpcyBvbmUgcG9zc2libGUNCiAg IG1ldGhvZC4gIEFub3RoZXIgbWV0aG9kIGNvdWxkIGJlIGNvbmZpZ3VyYXRpb24iLg0KDQogICBU aGlzIGRvY3VtZW50IGludGVuZHMgdG8gY2xhcmlmeSBzZXZlcmFsIEgtVlBMUyBkdWFsLWhvbWlu ZyBtb2RlbHMNCiAgIHRoYXQgYXJlIGRlcGxveWVkIGluIHByYWN0aWNlIGFuZCB2YXJpb3VzIHVz ZSBjYXNlcyBvZiBMRFAgYmFzZWQgTUFDDQogICBmbHVzaCBpbiB0aGVzZSBtb2RlbHMuDQoyLiAg VGVybWlub2xvZ3kNCg0KDQogICBUaGlzIGRvY3VtZW50IHVzZXMgdGhlIHRlcm1pbm9sb2d5IGRl ZmluZWQgaW4gW1JGQzcwNDFdLCBbUkZDNTAzNl0sDQogICBbUkZDNDQ0N10gYW5kIFtSRkM0NzYy XS4NCg0KICAgVGhyb3VnaG91dCB0aGlzIGRvY3VtZW50IFZpcnR1YWwgUHJpdmF0ZSBMQU4gU2Vy dmljZSAoVlBMUykgbWVhbnMgdGhlDQogICBlbXVsYXRlZCBicmlkZ2VkIExBTiBzZXJ2aWNlIG9m ZmVyZWQgdG8gYSBjdXN0b21lci4gIEgtVlBMUyBtZWFucyB0aGUNCiAgIGhpZXJhcmNoaWNhbCBj b25uZWN0aXZpdHkgb3IgbGF5b3V0IG9mIE11bHRpIFRlbmFudCBVbml0IHN3aXRjaCAoTVRVLQ0K ICAgcykgYW5kIFByb3ZpZGVyIEVkZ2UgUm91dGluZyBhbmQgc3dpdGNoaW5nIGNhcGFibGUgKFBF LXJzKSBkZXZpY2VzDQogICBvZmZlcmluZyB0aGUgVlBMUyBbUkZDNDc2Ml0uDQoNCiAgIFRoZSB0 ZXJtcyAiU3Bva2UgTm9kZSIgYW5kICJNVFUtcyIgaW4gSC1WUExTIGFyZSB1c2VkDQogICBpbnRl cmNoYW5nZWFibHkuDQoNCiAgICJTcG9rZSBQVyIgbWVhbnMgdGhlIFBzZXVkb3dpcmUgUFcgdGhh dCBwcm92aWRlcyBjb25uZWN0aXZpdHkgYmV0d2Vlbg0KICAgTVRVLXMgYW5kIFBFLXJzIG5vZGVz Lg0KDQogICAiTWVzaCBQVyIgbWVhbnMgdGhlIFBXIHRoYXQgcHJvdmlkZXMgY29ubmVjdGl2aXR5 IGJldHdlZW4gUEUtcnMgbm9kZXMNCiAgIGluIGEgVlBMUyBmdWxsIG1lc2ggY29yZS4NCg0KICAg Ik1BQyBGbHVzaCBNZXNzYWdlIiBtZWFucyBMYWJlbCBEaXN0cmlidXRpb24gUHJvdG9jb2wgKExE UCkgQWRkcmVzcw0KICAgV2l0aGRyYXcgTWVzc2FnZSB3aXRob3V0IE1BQyBMaXN0IFRMVi4NCg0K ICAgTUFDIEZsdXNoIE1lc3NhZ2UgaW4gdGhlICJjb250ZXh0IG9mIGEgUHNldWRvIFdpcmUgKFBX KSIgbWVhbnMgdGhlDQogICBNZXNzYWdlIHRoYXQgaGFzIGJlZW4gcmVjZWl2ZWQgb3ZlciB0aGUg TERQIHNlc3Npb24gdGhhdCBpcyB1c2VkIHRvDQogICBzZXQgdXAgdGhlIFBXIHVzZWQgdG8gcHJv dmlkZSBjb25uZWN0aXZpdHkgaW4gVlBMUy4gIFRoZSBNQUMgRmx1c2gNCiANCg0KDQpEdXR0YSwg ZXQgYWwuICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDI2LCAyMDE0ICAgICAgICAgICAgICAg W1BhZ2UgNV0NCgwNCkludGVybmV0LURyYWZ0ICAgICBPcHRpbWl6ZWQgTUFDIFdpdGhkcmF3YWwg aW4gSC1WUExTICAgICBNYXJjaCAyNSwgMjAxNA0KDQoNCiAgIE1lc3NhZ2UgY2FycmllcyB0aGUg Y29udGV4dCBvZiB0aGUgUFcgaW4gdGVybXMgb2YgRm9yd2FyZGluZw0KICAgRXF1aXZhbGVuY2Ug Q2xhc3MgKEZFQykgVExWIGFzc29jaWF0ZWQgd2l0aCB0aGUgUFcNCiAgIFtSRkM0NzYyXVtSRkM0 NDQ3XS4NCg0KICAgSW4gZ2VuZXJhbCwgIk1BQyBGbHVzaCIgbWVhbnMgdGhlIG1ldGhvZCBvZiBp bml0aWF0aW5nIGFuZCBwcm9jZXNzaW5nDQogICBvZiBNQUMgRmx1c2ggTWVzc2FnZXMgYWNyb3Nz IGEgVlBMUyBpbnN0YW5jZS4NCg0KMy4gIE92ZXJ2aWV3DQoNCiAgIFdoZW4gdGhlIE1UVS1zIHN3 aXRjaGVzIG92ZXIgdG8gdGhlIGJhY2t1cCBQVywgdGhlIHJlcXVpcmVtZW50IGlzIHRvDQogICBm bHVzaCB0aGUgTUFDIGFkZHJlc3NlcyBsZWFybmVkIGluIHRoZSBjb3JyZXNwb25kaW5nIFZpcnR1 YWwgU3dpdGNoDQogICBJbnN0YW5jZSAoVlNJKSBpbiBwZWVyIFBFIGRldmljZXMgcGFydGljaXBh dGluZyBpbiB0aGUgZnVsbCBtZXNoLCB0bw0KICAgYXZvaWQgYmxhY2sgaG9saW5nIG9mIGZyYW1l cyB0byB0aG9zZSBhZGRyZXNzZXMuICBUaGlzIGlzDQogICBhY2NvbXBsaXNoZWQgYnkgc2VuZGlu ZyBhbiBMRFAgQWRkcmVzcyBXaXRoZHJhdyBNZXNzYWdlIGZyb20gdGhlIFBFDQogICB0aGF0IGlz IG5vIGxvbmdlciBjb25uZWN0ZWQgdG8gdGhlIE1UVS1zIHdpdGggdGhlIHByaW1hcnkgUFcsIHdp dGgNCiAgIHRoZSBsaXN0IG9mIE1BQyBhZGRyZXNzZXMgdG8gYmUgcmVtb3ZlZCB0byBhbGwgb3Ro ZXIgUEVzIG92ZXIgdGhlDQogICBjb3JyZXNwb25kaW5nIExEUCBzZXNzaW9ucyBbUkZDNDc2Ml0u DQoNCiAgIEluIG9yZGVyIHRvIG1pbmltaXplIHRoZSBpbXBhY3Qgb24gTERQIGNvbnZlcmdlbmNl IHRpbWUgYW5kDQogICBzY2FsYWJpbGl0eSB3aGVuIGEgTUFDIExpc3QgVExWIGNvbnRhaW5zIGEg bGFyZ2UgbnVtYmVyIG9mIE1BQw0KICAgYWRkcmVzc2VzLCBtYW55IGltcGxlbWVudGF0aW9ucyB1 c2UgYSBMRFAgQWRkcmVzcyBXaXRoZHJhdyBNZXNzYWdlDQogICB3aXRoIGFuIGVtcHR5IE1BQyBM aXN0LiAgVGhyb3VnaG91dCB0aGlzIGRvY3VtZW50IHRoZSB0ZXJtICJNQUMgRmx1c2gNCiAgIE1l c3NhZ2UiIGlzIHVzZWQgdG8gc3BlY2lmeSBMRFAgQWRkcmVzcyBXaXRoZHJhdyBNZXNzYWdlIHdp dGggYW4NCiAgIGVtcHR5IE1BQyBMaXN0IGRlc2NyaWJlZCBpbiBbUkZDNDc2Ml0gdW5sZXNzIHNw ZWNpZmllZCBvdGhlcndpc2UuIFRoZQ0KICAgc29sdXRpb25zIGRlc2NyaWJlZCBpbiB0aGlzIGRv Y3VtZW50IGFyZSBhcHBsaWNhYmxlIG9ubHkgdG8gTERQDQogICBBZGRyZXNzIFdpdGhkcmF3IE1l c3NhZ2Ugd2l0aCBlbXB0eSBNQUMgTGlzdC4NCg0KICAgSW4gYSBWUExTIHRvcG9sb2d5LCB0aGUg Y29yZSBQV3MgcmVtYWluIGFjdGl2ZSBhbmQgbGVhcm5pbmcgaGFwcGVucw0KICAgb24gdGhlIFBF LXJzIG5vZGVzLiAgSG93ZXZlciB3aGVuIHRoZSBWUExTIHRvcG9sb2d5IGNoYW5nZXMsIHRoZQ0K ICAgUEUtcnMgbXVzdCByZWxlYXJuIHVzaW5nIE1BQyBBZGRyZXNzZXMgd2l0aGRyYXdhbCBvciBm bHVzaC4gIEFzIHBlcg0KICAgdGhlIE1BQyBBZGRyZXNzIFdpdGhkcmF3YWwgcHJvY2Vzc2luZyBy dWxlcyBpbiBbUkZDNDc2Ml0gYSBQRSBkZXZpY2UNCiAgIG9uIHJlY2VpdmluZyBhIE1BQyBGbHVz aCBNZXNzYWdlIHJlbW92ZXMgYWxsIE1BQyBhZGRyZXNzZXMgYXNzb2NpYXRlZA0KICAgd2l0aCB0 aGUgc3BlY2lmaWVkIFZQTFMgaW5zdGFuY2UgKGFzIGluZGljYXRlZCBpbiB0aGUgRkVDIFRMVikg ZXhjZXB0DQogICB0aGUgTUFDIGFkZHJlc3NlcyBsZWFybmVkIG92ZXIgdGhlIFBXIGFzc29jaWF0 ZWQgd2l0aCB0aGlzIHNpZ25hbGluZw0KICAgc2Vzc2lvbiBvdmVyIHdoaWNoIHRoZSBtZXNzYWdl IHdhcyByZWNlaXZlZC4gIFRocm91Z2hvdXQgdGhpcw0KICAgZG9jdW1lbnQgd2UgdXNlIHRoZSB0 ZXJtaW5vbG9neSAiUG9zaXRpdmUiIE1BQyBGbHVzaCBvciAiRmx1c2gtYWxsLQ0KICAgYnV0LW1p bmUiIGZvciB0aGlzIHR5cGUgb2YgTUFDIEZsdXNoIE1lc3NhZ2UgYW5kIGl0cyBhY3Rpb25zLg0K DQozLjEuICBNQUMgRmx1c2ggb24gYWN0aXZhdGlvbiBvZiBiYWNrdXAgc3Bva2UgUFcNCg0KICAg VGhpcyBzZWN0aW9uIGRlc2NyaWJlcyBzY2VuYXJpb3Mgd2hlcmUgTUFDIEZsdXNoIHdpdGhkcmF3 YWwgaXMNCiAgIGluaXRpYXRlZCBvbiBhY3RpdmF0aW9uIG9mIGJhY2t1cCBQVyBpbiBILVZQTFMu DQoNCg0KDQoNCg0KDQogDQoNCg0KRHV0dGEsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIFNlcHRl bWJlciAyNiwgMjAxNCAgICAgICAgICAgICAgIFtQYWdlIDZdDQoMDQpJbnRlcm5ldC1EcmFmdCAg ICAgT3B0aW1pemVkIE1BQyBXaXRoZHJhd2FsIGluIEgtVlBMUyAgICAgTWFyY2ggMjUsIDIwMTQN Cg0KDQozLjEuMS4gIFBFLXJzIGluaXRpYXRlZCBNQUMgRmx1c2gNCg0KDQoNCiAgIFtSRkM0NzYy XSBzcGVjaWZpZXMgdGhhdCBvbiBmYWlsdXJlIG9mIHRoZSBwcmltYXJ5IFBXLCBpdCBpcyB0aGUN CiAgIFBFMy1ycyAoRmlndXJlIDEpIHRoYXQgaW5pdGlhdGVzIE1BQyBmbHVzaCB0b3dhcmRzIHRo ZSBjb3JlLiAgSG93ZXZlcg0KICAgbm90ZSB0aGF0IFBFMy1ycyBjYW4gaW5pdGlhdGUgTUFDIEZs dXNoIG9ubHkgd2hlbiBQRTMtcnMgaXMgZHVhbA0KICAgaG9taW5nICJhd2FyZSIgLSB0aGF0IGlz LCB0aGVyZSBpcyBzb21lIHJlZHVuZGFuY3kgbWFuYWdlbWVudA0KICAgcHJvdG9jb2wgcnVubmlu ZyBiZXR3ZWVuIE1UVS1zIGFuZCBpdHMgaG9zdCBQRS1ycyBkZXZpY2VzLiAgVGhlIHNjb3BlDQog ICBvZiB0aGlzIGRvY3VtZW50IGlzIG5vdCBzcGVjaWZpYyB0byBhbnkgZHVhbCBob21pbmcgcHJv dG9jb2xzLiAgT25lDQogICBleGFtcGxlIGNvdWxkIGJlIEJHUCBiYXNlZCBtdWx0aS1ob21pbmcg aW4gTERQIGJhc2VkIFZQTFMgdGhhdCB1c2VzDQogICB0aGUgcHJvY2VkdXJlcyBkZWZpbmVkIGlu IFtJLUQuaWV0Zi1sMnZwbi12cGxzLW11bHRpaG9taW5nXS4gIEluIHRoaXMNCiAgIG1ldGhvZCBv ZiBkdWFsLWhvbWluZywgUEUzLXJzIHdvdWxkIG5laXRoZXIgZm9yd2FyZCBhbnkgdHJhZmZpYyB0 bw0KICAgTVRVLXMgbm9yIHdvdWxkIGl0IHJlY2VpdmUgYW55IHRyYWZmaWMgZnJvbSBNVFUtcyB3 aGlsZSBQRTEtcnMgaXMNCiAgIGFjdGluZyBhcyBhIHByaW1hcnkgKG9yIGRlc2lnbmF0ZWQgZm9y d2FyZGVyKS4NCg0KMy4xLjIuICBNVFUtcyBpbml0aWF0aWVkIE1BQyBmbHVzaA0KDQogICBXaGVu IGR1YWwgaG9taW5nIGlzIGFjaGlldmVkIGJ5IG1hbnVhbCBjb25maWd1cmF0aW9uIGluIE1UVS1z LCB0aGUNCiAgIGhvc3RpbmcgUEUtcnMgZGV2aWNlcyBhcmUgZHVhbCBob21pbmcgImFnbm9zdGlj IiBhbmQgUEUzLXJzIGNhbiBub3QNCiAgIGluaXRpYXRlIE1BQyBGbHVzaCBtZXNzYWdlLiAgUEUz LXJzIGNhbiBzZW5kIG9yIHJlY2VpdmUgdHJhZmZpYyBvdmVyDQogICB0aGUgYmFja3VwIFBXIHNp bmNlIHRoZSBkdWFsLWhvbWluZyBjb250cm9sIGlzIHdpdGggTVRVLXMgb25seS4gIFdoZW4NCiAg IHRoZSBiYWNrdXAgUFcgaXMgbWFkZSBhY3RpdmUgYnkgdGhlIE1UVS1zLCB0aGUgTVRVLXMgdHJp Z2dlcnMgTUFDDQogICBGbHVzaCBNZXNzYWdlLiAgVGhlIG1lc3NhZ2UgaXMgc2VudCBvdmVyIHRo ZSBMRFAgc2Vzc2lvbiBhc3NvY2lhdGVkDQogICB3aXRoIHRoZSBuZXdseSBhY3RpdmF0ZWQgUFcu ICBPbiByZWNlaXZpbmcgdGhlIE1BQyBGbHVzaCBNZXNzYWdlIGZyb20NCiAgIE1UVS1zLCBQRTMt cnMgKFBFLXJzIGRldmljZSB3aXRoIG5vdy1hY3RpdmUgUFcpIHdvdWxkIGZsdXNoIGFsbCB0aGUN CiAgIE1BQyBhZGRyZXNzZXMgaXQgaGFzIGxlYXJuZWQgZXhjZXB0IHRoZSBvbmVzIGxlYXJuZWQg b3ZlciB0aGUgbmV3bHkNCiAgIGFjdGl2YXRlZCBzcG9rZSBQVy4gIFBFMy1ycyBmdXJ0aGVyIGlu aXRpYXRlcyBhIE1BQyBGbHVzaCBNZXNzYWdlIHRvDQogICBhbGwgb3RoZXIgUEUgZGV2aWNlcyBp biB0aGUgY29yZS4gIE5vdGUgdGhhdCBmb3JjZWQgc3dpdGNob3ZlciB0bw0KICAgYmFja3VwIFBX IGNhbiBiZSBhbHNvIHBlcmZvcm1lZCBhdCBNVFUtcyBhZG1pbmlzdHJhdGl2ZWx5IGR1ZSB0bw0K ICAgbWFpbnRlbmFuY2UgYWN0aXZpdGllcyBvbiB0aGUgZm9ybWVyIHByaW1hcnkgc3Bva2UgUFcu DQoNCiAgIE1UVS1zIGluaXRpYXRlZCBtZXRob2Qgb2YgTUFDIGZsdXNoaW5nIGlzIG1vZGVsZWQg YWZ0ZXIgVG9wb2xvZ3kNCiAgIENoYW5nZSBOb3RpZmljYXRpb24gKFRDTikgaW4gUmFwaWQgU3Bh bm5pbmcgVHJlZSBQcm90b2NvbCAoUlNUUCkNCiAgIFtJRUVFLjgwMi4xUS0yMDExXS4gIFdoZW4g YSBicmlkZ2Ugc3dpdGNoZXMgZnJvbSBhIGZhaWxlZCBsaW5rIHRvIHRoZQ0KICAgYmFja3VwIGxp bmssIHRoZSBicmlkZ2Ugc2VuZHMgb3V0IGEgVENOIG1lc3NhZ2Ugb3ZlciB0aGUgbmV3bHkNCiAg IGFjdGl2YXRlZCBsaW5rLiAgVGhlIHVwc3RyZWFtIGJyaWRnZSB1cG9uIHJlY2VpdmluZyB0aGlz IG1lc3NhZ2UNCiAgIGZsdXNoZXMgaXRzIGVudGlyZSBNQUMgYWRkcmVzc2VzIGV4Y2VwdCB0aGUg b25lcyByZWNlaXZlZCBvdmVyIHRoaXMNCiAgIGxpbmsgYW5kIHNlbmRzIHRoZSBUQ04gbWVzc2Fn ZSBvdXQgb2YgaXRzIG90aGVyIHBvcnRzIGluIHRoYXQNCiAgIHNwYW5uaW5nIHRyZWUgaW5zdGFu Y2UuICBUaGUgbWVzc2FnZSBpcyBmdXJ0aGVyIHJlbGF5ZWQgYWxvbmcgdGhlDQogICBzcGFubmlu ZyB0cmVlIGJ5IHRoZSBvdGhlciBicmlkZ2VzLg0KDQogICBUaGUgTUFDIEZsdXNoIGluZm9ybWF0 aW9uIGlzIHByb3BhZ2F0ZWQgaW4gdGhlIGNvbnRyb2wgcGxhbmUuICBUaGUNCiAgIGNvbnRyb2wg cGxhbmUgbWVzc2FnZSBwcm9wYWdhdGlvbiBpcyBhc3NvY2lhdGVkIHdpdGggdGhlIGRhdGEgcGF0 aA0KICAgYW5kIGhlbmNlIGZvbGxvd3Mgc2ltaWxhciBydWxlcyBmb3IgcHJvcGFnYXRpb24gYXMg dGhlIGZvcndhcmRpbmcgaW4NCiAgIHRoZSBMRFAgZGF0YSBwbGFuZS4gIEZvciBleGFtcGxlIFBF LXJzIG5vZGVzIGZvbGxvdyB0aGUgZGF0YSBwbGFuZQ0KICAgInNwbGl0LWhvcml6b24iIGZvcndh cmRpbmcgcnVsZXMgaW4gSC1WUExTIChSZWZlciB0byBzZWN0aW9uIDQuNCBpbg0KICAgW1JGQzQ3 NjJdKS4gIFRoZXJlZm9yZSBhIE1BQyBGbHVzaCBpcyBwcm9wYWdhdGVkIGluIHRoZSBjb250ZXh0 IG9mDQogDQoNCg0KRHV0dGEsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyNiwg MjAxNCAgICAgICAgICAgICAgIFtQYWdlIDddDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgT3B0aW1p emVkIE1BQyBXaXRoZHJhd2FsIGluIEgtVlBMUyAgICAgTWFyY2ggMjUsIDIwMTQNCg0KDQogICBt ZXNoIFBXKHMpIHdoZW4gaXQgaXMgcmVjZWl2ZWQgaW4gdGhlIGNvbnRleHQgb2YgYSBzcG9rZSBQ Vy4gIFdoZW4gYQ0KICAgUEUtcnMgbm9kZSByZWNlaXZlcyBhIE1BQyBGbHVzaCBpbiB0aGUgY29u dGV4dCBvZiBhIG1lc2ggUFcgdGhlbiBpdA0KICAgaXMgbm90IHByb3BhZ2F0ZWQgdG8gb3RoZXIg bWVzaCBQV3MuDQoNCiAgIElycmVzcGVjdGl2ZSBvZiB3aGV0aGVyIGEgTUFDIEZsdXNoIGlzIGlu aXRpYXRlZCBieSBhIFBFLXJzIG9yIE1UVS1zLA0KICAgd2hlbiBhIFBFLXJzIGRldmljZSBpbiB0 aGUgZnVsbC1tZXNoIG9mIEgtVlBMUyByZWNlaXZlcyBhIE1BQyBmbHVzaA0KICAgbWVzc2FnZSBp dCBhbHNvIGZsdXNoZXMgTUFDIGFkZHJlc3NlcyB3aGljaCBhcmUgbm90IGFmZmVjdGVkIGR1ZSB0 bw0KICAgdG9wb2xvZ3kgY2hhbmdlLCB0aHVzIGxlYWRpbmcgdG8gdW5uZWNlc3NhcnkgZmxvb2Rp bmcgYW5kIHJlbGVhcm5pbmcuDQogICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhbiBvcHRpb25h bCBtZWNoYW5pc20gdG8gb3B0aW1pemUgdGhlIE1BQw0KICAgZmx1c2ggcHJvY2VkdXJlIGluIFtS RkM0NzYyXSBzbyB0aGF0IGl0IGZsdXNoZXMgb25seSB0aGUgc2V0IG9mIE1BQw0KICAgYWRkcmVz c2VzIHRoYXQgcmVxdWlyZSByZWxlYXJuaW5nIHdoZW4gdG9wb2xvZ3kgY2hhbmdlcyBpbiBILVZQ TFMuDQoNCjMuMi4gIE1BQyBGbHVzaCBvbiBmYWlsdXJlDQoNCiAgIE1BQyBGbHVzaCBvbiBmYWls dXJlIGlzIGludHJvZHVjZWQgaW4gdGhpcyBkb2N1bWVudC4gIEluIHRoaXMgbW9kZWwsDQogICB0 aGUgTUFDIEZsdXNoIGlzIGluaXRpYXRlZCBieSBQRTEtcnMgKEZpZ3VyZSAxKSBvbiBkZXRlY3Rp b24gb2YNCiAgIGZhaWx1cmUgb2YgdGhlIHByaW1hcnkgc3Bva2UgUFcgYW5kIGlzIHNlbnQgdG8g YWxsIHBhcnRpY2lwYXRpbmcNCiAgIFBFLXJzIGRldmljZXMgaW4gdGhlIFZQTFMgZnVsbC1tZXNo LiAgUEUxLXJzIFNIT1VMRCBpbml0aWF0ZSBNQUMNCiAgIGZsdXNoIG9ubHkgaWYgUEUxLXJzIGlz IGR1YWwgaG9taW5nIGF3YXJlLiAgKElmIFBFMS1ycyBpcyBkdWFsIGhvbWluZw0KICAgYWdub3N0 aWMsIHRoZSBwb2xpY3kgaXMgZG8gbm90IGluaXRpYXRlIGEgTUFDIGZsdXNoIG9uIGZhaWx1cmUs IHNpbmNlDQogICB0aGF0IGNvdWxkIGNhdXNlIHVubmVjZXNzYXJ5IGZsdXNoaW5nIGluIHRoZSBj YXNlIG9mIHNpbmdsZSBob21lZA0KICAgTVRVLXMuKSAgVGhlIGR1YWwtaG9taW5nIHByb3RvY29s cyBmb3IgdGhpcyBzY2VuYXJpbyBhcmUgb3V0c2lkZSB0aGUNCiAgIHNjb3BlIG9mIHRoaXMgZG9j dW1lbnQuICBGb3IgZXhhbXBsZSwgdGhlIGNhc2Ugb2YgUEUxLXJzIGluaXRpYXRlZA0KICAgTUFD IGZsdXNoIG9uIGZhaWx1cmUgbWF5IGFyaXNlIHdoZW4gdGhlIGR1YWwtaG9taW5nIHNlZ21lbnQg aXMgbmF0aXZlDQogICBldGhlcm5ldCBhcyBvcHBvc2VkIHRvIHNwb2tlIFBXcy4gIEluIHRoaXMg Y2FzZSB0aGUgUEUtcnMgZGV2aWNlcw0KICAgdGhhdCByZWNlaXZlIHRoZSBNQUMgZmx1c2ggZnJv bSBQRTEtcnMgYXJlIHJlcXVpcmVkIHRvIGZsdXNoIGFsbCB0aGUNCiAgIE1BQyBhZGRyZXNzZXMg bGVhcm5lZCBvdmVyIHRoZSBQVyBjb25uZWN0ZWQgdG8gUEUxLXJzLiAgVGhpcyBjYW5ub3QNCiAg IGJlIGFjaGlldmVkIHdpdGggdGhlIE1BQyBBZGRyZXNzIFdpdGhkcmF3IE1lc3NhZ2UgZGVmaW5l ZCBpbg0KICAgW1JGQzQ3NjJdLiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgZXh0ZW5zaW9ucyB0 byBNQUMgRmx1c2gNCiAgIHByb2NlZHVyZXMgZGVmaW5lZCBpbiBbUkZDNDc2Ml0gaW4gb3JkZXIg dG8gaW1wbGVtZW50IE1BQyBGbHVzaCBvbg0KICAgRmFpbHVyZS4gIFdlIHVzZSB0aGUgdGVybSAi bmVnYXRpdmUiIE1BQyBmbHVzaCBvciAiRmx1c2gtYWxsLWZyb20tbWUiDQogICBmb3IgdGhpcyBr aW5kIG9mIGZsdXNoaW5nIGFjdGlvbiBhcyBvcHBvc2VkIHRvICJwb3NpdGl2ZSIgTUFDIEZsdXNo DQogICBhY3Rpb24gaW4gW1JGQzQ3NjJdLiAgVGhlIG5lZ2F0aXZlIE1BQyBmbHVzaCB0eXBpY2Fs bHkgcmVzdWx0cyBpcyBhDQogICBzbWFsbGVyIHNldCBvZiBNQUNzIHRvIGJlIGZsdXNoZWQuDQoN CiAgIE5vdGUgdGhhdCBpbiB0aGUgY2FzZSBvZiBuZWdhdGl2ZSBmbHVzaCB0aGUgbGlzdCBTSE9V TEQgYmUgb25seSB0aGUNCiAgIE1BQ3MgZm9yIHRoZSBhZmZlY3RlZCBNVFUtcy4gIElmIHRoZSBs aXN0IGlzIGVtcHR5IHRoZW4gdGhlIG5lZ2F0aXZlDQogICBmbHVzaCB3aWxsIHJlc3VsdCBpbiBm bHVzaGluZyBhbmQgcmVsZWFybmluZyBhbGwgYXR0YWNoZWQgTVRVLXMncyBmb3INCiAgIHRoZSBv cmlnaW5hdGluZyBQRS1ycy4NCg0KMy4zLiAgTUFDIEZsdXNoIGluIFBCQi1WUExTDQoNCiAgIFtS RkM3MDQxXSBkZXNjcmliZXMgaG93IFBCQiBjYW4gYmUgaW50ZWdyYXRlZCB3aXRoIFZQTFMgdG8g YWxsb3cgZm9yDQogICB1c2VmdWwgUEJCIGNhcGFiaWxpdGllcyB3aGlsZSBjb250aW51aW5nIHRv IGF2b2lkIHRoZSB1c2Ugb2YgTVNUUCBpbg0KICAgdGhlIGJhY2tib25lLiAgVGhlIGNvbWJpbmVk IHNvbHV0aW9uIHJlZmVycmVkIHRvIGFzICJQQkItVlBMUyINCiAgIHJlc3VsdHMgaW4gYmV0dGVy IHNjYWxhYmlsaXR5IGluIHRlcm1zIG9mIG51bWJlciBvZiBzZXJ2aWNlDQogICBpbnN0YW5jZXMs IFBXcyBhbmQgQy1NQUNzIHRoYXQgbmVlZCB0byBiZSBoYW5kbGVkIGluIHRoZSBWUExTIFBFLXJz DQogICBkZXZpY2VzLiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgZXh0ZW5zaW9ucyB0byBMRFAg TUFDIEZsdXNoDQogDQoNCg0KRHV0dGEsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJl ciAyNiwgMjAxNCAgICAgICAgICAgICAgIFtQYWdlIDhdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAg T3B0aW1pemVkIE1BQyBXaXRoZHJhd2FsIGluIEgtVlBMUyAgICAgTWFyY2ggMjUsIDIwMTQNCg0K DQogICBwcm9jZWR1cmVzIGRlc2NyaWJlZCBpbiBbUkZDNDc2Ml0gcmVxdWlyZWQgdG8gYnVpbGQg ZGVzaXJhYmxlDQogICBjYXBhYmlsaXRpZXMgdG8gUEJCLVZQTFMgc29sdXRpb24uDQoNCiAgIFRo ZSBzb2x1dGlvbiBwcm9wb3NlZCBpbiB0aGlzIGRvY3VtZW50IGlzIGdlbmVyaWMgYW5kIGlzIGFw cGxpY2FibGUNCiAgIHdoZW4gTVMtUFdzIGFyZSB1c2VkIGluIGludGVyY29ubmVjdGluZyBQRSBk ZXZpY2VzIGluIEgtVlBMUy4gIFRoZXJlDQogICBjb3VsZCBiZSBvdGhlciBILVZQTFMgbW9kZWxz IG5vdCBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQgd2hlcmUgdGhlDQogICBzb2x1dGlvbiBtYXkg YmUgYXBwbGljYWJsZS4NCg0KDQo0LiAgUHJvYmxlbSBEZXNjcmlwdGlvbg0KDQogICBUaGlzIHNl Y3Rpb24gZGVzY3JpYmVzIHRoZSBwcm9ibGVtcyBpbiBkZXRhaWwgd2l0aCByZXNwZWN0aXZlIHRv DQogICB2YXJpb3VzIE1BQyBmbHVzaCBhY3Rpb25zIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDMuDQoN CjQuMS4gIE1BQyBGbHVzaCBPcHRpbWl6YXRpb24gaW4gVlBMUyBSZXNpbGllbmN5DQoNCiAgIFRo aXMgc2VjdGlvbiBkZXNjcmliZXMgdGhlIG9wdGltaXphdGlvbnMgcmVxdWlyZWQgaW4gTUFDIGZs dXNoDQogICBwcm9jZWR1cmVzIHdoZW4gSC1WUExTIHJlc2lsaWVuY3kgaXMgcHJvdmlkZWQgYnkg cHJpbWFyeSBhbmQgYmFja3VwDQogICBzcG9rZSBQV3MuDQoNCjQuMS4xLiAgTUFDIEZsdXNoIE9w dGltaXphdGlvbiBmb3IgcmVndWxhciBILVZQTFMNCg0KICAgRmlndXJlIDIuIGRlc2NyaWJlcyBh IGR1YWwtaG9tZWQgSC1WUExTIHNjZW5hcmlvIGZvciBhIFZQTFMgaW5zdGFuY2UNCiAgIHdoZXJl IHRoZSBwcm9ibGVtIHdpdGggdGhlIGV4aXN0aW5nIE1BQyBmbHVzaCBtZXRob2QgZXhwbGFpbmVk IGluDQogICBzZWN0aW9uIDMuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KIA0KDQoNCkR1dHRhLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIg MjYsIDIwMTQgICAgICAgICAgICAgICBbUGFnZSA5XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgIE9w dGltaXplZCBNQUMgV2l0aGRyYXdhbCBpbiBILVZQTFMgICAgIE1hcmNoIDI1LCAyMDE0DQoNCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUEUxLXJzICAgICAgICAgICAgICAgICAg ICAgICBQRTMtcnMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0rICAg ICAgICAgICAgICAgICAgKy0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgICAgICAgIHwgICAgICAgICAgICAgICAgICB8ICAgICAgICB8DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgIC0tICAgfCAgICAgICAgICAgICAgICAgIHwgICAtLSAgIHwNCiAg IEN1c3RvbWVyIFNpdGUgMSAgICAgICAgICAgICB8ICAvICBcICB8LS0tLS0tLS0tLS0tLS0tLS0t fCAgLyAgXCAgfC0+Wg0KICAgWC0+Q0UtMSAgICAgICAgICAgICAgIC8tLS0tLXwgIFxzIC8gIHwg ICAgICAgICAgICAgICAgICB8ICBccyAvICB8DQogICAgICAgXCAgICAgcHJpbWFyeSBzcG9rZSBQ VyAgfCAgIC0tICAgfCAgICAgICAgICAgLy0tLS0tLXwgICAtLSAgIHwNCiAgICAgICAgXCAgICAg ICAgICAgICAvICAgICAgICArLS0tLS0tLS0rICAgICAgICAgIC8gICAgICAgKy0tLS0tLS0tKw0K ICAgICAgICAgXCAgICAoTVRVLXMpLyAgICAgICAgICAgICAgfCAgICBcICAgICAgICAvICAgICAg ICAgICAgIHwNCiAgICAgICAgICArLS0tLS0tLS0rLyAgICAgICAgICAgICAgIHwgICAgIFwgICAg ICAvICAgICAgICAgICAgICB8DQogICAgICAgICAgfCAgICAgICAgfCAgICAgICAgICAgICAgICB8 ICAgICAgXCAgICAvICAgICAgICAgICAgICAgfA0KICAgICAgICAgIHwgICAtLSAgIHwgICAgICAg ICAgICAgICAgfCAgICAgICBcICAvICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICB8ICAvICBc ICB8ICAgICAgICAgICAgICAgIHwgICAgICBILVZQTFMgRnVsbCBNZXNoIENvcmV8DQogICAgICAg ICAgfCAgXHMgLyAgfCAgICAgICAgICAgICAgICB8ICAgICAgIC8gXCAgICAgICAgICAgICAgICAg fA0KICAgICAgICAgIHwgICAtLSAgIHwgICAgICAgICAgICAgICAgfCAgICAgIC8gICBcICAgICAg ICAgICAgICAgIHwNCiAgICAgICAgIC8rLS0tLS0tLS0rXCAgICAgICAgICAgICAgIHwgICAgIC8g ICAgIFwgICAgICAgICAgICAgICB8DQogICAgICAgIC8gICAgIGJhY2t1cCBzcG9rZSBQVyAgICAg ICB8ICAgIC8gICAgICAgXCAgICAgICAgICAgICAgfA0KICAgICAgIC8gICAgICAgICAgICAgIFwg ICAgICAgICstLS0tLS0tLSsgICAgICAgICBcLS0tLS0tLS0rLS0tLS0tLS0rDQogICBZLT5DRS0y ICAgICAgICAgICAgIFwgICAgICAgfCAgICAgICAgfCAgICAgICAgICAgICAgICAgIHwgICAgICAg IHwNCiAgIEN1c3RvbWVyIFNpdGUgMiAgICAgIFwtLS0tLS18ICAtLSAgICB8ICAgICAgICAgICAg ICAgICAgfCAgLS0gICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgLyAgXCAg IHwtLS0tLS0tLS0tLS0tLS0tLS18IC8gIFwgICB8LT4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8IFxzIC8gICB8ICAgICAgICAgICAgICAgICAgfCBccyAvICAgfA0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgIC0tICAgIHwgICAgICAgICAgICAgICAgICB8ICAtLSAg ICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tKyAgICAgICAgICAg ICAgICAgICstLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBFMi1y cyAgICAgICAgICAgICAgICAgICAgICBQRTQtcnMNCg0KICAgICAgICAgICBGaWd1cmUgMjogRHVh bCBob21lZCBNVFUtcyBpbiB0d28gdGllciBoaWVyYXJjaHkgSC1WUExTDQoNCiAgIEluIEZpZ3Vy ZSAyLCB0aGUgTVRVLXMgaXMgZHVhbC1ob21lZCB0byBQRTEtcnMgYW5kIFBFMi1ycy4gIE9ubHkg dGhlDQogICBwcmltYXJ5IHNwb2tlIFBXIGlzIGFjdGl2ZSBhdCBNVFUtcywgdGh1cyBQRTEtcnMg aXMgYWN0aW5nIGFzIHRoZQ0KICAgYWN0aXZlIGRldmljZSAoZGVzaWduYXRlZCBmb3J3YXJkZXIp IHRvIHJlYWNoIHRoZSBmdWxsIG1lc2ggaW4gdGhlDQogICBWUExTIGluc3RhbmNlLiAgVGhlIE1B QyBhZGRyZXNzZXMgb2Ygbm9kZXMgbG9jYXRlZCBhdCBhY2Nlc3Mgc2l0ZXMNCiAgIChiZWhpbmQg Q0UxIGFuZCBDRTIpIGFyZSBsZWFybmVkIGF0IFBFMS1ycyBvdmVyIHRoZSBwcmltYXJ5IHNwb2tl IFBXLg0KICAgTGV0J3Mgc2F5IFggcmVwcmVzZW50cyBhIHNldCBvZiBzdWNoIE1BQyBhZGRyZXNz ZXMgbG9jYXRlZCBiZWhpbmQNCiAgIENFLTEuICBBcyBwYWNrZXRzIGZsb3cgZnJvbSBYIHRvIG90 aGVyIE1BQ3MgaW4gdGhlIFZQTFMgbmV0d29yaywNCiAgIFBFMi1ycywgUEUzLXJzIGFuZCBQRTQt cnMgbGVhcm4gYWJvdXQgWCBvbiB0aGVpciByZXNwZWN0aXZlIG1lc2ggUFdzDQogICB0ZXJtaW5h dGluZyBhdCBQRTEtcnMuICBXaGVuIE1UVS1zIHN3aXRjaGVzIHRvIHRoZSBiYWNrdXAgc3Bva2Ug UFcNCiAgIGFuZCBhY3RpdmF0ZXMgaXQsIFBFMi1ycyBiZWNvbWVzIHRoZSBhY3RpdmUgZGV2aWNl IChkZXNpZ25hdGVkDQogICBmb3J3YXJkZXIpIHRvIHJlYWNoIHRoZSBmdWxsIG1lc2ggY29yZSBm b3IgTVRVLXMuICBUcmFmZmljIGVudGVyaW5nDQogICB0aGUgSC1WUExTIGZyb20gQ0UtMSBhbmQg Q0UtMiBpcyBkaXZlcnRlZCBieSB0aGUgTVRVLXMgdG8gdGhlIHNwb2tlDQogICBQVyB0byBQRTIt cnMuICBUcmFmZmljIGRlc3RpbmVkIGZyb20gUEUyLXJzLCBQRTMtcnMgYW5kIFBFNC1ycyB0byBY DQogICB3aWxsIGJlIGJsYWNraG9sZWQgdGlsbCBNQUMgYWRkcmVzcyBhZ2luZyB0aW1lciBleHBp cmVzIChkZWZhdWx0IGlzIDUNCiAgIG1pbnV0ZXMpIG9yIGEgcGFja2V0IGZsb3dzIGZyb20gWCB0 byBvdGhlciBhZGRyZXNzZXMgdGhyb3VnaCBQRTItcnMuDQoNCiAgIEZvciBleGFtcGxlLCBpZiBh ZnRlciB0aGUgYmFja3VwIHNwb2tlIFBXIGlzIGFjdGl2ZSwgaWYgYSBwYWNrZXQNCiAgIGZsb3dz IGZyb20gTUFDIFogdG8gTUFDIFgsIHBhY2tldHMgZnJvbSBNQUMgWiB0cmF2ZWwgZnJvbSBQRTMt cnMgdG8NCiAgIFBFLTFycyBhbmQgYXJlIGRyb3BwZWQuICBIb3dldmVyLCBpZiBhIHBhY2tldCB3 aXRoIE1BQyBYIGFzIHNvdXJjZQ0KICAgYW5kIE1BQyBaIGFzIGRlc3RpbmF0aW9uIGFycml2ZXMg YXQgUEUyLXJzLCBQRTItcnMgd2lsbCBub3cgbGVhcm4gTUFDDQogDQoNCg0KRHV0dGEsIGV0IGFs LiAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyNiwgMjAxNCAgICAgICAgICAgICAgW1BhZ2Ug MTBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgT3B0aW1pemVkIE1BQyBXaXRoZHJhd2FsIGluIEgt VlBMUyAgICAgTWFyY2ggMjUsIDIwMTQNCg0KDQogICBYIGlzIG9uIHRoZSBiYWNrdXAgc3Bva2Ug UFcgYW5kIHdpbGwgZm9yd2FyZCB0byBNQUMgWi4gQXQgdGhpcyBwb2ludA0KICAgdHJhZmZpYyBm cm9tIFBFMy1ycyB0byBNQUMgWCB3aWxsIGdvIHRvIFBFMi1ycywgc2luY2UgUEUtM3JzIGhhcyBh bHNvDQogICBsZWFybmVkIGFib3V0IE1BQyBYLiBUaGVyZWZvcmUgYSBtZWNoYW5pc20gaXMgcmVx dWlyZWQgdG8gbWFrZSB0aGlzDQogICBsZWFybmluZyBtb3JlIHRpbWVseSBpbiBjYXNlcyB3aGVy ZSB0cmFmZmljIGlzIG5vdCBiaWRpcmVjdGlvbmFsLg0KDQogICBUbyBhdm9pZCB0cmFmZmljIGJs YWNraG9saW5nIHRoZSBNQUMgYWRkcmVzc2VzIHRoYXQgaGF2ZSBiZWVuIGxlYXJuZWQNCiAgIGlu IHRoZSB1cHN0cmVhbSBWUExTIGZ1bGwtbWVzaCB0aHJvdWdoIFBFMS1ycywgbXVzdCBiZSByZWxl YXJuZWQgb3INCiAgIHJlbW92ZWQgZnJvbSB0aGUgTUFDIEZJQnMgaW4gdGhlIFZTSXMgYXQgUEUy LXJzLCBQRTMtcnMgYW5kIFBFNC1ycy4NCiAgIElmIFBFMS1ycyBhbmQgUEUyLXJzIGFyZSBkdWFs LWhvbWluZyBhZ25vc3RpYyB0aGVuIG9uIGFjdGl2YXRpb24gb2YNCiAgIHRoZSBzdGFuZGJ5IFBX IGZyb20gTVRVLXMsIGEgTUFDIGZsdXNoIG1lc3NhZ2Ugd2lsbCBiZSBzZW50IGJ5IE1UVS1zDQog ICB0byBQRTItcnMgdGhhdCB3aWxsIGZsdXNoIGFsbCB0aGUgTUFDIGFkZHJlc3NlcyBsZWFybmVk IGluIHRoZSBWUExTDQogICBpbnN0YW5jZSBhdCBQRTItcnMgZnJvbSBhbGwgdGhlIG90aGVyIFBX cyBidXQgdGhlIFBXIGNvbm5lY3RlZCB0bw0KICAgTVRVLXMuDQoNCiAgIFBFMi1ycyBmdXJ0aGVy IHJlbGF5cyBNQUMgZmx1c2ggbWVzc2FnZXMgdG8gYWxsIG90aGVyIFBFLXJzIGRldmljZXMNCiAg IGluIHRoZSBmdWxsIG1lc2guICBUaGUgc2FtZSBwcm9jZXNzaW5nIHJ1bGUgYXBwbGllcyBhdCBh bGwgdGhvc2UNCiAgIFBFLXJzIGRldmljZXM6IGFsbCB0aGUgTUFDIGFkZHJlc3NlcyBhcmUgZmx1 c2hlZCBidXQgdGhlIG9uZXMgbGVhcm5lZA0KICAgb24gdGhlIFBXIGNvbm5lY3RlZCB0byBQRTIt cnMuICBGb3IgZXhhbXBsZSwgYXQgUEUzLXJzIGFsbCBvZiB0aGUgTUFDDQogICBhZGRyZXNzZXMg bGVhcm5lZCBmcm9tIHRoZSBQV3MgY29ubmVjdGVkIHRvIFBFMS1ycyBhbmQgUEU0LXJzIGFyZQ0K ICAgZmx1c2hlZCBhbmQgcmVsZWFybmVkIHN1YnNlcXVlbnRseS4gIEJlZm9yZSB0aGUgcmVsZWFy bmluZyBoYXBwZW5zDQogICBmbG9vZGluZyBvZiB1bmtub3duIGRlc3RpbmF0aW9uIE1BQyBhZGRy ZXNzZXMgdGFrZXMgcGxhY2UgdGhyb3VnaG91dA0KICAgdGhlIG5ldHdvcmsuICBBcyB0aGUgbnVt YmVyIG9mIFBFLXJzIGRldmljZXMgaW4gdGhlIGZ1bGwtbWVzaA0KICAgaW5jcmVhc2VzLCB0aGUg bnVtYmVyIG9mIHVuYWZmZWN0ZWQgTUFDIGFkZHJlc3NlcyBmbHVzaGVkIGluIGEgVlBMUw0KICAg aW5zdGFuY2UgYWxzbyBpbmNyZWFzZXMsIHRodXMgbGVhZGluZyB0byB1bm5lY2Vzc2FyeSBmbG9v ZGluZyBhbmQNCiAgIHJlbGVhcm5pbmcuICBXaXRoIGxhcmdlIG51bWJlciBvZiBWUExTIGluc3Rh bmNlcyBwcm92aXNpb25lZCBpbiB0aGUNCiAgIEgtVlBMUyBuZXR3b3JrIHRvcG9sb2d5IHRoZSBh bW91bnQgb2YgdW5uZWNlc3NhcnkgZmxvb2RpbmcgYW5kDQogICByZWxlYXJuaW5nIGluY3JlYXNl cy4gIEFuIG9wdGltaXphdGlvbiwgZGVzY3JpYmVkIGJlbG93LCBpcyByZXF1aXJlZA0KICAgdGhh dCB3aWxsIGZsdXNoIG9ubHkgdGhlIE1BQyBhZGRyZXNzZXMgbGVhcm5lZCBmcm9tIHRoZSByZXNw ZWN0aXZlDQogICBQV3MgYmV0d2VlbiBQRTEtcnMgYW5kIG90aGVyIFBFIGRldmljZXMgaW4gdGhl IGZ1bGwtbWVzaCBtaW5pbWl6aW5nDQogICB0aGUgcmVsZWFybmluZyBhbmQgZmxvb2RpbmcgaW4g dGhlIG5ldHdvcmsuICBJbiB0aGUgZXhhbXBsZSBhYm92ZSwNCiAgIG9ubHkgdGhlIE1BQyBhZGRy ZXNzZXMgaW4gc2V0IFggYW5kIFkgKHNob3duIGluIEZpZ3VyZSAyKSBuZWVkIHRvIGJlDQogICBm bHVzaGVkIGFjcm9zcyB0aGUgY29yZS4NCg0KICAgVGhlIHNhbWUgY2FzZSBpcyBhcHBsaWNhYmxl IHdoZW4gUEUxLXJzIGFuZCBQRTItcnMgYXJlIGR1YWwgaG9taW5nDQogICBhd2FyZSBhbmQgcGFy dGljaXBhdGUgaW4gYSBkZXNpZ25hdGVkIGZvcndhcmRlciBlbGVjdGlvbi4gIFdoZW4NCiAgIFBF Mi1ycyBiZWNvbWVzIHRoZSBhY3RpdmUgZGV2aWNlIGZvciBNVFUtcyB0aGVuIFBFMi1ycyBNQVkg aW5pdGlhdGUNCiAgIE1BQyBmbHVzaCB0b3dhcmRzIHRoZSBjb3JlLiAgVGhlIHJlY2VpdmluZyBh Y3Rpb24gb2YgdGhlIE1BQyBGbHVzaCBpbg0KICAgb3RoZXIgUEUtcnMgZGV2aWNlcyBpcyB0aGUg c2FtZSBhcyBpbiBNVFUtcyBpbml0aWF0ZWQgTUFDIEZsdXNoLiBUaGlzDQogICBpcyB0aGUgW1JG QzQ3NjJdIHNwZWNpZmllZCBiZWhhdmlvci4NCg0KNC4xLjIuICBNQUMgRmx1c2ggT3B0aW1pemF0 aW9uIGZvciBuYXRpdmUgRXRoZXJuZXQgYWNjZXNzDQoNCiAgIFRoZSBhbmFseXNpcyBpbiBzZWN0 aW9uIDQuMS4xIGFwcGxpZXMgYWxzbyB0byB0aGUgbmF0aXZlIEV0aGVybmV0DQogICBhY2Nlc3Mg aW50byBhIFZQTFMuICBJbiBzdWNoIGEgc2NlbmFyaW8gb25lIGFjdGl2ZSBhbmQgb25lIG9yIG1v cmUNCiAgIHN0YW5kYnkgZW5kcG9pbnRzIHRlcm1pbmF0ZSBpbnRvIHR3byBvciBtb3JlIFZQTFMg b3IgSC1WUExTIFBFLXJzDQogICBkZXZpY2VzLiAgRXhhbXBsZXMgb2YgdGhlc2UgZHVhbCBob21l ZCBhY2Nlc3MgYXJlIElUVS1UIFtJVFUuRzgwMzJdDQogICBhY2Nlc3MgcmluZ3Mgb3IgYW55IHBy b3ByaWV0YXJ5IG11bHRpLWNoYXNzaXMgTEFHIGVtdWxhdGlvbnMuICBVcG9uDQogICBmYWlsdXJl IG9mIHRoZSBhY3RpdmUgbmF0aXZlIEV0aGVybmV0IGVuZHBvaW50IG9uIFBFMS1ycywgYW4NCiAN Cg0KDQpEdXR0YSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDI2LCAyMDE0ICAg ICAgICAgICAgICBbUGFnZSAxMV0NCgwNCkludGVybmV0LURyYWZ0ICAgICBPcHRpbWl6ZWQgTUFD IFdpdGhkcmF3YWwgaW4gSC1WUExTICAgICBNYXJjaCAyNSwgMjAxNA0KDQoNCiAgIG9wdGltaXpl ZCBNQUMgZmx1c2ggaXMgcmVxdWlyZWQgdG8gYmUgaW5pdGlhdGVkIGJ5IFBFMS1ycyB0byBlbnN1 cmUNCiAgIHRoYXQgb24gUEUyLXJzLCBQRTMtcnMgYW5kIFBFNC1ycyBvbmx5IHRoZSBNQUMgYWRk cmVzc2VzIGxlYXJuZWQgZnJvbQ0KICAgdGhlIHJlc3BlY3RpdmUgUFdzIGNvbm5lY3RlZCB0byBQ RTEtcnMgYXJlIGJlaW5nIGZsdXNoZWQuDQoNCjQuMi4gIEJsYWNrIGhvbGluZyBpc3N1ZSBpbiBQ QkItVlBMUw0KDQogICBJbiBhIFBCQi1WUExTIGRlcGxveW1lbnQgYSBCLWNvbXBvbmVudCBWUExT IChCLVZQTFMpIG1heSBiZSB1c2VkIGFzDQogICBpbmZyYXN0cnVjdHVyZSB0byBzdXBwb3J0IG9u ZSBvciBtb3JlIEktY29tcG9uZW50IGluc3RhbmNlcy4gIFRoZQ0KICAgQi1WUExTIGNvbnRyb2wg cGxhbmUgKExEUCBTaWduYWxpbmcpIGFuZCBsZWFybmluZyBvZiAiQmFja2JvbmUiIE1BQ3MNCiAg IChCTUFDcykgcmVwbGFjZXMgSS1jb21wb25lbnQgY29udHJvbCBwbGFuZSBhbmQgbGVhcm5pbmcg b2YgY3VzdG9tZXINCiAgIE1BQ3MgKENNQUNzKSB0aHJvdWdob3V0IHRoZSBNUExTIGNvcmUuICBU aGlzIHJhaXNlcyBhbiBhZGRpdGlvbmFsDQogICBjaGFsbGVuZ2UgcmVsYXRlZCB0byBibGFjayBo b2xlIGF2b2lkYW5jZSBpbiB0aGUgSS1jb21wb25lbnQgZG9tYWluDQogICBhcyBkZXNjcmliZWQg aW4gdGhpcyBzZWN0aW9uLiAgRmlndXJlIDMgZGVzY3JpYmVzIHRoZSBjYXNlIG9mIGEgQ0UNCiAg IGRldmljZSAobm9kZSBBKSBkdWFsLWhvbWVkIHRvIHR3byBJLWNvbXBvbmVudCBpbnN0YW5jZXMg bG9jYXRlZCBvbg0KICAgdHdvIFBCQi1WUExTIFBFcyAoUEUxLXJzIGFuZCBQRTItcnMpLg0KDQog ICBJUC9NUExTIENvcmUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0t Kw0KICAgICAgICAgICAgICAgICAgICAgICAgICB8UEUyLXJzICAgICAgICB8DQogICAgICAgICAg ICAgICAgICAgICAgICAgKy0tLS0rICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAg ICB8UEJCIHwgICArLSsgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgIHxWUExTfC0tLXxQ fCAgICB8DQogICAgICAgICAgICAgICAgICAgICAgIFMvKy0tLS0rICAvKy0rXCAgIHxQRTMtcnMN CiAgICAgICAgICAgICAgICAgICAgICAgLyArLS0tLSsgLyAgICAgXCstLS0tKw0KICAgICAgICAg ICAgICAgICArLS0tKy8gIHxQQkIgfC8gICstKyAgfFBCQiB8ICAgKy0tLSsNCiAgICAgICAgIENN QUMgWC0tfENFIHwtLS18VlBMU3wtLS18UHwtLXxWUExTfC0tLXxDRSB8LS1DTUFDIFkNCiAgICAg ICAgICAgICAgICAgKy0tLSsgQSArLS0tLSsgICArLSsgICstLS0tKyAgICstLS0rDQogICAgICAg ICAgICAgICAgICAgQSAgICAgIHxQRTEtcnMgICAgICAgIHwgICAgICAgIEINCiAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAg ICArLS0tLS0tLS0tLS0tLS0rDQogICBGaWd1cmUgMzogUEJCIEJsYWNrIGhvbGluZyBJc3N1ZSAt IENFIER1YWwtSG9taW5nIHVzZSBjYXNlDQoNCiAgIFRoZSBsaW5rIGJldHdlZW4gUEUxLXJzIGFu ZCBDRS1BIGlzIGFjdGl2ZSAobWFya2VkIHdpdGggQSkgd2hpbGUgdGhlDQogICBsaW5rIGJldHdl ZW4gQ0UtQSBhbmQgUEUyLXJzIGlzIGluIFN0YW5kYnkvQmxvY2tlZCBzdGF0dXMuICBJbiB0aGUN CiAgIG5ldHdvcmsgZGlhZ3JhbSBDTUFDIFggaXMgb25lIG9mIHRoZSBNQUMgYWRkcmVzc2VzIGxv Y2F0ZWQgYmVoaW5kICAgDQogICBDRS1BIGluIHRoZSBjdXN0b21lciBkb21haW4sIENNQUMgWSBp cyBiZWhpbmQgQ0UtQiBhbmQgdGhlIEItVlBMUw0KICAgaW5zdGFuY2VzIG9uIFBFMS1ycyBhcmUg YXNzb2NpYXRlZCB3aXRoIEJNQUMgQjEgYW5kIFBFMi1ycyB3aXRoIEJNQUMNCiAgIEIyLg0KDQog ICBBcyB0aGUgcGFja2V0cyBmbG93IGZyb20gQ01BQyBYIHRvIENNQUMgWSB0aHJvdWdoIFBFMS1y cyB3aXRoIEJNQUMNCiAgIEIxLCB0aGUgcmVtb3RlIFBFLXJzIGRldmljZXMgcGFydGljaXBhdGlu ZyBpbiB0aGUgQi1WUExTIHdpdGggdGhlDQogICBzYW1lIEktU0lEIChmb3IgZXhhbXBsZSwgUEUz LXJzKSB3aWxsIGxlYXJuIHRoZSBDTUFDIFggYXNzb2NpYXRlZA0KICAgd2l0aCBCTUFDIEIxIG9u IFBFMS1ycy4gIFVuZGVyIGEgZmFpbHVyZSBjb25kaXRpb24gb2YgdGhlIGxpbmsNCiAgIGJldHdl ZW4gQ0UtQSBhbmQgUEUxLXJzIGFuZCBvbiBhY3RpdmF0aW9uIG9mIHRoZSBsaW5rIHRvIFBFMi1y cywgdGhlDQogICByZW1vdGUgUEUtcnMgZGV2aWNlcyAoZm9yIGV4YW1wbGUsIFBFMy1ycykgd2ls bCBmb3J3YXJkIHRoZSB0cmFmZmljDQogICBkZXN0aW5lZCBmb3IgY3VzdG9tZXIgTUFDIFggdG8g Qk1BQyBCMSByZXN1bHRpbmcgaW4gUEUxLXJzDQogICBibGFja2hvbGluZyB0aGF0IHRyYWZmaWMg dW50aWwgdGhlIGFnaW5nIHRpbWVyIGV4cGlyZXMgb3IgYSBwYWNrZXQNCiAgIGZsb3dzIGZyb20g WCB0byBZIHRocm91Z2ggdGhlIFBFMi1ycywgQk1BQyBCMi4gIFRoaXMgbWF5IHRha2UgYSBsb25n DQogDQoNCg0KRHV0dGEsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyNiwgMjAx NCAgICAgICAgICAgICAgW1BhZ2UgMTJdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgT3B0aW1pemVk IE1BQyBXaXRoZHJhd2FsIGluIEgtVlBMUyAgICAgTWFyY2ggMjUsIDIwMTQNCg0KDQogICB0aW1l IChkZWZhdWx0IGFnaW5nIHRpbWVyIGlzIDUgbWludXRlcykgYW5kIG1heSBhZmZlY3QgYSBsYXJn ZSBudW1iZXINCiAgIG9mIGZsb3dzIGFjcm9zcyBtdWx0aXBsZSBJLWNvbXBvbmVudHMuDQoNCiAg IEEgcG9zc2libGUgc29sdXRpb24gdG8gdGhpcyBpc3N1ZSBpcyB0byB1c2UgdGhlIGV4aXN0aW5n IExEUCBNQUMNCiAgIEZsdXNoIGFzIHNwZWNpZmllZCBpbiBbUkZDNDc2Ml0gdG8gZmx1c2ggdGhl IEJNQUMgYXNzb2NpYXRlZCB3aXRoIHRoZQ0KICAgUEUtcnMgaW4gdGhlIEItVlBMUyBkb21haW4g d2hlcmUgdGhlIGZhaWx1cmUgb2NjdXJyZWQuICBUaGlzIHdpbGwNCiAgIGF1dG9tYXRpY2FsbHkg Zmx1c2ggdGhlIENNQUMgdG8gQk1BQyBhc3NvY2lhdGlvbiBpbiB0aGUgcmVtb3RlIFBFLXJzDQog ICBkZXZpY2VzLiAgVGhpcyBzb2x1dGlvbiBoYXMgdGhlIGRpc2FkdmFudGFnZSBvZiBwcm9kdWNp bmcgYSBsb3Qgb2YNCiAgIHVubmVjZXNzYXJ5IE1BQyBmbHVzaCBpbiB0aGUgQi1WUExTIGRvbWFp biBhcyB0aGVyZSB3YXMgbm8gZmFpbHVyZSBvcg0KICAgdG9wb2xvZ3kgY2hhbmdlIGFmZmVjdGlu ZyB0aGUgQmFja2JvbmUgZG9tYWluLg0KDQogICBBIGJldHRlciBzb2x1dGlvbiB3aGljaCBwcm9w YWdhdGVzIHRoZSBJLWNvbXBvbmVudCBldmVudHMgdGhyb3VnaCB0aGUNCiAgIGJhY2tib25lIGlu ZnJhc3RydWN0dXJlIChCLVZQTFMpIGlzIHJlcXVpcmVkIGluIG9yZGVyIHRvIGZsdXNoIG9ubHkN CiAgIHRoZSBDTUFDIHRvIEJNQUMgYXNzb2NpYXRpb25zIGluIHRoZSByZW1vdGUgUEJCLVZQTFMg Y2FwYWJsZSBQRS1ycw0KICAgZGV2aWNlcy4gIFNpbmNlIHRoZXJlIGFyZSBubyBJLWNvbXBvbmVu dCBjb250cm9sIHBsYW5lIGV4Y2hhbmdlcw0KICAgYWNyb3NzIHRoZSBQQkIgYmFja2JvbmUsIGV4 dGVuc2lvbnMgdG8gQi1WUExTIGNvbnRyb2wgcGxhbmUgYXJlDQogICByZXF1aXJlZCB0byBwcm9w YWdhdGUgdGhlIEktY29tcG9uZW50IE1BQyBGbHVzaCBldmVudHMgYWNyb3NzIHRoZQ0KICAgQi1W UExTLg0KDQoNCjUuICBTb2x1dGlvbiBEZXNjcmlwdGlvbg0KDQogICBUaGlzIHNlY3Rpb24gZGVz Y3JpYmVzIHRoZSBzb2x1dGlvbiBmb3IgdGhlIHByb2JsZW0gc3BhY2UgZGVzY3JpYmVkDQogICBp biBzZWN0aW9uIDQuDQoNCjUuMS4gIE1BQyBGbHVzaCBPcHRpbWl6YXRpb24gZm9yIFZQTFMgUmVz aWxpZW5jeQ0KDQogICBUaGUgYmFzaWMgcHJpbmNpcGxlIG9mIHRoZSBvcHRpbWl6ZWQgTUFDIGZs dXNoIG1lY2hhbmlzbSBpcyBleHBsYWluZWQNCiAgIHdpdGggcmVmZXJlbmNlIHRvIEZpZ3VyZSAy LiAgVGhlIG9wdGltaXphdGlvbiBpcyBhY2hpZXZlZCBieQ0KICAgaW5pdGlhdGluZyBNQUMgRmx1 c2ggb24gZmFpbHVyZSBhcyBkZXNjcmliZWQgaW4gc2VjdGlvbiAzLjIuDQoNCiAgIFBFMS1ycyB3 b3VsZCBpbml0aWF0ZSBNQUMgRmx1c2ggdG93YXJkcyB0aGUgY29yZSBvbiBkZXRlY3Rpb24gb2YN CiAgIGZhaWx1cmUgb2YgcHJpbWFyeSBzcG9rZSBQVyBiZXR3ZWVuIE1UVS1zIGFuZCBQRTEtcnMg KG9yIHN0YXR1cw0KICAgY2hhbmdlIGZyb20gYWN0aXZlIHRvIHN0YW5kYnkgW1JGQzY3MThdICku ICBUaGlzIG1ldGhvZCBpcyByZWZlcnJlZA0KICAgdG8gYXMgIk1BQyBGbHVzaCBvbiBGYWlsdXJl IiB0aHJvdWdob3V0IHRoaXMgZG9jdW1lbnQuICBUaGUgTUFDIEZsdXNoDQogICBtZXNzYWdlIHdv dWxkIGluZGljYXRlIHRvIHJlY2VpdmluZyBQRS1ycyBkZXZpY2VzIHRvIGZsdXNoIGFsbCBNQUNz DQogICBsZWFybmVkIG92ZXIgdGhlIFBXIGluIHRoZSBjb250ZXh0IG9mIHRoZSBWUExTIGZvciB3 aGljaCB0aGUgTUFDDQogICBmbHVzaCBtZXNzYWdlIGlzIHJlY2VpdmVkLiAgRWFjaCBQRS1ycyBk ZXZpY2UgaW4gdGhlIGZ1bGwgbWVzaCB0aGF0DQogICByZWNlaXZlcyB0aGUgbWVzc2FnZSBpZGVu dGlmaWVzIHRoZSBWUExTIGluc3RhbmNlIGFuZCBpdHMgcmVzcGVjdGl2ZQ0KICAgUFcgdGhhdCB0 ZXJtaW5hdGVzIGluIFBFMS1ycyBmcm9tIHRoZSBGRUMgVExWIHJlY2VpdmVkIGluIHRoZSBtZXNz YWdlDQogICBhbmQvb3IgTERQIHNlc3Npb24uICBUaHVzIHRoZSBQRS1ycyBkZXZpY2UgZmx1c2hl cyBvbmx5IHRoZSBNQUMNCiAgIGFkZHJlc3NlcyBsZWFybmVkIGZyb20gdGhhdCBQVyBjb25uZWN0 ZWQgdG8gUEUxLXJzLCBtaW5pbWl6aW5nIHRoZQ0KICAgcmVxdWlyZWQgcmVsZWFybmluZyBhbmQg dGhlIGZsb29kaW5nIHRocm91Z2hvdXQgdGhlIFZQTFMgZG9tYWluLg0KDQogICBUaGlzIHNlY3Rp b24gZGVmaW5lcyBhIGdlbmVyaWMgTUFDIEZsdXNoIFBhcmFtZXRlcnMgVExWIGZvciBMRFANCiAg IFtSRkM1MDM2XS4gIFRocm91Z2ggb3V0IHRoaXMgZG9jdW1lbnQgdGhlIE1BQyBGbHVzaCBQYXJh bWV0ZXJzIFRMViBpcw0KICAgcmVmZXJyZWQgYXMgTUFDIEZsdXNoIFRMVi4gIEEgTUFDIEZsdXNo IFRMViBjYXJyaWVzIGluZm9ybWF0aW9uIG9uDQogICB0aGUgZGVzaXJlZCBhY3Rpb24gYXQgdGhl IFBFLXJzIGRldmljZSByZWNlaXZpbmcgdGhlIG1lc3NhZ2UgYW5kIGlzDQogDQoNCg0KRHV0dGEs IGV0IGFsLiAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyNiwgMjAxNCAgICAgICAgICAgICAg W1BhZ2UgMTNdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgT3B0aW1pemVkIE1BQyBXaXRoZHJhd2Fs IGluIEgtVlBMUyAgICAgTWFyY2ggMjUsIDIwMTQNCg0KDQogICB1c2VkIGZvciBvcHRpbWl6ZWQg TUFDIGZsdXNoaW5nIGluIFZQTFMuICBUaGUgTUFDIEZsdXNoIFRMViBjYW4gYWxzbw0KICAgYmUg dXNlZCBmb3IgW1JGQzQ3NjJdIHN0eWxlIG9mIE1BQyBGbHVzaCBhcyBleHBsYWluZWQgaW4gc2Vj dGlvbiAzLg0KDQo1LjEuMS4gIE1BQyBGbHVzaCBQYXJhbWV0ZXJzIFRMVg0KDQogICBUaGUgTUFD IEZsdXNoIFBhcmFtZXRlcnMgVExWIGlzIGRlc2NyaWJlZCBhcyBiZWxvdzoNCg0KICAgMCAgICAg ICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0K ICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMQ0KICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgIHwxfDF8IE1BQyBGbHVzaCBQYXJhbXMgVExWKFRC REEpfCAgICAgICAgICAgTGVuZ3RoICAgICAgICAgICAgICB8DQogICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgfCAg ICAgRmxhZ3MgICAgIHwgU3ViLVRMViBUeXBlICB8ICAgICAgICAgU3ViLVRMViBMZW5ndGggICAg ICAgIHwNCiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQogICB8ICAgICAgICAgICAgICAgIFN1Yi1UTFYgVmFyaWFibGUg TGVuZ3RoIFZhbHVlICAgICAgICAgICAgICAgICAgfA0KICAgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r DQoNCiAgIFRoZSBVIGFuZCBGIGJpdHMgYXJlIHNldCB0byBmb3J3YXJkIGlmIHVua25vd24gc28g dGhhdCBwb3RlbnRpYWwNCiAgIGludGVybWVkaWF0ZSBWUExTIFBFLXJzIGRldmljZXMgdW5hd2Fy ZSBvZiB0aGUgbmV3IFRMViBjYW4ganVzdA0KICAgcHJvcGFnYXRlIGl0IHRyYW5zcGFyZW50bHku ICBJbiB0aGUgY2FzZSBvZiBhbiBCLVZQTFMgbmV0d29yayB0aGF0DQogICBoYXMgUEJCLVZQTFMg aW4gdGhlIGNvcmUgd2l0aCBubyBJLWNvbXBvbmVudHMgYXR0YWNoZWQgdGhpcyBtZXNzYWdlDQog ICBjYW4gc3RpbGwgYmUgdXNlZnVsIHRvIGVkZ2UgQi1WUExTIHRoYXQgZG8gaGF2ZSB0aGUgSS1j b21wb25lbnRzIHdpdGgNCiAgIHRoZSBJU0lEcyBhbmQgdW5kZXJzdGFuZCB0aGUgbWVzc2FnZS4g IFRoZSBNQUMgRmx1c2ggUGFyYW1ldGVycyBUTFYNCiAgIHR5cGUgaXMgdG8gYmUgYXNzaWduZWQg YnkgSUFOQS4gIFRoZSBlbmNvZGluZyBvZiB0aGUgVExWIGZvbGxvd3MgdGhlDQogICBzdGFuZGFy ZCBMRFAgVExWIGVuY29kaW5nIGluIFtSRkM1MDM2XQ0KDQogICBUaGUgVExWIHZhbHVlIGZpZWxk IGNvbnRhaW5zIGEgb25lIGJ5dGUgRmxhZyBmaWVsZCB1c2VkIGFzIGRlc2NyaWJlZA0KICAgYmVs b3cuICBGdXJ0aGVyIHRoZSBUTFYgdmFsdWUgTUFZIGNhcnJ5IG9uZSBvciBtb3JlIHN1Yi1UTFZz LiAgQW55DQogICBzdWItVExWIGRlZmluaXRpb24gdG8gdGhlIGFib3ZlIFRMViBNVVNUIGFkZHJl c3MgdGhlIGFjdGlvbnMgaW4NCiAgIGNvbWJpbmF0aW9uIHdpdGggb3RoZXIgZXhpc3Rpbmcgc3Vi LVRMVnMuDQoNCiAgIFRoZSBkZXRhaWxlZCBmb3JtYXQgZm9yIHRoZSBGbGFncyBiaXQgdmVjdG9y IGlzIGRlc2NyaWJlZCBiZWxvdzoNCg0KICAgIDAgMSAyIDMgNCA1IDYgNw0KICAgKy0rLSstKy0r LSstKy0rLSsNCiAgIHxDfE58ICAgIE1CWiAgICB8IChNQlogPSBNVVNUIEJlIFplcm8pDQogICAr LSstKy0rLSstKy0rLSstKw0KDQogICAxIEJ5dGUgRmxhZyBmaWVsZCBpcyBtYW5kYXRvcnkuICBU aGUgZm9sbG93aW5nIGZsYWdzIGFyZSBkZWZpbmVkOg0KDQogICBDIGZsYWcsIHVzZWQgdG8gaW5k aWNhdGUgdGhlIGNvbnRleHQgb2YgdGhlIFBCQi1WUExTIGNvbXBvbmVudCBpbg0KICAgd2hpY2gg TUFDIGZsdXNoIGlzIHJlcXVpcmVkLiAgRm9yIFBCQi1WUExTIHRoZXJlIGFyZSB0d28gY29udGV4 dHMgb2YNCiAgIE1BQyBmbHVzaGluZyAtIFRoZSBCYWNrYm9uZSBWUExTIChCLWNvbXBvbmVudCBW UExTKSBhbmQgQ3VzdG9tZXIgVlBMUw0KICAgKEktY29tcG9uZW50IFZQTFMpLiAgQyBmbGFnIE1V U1QgYmUgWkVSTyAoQz0wKSB3aGVuIGEgTUFDIEZsdXNoIGZvcg0KICAgdGhlIEItVlBMUyBpcyBy ZXF1aXJlZC4gIEMgZmxhZyBNVVNUIGJlIHNldCAoQz0xKSB3aGVuIHRoZSBNQUMgRmx1c2gNCiAg IGZvciBJLWNvbXBvbmVudCBpcyByZXF1aXJlZC4gIEluIHRoZSByZWd1bGFyIEgtVlBMUyBjYXNl IHRoZSBDIGZsYWcNCiAgIE1VU1QgYmUgWkVSTyAoQz0wKSB0byBpbmRpY2F0ZSB0aGUgZmx1c2gg YXBwbGllcyB0byB0aGUgY3VycmVudCBWUExTDQogDQoNCg0KRHV0dGEsIGV0IGFsLiAgICAgICAg ICBFeHBpcmVzIFNlcHRlbWJlciAyNiwgMjAxNCAgICAgICAgICAgICAgW1BhZ2UgMTRdDQoMDQpJ bnRlcm5ldC1EcmFmdCAgICAgT3B0aW1pemVkIE1BQyBXaXRoZHJhd2FsIGluIEgtVlBMUyAgICAg TWFyY2ggMjUsIDIwMTQNCg0KDQogICBjb250ZXh0Lg0KDQogICBOIGZsYWcsIHVzZWQgdG8gaW5k aWNhdGUgd2hldGhlciBhIHBvc2l0aXZlIChOPTAsIEZsdXNoLWFsbC1idXQtbWluZSkNCiAgIG9y IG5lZ2F0aXZlIChOPTEgRmx1c2gtYWxsLWZyb20tbWUpIE1BQyBGbHVzaCBpcyByZXF1aXJlZC4g IFRoZQ0KICAgc291cmNlIChtaW5lL21lKSBpcyBkZWZpbmVkIGVpdGhlciBhcyB0aGUgUFcgYXNz b2NpYXRlZCB3aXRoIHRoZSBMRFANCiAgIHNlc3Npb24gb24gd2hpY2ggdGhlIExEUCBNQUMgV2l0 aGRyYXcgd2FzIHJlY2VpdmVkIG9yIHdpdGggdGhlDQogICBCTUFDKHMpIGxpc3RlZCBpbiB0aGUg Qk1BQyBTdWItVExWLiAgRm9yIHRoZSBvcHRpbWl6ZWQgTUFDIEZsdXNoDQogICBwcm9jZWR1cmUg ZGVzY3JpYmVkIGluIHRoaXMgc2VjdGlvbiB0aGUgZmxhZyBNVVNUIGJlIHNldCAoTj0xKS4NCg0K ICAgRGV0YWlsZWQgdXNhZ2UgaW4gdGhlIGNvbnRleHQgb2YgUEJCLVZQTFMgaXMgZXhwbGFpbmVk IGluIHNlY3Rpb24NCiAgIDUuMi4NCg0KICAgTUJaIGZsYWdzLCB0aGUgcmVzdCBvZiB0aGUgZmxh Z3MgU0hPVUxEIGJlIHNldCB0byB6ZXJvIG9uDQogICB0cmFuc21pc3Npb24gYW5kIGlnbm9yZWQg b24gcmVjZXB0aW9uLg0KDQogICBUaGUgTUFDIEZsdXNoIFRMViBTSE9VTEQgYmUgcGxhY2VkIGFm dGVyIHRoZSBleGlzdGluZyBUTFZzIGluIE1BQw0KICAgRmx1c2ggbWVzc2FnZSBpbiBbUkZDNDc2 Ml0uDQoNCjUuMS4yLiAgQXBwbGljYXRpb24gb2YgTUFDIEZsdXNoIFRMViBpbiBPcHRpbWl6ZWQg TUFDIEZsdXNoDQoNCiAgIEZvciBvcHRpbWl6ZWQgTUFDIGZsdXNoLCB0aGUgTUFDIEZsdXNoIFRM ViBNQVkgYmUgc2VudCBhcyBpbiBleGlzdGluZw0KICAgTERQIEFkZHJlc3MgV2l0aGRyYXcgTWVz c2FnZSB3aXRoIGVtcHR5IE1BQyBMaXN0IGJ1dCBmcm9tIHRoZSBjb3JlDQogICBQRS1ycyBvbiBk ZXRlY3Rpb24gb2YgZmFpbHVyZSBvZiBpdHMgbG9jYWwvcHJpbWFyeSBzcG9rZSBQVy4gIFRoZSBO DQogICBiaXQgaW4gVExWIE1VU1QgYmUgc2V0IHRvIDEgdG8gaW5kaWNhdGUgRmx1c2gtYWxsLWZy b20tbWUuICBJZiB0aGUNCiAgIG9wdGltaXplZCBNQUMgRmx1c2ggcHJvY2VkdXJlIGlzIHVzZWQg aW4gYSBCYWNrYm9uZSBWUExTIG9yIHJlZ3VsYXINCiAgIFZQTFMvSC1WUExTIGNvbnRleHQgdGhl IEMgYml0IE1VU1QgYmUgWkVSTyAoQz0wKS4gIElmIGl0IGlzIHVzZWQgaW4NCiAgIGFuIEktY29t cG9uZW50IGNvbnRleHQgdGhlIEMgYml0IE1VU1QgYmUgc2V0IChDPSAxKS4gIFNlZSBzZWN0aW9u IDQuMg0KICAgZm9yIGRldGFpbHMgb2YgaXRzIHVzYWdlIGluIFBCQi1WUExTIGNvbnRleHQuDQoN CiAgIE5vdGUgdGhhdCB0aGUgYXNzdW1wdGlvbiBpcyB0aGUgTUFDIGZsdXNoIFRMViBpcyB1bmRl cnN0b29kIGJ5IGFsbA0KICAgZGV2aWNlcyBiZWZvcmUgaXQgaXMgdHVybmVkIG9uIGluIGFueSBu ZXR3b3JrLiAgU2VlIE9wZXJhdGlvbmFsDQogICBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIDYuDQoN CiAgIFRoZSBNQUMgd2l0aGRyYXcgcHJvY2VkdXJlcyBkZWZpbmVkIGluIFtSRkM0NzYyXSwgd2hl cmUgZWl0aGVyIHRoZQ0KICAgTVRVLXMgb3IgUEUyLXJzIHNlbmQgdGhlIE1BQyBXaXRoZHJhd2wg bWVzc2FnZSBTSE9VTEQgYmUgdXNlZCBpbg0KICAgY2FzZXMgd2hlcmUgdGhlIG5ldHdvcmsgaXMg YmVpbmcgdXBncmFkZWQgYW5kIGRldmljZXMgYXJlIG5vdCBjYXBhYmxlDQogICBvZiB1bmRlcnN0 YW5kaW5nIHRoZSBvcHRpbWl6ZWQgTUFDIGZsdXNoLiAgVGhpcyB3b3VsZCByZXN1bHQgaW4gdGhl DQogICBzYW1lIGZsdXNoaW5nIGFjdGlvbiBhcyBbUkZDNDc2Ml0gYXQgdGhlIHJlY2VpdmluZyBQ RS1ycyBkZXZpY2VzLg0KDQogICBGb3IgdGhlIGNhc2Ugb2YgQi1WUExTIGRldmljZXMgb3B0aW1p emVkIE1BQyBmbHVzaCBtZXNzYWdlIFNIT1VMRCBiZQ0KICAgc3VwcG9ydGVkLg0KDQo1LjEuMy4g IE1BQyBGbHVzaCBUTFYgUHJvY2Vzc2luZyBSdWxlcyBmb3IgUmVndWxhciBWUExTDQoNCiAgIFRo aXMgc2VjdGlvbiBkZXNjcmliZXMgdGhlIHByb2Nlc3NpbmcgcnVsZXMgb2YgTUFDIEZsdXNoIFRM ViB0aGF0DQogICBTSE9VTEQgYmUgZm9sbG93ZWQgaW4gdGhlIGNvbnRleHQgb2YgTUFDIGZsdXNo IHByb2NlZHVyZXMgaW4gVlBMUy4NCg0KICAgRm9yIG9wdGltaXplZCBNQUMgRmx1c2ggYSBtdWx0 aS1ob21pbmcgUEUtcnMgaW5pdGlhdGVzIE1BQyBmbHVzaA0KIA0KDQoNCkR1dHRhLCBldCBhbC4g ICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjYsIDIwMTQgICAgICAgICAgICAgIFtQYWdlIDE1 XQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgIE9wdGltaXplZCBNQUMgV2l0aGRyYXdhbCBpbiBILVZQ TFMgICAgIE1hcmNoIDI1LCAyMDE0DQoNCg0KICAgbWVzc2FnZSB0b3dhcmRzIHRoZSBvdGhlciBy ZWxhdGVkIFZQTFMgUEUtcnMgZGV2aWNlcyB3aGVuIGl0IGRldGVjdHMNCiAgIGEgdHJhbnNpdGlv biAoZmFpbHVyZSBvciB0byBzdGFuZGJ5KSBpbiBpdHMgYWN0aXZlIHNwb2tlIFBXLiAgSW4gc3Vj aA0KICAgY2FzZSB0aGUgTUFDIEZsdXNoIFRMViBNVVNUIGJlIHNlbnQgd2l0aCBOPSAxLiAgQSBQ RS1ycyBkZXZpY2UNCiAgIHJlY2VpdmluZyB0aGUgTUFDIEZsdXNoIFRMViBTSE9VTEQgZm9sbG93 IHRoZSBzYW1lIHByb2Nlc3NpbmcgcnVsZXMNCiAgIGFzIGRlc2NyaWJlZCBpbiB0aGlzIHNlY3Rp b24uDQoNCiAgIE5vdGUgdGhhdCBpZiBNUy1QVyBpcyB1c2VkIGluIFZQTFMgdGhlbiBhIE1BQyBm bHVzaCBtZXNzYWdlIGlzDQogICBwcm9jZXNzZWQgb25seSBhdCB0aGUgVC1QRSBub2RlcyBzaW5j ZSBTLVBFKHMpIHRyYXZlcnNlZCBieSB0aGUgTVMtUFcNCiAgIHByb3BhZ2F0ZSBNQUMgZmx1c2gg bWVzc2FnZXMgd2l0aG91dCBhbnkgYWN0aW9uLiAgSW4gdGhpcyBzZWN0aW9uLCBhDQogICBQRS1y cyBkZXZpY2Ugc2lnbmlmaWVzIG9ubHkgVC1QRSBpbiBNUy1QVyBjYXNlIHVubGVzcyBzcGVjaWZp ZWQNCiAgIG90aGVyd2lzZS4NCg0KICAgV2hlbiBhIFBFLXJzIGRldmljZSByZWNlaXZlcyBhIE1B QyBGbHVzaCBUTFYgd2l0aCBOID0gMSwgaXQgU0hPVUxEDQogICBmbHVzaCBhbGwgdGhlIE1BQyBh ZGRyZXNzZXMgbGVhcm5lZCBmcm9tIHRoZSBQVyBpbiB0aGUgVlBMUyBpbiB0aGUNCiAgIGNvbnRl eHQgb24gd2hpY2ggdGhlIE1BQyBGbHVzaCBtZXNzYWdlIGlzIHJlY2VpdmVkLg0KDQogICBJZiBh IE1BQyBGbHVzaCBUTFYgaXMgcmVjZWl2ZWQgd2l0aCBOID0gMCBpbiB0aGUgTUFDIGZsdXNoIG1l c3NhZ2UNCiAgIHRoZW4gdGhlIHJlY2VpdmluZyBQRS1ycyBTSE9VTEQgZmx1c2ggdGhlIE1BQyBh ZGRyZXNzZXMgbGVhcm5lZCBmcm9tDQogICBhbGwgUFdzIGluIHRoZSBWUExTIGluc3RhbmNlIGV4 Y2VwdCB0aGUgb25lcyBsZWFybmVkIG92ZXIgdGhlIFBXIG9uDQogICB3aGljaCB0aGUgbWVzc2Fn ZSBpcyByZWNlaXZlZC4NCg0KICAgSWYgYSBQRS1ycyBkZXZpY2UgcmVjZWl2ZXMgYSBNQUMgZmx1 c2ggd2l0aCB0aGUgTUFDIEZsdXNoIFRMViBvcHRpb24NCiAgIGFuZCBhIHZhbGlkIE1BQyBhZGRy ZXNzIGxpc3QsIGl0IFNIT1VMRCBpZ25vcmUgdGhlIG9wdGlvbiBhbmQgZGVhbA0KICAgd2l0aCBN QUMgYWRkcmVzc2VzIGV4cGxpY2l0bHkgYXMgcGVyIFtSRkM0NzYyXS4gIEl0IGlzIGFzc3VtZWQg d2hlbg0KICAgdGhlc2UgcHJvY2VkdXJlcyBhcmUgdXNlZCBhbGwgbm9kZXMgc3VwcG9ydCB0aGUg TUFDIEZsdXNoIE1lc3NhZ2UuDQogICBTZWUgc2VjdGlvbiA2IE9wZXJhdGlvbmFsIENvbnNpZGVy YXRpb25zIGZvciBkZXRhaWxzLg0KDQo1LjEuNC4gIE9wdGltaXplZCBNQUMgRmx1c2ggUHJvY2Vk dXJlcw0KDQogICBUaGlzIHNlY3Rpb24gZXhwbGFpbnMgdGhlIG9wdGltaXplZCBNQUMgZmx1c2gg cHJvY2VkdXJlIGluIHRoZQ0KICAgc2NlbmFyaW8gaW4gRmlndXJlIDIuICBXaGVuIE9wdGltaXpl ZCBNQUMgZmx1c2ggaXMgYmVpbmcgdXNlZCBhIFBFLXJzDQogICB0aGF0IGlzIGR1YWwgaG9taW5n IGF3YXJlIFNIT1VMRCBzZW5kIE1BQyBhZGRyZXNzIG1lc3NhZ2VzIHdpdGggTUFDDQogICBGbHVz aCBUTFYgYW5kIE49MSBwcm92aWRlZCB0aGUgb3RoZXIgUEVzIHVuZGVyc3RhbmQgdGhlIG5ldyBt ZXNzYWdlcy4NCiAgICBVcG9uIHJlY2VpcHQgb2YgdGhlIE1BQyBmbHVzaCBtZXNzYWdlLCBQRTIt cnMgaWRlbnRpZmllcyB0aGUgVlBMUw0KICAgaW5zdGFuY2UgdGhhdCByZXF1aXJlcyBNQUMgZmx1 c2ggZnJvbSB0aGUgRkVDIGVsZW1lbnQgaW4gdGhlIEZFQyBUTFYuDQogICBPbiByZWNlaXZpbmcg Tj0xLCBQRS0yIHJlbW92ZXMgYWxsIE1BQyBhZGRyZXNzZXMgbGVhcm5lZCBmcm9tIHRoYXQgUFcN CiAgIG92ZXIgd2hpY2ggdGhlIG1lc3NhZ2UgaXMgcmVjZWl2ZWQuICBUaGUgc2FtZSBhY3Rpb24g aXMgZm9sbG93ZWQgYnkNCiAgIFBFMy1ycyBhbmQgUEU0LXJzLg0KDQogICBGaWd1cmUgNCBzaG93 cyBhbm90aGVyIHJlZHVuZGFudCBILVZQTFMgdG9wb2xvZ3kgdG8gcHJvdGVjdCBhZ2FpbnN0DQog ICBmYWlsdXJlIG9mIE1UVS1zIGRldmljZS4gIFByb3ZpZGVyIFJTVFAgW0lFRUUuODAyLjFRLTIw MTFdIG1heSBiZQ0KICAgdXNlZCBhcyBzZWxlY3Rpb24gYWxnb3JpdGhtIGZvciBhY3RpdmUgYW5k IGJhY2t1cCBQV3MgaW4gb3JkZXIgdG8NCiAgIG1haW50YWluIHRoZSBjb25uZWN0aXZpdHkgYmV0 d2VlbiBNVFUtcyBkZXZpY2VzIGFuZCBQRS1ycyBkZXZpY2VzIGF0DQogICB0aGUgZWRnZS4gIEl0 IGlzIGFzc3VtZWQgdGhhdCBQRS1ycyBkZXZpY2VzIGNhbiBkZXRlY3QgZmFpbHVyZSBvbiBQV3MN CiAgIGluIGVpdGhlciBkaXJlY3Rpb24gdGhyb3VnaCBPQU0gbWVjaGFuaXNtcyBzdWNoIGFzIFZD Q1YgcHJvY2VkdXJlcw0KICAgZm9yIGluc3RhbmNlLg0KDQoNCiANCg0KDQpEdXR0YSwgZXQgYWwu ICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDI2LCAyMDE0ICAgICAgICAgICAgICBbUGFnZSAx Nl0NCgwNCkludGVybmV0LURyYWZ0ICAgICBPcHRpbWl6ZWQgTUFDIFdpdGhkcmF3YWwgaW4gSC1W UExTICAgICBNYXJjaCAyNSwgMjAxNA0KDQoNCiAgICAgICAgICAgICAgICAgIE1UVS0xPT09PT09 PT09PT09PT09PVBFLTEtcnM9PT09PT09PT09PT09UEUtMy1ycw0KICAgICAgICAgICAgICAgICAg ICB8fCAgICAgICAgICAgICAgICAgIHx8IFwgICAgICAgICAgICAgL3x8DQogICAgICAgICAgICAg ICAgICAgIHx8ICBSZWR1bmRhbmN5ICAgICAgfHwgIFwgICAgICAgICAgIC8gfHwNCiAgICAgICAg ICAgICAgICAgICAgfHwgIFByb3ZpZGVyIFJTVFAgICB8fCAgIEZ1bGwtTWVzaCAuICB8fA0KICAg ICAgICAgICAgICAgICAgICB8fCAgICAgICAgICAgICAgICAgIHx8ICAvICAgICAgICAgICBcIHx8 DQogICAgICAgICAgICAgICAgICAgIHx8ICAgICAgICAgICAgICAgICAgfHwgLyAgICAgICAgICAg ICBcfHwNCiAgICAgICAgICAgICAgICAgIE1UVS0yLS0tLS0tLS0tLS0tLS0tLVBFLTItcnM9PT09 PT09PT09PT09UEUtNC1ycw0KICAgICAgICAgICAgICAgICAgICAgICAgIEJhY2t1cCBQVw0KDQog ICAgICAgICAgICAgICAgICBGaWd1cmUgNDogUmVkdW5kYW5jeSB3aXRoIFByb3ZpZGVyIFJTVFAN Cg0KICAgTVRVLTEsIE1UVS0yLCBQRTEtcnMgYW5kIFBFMi1ycyBwYXJ0aWNpcGF0ZSBpbiBwcm92 aWRlciBSU1RQLiAgQnkNCiAgIGNvbmZpZ3VyYXRpb24gaW4gUlNUUCBpdCBpcyBlbnN1cmVkIHRo YXQgdGhlIFBXIGJldHdlZW4gTVRVLTEgYW5kDQogICBQRTEtcnMgaXMgYWN0aXZlIGFuZCB0aGUg UFcgYmV0d2VlbiBNVFUtMiBhbmQgUEUyLXJzIGlzIGJsb2NrZWQgKG1hZGUNCiAgIGJhY2t1cCkg YXQgTVRVLTIgZW5kLiAgV2hlbiB0aGUgYWN0aXZlIFBXIGZhaWx1cmUgaXMgZGV0ZWN0ZWQgYnkN CiAgIFJTVFAsIGl0IGFjdGl2YXRlcyB0aGUgUFcgYmV0d2VlbiBNVFUtMiBhbmQgUEUyLXJzLiAg V2hlbiBQRTEtcnMNCiAgIGRldGVjdHMgdGhlIGZhaWxpbmcgUFcgdG8gTVRVLTEsIGl0IE1BWSB0 cmlnZ2VyIE1BQyBmbHVzaCBpbnRvIHRoZQ0KICAgZnVsbCBtZXNoIHdpdGggTUFDIEZsdXNoIFRM ViB0aGF0IGNhcnJpZXMgTj0xLiAgT3RoZXIgUEUtcnMgZGV2aWNlcw0KICAgaW4gdGhlIGZ1bGwg bWVzaCB0aGF0IHJlY2VpdmUgdGhlIE1BQyBmbHVzaCBtZXNzYWdlIGlkZW50aWZ5IHRoZWlyDQog ICByZXNwZWN0aXZlIFBXcyB0ZXJtaW5hdGluZyBvbiBQRTEtcnMgYW5kIGZsdXNoIGFsbCB0aGUg TUFDIGFkZHJlc3Nlcw0KICAgbGVhcm5lZCBmcm9tIGl0Lg0KDQogICBbUkZDNDc2Ml0gZGVzY3Jp YmVzIG11bHRpLWRvbWFpbiBWUExTIHNlcnZpY2Ugd2hlcmUgZnVsbHkgbWVzaGVkIFZQTFMNCiAg IG5ldHdvcmtzIChkb21haW5zKSBhcmUgY29ubmVjdGVkIHRvZ2V0aGVyIGJ5IGEgc2luZ2xlIHNw b2tlIFBXIHBlcg0KICAgVlBMUyBzZXJ2aWNlIGJldHdlZW4gdGhlIFZQTFMgImJvcmRlciIgUEUt cnMgZGV2aWNlcy4gIFRvIHByb3ZpZGUNCiAgIHJlZHVuZGFuY3kgYWdhaW5zdCBmYWlsdXJlIG9m IHRoZSBpbnRlci1kb21haW4gc3Bva2UsIGZ1bGwgbWVzaCBvZg0KICAgaW50ZXItZG9tYWluIHNw b2tlcyBjYW4gYmUgc2V0dXAgYmV0d2VlbiBib3JkZXIgUEUtcnMgZGV2aWNlcyBhbmQNCiAgIHBy b3ZpZGVyIFJTVFAgbWF5IGJlIHVzZWQgZm9yIHNlbGVjdGlvbiBvZiB0aGUgYWN0aXZlIGludGVy LWRvbWFpbg0KICAgc3Bva2UuICBJbiBjYXNlIG9mIGludGVyLWRvbWFpbiBzcG9rZSBQVyBmYWls dXJlLCBQRS1ycyBpbml0aWF0ZWQgTUFDDQogICB3aXRoZHJhd2FsIE1BWSBiZSB1c2VkIGZvciBv cHRpbWl6ZWQgTUFDIGZsdXNoaW5nIHdpdGhpbiBpbmRpdmlkdWFsDQogICBkb21haW5zLg0KDQog ICBGdXJ0aGVyLCB0aGUgcHJvY2VkdXJlcyBhcmUgYXBwbGljYWJsZSB3aXRoIGFueSBuYXRpdmUg RXRoZXJuZXQNCiAgIGFjY2VzcyB0b3BvbG9naWVzIG11bHRpLWhvbWVkIHRvIHR3byBvciBtb3Jl IFZQTFMgUEUtcnMgZGV2aWNlcy4gIFRoZQ0KICAgdGV4dCBpbiB0aGlzIHNlY3Rpb24gYXBwbGll cyBmb3IgdGhlIG5hdGl2ZSBFdGhlcm5ldCBjYXNlIHdoZXJlDQogICBhY3RpdmUvc3RhbmRieSBQ V3MgYXJlIHJlcGxhY2VkIHdpdGggdGhlIGFjdGl2ZS9zdGFuZGJ5IEV0aGVybmV0DQogICBlbmRw b2ludHMuICBBbiBvcHRpbWl6ZWQgTUFDIEZsdXNoIG1lc3NhZ2UgY2FuIGJlIGdlbmVyYXRlZCBi eSB0aGUNCiAgIFZQTFMgUEUtcnMgdGhhdCBkZXRlY3RzIHRoZSBmYWlsdXJlIGluIHRoZSBwcmlt YXJ5IEV0aGVybmV0IGFjY2Vzcy4NCg0KNS4yLiAgTERQIE1BQyBGbHVzaCBFeHRlbnNpb25zIGZv ciBQQkItVlBMUw0KDQogICBUaGUgdXNlIG9mIEFkZHJlc3MgV2l0aGRyYXcgbWVzc2FnZSB3aXRo IE1BQyBMaXN0IFRMViBpcyBwcm9wb3NlZCBpbg0KICAgW1JGQzQ3NjJdIGFzIGEgd2F5IHRvIGV4 cGVkaXRlIHJlbW92YWwgb2YgTUFDIGFkZHJlc3NlcyBhcyB0aGUgcmVzdWx0DQogICBvZiBhIHRv cG9sb2d5IGNoYW5nZSAoZS5nLiBmYWlsdXJlIG9mIGEgcHJpbWFyeSBsaW5rIG9mIGEgVlBMUyBQ RS1ycw0KICAgZGV2aWNlIGFuZCBpbXBsaWNpdGx5IHRoZSBhY3RpdmF0aW9uIG9mIGFuIGFsdGVy bmF0ZSBsaW5rIGluIGEgZHVhbC0NCiAgIGhvbWluZyB1c2UgY2FzZSkuICBUaGVzZSBleGlzdGlu ZyBwcm9jZWR1cmVzIGFwcGx5IGluZGl2aWR1YWxseSB0bw0KICAgQi1WUExTIGFuZCBJLWNvbXBv bmVudCBkb21haW5zLg0KDQogDQoNCg0KRHV0dGEsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIFNl cHRlbWJlciAyNiwgMjAxNCAgICAgICAgICAgICAgW1BhZ2UgMTddDQoMDQpJbnRlcm5ldC1EcmFm dCAgICAgT3B0aW1pemVkIE1BQyBXaXRoZHJhd2FsIGluIEgtVlBMUyAgICAgTWFyY2ggMjUsIDIw MTQNCg0KDQogICBXaGVuIGl0IGNvbWVzIHRvIHJlZmxlY3RpbmcgdG9wb2xvZ3kgY2hhbmdlcyBp biBhY2Nlc3MgbmV0d29ya3MNCiAgIGNvbm5lY3RlZCB0byBJLWNvbXBvbmVudCBhY3Jvc3MgdGhl IEItVlBMUyBkb21haW4gY2VydGFpbiBhZGRpdGlvbnMNCiAgIHNob3VsZCBiZSBjb25zaWRlcmVk IGFzIGRlc2NyaWJlZCBiZWxvdy4NCg0KICAgTUFDIFN3aXRjaGluZyBpbiBQQkIgaXMgYmFzZWQg b24gdGhlIG1hcHBpbmcgb2YgQ3VzdG9tZXIgTUFDcyAoQ01BQ3MpDQogICB0byBCYWNrYm9uZSBN QUMocykgKEJNQUNzKS4gIEEgdG9wb2xvZ3kgY2hhbmdlIGluIHRoZSBhY2Nlc3MNCiAgIChJLWRv bWFpbikgc2hvdWxkIGp1c3QgaW52b2tlIHRoZSBmbHVzaGluZyBvZiBDTUFDIGVudHJpZXMgaW4g UEJCDQogICBQRXMnIEZJQihzKSBhc3NvY2lhdGVkIHdpdGggdGhlIEktY29tcG9uZW50KHMpIGlt cGFjdGVkIGJ5IHRoZQ0KICAgZmFpbHVyZS4gIFRoZXJlIGlzIGEgbmVlZCB0byBpbmRpY2F0ZSB0 aGUgUEJCIFBFIChCTUFDIHNvdXJjZSkgdGhhdA0KICAgb3JpZ2luYXRlZCB0aGUgTUFDIEZsdXNo IG1lc3NhZ2UgdG8gc2VsZWN0aXZlbHkgZmx1c2ggb25seSB0aGUgTUFDcw0KICAgdGhhdCBhcmUg YWZmZWN0ZWQuDQoNCiAgIFRoZXNlIGdvYWxzIGNhbiBiZSBhY2hpZXZlZCBieSBpbmNsdWRpbmcg dGhlIE1BQyBGbHVzaCBQYXJhbWV0ZXJzIFRMVg0KICAgaW4gdGhlIExEUCBBZGRyZXNzIFdpdGhk cmF3IG1lc3NhZ2UgdG8gaW5kaWNhdGUgdGhlIHBhcnRpY3VsYXINCiAgIGRvbWFpbihzKSByZXF1 aXJpbmcgTUFDIGZsdXNoLiAgT24gdGhlIG90aGVyIGVuZCwgdGhlIHJlY2VpdmluZyBQRXMNCiAg IFNIT1VMRCB1c2UgdGhlIGluZm9ybWF0aW9uIGZyb20gdGhlIG5ldyBUTFYgdG8gZmx1c2ggb25s eSB0aGUgcmVsYXRlZA0KICAgRklCIGVudHJ5L2VudHJpZXMgaW4gdGhlIEktY29tcG9uZW50IGlu c3RhbmNlKHMpLg0KDQogICBBdCBsZWFzdCBvbmUgb2YgdGhlIGZvbGxvd2luZyBzdWItVExWcyBN VVNUIGJlIGluY2x1ZGVkIGluIHRoZSBNQUMNCiAgIEZsdXNoIFBhcmFtZXRlcnMgVExWIGlmIHRo ZSBDLWZsYWcgaXMgc2V0IHRvIDE6DQoNCiAgIG8gIFBCQiBCTUFDIExpc3QgU3ViLVRMVjoNCg0K ICAgVHlwZTogSUFOQSBUQkRCDQoNCiAgIExlbmd0aDogdmFsdWUgbGVuZ3RoIGluIG9jdGV0cy4g IEF0IGxlYXN0IG9uZSBCTUFDIGFkZHJlc3MgTVVTVCBiZQ0KICAgcHJlc2VudCBpbiB0aGUgbGlz dC4NCg0KICAgVmFsdWU6IG9uZSBvciBhIGxpc3Qgb2YgNDggYml0cyBCTUFDIGFkZHJlc3Nlcy4g IFRoZXNlIGFyZSB0aGUgc291cmNlDQogICBCTUFDIGFkZHJlc3NlcyBhc3NvY2lhdGVkIHdpdGgg dGhlIEItVlBMUyBpbnN0YW5jZSB0aGF0IG9yaWdpbmF0ZWQNCiAgIHRoZSBNQUMgV2l0aGRyYXcg bWVzc2FnZS4gIEl0IHdpbGwgYmUgdXNlZCB0byBpZGVudGlmeSB0aGUgQ01BQyhzKQ0KICAgbWFw cGVkIHRvIHRoZSBCTUFDKHMpIGxpc3RlZCBpbiB0aGUgc3ViLVRMVi4NCg0KICAgbyAgUEJCIElT SUQgTGlzdCBTdWItVExWOg0KDQogICBUeXBlOiBJQU5BIFRCREMNCg0KICAgTGVuZ3RoOiB2YWx1 ZSBsZW5ndGggaW4gb2N0ZXRzLiAgWmVybyBpbmRpY2F0ZXMgYW4gZW1wdHkgSVNJRCBsaXN0Lg0K ICAgQW4gZW1wdHkgSVNJRCBsaXN0IG1lYW5zIHRoYXQgdGhlIGZsdXNoIGFwcGxpZXMgdG8gYWxs IHRoZSBJU0lEcw0KICAgbWFwcGVkIHRvIHRoZSBCLVZQTFMgaW5kaWNhdGVkIGJ5IHRoZSBGRUMg VExWLg0KDQogICBWYWx1ZTogb25lIG9yIGEgbGlzdCBvZiAyNCBiaXRzIElTSURzIHRoYXQgcmVw cmVzZW50IHRoZSBJLWNvbXBvbmVudA0KICAgRklCKHMpIHdoZXJlIHRoZSBNQUMgRmx1c2ggbmVl ZHMgdG8gdGFrZSBwbGFjZS4NCg0KNS4yLjEuICBNQUMgRmx1c2ggVExWIFByb2Nlc3NpbmcgUnVs ZXMgZm9yIFBCQi1WUExTDQoNCiAgIFRoZSBmb2xsb3dpbmcgc3RlcHMgZGVzY3JpYmUgdGhlIGRl dGFpbHMgb2YgdGhlIHByb2Nlc3NpbmcgcnVsZXMgZm9yDQogICBNQUMgRmx1c2ggVExWIGluIHRo ZSBjb250ZXh0IG9mIFBCQi1WUExTOg0KIA0KDQoNCkR1dHRhLCBldCBhbC4gICAgICAgICAgRXhw aXJlcyBTZXB0ZW1iZXIgMjYsIDIwMTQgICAgICAgICAgICAgIFtQYWdlIDE4XQ0KDA0KSW50ZXJu ZXQtRHJhZnQgICAgIE9wdGltaXplZCBNQUMgV2l0aGRyYXdhbCBpbiBILVZQTFMgICAgIE1hcmNo IDI1LCAyMDE0DQoNCg0KICAgVGhlIE1BQyBGbHVzaCBjYW4gYmUgZm9yIHRoZSBCLVZQTFMgQi1j b21wb25lbnQgKHdoaWNoIGFwcGxpZXMgdG8gdGhlDQogICBCTUFDcyBhbmQgdGhlIGNvcnJlc3Bv bmRpbmcgQ01BQ3MpIG9yIHRoZSBCLVZQTFMgSS1jb21wb25lbnQgKHdoaWNoDQogICBhcHBsaWVz IHRvIHRoZSBDTUFDcykgd2hpY2ggaXMgZGVzY3JpYmVkIGluIG1vcmUgZGV0YWlsIGhlcmUuDQoN CiAgIC0gVGhlIE1BQyBGbHVzaCBNZXNzYWdlLCBpbmNsdWRpbmcgdGhlIE1BQyBGbHVzaCBQYXJh bWV0ZXJzIFRMViBpcw0KICAgaW5pdGlhdGVkIGJ5IHRoZSBQQkIgUEUocykgZXhwZXJpZW5jaW5n IGEgVG9wb2xvZ3kgQ2hhbmdlIGV2ZW50IGluDQogICBvbmUgb3IgbXVsdGlwbGUgY3VzdG9tZXIg SS1jb21wb25lbnQocykuDQoNCiAgIC0gVGhlIGZsYWdzIGFyZSBzZXQgYWNjb3JkaW5nbHkgdG8g aW5kaWNhdGUgdGhlIHR5cGUgb2YgTUFDIEZsdXNoDQogICByZXF1aXJlZCBmb3IgdGhpcyBldmVu dDogRm9yIGV4YW1wbGUgZm9yIGFuIEItVlBMUyBJLUNvbXBvbmVudCBOPTANCiAgIChGbHVzaC1h bGwtYnV0LW1pbmUpLCBDPTEgKEZsdXNoIG9ubHkgQ01BQyBGSUJzKS4NCg0KICAgLSBUaGUgUEJC IFN1Yi1UTFZzIChCTUFDIGFuZCBJU0lEIExpc3RzKSBhcmUgaW5jbHVkZWQgYWNjb3JkaW5nIHRv DQogICB0aGUgY29udGV4dCBvZiB0b3BvbG9neSBjaGFuZ2UuDQoNCiAgIC0gT24gcmVjZXB0aW9u IG9mIHRoZSBNQUMgRmx1c2ggbWVzc2FnZSwgdGhlIEItVlBMUyBpbnN0YW5jZXMNCiAgIGNvcnJl c3BvbmRpbmcgdG8gdGhlIEZFQyBUTFYgaW4gdGhlIG1lc3NhZ2UgbXVzdCBpbnRlcnByZXQgdGhl DQogICBjb250ZW50IG9mIE1BQyBGbHVzaCBQYXJhbWV0ZXJzIFRMVi4gIElmIHRoZSBDLWJpdCBp cyBzZXQgdG8gMSB0aGVuDQogICBCYWNrYm9uZSBDb3JlIEJyaWRnZXMgKEJDQikgaW4gdGhlIFBC Qi1WUExTIFNIT1VMRCBOT1QgZmx1c2ggdGhlaXINCiAgIEJNQUMgRklCcy4gIFRoZSBCLVZQTFMg Y29udHJvbCBwbGFuZSBTSE9VTEQgcHJvcGFnYXRlIHRoZSBNQUMgRmx1c2gNCiAgIGZvbGxvd2lu ZyB0aGUgZGF0YS1wbGFuZSBzcGxpdC1ob3Jpem9uIHJ1bGVzIHRvIHRoZSBlc3RhYmxpc2hlZA0K ICAgQi1WUExTIHRvcG9sb2d5Lg0KDQogICAtIFRoZSB1c2FnZSBhbmQgcHJvY2Vzc2luZyBydWxl cyBvZiBNQUMgRmx1c2ggUGFyYW1ldGVycyBUTFYgaW4gdGhlDQogICBjb250ZXh0IG9mIEJhY2ti b25lIEVkZ2UgQnJpZGdlcyAoQkVCKSBpcyBhcyBmb2xsb3dzOg0KDQogICAtIFRoZSBQQkIgSVNJ RCBMaXN0IGlzIHVzZWQgdG8gZGV0ZXJtaW5lIHRoZSBwYXJ0aWN1bGFyIElTSUQgRklCcw0KICAg KEktY29tcG9uZW50KSB0aGF0IG5lZWQgdG8gYmUgY29uc2lkZXJlZCBmb3IgZmx1c2hpbmcgYWN0 aW9uLiAgSWYgdGhlDQogICBQQkIgSVNJRCBMaXN0IHN1Yi10bHYgaXMgbm90IGluY2x1ZGVkIGlu IGEgcmVjZWl2ZWQgbWVzc2FnZSB0aGVuIGFsbA0KICAgdGhlIElTSUQgRklCcyBhc3NvY2lhdGVk IHdpdGggdGhlIHJlY2VpdmluZyBCLVZQTFMgU0hPVUxEIGJlDQogICBjb25zaWRlcmVkIGZvciBm bHVzaGluZyBhY3Rpb24uDQoNCiAgIC0gVGhlIFBCQiBCTUFDIExpc3QgaXMgdXNlZCB0byBpZGVu dGlmeSBmcm9tIHRoZSBJU0lEIEZJQnMgaW4gdGhlDQogICBwcmV2aW91cyBzdGVwIHRvIHNlbGVj dGl2ZWx5IGZsdXNoIEJNQUMgdG8gQ01BQyBhc3NvY2lhdGlvbnMNCiAgIGRlcGVuZGluZyBvbiB0 aGUgTiBmbGFnIHNwZWNpZmllZCBiZWxvdy4gIElmIFBCQiBCTUFDIExpc3QgU3ViLVRMViBpcw0K ICAgbm90IGluY2x1ZGVkIGluIGEgcmVjZWl2ZWQgbWVzc2FnZSB0aGVuIGFsbCBCTUFDIHRvIENN QUMgYXNzb2NpYXRpb24NCiAgIGluIGFsbCBJU0lEIEZJQnMgKEktY29tcG9uZW50KSBhcyBzcGVj aWZpZWQgYnkgdGhlIElTSUQgTGlzdCBhcmUNCiAgIGNvbnNpZGVyZWQgZm9yIHJlcXVpcmVkIGZs dXNoaW5nIGFjdGlvbiwgYWdhaW4gZGVwZW5kaW5nIG9uIHRoZSBODQogICBmbGFnIHNwZWNpZmll ZCBiZWxvdy4NCg0KICAgLSBOZXh0LCBkZXBlbmRpbmcgb24gdGhlIE4gZmxhZyB2YWx1ZSB0aGUg Zm9sbG93aW5nIGFjdGlvbnMgYXBwbHk6DQoNCiAgIC0gTj0wLCBhbGwgdGhlIENNQUNzIGluIHRo ZSBzZWxlY3RlZCBJU0lEIEZJQnMgU0hPVUxEIGJlIGZsdXNoZWQgd2l0aA0KICAgdGhlIGV4Y2Vw dGlvbiBvZiB0aGUgcmVzdWx0ZWQgQ01BQyBsaXN0IGZyb20gdGhlIEJNQUMgTGlzdCBtZW50aW9u ZWQNCiAgIGluIHRoZSBtZXNzYWdlLiAgKCJGbHVzaCBhbGwgYnV0IHRoZSBDTUFDcyBhc3NvY2lh dGVkIHdpdGggdGhlDQogICBCTUFDKHMpIGluIHRoZSBCTUFDIExpc3QgU3ViLVRMViBmcm9tIHRo ZSBGSUJzIGFzc29jaWF0ZWQgd2l0aCB0aGUNCiAgIElTSUQgbGlzdCIpLg0KDQogDQoNCg0KRHV0 dGEsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAyNiwgMjAxNCAgICAgICAgICAg ICAgW1BhZ2UgMTldDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgT3B0aW1pemVkIE1BQyBXaXRoZHJh d2FsIGluIEgtVlBMUyAgICAgTWFyY2ggMjUsIDIwMTQNCg0KDQogICAtIE49MSwgYWxsIHRoZSBy ZXN1bHRlZCBDTUFDcyBTSE9VTEQgYmUgZmx1c2hlZCAoIkZsdXNoIGFsbCB0aGUgQ01BQ3MNCiAg IGFzc29jaWF0ZWQgd2l0aCB0aGUgQk1BQyhzKSBpbiB0aGUgQk1BQyBMaXN0IFN1Yi1UTFYgZnJv bSB0aGUgRklCcw0KICAgYXNzb2NpYXRlZCB3aXRoIHRoZSBJU0lEIGxpc3QiKS4NCg0KNS4yLjIu ICBBcHBsaWNhYmlsaXR5IG9mIE1BQyBGbHVzaCBQYXJhbWV0ZXJzIFRMVg0KDQogICBJZiBNQUMg Rmx1c2ggUGFyYW1ldGVycyBUTFYgaXMgcmVjZWl2ZWQgYnkgYSBCYWNrYm9uZSBFZGdlIEJyaWRn ZXMNCiAgIChCRUIpIGluIGEgUEJCLVZQTFMgdGhhdCBkb2VzIG5vdCB1bmRlcnN0YW5kIHRoZSBU TFYgdGhlbiBpdCBtYXkNCiAgIHJlc3VsdCBpbiB1bmRlc2lyYWJsZSBNQUMgZmx1c2hpbmcgYWN0 aW9uLiAgSXQgaXMgUkVDT01NRU5ERUQgdGhhdA0KICAgYWxsIFBFLXJzIGRldmljZXMgcGFydGlj aXBhdGluZyBpbiBQQkItVlBMUyBzdXBwb3J0IE1BQyBGbHVzaA0KICAgUGFyYW1ldGVycyBUTFYu ICBJZiB0aGlzIGlzIG5vdCBwb3NzaWJsZSB0aGUgTUFDIEZsdXNoIFBhcmFtZXRlcnMgVExWDQog ICBTSE9VTEQgYmUgZGlzYWJsZWQgYXMgbWVudGlvbmVkIGluIHNlY3Rpb24gNiBPcGVyYXRpb25h bA0KICAgQ29uc2lkZXJhdGlvbnMuDQoNCiAgIFRoZSBNQUMgRmx1c2ggUGFyYW1ldGVycyBUTFYg aXMgYWxzbyBhcHBsaWNhYmxlIHRvIHJlZ3VsYXIgVlBMUw0KICAgY29udGV4dCBhcyB3ZWxsIGFz IGV4cGxhaW5lZCBpbiBzZWN0aW9uIDMuMS4xLiAgVG8gYWNoaWV2ZSBuZWdhdGl2ZQ0KICAgTUFD IEZsdXNoIChmbHVzaC1hbGwtZnJvbS1tZSkgaW4gcmVndWxhciBWUExTIGNvbnRleHQsIHRoZSBN QUMgRmx1c2gNCiAgIFBhcmFtZXRlcnMgVExWIFNIT1VMRCBiZSBlbmNvZGVkIHdpdGggQz0wIGFu ZCBOID0gMSB3aXRob3V0IGluY2x1c2lvbg0KICAgb2YgYW55IFN1Yi1UTFZzLiAgTmVnYXRpdmUg TUFDIGZsdXNoIGlzIGhpZ2hseSBkZXNpcmFibGUgaW4gc2NlbmFyaW9zDQogICB3aGVuIFZQTFMg YWNjZXNzIHJlZHVuZGFuY3kgaXMgcHJvdmlkZWQgYnkgRXRoZXJuZXQgUmluZyBQcm90ZWN0aW9u DQogICBhcyBzcGVjaWZpZWQgaW4gSVRVLVQgW0lUVS5HODAzMl1zcGVjaWZpY2F0aW9uLg0KDQoN CjYuICBPcGVyYXRpb25hbCBDb25zaWRlcmF0aW9ucw0KDQogICBBcyBtZW50aW9uZWQgYmVmb3Jl LCBpZiBNQUMgRmx1c2ggUGFyYW1ldGVycyBUTFYgaXMgbm90IHVuZGVyc3Rvb2QgYnkNCiAgIGEg cmVjZWl2ZXIgdGhlbiBpdCB3b3VsZCByZXN1bHQgaW4gdW5kZXNpcmVkIGZsdXNoaW5nIGFjdGlv bi4gIFRvDQogICBhdm9pZCB0aGlzIG9uZSBzb2x1dGlvbiBpcyB0byBkZXZlbG9wIGFuIExEUCBi YXNlZCBjYXBhYmlsaXR5DQogICBuZWdvdGlhdGlvbiBtZWNoYW5pc20gdG8gbmVnb3RpYXRlIHN1 cHBvcnQgb2YgdmFyaW91cyBNQUMgRmx1c2hpbmcNCiAgIGNhcGFiaWxpdHkgYmV0d2VlbiBQRS1y cyBkZXZpY2VzIGluIGEgVlBMUyBpbnN0YW5jZS4gIEEgbmVnb3RpYXRpb24NCiAgIG1lY2hhbmlz bSBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50IGJ1dCBpcyBub3QgcmVxdWly ZWQNCiAgIHRvIGRlcGxveSB0aGlzIG9wdGltaXplZCBNQUMgZmx1c2ggYXMgZGVzY3JpYmVkIGJl bG93Lg0KDQogICBWUExTIG1heSBiZSB1c2VkIHdpdGggb3Igd2l0aG91dCB0aGUgb3B0aW1pemF0 aW9uLiAgRm9yIHRoZSBjYXNlIG9mDQogICBQQkItVlBMUyB0aGlzIG9wZXJhdGlvbiBpcyB0aGUg b25seSBtZXRob2Qgc3VwcG9ydGVkIGZvciBJU0lEcy4gIElmDQogICBhbiBvcGVyYXRvciB3YW50 cyB0aGUgb3B0aW1pemF0aW9ucyBmb3IgVlBMUyBpdCBpcyB0aGUgb3BlcmF0b3Incw0KICAgcmVz cG9uc2liaWxpdHkgdG8gbWFrZSBzdXJlIHRoZSBWUExTIHRoYXQgYXJlIGNhcGFibGUgb2Ygc3Vw cG9ydGluZw0KICAgdGhlIG9wdGltaXphdGlvbiBhcmUgcHJvcGVybHkgY29uZmlndXJlZC4gIEZy b20gb3BlcmF0aW9uYWwNCiAgIHN0YW5kcG9pbnQsIGl0IGlzIFJFQ09NTUVOREVEIHRoYXQgaW1w bGVtZW50YXRpb25zIG9mIHRoZSBzb2x1dGlvbg0KICAgcHJvdmlkZSBhZG1pbmlzdHJhdGl2ZSBj b250cm9sIHRvIHNlbGVjdCB0aGUgZGVzaXJlZCBNQUMgRmx1c2hpbmcNCiAgIGFjdGlvbiB0b3dh cmRzIGEgUEUtcnMgZGV2aWNlIGluIHRoZSBWUExTLiAgVGh1cyBpbiB0aGUgdG9wb2xvZ3kNCiAg IGRlc2NyaWJlZCBpbiBmaWd1cmUgMiwgaXQgaXMgcG9zc2libGUgdGhhdCBQRTEtcnMgd291bGQg aW5pdGlhdGUNCiAgIG9wdGltaXplZCBNQUMgRmx1c2ggdG93YXJkcyB0aGUgUEUtcnMgZGV2aWNl cyB0aGF0IHN1cHBvcnQgdGhlDQogICBzb2x1dGlvbiB3aGVyZWFzIFBFMi1ycyB3b3VsZCBpbml0 aWF0ZSBbUkZDNDc2Ml0gc3R5bGUgb2YgTUFDIEZsdXNoIA0KICAgdG93YXJkcyB0aGUgUEUtcnMg ZGV2aWNlcyB0aGF0IGRvIG5vdCBzdXBwb3J0IHRoZSBvcHRpbWl6ZWQgc29sdXRpb24uDQogICBU aGUgUEUtcnMgdGhhdCBzdXBwb3J0cyB0aGUgTUFDIEZsdXNoIFBhcmFtZXRlcnMgVExWIE1VU1Qg c3VwcG9ydCB0aGUNCiAgIFJGQzQ3NjIgTUFDIGZsdXNoIHByb2NlZHVyZSBmb3IgY29tcGxldGVu ZXNzLg0KDQogDQoNCg0KRHV0dGEsIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIFNlcHRlbWJlciAy NiwgMjAxNCAgICAgICAgICAgICAgW1BhZ2UgMjBdDQoMDQpJbnRlcm5ldC1EcmFmdCAgICAgT3B0 aW1pemVkIE1BQyBXaXRoZHJhd2FsIGluIEgtVlBMUyAgICAgTWFyY2ggMjUsIDIwMTQNCg0KDQo3 LiAgSUFOQSBDb25zaWRlcmF0aW9ucw0KDQo3LjEgTmV3IExEUCBUTFYNCg0KICAgSUFOQSBtYWlu dGFpbnMgYSByZWdpc3RyeSBjYWxsZWQgIkxhYmVsIERpc3RyaWJ1dGlvbiBQcm90b2NvbCAoTERQ KQ0KICAgUGFyYW1ldGVycyIgd2l0aCBhIHN1Yi1yZWdpc3RyeSBjYWxsZWQgIlRMViBUeXBlIE5h bWUgU3BhY2UiLg0KDQogICBJQU5BIGlzIHJlcXVlc3RlZCB0byBhbGxvY2F0ZSB0aHJlZSBuZXcg Y29kZSBwb2ludHMgZnJvbSB0aGUNCiAgIHVuYXNzaWduZWQgcmFuZ2UgMHgwNDA1LTB4MDRGRiBh cyBmb2xsb3dzLiBJQU5BIGlzIHJlcXVlc3RlZCB0bw0KICAgYWxsb2NhdGUgY29uc2VjdXRpdmUg bnVtYmVycy4NCg0KICAgICAgVmFsdWUgfCBEZXNjcmlwdGlvbiAgICAgICAgICAgICAgfCBSZWZl cmVuY2UgIHwgTm90ZXMNCiAgICAgIC0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0NCiAgICAgIFRCREEgIHwgTUFDIEZsdXNoIFBhcmFtZXRl cnMgVExWIHwgW1RoaXMuSS1EXSB8DQogICAgICBUQkRCICB8IFBCQiBCTUFDIExpc3QgU3ViLVRM ViAgICB8IFtUaGlzLkktRF0gfA0KICAgICAgVEJEQyAgfCBQQkIgSVNJRCBMaXN0IFN1Yi1UTFYg ICAgfCBbVGhpcy5JLURdIHwNCg0KNy4yIE5ldyBSZWdpc3RyeSBmb3IgTUFDIEZsdXNoIEZsYWdz IA0KDQogICBJQU5BIGlzIHJlcXVlc3RlZCB0byBjcmVhdGUgYSBuZXcgc3ViLXJlZ2lzdHJ5IHVu ZGVyICJMYWJlbA0KICAgRGlzdHJpYnV0aW9uIFByb3RvY29sIChMRFApIFBhcmFtZXRlcnMiIGNh bGxlZCAiTUFDIEZsdXNoIEZsYWdzIi4NCg0KICAgSUFOQSBpcyByZXF1ZXN0ZWQgdG8gcG9wdWxh dGUgdGhlIHJlZ2lzdHJ5IGFzIGZvbGxvd3M6DQoNCiAgICAgIEJpdCBudW1iZXIgfCBIZXggIHwg QWJicmV2aWF0aW9uIHwgRGVzY3JpcHRpb24gICAgICB8IFJlZmVyZW5jZQ0KICAgICAgLS0tLS0t LS0tLS0rLS0tLS0tKy0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0t LS0NCiAgICAgICAgMCAgICAgICAgfCAweDgwIHwgQyAgICAgICAgICAgIHwgQ29udGV4dCAgICAg ICAgICB8IFtUaGlzLkktRF0NCiAgICAgICAgMSAgICAgICAgfCAweDQwIHwgTiAgICAgICAgICAg IHwgTmVnYXRpdmUgZmx1c2ggICB8IFtUaGlzLkktRF0NCiAgICAgICAgMi03ICAgICAgfCAgICAg IHwgICAgICAgICAgICAgIHwgVW5hc3NpZ25lZCAgICAgICB8DQoNCiAgIE90aGVyIG5ldyBiaXRz IGFyZSB0byBiZSBhc3NpZ25lZCBieSBTdGFuZGFyZHMgQWN0aW9uLg0KDQo4LiAgU2VjdXJpdHkg Q29uc2lkZXJhdGlvbnMNCg0KICAgQ29udHJvbCBwbGFuZSBhc3BlY3RzOg0KDQogICBMRFAgc2Vj dXJpdHkgKGF1dGhlbnRpY2F0aW9uKSBtZXRob2RzIGFzIGRlc2NyaWJlZCBpbiBbUkZDNTAzNl0g aXMNCiAgIGFwcGxpY2FibGUgaGVyZS4gIEZ1cnRoZXIgdGhpcyBkb2N1bWVudCBpbXBsZW1lbnRz IHNlY3VyaXR5DQogICBjb25zaWRlcmF0aW9ucyBhcyBpbiBbUkZDNDQ0N10gYW5kIFtSRkM0NzYy XS4gVGhlIGV4dGVuc2lvbnMgZGVmaW5lZA0KICAgaGVyZSBvcHRpbWl6ZSB0aGUgZmx1c2hpbmcg YW5kIHNvIHRoZSByaXNrIG9mIHNlY3VyaXR5IGF0dGFja3MgaXMNCiAgIHJlZHVjZWQuIEhvd2V2 ZXIsIGluIHRoZSBldmVudCB0aGF0IHRoZSBjb25maWd1cmF0aW9uIG9mIHN1cHBvcnQgZm9yDQog ICB0aGUgbmV3IFRMViBjYW4gYmUgc3Bvb2ZlZCwgc3ViLW9wdGltYWwgYmVoYXZpb3Igd2lsbCBi ZSBzZWVuLg0KDQogICBEYXRhIHBsYW5lIGFzcGVjdHM6DQoNCiAgIFRoaXMgc3BlY2lmaWNhdGlv biBkb2VzIG5vdCBoYXZlIGFueSBpbXBhY3Qgb24gdGhlIFZQTFMgZm9yd2FyZGluZw0KICAgcGxh bmUgYnV0IGNhbiBpbXByb3ZlIE1BQyBmbHVzaGluZyBiZWhhdmlvci4NCg0KIA0KDQoNCkR1dHRh LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBTZXB0ZW1iZXIgMjYsIDIwMTQgICAgICAgICAgICAg IFtQYWdlIDIxXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAgIE9wdGltaXplZCBNQUMgV2l0aGRyYXdh bCBpbiBILVZQTFMgICAgIE1hcmNoIDI1LCAyMDE0DQoNCg0KOS4gIENvbnRyaWJ1dGluZyBBdXRo b3JzDQoNCiAgIFRoZSBhdXRob3JzIHdvdWxkIGxpa2UgdG8gdGhhbmsgTWFyYyBMYXNzZXJyZSBh bmQgRG9uIEZlZHlrIHdobyBtYWRlDQogICBhIG1ham9yIGNvbnRyaWJ1dGlvbiB0byB0aGUgZGV2 ZWxvcG1lbnQgb2YgdGhpcyBkb2N1bWVudC4NCg0KICAgTWFyYyBMYXNzZXJyZQ0KDQogICBBbGNh dGVsLUx1Y2VudA0KDQogICBFbWFpbDogbWFyYy5sYXNzZXJyZUBhbGNhdGVsLWx1Y2VudC5jb20N Cg0KICAgRG9uIEZlZHlrDQoNCiAgIEhld2xldHQtUGFja2FyZCBDb21wYW55DQoNCiAgIEVtYWls OiBkb24uZmVkeWtAaHAuY29tDQoNCg0KMTAuICBBY2tub3dsZWRnZW1lbnRzDQoNCiAgIFRoZSBh dXRob3JzIHdvdWxkIGxpa2UgdG8gdGhhbmsgdGhlIGZvbGxvd2luZyBwZW9wbGUgd2hvIGhhdmUN CiAgIHByb3ZpZGVkIHZhbHVhYmxlIGNvbW1lbnRzIGFuZCBmZWVkYmFjayBvbiB0aGUgdG9waWNz IGRpc2N1c3NlZCBpbg0KICAgdGhpcyBkb2N1bWVudDogRGltaXRyaSBQYXBhZGltaXRyaW91LCBK b3JnZSBSYWJhZGFuLCBQcmFzaGFudGgNCiAgIElzaHdhciwgVmlwaW4gSmFpbiwgSm9obiBSaWdi eSwgQWxpIFNhamFzc2ksIFdpbSBIZW5kZXJpY2t4LCBQYXVsDQogICBLd29rLCBNYWFydGVuIFZp c3NlcnMsIERhbmllbCBDb2huLCBOYWJpbCBCaXRhciwgR2lsZXMgSGVyb24gYW5kDQogICBBZHJp YW4gRmFycmVsLg0KDQoNCjExLiAgUmVmZXJlbmNlcw0KDQoxMS4xLiAgTm9ybWF0aXZlIFJlZmVy ZW5jZXMNCg0KICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3b3JkcyBmb3IgdXNlIGlu IFJGQ3MgdG8gSW5kaWNhdGUNCiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwgQkNQ IDE0LCBSRkMgMjExOSwgTWFyY2ggMTk5Ny4NCg0KICAgW1JGQzQ0NDddICBNYXJ0aW5pLCBMLiwg Um9zZW4sIEUuLCBFbC1BYXdhciwgTi4sIFNtaXRoLCBULiwgYW5kIEcuDQogICAgICAgICAgICAg IEhlcm9uLCAiUHNldWRvd2lyZSBTZXR1cCBhbmQgTWFpbnRlbmFuY2UgVXNpbmcgdGhlIExhYmVs DQogICAgICAgICAgICAgIERpc3RyaWJ1dGlvbiBQcm90b2NvbCAoTERQKSIsIFJGQyA0NDQ3LCBB cHJpbCAyMDA2Lg0KDQogICBbUkZDNDc2Ml0gIExhc3NlcnJlLCBNLiBhbmQgVi4gS29tcGVsbGEs ICJWaXJ0dWFsIFByaXZhdGUgTEFOIFNlcnZpY2UNCiAgICAgICAgICAgICAgKFZQTFMpIFVzaW5n IExhYmVsIERpc3RyaWJ1dGlvbiBQcm90b2NvbCAoTERQKSBTaWduYWxpbmciLA0KICAgICAgICAg ICAgICBSRkMgNDc2MiwgSmFudWFyeSAyMDA3Lg0KDQogICBbUkZDNTAzNl0gIEFuZGVyc3Nvbiwg TC4sIE1pbmVpLCBJLiwgYW5kIEIuIFRob21hcywgIkxEUA0KICAgICAgICAgICAgICBTcGVjaWZp Y2F0aW9uIiwgUkZDIDUwMzYsIE9jdG9iZXIgMjAwNy4NCg0KMTEuMi4gIEluZm9ybWF0aXZlIFJl ZmVyZW5jZXMNCg0KIA0KDQoNCkR1dHRhLCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBTZXB0ZW1i ZXIgMjYsIDIwMTQgICAgICAgICAgICAgIFtQYWdlIDIyXQ0KDA0KSW50ZXJuZXQtRHJhZnQgICAg IE9wdGltaXplZCBNQUMgV2l0aGRyYXdhbCBpbiBILVZQTFMgICAgIE1hcmNoIDI1LCAyMDE0DQoN Cg0KICAgW1JGQzcwNDFdICBCYWx1cywgRi4sIFNhamFzc2ksIEEuLCBhbmQgTi4gQml0YXIsICJF eHRlbnNpb25zIHRvIHRoZQ0KICAgICAgICAgICAgICBWaXJ0dWFsIFByaXZhdGUgTEFOIFNlcnZp Y2UgKFZQTFMpIFByb3ZpZGVyIEVkZ2UgKFBFKQ0KICAgICAgICAgICAgICBNb2RlbCBmb3IgUHJv dmlkZXIgQmFja2JvbmUgQnJpZGdpbmciLFJGQyA3MDQxLA0KICAgICAgICAgICAgICBOb3ZlbWJl ciAyMDEzLg0KDQogICBbSS1ELmlldGYtbDJ2cG4tdnBscy1tdWx0aWhvbWluZ10NCiAgICAgICAg ICAgICAgS290aGFyaSwgQi4sIEtvbXBlbGxhLCBLLiwgSGVuZGVyaWNreCwgVy4sIEJhbHVzLCBG LiwNCiAgICAgICAgICAgICAgUGFsaXNsYW1vdmljLCBTLiwgVXR0YXJvLCBKLiwgYW5kIFcuIExp biwgIkJHUCBiYXNlZA0KICAgICAgICAgICAgICBNdWx0aS1ob21pbmcgaW4gVmlydHVhbCBQcml2 YXRlIExBTiBTZXJ2aWNlIiwNCiAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1sMnZwbi12cGxzLW11 bHRpaG9taW5nLTA2ICh3b3JrIGluIHByb2dyZXNzKSwNCiAgICAgICAgICAgICAgT2N0b2JlciAy MDEyLg0KDQogICBbSUVFRS44MDIuMVEtMjAxMV0NCiAgICAgICAgICAgICAgSUVFRSwgIklFRUUg U3RhbmRhcmQgZm9yIExvY2FsIGFuZCBtZXRyb3BvbGl0YW4gYXJlYQ0KICAgICAgICAgICAgICBu ZXR3b3JrcyAtLSBNZWRpYSBBY2Nlc3MgQ29udHJvbCAoTUFDKSBCcmlkZ2VzIGFuZCBWaXJ0dWFs DQogICAgICAgICAgICAgIEJyaWRnZWQgTG9jYWwgQXJlYSBOZXR3b3JrcyIsIElFRUUgU3RkIDgw Mi4xUSwgMjAxMS4NCg0KICAgW0lUVS5HODAzMl0NCiAgICAgICAgICAgICAgSW50ZXJuYXRpb25h bCBUZWxlY29tbXVuaWNhdGlvbnMgVW5pb24sICJFdGhlcm5ldCByaW5nDQogICAgICAgICAgICAg IHByb3RlY3Rpb24gc3dpdGNoaW5nIiwgSVRVLVQgUmVjb21tZW5kYXRpb24gRy44MDMyLA0KICAg ICAgICAgICAgICBNYXJjaCAyMDEwLg0KDQogICBbUkZDNDY2NF0gIEFuZGVyc3NvbiwgTC4gYW5k IEUuIFJvc2VuLCAiRnJhbWV3b3JrIGZvciBMYXllciAyIFZpcnR1YWwNCiAgICAgICAgICAgICAg UHJpdmF0ZSBOZXR3b3JrcyAoTDJWUE5zKSIsIFJGQyA0NjY0LCBTZXB0ZW1iZXIgMjAwNi4NCg0K ICAgW1JGQzY3MThdICBNdWxleSwgUC4sIEFpc3Nhb3VpLCBNLiwgYW5kIE0uIEJvY2NpLCAiUHNl dWRvd2lyZQ0KICAgICAgICAgICAgICBSZWR1bmRhbmN5IiwgUkZDIDY3MTgsIEF1Z3VzdCAyMDEy Lg0KDQoNCkF1dGhvcnMnIEFkZHJlc3Nlcw0KDQogICBQcmFuamFsIEt1bWFyIER1dHRhDQogICBB bGNhdGVsLUx1Y2VudA0KICAgNzAxIEUgTWlkZGxlZmllbGQgUm9hZA0KICAgTW91bnRhaW4gVmll dywgQ2FsaWZvcm5pYSAgOTQwNDMNCiAgIFVTQQ0KDQogICBFbWFpbDogcHJhbmphbC5kdXR0YUBh bGNhdGVsLWx1Y2VudC5jb20NCg0KDQogICBGbG9yaW4gQmFsdXMNCiAgIEFsY2F0ZWwtTHVjZW50 DQogICA3MDEgRSBNaWRkbGVmaWVsZCBSb2FkDQogICBNb3VudGFpbiBWaWV3LCBDYWxpZm9ybmlh ICA5NDA0Mw0KICAgVVNBDQoNCiAgIEVtYWlsOiBmbG9yaW4uYmFsdXNAYWxjYXRlbC1sdWNlbnQu Y29tDQoNCiANCg0KDQpEdXR0YSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgU2VwdGVtYmVyIDI2 LCAyMDE0ICAgICAgICAgICAgICBbUGFnZSAyM10NCgwNCkludGVybmV0LURyYWZ0ICAgICBPcHRp bWl6ZWQgTUFDIFdpdGhkcmF3YWwgaW4gSC1WUExTICAgICBNYXJjaCAyNSwgMjAxNA0KDQoNCiAg IE9sZW4gU3Rva2VzDQogICBFeHRyZW1lIE5ldHdvcmtzDQogICBQTyBCb3ggMTQxMjksIFJUUA0K ICAgUmFsZWlnaCwgTm9ydGggQ2Fyb2xpbmEgIDI3NzA5DQogICBVU0ENCg0KICAgRW1haWw6IG9z dG9rZXNAZXh0cmVtZW5ldHdvcmtzLmNvbQ0KDQoNCiAgIEdlcmFsZGluZSBDYWx2aW5hYw0KICAg RnJhbmNlIFRlbGVjb20NCiAgIDIsIGF2ZW51ZSBQaWVycmUtTWFyemluDQogICBMYW5uaW9uIENl ZGV4LCAgIDIyMzA3DQogICBGcmFuY2UNCg0KICAgRW1haWw6IGdlcmFsZGluZS5jYWx2aWduYWNA b3JhbmdlLWZ0Z3JvdXAuY29tDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KRHV0dGEsIGV0IGFsLiAgICAgICAgICBF eHBpcmVzIFNlcHRlbWJlciAyNiwgMjAxNCAgICAgICAgICAgICAgW1BhZ2UgMjRdDQo= --_003_A46D9C092EA46F489F135060986AD9FFD0A81AG6W2492americashp_ Content-Type: text/html; name="Diff draft-ietf-l2vpn-vpls-ldp-mac-opt-11_txt - draft-ietf-l2vpn-vpls-ldp-mac-opt-12_txt.htm" Content-Description: Diff draft-ietf-l2vpn-vpls-ldp-mac-opt-11_txt - draft-ietf-l2vpn-vpls-ldp-mac-opt-12_txt.htm Content-Disposition: attachment; filename="Diff draft-ietf-l2vpn-vpls-ldp-mac-opt-11_txt - draft-ietf-l2vpn-vpls-ldp-mac-opt-12_txt.htm"; size=61195; creation-date="Mon, 07 Apr 2014 13:01:35 GMT"; modification-date="Mon, 07 Apr 2014 13:01:35 GMT" Content-Transfer-Encoding: base64 CjwhRE9DVFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgWEhUTUwgMS4wIFRyYW5zaXRpb25h bC8vRU4iICJodHRwOi8vd3d3LnczLm9yZy9UUi94aHRtbDEvRFREL3hodG1sMS10cmFuc2l0aW9u YWwuZHRkIj4gCjwhLS0gR2VuZXJhdGVkIGJ5IHJmY2RpZmYgMS40MTogcmZjZGlmZiAgLS0+IAo8 IS0tIDwhRE9DVFlQRSBodG1sIFBVQkxJQyAiLS8vVzNDLy9EVEQgSFRNTCA0LjAxIFRyYW5zaXRp b25hbCIgPiAtLT4KPCEtLSBTeXN0ZW06IExpbnV4IGlldGZhLmFtc2wuY29tIDMuNy4xMC0xLjI4 LXhlbiAjMSBTTVAgTW9uIEZlYiAzIDE0OjExOjE1IFVUQyAyMDE0IChjOWEyYzZjKSB4ODZfNjQg eDg2XzY0IHg4Nl82NCBHTlUvTGludXggLS0+IAo8IS0tIFVzaW5nIGF3azogL3Vzci9iaW4vZ2F3 azogR05VIEF3ayA0LjAuMSAtLT4gCjwhLS0gVXNpbmcgZGlmZjogL3Vzci9iaW4vZGlmZjogZGlm ZiAoR05VIGRpZmZ1dGlscykgMy4yIC0tPiAKPCEtLSBVc2luZyB3ZGlmZjogL3Vzci9iaW4vd2Rp ZmY6IHdkaWZmIChHTlUgd2RpZmYpIDEuMS4yIC0tPiAKPGh0bWw+IAo8aGVhZD4gCiAgPG1ldGEg aHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9aXNv LTg4NTktMSIgLz4gCiAgPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1TdHlsZS1UeXBlIiBjb250 ZW50PSJ0ZXh0L2NzcyIgLz4gCiAgPHRpdGxlPkRpZmY6IGRyYWZ0LWlldGYtbDJ2cG4tdnBscy1s ZHAtbWFjLW9wdC0xMS50eHQgLSBkcmFmdC1pZXRmLWwydnBuLXZwbHMtbGRwLW1hYy1vcHQtMTIu dHh0PC90aXRsZT4gCiAgPHN0eWxlIHR5cGU9InRleHQvY3NzIj4gCiAgICBib2R5ICAgIHsgbWFy Z2luOiAwLjRleDsgbWFyZ2luLXJpZ2h0OiBhdXRvOyB9IAogICAgdHIgICAgICB7IH0gCiAgICB0 ZCAgICAgIHsgd2hpdGUtc3BhY2U6IHByZTsgZm9udC1mYW1pbHk6IG1vbm9zcGFjZTsgdmVydGlj YWwtYWxpZ246IHRvcDsgZm9udC1zaXplOiAwLjg2ZW07fSAKICAgIHRoICAgICAgeyBmb250LXNp emU6IDAuODZlbTsgfSAKICAgIC5zbWFsbCAgeyBmb250LXNpemU6IDAuNmVtOyBmb250LXN0eWxl OiBpdGFsaWM7IGZvbnQtZmFtaWx5OiBWZXJkYW5hLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IH0g CiAgICAubGVmdCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgfSAKICAgIC5yaWdodCAgeyBi YWNrZ3JvdW5kLWNvbG9yOiAjRkZGOyB9IAogICAgLmRpZmYgICB7IGJhY2tncm91bmQtY29sb3I6 ICNDQ0Y7IH0gCiAgICAubGJsb2NrIHsgYmFja2dyb3VuZC1jb2xvcjogI0JGQjsgfSAKICAgIC5y YmxvY2sgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkY4OyB9IAogICAgLmluc2VydCB7IGJhY2tncm91 bmQtY29sb3I6ICM4RkY7IH0gCiAgICAuZGVsZXRlIHsgYmFja2dyb3VuZC1jb2xvcjogI0FDRjsg fSAKICAgIC52b2lkICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRkZCOyB9IAogICAgLmNvbnQgICB7 IGJhY2tncm91bmQtY29sb3I6ICNFRUU7IH0gCiAgICAubGluZWJyIHsgYmFja2dyb3VuZC1jb2xv cjogI0FBQTsgfSAKICAgIC5saW5lbm8geyBjb2xvcjogcmVkOyBiYWNrZ3JvdW5kLWNvbG9yOiAj RkZGOyBmb250LXNpemU6IDAuN2VtOyB0ZXh0LWFsaWduOiByaWdodDsgcGFkZGluZzogMCAycHg7 IH0gCiAgICAuZWxpcHNpc3sgYmFja2dyb3VuZC1jb2xvcjogI0FBQTsgfSAKICAgIC5sZWZ0IC5j b250IHsgYmFja2dyb3VuZC1jb2xvcjogI0RERDsgfSAKICAgIC5yaWdodCAuY29udCB7IGJhY2tn cm91bmQtY29sb3I6ICNFRUU7IH0gCiAgICAubGJsb2NrIC5jb250IHsgYmFja2dyb3VuZC1jb2xv cjogIzlEOTsgfSAKICAgIC5yYmxvY2sgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjREQ2OyB9 IAogICAgLmluc2VydCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICMwREQ7IH0gCiAgICAuZGVs ZXRlIC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogIzhBRDsgfSAKICAgIC5zdGF0cywgLnN0YXRz IHRkLCAuc3RhdHMgdGggeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyBwYWRkaW5nOiAycHggMDsg fSAKICA8L3N0eWxlPiAKPC9oZWFkPiAKPGJvZHkgPiAKICA8dGFibGUgYm9yZGVyPSIwIiBjZWxs cGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPiAKICA8dHIgYmdjb2xvcj0ib3JhbmdlIj48dGg+ PC90aD48dGg+PGEgaHJlZj0iL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWwydnBuLXZwbHMtbGRw LW1hYy1vcHQtMTEudHh0IiBzdHlsZT0iY29sb3I6IzAwODsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7 Ij4mbHQ7PC9hPiZuYnNwOzxhIGhyZWY9Ii9odG1sL2RyYWZ0LWlldGYtbDJ2cG4tdnBscy1sZHAt bWFjLW9wdC0xMS50eHQiIHN0eWxlPSJjb2xvcjojMDA4Ij5kcmFmdC1pZXRmLWwydnBuLXZwbHMt bGRwLW1hYy1vcHQtMTEudHh0PC9hPiZuYnNwOzwvdGg+PHRoPiA8L3RoPjx0aD4mbmJzcDs8YSBo cmVmPSIvaHRtbC9kcmFmdC1pZXRmLWwydnBuLXZwbHMtbGRwLW1hYy1vcHQtMTIudHh0IiBzdHls ZT0iY29sb3I6IzAwOCI+ZHJhZnQtaWV0Zi1sMnZwbi12cGxzLWxkcC1tYWMtb3B0LTEyLnR4dDwv YT4mbmJzcDs8YSBocmVmPSIvcmZjZGlmZj91cmwxPWRyYWZ0LWlldGYtbDJ2cG4tdnBscy1sZHAt bWFjLW9wdC0xMi50eHQiIHN0eWxlPSJjb2xvcjojMDA4OyB0ZXh0LWRlY29yYXRpb246bm9uZTsi PiZndDs8L2E+PC90aD48dGg+PC90aD48L3RyPiAKICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgYmdjb2xvcj0iZ3Jh eSIgPjx0ZD48L3RkPjx0aD48YSBuYW1lPSJwYXJ0LWwxIiAvPjxzbWFsbD5za2lwcGluZyB0byBj aGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAxLCBsaW5lIDEzPC9lbT48L3RoPjx0aD4gPC90aD48 dGg+PGEgbmFtZT0icGFydC1yMSIgLz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFs bD48ZW0+IHBhZ2UgMSwgbGluZSAxMzwvZW0+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+TmV0 d29yayBXb3JraW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFAuIER1dHRhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+TmV0d29yayBXb3Jr aW5nIEdyb3VwICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFAuIER1 dHRhPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBGLiBCYWx1czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkludGVybmV0 LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBG LiBCYWx1czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij5JbnRlbmRlZCBzdGF0dXM6IFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAg ICAgICAgQWxjYXRlbC1MdWNlbnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5JbnRl bmRlZCBzdGF0dXM6IFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgICAgQWxj YXRlbC1MdWNlbnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+RXhwaXJlczogU2VwdGVtYmVyIDI2LCAyMDE0ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgTy4gU3Rva2VzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ RXhwaXJlczogU2VwdGVtYmVyIDI2LCAyMDE0ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgTy4gU3Rva2VzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgRXh0cmVtZSBOZXR3b3JrczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgRXh0cmVtZSBOZXR3b3JrczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgRy4gQ2FsdmluYWM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgRy4gQ2FsdmluYWM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIEZyYW5jZSBUZWxlY29tPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEZyYW5jZSBUZWxlY29tPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBNYXJjaCAyNSwgMjAxNDwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBNYXJjaCAyNSwgMjAxNDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICBMRFAgRXh0ZW5zaW9ucyBmb3IgT3B0aW1pemVkIE1BQyBBZGRyZXNzIFdpdGhkcmF3 YWwgaW4gSC1WUExTPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICBMRFAgRXh0 ZW5zaW9ucyBmb3IgT3B0aW1pemVkIE1BQyBBZGRyZXNzIFdpdGhkcmF3YWwgaW4gSC1WUExTPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZD48YSBuYW1lPSJkaWZmMDAwMSIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAgICAg ICAgIGRyYWZ0LWlldGYtbDJ2cG4tdnBscy1sZHAtbWFjLW9wdC0xPHNwYW4gY2xhc3M9ImRlbGV0 ZSI+MTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAg ICAgICAgZHJhZnQtaWV0Zi1sMnZwbi12cGxzLWxkcC1tYWMtb3B0LTE8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4yPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+QWJzdHJhY3Q8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5BYnN0cmFjdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgUkZDNDc2MiBkZXNjcmliZXMgYSBtZWNoYW5pc20gdG8gcmVtb3ZlIG9yIHVubGVh cm4gTUFDIGFkZHJlc3NlcyB0aGF0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg UkZDNDc2MiBkZXNjcmliZXMgYSBtZWNoYW5pc20gdG8gcmVtb3ZlIG9yIHVubGVhcm4gTUFDIGFk ZHJlc3NlcyB0aGF0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIGhhdmUgYmVlbiBkeW5hbWljYWxseSBsZWFybmVkIGluIGEgVmlydHVhbCBQ cml2YXRlIExBTiBTZXJ2aWNlIChWUExTKTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIGhhdmUgYmVlbiBkeW5hbWljYWxseSBsZWFybmVkIGluIGEgVmlydHVhbCBQcml2YXRlIExB TiBTZXJ2aWNlIChWUExTKTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBJbnN0YW5jZSBmb3IgZmFzdGVyIGNvbnZlcmdlbmNlIG9uIHRvcG9s b2d5IGNoYW5nZS4gIFRoZSBwcm9jZWR1cmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBJbnN0YW5jZSBmb3IgZmFzdGVyIGNvbnZlcmdlbmNlIG9uIHRvcG9sb2d5IGNoYW5nZS4g IFRoZSBwcm9jZWR1cmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgYWxzbyByZW1vdmVzIE1BQyBhZGRyZXNzZXMgaW4gdGhlIFZQTFMgdGhh dCBkbyBub3QgcmVxdWlyZSByZWxlYXJuaW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgYWxzbyByZW1vdmVzIE1BQyBhZGRyZXNzZXMgaW4gdGhlIFZQTFMgdGhhdCBkbyBub3Qg cmVxdWlyZSByZWxlYXJuaW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIGR1ZSB0byBzdWNoIHRvcG9sb2d5IGNoYW5nZS4gIFRoaXMgZG9j dW1lbnQgZGVmaW5lcyBhbiBlbmhhbmNlbWVudCB0bzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIGR1ZSB0byBzdWNoIHRvcG9sb2d5IGNoYW5nZS4gIFRoaXMgZG9jdW1lbnQgZGVm aW5lcyBhbiBlbmhhbmNlbWVudCB0bzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGUgTUFDIEFkZHJlc3MgV2l0aGRyYXdhbCBwcm9jZWR1 cmUgd2l0aCBlbXB0eSBNQUMgTGlzdCBmcm9tPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgdGhlIE1BQyBBZGRyZXNzIFdpdGhkcmF3YWwgcHJvY2VkdXJlIHdpdGggZW1wdHkgTUFD IExpc3QgZnJvbTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBSRkM0NzYyLCB3aGljaCBlbmFibGVzIGEgUHJvdmlkZXIgRWRnZShQRSkgZGV2 aWNlIHRvIHJlbW92ZSBvbmx5IHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IFJGQzQ3NjIsIHdoaWNoIGVuYWJsZXMgYSBQcm92aWRlciBFZGdlKFBFKSBkZXZpY2UgdG8gcmVt b3ZlIG9ubHkgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHIgYmdjb2xvcj0iZ3JheSIgPjx0ZD48L3RkPjx0aD48YSBuYW1lPSJw YXJ0LWwyIiAvPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSA5 LCBsaW5lIDE1PC9lbT48L3RoPjx0aD4gPC90aD48dGg+PGEgbmFtZT0icGFydC1yMiIgLz48c21h bGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgOSwgbGluZSAxNTwvZW0+ PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY2FwYWJpbGl0aWVzIHRvIFBCQi1WUExTIHNv bHV0aW9uLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNhcGFiaWxpdGllcyB0 byBQQkItVlBMUyBzb2x1dGlvbi48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoZSBz b2x1dGlvbiBwcm9wb3NlZCBpbiB0aGlzIGRvY3VtZW50IGlzIGdlbmVyaWMgYW5kIGlzIGFwcGxp Y2FibGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgc29sdXRpb24gcHJv cG9zZWQgaW4gdGhpcyBkb2N1bWVudCBpcyBnZW5lcmljIGFuZCBpcyBhcHBsaWNhYmxlPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHdoZW4g TVMtUFdzIGFyZSB1c2VkIGluIGludGVyY29ubmVjdGluZyBQRSBkZXZpY2VzIGluIEgtVlBMUy4g IFRoZXJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgd2hlbiBNUy1QV3MgYXJl IHVzZWQgaW4gaW50ZXJjb25uZWN0aW5nIFBFIGRldmljZXMgaW4gSC1WUExTLiAgVGhlcmU8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY291 bGQgYmUgb3RoZXIgSC1WUExTIG1vZGVscyBub3QgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IHdo ZXJlIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNvdWxkIGJlIG90aGVy IEgtVlBMUyBtb2RlbHMgbm90IGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCB3aGVyZSB0aGU8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgc29s dXRpb24gbWF5IGJlIGFwcGxpY2FibGUuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgc29sdXRpb24gbWF5IGJlIGFwcGxpY2FibGUuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij40LiAgUHJvYmxlbSBEZXNjcmlwdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjQuICBQcm9ibGVtIERlc2NyaXB0aW9uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBU aGlzIHNlY3Rpb24gZGVzY3JpYmVzIHRoZSBwcm9ibGVtcyBpbiBkZXRhaWwgd2l0aCByZXNwZWN0 aXZlIHRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhpcyBzZWN0aW9uIGRl c2NyaWJlcyB0aGUgcHJvYmxlbXMgaW4gZGV0YWlsIHdpdGggcmVzcGVjdGl2ZSB0bzwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEg bmFtZT0iZGlmZjAwMDIiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICB2YXJpb3VzIE1BQyBmbHVz aCBhY3Rpb25zIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDxzcGFuIGNsYXNzPSJkZWxldGUiPjI8L3Nw YW4+LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICB2YXJpb3VzIE1BQyBmbHVz aCBhY3Rpb25zIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjM8L3Nw YW4+LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+NC4xLiAgTUFDIEZsdXNoIE9wdGltaXph dGlvbiBpbiBWUExTIFJlc2lsaWVuY3k8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij40 LjEuICBNQUMgRmx1c2ggT3B0aW1pemF0aW9uIGluIFZQTFMgUmVzaWxpZW5jeTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBzZWN0aW9uIGRlc2NyaWJlcyB0aGUgb3B0aW1pemF0 aW9ucyByZXF1aXJlZCBpbiBNQUMgZmx1c2g8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBUaGlzIHNlY3Rpb24gZGVzY3JpYmVzIHRoZSBvcHRpbWl6YXRpb25zIHJlcXVpcmVkIGlu IE1BQyBmbHVzaDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBwcm9jZWR1cmVzIHdoZW4gSC1WUExTIHJlc2lsaWVuY3kgaXMgcHJvdmlkZWQg YnkgcHJpbWFyeSBhbmQgYmFja3VwPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg cHJvY2VkdXJlcyB3aGVuIEgtVlBMUyByZXNpbGllbmN5IGlzIHByb3ZpZGVkIGJ5IHByaW1hcnkg YW5kIGJhY2t1cDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBzcG9rZSBQV3MuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg c3Bva2UgUFdzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+NC4xLjEuICBNQUMgRmx1c2gg T3B0aW1pemF0aW9uIGZvciByZWd1bGFyIEgtVlBMUzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjQuMS4xLiAgTUFDIEZsdXNoIE9wdGltaXphdGlvbiBmb3IgcmVndWxhciBILVZQTFM8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEZpZ3VyZSAyLiBkZXNjcmliZXMgYSBkdWFs LWhvbWVkIEgtVlBMUyBzY2VuYXJpbyBmb3IgYSBWUExTIGluc3RhbmNlPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgRmlndXJlIDIuIGRlc2NyaWJlcyBhIGR1YWwtaG9tZWQgSC1W UExTIHNjZW5hcmlvIGZvciBhIFZQTFMgaW5zdGFuY2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBiZ2NvbG9yPSJncmF5IiA+PHRk PjwvdGQ+PHRoPjxhIG5hbWU9InBhcnQtbDMiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBh dDwvc21hbGw+PGVtPiBwYWdlIDExLCBsaW5lIDM0PC9lbT48L3RoPjx0aD4gPC90aD48dGg+PGEg bmFtZT0icGFydC1yMyIgLz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+ IHBhZ2UgMTEsIGxpbmUgMzQ8L2VtPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGZsb29k aW5nIG9mIHVua25vd24gZGVzdGluYXRpb24gTUFDIGFkZHJlc3NlcyB0YWtlcyBwbGFjZSB0aHJv dWdob3V0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZmxvb2Rpbmcgb2YgdW5r bm93biBkZXN0aW5hdGlvbiBNQUMgYWRkcmVzc2VzIHRha2VzIHBsYWNlIHRocm91Z2hvdXQ8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhl IG5ldHdvcmsuICBBcyB0aGUgbnVtYmVyIG9mIFBFLXJzIGRldmljZXMgaW4gdGhlIGZ1bGwtbWVz aDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoZSBuZXR3b3JrLiAgQXMgdGhl IG51bWJlciBvZiBQRS1ycyBkZXZpY2VzIGluIHRoZSBmdWxsLW1lc2g8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaW5jcmVhc2VzLCB0aGUg bnVtYmVyIG9mIHVuYWZmZWN0ZWQgTUFDIGFkZHJlc3NlcyBmbHVzaGVkIGluIGEgVlBMUzwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGluY3JlYXNlcywgdGhlIG51bWJlciBvZiB1 bmFmZmVjdGVkIE1BQyBhZGRyZXNzZXMgZmx1c2hlZCBpbiBhIFZQTFM8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaW5zdGFuY2UgYWxzbyBp bmNyZWFzZXMsIHRodXMgbGVhZGluZyB0byB1bm5lY2Vzc2FyeSBmbG9vZGluZyBhbmQ8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpbnN0YW5jZSBhbHNvIGluY3JlYXNlcywgdGh1 cyBsZWFkaW5nIHRvIHVubmVjZXNzYXJ5IGZsb29kaW5nIGFuZDwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICByZWxlYXJuaW5nLiAgV2l0aCBs YXJnZSBudW1iZXIgb2YgVlBMUyBpbnN0YW5jZXMgcHJvdmlzaW9uZWQgaW4gdGhlPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcmVsZWFybmluZy4gIFdpdGggbGFyZ2UgbnVtYmVy IG9mIFZQTFMgaW5zdGFuY2VzIHByb3Zpc2lvbmVkIGluIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBILVZQTFMgbmV0d29yayB0b3Bv bG9neSB0aGUgYW1vdW50IG9mIHVubmVjZXNzYXJ5IGZsb29kaW5nIGFuZDwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIEgtVlBMUyBuZXR3b3JrIHRvcG9sb2d5IHRoZSBhbW91bnQg b2YgdW5uZWNlc3NhcnkgZmxvb2RpbmcgYW5kPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHJlbGVhcm5pbmcgaW5jcmVhc2VzLiAgQW4gb3B0 aW1pemF0aW9uLCBkZXNjcmliZWQgYmVsb3csIGlzIHJlcXVpcmVkPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgcmVsZWFybmluZyBpbmNyZWFzZXMuICBBbiBvcHRpbWl6YXRpb24s IGRlc2NyaWJlZCBiZWxvdywgaXMgcmVxdWlyZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhhdCB3aWxsIGZsdXNoIG9ubHkgdGhlIE1B QyBhZGRyZXNzZXMgbGVhcm5lZCBmcm9tIHRoZSByZXNwZWN0aXZlPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgdGhhdCB3aWxsIGZsdXNoIG9ubHkgdGhlIE1BQyBhZGRyZXNzZXMg bGVhcm5lZCBmcm9tIHRoZSByZXNwZWN0aXZlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFBXcyBiZXR3ZWVuIFBFMS1ycyBhbmQgb3RoZXIg UEUgZGV2aWNlcyBpbiB0aGUgZnVsbC1tZXNoIG1pbmltaXppbmc8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBQV3MgYmV0d2VlbiBQRTEtcnMgYW5kIG90aGVyIFBFIGRldmljZXMg aW4gdGhlIGZ1bGwtbWVzaCBtaW5pbWl6aW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRoZSByZWxlYXJuaW5nIGFuZCBmbG9vZGluZyBp biB0aGUgbmV0d29yay4gIEluIHRoZSBleGFtcGxlIGFib3ZlLDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIHRoZSByZWxlYXJuaW5nIGFuZCBmbG9vZGluZyBpbiB0aGUgbmV0d29y ay4gIEluIHRoZSBleGFtcGxlIGFib3ZlLDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDMiIC8+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICBvbmx5IHRoZSBNQUMgYWRkcmVzc2VzIGluIHNldCBYIGFuZCBZIG5l ZWQgdG8gYmUgZmx1c2hlZCBhY3Jvc3MgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgIG9ubHkgdGhlIE1BQyBhZGRyZXNzZXMgaW4gc2V0IFggYW5kIFkgPHNwYW4gY2xhc3M9 Imluc2VydCI+KHNob3duIGluIEZpZ3VyZSAyKTwvc3Bhbj4gbmVlZCB0byBiZTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGNvcmUuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGZsdXNoZWQgYWNyb3NzIHRoZSBjb3Jl LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIHNhbWUgY2FzZSBpcyBhcHBsaWNh YmxlIHdoZW4gUEUxLXJzIGFuZCBQRTItcnMgYXJlIGR1YWwgaG9taW5nPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIHNhbWUgY2FzZSBpcyBhcHBsaWNhYmxlIHdoZW4gUEUx LXJzIGFuZCBQRTItcnMgYXJlIGR1YWwgaG9taW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGF3YXJlIGFuZCBwYXJ0aWNpcGF0ZSBpbiBh IGRlc2lnbmF0ZWQgZm9yd2FyZGVyIGVsZWN0aW9uLiAgV2hlbjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIGF3YXJlIGFuZCBwYXJ0aWNpcGF0ZSBpbiBhIGRlc2lnbmF0ZWQgZm9y d2FyZGVyIGVsZWN0aW9uLiAgV2hlbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBQRTItcnMgYmVjb21lcyB0aGUgYWN0aXZlIGRldmljZSBm b3IgTVRVLXMgdGhlbiBQRTItcnMgTUFZIGluaXRpYXRlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgUEUyLXJzIGJlY29tZXMgdGhlIGFjdGl2ZSBkZXZpY2UgZm9yIE1UVS1zIHRo ZW4gUEUyLXJzIE1BWSBpbml0aWF0ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBNQUMgZmx1c2ggdG93YXJkcyB0aGUgY29yZS4gIFRoZSBy ZWNlaXZpbmcgYWN0aW9uIG9mIHRoZSBNQUMgRmx1c2ggaW48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBNQUMgZmx1c2ggdG93YXJkcyB0aGUgY29yZS4gIFRoZSByZWNlaXZpbmcg YWN0aW9uIG9mIHRoZSBNQUMgRmx1c2ggaW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgb3RoZXIgUEUtcnMgZGV2aWNlcyBpcyB0aGUgc2Ft ZSBhcyBpbiBNVFUtcyBpbml0aWF0ZWQgTUFDIEZsdXNoLiBUaGlzPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgb3RoZXIgUEUtcnMgZGV2aWNlcyBpcyB0aGUgc2FtZSBhcyBpbiBN VFUtcyBpbml0aWF0ZWQgTUFDIEZsdXNoLiBUaGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGlzIHRoZSBbUkZDNDc2Ml0gc3BlY2lmaWVk IGJlaGF2aW9yLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGlzIHRoZSBbUkZD NDc2Ml0gc3BlY2lmaWVkIGJlaGF2aW9yLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+NC4x LjIuICBNQUMgRmx1c2ggT3B0aW1pemF0aW9uIGZvciBuYXRpdmUgRXRoZXJuZXQgYWNjZXNzPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+NC4xLjIuICBNQUMgRmx1c2ggT3B0aW1pemF0 aW9uIGZvciBuYXRpdmUgRXRoZXJuZXQgYWNjZXNzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDQiIC8+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBUaGUg YW5hbHlzaXMgaW4gc2VjdGlvbiA8c3BhbiBjbGFzcz0iZGVsZXRlIj4zPC9zcGFuPi4xLjEgYXBw bGllcyBhbHNvIHRvIHRoZSBuYXRpdmUgRXRoZXJuZXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgVGhlIGFuYWx5c2lzIGluIHNlY3Rpb24gPHNwYW4gY2xhc3M9Imluc2VydCI+ NDwvc3Bhbj4uMS4xIGFwcGxpZXMgYWxzbyB0byB0aGUgbmF0aXZlIEV0aGVybmV0PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFjY2VzcyBp bnRvIGEgVlBMUy4gIEluIHN1Y2ggYSBzY2VuYXJpbyBvbmUgYWN0aXZlIGFuZCBvbmUgb3IgbW9y ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFjY2VzcyBpbnRvIGEgVlBMUy4g IEluIHN1Y2ggYSBzY2VuYXJpbyBvbmUgYWN0aXZlIGFuZCBvbmUgb3IgbW9yZTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBzdGFuZGJ5IGVu ZHBvaW50cyB0ZXJtaW5hdGUgaW50byB0d28gb3IgbW9yZSBWUExTIG9yIEgtVlBMUyBQRS1yczwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHN0YW5kYnkgZW5kcG9pbnRzIHRlcm1p bmF0ZSBpbnRvIHR3byBvciBtb3JlIFZQTFMgb3IgSC1WUExTIFBFLXJzPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRldmljZXMuICBFeGFt cGxlcyBvZiB0aGVzZSBkdWFsIGhvbWVkIGFjY2VzcyBhcmUgSVRVLVQgW0lUVS5HODAzMl08L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkZXZpY2VzLiAgRXhhbXBsZXMgb2YgdGhl c2UgZHVhbCBob21lZCBhY2Nlc3MgYXJlIElUVS1UIFtJVFUuRzgwMzJdPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFjY2VzcyByaW5ncyBv ciBhbnkgcHJvcHJpZXRhcnkgbXVsdGktY2hhc3NpcyBMQUcgZW11bGF0aW9ucy4gIFVwb248L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhY2Nlc3MgcmluZ3Mgb3IgYW55IHByb3By aWV0YXJ5IG11bHRpLWNoYXNzaXMgTEFHIGVtdWxhdGlvbnMuICBVcG9uPC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGZhaWx1cmUgb2YgdGhl IGFjdGl2ZSBuYXRpdmUgRXRoZXJuZXQgZW5kcG9pbnQgb24gUEUxLXJzLCBhbjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGZhaWx1cmUgb2YgdGhlIGFjdGl2ZSBuYXRpdmUgRXRo ZXJuZXQgZW5kcG9pbnQgb24gUEUxLXJzLCBhbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvcHRpbWl6ZWQgTUFDIGZsdXNoIGlzIHJlcXVp cmVkIHRvIGJlIGluaXRpYXRlZCBieSBQRTEtcnMgdG8gZW5zdXJlPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgb3B0aW1pemVkIE1BQyBmbHVzaCBpcyByZXF1aXJlZCB0byBiZSBp bml0aWF0ZWQgYnkgUEUxLXJzIHRvIGVuc3VyZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGF0IG9uIFBFMi1ycywgUEUzLXJzIGFuZCBQ RTQtcnMgb25seSB0aGUgTUFDIGFkZHJlc3NlcyBsZWFybmVkIGZyb208L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICB0aGF0IG9uIFBFMi1ycywgUEUzLXJzIGFuZCBQRTQtcnMgb25s eSB0aGUgTUFDIGFkZHJlc3NlcyBsZWFybmVkIGZyb208L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhlIHJlc3BlY3RpdmUgUFdzIGNvbm5l Y3RlZCB0byBQRTEtcnMgYXJlIGJlaW5nIGZsdXNoZWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgdGhlIHJlc3BlY3RpdmUgUFdzIGNvbm5lY3RlZCB0byBQRTEtcnMgYXJlIGJl aW5nIGZsdXNoZWQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij40LjIuICBCbGFjayBob2xp bmcgaXNzdWUgaW4gUEJCLVZQTFM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij40LjIu ICBCbGFjayBob2xpbmcgaXNzdWUgaW4gUEJCLVZQTFM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBiZ2NvbG9yPSJncmF5IiA+PHRk PjwvdGQ+PHRoPjxhIG5hbWU9InBhcnQtbDQiIC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBh dDwvc21hbGw+PGVtPiBwYWdlIDEzLCBsaW5lIDI1PC9lbT48L3RoPjx0aD4gPC90aD48dGg+PGEg bmFtZT0icGFydC1yNCIgLz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+ IHBhZ2UgMTMsIGxpbmUgMjU8L2VtPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEEgYmV0 dGVyIHNvbHV0aW9uIHdoaWNoIHByb3BhZ2F0ZXMgdGhlIEktY29tcG9uZW50IGV2ZW50cyB0aHJv dWdoIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEEgYmV0dGVyIHNvbHV0 aW9uIHdoaWNoIHByb3BhZ2F0ZXMgdGhlIEktY29tcG9uZW50IGV2ZW50cyB0aHJvdWdoIHRoZTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBi YWNrYm9uZSBpbmZyYXN0cnVjdHVyZSAoQi1WUExTKSBpcyByZXF1aXJlZCBpbiBvcmRlciB0byBm bHVzaCBvbmx5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYmFja2JvbmUgaW5m cmFzdHJ1Y3R1cmUgKEItVlBMUykgaXMgcmVxdWlyZWQgaW4gb3JkZXIgdG8gZmx1c2ggb25seTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0 aGUgQ01BQyB0byBCTUFDIGFzc29jaWF0aW9ucyBpbiB0aGUgcmVtb3RlIFBCQi1WUExTIGNhcGFi bGUgUEUtcnM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0aGUgQ01BQyB0byBC TUFDIGFzc29jaWF0aW9ucyBpbiB0aGUgcmVtb3RlIFBCQi1WUExTIGNhcGFibGUgUEUtcnM8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgZGV2 aWNlcy4gIFNpbmNlIHRoZXJlIGFyZSBubyBJLWNvbXBvbmVudCBjb250cm9sIHBsYW5lIGV4Y2hh bmdlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGRldmljZXMuICBTaW5jZSB0 aGVyZSBhcmUgbm8gSS1jb21wb25lbnQgY29udHJvbCBwbGFuZSBleGNoYW5nZXM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYWNyb3NzIHRo ZSBQQkIgYmFja2JvbmUsIGV4dGVuc2lvbnMgdG8gQi1WUExTIGNvbnRyb2wgcGxhbmUgYXJlPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYWNyb3NzIHRoZSBQQkIgYmFja2JvbmUs IGV4dGVuc2lvbnMgdG8gQi1WUExTIGNvbnRyb2wgcGxhbmUgYXJlPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHJlcXVpcmVkIHRvIHByb3Bh Z2F0ZSB0aGUgSS1jb21wb25lbnQgTUFDIEZsdXNoIGV2ZW50cyBhY3Jvc3MgdGhlPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcmVxdWlyZWQgdG8gcHJvcGFnYXRlIHRoZSBJLWNv bXBvbmVudCBNQUMgRmx1c2ggZXZlbnRzIGFjcm9zcyB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQi1WUExTLjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIEItVlBMUy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjUuICBTb2x1dGlvbiBEZXNjcmlwdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjUuICBTb2x1dGlvbiBEZXNjcmlwdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkPjxhIG5hbWU9ImRpZmYwMDA1IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgVGhpcyBzZWN0 aW9uIGRlc2NyaWJlcyB0aGUgc29sdXRpb24gZm9yIHRoZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5y ZXF1aXJlbWVudHM8L3NwYW4+IGRlc2NyaWJlZCBpbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICBUaGlzIHNlY3Rpb24gZGVzY3JpYmVzIHRoZSBzb2x1dGlvbiBmb3IgdGhlIDxz cGFuIGNsYXNzPSJpbnNlcnQiPnByb2JsZW0gc3BhY2U8L3NwYW4+IGRlc2NyaWJlZDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHNlY3Rp b24gNC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgaW4gc2VjdGlvbiA0Ljwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+NS4xLiAgTUFDIEZsdXNoIE9wdGltaXphdGlvbiBm b3IgVlBMUyBSZXNpbGllbmN5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+NS4xLiAg TUFDIEZsdXNoIE9wdGltaXphdGlvbiBmb3IgVlBMUyBSZXNpbGllbmN5PC90ZD48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBUaGUgYmFzaWMgcHJpbmNpcGxlIG9mIHRoZSBvcHRpbWl6ZWQgTUFD IGZsdXNoIG1lY2hhbmlzbSBpcyBleHBsYWluZWQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBUaGUgYmFzaWMgcHJpbmNpcGxlIG9mIHRoZSBvcHRpbWl6ZWQgTUFDIGZsdXNoIG1l Y2hhbmlzbSBpcyBleHBsYWluZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgd2l0aCByZWZlcmVuY2UgdG8gRmlndXJlIDIuICBUaGUgb3B0 aW1pemF0aW9uIGlzIGFjaGlldmVkIGJ5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgd2l0aCByZWZlcmVuY2UgdG8gRmlndXJlIDIuICBUaGUgb3B0aW1pemF0aW9uIGlzIGFjaGll dmVkIGJ5PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwNiIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIGlu aXRpYXRpbmcgTUFDIEZsdXNoIG9uIGZhaWx1cmUgYXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gPHNw YW4gY2xhc3M9ImRlbGV0ZSI+Mjwvc3Bhbj4uMi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgaW5pdGlhdGluZyBNQUMgRmx1c2ggb24gZmFpbHVyZSBhcyBkZXNjcmliZWQgaW4g c2VjdGlvbiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4zPC9zcGFuPi4yLjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgUEUxLXJzIHdvdWxkIGluaXRpYXRlIE1BQyBGbHVzaCB0b3dhcmRzIHRo ZSBjb3JlIG9uIGRldGVjdGlvbiBvZjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IFBFMS1ycyB3b3VsZCBpbml0aWF0ZSBNQUMgRmx1c2ggdG93YXJkcyB0aGUgY29yZSBvbiBkZXRl Y3Rpb24gb2Y8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgZmFpbHVyZSBvZiBwcmltYXJ5IHNwb2tlIFBXIGJldHdlZW4gTVRVLXMgYW5kIFBF MS1ycyAob3Igc3RhdHVzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZmFpbHVy ZSBvZiBwcmltYXJ5IHNwb2tlIFBXIGJldHdlZW4gTVRVLXMgYW5kIFBFMS1ycyAob3Igc3RhdHVz PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IGNoYW5nZSBmcm9tIGFjdGl2ZSB0byBzdGFuZGJ5IFtSRkM2NzE4XSApLiAgVGhpcyBtZXRob2Qg aXMgcmVmZXJyZWQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBjaGFuZ2UgZnJv bSBhY3RpdmUgdG8gc3RhbmRieSBbUkZDNjcxOF0gKS4gIFRoaXMgbWV0aG9kIGlzIHJlZmVycmVk PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IHRvIGFzICJNQUMgRmx1c2ggb24gRmFpbHVyZSIgdGhyb3VnaG91dCB0aGlzIGRvY3VtZW50LiAg VGhlIE1BQyBGbHVzaDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRvIGFzICJN QUMgRmx1c2ggb24gRmFpbHVyZSIgdGhyb3VnaG91dCB0aGlzIGRvY3VtZW50LiAgVGhlIE1BQyBG bHVzaDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBtZXNzYWdlIHdvdWxkIGluZGljYXRlIHRvIHJlY2VpdmluZyBQRS1ycyBkZXZpY2VzIHRv IGZsdXNoIGFsbCBNQUNzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbWVzc2Fn ZSB3b3VsZCBpbmRpY2F0ZSB0byByZWNlaXZpbmcgUEUtcnMgZGV2aWNlcyB0byBmbHVzaCBhbGwg TUFDczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBsZWFybmVkIG92ZXIgdGhlIFBXIGluIHRoZSBjb250ZXh0IG9mIHRoZSBWUExTIGZvciB3 aGljaCB0aGUgTUFDPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbGVhcm5lZCBv dmVyIHRoZSBQVyBpbiB0aGUgY29udGV4dCBvZiB0aGUgVlBMUyBmb3Igd2hpY2ggdGhlIE1BQzwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBm bHVzaCBtZXNzYWdlIGlzIHJlY2VpdmVkLiAgRWFjaCBQRS1ycyBkZXZpY2UgaW4gdGhlIGZ1bGwg bWVzaCB0aGF0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZmx1c2ggbWVzc2Fn ZSBpcyByZWNlaXZlZC4gIEVhY2ggUEUtcnMgZGV2aWNlIGluIHRoZSBmdWxsIG1lc2ggdGhhdDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBy ZWNlaXZlcyB0aGUgbWVzc2FnZSBpZGVudGlmaWVzIHRoZSBWUExTIGluc3RhbmNlIGFuZCBpdHMg cmVzcGVjdGl2ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHJlY2VpdmVzIHRo ZSBtZXNzYWdlIGlkZW50aWZpZXMgdGhlIFZQTFMgaW5zdGFuY2UgYW5kIGl0cyByZXNwZWN0aXZl PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IFBXIHRoYXQgdGVybWluYXRlcyBpbiBQRTEtcnMgZnJvbSB0aGUgRkVDIFRMViByZWNlaXZlZCBp biB0aGUgbWVzc2FnZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFBXIHRoYXQg dGVybWluYXRlcyBpbiBQRTEtcnMgZnJvbSB0aGUgRkVDIFRMViByZWNlaXZlZCBpbiB0aGUgbWVz c2FnZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBhbmQvb3IgTERQIHNlc3Npb24uICBUaHVzIHRoZSBQRS1ycyBkZXZpY2UgZmx1c2hlcyBv bmx5IHRoZSBNQUM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhbmQvb3IgTERQ IHNlc3Npb24uICBUaHVzIHRoZSBQRS1ycyBkZXZpY2UgZmx1c2hlcyBvbmx5IHRoZSBNQUM8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYWRk cmVzc2VzIGxlYXJuZWQgZnJvbSB0aGF0IFBXIGNvbm5lY3RlZCB0byBQRTEtcnMsIG1pbmltaXpp bmcgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYWRkcmVzc2VzIGxlYXJu ZWQgZnJvbSB0aGF0IFBXIGNvbm5lY3RlZCB0byBQRTEtcnMsIG1pbmltaXppbmcgdGhlPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHJlcXVp cmVkIHJlbGVhcm5pbmcgYW5kIHRoZSBmbG9vZGluZyB0aHJvdWdob3V0IHRoZSBWUExTIGRvbWFp bi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICByZXF1aXJlZCByZWxlYXJuaW5n IGFuZCB0aGUgZmxvb2RpbmcgdGhyb3VnaG91dCB0aGUgVlBMUyBkb21haW4uPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIHNlY3Rpb24gZGVmaW5lcyBhIGdlbmVyaWMgTUFDIEZs dXNoIFBhcmFtZXRlcnMgVExWIGZvciBMRFA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBUaGlzIHNlY3Rpb24gZGVmaW5lcyBhIGdlbmVyaWMgTUFDIEZsdXNoIFBhcmFtZXRlcnMg VExWIGZvciBMRFA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgW1JGQzUwMzZdLiAgVGhyb3VnaCBvdXQgdGhpcyBkb2N1bWVudCB0aGUgTUFD IEZsdXNoIFBhcmFtZXRlcnMgVExWIGlzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgW1JGQzUwMzZdLiAgVGhyb3VnaCBvdXQgdGhpcyBkb2N1bWVudCB0aGUgTUFDIEZsdXNoIFBh cmFtZXRlcnMgVExWIGlzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIHJlZmVycmVkIGFzIE1BQyBGbHVzaCBUTFYuICBBIE1BQyBGbHVzaCBU TFYgY2FycmllcyBpbmZvcm1hdGlvbiBvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIHJlZmVycmVkIGFzIE1BQyBGbHVzaCBUTFYuICBBIE1BQyBGbHVzaCBUTFYgY2FycmllcyBp bmZvcm1hdGlvbiBvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICB0aGUgZGVzaXJlZCBhY3Rpb24gYXQgdGhlIFBFLXJzIGRldmljZSByZWNl aXZpbmcgdGhlIG1lc3NhZ2UgYW5kIGlzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgdGhlIGRlc2lyZWQgYWN0aW9uIGF0IHRoZSBQRS1ycyBkZXZpY2UgcmVjZWl2aW5nIHRoZSBt ZXNzYWdlIGFuZCBpczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICB1c2VkIGZvciBvcHRpbWl6ZWQgTUFDIGZsdXNoaW5nIGluIFZQTFMuICBU aGUgTUFDIEZsdXNoIFRMViBjYW4gYWxzbzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIHVzZWQgZm9yIG9wdGltaXplZCBNQUMgZmx1c2hpbmcgaW4gVlBMUy4gIFRoZSBNQUMgRmx1 c2ggVExWIGNhbiBhbHNvPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZD48YSBuYW1lPSJkaWZmMDAwNyIgLz48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgIGJlIHVzZWQgZm9yIFtSRkM0NzYyXSBzdHlsZSBvZiBNQUMgRmx1c2ggYXMgZXhwbGFp bmVkIGluIHNlY3Rpb24gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Mjwvc3Bhbj4uPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGJlIHVzZWQgZm9yIFtSRkM0NzYyXSBzdHlsZSBvZiBN QUMgRmx1c2ggYXMgZXhwbGFpbmVkIGluIHNlY3Rpb24gPHNwYW4gY2xhc3M9Imluc2VydCI+Mzwv c3Bhbj4uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij41LjEuMS4gIE1BQyBGbHVzaCBQYXJh bWV0ZXJzIFRMVjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjUuMS4xLiAgTUFDIEZs dXNoIFBhcmFtZXRlcnMgVExWPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUgTUFD IEZsdXNoIFBhcmFtZXRlcnMgVExWIGlzIGRlc2NyaWJlZCBhcyBiZWxvdzo8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgTUFDIEZsdXNoIFBhcmFtZXRlcnMgVExWIGlzIGRl c2NyaWJlZCBhcyBiZWxvdzo8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDAgICAgICAg ICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDM8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAwICAgICAgICAgICAgICAgICAgIDEgICAg ICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzPC90ZD48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgfDF8MXwgTUFDIEZsdXNoIFBhcmFtcyBUTFYoVEJE QSl8ICAgICAgICAgICBMZW5ndGggICAgICAgICAgICAgIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICB8MXwxfCBNQUMgRmx1c2ggUGFyYW1zIFRMVihUQkRBKXwgICAgICAgICAg IExlbmd0aCAgICAgICAgICAgICAgfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHIgYmdjb2xvcj0iZ3JheSIgPjx0ZD48L3RkPjx0aD48YSBu YW1lPSJwYXJ0LWw1IiAvPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4g cGFnZSAxNSwgbGluZSAxNDwvZW0+PC90aD48dGg+IDwvdGg+PHRoPjxhIG5hbWU9InBhcnQtcjUi IC8+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGVtPiBwYWdlIDE1LCBsaW5l IDE0PC9lbT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBjb250ZXh0LjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNvbnRleHQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBOIGZsYWcsIHVzZWQgdG8gaW5kaWNhdGUgd2hldGhlciBhIHBvc2l0aXZlIChOPTAs IEZsdXNoLWFsbC1idXQtbWluZSk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBO IGZsYWcsIHVzZWQgdG8gaW5kaWNhdGUgd2hldGhlciBhIHBvc2l0aXZlIChOPTAsIEZsdXNoLWFs bC1idXQtbWluZSk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgb3IgbmVnYXRpdmUgKE49MSBGbHVzaC1hbGwtZnJvbS1tZSkgTUFDIEZsdXNo IGlzIHJlcXVpcmVkLiAgVGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb3Ig bmVnYXRpdmUgKE49MSBGbHVzaC1hbGwtZnJvbS1tZSkgTUFDIEZsdXNoIGlzIHJlcXVpcmVkLiAg VGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIHNvdXJjZSAobWluZS9tZSkgaXMgZGVmaW5lZCBlaXRoZXIgYXMgdGhlIFBXIGFzc29jaWF0 ZWQgd2l0aCB0aGUgTERQPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgc291cmNl IChtaW5lL21lKSBpcyBkZWZpbmVkIGVpdGhlciBhcyB0aGUgUFcgYXNzb2NpYXRlZCB3aXRoIHRo ZSBMRFA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgc2Vzc2lvbiBvbiB3aGljaCB0aGUgTERQIE1BQyBXaXRoZHJhdyB3YXMgcmVjZWl2ZWQg b3Igd2l0aCB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBzZXNzaW9uIG9u IHdoaWNoIHRoZSBMRFAgTUFDIFdpdGhkcmF3IHdhcyByZWNlaXZlZCBvciB3aXRoIHRoZTwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBCTUFD KHMpIGxpc3RlZCBpbiB0aGUgQk1BQyBTdWItVExWLiAgRm9yIHRoZSBvcHRpbWl6ZWQgTUFDIEZs dXNoPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQk1BQyhzKSBsaXN0ZWQgaW4g dGhlIEJNQUMgU3ViLVRMVi4gIEZvciB0aGUgb3B0aW1pemVkIE1BQyBGbHVzaDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBwcm9jZWR1cmUg ZGVzY3JpYmVkIGluIHRoaXMgc2VjdGlvbiB0aGUgZmxhZyBNVVNUIGJlIHNldCAoTj0xKS48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBwcm9jZWR1cmUgZGVzY3JpYmVkIGluIHRo aXMgc2VjdGlvbiB0aGUgZmxhZyBNVVNUIGJlIHNldCAoTj0xKS48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIERldGFpbGVkIHVzYWdlIGluIHRoZSBjb250ZXh0IG9mIFBCQi1WUExTIGlz IGV4cGxhaW5lZCBpbiBzZWN0aW9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg RGV0YWlsZWQgdXNhZ2UgaW4gdGhlIGNvbnRleHQgb2YgUEJCLVZQTFMgaXMgZXhwbGFpbmVkIGlu IHNlY3Rpb248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDA4IiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg PHNwYW4gY2xhc3M9ImRlbGV0ZSI+NDwvc3Bhbj4uMi48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+NTwvc3Bhbj4uMi48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIE1CWiBmbGFncywgdGhlIHJlc3Qgb2YgdGhlIGZsYWdzIFNIT1VM RCBiZSBzZXQgdG8gemVybyBvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIE1C WiBmbGFncywgdGhlIHJlc3Qgb2YgdGhlIGZsYWdzIFNIT1VMRCBiZSBzZXQgdG8gemVybyBvbjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0 cmFuc21pc3Npb24gYW5kIGlnbm9yZWQgb24gcmVjZXB0aW9uLjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIHRyYW5zbWlzc2lvbiBhbmQgaWdub3JlZCBvbiByZWNlcHRpb24uPC90 ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUgTUFDIEZsdXNoIFRMViBTSE9VTEQgYmUg cGxhY2VkIGFmdGVyIHRoZSBleGlzdGluZyBUTFZzIGluIE1BQzwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIFRoZSBNQUMgRmx1c2ggVExWIFNIT1VMRCBiZSBwbGFjZWQgYWZ0ZXIg dGhlIGV4aXN0aW5nIFRMVnMgaW4gTUFDPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEZsdXNoIG1lc3NhZ2UgaW4gW1JGQzQ3NjJdLjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEZsdXNoIG1lc3NhZ2UgaW4gW1JGQzQ3NjJd LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+NS4xLjIuICBBcHBsaWNhdGlvbiBvZiBNQUMg Rmx1c2ggVExWIGluIE9wdGltaXplZCBNQUMgRmx1c2g8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij41LjEuMi4gIEFwcGxpY2F0aW9uIG9mIE1BQyBGbHVzaCBUTFYgaW4gT3B0aW1pemVk IE1BQyBGbHVzaDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRm9yIG9wdGltaXplZCBN QUMgZmx1c2gsIHRoZSBNQUMgRmx1c2ggVExWIE1BWSBiZSBzZW50IGFzIGluIGV4aXN0aW5nPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRm9yIG9wdGltaXplZCBNQUMgZmx1c2gs IHRoZSBNQUMgRmx1c2ggVExWIE1BWSBiZSBzZW50IGFzIGluIGV4aXN0aW5nPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIExEUCBBZGRyZXNz IFdpdGhkcmF3IE1lc3NhZ2Ugd2l0aCBlbXB0eSBNQUMgTGlzdCBidXQgZnJvbSB0aGUgY29yZTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIExEUCBBZGRyZXNzIFdpdGhkcmF3IE1l c3NhZ2Ugd2l0aCBlbXB0eSBNQUMgTGlzdCBidXQgZnJvbSB0aGUgY29yZTwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBQRS1ycyBvbiBkZXRl Y3Rpb24gb2YgZmFpbHVyZSBvZiBpdHMgbG9jYWwvcHJpbWFyeSBzcG9rZSBQVy4gIFRoZSBOPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUEUtcnMgb24gZGV0ZWN0aW9uIG9mIGZh aWx1cmUgb2YgaXRzIGxvY2FsL3ByaW1hcnkgc3Bva2UgUFcuICBUaGUgTjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBiaXQgaW4gVExWIE1V U1QgYmUgc2V0IHRvIDEgdG8gaW5kaWNhdGUgRmx1c2gtYWxsLWZyb20tbWUuICBJZiB0aGU8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBiaXQgaW4gVExWIE1VU1QgYmUgc2V0IHRv IDEgdG8gaW5kaWNhdGUgRmx1c2gtYWxsLWZyb20tbWUuICBJZiB0aGU8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgb3B0aW1pemVkIE1BQyBG bHVzaCBwcm9jZWR1cmUgaXMgdXNlZCBpbiBhIEJhY2tib25lIFZQTFMgb3IgcmVndWxhcjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9wdGltaXplZCBNQUMgRmx1c2ggcHJvY2Vk dXJlIGlzIHVzZWQgaW4gYSBCYWNrYm9uZSBWUExTIG9yIHJlZ3VsYXI8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVlBMUy9ILVZQTFMgY29u dGV4dCB0aGUgQyBiaXQgTVVTVCBiZSBaRVJPIChDPTApLiAgSWYgaXQgaXMgdXNlZCBpbjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFZQTFMvSC1WUExTIGNvbnRleHQgdGhlIEMg Yml0IE1VU1QgYmUgWkVSTyAoQz0wKS4gIElmIGl0IGlzIHVzZWQgaW48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYW4gSS1jb21wb25lbnQg Y29udGV4dCB0aGUgQyBiaXQgTVVTVCBiZSBzZXQgKEM9IDEpLiAgU2VlIHNlY3Rpb24gNC4yPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYW4gSS1jb21wb25lbnQgY29udGV4dCB0 aGUgQyBiaXQgTVVTVCBiZSBzZXQgKEM9IDEpLiAgU2VlIHNlY3Rpb24gNC4yPC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGZvciBkZXRhaWxz IG9mIGl0cyB1c2FnZSBpbiBQQkItVlBMUyBjb250ZXh0LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIGZvciBkZXRhaWxzIG9mIGl0cyB1c2FnZSBpbiBQQkItVlBMUyBjb250ZXh0 LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgTm90ZSB0aGF0IHRoZSBhc3N1bXB0aW9u IGlzIHRoZSBNQUMgZmx1c2ggVExWIGlzIHVuZGVyc3Rvb2QgYnkgYWxsPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgTm90ZSB0aGF0IHRoZSBhc3N1bXB0aW9uIGlzIHRoZSBNQUMg Zmx1c2ggVExWIGlzIHVuZGVyc3Rvb2QgYnkgYWxsPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGRldmljZXMgYmVmb3JlIGl0IGlzIHR1cm5l ZCBvbiBpbiBhbnkgbmV0d29yay4gIFNlZSBPcGVyYXRpb25hbDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIGRldmljZXMgYmVmb3JlIGl0IGlzIHR1cm5lZCBvbiBpbiBhbnkgbmV0 d29yay4gIFNlZSBPcGVyYXRpb25hbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMDkiIC8+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIDxzcGFuIGNsYXNzPSJkZWxldGUi PjU8L3NwYW4+LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBDb25zaWRlcmF0 aW9ucyBzZWN0aW9uIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjY8L3NwYW4+LjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDEwIiAvPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+ICAgVGhlIE1BQyB3aXRoZHJhdyBwcm9jZWR1cmVzIGRlZmluZWQgaW4gW1JGQzQ3NjJd LCBNVFUtcyBvciBQRTItcnM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgVGhl IE1BQyB3aXRoZHJhdyBwcm9jZWR1cmVzIGRlZmluZWQgaW4gW1JGQzQ3NjJdLCA8c3BhbiBjbGFz cz0iaW5zZXJ0Ij53aGVyZSBlaXRoZXIgdGhlPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFNIT1VMRCBiZSA8c3BhbiBjbGFz cz0iZGVsZXRlIj5zZW50PC9zcGFuPiBpbiBjYXNlcyB3aGVyZSB0aGUgbmV0d29yayBpcyBiZWlu ZyB1cGdyYWRlZCBhbmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgTVRVLXMg b3IgUEUyLXJzIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnNlbmQgdGhlIE1BQyBXaXRoZHJhd2wgbWVz c2FnZTwvc3Bhbj4gU0hPVUxEIGJlIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnVzZWQ8L3NwYW4+IGlu PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgZGV2aWNlcyBhcmUgbm90IGNhcGFibGUgb2YgdW5kZXJzdGFuZGluZyB0aGUgb3B0aW1pemVk IE1BQyBmbHVzaC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgY2FzZXMgd2hl cmUgdGhlIG5ldHdvcmsgaXMgYmVpbmcgdXBncmFkZWQgYW5kIGRldmljZXMgYXJlIG5vdCBjYXBh YmxlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgVGhpcyB3b3VsZCByZXN1bHQgaW4gdGhlIHNhbWUgZmx1c2hpbmcgYWN0aW9uIGFzIFtS RkM0NzYyXSBhdCB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgb2YgdW5k ZXJzdGFuZGluZyB0aGUgb3B0aW1pemVkIE1BQyBmbHVzaC4gIFRoaXMgd291bGQgcmVzdWx0IGlu IHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgIHJlY2VpdmluZyBQRS1ycyBkZXZpY2VzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICBzYW1lIGZsdXNoaW5nIGFjdGlvbiBhcyBbUkZDNDc2Ml0gYXQgdGhlIHJlY2Vp dmluZyBQRS1ycyBkZXZpY2VzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRm9yIHRo ZSBjYXNlIG9mIEItVlBMUyBkZXZpY2VzIG9wdGltaXplZCBNQUMgZmx1c2ggbWVzc2FnZSBTSE9V TEQgYmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBGb3IgdGhlIGNhc2Ugb2Yg Qi1WUExTIGRldmljZXMgb3B0aW1pemVkIE1BQyBmbHVzaCBtZXNzYWdlIFNIT1VMRCBiZTwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBzdXBw b3J0ZWQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgc3VwcG9ydGVkLjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+NS4xLjMuICBNQUMgRmx1c2ggVExWIFByb2Nlc3Npbmcg UnVsZXMgZm9yIFJlZ3VsYXIgVlBMUzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjUu MS4zLiAgTUFDIEZsdXNoIFRMViBQcm9jZXNzaW5nIFJ1bGVzIGZvciBSZWd1bGFyIFZQTFM8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWdu PSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMgc2VjdGlvbiBkZXNjcmliZXMgdGhlIHBy b2Nlc3NpbmcgcnVsZXMgb2YgTUFDIEZsdXNoIFRMViB0aGF0PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgVGhpcyBzZWN0aW9uIGRlc2NyaWJlcyB0aGUgcHJvY2Vzc2luZyBydWxl cyBvZiBNQUMgRmx1c2ggVExWIHRoYXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRv cCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgU0hPVUxEIGJlIGZvbGxvd2VkIGluIHRoZSBjb250ZXh0 IG9mIE1BQyBmbHVzaCBwcm9jZWR1cmVzIGluIFZQTFMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgU0hPVUxEIGJlIGZvbGxvd2VkIGluIHRoZSBjb250ZXh0IG9mIE1BQyBmbHVz aCBwcm9jZWR1cmVzIGluIFZQTFMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3Ai PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBGb3Ig b3B0aW1pemVkIE1BQyBGbHVzaCBhIG11bHRpLWhvbWluZyBQRS1ycyBpbml0aWF0ZXMgTUFDIGZs dXNoPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRm9yIG9wdGltaXplZCBNQUMg Rmx1c2ggYSBtdWx0aS1ob21pbmcgUEUtcnMgaW5pdGlhdGVzIE1BQyBmbHVzaDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGJnY29s b3I9ImdyYXkiID48dGQ+PC90ZD48dGg+PGEgbmFtZT0icGFydC1sNiIgLz48c21hbGw+c2tpcHBp bmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBhZ2UgMTYsIGxpbmUgMjk8L2VtPjwvdGg+PHRo PiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXI2IiAvPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2Ug YXQ8L3NtYWxsPjxlbT4gcGFnZSAxNiwgbGluZSAyOTwvZW0+PC90aD48dGQ+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIElmIGEgTUFDIEZsdXNoIFRM ViBpcyByZWNlaXZlZCB3aXRoIE4gPSAwIGluIHRoZSBNQUMgZmx1c2ggbWVzc2FnZTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIElmIGEgTUFDIEZsdXNoIFRMViBpcyByZWNlaXZl ZCB3aXRoIE4gPSAwIGluIHRoZSBNQUMgZmx1c2ggbWVzc2FnZTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aGVuIHRoZSByZWNlaXZpbmcg UEUtcnMgU0hPVUxEIGZsdXNoIHRoZSBNQUMgYWRkcmVzc2VzIGxlYXJuZWQgZnJvbTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRoZW4gdGhlIHJlY2VpdmluZyBQRS1ycyBTSE9V TEQgZmx1c2ggdGhlIE1BQyBhZGRyZXNzZXMgbGVhcm5lZCBmcm9tPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFsbCBQV3MgaW4gdGhlIFZQ TFMgaW5zdGFuY2UgZXhjZXB0IHRoZSBvbmVzIGxlYXJuZWQgb3ZlciB0aGUgUFcgb248L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhbGwgUFdzIGluIHRoZSBWUExTIGluc3RhbmNl IGV4Y2VwdCB0aGUgb25lcyBsZWFybmVkIG92ZXIgdGhlIFBXIG9uPC90ZD48dGQgY2xhc3M9Imxp bmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v IiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHdoaWNoIHRoZSBtZXNzYWdl IGlzIHJlY2VpdmVkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHdoaWNoIHRo ZSBtZXNzYWdlIGlzIHJlY2VpdmVkLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSWYg YSBQRS1ycyBkZXZpY2UgcmVjZWl2ZXMgYSBNQUMgZmx1c2ggd2l0aCB0aGUgTUFDIEZsdXNoIFRM ViBvcHRpb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJZiBhIFBFLXJzIGRl dmljZSByZWNlaXZlcyBhIE1BQyBmbHVzaCB3aXRoIHRoZSBNQUMgRmx1c2ggVExWIG9wdGlvbjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBh bmQgYSB2YWxpZCBNQUMgYWRkcmVzcyBsaXN0LCBpdCBTSE9VTEQgaWdub3JlIHRoZSBvcHRpb24g YW5kIGRlYWw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhbmQgYSB2YWxpZCBN QUMgYWRkcmVzcyBsaXN0LCBpdCBTSE9VTEQgaWdub3JlIHRoZSBvcHRpb24gYW5kIGRlYWw8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgd2l0 aCBNQUMgYWRkcmVzc2VzIGV4cGxpY2l0bHkgYXMgcGVyIFtSRkM0NzYyXS4gIEl0IGlzIGFzc3Vt ZWQgd2hlbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHdpdGggTUFDIGFkZHJl c3NlcyBleHBsaWNpdGx5IGFzIHBlciBbUkZDNDc2Ml0uICBJdCBpcyBhc3N1bWVkIHdoZW48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdGhl c2UgcHJvY2VkdXJlcyBhcmUgdXNlZCBhbGwgbm9kZXMgc3VwcG9ydCB0aGUgTUFDIEZsdXNoIE1l c3NhZ2UuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhlc2UgcHJvY2VkdXJl cyBhcmUgdXNlZCBhbGwgbm9kZXMgc3VwcG9ydCB0aGUgTUFDIEZsdXNoIE1lc3NhZ2UuPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZD48 YSBuYW1lPSJkaWZmMDAxMSIgLz48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFNlZSBzZWN0aW9uIDxz cGFuIGNsYXNzPSJkZWxldGUiPjU8L3NwYW4+IE9wZXJhdGlvbmFsIENvbnNpZGVyYXRpb25zIGZv ciBkZXRhaWxzLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBTZWUgc2VjdGlv biA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij42PC9zcGFuPiBPcGVyYXRpb25hbCBDb25zaWRlcmF0aW9u cyBmb3IgZGV0YWlscy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjUuMS40LiAgT3B0aW1p emVkIE1BQyBGbHVzaCBQcm9jZWR1cmVzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ NS4xLjQuICBPcHRpbWl6ZWQgTUFDIEZsdXNoIFByb2NlZHVyZXM8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIFRoaXMgc2VjdGlvbiBleHBsYWlucyB0aGUgb3B0aW1pemVkIE1BQyBmbHVz aCBwcm9jZWR1cmUgaW4gdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhp cyBzZWN0aW9uIGV4cGxhaW5zIHRoZSBvcHRpbWl6ZWQgTUFDIGZsdXNoIHByb2NlZHVyZSBpbiB0 aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkPjxhIG5hbWU9ImRpZmYwMDEyIiAvPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgc2NlbmFy aW8gaW4gRmlndXJlIDIuICBXaGVuIDxzcGFuIGNsYXNzPSJkZWxldGUiPnRoZSBwcmltYXJ5IHNw b2tlIFBXIHRyYW5zaXRpb24gKGZhaWx1cmU8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgIHNjZW5hcmlvIGluIEZpZ3VyZSAyLiAgV2hlbiA8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij5PcHRpbWl6ZWQgTUFDIGZsdXNoIGlzIGJlaW5nIHVzZWQgYSBQRS1yczwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3Bh biBjbGFzcz0iZGVsZXRlIj4gICBvciBzdGFuZGJ5IHRyYW5zaXRpb24pPC9zcGFuPiBpcyA8c3Bh biBjbGFzcz0iZGVsZXRlIj5kZXRlY3RlZCBieSBQRTEtcnMsIGl0IE1BWTwvc3Bhbj4gc2VuZCBN QUMgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Zmx1c2g8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHRoYXQ8L3NwYW4+IGlzIDxzcGFu IGNsYXNzPSJpbnNlcnQiPmR1YWwgaG9taW5nIGF3YXJlIFNIT1VMRDwvc3Bhbj4gc2VuZCBNQUMg PHNwYW4gY2xhc3M9Imluc2VydCI+YWRkcmVzczwvc3Bhbj4gbWVzc2FnZXMgd2l0aCBNQUM8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBt ZXNzYWdlcyA8c3BhbiBjbGFzcz0iZGVsZXRlIj50byBQRTItcnMsIFBFMy1ycyBhbmQgUEU0LXJz PC9zcGFuPiB3aXRoIE1BQyBGbHVzaCBUTFYgYW5kIDxzcGFuIGNsYXNzPSJkZWxldGUiPk4gPSAx Ljwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgRmx1c2ggVExWIGFu ZCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5OPTEgcHJvdmlkZWQgdGhlIG90aGVyIFBFcyB1bmRlcnN0 YW5kIHRoZSBuZXcgbWVzc2FnZXMuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBVcG9uIHJlY2VpcHQgb2YgdGhlIE1BQyBmbHVz aCBtZXNzYWdlLCBQRTItcnMgaWRlbnRpZmllcyB0aGUgVlBMUzwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIFVwb24gcmVjZWlwdCBvZiB0aGUgTUFDIGZsdXNoIG1lc3NhZ2UsIFBF Mi1ycyBpZGVudGlmaWVzIHRoZSBWUExTPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGluc3RhbmNlIHRoYXQgcmVxdWlyZXMgTUFDIGZsdXNo IGZyb20gdGhlIEZFQyBlbGVtZW50IGluIHRoZSBGRUMgVExWLjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIGluc3RhbmNlIHRoYXQgcmVxdWlyZXMgTUFDIGZsdXNoIGZyb20gdGhl IEZFQyBlbGVtZW50IGluIHRoZSBGRUMgVExWLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBPbiByZWNlaXZpbmcgTj0xLCBQRS0yIHJlbW92 ZXMgYWxsIE1BQyBhZGRyZXNzZXMgbGVhcm5lZCBmcm9tIHRoYXQgUFc8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBPbiByZWNlaXZpbmcgTj0xLCBQRS0yIHJlbW92ZXMgYWxsIE1B QyBhZGRyZXNzZXMgbGVhcm5lZCBmcm9tIHRoYXQgUFc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgb3ZlciB3aGljaCB0aGUgbWVzc2FnZSBp cyByZWNlaXZlZC4gIFRoZSBzYW1lIGFjdGlvbiBpcyBmb2xsb3dlZCBieTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIG92ZXIgd2hpY2ggdGhlIG1lc3NhZ2UgaXMgcmVjZWl2ZWQu ICBUaGUgc2FtZSBhY3Rpb24gaXMgZm9sbG93ZWQgYnk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUEUzLXJzIGFuZCBQRTQtcnMuPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUEUzLXJzIGFuZCBQRTQtcnMuPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBGaWd1cmUgNCBzaG93cyBhbm90aGVyIHJlZHVuZGFudCBI LVZQTFMgdG9wb2xvZ3kgdG8gcHJvdGVjdCBhZ2FpbnN0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgRmlndXJlIDQgc2hvd3MgYW5vdGhlciByZWR1bmRhbnQgSC1WUExTIHRvcG9s b2d5IHRvIHByb3RlY3QgYWdhaW5zdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBmYWlsdXJlIG9mIE1UVS1zIGRldmljZS4gIFByb3ZpZGVy IFJTVFAgW0lFRUUuODAyLjFRLTIwMTFdIG1heSBiZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIGZhaWx1cmUgb2YgTVRVLXMgZGV2aWNlLiAgUHJvdmlkZXIgUlNUUCBbSUVFRS44 MDIuMVEtMjAxMV0gbWF5IGJlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIHVzZWQgYXMgc2VsZWN0aW9uIGFsZ29yaXRobSBmb3IgYWN0aXZl IGFuZCBiYWNrdXAgUFdzIGluIG9yZGVyIHRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgdXNlZCBhcyBzZWxlY3Rpb24gYWxnb3JpdGhtIGZvciBhY3RpdmUgYW5kIGJhY2t1cCBQ V3MgaW4gb3JkZXIgdG88L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgbWFpbnRhaW4gdGhlIGNvbm5lY3Rpdml0eSBiZXR3ZWVuIE1UVS1zIGRl dmljZXMgYW5kIFBFLXJzIGRldmljZXMgYXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBtYWludGFpbiB0aGUgY29ubmVjdGl2aXR5IGJldHdlZW4gTVRVLXMgZGV2aWNlcyBhbmQg UEUtcnMgZGV2aWNlcyBhdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyIGJnY29sb3I9ImdyYXkiID48dGQ+PC90ZD48dGg+PGEgbmFt ZT0icGFydC1sNyIgLz48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48ZW0+IHBh Z2UgMjAsIGxpbmUgMTY8L2VtPjwvdGg+PHRoPiA8L3RoPjx0aD48YSBuYW1lPSJwYXJ0LXI3IiAv PjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxlbT4gcGFnZSAyMCwgbGluZSAx NjwvZW0+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZh bGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYXNzb2NpYXRlZCB3aXRoIHRoZSBC TUFDKHMpIGluIHRoZSBCTUFDIExpc3QgU3ViLVRMViBmcm9tIHRoZSBGSUJzPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYXNzb2NpYXRlZCB3aXRoIHRoZSBCTUFDKHMpIGluIHRo ZSBCTUFDIExpc3QgU3ViLVRMViBmcm9tIHRoZSBGSUJzPC90ZD48dGQgY2xhc3M9ImxpbmVubyIg dmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxp Z249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFzc29jaWF0ZWQgd2l0aCB0aGUgSVNJ RCBsaXN0IikuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYXNzb2NpYXRlZCB3 aXRoIHRoZSBJU0lEIGxpc3QiKS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjUuMi4yLiAg QXBwbGljYWJpbGl0eSBvZiBNQUMgRmx1c2ggUGFyYW1ldGVycyBUTFY8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij41LjIuMi4gIEFwcGxpY2FiaWxpdHkgb2YgTUFDIEZsdXNoIFBhcmFt ZXRlcnMgVExWPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJZiBNQUMgRmx1c2ggUGFy YW1ldGVycyBUTFYgaXMgcmVjZWl2ZWQgYnkgYSBCYWNrYm9uZSBFZGdlIEJyaWRnZXM8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJZiBNQUMgRmx1c2ggUGFyYW1ldGVycyBUTFYg aXMgcmVjZWl2ZWQgYnkgYSBCYWNrYm9uZSBFZGdlIEJyaWRnZXM8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIiB2YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgKEJFQikgaW4gYSBQQkItVlBM UyB0aGF0IGRvZXMgbm90IHVuZGVyc3RhbmQgdGhlIFRMViB0aGVuIGl0IG1heTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIChCRUIpIGluIGEgUEJCLVZQTFMgdGhhdCBkb2VzIG5v dCB1bmRlcnN0YW5kIHRoZSBUTFYgdGhlbiBpdCBtYXk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcmVzdWx0IGluIHVuZGVzaXJhYmxlIE1B QyBmbHVzaGluZyBhY3Rpb24uICBJdCBpcyBSRUNPTU1FTkRFRCB0aGF0PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgcmVzdWx0IGluIHVuZGVzaXJhYmxlIE1BQyBmbHVzaGluZyBh Y3Rpb24uICBJdCBpcyBSRUNPTU1FTkRFRCB0aGF0PC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFsbCBQRS1ycyBkZXZpY2VzIHBhcnRpY2lw YXRpbmcgaW4gUEJCLVZQTFMgc3VwcG9ydCBNQUMgRmx1c2g8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBhbGwgUEUtcnMgZGV2aWNlcyBwYXJ0aWNpcGF0aW5nIGluIFBCQi1WUExT IHN1cHBvcnQgTUFDIEZsdXNoPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIFBhcmFtZXRlcnMgVExWLiAgSWYgdGhpcyBpcyBub3QgcG9zc2li bGUgdGhlIE1BQyBGbHVzaCBQYXJhbWV0ZXJzIFRMVjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIFBhcmFtZXRlcnMgVExWLiAgSWYgdGhpcyBpcyBub3QgcG9zc2libGUgdGhlIE1B QyBGbHVzaCBQYXJhbWV0ZXJzIFRMVjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQ+PGEgbmFtZT0iZGlmZjAwMTMiIC8+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICBTSE9VTEQgYmUgZGlzYWJsZWQgYXMgbWVudGlvbmVkIGluIHNlY3Rpb24g PHNwYW4gY2xhc3M9ImRlbGV0ZSI+NTwvc3Bhbj4gT3BlcmF0aW9uYWw8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgU0hPVUxEIGJlIGRpc2FibGVkIGFzIG1lbnRpb25lZCBpbiBz ZWN0aW9uIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjY8L3NwYW4+IE9wZXJhdGlvbmFsPC90ZD48dGQg Y2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIENvbnNpZGVy YXRpb25zLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIENvbnNpZGVyYXRpb25z LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2 YWxpZ249InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGln bj0idG9wIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIE1BQyBGbHVzaCBQYXJhbWV0ZXJz IFRMViBpcyBhbHNvIGFwcGxpY2FibGUgdG8gcmVndWxhciBWUExTPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgVGhlIE1BQyBGbHVzaCBQYXJhbWV0ZXJzIFRMViBpcyBhbHNvIGFw cGxpY2FibGUgdG8gcmVndWxhciBWUExTPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGNvbnRleHQgYXMgd2VsbCBhcyBleHBsYWluZWQgaW4g c2VjdGlvbiAzLjEuMS4gIFRvIGFjaGlldmUgbmVnYXRpdmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBjb250ZXh0IGFzIHdlbGwgYXMgZXhwbGFpbmVkIGluIHNlY3Rpb24gMy4x LjEuICBUbyBhY2hpZXZlIG5lZ2F0aXZlPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0 b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE1BQyBGbHVzaCAoZmx1c2gtYWxsLWZyb20tbWUpIGlu IHJlZ3VsYXIgVlBMUyBjb250ZXh0LCB0aGUgTUFDIEZsdXNoPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgTUFDIEZsdXNoIChmbHVzaC1hbGwtZnJvbS1tZSkgaW4gcmVndWxhciBW UExTIGNvbnRleHQsIHRoZSBNQUMgRmx1c2g8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0idG9w Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUGFyYW1ldGVycyBUTFYgU0hPVUxEIGJlIGVuY29k ZWQgd2l0aCBDPTAgYW5kIE4gPSAxIHdpdGhvdXQgaW5jbHVzaW9uPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgUGFyYW1ldGVycyBUTFYgU0hPVUxEIGJlIGVuY29kZWQgd2l0aCBD PTAgYW5kIE4gPSAxIHdpdGhvdXQgaW5jbHVzaW9uPC90ZD48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIiB2YWxpZ249 InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG9mIGFueSBTdWItVExWcy4gIE5lZ2F0aXZl IE1BQyBmbHVzaCBpcyBoaWdobHkgZGVzaXJhYmxlIGluIHNjZW5hcmlvczwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9mIGFueSBTdWItVExWcy4gIE5lZ2F0aXZlIE1BQyBmbHVz aCBpcyBoaWdobHkgZGVzaXJhYmxlIGluIHNjZW5hcmlvczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB3aGVuIFZQTFMgYWNjZXNzIHJlZHVu ZGFuY3kgaXMgcHJvdmlkZWQgYnkgRXRoZXJuZXQgUmluZyBQcm90ZWN0aW9uPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgd2hlbiBWUExTIGFjY2VzcyByZWR1bmRhbmN5IGlzIHBy b3ZpZGVkIGJ5IEV0aGVybmV0IFJpbmcgUHJvdGVjdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i IHZhbGlnbj0idG9wIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyIgdmFs aWduPSJ0b3AiPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhcyBzcGVjaWZpZWQgaW4gSVRVLVQg W0lUVS5HODAzMl1zcGVjaWZpY2F0aW9uLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIGFzIHNwZWNpZmllZCBpbiBJVFUtVCBbSVRVLkc4MDMyXXNwZWNpZmljYXRpb24uPC90ZD48 dGQgY2xhc3M9ImxpbmVubyIgdmFsaWduPSJ0b3AiPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIiB2YWxpZ249InRvcCI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iIHZhbGlnbj0i dG9wIj48L3RkPjwvdHI+CgogICAgIDx0cj48dGQ+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkPjwvdGQ+PC90cj4KICAgICA8dHIg Ymdjb2xvcj0iZ3JheSI+PHRoIGNvbHNwYW49IjUiIGFsaWduPSJjZW50ZXIiPjxhIG5hbWU9ImVu ZCI+Jm5ic3A7RW5kIG9mIGNoYW5nZXMuIDEzIGNoYW5nZSBibG9ja3MuJm5ic3A7PC9hPjwvdGg+ PC90cj4KICAgICA8dHIgY2xhc3M9InN0YXRzIj48dGQ+PC90ZD48dGg+PGk+MjEgbGluZXMgY2hh bmdlZCBvciBkZWxldGVkPC9pPjwvdGg+PHRoPjxpPiA8L2k+PC90aD48dGg+PGk+MjEgbGluZXMg Y2hhbmdlZCBvciBhZGRlZDwvaT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgPHRyPjx0ZCBjb2xz cGFuPSI1IiBhbGlnbj0iY2VudGVyIiBjbGFzcz0ic21hbGwiPjxici8+VGhpcyBodG1sIGRpZmYg d2FzIHByb2R1Y2VkIGJ5IHJmY2RpZmYgMS40MS4gVGhlIGxhdGVzdCB2ZXJzaW9uIGlzIGF2YWls YWJsZSBmcm9tIDxhIGhyZWY9Imh0dHA6Ly93d3cudG9vbHMuaWV0Zi5vcmcvdG9vbHMvcmZjZGlm Zi8iID5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvdG9vbHMvcmZjZGlmZi88L2E+IDwvdGQ+PC90cj4K ICAgPC90YWJsZT4KICAgPC9ib2R5PgogICA8L2h0bWw+Cg== --_003_A46D9C092EA46F489F135060986AD9FFD0A81AG6W2492americashp_-- From nobody Mon Apr 7 12:41:20 2014 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 1E5591A07F5; Mon, 7 Apr 2014 12:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 0lbUX2xwYsT3; Mon, 7 Apr 2014 12:41:10 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A54E1A0705; Mon, 7 Apr 2014 12:41:10 -0700 (PDT) Received: from unnumerable.local (pool-173-71-50-89.dllstx.fios.verizon.net [173.71.50.89]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s37Jf3c1073059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Mon, 7 Apr 2014 14:41:04 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-71-50-89.dllstx.fios.verizon.net [173.71.50.89] claimed to be unnumerable.local Message-ID: <5342FF4F.4040906@nostrum.com> Date: Mon, 07 Apr 2014 14:41:03 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: General Area Review Team , draft-ietf-l2vpn-vpls-ldp-mac-opt@tools.ietf.org, l2vpn@ietf.org Subject: Gen-art LC review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/ikdgtOupcL5EF8nsIQNzHA5eYAM 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, 07 Apr 2014 19:41:15 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-l2vpn-vpls-ldp-mac-opt-11 Reviewer: Robert Sparks Review Date: 7Apr2014 IETF LC End Date: 8Apr2014 IESG Telechat date: not yet scheduled Summary: This draft is almost ready for publication as a Proposed Standard, but has minor issues (primarily editorial) that should be addressed. I found this document very difficult to read. It asks the reader to hop between sections in unusual ways (for instance, it sends the reader to the problem statement section for details on normative behavior). I strongly encourage an editorial pass focusing on document structure. There are many instances of SHOULD in the document where the text should just be using prose instead. It's not always clear when an implementation would choose to ignore the SHOULD, and what the consequences of that choice would be. The document is inconsistent about the level of support needed in the network before trying to use this extension. Section 5.1.2 says the assumption is everything understands it before it's turned on. Section 6 points back to figure 2 and says to use the extension over the pw where you administratively know the peer supports the extension, and fall back to 4762 for everything else. Which of those did you intend? Specific comments in document order: Section 3.2 paragraph 1: This paragraph would benefit from being broken into several. It's hard to find its point. The SHOULD in this paragraph is probably not a 2119 SHOULD (this section isn't defining the protocol). It would be useful in this overview to explicitly say _why_ "This cannot be achieved with ... 4762]" at this point in the document. Section 3.2 paragraph 2: This SHOULD _is_ defining protocol - shouldn't it be in section 5? Section 4.1.1 paragraph 3: It took me some time to find Z on the figure. It might help to introduce it similar to how you introduce X. Section 4.1.2: paragraph 1: I think you meant to reference 4.1.1 Section 5: The first sentence talks about requirements in section 4. Section 4 describes a problem using some examples but doesn't explicitly call out requirements. Doing so would help the document. Last sentence in 5.1.1 (and several other places in the document): Please add an article before "MAC Flush message". (I apologize for such a small nit, but each of these instances made making sure I was reading what the sentence intended significantly more difficult). Section 5.1.2 first paragraph: This section is defining behavior - why are you sending the reader back into the problem statement for detail on the behavior? 5.1.2 paragraph 2: You meant section 6, not 5. 5.1.2 paragraph 3: I can't follow this paragraph's structure. I think you're trying to say "An MTU-s or PE2-rs SHOULD send MAC withdraw messages as defined in [RFC4762] in cases where the network is being upgraded and devices are not capable of understanding the optimized MAC flush." (But if so, the next sentence is redundant.) Why is this SHOULD? 5.1.3 paragraph 1: Why is this a SHOULD and not a MUST? (Similar question for the SHOULD in paragraph 2). It's not clear if you're trying to avoid "Some things won't implement this spec" or "Don't do this if you haven't administratively ensured every element understands this extension first" or something else? 5.1.3 paragraph 3: You say "unless specified otherwise". Do you ever specify otherwise? Why is this disclaimer here? 5.1.3 last paragraph: You meant section 6 not 5. From nobody Mon Apr 7 18:18:21 2014 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 A69BC1A0869; Mon, 7 Apr 2014 18:18:17 -0700 (PDT) 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 oS1K1C59FFn2; Mon, 7 Apr 2014 18:18:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 938C01A085F; Mon, 7 Apr 2014 18:18:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l2vpn-vpls-pe-etree-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140408011809.29243.16302.idtracker@ietfa.amsl.com> Date: Mon, 07 Apr 2014 18:18:09 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/vEh62_H0XJPGcVA20eCsyOIQjK4 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: Tue, 08 Apr 2014 01:18:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : Ethernet-Tree (E-Tree) Support in Virtual Private LAN Service (VPLS) Authors : Yuanlong Jiang Lucy Yong Manuel Paul Frederic Jounay Florin Balus Wim Henderickx Ali Sajassi Filename : draft-ietf-l2vpn-vpls-pe-etree-03.txt Pages : 23 Date : 2014-04-07 Abstract: A generic Virtual Private LAN Service (VPLS) solution is proposed for Ethernet-Tree (E-Tree) services which uses VLANs to indicate root or leaf traffic. A VPLS Provider Edge (PE) model is illustrated as an example for the solution. In the solution, E-Tree VPLS PEs are interconnected by PWs which carry the VLAN indicating the E-Tree attribute, the MAC address based Ethernet forwarding engine and the PW work in the same way as before. A signaling mechanism for E-Tree capability and VLAN mapping negotiation is further described. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-vpls-pe-etree/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-pe-etree-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-l2vpn-vpls-pe-etree-03 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 nobody Mon Apr 7 20:32:55 2014 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 CF9141A00BB for ; Mon, 7 Apr 2014 20:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 29H25-1XjpLN for ; Mon, 7 Apr 2014 20:32:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B24D21A00B0 for ; Mon, 7 Apr 2014 20:32:47 -0700 (PDT) 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 BFJ46544; Tue, 08 Apr 2014 03:32:41 +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; Tue, 8 Apr 2014 04:31:29 +0100 Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 8 Apr 2014 04:32:40 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.41]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Tue, 8 Apr 2014 11:32:28 +0800 From: Jiangyuanlong To: "l2vpn@ietf.org" Subject: FW: New Version Notification for draft-ietf-l2vpn-vpls-pe-etree-03.txt Thread-Topic: New Version Notification for draft-ietf-l2vpn-vpls-pe-etree-03.txt Thread-Index: AQHPUsht0aVWdFuPgEi2U4taGq67+ZsHDm5A Date: Tue, 8 Apr 2014 03:32:27 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B5A6F234B@szxema506-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.118] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/faciDxIiRv6MQJUiY_Ac5KnJ7nU 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, 08 Apr 2014 03:32:53 -0000 SGkgY29sbGVhZ3VlcywNCg0KU2luY2UgRS1UcmVlIHJlcXVpcmVtZW50cyBkb2MgaGFzIGFscmVh ZHkgYmVlbiBwdWJsaXNoZWQgYXMgUkZDIDcxNTIsIHdlIGhhdmUgdXBkYXRlZCBkcmFmdC1pZXRm LWwydnBuLXZwbHMtcGUtZXRyZWUgdG8gYWxpZ24gd2l0aCBpdC4gDQpGb3IgdGhpcyBuZXcgdmVy c2lvbiwgbWFpbiB1cGRhdGVzIGluY2x1ZGU6DQoxLglBIG5ldyB0aXRsZSBtb3JlIGFwcHJvcHJp YXRlIGZvciB0aGlzIGRvYy47DQoyLglJbnRyb2R1Y3Rpb24gbW92ZWQgdG8gU2VjdGlvbiAzOw0K My4gIFF1aXRlIGEgZmV3IGVkaXRvcmlhbCBjaGFuZ2VzIHRvIGJlIGNvbnNpc3RlbnQgd2l0aCBS RkMgNzE1Mi4NCg0KSG9wZSB0byBzZWUgeW91ciBvcGluaW9ucyBvbiB0aGlzIHJldmlzaW9uLg0K DQpCZXN0IHJlZ2FyZHMsDQpZdWFubG9uZw0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmddIA0KU2VudDogVHVlc2RheSwgQXByaWwgMDgsIDIwMTQgOToxOCBBTQ0KVG86IFdp bSBIZW5kZXJpY2t4OyBNYW51ZWwgUGF1bDsgRnJlZGVyaWMgSm91bmF5OyBGbG9yaW4gQmFsdXM7 IEx1Y3kgeW9uZzsgV2ltIEhlbmRlcmlja3g7IEZsb3JpbiBCYWx1czsgRnJlZGVyaWMgSk9VTkFZ OyBMdWN5IHlvbmc7IE1hbnVlbCBQYXVsOyBBbGkgU2FqYXNzaTsgQWxpIFNhamFzc2k7IEppYW5n eXVhbmxvbmc7IEppYW5neXVhbmxvbmcNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtaWV0Zi1sMnZwbi12cGxzLXBlLWV0cmVlLTAzLnR4dA0KDQoNCkEgbmV3IHZl cnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLWwydnBuLXZwbHMtcGUtZXRyZWUtMDMudHh0DQpoYXMg YmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFl1YW5sb25nIEppYW5nIGFuZCBwb3N0ZWQg dG8gdGhlDQpJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFmdC1pZXRmLWwydnBuLXZwbHMt cGUtZXRyZWUNClJldmlzaW9uOgkwMw0KVGl0bGU6CQlFdGhlcm5ldC1UcmVlIChFLVRyZWUpIFN1 cHBvcnQgaW4gVmlydHVhbCBQcml2YXRlIExBTiBTZXJ2aWNlIChWUExTKQ0KRG9jdW1lbnQgZGF0 ZToJMjAxNC0wNC0wOA0KR3JvdXA6CQlsMnZwbg0KUGFnZXM6CQkyMw0KVVJMOiAgICAgICAgICAg IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtbDJ2cG4tdnBs cy1wZS1ldHJlZS0wMy50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWwydnBuLXZwbHMtcGUtZXRyZWUvDQpIdG1saXplZDogICAg ICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1sMnZwbi12cGxzLXBlLWV0 cmVlLTAzDQpEaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtaWV0Zi1sMnZwbi12cGxzLXBlLWV0cmVlLTAzDQoNCkFic3RyYWN0Og0KICAgQSBnZW5l cmljIFZpcnR1YWwgUHJpdmF0ZSBMQU4gU2VydmljZSAoVlBMUykgc29sdXRpb24gaXMgcHJvcG9z ZWQgZm9yDQogICBFdGhlcm5ldC1UcmVlIChFLVRyZWUpIHNlcnZpY2VzIHdoaWNoIHVzZXMgVkxB TnMgdG8gaW5kaWNhdGUgcm9vdCBvcg0KICAgbGVhZiB0cmFmZmljLiBBIFZQTFMgUHJvdmlkZXIg RWRnZSAoUEUpIG1vZGVsIGlzIGlsbHVzdHJhdGVkIGFzIGFuDQogICBleGFtcGxlIGZvciB0aGUg c29sdXRpb24uIEluIHRoZSBzb2x1dGlvbiwgRS1UcmVlIFZQTFMgUEVzIGFyZQ0KICAgaW50ZXJj b25uZWN0ZWQgYnkgUFdzIHdoaWNoIGNhcnJ5IHRoZSBWTEFOIGluZGljYXRpbmcgdGhlIEUtVHJl ZQ0KICAgYXR0cmlidXRlLCB0aGUgTUFDIGFkZHJlc3MgYmFzZWQgRXRoZXJuZXQgZm9yd2FyZGlu ZyBlbmdpbmUgYW5kIHRoZQ0KICAgUFcgd29yayBpbiB0aGUgc2FtZSB3YXkgYXMgYmVmb3JlLiBB IHNpZ25hbGluZyBtZWNoYW5pc20gZm9yIEUtVHJlZQ0KICAgY2FwYWJpbGl0eSBhbmQgVkxBTiBt YXBwaW5nIG5lZ290aWF0aW9uIGlzIGZ1cnRoZXIgZGVzY3JpYmVkLg0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBv ZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhl IElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Tue Apr 8 01:17:06 2014 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 008511A0197; Tue, 8 Apr 2014 01:17:00 -0700 (PDT) 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 2juj3mJrz40q; Tue, 8 Apr 2014 01:16:54 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3D21A0160; Tue, 8 Apr 2014 01:16:53 -0700 (PDT) Received: from cpc4-cmbg17-2-0-cust814.5-4.cable.virginm.net ([86.14.227.47] helo=[192.168.0.3]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1WXRD3-0000FS-ND; Tue, 08 Apr 2014 09:16:46 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: RtgDir review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt From: Ben Niven-Jenkins In-Reply-To: Date: Tue, 8 Apr 2014 09:16:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4A8A526D-C573-424C-9FFF-2BF282C951F2@niven-jenkins.co.uk> References: To: "Fedyk, Don" X-Mailer: Apple Mail (2.1874) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/QiN-eQqhmEFDoxyONUg6xDxrVYQ Cc: "l2vpn@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-l2vpn-vpls-ldp-mac-opt.all@tools.ietf.org" , "rtg-ads@tools.ietf.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: Tue, 08 Apr 2014 08:17:00 -0000 Hi Don, Some follow-ups inline below On 7 Apr 2014, at 14:04, Fedyk, Don wrote: > Hi Ben >=20 > Thanks for your review. Attached are the changes so far. Inline [Don] = are my comments. >=20 > You raise a couple of points that Adrian/Nabil/Giles, other authors = should review before I change anything else. >=20 > Don >> From: Ben Niven-Jenkins =46rom reading the = document my opinion is that it suitably describes what is required to = implement the newly proposed mechanism but it may be hard for someone to = read the document and determine what circumstances would motivate using = the new optimised MAC flush versus sticking with the original RFC4627 = [don] 4762 MAC flush mechanism. >=20 > [Don] It is mentioned in section 3 overview that a simplified LDP MAC = message while it speeds up LDP can adversely affect the native Ethernet = forwarding which reverts to flooding of unknown addresses. This is = important in real time Etehrnet networks. I saw that in section 3. I can see that you have a new mechanism that = solves a problem with an existing mechanism. My comment above is my observation that the way the document is written = seems to me to assume that the reader is already familiar with the = proposed optimised MAC flush and any implications it might have and has = already decided to use/implement it and is reading the RFC to figure out = what code to write to implement it. The ADs may decide that is fine. >> Major issues: >>=20 >> I've raised this as a major issue as I think it may require AD = input/attention to resolve. It is not a technical issue but a suggestion = for including more explanatory text that I think would help improve the = document but which the AD may decide is not required. >>=20 >> The document specifies a solution to solve a problem with the = mechanism for MAC address withdrawal specified in RFC4762 but it doesn't = provide any indication of when the new optimised MAC flush that is = proposed should be used instead of the existing MAC flush mechanism = specified in RFC4627. >=20 > [Don] One of the debates we had was that for backwards compatibly the = worst you get is the RFC4762 behaviour. > But if all nodes are updated you can use the new message and get the = optimized MAC flush. However during the course of the draft a more = explicit means of specifying the behavior was proposed to signal = compatibility that became its own draft. In order to resolve the MAC = flush issues, without dependency on a capabilities draft, this draft = specifies backwards compatibly by requiring the node that supports the = optimized MAC flush can also support the old MAC flush. See my comment above. I think the same applies here. >> The downside of the existing RFC4627 MAC flush mechanism appears to = be that PEs can end up having to flush many more MAC addresses than = absolutely required when a dual homed CE/MTU switches from using the = primary spoke PW to the backup spoke PW. >=20 > [Don] Flushing more MACs causes issues with the side effect of traffic = that should not be affected being affected by a change. In order to = decouple this effect, the optimization reduces unintentional disruption. It would IMO be useful if the document stated this sort of thing = somewhere. I=92m not thinking about specific numbers or anything but = some information along these lines that highlights what are the issues & = impacts caused by RFC4627 under what circumstances and how the new = optimised MAC flush avoids them would be valuable information for a = reader to determine if they are likely to face the problems optimised = MAC flush addresses and therefore whether optimised MAC flush is = something they should consider using/implementing. >> The optimised MAC flush specified in the document solves the problem = by moving the initiation of the MAC flush message from the 'backup' = PE-rs to the 'primary' PE-rs and introducing a new message to allow the = primary PE-rs to request other PE-rs in the network flush all MAC = addresses learnt via the primary PE-rs. >>=20 >> While the new message means that the PE-rs in the network will flush = and relearn fewer MAC addresses on failure of the primary spoke PW = between the MTU-s & primary PE-rs, it is not clear to me whether it is = superior in all cases. >=20 > [Don] It does solve cases where dual homing aware PE-rs connect to = resilient Ethernet networks. This is a case worth solving because those = type of network usually have strict SLAs. The other cases where other = dual homing is outside of the of the PE-rs was covered for completeness. I think my sloppy use of =93in all cases=94 may have caused confusion. If instead I said "it is not clear to me whether optimised MAC flush is = superior in all failure scenarios=94, does that help clarify? >> For example, the new optimised MAC flush relies on the primary PE-rs = to detect the failure of the spoke PW and initiate the optimised MAC = flush but the document doesn't discuss what happens if the failure isn't = detected (e.g. if PE-rs doesn't detect the failure or PE-rs itself = fails). My assumption is that the network falls back to relying on = aging/timeout of MAC entries, which presumably means that traffic is = blackholed for up to 5 minutes (using default timers). > [Don] Yes as mentioned this is not the case this was designed for but = was described for completeness. I=92m not quite sure what you mean here (specifically what you mean by = =93case=94). Let me try and expand on my concern. With RFC4762, failure of the primary spoke PW causes the MTU-s to switch = traffic to the backup spoke PW, which results in packets being no longer = being forwarded to PE1-rs and instead being forwarded to PE3-rs (using = the labelling from Figure 1 of the document). On seeing packets suddenly arriving, PE3-rs can tell it is now the = primary PE-rs, and can initiate a MAC flush message to all other PE-rs. This doesn=92t rely on anything external, PE3-rs can determine just by = the appearance of packets on the PW that it is now the primary PE-rs for = that traffic. There=92s very little further to go wrong, except for the = possibility that PE3-rs does not initiate the MAC flush for some reason = and then the fallback is to ageing/timeout of MACs. With the optimised MAC flush, in order for the optimised MAC flush to = work, it relies on PE1-rs detecting the failure somehow and initiating = the optimised MAC flush. The optimised MAC flush isn=92t triggered by = PE3-rs suddenly seeing traffic anymore. Now if PE1-rs does=92t trigger = the optimised MAC flush for whatever reason (it didn=92t detect the PW = failed, PE1-rs itself fell over, etc) the fallback is to ageing/timeout = of MACs. Therefore my conclusion is that with RFC4762 the chance of having to = fallback to ageing MACs is pretty remote (basically just when there is a = badly borked implementation on PE3-rs). With optimised MAC flush there are several scenarios which could result = in PE1-rs not initiating the optimised MAC flush message for some reason = and so the network has to rely on ageing MACs in those cases. I think it=92s worth saying something about this.=20 >> It is also not clear whether this mechanism is designed to replace = the mechanism in RFC4627 or to augment it, although I have assumed the = former. > [Don] In a case where all nodes supported the optimized flush RFC4627 = would be used but for backwards compatibility the mechanism in RFC4627 = is recommended to be retained. >>=20 >> I therefore think that the document would benefit significantly from: >>=20 >> a) Some clear text/statement of when the new optimised MAC flush = mechanism should be used instead of the existing RFC4627 mechanism (e.g. = when is a full RFC4627 MAC flush "bad"). > [Don] OK I'll ask Adrian if he would like this highlighted. >>=20 >> b) Some discussion describing how the new optimised MAC flush = mechanism is equivalent to the existing mechanism and highlighting any = cases where it may not provide as rapid MAC table updates as the RFC4627 = mechanisms. > [Don] I don't think we should get into operational specifics of = timing. I know for a fact that the mechanism has been deployed in dual = homing aware networks with tight SLAs. Flushing traffic that is = unaffected is clearly undesirable. It really depends on the network = scenario where you are flushing MACs. PBB networks can have 1000s of = affected flows. I am not asking for operational specifics of timing. See above. >> Minor issues: >>=20 >> 1) The first paragraph of section 3 states: >>=20 >> When the MTU-s switches over to the backup PW, the requirement is to >> flush the MAC addresses learned in the corresponding Virtual Switch >> Instance (VSI) in peer PE devices participating in the full mesh, to >> avoid black holing of frames to those addresses. This is >> accomplished by sending an LDP Address Withdraw Message from the PE >> that is no longer connected to the MTU-s with the primary PW, with >> the list of MAC addresses to be removed to all other PEs over the >> corresponding LDP sessions [RFC4762]. >>=20 >> Comparing this against Figure 1, my understanding is that the "PE = that is no longer connected to the MTU-s with the primary PW" is PE1-rs. = However section 3.1.1 states: >>=20 >> [RFC4762] specifies that on failure of the primary PW, it is the >> PE3-rs (Figure 1) that initiates MAC flush towards the core. >>=20 >> Which contradicts the first paragraph of section 3? > [Don] I see your point here, is what is being described. > 1) PE-rs dual homing Aware > - Control of dual homing by the PE-RS <- This is 3.1.1 > - Control of dual homing by the MTUs <-This is 3. > 2) PE-Rs dual homing unaware. >=20 > [Don] It is up to you Ads & WG chairs to say if this should be = highlighted, I think it covers the cases and I can try make it clearer = as above if that helps. >>=20 >> I think that the first paragraph of section 3 is describing the = behaviour when using the new mechanism described in the draft, but that = wasn't clear to me when I first read the draft, so I would suggest = re-wording or adding some text to make it more explicit when you are = describing new behaviour specified in the document versus existing = behavior inherited from RFC4762. > [Don] The first part of section 3 is describing an existing RFC 4762 = message a positive flush by a MTU-s that is dual homing and in control = of the dual homing. However it is true that a MTU-s using LDP could use = the new procedures to propagate a flush to the PE-RS in the case of some = downstream Dual homing and that is not excluded. >>=20 >> 2) Section 3.2. I'm not sure what the significance of the native = ethernet segment is in this sentence "For example, the case of PE1-rs = initiated MAC flush on failure may arise when the dual-homing segment is = native ethernet as opposed to spoke PWs.". You may want to consider = stating what issue it is that the presence of native ethernet causes. > [Don] If the connection is MPLS then there are LDP control messages = that can propagate MAC status messages and if it is native Ethernet then = the PE-RS has to interpret the messages and convert them to the LDP = messages. I think that is all native Ethernet is trying to say but = there are multiple ways Ethernet can do that RSTP, G.8031 etc. >>=20 >> 3) Section 3.2 goes on to say "In this case the PE-rs devices >> that receive the MAC flush from PE1-rs are required to flush all the >> MAC addresses learned over the PW connected to PE1-rs. This cannot >> be achieved with the MAC Address Withdraw Message defined in >> [RFC4762]." >>=20 >> You may want to consider stating why MAC flush cannot be achieved = with the MAC Address Withdraw Message defined in RFC4762 (as the lack of = ability for performing MAC flush in this scenario is presumably the = motivation for defining the new MAC flush on failure mechanism in the = document?). > [Don] Reasons from the document are : > Many implementations use an LDP withdraw message with an empty MAC = list. (My interpretation is this is just the way it is.) > Section 3.2 states the rational for the MAC flush on failure. That = cannot be achieved with the RFC4762 message and procedures. >>=20 >> 4) Section 5.1.2 states >>=20 >> The MAC withdraw procedures defined in [RFC4762], MTU-s or PE2-rs >> SHOULD be sent in cases where the network is being upgraded and >> devices are not capable of understanding the optimized MAC flush. >> This would result in the same flushing action as [RFC4762] at the >> receiving PE-rs devices. >>=20 >> Which I am struggling to parse. Do you mean something along these = lines? >>=20 >> The MAC withdraw procedures defined in [RFC4762], where either >> MTU-s or PE2-rs send the MAC Withdrawl message SHOULD be used >> in cases where the network is being upgraded and devices are not >> capable of understanding the optimized MAC flush. >> This would result in the same flushing action as [RFC4762] at the >> receiving PE-rs devices. > [Don] Your text is better. This is the recommendation for backward = compatibility since there is no capabilities exchange. >>=20 >> 5) Section 5.1.2 states >>=20 >> For the case of B-VPLS devices optimized MAC flush message SHOULD be >> supported. >>=20 >> It's not clear to me what the purpose of this sentence is or what it = adds to the document. > [Don] It is historical. RFC 4762 VPLS preceded the deployment of PBB = B-VPLS. But B-VPLS was developed the same time as this draft and the = procures help in deployments where there are lots of I-SIDs . So the = recommendation is to use the optimization for PBB deployments. I=92d suggest stating something like that then instead of the current = sentence. The current SHOULD does=92t contribute to interoperability of = your mechanism, instead it is placing a requirement on devices to = implement your mechanism. That requirement carries no weight in reality = as it in unenforceable so I=92d suggest not using the SHOULD and just = stating what you want to say, e.g. something like: B-VPLS deployments = with lots of I-SIDs can also benefit from using the optimised MAC flush = mechanism specified in this document. >> 6) Section 5.1.4 states >>=20 >> This section explains the optimized MAC flush procedure in the >> scenario in Figure 2. When the primary spoke PW transition (failure >> or standby transition) is detected by PE1-rs, it MAY send MAC flush >> messages to PE2-rs, PE3-rs and PE4-rs with MAC Flush TLV and N =3D = 1. >>=20 >> Use of MAY here seems a bit strange to me. I may have misunderstood = but it seems to me that the document is proposing replacing the existing = MAC withdraw mechanisms with this new mechanism, but when using this new = mechanism sending the optimised MAC flush is only a MAY, so what happens = when PE1-rs doesn't send the optimised MAC flush? I assume the fallback = is aging/timeout of MAC entries, or is it that the previous MAC withdraw = mechanism is also being used? >=20 > [Don] How about: > When Optimized MAC flush is being used a PE-rs that is dual homing = aware SHOULD send MAC address messages with MAC Flush TLV and N=3D1 = provided the other PEs understand the new messages. WFM. Ben >> You may want to consider re-phrasing it along the lines of "When = optimised MAC flush is being used then " >>=20 >>=20 >> nits: >> 1) Section 4 states: >> This section describes the problems in detail with respective to >> various MAC flush actions described in section 2. >=20 > [Don] Yes s/2/3/ >> Section 2 is the terminology section and doesn't describe any MAC = flush actions, do you mean to reference section 3? >>=20 >> Also I'm not exactly sure what a MAC flush action is. I think you may = mean: >>=20 >> This section describes the problems in detail with respect to the >> various MAC flush scenarios described in section 3. >>=20 >> And I think you mean to use 'respect' rather than 'respective'. >>=20 >> 2) Section 4.1.1, penultimate paragraph says "In the example above, = only the MAC addresses in set X and Y need to be flushed across the = core." Y is not used in the text which confused me for a while until I = realised you were referring to Figure 2. You may want to consider making = that more explicit, for example: >>=20 >> In the example above, only the MAC addresses in set X and Y >> (shown in Figure 2) need to be flushed across the core. > [Don] Sure. >>=20 >> 3) Section 4.1.2 starts >>=20 >> The analysis in section 3.1.1 applies also to the native Ethernet >> access into a VPLS. >>=20 >> I think you may mean to reference section 4.1.1, not 3.1.1? >>=20 > [Don] I believe you are correct is accurate. Section 3 and section 4 = are roughly parallel a holdover from before I took over editing. >> 4) Section 5 states >>=20 >> This section describes the solution for the requirements described = in >> section 4. >>=20 >> Section 4 doesn't seem to list any requirements as such. Maybe = consider rewording to something like: >>=20 >> This section describes a solution for the problem space described in >> section 4. > [Don] I like your suggestion. >>=20 >> 5) Section 5.1 states >>=20 >> The optimization is achieved by >> initiating MAC Flush on failure as described in section 2.2. >>=20 >> and >>=20 >> The MAC Flush TLV can also >> be used for [RFC4762] style of MAC Flush as explained in section 2. >>=20 >> I think you mean section 3.2 and section 3 respectively. > [Don] Yes I think we switched section 3 and section 2 and forgot the = reference. No smart tags just me. >>=20 >> 6) Section 5.1.1 & 5.1.2 cross-reference section 4.2 for details of = its usage in PBB-VPLS but I think you mean to cross-reference section = 5.2. > [Don] Changed 4.2 is not completely wrong but 5.2 gives more usage = notes. I'm tempted to reference both but I've change to 5.2. >>=20 >> 7) Section 5.1.2, 5.1.3 & 5.2.2 cross-references section 5 for = operational considerations but I think you mean to cross-reference = section 6. > [Don] Yes. >>=20 >> Regards >> Ben >>=20 >=20 > From nobody Tue Apr 8 06:25:59 2014 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 78C8B1A03D4 for ; Tue, 8 Apr 2014 06:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 V9v9iIXhuaig for ; Tue, 8 Apr 2014 06:25:54 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2FDCF1A03D1 for ; Tue, 8 Apr 2014 06:25:53 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id rp16so1019243pbb.31 for ; Tue, 08 Apr 2014 06:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=2Pe5tF+AJ7JVwuoTztMrfaD9dQYoVYsMM2VWOjPI8Yg=; b=GRyCXrEhtBedoswqn3XP5gswrT6UbJc6WJQ7WnY+O2q9sGhtNp4H1teVW4CUa76aT3 1H3Z1gr+48hMBRHeaoCAtKU50DRocSArFOcjslKXMlpqJcHQU2REL7clE9WMWF0y8r8H a8cxDnoP4qfq0s9hZsjDOOXZRWtha8ywL/tAiyxSePheZ8J9/V3bSBPQiQhxhFiUqh4c wIUF63m7wtt8LiTyrQ85iwOeQ6adxzdYAD0a4b+z7++sNLH2p1OrPsOKYtl+WeUsCXsV dBB4VEVDXwQ4AOVf/+A9tlR/4iy+9bTgDytBRjEItwJkWDroSFniXUQ2zu9YnC3CzjB4 YqFA== X-Received: by 10.66.66.66 with SMTP id d2mr4719266pat.24.1396963553210; Tue, 08 Apr 2014 06:25:53 -0700 (PDT) Received: from LizhongPC ([114.62.223.166]) by mx.google.com with ESMTPSA id cz3sm4680941pbc.9.2014.04.08.06.25.42 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 08 Apr 2014 06:25:52 -0700 (PDT) From: "Lizhong Jin" To: , References: <0aaa01cf45f0$7d04ae00$770e0a00$@olddog.co.uk> <53345952.a70e440a.2a29.4f84@mx.google.com> <016601cf4c50$078c8ce0$16a5a6a0$@olddog.co.uk> <011e01cf4cf0$28349370$789dba50$@gmail.com> In-Reply-To: <011e01cf4cf0$28349370$789dba50$@gmail.com> Subject: RE: AD review of draft-ietf-l2vpn-vpls-inter-domain-redundancy Date: Tue, 8 Apr 2014 21:25:39 +0800 Message-ID: <5343f8e0.a3b2440a.7ee6.ffffccc6@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQKieMH6bvwQq0oDr/K5WljRkwwysgG2FEXSAieGbsoB5zRVRZkzQqzQ Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/jQdOlSZp7e1PoqqaH7sB6LtmfsQ Cc: l2vpn@ietf.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: Tue, 08 Apr 2014 13:25:58 -0000 Hi Adrian, The draft authors suggest to separate "security" section into = "management" and "security", and the new content is as below. Are you OK = with the following changes? 6. Management Considerations When deploying the inter-domain redundancy mechanism described in this document, some manual operation/negotiation is required to be done correctly and securely. E.g., each node within one RG should be configured with same redundancy mode; the two operators should negotiate to configure same PW priority at two nodes. If the configuration consistency is broken, the inter-domain redundancy mechanism may not work properly. 7. Security Considerations Besides the security properties of [I-D.ietf-pwe3-iccp], [RFC4762] and [RFC6870], this document will have additional security consideration. ICCP is now deployed between two PEs or ASBRs, the two PEs or ASBRs should be connected by a well managed and highly monitored network. The LDP session could be secured with TCP Authentication Option [RFC5925]. This provides integrity and authentication for the ICCP messages. The LDP MD5 authentication key option, as described in section 2.9 of [RFC5036] MAY also be used. The attention of implementers and deployers is drawn to [RFC6941] and [RFC6952] with special attention to the recommendation to use TCP-AO [RFC5925] for enhanced security of LDP sessions. The activitiy on the inter-domain and intra-domain pseudowire may cause security threats or be exploited to create denial of service attackes. Excessive pseudowire state flapping (e.g., by malicious peer PE's implementation) may lead to excessive ICCP exchanges. Implementations SHOULD provide mechanisms to perform control-plane policing and mitigate such types of attacks. Regards Lizhong > -----Original Message----- > From: Lizhong Jin [mailto:lizho.jin@gmail.com] > Sent: Monday, March 31, 2014 10:47 PM > To: adrian@olddog.co.uk; draft-ietf-l2vpn-vpls-inter-domain- > redundancy.all@tools.ietf.org > Cc: l2vpn@ietf.org > Subject: RE: AD review of = draft-ietf-l2vpn-vpls-inter-domain-redundancy >=20 > Hi Adrian, > Thank you for the quick reply. See my reply inline below. > We will post a new version accordingly soon to reflect these comments. >=20 > Regards > Lizhong >=20 > > -----Original Message----- > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > Sent: 2014=E5=B9=B43=E6=9C=8831=E6=97=A5 3:41 > > To: 'Lizhong Jin'; draft-ietf-l2vpn-vpls-inter-domain- > > redundancy.all@tools.ietf.org > > Cc: l2vpn@ietf.org > > Subject: RE: AD review of draft-ietf-l2vpn-vpls-inter-domain- > redundancy > > > > Hi Lizhong, > > > > > Sorry for the late reply. Please see my reply inline below. > > > Please co-authors help to correct if I am wrong. > > > > [snip] > > > > > > I can't see how this is a BCP. I realise that RFC 2026 section 5 > is > > > > not really clearly written, but this is a technical spec that > > > > describes how to build a particular function in the network. > > > > Standards Track would be just fine (even though there are no = bits > > > > and bytes defined) because you are defining procedures (using > 2119 > > > > language) that an implementation has to perform to make this > function > > work (i.e., interoperate). > > > > > > [Lizhong] thank you for pointing out this. We will change to > Standards > > > Track. > > > > Good. I hope the WG is paying attention! > [Lizhong] OK, we will post a new version accordingly. >=20 > > > > > > Section 1 > > > > > > > > Please give a little more information about what the "solution" > is. > > > > You don't need to go into full detail, but you do need to give > some > > > > overview. Things I'd like to see covered... > > > > - motivation is to provide service protection mechanisms in the > event > > > > of edge node failure > > > > - basic mechanism is to provide edge node redundancy > > > > - solution is dependent on the use of ICCP (with reference) to > > > > coordinate between redundant edge nodes > > > > - no changes to any protocol message formats are needed for this > > > > solution and no new protocol options are defined > > > > - this solution is a description of how existing protocol > building > > > > blocks may be deployed to achieve the desired function, but > also > > > > defines implementation behavior necessary for the function to > work. > > > [Lizhong] accepted, and I try to rephrase as below: > > > In many existing Virtual Private LAN Service (VPLS) deployments > based > > > on [RFC4762], inter-domain connectivity has been deployed without > node > > > redundancy, or with node redundancy in a single domain. This > document > > > is to provide a service protection mechanism for inter-domain VPLS > > > based on [RFC4762]. The protection mechanism will provide edge = node > > > redundancy and link redundancy in both domains. The domain in = this > > > document refers to autonomous system (AS), or other administrative > > domains. > > > The solution relies on the use of ICCP [ietf-pwe3-iccp] to > coordinate > > > between redundant edge nodes, and use of Pseudowire (PW) > Preferential > > > Forwarding Status Bit [RFC 6870] to negotiate the PW status. There > is > > > no change to any protocol message formats and no new protocol > options > > > introduced. This solution is a description of reusing existing > > > protocol building blocks to achieve the desired function, but also > > > defines implementation behavior necessary for the function to = work. > > > > Works for me. > [Lizhong] Thanks. > > > > [snip] > > > > > > Figure 2 might usefully be redrawn to show how PW3 and PW4 = attach > to > > > > the PEs. > > > [Lizhong] do you mean the PW is broken to the PE in the figure? > Will fix > > > that. > > > Thanks. > > > > Yeah. PW3 should connect to PE3 etc. > [Lizhong] Thanks. > > > > > > Section 5 says > > > > > > > > For the inter-domain four-PW scenario, > > > > it is required for PEs to ensure that the same mode is > supported on > > > > the two ICCP peers in the same redundancy group (RG). > > > > > > > > But you don't say how this is achieved. > > > [Lizhong] will add: One method to ensure mode consistency is by > manual > > > operation. Other methods are also possible and is out of the scope > of > > > this document. > > > > I'm OK with that, but it is a bit thin. Operators are famous for not > > configuring > > the same thing at two ends of a link. > [Lizhong] I understand. At current stage, let's keep it simple. >=20 > > > > > > Section 5.2 > > > > > > > > Before > > > > deploying this inter-domain VPLS, the operators MUST = negotiate > to > > > > configure same PW high/low priority at two PW end-points. > > > > > > > > How do they do this? > > > [Lizhong] we check this with the operator. When they do inter-AS > > > connection, there will be some kind of contract to ensure the > > > interconnection. The PW priority could be one part of the > > > contract/negotiation. This is more of the operation method. Now I > think > > > we > > should not use RFC2119 word "MUST" here. > > > "should" would be a better word here. > > > > Yup, "should" is better, and maybe add "The inter-domain VPLS > relationship > > normally involves a contractual process between operators, and the > > configuration of PW roles forms part of this process." > [Lizhong] OK, thanks. >=20 > > > > > > Section 5.3 > > > > > > > > In this use case, there are generally three options > > > > > > > > So, sometimes two options and sometimes four options? :-) Delete > > > > "generally", but also make clear what the three options are. > > > [Lizhong] it would be clear to say: In this use case, there are = two > > > options to provide protection: 1:1 and 3:1 protection. > > > > OK > > > > [snip] > > > > > > Section 6 > > > > > > > > There seem to be some independent actions needed (operator > > > > negotiation, setting of mode). Are these security = vulnerabilities? > > > > > > > > ICCP is being run on the Internet and not in a chassis. Does = that > > > > make a difference to the security model? > > > [Lizhong] yes, more consideration is required. I try to change: > > > Besides of the security properties of [I-D.ietf-pwe3-iccp] and > > > [RFC4762], this draft will have additional security consideration. > > > When deploying the inter-domain redundancy mechanism described in > this > > > document, some manual operation/negotiation is required to be done > > > correctly and securely. E.g., each node within one RG should be > > > configured with same redundancy mode; the two operators should > > > negotiate to configure same PW priority at two nodes. If the > > > configuration consistency is broken, the inter-domain redundancy > > mechanism may not work properly. > > > Since ICCP is now deployed between two PEs or ASBRs, the LDP > session > > > could be secured with TCP Authentication Option [RFC5925]. This > > > provides integrity and authentication for the ICCP messages. The > LDP > > > MD5 authentication key option, as described in section 2.9 of > [RFC5036] > > MAY also be used. > > > > That is good except that MD5 is pretty much regarded as useless as a > > security > > tool these days. > > > > How about adding to the end of your text: > > > > "The attention of implementers and deployers is drawn to [RFC6941] > and > > [RFC6952] with special attention to the recommendation to use TCP-AO > > [RFC5925] for enhanced security of LDP sessions." > [Lizhong] OK, thanks. >=20 > > > > Cheers, > > Adrian > > From nobody Thu Apr 10 03:45:26 2014 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 9453F1A01D3 for ; Thu, 10 Apr 2014 03:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 n_zCM1p-vjPf for ; Thu, 10 Apr 2014 03:45:22 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 516131A01BB for ; Thu, 10 Apr 2014 03:45:22 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3AAjJpk017266; Thu, 10 Apr 2014 11:45:19 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3AAjHHH017246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Apr 2014 11:45:18 +0100 From: "Adrian Farrel" To: "'Lizhong Jin'" , References: <0aaa01cf45f0$7d04ae00$770e0a00$@olddog.co.uk> <53345952.a70e440a.2a29.4f84@mx.google.com> <016601cf4c50$078c8ce0$16a5a6a0$@olddog.co.uk> <011e01cf4cf0$28349370$789dba50$@gmail.com> <5343f8e0.a3b2440a.7ee6.ffffccc6@mx.google.com> In-Reply-To: <5343f8e0.a3b2440a.7ee6.ffffccc6@mx.google.com> Subject: RE: AD review of draft-ietf-l2vpn-vpls-inter-domain-redundancy Date: Thu, 10 Apr 2014 11:45:18 +0100 Message-ID: <028901cf54a9$f7634cc0$e629e640$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKieMH6bvwQq0oDr/K5WljRkwwysgG2FEXSAieGbsoB5zRVRQLDIuM8mSAiM8A= Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20622.006 X-TM-AS-Result: No--37.343-10.0-31-10 X-imss-scan-details: No--37.343-10.0-31-10 X-TMASE-MatchedRID: a6VsEHZT/ZFDZFBd1jLr/rxygpRxo469t3aeg7g/usAiFs20Vxq/wrmR LdJVdEm/YKXU5x6vEGPkkTbfp2U50xyCaonaIG/AuIwLnB3Aqp0rHkgIan9a0WsSgW01iDQLvL4 BuAuBsSlvFeXz/P2+wkGsUll38aASMZpnc+6w+DTuykw7cfAoIG5N71UY7eq8uSIn8GC9fqs+mZ LuHsKcOpdEQabRybjEkfogCiAqT001cvnM9phj4RokisCyVCexzDlraXs8h+ZQnnYsWF8zq2pVo /joOvwExCwuvsHRtIQ7V2y6PpJnIrvuuksuYzsCZwDJZynfzStGvA4S70GhMmgT9IdN4mUOuaes YH+TAYxT7gKktTs+watVlfc245o23XkI6jWXY3RswYo64ufkVX4rryovYbmme+xt+hmLFRM4OJj GEod9DbNPCp/BU1u8R0SKTnZYmfsTCPmEbq0xeG/+RwWenb0YviRliDV2nywY0A95tjAn+7JVv1 3dZNfHPjmw6VWAfsbiXn352PuYAW94Ipa1otxohDqIQb7sQecT1RzDMx9VmLKeTtOdjMy6N/IPg HUHVfDwM1lgED/qJxgaZOJZCVBCa6E59IxHGX9+7IhLVmN+u3tjaUnUUncdInzOyTDR1uvLw0Kh HW39TeyXzLxaAGeG6B07gBpHiv1XKLar1IWcqlz+axQLnAVB2D/7bUIJlF1PtLhlThdPEFdWJfE qbx6MFLfDUO9Th15FcQlq8WbRMKwUHwBRC6Ff9Ib/6w+1lWRaCvPATPKcuU+u8oS4XkKMIiLw+j kqZLJ1yrGmWl5vjG5MrjdTavzWy6Bb6HVNE6aeAiCmPx4NwFkMvWAuahr8ooPRqITj5zirusVRy 4an8bxAi7jPoeEQftwZ3X11IV0= Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/8ci6bVL169O350I6ChfihuBA_gI Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 10:45:25 -0000 Yes, good job. Please post it. Adrian > -----Original Message----- > From: Lizhong Jin [mailto:lizho.jin@gmail.com] > Sent: 08 April 2014 14:26 > To: adrian@olddog.co.uk; draft-ietf-l2vpn-vpls-inter-domain- > redundancy.all@tools.ietf.org > Cc: l2vpn@ietf.org > Subject: RE: AD review of = draft-ietf-l2vpn-vpls-inter-domain-redundancy >=20 > Hi Adrian, > The draft authors suggest to separate "security" section into = "management" and > "security", and the new content is as below. Are you OK with the = following > changes? >=20 > 6. Management Considerations >=20 > When deploying the inter-domain redundancy mechanism described in > this document, some manual operation/negotiation is required to be > done correctly and securely. E.g., each node within one RG should = be > configured with same redundancy mode; the two operators should > negotiate to configure same PW priority at two nodes. If the > configuration consistency is broken, the inter-domain redundancy > mechanism may not work properly. >=20 >=20 > 7. Security Considerations >=20 > Besides the security properties of [I-D.ietf-pwe3-iccp], [RFC4762] > and [RFC6870], this document will have additional security > consideration. >=20 > ICCP is now deployed between two PEs or ASBRs, the two PEs or ASBRs > should be connected by a well managed and highly monitored network. > The LDP session could be secured with TCP Authentication Option > [RFC5925]. This provides integrity and authentication for the ICCP > messages. The LDP MD5 authentication key option, as described in > section 2.9 of [RFC5036] MAY also be used. >=20 > The attention of implementers and deployers is drawn to [RFC6941] = and > [RFC6952] with special attention to the recommendation to use = TCP-AO > [RFC5925] for enhanced security of LDP sessions. >=20 > The activitiy on the inter-domain and intra-domain pseudowire may > cause security threats or be exploited to create denial of service > attackes. Excessive pseudowire state flapping (e.g., by > malicious peer PE's implementation) may lead to excessive ICCP > exchanges. Implementations SHOULD provide mechanisms to perform > control-plane policing and mitigate such types of attacks. >=20 > Regards > Lizhong >=20 > > -----Original Message----- > > From: Lizhong Jin [mailto:lizho.jin@gmail.com] > > Sent: Monday, March 31, 2014 10:47 PM > > To: adrian@olddog.co.uk; draft-ietf-l2vpn-vpls-inter-domain- > > redundancy.all@tools.ietf.org > > Cc: l2vpn@ietf.org > > Subject: RE: AD review of = draft-ietf-l2vpn-vpls-inter-domain-redundancy > > > > Hi Adrian, > > Thank you for the quick reply. See my reply inline below. > > We will post a new version accordingly soon to reflect these = comments. > > > > Regards > > Lizhong > > > > > -----Original Message----- > > > From: Adrian Farrel [mailto:adrian@olddog.co.uk] > > > Sent: 2014=E5=B9=B43=E6=9C=8831=E6=97=A5 3:41 > > > To: 'Lizhong Jin'; draft-ietf-l2vpn-vpls-inter-domain- > > > redundancy.all@tools.ietf.org > > > Cc: l2vpn@ietf.org > > > Subject: RE: AD review of draft-ietf-l2vpn-vpls-inter-domain- > > redundancy > > > > > > Hi Lizhong, > > > > > > > Sorry for the late reply. Please see my reply inline below. > > > > Please co-authors help to correct if I am wrong. > > > > > > [snip] > > > > > > > > I can't see how this is a BCP. I realise that RFC 2026 section = 5 > > is > > > > > not really clearly written, but this is a technical spec that > > > > > describes how to build a particular function in the network. > > > > > Standards Track would be just fine (even though there are no = bits > > > > > and bytes defined) because you are defining procedures (using > > 2119 > > > > > language) that an implementation has to perform to make this > > function > > > work (i.e., interoperate). > > > > > > > > [Lizhong] thank you for pointing out this. We will change to > > Standards > > > > Track. > > > > > > Good. I hope the WG is paying attention! > > [Lizhong] OK, we will post a new version accordingly. > > > > > > > > > > Section 1 > > > > > > > > > > Please give a little more information about what the = "solution" > > is. > > > > > You don't need to go into full detail, but you do need to give > > some > > > > > overview. Things I'd like to see covered... > > > > > - motivation is to provide service protection mechanisms in = the > > event > > > > > of edge node failure > > > > > - basic mechanism is to provide edge node redundancy > > > > > - solution is dependent on the use of ICCP (with reference) to > > > > > coordinate between redundant edge nodes > > > > > - no changes to any protocol message formats are needed for = this > > > > > solution and no new protocol options are defined > > > > > - this solution is a description of how existing protocol > > building > > > > > blocks may be deployed to achieve the desired function, but > > also > > > > > defines implementation behavior necessary for the function = to > > work. > > > > [Lizhong] accepted, and I try to rephrase as below: > > > > In many existing Virtual Private LAN Service (VPLS) deployments > > based > > > > on [RFC4762], inter-domain connectivity has been deployed = without > > node > > > > redundancy, or with node redundancy in a single domain. This > > document > > > > is to provide a service protection mechanism for inter-domain = VPLS > > > > based on [RFC4762]. The protection mechanism will provide edge = node > > > > redundancy and link redundancy in both domains. The domain in = this > > > > document refers to autonomous system (AS), or other = administrative > > > domains. > > > > The solution relies on the use of ICCP [ietf-pwe3-iccp] to > > coordinate > > > > between redundant edge nodes, and use of Pseudowire (PW) > > Preferential > > > > Forwarding Status Bit [RFC 6870] to negotiate the PW status. = There > > is > > > > no change to any protocol message formats and no new protocol > > options > > > > introduced. This solution is a description of reusing existing > > > > protocol building blocks to achieve the desired function, but = also > > > > defines implementation behavior necessary for the function to = work. > > > > > > Works for me. > > [Lizhong] Thanks. > > > > > > [snip] > > > > > > > > Figure 2 might usefully be redrawn to show how PW3 and PW4 = attach > > to > > > > > the PEs. > > > > [Lizhong] do you mean the PW is broken to the PE in the figure? > > Will fix > > > > that. > > > > Thanks. > > > > > > Yeah. PW3 should connect to PE3 etc. > > [Lizhong] Thanks. > > > > > > > > Section 5 says > > > > > > > > > > For the inter-domain four-PW scenario, > > > > > it is required for PEs to ensure that the same mode is > > supported on > > > > > the two ICCP peers in the same redundancy group (RG). > > > > > > > > > > But you don't say how this is achieved. > > > > [Lizhong] will add: One method to ensure mode consistency is by > > manual > > > > operation. Other methods are also possible and is out of the = scope > > of > > > > this document. > > > > > > I'm OK with that, but it is a bit thin. Operators are famous for = not > > > configuring > > > the same thing at two ends of a link. > > [Lizhong] I understand. At current stage, let's keep it simple. > > > > > > > > > > Section 5.2 > > > > > > > > > > Before > > > > > deploying this inter-domain VPLS, the operators MUST = negotiate > > to > > > > > configure same PW high/low priority at two PW end-points. > > > > > > > > > > How do they do this? > > > > [Lizhong] we check this with the operator. When they do inter-AS > > > > connection, there will be some kind of contract to ensure the > > > > interconnection. The PW priority could be one part of the > > > > contract/negotiation. This is more of the operation method. Now = I > > think > > > > we > > > should not use RFC2119 word "MUST" here. > > > > "should" would be a better word here. > > > > > > Yup, "should" is better, and maybe add "The inter-domain VPLS > > relationship > > > normally involves a contractual process between operators, and the > > > configuration of PW roles forms part of this process." > > [Lizhong] OK, thanks. > > > > > > > > > > Section 5.3 > > > > > > > > > > In this use case, there are generally three options > > > > > > > > > > So, sometimes two options and sometimes four options? :-) = Delete > > > > > "generally", but also make clear what the three options are. > > > > [Lizhong] it would be clear to say: In this use case, there are = two > > > > options to provide protection: 1:1 and 3:1 protection. > > > > > > OK > > > > > > [snip] > > > > > > > > Section 6 > > > > > > > > > > There seem to be some independent actions needed (operator > > > > > negotiation, setting of mode). Are these security = vulnerabilities? > > > > > > > > > > ICCP is being run on the Internet and not in a chassis. Does = that > > > > > make a difference to the security model? > > > > [Lizhong] yes, more consideration is required. I try to change: > > > > Besides of the security properties of [I-D.ietf-pwe3-iccp] and > > > > [RFC4762], this draft will have additional security = consideration. > > > > When deploying the inter-domain redundancy mechanism described = in > > this > > > > document, some manual operation/negotiation is required to be = done > > > > correctly and securely. E.g., each node within one RG should be > > > > configured with same redundancy mode; the two operators should > > > > negotiate to configure same PW priority at two nodes. If the > > > > configuration consistency is broken, the inter-domain redundancy > > > mechanism may not work properly. > > > > Since ICCP is now deployed between two PEs or ASBRs, the LDP > > session > > > > could be secured with TCP Authentication Option [RFC5925]. This > > > > provides integrity and authentication for the ICCP messages. The > > LDP > > > > MD5 authentication key option, as described in section 2.9 of > > [RFC5036] > > > MAY also be used. > > > > > > That is good except that MD5 is pretty much regarded as useless as = a > > > security > > > tool these days. > > > > > > How about adding to the end of your text: > > > > > > "The attention of implementers and deployers is drawn to [RFC6941] > > and > > > [RFC6952] with special attention to the recommendation to use = TCP-AO > > > [RFC5925] for enhanced security of LDP sessions." > > [Lizhong] OK, thanks. > > > > > > > > Cheers, > > > Adrian > > > From nobody Thu Apr 10 07:48:51 2014 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 9046F1A0294; Thu, 10 Apr 2014 07:48:48 -0700 (PDT) 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 nbBkvnUXxuvZ; Thu, 10 Apr 2014 07:48:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83F4D1A01AD; Thu, 10 Apr 2014 07:48:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l2vpn-vpls-inter-domain-redundancy-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.2.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140410144839.1998.71039.idtracker@ietfa.amsl.com> Date: Thu, 10 Apr 2014 07:48:39 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/sjiFxo0Pp7IrC0kUhxPPyw1R_mE 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: Thu, 10 Apr 2014 14:48:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : Redundancy provisioning for VPLS Inter-domain Authors : Zhihua Liu Lizhong Jin Ran Chen Dennis Cai Samer Salam Filename : draft-ietf-l2vpn-vpls-inter-domain-redundancy-05.txt Pages : 12 Date : 2014-04-10 Abstract: In many existing Virtual Private LAN Service (VPLS) deployments based on RFC 4762, inter-domain connectivity has been deployed without node redundancy, or with node redundancy in a single domain. This document describes a solution for inter-domain VPLS based on RFC 4762 with node and link redundancy in both domains. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-vpls-inter-domain-redundancy/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-inter-domain-redundancy-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-l2vpn-vpls-inter-domain-redundancy-05 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 nobody Thu Apr 10 09:02:54 2014 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 6F1181A02E0; Thu, 10 Apr 2014 09:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.2 X-Spam-Level: X-Spam-Status: No, score=-99.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 PskJGs18CGEJ; Thu, 10 Apr 2014 09:02:49 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 9757C1A02D1; Thu, 10 Apr 2014 09:02:49 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3AG2YHu000964; Thu, 10 Apr 2014 17:02:34 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3AG2XOx000958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Apr 2014 17:02:33 +0100 From: "Adrian Farrel" To: "'Fedyk, Don'" , "'Ben Niven-Jenkins'" , References: In-Reply-To: Subject: RE: RtgDir review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt Date: Thu, 10 Apr 2014 17:02:33 +0100 Message-ID: <031e01cf54d6$496516d0$dc2f4470$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH+AHmJeatBe0KR/K3XXWNXppdEMAGodTO8AiQoiKaaj0RkUA== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20624.000 X-TM-AS-Result: No--6.690-10.0-31-10 X-imss-scan-details: No--6.690-10.0-31-10 X-TMASE-MatchedRID: 6otD/cJAac0tqx4vLVZ3FppWgCLYjjT9NACnndLvXweCsBeCv8CM/RZ0 n9DHfDteqthi32DRSIKtmu58TYSSJekOZa3OWbiWTQh9A4m9EtHh04vhNT6Pi6MVwpOQMj2MowO jF+MaCNgHyVe0cM3K0c2O30xxOFFQGjqKL+SYU9X5WZT2GFh+nbYxxljjfMnjd71AOvz4tNyaD4 6neqGHJAY+dsqE8cvNJ+6k856T1ST9k2nJXxNdGn6DQ2TEDqZs1kqyrcMalqUXzqHaBURjrBjbR /XCsHXWDiTX4NL90becUEZb1VcLPl2zdiRYF6EuHcQQBuf4ZFueimGtNywjtpsoi2XrUn/JyeMt MD9QOgDGlDvsLUDW2o6HM5rqDwqtsRCKU4TxQuAiV7UYA8luTzSZX4BvfCMKsWxOSccJX9wG4fU CBdx/dA== Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/hqNkBi6VG1Uy2Lz0HAQmNYyq4eg Cc: l2vpn@ietf.org, rtg-dir@ietf.org, draft-ietf-l2vpn-vpls-ldp-mac-opt.all@tools.ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 16:02:51 -0000 Hi Don, [snip] > > a) Some clear text/statement of when the new optimised MAC flush > mechanism should be used instead of the existing RFC4627 mechanism (e.g. > when is a full RFC4627 MAC flush "bad"). > [Don] OK I'll ask Adrian if he would like this highlighted. I think that would be valuable to include (and am embarrassed to have not picked up on it myself). Essentially, you are introducing an option: new flush mechanism or old flush mechanism. You should help implementers decide which to use. Might be as simple as "always" or might be some other issues. [snip] > > 1) The first paragraph of section 3 states: > > > > When the MTU-s switches over to the backup PW, the requirement is to > > flush the MAC addresses learned in the corresponding Virtual Switch > > Instance (VSI) in peer PE devices participating in the full mesh, to > > avoid black holing of frames to those addresses. This is > > accomplished by sending an LDP Address Withdraw Message from the PE > > that is no longer connected to the MTU-s with the primary PW, with > > the list of MAC addresses to be removed to all other PEs over the > > corresponding LDP sessions [RFC4762]. > > > > Comparing this against Figure 1, my understanding is that the "PE that is no > longer connected to the MTU-s with the primary PW" is PE1-rs. However section > 3.1.1 states: > > > > [RFC4762] specifies that on failure of the primary PW, it is the > > PE3-rs (Figure 1) that initiates MAC flush towards the core. > > > > Which contradicts the first paragraph of section 3? > [Don] I see your point here, is what is being described. > 1) PE-rs dual homing Aware > - Control of dual homing by the PE-RS <- This is 3.1.1 > - Control of dual homing by the MTUs <-This is 3. > 2) PE-Rs dual homing unaware. > > [Don] It is up to you Ads & WG chairs to say if this should be highlighted, I think it > covers the cases and I can try make it clearer as above if that helps. My general rule of thumb is that if a reasonably smart reader has questions arising from the text, clarifying the text is worthwhile. Maybe that some pointers as highlighted would cover the case. [snip] Thanks, Adrian From nobody Thu Apr 10 09:12:58 2014 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 121651A0289; Thu, 10 Apr 2014 09:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, USER_IN_WHITELIST=-100] 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 hdXmW-Dz-JZW; Thu, 10 Apr 2014 09:12:54 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABE31A01FF; Thu, 10 Apr 2014 09:12:53 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3AGCpBa028824; Thu, 10 Apr 2014 17:12:52 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id s3AGCova028807 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 10 Apr 2014 17:12:51 +0100 From: "Adrian Farrel" To: "'Robert Sparks'" , "'General Area Review Team'" , , References: <5342FF4F.4040906@nostrum.com> In-Reply-To: <5342FF4F.4040906@nostrum.com> Subject: RE: Gen-art LC review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11 Date: Thu, 10 Apr 2014 17:12:51 +0100 Message-ID: <031f01cf54d7$b9432180$2bc96480$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJXXrgC05DloNvZAOm6v9OnzzYQ25n68DpQ Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1017-20624.000 X-TM-AS-Result: No--20.850-10.0-31-10 X-imss-scan-details: No--20.850-10.0-31-10 X-TMASE-MatchedRID: cxtZ8fwm3r+nykMun0J1wvAjkTMkRNNUkclKpZaEedradW4iYSMjUeO7 Q9MS0NLni4zi2tMdmf5/129x0+dDBxME5sXUqWznbMGKOuLn5FU7Uh8Mo43jSVMnnsDzMI/0AMN ZJLKWqgY8ivFkadaiTVJ0nehpZ2rrXV8zTKunnsn7/v/5alNYetRmti/O6j0CRJWmeOMHa+SlQa x3ye0WRV0+aUSxlEKolCdkhztc19MmH3w4SvLIydjko+KiQPUGVo4lwLFUdisxCa3oFeZrRXLOA PNCmmpA8MaosETR+4LwIQ8TEKBvAHZ4WhytKCEOiUPZPmKZOQmWesyrtKuK7fgnJH5vm2+g33pz MsMDyh+4iy5ozcFtGbi4+LWAODipFDysHLls3CSGwT67eecJ8PDYQQsX+kfDN/M32cK+fkhpRez oWC5XLY7b6FbuI0+YDmIE4Tvg5l9bmMYrRJDeAk+4wmL9kCTxy1y/jIuoZZ4nFcnAoAp5r9V2ks C4+totJRrVLqjmxpfxeKURfJizjF/wr9J3woyTbD4iYfbCo2ND3kXYiJVSRKJpFCjCjSYrF5ZRT dcETVTi8zVgXoAltlwtzewu2M63VkVZa47CjvDdB/CxWTRRuyUIayx+Skid Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/pQ1zq_GbuzWwFiZY1QCDchiR9Po X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Apr 2014 16:12:56 -0000 Thanks Robert, Will be interested to hear author/shepherd responses to this. Adrian > -----Original Message----- > From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Robert Sparks > Sent: 07 April 2014 20:41 > To: General Area Review Team; draft-ietf-l2vpn-vpls-ldp-mac-opt@tools.ietf.org; > l2vpn@ietf.org > Subject: Gen-art LC review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11 > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > . > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-l2vpn-vpls-ldp-mac-opt-11 > Reviewer: Robert Sparks > Review Date: 7Apr2014 > IETF LC End Date: 8Apr2014 > IESG Telechat date: not yet scheduled > > Summary: This draft is almost ready for publication as a Proposed > Standard, but has minor issues (primarily editorial) that should be > addressed. > > I found this document very difficult to read. It asks the reader to hop > between sections in unusual ways (for instance, it sends the reader to > the problem statement section for details on normative behavior). I > strongly encourage an editorial pass focusing on document structure. > > There are many instances of SHOULD in the document where the text should > just be using prose instead. It's not always clear when an > implementation would choose to ignore the SHOULD, and what the > consequences of that choice would be. > > The document is inconsistent about the level of support needed in the > network before trying to use this extension. > Section 5.1.2 says the assumption is everything understands it before > it's turned on. Section 6 points back to figure 2 and says > to use the extension over the pw where you administratively know the > peer supports the extension, and fall back to 4762 for > everything else. Which of those did you intend? > > Specific comments in document order: > > Section 3.2 paragraph 1: This paragraph would benefit from being broken > into several. It's hard to find its point. The SHOULD in this paragraph > is probably not a 2119 SHOULD (this section isn't defining the > protocol). It would be useful in this overview to explicitly say _why_ > "This cannot be achieved with ... 4762]" at this point in the document. > > Section 3.2 paragraph 2: This SHOULD _is_ defining protocol - shouldn't > it be in section 5? > > Section 4.1.1 paragraph 3: It took me some time to find Z on the figure. > It might help to introduce it similar to how you introduce X. > > Section 4.1.2: paragraph 1: I think you meant to reference 4.1.1 > > Section 5: The first sentence talks about requirements in section 4. > Section 4 describes a problem using some examples but doesn't explicitly > call out requirements. Doing so would help the document. > > Last sentence in 5.1.1 (and several other places in the document): > Please add an article before "MAC Flush message". (I apologize for such > a small nit, but each of these instances made making sure I was reading > what the sentence intended significantly more difficult). > > Section 5.1.2 first paragraph: This section is defining behavior - why > are you sending the reader back into the problem statement for detail on > the behavior? > > 5.1.2 paragraph 2: You meant section 6, not 5. > > 5.1.2 paragraph 3: I can't follow this paragraph's structure. I think > you're trying to say "An MTU-s or PE2-rs SHOULD send MAC withdraw > messages as defined in [RFC4762] in cases where the network is being > upgraded and devices are not capable of understanding the optimized MAC > flush." (But if so, the next sentence is redundant.) Why is this SHOULD? > > 5.1.3 paragraph 1: Why is this a SHOULD and not a MUST? (Similar > question for the SHOULD in paragraph 2). It's not clear if you're trying > to avoid "Some things won't implement this spec" or "Don't do this if > you haven't administratively ensured every element understands this > extension first" or something else? > > 5.1.3 paragraph 3: You say "unless specified otherwise". Do you ever > specify otherwise? Why is this disclaimer here? > > 5.1.3 last paragraph: You meant section 6 not 5. > > > From nobody Thu Apr 10 09:25:51 2014 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 C59991A030B; Thu, 10 Apr 2014 09:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.528 X-Spam-Level: X-Spam-Status: No, score=0.528 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.272] 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 24_XONnviAq7; Thu, 10 Apr 2014 09:25:45 -0700 (PDT) Received: from g6t1524.atlanta.hp.com (g6t1524.atlanta.hp.com [15.193.200.67]) by ietfa.amsl.com (Postfix) with ESMTP id 638C21A02E0; Thu, 10 Apr 2014 09:25:45 -0700 (PDT) Received: from G6W4001.americas.hpqcorp.net (g6w4001.atlanta.hp.com [16.205.80.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t1524.atlanta.hp.com (Postfix) with ESMTPS id 703C3268; Thu, 10 Apr 2014 16:25:41 +0000 (UTC) Received: from G6W3998.americas.hpqcorp.net (16.205.80.213) by G6W4001.americas.hpqcorp.net (16.205.80.210) with Microsoft SMTP Server (TLS) id 14.3.169.1; Thu, 10 Apr 2014 16:23:32 +0000 Received: from G6W2492.americas.hpqcorp.net ([169.254.8.28]) by G6W3998.americas.hpqcorp.net ([16.205.80.213]) with mapi id 14.03.0169.001; Thu, 10 Apr 2014 16:23:32 +0000 From: "Fedyk, Don" To: Ben Niven-Jenkins Subject: RE: RtgDir review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt Thread-Topic: RtgDir review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt Thread-Index: AQHPTcsuEp8NjP2MHUefw+jGDEpVuZsBd6OwgAXygwCAAJNdoA== Date: Thu, 10 Apr 2014 16:23:32 +0000 Message-ID: References: <4A8A526D-C573-424C-9FFF-2BF282C951F2@niven-jenkins.co.uk> In-Reply-To: <4A8A526D-C573-424C-9FFF-2BF282C951F2@niven-jenkins.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [15.193.49.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/JfEg6BBgWFziJmPvrQZXHpJnUvs Cc: "l2vpn@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-l2vpn-vpls-ldp-mac-opt.all@tools.ietf.org" , "rtg-ads@tools.ietf.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: Thu, 10 Apr 2014 16:25:50 -0000 Hi Ben=20 Inline [Don] (no >) I'll be providing an update based on your feedback and that of Robert and = Adrian. Hopefully in short order, Thanks Don=20 >-----Original Message----- >From: Ben Niven-Jenkins [mailto:ben@niven-jenkins.co.uk]=20 >Hi Don, > >Some follow-ups inline below > >On 7 Apr 2014, at 14:04, Fedyk, Don wrote: > >> Hi Ben >>=20 >> Thanks for your review. Attached are the changes so far. Inline [Don] a= re my comments. >>=20 >> You raise a couple of points that Adrian/Nabil/Giles, other authors shou= ld review before I change anything else. >>=20 >> Don >>> From: Ben Niven-Jenkins From reading the docum= ent my opinion is that it suitably describes what is required to implement = the newly proposed mechanism but it may be hard for someone to read the doc= ument and determine what circumstances would motivate using the new optimis= ed MAC flush versus sticking with the original RFC4627 [don] 4762 MAC flush= mechanism. >>=20 >> [Don] It is mentioned in section 3 overview that a simplified LDP MAC me= ssage while it speeds up LDP can adversely affect the native Ethernet forwa= rding which reverts to flooding of unknown addresses. This is important in = real time Ethernet networks. > >I saw that in section 3. I can see that you have a new mechanism that solv= es a problem with an existing mechanism. > >My comment above is my observation that the way the document is written se= ems to me to assume that the reader is already familiar with the proposed o= ptimised MAC flush and any implications it might have and has already decid= ed to use/implement it and is reading the RFC to figure out what code to wr= ite to implement it. > >The ADs may decide that is fine. [Don] OK.=20 > >>> Major issues: >>>=20 >>> I've raised this as a major issue as I think it may require AD input/at= tention to resolve. It is not a technical issue but a suggestion for includ= ing more explanatory text that I think would help improve the document but = which the AD may decide is not required. >>>=20 >>> The document specifies a solution to solve a problem with the mechanism= for MAC address withdrawal specified in RFC4762 but it doesn't provide any= indication of when the new optimised MAC flush that is proposed should be = used instead of the existing MAC flush mechanism specified in RFC4627. >>=20 >> [Don] One of the debates we had was that for backwards compatibly the wo= rst you get is the RFC4762 behaviour. > >> But if all nodes are updated you can use the new message and get the op= timized MAC flush. However during the course of the draft a more explicit = means of specifying the behavior was proposed to signal compatibility that = became its own draft. In order to resolve the MAC flush issues, without de= pendency on a capabilities draft, this draft specifies backwards compatib= ly by requiring the node that supports the optimized MAC flush can also su= pport the old MAC flush. > >See my comment above. I think the same applies here. > >>> The downside of the existing RFC4627 MAC flush mechanism appears to be = that PEs can end up having to flush many more MAC addresses than absolutely= required when a dual homed CE/MTU switches from using the primary spoke PW= to the backup spoke PW. >>=20 >> [Don] Flushing more MACs causes issues with the side effect of traffic t= hat should not be affected being affected by a change. In order to decoupl= e this effect, the optimization reduces unintentional disruption. > >It would IMO be useful if the document stated this sort of thing somewhere= . I'm not thinking about specific numbers or anything but some information = along these lines that highlights what are the issues & impacts caused by R= FC4627 under what circumstances and how the new optimised MAC flush avoids = them would be valuable information for a reader to determine if they are li= kely to face the problems optimised MAC flush addresses and therefore wheth= er optimised MAC flush is something they should consider using/implementing= . > [Don] OK I'll try to make this point. =20 >>> The optimised MAC flush specified in the document solves the problem by= moving the initiation of the MAC flush message from the 'backup' PE-rs to = the 'primary' PE-rs and introducing a new message to allow the primary PE-r= s to request other PE-rs in the network flush all MAC addresses learnt via = the primary PE-rs. >>>=20 >>> While the new message means that the PE-rs in the network will flush an= d relearn fewer MAC addresses on failure of the primary spoke PW between th= e MTU-s & primary PE-rs, it is not clear to me whether it is superior in al= l cases. >>=20 >> [Don] It does solve cases where dual homing aware PE-rs connect to resil= ient Ethernet networks. This is a case worth solving because those type of = network usually have strict SLAs. The other cases where other dual homing= is outside of the of the PE-rs was covered for completeness. > >I think my sloppy use of "in all cases" may have caused confusion. > >If instead I said "it is not clear to me whether optimised MAC flush is su= perior in all failure scenarios", does that help clarify? > [Don] I think the true statement is optimized MAC flush is superior in the = case of Dual Homing Aware PE-rs which is a common and important case. As= you point out there are possible error cases which fall back to less respo= nsive behavior.=20 >>> For example, the new optimised MAC flush relies on the primary PE-rs to= detect the failure of the spoke PW and initiate the optimised MAC flush bu= t the document doesn't discuss what happens if the failure isn't detected (= e.g. if PE-rs doesn't detect the failure or PE-rs itself fails). My assumpt= ion is that the network falls back to relying on aging/timeout of MAC entri= es, which presumably means that traffic is blackholed for up to 5 minutes (= using default timers). >> [Don] Yes as mentioned this is not the case this was designed for but wa= s described for completeness. > >I'm not quite sure what you mean here (specifically what you mean by "case= "). > >Let me try and expand on my concern. > >With RFC4762, failure of the primary spoke PW causes the MTU-s to switch t= raffic to the backup spoke PW, which results in packets being no longer bei= ng forwarded to PE1-rs and instead being forwarded to PE3-rs (using the lab= elling from Figure 1 of the document). > >On seeing packets suddenly arriving, PE3-rs can tell it is now the primary= PE-rs, and can initiate a MAC flush message to all other PE-rs. [Don] Section 3.1.1 Points out the cases that PE3-rs is not being able to = tell it is a new primary. I.e. PE3-rs is not dual homing aware or PE3-rs = is not in control of the dual homing (eg BGP-MH).=20 > >This doesn't rely on anything external, PE3-rs can determine just by the a= ppearance of packets on the PW that it is now the primary PE-rs for that tr= affic. There's very little further to go wrong, except for the possibility = that PE3-rs does not initiate the MAC flush for some reason and then the fa= llback is to ageing/timeout of MACs. > >With the optimised MAC flush, in order for the optimised MAC flush to work= , it relies on PE1-rs detecting the failure somehow and initiating the opti= mised MAC flush. The optimised MAC flush isn't triggered by PE3-rs suddenly= seeing traffic anymore. Now if PE1-rs does't trigger the optimised MAC flu= sh for whatever reason (it didn't detect the PW failed, PE1-rs itself fell = over, etc) the fallback is to ageing/timeout of MACs. > >Therefore my conclusion is that with RFC4762 the chance of having to fallb= ack to ageing MACs is pretty remote (basically just when there is a badly b= orked implementation on PE3-rs). [Don] Not just that as pointed out in section 3.1.1. > >With optimised MAC flush there are several scenarios which could result in= PE1-rs not initiating the optimised MAC flush message for some reason and = so the network has to rely on ageing MACs in those cases. [Don] So we have a case where optimized MAC flush is fast and efficient but= if for some reason PE1-rs does not initiate the MAC flush there is some de= lay. If PE1-rs fails then LDP will trigger MAC flush on other VPLS on othe= r PE-rs. So we are down to Failure cases where PE1-rs does not notice the M= TU-s went away or there is a software error on PE1-rs. I believe the inten= t is that is a fairly rare case and as pointed out PE3-rs cannot do better.= If you had both mechanisms you would be initiating 2 flushes. Also, PE3-= rs must initiate a full VPLS flush (empty MAC list) because it does not kno= w in the RFC4762 case how many MAC addresses or the specifics of the MAC ad= dresses. So the intent of the optimized MAC flush is to use the more targ= eted flush from PE1-rs.=20 > >I think it's worth saying something about this.=20 > [Don] I will attempt to address this. =20 >>> It is also not clear whether this mechanism is designed to replace the = mechanism in RFC4627 or to augment it, although I have assumed the former. >> [Don] In a case where all nodes supported the optimized flush RFC4627 wo= uld be used but for backwards compatibility the mechanism in RFC4627 is rec= ommended to be retained. >>>=20 >>> I therefore think that the document would benefit significantly from: >>>=20 >>> a) Some clear text/statement of when the new optimised MAC flush mechan= ism should be used instead of the existing RFC4627 mechanism (e.g. when is = a full RFC4627 MAC flush "bad"). >> [Don] OK I'll ask Adrian if he would like this highlighted. >>>=20 >>> b) Some discussion describing how the new optimised MAC flush mechanism= is equivalent to the existing mechanism and highlighting any cases where i= t may not provide as rapid MAC table updates as the RFC4627 mechanisms. >> [Don] I don't think we should get into operational specifics of timing.= I know for a fact that the mechanism has been deployed in dual homing awar= e networks with tight SLAs. Flushing traffic that is unaffected is clearly= undesirable. It really depends on the network scenario where you are flush= ing MACs. PBB networks can have 1000s of affected flows. > >I am not asking for operational specifics of timing. See above. [Don] So if we say something about the corner case and point out when optim= ized MAC Flush operates it is fast and more efficient. Also we make it cle= ar that it augments RFC4762 by handling cases that were outside of RFC4762.= =20 Does that cover your points? =20 > >>> Minor issues: >>>=20 >>> 1) The first paragraph of section 3 states: >>>=20 >>> When the MTU-s switches over to the backup PW, the requirement is to = =20 >>> flush the MAC addresses learned in the corresponding Virtual Switch =20 >>> Instance (VSI) in peer PE devices participating in the full mesh, to =20 >>> avoid black holing of frames to those addresses. This is =20 >>> accomplished by sending an LDP Address Withdraw Message from the PE =20 >>> that is no longer connected to the MTU-s with the primary PW, with =20 >>> the list of MAC addresses to be removed to all other PEs over the =20 >>> corresponding LDP sessions [RFC4762]. >>>=20 >>> Comparing this against Figure 1, my understanding is that the "PE that = is no longer connected to the MTU-s with the primary PW" is PE1-rs. However= section 3.1.1 states: >>>=20 >>> [RFC4762] specifies that on failure of the primary PW, it is the =20 >>> PE3-rs (Figure 1) that initiates MAC flush towards the core. >>>=20 >>> Which contradicts the first paragraph of section 3? >> [Don] I see your point here, is what is being described. >> 1) PE-rs dual homing Aware >> - Control of dual homing by the PE-RS <- This is 3.1.1 >> - Control of dual homing by the MTUs <-This is 3. >> 2) PE-Rs dual homing unaware. >>=20 >> [Don] It is up to you Ads & WG chairs to say if this should be highlight= ed, I think it covers the cases and I can try make it clearer as above if = that helps. >>>=20 >>> I think that the first paragraph of section 3 is describing the behavio= ur when using the new mechanism described in the draft, but that wasn't cle= ar to me when I first read the draft, so I would suggest re-wording or addi= ng some text to make it more explicit when you are describing new behaviour= specified in the document versus existing behavior inherited from RFC4762. >> [Don] The first part of section 3 is describing an existing RFC 4762 mes= sage a positive flush by a MTU-s that is dual homing and in control of the = dual homing. However it is true that a MTU-s using LDP could use the new p= rocedures to propagate a flush to the PE-RS in the case of some downstream = Dual homing and that is not excluded. >>>=20 >>> 2) Section 3.2. I'm not sure what the significance of the native ethern= et segment is in this sentence "For example, the case of PE1-rs initiated M= AC flush on failure may arise when the dual-homing segment is native ethern= et as opposed to spoke PWs.". You may want to consider stating what issue i= t is that the presence of native ethernet causes. >> [Don] If the connection is MPLS then there are LDP control messages tha= t can propagate MAC status messages and if it is native Ethernet then the P= E-RS has to interpret the messages and convert them to the LDP messages. I= think that is all native Ethernet is trying to say but there are multiple = ways Ethernet can do that RSTP, G.8031 etc. >>>=20 >>> 3) Section 3.2 goes on to say "In this case the PE-rs devices that=20 >>> receive the MAC flush from PE1-rs are required to flush all the MAC=20 >>> addresses learned over the PW connected to PE1-rs. This cannot be=20 >>> achieved with the MAC Address Withdraw Message defined in =20 >>> [RFC4762]." >>>=20 >>> You may want to consider stating why MAC flush cannot be achieved with = the MAC Address Withdraw Message defined in RFC4762 (as the lack of ability= for performing MAC flush in this scenario is presumably the motivation for= defining the new MAC flush on failure mechanism in the document?). >> [Don] Reasons from the document are : >> Many implementations use an LDP withdraw message with an empty MAC=20 >> list. (My interpretation is this is just the way it is.) Section 3.2 sta= tes the rational for the MAC flush on failure. That cannot be achieved with= the RFC4762 message and procedures. >>>=20 >>> 4) Section 5.1.2 states >>>=20 >>> The MAC withdraw procedures defined in [RFC4762], MTU-s or PE2-rs =20 >>> SHOULD be sent in cases where the network is being upgraded and =20 >>> devices are not capable of understanding the optimized MAC flush. >>> This would result in the same flushing action as [RFC4762] at the =20 >>> receiving PE-rs devices. >>>=20 >>> Which I am struggling to parse. Do you mean something along these lines= ? >>>=20 >>> The MAC withdraw procedures defined in [RFC4762], where either =20 >>> MTU-s or PE2-rs send the MAC Withdrawl message SHOULD be used in=20 >>> cases where the network is being upgraded and devices are not =20 >>> capable of understanding the optimized MAC flush. >>> This would result in the same flushing action as [RFC4762] at the =20 >>> receiving PE-rs devices. >> [Don] Your text is better. This is the recommendation for backward comp= atibility since there is no capabilities exchange. >>>=20 >>> 5) Section 5.1.2 states >>>=20 >>> For the case of B-VPLS devices optimized MAC flush message SHOULD be = =20 >>> supported. >>>=20 >>> It's not clear to me what the purpose of this sentence is or what it ad= ds to the document. >> [Don] It is historical. RFC 4762 VPLS preceded the deployment of PBB B-V= PLS. But B-VPLS was developed the same time as this draft and the procure= s help in deployments where there are lots of I-SIDs . So the recommendati= on is to use the optimization for PBB deployments. > >I'd suggest stating something like that then instead of the current senten= ce. The current SHOULD does't contribute to interoperability of your mechan= ism, instead it is placing a requirement on devices to implement your mecha= nism. That requirement carries no weight in reality as it in unenforceable = so I'd suggest not using the SHOULD and just stating what you want to say, = e.g. something like: B-VPLS deployments with lots of I-SIDs can also benefi= t from using the optimised MAC flush mechanism specified in this document. [Don] Good by me.=20 > >>> 6) Section 5.1.4 states >>>=20 >>> This section explains the optimized MAC flush procedure in the =20 >>> scenario in Figure 2. When the primary spoke PW transition (failure =20 >>> or standby transition) is detected by PE1-rs, it MAY send MAC flush =20 >>> messages to PE2-rs, PE3-rs and PE4-rs with MAC Flush TLV and N =3D 1. >>>=20 >>> Use of MAY here seems a bit strange to me. I may have misunderstood but= it seems to me that the document is proposing replacing the existing MAC w= ithdraw mechanisms with this new mechanism, but when using this new mechani= sm sending the optimised MAC flush is only a MAY, so what happens when PE1-= rs doesn't send the optimised MAC flush? I assume the fallback is aging/tim= eout of MAC entries, or is it that the previous MAC withdraw mechanism is a= lso being used? >>=20 >> [Don] How about: >> When Optimized MAC flush is being used a PE-rs that is dual homing aware= SHOULD send MAC address messages with MAC Flush TLV and N=3D1 provided the= other PEs understand the new messages. > >WFM. > >Ben > >>> You may want to consider re-phrasing it along the lines of "When optimi= sed MAC flush is being used then " >>>=20 >>>=20 >>> nits: >>> 1) Section 4 states: >>> This section describes the problems in detail with respective to =20 >>> various MAC flush actions described in section 2. >>=20 >> [Don] Yes s/2/3/ >>> Section 2 is the terminology section and doesn't describe any MAC flush= actions, do you mean to reference section 3? >>>=20 >>> Also I'm not exactly sure what a MAC flush action is. I think you may m= ean: >>>=20 >>> This section describes the problems in detail with respect to the =20 >>> various MAC flush scenarios described in section 3. >>>=20 >>> And I think you mean to use 'respect' rather than 'respective'. >>>=20 >>> 2) Section 4.1.1, penultimate paragraph says "In the example above, onl= y the MAC addresses in set X and Y need to be flushed across the core." Y i= s not used in the text which confused me for a while until I realised you w= ere referring to Figure 2. You may want to consider making that more explic= it, for example: >>>=20 >>> In the example above, only the MAC addresses in set X and Y (shown=20 >>> in Figure 2) need to be flushed across the core. >> [Don] Sure. >>>=20 >>> 3) Section 4.1.2 starts >>>=20 >>> The analysis in section 3.1.1 applies also to the native Ethernet =20 >>> access into a VPLS. >>>=20 >>> I think you may mean to reference section 4.1.1, not 3.1.1? >>>=20 >> [Don] I believe you are correct is accurate. Section 3 and section 4 ar= e roughly parallel a holdover from before I took over editing. >>> 4) Section 5 states >>>=20 >>> This section describes the solution for the requirements described=20 >>> in section 4. >>>=20 >>> Section 4 doesn't seem to list any requirements as such. Maybe consider= rewording to something like: >>>=20 >>> This section describes a solution for the problem space described in = =20 >>> section 4. >> [Don] I like your suggestion. >>>=20 >>> 5) Section 5.1 states >>>=20 >>> The optimization is achieved by >>> initiating MAC Flush on failure as described in section 2.2. >>>=20 >>> and >>>=20 >>> The MAC Flush TLV can also >>> be used for [RFC4762] style of MAC Flush as explained in section 2. >>>=20 >>> I think you mean section 3.2 and section 3 respectively. >> [Don] Yes I think we switched section 3 and section 2 and forgot the ref= erence. No smart tags just me. >>>=20 >>> 6) Section 5.1.1 & 5.1.2 cross-reference section 4.2 for details of its= usage in PBB-VPLS but I think you mean to cross-reference section 5.2. >> [Don] Changed 4.2 is not completely wrong but 5.2 gives more usage notes= . I'm tempted to reference both but I've change to 5.2. >>>=20 >>> 7) Section 5.1.2, 5.1.3 & 5.2.2 cross-references section 5 for operatio= nal considerations but I think you mean to cross-reference section 6. >> [Don] Yes. >>>=20 >>> Regards >>> Ben >>>=20 >>=20 >> > draft-ietf-l2vpn-vpls-ldp-mac-opt-11_txt -=20 >> draft-ietf-l2vpn-vpls-ldp-mac-opt-12_txt.htm> > > From nobody Thu Apr 10 09:27:08 2014 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 4DFBC1A02FD; Thu, 10 Apr 2014 09:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] 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 zHdvB6RT0iao; Thu, 10 Apr 2014 09:27:04 -0700 (PDT) Received: from g6t1524.atlanta.hp.com (g6t1524.atlanta.hp.com [15.193.200.67]) by ietfa.amsl.com (Postfix) with ESMTP id B0B481A023A; Thu, 10 Apr 2014 09:27:04 -0700 (PDT) Received: from G6W4001.americas.hpqcorp.net (g6w4001.atlanta.hp.com [16.205.80.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t1524.atlanta.hp.com (Postfix) with ESMTPS id 88CB4294; Thu, 10 Apr 2014 16:27:03 +0000 (UTC) Received: from G6W3997.americas.hpqcorp.net (16.205.80.212) by G6W4001.americas.hpqcorp.net (16.205.80.210) with Microsoft SMTP Server (TLS) id 14.3.169.1; Thu, 10 Apr 2014 16:25:10 +0000 Received: from G6W2492.americas.hpqcorp.net ([169.254.8.28]) by G6W3997.americas.hpqcorp.net ([16.205.80.212]) with mapi id 14.03.0169.001; Thu, 10 Apr 2014 16:25:10 +0000 From: "Fedyk, Don" To: Robert Sparks , General Area Review Team , "draft-ietf-l2vpn-vpls-ldp-mac-opt@tools.ietf.org" , "l2vpn@ietf.org" Subject: RE: Gen-art LC review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11 Thread-Topic: Gen-art LC review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11 Thread-Index: AQHPUpla/vBEaWxwvkyaZc2uEqclVJsIK+Vw Date: Thu, 10 Apr 2014 16:25:10 +0000 Message-ID: References: <5342FF4F.4040906@nostrum.com> In-Reply-To: <5342FF4F.4040906@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [15.193.49.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/SbS-oM1WT3OiKJvTQ5aK3VKvfyo 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, 10 Apr 2014 16:27:06 -0000 Hi Robert Thanks for your comments. Inline [Don] I've incorporated your feedback in the latest draft which I will distribute= and check with authors and ADs and Chairs shortly.=20 Don. -----Original Message----- From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Robert Sparks Sent: Monday, April 07, 2014 3:41 PM To: General Area Review Team; draft-ietf-l2vpn-vpls-ldp-mac-opt@tools.ietf.= org; l2vpn@ietf.org Subject: Gen-art LC review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11 I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR= T, please see the FAQ at . Please resolve these comments along with any other Last Call comments you m= ay receive. Document: draft-ietf-l2vpn-vpls-ldp-mac-opt-11 Reviewer: Robert Sparks Review Date: 7Apr2014 IETF LC End Date: 8Apr2014 IESG Telechat date: not yet scheduled Summary: This draft is almost ready for publication as a Proposed Standard,= but has minor issues (primarily editorial) that should be addressed. I found this document very difficult to read. It asks the reader to hop bet= ween sections in unusual ways (for instance, it sends the reader to the pro= blem statement section for details on normative behavior). I strongly encou= rage an editorial pass focusing on document structure. [Don] Will work with AD to see what can be done here. =20 There are many instances of SHOULD in the document where the text should ju= st be using prose instead. It's not always clear when an implementation wou= ld choose to ignore the SHOULD, and what the consequences of that choice wo= uld be. [Don] I'll check this.=20 The document is inconsistent about the level of support needed in the netwo= rk before trying to use this extension. Section 5.1.2 says the assumption is everything understands it before it's = turned on. Section 6 points back to figure 2 and says to use the extension = over the pw where you administratively know the peer supports the extension= , and fall back to 4762 for everything else. Which of those did you intend? [Don] I will clarify. =20 Specific comments in document order: Section 3.2 paragraph 1: This paragraph would benefit from being broken int= o several. It's hard to find its point. The SHOULD in this paragraph is pro= bably not a 2119 SHOULD (this section isn't defining the protocol). It woul= d be useful in this overview to explicitly say _why_ "This cannot be achiev= ed with ... 4762]" at this point in the document. [Don] Will address this . Section 3.2 paragraph 2: This SHOULD _is_ defining protocol - shouldn't it = be in section 5? [Don] Agree.=20 Section 4.1.1 paragraph 3: It took me some time to find Z on the figure.=20 It might help to introduce it similar to how you introduce X. [Don] OK Section 4.1.2: paragraph 1: I think you meant to reference 4.1.1 [Don] Done. Section 5: The first sentence talks about requirements in section 4.=20 Section 4 describes a problem using some examples but doesn't explicitly ca= ll out requirements. Doing so would help the document. [[Don]] Renamed Problem Space as recommended by Ben.=20 Last sentence in 5.1.1 (and several other places in the document):=20 Please add an article before "MAC Flush message". (I apologize for such a = small nit, but each of these instances made making sure I was reading what = the sentence intended significantly more difficult). [Don] OK.=20 Section 5.1.2 first paragraph: This section is defining behavior - why are = you sending the reader back into the problem statement for detail on the be= havior? [Don] s/4.2/5.2/ 5.1.2 paragraph 2: You meant section 6, not 5. [Don] Done. 5.1.2 paragraph 3: I can't follow this paragraph's structure. I think you'r= e trying to say "An MTU-s or PE2-rs SHOULD send MAC withdraw messages as de= fined in [RFC4762] in cases where the network is being upgraded and devices= are not capable of understanding the optimized MAC flush." (But if so, the= next sentence is redundant.) Why is this SHOULD? [Don] Updated.=20 5.1.3 paragraph 1: Why is this a SHOULD and not a MUST? (Similar question f= or the SHOULD in paragraph 2). It's not clear if you're trying to avoid "So= me things won't implement this spec" or "Don't do this if you haven't admin= istratively ensured every element understands this extension first" or some= thing else? [Don] Changed to MUST for optimized MAC Flush.=20 5.1.3 paragraph 3: You say "unless specified otherwise". Do you ever specif= y otherwise? Why is this disclaimer here? [Don] Removed. 5.1.3 last paragraph: You meant section 6 not 5. [Don] Done.=20 From nobody Thu Apr 10 18:43:57 2014 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 0D7CE1A02F7; Thu, 10 Apr 2014 18:43:53 -0700 (PDT) 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 rYsda05VPc_r; Thu, 10 Apr 2014 18:43:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E5FC51A01E1; Thu, 10 Apr 2014 18:43:47 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce Subject: Last Call: (Redundancy provisioning for VPLS Inter-domain) to Best Current Practice X-Test-IDTracker: no X-IETF-IDTracker: 5.2.1 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20140411014347.10596.6180.idtracker@ietfa.amsl.com> Date: Thu, 10 Apr 2014 18:43:47 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/3Py0p7XPxp7Tt9F79gkek2kuXNE Cc: l2vpn@ietf.org X-BeenThere: l2vpn@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Layer 2 Virtual Private Networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Apr 2014 01:43:53 -0000 The IESG has received a request from the Layer 2 Virtual Private Networks WG (l2vpn) to consider the following document: - 'Redundancy provisioning for VPLS Inter-domain' as Best Current Practice The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2014-04-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract In many existing Virtual Private LAN Service (VPLS) deployments based on RFC 4762, inter-domain connectivity has been deployed without node redundancy, or with node redundancy in a single domain. This document describes a solution for inter-domain VPLS based on RFC 4762 with node and link redundancy in both domains. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-l2vpn-vpls-inter-domain-redundancy/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-l2vpn-vpls-inter-domain-redundancy/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Apr 11 03:59:20 2014 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 607D91A02A8; Fri, 11 Apr 2014 03:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.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 IOyOKGnPmzJB; Fri, 11 Apr 2014 03:59:14 -0700 (PDT) Received: from mailex.mailcore.me (mailex.mailcore.me [94.136.40.62]) by ietfa.amsl.com (Postfix) with ESMTP id B50CC1A01F1; Fri, 11 Apr 2014 03:59:14 -0700 (PDT) Received: from aputeaux-554-1-37-47.w90-35.abo.wanadoo.fr ([90.35.60.47] helo=[192.168.1.132]) by smtp04.mailcore.me with esmtpa (Exim 4.80.1) (envelope-from ) id 1WYZAt-0006qK-DA; Fri, 11 Apr 2014 11:59:11 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: RtgDir review: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt From: Ben Niven-Jenkins In-Reply-To: Date: Fri, 11 Apr 2014 12:59:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4A8A526D-C573-424C-9FFF-2BF282C951F2@niven-jenkins.co.uk> To: "Fedyk, Don" X-Mailer: Apple Mail (2.1874) X-Mailcore-Auth: 9600544 X-Mailcore-Domain: 172912 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/LZUFzZyv6W4jR5bM4Omcv0o3lnQ Cc: "l2vpn@ietf.org" , "rtg-dir@ietf.org" , "draft-ietf-l2vpn-vpls-ldp-mac-opt.all@tools.ietf.org" , "rtg-ads@tools.ietf.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: Fri, 11 Apr 2014 10:59:16 -0000 Don, On 10 Apr 2014, at 18:23, Fedyk, Don wrote: > [Don] So if we say something about the corner case and point out when = optimized MAC Flush operates it is fast and more efficient. Also we = make it clear that it augments RFC4762 by handling cases that were = outside of RFC4762.=20 > Does that cover your points? =20 Yes I think it will :-) Ben From nobody Tue Apr 15 03:45:26 2014 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 BFBFB1A03C0; Tue, 15 Apr 2014 03:45:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Xt1DOhbFD6Sa; Tue, 15 Apr 2014 03:45:22 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 765311A03BB; Tue, 15 Apr 2014 03:45:22 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id j107so263861qga.3 for ; Tue, 15 Apr 2014 03:45:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=OUJTV0IbKqSmLwITVaPe3OPb1mV774WgOqJdmIovAh8=; b=ohBINBYepC5mjveAtECBc+4Az8UIwafwcvNRDQ0b7FMndRJ7+Nsgxof8R1H6TY5wyL tvZ82uIr4aeTg5rJN3Cr88fpiQCaC5bjx201d9pyyYmCQqPmtgLvhwQbUoum4VyGRggR BsQf9mVwXijOXe01j5/n6XZOEbn0NcL0XirSCyeO8EOQ6rSA/UcyZYNQaaHv2L5ER8ma dk00mBU4wsoHN5jSEKEm4kcQucbZYyEluK0KK+doN3J7upavjvmEBu2HsJ9ApTpUnda4 y83aU+qJTs2fHYp/0tboKqvnCITtsjM7k4CkMht7dStzPzhkxNhOjtuqBe53DZPPx4Nk ZbKQ== X-Received: by 10.224.66.4 with SMTP id l4mr1387055qai.70.1397558719421; Tue, 15 Apr 2014 03:45:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.205.69 with HTTP; Tue, 15 Apr 2014 03:44:59 -0700 (PDT) From: "Andrew G. Malis" Date: Tue, 15 Apr 2014 06:44:59 -0400 Message-ID: Subject: RtgDir review: draft-ietf-l2vpn-vpls-inter-domain-redundancy-05.txt To: rtg-ads@tools.ietf.org Content-Type: multipart/alternative; boundary=001a11c2905806249004f7127f07 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/IKkKMMB8LKjhb3z14Y167CQ7ZTY Cc: "l2vpn@ietf.org" , "rtg-dir@ietf.org" , draft-ietf-l2vpn-vpls-inter-domain-redundancy.all@tools.ietf.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: Tue, 15 Apr 2014 10:45:25 -0000 --001a11c2905806249004f7127f07 Content-Type: text/plain; charset=UTF-8 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-l2vpn-vpls-inter-domain-redundancy-05.txt Reviewer: Andy Malis Review Date: 15 April 2014 IETF LC End Date: 24 April 2014 Intended Status: Standards Track Summary: I have some minor concerns about this document that I think should be resolved before publication. It also has editorial nits that should be considered prior to publication. Comments: In general, I found the draft straightforward to read and follow. It does require a working knowledge of draft-ietf-pwe3-iccp-16.txt and RFC 6870, and it is a very good application of these two specifications. I noted that the only draft in the references (draft-ietf-pwe3-iccp-16.txt) is currently in the RFC Editor's queue. Major Issues: No major issues found. Minor Issues: Section 5.3: The draft includes two variants of the 3:1 protection model, referred to as options A and B. However, it does not provide any criteria or guidelines for selection between the two either for code implementation or network operation. The draft should state whether one or both are required for implementation (I would guess both) and how to choose between them operationally (there are hints if you read between the lines, but it should be explicit). It is also implied (but again not explicitly stated) that both domains should choose the same option. That should be explicitly stated, if correct, and should be repeated in Section 6. Section 6: This section provides two examples of options that need to be provisioned identically within and/or between RGs for proper operation. This should be a list of such options rather than just the two examples. Section 7, second paragraph: Should "could be secured" be "MAY be secured"? Nits: Section 1, last paragraph, "behaviour" -> "behavior". Section 3, fourth paragraph, "P2P" is used without definition. As this is the only use in the document, I recommend spelling it out to "point-to-point". Section 4, third paragraph, "use-case" -> "use case" Section 5, second paragraph, I personally prefer "manual provisioning" instead of "manual operation", but the current text is OK if the authors prefer it. Section 5.1.3, "that is member" -> "that is a member" Section 5.3, fourth paragraph: "option A and B" -> "options A and B" Section 7, last paragraph, "activitiy" -> "activity" "attackes" -> "attacks" --001a11c2905806249004f7127f07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I have been selected = as the Routing Directorate reviewer for this draft. The Routing Directorate= seeks to review all routing or routing-related drafts as they pass through= IETF last call and IESG review, and sometimes on special request. The purp= ose of the review is to provide assistance to the Routing ADs. For more inf= ormation about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/= routing.html

Although these comments are primarily for the use of th= e Routing ADs, it would be helpful if you could consider them along with an= y other IETF Last Call comments that you receive, and strive to resolve the= m through discussion or by updating the draft.

Document: draft-ietf-l2vpn-vpls-inter-domain-redundancy= -05.txt
Reviewer: Andy Malis
Review Date: 15 April 2014=
IETF LC End Date: 24 April 2014
Intended Status: Stand= ards Track

Summary:

I have some minor con= cerns about this document that I think should be resolved before publicatio= n. It also has editorial nits that should be considered prior to publicatio= n.

Comments:

In general, I found = the draft straightforward to read and follow. It does require a working kno= wledge of draft-ietf-pwe3-iccp-16.txt and RFC 6870, and it is a very good a= pplication of these two specifications.

I noted that the only draft in the references (draft-ie= tf-pwe3-iccp-16.txt) is currently in the RFC Editor's queue.
=
Major Issues:

No major issues found= .

Minor Issues:

Section 5.3: The= draft includes two variants of the 3:1 protection model, referred to as op= tions A and B. However, it does not provide any criteria or guidelines for = selection between the two either for code implementation or network operati= on. The draft should state whether one or both are required for implementat= ion (I would guess both) and how to choose between them operationally (ther= e are hints if you read between the lines, but it should be explicit). It i= s also implied (but again not explicitly stated) that both domains should c= hoose the same option. That should be explicitly stated, if correct, and sh= ould be repeated in Section 6.

Section 6: This section provides two examples of option= s that need to be provisioned identically within and/or between RGs for pro= per operation. This should be a list of such options rather than just the t= wo examples.

Section 7, second paragraph: Should "could be secu= red" be "MAY be secured"?

Nits:

Section 1, last paragraph, "behaviour" ->= ; "behavior".

Section 3, fourth paragraph, "P2P" is used wi= thout definition. As this is the only use in the document, I recommend spel= ling it out to "point-to-point".

Section= 4, third paragraph, "use-case" -> "use case"

Section 5, second paragraph, I personally prefer "= manual provisioning" instead of "manual operation", but the = current text is OK if the authors prefer it.

Section 5.1.3, "that is member" -> "that is a member"= ;

Section 5.3, fourth paragraph: "option A and B&quo= t; -> "options A and B"

Section 7, la= st paragraph, "activitiy" -> "activity"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0"attackes" -> "attacks"

--001a11c2905806249004f7127f07-- From nobody Wed Apr 16 08:40:35 2014 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 844E11A01F2; Wed, 16 Apr 2014 08:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 kOuXhJhmx0rw; Wed, 16 Apr 2014 08:40:29 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id B64431A01A9; Wed, 16 Apr 2014 08:40:29 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id fb1so11150006pad.1 for ; Wed, 16 Apr 2014 08:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=7SzdXAxGI6OuLegRN9SaDnTMtj60Yfx+9iegJ8u3EU8=; b=dFnJ5J435J7H/cWxFGzl+D9vFuX54+zI8Zvc/uYweMRkeY4/8yqjWKmykHIiCPPewf FJHhzMpq/4WhQgtLjATZ5lLEjalU/iLxaT/6FCcvvF/uHhL43iIxXGStlXqlQmKQiSuC k7PHANxAFlpkn4fNapj0SsM89k1MNCwxz086Zmk8vz7mgKPbfLgB259PN+3HWRv3dl1+ pILCV0K4tG7sDG2EwpOErKT4qim6hxtk+m3uNzPFouRmdso2kz/xqBwhR2VT2S20xjdg cGrnQcMEGpNaM1BLiFHBKKrO1Ta1/EpBtKw8MwNVVKl73gqIJ/sKo9YaZ4U0m/Iby6yF b4xA== X-Received: by 10.66.142.42 with SMTP id rt10mr9312667pab.1.1397662826597; Wed, 16 Apr 2014 08:40:26 -0700 (PDT) Received: from LizhongPC ([114.62.215.53]) by mx.google.com with ESMTPSA id sy2sm47745306pbc.28.2014.04.16.08.40.19 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 16 Apr 2014 08:40:25 -0700 (PDT) From: "Lizhong Jin" To: "'Andrew G. Malis'" , References: In-Reply-To: Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-l2vpn-vpls-inter-domain-redundancy-05.txt Date: Wed, 16 Apr 2014 23:40:16 +0800 Message-ID: <534ea469.82e6440a.4410.0b83@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01CF59CD.3BD27610" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHtQIp7LE8eYs0PBkrzAVT3F51Sw5rXsZrQ Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/4xPB_B_nMDaQjlpa949rPJOPizM Cc: l2vpn@ietf.org, rtg-dir@ietf.org, draft-ietf-l2vpn-vpls-inter-domain-redundancy.all@tools.ietf.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: Wed, 16 Apr 2014 15:40:32 -0000 ÕâÊÇÒ»·â MIME ¸ñʽµÄ¶à²¿·ÖÓʼþ¡£ ------=_NextPart_000_002F_01CF59CD.3BD27610 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Andy, Thank you for the detail review. See my reply inline below. =20 Regards Lizhong =20 From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Andrew G. = Malis Sent: 2014=E5=B9=B44=E6=9C=8815=E6=97=A5 18:45 To: rtg-ads@tools.ietf.org Cc: l2vpn@ietf.org; rtg-dir@ietf.org; = draft-ietf-l2vpn-vpls-inter-domain-redundancy.all@tools.ietf.org Subject: [RTG-DIR] RtgDir review: = draft-ietf-l2vpn-vpls-inter-domain-redundancy-05.txt =20 Hello, =20 I have been selected as the Routing Directorate reviewer for this draft. = The Routing Directorate seeks to review all routing or routing-related = drafts as they pass through IETF last call and IESG review, and = sometimes on special request. The purpose of the review is to provide = assistance to the Routing ADs. For more information about the Routing = Directorate, please see = http://www.ietf.org/iesg/directorate/routing.html =20 Although these comments are primarily for the use of the Routing ADs, it = would be helpful if you could consider them along with any other IETF = Last Call comments that you receive, and strive to resolve them through = discussion or by updating the draft. =20 Document: draft-ietf-l2vpn-vpls-inter-domain-redundancy-05.txt Reviewer: Andy Malis Review Date: 15 April 2014 IETF LC End Date: 24 April 2014 Intended Status: Standards Track =20 Summary: =20 I have some minor concerns about this document that I think should be = resolved before publication. It also has editorial nits that should be = considered prior to publication. =20 Comments: =20 In general, I found the draft straightforward to read and follow. It = does require a working knowledge of draft-ietf-pwe3-iccp-16.txt and RFC = 6870, and it is a very good application of these two specifications. =20 I noted that the only draft in the references = (draft-ietf-pwe3-iccp-16.txt) is currently in the RFC Editor's queue. =20 Major Issues: =20 No major issues found. =20 Minor Issues: =20 Section 5.3: The draft includes two variants of the 3:1 protection = model, referred to as options A and B. However, it does not provide any = criteria or guidelines for selection between the two either for code = implementation or network operation. The draft should state whether one = or both are required for implementation (I would guess both) and how to = choose between them operationally (there are hints if you read between = the lines, but it should be explicit). It is also implied (but again not = explicitly stated) that both domains should choose the same option. That = should be explicitly stated, if correct, and should be repeated in = Section 6. [Lizhong] Thank you for pointing out this. This is the missing part for = a standard track draft.=20 The implementation MUST support option A, and MAY support option B. = Option B will be useful when the two legacy PEs in one domain does not = support the function in this document. The two legacy PEs still need to = support PW redundancy defined in [RFC 6870], but be configured as slave = node. The Section 6 will be updated as below: When deploying the inter-domain redundancy mechanism described in this = document, some manual operation/negotiation is required to be done = correctly and securely. For all the options described in section 5.2 = and 5.3, each node within one RG should be configured with same = redundancy mode, and both domains should choose the same option. For the = two-PWs redundancy options defined in section 5.2, the two operators = should also negotiate to configure same high/low PW priority at the two = PW end-points. If the configuration consistency is broken, the = inter-domain redundancy mechanism may not work properly. =20 =20 Section 6: This section provides two examples of options that need to be = provisioned identically within and/or between RGs for proper operation. = This should be a list of such options rather than just the two examples. [Lizhong] right, see the changes in the previous comment. =20 Section 7, second paragraph: Should "could be secured" be "MAY be = secured"? [Lizhong] the security directorate points out that the text of paragraph = two and three conflicts with [I-D.ietf-pwe3-iccp] SC. Then I will = rephrase the section as below. Besides the security properties of [I-D.ietf-pwe3-iccp] for ICCP control = plane, [RFC4762] and [RFC6870] for PW control plane, this document will = have additional security consideration for ICCP control plane. =20 In this document, ICCP protocol is deployed between two PEs or ASBRs. = The two PEs or ASBRs should only be connected by a well managed and = highly monitored network. This should be ensured by the operator. =20 The state flapping on the inter-domain and intra-domain pseudowire may = cause security threats or be exploited to create denial of service = attacks. For example, excessive pseudowire state flapping (e.g., by = malicious peer PE's implementation) may lead to excessive ICCP = exchanges. Implementations SHOULD provide mechanisms to perform = control-plane policing and mitigate such types of attacks. =20 =20 Nits: =20 Section 1, last paragraph, "behaviour" -> "behavior". =20 Section 3, fourth paragraph, "P2P" is used without definition. As this = is the only use in the document, I recommend spelling it out to = "point-to-point". =20 Section 4, third paragraph, "use-case" -> "use case" =20 Section 5, second paragraph, I personally prefer "manual provisioning" = instead of "manual operation", but the current text is OK if the authors = prefer it. =20 Section 5.1.3, "that is member" -> "that is a member" =20 Section 5.3, fourth paragraph: "option A and B" -> "options A and B" =20 Section 7, last paragraph, "activitiy" -> "activity" "attackes" -> "attacks" [Lizhong] all the nits are accepted. Thanks. =20 Regards Lizhong ------=_NextPart_000_002F_01CF59CD.3BD27610 Content-Type: text/html; boundary="----=_NextPart_000_0049_01CF599F.E104E420"; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Andy,

Thank you for the detail review. See my reply inline = below.

 

Regards

Lizhong

 

From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Andrew G. = Malis
Sent: 2014=E5=B9=B44=E6=9C=8815=E6=97=A5 18:45
To: rtg-ads@tools.ietf.org
Cc: l2vpn@ietf.org; rtg-dir@ietf.org; draft-ietf-l2vpn-vpls-inter-domain-redundancy.all@tools.ietf.org
Subject: [RTG-DIR] RtgDir review: draft-ietf-l2vpn-vpls-inter-domain-redundancy-05.txt

 

Hello,

 

I have been selected as the Routing Directorate = reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG = review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.iet= f.org/iesg/directorate/routing.html

 

Although these comments are primarily for the use = of the Routing ADs, it would be helpful if you could consider them along with = any other IETF Last Call comments that you receive, and strive to resolve = them through discussion or by updating the draft.

 

Document: draft-ietf-l2vpn-vpls-inter-domain-redundancy-05.txt

Reviewer: Andy Malis

Review Date: 15 April 2014

IETF LC End Date: 24 April 2014

Intended Status: Standards Track

 

Summary:

 

I have some minor concerns about this document that = I think should be resolved before publication. It also has editorial nits that = should be considered prior to publication.

 

Comments:

 

In general, I found the draft straightforward to = read and follow. It does require a working knowledge of = draft-ietf-pwe3-iccp-16.txt and RFC 6870, and it is a very good application of these two = specifications.

 

I noted that the only draft in the references (draft-ietf-pwe3-iccp-16.txt) is currently in the RFC Editor's = queue.

 

Major Issues:

 

No major issues found.

 

Minor Issues:

 

Section 5.3: The draft includes two variants of the = 3:1 protection model, referred to as options A and B. However, it does not = provide any criteria or guidelines for selection between the two either for code implementation or network operation. The draft should state whether one = or both are required for implementation (I would guess both) and how to choose = between them operationally (there are hints if you read between the lines, but = it should be explicit). It is also implied (but again not explicitly = stated) that both domains should choose the same option. That should be explicitly = stated, if correct, and should be repeated in Section 6.

[Lizhong] Thank you for pointing out this. This is the = missing part for a standard track draft.

The implementation MUST support option A, and MAY support = option B. Option B will be useful when the two legacy PEs in one domain does = not support the function in this document. The two legacy PEs still need to = support PW redundancy defined in [RFC 6870], but be configured as slave = node.

The Section 6 will be updated as = below:

When deploying the inter-domain redundancy mechanism = described in this document, some manual operation/negotiation is required to be = done correctly and securely.=C2=A0 For all the options described in section = 5.2 and 5.3, each node within one RG should be configured with same redundancy mode, and = both domains should choose the same option. For the two-PWs redundancy = options defined in section 5.2, the two operators should also negotiate to configure = same high/low PW priority at the two PW end-points.=C2=A0 If the = configuration consistency is broken, the inter-domain redundancy mechanism may not = work properly.

 

 

Section 6: This section provides two examples of = options that need to be provisioned identically within and/or between RGs for = proper operation. This should be a list of such options rather than just the = two examples.

[Lizhong] right, see the changes in the previous = comment.

 

Section 7, second paragraph: Should "could be secured" be "MAY be secured"?

[Lizhong] the security directorate points out that the = text of paragraph two and three conflicts with [I-D.ietf-pwe3-iccp] SC. Then I will = rephrase the section as below.

Besides the security properties of [I-D.ietf-pwe3-iccp] = for ICCP control plane, [RFC4762] and [RFC6870] for PW control plane, this = document will have additional security consideration for ICCP control = plane.

 

In this document, ICCP protocol is deployed between two = PEs or ASBRs. The two PEs or ASBRs should only be connected by a well managed = and highly monitored network. This should be ensured by the = operator.

 

The state flapping on the inter-domain and intra-domain pseudowire may cause security threats or be exploited to create denial = of service attacks.=C2=A0 For example, excessive pseudowire state flapping = (e.g., by malicious peer PE's implementation) may lead to excessive ICCP = exchanges. Implementations SHOULD provide mechanisms to perform control-plane = policing and mitigate such types of attacks.

 

 

Nits:

 

Section 1, last paragraph, "behaviour" = -> "behavior".

 

Section 3, fourth paragraph, "P2P" is = used without definition. As this is the only use in the document, I recommend = spelling it out to "point-to-point".

 

Section 4, third paragraph, "use-case" = -> "use case"

 

Section 5, second paragraph, I personally prefer "manual provisioning" instead of "manual operation", = but the current text is OK if the authors prefer it.

 

Section 5.1.3, "that is member" -> = "that is a member"

 

Section 5.3, fourth paragraph: "option A and = B" -> "options A and B"

 

Section 7, last paragraph, "activitiy" = -> "activity"

              =              "attackes" -> "attacks"

[Lizhong] all the nits are accepted. = Thanks.

 

Regards

Lizhong

------=_NextPart_000_002F_01CF59CD.3BD27610-- From nobody Wed Apr 16 10:42:52 2014 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 5D05E1A0284; Wed, 16 Apr 2014 10:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 2ggJoAJ8J-sJ; Wed, 16 Apr 2014 10:42:47 -0700 (PDT) Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) by ietfa.amsl.com (Postfix) with ESMTP id EA0E91A01FD; Wed, 16 Apr 2014 10:42:46 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id i50so4089607qgf.20 for ; Wed, 16 Apr 2014 10:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bKHlaQ2u/2Sj13BFFk116iMu57Y9ftvmD0nt8IC8M1E=; b=NG/QAItK200tAJRChEPTZN6+7WhMn/6bFPHEYLTCPNuMNDWtmsuKN3moKTk4Dvx6Oe IuyA7NeFXURPZE93dgq8bANP2ShJSHpDgPHkN24x30vF8OqGJRF1eSV/7UHLzVBX/NrO rllebRbVIJuGs0DVeekyK/0yMW7ZB6Op2Rkvb8oUUvAXE1sW9Xpd5inw2i+p+hKWH4nA SbRVk7FHe3bKF4YyO1gD+D/c6pgbTy8ZjmMH0sMX8neJATq3i6Vu6FqI00tMwNribUgz beyf7QcR7HMujJ3RihZPLeheC94ORy+LyIzBqsSXOWGg1BAzhd1GFMIDQBRsPXJaORxY 8bww== X-Received: by 10.140.16.37 with SMTP id 34mr11405380qga.37.1397670163602; Wed, 16 Apr 2014 10:42:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.205.69 with HTTP; Wed, 16 Apr 2014 10:42:23 -0700 (PDT) In-Reply-To: <534ea469.82e6440a.4410.0b83@mx.google.com> References: <534ea469.82e6440a.4410.0b83@mx.google.com> From: "Andrew G. Malis" Date: Wed, 16 Apr 2014 13:42:23 -0400 Message-ID: Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-l2vpn-vpls-inter-domain-redundancy-05.txt To: Lizhong Jin Content-Type: multipart/alternative; boundary=001a11c04ff69d60c504f72c718d Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/1dUjyPK60F3V4WoNV8Rx24dCc44 Cc: "l2vpn@ietf.org" , "rtg-dir@ietf.org" , draft-ietf-l2vpn-vpls-inter-domain-redundancy.all@tools.ietf.org, rtg-ads@tools.ietf.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: Wed, 16 Apr 2014 17:42:49 -0000 --001a11c04ff69d60c504f72c718d Content-Type: text/plain; charset=UTF-8 Lizhong, You're welcome! Continued inline, with unnecessary text trimmed ... Minor Issues: > > > > Section 5.3: The draft includes two variants of the 3:1 protection model, > referred to as options A and B. However, it does not provide any criteria > or guidelines for selection between the two either for code implementation > or network operation. The draft should state whether one or both are > required for implementation (I would guess both) and how to choose between > them operationally (there are hints if you read between the lines, but it > should be explicit). It is also implied (but again not explicitly stated) > that both domains should choose the same option. That should be explicitly > stated, if correct, and should be repeated in Section 6. > > [Lizhong] Thank you for pointing out this. This is the missing part for a > standard track draft. > > The implementation MUST support option A, and MAY support option B. Option > B will be useful when the two legacy PEs in one domain does not support the > function in this document. The two legacy PEs still need to support PW > redundancy defined in [RFC 6870], but be configured as slave node. > Andy: Are you going to update section 5.3 to include this text? The Section 6 will be updated as below: > > When deploying the inter-domain redundancy mechanism described in this > document, some manual operation/negotiation is required to be done > correctly and securely. For all the options described in section 5.2 and > 5.3, each node within one RG should be configured with same redundancy > mode, and both domains should choose the same option. For the two-PWs > redundancy options defined in section 5.2, the two operators should also > negotiate to configure same high/low PW priority at the two PW end-points. > If the configuration consistency is broken, the inter-domain redundancy > mechanism may not work properly. > Andy: Could you simplify this to: When deploying the inter-domain redundancy mechanism described in this document, consistent provisioning is required for proper operation. The two domains must both use the same use case (section 5.2 or section 5.3). Within each section, all of the described modes and options must be provisioned identically both within each RG and between the RGs. Additionally, for the two-PWs redundancy options defined in section 5.2, the two operators must also negotiate to configure same high/low PW priority at the two PW end-points. If the provisioning is inconsistent, then the inter-domain redundancy mechanism may not work properly. Cheers, Andy --001a11c04ff69d60c504f72c718d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Lizhong,

You're welcome! Continued = inline, with unnecessary text trimmed ...
<= br>

Minor Issues:

=

=C2=A0

Section 5.3: The draft includes two variants of the = 3:1 protection model, referred to as options A and B. However, it does not prov= ide any criteria or guidelines for selection between the two either for code implementation or network operation. The draft should state whether one or = both are required for implementation (I would guess both) and how to choose betw= een them operationally (there are hints if you read between the lines, but it should be explicit). It is also implied (but again not explicitly stated) t= hat both domains should choose the same option. That should be explicitly state= d, if correct, and should be repeated in Section 6.

[Lizhong] Thank you for pointing out t= his. This is the missing part for a standard track draft.

The implementation MUST support option A, an= d MAY support option B. Option B will be useful when the two legacy PEs in one domain does not support the function in this document. The two legacy PEs still need to sup= port PW redundancy defined in [RFC 6870], but be configured as slave node.


Andy: A= re you going to update section 5.3 to include this text?


The Section 6 will be updated as below:

When deploying the inter-domain redundancy m= echanism described in this document, some manual operation/negotiation is required to be done correctly and securely.=C2=A0 For all the options described in section 5.2 = and 5.3, each node within one RG should be configured with same redundancy mode, and both domains should choose the same option. For the two-PWs redundancy options d= efined in section 5.2, the two operators should also negotiate to configure same high/low PW priority at the two PW end-points.=C2=A0 If the configuration consistency is broken, the inter-domain redundancy mechanism may not work properly.

=C2=A0
Andy: Co= uld you simplify this to:

When deploying the inter= -domain redundancy mechanism described in this document, consistent provisi= oning is required for proper operation. The two domains must both use the s= ame use case (section 5.2 or section 5.3). Within each section, all of the = described modes and options must be provisioned identically both within eac= h RG and between the RGs. Additionally, for the two-PWs redundancy options = defined in section 5.2, the two operators must also negotiate to configure = same high/low PW priority at the two PW end-points. =C2=A0If the provisioni= ng is inconsistent, then the inter-domain redundancy mechanism may not work= properly.=C2=A0

Cheers,
Andy=C2=A0
--001a11c04ff69d60c504f72c718d-- From nobody Wed Apr 16 20:12:26 2014 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 7845F1A0401; Wed, 16 Apr 2014 20:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 GOh2SEwY0HZP; Wed, 16 Apr 2014 20:12:19 -0700 (PDT) Received: from mail-pb0-x22c.google.com (mail-pb0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 723081A0427; Wed, 16 Apr 2014 20:12:19 -0700 (PDT) Received: by mail-pb0-f44.google.com with SMTP id rp16so11614524pbb.17 for ; Wed, 16 Apr 2014 20:12:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=gNVhHc1T5YpasmuDi3dBXB8fNQAVckr0bJExrSYf2rY=; b=PfBt4x/fjkTXQu2hv5M5aB2uoW6bcXSgfsB8SuQ3wElCHr3fgmnp8PnLh4lw7+2lK0 ChfEL3DCpdjJABrBrznR92evJ78Rc1LZFm3ozuXp1kTgN0D94kCqyCXOTiaVYXZLz47h 3QpnnF19JrHSMIZNiuCZd54JNDmUGn/4Tq96SiIcC39U3gOxa5V0F2lkxxWyrRcySdgY EQJjSlN0iv8gXO5UsHZJCytl+0g6EYBQRurBn4znViVX4izuuIzBzW1Jut5bLPuSMEox xeVPuyq7ZwUwpTXB+tA5y06dh6ksXI5tZsf86VWo02bKrq+8zi1f/S8ygelWgTr+mP9u bvJQ== X-Received: by 10.68.113.5 with SMTP id iu5mr12607510pbb.60.1397704336108; Wed, 16 Apr 2014 20:12:16 -0700 (PDT) Received: from LIZHONGJ ([180.166.53.21]) by mx.google.com with ESMTPSA id te2sm119417976pac.25.2014.04.16.20.12.12 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 16 Apr 2014 20:12:14 -0700 (PDT) From: "Lizhong Jin" To: "'Andrew G. Malis'" References: <534ea469.82e6440a.4410.0b83@mx.google.com> In-Reply-To: Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-l2vpn-vpls-inter-domain-redundancy-05.txt Date: Thu, 17 Apr 2014 11:12:09 +0800 Message-ID: <00bb01cf59ea$d46daad0$7d490070$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BC_01CF5A2D.E2922350" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHtQIp7LE8eYs0PBkrzAVT3F51SwwDslhxbAc7xHq6aw3cn4A== Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/I76a7Gi6qxcVWjRXtzUW_riZhwE Cc: l2vpn@ietf.org, rtg-dir@ietf.org, draft-ietf-l2vpn-vpls-inter-domain-redundancy.all@tools.ietf.org, rtg-ads@tools.ietf.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: Thu, 17 Apr 2014 03:12:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00BC_01CF5A2D.E2922350 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Andy, See inline below. Thank you. =20 Regards Lizhong =20 From: Andrew G. Malis [mailto:agmalis@gmail.com]=20 Sent: 2014=E5=B9=B44=E6=9C=8817=E6=97=A5 1:42 To: Lizhong Jin Cc: rtg-ads@tools.ietf.org; l2vpn@ietf.org; rtg-dir@ietf.org; = draft-ietf-l2vpn-vpls-inter-domain-redundancy.all@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: = draft-ietf-l2vpn-vpls-inter-domain-redundancy-05.txt =20 Lizhong, =20 You're welcome! Continued inline, with unnecessary text trimmed ... =20 Minor Issues: =20 Section 5.3: The draft includes two variants of the 3:1 protection = model, referred to as options A and B. However, it does not provide any = criteria or guidelines for selection between the two either for code = implementation or network operation. The draft should state whether one = or both are required for implementation (I would guess both) and how to = choose between them operationally (there are hints if you read between = the lines, but it should be explicit). It is also implied (but again not = explicitly stated) that both domains should choose the same option. That = should be explicitly stated, if correct, and should be repeated in = Section 6. [Lizhong] Thank you for pointing out this. This is the missing part for = a standard track draft.=20 The implementation MUST support option A, and MAY support option B. = Option B will be useful when the two legacy PEs in one domain does not = support the function in this document. The two legacy PEs still need to = support PW redundancy defined in [RFC 6870], but be configured as slave = node. =20 Andy: Are you going to update section 5.3 to include this text? [Lizhong] yes. Or we could have another section =E2=80=9CBackward = compatibility=E2=80=9D to include the second sentence. Any suggestion? =20 =20 The Section 6 will be updated as below: When deploying the inter-domain redundancy mechanism described in this = document, some manual operation/negotiation is required to be done = correctly and securely. For all the options described in section 5.2 = and 5.3, each node within one RG should be configured with same = redundancy mode, and both domains should choose the same option. For the = two-PWs redundancy options defined in section 5.2, the two operators = should also negotiate to configure same high/low PW priority at the two = PW end-points. If the configuration consistency is broken, the = inter-domain redundancy mechanism may not work properly. =20 Andy: Could you simplify this to: =20 When deploying the inter-domain redundancy mechanism described in this = document, consistent provisioning is required for proper operation. The = two domains must both use the same use case (section 5.2 or section = 5.3). Within each section, all of the described modes and options must = be provisioned identically both within each RG and between the RGs. = Additionally, for the two-PWs redundancy options defined in section 5.2, = the two operators must also negotiate to configure same high/low PW = priority at the two PW end-points. If the provisioning is inconsistent, = then the inter-domain redundancy mechanism may not work properly.=20 [Lizhong] accepted, thank you. =20 Cheers, Andy=20 ------=_NextPart_000_00BC_01CF5A2D.E2922350 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Andy,

See inline below. Thank you.

 

Regards

Lizhong

 

From:= = Andrew G. Malis [mailto:agmalis@gmail.com]
Sent: = 2014=E5=B9=B44=E6=9C=8817=E6=97=A5 = 1:42
To: Lizhong Jin
Cc: rtg-ads@tools.ietf.org; = l2vpn@ietf.org; rtg-dir@ietf.org; = draft-ietf-l2vpn-vpls-inter-domain-redundancy.all@tools.ietf.org
Su= bject: Re: [RTG-DIR] RtgDir review: = draft-ietf-l2vpn-vpls-inter-domain-redundancy-05.txt

 

Lizhong,

 

You're welcome! Continued inline, with unnecessary = text trimmed ...

 

Minor = Issues:

 <= /o:p>

Section = 5.3: The draft includes two variants of the 3:1 protection model, = referred to as options A and B. However, it does not provide any = criteria or guidelines for selection between the two either for code = implementation or network operation. The draft should state whether one = or both are required for implementation (I would guess both) and how to = choose between them operationally (there are hints if you read between = the lines, but it should be explicit). It is also implied (but again not = explicitly stated) that both domains should choose the same option. That = should be explicitly stated, if correct, and should be repeated in = Section 6.

[Lizhong] Thank you for pointing out this. This is the missing part = for a standard track draft.

The implementation MUST support option A, and MAY support option B. = Option B will be useful when the two legacy PEs in one domain does not = support the function in this document. The two legacy PEs still need to = support PW redundancy defined in [RFC 6870], but be configured as slave = node.

 

Andy: Are you going to update section 5.3 to include = this text?

[Lizhong] yes. Or we could have another section =E2=80=9CBackward = compatibility=E2=80=9D to include the second sentence. Any = suggestion?

 

 

The Section 6 will be updated as below:

When deploying the inter-domain redundancy mechanism described in = this document, some manual operation/negotiation is required to be done = correctly and securely.  For all the options described in section = 5.2 and 5.3, each node within one RG should be configured with same = redundancy mode, and both domains should choose the same option. For the = two-PWs redundancy options defined in section 5.2, the two operators = should also negotiate to configure same high/low PW priority at the two = PW end-points.  If the configuration consistency is broken, the = inter-domain redundancy mechanism may not work = properly.

 

Andy: Could you simplify this = to:

 

When deploying the inter-domain redundancy mechanism = described in this document, consistent provisioning is required for = proper operation. The two domains must both use the same use case = (section 5.2 or section 5.3). Within each section, all of the described = modes and options must be provisioned identically both within each RG = and between the RGs. Additionally, for the two-PWs redundancy options = defined in section 5.2, the two operators must also negotiate to = configure same high/low PW priority at the two PW end-points.  If = the provisioning is inconsistent, then the inter-domain redundancy = mechanism may not work properly. 

[Lizhong] accepted, thank you.

 

Cheers,

Andy 

=
------=_NextPart_000_00BC_01CF5A2D.E2922350-- From nobody Wed Apr 16 20:58:20 2014 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 AB5171A0433; Wed, 16 Apr 2014 20:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 Q2uivdQu116W; Wed, 16 Apr 2014 20:58:11 -0700 (PDT) Received: from mail-qg0-x235.google.com (mail-qg0-x235.google.com [IPv6:2607:f8b0:400d:c04::235]) by ietfa.amsl.com (Postfix) with ESMTP id 3516C1A043C; Wed, 16 Apr 2014 20:58:11 -0700 (PDT) Received: by mail-qg0-f53.google.com with SMTP id f51so633188qge.26 for ; Wed, 16 Apr 2014 20:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=s1BupJX7cDK9aTdT8Dm6Ehc3MiN9lUp/RVSa5yNVrcc=; b=R245svcrvV39iBkJTn8cHE9GYcQEPfvN7qKBCmxyl9rm1hLvpQv1XbA2Y2miQGAQgx aNgJy0fG0nxweCX3wYeJoJYxOcBtLL2rbIIzc50OEta6HQkz9Q7nw9oa85rOd9VdAtCR +P3tUS2pN5llrHM0/ThMhmcEuCJIW578ziHBTmuIyw+8nmG29CEvtvYSMWpuG/bXrOsF I8GvGMIV1R5xku6aTRlDCNbzM8SoIWmupvyXpt1GXWygnYBvUr7LZdWcP5yN69SEVGOm YCUp9W0wIa5T+fp4ysIJVOqqH6afEGS3xfHGiE7H41RT8xyn2Hq/jqzfEtW0VZLK5dmd j9BA== X-Received: by 10.229.54.201 with SMTP id r9mr8650732qcg.6.1397707087614; Wed, 16 Apr 2014 20:58:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.205.69 with HTTP; Wed, 16 Apr 2014 20:57:47 -0700 (PDT) In-Reply-To: <00bb01cf59ea$d46daad0$7d490070$@gmail.com> References: <534ea469.82e6440a.4410.0b83@mx.google.com> <00bb01cf59ea$d46daad0$7d490070$@gmail.com> From: "Andrew G. Malis" Date: Wed, 16 Apr 2014 23:57:47 -0400 Message-ID: Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-l2vpn-vpls-inter-domain-redundancy-05.txt To: Lizhong Jin Content-Type: multipart/alternative; boundary=001a1135ef487518aa04f7350a75 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/It8nG1YT9fYT-Epo7di1EK4xZZE Cc: "l2vpn@ietf.org" , "rtg-dir@ietf.org" , draft-ietf-l2vpn-vpls-inter-domain-redundancy.all@tools.ietf.org, rtg-ads@tools.ietf.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: Thu, 17 Apr 2014 03:58:13 -0000 --001a1135ef487518aa04f7350a75 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Lizhong, I don't think you need a new section, just the new text in 5.3. Cheers, Andy On Wed, Apr 16, 2014 at 11:12 PM, Lizhong Jin wrote: > Hi Andy, > > See inline below. Thank you. > > > > Regards > > Lizhong > > > > *From:* Andrew G. Malis [mailto:agmalis@gmail.com] > *Sent:* 2014=E5=B9=B44=E6=9C=8817=E6=97=A5 1:42 > *To:* Lizhong Jin > *Cc:* rtg-ads@tools.ietf.org; l2vpn@ietf.org; rtg-dir@ietf.org; > draft-ietf-l2vpn-vpls-inter-domain-redundancy.all@tools.ietf.org > *Subject:* Re: [RTG-DIR] RtgDir review: > draft-ietf-l2vpn-vpls-inter-domain-redundancy-05.txt > > > > Lizhong, > > > > You're welcome! Continued inline, with unnecessary text trimmed ... > > > > Minor Issues: > > > > Section 5.3: The draft includes two variants of the 3:1 protection model, > referred to as options A and B. However, it does not provide any criteria > or guidelines for selection between the two either for code implementatio= n > or network operation. The draft should state whether one or both are > required for implementation (I would guess both) and how to choose betwee= n > them operationally (there are hints if you read between the lines, but it > should be explicit). It is also implied (but again not explicitly stated) > that both domains should choose the same option. That should be explicitl= y > stated, if correct, and should be repeated in Section 6. > > [Lizhong] Thank you for pointing out this. This is the missing part for a > standard track draft. > > The implementation MUST support option A, and MAY support option B. Optio= n > B will be useful when the two legacy PEs in one domain does not support t= he > function in this document. The two legacy PEs still need to support PW > redundancy defined in [RFC 6870], but be configured as slave node. > > > > Andy: Are you going to update section 5.3 to include this text? > > [Lizhong] yes. Or we could have another section =E2=80=9CBackward compati= bility=E2=80=9D > to include the second sentence. Any suggestion? > > > > > > The Section 6 will be updated as below: > > When deploying the inter-domain redundancy mechanism described in this > document, some manual operation/negotiation is required to be done > correctly and securely. For all the options described in section 5.2 and > 5.3, each node within one RG should be configured with same redundancy > mode, and both domains should choose the same option. For the two-PWs > redundancy options defined in section 5.2, the two operators should also > negotiate to configure same high/low PW priority at the two PW end-points= . > If the configuration consistency is broken, the inter-domain redundancy > mechanism may not work properly. > > > > Andy: Could you simplify this to: > > > > When deploying the inter-domain redundancy mechanism described in this > document, consistent provisioning is required for proper operation. The t= wo > domains must both use the same use case (section 5.2 or section 5.3). > Within each section, all of the described modes and options must be > provisioned identically both within each RG and between the RGs. > Additionally, for the two-PWs redundancy options defined in section 5.2, > the two operators must also negotiate to configure same high/low PW > priority at the two PW end-points. If the provisioning is inconsistent, > then the inter-domain redundancy mechanism may not work properly. > > [Lizhong] accepted, thank you. > > > > Cheers, > > Andy > --001a1135ef487518aa04f7350a75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Lizhong,

I don't think you need a n= ew section, just the new text in 5.3.

Cheers,
A= ndy


On Wed, Apr 16, 2014 at 11:12 PM, Lizhong Jin <lizho.jin@gmail.com= > wrote:

Hi Andy,

See inline below. Thank y= ou.

=C2=A0

Regards

Lizhong<= /u>

=C2=A0

From: Andrew G. Malis [mailto:agmalis@gmail.com]
Sent: 2014=E5=B9=B44=E6=9C= =8817=E6=97=A5 1:42
To: Lizhong Jin
Cc: rtg-ads@tools.ietf.org; l2vpn@ietf.org; rtg-dir@ietf.org; = draft-ietf-l2vpn-vpls-inter-domain-redundancy.all@tools.ietf.org
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-l2vpn-vpls-inter-do= main-redundancy-05.txt

=C2=A0

= Lizhong,

=C2=A0

You're welcome! Continued inline, with unnecessary text trim= med ...

=C2= =A0

Minor Issues:

=C2=A0

Section 5.3: The draft includes two variants of the 3:1 protecti= on model, referred to as options A and B. However, it does not provide any = criteria or guidelines for selection between the two either for code implem= entation or network operation. The draft should state whether one or both a= re required for implementation (I would guess both) and how to choose betwe= en them operationally (there are hints if you read between the lines, but i= t should be explicit). It is also implied (but again not explicitly stated)= that both domains should choose the same option. That should be explicitly= stated, if correct, and should be repeated in Section 6.

[Lizhong] Thank you= for pointing out this. This is the missing part for a standard track draft= .

The implementation MUST s= upport option A, and MAY support option B. Option B will be useful when the= two legacy PEs in one domain does not support the function in this documen= t. The two legacy PEs still need to support PW redundancy defined in [RFC 6= 870], but be configured as slave node.

<= /u>=C2=A0

Andy: Are you going to update section 5.3 to include this text?<= /u>

[Lizhong] yes. Or w= e could have another section =E2=80=9CBackward compatibility=E2=80=9D to in= clude the second sentence. Any suggestion?

=C2=A0

<= /div>

=C2=A0

The Section 6= will be updated as below:

When deploying the inter-= domain redundancy mechanism described in this document, some manual operati= on/negotiation is required to be done correctly and securely.=C2=A0 For all= the options described in section 5.2 and 5.3, each node within one RG shou= ld be configured with same redundancy mode, and both domains should choose = the same option. For the two-PWs redundancy options defined in section 5.2,= the two operators should also negotiate to configure same high/low PW prio= rity at the two PW end-points.=C2=A0 If the configuration consistency is br= oken, the inter-domain redundancy mechanism may not work properly.

=C2=A0

Andy: Could you simplify this to:

=C2=A0

When deploying the inter-domain redu= ndancy mechanism described in this document, consistent provisioning is req= uired for proper operation. The two domains must both use the same use case= (section 5.2 or section 5.3). Within each section, all of the described mo= des and options must be provisioned identically both within each RG and bet= ween the RGs. Additionally, for the two-PWs redundancy options defined in s= ection 5.2, the two operators must also negotiate to configure same high/lo= w PW priority at the two PW end-points. =C2=A0If the provisioning is incons= istent, then the inter-domain redundancy mechanism may not work properly.= =C2=A0

[Lizhong] accepted,= thank you.

=C2=A0

Cheers,

Andy=C2=A0


--001a1135ef487518aa04f7350a75-- From nobody Wed Apr 16 21:30:29 2014 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 1A1721A03FD; Wed, 16 Apr 2014 21:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no 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 2OTKG7VRVfMG; Wed, 16 Apr 2014 21:30:25 -0700 (PDT) Received: from mail-pd0-x230.google.com (mail-pd0-x230.google.com [IPv6:2607:f8b0:400e:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 59DE51A0339; Wed, 16 Apr 2014 21:30:25 -0700 (PDT) Received: by mail-pd0-f176.google.com with SMTP id r10so11560679pdi.35 for ; Wed, 16 Apr 2014 21:30:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=52iTatkHRA0TmX3ZErPv8fSS195Oddn/nmucXlrYri8=; b=JGESBZ891fwzckj1R1oJzyaux2eIM9nKybMJBSXA4/ag6HHJyUGS7aYoSlvi9d9ucn VM1qxl/Ku9Ysc7tYgv+oaPIPqh7KD2cB9enNwh0CY1iZFOIZ85E4A1+ng78lUN9/fGtF nMzejUrOz65BmqmvaTrNELRAP/gyIoAkRr0le0p8StdH+1tpJtBM+BZgnTAPUbq+WZP0 +1kJiGcPjylRW4JfxENw0O3ZbLEYSXCgSIczncwZWiwGd5uTKTQCA6ou49bNeEqfNUuj k6OhdEuYuFF5goeUcwJJQXNyTL8MTAWEnYGDl9F51s9WVyRf98V5PWzq2k+8Gqfb0jb9 Yv4g== X-Received: by 10.68.212.10 with SMTP id ng10mr12921871pbc.95.1397709022061; Wed, 16 Apr 2014 21:30:22 -0700 (PDT) Received: from LIZHONGJ ([180.166.53.21]) by mx.google.com with ESMTPSA id bs17sm91914800pac.28.2014.04.16.21.30.19 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 16 Apr 2014 21:30:21 -0700 (PDT) From: "Lizhong Jin" To: "'Andrew G. Malis'" References: <534ea469.82e6440a.4410.0b83@mx.google.com> <00bb01cf59ea$d46daad0$7d490070$@gmail.com> In-Reply-To: Subject: RE: [RTG-DIR] RtgDir review: draft-ietf-l2vpn-vpls-inter-domain-redundancy-05.txt Date: Thu, 17 Apr 2014 12:30:17 +0800 Message-ID: <00ea01cf59f5$be0ac470$3a204d50$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EB_01CF5A38.CC3138C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHtQIp7LE8eYs0PBkrzAVT3F51SwwDslhxbAc7xHq4DFE8QegJaqFkampgWUEA= Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/cy07Q7oCWdtTN5XtNrDvcVny7Rk Cc: l2vpn@ietf.org, rtg-dir@ietf.org, draft-ietf-l2vpn-vpls-inter-domain-redundancy.all@tools.ietf.org, rtg-ads@tools.ietf.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: Thu, 17 Apr 2014 04:30:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00EB_01CF5A38.CC3138C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable OK, thanks. =20 Regards Lizhong =20 From: Andrew G. Malis [mailto:agmalis@gmail.com]=20 Sent: 2014=E5=B9=B44=E6=9C=8817=E6=97=A5 11:58 To: Lizhong Jin Cc: rtg-ads@tools.ietf.org; l2vpn@ietf.org; rtg-dir@ietf.org; = draft-ietf-l2vpn-vpls-inter-domain-redundancy.all@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: = draft-ietf-l2vpn-vpls-inter-domain-redundancy-05.txt =20 Lizhong, =20 I don't think you need a new section, just the new text in 5.3. =20 Cheers, Andy =20 On Wed, Apr 16, 2014 at 11:12 PM, Lizhong Jin = wrote: Hi Andy, See inline below. Thank you. =20 Regards Lizhong =20 From: Andrew G. Malis [mailto:agmalis@gmail.com]=20 Sent: 2014=E5=B9=B44=E6=9C=8817=E6=97=A5 1:42 To: Lizhong Jin Cc: rtg-ads@tools.ietf.org; l2vpn@ietf.org; rtg-dir@ietf.org; = draft-ietf-l2vpn-vpls-inter-domain-redundancy.all@tools.ietf.org Subject: Re: [RTG-DIR] RtgDir review: = draft-ietf-l2vpn-vpls-inter-domain-redundancy-05.txt =20 Lizhong, =20 You're welcome! Continued inline, with unnecessary text trimmed ... =20 Minor Issues: =20 Section 5.3: The draft includes two variants of the 3:1 protection = model, referred to as options A and B. However, it does not provide any = criteria or guidelines for selection between the two either for code = implementation or network operation. The draft should state whether one = or both are required for implementation (I would guess both) and how to = choose between them operationally (there are hints if you read between = the lines, but it should be explicit). It is also implied (but again not = explicitly stated) that both domains should choose the same option. That = should be explicitly stated, if correct, and should be repeated in = Section 6. [Lizhong] Thank you for pointing out this. This is the missing part for = a standard track draft.=20 The implementation MUST support option A, and MAY support option B. = Option B will be useful when the two legacy PEs in one domain does not = support the function in this document. The two legacy PEs still need to = support PW redundancy defined in [RFC 6870], but be configured as slave = node. =20 Andy: Are you going to update section 5.3 to include this text? [Lizhong] yes. Or we could have another section =E2=80=9CBackward = compatibility=E2=80=9D to include the second sentence. Any suggestion? =20 =20 The Section 6 will be updated as below: When deploying the inter-domain redundancy mechanism described in this = document, some manual operation/negotiation is required to be done = correctly and securely. For all the options described in section 5.2 = and 5.3, each node within one RG should be configured with same = redundancy mode, and both domains should choose the same option. For the = two-PWs redundancy options defined in section 5.2, the two operators = should also negotiate to configure same high/low PW priority at the two = PW end-points. If the configuration consistency is broken, the = inter-domain redundancy mechanism may not work properly. =20 Andy: Could you simplify this to: =20 When deploying the inter-domain redundancy mechanism described in this = document, consistent provisioning is required for proper operation. The = two domains must both use the same use case (section 5.2 or section = 5.3). Within each section, all of the described modes and options must = be provisioned identically both within each RG and between the RGs. = Additionally, for the two-PWs redundancy options defined in section 5.2, = the two operators must also negotiate to configure same high/low PW = priority at the two PW end-points. If the provisioning is inconsistent, = then the inter-domain redundancy mechanism may not work properly.=20 [Lizhong] accepted, thank you. =20 Cheers, Andy=20 =20 ------=_NextPart_000_00EB_01CF5A38.CC3138C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

OK, thanks.

 

Regards

Lizhong

 

From:= = Andrew G. Malis [mailto:agmalis@gmail.com]
Sent: = 2014=E5=B9=B44=E6=9C=8817=E6=97=A5 = 11:58
To: Lizhong Jin
Cc: rtg-ads@tools.ietf.org; = l2vpn@ietf.org; rtg-dir@ietf.org; = draft-ietf-l2vpn-vpls-inter-domain-redundancy.all@tools.ietf.org
Su= bject: Re: [RTG-DIR] RtgDir review: = draft-ietf-l2vpn-vpls-inter-domain-redundancy-05.txt

 

Lizhong,

 

I = don't think you need a new section, just the new text in = 5.3.

 

Cheers,
Andy

 

On Wed, Apr 16, 2014 at 11:12 PM, Lizhong Jin <lizho.jin@gmail.com> = wrote:

Hi Andy,

See inline below. Thank you.

 

Regards

Lizhong

 

From:= = Andrew G. Malis [mailto:agmalis@gmail.com]
Sent: = 2014=E5=B9=B44=E6=9C=8817=E6=97=A5 = 1:42
To: Lizhong Jin
Cc: rtg-ads@tools.ietf.org; l2vpn@ietf.org; rtg-dir@ietf.org; = draft-ietf-l2vpn-vpls-inter-domain-redundancy.all@tools= .ietf.org
Subject: Re: [RTG-DIR] RtgDir review: = draft-ietf-l2vpn-vpls-inter-domain-redundancy-05.txt

 <= /o:p>

Lizhong,

 <= /o:p>

You're = welcome! Continued inline, with unnecessary text trimmed = ...

 <= /o:p>

Minor = Issues:

 <= /o:p>

Section = 5.3: The draft includes two variants of the 3:1 protection model, = referred to as options A and B. However, it does not provide any = criteria or guidelines for selection between the two either for code = implementation or network operation. The draft should state whether one = or both are required for implementation (I would guess both) and how to = choose between them operationally (there are hints if you read between = the lines, but it should be explicit). It is also implied (but again not = explicitly stated) that both domains should choose the same option. That = should be explicitly stated, if correct, and should be repeated in = Section 6.

[Lizhong] Thank you for pointing out this. This is the missing part = for a standard track draft.

The implementation MUST support option A, and MAY support option B. = Option B will be useful when the two legacy PEs in one domain does not = support the function in this document. The two legacy PEs still need to = support PW redundancy defined in [RFC 6870], but be configured as slave = node.

 <= /o:p>

Andy: Are = you going to update section 5.3 to include this = text?

[Lizhong] yes. Or we could have another section =E2=80=9CBackward = compatibility=E2=80=9D to include the second sentence. Any = suggestion?

 <= /o:p>

 <= /o:p>

The Section 6 will be updated as below:

When deploying the inter-domain redundancy mechanism described in = this document, some manual operation/negotiation is required to be done = correctly and securely.  For all the options described in section = 5.2 and 5.3, each node within one RG should be configured with same = redundancy mode, and both domains should choose the same option. For the = two-PWs redundancy options defined in section 5.2, the two operators = should also negotiate to configure same high/low PW priority at the two = PW end-points.  If the configuration consistency is broken, the = inter-domain redundancy mechanism may not work = properly.

 <= /o:p>

Andy: Could = you simplify this to:

 <= /o:p>

When = deploying the inter-domain redundancy mechanism described in this = document, consistent provisioning is required for proper operation. The = two domains must both use the same use case (section 5.2 or section = 5.3). Within each section, all of the described modes and options must = be provisioned identically both within each RG and between the RGs. = Additionally, for the two-PWs redundancy options defined in section 5.2, = the two operators must also negotiate to configure same high/low PW = priority at the two PW end-points.  If the provisioning is = inconsistent, then the inter-domain redundancy mechanism may not work = properly. 

[Lizhong] accepted, thank you.

 <= /o:p>

Cheers,=

Andy 

 

------=_NextPart_000_00EB_01CF5A38.CC3138C0-- From nobody Mon Apr 21 12:15:05 2014 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 4A3971A0245; Mon, 21 Apr 2014 12:15:02 -0700 (PDT) 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 fBbwIe3fPfr2; Mon, 21 Apr 2014 12:15:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 262861A0251; Mon, 21 Apr 2014 12:15:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l2vpn-spbm-evpn-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.3.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140421191501.10633.80373.idtracker@ietfa.amsl.com> Date: Mon, 21 Apr 2014 12:15:01 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/Vpmbp11E3y-CDwJo1uzLjYRZqbw 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: Mon, 21 Apr 2014 19:15:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : Shortest Path Bridging, MAC mode Support over EVPN Authors : Dave Allan Jeff Tantsura Don Fedyk Ali Sajassi Filename : draft-ietf-l2vpn-spbm-evpn-01.txt Pages : 10 Date : 2014-04-21 Abstract: This document describes how Ethernet Shortest Path Bridging MAC mode (802.1aq) can be combined with EVPN in a way that interworks with PBB-PEs as described in the PBB-EVPN solution. This is achieved via operational isolation of each Ethernet network subtending an EVPN core while supporting full interworking between the different variations of Ethernet networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-spbm-evpn/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-spbm-evpn-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-l2vpn-spbm-evpn-01 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 nobody Thu Apr 24 08:05:06 2014 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 D1DD11A0332; Thu, 24 Apr 2014 08:05:03 -0700 (PDT) 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 LDMGemIMw8tb; Thu, 24 Apr 2014 08:05:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 28D3E1A0357; Thu, 24 Apr 2014 08:04:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l2vpn-vpls-inter-domain-redundancy-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140424150455.3204.18831.idtracker@ietfa.amsl.com> Date: Thu, 24 Apr 2014 08:04:55 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/4KptrtO5yCirRU3OwLWaO_ufZA8 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: Thu, 24 Apr 2014 15:05:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : Redundancy Mechanism for Inter-domain VPLS Service Authors : Zhihua Liu Lizhong Jin Ran Chen Dennis Cai Samer Salam Filename : draft-ietf-l2vpn-vpls-inter-domain-redundancy-06.txt Pages : 11 Date : 2014-04-24 Abstract: In many existing Virtual Private LAN Service (VPLS) inter-domain deployments (based on RFC 4762), pseudowire (PW) connectivity offers no node redundancy, or offers node redundancy only with a single domain. This deployment approach incurs a high risk of service interruption, since at least one domain will not offer PW node redundancy. This document describes an inter-domain VPLS solution that provides PW node redundancy across domains. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-vpls-inter-domain-redundancy/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-inter-domain-redundancy-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-l2vpn-vpls-inter-domain-redundancy-06 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 nobody Tue Apr 29 13:34:35 2014 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 DE8AC1A09C2; Tue, 29 Apr 2014 13:34:29 -0700 (PDT) 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 VEJ91TtcHXx7; Tue, 29 Apr 2014 13:34:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1E61A09C4; Tue, 29 Apr 2014 13:34:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org Subject: I-D Action: draft-ietf-l2vpn-vpls-pim-snooping-06.txt X-Test-IDTracker: no X-IETF-IDTracker: 5.4.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140429203422.14260.12719.idtracker@ietfa.amsl.com> Date: Tue, 29 Apr 2014 13:34:22 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/3rfYqFdh7XqSHA8LA2K73DWHJLg 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: Tue, 29 Apr 2014 20:34:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Layer 2 Virtual Private Networks Working Group of the IETF. Title : PIM Snooping over VPLS Authors : Olivier Dornon Jayant Kotalwar Venu Hemige Ray Qiu Filename : draft-ietf-l2vpn-vpls-pim-snooping-06.txt Pages : 40 Date : 2014-04-29 Abstract: This document describes the procedures and recommendations for VPLS PEs to facilitate replication of multicast traffic to only certain ports (behind which there are interested PIM routers and/or IGMP hosts) via PIM Snooping and PIM Proxy. With PIM Snooping, PEs passively listen to certain PIM control messages to build control and forwarding states while transparently flooding those messages. With PIM Proxy, PEs do not flood PIM Join/ Prune messages but only generate their own and send out of certain ports, based on the control states built from downstream Join/Prune messages. PIM Proxy is required when PIM Join suppression is enabled on the CE devices and useful to reduce PIM control traffic in a VPLS domain. The document also describes PIM Relay, which can be viewed as light- weight proxy, where all downstream Join/Prune messages are simply forwarded out of certain ports but not flooded to avoid triggering PIM Join suppression on CE devices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-l2vpn-vpls-pim-snooping/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-l2vpn-vpls-pim-snooping-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-l2vpn-vpls-pim-snooping-06 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/