From nobody Mon Apr 1 00:47:49 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5760C12008B; Mon, 1 Apr 2019 00:47:47 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 GXksq8UiBRKN; Mon, 1 Apr 2019 00:47:45 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68852120086; Mon, 1 Apr 2019 00:47:45 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id k189so5037428qkc.0; Mon, 01 Apr 2019 00:47:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=rAlAH3tZz0jBY4aSV+/dyVtb/WZgFlGqN63ygx+EVD4=; b=fdAWKTHXz1V4p0MzXChIsb5suRpVfcGiZ5cQnmGa3f5zbs3B789SRzWfLRgaYLJoo8 6R7iqAmPM+MHZUJwF4nBtbZ/2luOhk6SAmQ/US8DHDeJrfPkrnJSpbAzPkgM+G6zZzWR EXUQMDNzyruA8ZBaCRtUF8icj54D5pYKe4zesuNeYcPLaxzLniccWC2LqVFHfYS2kHew f2nLsEOjWijDbZNpHOVrliNdqSvcM8IWiUFVPchqy5tkxaWTsjQa67cjeKQtSdo6GbaL pdbSzFpUKbfXdyi5gSXgz+MoGo0y/EvWIIUcmGR59p5FurzZJjdUcNrk59F3XAr8iAbz ZYxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=rAlAH3tZz0jBY4aSV+/dyVtb/WZgFlGqN63ygx+EVD4=; b=cGp+e+60bBZyHhImJmW/ovvnRIRsODvtlyfMcNsytwSXCxZjkvi0rOvLr/D+SFcfkv cEW+QMtoZ81ZefMHiHsuZEK3xYPe3jDvPHS6rOMp4lio2i7axvitBzBgGsQn8wVoiceD wsmi58mcPd+bO5F0p2PNctIk/3LkBoTuENPaGA2s3xPUhJXVwFtVx88yp19z/k59sA4g /hUFCTEeEE127yjNKNqR1pg4WyjjoQ6vaeaPEzuPcuRIYmTw5zCd56KyGCbEBpGTiC5i vQCxj4y3/5WNu6p3Nf5tUry5T03ouM0LryXoOQWvHxdJKuN+WbkyuAzUE/CsmQWzvWY8 pL8g== X-Gm-Message-State: APjAAAWg5NMq30U86449iq11K3b1rgz7e6EvHfLPfu56Dl8SH/1KwKzp exZYJ+CI6J4y6+lOnlZs0sQ+igrHpa2T7XPMhxP/X6GVIBo= X-Google-Smtp-Source: APXvYqw1qrIVb4P5zzUY68+/3Eh9uRo1nph68lPatcFzxgWa3elAi0pvTsDYxm6vuhYDc76RzTr/BA5FcAOYagD3hIE= X-Received: by 2002:ae9:f70e:: with SMTP id s14mr21465920qkg.259.1554104864332; Mon, 01 Apr 2019 00:47:44 -0700 (PDT) MIME-Version: 1.0 From: Tal Mizrahi Date: Mon, 1 Apr 2019 10:47:33 +0300 Message-ID: To: IETF IPPM WG , Greg Mirsky , guo.jun2@zte.com.cn, hnydell@accedian.com, footer.foote@nokia.com Cc: ippm-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000061e0340585733cfe" Archived-At: Subject: [ippm] IPR Poll for draft-ietf-ippm-stamp-05 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 07:47:48 -0000 --00000000000061e0340585733cfe Content-Type: text/plain; charset="UTF-8" Hi, This email begins a two-week poll for any IPRs that may apply to draft-ietf-ippm-stamp-05. Are you aware of any IPR that applies to draft-ietf-ippm-stamp-05? Specifically, if you are listed as a document author or contributor, please respond to this email (reply-to-all) stating whether or not you are aware of any relevant IPR. If you are aware of a relevant IPR, please state whether this IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). This poll closes on the 15th of April 2019. Best regards, Tal. [As shepherd of draft-ietf-ippm-stamp] --00000000000061e0340585733cfe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

This email begins a two-week po= ll for any IPRs that may apply to draft-ietf-ippm-stamp-05.

<= /div>
Are you aware of any IPR that applies to draft-ietf-ippm-stamp-05= ?=C2=A0

Specifically, if you are listed as a docum= ent author or contributor, please respond to this email (reply-to-all) stat= ing whether or not you are aware of any relevant IPR.

<= div>If you are aware of a relevant IPR, please state whether this IPR has b= een disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 = and 5378 for more details).

This poll closes on th= e 15th of April 2019.

Best regards,
Tal.=
[As shepherd of=C2=A0draft-ietf-ippm-stamp]
--00000000000061e0340585733cfe-- From nobody Mon Apr 1 04:16:34 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73EF31200FD; Mon, 1 Apr 2019 04:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 QnLSzDT2zPTH; Mon, 1 Apr 2019 04:16:29 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34C7712011E; Mon, 1 Apr 2019 04:16:29 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 0BF64B0; Mon, 1 Apr 2019 13:16:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1554117386; bh=ZeZqsp91NOk0wuvXkoCeCynKnYf+WNmAr0EgCd6Lf54=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=AcO/Xxg4+I6qyByUxBVJ5rdVKWvHItGzsoVyYcfdO8mzV8xqpz0NBX6hT/8xnQMAy fqIQUOr1yYTlnvS6SNGx1CliP3QrszGp3T4UBTcmdAS5ObF16QQwQKBQIaoEfAU3zU o6OU+dwLC/DSsK0cK8HbF6TY6q0O8QcV9lMDCSgg= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 09D30AF; Mon, 1 Apr 2019 13:16:26 +0200 (CEST) Date: Mon, 1 Apr 2019 13:16:26 +0200 (CEST) From: Mikael Abrahamsson To: "Frank Brockners (fbrockne)" cc: Mark Smith , "C. M. Heard" , 6man WG , "ippm@ietf.org" In-Reply-To: Message-ID: References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 11:16:33 -0000 On Thu, 28 Mar 2019, Frank Brockners (fbrockne) wrote: > > FYI - A new draft including Mark's comments below just got posted: > https://tools.ietf.org/html/draft-ioametal-ippm-6man-ioam-ipv6-deployment-01 I watched the tech deep dive video recording in conjunction with this. This is a really hard problem to solve with all those factors to take into account. Some random thoughts: There seems to be overlap of this problem space with SRv6, these seem to have almost identical properties. They insert something, the forwarding devices need to interact with it and it needs to be stripped before it leaves the domain. Though, in the SRv6 space the forwarding information is in the header, whereas for the IOAM space the forwarding device should actually ignore whatever is in the IOAM header as the desire is for it to treat packets identically regardless if they have the header or not. Considering how routers forward packets based on 5-tuple (or even deeper), what's the thinking been on this so far? The MTU issue should be the least problematic, recommendations on using a considerable higher MTU on the internal links compared to the external links is identical to what has been used for encapsulation networks for a long time. We use 9180 IP MTU on the internal links and external links are 9000 MTU. This leaves room for several layers of encap without affecting the customer visible MTU. I like the fact that the IOAM information is attached to the real packet being forwarded as opposed to just using test traffic. I think the C1-C6 requirements make a lot of sense, but following them is hard. I have myself run networks that ran IPv4 and IPv6 Internet packets native (no encap) internally, and only encapsulated VPN overlay packets. It'd of course be nice to support IOAM also for those deployment scenarios, but then it becomes harder to assure no leakage (C5) and identifying the leaker. Otoh when doing MPLS if you leak labeled packets they are probably dropped at the other end (do we have research on this?). So leaking IOAM enabled packets might be less of a disaster compared to other encaps? Doing IOAM only based on some other forwarding scheme (MPLS, SRv6 etc) and embedding meaning into whatever forwarding information is used for that might help (IOAM information lives within that forwarding plane), but also makes IOAM less deployable for other networks that just run native. Reading https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-05 and considering the C5 requirement, how do I as an end receiver of a packet with an IOAM header in it identify even what operator to contact about these leaked packets? It looks like the namespace/identifier is operator-internal, but how do I identify what operator it is? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Apr 1 05:03:05 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A242C12010F for ; Mon, 1 Apr 2019 05:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.87 X-Spam-Level: X-Spam-Status: No, score=-1.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_KAM_HTML_FONT_INVALID=0.01, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=accedian-com.20150623.gappssmtp.com 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 hrvwGjXTTfHT for ; Mon, 1 Apr 2019 05:03:01 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9389912010C for ; Mon, 1 Apr 2019 05:03:00 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id r24so7882464ljg.3 for ; Mon, 01 Apr 2019 05:03:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=accedian-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9gD2/9v/t/cCbqlBKw4pansdMnGLlqC3nqz5XWOl790=; b=kPEFgo9xcVnXxHnaXZ+7Ifg3vIjFM4A5nScHtmRd18YXWYigUC1f/1sxdFCbZvrHXN W8a3u9YYB417X8rVvYGg2A6XTQwsQjfy5WhBwf+B1kpaqxe2HfQ3mL7ldeCpAOvrwNAd knlpjWzpygSZ/B3mCenzqxgXaQBSur6Nv02yoDT6Iao2ogzdlpEDJLZWb+OagqS9x/mD /xs2iOMNEbIIvAdcc1eJ+Db+ladRlC1PZ38vfGfORXZ3hQcOfE44OmJgPl371VNvEUW4 3bZIw1j950i7yxbrAYxd3zbGAniuS3lPP4uGyzZl4UHCV5b/02e89IzPY8tO8ZCACcAg dz0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9gD2/9v/t/cCbqlBKw4pansdMnGLlqC3nqz5XWOl790=; b=LL4KMZHHLy0RSNSp3Nl8MRV3h3XQsiv8q8X+4H6OFTpUqT0yOfo224a7lhQk+bUI66 LEb5fbpLtCfNilCGtoLKZlQh/ADT3ICcDKnoq+nJxsmvKpkje65RYRjmr5P3su3qo2Xb C0bpOxP64zUJ8Jlz8W41j2710+n68fvS5qknGk64ZnEnANxUCaGLNF32W/G8BkdF+bLk 42qNTEyLxZZmPloBdstbk6a6YS8PLUH8TRWhQWawqCv8ugYxVpJGGs1VxI/uKtwTLUyD +ntdzq6TceKpoq/1Tj4pmWQwpg+eD5uWSAKVj/GpoaFTfjnGR1dta2ZxbbfD79X8Ofxp 9KpQ== X-Gm-Message-State: APjAAAXCCmFzq3n1i4fhcvOGPmPTaAy44VFbRWcYyv97BDyl/Vcy8upI kb2dMnDyeoyPJGZc2Y3zifPDqUpNFi3g15kMg8RXxaoB6K65gI5Ryv6cVGgLbVi5KqCuuegN944 KoWTCVQHKWQ== X-Google-Smtp-Source: APXvYqyAfwhmWlzXIgpkOnVD6HGwrbhu1r40aOAWdT5nUTKsHfQm6R5i8tKQTAPbm6QQ3G/sO9krpx1J1oWUDIjWKhQ= X-Received: by 2002:a2e:91cb:: with SMTP id u11mr30978026ljg.64.1554120178731; Mon, 01 Apr 2019 05:02:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Henrik Nydell Date: Mon, 1 Apr 2019 14:02:48 +0200 Message-ID: To: Tal Mizrahi Cc: IETF IPPM WG , Greg Mirsky , guo.jun2@zte.com.cn, "Foote, Footer (Nokia - CA)" , ippm-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000312106058576cdfa" Archived-At: Subject: Re: [ippm] IPR Poll for draft-ietf-ippm-stamp-05 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 12:03:04 -0000 --000000000000312106058576cdfa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have checked the draft-05, and as a co-author there is no IPR that I'm aware of related to this draft. On Mon, Apr 1, 2019 at 9:47 AM Tal Mizrahi wrote: > Hi, > > This email begins a two-week poll for any IPRs that may apply to > draft-ietf-ippm-stamp-05. > > Are you aware of any IPR that applies to draft-ietf-ippm-stamp-05? > > Specifically, if you are listed as a document author or contributor, > please respond to this email (reply-to-all) stating whether or not you ar= e > aware of any relevant IPR. > > If you are aware of a relevant IPR, please state whether this IPR has bee= n > disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 an= d > 5378 for more details). > > This poll closes on the 15th of April 2019. > > Best regards, > Tal. > [As shepherd of draft-ietf-ippm-stamp] > --=20 [image: Accedian.com] Henrik Nydell Sr Product Manager SkyLIGHT Solutions Cell Email Skype +46 709845992 hnydell@accedian.com h nydell --=20 Avis de confidentialit=C3=A9 Les informations contenues dans le pr=C3=A9sent=20 message et dans toute pi=C3=A8ce qui=20 lui est jointe sont confidentielles et=20 peuvent =C3=AAtre prot=C3=A9g=C3=A9es par le=20 secret professionnel. Ces informations sont=20 =C3=A0 l=E2=80=99usage exclusif de son ou de ses destinataires. Si vous recevez ce=20 message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement=20 avec l=E2=80=99exp=C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est=20 strictement interdit de=20 le divulguer, de le distribuer ou de le reproduire=20 sans l=E2=80=99autorisation=20 de l=E2=80=99exp=C3=A9diteur. Merci. Confidentiality notice This e-mail message and any attachment hereto contain confidential=20 information=20 which may be privileged and which is intended for the=20 exclusive use of its=20 addressee(s). If you receive this message in error, please inform sender=20 immediately and destroy any copy thereof.=20 Furthermore, any disclosure,=20 distribution or copying of this message=20 and/or any attachment hereto=20 without the consent of the sender is=20 strictly prohibited. Thank you. --000000000000312106058576cdfa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have checked the draft-05, and as a co-= author there is no IPR that I'm aware of related to this draft.

On Mon, Apr 1, 2019 at 9:47 AM Tal Mizrahi <tal.mizrahi.phd@gmail.com> wrote:
Hi,
This email begins a two-week poll for any IPRs that may apply = to draft-ietf-ippm-stamp-05.

Are you aware of any = IPR that applies to draft-ietf-ippm-stamp-05?=C2=A0

Specifically, if you are listed as a document author or contributor, plea= se respond to this email (reply-to-all) stating whether or not you are awar= e of any relevant IPR.

If you are aware of a relev= ant IPR, please state whether this IPR has been disclosed in compliance wit= h IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

This poll closes on the 15th of April 2019.

Best regards,
Tal.
[As shepherd of=C2= =A0draft-ietf-ippm-stamp]


--


<= col width=3D"211">

Henrik Nydell

Sr Product Ma= nager SkyLIGHT Solutions

3D"Accedian.com"


Cell

Email

Skype

+46 709845992

hnydell@accedian.com

hn= ydell



<= /a> =C2=A0 =C2=A0 =C2=A0<= span style=3D"font-size:11pt;font-family:Calibri;color:rgb(17,85,204);text-= decoration:underline;vertical-align:baseline;white-space:pre-wrap"> =C2=A0


<= /p>



Avis de confidentialit=C3=A9

Les informations contenues dans le pr=C3=A9sent message et dans toute pi=C3=A8= ce qui=20 lui est jointe sont confidentielles et peuvent =C3=AAtre prot=C3=A9g=C3=A9e= s par le=20 secret professionnel. Ces informations sont =C3=A0 l=E2=80=99usage exclusif= de son ou de ses destinataires. Si vous recevez ce message par erreur, veuillez=20 s=E2=80=99il vous plait communiquer imm=C3=A9diatement avec l=E2=80=99exp= =C3=A9diteur et en=20 d=C3=A9truire tout exemplaire. De plus, il vous est strictement interdit de= =20 le divulguer, de le distribuer ou de le reproduire sans l=E2=80=99autorisat= ion=20 de l=E2=80=99exp=C3=A9diteur. Merci.

Confidentiality notice

This e-mail message and any attachment hereto contain confidential=20 information which may be privileged and which is intended for the=20 exclusive use of its addressee(s). If you receive this message in error, please inform sender immediately and destroy any copy thereof.=20 Furthermore, any disclosure, distribution or copying of this message=20 and/or any attachment hereto without the consent of the sender is=20 strictly prohibited. Thank you.

--000000000000312106058576cdfa-- From nobody Mon Apr 1 07:09:36 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539A3120159; Mon, 1 Apr 2019 07:09:34 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 CrxNeBss3boz; Mon, 1 Apr 2019 07:09:32 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B2D212014E; Mon, 1 Apr 2019 07:09:32 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id j89so8308438ljb.1; Mon, 01 Apr 2019 07:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GxsU4/meGCovfQP//gnJjnYbQZOD8vFio58bzFIxECA=; b=ZiQM0Zg+zxQ4j9i/tePXic2Co0aCmoqzxBrJJoqJJiGbRKvkciVJEW942j6TL7/KQq JtjZtNlmNWyjncEXoYVUXCEetQnJif1UVDIFdGvBLX9x9sO8Aa+0CfxVb4eWmPSZYVgG 6MLFECJw9ooUYH4FjQ3LfbW6IwIQAh999iPSYxdXfLgYVKUDpDsUhH2nmiLA2JI/d06c sttpZ+Zd07Y8UurerUAHO8ws9zwwoXl3kLCrjUw+vSMWQyNBVESplrYa4e+7ZiT5TQA+ 8cMGHDiFk5sDXslCgrKBO320dV6i57bXS8a0z8J+CVBuyi+z0TSqocAp5C1QKQxK4K0z hBXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GxsU4/meGCovfQP//gnJjnYbQZOD8vFio58bzFIxECA=; b=kyNFCBMwANmHvZee6Jatqlc0pprU9eyLZn3GGq4f3NKHfu/UvcJ+wTaG8AXr5hKY25 T6dPjs/K3W/tcAHFgm9wQyxufYRFCWJPY1L2/TUbktqj2AGuunJrf562VCBn68TAuCsd WW+xmQokB4vblYeLM5Hi9ZoM03WJh1cOP6oyr7OjaFB9GmwLGdaeE/xNxXFBmzHlJlzr FBZPfARYwix6onJNal4VzudvwOvDHRXc8XE8onwZkkOCXLBFA5qCr22RhNwDpKTTMrR6 W7TnihlEMd4N7wARyQlV6RCIGJDVaS2VleowH6dd7SoTW5NKBqDl/3Nam+8uIKGnJZyU BELQ== X-Gm-Message-State: APjAAAXpJl4t6gnKONA9tAtSZHa4FcIgtplEPN5nKBralEuQmkXo6sVZ nyNdApXGPXYGAo7MI4KzUkO2oTJL8gqD/CCbAaA= X-Google-Smtp-Source: APXvYqyJMu4ehdYgm5u2UT/4i2ILhuFfAQ6pRonT9RYUngj2jssYviJ74vk3Tyx3YvnSmJM6zgFXp5JowIJE+a71wlY= X-Received: by 2002:a2e:974d:: with SMTP id f13mr34775398ljj.140.1554127770311; Mon, 01 Apr 2019 07:09:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Mon, 1 Apr 2019 07:09:19 -0700 Message-ID: To: Tal Mizrahi Cc: IETF IPPM WG , guo.jun2@zte.com.cn, Henrik Nydell , "Foote, Footer (Nokia - CA)" , IPPM Chairs Content-Type: multipart/alternative; boundary="000000000000af603b05857891b0" Archived-At: Subject: Re: [ippm] IPR Poll for draft-ietf-ippm-stamp-05 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 14:09:34 -0000 --000000000000af603b05857891b0 Content-Type: text/plain; charset="UTF-8" Hi Tal, et al., as the co-author, I'm not aware of any undisclosed IPR related to draft-ietf-ippm-stamp-05, Regards, Greg On Mon, Apr 1, 2019 at 12:47 AM Tal Mizrahi wrote: > Hi, > > This email begins a two-week poll for any IPRs that may apply to > draft-ietf-ippm-stamp-05. > > Are you aware of any IPR that applies to draft-ietf-ippm-stamp-05? > > Specifically, if you are listed as a document author or contributor, > please respond to this email (reply-to-all) stating whether or not you are > aware of any relevant IPR. > > If you are aware of a relevant IPR, please state whether this IPR has been > disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and > 5378 for more details). > > This poll closes on the 15th of April 2019. > > Best regards, > Tal. > [As shepherd of draft-ietf-ippm-stamp] > --000000000000af603b05857891b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tal, et al.,
as the co-author, I'm not aware of= any undisclosed IPR related to draft-ietf-ippm-stamp-05,

Regards,
Greg

<= div dir=3D"ltr" class=3D"gmail_attr">On Mon, Apr 1, 2019 at 12:47 AM Tal Mi= zrahi <tal.mizrahi.phd@gmai= l.com> wrote:
Hi,

This email begins a two-we= ek poll for any IPRs that may apply to draft-ietf-ippm-stamp-05.
=
Are you aware of any IPR that applies to draft-ietf-ippm-sta= mp-05?=C2=A0

Specifically, if you are listed as a = document author or contributor, please respond to this email (reply-to-all)= stating whether or not you are aware of any relevant IPR.

If you are aware of a relevant IPR, please state whether this IPR = has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, = 3669 and 5378 for more details).

This poll closes = on the 15th of April 2019.

Best regards,
Tal.
[As shepherd of=C2=A0draft-ietf-ippm-stamp]
--000000000000af603b05857891b0-- From nobody Mon Apr 1 07:37:38 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D1412013E; Mon, 1 Apr 2019 07:37: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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com 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 ROlaRJV9bZia; Mon, 1 Apr 2019 07:37:32 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80092.outbound.protection.outlook.com [40.107.8.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 685C4120110; Mon, 1 Apr 2019 07:37:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kzzXwvTJCxY4Z4iYbJJWvMqLeVedeH+oRIDWKn25qxw=; b=ARh8Iu8cT+Dv0xwkkQ5RWkWXaQCqeHflvm3UWYOR+ugQg6+L+O4X4hdm6JVVv5lf2IfLppigDQMQqrxGuRJbVnKKNJ+5NsBgacE2rfzxx4bFdNAbWT3GfpyKUlm35OLJooC7sTxTQhLiGRyB8iQALUDzr4D+iUT2PY/lf9YrV4g= Received: from AM6PR07MB4518.eurprd07.prod.outlook.com (20.177.38.81) by AM6PR07MB6008.eurprd07.prod.outlook.com (20.178.94.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.7; Mon, 1 Apr 2019 14:37:28 +0000 Received: from AM6PR07MB4518.eurprd07.prod.outlook.com ([fe80::21:c850:7d13:a106]) by AM6PR07MB4518.eurprd07.prod.outlook.com ([fe80::21:c850:7d13:a106%2]) with mapi id 15.20.1771.006; Mon, 1 Apr 2019 14:37:28 +0000 From: "Foote, Footer (Nokia - CA)" To: Tal Mizrahi , IETF IPPM WG , Greg Mirsky , "guo.jun2@zte.com.cn" , "hnydell@accedian.com" CC: "ippm-chairs@ietf.org" Thread-Topic: IPR Poll for draft-ietf-ippm-stamp-05 Thread-Index: AQHU6F8y31X3HsVPSEOO9gD38SmE9qYnX+DA Date: Mon, 1 Apr 2019 14:37:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=footer.foote@nokia.com; x-originating-ip: [70.54.112.12] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cef03453-3b1a-4d7c-22fd-08d6b6af9092 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:AM6PR07MB6008; x-ms-traffictypediagnostic: AM6PR07MB6008: x-microsoft-antispam-prvs: x-forefront-prvs: 0994F5E0C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(366004)(346002)(376002)(136003)(189003)(199004)(486006)(6436002)(110136005)(53546011)(6246003)(5660300002)(8676002)(25786009)(54896002)(55016002)(6506007)(6306002)(11346002)(446003)(102836004)(74316002)(106356001)(7696005)(81156014)(66066001)(6116002)(76176011)(2201001)(26005)(256004)(52536014)(8936002)(14454004)(53936002)(186003)(9686003)(105586002)(476003)(3846002)(790700001)(68736007)(478600001)(86362001)(4326008)(81166006)(33656002)(2501003)(7736002)(97736004)(71200400001)(99286004)(71190400001)(2906002)(316002)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM6PR07MB6008; H:AM6PR07MB4518.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: wiLQFLZ+iJRKov5Eo2fZkjpfiKdvnkIE/cjbzZni9tMfxvBdYsL0NEBRqXc3mYc7gpzZes2vESJZrJZKT4tjzLDGE3BQQnKY72NScb51yF1zdLPjsTh609cSQvlHbxhaAJ/YvG5qzGc/724A1A0aIzRwhzHq3iAsD+V4/+ot+tsFiWgjHPBhqzppGS1uGzngkeDf94OPJyejSHs8OunErxmgJozr9BSMPTLklUJrt+GWfFHT1T4QXqyNF3O70NUeKbTu7C+l/5BDjMdjg7MRkxK1t7feArMQLqFFQWrQx2l5Z/0ZngIaNWfgBF211BzbDVwyrEMKb5ooVMgp9pd3157V3zPGc/JEGSx+XWxFn9RfQviNKV/9bncq04GlxohXs7mIcbKf59ib2eDQP0BY+TbLwAJi0Mvi2k4F2EdTcBQ= Content-Type: multipart/alternative; boundary="_000_AM6PR07MB451858DA06FA3064172DE67F8B550AM6PR07MB4518eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: cef03453-3b1a-4d7c-22fd-08d6b6af9092 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2019 14:37:27.9201 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB6008 Archived-At: Subject: Re: [ippm] IPR Poll for draft-ietf-ippm-stamp-05 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 14:37:36 -0000 --_000_AM6PR07MB451858DA06FA3064172DE67F8B550AM6PR07MB4518eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R29vZCBtb3JuaW5nIFRhbCwNCg0KQXMgdGhlIGNvLWF1dGhvciwgSSdtIG5vdCBhd2FyZSBvZiBh bnkgdW5kaXNjbG9zZWQgSVBSIHJlbGF0ZWQgdG8gZHJhZnQtaWV0Zi1pcHBtLXN0YW1wLTA1Lg0K DQpGb290ZXINCg0KDQoNCkZyb206IFRhbCBNaXpyYWhpIDx0YWwubWl6cmFoaS5waGRAZ21haWwu Y29tPg0KU2VudDogTW9uZGF5LCAxIEFwcmlsIDIwMTkgMDM6NDgNClRvOiBJRVRGIElQUE0gV0cg PGlwcG1AaWV0Zi5vcmc+OyBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPjsgZ3Vv Lmp1bjJAenRlLmNvbS5jbjsgaG55ZGVsbEBhY2NlZGlhbi5jb207IEZvb3RlLCBGb290ZXIgKE5v a2lhIC0gQ0EpIDxmb290ZXIuZm9vdGVAbm9raWEuY29tPg0KQ2M6IGlwcG0tY2hhaXJzQGlldGYu b3JnDQpTdWJqZWN0OiBJUFIgUG9sbCBmb3IgZHJhZnQtaWV0Zi1pcHBtLXN0YW1wLTA1DQoNCkhp LA0KDQpUaGlzIGVtYWlsIGJlZ2lucyBhIHR3by13ZWVrIHBvbGwgZm9yIGFueSBJUFJzIHRoYXQg bWF5IGFwcGx5IHRvIGRyYWZ0LWlldGYtaXBwbS1zdGFtcC0wNS4NCg0KQXJlIHlvdSBhd2FyZSBv ZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdC1pZXRmLWlwcG0tc3RhbXAtMDU/DQoNClNw ZWNpZmljYWxseSwgaWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29u dHJpYnV0b3IsIHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgKHJlcGx5LXRvLWFsbCkgc3Rh dGluZyB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuDQoN CklmIHlvdSBhcmUgYXdhcmUgb2YgYSByZWxldmFudCBJUFIsIHBsZWFzZSBzdGF0ZSB3aGV0aGVy IHRoaXMgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIg cnVsZXMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWls cykuDQoNClRoaXMgcG9sbCBjbG9zZXMgb24gdGhlIDE1dGggb2YgQXByaWwgMjAxOS4NCg0KQmVz dCByZWdhcmRzLA0KVGFsLg0KW0FzIHNoZXBoZXJkIG9mIGRyYWZ0LWlldGYtaXBwbS1zdGFtcF0N Cg== --_000_AM6PR07MB451858DA06FA3064172DE67F8B550AM6PR07MB4518eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iZW4tTlUiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+R29vZCBtb3JuaW5nIFRhbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5BPC9zcGFuPnMgdGhlIGNvLWF1dGhvciwgSSdtIG5vdCBhd2FyZSBv ZiBhbnkgdW5kaXNjbG9zZWQgSVBSIHJlbGF0ZWQgdG8gZHJhZnQtaWV0Zi1pcHBtLXN0YW1wLTA1 PHNwYW4gbGFuZz0iRU4tVVMiPi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5Gb290ZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9ImVuLU5VIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9ImVu LU5VIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBUYWwgTWl6cmFoaSAmbHQ7dGFsLm1p enJhaGkucGhkQGdtYWlsLmNvbSZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIDEgQXBy aWwgMjAxOSAwMzo0ODxicj4NCjxiPlRvOjwvYj4gSUVURiBJUFBNIFdHICZsdDtpcHBtQGlldGYu b3JnJmd0OzsgR3JlZyBNaXJza3kgJmx0O2dyZWdpbWlyc2t5QGdtYWlsLmNvbSZndDs7IGd1by5q dW4yQHp0ZS5jb20uY247IGhueWRlbGxAYWNjZWRpYW4uY29tOyBGb290ZSwgRm9vdGVyIChOb2tp YSAtIENBKSAmbHQ7Zm9vdGVyLmZvb3RlQG5va2lhLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IGlw cG0tY2hhaXJzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IElQUiBQb2xsIGZvciBkcmFm dC1pZXRmLWlwcG0tc3RhbXAtMDU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGVtYWlsIGJlZ2lucyBh IHR3by13ZWVrIHBvbGwgZm9yIGFueSBJUFJzIHRoYXQgbWF5IGFwcGx5IHRvIGRyYWZ0LWlldGYt aXBwbS1zdGFtcC0wNS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+QXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFm dC1pZXRmLWlwcG0tc3RhbXAtMDU/Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNwZWNpZmljYWxseSwgaWYgeW91IGFyZSBsaXN0ZWQg YXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IsIHBsZWFzZSByZXNwb25kIHRvIHRo aXMgZW1haWwgKHJlcGx5LXRvLWFsbCkgc3RhdGluZyB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3 YXJlIG9mIGFueSByZWxldmFudCBJUFIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHlvdSBhcmUgYXdhcmUgb2YgYSByZWxldmFudCBJUFIs IHBsZWFzZSBzdGF0ZSB3aGV0aGVyIHRoaXMgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21w bGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2NjkgYW5k IDUzNzggZm9yIG1vcmUgZGV0YWlscykuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgcG9sbCBjbG9zZXMgb24gdGhlIDE1dGggb2YgQXBy aWwgMjAxOS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGFsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+W0FzIHNoZXBoZXJkIG9mJm5ic3A7ZHJhZnQtaWV0Zi1pcHBtLXN0YW1w XTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AM6PR07MB451858DA06FA3064172DE67F8B550AM6PR07MB4518eurp_-- From nobody Mon Apr 1 09:25:34 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773AA12039D; Mon, 1 Apr 2019 09:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=B74ftatL; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=W7WJCJDN 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 wfYXAzsUx7V5; Mon, 1 Apr 2019 09:25:27 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28BB31203A1; Mon, 1 Apr 2019 09:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5398; q=dns/txt; s=iport; t=1554135920; x=1555345520; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=U23fZU2IDJMmO0wwClfUMoQiP1VSh/Zkhohp7zLZKRY=; b=B74ftatLKD0Dxd6VFuvQFIcncoD0wuTK51DiS1DbpdxNYPUoZGKxK7Cv CIRhSHiwqs2uWmXiAY2d/AHl6/uTjs5n+/2eMh6ApExGStBV73xrFRtbO qKh/QBVL4IRSzoHbgwP3nPMFfW01U9PrDCZHknnALgLYqVOb+Z9l2v101 M=; IronPort-PHdr: =?us-ascii?q?9a23=3AKj/WCBefWPUkxuuWTu2VgfBqlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGQD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/YSYgG89BUlJN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAACoOqJc/4MNJK1ZChoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVEFAQEBAQsBgT0kLANodAQLJwqHSwOEUophgld+hCeEEgG?= =?us-ascii?q?NV4EuFIEQA1QOAQEjCYRAAoVEIjQJDQEBAwEBCQEDAm0cDIVKAQEBAQIBOgY?= =?us-ascii?q?BASUSAQsEAgEIDgMEAQEWCQULIREdCAIEDgUIgxuBXQMNCAECDKFEAooUgiC?= =?us-ascii?q?CeQEBBYE1AoNDDQuCDAMFgS8BizIXgUA/gRFGgTdgNT6CGkcBAQOBGRIBBws?= =?us-ascii?q?BIT2CfIImpRc2CQKHb4gvg1qCA4YMjB2RUIE8jAECBAIEBQIOAQEFgU04ZXF?= =?us-ascii?q?wFYMnggoMBRITgziFFIU/coEoTYwogR8BgR4BAQ?= X-IronPort-AV: E=Sophos;i="5.60,297,1549929600"; d="scan'208";a="252163902" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Apr 2019 16:25:18 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x31GPIea004113 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 1 Apr 2019 16:25:18 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 1 Apr 2019 11:25:18 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 1 Apr 2019 12:25:17 -0400 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 1 Apr 2019 12:25:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=frBG9YMoBCpY9mhuOGUmH9lVJHEWIuKJYC9dD0xtaEA=; b=W7WJCJDNoIumgIg1d/ygTuFSHOMTB5sZBYzO+j6UVyjfpuAfZfHmsCOjV5CcmyC6AkkHlmbHVXJXWh1OC73qHkSrKdM2kjmoenr+gwzZ7GB4cBFezH4eIyjY3qt362mY2vQkjmgcyEqBm1BivC+q+gsHZTIv/3PGOtN8LveA9nk= Received: from BN8PR11MB3618.namprd11.prod.outlook.com (20.178.219.85) by BN8PR11MB3700.namprd11.prod.outlook.com (20.178.220.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.17; Mon, 1 Apr 2019 16:25:15 +0000 Received: from BN8PR11MB3618.namprd11.prod.outlook.com ([fe80::9d38:1845:842d:a489]) by BN8PR11MB3618.namprd11.prod.outlook.com ([fe80::9d38:1845:842d:a489%3]) with mapi id 15.20.1750.017; Mon, 1 Apr 2019 16:25:15 +0000 From: "Frank Brockners (fbrockne)" To: Mikael Abrahamsson CC: Mark Smith , "C. M. Heard" , 6man WG , "ippm@ietf.org" Thread-Topic: draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) Thread-Index: AQHU4eVk77oZnWiBmUa6JfuK7viq2qYclmiQgATixqCABbu4AIAAT+7g Date: Mon, 1 Apr 2019 16:25:15 +0000 Message-ID: References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=fbrockne@cisco.com; x-originating-ip: [173.38.220.59] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 08576bf6-099d-42e2-ca0a-08d6b6be9f7f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BN8PR11MB3700; x-ms-traffictypediagnostic: BN8PR11MB3700: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0994F5E0C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(136003)(39860400002)(376002)(366004)(13464003)(189003)(199004)(76176011)(53546011)(6506007)(446003)(11346002)(26005)(102836004)(6116002)(5660300002)(486006)(105586002)(8936002)(6246003)(6436002)(186003)(6916009)(97736004)(5024004)(14444005)(68736007)(14454004)(966005)(81166006)(2906002)(81156014)(8676002)(7736002)(305945005)(53936002)(256004)(33656002)(52536014)(6306002)(66574012)(74316002)(229853002)(54906003)(9686003)(66066001)(55016002)(478600001)(476003)(86362001)(316002)(106356001)(99286004)(25786009)(71200400001)(71190400001)(7696005)(93886005)(4326008)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR11MB3700; H:BN8PR11MB3618.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ehpX4LZ5fjjjVgFpr1mg1FqV6oxduG+raj2OvHzUEdKl4syudw0FyjS6dwLFn5nf55KspdWhKa5Bh48iufwTb+T5Y1ELteLUDbkIVwawil6PmMizJ7t/hVCy0zgmnydqeZXHKHGHROmvNGmS/YiRgwVz/PAnbSkExH0anad3d1pgnc8ve5prNFnN/MP6TiwL9tgVHYYoqxU+uD4+1FdLE6ZlBY0PLEk50iTjsJrkUxtbKHm73dVlzOTP3XVkJGQz96BtPeRUwYOB2mLPt9VpqtTcxvieQrl51VQppO6C4twtLXX813RIFY5jSSjzfvAh/4/7HNrydX+/AiuTWOp00h4p9hQQoWitbbyiawwZCvxEMJEUTYXy72pafdUr3d/LaZvA3PnbiVzbUNbeHILe2c6FeGub3EqXTUXCPNsdzwQ= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 08576bf6-099d-42e2-ca0a-08d6b6be9f7f X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2019 16:25:15.3616 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3700 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.30, xch-aln-020.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 16:25:32 -0000 Hi Mikael, Thanks - please find some notes inline ("... FB"). -----Original Message----- From: Mikael Abrahamsson =20 Sent: Montag, 1. April 2019 13:16 To: Frank Brockners (fbrockne) Cc: Mark Smith ; C. M. Heard ; 6ma= n WG ; ippm@ietf.org Subject: RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re:= v6 option types for IOAM data fields) On Thu, 28 Mar 2019, Frank Brockners (fbrockne) wrote: > > FYI - A new draft including Mark's comments below just got posted: > https://tools.ietf.org/html/draft-ioametal-ippm-6man-ioam-ipv6-deploym > ent-01 I watched the tech deep dive video recording in conjunction with this.=20 This is a really hard problem to solve with all those factors to take into = account. Some random thoughts: There seems to be overlap of this problem space with SRv6, these seem to ha= ve almost identical properties. They insert something, the forwarding devic= es need to interact with it and it needs to be stripped before it leaves th= e domain. Though, in the SRv6 space the forwarding information is in the header, wher= eas for the IOAM space the forwarding device should actually ignore whateve= r is in the IOAM header as the desire is for it to treat packets identicall= y regardless if they have the header or not. Considering how routers forwar= d packets based on 5-tuple (or even deeper), what's the thinking been on th= is so far? ...FB: There is obviously no easy answer. Couple of thoughts: * IOAM is considered a "domain specific" feature (see draft-ietf-ippm-ioam-= data-05, section 3). Routers in the IOAM domain should be IOAM capable. An= d IMHO, we should add a statement to draft-ioametal-ippm-6man-ioam-ipv6-de= ployment that an implementation of IOAM MUST ensure "C1". * That said, there can be situations, where C1 cannot be achieved, e.g. con= sider a network which does ECMP scheduling based on packet length.=20 * What one could consider - and which is one suggested deployment model - i= s that by default IOAM data fields are added to _all_ customer packets. The= decapsulating node would decide whether the IOAM information contained in = a packet would be used (and exported) or not. That way one would not need t= o deal with the situation that some traffic carries IOAM while other does n= ot - and might thus be treated differently.=20 The MTU issue should be the least problematic, recommendations on using a c= onsiderable higher MTU on the internal links compared to the external links= is identical to what has been used for encapsulation networks for a long t= ime. We use 9180 IP MTU on the internal links and external links are 9000 MTU. This leaves room for several layers of encap without affecting th= e customer visible MTU. I like the fact that the IOAM information is attached to the real packet be= ing forwarded as opposed to just using test traffic. I think the C1-C6 requirements make a lot of sense, but following them is h= ard. I have myself run networks that ran IPv4 and IPv6 Internet packets nat= ive (no encap) internally, and only encapsulated VPN overlay packets.=20 It'd of course be nice to support IOAM also for those deployment scenarios,= but then it becomes harder to assure no leakage (C5) and identifying the l= eaker. Otoh when doing MPLS if you leak labeled packets they are probably d= ropped at the other end (do we have research on this?).=20 So leaking IOAM enabled packets might be less of a disaster compared to oth= er encaps? ...FB: The comparison to MPLS is interesting. How often do MPLS packets lea= k and cause harm? For IOAM, draft-ioametal-ippm-6man-ioam-ipv6-options-02 p= roposes a deployment model similar to what we do for MPLS: Unless an interf= ace is explicitly configured for IOAM, packets with IOAM data fields MUST b= e dropped. Hence leakage would only occur, if we have a clearly misbehaving= router which violates this rule. Similar to you, I'd also greatly apprecia= te any pointers to research on how common MPLS leaked packets are. Doing IOAM only based on some other forwarding scheme (MPLS, SRv6 etc) and = embedding meaning into whatever forwarding information is used for that mig= ht help (IOAM information lives within that forwarding plane), but also mak= es IOAM less deployable for other networks that just run native. ...FB: Yes - this is a trade-off. In some deployments, it might not be feas= ible to deploy IOAM in the underlay (e.g. v6) - but you still want to use i= t to measure the overlay (e.g. with NSH) - hence we're defining encapsulati= ons for several "tunnel" protocols.=20 Reading https://tools.ietf.org/html/draft-ietf-ippm-ioam-data-05 and consid= ering the C5 requirement, how do I as an end receiver of a packet with an I= OAM header in it identify even what operator to contact about these leaked = packets? It looks like the namespace/identifier is operator-internal, but h= ow do I identify what operator it is? ...FB: One idea that Shwetha came up with to identify the source AS of a le= aked packet, would be to add a new new IOAM E2E option - as proposed in sec= tion 5.1.1 bullet 2 of draft-ioametal-ippm-6man-ioam-ipv6-deployment-01. Cheers, Frank --=20 Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Apr 1 23:06:21 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553FE120049; Mon, 1 Apr 2019 23:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 i5zlUfqZA_Lt; Mon, 1 Apr 2019 23:05:46 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17CE7120013; Mon, 1 Apr 2019 23:05:46 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8C6A6B2; Tue, 2 Apr 2019 08:05:43 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1554185143; bh=Bths6+lqYYE2UI1W6mHzIkWjCcn0OJ8Wj/zrNnCoT/Y=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=WgACF7u6weoqqPK6M3j1QOMJy1mpLc5P9nQOtB1JUbWS6+q2ObCEZy2JHSJ9og3eh zP9EjUWMAUejFuH2/XS/2ksP2ELiDQVtQlaCifnNAyfxQ4eWvt2Ea3CpGBOPcldcBz QzWQTvOJ7nxP7fr3PRCQ6+VaalWDSA0gYj0wkMxQ= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 89059B1; Tue, 2 Apr 2019 08:05:43 +0200 (CEST) Date: Tue, 2 Apr 2019 08:05:43 +0200 (CEST) From: Mikael Abrahamsson To: "Frank Brockners (fbrockne)" cc: Mark Smith , "C. M. Heard" , 6man WG , "ippm@ietf.org" In-Reply-To: Message-ID: References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 06:05:49 -0000 On Mon, 1 Apr 2019, Frank Brockners (fbrockne) wrote: > ...FB: There is obviously no easy answer. Couple of thoughts: > * IOAM is considered a "domain specific" feature (see > draft-ietf-ippm-ioam-data-05, section 3). Routers in the IOAM domain > should be IOAM capable. And IMHO, we should add a statement to > draft-ioametal-ippm-6man-ioam-ipv6-deployment that an implementation of > IOAM MUST ensure "C1". > > * That said, there can be situations, where C1 cannot be achieved, e.g. > consider a network which does ECMP scheduling based on packet length. > > * What one could consider - and which is one suggested deployment model > - is that by default IOAM data fields are added to _all_ customer > packets. The decapsulating node would decide whether the IOAM > information contained in a packet would be used (and exported) or not. > That way one would not need to deal with the situation that some traffic > carries IOAM while other does not - and might thus be treated > differently. Yes, I think this is the only way. Is there a risk that intermediate routers would not be IOAM capable? I think the C1 requirement is really really hard to fulfil and I'm also afraid that adding the IOAM header will actually make ECMP stop working on some platforms (because they would not have the capability to look deep enough into the packet to find L4 information, so it'll go back to 2 tuple ECMP instead of 5 tuple. But this question can only be answered by people with deep NPU knowledge... > ...FB: The comparison to MPLS is interesting. How often do MPLS packets > leak and cause harm? For IOAM, > draft-ioametal-ippm-6man-ioam-ipv6-options-02 proposes a deployment > model similar to what we do for MPLS: Unless an interface is explicitly > configured for IOAM, packets with IOAM data fields MUST be dropped. > Hence leakage would only occur, if we have a clearly misbehaving router > which violates this rule. Similar to you, I'd also greatly appreciate > any pointers to research on how common MPLS leaked packets are. When it comes to "cause harm" I imagine there are (at least) two ways to cause harm, one is privacy/secrecy/security loss and the other one is actual operational loss. I know of bugs where labeled packets went the wrong way and caused them to be lost, I've also seen bugs where bugs caused traffic to "hop" between VRFs in MPLS VPN (or to "global" VRF). I don't have numbers on this though. Depending on the deployment scenario, it might make sense to make IOAM packets not valid for non-IOAM aware devices (basically encap entire packet/payload), but that might be a problem for intermediate non-IOAM nodes then. This would affect the ECMP requirement. I can see cases where one would operationally turn on IOAM for some customers traffic and then see the problem go away because now ECMP changed. > ...FB: One idea that Shwetha came up with to identify the source AS of a > leaked packet, would be to add a new new IOAM E2E option - as proposed > in section 5.1.1 bullet 2 of > draft-ioametal-ippm-6man-ioam-ipv6-deployment-01. Yes, that'd solve that problem. How much has the silicon people been involved so far in the design of the headers? What is the current thinking of amount of data going into the IOAM header? Considering things like trace options etc it seems to me the header can grow quite large? To satisfy the ECMP requirement what about putting the IOAM information as a trailer behind the regular payload? Or is there a problem for the hw to manipulate information that far into the packet (I also imagine this will considerably lower the forwarding performance of IOAM packets on IOAM aware platforms). -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Apr 1 23:26:37 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4313A1200F5 for ; Mon, 1 Apr 2019 23:26:36 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 4GV6MhdWA3Kz for ; Mon, 1 Apr 2019 23:26:33 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A841212001E for ; Mon, 1 Apr 2019 23:26:33 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id o129so7219605qke.8 for ; Mon, 01 Apr 2019 23:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZoA4+xHHv8S1/xwu8JJSabbA90pRUaXSBxJfroNWlwM=; b=CExVKXGbQOwh1ZE3htAZvUq+SkfYQ6jKyKY9CrcrWAfl4GgDE4n6GbAkYaNLp6u5EO +PRdGHe4UfWQwybJJ+JT/OsjO9LA36FQtKEC68jIFl9c6tBgIUb2DpjFmG7X5XcctAIH P/seDGUVUo0KzjKhPwnNzJiVSb/TLwd7yYbsPQtqn3Z6Q9bfNkYCyWZmIwkyoHS0BMT1 Qr358zuJbpCuymOXvaEwuyRD3jCfB7qI9K0g9OhmdpJ4ZS5UoeKe6FLSib1cwbKz+wBk K/jy65sBcyIuquhr3Eh/Mb4cmj4YW+SY/kkjxoz8SC7lvCFhxgcTZCFW9216ZDIwYaOX Eq6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZoA4+xHHv8S1/xwu8JJSabbA90pRUaXSBxJfroNWlwM=; b=oIvl8WaI00Ok9YYa38l6S9zh6RDsak+XqH3HhnzvDCPryzvCFHIaj6pXDU+X3nXPWD 0OMJTn3onA4XkvzOC31C+qW4qvSAW2W3+74VVPe9ZrHMGsYNehpAu7rGO/OPDKmequlo egT18mmY4NJaxJ/tQbfJD7lMGIf5Ba4Mtq5Cl7QRqwCvTY1YWrT64TF5pZ/z9nLIgXjS t+B1peo0WgPlig2wpcrY5mZtzlHkBijWidA0Ik+o9bqgRopIbstARqA0sSEezbheryCN SrvV0hTmuFR6aif5NMzsvooafkJdvBkHVSxTqhHc2GeI/Z7+fh9rAVkeuETrKk03H41V AnGA== X-Gm-Message-State: APjAAAXNOJvo2GxgbG7LeZKqU3ZiUzveIttgamB0JamvQLOzfqycCm+b 2DH5h0uELDJotetehs4vFy8ty1rs7hgVZ3cITIjvFA== X-Google-Smtp-Source: APXvYqzLYF+W/2pMDrIV36piZSPUHZcBnFiyTVCVbAPN3g0cI1cJtNZVnTX9j11aoW6nx0U2LCuxtdBp7q6QhzbNq9I= X-Received: by 2002:a37:4d53:: with SMTP id a80mr56170387qkb.247.1554186392500; Mon, 01 Apr 2019 23:26:32 -0700 (PDT) MIME-Version: 1.0 References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> In-Reply-To: From: Tom Herbert Date: Tue, 2 Apr 2019 08:26:21 +0200 Message-ID: To: Mikael Abrahamsson Cc: "Frank Brockners (fbrockne)" , "C. M. Heard" , 6man WG , "ippm@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 06:26:36 -0000 On Tue, Apr 2, 2019 at 8:06 AM Mikael Abrahamsson wrote: > > On Mon, 1 Apr 2019, Frank Brockners (fbrockne) wrote: > > > ...FB: There is obviously no easy answer. Couple of thoughts: > > * IOAM is considered a "domain specific" feature (see > > draft-ietf-ippm-ioam-data-05, section 3). Routers in the IOAM domain > > should be IOAM capable. And IMHO, we should add a statement to > > draft-ioametal-ippm-6man-ioam-ipv6-deployment that an implementation of > > IOAM MUST ensure "C1". > > > > * That said, there can be situations, where C1 cannot be achieved, e.g. > > consider a network which does ECMP scheduling based on packet length. > > > > * What one could consider - and which is one suggested deployment model > > - is that by default IOAM data fields are added to _all_ customer > > packets. The decapsulating node would decide whether the IOAM > > information contained in a packet would be used (and exported) or not. > > That way one would not need to deal with the situation that some traffic > > carries IOAM while other does not - and might thus be treated > > differently. > > Yes, I think this is the only way. Is there a risk that intermediate > routers would not be IOAM capable? I think the C1 requirement is really > really hard to fulfil and I'm also afraid that adding the IOAM header will > actually make ECMP stop working on some platforms (because they would not > have the capability to look deep enough into the packet to find L4 > information, so it'll go back to 2 tuple ECMP instead of 5 tuple. > > But this question can only be answered by people with deep NPU > knowledge... > Mikael, This is solved with proper use of the IPv6 flow label for ECMP instead of devices continuing to try to find 5 tuples buried deep within packets. DPI is only going to become harder as more headers and functionality are added (e.g. segment routing header will be another problem, deep headers will exceed parsing buffers, and it's impossible to find the 5 tuple for a fragment and still be stateless). Since IOAM is used in a limited domain, the requirement should be that all routers in the domain support ECMP routing using flow label (note that is a less stringent requirement than all routers having to support IOAM). Tom > > ...FB: The comparison to MPLS is interesting. How often do MPLS packets > > leak and cause harm? For IOAM, > > draft-ioametal-ippm-6man-ioam-ipv6-options-02 proposes a deployment > > model similar to what we do for MPLS: Unless an interface is explicitly > > configured for IOAM, packets with IOAM data fields MUST be dropped. > > Hence leakage would only occur, if we have a clearly misbehaving router > > which violates this rule. Similar to you, I'd also greatly appreciate > > any pointers to research on how common MPLS leaked packets are. > > When it comes to "cause harm" I imagine there are (at least) two ways to > cause harm, one is privacy/secrecy/security loss and the other one is > actual operational loss. > > I know of bugs where labeled packets went the wrong way and caused them to > be lost, I've also seen bugs where bugs caused traffic to "hop" between > VRFs in MPLS VPN (or to "global" VRF). I don't have numbers on this > though. > > Depending on the deployment scenario, it might make sense to make IOAM > packets not valid for non-IOAM aware devices (basically encap entire > packet/payload), but that might be a problem for intermediate non-IOAM > nodes then. This would affect the ECMP requirement. I can see cases where > one would operationally turn on IOAM for some customers traffic and then > see the problem go away because now ECMP changed. > > > ...FB: One idea that Shwetha came up with to identify the source AS of a > > leaked packet, would be to add a new new IOAM E2E option - as proposed > > in section 5.1.1 bullet 2 of > > draft-ioametal-ippm-6man-ioam-ipv6-deployment-01. > > Yes, that'd solve that problem. > > How much has the silicon people been involved so far in the design of the > headers? What is the current thinking of amount of data going into the > IOAM header? Considering things like trace options etc it seems to me the > header can grow quite large? To satisfy the ECMP requirement what about > putting the IOAM information as a trailer behind the regular payload? Or > is there a problem for the hw to manipulate information that far into the > packet (I also imagine this will considerably lower the forwarding > performance of IOAM packets on IOAM aware platforms). > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Tue Apr 2 00:33:22 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 958CF12021B; Tue, 2 Apr 2019 00:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 kD6AFZ4bj6YV; Tue, 2 Apr 2019 00:33:16 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE45112027C; Tue, 2 Apr 2019 00:33:15 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1DC67B1; Tue, 2 Apr 2019 09:33:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1554190392; bh=XjlET91oK+ILIdDQ+ilC6aJuDE11QftMcBcWACJx+cg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=l57YAf2nbRdeWlNlfqzgqXTA0g4pq1etFGqZO4WBivKos7sA0HqrqZGu1l5RtEtvt 8jqXP4zcwHV/uhQK0MsKtr/+9i/jUS666ErsFDaKE52ipsTSjG94hcianobTD+lmJt m7ngohYLqzIuReETqu6OA+5uDEhaNfQtVNbX55f0= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 19E6FB0; Tue, 2 Apr 2019 09:33:12 +0200 (CEST) Date: Tue, 2 Apr 2019 09:33:12 +0200 (CEST) From: Mikael Abrahamsson To: Tom Herbert cc: "Frank Brockners (fbrockne)" , "C. M. Heard" , 6man WG , "ippm@ietf.org" In-Reply-To: Message-ID: References: <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 07:33:19 -0000 On Tue, 2 Apr 2019, Tom Herbert wrote: > This is solved with proper use of the IPv6 flow label for ECMP instead > of devices continuing to try to find 5 tuples buried deep within > packets. DPI is only going to become harder as more headers and > functionality are added (e.g. segment routing header will be another > problem, deep headers will exceed parsing buffers, and it's impossible > to find the 5 tuple for a fragment and still be stateless). Since IOAM > is used in a limited domain, the requirement should be that all routers > in the domain support ECMP routing using flow label (note that is a less > stringent requirement than all routers having to support IOAM). >From what I have seen so far, most devices if they support flow label for ECMP, can/will use the flow label in *addition* to 5-tuple. For the requirement of IOAM to not have separate ECMP characteristics then the entire IOAM domain will have to be configured to use 2-tuple + flow label? Do we have data on how much end systems use flow labels nowadays? If this is low, do we have data from OS vendors that they're considering increasing the use of flow labels? -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Apr 2 02:39:59 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3469120111; Tue, 2 Apr 2019 02:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=IQT1kTQB; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=QKQHigeK 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 ltIAuFfQTU1B; Tue, 2 Apr 2019 02:39:55 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDEBF1200B5; Tue, 2 Apr 2019 02:39:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5389; q=dns/txt; s=iport; t=1554197994; x=1555407594; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6VfnFzFSQ5Ig8qi4M8Z5Bpk4D7O3aNNqBYlCZ1Jygik=; b=IQT1kTQBzBnrI/HF2PKa3z/bRoPW+HhB6egT6uFibLtzG0H42No0xZbG Sd+egMEvD0fmYErFMY73XGSjnrYTte7bSrcTsp9RM76/FhWYlgBLNxhgp POc8FwVEJaNRRVn7MZE1UzibciQ21cOH+MGo0mA1C9L540ukC9TjzjoZs M=; IronPort-PHdr: =?us-ascii?q?9a23=3AMjLHwB0c6SMPVZ8zsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQB0fhK/XpaSESF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B2AABrLaNc/49dJa1bChoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVQCAQEBAQsBgT0kLAOBPCAECycKh0sDjzSCV4k4jVmBQoE?= =?us-ascii?q?QA1QOAQEsgUuCdQKFOiI3Bg0BAQMBAQkBAwJtHAyFSgEBAQEDOgYBASUSAQs?= =?us-ascii?q?EAgEIDgMEAQEfBQshER0IAgQOBQiEeAMVAQKiHAKKFIIggnkBAQWFEw0Lggw?= =?us-ascii?q?IgS8BizIXgUA/gRFGgkw+ghqBdwEHCwEhgzmCJqUeNgkCkCSDW5Q0kxqMBAI?= =?us-ascii?q?EAgQFAg4BAQWBYyJlcXAVgyeCCgkDBRITgziKU3KBKIx5gR8BgR4BAQ?= X-IronPort-AV: E=Sophos;i="5.60,300,1549929600"; d="scan'208";a="542410466" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 02 Apr 2019 09:39:52 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x329dqJQ005776 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 2 Apr 2019 09:39:53 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 2 Apr 2019 04:39:52 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 2 Apr 2019 04:39:51 -0500 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 2 Apr 2019 04:39:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lZhjMnfHIFjadMQiUlXDrvMpwfRIMj/nKdETZ+oyPCI=; b=QKQHigeKa2rFVudNEoYTWE2tY8v9AjDuak9cCqo6Se2rM+smJaWp+kSnnZ49Egv6UwP8nW9uEpG2Yiuky0TbdYX6Ae+A1VYU24xEb+2o681qfiBnl7MRS35xPva/AlD/5YaXVH4ttAtkVlDf6Xlp/0+AwCV344Ue4yfeGpRAwzs= Received: from MN2PR11MB3629.namprd11.prod.outlook.com (20.178.252.31) by MN2PR11MB3662.namprd11.prod.outlook.com (20.178.251.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.20; Tue, 2 Apr 2019 09:39:49 +0000 Received: from MN2PR11MB3629.namprd11.prod.outlook.com ([fe80::ad94:267b:a12e:1a64]) by MN2PR11MB3629.namprd11.prod.outlook.com ([fe80::ad94:267b:a12e:1a64%2]) with mapi id 15.20.1750.014; Tue, 2 Apr 2019 09:39:49 +0000 From: "Frank Brockners (fbrockne)" To: Mikael Abrahamsson CC: Mark Smith , "C. M. Heard" , 6man WG , "ippm@ietf.org" Thread-Topic: draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) Thread-Index: AQHU4eVk77oZnWiBmUa6JfuK7viq2qYclmiQgATixqCABbu4AIAAT+7ggADrloCAADhXsA== Date: Tue, 2 Apr 2019 09:39:49 +0000 Message-ID: References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=fbrockne@cisco.com; x-originating-ip: [173.38.220.33] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 29627dab-5378-4328-97cb-08d6b74f26a8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:MN2PR11MB3662; x-ms-traffictypediagnostic: MN2PR11MB3662: x-microsoft-antispam-prvs: x-forefront-prvs: 0995196AA2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(346002)(39860400002)(376002)(396003)(199004)(13464003)(189003)(7696005)(53546011)(14454004)(305945005)(8936002)(2906002)(102836004)(6436002)(66066001)(3846002)(6116002)(478600001)(106356001)(99286004)(316002)(105586002)(186003)(446003)(486006)(86362001)(6506007)(55016002)(9686003)(6916009)(229853002)(476003)(54906003)(66574012)(26005)(93886005)(76176011)(11346002)(71190400001)(71200400001)(256004)(68736007)(14444005)(52536014)(74316002)(97736004)(8676002)(6246003)(5660300002)(81166006)(81156014)(25786009)(53936002)(33656002)(4326008)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3662; H:MN2PR11MB3629.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: wT/Z2ig1eiCjtVZSTT7oGtjtrQH3p1pLIQ3QwEFBNALhUn9QBS02xIkEBFzwTX62p0D6+D6mRvALGjKnaPerqHgsuI/Tor0Y3DShweYXNoK8lV+LsVXMXJLhMAiyE7G0AXGAHJoxX6DfSjiGql/Y/XBQ42CNj+3KJ1dMKlMAxnrnVwxvrJZYIeORsGIoaV+KWjQro08PvFPySvQADfBQ+Goy9Jw0y1BSf/W+0Hkd0YY5RJJHMsu/Mj6zsxkyyXdJET6zQROJU8gDSFQ3tuWz00ybc1tC7zENaixEEmiA7BJ7xnuHgaZ+o3WilEmbuWe1OYcL7w/QhY/pg5RA3A0Kn7CEAbWYmcbdMnsqolFATarzVJkm5O0qiVcEpbOKyOC16gCb0Xxb0jBUaMfIOl/RZJWXuuRA3V16zpNKVH76jLI= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 29627dab-5378-4328-97cb-08d6b74f26a8 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2019 09:39:49.7055 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3662 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 09:39:58 -0000 -----Original Message----- From: Mikael Abrahamsson =20 Sent: Dienstag, 2. April 2019 08:06 To: Frank Brockners (fbrockne) Cc: Mark Smith ; C. M. Heard ; 6ma= n WG ; ippm@ietf.org Subject: RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re:= v6 option types for IOAM data fields) On Mon, 1 Apr 2019, Frank Brockners (fbrockne) wrote: > ...FB: There is obviously no easy answer. Couple of thoughts: > * IOAM is considered a "domain specific" feature (see=20 > draft-ietf-ippm-ioam-data-05, section 3). Routers in the IOAM domain=20 > should be IOAM capable. And IMHO, we should add a statement to=20 > draft-ioametal-ippm-6man-ioam-ipv6-deployment that an implementation=20 > of IOAM MUST ensure "C1". > > * That said, there can be situations, where C1 cannot be achieved, e.g.=20 > consider a network which does ECMP scheduling based on packet length. > > * What one could consider - and which is one suggested deployment=20 > model > - is that by default IOAM data fields are added to _all_ customer=20 > packets. The decapsulating node would decide whether the IOAM=20 > information contained in a packet would be used (and exported) or not. > That way one would not need to deal with the situation that some=20 > traffic carries IOAM while other does not - and might thus be treated=20 > differently. Yes, I think this is the only way. Is there a risk that intermediate router= s would not be IOAM capable? I think the C1 requirement is really really ha= rd to fulfil and I'm also afraid that adding the IOAM header will actually = make ECMP stop working on some platforms (because they would not have the c= apability to look deep enough into the packet to find L4 information, so it= 'll go back to 2 tuple ECMP instead of 5 tuple. But this question can only be answered by people with deep NPU knowledge... ...FB2: Given that IOAM is a domain specific feature - I expect that folks = initially start to use it in domains (like e.g. a DC) where all boxes are I= OAM capable and can trace the packet appropriately - or per Tom's note, can= be configured so that one would do ECMP based on addresses and flow-label.= There are chips with pretty deep parsing capability (up to a few hundred = bytes).=20 > ...FB: The comparison to MPLS is interesting. How often do MPLS=20 > packets leak and cause harm? For IOAM, > draft-ioametal-ippm-6man-ioam-ipv6-options-02 proposes a deployment=20 > model similar to what we do for MPLS: Unless an interface is=20 > explicitly configured for IOAM, packets with IOAM data fields MUST be dro= pped. > Hence leakage would only occur, if we have a clearly misbehaving=20 > router which violates this rule. Similar to you, I'd also greatly=20 > appreciate any pointers to research on how common MPLS leaked packets are= . When it comes to "cause harm" I imagine there are (at least) two ways to ca= use harm, one is privacy/secrecy/security loss and the other one is actual = operational loss. I know of bugs where labeled packets went the wrong way and caused them to = be lost, I've also seen bugs where bugs caused traffic to "hop" between VRF= s in MPLS VPN (or to "global" VRF). I don't have numbers on this though. Depending on the deployment scenario, it might make sense to make IOAM pack= ets not valid for non-IOAM aware devices (basically encap entire packet/pay= load), but that might be a problem for intermediate non-IOAM nodes then. Th= is would affect the ECMP requirement. I can see cases where one would opera= tionally turn on IOAM for some customers traffic and then see the problem g= o away because now ECMP changed. > ...FB: One idea that Shwetha came up with to identify the source AS of=20 > a leaked packet, would be to add a new new IOAM E2E option - as=20 > proposed in section 5.1.1 bullet 2 of=20 > draft-ioametal-ippm-6man-ioam-ipv6-deployment-01. Yes, that'd solve that problem. How much has the silicon people been involved so far in the design of the h= eaders? What is the current thinking of amount of data going into the IOAM = header? Considering things like trace options etc it seems to me the header= can grow quite large? To satisfy the ECMP requirement what about putting t= he IOAM information as a trailer behind the regular payload? Or is there a = problem for the hw to manipulate information that far into the packet (I al= so imagine this will considerably lower the forwarding performance of IOAM = packets on IOAM aware platforms). ...FB2: There are quite a few folks with hardware background that co-author= the IOAM drafts. Parsing capability differs between chips, as does the abi= lity to deal with new/flexible headers and the ability to modify data in th= e extension headers. So the unfortunate answer to that question is "it depe= nds" (what information do you gather, how large is your domain, what are th= e capabilities of your hardware/software forwarder, etc.), but I do expect = that for specific deployment domains (e.g. DC, Enterprise) - but also for o= verlay networks / VPNs - we'll see an increasing amount of chips that are w= ell suited for processing large extension header. Cheers, Frank --=20 Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Apr 2 07:45:54 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C3C12013B for ; Tue, 2 Apr 2019 07:45:46 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 rbHJ0b7O5_ZL for ; Tue, 2 Apr 2019 07:45:42 -0700 (PDT) Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12B4B12016F for ; Tue, 2 Apr 2019 07:45:40 -0700 (PDT) Received: by mail-qk1-x744.google.com with SMTP id c189so8046044qke.6 for ; Tue, 02 Apr 2019 07:45:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GgYDz4DAh7RYMhQtiWapgETDEuIDnMJM2pF8ygervPI=; b=QjrHAwyZLC6ZeDogZux8OAjqJvUaeUmnTXYqF/b16YALon5AbPsS2m98fiq2he8Zsv t3QZna/SdgViuXtGinGd+CIDzr1HIKlDbIEhZHq9D/TzyCARv+hHai2FniYa1eWd3qQy 1Lxg7pRFUCcH+k11gchKaWsPXtc9NlPl/S+Ei2+xjrofh5X3oNEikdGwEtccXc5N8MSW CMJFWDqPxuRV0zo5PsHyvY9P639Fa2rTSAwfvu6jkOONFfhhYudZnlNndfCMX37w1QMz 2OnOF/RujobWAoJUkuzZfL5QIlg8Xddf67T/3K3KwUMuqlMzNDGI40BjGH4n68Ts9dIh Wilw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GgYDz4DAh7RYMhQtiWapgETDEuIDnMJM2pF8ygervPI=; b=nOyz70uGZ2Hq5dVIOB2b3GC+KZywYHFuI1Uu80qv+khCXWjXOKcCvDnHaQm39xCDKr xZG8e4b+Y77//b5YZjenlaV+IIcAWjcqqPvAxmwitNuCXp10aqN5CWm+5mDOiebNWegk AU3a30x2g+lK3a+TwHtt0QeKyiIqZA2aeBp5o3ulrusXWbPHj2w3WGV1AGjPFYkAF1pL d8w6wq9UOPscv9+dVNrfg3tUNmb+y6atYyx2F/HUQu4w/BSsdRBhUs7C6UOjnU15YJJ8 NnYscRhGz3oOA1aCeZv/76sNXwoohWAYcl/pStCE5ebXGvkjSIlQH2tB3ggKe0MTUPPc gWlA== X-Gm-Message-State: APjAAAVMohv3jFytBGKAykvCUwmHbBh8W4lWeao08cj/4nXr5oq0cb7q Ayf0NHhd7LZ0xua2+6sZ6iCl3q0wvPq8JqELuBj9+w== X-Google-Smtp-Source: APXvYqy4wRUiSbUnQSXv89zvRoWlzvnUBtzINZry72rYJTdLXAwOW1ssrDwm4szFBjYxsjS3kK5QKUaeXpafnio636Q= X-Received: by 2002:a37:9bd4:: with SMTP id d203mr56387887qke.58.1554216337984; Tue, 02 Apr 2019 07:45:37 -0700 (PDT) MIME-Version: 1.0 References: <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> In-Reply-To: From: Tom Herbert Date: Tue, 2 Apr 2019 16:45:26 +0200 Message-ID: To: Mikael Abrahamsson Cc: "Frank Brockners (fbrockne)" , "C. M. Heard" , 6man WG , "ippm@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 14:45:46 -0000 On Tue, Apr 2, 2019 at 9:33 AM Mikael Abrahamsson wrote: > > On Tue, 2 Apr 2019, Tom Herbert wrote: > > > This is solved with proper use of the IPv6 flow label for ECMP instead > > of devices continuing to try to find 5 tuples buried deep within > > packets. DPI is only going to become harder as more headers and > > functionality are added (e.g. segment routing header will be another > > problem, deep headers will exceed parsing buffers, and it's impossible > > to find the 5 tuple for a fragment and still be stateless). Since IOAM > > is used in a limited domain, the requirement should be that all routers > > in the domain support ECMP routing using flow label (note that is a less > > stringent requirement than all routers having to support IOAM). > > From what I have seen so far, most devices if they support flow label for > ECMP, can/will use the flow label in *addition* to 5-tuple. > Mikael, They can do that if they want, but it's less reliable then just using the flow label and three tuple. There is no gaurantee that the five tuple can be consistently determined for all packets of a flow for a number of reasons. Even with the just the IOAM in an EH, there are going to be devices that don't have the logic to skip over an EH to find the transport layer, so that motivates that the idea that every packet needs to have the IOAM attached whether it's needed or not (hence it is an overhead tax). > For the requirement of IOAM to not have separate ECMP characteristics then > the entire IOAM domain will have to be configured to use 2-tuple + flow > label? > It is a SHOULD. IMO, it's a less invasive requirement than requiring all routers in the domain to support IOAM or that IOAM must be set in every packet. > Do we have data on how much end systems use flow labels nowadays? If this > is low, do we have data from OS vendors that they're considering > increasing the use of flow labels? All major OSes (Windows, iOS, FreeBSD, Linux) now set the label by default per RFC6437 and the flow label is usable for ECMP as described in RFC6438. Linux has been automatically setting flow labels since 2014. So they are definitely being set on packets in the Internet. I'm not sure if anyone has yet done measurements on how pervasive they are, but it would be easy enough for a major application or service provider to count them. I should also point out that even if the flow label is not set, ECMP still works and gives consistent results where a "flow" is all packets sent from one IP address to another. The granularity of doing ECMP per transport flow is really only needed when there are a lot of flows over some IP address pair like in a tunnel for instance. There is a lot of incentive to use flow labels with tunnels to get ECMP. For a tunnel packet, the flow label is set as a hash for flow of an encapsulated packet and ECMP is effective just by using the three tuple of fields in the IP header. For a device trying to extract the 5-tuple they would need to parse over encapsulation shim layers to find the transport layer. Again, finding the 5-tuple is considerable work and there's no guarantee that parsing a particular encapsulation protocol (there are a lot of them) is supported by all devices or that inner five tuple is even observable (e.g. the tunnel could be encrypted). Tom > > -- > Mikael Abrahamsson email: swmike@swm.pp.se From nobody Tue Apr 2 18:13:46 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A590120401; Tue, 2 Apr 2019 18:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 AxGQJ-a-FyZH; Tue, 2 Apr 2019 18:13:41 -0700 (PDT) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B83921203EB; Tue, 2 Apr 2019 18:13:40 -0700 (PDT) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Forcepoint Email with ESMTPS id 5293232D106E4B667E1E; Wed, 3 Apr 2019 09:13:38 +0800 (CST) Received: (from root@localhost) by mse02.zte.com.cn id x331DalZ025670; Wed, 3 Apr 2019 09:13:36 +0800 (GMT-8) (envelope-from guo.jun2@zte.com.cn) Message-Id: <201904030113.x331DalZ025670@mse02.zte.com.cn> Received: from njxapp03.zte.com.cn ([10.41.132.202]) by mse02.zte.com.cn with SMTP id x331CGco024229; Wed, 3 Apr 2019 09:12:16 +0800 (GMT-8) (envelope-from guo.jun2@zte.com.cn) Received: from mapi (njxapp05[null]) by mapi (Zmail) with MAPI id mid201; Wed, 3 Apr 2019 09:12:17 +0800 (CST) Date: Wed, 3 Apr 2019 09:12:17 +0800 (CST) X-Zmail-TransId: 2afd5ca408718b90c2c2 X-Mailer: Zmail v1.0 In-Reply-To: References: CABUE3X=MwMqbzf+hasZCMYLO60VxvUc=kMZoSJcWwJstY-CN4g@mail.gmail.com Mime-Version: 1.0 From: To: Cc: , , , , Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse02.zte.com.cn x331DalZ025670 X-MSS: AUDITRELEASE@mse02.zte.com.cn Archived-At: Subject: Re: [ippm] =?utf-8?q?IPR_Poll_for_draft-ietf-ippm-stamp-05?= X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 01:13:44 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksIGFzIHRoZSBjby1hdXRob3IsIEknbSBub3QgYXdhcmUgb2YgYW55IHVuZGlzY2xvc2VkIElQ UiByZWxhdGVkIHRvIGRyYWZ0LWlldGYtaXBwbS1zdGFtcA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K6YOt5L+KIGd1b2p1bg0KDQoNCg0KDQoN Cg0K6L2v5Lu25byA5Y+R5bel56iL5biIICBEZXZlbG9wbWVudApFbmdpbmVlcg0K5YiG57uE5Y2X 5Lqs6L2v5Lu25byA5Y+R5LiA6YOoL+aciee6v+eglOeptumZoi/mnInnur/kuqflk4Hnu4/okKXp g6ggUGFja2V0IE5hbmppbmcgU29mdHdhcmUgRGV2ZWxvcG1lbnQgRGVwdC4gSS9XaXJlbGluZSBQ cm9kdWN0IE9wZXJhdGlvbiBEaXZpc2lvbg0KDQoNCg0KDQoNCg0KDQoNCg0K5Y2X5Lqs5biC6Zuo 6Iqx5Y+w5Yy657Sr6I2G6Iqx6LevNjjlj7fkuK3lhbTpgJrorq/ljZfkuqznoJTlj5HkuK3lv4Pk uIDmnJ8NClQ6ICs4NiA3NTUgeHh4eHh4eHggRjorODYgNzU1IHh4eHh4eHh4IA0KTTogKzg2IDE4 MTA1MTgzNjYzDQpFOiBndW8uanVuMkB6dGUuY29tLmNuIA0Kd3d3Lnp0ZS5jb20uY24NCg0KDQoN Cg0KDQoNCuWOn+Wni+mCruS7tg0KDQoNCg0K5Y+R5Lu25Lq677yaVGFsTWl6cmFoaSA8dGFsLm1p enJhaGkucGhkQGdtYWlsLmNvbT4NCuaUtuS7tuS6uu+8mklFVEYgSVBQTSBXRyA8aXBwbUBpZXRm Lm9yZz47R3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbT476YOt5L+KMTAwODY5Nzk7 aG55ZGVsbEBhY2NlZGlhbi5jb20gPGhueWRlbGxAYWNjZWRpYW4uY29tPjtmb290ZXIuZm9vdGVA bm9raWEuY29tIDxmb290ZXIuZm9vdGVAbm9raWEuY29tPjsNCuaKhOmAgeS6uu+8mmlwcG0tY2hh aXJzQGlldGYub3JnIDxpcHBtLWNoYWlyc0BpZXRmLm9yZz47DQrml6Ug5pyfIO+8mjIwMTnlubQw NOaciDAx5pelIDE1OjQ3DQrkuLsg6aKYIO+8mklQUiBQb2xsIGZvciBkcmFmdC1pZXRmLWlwcG0t c3RhbXAtMDUNCg0KDQoNCg0KDQoNCg0KSGksDQoNClRoaXMgZW1haWwgYmVnaW5zIGEgdHdvLXdl ZWsgcG9sbCBmb3IgYW55IElQUnMgdGhhdCBtYXkgYXBwbHkgdG8gZHJhZnQtaWV0Zi1pcHBtLXN0 YW1wLTA1Lg0KDQpBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0 LWlldGYtaXBwbS1zdGFtcC0wNT8gDQoNClNwZWNpZmljYWxseSwgaWYgeW91IGFyZSBsaXN0ZWQg YXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IsIHBsZWFzZSByZXNwb25kIHRvIHRo aXMgZW1haWwgKHJlcGx5LXRvLWFsbCkgc3RhdGluZyB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3 YXJlIG9mIGFueSByZWxldmFudCBJUFIuDQoNCklmIHlvdSBhcmUgYXdhcmUgb2YgYSByZWxldmFu dCBJUFIsIHBsZWFzZSBzdGF0ZSB3aGV0aGVyIHRoaXMgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBp biBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM5NzksIDQ4NzksIDM2 NjkgYW5kIDUzNzggZm9yIG1vcmUgZGV0YWlscykuDQoNClRoaXMgcG9sbCBjbG9zZXMgb24gdGhl IDE1dGggb2YgQXByaWwgMjAxOS4NCg0KQmVzdCByZWdhcmRzLA0KVGFsLg0KW0FzIHNoZXBoZXJk IG9mIGRyYWZ0LWlldGYtaXBwbS1zdGFtcF0= --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZh bWlseTphcmlhbDsiPjxzcGFuIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94OyBsaW5lLWhl aWdodDogMjBweDsgZm9udC1mYW1pbHk6IEFyaWFsLCDlrovkvZMsICdNaWNyb3NvZnQgWWFoZWkn LCAnTHVjaWRhIEdyYW5kZScsIFZlcmRhbmEsIEx1Y2lkYSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlm OyBvdXRsaW5lOiAwcHggIWltcG9ydGFudDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1 LCAyNTUpOyI+SGksJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXIt Ym94OyBsaW5lLWhlaWdodDogMjBweDsgZm9udC1mYW1pbHk6IEFyaWFsLCDlrovkvZMsICdNaWNy b3NvZnQgWWFoZWknLCAnTHVjaWRhIEdyYW5kZScsIFZlcmRhbmEsIEx1Y2lkYSwgSGVsdmV0aWNh LCBzYW5zLXNlcmlmOyBvdXRsaW5lOiAwcHggIWltcG9ydGFudDsgYmFja2dyb3VuZC1jb2xvcjog cmdiKDI1NSwgMjU1LCAyNTUpOyI+YXMgdGhlIGNvLWF1dGhvciwgSSdtIG5vdCBhd2FyZSBvZiBh bnkgdW5kaXNjbG9zZWQgSVBSIHJlbGF0ZWQgdG8gZHJhZnQtaWV0Zi1pcHBtLXN0YW1wPC9zcGFu PjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij48YnI+PC9w PjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZhbWlseTphcmlhbDsiPjxicj48L3A+PHAg c3R5bGU9ImZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5OmFyaWFsOyI+PGJyPjwvcD48cCBzdHls ZT0iZm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij48YnI+PC9wPjxkaXYgY2xhc3M9 InpNYWlsU2lnbiIgdW5vbmFtZWNoPSLpg63kv4oxMDA4Njk3OSIgdW5vbmFtZWVuPSJndW8ganVu MTAwODY5NzkiPjxwIGNsYXNzPSJ6TWFpbFNpZ25UaXRsZSIgdW5vbmFtZWNoPSLpg63kv4oxMDA4 Njk3OSIgdW5vbmFtZWVuPSJndW8ganVuMTAwODY5NzkiIHN0eWxlPSJkaXNwbGF5OiBub25lOyI+ PGxhYmVsIGNsYXNzPSJzaWduX25hbWVVbm8iPjwvbGFiZWw+PHNwYW4gY2xhc3M9InNpZ25fYXJy b3ciPjwvc3Bhbj48L3A+PGRpdiBjbGFzcz0iek1haWxTaWduQ29udGVudCI+PGRpdj48ZGl2Pjxk aXY+PHAgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZM7IGZvbnQtc2l6ZToxNHB4OyBsaW5lLWhl aWdodDogbm9ybWFsOyB3aWRvd3M6IDE7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0cHg7Y29s b3I6IzU4NTk1Qjtmb250LWZhbWlseTrlvq7ova/pm4Xpu5E7Zm9udC1zaXplOjE0cHg7Ij48c3Bh biBjbGFzcz0ic2lnbmVkaXQiPjxicj48L3NwYW4+PC9zcGFuPjwvcD48cCBzdHlsZT0iZm9udC1m YW1pbHk6IOWui+S9kzsgZm9udC1zaXplOjE0cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IHdpZG93 czogMTsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTRweDtjb2xvcjojNTg1OTVCO2ZvbnQtZmFt aWx5OuW+rui9r+mbhem7kSI+PHNwYW4gY2xhc3M9InNpZ25lZGl0IiBpZD0ic2lnbl9uYW1lIj7p g63kv4o8L3NwYW4+IDxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpBcmlhbCI+PHNwYW4gY2xhc3M9 InNpZ25lZGl0IiBpZD0ic2lnbl9uYW1lX2VuZyI+Z3VvanVuPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgd2lkb3dz OiAxOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNHB4O2NvbG9yOiM1ODU5NUI7Zm9udC1mYW1p bHk65b6u6L2v6ZuF6buRO2ZvbnQtc2l6ZToxNHB4OyI+PHNwYW4gc3R5bGU9IiI+PHNwYW4gY2xh c3M9InNpZ25lZGl0Ij48YnI+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9wPjxwIHN0eWxlPSJmb250 LWZhbWlseTog5a6L5L2TOyBmb250LXNpemU6MTRweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgd2lk b3dzOiAxOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNHB4O2NvbG9yOiM1ODU5NUI7Zm9udC1m YW1pbHk65b6u6L2v6ZuF6buRIj48c3BhbiBjbGFzcz0ic2lnbmVkaXQiIGlkPSJzaWduX3Bvc2l0 aW9uIj7ova/ku7blvIDlj5Hlt6XnqIvluIg8L3NwYW4+Jm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OkFyaWFsIj48c3BhbiBjbGFzcz0ic2lnbmVkaXQiIGlkPSJzaWduX3Bvc2l0aW9uX2Vu ZyI+Jm5ic3A7RGV2ZWxvcG1lbnQKRW5naW5lZXI8L3NwYW4+PC9zcGFuPjwvc3Bhbj48YnI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxNHB4O2NvbG9yOiM1ODU5NUI7Zm9udC1mYW1pbHk65b6u6L2v 6ZuF6buRIj48c3BhbiBjbGFzcz0ic2lnbmVkaXQiIGlkPSJzaWduX2RlcHQiPuWIhue7hOWNl+S6 rOi9r+S7tuW8gOWPkeS4gOmDqC/mnInnur/noJTnqbbpmaIv5pyJ57q/5Lqn5ZOB57uP6JCl6YOo PC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6QXJpYWwiPiA8c3BhbiBjbGFzcz0ic2ln bmVkaXQiIGlkPSJzaWduX2RlcHRfZW5nIj5QYWNrZXQgTmFuamluZyBTb2Z0d2FyZSBEZXZlbG9w bWVudCBEZXB0LiBJL1dpcmVsaW5lIFByb2R1Y3QgT3BlcmF0aW9uIERpdmlzaW9uPC9zcGFuPjwv c3Bhbj48L3NwYW4+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDsgbGluZS1oZWlnaHQ6IG5v cm1hbDsgd2lkb3dzOiAxOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNHB4O2NvbG9yOiM1ODU5 NUI7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buRO2ZvbnQtc2l6ZToxNHB4OyI+PHNwYW4gc3R5bGU9 IiI+PHNwYW4gY2xhc3M9InNpZ25lZGl0Ij48YnI+PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9wPjxw IHN0eWxlPSJmb250LXNpemU6MTRweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgd2lkb3dzOiAxOyI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNHB4O2NvbG9yOiM1ODU5NUI7Zm9udC1mYW1pbHk65b6u 6L2v6ZuF6buRO2ZvbnQtc2l6ZToxNHB4OyI+PC9zcGFuPjwvcD48dGFibGUgc3R5bGU9ImNvbG9y OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiDlrovkvZM7IHdpZG93czogMTsiPjx0Ym9keT48 dHIgY2xhc3M9ImZpcnN0Um93Ij48dGQgdmFsaWduPSJ0b3AiIHdpZHRoPSIxMDAiPjxpbWcgaWQ9 InNpZ24taWNvbiIgc3JjPSJjaWQ6OWFlM2UyMTRjMTdkNDllZDkzNWQ4N2M2NzRiYTNlZTIiIHdp ZHRoPSIxMzAiIGhlaWdodD0iMTIwIj48L3RkPjx0ZCB2YWxpZ249InRvcCIgd2lkdGg9IjUwMCIg c3R5bGU9IndvcmQtYnJlYWs6IGJyZWFrLWFsbDsiPjxpbWcgaWQ9InNpZ24tbG9nbyIgc3JjPSJj aWQ6MjQyNDJlNTYzN2FmNDI4ODkxYzRkYjczMWU3NzY1YWQiIHdpZHRoPSIxMTUiIGhlaWdodD0i MzgiPjxicj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0cHg7Y29sb3I6IzU4NTk1Qjtmb250LWZh bWlseTrlvq7ova/pm4Xpu5EiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDE0cHg7IGNvbG9yOiBy Z2IoODgsIDg5LCA5MSk7IGZvbnQtZmFtaWx5OiDlvq7ova/pm4Xpu5E7Ij7ljZfkuqzluILpm6jo irHlj7DljLrntKvojYboirHot682OOWPt+S4reWFtOmAmuiur+WNl+S6rOeglOWPkeS4reW/g+S4 gOacnzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6QXJpYWwiPjxicj48c3BhbiBzdHls ZT0iY29sb3I6IzAwOEZENCI+VDwvc3Bhbj46IDxzcGFuIGNsYXNzPSJzaWduZWRpdCIgaWQ9InNp Z25fZml4X3Bob25lIj4rODYgNzU1IHh4eHh4eHh4PC9zcGFuPiA8c3BhbiBzdHlsZT0iY29sb3I6 IzAwOEZENCI+Rjwvc3Bhbj46PHNwYW4gY2xhc3M9InNpZ25lZGl0IiBpZD0ic2lnbl9mYXgiPis4 NiA3NTUgeHh4eHh4eHg8L3NwYW4+IDxicj48c3BhbiBzdHlsZT0iY29sb3I6IzAwOEZENCI+TTwv c3Bhbj46IDxzcGFuIGNsYXNzPSJzaWduZWRpdCIgaWQ9InNpZ25fcGhvbmUiPis4NiAxODEwNTE4 MzY2Mzwvc3Bhbj48YnI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDhGRDQiPkU8L3NwYW4+OiA8c3Bh biBjbGFzcz0ic2lnbmVkaXQiIGlkPSJzaWduX2VtYWlsIj5ndW8uanVuMkB6dGUuY29tLmNuPC9z cGFuPiA8YnI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDhGRDQiPjxhIGhyZWY9Imh0dHA6Ly93d3cu enRlLmNvbS5jbi8iIHRhcmdldD0iX2JsYW5rIj53d3cuenRlLmNvbS5jbjwvYT48L3NwYW4+PC9z cGFuPjwvc3Bhbj48L3RkPjwvdHI+PC90Ym9keT48L3RhYmxlPjxzcGFuIHN0eWxlPSJsaW5lLWhl aWdodDogbm9ybWFsOyB3aWRvd3M6IDE7IGZvbnQtc2l6ZToxNHB4Oztjb2xvcjojNTg1OTViO2Zv bnQtc2l6ZToxMHB4Ij48L3NwYW4+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48 ZGl2IGNsYXNzPSJ6aGlzdG9yeVJvdyIgc3R5bGU9ImRpc3BsYXk6YmxvY2siPjxkaXYgY2xhc3M9 InpoaXN0b3J5RGVzIiBzdHlsZT0id2lkdGg6IDEwMCU7IGhlaWdodDogMjhweDsgbGluZS1oZWln aHQ6IDI4cHg7IGJhY2tncm91bmQtY29sb3I6ICNFMEU1RTk7IGNvbG9yOiAjMTM4OEZGOyB0ZXh0 LWFsaWduOiBjZW50ZXI7IiBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5T3JnVHh0Ij7ljp/lp4vpgq7k u7Y8L2Rpdj48ZGl2IGlkPSJ6d3JpdGVIaXN0b3J5Q29udGFpbmVyIj48ZGl2IGNsYXNzPSJjb250 cm9sLWdyb3VwIHpoaXN0b3J5UGFuZWwiPjxkaXYgY2xhc3M9InpoaXN0b3J5SGVhZGVyIiBzdHls ZT0icGFkZGluZzogOHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiAjRjVGNkY4OyI+PGRpdj48c3Ryb25n IGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlTZW5kZXJUeHQiPuWPkeS7tuS6uu+8mjwvc3Ryb25nPjxz cGFuIGNsYXNzPSJ6cmVhZFVzZXJOYW1lIj5UYWxNaXpyYWhpICZsdDt0YWwubWl6cmFoaS5waGRA Z21haWwuY29tJmd0Ozwvc3Bhbj48L2Rpdj48ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlz dG9yeVRPVHh0Ij7mlLbku7bkurrvvJo8L3N0cm9uZz48c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFt ZSIgc3R5bGU9ImRpc3BsYXk6IGlubGluZTsiPklFVEYgSVBQTSBXRyAmbHQ7aXBwbUBpZXRmLm9y ZyZndDs7PC9zcGFuPjxzcGFuIGNsYXNzPSJ6cmVhZFVzZXJOYW1lIiBzdHlsZT0iZGlzcGxheTog aW5saW5lOyI+R3JlZyBNaXJza3kgJmx0O2dyZWdpbWlyc2t5QGdtYWlsLmNvbSZndDs7PC9zcGFu PjxzcGFuIGNsYXNzPSJ6cmVhZFVzZXJOYW1lIiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyI+6YOt 5L+KMTAwODY5Nzk7PC9zcGFuPjxzcGFuIGNsYXNzPSJ6cmVhZFVzZXJOYW1lIiBzdHlsZT0iZGlz cGxheTogaW5saW5lOyI+aG55ZGVsbEBhY2NlZGlhbi5jb20gJmx0O2hueWRlbGxAYWNjZWRpYW4u Y29tJmd0Ozs8L3NwYW4+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUiIHN0eWxlPSJkaXNwbGF5 OiBpbmxpbmU7Ij5mb290ZXIuZm9vdGVAbm9raWEuY29tICZsdDtmb290ZXIuZm9vdGVAbm9raWEu Y29tJmd0Ozs8L3NwYW4+PC9kaXY+PGRpdj48c3Ryb25nIGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlD Q1R4dCI+5oqE6YCB5Lq677yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUiIHN0 eWxlPSJkaXNwbGF5OiBpbmxpbmU7Ij5pcHBtLWNoYWlyc0BpZXRmLm9yZyAmbHQ7aXBwbS1jaGFp cnNAaWV0Zi5vcmcmZ3Q7Ozwvc3Bhbj48L2Rpdj48ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0i SGlzdG9yeURhdGVUeHQiPuaXpSDmnJ8g77yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9IiI+MjAxOeW5 tDA05pyIMDHml6UgMTU6NDc8L3NwYW4+PC9kaXY+PGRpdj48c3Ryb25nIGxhbmd1YWdlLWRhdGE9 Ikhpc3RvcnlTdWJqZWN0VHh0Ij7kuLsg6aKYIO+8mjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJ6cmVh ZFRpdGxlIj48c3Ryb25nPklQUiBQb2xsIGZvciBkcmFmdC1pZXRmLWlwcG0tc3RhbXAtMDU8L3N0 cm9uZz48L3NwYW4+PC9kaXY+PC9kaXY+PGRpdiBjbGFzcz0iemhpc3RvcnlDb250ZW50Ij48ZGl2 PjxkaXYgZGlyPSJsdHIiPjxkaXYgZGlyPSJsdHIiPjxkaXYgZGlyPSJsdHIiPjxkaXYgZGlyPSJs dHIiPjxkaXYgZGlyPSJsdHIiPjxkaXY+SGksPC9kaXY+PGJyPjxkaXY+VGhpcyBlbWFpbCBiZWdp bnMgYSB0d28td2VlayBwb2xsIGZvciBhbnkgSVBScyB0aGF0IG1heSBhcHBseSB0byBkcmFmdC1p ZXRmLWlwcG0tc3RhbXAtMDUuPC9kaXY+PGJyPjxkaXY+QXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBS IHRoYXQgYXBwbGllcyB0byBkcmFmdC1pZXRmLWlwcG0tc3RhbXAtMDU/Jm5ic3A7PC9kaXY+PGJy PjxkaXY+U3BlY2lmaWNhbGx5LCBpZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhv ciBvciBjb250cmlidXRvciwgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCAocmVwbHktdG8t YWxsKSBzdGF0aW5nIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50 IElQUi48L2Rpdj48YnI+PGRpdj5JZiB5b3UgYXJlIGF3YXJlIG9mIGEgcmVsZXZhbnQgSVBSLCBw bGVhc2Ugc3RhdGUgd2hldGhlciB0aGlzIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxp YW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1 Mzc4IGZvciBtb3JlIGRldGFpbHMpLjwvZGl2Pjxicj48ZGl2PlRoaXMgcG9sbCBjbG9zZXMgb24g dGhlIDE1dGggb2YgQXByaWwgMjAxOS48L2Rpdj48YnI+PGRpdj5CZXN0IHJlZ2FyZHMsPC9kaXY+ PGRpdj5UYWwuPC9kaXY+PGRpdj5bQXMgc2hlcGhlcmQgb2YmbmJzcDtkcmFmdC1pZXRmLWlwcG0t c3RhbXBdPC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9k aXY+PC9kaXY+PC9kaXY+PC9kaXY+PHA+PGJyPjwvcD48L2Rpdj4= --=====_003_next=====-- --=====_002_next===== Content-Type: image/jpeg; name="=?UTF-8?B?MjQyNDJlNTYzN2FmNDI4ODkxYzRkYjczMWU3NzY1YWQuanBn?=" Content-Disposition: inline; filename="=?UTF-8?B?MjQyNDJlNTYzN2FmNDI4ODkxYzRkYjczMWU3NzY1YWQuanBn?=" Content-Transfer-Encoding: base64 Content-ID: <24242e5637af428891c4db731e7765ad> R0lGODlhcwAmAPcAAAAAAP///wCP1QCP1Pf7/vL5/QCP1gWR1gqT1gyU2AyU1w6V1xWY2BeZ2R6c 2iGd2iyi3C6j3TOl3Tqo3kWt4Emv4Uyw4U2x4lOz4ly35F645GO65WW75me85m6/53XC6IHH64XJ 64bK7IzM7I/N7JXQ7ZfR7pnS7pzT7p3U76PW8KPW76XX8K7b8bDc8rff87vh9Lzh9L7i9cnn9tLr +Nnu+eDx+uf0++n1++33/PD4/PT6/fj8/gKQ1AWR1QeS1QiT1QmT1g+W1xCW1xOX1xia2Bub2Ryb 2R+d2SCd2SKe2iSf2iag2ymh2yqh2yui3DSm3Tio3Typ3j2q3j6q3kCr30Os30eu4Euw4U6x4U+y 4k+y4VGz4lCy4Va141W04li241q341245F+55GW75Ga85Wm95mi95Gq+5Wu+5m2/5m/A53HB6HDA 53HB5nLB53PC53XC53bD53nE6HvF6X3G6X/H6YHI6oHI6YLI6oLI6YbK64TJ6YnL64rM64zM65HP 7JPQ7ZbR7ZrT7qXX76bY8KfY76jZ8Kra8azb8a/c8bDc8bHd8rLd8rXe8rXe8bjg87zi9Lzh873i 88Dj9MPl9cXm9cfm9cnn9c3p9s/q987p9tHr99Lr99Xt+Nbt+Nrv+d/x+eDx+eX0++Tz+u/4/OHy +ePz+ur2+/b7/fr9/vz+/v7//////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAK0ALAAAAABzACYA Rwj/AAMIHEiwoMGDCBMqXMiwoUOGiti0mUhxopcBAgZoHKAglcATFaVg3DgAC0U2hgKsKkJyiZqK FUV4bHijx4AHDFmN0BiJ4A2NRFYRJKAAo6WFKzJibOCQEclMB1WxxOgDUQEeqbKm2sEDoQaMhAqS sonE4B2MeQ7WmGlwj0YKCv0oHeDkIUGnAvJCNShVowA7dgXyyXKhsGEJG6kYNqxFUEImGSsQDJFR gOSClUj61cx5wAmEBKJk9JIwTefTaxzaGNnQxhIBex0WAUPwRZoOZnLr3q27Q6CBKXgL742mhUBW e3AP771HlcNSaDjQCVwwByQc1A2+9vtbodONsQn2/8UI2O6F03lP+/1QcEpeJgMbabwyMEzeOQuJ bBSAyC5ejeENNN5GQzBAxIEHNgAGAQZ9JQAlBvUggBIGlYDWQBtYoKGGW1yw4YZacPGhBVjsIRAB B4xEV3YCfZdRgAKNJ0ATLBo01gBlOXSIARgpohAEeQkgSo1EFmnkkUgmqeSSCKkxl3qaMRUBZ5V1 llcHAaQ40lxP+uXQWALkmB0HGplhECYHWADDQ24oJYAVClHilwCgRMVSXiYGhgIZG/TZZxlXaNTD F2X4+adxA+Fg0wBkEGTfACkQhNgAKzR0iop0MvQdgHZu5EdgXw0AYUE2UViQhQKkVdAcQZYSAA9D GP/xxQ4B1KHRFg1h4OYYDzHiJowBDKgiSZXlSZAGeYVFEJhiDnRHXnoM5EOXxO7HmQMGdRJkRtj5 txmwMqoRWBZPplftuXEkxIUJBj2CxUJSVPkGi5sOAO5UA6hqJCql2sVKEBilcRCyAxhQB0GFqEet X3IglAhJlxzEAwPoaSaABV+S1VAmQ+RlREOTBHkGkySXbPLJKKes8sosC6TJllCS9JshC8NsbSUB eFAzZ244FIpSNfrRxADsGoRKQS/ETCWWIShspSMBUGyteu82dGOzCr3AR0EyaESFQU4OAJdDcBC7 SEJjuJmuQTzg+0SSNmG7ECuQDZBAQUlo9AlBg2D/BMVDm2wpQA4KOUISJ53mpa9DJVRmLkZcUgv1 QDRjRMNAI2SUmkAzYDSEcw3xMVcEmj7VqUblPSRGRl2ooMIKK6hAh0Y/kMBC7K9PkBceBeGwUaUB gLKRc/xqZIpD7vkFR0Obwna6AGiAqlEhBY1iUxIG5YFRtAZh1IYOAh090AIY9cRQAUBALsBRzM91 734CICDEAvQvoMAQGNBaELICKDvQ1Wa5kEBi4IJGNMITmTCgAhvhgg8o5QsvMKALcHaQSKRHAAro SlO+ZafHQQ5mAuhDg8AiFo0VBAQCDAAIMWWuKlWGKQZJg5vg5C2/vI92LujKKna4CtAdRAwa8QIL 7YY4xLPErwREHGIVMMI7km0nL4CgjovsdboBiNAumbPYsKpkLUQZRAZ5+dtAOrEAAXwtITjgkiey U68bDiB1RSKARo4QmEOkR3wDOUNlMnCQQrgJPvQyHV+KUCwkAfAhYMjLD4RyECxUJhEESeRmBCAB mMCkBAlpnhsHwAQPWHIifWCQ1UzIEFAEqQsLwQEQ8gIBgWiBS0qbI0JeMJcaHGQV04plXr6kEbkp hBVTEkAPjtcQOWSEVwGQxBw+wMxmOvOZHxiEQnIAgj1o8JZ/gKY2SeDDhejgDW1YnEI+AUm7fIKR LUunOtfJThYFBAA7 --=====_002_next===== Content-Type: image/jpeg; name="=?UTF-8?B?OWFlM2UyMTRjMTdkNDllZDkzNWQ4N2M2NzRiYTNlZTIuanBn?=" Content-Disposition: inline; filename="=?UTF-8?B?OWFlM2UyMTRjMTdkNDllZDkzNWQ4N2M2NzRiYTNlZTIuanBn?=" Content-Transfer-Encoding: base64 Content-ID: <9ae3e214c17d49ed935d87c674ba3ee2> R0lGODlhggB4AHcAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQICgAAACwAAAAAggB4AIcATr79vg2j x+twuSDo8tdNjNSk0mTQ57AojVB4uI7+1GPI3/P+6rKPxan9yjsBes4/gtD+34y61u9jm9rr9vva 7Pek0aolccv///8Baccki9Sj0FwSfM6DtOOAv2Wy1e9Mo92axurf78n9xisLacf+2XNwpN33+vE7 m9r9zkv+89Q0jNWMvebh7/nL5KPR5vbC3vP+5Jxks+NbpN10u+UDg9Gqzuyi0YLx9+aTvuYkhNF/ wDbZ7L0cjNQAdccAZMUlkta73Y0Ybsn+z1CUyk5LnNpiqd88k9f9whz+3YNNqt9EnNr0+/18vOaF weczm9oBjNQae879xzK426PV7fjc8vqIxCek0u79zEP+5qR8r+Cd0u5ss+O84vT+8Mlbqd8Le87M 6fdTnNrl8dMrg9G22e8BXcMKdMsrdcyUyuuMy+xtqd+s1vAsktb+9t3+1muy2Hqs1XTt+f1xsdvE 4/X9012BwQ3u9uIwjelDkteKxTTW6rr+23tTo939xCNEo91ro92DvPd7wOcchNKEwoQ8jNRtvOZN ltg8o90sm9qIvui02YOm0/kri9QLgM/m+f1dseIUg9EMjNQOZsZUqd8NW8I0k9cSdMv+4ZObzOwk fM/H6ff+6Ku24PN1wunV8frz+esyhNHN5quDvOZcnNrU6vczeM2bzVpxr+y/35R7viO73PLb7cOn 0mz++OTE4Z2s2vHj8/oSbsphpN6TyTwAbMmU0O6r05rb7vn9wRTN7PlDi9Ti8M1Dltj+7LvT6LRK ktaTxene+Pw3od2EyetbrOHL5fV0reAse86d2PF6vSlzteMCk9am2PEtldigz/Eckdaz1/Gt1IW6 3IRjreGz3PkBVMBNseEzltg8mOH9yC9sreFVrOBSltgcdMs9ltgkldmKwOdhueUeftAAddCMw+mB v+kNbcnn89ir0+6jzex6tOP90E/q9NyVyPBEqd7R56+k0nH9yTSz2/ILftB8w+mAvyP92G390VQK hNEBdMuEw+kAfdARftD+/v7///8I/wAxCBxIsKDBgwgTKlzIsKHDhxAJMimHAgaGckvoYNgHgg6T JktKMaFRpBSGZSBKyeECogIFLn1iYeDyxSW1LxRiFeMmh8kXarGq9KHGBNdPDLH6cImFC8QyDC9A 0MBABUQTJsaWNMFAZ8koDFn3MemyJBiGVX/SYJiHItNaFFsiLkwH4goTarXSYZihjw2GPvrSyQFx xiMKfRaPgFkV69slY7Es0aOCoVEkY1UaaYpValAkCnIG6SjVeQUFY5E0FAXTBtcmDnmYrHrwhKu+ IhTmnenDJJ0+EBg+1OJ9pdY2DMH0ycCQptayibW+ZvozT67BJrW4gFXXgusVmXS+c/9NR+HslfKr 0slMT0E2GyZr2bRf9YEJkw/RBKaLZj/aKgwUpFNdb/MwIUc6FgX4HwVX/BcLgkhd0QVS6mgUiw3G YICLOhnickWGpahTwUw1uGXdWcGU8kIaGp3o4oswMsSEEpKsUkoT1UVUzAMmxujjjz5SoUMtsFzx ADVyZfLFf0A26eRDxswTxhrArGJME/lBSUd5T3YZC3xdFtSUDuowBSYT8zC5EBMgaGBRmE3OM0sw XMKJQRP6RAemQKvkg8KeCTExgyUt2hkjE1xY0wguhlLRiD5PbFJQVto1xMSXhv54BQo01NnlRA/w eJB9Db3gUaY/XiqHobGAoI8zlBn/REEzOSokxiVZogrjKtzs4+mTqP0gw6oGrXJJHgzRgEKhup6I aAYrjAhnUhr4dVApXJi1UE6ANisXBcXU0kascFYhUqDdHmTMKr96CxEFkOiTCLldzgPJFQnFkkmu CYnhDb+6VlFPPYw6RMEXPzRi0kNXGMKsQhQYYY0l7fKpzxEMdSDGw6iyUUsGejnERDBkzCKTQ1UU Ys1xlqpDilgIlbJNOO5CtMouBXQRS8UHUdAJvQvF8skxppQD0SbEvkhHNDzbyUQYYawyAw0nF8QE FfPYUh0uIaRT1BZX0FF1QVfMEIwuW4q8yhqZpCtQLGlYq9Af+nxQ80Cj/KAP1QRV/wELSJHoA4S+ ZuiAyyj6PIANNVvoAmgzGphxBNBBI+zM2AStoo8lDIHEcbPzAFHLA50KVMoMD+SpzyW94ALDEUux EMUZqrehzkDz9FALGII0fVAslECK+UAVcGH03RGFro8+acQixxWa/NDDH4bYIilSq8YCSz3XgHPG D7MwQUEYooPBN0SxcKMPIr43tG77mc7TRiQg9EJDGKNQM0/SCDGhiyfcSFMf3gGNSPROLunTxzCG 97Z9MaQIl5Ab8qgShmVUQgfGIJVAVBCDJCShBAp4Ax8w4QWB2IcC67CGBmBxLgSqLxEMxEAZZIGs hYyiDxmaoOmoYIxllKNOWVCAA//8II8I4CMXSPADEkZQB04MZBViaB4V3MYQnfzAEjGsQBN6FCj4 xa8NjdgfmHyhgBH4YQQjkEcS+CCPETjAAW1EAj5KiJRYUIMM++DfQ9jQh2BQEQN/JAgd2BDDgP1h dLDYIB+kQEQ4ysMBUsBHDCJQhwjEoAR1SGMWTHiEH0Qikdapgh77tg98LaQIZ7Ab8iayPBnIxBUx wAIS5IEFB9QhCW9QQAmScA985DIFSYhAEmMgEHVEIgMgqEJEmHCFOVFRc5xbCAtmkcO7GaMNtYCV QDiByzfIEguYiEEddukANyoRCxHIAj4CMIJNMgESZwCDWt7VB2tgg2e4WAcXdZj/EDnsI3H7EIg6 bRmDN+AjAkI8IxbQSMs68OGhJXBAABzgBq4AIQN/oJxCZKPPQDZkFeK5G/B+0BoMeCEFSpRHCdLJ h1yMAB/4wEIJMBnOOsgDH5gogTxu6YqZZOCTEYmFRgcSi2CETCGHAeXd2ACCeSbBD1gYgjzkoYAy yuMenKCkF2KQgqrKAwkO4IMHIzACJ9JBDFxQ5kN00gs1GWQetYimQpoAgmq6KxZhUCsGFIAEEQ7x jG/AxBvekAIHYKKMSXRAYV+ahSTkogRvo0IVPEoQWOgjAzA7SPGOx0+FLIMDAcWAG/CBBD5koQ4p wIcCJimPRmKBD5eEIxZSIA8p/2BCmCmoaFZK4hCd1CISbjUIZcEyDy++qCcCkQMFllsFQFSCNwLh KxYGiwlOvAGODsBCLUeggDXyAR+0dAA7kmDVEqphEqaIhnJBAx8DYaAKm5AJBfZRA31Q4o8tCIYp bSWL2xlDHYxhQgX2EwtMuYgOf5ABBeighCcg4gnFUMcHCoWJJNIyBQ+VrXa164BcpCALb3CjTOvw RnkwAAO6SEMImoCIPyBiGGlgQibqwgXQrmR5PajVQVZBQ48GgxppuFIPuNEJY2QCGyCYxxWkdaIQ mOEMpQiBLDKgD73JQBgFeQMStjzR645gwxzuawzwoQ3tFvaN2tgkIGFBBr3V4v8HRfgEKczQhyWY YRmxEIMZejDPhFRgFLdb03rDAIstUQAX89CZgU9kjBlw4TTUWEIfvoCCfPRCx67IAghDSFgzErG1 KvUFJ1Lw5Vpmt5ybjMUyNJCIGdS5CJmQgzrEIKFyZGgV4VjFcD+aCeO6aGeRxUUskuGIWoSWIK5I thtU4AVu4mMEKSjBG9aYhDoQccMOWKIvuDIkQzCFCrho72QBOZDhtqAc+03IEs4QXF3RQQP6qIdD VJBV8mIBqhHgQznTmIKuVnQVjyJGkzSHAob82CP20WCmuqCBB8j7ISpAqRTayAdOhLAE+BArJgQC i4YLHEi42GJvq0ByybrbEvr/EEdEMHHGwmJBtZY0aApOjAE15AMMcanZKtJQigL7XFe4KMIPnlBI hPAhsQ7QhmIXGgAFDEQGP9CBjmN0uEAjVR/tRhUT1iGLPvhaIK7ggxmnasYA5KIOPRXIMkhQBL36 aB76+AZDylGMFyAvDPuYkHWCiIWpyoMdmEi7QIxhiHT7CBfm2Gf/9rRrH9knFlfw2omanQUGVLTc Si66ixSeEBikQWck/8S4DRXyfYTjHOMIg5OoEApjN94hVWeIGM7RNjkERfM+ioUMaqGDYjQCBbgP KggeIIkkD/xYDEkDFxamq1hA4gG1QAFkwkCHguXeGB7SQcIM/6JYqOGo6HLX/zpqUYsn6F0dOgBB 8BlysEbgKxxgEJdSdcWGclgfVZCoBTb0zoRRUPkqMbIPD/ADT0EBTQAGP3AEqhcjpbAMfZYQvVAL bRMUogcjuJAGnrAP+1APnjCBTfB5W6B3g4cNv5UGo2cdbDAI4sIkBsgBS+B2LgJXbcAQmXAMdGB7 VVCBCNQE1OAh8RcqeRIFXZAJP8ABzEcQufMAPQAC+mMdq+AM+pAP6TYrSrYN3BcR52Z1mRIGZ2AG mUAHRxAFGjCGUZAHhIYMCogQ9SAJoVJ+n6MQuLAEP0A66SIHS2ANS/B6LhINmbB+MTMPxrANVYIB m5AMsDAPsNAMGcIEzdAFVP/UBT1QA8xQAw/AWQ5RAUPiSj0zCrvAAnooJoDGECiQFy7SFP2QBnLw CJ84EMbQcFBQAzWgLQ0RC11AB2lwPqPyCauYObWAMQuRBpSwP0FRBX7IBP+UAQD4IojCAanTB0e4 EOWwG7sYERWwDzm3EDhIcroAg3B4GM6wgDAyXwn2jBs1CpWwAn4II5yHEPPQhyfSJw43jcJFVJgi B2pFASRXBbhAB13QBegGdB/IEIcgCwDzEFvwADUwfz8SC/vwBG3QNk0ABAXCBeCQCE/wBIPAAU4g j8lzDrGxEJmwDCZhe6vyeO1BRSMzOlMXI1XADWCQAT9ADVUADNZQDrHQCHr/szx6Yw7eoi+qtCZ0 0AlNYAlcUItXUARfMA/NwI0CMQ+RoE1N0gSpowFGoGuZAAgekQkz8AWGQAM04I6dZRDpsA/zUAXp sAyZIFl0MAq2ljajQgfkCCMVMIpPAAsncykmVGCgMUqZggvLIIvq1hcmxHgeFQtbIBhNEgYaQIDu sgevMAagwAup8As4gAOvkApjcAJj4AINQA7ZQINNEJcNoQ4/cAlZ5yIvcWnNcgKsEAcGIAKgsAdx 8Art0A5BAAesAAqsMA23EAwF6SSrUADdYHdNUgVhEAxr8B7pQAMDUw800AQZpA7Q+SKg8Au/wAt7 wAongAGg0A53IBB30A6g/8Cd7YADDpEOihAGBqJcfJkQxNglcpAHACADVXAEZrA8efIDo1AKoWAG AbWLr0AEogARVPCXDLEEtYCKOagLuthbadBrT9J/efAd20AGbXChjRAK6oALgFAIWzAPowCOEJEK qTCeD6EbNaQQ6nA/gMSeD5EJu3Oa6khUdFCj/Kie7yVUnTQVETEGvIBAaQB+geIsaaAPNSBBubcF LEJZYYBNxRARd+ACY2AdyDUX4XB/EJEJD5APK3lcMpAP+jAIlsiOPaAPlfIQonAKIiAXFbANY3oQ h3AOppRwL7qlXeoiVzAI/AAFm2NXBoEL8RIJircQe5AK7SAXq+CRDPEBNP9Qlgt6giCJkHd6IvtA D5L4AGE0V3lCCV+HAeFpHQ8ioxKxni7qEM2hDwoJI/PgijXQAzKQCUwpKGagASL4EHeQmXCSCTTA ZBFBB70gBrx6KGkwCOujBBwQBYjgCVtglzUHAgA2CqnaEL+wCFMaEaXwBV+xECQopBChC0OljDRg CQ3SCBlQC/oQCZqwDlWAAgAwA+3ZEC4QB9UKEXAnVwlxBSyApQ9BBTRgk0+CV/DRBSShA9DXdplA CuowjWPAAyaKPg7UEPZIjEHxrgWRCWZQC2/SJPi4J1ijBp6QI6pInQ3bJekwCl2Qg6JHBesHA2Iw A6L5IqNQCFr4JLzwCyP/6xAywwIMEYES9HrC8Ahdsg7IEAJ28gqtMK8PsQpnkKL3SjAncjh08q9U 0KkRcQBBcKhBdQWTKhEuAqOL8SSHxpEL0Q5I+y6UdQU0cIPD6IdFWgNbS6ng8Ax2wgoEYB3Xmq0K cQgkUHsk54dayqVPQgP54A5wkgpxgLXJcwa94FHpEAz66hB/+7Zy0Q434AFTcLM/0g6t8AonQgET 5jRpsKXV0CRjcApWYAWqEAeYS53YqZ2Gonzf+ou14AMWwAPfiQ6ikJu6eQDtcAJ3cAC5yZoHMKV3 8At7gAOgMAa/YAD2oAdEMAA7AA/tIAqQ+bt7MJ4iMLyeygPHiwFjIAo//xqblIkBv7ABQfCdLlIK lLAVC4GgtXd7+4oKcyANuBmbrXC17ZAKrZCbrHC/Y3AHrxAHooADrAAH1Dq9cKAHVkALp7ADypAK PNAKv9AOBTwNvADAAnwHIrAIi3DBomAALnCrixAHF2y1ZYuoDyB3CzEP5aC2OciU/RQLY8AK33kH PMALJxCZNOyprMALoJC8rHCod8AKsHkC7SACcKAMqkALqrADv2DDvYsDIsALOKCZQXwCBFzE7cAD vQsKIsAKVby635IOomo1dPoQL3AM65CODNEO8aAKdmAFiyDGYfmLInkiFlsLZTy5hIAACUDHE/QC s4C3gfmb7sMNS/EkjP+AB4FQxwVhLMDAEPUnEnJAkhDxCWxsMLhAsRNEAYUmIxT4CZ+wjVAyFJns EDDwAVSbKcvFECGwfIPZeGmQAWcguaG0C8jwhhNkDH9wpgkRp4acfEZqy9+yDD3oyHyytAyxCltw yhgQuWGyXLiQDi9bMwtGnOznOplQlhRABftBclQEzXASDEJwDMjsEOUAZHRgCJJwDfNgi+CACGyw BY/LBG0brUASDWLgFsLWWcZQBE+xEIeRBgumNcRYCsuKC6XAM5lAZXusjF9iDIVgBKu8wpAgA7Y8 G9jAENEQDM6saniGKsYQCjixClzgIGLzXl1QHlVwgxqSNvsIHzGNFFv/gA2hsgLVwUOmcyphkEEU wAYP/Wtd4Di6wgRwiQE0kAFfwQJkcDssgAx20QRkIAEnQQZ2sw6hoGt3lCGjwIyvaKYUsA2FMCJ9 UAjGIAeksAt2N1zBsA3YDBHBEAUzUNEvYtIawQIaigE5AAFeMwpTjQFYbTcdAAGrIAfbEApcHQUP 8IoPsAxhPdZ7kQcvIAcTAAyk0QfrIJDnQNUQYSAsMAmNELuZEgu6UB4UcC54lT1ThBRELVTtVdPL YwnVQdoCUQWrLcoYsAChMAMM0Y4Su1zOY0LEcik5QQflUCFq0AznfCLzQAkB1BC5ocsEoS/FUAwy IAPFwAVhQAHlwAUt/zARXyAD3AAEPxAFxLzcDNgH7KsQbPAH8bc80HcOTaALmmAG6RAGoZCT+nAG 0ofeqAIDUVAEDFEMZ9AGKJAIFgkNzqAebbIl3KDgT0AJmfC4/h2hdCCiCAFSKpuPuDBuTPE2uCBs dF3hEVGlMiK2JO4kuDALBVDNAxEMRzCzKa5DcTgIfooQTcABDzjj/LQuw1UBZWniPF4zsVAOo9Cp HOqJQ343jgIG0r1jF9ANJbnkWkcHkJEGTsDG+lJcmTAKMlFgtX0y75mjYS4Q/cwEY37mai4TRVEe V1MecoALbj61gLTah2badm7n4QYg49bN8BG2SLHnHx7oGFABK/CCMP9CBYWABmEQCzMw14JiBAU2 C8eBC0rBBC3QB45dCkWQ2f+c2Zx+Ff/8FavgFVyxBOUgG73gFmywBEQ7D9/QNumQB3qRCb1wO+rw Dfhi6/8RDL2QH8GwBAVSDr3A1d9gEaOwBDDQf0UQbtvwDS/QAt0wAxT+EBSQCUaDC2QQCrHwCBBQ CKWACxBQAFgxCLFRCqZwCLFAB8gwAWfhDWLAFWgw16uABoCAAVfgDfcuARewDc9zAR2AASHgDZmt Dt5wFSFwAWYxCt6gszngDak+ChcgABhwDN5wO1pw8UxwDGjwHzPgDVRtAt7gNYBgCgvABGIwDv9h e00yFqdSo/ZRo4BJVIsC0QUZNBaqRwFdoHo4DyCdYBKxYCM+Txk+A/TzQBmxMA+MkvQyUQVKjxTz 0PRRTxU6oyGdIBNYsyphUFxUXx6lwPWusYsBAQA7 --=====_002_next=====-- --=====_001_next=====-- From nobody Wed Apr 3 06:47:08 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8A51200B5; Wed, 3 Apr 2019 06:47:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 utttronkMTL3; Wed, 3 Apr 2019 06:47:05 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD08B12008D; Wed, 3 Apr 2019 06:47:04 -0700 (PDT) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id D518688B2E88B98BDF78; Wed, 3 Apr 2019 14:47:02 +0100 (IST) Received: from DGGEML424-HUB.china.huawei.com (10.1.199.41) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 3 Apr 2019 14:47:02 +0100 Received: from DGGEML532-MBX.china.huawei.com ([169.254.8.160]) by dggeml424-hub.china.huawei.com ([10.1.199.41]) with mapi id 14.03.0415.000; Wed, 3 Apr 2019 21:46:57 +0800 From: "Pengshuping (Peng Shuping)" To: "Frank Brockners (fbrockne)" , Mikael Abrahamsson CC: "C. M. Heard" , 6man WG , Mark Smith , "ippm@ietf.org" Thread-Topic: draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) Thread-Index: AQHU6TgZZ0//UXm1xEuikh93W/G1dKYqbPpA Date: Wed, 3 Apr 2019 13:46:57 +0000 Message-ID: <4278D47A901B3041A737953BAA078ADE1478D5E2@DGGEML532-MBX.china.huawei.com> References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.181.110] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [ippm] =?gb2312?b?tPC4tDogZHJhZnQtaW9hbWV0YWwtaXBwbS02bWFuLWlv?= =?gb2312?b?YW0taXB2Ni1kZXBsb3ltZW50LTAwIGZlZWRiYWNrIChSZTogdjYgb3B0aW9u?= =?gb2312?b?IHR5cGVzIGZvciBJT0FNIGRhdGEgZmllbGRzKQ==?= X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 13:47:07 -0000 SGksIA0KDQpUaGUgcGFyc2luZyBkZXB0aCBvZiB0aGUgZWFybHkgY2hpcHMgaXMgOTZCLzEyOEIu IEZvciB0aGUgbmV3IGNoaXBzIHRoZSBwYXJzaW5nIGRlcHRoIGhhcyBiZWVuIGluY3JlYXNlZCBi dXQgc3RpbGwgbGltaXRlZC4gU28gTWlrYWVsJ3MgY29uY2VybiBtYWtlcyBzZW5zZSBlc3BlY2lh bGx5IGluIHRoZSB0cmFjaW5nIG1vZGUgdGhhdCB0aGUgSU9BTSBkYXRhIGZpZWxkcyBhcmUgZ29p bmcgdG8gaW5jcmVhc2Ugc2lnbmlmaWNhbnRseSBhbG9uZyB0aGUgcGF0aCwgd2hpY2ggd2lsbCBl dmVuIHB1c2ggdGhlIFJvdXRpbmcgSGVhZGVyIG91dCBvZiB0aGUgcGFyc2luZyBkZXB0aCBvZiB0 aGUgY2hpcC4gU28gaXQgd291bGQgbWFrZSBzZW5zZSB0byBzcGxpdCB0aGUgSU9BTSBkYXRhIHBh cnQgZnJvbSB0aGUgSU9BTSBoZWFkZXIvaW5zdHJ1Y3Rpb24gcGFydCwgYW5kIHBsYWNlIHRoZSBJ T0FNIGRhdGEgYWZ0ZXIgdGhlIFJIIG9yIGV2ZW4gYWZ0ZXIgdGhlIEw0IGhlYWRlciBpbiBvcmRl ciB0byBiZSBhYmxlIHRvIHJlYWQgdGhlIEw0IGluZm9ybWF0aW9uIHRvIGVuYWJsZSBFQ01QLCBh cyBzdGF0ZWQgaW4gdGhlIGRyYWZ0IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1s aS02bWFuLWlwdjYtc2ZjLWlmaXQtMDAuDQoNCkJSLA0KU2h1cGluZyANCg0KDQotLS0tLdPKvP7U rbz+LS0tLS0NCreivP7IyzogaXBwbSBbbWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZ10gtPqx 7SBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKQ0Kt6LLzcqxvOQ6IDIwMTnE6jTUwjLI1SAxNzo0 MA0KytW8/sjLOiBNaWthZWwgQWJyYWhhbXNzb24gPHN3bWlrZUBzd20ucHAuc2U+DQqzrcvNOiBD LiBNLiBIZWFyZCA8aGVhcmRAcG9ib3guY29tPjsgNm1hbiBXRyA8aXB2NkBpZXRmLm9yZz47IE1h cmsgU21pdGggPG1hcmt6enpzbWl0aEBnbWFpbC5jb20+OyBpcHBtQGlldGYub3JnDQrW98ziOiBS ZTogW2lwcG1dIGRyYWZ0LWlvYW1ldGFsLWlwcG0tNm1hbi1pb2FtLWlwdjYtZGVwbG95bWVudC0w MCBmZWVkYmFjayAoUmU6IHY2IG9wdGlvbiB0eXBlcyBmb3IgSU9BTSBkYXRhIGZpZWxkcykNCg0K DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNaWthZWwgQWJyYWhhbXNzb24g PHN3bWlrZUBzd20ucHAuc2U+DQpTZW50OiBEaWVuc3RhZywgMi4gQXByaWwgMjAxOSAwODowNg0K VG86IEZyYW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpIDxmYnJvY2tuZUBjaXNjby5jb20+DQpDYzog TWFyayBTbWl0aCA8bWFya3p6enNtaXRoQGdtYWlsLmNvbT47IEMuIE0uIEhlYXJkIDxoZWFyZEBw b2JveC5jb20+OyA2bWFuIFdHIDxpcHY2QGlldGYub3JnPjsgaXBwbUBpZXRmLm9yZw0KU3ViamVj dDogUkU6IGRyYWZ0LWlvYW1ldGFsLWlwcG0tNm1hbi1pb2FtLWlwdjYtZGVwbG95bWVudC0wMCBm ZWVkYmFjayAoUmU6IHY2IG9wdGlvbiB0eXBlcyBmb3IgSU9BTSBkYXRhIGZpZWxkcykNCg0KT24g TW9uLCAxIEFwciAyMDE5LCBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKSB3cm90ZToNCg0KPiAu Li5GQjogVGhlcmUgaXMgb2J2aW91c2x5IG5vIGVhc3kgYW5zd2VyLiBDb3VwbGUgb2YgdGhvdWdo dHM6DQo+ICogSU9BTSBpcyBjb25zaWRlcmVkIGEgImRvbWFpbiBzcGVjaWZpYyIgZmVhdHVyZSAo c2VlIA0KPiBkcmFmdC1pZXRmLWlwcG0taW9hbS1kYXRhLTA1LCBzZWN0aW9uIDMpLiBSb3V0ZXJz IGluIHRoZSBJT0FNIGRvbWFpbiANCj4gc2hvdWxkIGJlIElPQU0gY2FwYWJsZS4gIEFuZCBJTUhP LCAgd2Ugc2hvdWxkIGFkZCBhIHN0YXRlbWVudCB0byANCj4gZHJhZnQtaW9hbWV0YWwtaXBwbS02 bWFuLWlvYW0taXB2Ni1kZXBsb3ltZW50IHRoYXQgYW4gaW1wbGVtZW50YXRpb24gDQo+IG9mIElP QU0gTVVTVCBlbnN1cmUgIkMxIi4NCj4NCj4gKiBUaGF0IHNhaWQsIHRoZXJlIGNhbiBiZSBzaXR1 YXRpb25zLCB3aGVyZSBDMSBjYW5ub3QgYmUgYWNoaWV2ZWQsIGUuZy4gDQo+IGNvbnNpZGVyIGEg bmV0d29yayB3aGljaCBkb2VzIEVDTVAgc2NoZWR1bGluZyBiYXNlZCBvbiBwYWNrZXQgbGVuZ3Ro Lg0KPg0KPiAqIFdoYXQgb25lIGNvdWxkIGNvbnNpZGVyIC0gYW5kIHdoaWNoIGlzIG9uZSBzdWdn ZXN0ZWQgZGVwbG95bWVudCANCj4gbW9kZWwNCj4gLSBpcyB0aGF0IGJ5IGRlZmF1bHQgSU9BTSBk YXRhIGZpZWxkcyBhcmUgYWRkZWQgdG8gX2FsbF8gY3VzdG9tZXIgDQo+IHBhY2tldHMuIFRoZSBk ZWNhcHN1bGF0aW5nIG5vZGUgd291bGQgZGVjaWRlIHdoZXRoZXIgdGhlIElPQU0gDQo+IGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpbiBhIHBhY2tldCB3b3VsZCBiZSB1c2VkIChhbmQgZXhwb3J0ZWQp IG9yIG5vdC4NCj4gVGhhdCB3YXkgb25lIHdvdWxkIG5vdCBuZWVkIHRvIGRlYWwgd2l0aCB0aGUg c2l0dWF0aW9uIHRoYXQgc29tZSANCj4gdHJhZmZpYyBjYXJyaWVzIElPQU0gd2hpbGUgb3RoZXIg ZG9lcyBub3QgLSBhbmQgbWlnaHQgdGh1cyBiZSB0cmVhdGVkIA0KPiBkaWZmZXJlbnRseS4NCg0K WWVzLCBJIHRoaW5rIHRoaXMgaXMgdGhlIG9ubHkgd2F5LiBJcyB0aGVyZSBhIHJpc2sgdGhhdCBp bnRlcm1lZGlhdGUgcm91dGVycyB3b3VsZCBub3QgYmUgSU9BTSBjYXBhYmxlPyBJIHRoaW5rIHRo ZSBDMSByZXF1aXJlbWVudCBpcyByZWFsbHkgcmVhbGx5IGhhcmQgdG8gZnVsZmlsIGFuZCBJJ20g YWxzbyBhZnJhaWQgdGhhdCBhZGRpbmcgdGhlIElPQU0gaGVhZGVyIHdpbGwgYWN0dWFsbHkgbWFr ZSBFQ01QIHN0b3Agd29ya2luZyBvbiBzb21lIHBsYXRmb3JtcyAoYmVjYXVzZSB0aGV5IHdvdWxk IG5vdCBoYXZlIHRoZSBjYXBhYmlsaXR5IHRvIGxvb2sgZGVlcCBlbm91Z2ggaW50byB0aGUgcGFj a2V0IHRvIGZpbmQgTDQgaW5mb3JtYXRpb24sIHNvIGl0J2xsIGdvIGJhY2sgdG8gMiB0dXBsZSBF Q01QIGluc3RlYWQgb2YgNSB0dXBsZS4NCg0KQnV0IHRoaXMgcXVlc3Rpb24gY2FuIG9ubHkgYmUg YW5zd2VyZWQgYnkgcGVvcGxlIHdpdGggZGVlcCBOUFUga25vd2xlZGdlLi4uDQoNCi4uLi5GQjI6 IEdpdmVuIHRoYXQgSU9BTSBpcyBhIGRvbWFpbiBzcGVjaWZpYyBmZWF0dXJlIC0gSSBleHBlY3Qg dGhhdCBmb2xrcyBpbml0aWFsbHkgc3RhcnQgdG8gdXNlIGl0IGluIGRvbWFpbnMgKGxpa2UgZS5n LiBhIERDKSB3aGVyZSBhbGwgYm94ZXMgYXJlIElPQU0gY2FwYWJsZSBhbmQgY2FuIHRyYWNlIHRo ZSBwYWNrZXQgYXBwcm9wcmlhdGVseSAtIG9yIHBlciBUb20ncyBub3RlLCBjYW4gYmUgY29uZmln dXJlZCBzbyB0aGF0IG9uZSB3b3VsZCBkbyBFQ01QIGJhc2VkIG9uIGFkZHJlc3NlcyBhbmQgZmxv dy1sYWJlbC4gIFRoZXJlIGFyZSBjaGlwcyB3aXRoIHByZXR0eSBkZWVwIHBhcnNpbmcgY2FwYWJp bGl0eSAodXAgdG8gYSBmZXcgaHVuZHJlZCBieXRlcykuIA0KDQo+IC4uLkZCOiBUaGUgY29tcGFy aXNvbiB0byBNUExTIGlzIGludGVyZXN0aW5nLiBIb3cgb2Z0ZW4gZG8gTVBMUyANCj4gcGFja2V0 cyBsZWFrIGFuZCBjYXVzZSBoYXJtPyBGb3IgSU9BTSwNCj4gZHJhZnQtaW9hbWV0YWwtaXBwbS02 bWFuLWlvYW0taXB2Ni1vcHRpb25zLTAyIHByb3Bvc2VzIGEgZGVwbG95bWVudCANCj4gbW9kZWwg c2ltaWxhciB0byB3aGF0IHdlIGRvIGZvciBNUExTOiBVbmxlc3MgYW4gaW50ZXJmYWNlIGlzIA0K PiBleHBsaWNpdGx5IGNvbmZpZ3VyZWQgZm9yIElPQU0sIHBhY2tldHMgd2l0aCBJT0FNIGRhdGEg ZmllbGRzIE1VU1QgYmUgZHJvcHBlZC4NCj4gSGVuY2UgbGVha2FnZSB3b3VsZCBvbmx5IG9jY3Vy LCBpZiB3ZSBoYXZlIGEgY2xlYXJseSBtaXNiZWhhdmluZyANCj4gcm91dGVyIHdoaWNoIHZpb2xh dGVzIHRoaXMgcnVsZS4gU2ltaWxhciB0byB5b3UsIEknZCBhbHNvIGdyZWF0bHkgDQo+IGFwcHJl Y2lhdGUgYW55IHBvaW50ZXJzIHRvIHJlc2VhcmNoIG9uIGhvdyBjb21tb24gTVBMUyBsZWFrZWQg cGFja2V0cyBhcmUuDQoNCldoZW4gaXQgY29tZXMgdG8gImNhdXNlIGhhcm0iIEkgaW1hZ2luZSB0 aGVyZSBhcmUgKGF0IGxlYXN0KSB0d28gd2F5cyB0byBjYXVzZSBoYXJtLCBvbmUgaXMgcHJpdmFj eS9zZWNyZWN5L3NlY3VyaXR5IGxvc3MgYW5kIHRoZSBvdGhlciBvbmUgaXMgYWN0dWFsIG9wZXJh dGlvbmFsIGxvc3MuDQoNCkkga25vdyBvZiBidWdzIHdoZXJlIGxhYmVsZWQgcGFja2V0cyB3ZW50 IHRoZSB3cm9uZyB3YXkgYW5kIGNhdXNlZCB0aGVtIHRvIGJlIGxvc3QsIEkndmUgYWxzbyBzZWVu IGJ1Z3Mgd2hlcmUgYnVncyBjYXVzZWQgdHJhZmZpYyB0byAiaG9wIiBiZXR3ZWVuIFZSRnMgaW4g TVBMUyBWUE4gKG9yIHRvICJnbG9iYWwiIFZSRikuIEkgZG9uJ3QgaGF2ZSBudW1iZXJzIG9uIHRo aXMgdGhvdWdoLg0KDQpEZXBlbmRpbmcgb24gdGhlIGRlcGxveW1lbnQgc2NlbmFyaW8sIGl0IG1p Z2h0IG1ha2Ugc2Vuc2UgdG8gbWFrZSBJT0FNIHBhY2tldHMgbm90IHZhbGlkIGZvciBub24tSU9B TSBhd2FyZSBkZXZpY2VzIChiYXNpY2FsbHkgZW5jYXAgZW50aXJlIHBhY2tldC9wYXlsb2FkKSwg YnV0IHRoYXQgbWlnaHQgYmUgYSBwcm9ibGVtIGZvciBpbnRlcm1lZGlhdGUgbm9uLUlPQU0gbm9k ZXMgdGhlbi4gVGhpcyB3b3VsZCBhZmZlY3QgdGhlIEVDTVAgcmVxdWlyZW1lbnQuIEkgY2FuIHNl ZSBjYXNlcyB3aGVyZSBvbmUgd291bGQgb3BlcmF0aW9uYWxseSB0dXJuIG9uIElPQU0gZm9yIHNv bWUgY3VzdG9tZXJzIHRyYWZmaWMgYW5kIHRoZW4gc2VlIHRoZSBwcm9ibGVtIGdvIGF3YXkgYmVj YXVzZSBub3cgRUNNUCBjaGFuZ2VkLg0KDQo+IC4uLkZCOiBPbmUgaWRlYSB0aGF0IFNod2V0aGEg Y2FtZSB1cCB3aXRoIHRvIGlkZW50aWZ5IHRoZSBzb3VyY2UgQVMgb2YgDQo+IGEgbGVha2VkIHBh Y2tldCwgd291bGQgYmUgdG8gYWRkIGEgbmV3IG5ldyBJT0FNIEUyRSBvcHRpb24gLSBhcyANCj4g cHJvcG9zZWQgaW4gc2VjdGlvbiA1LjEuMSBidWxsZXQgMiBvZiANCj4gZHJhZnQtaW9hbWV0YWwt aXBwbS02bWFuLWlvYW0taXB2Ni1kZXBsb3ltZW50LTAxLg0KDQpZZXMsIHRoYXQnZCBzb2x2ZSB0 aGF0IHByb2JsZW0uDQoNCkhvdyBtdWNoIGhhcyB0aGUgc2lsaWNvbiBwZW9wbGUgYmVlbiBpbnZv bHZlZCBzbyBmYXIgaW4gdGhlIGRlc2lnbiBvZiB0aGUgaGVhZGVycz8gV2hhdCBpcyB0aGUgY3Vy cmVudCB0aGlua2luZyBvZiBhbW91bnQgb2YgZGF0YSBnb2luZyBpbnRvIHRoZSBJT0FNIGhlYWRl cj8gQ29uc2lkZXJpbmcgdGhpbmdzIGxpa2UgdHJhY2Ugb3B0aW9ucyBldGMgaXQgc2VlbXMgdG8g bWUgdGhlIGhlYWRlciBjYW4gZ3JvdyBxdWl0ZSBsYXJnZT8gVG8gc2F0aXNmeSB0aGUgRUNNUCBy ZXF1aXJlbWVudCB3aGF0IGFib3V0IHB1dHRpbmcgdGhlIElPQU0gaW5mb3JtYXRpb24gYXMgYSB0 cmFpbGVyIGJlaGluZCB0aGUgcmVndWxhciBwYXlsb2FkPyBPciBpcyB0aGVyZSBhIHByb2JsZW0g Zm9yIHRoZSBodyB0byBtYW5pcHVsYXRlIGluZm9ybWF0aW9uIHRoYXQgZmFyIGludG8gdGhlIHBh Y2tldCAoSSBhbHNvIGltYWdpbmUgdGhpcyB3aWxsIGNvbnNpZGVyYWJseSBsb3dlciB0aGUgZm9y d2FyZGluZyBwZXJmb3JtYW5jZSBvZiBJT0FNIHBhY2tldHMgb24gSU9BTSBhd2FyZSBwbGF0Zm9y bXMpLg0KDQouLi4uRkIyOiBUaGVyZSBhcmUgcXVpdGUgYSBmZXcgZm9sa3Mgd2l0aCBoYXJkd2Fy ZSBiYWNrZ3JvdW5kIHRoYXQgY28tYXV0aG9yIHRoZSBJT0FNIGRyYWZ0cy4gUGFyc2luZyBjYXBh YmlsaXR5IGRpZmZlcnMgYmV0d2VlbiBjaGlwcywgYXMgZG9lcyB0aGUgYWJpbGl0eSB0byBkZWFs IHdpdGggbmV3L2ZsZXhpYmxlIGhlYWRlcnMgYW5kIHRoZSBhYmlsaXR5IHRvIG1vZGlmeSBkYXRh IGluIHRoZSBleHRlbnNpb24gaGVhZGVycy4gU28gdGhlIHVuZm9ydHVuYXRlIGFuc3dlciB0byB0 aGF0IHF1ZXN0aW9uIGlzICJpdCBkZXBlbmRzIiAod2hhdCBpbmZvcm1hdGlvbiBkbyB5b3UgZ2F0 aGVyLCBob3cgbGFyZ2UgaXMgeW91ciBkb21haW4sIHdoYXQgYXJlIHRoZSBjYXBhYmlsaXRpZXMg b2YgeW91ciBoYXJkd2FyZS9zb2Z0d2FyZSBmb3J3YXJkZXIsIGV0Yy4pLCBidXQgSSBkbyBleHBl Y3QgdGhhdCBmb3Igc3BlY2lmaWMgZGVwbG95bWVudCBkb21haW5zIChlLmcuIERDLCBFbnRlcnBy aXNlKSAtIGJ1dCBhbHNvIGZvciBvdmVybGF5IG5ldHdvcmtzIC8gVlBOcyAtIHdlJ2xsIHNlZSBh biBpbmNyZWFzaW5nIGFtb3VudCBvZiBjaGlwcyB0aGF0IGFyZSB3ZWxsIHN1aXRlZCBmb3IgcHJv Y2Vzc2luZyBsYXJnZSBleHRlbnNpb24gaGVhZGVyLg0KDQpDaGVlcnMsIEZyYW5rDQoNCi0tIA0K TWlrYWVsIEFicmFoYW1zc29uICAgIGVtYWlsOiBzd21pa2VAc3dtLnBwLnNlDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQppcHBtIG1haWxpbmcgbGlz dA0KaXBwbUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p cHBtDQo= From nobody Thu Apr 4 12:18:24 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED23A120139; Thu, 4 Apr 2019 12:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mellanox.com 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 D9K8uC3XIAeX; Thu, 4 Apr 2019 12:18:19 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30041.outbound.protection.outlook.com [40.107.3.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6C39120159; Thu, 4 Apr 2019 12:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Mellanox.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fYs0zo2BLkpYzMzmif40Eq0NAkeAxv7yDcMTy1XmSM8=; b=ddENKtEh6gMf2M5TM2QQlIpTmRkzYWj+JlCfKVWgkF4+lCZETXF8RjYU80x4U3nmEd4/g8W+L8h1YPVXyCnanUlmjtx+dMxTH8Yue2fHm0hkIqDNno4AWdozi50lDBZO2K8z40BN9NNenb0Vhtdb126+jOmL19DeRDLEhhRKpMU= Received: from VI1PR05MB4125.eurprd05.prod.outlook.com (10.171.182.140) by VI1PR05MB4845.eurprd05.prod.outlook.com (20.177.50.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.13; Thu, 4 Apr 2019 19:18:15 +0000 Received: from VI1PR05MB4125.eurprd05.prod.outlook.com ([fe80::4d91:4492:3150:877e]) by VI1PR05MB4125.eurprd05.prod.outlook.com ([fe80::4d91:4492:3150:877e%4]) with mapi id 15.20.1750.017; Thu, 4 Apr 2019 19:18:15 +0000 From: Barak Gafni To: "Pengshuping (Peng Shuping)" , "Frank Brockners (fbrockne)" , Mikael Abrahamsson CC: "C. M. Heard" , 6man WG , Mark Smith , "ippm@ietf.org" Thread-Topic: draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) Thread-Index: AQHU6iO07PZDc2RbS0itQu8VbenWiKYsXw+g Date: Thu, 4 Apr 2019 19:17:46 +0000 Deferred-Delivery: Thu, 4 Apr 2019 19:16:50 +0000 Message-ID: References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> <4278D47A901B3041A737953BAA078ADE1478D5E2@DGGEML532-MBX.china.huawei.com> In-Reply-To: <4278D47A901B3041A737953BAA078ADE1478D5E2@DGGEML532-MBX.china.huawei.com> Accept-Language: he-IL, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gbarak@mellanox.com; x-originating-ip: [209.116.155.178] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 67a8cd41-0274-4a1c-7e74-08d6b9324975 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:VI1PR05MB4845; x-ms-traffictypediagnostic: VI1PR05MB4845: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0997523C40 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(376002)(396003)(39860400002)(136003)(199004)(189003)(13464003)(51444003)(186003)(476003)(446003)(229853002)(74316002)(316002)(45080400002)(54906003)(478600001)(6436002)(14444005)(106356001)(11346002)(966005)(99286004)(2906002)(486006)(105586002)(76176011)(256004)(110136005)(66574012)(3846002)(6116002)(6666004)(6246003)(68736007)(52536014)(102836004)(71200400001)(8936002)(7696005)(8676002)(97736004)(81156014)(81166006)(9686003)(7736002)(6506007)(5660300002)(14454004)(53546011)(33656002)(4326008)(53936002)(6306002)(55016002)(66066001)(86362001)(25786009)(93886005)(305945005)(26005)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR05MB4845; H:VI1PR05MB4125.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: mellanox.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: aXVCIho0Lc7WtdG2YjvGGcSFl+ZPk199UEywqXaJYHhzodT8ixVHElkI2aWsATaI1uxlUMd2tfZhWAxobb9pafS2lSyrASKlz88AlEf3GwImAeVWbQKerFvXA0s94i8277O8duPF6RHSD+Wyn/2veOF1uMnE/sbHMDVKqDJktotJXHszIn4eOpRGVd+MX23MaVgp2bRjUXM0mqXNKA9zGsL+eelMepMYNZS9NewatsN3CFcnLqgkVXQUReatDUMWl44wxAqcBnMwC2I3g/EQZmexvnOi8wu5mJu8QjoQKiwnnK/6EQVWsz8c4++ZahigJMbMW7UMy8xDYbm5pBC8wxZyouQ0ZLrmz2AX5VJMOBlZuHM8U80dONX3/aL/bh35tX0b74EPr1ylXCdG3Twy7E06vgO2NGLAX5R+e1VgFgI= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: Mellanox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 67a8cd41-0274-4a1c-7e74-08d6b9324975 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Apr 2019 19:18:14.9943 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a652971c-7d2e-4d9b-a6a4-d149256f461b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR05MB4845 Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 19:18:23 -0000 SGkgU2h1cGluZywNCkkgdGhpbmsgdGhhdCB0aGUgcXVlc3Rpb24gaXMgd2hldGhlciB3ZSBkZXNp Z24gZm9yIHRoZSBsb3dlc3QgY2FwYWJsZSBzb2x1dGlvbnMuIEkgYXNzdW1lIHNvbWVvbmUgY2Fu IGZpbmQgc29sdXRpb25zIHdpdGggZXZlbiBsb3dlciBhbW91bnQgb2YgcGFyc2luZy4gVGhlIGxv dyBlbmQgc29sdXRpb25zIGZvciB0aGVzZSBjYXBhYmlsaXRpZXMgbWF5IG5lZWQgdG8gZWl0aGVy IGFkb3B0IHdpdGggbmV3IGRlc2lnbnMgb3IgdXNlIHNvbHV0aW9ucyBzdWNoIGFzIHdoYXQgaXMg c3VnZ2VzdGVkIGluIHRoaXMgdGhyZWFkIGJ5IFRvbSBIZXJiZXJ0Lg0KUGVyc29uYWxseSwgSSBk b24ndCB0aGluayB3ZSBzaG91bGQgZ28gdGhpcyB3YXksIGJ1dCB0byBkZXNpZ24gYXBwcm9wcmlh dGUgc29sdXRpb25zLCB3aXRoIGFwcHJvcHJpYXRlIGxheWVycyBpbiB0aGUgaGVhZGVycy4gRm9y IGV4YW1wbGUsIHByZXZlbnQgZGVwZW5kZW5jaWVzIGJldHdlZW4gInJlbW90ZSIgaGVhZGVycy4N Cg0KVGhhbmtzLA0KQmFyYWsNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGlw cG0gPGlwcG0tYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFBlbmdzaHVwaW5nIChQZW5n IFNodXBpbmcpDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDMsIDIwMTkgNjo0NyBBTQ0KVG86IEZy YW5rIEJyb2NrbmVycyAoZmJyb2NrbmUpIDxmYnJvY2tuZUBjaXNjby5jb20+OyBNaWthZWwgQWJy YWhhbXNzb24gPHN3bWlrZUBzd20ucHAuc2U+DQpDYzogQy4gTS4gSGVhcmQgPGhlYXJkQHBvYm94 LmNvbT47IDZtYW4gV0cgPGlwdjZAaWV0Zi5vcmc+OyBNYXJrIFNtaXRoIDxtYXJrenp6c21pdGhA Z21haWwuY29tPjsgaXBwbUBpZXRmLm9yZw0KU3ViamVjdDogW2lwcG1dIOetlOWkjTogZHJhZnQt aW9hbWV0YWwtaXBwbS02bWFuLWlvYW0taXB2Ni1kZXBsb3ltZW50LTAwIGZlZWRiYWNrIChSZTog djYgb3B0aW9uIHR5cGVzIGZvciBJT0FNIGRhdGEgZmllbGRzKQ0KDQpIaSwgDQoNClRoZSBwYXJz aW5nIGRlcHRoIG9mIHRoZSBlYXJseSBjaGlwcyBpcyA5NkIvMTI4Qi4gRm9yIHRoZSBuZXcgY2hp cHMgdGhlIHBhcnNpbmcgZGVwdGggaGFzIGJlZW4gaW5jcmVhc2VkIGJ1dCBzdGlsbCBsaW1pdGVk LiBTbyBNaWthZWwncyBjb25jZXJuIG1ha2VzIHNlbnNlIGVzcGVjaWFsbHkgaW4gdGhlIHRyYWNp bmcgbW9kZSB0aGF0IHRoZSBJT0FNIGRhdGEgZmllbGRzIGFyZSBnb2luZyB0byBpbmNyZWFzZSBz aWduaWZpY2FudGx5IGFsb25nIHRoZSBwYXRoLCB3aGljaCB3aWxsIGV2ZW4gcHVzaCB0aGUgUm91 dGluZyBIZWFkZXIgb3V0IG9mIHRoZSBwYXJzaW5nIGRlcHRoIG9mIHRoZSBjaGlwLiBTbyBpdCB3 b3VsZCBtYWtlIHNlbnNlIHRvIHNwbGl0IHRoZSBJT0FNIGRhdGEgcGFydCBmcm9tIHRoZSBJT0FN IGhlYWRlci9pbnN0cnVjdGlvbiBwYXJ0LCBhbmQgcGxhY2UgdGhlIElPQU0gZGF0YSBhZnRlciB0 aGUgUkggb3IgZXZlbiBhZnRlciB0aGUgTDQgaGVhZGVyIGluIG9yZGVyIHRvIGJlIGFibGUgdG8g cmVhZCB0aGUgTDQgaW5mb3JtYXRpb24gdG8gZW5hYmxlIEVDTVAsIGFzIHN0YXRlZCBpbiB0aGUg ZHJhZnQgaHR0cHM6Ly9ldXIwMy5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs PWh0dHBzJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmclMkZodG1sJTJGZHJhZnQtbGktNm1hbi1pcHY2 LXNmYy1pZml0LTAwJmFtcDtkYXRhPTAyJTdDMDElN0NnYmFyYWslNDBtZWxsYW5veC5jb20lN0M2 MTJiYTZkYzExNzQ0MGU2OGM0NjA4ZDZiODNhZTE3NCU3Q2E2NTI5NzFjN2QyZTRkOWJhNmE0ZDE0 OTI1NmY0NjFiJTdDMCU3QzAlN0M2MzY4OTg5NjAzNzk0ODU4MzMmYW1wO3NkYXRhPURvYjR6TiUy RjFqU0d4TFRscUdtYTI5SkpOdnFKREJ0NFZ6cUhzTjRPcHhNNCUzRCZhbXA7cmVzZXJ2ZWQ9MC4N Cg0KQlIsDQpTaHVwaW5nIA0KDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujog aXBwbSBbbWFpbHRvOmlwcG0tYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIEZyYW5rIEJyb2NrbmVy cyAoZmJyb2NrbmUpDQrlj5HpgIHml7bpl7Q6IDIwMTnlubQ05pyIMuaXpSAxNzo0MA0K5pS25Lu2 5Lq6OiBNaWthZWwgQWJyYWhhbXNzb24gPHN3bWlrZUBzd20ucHAuc2U+DQrmioTpgIE6IEMuIE0u IEhlYXJkIDxoZWFyZEBwb2JveC5jb20+OyA2bWFuIFdHIDxpcHY2QGlldGYub3JnPjsgTWFyayBT bWl0aCA8bWFya3p6enNtaXRoQGdtYWlsLmNvbT47IGlwcG1AaWV0Zi5vcmcNCuS4u+mimDogUmU6 IFtpcHBtXSBkcmFmdC1pb2FtZXRhbC1pcHBtLTZtYW4taW9hbS1pcHY2LWRlcGxveW1lbnQtMDAg ZmVlZGJhY2sgKFJlOiB2NiBvcHRpb24gdHlwZXMgZm9yIElPQU0gZGF0YSBmaWVsZHMpDQoNCg0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWlrYWVsIEFicmFoYW1zc29uIDxz d21pa2VAc3dtLnBwLnNlPg0KU2VudDogRGllbnN0YWcsIDIuIEFwcmlsIDIwMTkgMDg6MDYNClRv OiBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKSA8ZmJyb2NrbmVAY2lzY28uY29tPg0KQ2M6IE1h cmsgU21pdGggPG1hcmt6enpzbWl0aEBnbWFpbC5jb20+OyBDLiBNLiBIZWFyZCA8aGVhcmRAcG9i b3guY29tPjsgNm1hbiBXRyA8aXB2NkBpZXRmLm9yZz47IGlwcG1AaWV0Zi5vcmcNClN1YmplY3Q6 IFJFOiBkcmFmdC1pb2FtZXRhbC1pcHBtLTZtYW4taW9hbS1pcHY2LWRlcGxveW1lbnQtMDAgZmVl ZGJhY2sgKFJlOiB2NiBvcHRpb24gdHlwZXMgZm9yIElPQU0gZGF0YSBmaWVsZHMpDQoNCk9uIE1v biwgMSBBcHIgMjAxOSwgRnJhbmsgQnJvY2tuZXJzIChmYnJvY2tuZSkgd3JvdGU6DQoNCj4gLi4u RkI6IFRoZXJlIGlzIG9idmlvdXNseSBubyBlYXN5IGFuc3dlci4gQ291cGxlIG9mIHRob3VnaHRz Og0KPiAqIElPQU0gaXMgY29uc2lkZXJlZCBhICJkb21haW4gc3BlY2lmaWMiIGZlYXR1cmUgKHNl ZSANCj4gZHJhZnQtaWV0Zi1pcHBtLWlvYW0tZGF0YS0wNSwgc2VjdGlvbiAzKS4gUm91dGVycyBp biB0aGUgSU9BTSBkb21haW4gDQo+IHNob3VsZCBiZSBJT0FNIGNhcGFibGUuICBBbmQgSU1ITywg IHdlIHNob3VsZCBhZGQgYSBzdGF0ZW1lbnQgdG8gDQo+IGRyYWZ0LWlvYW1ldGFsLWlwcG0tNm1h bi1pb2FtLWlwdjYtZGVwbG95bWVudCB0aGF0IGFuIGltcGxlbWVudGF0aW9uIA0KPiBvZiBJT0FN IE1VU1QgZW5zdXJlICJDMSIuDQo+DQo+ICogVGhhdCBzYWlkLCB0aGVyZSBjYW4gYmUgc2l0dWF0 aW9ucywgd2hlcmUgQzEgY2Fubm90IGJlIGFjaGlldmVkLCBlLmcuIA0KPiBjb25zaWRlciBhIG5l dHdvcmsgd2hpY2ggZG9lcyBFQ01QIHNjaGVkdWxpbmcgYmFzZWQgb24gcGFja2V0IGxlbmd0aC4N Cj4NCj4gKiBXaGF0IG9uZSBjb3VsZCBjb25zaWRlciAtIGFuZCB3aGljaCBpcyBvbmUgc3VnZ2Vz dGVkIGRlcGxveW1lbnQgDQo+IG1vZGVsDQo+IC0gaXMgdGhhdCBieSBkZWZhdWx0IElPQU0gZGF0 YSBmaWVsZHMgYXJlIGFkZGVkIHRvIF9hbGxfIGN1c3RvbWVyIA0KPiBwYWNrZXRzLiBUaGUgZGVj YXBzdWxhdGluZyBub2RlIHdvdWxkIGRlY2lkZSB3aGV0aGVyIHRoZSBJT0FNIA0KPiBpbmZvcm1h dGlvbiBjb250YWluZWQgaW4gYSBwYWNrZXQgd291bGQgYmUgdXNlZCAoYW5kIGV4cG9ydGVkKSBv ciBub3QuDQo+IFRoYXQgd2F5IG9uZSB3b3VsZCBub3QgbmVlZCB0byBkZWFsIHdpdGggdGhlIHNp dHVhdGlvbiB0aGF0IHNvbWUgDQo+IHRyYWZmaWMgY2FycmllcyBJT0FNIHdoaWxlIG90aGVyIGRv ZXMgbm90IC0gYW5kIG1pZ2h0IHRodXMgYmUgdHJlYXRlZCANCj4gZGlmZmVyZW50bHkuDQoNClll cywgSSB0aGluayB0aGlzIGlzIHRoZSBvbmx5IHdheS4gSXMgdGhlcmUgYSByaXNrIHRoYXQgaW50 ZXJtZWRpYXRlIHJvdXRlcnMgd291bGQgbm90IGJlIElPQU0gY2FwYWJsZT8gSSB0aGluayB0aGUg QzEgcmVxdWlyZW1lbnQgaXMgcmVhbGx5IHJlYWxseSBoYXJkIHRvIGZ1bGZpbCBhbmQgSSdtIGFs c28gYWZyYWlkIHRoYXQgYWRkaW5nIHRoZSBJT0FNIGhlYWRlciB3aWxsIGFjdHVhbGx5IG1ha2Ug RUNNUCBzdG9wIHdvcmtpbmcgb24gc29tZSBwbGF0Zm9ybXMgKGJlY2F1c2UgdGhleSB3b3VsZCBu b3QgaGF2ZSB0aGUgY2FwYWJpbGl0eSB0byBsb29rIGRlZXAgZW5vdWdoIGludG8gdGhlIHBhY2tl dCB0byBmaW5kIEw0IGluZm9ybWF0aW9uLCBzbyBpdCdsbCBnbyBiYWNrIHRvIDIgdHVwbGUgRUNN UCBpbnN0ZWFkIG9mIDUgdHVwbGUuDQoNCkJ1dCB0aGlzIHF1ZXN0aW9uIGNhbiBvbmx5IGJlIGFu c3dlcmVkIGJ5IHBlb3BsZSB3aXRoIGRlZXAgTlBVIGtub3dsZWRnZS4uLg0KDQouLi4uRkIyOiBH aXZlbiB0aGF0IElPQU0gaXMgYSBkb21haW4gc3BlY2lmaWMgZmVhdHVyZSAtIEkgZXhwZWN0IHRo YXQgZm9sa3MgaW5pdGlhbGx5IHN0YXJ0IHRvIHVzZSBpdCBpbiBkb21haW5zIChsaWtlIGUuZy4g YSBEQykgd2hlcmUgYWxsIGJveGVzIGFyZSBJT0FNIGNhcGFibGUgYW5kIGNhbiB0cmFjZSB0aGUg cGFja2V0IGFwcHJvcHJpYXRlbHkgLSBvciBwZXIgVG9tJ3Mgbm90ZSwgY2FuIGJlIGNvbmZpZ3Vy ZWQgc28gdGhhdCBvbmUgd291bGQgZG8gRUNNUCBiYXNlZCBvbiBhZGRyZXNzZXMgYW5kIGZsb3ct bGFiZWwuICBUaGVyZSBhcmUgY2hpcHMgd2l0aCBwcmV0dHkgZGVlcCBwYXJzaW5nIGNhcGFiaWxp dHkgKHVwIHRvIGEgZmV3IGh1bmRyZWQgYnl0ZXMpLiANCg0KPiAuLi5GQjogVGhlIGNvbXBhcmlz b24gdG8gTVBMUyBpcyBpbnRlcmVzdGluZy4gSG93IG9mdGVuIGRvIE1QTFMgDQo+IHBhY2tldHMg bGVhayBhbmQgY2F1c2UgaGFybT8gRm9yIElPQU0sDQo+IGRyYWZ0LWlvYW1ldGFsLWlwcG0tNm1h bi1pb2FtLWlwdjYtb3B0aW9ucy0wMiBwcm9wb3NlcyBhIGRlcGxveW1lbnQgDQo+IG1vZGVsIHNp bWlsYXIgdG8gd2hhdCB3ZSBkbyBmb3IgTVBMUzogVW5sZXNzIGFuIGludGVyZmFjZSBpcyANCj4g ZXhwbGljaXRseSBjb25maWd1cmVkIGZvciBJT0FNLCBwYWNrZXRzIHdpdGggSU9BTSBkYXRhIGZp ZWxkcyBNVVNUIGJlIGRyb3BwZWQuDQo+IEhlbmNlIGxlYWthZ2Ugd291bGQgb25seSBvY2N1ciwg aWYgd2UgaGF2ZSBhIGNsZWFybHkgbWlzYmVoYXZpbmcgDQo+IHJvdXRlciB3aGljaCB2aW9sYXRl cyB0aGlzIHJ1bGUuIFNpbWlsYXIgdG8geW91LCBJJ2QgYWxzbyBncmVhdGx5IA0KPiBhcHByZWNp YXRlIGFueSBwb2ludGVycyB0byByZXNlYXJjaCBvbiBob3cgY29tbW9uIE1QTFMgbGVha2VkIHBh Y2tldHMgYXJlLg0KDQpXaGVuIGl0IGNvbWVzIHRvICJjYXVzZSBoYXJtIiBJIGltYWdpbmUgdGhl cmUgYXJlIChhdCBsZWFzdCkgdHdvIHdheXMgdG8gY2F1c2UgaGFybSwgb25lIGlzIHByaXZhY3kv c2VjcmVjeS9zZWN1cml0eSBsb3NzIGFuZCB0aGUgb3RoZXIgb25lIGlzIGFjdHVhbCBvcGVyYXRp b25hbCBsb3NzLg0KDQpJIGtub3cgb2YgYnVncyB3aGVyZSBsYWJlbGVkIHBhY2tldHMgd2VudCB0 aGUgd3Jvbmcgd2F5IGFuZCBjYXVzZWQgdGhlbSB0byBiZSBsb3N0LCBJJ3ZlIGFsc28gc2VlbiBi dWdzIHdoZXJlIGJ1Z3MgY2F1c2VkIHRyYWZmaWMgdG8gImhvcCIgYmV0d2VlbiBWUkZzIGluIE1Q TFMgVlBOIChvciB0byAiZ2xvYmFsIiBWUkYpLiBJIGRvbid0IGhhdmUgbnVtYmVycyBvbiB0aGlz IHRob3VnaC4NCg0KRGVwZW5kaW5nIG9uIHRoZSBkZXBsb3ltZW50IHNjZW5hcmlvLCBpdCBtaWdo dCBtYWtlIHNlbnNlIHRvIG1ha2UgSU9BTSBwYWNrZXRzIG5vdCB2YWxpZCBmb3Igbm9uLUlPQU0g YXdhcmUgZGV2aWNlcyAoYmFzaWNhbGx5IGVuY2FwIGVudGlyZSBwYWNrZXQvcGF5bG9hZCksIGJ1 dCB0aGF0IG1pZ2h0IGJlIGEgcHJvYmxlbSBmb3IgaW50ZXJtZWRpYXRlIG5vbi1JT0FNIG5vZGVz IHRoZW4uIFRoaXMgd291bGQgYWZmZWN0IHRoZSBFQ01QIHJlcXVpcmVtZW50LiBJIGNhbiBzZWUg Y2FzZXMgd2hlcmUgb25lIHdvdWxkIG9wZXJhdGlvbmFsbHkgdHVybiBvbiBJT0FNIGZvciBzb21l IGN1c3RvbWVycyB0cmFmZmljIGFuZCB0aGVuIHNlZSB0aGUgcHJvYmxlbSBnbyBhd2F5IGJlY2F1 c2Ugbm93IEVDTVAgY2hhbmdlZC4NCg0KPiAuLi5GQjogT25lIGlkZWEgdGhhdCBTaHdldGhhIGNh bWUgdXAgd2l0aCB0byBpZGVudGlmeSB0aGUgc291cmNlIEFTIG9mIA0KPiBhIGxlYWtlZCBwYWNr ZXQsIHdvdWxkIGJlIHRvIGFkZCBhIG5ldyBuZXcgSU9BTSBFMkUgb3B0aW9uIC0gYXMgDQo+IHBy b3Bvc2VkIGluIHNlY3Rpb24gNS4xLjEgYnVsbGV0IDIgb2YgDQo+IGRyYWZ0LWlvYW1ldGFsLWlw cG0tNm1hbi1pb2FtLWlwdjYtZGVwbG95bWVudC0wMS4NCg0KWWVzLCB0aGF0J2Qgc29sdmUgdGhh dCBwcm9ibGVtLg0KDQpIb3cgbXVjaCBoYXMgdGhlIHNpbGljb24gcGVvcGxlIGJlZW4gaW52b2x2 ZWQgc28gZmFyIGluIHRoZSBkZXNpZ24gb2YgdGhlIGhlYWRlcnM/IFdoYXQgaXMgdGhlIGN1cnJl bnQgdGhpbmtpbmcgb2YgYW1vdW50IG9mIGRhdGEgZ29pbmcgaW50byB0aGUgSU9BTSBoZWFkZXI/ IENvbnNpZGVyaW5nIHRoaW5ncyBsaWtlIHRyYWNlIG9wdGlvbnMgZXRjIGl0IHNlZW1zIHRvIG1l IHRoZSBoZWFkZXIgY2FuIGdyb3cgcXVpdGUgbGFyZ2U/IFRvIHNhdGlzZnkgdGhlIEVDTVAgcmVx dWlyZW1lbnQgd2hhdCBhYm91dCBwdXR0aW5nIHRoZSBJT0FNIGluZm9ybWF0aW9uIGFzIGEgdHJh aWxlciBiZWhpbmQgdGhlIHJlZ3VsYXIgcGF5bG9hZD8gT3IgaXMgdGhlcmUgYSBwcm9ibGVtIGZv ciB0aGUgaHcgdG8gbWFuaXB1bGF0ZSBpbmZvcm1hdGlvbiB0aGF0IGZhciBpbnRvIHRoZSBwYWNr ZXQgKEkgYWxzbyBpbWFnaW5lIHRoaXMgd2lsbCBjb25zaWRlcmFibHkgbG93ZXIgdGhlIGZvcndh cmRpbmcgcGVyZm9ybWFuY2Ugb2YgSU9BTSBwYWNrZXRzIG9uIElPQU0gYXdhcmUgcGxhdGZvcm1z KS4NCg0KLi4uLkZCMjogVGhlcmUgYXJlIHF1aXRlIGEgZmV3IGZvbGtzIHdpdGggaGFyZHdhcmUg YmFja2dyb3VuZCB0aGF0IGNvLWF1dGhvciB0aGUgSU9BTSBkcmFmdHMuIFBhcnNpbmcgY2FwYWJp bGl0eSBkaWZmZXJzIGJldHdlZW4gY2hpcHMsIGFzIGRvZXMgdGhlIGFiaWxpdHkgdG8gZGVhbCB3 aXRoIG5ldy9mbGV4aWJsZSBoZWFkZXJzIGFuZCB0aGUgYWJpbGl0eSB0byBtb2RpZnkgZGF0YSBp biB0aGUgZXh0ZW5zaW9uIGhlYWRlcnMuIFNvIHRoZSB1bmZvcnR1bmF0ZSBhbnN3ZXIgdG8gdGhh dCBxdWVzdGlvbiBpcyAiaXQgZGVwZW5kcyIgKHdoYXQgaW5mb3JtYXRpb24gZG8geW91IGdhdGhl ciwgaG93IGxhcmdlIGlzIHlvdXIgZG9tYWluLCB3aGF0IGFyZSB0aGUgY2FwYWJpbGl0aWVzIG9m IHlvdXIgaGFyZHdhcmUvc29mdHdhcmUgZm9yd2FyZGVyLCBldGMuKSwgYnV0IEkgZG8gZXhwZWN0 IHRoYXQgZm9yIHNwZWNpZmljIGRlcGxveW1lbnQgZG9tYWlucyAoZS5nLiBEQywgRW50ZXJwcmlz ZSkgLSBidXQgYWxzbyBmb3Igb3ZlcmxheSBuZXR3b3JrcyAvIFZQTnMgLSB3ZSdsbCBzZWUgYW4g aW5jcmVhc2luZyBhbW91bnQgb2YgY2hpcHMgdGhhdCBhcmUgd2VsbCBzdWl0ZWQgZm9yIHByb2Nl c3NpbmcgbGFyZ2UgZXh0ZW5zaW9uIGhlYWRlci4NCg0KQ2hlZXJzLCBGcmFuaw0KDQotLSANCk1p a2FlbCBBYnJhaGFtc3NvbiAgICBlbWFpbDogc3dtaWtlQHN3bS5wcC5zZQ0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KaXBwbSBtYWlsaW5nIGxpc3QN CmlwcG1AaWV0Zi5vcmcNCmh0dHBzOi8vZXVyMDMuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v ay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5m byUyRmlwcG0mYW1wO2RhdGE9MDIlN0MwMSU3Q2diYXJhayU0MG1lbGxhbm94LmNvbSU3QzYxMmJh NmRjMTE3NDQwZTY4YzQ2MDhkNmI4M2FlMTc0JTdDYTY1Mjk3MWM3ZDJlNGQ5YmE2YTRkMTQ5MjU2 ZjQ2MWIlN0MwJTdDMCU3QzYzNjg5ODk2MDM3OTQ4NTgzMyZhbXA7c2RhdGE9VmpaMVBpd2lmWUdD ZjE1OWplMHllZjNCSkZ6NkFRTk5BdGtnbUFNREZLTSUzRCZhbXA7cmVzZXJ2ZWQ9MA0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmlwcG0gbWFpbGluZyBs aXN0DQppcHBtQGlldGYub3JnDQpodHRwczovL2V1cjAzLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlz dGluZm8lMkZpcHBtJmFtcDtkYXRhPTAyJTdDMDElN0NnYmFyYWslNDBtZWxsYW5veC5jb20lN0M2 MTJiYTZkYzExNzQ0MGU2OGM0NjA4ZDZiODNhZTE3NCU3Q2E2NTI5NzFjN2QyZTRkOWJhNmE0ZDE0 OTI1NmY0NjFiJTdDMCU3QzAlN0M2MzY4OTg5NjAzNzk0ODU4MzMmYW1wO3NkYXRhPVZqWjFQaXdp ZllHQ2YxNTlqZTB5ZWYzQkpGejZBUU5OQXRrZ21BTURGS00lM0QmYW1wO3Jlc2VydmVkPTANCg== From nobody Fri Apr 5 09:16:24 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E0D120445; Fri, 5 Apr 2019 09:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.21 X-Spam-Level: X-Spam-Status: No, score=-2.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 aF3TKls2rlza; Fri, 5 Apr 2019 09:16:09 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FD171200A2; Fri, 5 Apr 2019 09:16:09 -0700 (PDT) Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id D52D79FA580E465C013D; Fri, 5 Apr 2019 17:16:05 +0100 (IST) Received: from DGGEML404-HUB.china.huawei.com (10.3.17.39) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Fri, 5 Apr 2019 17:16:05 +0100 Received: from DGGEML532-MBX.china.huawei.com ([169.254.8.160]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0415.000; Sat, 6 Apr 2019 00:15:58 +0800 From: "Pengshuping (Peng Shuping)" To: Barak Gafni , "Frank Brockners (fbrockne)" , Mikael Abrahamsson CC: "C. M. Heard" , 6man WG , Mark Smith , ippm Thread-Topic: draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) Thread-Index: AQHU6TgZZ0//UXm1xEuikh93W/G1dKYqbPpAgAFwpACAAeWlPw== Date: Fri, 5 Apr 2019 16:15:57 +0000 Message-ID: <4278D47A901B3041A737953BAA078ADE1478EC8B@DGGEML532-MBX.china.huawei.com> References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> <4278D47A901B3041A737953BAA078ADE1478D5E2@DGGEML532-MBX.china.huawei.com>, In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4278D47A901B3041A737953BAA078ADE1478EC8BDGGEML532MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 16:16:13 -0000 --_000_4278D47A901B3041A737953BAA078ADE1478EC8BDGGEML532MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQmFyYWssDQoNCldlIGFyZSBjZXJ0YWlubHkgbm90IGRlc2lnbmluZyBmb3IgdGhlIGxvd2Vz dCBjYXBhYmxlIHNvbHV0aW9ucyBidXQgZXhwbG9yaW5nIG9wdGltYWwgc29sdXRpb25zIHdoaWNo IGNvdWxkIGhlbHAgdG8ga2VlcCB0aGUgZm9yd2FyZGluZyBwZXJmb3JtYW5jZSB3aGlsZSBpbnNl cnRpbmcgdGhlIGlPQU0gZGF0YSB3aXRoIHZhcmlhYmxlIGxlbmd0aC4NCg0KSW4gdGVybXMgb2Yg dGhlIGZvcndhcmRpbmcgZWZmaWNpZW5jeSwgd2Ugd291bGQgYWxsIGFncmVlIHRoYXQgYSBzaG9y dCBhbmQgZml4ZWQgaGVhZGVyIHdvdWxkIGJlIGJldHRlciB0aGFuIGEgdmFyaWFibGUgaGVhZGVy Lg0KDQpCZXN0IHJlZ2FyZHMNClNodXBpbmcNCg0KDQq3orz+yMujuiBCYXJhayBHYWZuaTxnYmFy YWtAbWVsbGFub3guY29tPG1haWx0bzpnYmFyYWtAbWVsbGFub3guY29tPj4NCsrVvP7Iy6O6IFBl bmdzaHVwaW5nIChQZW5nIFNodXBpbmcpPHBlbmdzaHVwaW5nQGh1YXdlaS5jb208bWFpbHRvOnBl bmdzaHVwaW5nQGh1YXdlaS5jb20+PjtGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKTxmYnJvY2tu ZUBjaXNjby5jb208bWFpbHRvOmZicm9ja25lQGNpc2NvLmNvbT4+O01pa2FlbCBBYnJhaGFtc3Nv bjxzd21pa2VAc3dtLnBwLnNlPG1haWx0bzpzd21pa2VAc3dtLnBwLnNlPj4NCrOty82juiBDLiBN LiBIZWFyZDxoZWFyZEBwb2JveC5jb208bWFpbHRvOmhlYXJkQHBvYm94LmNvbT4+OzZtYW4gV0c8 aXB2NkBpZXRmLm9yZzxtYWlsdG86aXB2NkBpZXRmLm9yZz4+O01hcmsgU21pdGg8bWFya3p6enNt aXRoQGdtYWlsLmNvbTxtYWlsdG86bWFya3p6enNtaXRoQGdtYWlsLmNvbT4+O2lwcG08aXBwbUBp ZXRmLm9yZzxtYWlsdG86aXBwbUBpZXRmLm9yZz4+DQrW98zio7ogUkU6IGRyYWZ0LWlvYW1ldGFs LWlwcG0tNm1hbi1pb2FtLWlwdjYtZGVwbG95bWVudC0wMCBmZWVkYmFjayAoUmU6IHY2IG9wdGlv biB0eXBlcyBmb3IgSU9BTSBkYXRhIGZpZWxkcykNCsqxvOSjuiAyMDE5LTA0LTA1IDAzOjE4OjI2 DQoNCkhpIFNodXBpbmcsDQpJIHRoaW5rIHRoYXQgdGhlIHF1ZXN0aW9uIGlzIHdoZXRoZXIgd2Ug ZGVzaWduIGZvciB0aGUgbG93ZXN0IGNhcGFibGUgc29sdXRpb25zLiBJIGFzc3VtZSBzb21lb25l IGNhbiBmaW5kIHNvbHV0aW9ucyB3aXRoIGV2ZW4gbG93ZXIgYW1vdW50IG9mIHBhcnNpbmcuIFRo ZSBsb3cgZW5kIHNvbHV0aW9ucyBmb3IgdGhlc2UgY2FwYWJpbGl0aWVzIG1heSBuZWVkIHRvIGVp dGhlciBhZG9wdCB3aXRoIG5ldyBkZXNpZ25zIG9yIHVzZSBzb2x1dGlvbnMgc3VjaCBhcyB3aGF0 IGlzIHN1Z2dlc3RlZCBpbiB0aGlzIHRocmVhZCBieSBUb20gSGVyYmVydC4NClBlcnNvbmFsbHks IEkgZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIGdvIHRoaXMgd2F5LCBidXQgdG8gZGVzaWduIGFwcHJv cHJpYXRlIHNvbHV0aW9ucywgd2l0aCBhcHByb3ByaWF0ZSBsYXllcnMgaW4gdGhlIGhlYWRlcnMu IEZvciBleGFtcGxlLCBwcmV2ZW50IGRlcGVuZGVuY2llcyBiZXR3ZWVuICJyZW1vdGUiIGhlYWRl cnMuDQoNClRoYW5rcywNCkJhcmFrDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBpcHBtIDxpcHBtLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBQZW5nc2h1cGluZyAo UGVuZyBTaHVwaW5nKQ0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAzLCAyMDE5IDY6NDcgQU0NClRv OiBGcmFuayBCcm9ja25lcnMgKGZicm9ja25lKSA8ZmJyb2NrbmVAY2lzY28uY29tPjsgTWlrYWVs IEFicmFoYW1zc29uIDxzd21pa2VAc3dtLnBwLnNlPg0KQ2M6IEMuIE0uIEhlYXJkIDxoZWFyZEBw b2JveC5jb20+OyA2bWFuIFdHIDxpcHY2QGlldGYub3JnPjsgTWFyayBTbWl0aCA8bWFya3p6enNt aXRoQGdtYWlsLmNvbT47IGlwcG1AaWV0Zi5vcmcNClN1YmplY3Q6IFtpcHBtXSC08Li0OiBkcmFm dC1pb2FtZXRhbC1pcHBtLTZtYW4taW9hbS1pcHY2LWRlcGxveW1lbnQtMDAgZmVlZGJhY2sgKFJl OiB2NiBvcHRpb24gdHlwZXMgZm9yIElPQU0gZGF0YSBmaWVsZHMpDQoNCkhpLA0KDQpUaGUgcGFy c2luZyBkZXB0aCBvZiB0aGUgZWFybHkgY2hpcHMgaXMgOTZCLzEyOEIuIEZvciB0aGUgbmV3IGNo aXBzIHRoZSBwYXJzaW5nIGRlcHRoIGhhcyBiZWVuIGluY3JlYXNlZCBidXQgc3RpbGwgbGltaXRl ZC4gU28gTWlrYWVsJ3MgY29uY2VybiBtYWtlcyBzZW5zZSBlc3BlY2lhbGx5IGluIHRoZSB0cmFj aW5nIG1vZGUgdGhhdCB0aGUgSU9BTSBkYXRhIGZpZWxkcyBhcmUgZ29pbmcgdG8gaW5jcmVhc2Ug c2lnbmlmaWNhbnRseSBhbG9uZyB0aGUgcGF0aCwgd2hpY2ggd2lsbCBldmVuIHB1c2ggdGhlIFJv dXRpbmcgSGVhZGVyIG91dCBvZiB0aGUgcGFyc2luZyBkZXB0aCBvZiB0aGUgY2hpcC4gU28gaXQg d291bGQgbWFrZSBzZW5zZSB0byBzcGxpdCB0aGUgSU9BTSBkYXRhIHBhcnQgZnJvbSB0aGUgSU9B TSBoZWFkZXIvaW5zdHJ1Y3Rpb24gcGFydCwgYW5kIHBsYWNlIHRoZSBJT0FNIGRhdGEgYWZ0ZXIg dGhlIFJIIG9yIGV2ZW4gYWZ0ZXIgdGhlIEw0IGhlYWRlciBpbiBvcmRlciB0byBiZSBhYmxlIHRv IHJlYWQgdGhlIEw0IGluZm9ybWF0aW9uIHRvIGVuYWJsZSBFQ01QLCBhcyBzdGF0ZWQgaW4gdGhl IGRyYWZ0IGh0dHBzOi8vZXVyMDMuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGaHRtbCUyRmRyYWZ0LWxpLTZtYW4taXB2 Ni1zZmMtaWZpdC0wMCZhbXA7ZGF0YT0wMiU3QzAxJTdDZ2JhcmFrJTQwbWVsbGFub3guY29tJTdD NjEyYmE2ZGMxMTc0NDBlNjhjNDYwOGQ2YjgzYWUxNzQlN0NhNjUyOTcxYzdkMmU0ZDliYTZhNGQx NDkyNTZmNDYxYiU3QzAlN0MwJTdDNjM2ODk4OTYwMzc5NDg1ODMzJmFtcDtzZGF0YT1Eb2I0ek4l MkYxalNHeExUbHFHbWEyOUpKTnZxSkRCdDRWenFIc040T3B4TTQlM0QmYW1wO3Jlc2VydmVkPTAu DQoNCkJSLA0KU2h1cGluZw0KDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBpcHBtIFtt YWlsdG86aXBwbS1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEZyYW5rIEJyb2NrbmVycyAoZmJyb2Nr bmUpDQq3osvNyrG85DogMjAxOcTqNNTCMsjVIDE3OjQwDQrK1bz+yMs6IE1pa2FlbCBBYnJhaGFt c3NvbiA8c3dtaWtlQHN3bS5wcC5zZT4NCrOty806IEMuIE0uIEhlYXJkIDxoZWFyZEBwb2JveC5j b20+OyA2bWFuIFdHIDxpcHY2QGlldGYub3JnPjsgTWFyayBTbWl0aCA8bWFya3p6enNtaXRoQGdt YWlsLmNvbT47IGlwcG1AaWV0Zi5vcmcNCtb3zOI6IFJlOiBbaXBwbV0gZHJhZnQtaW9hbWV0YWwt aXBwbS02bWFuLWlvYW0taXB2Ni1kZXBsb3ltZW50LTAwIGZlZWRiYWNrIChSZTogdjYgb3B0aW9u IHR5cGVzIGZvciBJT0FNIGRhdGEgZmllbGRzKQ0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IE1pa2FlbCBBYnJhaGFtc3NvbiA8c3dtaWtlQHN3bS5wcC5zZT4NClNlbnQ6 IERpZW5zdGFnLCAyLiBBcHJpbCAyMDE5IDA4OjA2DQpUbzogRnJhbmsgQnJvY2tuZXJzIChmYnJv Y2tuZSkgPGZicm9ja25lQGNpc2NvLmNvbT4NCkNjOiBNYXJrIFNtaXRoIDxtYXJrenp6c21pdGhA Z21haWwuY29tPjsgQy4gTS4gSGVhcmQgPGhlYXJkQHBvYm94LmNvbT47IDZtYW4gV0cgPGlwdjZA aWV0Zi5vcmc+OyBpcHBtQGlldGYub3JnDQpTdWJqZWN0OiBSRTogZHJhZnQtaW9hbWV0YWwtaXBw bS02bWFuLWlvYW0taXB2Ni1kZXBsb3ltZW50LTAwIGZlZWRiYWNrIChSZTogdjYgb3B0aW9uIHR5 cGVzIGZvciBJT0FNIGRhdGEgZmllbGRzKQ0KDQpPbiBNb24sIDEgQXByIDIwMTksIEZyYW5rIEJy b2NrbmVycyAoZmJyb2NrbmUpIHdyb3RlOg0KDQo+IC4uLkZCOiBUaGVyZSBpcyBvYnZpb3VzbHkg bm8gZWFzeSBhbnN3ZXIuIENvdXBsZSBvZiB0aG91Z2h0czoNCj4gKiBJT0FNIGlzIGNvbnNpZGVy ZWQgYSAiZG9tYWluIHNwZWNpZmljIiBmZWF0dXJlIChzZWUNCj4gZHJhZnQtaWV0Zi1pcHBtLWlv YW0tZGF0YS0wNSwgc2VjdGlvbiAzKS4gUm91dGVycyBpbiB0aGUgSU9BTSBkb21haW4NCj4gc2hv dWxkIGJlIElPQU0gY2FwYWJsZS4gIEFuZCBJTUhPLCAgd2Ugc2hvdWxkIGFkZCBhIHN0YXRlbWVu dCB0bw0KPiBkcmFmdC1pb2FtZXRhbC1pcHBtLTZtYW4taW9hbS1pcHY2LWRlcGxveW1lbnQgdGhh dCBhbiBpbXBsZW1lbnRhdGlvbg0KPiBvZiBJT0FNIE1VU1QgZW5zdXJlICJDMSIuDQo+DQo+ICog VGhhdCBzYWlkLCB0aGVyZSBjYW4gYmUgc2l0dWF0aW9ucywgd2hlcmUgQzEgY2Fubm90IGJlIGFj aGlldmVkLCBlLmcuDQo+IGNvbnNpZGVyIGEgbmV0d29yayB3aGljaCBkb2VzIEVDTVAgc2NoZWR1 bGluZyBiYXNlZCBvbiBwYWNrZXQgbGVuZ3RoLg0KPg0KPiAqIFdoYXQgb25lIGNvdWxkIGNvbnNp ZGVyIC0gYW5kIHdoaWNoIGlzIG9uZSBzdWdnZXN0ZWQgZGVwbG95bWVudA0KPiBtb2RlbA0KPiAt IGlzIHRoYXQgYnkgZGVmYXVsdCBJT0FNIGRhdGEgZmllbGRzIGFyZSBhZGRlZCB0byBfYWxsXyBj dXN0b21lcg0KPiBwYWNrZXRzLiBUaGUgZGVjYXBzdWxhdGluZyBub2RlIHdvdWxkIGRlY2lkZSB3 aGV0aGVyIHRoZSBJT0FNDQo+IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiBhIHBhY2tldCB3b3Vs ZCBiZSB1c2VkIChhbmQgZXhwb3J0ZWQpIG9yIG5vdC4NCj4gVGhhdCB3YXkgb25lIHdvdWxkIG5v dCBuZWVkIHRvIGRlYWwgd2l0aCB0aGUgc2l0dWF0aW9uIHRoYXQgc29tZQ0KPiB0cmFmZmljIGNh cnJpZXMgSU9BTSB3aGlsZSBvdGhlciBkb2VzIG5vdCAtIGFuZCBtaWdodCB0aHVzIGJlIHRyZWF0 ZWQNCj4gZGlmZmVyZW50bHkuDQoNClllcywgSSB0aGluayB0aGlzIGlzIHRoZSBvbmx5IHdheS4g SXMgdGhlcmUgYSByaXNrIHRoYXQgaW50ZXJtZWRpYXRlIHJvdXRlcnMgd291bGQgbm90IGJlIElP QU0gY2FwYWJsZT8gSSB0aGluayB0aGUgQzEgcmVxdWlyZW1lbnQgaXMgcmVhbGx5IHJlYWxseSBo YXJkIHRvIGZ1bGZpbCBhbmQgSSdtIGFsc28gYWZyYWlkIHRoYXQgYWRkaW5nIHRoZSBJT0FNIGhl YWRlciB3aWxsIGFjdHVhbGx5IG1ha2UgRUNNUCBzdG9wIHdvcmtpbmcgb24gc29tZSBwbGF0Zm9y bXMgKGJlY2F1c2UgdGhleSB3b3VsZCBub3QgaGF2ZSB0aGUgY2FwYWJpbGl0eSB0byBsb29rIGRl ZXAgZW5vdWdoIGludG8gdGhlIHBhY2tldCB0byBmaW5kIEw0IGluZm9ybWF0aW9uLCBzbyBpdCds bCBnbyBiYWNrIHRvIDIgdHVwbGUgRUNNUCBpbnN0ZWFkIG9mIDUgdHVwbGUuDQoNCkJ1dCB0aGlz IHF1ZXN0aW9uIGNhbiBvbmx5IGJlIGFuc3dlcmVkIGJ5IHBlb3BsZSB3aXRoIGRlZXAgTlBVIGtu b3dsZWRnZS4uLg0KDQouLi4uRkIyOiBHaXZlbiB0aGF0IElPQU0gaXMgYSBkb21haW4gc3BlY2lm aWMgZmVhdHVyZSAtIEkgZXhwZWN0IHRoYXQgZm9sa3MgaW5pdGlhbGx5IHN0YXJ0IHRvIHVzZSBp dCBpbiBkb21haW5zIChsaWtlIGUuZy4gYSBEQykgd2hlcmUgYWxsIGJveGVzIGFyZSBJT0FNIGNh cGFibGUgYW5kIGNhbiB0cmFjZSB0aGUgcGFja2V0IGFwcHJvcHJpYXRlbHkgLSBvciBwZXIgVG9t J3Mgbm90ZSwgY2FuIGJlIGNvbmZpZ3VyZWQgc28gdGhhdCBvbmUgd291bGQgZG8gRUNNUCBiYXNl ZCBvbiBhZGRyZXNzZXMgYW5kIGZsb3ctbGFiZWwuICBUaGVyZSBhcmUgY2hpcHMgd2l0aCBwcmV0 dHkgZGVlcCBwYXJzaW5nIGNhcGFiaWxpdHkgKHVwIHRvIGEgZmV3IGh1bmRyZWQgYnl0ZXMpLg0K DQo+IC4uLkZCOiBUaGUgY29tcGFyaXNvbiB0byBNUExTIGlzIGludGVyZXN0aW5nLiBIb3cgb2Z0 ZW4gZG8gTVBMUw0KPiBwYWNrZXRzIGxlYWsgYW5kIGNhdXNlIGhhcm0/IEZvciBJT0FNLA0KPiBk cmFmdC1pb2FtZXRhbC1pcHBtLTZtYW4taW9hbS1pcHY2LW9wdGlvbnMtMDIgcHJvcG9zZXMgYSBk ZXBsb3ltZW50DQo+IG1vZGVsIHNpbWlsYXIgdG8gd2hhdCB3ZSBkbyBmb3IgTVBMUzogVW5sZXNz IGFuIGludGVyZmFjZSBpcw0KPiBleHBsaWNpdGx5IGNvbmZpZ3VyZWQgZm9yIElPQU0sIHBhY2tl dHMgd2l0aCBJT0FNIGRhdGEgZmllbGRzIE1VU1QgYmUgZHJvcHBlZC4NCj4gSGVuY2UgbGVha2Fn ZSB3b3VsZCBvbmx5IG9jY3VyLCBpZiB3ZSBoYXZlIGEgY2xlYXJseSBtaXNiZWhhdmluZw0KPiBy b3V0ZXIgd2hpY2ggdmlvbGF0ZXMgdGhpcyBydWxlLiBTaW1pbGFyIHRvIHlvdSwgSSdkIGFsc28g Z3JlYXRseQ0KPiBhcHByZWNpYXRlIGFueSBwb2ludGVycyB0byByZXNlYXJjaCBvbiBob3cgY29t bW9uIE1QTFMgbGVha2VkIHBhY2tldHMgYXJlLg0KDQpXaGVuIGl0IGNvbWVzIHRvICJjYXVzZSBo YXJtIiBJIGltYWdpbmUgdGhlcmUgYXJlIChhdCBsZWFzdCkgdHdvIHdheXMgdG8gY2F1c2UgaGFy bSwgb25lIGlzIHByaXZhY3kvc2VjcmVjeS9zZWN1cml0eSBsb3NzIGFuZCB0aGUgb3RoZXIgb25l IGlzIGFjdHVhbCBvcGVyYXRpb25hbCBsb3NzLg0KDQpJIGtub3cgb2YgYnVncyB3aGVyZSBsYWJl bGVkIHBhY2tldHMgd2VudCB0aGUgd3Jvbmcgd2F5IGFuZCBjYXVzZWQgdGhlbSB0byBiZSBsb3N0 LCBJJ3ZlIGFsc28gc2VlbiBidWdzIHdoZXJlIGJ1Z3MgY2F1c2VkIHRyYWZmaWMgdG8gImhvcCIg YmV0d2VlbiBWUkZzIGluIE1QTFMgVlBOIChvciB0byAiZ2xvYmFsIiBWUkYpLiBJIGRvbid0IGhh dmUgbnVtYmVycyBvbiB0aGlzIHRob3VnaC4NCg0KRGVwZW5kaW5nIG9uIHRoZSBkZXBsb3ltZW50 IHNjZW5hcmlvLCBpdCBtaWdodCBtYWtlIHNlbnNlIHRvIG1ha2UgSU9BTSBwYWNrZXRzIG5vdCB2 YWxpZCBmb3Igbm9uLUlPQU0gYXdhcmUgZGV2aWNlcyAoYmFzaWNhbGx5IGVuY2FwIGVudGlyZSBw YWNrZXQvcGF5bG9hZCksIGJ1dCB0aGF0IG1pZ2h0IGJlIGEgcHJvYmxlbSBmb3IgaW50ZXJtZWRp YXRlIG5vbi1JT0FNIG5vZGVzIHRoZW4uIFRoaXMgd291bGQgYWZmZWN0IHRoZSBFQ01QIHJlcXVp cmVtZW50LiBJIGNhbiBzZWUgY2FzZXMgd2hlcmUgb25lIHdvdWxkIG9wZXJhdGlvbmFsbHkgdHVy biBvbiBJT0FNIGZvciBzb21lIGN1c3RvbWVycyB0cmFmZmljIGFuZCB0aGVuIHNlZSB0aGUgcHJv YmxlbSBnbyBhd2F5IGJlY2F1c2Ugbm93IEVDTVAgY2hhbmdlZC4NCg0KPiAuLi5GQjogT25lIGlk ZWEgdGhhdCBTaHdldGhhIGNhbWUgdXAgd2l0aCB0byBpZGVudGlmeSB0aGUgc291cmNlIEFTIG9m DQo+IGEgbGVha2VkIHBhY2tldCwgd291bGQgYmUgdG8gYWRkIGEgbmV3IG5ldyBJT0FNIEUyRSBv cHRpb24gLSBhcw0KPiBwcm9wb3NlZCBpbiBzZWN0aW9uIDUuMS4xIGJ1bGxldCAyIG9mDQo+IGRy YWZ0LWlvYW1ldGFsLWlwcG0tNm1hbi1pb2FtLWlwdjYtZGVwbG95bWVudC0wMS4NCg0KWWVzLCB0 aGF0J2Qgc29sdmUgdGhhdCBwcm9ibGVtLg0KDQpIb3cgbXVjaCBoYXMgdGhlIHNpbGljb24gcGVv cGxlIGJlZW4gaW52b2x2ZWQgc28gZmFyIGluIHRoZSBkZXNpZ24gb2YgdGhlIGhlYWRlcnM/IFdo YXQgaXMgdGhlIGN1cnJlbnQgdGhpbmtpbmcgb2YgYW1vdW50IG9mIGRhdGEgZ29pbmcgaW50byB0 aGUgSU9BTSBoZWFkZXI/IENvbnNpZGVyaW5nIHRoaW5ncyBsaWtlIHRyYWNlIG9wdGlvbnMgZXRj IGl0IHNlZW1zIHRvIG1lIHRoZSBoZWFkZXIgY2FuIGdyb3cgcXVpdGUgbGFyZ2U/IFRvIHNhdGlz ZnkgdGhlIEVDTVAgcmVxdWlyZW1lbnQgd2hhdCBhYm91dCBwdXR0aW5nIHRoZSBJT0FNIGluZm9y bWF0aW9uIGFzIGEgdHJhaWxlciBiZWhpbmQgdGhlIHJlZ3VsYXIgcGF5bG9hZD8gT3IgaXMgdGhl cmUgYSBwcm9ibGVtIGZvciB0aGUgaHcgdG8gbWFuaXB1bGF0ZSBpbmZvcm1hdGlvbiB0aGF0IGZh ciBpbnRvIHRoZSBwYWNrZXQgKEkgYWxzbyBpbWFnaW5lIHRoaXMgd2lsbCBjb25zaWRlcmFibHkg bG93ZXIgdGhlIGZvcndhcmRpbmcgcGVyZm9ybWFuY2Ugb2YgSU9BTSBwYWNrZXRzIG9uIElPQU0g YXdhcmUgcGxhdGZvcm1zKS4NCg0KLi4uLkZCMjogVGhlcmUgYXJlIHF1aXRlIGEgZmV3IGZvbGtz IHdpdGggaGFyZHdhcmUgYmFja2dyb3VuZCB0aGF0IGNvLWF1dGhvciB0aGUgSU9BTSBkcmFmdHMu IFBhcnNpbmcgY2FwYWJpbGl0eSBkaWZmZXJzIGJldHdlZW4gY2hpcHMsIGFzIGRvZXMgdGhlIGFi aWxpdHkgdG8gZGVhbCB3aXRoIG5ldy9mbGV4aWJsZSBoZWFkZXJzIGFuZCB0aGUgYWJpbGl0eSB0 byBtb2RpZnkgZGF0YSBpbiB0aGUgZXh0ZW5zaW9uIGhlYWRlcnMuIFNvIHRoZSB1bmZvcnR1bmF0 ZSBhbnN3ZXIgdG8gdGhhdCBxdWVzdGlvbiBpcyAiaXQgZGVwZW5kcyIgKHdoYXQgaW5mb3JtYXRp b24gZG8geW91IGdhdGhlciwgaG93IGxhcmdlIGlzIHlvdXIgZG9tYWluLCB3aGF0IGFyZSB0aGUg Y2FwYWJpbGl0aWVzIG9mIHlvdXIgaGFyZHdhcmUvc29mdHdhcmUgZm9yd2FyZGVyLCBldGMuKSwg YnV0IEkgZG8gZXhwZWN0IHRoYXQgZm9yIHNwZWNpZmljIGRlcGxveW1lbnQgZG9tYWlucyAoZS5n LiBEQywgRW50ZXJwcmlzZSkgLSBidXQgYWxzbyBmb3Igb3ZlcmxheSBuZXR3b3JrcyAvIFZQTnMg LSB3ZSdsbCBzZWUgYW4gaW5jcmVhc2luZyBhbW91bnQgb2YgY2hpcHMgdGhhdCBhcmUgd2VsbCBz dWl0ZWQgZm9yIHByb2Nlc3NpbmcgbGFyZ2UgZXh0ZW5zaW9uIGhlYWRlci4NCg0KQ2hlZXJzLCBG cmFuaw0KDQotLQ0KTWlrYWVsIEFicmFoYW1zc29uICAgIGVtYWlsOiBzd21pa2VAc3dtLnBwLnNl DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQppcHBt IG1haWxpbmcgbGlzdA0KaXBwbUBpZXRmLm9yZw0KaHR0cHM6Ly9ldXIwMy5zYWZlbGlua3MucHJv dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFp bG1hbiUyRmxpc3RpbmZvJTJGaXBwbSZhbXA7ZGF0YT0wMiU3QzAxJTdDZ2JhcmFrJTQwbWVsbGFu b3guY29tJTdDNjEyYmE2ZGMxMTc0NDBlNjhjNDYwOGQ2YjgzYWUxNzQlN0NhNjUyOTcxYzdkMmU0 ZDliYTZhNGQxNDkyNTZmNDYxYiU3QzAlN0MwJTdDNjM2ODk4OTYwMzc5NDg1ODMzJmFtcDtzZGF0 YT1WaloxUGl3aWZZR0NmMTU5amUweWVmM0JKRno2QVFOTkF0a2dtQU1ERktNJTNEJmFtcDtyZXNl cnZlZD0wDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K aXBwbSBtYWlsaW5nIGxpc3QNCmlwcG1AaWV0Zi5vcmcNCmh0dHBzOi8vZXVyMDMuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUy Rm1haWxtYW4lMkZsaXN0aW5mbyUyRmlwcG0mYW1wO2RhdGE9MDIlN0MwMSU3Q2diYXJhayU0MG1l bGxhbm94LmNvbSU3QzYxMmJhNmRjMTE3NDQwZTY4YzQ2MDhkNmI4M2FlMTc0JTdDYTY1Mjk3MWM3 ZDJlNGQ5YmE2YTRkMTQ5MjU2ZjQ2MWIlN0MwJTdDMCU3QzYzNjg5ODk2MDM3OTQ4NTgzMyZhbXA7 c2RhdGE9VmpaMVBpd2lmWUdDZjE1OWplMHllZjNCSkZ6NkFRTk5BdGtnbUFNREZLTSUzRCZhbXA7 cmVzZXJ2ZWQ9MA0K --_000_4278D47A901B3041A737953BAA078ADE1478EC8BDGGEML532MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Hi Barak,

We are certainly not designing for the lowest capable solutions but explori= ng optimal solutions which could help to keep the forwarding performance wh= ile inserting the iOAM data with variable length.

In terms of the forwarding efficiency, we would all agree that a short and = fixed header would be better than a variable header.

Best regards
Shuping


=B7=A2=BC=FE=C8=CB=A3=BA Barak Gafni<gbarak@mellanox.com>
=CA=D5=BC=FE=C8=CB=A3=BA Pengshuping (Peng Shuping)<pengshuping@huawei.com>;Frank Bro= ckners (fbrockne)<fbrockne@cisco.c= om>;Mikael Abrahamsson<swmike= @swm.pp.se>
=B3=AD=CB=CD=A3=BA C. M. Heard<heard@pobox.com>;6man WG<i= pv6@ietf.org>;Mark Smith<markzzzsmith@gmail.com>;ippm<i= ppm@ietf.org>
=D6=F7=CC=E2=A3=BA RE: draft-ioametal-ippm-6man-ioam-ipv6-deplo= yment-00 feedback (Re: v6 option types for IOAM data fields)
=CA=B1=BC=E4=A3=BA 2019-04-05 03:18:26

Hi Shuping,
I think that the question is whether we design for the lowest capable solut= ions. I assume someone can find solutions with even lower amount of parsing= . The low end solutions for these capabilities may need to either adopt wit= h new designs or use solutions such as what is suggested in this thread by Tom Herbert.
Personally, I don't think we should go this way, but to design appropriate = solutions, with appropriate layers in the headers. For example, prevent dep= endencies between "remote" headers.

Thanks,
Barak

-----Original Message-----
From: ippm <ippm-bounces@ietf.org> On Behalf Of Pengshuping (Peng Shu= ping)
Sent: Wednesday, April 3, 2019 6:47 AM
To: Frank Brockners (fbrockne) <fbrockne@cisco.com>; Mikael Abrahamss= on <swmike@swm.pp.se>
Cc: C. M. Heard <heard@pobox.com>; 6man WG <ipv6@ietf.org>; Mar= k Smith <markzzzsmith@gmail.com>; ippm@ietf.org
Subject: [ippm] =B4=F0=B8=B4: draft-ioametal-ippm-6man-ioam-ipv6-deployment= -00 feedback (Re: v6 option types for IOAM data fields)

Hi,

The parsing depth of the early chips is 96B/128B. For the new chips the par= sing depth has been increased but still limited. So Mikael's concern makes = sense especially in the tracing mode that the IOAM data fields are going to= increase significantly along the path, which will even push the Routing Header out of the parsing depth of = the chip. So it would make sense to split the IOAM data part from the IOAM = header/instruction part, and place the IOAM data after the RH or even after= the L4 header in order to be able to read the L4 information to enable ECMP, as stated in the draft https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.i= etf.org%2Fhtml%2Fdraft-li-6man-ipv6-sfc-ifit-00&amp;data=3D02%7C01%7Cgb= arak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6= a4d149256f461b%7C0%7C0%7C636898960379485833&amp;sdata=3DDob4zN%2F1jSGxL= TlqGma29JJNvqJDBt4VzqHsN4OpxM4%3D&amp;reserved=3D0.

BR,
Shuping


-----=D3=CA=BC=FE=D4=AD=BC=FE-----
=B7=A2=BC=FE=C8=CB: ippm [mailto:i= ppm-bounces@ietf.org] =B4=FA=B1=ED Frank Brockners (fbrockne)
=B7=A2=CB=CD=CA=B1=BC=E4: 2019=C4=EA4=D4=C22=C8=D5 17:40
=CA=D5=BC=FE=C8=CB: Mikael Abrahamsson <swmike@swm.pp.se>
=B3=AD=CB=CD: C. M. Heard <heard@pobox.com>; 6man WG <ipv6@ietf.or= g>; Mark Smith <markzzzsmith@gmail.com>; ippm@ietf.org
=D6=F7=CC=E2: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 f= eedback (Re: v6 option types for IOAM data fields)



-----Original Message-----
From: Mikael Abrahamsson <swmike@swm.pp.se>
Sent: Dienstag, 2. April 2019 08:06
To: Frank Brockners (fbrockne) <fbrockne@cisco.com>
Cc: Mark Smith <markzzzsmith@gmail.com>; C. M. Heard <heard@pobox.= com>; 6man WG <ipv6@ietf.org>; ippm@ietf.org
Subject: RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re:= v6 option types for IOAM data fields)

On Mon, 1 Apr 2019, Frank Brockners (fbrockne) wrote:

> ...FB: There is obviously no easy answer. Couple of thoughts:
> * IOAM is considered a "domain specific" feature (see
> draft-ietf-ippm-ioam-data-05, section 3). Routers in the IOAM domain <= br> > should be IOAM capable.  And IMHO,  we should add a statemen= t to
> draft-ioametal-ippm-6man-ioam-ipv6-deployment that an implementation <= br> > of IOAM MUST ensure "C1".
>
> * That said, there can be situations, where C1 cannot be achieved, e.g= .
> consider a network which does ECMP scheduling based on packet length.<= br> >
> * What one could consider - and which is one suggested deployment
> model
> - is that by default IOAM data fields are added to _all_ customer
> packets. The decapsulating node would decide whether the IOAM
> information contained in a packet would be used (and exported) or not.=
> That way one would not need to deal with the situation that some
> traffic carries IOAM while other does not - and might thus be treated =
> differently.

Yes, I think this is the only way. Is there a risk that intermediate router= s would not be IOAM capable? I think the C1 requirement is really really ha= rd to fulfil and I'm also afraid that adding the IOAM header will actually = make ECMP stop working on some platforms (because they would not have the capability to look deep enough into the p= acket to find L4 information, so it'll go back to 2 tuple ECMP instead of 5= tuple.

But this question can only be answered by people with deep NPU knowledge...=

....FB2: Given that IOAM is a domain specific feature - I expect that folks= initially start to use it in domains (like e.g. a DC) where all boxes are = IOAM capable and can trace the packet appropriately - or per Tom's note, ca= n be configured so that one would do ECMP based on addresses and flow-label.  There are chips with pret= ty deep parsing capability (up to a few hundred bytes).

> ...FB: The comparison to MPLS is interesting. How often do MPLS
> packets leak and cause harm? For IOAM,
> draft-ioametal-ippm-6man-ioam-ipv6-options-02 proposes a deployment > model similar to what we do for MPLS: Unless an interface is
> explicitly configured for IOAM, packets with IOAM data fields MUST be = dropped.
> Hence leakage would only occur, if we have a clearly misbehaving
> router which violates this rule. Similar to you, I'd also greatly
> appreciate any pointers to research on how common MPLS leaked packets = are.

When it comes to "cause harm" I imagine there are (at least) two = ways to cause harm, one is privacy/secrecy/security loss and the other one = is actual operational loss.

I know of bugs where labeled packets went the wrong way and caused them to = be lost, I've also seen bugs where bugs caused traffic to "hop" b= etween VRFs in MPLS VPN (or to "global" VRF). I don't have number= s on this though.

Depending on the deployment scenario, it might make sense to make IOAM pack= ets not valid for non-IOAM aware devices (basically encap entire packet/pay= load), but that might be a problem for intermediate non-IOAM nodes then. Th= is would affect the ECMP requirement. I can see cases where one would operationally turn on IOAM for some custom= ers traffic and then see the problem go away because now ECMP changed.

> ...FB: One idea that Shwetha came up with to identify the source AS of=
> a leaked packet, would be to add a new new IOAM E2E option - as
> proposed in section 5.1.1 bullet 2 of
> draft-ioametal-ippm-6man-ioam-ipv6-deployment-01.

Yes, that'd solve that problem.

How much has the silicon people been involved so far in the design of the h= eaders? What is the current thinking of amount of data going into the IOAM = header? Considering things like trace options etc it seems to me the header= can grow quite large? To satisfy the ECMP requirement what about putting the IOAM information as a trailer = behind the regular payload? Or is there a problem for the hw to manipulate = information that far into the packet (I also imagine this will considerably= lower the forwarding performance of IOAM packets on IOAM aware platforms).

....FB2: There are quite a few folks with hardware background that co-autho= r the IOAM drafts. Parsing capability differs between chips, as does the ab= ility to deal with new/flexible headers and the ability to modify data in t= he extension headers. So the unfortunate answer to that question is "it depends" (what information do you= gather, how large is your domain, what are the capabilities of your hardwa= re/software forwarder, etc.), but I do expect that for specific deployment = domains (e.g. DC, Enterprise) - but also for overlay networks / VPNs - we'll see an increasing amount of chips that are= well suited for processing large extension header.

Cheers, Frank

--
Mikael Abrahamsson    email: swmike@swm.pp.se

_______________________________________________
ippm mailing list
ippm@ietf.org
https://eur03.safelinks.= protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistin= fo%2Fippm&amp;data=3D02%7C01%7Cgbarak%40mellanox.com%7C612ba6dc117440e6= 8c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C6368989603794= 85833&amp;sdata=3DVjZ1PiwifYGCf159je0yef3BJFz6AQNNAtkgmAMDFKM%3D&am= p;reserved=3D0
_______________________________________________
ippm mailing list
ippm@ietf.org
https://eur03.safelinks.= protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistin= fo%2Fippm&amp;data=3D02%7C01%7Cgbarak%40mellanox.com%7C612ba6dc117440e6= 8c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C6368989603794= 85833&amp;sdata=3DVjZ1PiwifYGCf159je0yef3BJFz6AQNNAtkgmAMDFKM%3D&am= p;reserved=3D0
 --_000_4278D47A901B3041A737953BAA078ADE1478EC8BDGGEML532MBXchi_-- From nobody Fri Apr 5 10:31:37 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF22120117 for ; Fri, 5 Apr 2019 10:31: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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 Jsw9pwQlYVFA for ; Fri, 5 Apr 2019 10:31:32 -0700 (PDT) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEE15120112 for ; Fri, 5 Apr 2019 10:31:31 -0700 (PDT) Received: by mail-qk1-x731.google.com with SMTP id n68so4318891qka.1 for ; Fri, 05 Apr 2019 10:31:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Fd98CyLNuPNbwNn7X5WZPo3fhoaa9blTJpLwf7Esuc8=; b=OVihQFSRfHyZ9aSZk9oDl3PUTj6Q2Xl8oTaSEL91zNA9JgehH/wsHrXhsVSU9ccayM ZtqxtNOr02QMTDwIh0Bkk847s/NbXSKZvXaNSH5hN1crlOxkUexmNywVVM2bzFky6HRM uNtFIY3Rh0fkRQQtVZJEjfo/pY9i+AHPS2ZZ/k78igwnUc5Tb0zQfEVu+K1hm7UY91Rw P1z0EqFuGKpPQAUYRc6NqJrbZmoAolPdVuw3a5tpgSBrAoVLEAMpDNn5BFfdGLCbeX4s vHo6EB9FM8XzpqVJOfql3UysFJu+DVUwvZNY+GvbTVU8Ag/lNkUOM6PCpRBgXCeXvyGg lPRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Fd98CyLNuPNbwNn7X5WZPo3fhoaa9blTJpLwf7Esuc8=; b=fp6k1ig/cmTq7l7WKkSKtUPH73+lBgcOS610OLv0dLmqNdxQzGL+qA/KZmHGaWcEM4 zq/rRo9ingCPEJ/FcStwIQ6R41wUHMDjubgzzcW1bUI1/w5UtXYqarWGQno41nRELyIr sXAHiEI7mo5DSY3Os3ZPWlwUv/DRmknead+rzA6S0UT2xo9jCyLqTyH8EJquAbtUbare ZcpiZCiVW8Adnhrik9YgHbzUsmSQW5L/r/Zf473CoYWYvSY3Ow9yL+KM+Ud1rtaWXy4Z nweKPuu7/Z2I3RrTDMreLlxbXOAZgVxb6fQD7zZV4j8ofYbWZo9oaGpb4bj67APAalTH M0PQ== X-Gm-Message-State: APjAAAUw9c2g7mjvQUTdji/QwXGaB4A9nnC9seJcLBghxMTO1+oMZL76 ZnD9f//FvP+SSedHnNGDJUxuJYA+fqOtKizuC77pmA== X-Google-Smtp-Source: APXvYqwieQNH+j4M9xeUi5j1J6yHgjwKF0kMM6ldw/bseOJ709Vb0BesnwM0RXny5WDOdk+ozFZe6wCOp7GAUoeIvrQ= X-Received: by 2002:a37:638c:: with SMTP id x134mr11111597qkb.107.1554485490634; Fri, 05 Apr 2019 10:31:30 -0700 (PDT) MIME-Version: 1.0 References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> <4278D47A901B3041A737953BAA078ADE1478D5E2@DGGEML532-MBX.china.huawei.com> <4278D47A901B3041A737953BAA078ADE1478EC8B@DGGEML532-MBX.china.huawei.com> In-Reply-To: <4278D47A901B3041A737953BAA078ADE1478EC8B@DGGEML532-MBX.china.huawei.com> From: Tom Herbert Date: Fri, 5 Apr 2019 10:31:19 -0700 Message-ID: To: "Pengshuping (Peng Shuping)" Cc: Barak Gafni , "Frank Brockners (fbrockne)" , Mikael Abrahamsson , "C. M. Heard" , 6man WG , ippm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 17:31:36 -0000 On Fri, Apr 5, 2019 at 9:16 AM Pengshuping (Peng Shuping) wrote: > > Hi Barak, > > We are certainly not designing for the lowest capable solutions but explo= ring optimal solutions which could help to keep the forwarding performance = while inserting the iOAM data with variable length. Shuping, That's exactly the argument for using the flow label in ECMP. Efficeint packet forwarding can be done solely by inspected the forty byte fixed length header of the packet regardless of the contents of the rest of the packet. That is an optimal solution. Anything else for ECMP like doing DPI or hacking up IOAM to try do pull transport layers into the parsing buffer (whatever size that may be) are nothing more than hacks and unnecessarily perpetuate techniques used with IPv4 that either don't work or are unnecessary in IPv6. Tom > > In terms of the forwarding efficiency, we would all agree that a short an= d fixed header would be better than a variable header. > > Best regards > Shuping > > > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Barak Gafni > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Pengshuping (Peng Shuping);Frank Brockners (fbrockne);Mikael Abraha= msson > =E6=8A=84=E9=80=81=EF=BC=9A C. M. Heard;6man WG;Mark Smith;ippm > =E4=B8=BB=E9=A2=98=EF=BC=9A RE: draft-ioametal-ippm-6man-ioam-ipv6-deploy= ment-00 feedback (Re: v6 option types for IOAM data fields) > =E6=97=B6=E9=97=B4=EF=BC=9A 2019-04-05 03:18:26 > > Hi Shuping, > I think that the question is whether we design for the lowest capable sol= utions. I assume someone can find solutions with even lower amount of parsi= ng.. The low end solutions for these capabilities may need to either adopt = with new designs or use solutions such as what is suggested in this thread = by Tom Herbert. > Personally, I don't think we should go this way, but to design appropriat= e solutions, with appropriate layers in the headers. For example, prevent d= ependencies between "remote" headers. > > Thanks, > Barak > > -----Original Message----- > From: ippm On Behalf Of Pengshuping (Peng Shuping= ) > Sent: Wednesday, April 3, 2019 6:47 AM > To: Frank Brockners (fbrockne) ; Mikael Abrahamsson <= swmike@swm.pp.se> > Cc: C. M. Heard ; 6man WG ; Mark Smith ; ippm@ietf.org > Subject: [ippm] =E7=AD=94=E5=A4=8D: draft-ioametal-ippm-6man-ioam-ipv6-de= ployment-00 feedback (Re: v6 option types for IOAM data fields) > > Hi, > > The parsing depth of the early chips is 96B/128B. For the new chips the p= arsing depth has been increased but still limited. So Mikael's concern make= s sense especially in the tracing mode that the IOAM data fields are going = to increase significantly along the path, which will even push the Routing = Header out of the parsing depth of the chip. So it would make sense to spli= t the IOAM data part from the IOAM header/instruction part, and place the I= OAM data after the RH or even after the L4 header in order to be able to re= ad the L4 information to enable ECMP, as stated in the draft https://eur03.= safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml= %2Fdraft-li-6man-ipv6-sfc-ifit-00&data=3D02%7C01%7Cgbarak%40mellanox.co= m%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0= %7C0%7C636898960379485833&sdata=3DDob4zN%2F1jSGxLTlqGma29JJNvqJDBt4VzqH= sN4OpxM4%3D&reserved=3D0. > > BR, > Shuping > > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: ippm [mailto:ippm-bounces@ietf.org] =E4=BB= =A3=E8=A1=A8 Frank Brockners (fbrockne) > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B44=E6=9C=882=E6=97=A5 1= 7:40 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Mikael Abrahamsson > =E6=8A=84=E9=80=81: C. M. Heard ; 6man WG ; Mark Smith ; ippm@ietf.org > =E4=B8=BB=E9=A2=98: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deploym= ent-00 feedback (Re: v6 option types for IOAM data fields) > > > > -----Original Message----- > From: Mikael Abrahamsson > Sent: Dienstag, 2. April 2019 08:06 > To: Frank Brockners (fbrockne) > Cc: Mark Smith ; C. M. Heard ; 6= man WG ; ippm@ietf.org > Subject: RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (R= e: v6 option types for IOAM data fields) > > On Mon, 1 Apr 2019, Frank Brockners (fbrockne) wrote: > > > ...FB: There is obviously no easy answer. Couple of thoughts: > > * IOAM is considered a "domain specific" feature (see > > draft-ietf-ippm-ioam-data-05, section 3). Routers in the IOAM domain > > should be IOAM capable. And IMHO, we should add a statement to > > draft-ioametal-ippm-6man-ioam-ipv6-deployment that an implementation > > of IOAM MUST ensure "C1". > > > > * That said, there can be situations, where C1 cannot be achieved, e.g.= . > > consider a network which does ECMP scheduling based on packet length. > > > > * What one could consider - and which is one suggested deployment > > model > > - is that by default IOAM data fields are added to _all_ customer > > packets. The decapsulating node would decide whether the IOAM > > information contained in a packet would be used (and exported) or not. > > That way one would not need to deal with the situation that some > > traffic carries IOAM while other does not - and might thus be treated > > differently. > > Yes, I think this is the only way. Is there a risk that intermediate rout= ers would not be IOAM capable? I think the C1 requirement is really really = hard to fulfil and I'm also afraid that adding the IOAM header will actuall= y make ECMP stop working on some platforms (because they would not have the= capability to look deep enough into the packet to find L4 information, so = it'll go back to 2 tuple ECMP instead of 5 tuple. > > But this question can only be answered by people with deep NPU knowledge.= .. > > .....FB2: Given that IOAM is a domain specific feature - I expect that fo= lks initially start to use it in domains (like e.g. a DC) where all boxes a= re IOAM capable and can trace the packet appropriately - or per Tom's note,= can be configured so that one would do ECMP based on addresses and flow-la= bel. There are chips with pretty deep parsing capability (up to a few hund= red bytes). > > > ...FB: The comparison to MPLS is interesting. How often do MPLS > > packets leak and cause harm? For IOAM, > > draft-ioametal-ippm-6man-ioam-ipv6-options-02 proposes a deployment > > model similar to what we do for MPLS: Unless an interface is > > explicitly configured for IOAM, packets with IOAM data fields MUST be d= ropped. > > Hence leakage would only occur, if we have a clearly misbehaving > > router which violates this rule. Similar to you, I'd also greatly > > appreciate any pointers to research on how common MPLS leaked packets a= re. > > When it comes to "cause harm" I imagine there are (at least) two ways to = cause harm, one is privacy/secrecy/security loss and the other one is actua= l operational loss. > > I know of bugs where labeled packets went the wrong way and caused them t= o be lost, I've also seen bugs where bugs caused traffic to "hop" between V= RFs in MPLS VPN (or to "global" VRF). I don't have numbers on this though. > > Depending on the deployment scenario, it might make sense to make IOAM pa= ckets not valid for non-IOAM aware devices (basically encap entire packet/p= ayload), but that might be a problem for intermediate non-IOAM nodes then. = This would affect the ECMP requirement. I can see cases where one would ope= rationally turn on IOAM for some customers traffic and then see the problem= go away because now ECMP changed. > > > ...FB: One idea that Shwetha came up with to identify the source AS of > > a leaked packet, would be to add a new new IOAM E2E option - as > > proposed in section 5.1.1 bullet 2 of > > draft-ioametal-ippm-6man-ioam-ipv6-deployment-01. > > Yes, that'd solve that problem. > > How much has the silicon people been involved so far in the design of the= headers? What is the current thinking of amount of data going into the IOA= M header? Considering things like trace options etc it seems to me the head= er can grow quite large? To satisfy the ECMP requirement what about putting= the IOAM information as a trailer behind the regular payload? Or is there = a problem for the hw to manipulate information that far into the packet (I = also imagine this will considerably lower the forwarding performance of IOA= M packets on IOAM aware platforms). > > .....FB2: There are quite a few folks with hardware background that co-au= thor the IOAM drafts. Parsing capability differs between chips, as does the= ability to deal with new/flexible headers and the ability to modify data i= n the extension headers. So the unfortunate answer to that question is "it = depends" (what information do you gather, how large is your domain, what ar= e the capabilities of your hardware/software forwarder, etc.), but I do exp= ect that for specific deployment domains (e.g. DC, Enterprise) - but also f= or overlay networks / VPNs - we'll see an increasing amount of chips that a= re well suited for processing large extension header. > > Cheers, Frank > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cgbarak%40mellanox.= com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7= C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef3BJFz6AQNNAtk= gmAMDFKM%3D&reserved=3D0 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cgbarak%40mellanox.= com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7= C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef3BJFz6AQNNAtk= gmAMDFKM%3D&reserved=3D0 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Apr 5 10:55:33 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E181205CE for ; Fri, 5 Apr 2019 10:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.com 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 Ki0DwwKPeYWc for ; Fri, 5 Apr 2019 10:55:29 -0700 (PDT) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A399A1204AB for ; Fri, 5 Apr 2019 10:55:22 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id cv12so3408928plb.9 for ; Fri, 05 Apr 2019 10:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=8F2GOXQUblGdSv/6YuUuavgLggyJv+2NgTxSn/Fcbq8=; b=Pt8U45nwdKYGTDj+KjM4LiGZtBN/y0ak3xnV4QlOL63RoWNk68q7weHQ2h8vjKNtJf plPDNws1V0lj5lC9brIrFkygp6zfZRE8QwPKdk3/uVIkjbdB6FGfeAK8XCZ5wzfnTdWx KjkHF+4vVNiY86W2ReYh7hddP6cb/g/xj1xNY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=8F2GOXQUblGdSv/6YuUuavgLggyJv+2NgTxSn/Fcbq8=; b=CAthfUE9N8J5g9PnCZ4mMcTY12hzDPLgfsa1Tzp3cnAyG6JvnU0ozXDsZlDjTySeG8 zNk67LDHvi4rH4tR7rf92JTzqjZMgI1STEOtQF8FVKa+RMbslRBAFjebJDJmntCIV6zc mOISurEqPXRaI+v0RtT+OH8jSto7ymUvXFRPBPjAk4gPa8L6aepGeB6J85GQLwxjdIW/ 0IhM0ksSA0wcW89wGOZio2a5J8OiiPcRRL0XRdWGLkY3QdH0Nu3ffaeMdobWbCFTtMH6 11mz4DTxVm/T2r/UAQ/Iwm61KNFjtyQg/2qiNyvgEIvjDk7PJNzjq1hwWCq7SsNGMa4B gmJA== X-Gm-Message-State: APjAAAWozZc3mtJdkSCTXv6EHWbGEYbVl5wKf4aFtJxPF9KmIMIDMpXs vaYs2IGfiTBb/APlKgWoYqHsiQ== X-Google-Smtp-Source: APXvYqznqe23E1i/kl2TfGoSGONA79QOYocrXjJwiFL7Z8LgYipx43mL0TH37wD4w0q59NNQ9qdp7w== X-Received: by 2002:a17:902:d70c:: with SMTP id w12mr14521527ply.198.1554486921908; Fri, 05 Apr 2019 10:55:21 -0700 (PDT) Received: from [10.0.0.131] ([2601:641:c080:5dc3:8019:dddb:7be9:ce63]) by smtp.gmail.com with ESMTPSA id k124sm34289883pgc.65.2019.04.05.10.55.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Apr 2019 10:55:21 -0700 (PDT) User-Agent: Microsoft-MacOutlook/10.17.1.190326 Date: Fri, 05 Apr 2019 10:55:20 -0700 From: Jai Kumar To: Tom Herbert , "Pengshuping (Peng Shuping)" CC: 6man WG , ippm , "C. M. Heard" , Mikael Abrahamsson Message-ID: <14A3D5C9-1EED-4E11-9329-B62B819271A2@broadcom.com> Thread-Topic: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> <4278D47A901B3041A737953BAA078ADE1478D5E2@DGGEML532-MBX.china.huawei.com> <4278D47A901B3041A737953BAA078ADE1478EC8B@DGGEML532-MBX.china.huawei.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 17:55:33 -0000 Even if we use flow label for ECMP, lack of accessibility of L4 information= (for various services, most simple is ACL) makes the proposal pretty much u= nusable. NIC cards are not used pervasively for ACLs and other services, I believe i= ptables in kernel are good enough for host but that=E2=80=99s not acceptable in ne= tworking elements. -Jai =EF=BB=BFOn 4/5/19, 10:31 AM, "ippm on behalf of Tom Herbert" wrote: On Fri, Apr 5, 2019 at 9:16 AM Pengshuping (Peng Shuping) wrote: > > Hi Barak, > > We are certainly not designing for the lowest capable solutions but e= xploring optimal solutions which could help to keep the forwarding performan= ce while inserting the iOAM data with variable length. =20 Shuping, =20 That's exactly the argument for using the flow label in ECMP. Efficeint packet forwarding can be done solely by inspected the forty byte fixed length header of the packet regardless of the contents of the rest of the packet. That is an optimal solution. Anything else for ECMP like doing DPI or hacking up IOAM to try do pull transport layers into the parsing buffer (whatever size that may be) are nothing more than hacks and unnecessarily perpetuate techniques used with IPv4 that either don't work or are unnecessary in IPv6. =20 Tom =20 =20 > > In terms of the forwarding efficiency, we would all agree that a shor= t and fixed header would be better than a variable header. > > Best regards > Shuping > > > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Barak Gafni > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Pengshuping (Peng Shuping);Frank= Brockners (fbrockne);Mikael Abrahamsson > =E6=8A=84=E9=80=81=EF=BC=9A C. M. Heard;6man WG;Mark Sm= ith;ippm > =E4=B8=BB=E9=A2=98=EF=BC=9A RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedba= ck (Re: v6 option types for IOAM data fields) > =E6=97=B6=E9=97=B4=EF=BC=9A 2019-04-05 03:18:26 > > Hi Shuping, > I think that the question is whether we design for the lowest capable= solutions. I assume someone can find solutions with even lower amount of pa= rsing.. The low end solutions for these capabilities may need to either adop= t with new designs or use solutions such as what is suggested in this thread= by Tom Herbert. > Personally, I don't think we should go this way, but to design approp= riate solutions, with appropriate layers in the headers. For example, preven= t dependencies between "remote" headers. > > Thanks, > Barak > > -----Original Message----- > From: ippm On Behalf Of Pengshuping (Peng Shu= ping) > Sent: Wednesday, April 3, 2019 6:47 AM > To: Frank Brockners (fbrockne) ; Mikael Abrahamss= on > Cc: C. M. Heard ; 6man WG ; Mark Smit= h ; ippm@ietf.org > Subject: [ippm] =E7=AD=94=E5=A4=8D: draft-ioametal-ippm-6man-ioam-ipv6-deployment= -00 feedback (Re: v6 option types for IOAM data fields) > > Hi, > > The parsing depth of the early chips is 96B/128B. For the new chips t= he parsing depth has been increased but still limited. So Mikael's concern m= akes sense especially in the tracing mode that the IOAM data fields are goin= g to increase significantly along the path, which will even push the Routing= Header out of the parsing depth of the chip. So it would make sense to spli= t the IOAM data part from the IOAM header/instruction part, and place the IO= AM data after the RH or even after the L4 header in order to be able to read= the L4 information to enable ECMP, as stated in the draft https://eur03.saf= elinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdra= ft-li-6man-ipv6-sfc-ifit-00&data=3D02%7C01%7Cgbarak%40mellanox.com%7C612ba= 6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636= 898960379485833&sdata=3DDob4zN%2F1jSGxLTlqGma29JJNvqJDBt4VzqHsN4OpxM4%3D&a= mp;reserved=3D0. > > BR, > Shuping > > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > =E5=8F=91=E4=BB=B6=E4=BA=BA: ippm [mailto:ippm-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Frank Brockners= (fbrockne) > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B44=E6=9C=882=E6=97=A5 17:40 > =E6=94=B6=E4=BB=B6=E4=BA=BA: Mikael Abrahamsson > =E6=8A=84=E9=80=81: C. M. Heard ; 6man WG ; Mark = Smith ; ippm@ietf.org > =E4=B8=BB=E9=A2=98: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 f= eedback (Re: v6 option types for IOAM data fields) > > > > -----Original Message----- > From: Mikael Abrahamsson > Sent: Dienstag, 2. April 2019 08:06 > To: Frank Brockners (fbrockne) > Cc: Mark Smith ; C. M. Heard ; 6man WG ; ippm@ietf.org > Subject: RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedbac= k (Re: v6 option types for IOAM data fields) > > On Mon, 1 Apr 2019, Frank Brockners (fbrockne) wrote: > > > ...FB: There is obviously no easy answer. Couple of thoughts: > > * IOAM is considered a "domain specific" feature (see > > draft-ietf-ippm-ioam-data-05, section 3). Routers in the IOAM domai= n > > should be IOAM capable. And IMHO, we should add a statement to > > draft-ioametal-ippm-6man-ioam-ipv6-deployment that an implementatio= n > > of IOAM MUST ensure "C1". > > > > * That said, there can be situations, where C1 cannot be achieved, = e.g.. > > consider a network which does ECMP scheduling based on packet lengt= h. > > > > * What one could consider - and which is one suggested deployment > > model > > - is that by default IOAM data fields are added to _all_ customer > > packets. The decapsulating node would decide whether the IOAM > > information contained in a packet would be used (and exported) or n= ot. > > That way one would not need to deal with the situation that some > > traffic carries IOAM while other does not - and might thus be treat= ed > > differently. > > Yes, I think this is the only way. Is there a risk that intermediate = routers would not be IOAM capable? I think the C1 requirement is really real= ly hard to fulfil and I'm also afraid that adding the IOAM header will actua= lly make ECMP stop working on some platforms (because they would not have th= e capability to look deep enough into the packet to find L4 information, so = it'll go back to 2 tuple ECMP instead of 5 tuple. > > But this question can only be answered by people with deep NPU knowle= dge... > > .....FB2: Given that IOAM is a domain specific feature - I expect tha= t folks initially start to use it in domains (like e.g. a DC) where all boxe= s are IOAM capable and can trace the packet appropriately - or per Tom's not= e, can be configured so that one would do ECMP based on addresses and flow-l= abel. There are chips with pretty deep parsing capability (up to a few hund= red bytes). > > > ...FB: The comparison to MPLS is interesting. How often do MPLS > > packets leak and cause harm? For IOAM, > > draft-ioametal-ippm-6man-ioam-ipv6-options-02 proposes a deployment > > model similar to what we do for MPLS: Unless an interface is > > explicitly configured for IOAM, packets with IOAM data fields MUST = be dropped. > > Hence leakage would only occur, if we have a clearly misbehaving > > router which violates this rule. Similar to you, I'd also greatly > > appreciate any pointers to research on how common MPLS leaked packe= ts are. > > When it comes to "cause harm" I imagine there are (at least) two ways= to cause harm, one is privacy/secrecy/security loss and the other one is ac= tual operational loss. > > I know of bugs where labeled packets went the wrong way and caused th= em to be lost, I've also seen bugs where bugs caused traffic to "hop" betwee= n VRFs in MPLS VPN (or to "global" VRF). I don't have numbers on this though= . > > Depending on the deployment scenario, it might make sense to make IOA= M packets not valid for non-IOAM aware devices (basically encap entire packe= t/payload), but that might be a problem for intermediate non-IOAM nodes then= . This would affect the ECMP requirement. I can see cases where one would op= erationally turn on IOAM for some customers traffic and then see the problem= go away because now ECMP changed. > > > ...FB: One idea that Shwetha came up with to identify the source AS= of > > a leaked packet, would be to add a new new IOAM E2E option - as > > proposed in section 5.1.1 bullet 2 of > > draft-ioametal-ippm-6man-ioam-ipv6-deployment-01. > > Yes, that'd solve that problem. > > How much has the silicon people been involved so far in the design of= the headers? What is the current thinking of amount of data going into the = IOAM header? Considering things like trace options etc it seems to me the he= ader can grow quite large? To satisfy the ECMP requirement what about puttin= g the IOAM information as a trailer behind the regular payload? Or is there = a problem for the hw to manipulate information that far into the packet (I a= lso imagine this will considerably lower the forwarding performance of IOAM = packets on IOAM aware platforms). > > .....FB2: There are quite a few folks with hardware background that c= o-author the IOAM drafts. Parsing capability differs between chips, as does = the ability to deal with new/flexible headers and the ability to modify data= in the extension headers. So the unfortunate answer to that question is "it= depends" (what information do you gather, how large is your domain, what ar= e the capabilities of your hardware/software forwarder, etc.), but I do expe= ct that for specific deployment domains (e.g. DC, Enterprise) - but also for= overlay networks / VPNs - we'll see an increasing amount of chips that are = well suited for processing large extension header. > > Cheers, Frank > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= .ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cgbarak%40mellanox.c= om%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0= %7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef3BJFz6AQNNAtkgmAMD= FKM%3D&reserved=3D0 > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= .ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cgbarak%40mellanox.c= om%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0= %7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef3BJFz6AQNNAtkgmAMD= FKM%3D&reserved=3D0 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- =20 _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm =20 From nobody Fri Apr 5 11:15:59 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 200E31205CE for ; Fri, 5 Apr 2019 11:15:50 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 NHXFaSBbiUAt for ; Fri, 5 Apr 2019 11:15:46 -0700 (PDT) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C3571205D2 for ; Fri, 5 Apr 2019 11:15:46 -0700 (PDT) Received: by mail-qt1-x841.google.com with SMTP id s15so119966qtn.3 for ; Fri, 05 Apr 2019 11:15:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=BOt/fXSTLa9xc3S1E4FP/kUsKbUwMPTZ75o7h7fmcHY=; b=raBud9Zca9vEWUQBY29RIYUfWkclImmW9cs0sk+c9fz6FSoAG/iUJTUOq0T60YJGgr bL6Z0F+loSe83i13nILr4j1aoc/bsVLxYYjDd8iPnzyAbd4U2p/7D2BDL6c2uXu4Lhwd nwO1zfmbogvRzb1WJsvmV9thQWG0Mph37aNVZVPK6f7mXFU+TA29dCJkMGx3Hl++i7zW WIbINeK6ajWXEZoT0+jZOKSfDblUJW57BD0vJjsYbrYC0wmhhkA2lzo07rQ4G+v785JE EyHO3TYmfbeNrApCHMgAnotv0xSiwq4c6MxTmvYUKKVOMHOtAyjO85rdC2UmxlXuNqXs zg6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=BOt/fXSTLa9xc3S1E4FP/kUsKbUwMPTZ75o7h7fmcHY=; b=Uxk5InRncxAsRUWpGO390aOaTa+43CqQ/c5D8UPUw90aGOvieD05QIaF8+PfTdSuAa BMitF5Ui3ElVOxzXh6G8fK4bfAr0lm05wCM12Jklk9w9wb/1YjllKQ2KKMuRSvSvqKUB U0KYavYbqBfOwkgjHZyKzEp3Eqf8sunWEAOq6HoqClC3F+wS4ytop3+LLIzAelbUNFSJ y1EUUB7DJe4MV7I6akvy28NwmwCwJ87i/Qdty7T7KzXl2ZEeRxetISHtDtu2/vOQII7i 04YadCzyYeswi1FsffRTLP3e/1AFweSm2J8QzGSMq1CjVz6314mX/U9A4nGpy225gc6P ugdg== X-Gm-Message-State: APjAAAXLystuUlG9vsp5+pHamgTkfohnoxPzlwRNRw5s8iHIE8FnfXXs S5EidBvAzoC1fvGkyijxtEgpJoohAusyihBZ6Eekqg== X-Google-Smtp-Source: APXvYqxaD645jVXPtid1SOpTp2NrjMbt882VZAyuzD/0gxTFoFYwG6J0FOs6a20yfDgDvDujBguQA8RTBMnmMCtySj8= X-Received: by 2002:ac8:3782:: with SMTP id d2mr12075878qtc.170.1554488144937; Fri, 05 Apr 2019 11:15:44 -0700 (PDT) MIME-Version: 1.0 References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> <4278D47A901B3041A737953BAA078ADE1478D5E2@DGGEML532-MBX.china.huawei.com> <4278D47A901B3041A737953BAA078ADE1478EC8B@DGGEML532-MBX.china.huawei.com> <14A3D5C9-1EED-4E11-9329-B62B819271A2@broadcom.com> In-Reply-To: <14A3D5C9-1EED-4E11-9329-B62B819271A2@broadcom.com> From: Tom Herbert Date: Fri, 5 Apr 2019 11:15:34 -0700 Message-ID: To: Jai Kumar Cc: "Pengshuping (Peng Shuping)" , 6man WG , ippm , "C. M. Heard" , Mikael Abrahamsson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 18:15:50 -0000 On Fri, Apr 5, 2019 at 10:55 AM Jai Kumar wrote: > > Even if we use flow label for ECMP, lack of accessibility of L4 informati= on (for various services, most simple is ACL) makes the proposal pretty muc= h unusable. > That is convoluting router and firewall functionality and requirements. This a discussion about packet forwarding which does _not_ require ACLs. In a limited domain, for which IOAM is intended, it is unlikely that they'll ACLs would be used in internal nodes, but we do need good ECMP routing at all intermediate nodes need to be consistent rather or not that the IOAM option is present. As side note, the ability to extract L4 information out of packets is dwindling anyway thanks to encryption and other techniques trying to undo protocol ossification. For instance, good luck getting L4 information out of an IPsec tunnel :-). Tom > NIC cards are not used pervasively for ACLs and other services, I believe= iptables in kernel are good enough for host but that=E2=80=99s not accepta= ble in networking elements. > > -Jai > > =EF=BB=BFOn 4/5/19, 10:31 AM, "ippm on behalf of Tom Herbert" wrote: > > On Fri, Apr 5, 2019 at 9:16 AM Pengshuping (Peng Shuping) > wrote: > > > > Hi Barak, > > > > We are certainly not designing for the lowest capable solutions but= exploring optimal solutions which could help to keep the forwarding perfor= mance while inserting the iOAM data with variable length. > > Shuping, > > That's exactly the argument for using the flow label in ECMP. > Efficeint packet forwarding can be done solely by inspected the forty > byte fixed length header of the packet regardless of the contents of > the rest of the packet. That is an optimal solution. Anything else fo= r > ECMP like doing DPI or hacking up IOAM to try do pull transport layer= s > into the parsing buffer (whatever size that may be) are nothing more > than hacks and unnecessarily perpetuate techniques used with IPv4 tha= t > either don't work or are unnecessary in IPv6. > > Tom > > > > > > In terms of the forwarding efficiency, we would all agree that a sh= ort and fixed header would be better than a variable header. > > > > Best regards > > Shuping > > > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Barak Gafni > > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Pengshuping (Peng Shuping);Frank Brockners (fbrockne);Mikael = Abrahamsson > > =E6=8A=84=E9=80=81=EF=BC=9A C. M. Heard;6man WG;Mark Smith;ippm > > =E4=B8=BB=E9=A2=98=EF=BC=9A RE: draft-ioametal-ippm-6man-ioam-ipv6-= deployment-00 feedback (Re: v6 option types for IOAM data fields) > > =E6=97=B6=E9=97=B4=EF=BC=9A 2019-04-05 03:18:26 > > > > Hi Shuping, > > I think that the question is whether we design for the lowest capab= le solutions. I assume someone can find solutions with even lower amount of= parsing.. The low end solutions for these capabilities may need to either = adopt with new designs or use solutions such as what is suggested in this t= hread by Tom Herbert. > > Personally, I don't think we should go this way, but to design appr= opriate solutions, with appropriate layers in the headers. For example, pre= vent dependencies between "remote" headers. > > > > Thanks, > > Barak > > > > -----Original Message----- > > From: ippm On Behalf Of Pengshuping (Peng S= huping) > > Sent: Wednesday, April 3, 2019 6:47 AM > > To: Frank Brockners (fbrockne) ; Mikael Abraham= sson > > Cc: C. M. Heard ; 6man WG ; Mark Sm= ith ; ippm@ietf.org > > Subject: [ippm] =E7=AD=94=E5=A4=8D: draft-ioametal-ippm-6man-ioam-i= pv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) > > > > Hi, > > > > The parsing depth of the early chips is 96B/128B. For the new chips= the parsing depth has been increased but still limited. So Mikael's concer= n makes sense especially in the tracing mode that the IOAM data fields are = going to increase significantly along the path, which will even push the Ro= uting Header out of the parsing depth of the chip. So it would make sense t= o split the IOAM data part from the IOAM header/instruction part, and place= the IOAM data after the RH or even after the L4 header in order to be able= to read the L4 information to enable ECMP, as stated in the draft https://= eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.org%= 2Fhtml%2Fdraft-li-6man-ipv6-sfc-ifit-00&data=3D02%7C01%7Cgbarak%40mella= nox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f46= 1b%7C0%7C0%7C636898960379485833&sdata=3DDob4zN%2F1jSGxLTlqGma29JJNvqJDB= t4VzqHsN4OpxM4%3D&reserved=3D0. > > > > BR, > > Shuping > > > > > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > =E5=8F=91=E4=BB=B6=E4=BA=BA: ippm [mailto:ippm-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Frank Brockners (fbrockne) > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B44=E6=9C=882=E6= =97=A5 17:40 > > =E6=94=B6=E4=BB=B6=E4=BA=BA: Mikael Abrahamsson > > =E6=8A=84=E9=80=81: C. M. Heard ; 6man WG ; Mark Smith ; ippm@ietf.org > > =E4=B8=BB=E9=A2=98: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-d= eployment-00 feedback (Re: v6 option types for IOAM data fields) > > > > > > > > -----Original Message----- > > From: Mikael Abrahamsson > > Sent: Dienstag, 2. April 2019 08:06 > > To: Frank Brockners (fbrockne) > > Cc: Mark Smith ; C. M. Heard ; 6man WG ; ippm@ietf.org > > Subject: RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedb= ack (Re: v6 option types for IOAM data fields) > > > > On Mon, 1 Apr 2019, Frank Brockners (fbrockne) wrote: > > > > > ...FB: There is obviously no easy answer. Couple of thoughts: > > > * IOAM is considered a "domain specific" feature (see > > > draft-ietf-ippm-ioam-data-05, section 3). Routers in the IOAM dom= ain > > > should be IOAM capable. And IMHO, we should add a statement to > > > draft-ioametal-ippm-6man-ioam-ipv6-deployment that an implementat= ion > > > of IOAM MUST ensure "C1". > > > > > > * That said, there can be situations, where C1 cannot be achieved= , e.g.. > > > consider a network which does ECMP scheduling based on packet len= gth. > > > > > > * What one could consider - and which is one suggested deployment > > > model > > > - is that by default IOAM data fields are added to _all_ customer > > > packets. The decapsulating node would decide whether the IOAM > > > information contained in a packet would be used (and exported) or= not. > > > That way one would not need to deal with the situation that some > > > traffic carries IOAM while other does not - and might thus be tre= ated > > > differently. > > > > Yes, I think this is the only way. Is there a risk that intermediat= e routers would not be IOAM capable? I think the C1 requirement is really r= eally hard to fulfil and I'm also afraid that adding the IOAM header will a= ctually make ECMP stop working on some platforms (because they would not ha= ve the capability to look deep enough into the packet to find L4 informatio= n, so it'll go back to 2 tuple ECMP instead of 5 tuple. > > > > But this question can only be answered by people with deep NPU know= ledge... > > > > .....FB2: Given that IOAM is a domain specific feature - I expect t= hat folks initially start to use it in domains (like e.g. a DC) where all b= oxes are IOAM capable and can trace the packet appropriately - or per Tom's= note, can be configured so that one would do ECMP based on addresses and f= low-label. There are chips with pretty deep parsing capability (up to a fe= w hundred bytes). > > > > > ...FB: The comparison to MPLS is interesting. How often do MPLS > > > packets leak and cause harm? For IOAM, > > > draft-ioametal-ippm-6man-ioam-ipv6-options-02 proposes a deployme= nt > > > model similar to what we do for MPLS: Unless an interface is > > > explicitly configured for IOAM, packets with IOAM data fields MUS= T be dropped. > > > Hence leakage would only occur, if we have a clearly misbehaving > > > router which violates this rule. Similar to you, I'd also greatly > > > appreciate any pointers to research on how common MPLS leaked pac= kets are. > > > > When it comes to "cause harm" I imagine there are (at least) two wa= ys to cause harm, one is privacy/secrecy/security loss and the other one is= actual operational loss. > > > > I know of bugs where labeled packets went the wrong way and caused = them to be lost, I've also seen bugs where bugs caused traffic to "hop" bet= ween VRFs in MPLS VPN (or to "global" VRF). I don't have numbers on this th= ough. > > > > Depending on the deployment scenario, it might make sense to make I= OAM packets not valid for non-IOAM aware devices (basically encap entire pa= cket/payload), but that might be a problem for intermediate non-IOAM nodes = then. This would affect the ECMP requirement. I can see cases where one wou= ld operationally turn on IOAM for some customers traffic and then see the p= roblem go away because now ECMP changed. > > > > > ...FB: One idea that Shwetha came up with to identify the source = AS of > > > a leaked packet, would be to add a new new IOAM E2E option - as > > > proposed in section 5.1.1 bullet 2 of > > > draft-ioametal-ippm-6man-ioam-ipv6-deployment-01. > > > > Yes, that'd solve that problem. > > > > How much has the silicon people been involved so far in the design = of the headers? What is the current thinking of amount of data going into t= he IOAM header? Considering things like trace options etc it seems to me th= e header can grow quite large? To satisfy the ECMP requirement what about p= utting the IOAM information as a trailer behind the regular payload? Or is = there a problem for the hw to manipulate information that far into the pack= et (I also imagine this will considerably lower the forwarding performance = of IOAM packets on IOAM aware platforms). > > > > .....FB2: There are quite a few folks with hardware background that= co-author the IOAM drafts. Parsing capability differs between chips, as do= es the ability to deal with new/flexible headers and the ability to modify = data in the extension headers. So the unfortunate answer to that question i= s "it depends" (what information do you gather, how large is your domain, w= hat are the capabilities of your hardware/software forwarder, etc.), but I = do expect that for specific deployment domains (e.g. DC, Enterprise) - but = also for overlay networks / VPNs - we'll see an increasing amount of chips = that are well suited for processing large extension header. > > > > Cheers, Frank > > > > -- > > Mikael Abrahamsson email: swmike@swm.pp.se > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cgbarak%40mel= lanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f= 461b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef3BJFz6A= QNNAtkgmAMDFKM%3D&reserved=3D0 > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cgbarak%40mel= lanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f= 461b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef3BJFz6A= QNNAtkgmAMDFKM%3D&reserved=3D0 > > -------------------------------------------------------------------= - > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------= - > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > > From nobody Fri Apr 5 11:26:06 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A5912008D for ; Fri, 5 Apr 2019 11:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.com 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 HQ4GccQLavH9 for ; Fri, 5 Apr 2019 11:25:55 -0700 (PDT) Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E265F120112 for ; Fri, 5 Apr 2019 11:25:54 -0700 (PDT) Received: by mail-pf1-x443.google.com with SMTP id 8so3727290pfr.4 for ; Fri, 05 Apr 2019 11:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=LSSb4fSC5P9oo9juNRRIdOzx07Vww9YOAtNE8vGg/QQ=; b=hK67FkrBN+/HNfCIr1qmPtwWBdKtaJnk7/AqrbL4YpNRYG5MeELLBSncY6S4hAsrEx u0imVOFcZMChD5AjnGMchc5/W3LLzLT/6D0ivtKH70mfQgRoChed3+iOggtec42PqvY8 NBkl5vCEeQyct207VfwVOcXeH7I0DgDiX6ZPw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=LSSb4fSC5P9oo9juNRRIdOzx07Vww9YOAtNE8vGg/QQ=; b=sGmSDiB2dyCl7iF+Ix1XX8557hCzene06jCMQ5YC4R5JezNzgxjSV1h/+ZAIXx5Mkn j1RhtQUwd8AF8gaT+7G9sqTHdNiAyj2Q9QWneXXzrs6G2LGSlArLRXNTyylcEw/+v1i8 SMWcm0w065cQp/b2fETmCZvUgRCQuDcINq5b/6RuVxQJSLDCJNuzsLqnS+VjwM+pRN1p LiWKIe4AmpkkxxnccXaKgBmxnqF1mBhqRlKmQRnxXp/sYvqKve+KXFgaMW8nFAC6lZm7 ocT9JLVLHz3P1b6YRBe7BojEWTUvYAvxL3WTLO0OzKCIMV+ivNWACZEfq8dYV0ZMQ4zY UTag== X-Gm-Message-State: APjAAAUaTDclJoz53qK1UbHv8XmbpnhR2kb4OM7eTRMtlvyPjcWlQDNB oOcTZCSsSCqXyV2SxJkDlZ1KWQ== X-Google-Smtp-Source: APXvYqxFsq2/NpZwKW6uiM4GPI7hSNc60rzkOCda1VspciVtMPonCCD978MYvAlBd44iODLgv7CQhQ== X-Received: by 2002:aa7:8458:: with SMTP id r24mr13870554pfn.231.1554488754276; Fri, 05 Apr 2019 11:25:54 -0700 (PDT) Received: from [10.0.0.131] ([2601:641:c080:5dc3:8019:dddb:7be9:ce63]) by smtp.gmail.com with ESMTPSA id i3sm33669884pfa.90.2019.04.05.11.25.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Apr 2019 11:25:53 -0700 (PDT) User-Agent: Microsoft-MacOutlook/10.17.1.190326 Date: Fri, 05 Apr 2019 11:25:52 -0700 From: Jai Kumar To: Tom Herbert CC: "Pengshuping (Peng Shuping)" , 6man WG , ippm , "C. M. Heard" , Mikael Abrahamsson Message-ID: <20D6FCDB-3357-4728-BD52-8069C32F3CCA@broadcom.com> Thread-Topic: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> <4278D47A901B3041A737953BAA078ADE1478D5E2@DGGEML532-MBX.china.huawei.com> <4278D47A901B3041A737953BAA078ADE1478EC8B@DGGEML532-MBX.china.huawei.com> <14A3D5C9-1EED-4E11-9329-B62B819271A2@broadcom.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 18:25:59 -0000 Tom, I am speaking based on the actual deployment not based on if all the traffi= c is/will move to IPSec tunnel. I have 6 large customer deployments and one someone previously called as "Y= ahoo" who insist on visibility in L4 even for IOAM packets. I can quote you on that and lose my business :-) ECMP argument is weak as well as it works for IPv6 flow label. What about I= Pv4 TCP/UDP traffic which typically is 80% of the traffic in MSDC. If someone tells me that proposal will work only for my 20% of traffic then= again as I said before, they will lose my business :-) Regards, -Jai =EF=BB=BFOn 4/5/19, 11:15 AM, "Tom Herbert" wrote: On Fri, Apr 5, 2019 at 10:55 AM Jai Kumar wrot= e: > > Even if we use flow label for ECMP, lack of accessibility of L4 infor= mation (for various services, most simple is ACL) makes the proposal pretty = much unusable. > That is convoluting router and firewall functionality and requirements. This a discussion about packet forwarding which does _not_ require ACLs. In a limited domain, for which IOAM is intended, it is unlikely that they'll ACLs would be used in internal nodes, but we do need good ECMP routing at all intermediate nodes need to be consistent rather or not that the IOAM option is present. As side note, the ability to extract L4 information out of packets is dwindling anyway thanks to encryption and other techniques trying to undo protocol ossification. For instance, good luck getting L4 information out of an IPsec tunnel :-). =20 Tom =20 > NIC cards are not used pervasively for ACLs and other services, I bel= ieve iptables in kernel are good enough for host but that=E2=80=99s not acceptable= in networking elements. > > -Jai > > =EF=BB=BFOn 4/5/19, 10:31 AM, "ippm on behalf of Tom Herbert" wrote: > > On Fri, Apr 5, 2019 at 9:16 AM Pengshuping (Peng Shuping) > wrote: > > > > Hi Barak, > > > > We are certainly not designing for the lowest capable solutions= but exploring optimal solutions which could help to keep the forwarding per= formance while inserting the iOAM data with variable length. > > Shuping, > > That's exactly the argument for using the flow label in ECMP. > Efficeint packet forwarding can be done solely by inspected the f= orty > byte fixed length header of the packet regardless of the contents= of > the rest of the packet. That is an optimal solution. Anything els= e for > ECMP like doing DPI or hacking up IOAM to try do pull transport l= ayers > into the parsing buffer (whatever size that may be) are nothing m= ore > than hacks and unnecessarily perpetuate techniques used with IPv4= that > either don't work or are unnecessary in IPv6. > > Tom > > > > > > In terms of the forwarding efficiency, we would all agree that = a short and fixed header would be better than a variable header. > > > > Best regards > > Shuping > > > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Barak Gafni > > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Pengshuping (Peng Shuping)= ;Frank Brockners (fbrockne);Mikael Abrahamsson > > =E6=8A=84=E9=80=81=EF=BC=9A C. M. Heard;6man WG;M= ark Smith;ippm > > =E4=B8=BB=E9=A2=98=EF=BC=9A RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 = feedback (Re: v6 option types for IOAM data fields) > > =E6=97=B6=E9=97=B4=EF=BC=9A 2019-04-05 03:18:26 > > > > Hi Shuping, > > I think that the question is whether we design for the lowest c= apable solutions. I assume someone can find solutions with even lower amount= of parsing.. The low end solutions for these capabilities may need to eithe= r adopt with new designs or use solutions such as what is suggested in this = thread by Tom Herbert. > > Personally, I don't think we should go this way, but to design = appropriate solutions, with appropriate layers in the headers. For example, = prevent dependencies between "remote" headers. > > > > Thanks, > > Barak > > > > -----Original Message----- > > From: ippm On Behalf Of Pengshuping (Pe= ng Shuping) > > Sent: Wednesday, April 3, 2019 6:47 AM > > To: Frank Brockners (fbrockne) ; Mikael Abr= ahamsson > > Cc: C. M. Heard ; 6man WG ; Mar= k Smith ; ippm@ietf.org > > Subject: [ippm] =E7=AD=94=E5=A4=8D: draft-ioametal-ippm-6man-ioam-ipv6-depl= oyment-00 feedback (Re: v6 option types for IOAM data fields) > > > > Hi, > > > > The parsing depth of the early chips is 96B/128B. For the new c= hips the parsing depth has been increased but still limited. So Mikael's con= cern makes sense especially in the tracing mode that the IOAM data fields ar= e going to increase significantly along the path, which will even push the R= outing Header out of the parsing depth of the chip. So it would make sense t= o split the IOAM data part from the IOAM header/instruction part, and place = the IOAM data after the RH or even after the L4 header in order to be able t= o read the L4 information to enable ECMP, as stated in the draft https://eur= 03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml= %2Fdraft-li-6man-ipv6-sfc-ifit-00&data=3D02%7C01%7Cgbarak%40mellanox.com%7= C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0= %7C636898960379485833&sdata=3DDob4zN%2F1jSGxLTlqGma29JJNvqJDBt4VzqHsN4OpxM= 4%3D&reserved=3D0. > > > > BR, > > Shuping > > > > > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > =E5=8F=91=E4=BB=B6=E4=BA=BA: ippm [mailto:ippm-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Frank Bro= ckners (fbrockne) > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B44=E6=9C=882=E6=97=A5 17:40 > > =E6=94=B6=E4=BB=B6=E4=BA=BA: Mikael Abrahamsson > > =E6=8A=84=E9=80=81: C. M. Heard ; 6man WG ;= Mark Smith ; ippm@ietf.org > > =E4=B8=BB=E9=A2=98: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deploymen= t-00 feedback (Re: v6 option types for IOAM data fields) > > > > > > > > -----Original Message----- > > From: Mikael Abrahamsson > > Sent: Dienstag, 2. April 2019 08:06 > > To: Frank Brockners (fbrockne) > > Cc: Mark Smith ; C. M. Heard ; 6man WG ; ippm@ietf.org > > Subject: RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 f= eedback (Re: v6 option types for IOAM data fields) > > > > On Mon, 1 Apr 2019, Frank Brockners (fbrockne) wrote: > > > > > ...FB: There is obviously no easy answer. Couple of thoughts: > > > * IOAM is considered a "domain specific" feature (see > > > draft-ietf-ippm-ioam-data-05, section 3). Routers in the IOAM= domain > > > should be IOAM capable. And IMHO, we should add a statement= to > > > draft-ioametal-ippm-6man-ioam-ipv6-deployment that an impleme= ntation > > > of IOAM MUST ensure "C1". > > > > > > * That said, there can be situations, where C1 cannot be achi= eved, e.g.. > > > consider a network which does ECMP scheduling based on packet= length. > > > > > > * What one could consider - and which is one suggested deploy= ment > > > model > > > - is that by default IOAM data fields are added to _all_ cust= omer > > > packets. The decapsulating node would decide whether the IOAM > > > information contained in a packet would be used (and exported= ) or not. > > > That way one would not need to deal with the situation that s= ome > > > traffic carries IOAM while other does not - and might thus be= treated > > > differently. > > > > Yes, I think this is the only way. Is there a risk that interme= diate routers would not be IOAM capable? I think the C1 requirement is reall= y really hard to fulfil and I'm also afraid that adding the IOAM header will= actually make ECMP stop working on some platforms (because they would not h= ave the capability to look deep enough into the packet to find L4 informatio= n, so it'll go back to 2 tuple ECMP instead of 5 tuple. > > > > But this question can only be answered by people with deep NPU = knowledge... > > > > .....FB2: Given that IOAM is a domain specific feature - I expe= ct that folks initially start to use it in domains (like e.g. a DC) where al= l boxes are IOAM capable and can trace the packet appropriately - or per Tom= 's note, can be configured so that one would do ECMP based on addresses and = flow-label. There are chips with pretty deep parsing capability (up to a fe= w hundred bytes). > > > > > ...FB: The comparison to MPLS is interesting. How often do MP= LS > > > packets leak and cause harm? For IOAM, > > > draft-ioametal-ippm-6man-ioam-ipv6-options-02 proposes a depl= oyment > > > model similar to what we do for MPLS: Unless an interface is > > > explicitly configured for IOAM, packets with IOAM data fields= MUST be dropped. > > > Hence leakage would only occur, if we have a clearly misbehav= ing > > > router which violates this rule. Similar to you, I'd also gre= atly > > > appreciate any pointers to research on how common MPLS leaked= packets are. > > > > When it comes to "cause harm" I imagine there are (at least) tw= o ways to cause harm, one is privacy/secrecy/security loss and the other one= is actual operational loss. > > > > I know of bugs where labeled packets went the wrong way and cau= sed them to be lost, I've also seen bugs where bugs caused traffic to "hop" = between VRFs in MPLS VPN (or to "global" VRF). I don't have numbers on this = though. > > > > Depending on the deployment scenario, it might make sense to ma= ke IOAM packets not valid for non-IOAM aware devices (basically encap entire= packet/payload), but that might be a problem for intermediate non-IOAM node= s then. This would affect the ECMP requirement. I can see cases where one wo= uld operationally turn on IOAM for some customers traffic and then see the p= roblem go away because now ECMP changed. > > > > > ...FB: One idea that Shwetha came up with to identify the sou= rce AS of > > > a leaked packet, would be to add a new new IOAM E2E option - = as > > > proposed in section 5.1.1 bullet 2 of > > > draft-ioametal-ippm-6man-ioam-ipv6-deployment-01. > > > > Yes, that'd solve that problem. > > > > How much has the silicon people been involved so far in the des= ign of the headers? What is the current thinking of amount of data going int= o the IOAM header? Considering things like trace options etc it seems to me = the header can grow quite large? To satisfy the ECMP requirement what about = putting the IOAM information as a trailer behind the regular payload? Or is = there a problem for the hw to manipulate information that far into the packe= t (I also imagine this will considerably lower the forwarding performance of= IOAM packets on IOAM aware platforms). > > > > .....FB2: There are quite a few folks with hardware background = that co-author the IOAM drafts. Parsing capability differs between chips, as= does the ability to deal with new/flexible headers and the ability to modif= y data in the extension headers. So the unfortunate answer to that question = is "it depends" (what information do you gather, how large is your domain, w= hat are the capabilities of your hardware/software forwarder, etc.), but I d= o expect that for specific deployment domains (e.g. DC, Enterprise) - but al= so for overlay networks / VPNs - we'll see an increasing amount of chips tha= t are well suited for processing large extension header. > > > > Cheers, Frank > > > > -- > > Mikael Abrahamsson email: swmike@swm.pp.se > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cgbarak%40mell= anox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f46= 1b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef3BJFz6AQNNAt= kgmAMDFKM%3D&reserved=3D0 > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cgbarak%40mell= anox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f46= 1b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef3BJFz6AQNNAt= kgmAMDFKM%3D&reserved=3D0 > > ---------------------------------------------------------------= ----- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/= ipv6 > > ---------------------------------------------------------------= ----- > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > > > =20 From nobody Fri Apr 5 11:54:33 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0071B120073 for ; Fri, 5 Apr 2019 11:54:26 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 YHpFSDK-aT56 for ; Fri, 5 Apr 2019 11:54:22 -0700 (PDT) Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04BA012008D for ; Fri, 5 Apr 2019 11:54:22 -0700 (PDT) Received: by mail-qk1-x744.google.com with SMTP id c189so4452720qke.6 for ; Fri, 05 Apr 2019 11:54:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rECVIljr0it4e4zPujMVIEIZu1b6a/2MkGwBSwcxhxI=; b=iwKmPoDDfDXnbOBKjumV8Rz56aMuW0cdLJ/zwWVkEplqfe1fOtfK69wjiVnWWeJLjj 7YBEmSjfgPuFVm6obrmXMxD+bWez6tORN8f2krtR3aEOfdkJEYun9n8fP1FZ23RixMgr a2gv+4PBxguOjnomBK0DMYh5XXlapcIs1V51vBjDexwUHmGFg7DkjtZVKN62k/I+DEdn k4suKHf55gnq9qdO9eQGlhCwiDi7j5JClfAsMLy+4l9GV+Z2JX5u2OwfiyMSY+hXHVpE kDucrsyScZ9NHfady0Py09Te9yuVjBuXqiKORzhSnmTlGeDfUb0hwd0sMo05eqQWudr5 RwtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rECVIljr0it4e4zPujMVIEIZu1b6a/2MkGwBSwcxhxI=; b=QrNerJF2fxUZ2onuNee0Mc8CJcZtby6gsqC6ixeqNHszxcE6xBOOIjSbWqCf12ksJ5 CFQx1LfI5XOdM+YABvirxvBSnLE+f5ePi2G2CgAG5xUeBUxHAOlTuW2jm+7GN8DfkkPK 7rybHUBG3FdaZej/XmRXtXEs4/uDvWbpZhc6G6/RY9TGrqOadmy6TzzWk+cCoaB/KV+g xddxaHC5jdOv72/LbJ6AoCsvX58+7ydTd5Wa2Sj0P94SuCNvj6bvIS7DGC+fzejJns8o uwvfkadkhmrLi+SuWwir/d2/lycW+pPf0p5Hf6JwDa/E5lU4ASBU6JkiorlfyDXbZyfF BKTQ== X-Gm-Message-State: APjAAAU4kj90WHclt+MrVK1m08IKo0VqQJXJ40EIkH22B0rnXXHgrulb 3Lu5JQd+QXxCbJ5zgnYDZz8qgi1nkbltL59Cp6PicQ== X-Google-Smtp-Source: APXvYqxVRb3gZX25oVRuDc+/csAkp3Oy8c2kex/4YST8NCqP+R7T7Zausma9jCAsNFJVfqUcpA4y8GooxSmMF5hfEF0= X-Received: by 2002:a37:aa8c:: with SMTP id t134mr11908760qke.93.1554490460775; Fri, 05 Apr 2019 11:54:20 -0700 (PDT) MIME-Version: 1.0 References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> <4278D47A901B3041A737953BAA078ADE1478D5E2@DGGEML532-MBX.china.huawei.com> <4278D47A901B3041A737953BAA078ADE1478EC8B@DGGEML532-MBX.china.huawei.com> <14A3D5C9-1EED-4E11-9329-B62B819271A2@broadcom.com> <20D6FCDB-3357-4728-BD52-8069C32F3CCA@broadcom.com> In-Reply-To: <20D6FCDB-3357-4728-BD52-8069C32F3CCA@broadcom.com> From: Tom Herbert Date: Fri, 5 Apr 2019 11:54:09 -0700 Message-ID: To: Jai Kumar Cc: "Pengshuping (Peng Shuping)" , 6man WG , ippm , "C. M. Heard" , Mikael Abrahamsson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 18:54:26 -0000 On Fri, Apr 5, 2019 at 11:25 AM Jai Kumar wrote: > > Tom, > > I am speaking based on the actual deployment not based on if all the traf= fic is/will move to IPSec tunnel. > > I have 6 large customer deployments and one someone previously called as = "Yahoo" who insist on visibility in L4 even for IOAM packets. > And I've worked in datcenters much larger, and my first rule is that I don't want random router vendors dictating to me what protocols I'm allowed to use in my datacenter. > I can quote you on that and lose my business :-) > > ECMP argument is weak as well as it works for IPv6 flow label. What about= IPv4 TCP/UDP traffic which typically is 80% of the traffic in MSDC. > draft-herbert-ipv4-udpencap-eh-01 > If someone tells me that proposal will work only for my 20% of traffic th= en again as I said before, they will lose my business :-) > Great, but this IETF. Where are the protocol requirements? If you are saying that there are requirements for "visibility in L4" what are they? If you are saying that ACLs are now required for packet forwarding, where is that described? Is it a MUST that teh only transport protocols we're allowed to use are UDP or TCP? Are we allowed to use extension headers at all? I suppose fragmentation is right out... Are we violating the requirements if we encrypt the transport headers? If you say that we shouldn't send long headers because we'll overflow parsing buffers, then what is the limit? Please be SPECIFC in setting requirements; we are trying to build protocols that work and are interoperable and we need to get out of this morass of reverse engineering to discover the least common denominator. Tom > Regards, > -Jai > > =EF=BB=BFOn 4/5/19, 11:15 AM, "Tom Herbert" wrote: > > On Fri, Apr 5, 2019 at 10:55 AM Jai Kumar wr= ote: > > > > Even if we use flow label for ECMP, lack of accessibility of L4 inf= ormation (for various services, most simple is ACL) makes the proposal pret= ty much unusable. > > > That is convoluting router and firewall functionality and > requirements. This a discussion about packet forwarding which does > _not_ require ACLs. In a limited domain, for which IOAM is intended, > it is unlikely that they'll ACLs would be used in internal nodes, but > we do need good ECMP routing at all intermediate nodes need to be > consistent rather or not that the IOAM option is present. As side > note, the ability to extract L4 information out of packets is > dwindling anyway thanks to encryption and other techniques trying to > undo protocol ossification. For instance, good luck getting L4 > information out of an IPsec tunnel :-). > > Tom > > > NIC cards are not used pervasively for ACLs and other services, I b= elieve iptables in kernel are good enough for host but that=E2=80=99s not a= cceptable in networking elements. > > > > -Jai > > > > =EF=BB=BFOn 4/5/19, 10:31 AM, "ippm on behalf of Tom Herbert" wrote: > > > > On Fri, Apr 5, 2019 at 9:16 AM Pengshuping (Peng Shuping) > > wrote: > > > > > > Hi Barak, > > > > > > We are certainly not designing for the lowest capable solutio= ns but exploring optimal solutions which could help to keep the forwarding = performance while inserting the iOAM data with variable length. > > > > Shuping, > > > > That's exactly the argument for using the flow label in ECMP. > > Efficeint packet forwarding can be done solely by inspected the= forty > > byte fixed length header of the packet regardless of the conten= ts of > > the rest of the packet. That is an optimal solution. Anything e= lse for > > ECMP like doing DPI or hacking up IOAM to try do pull transport= layers > > into the parsing buffer (whatever size that may be) are nothing= more > > than hacks and unnecessarily perpetuate techniques used with IP= v4 that > > either don't work or are unnecessary in IPv6. > > > > Tom > > > > > > > > > > In terms of the forwarding efficiency, we would all agree tha= t a short and fixed header would be better than a variable header. > > > > > > Best regards > > > Shuping > > > > > > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Barak Gafni > > > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Pengshuping (Peng Shupin= g);Frank Brockners (fbrockne);M= ikael Abrahamsson > > > =E6=8A=84=E9=80=81=EF=BC=9A C. M. Heard;6man= WG;Mark Smith;ippm > > > =E4=B8=BB=E9=A2=98=EF=BC=9A RE: draft-ioametal-ippm-6man-ioam= -ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) > > > =E6=97=B6=E9=97=B4=EF=BC=9A 2019-04-05 03:18:26 > > > > > > Hi Shuping, > > > I think that the question is whether we design for the lowest= capable solutions. I assume someone can find solutions with even lower amo= unt of parsing.. The low end solutions for these capabilities may need to e= ither adopt with new designs or use solutions such as what is suggested in = this thread by Tom Herbert. > > > Personally, I don't think we should go this way, but to desig= n appropriate solutions, with appropriate layers in the headers. For exampl= e, prevent dependencies between "remote" headers. > > > > > > Thanks, > > > Barak > > > > > > -----Original Message----- > > > From: ippm On Behalf Of Pengshuping (= Peng Shuping) > > > Sent: Wednesday, April 3, 2019 6:47 AM > > > To: Frank Brockners (fbrockne) ; Mikael A= brahamsson > > > Cc: C. M. Heard ; 6man WG ; M= ark Smith ; ippm@ietf.org > > > Subject: [ippm] =E7=AD=94=E5=A4=8D: draft-ioametal-ippm-6man-= ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) > > > > > > Hi, > > > > > > The parsing depth of the early chips is 96B/128B. For the new= chips the parsing depth has been increased but still limited. So Mikael's = concern makes sense especially in the tracing mode that the IOAM data field= s are going to increase significantly along the path, which will even push = the Routing Header out of the parsing depth of the chip. So it would make s= ense to split the IOAM data part from the IOAM header/instruction part, and= place the IOAM data after the RH or even after the L4 header in order to b= e able to read the L4 information to enable ECMP, as stated in the draft ht= tps://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.iet= f.org%2Fhtml%2Fdraft-li-6man-ipv6-sfc-ifit-00&data=3D02%7C01%7Cgbarak%4= 0mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149= 256f461b%7C0%7C0%7C636898960379485833&sdata=3DDob4zN%2F1jSGxLTlqGma29JJ= NvqJDBt4VzqHsN4OpxM4%3D&reserved=3D0. > > > > > > BR, > > > Shuping > > > > > > > > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: ippm [mailto:ippm-bounces@ietf.o= rg] =E4=BB=A3=E8=A1=A8 Frank Brockners (fbrockne) > > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B44=E6=9C=88= 2=E6=97=A5 17:40 > > > =E6=94=B6=E4=BB=B6=E4=BA=BA: Mikael Abrahamsson > > > =E6=8A=84=E9=80=81: C. M. Heard ; 6man WG ; Mark Smith ; ippm@ietf.org > > > =E4=B8=BB=E9=A2=98: Re: [ippm] draft-ioametal-ippm-6man-ioam-= ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) > > > > > > > > > > > > -----Original Message----- > > > From: Mikael Abrahamsson > > > Sent: Dienstag, 2. April 2019 08:06 > > > To: Frank Brockners (fbrockne) > > > Cc: Mark Smith ; C. M. Heard ; 6man WG ; ippm@ietf.org > > > Subject: RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment-00= feedback (Re: v6 option types for IOAM data fields) > > > > > > On Mon, 1 Apr 2019, Frank Brockners (fbrockne) wrote: > > > > > > > ...FB: There is obviously no easy answer. Couple of thought= s: > > > > * IOAM is considered a "domain specific" feature (see > > > > draft-ietf-ippm-ioam-data-05, section 3). Routers in the IO= AM domain > > > > should be IOAM capable. And IMHO, we should add a stateme= nt to > > > > draft-ioametal-ippm-6man-ioam-ipv6-deployment that an imple= mentation > > > > of IOAM MUST ensure "C1". > > > > > > > > * That said, there can be situations, where C1 cannot be ac= hieved, e.g.. > > > > consider a network which does ECMP scheduling based on pack= et length. > > > > > > > > * What one could consider - and which is one suggested depl= oyment > > > > model > > > > - is that by default IOAM data fields are added to _all_ cu= stomer > > > > packets. The decapsulating node would decide whether the IO= AM > > > > information contained in a packet would be used (and export= ed) or not. > > > > That way one would not need to deal with the situation that= some > > > > traffic carries IOAM while other does not - and might thus = be treated > > > > differently. > > > > > > Yes, I think this is the only way. Is there a risk that inter= mediate routers would not be IOAM capable? I think the C1 requirement is re= ally really hard to fulfil and I'm also afraid that adding the IOAM header = will actually make ECMP stop working on some platforms (because they would = not have the capability to look deep enough into the packet to find L4 info= rmation, so it'll go back to 2 tuple ECMP instead of 5 tuple. > > > > > > But this question can only be answered by people with deep NP= U knowledge... > > > > > > .....FB2: Given that IOAM is a domain specific feature - I ex= pect that folks initially start to use it in domains (like e.g. a DC) where= all boxes are IOAM capable and can trace the packet appropriately - or per= Tom's note, can be configured so that one would do ECMP based on addresses= and flow-label. There are chips with pretty deep parsing capability (up t= o a few hundred bytes). > > > > > > > ...FB: The comparison to MPLS is interesting. How often do = MPLS > > > > packets leak and cause harm? For IOAM, > > > > draft-ioametal-ippm-6man-ioam-ipv6-options-02 proposes a de= ployment > > > > model similar to what we do for MPLS: Unless an interface i= s > > > > explicitly configured for IOAM, packets with IOAM data fiel= ds MUST be dropped. > > > > Hence leakage would only occur, if we have a clearly misbeh= aving > > > > router which violates this rule. Similar to you, I'd also g= reatly > > > > appreciate any pointers to research on how common MPLS leak= ed packets are. > > > > > > When it comes to "cause harm" I imagine there are (at least) = two ways to cause harm, one is privacy/secrecy/security loss and the other = one is actual operational loss. > > > > > > I know of bugs where labeled packets went the wrong way and c= aused them to be lost, I've also seen bugs where bugs caused traffic to "ho= p" between VRFs in MPLS VPN (or to "global" VRF). I don't have numbers on t= his though. > > > > > > Depending on the deployment scenario, it might make sense to = make IOAM packets not valid for non-IOAM aware devices (basically encap ent= ire packet/payload), but that might be a problem for intermediate non-IOAM = nodes then. This would affect the ECMP requirement. I can see cases where o= ne would operationally turn on IOAM for some customers traffic and then see= the problem go away because now ECMP changed. > > > > > > > ...FB: One idea that Shwetha came up with to identify the s= ource AS of > > > > a leaked packet, would be to add a new new IOAM E2E option = - as > > > > proposed in section 5.1.1 bullet 2 of > > > > draft-ioametal-ippm-6man-ioam-ipv6-deployment-01. > > > > > > Yes, that'd solve that problem. > > > > > > How much has the silicon people been involved so far in the d= esign of the headers? What is the current thinking of amount of data going = into the IOAM header? Considering things like trace options etc it seems to= me the header can grow quite large? To satisfy the ECMP requirement what a= bout putting the IOAM information as a trailer behind the regular payload? = Or is there a problem for the hw to manipulate information that far into th= e packet (I also imagine this will considerably lower the forwarding perfor= mance of IOAM packets on IOAM aware platforms). > > > > > > .....FB2: There are quite a few folks with hardware backgroun= d that co-author the IOAM drafts. Parsing capability differs between chips,= as does the ability to deal with new/flexible headers and the ability to m= odify data in the extension headers. So the unfortunate answer to that ques= tion is "it depends" (what information do you gather, how large is your dom= ain, what are the capabilities of your hardware/software forwarder, etc.), = but I do expect that for specific deployment domains (e.g. DC, Enterprise) = - but also for overlay networks / VPNs - we'll see an increasing amount of = chips that are well suited for processing large extension header. > > > > > > Cheers, Frank > > > > > > -- > > > Mikael Abrahamsson email: swmike@swm.pp.se > > > > > > _______________________________________________ > > > ippm mailing list > > > ippm@ietf.org > > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3= A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cgbarak= %40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d1= 49256f461b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef3= BJFz6AQNNAtkgmAMDFKM%3D&reserved=3D0 > > > _______________________________________________ > > > ippm mailing list > > > ippm@ietf.org > > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3= A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cgbarak= %40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d1= 49256f461b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef3= BJFz6AQNNAtkgmAMDFKM%3D&reserved=3D0 > > > -------------------------------------------------------------= ------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: https://www.ietf.org/mailman/listinf= o/ipv6 > > > -------------------------------------------------------------= ------- > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://www.ietf.org/mailman/listinfo/ippm > > > > > > > > > From nobody Fri Apr 5 12:03:52 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ACCE120602 for ; Fri, 5 Apr 2019 12:03:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.com 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 zKfet_m3NaTq for ; Fri, 5 Apr 2019 12:03:29 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 022B4120627 for ; Fri, 5 Apr 2019 12:03:25 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id t21so1453220pfh.2 for ; Fri, 05 Apr 2019 12:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=+nc0Hgn6Ur5x4MT4vEh4g0tbjBwsJJ2jCHnZOTknCPQ=; b=NCXr6R5xWZTN3qxN8b+6ZnwmnS6SKzj++ijf+n0F94lTFQA6I30ia9bxBhqsgvlem/ Rvyfmhcjr7uQ5Papv89Bss3pp/uWsZk7D84zsJ2v7d4yHYMzp4mEy0NVryJXahojQ/v+ g0MDbDuNjDImmsUpKXSUTvcRHQAw4zuCQUHdQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=+nc0Hgn6Ur5x4MT4vEh4g0tbjBwsJJ2jCHnZOTknCPQ=; b=F9mDzkR/371EYLVuuI93bLx9hRoBOIxPprIiPHUNQqr/nAbE3s5Sh6FAjgChI3WTBd 4r1FxG+aVZzjmx/28chZuIuHy/X+dHozBvVdcjj3Cf177YVDKiPGjnd3Z7HJoJ2S4Iik MfrzK4Cg2sG/HLJCxm5OQQToNJXNpbWuniaNvUwoLjW20xBjKbr5PngTQHFq/IMAlVFQ Xm9eiOCE0h/WDYYLT9yVMQSLehiuDAdz1XAXe5y3B8HhGSTxVTZXpZDbPn2PE6Zspn2t 5RCmmacYODINcBVet893+3JkMAgyPOqxx1Y51fZYH6yXrFHlos4+jNbabl3SF3DH14zz U6qA== X-Gm-Message-State: APjAAAW2VWfzp1BQTuuMn+q6UiZnLlt9mRJKKdNzqj+9pF7URlVvjFbp ADhOp9Zvz2ve+d6iS2zARXLvPg== X-Google-Smtp-Source: APXvYqwkARt26mox4vDvd/kUhlSQYvqnrOqR00ixz5MVinY62oQJXfaBzBFoguCaRQrhRKGAI8TSOg== X-Received: by 2002:a62:5ec2:: with SMTP id s185mr14192483pfb.16.1554491005058; Fri, 05 Apr 2019 12:03:25 -0700 (PDT) Received: from [10.0.0.131] ([2601:641:c080:5dc3:8019:dddb:7be9:ce63]) by smtp.gmail.com with ESMTPSA id q87sm36200654pfa.133.2019.04.05.12.03.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Apr 2019 12:03:24 -0700 (PDT) User-Agent: Microsoft-MacOutlook/10.17.1.190326 Date: Fri, 05 Apr 2019 12:03:22 -0700 From: Jai Kumar To: Tom Herbert CC: "Pengshuping (Peng Shuping)" , 6man WG , ippm , "C. M. Heard" , Mikael Abrahamsson Message-ID: Thread-Topic: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> <4278D47A901B3041A737953BAA078ADE1478D5E2@DGGEML532-MBX.china.huawei.com> <4278D47A901B3041A737953BAA078ADE1478EC8B@DGGEML532-MBX.china.huawei.com> <14A3D5C9-1EED-4E11-9329-B62B819271A2@broadcom.com> <20D6FCDB-3357-4728-BD52-8069C32F3CCA@broadcom.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 19:03:42 -0000 " Great, but this IETF" Does it mean that drafts have no relevance to deployment and actual adoptio= n. For all your queries please take a look at IFA draft. https://datatracker.ietf.org/doc/draft-kumar-ippm-ifa/ It handles IPv6, IPv4 TCP/UDP with altering the packet path (due to inserti= ng options and/or encaping them in GRE header) as well as IPSec AH/ESP/WESP = both tunnel and transport and guess what it is successfully deployed.=20 -Jai =EF=BB=BFOn 4/5/19, 11:54 AM, "Tom Herbert" wrote: On Fri, Apr 5, 2019 at 11:25 AM Jai Kumar wrot= e: > > Tom, > > I am speaking based on the actual deployment not based on if all the = traffic is/will move to IPSec tunnel. > > I have 6 large customer deployments and one someone previously called= as "Yahoo" who insist on visibility in L4 even for IOAM packets. > And I've worked in datcenters much larger, and my first rule is that I don't want random router vendors dictating to me what protocols I'm allowed to use in my datacenter. =20 > I can quote you on that and lose my business :-) > > ECMP argument is weak as well as it works for IPv6 flow label. What a= bout IPv4 TCP/UDP traffic which typically is 80% of the traffic in MSDC. > =20 draft-herbert-ipv4-udpencap-eh-01 =20 > If someone tells me that proposal will work only for my 20% of traffi= c then again as I said before, they will lose my business :-) > Great, but this IETF. Where are the protocol requirements? If you are saying that there are requirements for "visibility in L4" what are they? If you are saying that ACLs are now required for packet forwarding, where is that described? Is it a MUST that teh only transport protocols we're allowed to use are UDP or TCP? Are we allowed to use extension headers at all? I suppose fragmentation is right out... Are we violating the requirements if we encrypt the transport headers? If you say that we shouldn't send long headers because we'll overflow parsing buffers, then what is the limit? Please be SPECIFC in setting requirements; we are trying to build protocols that work and are interoperable and we need to get out of this morass of reverse engineering to discover the least common denominator. =20 Tom =20 > Regards, > -Jai > > =EF=BB=BFOn 4/5/19, 11:15 AM, "Tom Herbert" wrote: > > On Fri, Apr 5, 2019 at 10:55 AM Jai Kumar wrote: > > > > Even if we use flow label for ECMP, lack of accessibility of L4= information (for various services, most simple is ACL) makes the proposal p= retty much unusable. > > > That is convoluting router and firewall functionality and > requirements. This a discussion about packet forwarding which doe= s > _not_ require ACLs. In a limited domain, for which IOAM is intend= ed, > it is unlikely that they'll ACLs would be used in internal nodes,= but > we do need good ECMP routing at all intermediate nodes need to be > consistent rather or not that the IOAM option is present. As side > note, the ability to extract L4 information out of packets is > dwindling anyway thanks to encryption and other techniques trying= to > undo protocol ossification. For instance, good luck getting L4 > information out of an IPsec tunnel :-). > > Tom > > > NIC cards are not used pervasively for ACLs and other services,= I believe iptables in kernel are good enough for host but that=E2=80=99s not acce= ptable in networking elements. > > > > -Jai > > > > =EF=BB=BFOn 4/5/19, 10:31 AM, "ippm on behalf of Tom Herbert" wrote: > > > > On Fri, Apr 5, 2019 at 9:16 AM Pengshuping (Peng Shuping) > > wrote: > > > > > > Hi Barak, > > > > > > We are certainly not designing for the lowest capable sol= utions but exploring optimal solutions which could help to keep the forwardi= ng performance while inserting the iOAM data with variable length. > > > > Shuping, > > > > That's exactly the argument for using the flow label in ECM= P. > > Efficeint packet forwarding can be done solely by inspected= the forty > > byte fixed length header of the packet regardless of the co= ntents of > > the rest of the packet. That is an optimal solution. Anythi= ng else for > > ECMP like doing DPI or hacking up IOAM to try do pull trans= port layers > > into the parsing buffer (whatever size that may be) are not= hing more > > than hacks and unnecessarily perpetuate techniques used wit= h IPv4 that > > either don't work or are unnecessary in IPv6. > > > > Tom > > > > > > > > > > In terms of the forwarding efficiency, we would all agree= that a short and fixed header would be better than a variable header. > > > > > > Best regards > > > Shuping > > > > > > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Barak Gafni > > > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Pengshuping (Peng Shuping);Frank Brockners (fbrockne);Mikael Abrahamsson > > > =E6=8A=84=E9=80=81=EF=BC=9A C. M. Heard;6man WG;Mark Smith;ippm > > > =E4=B8=BB=E9=A2=98=EF=BC=9A RE: draft-ioametal-ippm-6man-ioam-ipv6-deployme= nt-00 feedback (Re: v6 option types for IOAM data fields) > > > =E6=97=B6=E9=97=B4=EF=BC=9A 2019-04-05 03:18:26 > > > > > > Hi Shuping, > > > I think that the question is whether we design for the lo= west capable solutions. I assume someone can find solutions with even lower = amount of parsing.. The low end solutions for these capabilities may need to= either adopt with new designs or use solutions such as what is suggested in= this thread by Tom Herbert. > > > Personally, I don't think we should go this way, but to d= esign appropriate solutions, with appropriate layers in the headers. For exa= mple, prevent dependencies between "remote" headers. > > > > > > Thanks, > > > Barak > > > > > > -----Original Message----- > > > From: ippm On Behalf Of Pengshupi= ng (Peng Shuping) > > > Sent: Wednesday, April 3, 2019 6:47 AM > > > To: Frank Brockners (fbrockne) ; Mika= el Abrahamsson > > > Cc: C. M. Heard ; 6man WG ; Mark Smith ; ippm@ietf.org > > > Subject: [ippm] =E7=AD=94=E5=A4=8D: draft-ioametal-ippm-6man-ioam-ipv= 6-deployment-00 feedback (Re: v6 option types for IOAM data fields) > > > > > > Hi, > > > > > > The parsing depth of the early chips is 96B/128B. For the= new chips the parsing depth has been increased but still limited. So Mikael= 's concern makes sense especially in the tracing mode that the IOAM data fie= lds are going to increase significantly along the path, which will even push= the Routing Header out of the parsing depth of the chip. So it would make s= ense to split the IOAM data part from the IOAM header/instruction part, and = place the IOAM data after the RH or even after the L4 header in order to be = able to read the L4 information to enable ECMP, as stated in the draft https= ://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.org%= 2Fhtml%2Fdraft-li-6man-ipv6-sfc-ifit-00&data=3D02%7C01%7Cgbarak%40mellanox= .com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7= C0%7C0%7C636898960379485833&sdata=3DDob4zN%2F1jSGxLTlqGma29JJNvqJDBt4VzqHs= N4OpxM4%3D&reserved=3D0. > > > > > > BR, > > > Shuping > > > > > > > > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: ippm [mailto:ippm-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Fra= nk Brockners (fbrockne) > > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B44=E6=9C=882=E6=97=A5 17:40 > > > =E6=94=B6=E4=BB=B6=E4=BA=BA: Mikael Abrahamsson > > > =E6=8A=84=E9=80=81: C. M. Heard ; 6man WG ; Mark Smith ; ippm@ietf.org > > > =E4=B8=BB=E9=A2=98: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-dep= loyment-00 feedback (Re: v6 option types for IOAM data fields) > > > > > > > > > > > > -----Original Message----- > > > From: Mikael Abrahamsson > > > Sent: Dienstag, 2. April 2019 08:06 > > > To: Frank Brockners (fbrockne) > > > Cc: Mark Smith ; C. M. Heard ; 6man WG ; ippm@ietf.org > > > Subject: RE: draft-ioametal-ippm-6man-ioam-ipv6-deploymen= t-00 feedback (Re: v6 option types for IOAM data fields) > > > > > > On Mon, 1 Apr 2019, Frank Brockners (fbrockne) wrote: > > > > > > > ...FB: There is obviously no easy answer. Couple of tho= ughts: > > > > * IOAM is considered a "domain specific" feature (see > > > > draft-ietf-ippm-ioam-data-05, section 3). Routers in th= e IOAM domain > > > > should be IOAM capable. And IMHO, we should add a sta= tement to > > > > draft-ioametal-ippm-6man-ioam-ipv6-deployment that an i= mplementation > > > > of IOAM MUST ensure "C1". > > > > > > > > * That said, there can be situations, where C1 cannot b= e achieved, e.g.. > > > > consider a network which does ECMP scheduling based on = packet length. > > > > > > > > * What one could consider - and which is one suggested = deployment > > > > model > > > > - is that by default IOAM data fields are added to _all= _ customer > > > > packets. The decapsulating node would decide whether th= e IOAM > > > > information contained in a packet would be used (and ex= ported) or not. > > > > That way one would not need to deal with the situation = that some > > > > traffic carries IOAM while other does not - and might t= hus be treated > > > > differently. > > > > > > Yes, I think this is the only way. Is there a risk that i= ntermediate routers would not be IOAM capable? I think the C1 requirement is= really really hard to fulfil and I'm also afraid that adding the IOAM heade= r will actually make ECMP stop working on some platforms (because they would= not have the capability to look deep enough into the packet to find L4 info= rmation, so it'll go back to 2 tuple ECMP instead of 5 tuple. > > > > > > But this question can only be answered by people with dee= p NPU knowledge... > > > > > > .....FB2: Given that IOAM is a domain specific feature - = I expect that folks initially start to use it in domains (like e.g. a DC) wh= ere all boxes are IOAM capable and can trace the packet appropriately - or p= er Tom's note, can be configured so that one would do ECMP based on addresse= s and flow-label. There are chips with pretty deep parsing capability (up t= o a few hundred bytes). > > > > > > > ...FB: The comparison to MPLS is interesting. How often= do MPLS > > > > packets leak and cause harm? For IOAM, > > > > draft-ioametal-ippm-6man-ioam-ipv6-options-02 proposes = a deployment > > > > model similar to what we do for MPLS: Unless an interfa= ce is > > > > explicitly configured for IOAM, packets with IOAM data = fields MUST be dropped. > > > > Hence leakage would only occur, if we have a clearly mi= sbehaving > > > > router which violates this rule. Similar to you, I'd al= so greatly > > > > appreciate any pointers to research on how common MPLS = leaked packets are. > > > > > > When it comes to "cause harm" I imagine there are (at lea= st) two ways to cause harm, one is privacy/secrecy/security loss and the oth= er one is actual operational loss. > > > > > > I know of bugs where labeled packets went the wrong way a= nd caused them to be lost, I've also seen bugs where bugs caused traffic to = "hop" between VRFs in MPLS VPN (or to "global" VRF). I don't have numbers on= this though. > > > > > > Depending on the deployment scenario, it might make sense= to make IOAM packets not valid for non-IOAM aware devices (basically encap = entire packet/payload), but that might be a problem for intermediate non-IOA= M nodes then. This would affect the ECMP requirement. I can see cases where = one would operationally turn on IOAM for some customers traffic and then see= the problem go away because now ECMP changed. > > > > > > > ...FB: One idea that Shwetha came up with to identify t= he source AS of > > > > a leaked packet, would be to add a new new IOAM E2E opt= ion - as > > > > proposed in section 5.1.1 bullet 2 of > > > > draft-ioametal-ippm-6man-ioam-ipv6-deployment-01. > > > > > > Yes, that'd solve that problem. > > > > > > How much has the silicon people been involved so far in t= he design of the headers? What is the current thinking of amount of data goi= ng into the IOAM header? Considering things like trace options etc it seems = to me the header can grow quite large? To satisfy the ECMP requirement what = about putting the IOAM information as a trailer behind the regular payload? = Or is there a problem for the hw to manipulate information that far into the= packet (I also imagine this will considerably lower the forwarding performa= nce of IOAM packets on IOAM aware platforms). > > > > > > .....FB2: There are quite a few folks with hardware backg= round that co-author the IOAM drafts. Parsing capability differs between chi= ps, as does the ability to deal with new/flexible headers and the ability to= modify data in the extension headers. So the unfortunate answer to that que= stion is "it depends" (what information do you gather, how large is your dom= ain, what are the capabilities of your hardware/software forwarder, etc.), b= ut I do expect that for specific deployment domains (e.g. DC, Enterprise) - = but also for overlay networks / VPNs - we'll see an increasing amount of chi= ps that are well suited for processing large extension header. > > > > > > Cheers, Frank > > > > > > -- > > > Mikael Abrahamsson email: swmike@swm.pp.se > > > > > > _______________________________________________ > > > ippm mailing list > > > ippm@ietf.org > > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cgbarak%= 40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149= 256f461b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef3BJFz6= AQNNAtkgmAMDFKM%3D&reserved=3D0 > > > _______________________________________________ > > > ippm mailing list > > > ippm@ietf.org > > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cgbarak%= 40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149= 256f461b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef3BJFz6= AQNNAtkgmAMDFKM%3D&reserved=3D0 > > > ---------------------------------------------------------= ----------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: https://www.ietf.org/mailman/lis= tinfo/ipv6 > > > ---------------------------------------------------------= ----------- > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://www.ietf.org/mailman/listinfo/ippm > > > > > > > > > =20 From nobody Fri Apr 5 12:06:41 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B61F1200C7 for ; Fri, 5 Apr 2019 12:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.com 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 83RAgRrr1Tji for ; Fri, 5 Apr 2019 12:06:36 -0700 (PDT) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D71C012009E for ; Fri, 5 Apr 2019 12:06:35 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id b65so3510341plb.6 for ; Fri, 05 Apr 2019 12:06:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=wI3VHrxZwLHnOl9Zl2P4SzXkLGGmUIr7IEV9+G/n5hU=; b=dQQKhMynVX0D4gXzVzrc8Ape68n4wxOHlzr6I6lsemRQGpXs3GcYdwWSRzI4SpuhM7 rT2D2UE7ZZGbpsfiHu2JUt8JNtgJAnkd3IJmqm1jnMYPPmHq5qAo7qLK9cVzvaJ2D2BZ dqYFuiZELE1PnrCJQ5EoSF+97IgjxRt9R5eQo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=wI3VHrxZwLHnOl9Zl2P4SzXkLGGmUIr7IEV9+G/n5hU=; b=dFMMQuLZTQrlWFORRflHW7ObIwmSNUKNxFF1JhsoxhP3JFYn+Z7UgDTBRxK6IkqP3Y IkuHKBFZ2/8iY0MYcChH9INCBdA4xxQz5NwItEpjordNVgiTSAWir8ZrCU6x+bL3Buya LpxcPp2BEMC6YptlhSgYr9kb9p7KYsm6KPZI+hc/C54Sfu9rcJlW/GEG9jzlc28BhA2K I95NwxV5Q4RGsPlZ7NnY4zvy3XlUXsVjYupEWsgkJCVEt5o9VP+EBHj+IQQK3WsGEoKX EsIzbh9nMK76fs+Azp9yEDiK6lL7T9JM10gmdUke7qR8VQbzYkC+BDxG9wmSYi8qwJrR MYyA== X-Gm-Message-State: APjAAAWVhtZwgrGZsUWHuXTrM/xH5eKCnWEKQ/9+aGKar8sE5d3+huel Z+YyqsgKuDrEtEISYrW5F/UX9A== X-Google-Smtp-Source: APXvYqz3Z5hAUeQoCzlyJygycQ9qWq8ZA+TR7GNrMbqcs62ATSrsgfi8n+KoKe5m7QjP5ICEA4u+bg== X-Received: by 2002:a17:902:20e3:: with SMTP id v32mr14158844plg.213.1554491195086; Fri, 05 Apr 2019 12:06:35 -0700 (PDT) Received: from [10.0.0.131] ([2601:641:c080:5dc3:8019:dddb:7be9:ce63]) by smtp.gmail.com with ESMTPSA id l5sm41571431pfi.97.2019.04.05.12.06.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Apr 2019 12:06:34 -0700 (PDT) User-Agent: Microsoft-MacOutlook/10.17.1.190326 Date: Fri, 05 Apr 2019 12:06:33 -0700 From: Jai Kumar To: Tom Herbert CC: "Pengshuping (Peng Shuping)" , 6man WG , ippm , "C. M. Heard" , Mikael Abrahamsson Message-ID: <008D22AF-744A-4317-9D5B-BD8722AD6BE4@broadcom.com> Thread-Topic: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> <4278D47A901B3041A737953BAA078ADE1478D5E2@DGGEML532-MBX.china.huawei.com> <4278D47A901B3041A737953BAA078ADE1478EC8B@DGGEML532-MBX.china.huawei.com> <14A3D5C9-1EED-4E11-9329-B62B819271A2@broadcom.com> <20D6FCDB-3357-4728-BD52-8069C32F3CCA@broadcom.com> <8761E476-9B73-41E0-A58F-589369689961@broadcom.com> In-Reply-To: <8761E476-9B73-41E0-A58F-589369689961@broadcom.com> Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 19:06:39 -0000 It handles IPv6, IPv4 TCP/UDP *without altering the packet path ... =EF=BB=BFOn 4/5/19, 12:03 PM, "Jai Kumar" wrote: " Great, but this IETF" Does it mean that drafts have no relevance to deployment and actual ado= ption. =20 For all your queries please take a look at IFA draft. https://datatracker.ietf.org/doc/draft-kumar-ippm-ifa/ =20 It handles IPv6, IPv4 TCP/UDP with altering the packet path (due to ins= erting options and/or encaping them in GRE header) as well as IPSec AH/ESP/W= ESP both tunnel and transport and guess what it is successfully deployed.=20 =20 -Jai =20 =EF=BB=BFOn 4/5/19, 11:54 AM, "Tom Herbert" wrote: =20 On Fri, Apr 5, 2019 at 11:25 AM Jai Kumar = wrote: > > Tom, > > I am speaking based on the actual deployment not based on if all = the traffic is/will move to IPSec tunnel. > > I have 6 large customer deployments and one someone previously ca= lled as "Yahoo" who insist on visibility in L4 even for IOAM packets. > And I've worked in datcenters much larger, and my first rule is tha= t I don't want random router vendors dictating to me what protocols I'm allowed to use in my datacenter. =20 > I can quote you on that and lose my business :-) > > ECMP argument is weak as well as it works for IPv6 flow label. Wh= at about IPv4 TCP/UDP traffic which typically is 80% of the traffic in MSDC. > =20 draft-herbert-ipv4-udpencap-eh-01 =20 > If someone tells me that proposal will work only for my 20% of tr= affic then again as I said before, they will lose my business :-) > Great, but this IETF. Where are the protocol requirements? If you a= re saying that there are requirements for "visibility in L4" what are they? If you are saying that ACLs are now required for packet forwarding, where is that described? Is it a MUST that teh only transport protocols we're allowed to use are UDP or TCP? Are we allowed to use extension headers at all? I suppose fragmentation is right out... Are we violating the requirements if we encrypt the transport headers? If you say that we shouldn't send long headers because we'll overflow parsing buffers, then what is the limit? Ple= ase be SPECIFC in setting requirements; we are trying to build protocol= s that work and are interoperable and we need to get out of this mora= ss of reverse engineering to discover the least common denominator. =20 Tom =20 > Regards, > -Jai > > =EF=BB=BFOn 4/5/19, 11:15 AM, "Tom Herbert" wrote= : > > On Fri, Apr 5, 2019 at 10:55 AM Jai Kumar wrote: > > > > Even if we use flow label for ECMP, lack of accessibility o= f L4 information (for various services, most simple is ACL) makes the propos= al pretty much unusable. > > > That is convoluting router and firewall functionality and > requirements. This a discussion about packet forwarding which= does > _not_ require ACLs. In a limited domain, for which IOAM is in= tended, > it is unlikely that they'll ACLs would be used in internal no= des, but > we do need good ECMP routing at all intermediate nodes need t= o be > consistent rather or not that the IOAM option is present. As = side > note, the ability to extract L4 information out of packets is > dwindling anyway thanks to encryption and other techniques tr= ying to > undo protocol ossification. For instance, good luck getting L= 4 > information out of an IPsec tunnel :-). > > Tom > > > NIC cards are not used pervasively for ACLs and other servi= ces, I believe iptables in kernel are good enough for host but that=E2=80=99s not = acceptable in networking elements. > > > > -Jai > > > > =EF=BB=BFOn 4/5/19, 10:31 AM, "ippm on behalf of Tom Herbert" wrote: > > > > On Fri, Apr 5, 2019 at 9:16 AM Pengshuping (Peng Shupin= g) > > wrote: > > > > > > Hi Barak, > > > > > > We are certainly not designing for the lowest capable= solutions but exploring optimal solutions which could help to keep the forw= arding performance while inserting the iOAM data with variable length. > > > > Shuping, > > > > That's exactly the argument for using the flow label in= ECMP. > > Efficeint packet forwarding can be done solely by inspe= cted the forty > > byte fixed length header of the packet regardless of th= e contents of > > the rest of the packet. That is an optimal solution. An= ything else for > > ECMP like doing DPI or hacking up IOAM to try do pull t= ransport layers > > into the parsing buffer (whatever size that may be) are= nothing more > > than hacks and unnecessarily perpetuate techniques used= with IPv4 that > > either don't work or are unnecessary in IPv6. > > > > Tom > > > > > > > > > > In terms of the forwarding efficiency, we would all a= gree that a short and fixed header would be better than a variable header. > > > > > > Best regards > > > Shuping > > > > > > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Barak Gafni > > > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Pengshuping (Peng Shuping);Frank Brockners (fbrockne);Mikael Abrahamsson= > > > =E6=8A=84=E9=80=81=EF=BC=9A C. M. Heard;6man WG;Mark Smith;ippm > > > =E4=B8=BB=E9=A2=98=EF=BC=9A RE: draft-ioametal-ippm-6man-ioam-ipv6-depl= oyment-00 feedback (Re: v6 option types for IOAM data fields) > > > =E6=97=B6=E9=97=B4=EF=BC=9A 2019-04-05 03:18:26 > > > > > > Hi Shuping, > > > I think that the question is whether we design for th= e lowest capable solutions. I assume someone can find solutions with even lo= wer amount of parsing.. The low end solutions for these capabilities may nee= d to either adopt with new designs or use solutions such as what is suggeste= d in this thread by Tom Herbert. > > > Personally, I don't think we should go this way, but = to design appropriate solutions, with appropriate layers in the headers. For= example, prevent dependencies between "remote" headers. > > > > > > Thanks, > > > Barak > > > > > > -----Original Message----- > > > From: ippm On Behalf Of Pengs= huping (Peng Shuping) > > > Sent: Wednesday, April 3, 2019 6:47 AM > > > To: Frank Brockners (fbrockne) ; = Mikael Abrahamsson > > > Cc: C. M. Heard ; 6man WG ; Mark Smith ; ippm@ietf.org > > > Subject: [ippm] =E7=AD=94=E5=A4=8D: draft-ioametal-ippm-6man-ioam= -ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) > > > > > > Hi, > > > > > > The parsing depth of the early chips is 96B/128B. For= the new chips the parsing depth has been increased but still limited. So Mi= kael's concern makes sense especially in the tracing mode that the IOAM data= fields are going to increase significantly along the path, which will even = push the Routing Header out of the parsing depth of the chip. So it would ma= ke sense to split the IOAM data part from the IOAM header/instruction part, = and place the IOAM data after the RH or even after the L4 header in order to= be able to read the L4 information to enable ECMP, as stated in the draft h= ttps://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.= org%2Fhtml%2Fdraft-li-6man-ipv6-sfc-ifit-00&data=3D02%7C01%7Cgbarak%40mell= anox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f46= 1b%7C0%7C0%7C636898960379485833&sdata=3DDob4zN%2F1jSGxLTlqGma29JJNvqJDBt4V= zqHsN4OpxM4%3D&reserved=3D0. > > > > > > BR, > > > Shuping > > > > > > > > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: ippm [mailto:ippm-bounces@ietf.org] =E4=BB=A3=E8=A1=A8= Frank Brockners (fbrockne) > > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B44=E6=9C=882=E6=97=A5 17:40 > > > =E6=94=B6=E4=BB=B6=E4=BA=BA: Mikael Abrahamsson > > > =E6=8A=84=E9=80=81: C. M. Heard ; 6man WG ; Mark Smith ; ippm@ietf.org > > > =E4=B8=BB=E9=A2=98: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6= -deployment-00 feedback (Re: v6 option types for IOAM data fields) > > > > > > > > > > > > -----Original Message----- > > > From: Mikael Abrahamsson > > > Sent: Dienstag, 2. April 2019 08:06 > > > To: Frank Brockners (fbrockne) > > > Cc: Mark Smith ; C. M. Heard = ; 6man WG ; ippm@ietf.org > > > Subject: RE: draft-ioametal-ippm-6man-ioam-ipv6-deplo= yment-00 feedback (Re: v6 option types for IOAM data fields) > > > > > > On Mon, 1 Apr 2019, Frank Brockners (fbrockne) wrote: > > > > > > > ...FB: There is obviously no easy answer. Couple of= thoughts: > > > > * IOAM is considered a "domain specific" feature (s= ee > > > > draft-ietf-ippm-ioam-data-05, section 3). Routers i= n the IOAM domain > > > > should be IOAM capable. And IMHO, we should add a= statement to > > > > draft-ioametal-ippm-6man-ioam-ipv6-deployment that = an implementation > > > > of IOAM MUST ensure "C1". > > > > > > > > * That said, there can be situations, where C1 cann= ot be achieved, e.g.. > > > > consider a network which does ECMP scheduling based= on packet length. > > > > > > > > * What one could consider - and which is one sugges= ted deployment > > > > model > > > > - is that by default IOAM data fields are added to = _all_ customer > > > > packets. The decapsulating node would decide whethe= r the IOAM > > > > information contained in a packet would be used (an= d exported) or not. > > > > That way one would not need to deal with the situat= ion that some > > > > traffic carries IOAM while other does not - and mig= ht thus be treated > > > > differently. > > > > > > Yes, I think this is the only way. Is there a risk th= at intermediate routers would not be IOAM capable? I think the C1 requiremen= t is really really hard to fulfil and I'm also afraid that adding the IOAM h= eader will actually make ECMP stop working on some platforms (because they w= ould not have the capability to look deep enough into the packet to find L4 = information, so it'll go back to 2 tuple ECMP instead of 5 tuple. > > > > > > But this question can only be answered by people with= deep NPU knowledge... > > > > > > .....FB2: Given that IOAM is a domain specific featur= e - I expect that folks initially start to use it in domains (like e.g. a DC= ) where all boxes are IOAM capable and can trace the packet appropriately - = or per Tom's note, can be configured so that one would do ECMP based on addr= esses and flow-label. There are chips with pretty deep parsing capability (= up to a few hundred bytes). > > > > > > > ...FB: The comparison to MPLS is interesting. How o= ften do MPLS > > > > packets leak and cause harm? For IOAM, > > > > draft-ioametal-ippm-6man-ioam-ipv6-options-02 propo= ses a deployment > > > > model similar to what we do for MPLS: Unless an int= erface is > > > > explicitly configured for IOAM, packets with IOAM d= ata fields MUST be dropped. > > > > Hence leakage would only occur, if we have a clearl= y misbehaving > > > > router which violates this rule. Similar to you, I'= d also greatly > > > > appreciate any pointers to research on how common M= PLS leaked packets are. > > > > > > When it comes to "cause harm" I imagine there are (at= least) two ways to cause harm, one is privacy/secrecy/security loss and the= other one is actual operational loss. > > > > > > I know of bugs where labeled packets went the wrong w= ay and caused them to be lost, I've also seen bugs where bugs caused traffic= to "hop" between VRFs in MPLS VPN (or to "global" VRF). I don't have number= s on this though. > > > > > > Depending on the deployment scenario, it might make s= ense to make IOAM packets not valid for non-IOAM aware devices (basically en= cap entire packet/payload), but that might be a problem for intermediate non= -IOAM nodes then. This would affect the ECMP requirement. I can see cases wh= ere one would operationally turn on IOAM for some customers traffic and then= see the problem go away because now ECMP changed. > > > > > > > ...FB: One idea that Shwetha came up with to identi= fy the source AS of > > > > a leaked packet, would be to add a new new IOAM E2E= option - as > > > > proposed in section 5.1.1 bullet 2 of > > > > draft-ioametal-ippm-6man-ioam-ipv6-deployment-01. > > > > > > Yes, that'd solve that problem. > > > > > > How much has the silicon people been involved so far = in the design of the headers? What is the current thinking of amount of data= going into the IOAM header? Considering things like trace options etc it se= ems to me the header can grow quite large? To satisfy the ECMP requirement w= hat about putting the IOAM information as a trailer behind the regular paylo= ad? Or is there a problem for the hw to manipulate information that far into= the packet (I also imagine this will considerably lower the forwarding perf= ormance of IOAM packets on IOAM aware platforms). > > > > > > .....FB2: There are quite a few folks with hardware b= ackground that co-author the IOAM drafts. Parsing capability differs between= chips, as does the ability to deal with new/flexible headers and the abilit= y to modify data in the extension headers. So the unfortunate answer to that= question is "it depends" (what information do you gather, how large is your= domain, what are the capabilities of your hardware/software forwarder, etc.= ), but I do expect that for specific deployment domains (e.g. DC, Enterprise= ) - but also for overlay networks / VPNs - we'll see an increasing amount of= chips that are well suited for processing large extension header. > > > > > > Cheers, Frank > > > > > > -- > > > Mikael Abrahamsson email: swmike@swm.pp.se > > > > > > _______________________________________________ > > > ippm mailing list > > > ippm@ietf.org > > > https://eur03.safelinks.protection.outlook.com/?url=3Dh= ttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cgba= rak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4= d149256f461b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef3B= JFz6AQNNAtkgmAMDFKM%3D&reserved=3D0 > > > _______________________________________________ > > > ippm mailing list > > > ippm@ietf.org > > > https://eur03.safelinks.protection.outlook.com/?url=3Dh= ttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cgba= rak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4= d149256f461b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef3B= JFz6AQNNAtkgmAMDFKM%3D&reserved=3D0 > > > -----------------------------------------------------= --------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6 > > > -----------------------------------------------------= --------------- > > > > _______________________________________________ > > ippm mailing list > > ippm@ietf.org > > https://www.ietf.org/mailman/listinfo/ippm > > > > > > > > > =20 =20 From nobody Fri Apr 5 12:28:14 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D021200C5 for ; Fri, 5 Apr 2019 12:28:07 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 XYyzHz1-yFmX for ; Fri, 5 Apr 2019 12:28:03 -0700 (PDT) Received: from mail-qt1-x842.google.com (mail-qt1-x842.google.com [IPv6:2607:f8b0:4864:20::842]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A873120073 for ; Fri, 5 Apr 2019 12:28:03 -0700 (PDT) Received: by mail-qt1-x842.google.com with SMTP id w30so8714800qta.8 for ; Fri, 05 Apr 2019 12:28:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SxwbezEQ+HW95xXvyCcqH0bg7eg4pfZ7BTqzEhdt+yg=; b=cm67Q9x9AmjpgxZzrNiSvzQ2xqssXJ9nEbravj9g+I5hGXeTv+1lMyr1JK8oBvU6fu itmXht3vV0530cNyLcrEFMy5iinBHwzG0VVTRLySg79dpFNx6QuHpGp5n/AP30P+lFMO SYeXPOwj0XRoUMLKI0ZIhpvuydKcByAkY/KsLx5eglbYDlu2HvOMSbS0WBxAZ1vrWEk1 ZBlrd2zGj7zS7m8/GLa5kqt3Uk4T23jN6z8Lszfjfro0rTV5wfkmZuODyeFFczFiL64y kvR3HqETDuiEc1z862NH8jj7sLltMqI1lN7muBaX+9K8SV34H9G3r/j8QYFWMirGugxS f1wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SxwbezEQ+HW95xXvyCcqH0bg7eg4pfZ7BTqzEhdt+yg=; b=pR8v94OaSxB4OW4eF/Jlq3YZ7gTSq/Jha5DkeqWxpCKsHhGnjmZ8Tbd/pdzqu+kpxv DkvIDj7z+Z2uPocNiBhKtR8E1iH8LGzWvZqR2L8eIqxUlBrVlDz4lrNEhAgHPsUfRxEV i2Q3IeWhqGDah7vZ0LTDitZEbO0nqqvECTnSPXB+MtwNHLa//h5Xh8rqrv1FPGtiPX7f tAtuXQ7arJ9YrjRNg+pZ1vqaSrQQEFjlXbKdYGoKSV07lo5I/SZBDZT5ex1AtchDB3Nu lRDRkOZaxpkOETRyZacEJqLHRtSk/AXCwcwWIxfRG6jBZzrnM9+8CyiopjDcfwFlpj+y TOrA== X-Gm-Message-State: APjAAAVz1TC1qnRwNt8Qf5S7egkaxrX+b1FZtexj4W+iQ8BPJcIYDznb 591KXBGvczWWwwr/bX1Ulwdy555kY/k09ClMmGwP1g== X-Google-Smtp-Source: APXvYqxbV5W7NkrVuIQX4SN2MAKKBjLxP6ki2tm+mtZnmYzHSI4Zyx1tdZb10vn20+IQoANVfvv2qipn+dHc7ELSOkw= X-Received: by 2002:a0c:9326:: with SMTP id d35mr11907960qvd.108.1554492481983; Fri, 05 Apr 2019 12:28:01 -0700 (PDT) MIME-Version: 1.0 References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> <4278D47A901B3041A737953BAA078ADE1478D5E2@DGGEML532-MBX.china.huawei.com> <4278D47A901B3041A737953BAA078ADE1478EC8B@DGGEML532-MBX.china.huawei.com> <14A3D5C9-1EED-4E11-9329-B62B819271A2@broadcom.com> <20D6FCDB-3357-4728-BD52-8069C32F3CCA@broadcom.com> In-Reply-To: From: Tom Herbert Date: Fri, 5 Apr 2019 12:27:50 -0700 Message-ID: To: Jai Kumar Cc: "Pengshuping (Peng Shuping)" , 6man WG , ippm , "C. M. Heard" , Mikael Abrahamsson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 19:28:07 -0000 On Fri, Apr 5, 2019 at 12:03 PM Jai Kumar wrote: > > " Great, but this IETF" > Does it mean that drafts have no relevance to deployment and actual adopt= ion. > > For all your queries please take a look at IFA draft. > https://datatracker.ietf.org/doc/draft-kumar-ippm-ifa/ > I've looked at that draft. It's is creating a complete new IP protocolas well as a new packet format for TCP and UDP that somehow inserts meta data between the TCP header and payload. I don't understand why this could possibly be better than just using flow label for ECMP and teaching devices that need to extract transport information how to walk over EH, or just using some UDP encpasulation like in draft-herbert-ipv4-udpencap-eh-01. Tom > It handles IPv6, IPv4 TCP/UDP with altering the packet path (due to inser= ting options and/or encaping them in GRE header) as well as IPSec AH/ESP/WE= SP both tunnel and transport and guess what it is successfully deployed. > > -Jai > > =EF=BB=BFOn 4/5/19, 11:54 AM, "Tom Herbert" wrote: > > On Fri, Apr 5, 2019 at 11:25 AM Jai Kumar wr= ote: > > > > Tom, > > > > I am speaking based on the actual deployment not based on if all th= e traffic is/will move to IPSec tunnel. > > > > I have 6 large customer deployments and one someone previously call= ed as "Yahoo" who insist on visibility in L4 even for IOAM packets. > > > And I've worked in datcenters much larger, and my first rule is that = I > don't want random router vendors dictating to me what protocols I'm > allowed to use in my datacenter. > > > I can quote you on that and lose my business :-) > > > > ECMP argument is weak as well as it works for IPv6 flow label. What= about IPv4 TCP/UDP traffic which typically is 80% of the traffic in MSDC. > > > > draft-herbert-ipv4-udpencap-eh-01 > > > If someone tells me that proposal will work only for my 20% of traf= fic then again as I said before, they will lose my business :-) > > > Great, but this IETF. Where are the protocol requirements? If you are > saying that there are requirements for "visibility in L4" what are > they? If you are saying that ACLs are now required for packet > forwarding, where is that described? Is it a MUST that teh only > transport protocols we're allowed to use are UDP or TCP? Are we > allowed to use extension headers at all? I suppose fragmentation is > right out... Are we violating the requirements if we encrypt the > transport headers? If you say that we shouldn't send long headers > because we'll overflow parsing buffers, then what is the limit? Pleas= e > be SPECIFC in setting requirements; we are trying to build protocols > that work and are interoperable and we need to get out of this morass > of reverse engineering to discover the least common denominator. > > Tom > > > Regards, > > -Jai > > > > =EF=BB=BFOn 4/5/19, 11:15 AM, "Tom Herbert" w= rote: > > > > On Fri, Apr 5, 2019 at 10:55 AM Jai Kumar wrote: > > > > > > Even if we use flow label for ECMP, lack of accessibility of = L4 information (for various services, most simple is ACL) makes the proposa= l pretty much unusable. > > > > > That is convoluting router and firewall functionality and > > requirements. This a discussion about packet forwarding which d= oes > > _not_ require ACLs. In a limited domain, for which IOAM is inte= nded, > > it is unlikely that they'll ACLs would be used in internal node= s, but > > we do need good ECMP routing at all intermediate nodes need to = be > > consistent rather or not that the IOAM option is present. As si= de > > note, the ability to extract L4 information out of packets is > > dwindling anyway thanks to encryption and other techniques tryi= ng to > > undo protocol ossification. For instance, good luck getting L4 > > information out of an IPsec tunnel :-). > > > > Tom > > > > > NIC cards are not used pervasively for ACLs and other service= s, I believe iptables in kernel are good enough for host but that=E2=80=99s= not acceptable in networking elements. > > > > > > -Jai > > > > > > =EF=BB=BFOn 4/5/19, 10:31 AM, "ippm on behalf of Tom Herbert"= wrote: > > > > > > On Fri, Apr 5, 2019 at 9:16 AM Pengshuping (Peng Shuping) > > > wrote: > > > > > > > > Hi Barak, > > > > > > > > We are certainly not designing for the lowest capable s= olutions but exploring optimal solutions which could help to keep the forwa= rding performance while inserting the iOAM data with variable length. > > > > > > Shuping, > > > > > > That's exactly the argument for using the flow label in E= CMP. > > > Efficeint packet forwarding can be done solely by inspect= ed the forty > > > byte fixed length header of the packet regardless of the = contents of > > > the rest of the packet. That is an optimal solution. Anyt= hing else for > > > ECMP like doing DPI or hacking up IOAM to try do pull tra= nsport layers > > > into the parsing buffer (whatever size that may be) are n= othing more > > > than hacks and unnecessarily perpetuate techniques used w= ith IPv4 that > > > either don't work or are unnecessary in IPv6. > > > > > > Tom > > > > > > > > > > > > > > In terms of the forwarding efficiency, we would all agr= ee that a short and fixed header would be better than a variable header. > > > > > > > > Best regards > > > > Shuping > > > > > > > > > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Barak Gafni > > > > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Pengshuping (Peng = Shuping);Frank Brockners (fbrockne);Mikael Abrahamsson > > > > =E6=8A=84=E9=80=81=EF=BC=9A C. M. Heard;6man WG;Mark Smith;ippm > > > > =E4=B8=BB=E9=A2=98=EF=BC=9A RE: draft-ioametal-ippm-6ma= n-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data field= s) > > > > =E6=97=B6=E9=97=B4=EF=BC=9A 2019-04-05 03:18:26 > > > > > > > > Hi Shuping, > > > > I think that the question is whether we design for the = lowest capable solutions. I assume someone can find solutions with even low= er amount of parsing.. The low end solutions for these capabilities may nee= d to either adopt with new designs or use solutions such as what is suggest= ed in this thread by Tom Herbert. > > > > Personally, I don't think we should go this way, but to= design appropriate solutions, with appropriate layers in the headers. For = example, prevent dependencies between "remote" headers. > > > > > > > > Thanks, > > > > Barak > > > > > > > > -----Original Message----- > > > > From: ippm On Behalf Of Pengshu= ping (Peng Shuping) > > > > Sent: Wednesday, April 3, 2019 6:47 AM > > > > To: Frank Brockners (fbrockne) ; Mi= kael Abrahamsson > > > > Cc: C. M. Heard ; 6man WG ; Mark Smith ; ippm@ietf.org > > > > Subject: [ippm] =E7=AD=94=E5=A4=8D: draft-ioametal-ippm= -6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data f= ields) > > > > > > > > Hi, > > > > > > > > The parsing depth of the early chips is 96B/128B. For t= he new chips the parsing depth has been increased but still limited. So Mik= ael's concern makes sense especially in the tracing mode that the IOAM data= fields are going to increase significantly along the path, which will even= push the Routing Header out of the parsing depth of the chip. So it would = make sense to split the IOAM data part from the IOAM header/instruction par= t, and place the IOAM data after the RH or even after the L4 header in orde= r to be able to read the L4 information to enable ECMP, as stated in the dr= aft https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftoo= ls.ietf.org%2Fhtml%2Fdraft-li-6man-ipv6-sfc-ifit-00&data=3D02%7C01%7Cgb= arak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6= a4d149256f461b%7C0%7C0%7C636898960379485833&sdata=3DDob4zN%2F1jSGxLTlqG= ma29JJNvqJDBt4VzqHsN4OpxM4%3D&reserved=3D0. > > > > > > > > BR, > > > > Shuping > > > > > > > > > > > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: ippm [mailto:ippm-bounces@= ietf.org] =E4=BB=A3=E8=A1=A8 Frank Brockners (fbrockne) > > > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B44=E6= =9C=882=E6=97=A5 17:40 > > > > =E6=94=B6=E4=BB=B6=E4=BA=BA: Mikael Abrahamsson > > > > =E6=8A=84=E9=80=81: C. M. Heard ; 6man= WG ; Mark Smith ; ippm@ietf.org > > > > =E4=B8=BB=E9=A2=98: Re: [ippm] draft-ioametal-ippm-6man= -ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields= ) > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Mikael Abrahamsson > > > > Sent: Dienstag, 2. April 2019 08:06 > > > > To: Frank Brockners (fbrockne) > > > > Cc: Mark Smith ; C. M. Heard ; 6man WG ; ippm@ietf.org > > > > Subject: RE: draft-ioametal-ippm-6man-ioam-ipv6-deploym= ent-00 feedback (Re: v6 option types for IOAM data fields) > > > > > > > > On Mon, 1 Apr 2019, Frank Brockners (fbrockne) wrote: > > > > > > > > > ...FB: There is obviously no easy answer. Couple of t= houghts: > > > > > * IOAM is considered a "domain specific" feature (see > > > > > draft-ietf-ippm-ioam-data-05, section 3). Routers in = the IOAM domain > > > > > should be IOAM capable. And IMHO, we should add a s= tatement to > > > > > draft-ioametal-ippm-6man-ioam-ipv6-deployment that an= implementation > > > > > of IOAM MUST ensure "C1". > > > > > > > > > > * That said, there can be situations, where C1 cannot= be achieved, e.g.. > > > > > consider a network which does ECMP scheduling based o= n packet length. > > > > > > > > > > * What one could consider - and which is one suggeste= d deployment > > > > > model > > > > > - is that by default IOAM data fields are added to _a= ll_ customer > > > > > packets. The decapsulating node would decide whether = the IOAM > > > > > information contained in a packet would be used (and = exported) or not. > > > > > That way one would not need to deal with the situatio= n that some > > > > > traffic carries IOAM while other does not - and might= thus be treated > > > > > differently. > > > > > > > > Yes, I think this is the only way. Is there a risk that= intermediate routers would not be IOAM capable? I think the C1 requirement= is really really hard to fulfil and I'm also afraid that adding the IOAM h= eader will actually make ECMP stop working on some platforms (because they = would not have the capability to look deep enough into the packet to find L= 4 information, so it'll go back to 2 tuple ECMP instead of 5 tuple. > > > > > > > > But this question can only be answered by people with d= eep NPU knowledge... > > > > > > > > .....FB2: Given that IOAM is a domain specific feature = - I expect that folks initially start to use it in domains (like e.g. a DC)= where all boxes are IOAM capable and can trace the packet appropriately - = or per Tom's note, can be configured so that one would do ECMP based on add= resses and flow-label. There are chips with pretty deep parsing capability= (up to a few hundred bytes). > > > > > > > > > ...FB: The comparison to MPLS is interesting. How oft= en do MPLS > > > > > packets leak and cause harm? For IOAM, > > > > > draft-ioametal-ippm-6man-ioam-ipv6-options-02 propose= s a deployment > > > > > model similar to what we do for MPLS: Unless an inter= face is > > > > > explicitly configured for IOAM, packets with IOAM dat= a fields MUST be dropped. > > > > > Hence leakage would only occur, if we have a clearly = misbehaving > > > > > router which violates this rule. Similar to you, I'd = also greatly > > > > > appreciate any pointers to research on how common MPL= S leaked packets are. > > > > > > > > When it comes to "cause harm" I imagine there are (at l= east) two ways to cause harm, one is privacy/secrecy/security loss and the = other one is actual operational loss. > > > > > > > > I know of bugs where labeled packets went the wrong way= and caused them to be lost, I've also seen bugs where bugs caused traffic = to "hop" between VRFs in MPLS VPN (or to "global" VRF). I don't have number= s on this though. > > > > > > > > Depending on the deployment scenario, it might make sen= se to make IOAM packets not valid for non-IOAM aware devices (basically enc= ap entire packet/payload), but that might be a problem for intermediate non= -IOAM nodes then. This would affect the ECMP requirement. I can see cases w= here one would operationally turn on IOAM for some customers traffic and th= en see the problem go away because now ECMP changed. > > > > > > > > > ...FB: One idea that Shwetha came up with to identify= the source AS of > > > > > a leaked packet, would be to add a new new IOAM E2E o= ption - as > > > > > proposed in section 5.1.1 bullet 2 of > > > > > draft-ioametal-ippm-6man-ioam-ipv6-deployment-01. > > > > > > > > Yes, that'd solve that problem. > > > > > > > > How much has the silicon people been involved so far in= the design of the headers? What is the current thinking of amount of data = going into the IOAM header? Considering things like trace options etc it se= ems to me the header can grow quite large? To satisfy the ECMP requirement = what about putting the IOAM information as a trailer behind the regular pay= load? Or is there a problem for the hw to manipulate information that far i= nto the packet (I also imagine this will considerably lower the forwarding = performance of IOAM packets on IOAM aware platforms). > > > > > > > > .....FB2: There are quite a few folks with hardware bac= kground that co-author the IOAM drafts. Parsing capability differs between = chips, as does the ability to deal with new/flexible headers and the abilit= y to modify data in the extension headers. So the unfortunate answer to tha= t question is "it depends" (what information do you gather, how large is yo= ur domain, what are the capabilities of your hardware/software forwarder, e= tc.), but I do expect that for specific deployment domains (e.g. DC, Enterp= rise) - but also for overlay networks / VPNs - we'll see an increasing amou= nt of chips that are well suited for processing large extension header. > > > > > > > > Cheers, Frank > > > > > > > > -- > > > > Mikael Abrahamsson email: swmike@swm.pp.se > > > > > > > > _______________________________________________ > > > > ippm mailing list > > > > ippm@ietf.org > > > > https://eur03.safelinks.protection.outlook.com/?url=3Dh= ttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7C= gbarak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9b= a6a4d149256f461b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159j= e0yef3BJFz6AQNNAtkgmAMDFKM%3D&reserved=3D0 > > > > _______________________________________________ > > > > ippm mailing list > > > > ippm@ietf.org > > > > https://eur03.safelinks.protection.outlook.com/?url=3Dh= ttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7C= gbarak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9b= a6a4d149256f461b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159j= e0yef3BJFz6AQNNAtkgmAMDFKM%3D&reserved=3D0 > > > > -------------------------------------------------------= ------------- > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf.org > > > > Administrative Requests: https://www.ietf.org/mailman/l= istinfo/ipv6 > > > > -------------------------------------------------------= ------------- > > > > > > _______________________________________________ > > > ippm mailing list > > > ippm@ietf.org > > > https://www.ietf.org/mailman/listinfo/ippm > > > > > > > > > > > > > > > > > > From nobody Fri Apr 5 14:07:33 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12CBF120619 for ; Fri, 5 Apr 2019 14:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.com 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 p-BjkxSVCsby for ; Fri, 5 Apr 2019 14:07:27 -0700 (PDT) Received: from mail-yw1-xc35.google.com (mail-yw1-xc35.google.com [IPv6:2607:f8b0:4864:20::c35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1B46120608 for ; Fri, 5 Apr 2019 14:07:26 -0700 (PDT) Received: by mail-yw1-xc35.google.com with SMTP id v127so2799890ywe.13 for ; Fri, 05 Apr 2019 14:07:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=dhlvsDWYEJi+Q2Ns1x2jGSFmJrMxFyVKU4Qxr97B8jk=; b=Tx4k2HWlyFZGCjU7IPmAGqchAcw2Om0c0iDNT0wa+8J1HUExevY/rMAN0aiOgRiZJE 6BHpjTfo+lzQH25X6gwhvSFGFn5pqg822Vvx31g6L905quupt5YtZia+3ti3jT2ZV/4z XhvhJ6Ta4oBhw4tfbVsJ6ub90nYvZ4BC6nvgQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=dhlvsDWYEJi+Q2Ns1x2jGSFmJrMxFyVKU4Qxr97B8jk=; b=N4bIwjGWA8RoH09KiUftt/O3OEU66ZornA+c4JkzVR1SDLfw3Vgw/ewYKBLenPyem8 reQNLYWMfCHcNdwkb2E6F2slJADLg+15N5s78BuqP4sfRwRZK+BcdKMbcpdiEjNmMrJp 7CAQw6P/kpSe3JWf2ddYODlLrrimzytA84YHq1KEH860LQUYa/DAJYOWdFwrkhOabOns C39Z280IQ0kFoDGHVcfG9nbaaYP9O8uyPw+rh8iuNiIjkPqHs7vzFF9uTqzuma7rYLlf NK8An14NiKoxqaC8XPDhqpbMdM0U/irTm/Og5GLlKrF7TSKp9wAJCaRXIqg9szMoS9NS fD6A== X-Gm-Message-State: APjAAAWE+U+hV3oMyZ3kqTi1TinyBqTpPXMbjlKawtGyE1iP6vKAofpE NYkJPJElrPjLQ/uvOBb6MIMKb6/KkRo= X-Google-Smtp-Source: APXvYqw2ndjBiXzeROxUNISnlKAoAhXnVtULXQy1NeW2D0UDE8Y9NtNCFBgPfFdDvouQln0tHG+DuQ== X-Received: by 2002:a81:3a15:: with SMTP id h21mr12542504ywa.454.1554498445921; Fri, 05 Apr 2019 14:07:25 -0700 (PDT) Received: from [10.58.68.119] ([192.19.222.250]) by smtp.gmail.com with ESMTPSA id k189sm7820744ywa.48.2019.04.05.14.07.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Apr 2019 14:07:25 -0700 (PDT) User-Agent: Microsoft-MacOutlook/10.17.1.190326 Date: Fri, 05 Apr 2019 14:07:22 -0700 From: Jai Kumar To: Tom Herbert CC: "Pengshuping (Peng Shuping)" , 6man WG , ippm , "C. M. Heard" , Mikael Abrahamsson Message-ID: Thread-Topic: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> <4278D47A901B3041A737953BAA078ADE1478D5E2@DGGEML532-MBX.china.huawei.com> <4278D47A901B3041A737953BAA078ADE1478EC8B@DGGEML532-MBX.china.huawei.com> <14A3D5C9-1EED-4E11-9329-B62B819271A2@broadcom.com> <20D6FCDB-3357-4728-BD52-8069C32F3CCA@broadcom.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 21:07:31 -0000 Tom, Its all explained in the requirements section of the draft. IFA header is e= ssentially treated as an EH both in IPv4 and IPv6 (very similar to AH/ESP EH= ). Just like in AH/ESP the IP protocol is copied in the AH header and IP proto= col field is replaced in the IP header with the AH proto. There are several advantages to this approach. - devise know how to parse AH header and can follow very similar approach - Protocol agnostics, silicon need not support N encaps (just like AH/ESP).= Single implementation works for all protocol types. - No need to creation options and teach devices that options is NOT an exce= ption path processing - Really worry about ordering in IPv6 options - Note that all the OAM data need to be deleted as well so position need to= be optimal for removal. We can always do tail stamping of the data but this= puts considerable constrains on the cell based architecture - L4 accessibility I have already mentioned I am happy to discuss with you in person and explain more but bottom line i= s that this proposal is what came out with MSDC discussions in light of shor= tcomings from other IETF proposals. Regards, -Jai =EF=BB=BFOn 4/5/19, 12:28 PM, "Tom Herbert" wrote: On Fri, Apr 5, 2019 at 12:03 PM Jai Kumar wrot= e: > > " Great, but this IETF" > Does it mean that drafts have no relevance to deployment and actual a= doption. > > For all your queries please take a look at IFA draft. > https://datatracker.ietf.org/doc/draft-kumar-ippm-ifa/ > I've looked at that draft. It's is creating a complete new IP protocolas well as a new packet format for TCP and UDP that somehow inserts meta data between the TCP header and payload. I don't understand why this could possibly be better than just using flow label for ECMP and teaching devices that need to extract transport information how to walk over EH, or just using some UDP encpasulation like in draft-herbert-ipv4-udpencap-eh-01. =20 Tom =20 > It handles IPv6, IPv4 TCP/UDP with altering the packet path (due to i= nserting options and/or encaping them in GRE header) as well as IPSec AH/ESP= /WESP both tunnel and transport and guess what it is successfully deployed. > > -Jai > > =EF=BB=BFOn 4/5/19, 11:54 AM, "Tom Herbert" wrote: > > On Fri, Apr 5, 2019 at 11:25 AM Jai Kumar wrote: > > > > Tom, > > > > I am speaking based on the actual deployment not based on if al= l the traffic is/will move to IPSec tunnel. > > > > I have 6 large customer deployments and one someone previously = called as "Yahoo" who insist on visibility in L4 even for IOAM packets. > > > And I've worked in datcenters much larger, and my first rule is t= hat I > don't want random router vendors dictating to me what protocols I= 'm > allowed to use in my datacenter. > > > I can quote you on that and lose my business :-) > > > > ECMP argument is weak as well as it works for IPv6 flow label. = What about IPv4 TCP/UDP traffic which typically is 80% of the traffic in MSD= C. > > > > draft-herbert-ipv4-udpencap-eh-01 > > > If someone tells me that proposal will work only for my 20% of = traffic then again as I said before, they will lose my business :-) > > > Great, but this IETF. Where are the protocol requirements? If you= are > saying that there are requirements for "visibility in L4" what ar= e > they? If you are saying that ACLs are now required for packet > forwarding, where is that described? Is it a MUST that teh only > transport protocols we're allowed to use are UDP or TCP? Are we > allowed to use extension headers at all? I suppose fragmentation = is > right out... Are we violating the requirements if we encrypt the > transport headers? If you say that we shouldn't send long headers > because we'll overflow parsing buffers, then what is the limit? P= lease > be SPECIFC in setting requirements; we are trying to build protoc= ols > that work and are interoperable and we need to get out of this mo= rass > of reverse engineering to discover the least common denominator. > > Tom > > > Regards, > > -Jai > > > > =EF=BB=BFOn 4/5/19, 11:15 AM, "Tom Herbert" wro= te: > > > > On Fri, Apr 5, 2019 at 10:55 AM Jai Kumar wrote: > > > > > > Even if we use flow label for ECMP, lack of accessibility= of L4 information (for various services, most simple is ACL) makes the prop= osal pretty much unusable. > > > > > That is convoluting router and firewall functionality and > > requirements. This a discussion about packet forwarding whi= ch does > > _not_ require ACLs. In a limited domain, for which IOAM is = intended, > > it is unlikely that they'll ACLs would be used in internal = nodes, but > > we do need good ECMP routing at all intermediate nodes need= to be > > consistent rather or not that the IOAM option is present. A= s side > > note, the ability to extract L4 information out of packets = is > > dwindling anyway thanks to encryption and other techniques = trying to > > undo protocol ossification. For instance, good luck getting= L4 > > information out of an IPsec tunnel :-). > > > > Tom > > > > > NIC cards are not used pervasively for ACLs and other ser= vices, I believe iptables in kernel are good enough for host but that=E2=80=99s no= t acceptable in networking elements. > > > > > > -Jai > > > > > > =EF=BB=BFOn 4/5/19, 10:31 AM, "ippm on behalf of Tom Herbert" <= ippm-bounces@ietf.org on behalf of tom@herbertland.com> wrote: > > > > > > On Fri, Apr 5, 2019 at 9:16 AM Pengshuping (Peng Shup= ing) > > > wrote: > > > > > > > > Hi Barak, > > > > > > > > We are certainly not designing for the lowest capab= le solutions but exploring optimal solutions which could help to keep the fo= rwarding performance while inserting the iOAM data with variable length. > > > > > > Shuping, > > > > > > That's exactly the argument for using the flow label = in ECMP. > > > Efficeint packet forwarding can be done solely by ins= pected the forty > > > byte fixed length header of the packet regardless of = the contents of > > > the rest of the packet. That is an optimal solution. = Anything else for > > > ECMP like doing DPI or hacking up IOAM to try do pull= transport layers > > > into the parsing buffer (whatever size that may be) a= re nothing more > > > than hacks and unnecessarily perpetuate techniques us= ed with IPv4 that > > > either don't work or are unnecessary in IPv6. > > > > > > Tom > > > > > > > > > > > > > > In terms of the forwarding efficiency, we would all= agree that a short and fixed header would be better than a variable header. > > > > > > > > Best regards > > > > Shuping > > > > > > > > > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Barak Gafni > > > > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Pengshuping (Peng Shuping);Frank Brockners (fbrockne);Mikael Abrahamss= on > > > > =E6=8A=84=E9=80=81=EF=BC=9A C. M. Heard;6man WG;Mark Smith;ippm > > > > =E4=B8=BB=E9=A2=98=EF=BC=9A RE: draft-ioametal-ippm-6man-ioam-ipv6-de= ployment-00 feedback (Re: v6 option types for IOAM data fields) > > > > =E6=97=B6=E9=97=B4=EF=BC=9A 2019-04-05 03:18:26 > > > > > > > > Hi Shuping, > > > > I think that the question is whether we design for = the lowest capable solutions. I assume someone can find solutions with even = lower amount of parsing.. The low end solutions for these capabilities may n= eed to either adopt with new designs or use solutions such as what is sugges= ted in this thread by Tom Herbert. > > > > Personally, I don't think we should go this way, bu= t to design appropriate solutions, with appropriate layers in the headers. F= or example, prevent dependencies between "remote" headers. > > > > > > > > Thanks, > > > > Barak > > > > > > > > -----Original Message----- > > > > From: ippm On Behalf Of Pen= gshuping (Peng Shuping) > > > > Sent: Wednesday, April 3, 2019 6:47 AM > > > > To: Frank Brockners (fbrockne) = ; Mikael Abrahamsson > > > > Cc: C. M. Heard ; 6man WG ; Mark Smith ; ippm@ietf.org > > > > Subject: [ippm] =E7=AD=94=E5=A4=8D: draft-ioametal-ippm-6man-io= am-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) > > > > > > > > Hi, > > > > > > > > The parsing depth of the early chips is 96B/128B. F= or the new chips the parsing depth has been increased but still limited. So = Mikael's concern makes sense especially in the tracing mode that the IOAM da= ta fields are going to increase significantly along the path, which will eve= n push the Routing Header out of the parsing depth of the chip. So it would = make sense to split the IOAM data part from the IOAM header/instruction part= , and place the IOAM data after the RH or even after the L4 header in order = to be able to read the L4 information to enable ECMP, as stated in the draft= https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.iet= f.org%2Fhtml%2Fdraft-li-6man-ipv6-sfc-ifit-00&data=3D02%7C01%7Cgbarak%40me= llanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f= 461b%7C0%7C0%7C636898960379485833&sdata=3DDob4zN%2F1jSGxLTlqGma29JJNvqJDBt= 4VzqHsN4OpxM4%3D&reserved=3D0. > > > > > > > > BR, > > > > Shuping > > > > > > > > > > > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: ippm [mailto:ippm-bounces@ietf.org] =E4=BB=A3=E8= =A1=A8 Frank Brockners (fbrockne) > > > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B44=E6=9C=882=E6=97=A5 17:40 > > > > =E6=94=B6=E4=BB=B6=E4=BA=BA: Mikael Abrahamsson > > > > =E6=8A=84=E9=80=81: C. M. Heard ; 6man WG ; Mark Smith ; ippm@ietf.org > > > > =E4=B8=BB=E9=A2=98: Re: [ippm] draft-ioametal-ippm-6man-ioam-ip= v6-deployment-00 feedback (Re: v6 option types for IOAM data fields) > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Mikael Abrahamsson > > > > Sent: Dienstag, 2. April 2019 08:06 > > > > To: Frank Brockners (fbrockne) > > > > Cc: Mark Smith ; C. M. Hear= d ; 6man WG ; ippm@ietf.org > > > > Subject: RE: draft-ioametal-ippm-6man-ioam-ipv6-dep= loyment-00 feedback (Re: v6 option types for IOAM data fields) > > > > > > > > On Mon, 1 Apr 2019, Frank Brockners (fbrockne) wrot= e: > > > > > > > > > ...FB: There is obviously no easy answer. Couple = of thoughts: > > > > > * IOAM is considered a "domain specific" feature = (see > > > > > draft-ietf-ippm-ioam-data-05, section 3). Routers= in the IOAM domain > > > > > should be IOAM capable. And IMHO, we should add= a statement to > > > > > draft-ioametal-ippm-6man-ioam-ipv6-deployment tha= t an implementation > > > > > of IOAM MUST ensure "C1". > > > > > > > > > > * That said, there can be situations, where C1 ca= nnot be achieved, e.g.. > > > > > consider a network which does ECMP scheduling bas= ed on packet length. > > > > > > > > > > * What one could consider - and which is one sugg= ested deployment > > > > > model > > > > > - is that by default IOAM data fields are added t= o _all_ customer > > > > > packets. The decapsulating node would decide whet= her the IOAM > > > > > information contained in a packet would be used (= and exported) or not. > > > > > That way one would not need to deal with the situ= ation that some > > > > > traffic carries IOAM while other does not - and m= ight thus be treated > > > > > differently. > > > > > > > > Yes, I think this is the only way. Is there a risk = that intermediate routers would not be IOAM capable? I think the C1 requirem= ent is really really hard to fulfil and I'm also afraid that adding the IOAM= header will actually make ECMP stop working on some platforms (because they= would not have the capability to look deep enough into the packet to find L= 4 information, so it'll go back to 2 tuple ECMP instead of 5 tuple. > > > > > > > > But this question can only be answered by people wi= th deep NPU knowledge... > > > > > > > > .....FB2: Given that IOAM is a domain specific feat= ure - I expect that folks initially start to use it in domains (like e.g. a = DC) where all boxes are IOAM capable and can trace the packet appropriately = - or per Tom's note, can be configured so that one would do ECMP based on ad= dresses and flow-label. There are chips with pretty deep parsing capability= (up to a few hundred bytes). > > > > > > > > > ...FB: The comparison to MPLS is interesting. How= often do MPLS > > > > > packets leak and cause harm? For IOAM, > > > > > draft-ioametal-ippm-6man-ioam-ipv6-options-02 pro= poses a deployment > > > > > model similar to what we do for MPLS: Unless an i= nterface is > > > > > explicitly configured for IOAM, packets with IOAM= data fields MUST be dropped. > > > > > Hence leakage would only occur, if we have a clea= rly misbehaving > > > > > router which violates this rule. Similar to you, = I'd also greatly > > > > > appreciate any pointers to research on how common= MPLS leaked packets are. > > > > > > > > When it comes to "cause harm" I imagine there are (= at least) two ways to cause harm, one is privacy/secrecy/security loss and t= he other one is actual operational loss. > > > > > > > > I know of bugs where labeled packets went the wrong= way and caused them to be lost, I've also seen bugs where bugs caused traff= ic to "hop" between VRFs in MPLS VPN (or to "global" VRF). I don't have numb= ers on this though. > > > > > > > > Depending on the deployment scenario, it might make= sense to make IOAM packets not valid for non-IOAM aware devices (basically = encap entire packet/payload), but that might be a problem for intermediate n= on-IOAM nodes then. This would affect the ECMP requirement. I can see cases = where one would operationally turn on IOAM for some customers traffic and th= en see the problem go away because now ECMP changed. > > > > > > > > > ...FB: One idea that Shwetha came up with to iden= tify the source AS of > > > > > a leaked packet, would be to add a new new IOAM E= 2E option - as > > > > > proposed in section 5.1.1 bullet 2 of > > > > > draft-ioametal-ippm-6man-ioam-ipv6-deployment-01. > > > > > > > > Yes, that'd solve that problem. > > > > > > > > How much has the silicon people been involved so fa= r in the design of the headers? What is the current thinking of amount of da= ta going into the IOAM header? Considering things like trace options etc it = seems to me the header can grow quite large? To satisfy the ECMP requirement= what about putting the IOAM information as a trailer behind the regular pay= load? Or is there a problem for the hw to manipulate information that far in= to the packet (I also imagine this will considerably lower the forwarding pe= rformance of IOAM packets on IOAM aware platforms). > > > > > > > > .....FB2: There are quite a few folks with hardware= background that co-author the IOAM drafts. Parsing capability differs betwe= en chips, as does the ability to deal with new/flexible headers and the abil= ity to modify data in the extension headers. So the unfortunate answer to th= at question is "it depends" (what information do you gather, how large is yo= ur domain, what are the capabilities of your hardware/software forwarder, et= c.), but I do expect that for specific deployment domains (e.g. DC, Enterpri= se) - but also for overlay networks / VPNs - we'll see an increasing amount = of chips that are well suited for processing large extension header. > > > > > > > > Cheers, Frank > > > > > > > > -- > > > > Mikael Abrahamsson email: swmike@swm.pp.se > > > > > > > > _______________________________________________ > > > > ippm mailing list > > > > ippm@ietf.org > > > > https://eur03.safelinks.protection.outlook.com/?url= =3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cg= barak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6= a4d149256f461b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef= 3BJFz6AQNNAtkgmAMDFKM%3D&reserved=3D0 > > > > _______________________________________________ > > > > ippm mailing list > > > > ippm@ietf.org > > > > https://eur03.safelinks.protection.outlook.com/?url= =3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cg= barak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6= a4d149256f461b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef= 3BJFz6AQNNAtkgmAMDFKM%3D&reserved=3D0 > > > > ---------------------------------------------------= ----------------- > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf.org > > > > Administrative Requests: https://www.ietf.org/mailm= an/listinfo/ipv6 > > > > ---------------------------------------------------= ----------------- > > > > > > _______________________________________________ > > > ippm mailing list > > > ippm@ietf.org > > > https://www.ietf.org/mailman/listinfo/ippm > > > > > > > > > > > > > > > > > > =20 From nobody Fri Apr 5 14:35:03 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0141200E0 for ; Fri, 5 Apr 2019 14:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.09 X-Spam-Level: X-Spam-Status: No, score=0.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 PsnRseomNKjY for ; Fri, 5 Apr 2019 14:34:51 -0700 (PDT) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A34131202E3 for ; Fri, 5 Apr 2019 14:34:48 -0700 (PDT) Received: by mail-qt1-x835.google.com with SMTP id k2so9186474qtm.1 for ; Fri, 05 Apr 2019 14:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OgDnJMaXYOxFO9Mk2GI42esn9yJG7SWCtlNX4CN+bxY=; b=AEj/32VY5HJYsDK6B8yvaqWwv5zp4gHdVmjs8pHkp2CQeeEXPgHaoYvbqQc9AP5MjC LpJVIjtOGqsDDWUs3e3aS1gIDy0qPWF54jmADeZbk9A2jWBtm56iMhlxSlxDwnLHgEX9 v0q2pZF1VmpSn2b8U7Plaj3XpLwYAKXTyH/cqcQwjSAo8fX9K2Ka8pmbGK1iCBW8sFtQ Ubfjp59ZBxBDTRtrR4wLyGghhT67rRadh2d7JX56yYVtKMVds/5Z03e6o2tlbeWE5vYT QvrzlIIfBrZXZBKR8cdFQgX/fn/OeF3XEcFGDIIyrHa0d6OlKv8wWk1qyKc2YWdTSkWB 0QfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OgDnJMaXYOxFO9Mk2GI42esn9yJG7SWCtlNX4CN+bxY=; b=t3SrMTFFaC7WZwVs1x64aG97DbJSk9aq+XPjG5pf1hP92P0Gs6gCbGQDJrGvNedBxR lEHrF+XpQrmEcN6nTc1V57GNaFfil1WaSJ/TBq5Ib18ksDWTVzPjEZIkh4cbqFhyogiL 6l8G0h9O5E5PhGtRseILPSDNcVEbKW2lgvAp1Pthph44iN11cRMFSU0KDKGqmUOPHsYX Yf37hLztEvE01V4q//sw4UkCuOtqlE3ELjhxM84+OD8OjhrkGtgUWYJkLX7IilTuJbJo x6En83ot9rjUADtI28lxpcLhprbdQupsn0LAeQSSWhIyk6CPuKHtfi3Eosx2U8HCgCsL oB4g== X-Gm-Message-State: APjAAAXoRh+oO2UGHmvpPTI3U4mbSOdzHpAMFuQC+5Kk7fArVMhoNRV3 egmOHlZTAxS7nBozEhZLYI45Fufrl/7XilkbigeXOQ== X-Google-Smtp-Source: APXvYqxoNTAcOPkglaKh8uwskU2fT8RdGhoSw9otwhnpfKOF5qYghkPD7teFJNuS/VOdgJ7BFaBeMchq+dDCKLxNvXc= X-Received: by 2002:ac8:23ce:: with SMTP id r14mr12848627qtr.156.1554500087376; Fri, 05 Apr 2019 14:34:47 -0700 (PDT) MIME-Version: 1.0 References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> <4278D47A901B3041A737953BAA078ADE1478D5E2@DGGEML532-MBX.china.huawei.com> <4278D47A901B3041A737953BAA078ADE1478EC8B@DGGEML532-MBX.china.huawei.com> <14A3D5C9-1EED-4E11-9329-B62B819271A2@broadcom.com> <20D6FCDB-3357-4728-BD52-8069C32F3CCA@broadcom.com> In-Reply-To: From: Tom Herbert Date: Fri, 5 Apr 2019 14:34:35 -0700 Message-ID: To: Jai Kumar Cc: "Pengshuping (Peng Shuping)" , 6man , ippm , "C. M. Heard" , Mikael Abrahamsson Content-Type: multipart/alternative; boundary="0000000000008302570585cf41d9" Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 21:34:55 -0000 --0000000000008302570585cf41d9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Apr 5, 2019, 2:07 PM Jai Kumar wrote: > Tom, > > Its all explained in the requirements section of the draft. IFA header is > essentially treated as an EH both in IPv4 and IPv6 (very similar to AH/ES= P > EH). > > Just like in AH/ESP the IP protocol is copied in the AH header and IP > protocol field is replaced in the IP header with the AH proto. > > There are several advantages to this approach. > - devise know how to parse AH header and can follow very similar approach > - Protocol agnostics, silicon need not support N encaps (just like > AH/ESP). Single implementation works for all protocol types. > - No need to creation options and teach devices that options is NOT an > exception path processing > - Really worry about ordering in IPv6 options > - Note that all the OAM data need to be deleted as well so position need > to be optimal for removal. We can always do tail stamping of the data but > this puts considerable constrains on the cell based architecture > - L4 accessibility I have already mentioned > > I am happy to discuss with you in person and explain more but bottom line > is that this proposal is what came out with MSDC discussions in light of > shortcomings from other IETF proposals. > As they say, you are free to run whatever you want in your proprietary network, but if you expect to create an interoperable, deployable protocoI and get a protocol number assignment, you'll need to work in ietf. That is going to require justifying the protocol even in light of shortcomings in existing protocoIs. Tom > Regards, > -Jai > > > =EF=BB=BFOn 4/5/19, 12:28 PM, "Tom Herbert" wrote: > > On Fri, Apr 5, 2019 at 12:03 PM Jai Kumar > wrote: > > > > " Great, but this IETF" > > Does it mean that drafts have no relevance to deployment and actual > adoption. > > > > For all your queries please take a look at IFA draft. > > https://datatracker.ietf.org/doc/draft-kumar-ippm-ifa/ > > > I've looked at that draft. It's is creating a complete new IP > protocolas well as a new packet format for TCP and UDP that somehow > inserts meta data between the TCP header and payload. I don't > understand why this could possibly be better than just using flow > label for ECMP and teaching devices that need to extract transport > information how to walk over EH, or just using some UDP encpasulation > like in draft-herbert-ipv4-udpencap-eh-01. > > Tom > > > It handles IPv6, IPv4 TCP/UDP with altering the packet path (due to > inserting options and/or encaping them in GRE header) as well as IPSec > AH/ESP/WESP both tunnel and transport and guess what it is successfully > deployed. > > > > -Jai > > > > =EF=BB=BFOn 4/5/19, 11:54 AM, "Tom Herbert" w= rote: > > > > On Fri, Apr 5, 2019 at 11:25 AM Jai Kumar < > jai.kumar@broadcom.com> wrote: > > > > > > Tom, > > > > > > I am speaking based on the actual deployment not based on if > all the traffic is/will move to IPSec tunnel. > > > > > > I have 6 large customer deployments and one someone previousl= y > called as "Yahoo" who insist on visibility in L4 even for IOAM packets. > > > > > And I've worked in datcenters much larger, and my first rule is > that I > > don't want random router vendors dictating to me what protocols > I'm > > allowed to use in my datacenter. > > > > > I can quote you on that and lose my business :-) > > > > > > ECMP argument is weak as well as it works for IPv6 flow label= . > What about IPv4 TCP/UDP traffic which typically is 80% of the traffic in > MSDC. > > > > > > > draft-herbert-ipv4-udpencap-eh-01 > > > > > If someone tells me that proposal will work only for my 20% o= f > traffic then again as I said before, they will lose my business :-) > > > > > Great, but this IETF. Where are the protocol requirements? If > you are > > saying that there are requirements for "visibility in L4" what > are > > they? If you are saying that ACLs are now required for packet > > forwarding, where is that described? Is it a MUST that teh only > > transport protocols we're allowed to use are UDP or TCP? Are w= e > > allowed to use extension headers at all? I suppose fragmentatio= n > is > > right out... Are we violating the requirements if we encrypt th= e > > transport headers? If you say that we shouldn't send long heade= rs > > because we'll overflow parsing buffers, then what is the limit? > Please > > be SPECIFC in setting requirements; we are trying to build > protocols > > that work and are interoperable and we need to get out of this > morass > > of reverse engineering to discover the least common denominator= . > > > > Tom > > > > > Regards, > > > -Jai > > > > > > =EF=BB=BFOn 4/5/19, 11:15 AM, "Tom Herbert" > wrote: > > > > > > On Fri, Apr 5, 2019 at 10:55 AM Jai Kumar < > jai.kumar@broadcom.com> wrote: > > > > > > > > Even if we use flow label for ECMP, lack of > accessibility of L4 information (for various services, most simple is ACL= ) > makes the proposal pretty much unusable. > > > > > > > That is convoluting router and firewall functionality and > > > requirements. This a discussion about packet forwarding > which does > > > _not_ require ACLs. In a limited domain, for which IOAM i= s > intended, > > > it is unlikely that they'll ACLs would be used in interna= l > nodes, but > > > we do need good ECMP routing at all intermediate nodes > need to be > > > consistent rather or not that the IOAM option is present. > As side > > > note, the ability to extract L4 information out of packet= s > is > > > dwindling anyway thanks to encryption and other technique= s > trying to > > > undo protocol ossification. For instance, good luck > getting L4 > > > information out of an IPsec tunnel :-). > > > > > > Tom > > > > > > > NIC cards are not used pervasively for ACLs and other > services, I believe iptables in kernel are good enough for host but that= =E2=80=99s > not acceptable in networking elements. > > > > > > > > -Jai > > > > > > > > =EF=BB=BFOn 4/5/19, 10:31 AM, "ippm on behalf of Tom He= rbert" < > ippm-bounces@ietf.org on behalf of tom@herbertland.com> wrote: > > > > > > > > On Fri, Apr 5, 2019 at 9:16 AM Pengshuping (Peng > Shuping) > > > > wrote: > > > > > > > > > > Hi Barak, > > > > > > > > > > We are certainly not designing for the lowest > capable solutions but exploring optimal solutions which could help to kee= p > the forwarding performance while inserting the iOAM data with variable > length. > > > > > > > > Shuping, > > > > > > > > That's exactly the argument for using the flow labe= l > in ECMP. > > > > Efficeint packet forwarding can be done solely by > inspected the forty > > > > byte fixed length header of the packet regardless o= f > the contents of > > > > the rest of the packet. That is an optimal solution= . > Anything else for > > > > ECMP like doing DPI or hacking up IOAM to try do > pull transport layers > > > > into the parsing buffer (whatever size that may be) > are nothing more > > > > than hacks and unnecessarily perpetuate techniques > used with IPv4 that > > > > either don't work or are unnecessary in IPv6. > > > > > > > > Tom > > > > > > > > > > > > > > > > > > In terms of the forwarding efficiency, we would > all agree that a short and fixed header would be better than a variable > header. > > > > > > > > > > Best regards > > > > > Shuping > > > > > > > > > > > > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Barak Gafni<= gbarak@mellanox.com> > > > > > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Pengshuping = (Peng Shuping)< > pengshuping@huawei.com>;Frank Brockners (fbrockne);Mi= kael > Abrahamsson > > > > > =E6=8A=84=E9=80=81=EF=BC=9A C. M. Heard;6man WG< > ipv6@ietf.org>;Mark Smith;ippm > > > > > =E4=B8=BB=E9=A2=98=EF=BC=9A RE: > draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option > types for IOAM data fields) > > > > > =E6=97=B6=E9=97=B4=EF=BC=9A 2019-04-05 03:18:26 > > > > > > > > > > Hi Shuping, > > > > > I think that the question is whether we design fo= r > the lowest capable solutions. I assume someone can find solutions with ev= en > lower amount of parsing.. The low end solutions for these capabilities ma= y > need to either adopt with new designs or use solutions such as what is > suggested in this thread by Tom Herbert. > > > > > Personally, I don't think we should go this way, > but to design appropriate solutions, with appropriate layers in the > headers. For example, prevent dependencies between "remote" headers. > > > > > > > > > > Thanks, > > > > > Barak > > > > > > > > > > -----Original Message----- > > > > > From: ippm On Behalf Of > Pengshuping (Peng Shuping) > > > > > Sent: Wednesday, April 3, 2019 6:47 AM > > > > > To: Frank Brockners (fbrockne) ; > Mikael Abrahamsson > > > > > Cc: C. M. Heard ; 6man WG < > ipv6@ietf.org>; Mark Smith ; ippm@ietf.org > > > > > Subject: [ippm] =E7=AD=94=E5=A4=8D: > draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option > types for IOAM data fields) > > > > > > > > > > Hi, > > > > > > > > > > The parsing depth of the early chips is 96B/128B. > For the new chips the parsing depth has been increased but still limited. > So Mikael's concern makes sense especially in the tracing mode that the > IOAM data fields are going to increase significantly along the path, whic= h > will even push the Routing Header out of the parsing depth of the chip. S= o > it would make sense to split the IOAM data part from the IOAM > header/instruction part, and place the IOAM data after the RH or even aft= er > the L4 header in order to be able to read the L4 information to enable > ECMP, as stated in the draft > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= .ietf.org%2Fhtml%2Fdraft-li-6man-ipv6-sfc-ifit-00&data=3D02%7C01%7Cgbar= ak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4= d149256f461b%7C0%7C0%7C636898960379485833&sdata=3DDob4zN%2F1jSGxLTlqGma= 29JJNvqJDBt4VzqHsN4OpxM4%3D&reserved=3D0 > . > > > > > > > > > > BR, > > > > > Shuping > > > > > > > > > > > > > > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: ippm [mailto:ippm-bo= unces@ietf.org] =E4=BB=A3=E8=A1=A8 Frank > Brockners (fbrockne) > > > > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9= =B44=E6=9C=882=E6=97=A5 17:40 > > > > > =E6=94=B6=E4=BB=B6=E4=BA=BA: Mikael Abrahamsson <= swmike@swm.pp.se> > > > > > =E6=8A=84=E9=80=81: C. M. Heard = ; 6man WG < > ipv6@ietf.org>; Mark Smith ; ippm@ietf.org > > > > > =E4=B8=BB=E9=A2=98: Re: [ippm] > draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option > types for IOAM data fields) > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Mikael Abrahamsson > > > > > Sent: Dienstag, 2. April 2019 08:06 > > > > > To: Frank Brockners (fbrockne) > > > > > > Cc: Mark Smith ; C. M. > Heard ; 6man WG ; ippm@ietf.org > > > > > Subject: RE: > draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option > types for IOAM data fields) > > > > > > > > > > On Mon, 1 Apr 2019, Frank Brockners (fbrockne) > wrote: > > > > > > > > > > > ...FB: There is obviously no easy answer. Coupl= e > of thoughts: > > > > > > * IOAM is considered a "domain specific" featur= e > (see > > > > > > draft-ietf-ippm-ioam-data-05, section 3). > Routers in the IOAM domain > > > > > > should be IOAM capable. And IMHO, we should > add a statement to > > > > > > draft-ioametal-ippm-6man-ioam-ipv6-deployment > that an implementation > > > > > > of IOAM MUST ensure "C1". > > > > > > > > > > > > * That said, there can be situations, where C1 > cannot be achieved, e.g.. > > > > > > consider a network which does ECMP scheduling > based on packet length. > > > > > > > > > > > > * What one could consider - and which is one > suggested deployment > > > > > > model > > > > > > - is that by default IOAM data fields are added > to _all_ customer > > > > > > packets. The decapsulating node would decide > whether the IOAM > > > > > > information contained in a packet would be used > (and exported) or not. > > > > > > That way one would not need to deal with the > situation that some > > > > > > traffic carries IOAM while other does not - and > might thus be treated > > > > > > differently. > > > > > > > > > > Yes, I think this is the only way. Is there a ris= k > that intermediate routers would not be IOAM capable? I think the C1 > requirement is really really hard to fulfil and I'm also afraid that addi= ng > the IOAM header will actually make ECMP stop working on some platforms > (because they would not have the capability to look deep enough into the > packet to find L4 information, so it'll go back to 2 tuple ECMP instead o= f > 5 tuple. > > > > > > > > > > But this question can only be answered by people > with deep NPU knowledge... > > > > > > > > > > .....FB2: Given that IOAM is a domain specific > feature - I expect that folks initially start to use it in domains (like > e.g. a DC) where all boxes are IOAM capable and can trace the packet > appropriately - or per Tom's note, can be configured so that one would do > ECMP based on addresses and flow-label. There are chips with pretty deep > parsing capability (up to a few hundred bytes). > > > > > > > > > > > ...FB: The comparison to MPLS is interesting. > How often do MPLS > > > > > > packets leak and cause harm? For IOAM, > > > > > > draft-ioametal-ippm-6man-ioam-ipv6-options-02 > proposes a deployment > > > > > > model similar to what we do for MPLS: Unless an > interface is > > > > > > explicitly configured for IOAM, packets with > IOAM data fields MUST be dropped. > > > > > > Hence leakage would only occur, if we have a > clearly misbehaving > > > > > > router which violates this rule. Similar to you= , > I'd also greatly > > > > > > appreciate any pointers to research on how > common MPLS leaked packets are. > > > > > > > > > > When it comes to "cause harm" I imagine there are > (at least) two ways to cause harm, one is privacy/secrecy/security loss a= nd > the other one is actual operational loss. > > > > > > > > > > I know of bugs where labeled packets went the > wrong way and caused them to be lost, I've also seen bugs where bugs caus= ed > traffic to "hop" between VRFs in MPLS VPN (or to "global" VRF). I don't > have numbers on this though. > > > > > > > > > > Depending on the deployment scenario, it might > make sense to make IOAM packets not valid for non-IOAM aware devices > (basically encap entire packet/payload), but that might be a problem for > intermediate non-IOAM nodes then. This would affect the ECMP requirement.= I > can see cases where one would operationally turn on IOAM for some custome= rs > traffic and then see the problem go away because now ECMP changed. > > > > > > > > > > > ...FB: One idea that Shwetha came up with to > identify the source AS of > > > > > > a leaked packet, would be to add a new new IOAM > E2E option - as > > > > > > proposed in section 5.1.1 bullet 2 of > > > > > > draft-ioametal-ippm-6man-ioam-ipv6-deployment-0= 1. > > > > > > > > > > Yes, that'd solve that problem. > > > > > > > > > > How much has the silicon people been involved so > far in the design of the headers? What is the current thinking of amount = of > data going into the IOAM header? Considering things like trace options et= c > it seems to me the header can grow quite large? To satisfy the ECMP > requirement what about putting the IOAM information as a trailer behind t= he > regular payload? Or is there a problem for the hw to manipulate informati= on > that far into the packet (I also imagine this will considerably lower the > forwarding performance of IOAM packets on IOAM aware platforms). > > > > > > > > > > .....FB2: There are quite a few folks with > hardware background that co-author the IOAM drafts. Parsing capability > differs between chips, as does the ability to deal with new/flexible > headers and the ability to modify data in the extension headers. So the > unfortunate answer to that question is "it depends" (what information do > you gather, how large is your domain, what are the capabilities of your > hardware/software forwarder, etc.), but I do expect that for specific > deployment domains (e.g. DC, Enterprise) - but also for overlay networks = / > VPNs - we'll see an increasing amount of chips that are well suited for > processing large extension header. > > > > > > > > > > Cheers, Frank > > > > > > > > > > -- > > > > > Mikael Abrahamsson email: swmike@swm.pp.se > > > > > > > > > > _______________________________________________ > > > > > ippm mailing list > > > > > ippm@ietf.org > > > > > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cgbarak%40mellanox.= com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7= C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef3BJFz6AQNNAtk= gmAMDFKM%3D&reserved=3D0 > > > > > _______________________________________________ > > > > > ippm mailing list > > > > > ippm@ietf.org > > > > > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cgbarak%40mellanox.= com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7= C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef3BJFz6AQNNAtk= gmAMDFKM%3D&reserved=3D0 > > > > > > -------------------------------------------------------------------- > > > > > IETF IPv6 working group mailing list > > > > > ipv6@ietf.org > > > > > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > > > > > > -------------------------------------------------------------------- > > > > > > > > _______________________________________________ > > > > ippm mailing list > > > > ippm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ippm > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --0000000000008302570585cf41d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Apr 5, 2019, 2:07 PM Jai Kumar <jai.kumar@broadcom.com> wrote:
Tom,

Its all explained in the requirements section of the draft. IFA header is e= ssentially treated as an EH both in IPv4 and IPv6 (very similar to AH/ESP E= H).

Just like in AH/ESP the IP protocol is copied in the AH header and IP proto= col field is replaced in the IP header with the AH proto.

There are several advantages to this approach.
- devise know how to parse AH header and can follow very similar approach - Protocol agnostics, silicon need not support N encaps (just like AH/ESP).= Single implementation works for all protocol types.
- No need to creation options and teach devices that options is NOT an exce= ption path processing
- Really worry about ordering in IPv6 options
- Note that all the OAM data need to be deleted as well so position need to= be optimal for removal. We can always do tail stamping of the data but thi= s puts considerable constrains on the cell based architecture
- L4 accessibility I have already mentioned

I am happy to discuss with you in person and explain more but bottom line i= s that this proposal is what came out with MSDC discussions in light of sho= rtcomings from other IETF proposals.

As they say, you are free to run what= ever you want in your proprietary network, but if you expect to create an i= nteroperable, deployable protocoI and get a protocol number assignment, you= 'll need to work in ietf. That is going to require justifying the proto= col even in light of shortcomings in existing protocoIs.

Tom


Regards,
-Jai


=EF=BB=BFOn 4/5/19, 12:28 PM, "Tom Herbert" <tom@herbertland.= com> wrote:

=C2=A0 =C2=A0 On Fri, Apr 5, 2019 at 12:03 PM Jai Kumar <jai.kumar@b= roadcom.com> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > " Great, but this IETF"
=C2=A0 =C2=A0 > Does it mean that drafts have no relevance to deployment= and actual adoption.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > For all your queries please take a look at IFA draft. =C2=A0 =C2=A0 > https://datatrac= ker.ietf.org/doc/draft-kumar-ippm-ifa/
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 I've looked at that draft. It's is creating a complet= e new IP
=C2=A0 =C2=A0 protocolas well as a new packet format for TCP and UDP that s= omehow
=C2=A0 =C2=A0 inserts meta data between the TCP header and payload. I don&#= 39;t
=C2=A0 =C2=A0 understand why this could possibly be better than just using = flow
=C2=A0 =C2=A0 label for ECMP and teaching devices that need to extract tran= sport
=C2=A0 =C2=A0 information how to walk over EH, or just using some UDP encpa= sulation
=C2=A0 =C2=A0 like in draft-herbert-ipv4-udpencap-eh-01.

=C2=A0 =C2=A0 Tom

=C2=A0 =C2=A0 > It handles IPv6, IPv4 TCP/UDP with altering the packet p= ath (due to inserting options and/or encaping them in GRE header) as well a= s IPSec AH/ESP/WESP both tunnel and transport and guess what it is successf= ully deployed.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > -Jai
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > =EF=BB=BFOn 4/5/19, 11:54 AM, "Tom Herbert" &l= t;tom@herbertland.com> wrote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On Fri, Apr 5, 2019 at 11:25 AM Jai K= umar <jai.kumar@broadcom.com> wrote:
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> Tom,
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> I am speaking based on the actua= l deployment not based on if all the traffic is/will move to IPSec tunnel.<= br> =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> I have 6 large customer deployme= nts and one someone previously called as "Yahoo" who insist on vi= sibility in L4 even for IOAM packets.
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0And I've worked in datcenters muc= h larger, and my first rule is that I
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0don't want random router vendors = dictating to me what protocols I'm
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0allowed to use in my datacenter.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> I can quote you on that and lose= my business :-)
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> ECMP argument is weak as well as= it works for IPv6 flow label. What about IPv4 TCP/UDP traffic which typica= lly is 80% of the traffic in MSDC.
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0draft-herbert-ipv4-udpencap-eh-01
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> If someone tells me that proposa= l will work only for my 20% of traffic then again as I said before, they wi= ll lose my business :-)
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Great, but this IETF. Where are the p= rotocol requirements? If you are
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0saying that there are requirements fo= r "visibility in L4" what are
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0they? If you are saying that ACLs are= now required for packet
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0forwarding, where is that described? = Is it a MUST that teh only
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0transport protocols we're allowed= to use are=C2=A0 UDP or TCP? Are we
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0allowed to use extension headers at a= ll? I suppose fragmentation is
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0right out... Are we violating the req= uirements if we encrypt the
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0transport headers? If you say that we= shouldn't send long headers
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0because we'll overflow parsing bu= ffers, then what is the limit? Please
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0be SPECIFC in setting requirements; w= e are trying to build protocols
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0that work and are interoperable and w= e need to get out of this morass
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0of reverse engineering to discover th= e least common denominator.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Tom
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> Regards,
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> -Jai
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> =EF=BB=BFOn 4/5/19, 11:15 AM, &q= uot;Tom Herbert" <tom@herbertland.com> wrote:
=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=A0On Fri, Apr 5= , 2019 at 10:55 AM Jai Kumar <jai.kumar@broadcom.com> wrote:<= br> =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 =C2=A0 =C2=A0> Even if = we use flow label for ECMP, lack of accessibility of L4 information (for va= rious services, most simple is ACL) makes the proposal pretty much unusable= .
=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 =C2=A0 =C2=A0That is convo= luting router and firewall functionality and
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0requirements.= This a discussion about packet forwarding which does
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0_not_ require= ACLs. In a limited domain, for which IOAM is intended,
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0it is unlikel= y that they'll ACLs would be used in internal nodes, but
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0we do need go= od ECMP routing at all intermediate nodes need to be
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0consistent ra= ther or not that the IOAM option is present. As side
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0note, the abi= lity to extract L4 information out of packets is
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0dwindling any= way thanks to encryption and other techniques trying to
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0undo protocol= ossification. For instance, good luck getting L4
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0information o= ut of an IPsec tunnel :-).
=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=A0Tom
=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> NIC card= s are not used pervasively for ACLs and other services, I believe iptables = in kernel are good enough for host but that=E2=80=99s not acceptable in net= working elements.
=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 =C2=A0 =C2=A0> -Jai
=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 =C2=A0 =C2=A0> =EF=BB= =BFOn 4/5/19, 10:31 AM, "ippm on behalf of Tom Herbert" <ip= pm-bounces@ietf.org on behalf of tom@herbertland.com> wrote: =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 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0On Fri, Apr 5, 2019 at 9:16 AM Pengshuping (Peng Shuping)
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0<pengshuping@huawei.com> wrote:
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> Hi Barak,
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> We are certainly not designing for the lowest capable sol= utions but exploring optimal solutions which could help to keep the forward= ing performance while inserting the iOAM data with variable length.
=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 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0Shuping,
=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 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0That's exactly the argument for using the flow label in EC= MP.
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0Efficeint packet forwarding can be done solely by inspected th= e forty
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0byte fixed length header of the packet regardless of the conte= nts of
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0the rest of the packet. That is an optimal solution. Anything = else for
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0ECMP like doing DPI or hacking up IOAM to try do pull transpor= t layers
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0into the parsing buffer (whatever size that may be) are nothin= g more
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0than hacks and unnecessarily perpetuate techniques used with I= Pv4 that
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0either don't work or are unnecessary in IPv6.
=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 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0Tom
=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 =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 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> In terms of the forwarding efficiency, we would all agree= that a short and fixed header would be better than a variable header.
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> Best regards
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> Shuping
=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 =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 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Barak Gafni<gbar= ak@mellanox.com>
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Pengshuping (Peng Sh= uping)<pengshuping@huawei.com>;Frank Brockners (fbrockne)&l= t;fbrockne@cisco.com>;Mikael Abrahamsson<swmike@swm.pp.se> =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> =E6=8A=84=E9=80=81=EF=BC=9A C. M. Heard<heard@pobox.com>;6man WG<ipv6@ietf.org>;Mark Smith<markzzzsmith@gmail.com= >;ippm<ippm@ietf.org>
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> =E4=B8=BB=E9=A2=98=EF=BC=9A RE: draft-ioametal-ippm-6man-= ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields)=
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> =E6=97=B6=E9=97=B4=EF=BC=9A 2019-04-05 03:18:26
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> Hi Shuping,
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> I think that the question is whether we design for the lo= west capable solutions. I assume someone can find solutions with even lower= amount of parsing.. The low end solutions for these capabilities may need = to either adopt with new designs or use solutions such as what is suggested= in this thread by Tom Herbert.
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> Personally, I don't think we should go this way, but = to design appropriate solutions, with appropriate layers in the headers. Fo= r example, prevent dependencies between "remote" headers.
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> Thanks,
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> Barak
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> -----Original Message-----
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> From: ippm <ippm-bounces@ietf.org> On Behalf= Of Pengshuping (Peng Shuping)
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> Sent: Wednesday, April 3, 2019 6:47 AM
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> To: Frank Brockners (fbrockne) <fbrockne@cisco.com= >; Mikael Abrahamsson <swmike@swm.pp.se>
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> Cc: C. M. Heard <heard@pobox.com>; 6man WG <ipv6@iet= f.org>; Mark Smith <markzzzsmith@gmail.com>; ippm@ietf.or= g
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> Subject: [ippm] =E7=AD=94=E5=A4=8D: draft-ioametal-ippm-6= man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fie= lds)
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> Hi,
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> The parsing depth of the early chips is 96B/128B. For the= new chips the parsing depth has been increased but still limited. So Mikae= l's concern makes sense especially in the tracing mode that the IOAM da= ta fields are going to increase significantly along the path, which will ev= en push the Routing Header out of the parsing depth of the chip. So it woul= d make sense to split the IOAM data part from the IOAM header/instruction p= art, and place the IOAM data after the RH or even after the L4 header in or= der to be able to read the L4 information to enable ECMP, as stated in the = draft https://eur03.safelinks.prot= ection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-li-6m= an-ipv6-sfc-ifit-00&amp;data=3D02%7C01%7Cgbarak%40mellanox.com%7C612ba6= dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636= 898960379485833&amp;sdata=3DDob4zN%2F1jSGxLTlqGma29JJNvqJDBt4VzqHsN4Opx= M4%3D&amp;reserved=3D0.
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> BR,
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> Shuping
=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 =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 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> =E5=8F=91=E4=BB=B6=E4=BA=BA: ippm [mailto:ippm-bounces= @ietf.org] =E4=BB=A3=E8=A1=A8 Frank Brockners (fbrockne)
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B44=E6= =9C=882=E6=97=A5 17:40
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> =E6=94=B6=E4=BB=B6=E4=BA=BA: Mikael Abrahamsson <swmike@= swm.pp.se>
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> =E6=8A=84=E9=80=81: C. M. Heard <heard@pobox.com>;= 6man WG <ipv6@ietf.org>; Mark Smith <markzzzsmith@gmail.com>; ippm@ietf.org
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> =E4=B8=BB=E9=A2=98: Re: [ippm] draft-ioametal-ippm-6man-i= oam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields)<= br> =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 =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 =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 = =C2=A0 =C2=A0> -----Original Message-----
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> From: Mikael Abrahamsson <swmike@swm.pp.se>
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> Sent: Dienstag, 2. April 2019 08:06
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> To: Frank Brockners (fbrockne) <fbrockne@cisco.com= >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> Cc: Mark Smith <markzzzsmith@gmail.com>; C.= M. Heard <heard@pobox.com>; 6man WG <ipv6@ietf.org>; ippm@ietf.or= g
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> Subject: RE: draft-ioametal-ippm-6man-ioam-ipv6-deploymen= t-00 feedback (Re: v6 option types for IOAM data fields)
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> On Mon, 1 Apr 2019, Frank Brockners (fbrockne) wrote:
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > ...FB: There is obviously no easy answer. Couple of = thoughts:
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > * IOAM is considered a "domain specific" f= eature (see
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > draft-ietf-ippm-ioam-data-05, section 3). Routers in= the IOAM domain
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > should be IOAM capable.=C2=A0 And IMHO,=C2=A0 we sho= uld add a statement to
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > draft-ioametal-ippm-6man-ioam-ipv6-deployment that a= n implementation
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > of IOAM MUST ensure "C1".
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > * That said, there can be situations, where C1 canno= t be achieved, e.g..
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > consider a network which does ECMP scheduling based = on packet length.
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > * What one could consider - and which is one suggest= ed deployment
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > model
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > - is that by default IOAM data fields are added to _= all_ customer
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > packets. The decapsulating node would decide whether= the IOAM
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > information contained in a packet would be used (and= exported) or not.
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > That way one would not need to deal with the situati= on that some
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > traffic carries IOAM while other does not - and migh= t thus be treated
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > differently.
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> Yes, I think this is the only way. Is there a risk that i= ntermediate routers would not be IOAM capable? I think the C1 requirement i= s really really hard to fulfil and I'm also afraid that adding the IOAM= header will actually make ECMP stop working on some platforms (because the= y would not have the capability to look deep enough into the packet to find= L4 information, so it'll go back to 2 tuple ECMP instead of 5 tuple. =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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> But this question can only be answered by people with dee= p NPU knowledge...
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> .....FB2: Given that IOAM is a domain specific feature - = I expect that folks initially start to use it in domains (like e.g. a DC) w= here all boxes are IOAM capable and can trace the packet appropriately - or= per Tom's note, can be configured so that one would do ECMP based on a= ddresses and flow-label.=C2=A0 There are chips with pretty deep parsing cap= ability (up to a few hundred bytes).
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > ...FB: The comparison to MPLS is interesting. How of= ten do MPLS
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > packets leak and cause harm? For IOAM,
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > draft-ioametal-ippm-6man-ioam-ipv6-options-02 propos= es a deployment
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > model similar to what we do for MPLS: Unless an inte= rface is
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > explicitly configured for IOAM, packets with IOAM da= ta fields MUST be dropped.
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > Hence leakage would only occur, if we have a clearly= misbehaving
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > router which violates this rule. Similar to you, I&#= 39;d also greatly
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > appreciate any pointers to research on how common MP= LS leaked packets are.
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> When it comes to "cause harm" I imagine there a= re (at least) two ways to cause harm, one is privacy/secrecy/security loss = and the other one is actual operational loss.
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> I know of bugs where labeled packets went the wrong way a= nd caused them to be lost, I've also seen bugs where bugs caused traffi= c to "hop" between VRFs in MPLS VPN (or to "global" VRF= ). I don't have numbers on this though.
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> Depending on the deployment scenario, it might make sense= to make IOAM packets not valid for non-IOAM aware devices (basically encap= entire packet/payload), but that might be a problem for intermediate non-I= OAM nodes then. This would affect the ECMP requirement. I can see cases whe= re one would operationally turn on IOAM for some customers traffic and then= see the problem go away because now ECMP changed.
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > ...FB: One idea that Shwetha came up with to identif= y the source AS of
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > a leaked packet, would be to add a new new IOAM E2E = option - as
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > proposed in section 5.1.1 bullet 2 of
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > draft-ioametal-ippm-6man-ioam-ipv6-deployment-01. =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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> Yes, that'd solve that problem.
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> How much has the silicon people been involved so far in t= he design of the headers? What is the current thinking of amount of data go= ing into the IOAM header? Considering things like trace options etc it seem= s to me the header can grow quite large? To satisfy the ECMP requirement wh= at about putting the IOAM information as a trailer behind the regular paylo= ad? Or is there a problem for the hw to manipulate information that far int= o the packet (I also imagine this will considerably lower the forwarding pe= rformance of IOAM packets on IOAM aware platforms).
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> .....FB2: There are quite a few folks with hardware backg= round that co-author the IOAM drafts. Parsing capability differs between ch= ips, as does the ability to deal with new/flexible headers and the ability = to modify data in the extension headers. So the unfortunate answer to that = question is "it depends" (what information do you gather, how lar= ge is your domain, what are the capabilities of your hardware/software forw= arder, etc.), but I do expect that for specific deployment domains (e.g. DC= , Enterprise) - but also for overlay networks / VPNs - we'll see an inc= reasing amount of chips that are well suited for processing large extension= header.
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> Cheers, Frank
=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 =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 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> Mikael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se=
=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 =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 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> ippm mailing list
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> ippm@ietf.org
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> https://eur03.safelinks.protectio= n.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm= &amp;data=3D02%7C01%7Cgbarak%40mellanox.com%7C612ba6dc117440e68c4608d6b= 83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636898960379485833&= ;amp;sdata=3DVjZ1PiwifYGCf159je0yef3BJFz6AQNNAtkgmAMDFKM%3D&amp;reserve= d=3D0
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> ippm mailing list
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> ippm@ietf.org
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> https://eur03.safelinks.protectio= n.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm= &amp;data=3D02%7C01%7Cgbarak%40mellanox.com%7C612ba6dc117440e68c4608d6b= 83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636898960379485833&= ;amp;sdata=3DVjZ1PiwifYGCf159je0yef3BJFz6AQNNAtkgmAMDFKM%3D&amp;reserve= d=3D0
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> IETF IPv6 working group mailing list
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> ipv6@ietf.org
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> Administrative Requests: http= s://www.ietf.org/mailman/listinfo/ipv6
=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 =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 = =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=A0ippm mailing list
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0ippm@ietf.org
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0https://www.ietf.org/mailman/listi= nfo/ippm
=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 =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 =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 =C2=A0 >
=C2=A0 =C2=A0 >



--0000000000008302570585cf41d9-- From nobody Fri Apr 5 14:43:26 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3E3120620; Fri, 5 Apr 2019 14:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 zmIt5flI5EYk; Fri, 5 Apr 2019 14:43:12 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B1ED12061F; Fri, 5 Apr 2019 14:43:12 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id j10so7007881otq.0; Fri, 05 Apr 2019 14:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=DleTVSVQH6ModHWjBBo7OdKBq59mdUmvKQhsqjKOJT0=; b=NvyE5P+FJgvxizKVeKvcLyHN7HwfPC5glTqSOCUVrHvn9FQFQK7I51BanQfZTP7mGR /wsra1oYTLpYjxEeQjSTGuy6VXjRvIGT1gxdwN1dhzxz02Lb3zkRBURx6POeYWGsHIyj 0Mze7WABc0cLC2qU3ZBkFMDVOtl6evYUrc0xxvt3B7lUyMRy1+7bUk+/JBDSkaWDRYu4 SFND6PGY6Ts1pdhgRkfHDU1NE0myZqFKfFi/HAFGnIgxyBKLtRcmVQer+d6lZAH4vugs IJZVAKZ96cvI2OsHbLdsQXl1/Cnt4UgzYOFgz7hJSUl3Xf5n+JuctlNqZuPa0Bl1E6Jk KFCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=DleTVSVQH6ModHWjBBo7OdKBq59mdUmvKQhsqjKOJT0=; b=DByE+W6evq8xb2trEZ+exKUCEjUjW6QXXZVVeNUzwe8Q7EJ36hGwSNeUAFDkWRTph/ i8mumk9XhgtrLiH0w1kfONh3VecxKRiS0wX2mteONyKWKaVOd31gY34SN3jk5ofypm+p ht4INsygCpLV2S4oRhfioRkUYhgQ90rpTr87qLMYy2HG3Qd1LiLuuNRcAz8RIupWNVDx lKkiASBdhLOV+daf/XX5G8QG/UR0GN8pAGBE3qyM3fogyPBBsNv3iqjDYtllVZWUHMPD eEC+CmdTME1Rp6rGs090teKmysOsRxqft/hOKtPJcf/LV8eU+VCJh5E9nIh/qaInQZog cfBQ== X-Gm-Message-State: APjAAAX7xRRtnJ6O/UodXZ+IrOjgHFaqoOd0vxV5C4rVqHamcmbSwd+N yyhw3mIW08+dcGCVHOZdPCNxE5b/MSfwbiVg9mxCJA== X-Google-Smtp-Source: APXvYqwhr1Sx3a0GYc5NSOU6SjjPOQ5Y+SZ3IuSzoASKGMBizQGk29b0X0toDR9+c0Yha8fnWvI8jzoZhVb2cxojA4U= X-Received: by 2002:a05:6830:144e:: with SMTP id w14mr10806662otp.170.1554500591752; Fri, 05 Apr 2019 14:43:11 -0700 (PDT) MIME-Version: 1.0 References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> <4278D47A901B3041A737953BAA078ADE1478D5E2@DGGEML532-MBX.china.huawei.com> <4278D47A901B3041A737953BAA078ADE1478EC8B@DGGEML532-MBX.china.huawei.com> <14A3D5C9-1EED-4E11-9329-B62B819271A2@broadcom.com> <20D6FCDB-3357-4728-BD52-8069C32F3CCA@broadcom.com> In-Reply-To: From: Mark Smith Date: Sat, 6 Apr 2019 08:42:45 +1100 Message-ID: To: Tom Herbert Cc: Jai Kumar , "C. M. Heard" , 6man , ippm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 21:43:17 -0000 On Sat, 6 Apr 2019 at 08:35, Tom Herbert wrote: > > > > On Fri, Apr 5, 2019, 2:07 PM Jai Kumar wrote: >> >> Tom, >> >> Its all explained in the requirements section of the draft. IFA header i= s essentially treated as an EH both in IPv4 and IPv6 (very similar to AH/ES= P EH). >> >> Just like in AH/ESP the IP protocol is copied in the AH header and IP pr= otocol field is replaced in the IP header with the AH proto. >> >> There are several advantages to this approach. >> - devise know how to parse AH header and can follow very similar approac= h >> - Protocol agnostics, silicon need not support N encaps (just like AH/ES= P). Single implementation works for all protocol types. >> - No need to creation options and teach devices that options is NOT an e= xception path processing >> - Really worry about ordering in IPv6 options >> - Note that all the OAM data need to be deleted as well so position need= to be optimal for removal. We can always do tail stamping of the data but = this puts considerable constrains on the cell based architecture >> - L4 accessibility I have already mentioned >> >> I am happy to discuss with you in person and explain more but bottom lin= e is that this proposal is what came out with MSDC discussions in light of = shortcomings from other IETF proposals. > > > As they say, you are free to run whatever you want in your proprietary ne= twork, but if you expect to create an interoperable, deployable protocoI an= d get a protocol number assignment, you'll need to work in ietf. That is go= ing to require justifying the protocol even in light of shortcomings in exi= sting protocoIs. > And if it doesn't comply with the IPv6 protocol specification, you can't call it IPv6, even if the packet structure is the same. "closed domains" aren't a free for all for packet handing behaviour if you're also claiming protocol compliance. > Tom > >> >> Regards, >> -Jai >> >> >> =EF=BB=BFOn 4/5/19, 12:28 PM, "Tom Herbert" wrote: >> >> On Fri, Apr 5, 2019 at 12:03 PM Jai Kumar w= rote: >> > >> > " Great, but this IETF" >> > Does it mean that drafts have no relevance to deployment and actua= l adoption. >> > >> > For all your queries please take a look at IFA draft. >> > https://datatracker.ietf.org/doc/draft-kumar-ippm-ifa/ >> > >> I've looked at that draft. It's is creating a complete new IP >> protocolas well as a new packet format for TCP and UDP that somehow >> inserts meta data between the TCP header and payload. I don't >> understand why this could possibly be better than just using flow >> label for ECMP and teaching devices that need to extract transport >> information how to walk over EH, or just using some UDP encpasulatio= n >> like in draft-herbert-ipv4-udpencap-eh-01. >> >> Tom >> >> > It handles IPv6, IPv4 TCP/UDP with altering the packet path (due t= o inserting options and/or encaping them in GRE header) as well as IPSec AH= /ESP/WESP both tunnel and transport and guess what it is successfully deplo= yed. >> > >> > -Jai >> > >> > =EF=BB=BFOn 4/5/19, 11:54 AM, "Tom Herbert" = wrote: >> > >> > On Fri, Apr 5, 2019 at 11:25 AM Jai Kumar wrote: >> > > >> > > Tom, >> > > >> > > I am speaking based on the actual deployment not based on if= all the traffic is/will move to IPSec tunnel. >> > > >> > > I have 6 large customer deployments and one someone previous= ly called as "Yahoo" who insist on visibility in L4 even for IOAM packets. >> > > >> > And I've worked in datcenters much larger, and my first rule i= s that I >> > don't want random router vendors dictating to me what protocol= s I'm >> > allowed to use in my datacenter. >> > >> > > I can quote you on that and lose my business :-) >> > > >> > > ECMP argument is weak as well as it works for IPv6 flow labe= l. What about IPv4 TCP/UDP traffic which typically is 80% of the traffic in= MSDC. >> > > >> > >> > draft-herbert-ipv4-udpencap-eh-01 >> > >> > > If someone tells me that proposal will work only for my 20% = of traffic then again as I said before, they will lose my business :-) >> > > >> > Great, but this IETF. Where are the protocol requirements? If = you are >> > saying that there are requirements for "visibility in L4" what= are >> > they? If you are saying that ACLs are now required for packet >> > forwarding, where is that described? Is it a MUST that teh onl= y >> > transport protocols we're allowed to use are UDP or TCP? Are = we >> > allowed to use extension headers at all? I suppose fragmentati= on is >> > right out... Are we violating the requirements if we encrypt t= he >> > transport headers? If you say that we shouldn't send long head= ers >> > because we'll overflow parsing buffers, then what is the limit= ? Please >> > be SPECIFC in setting requirements; we are trying to build pro= tocols >> > that work and are interoperable and we need to get out of this= morass >> > of reverse engineering to discover the least common denominato= r. >> > >> > Tom >> > >> > > Regards, >> > > -Jai >> > > >> > > =EF=BB=BFOn 4/5/19, 11:15 AM, "Tom Herbert" wrote: >> > > >> > > On Fri, Apr 5, 2019 at 10:55 AM Jai Kumar wrote: >> > > > >> > > > Even if we use flow label for ECMP, lack of accessibil= ity of L4 information (for various services, most simple is ACL) makes the = proposal pretty much unusable.. >> > > > >> > > That is convoluting router and firewall functionality an= d >> > > requirements. This a discussion about packet forwarding = which does >> > > _not_ require ACLs. In a limited domain, for which IOAM = is intended, >> > > it is unlikely that they'll ACLs would be used in intern= al nodes, but >> > > we do need good ECMP routing at all intermediate nodes n= eed to be >> > > consistent rather or not that the IOAM option is present= . As side >> > > note, the ability to extract L4 information out of packe= ts is >> > > dwindling anyway thanks to encryption and other techniqu= es trying to >> > > undo protocol ossification. For instance, good luck gett= ing L4 >> > > information out of an IPsec tunnel :-). >> > > >> > > Tom >> > > >> > > > NIC cards are not used pervasively for ACLs and other = services, I believe iptables in kernel are good enough for host but that=E2= =80=99s not acceptable in networking elements. >> > > > >> > > > -Jai >> > > > >> > > > =EF=BB=BFOn 4/5/19, 10:31 AM, "ippm on behalf of Tom H= erbert" wrote: >> > > > >> > > > On Fri, Apr 5, 2019 at 9:16 AM Pengshuping (Peng S= huping) >> > > > wrote: >> > > > > >> > > > > Hi Barak, >> > > > > >> > > > > We are certainly not designing for the lowest ca= pable solutions but exploring optimal solutions which could help to keep th= e forwarding performance while inserting the iOAM data with variable length= . >> > > > >> > > > Shuping, >> > > > >> > > > That's exactly the argument for using the flow lab= el in ECMP. >> > > > Efficeint packet forwarding can be done solely by = inspected the forty >> > > > byte fixed length header of the packet regardless = of the contents of >> > > > the rest of the packet. That is an optimal solutio= n. Anything else for >> > > > ECMP like doing DPI or hacking up IOAM to try do p= ull transport layers >> > > > into the parsing buffer (whatever size that may be= ) are nothing more >> > > > than hacks and unnecessarily perpetuate techniques= used with IPv4 that >> > > > either don't work or are unnecessary in IPv6. >> > > > >> > > > Tom >> > > > >> > > > >> > > > > >> > > > > In terms of the forwarding efficiency, we would = all agree that a short and fixed header would be better than a variable hea= der. >> > > > > >> > > > > Best regards >> > > > > Shuping >> > > > > >> > > > > >> > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Barak Gafni= >> > > > > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Pengshuping= (Peng Shuping);Frank Brockners (fbrockne);Mikael Abrahamsson >> > > > > =E6=8A=84=E9=80=81=EF=BC=9A C. M. Heard;6man WG;Mark Smith;ippm >> > > > > =E4=B8=BB=E9=A2=98=EF=BC=9A RE: draft-ioametal-i= ppm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM dat= a fields) >> > > > > =E6=97=B6=E9=97=B4=EF=BC=9A 2019-04-05 03:18:26 >> > > > > >> > > > > Hi Shuping, >> > > > > I think that the question is whether we design f= or the lowest capable solutions. I assume someone can find solutions with e= ven lower amount of parsing.. The low end solutions for these capabilities = may need to either adopt with new designs or use solutions such as what is = suggested in this thread by Tom Herbert. >> > > > > Personally, I don't think we should go this way,= but to design appropriate solutions, with appropriate layers in the header= s. For example, prevent dependencies between "remote" headers. >> > > > > >> > > > > Thanks, >> > > > > Barak >> > > > > >> > > > > -----Original Message----- >> > > > > From: ippm On Behalf Of = Pengshuping (Peng Shuping) >> > > > > Sent: Wednesday, April 3, 2019 6:47 AM >> > > > > To: Frank Brockners (fbrockne) ; Mikael Abrahamsson >> > > > > Cc: C. M. Heard ; 6man WG ; Mark Smith ; ippm@ietf.org >> > > > > Subject: [ippm] =E7=AD=94=E5=A4=8D: draft-ioamet= al-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM= data fields) >> > > > > >> > > > > Hi, >> > > > > >> > > > > The parsing depth of the early chips is 96B/128B= . For the new chips the parsing depth has been increased but still limited.= So Mikael's concern makes sense especially in the tracing mode that the IO= AM data fields are going to increase significantly along the path, which wi= ll even push the Routing Header out of the parsing depth of the chip. So it= would make sense to split the IOAM data part from the IOAM header/instruct= ion part, and place the IOAM data after the RH or even after the L4 header = in order to be able to read the L4 information to enable ECMP, as stated in= the draft https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2= F%2Ftools.ietf.org%2Fhtml%2Fdraft-li-6man-ipv6-sfc-ifit-00&data=3D02%7C= 01%7Cgbarak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2= e4d9ba6a4d149256f461b%7C0%7C0%7C636898960379485833&sdata=3DDob4zN%2F1jS= GxLTlqGma29JJNvqJDBt4VzqHsN4OpxM4%3D&reserved=3D0. >> > > > > >> > > > > BR, >> > > > > Shuping >> > > > > >> > > > > >> > > > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >> > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: ippm [mailto:ippm-b= ounces@ietf.org] =E4=BB=A3=E8=A1=A8 Frank Brockners (fbrockne) >> > > > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9= =B44=E6=9C=882=E6=97=A5 17:40 >> > > > > =E6=94=B6=E4=BB=B6=E4=BA=BA: Mikael Abrahamsson = >> > > > > =E6=8A=84=E9=80=81: C. M. Heard ; 6man WG ; Mark Smith ; ippm@ietf.= org >> > > > > =E4=B8=BB=E9=A2=98: Re: [ippm] draft-ioametal-ip= pm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data= fields) >> > > > > >> > > > > >> > > > > >> > > > > -----Original Message----- >> > > > > From: Mikael Abrahamsson >> > > > > Sent: Dienstag, 2. April 2019 08:06 >> > > > > To: Frank Brockners (fbrockne) >> > > > > Cc: Mark Smith ; C. M. H= eard ; 6man WG ; ippm@ietf.org >> > > > > Subject: RE: draft-ioametal-ippm-6man-ioam-ipv6-= deployment-00 feedback (Re: v6 option types for IOAM data fields) >> > > > > >> > > > > On Mon, 1 Apr 2019, Frank Brockners (fbrockne) w= rote: >> > > > > >> > > > > > ...FB: There is obviously no easy answer. Coup= le of thoughts: >> > > > > > * IOAM is considered a "domain specific" featu= re (see >> > > > > > draft-ietf-ippm-ioam-data-05, section 3). Rout= ers in the IOAM domain >> > > > > > should be IOAM capable. And IMHO, we should = add a statement to >> > > > > > draft-ioametal-ippm-6man-ioam-ipv6-deployment = that an implementation >> > > > > > of IOAM MUST ensure "C1". >> > > > > > >> > > > > > * That said, there can be situations, where C1= cannot be achieved, e.g.. >> > > > > > consider a network which does ECMP scheduling = based on packet length. >> > > > > > >> > > > > > * What one could consider - and which is one s= uggested deployment >> > > > > > model >> > > > > > - is that by default IOAM data fields are adde= d to _all_ customer >> > > > > > packets. The decapsulating node would decide w= hether the IOAM >> > > > > > information contained in a packet would be use= d (and exported) or not. >> > > > > > That way one would not need to deal with the s= ituation that some >> > > > > > traffic carries IOAM while other does not - an= d might thus be treated >> > > > > > differently. >> > > > > >> > > > > Yes, I think this is the only way. Is there a ri= sk that intermediate routers would not be IOAM capable? I think the C1 requ= irement is really really hard to fulfil and I'm also afraid that adding the= IOAM header will actually make ECMP stop working on some platforms (becaus= e they would not have the capability to look deep enough into the packet to= find L4 information, so it'll go back to 2 tuple ECMP instead of 5 tuple. >> > > > > >> > > > > But this question can only be answered by people= with deep NPU knowledge... >> > > > > >> > > > > .....FB2: Given that IOAM is a domain specific f= eature - I expect that folks initially start to use it in domains (like e.g= . a DC) where all boxes are IOAM capable and can trace the packet appropria= tely - or per Tom's note, can be configured so that one would do ECMP based= on addresses and flow-label. There are chips with pretty deep parsing cap= ability (up to a few hundred bytes). >> > > > > >> > > > > > ...FB: The comparison to MPLS is interesting. = How often do MPLS >> > > > > > packets leak and cause harm? For IOAM, >> > > > > > draft-ioametal-ippm-6man-ioam-ipv6-options-02 = proposes a deployment >> > > > > > model similar to what we do for MPLS: Unless a= n interface is >> > > > > > explicitly configured for IOAM, packets with I= OAM data fields MUST be dropped. >> > > > > > Hence leakage would only occur, if we have a c= learly misbehaving >> > > > > > router which violates this rule. Similar to yo= u, I'd also greatly >> > > > > > appreciate any pointers to research on how com= mon MPLS leaked packets are. >> > > > > >> > > > > When it comes to "cause harm" I imagine there ar= e (at least) two ways to cause harm, one is privacy/secrecy/security loss a= nd the other one is actual operational loss. >> > > > > >> > > > > I know of bugs where labeled packets went the wr= ong way and caused them to be lost, I've also seen bugs where bugs caused t= raffic to "hop" between VRFs in MPLS VPN (or to "global" VRF). I don't have= numbers on this though. >> > > > > >> > > > > Depending on the deployment scenario, it might m= ake sense to make IOAM packets not valid for non-IOAM aware devices (basica= lly encap entire packet/payload), but that might be a problem for intermedi= ate non-IOAM nodes then. This would affect the ECMP requirement. I can see = cases where one would operationally turn on IOAM for some customers traffic= and then see the problem go away because now ECMP changed. >> > > > > >> > > > > > ...FB: One idea that Shwetha came up with to i= dentify the source AS of >> > > > > > a leaked packet, would be to add a new new IOA= M E2E option - as >> > > > > > proposed in section 5.1.1 bullet 2 of >> > > > > > draft-ioametal-ippm-6man-ioam-ipv6-deployment-= 01. >> > > > > >> > > > > Yes, that'd solve that problem. >> > > > > >> > > > > How much has the silicon people been involved so= far in the design of the headers? What is the current thinking of amount o= f data going into the IOAM header? Considering things like trace options et= c it seems to me the header can grow quite large? To satisfy the ECMP requi= rement what about putting the IOAM information as a trailer behind the regu= lar payload? Or is there a problem for the hw to manipulate information tha= t far into the packet (I also imagine this will considerably lower the forw= arding performance of IOAM packets on IOAM aware platforms). >> > > > > >> > > > > .....FB2: There are quite a few folks with hardw= are background that co-author the IOAM drafts. Parsing capability differs b= etween chips, as does the ability to deal with new/flexible headers and the= ability to modify data in the extension headers. So the unfortunate answer= to that question is "it depends" (what information do you gather, how larg= e is your domain, what are the capabilities of your hardware/software forwa= rder, etc.), but I do expect that for specific deployment domains (e.g. DC,= Enterprise) - but also for overlay networks / VPNs - we'll see an increasi= ng amount of chips that are well suited for processing large extension head= er. >> > > > > >> > > > > Cheers, Frank >> > > > > >> > > > > -- >> > > > > Mikael Abrahamsson email: swmike@swm.pp.se >> > > > > >> > > > > _______________________________________________ >> > > > > ippm mailing list >> > > > > ippm@ietf.org >> > > > > https://eur03.safelinks.protection.outlook.com/?= url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%= 7C01%7Cgbarak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7= d2e4d9ba6a4d149256f461b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifY= GCf159je0yef3BJFz6AQNNAtkgmAMDFKM%3D&reserved=3D0 >> > > > > _______________________________________________ >> > > > > ippm mailing list >> > > > > ippm@ietf.org >> > > > > https://eur03.safelinks.protection.outlook.com/?= url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%= 7C01%7Cgbarak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7= d2e4d9ba6a4d149256f461b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifY= GCf159je0yef3BJFz6AQNNAtkgmAMDFKM%3D&reserved=3D0 >> > > > > ------------------------------------------------= -------------------- >> > > > > IETF IPv6 working group mailing list >> > > > > ipv6@ietf.org >> > > > > Administrative Requests: https://www.ietf.org/ma= ilman/listinfo/ipv6 >> > > > > ------------------------------------------------= -------------------- >> > > > >> > > > _______________________________________________ >> > > > ippm mailing list >> > > > ippm@ietf.org >> > > > https://www.ietf.org/mailman/listinfo/ippm >> > > > >> > > > >> > > > >> > > >> > > >> > > >> > >> > >> > >> >> >> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Apr 5 15:09:27 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BAA0120188 for ; Fri, 5 Apr 2019 15:09:25 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.com 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 OEhDN8_NaVoH for ; Fri, 5 Apr 2019 15:09:21 -0700 (PDT) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 763FF12004C for ; Fri, 5 Apr 2019 15:09:21 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id p6so3748605pgh.9 for ; Fri, 05 Apr 2019 15:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=K+9RbHGPSO/Tcts9Y3NVqKaGPMd8qFOwSUu4cGTM6CE=; b=Yf2s6CwspM0We6xScK93x/NcyapwkdlIRYVGuClB74D3j3dZWMZrPjE7dyy+zT8o2g h9fX5aCGoSh5pib+jyuJl0E1MhTsUcnazagLdZrjRXPan0RoGwICvRK/5HZu7XvdKDR9 XVwHTrUi28VqShQhtX18ISZTa0r6JUvHSawrQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=K+9RbHGPSO/Tcts9Y3NVqKaGPMd8qFOwSUu4cGTM6CE=; b=AuzK35FFuuHqz5gZVNTeyXMPB0qY8k0eVatHeIlNsYtnwkWbzveAU9ZlKRL3TnrDrs 0YIV0DJGEw7YKRApZep/u/NwWgiC5ue7pVZipSVOzjQnIVgO2RHHgOxQl9cF4KAGrfVP Bp8rfW2CSIOtQkSW9Xj+FHm0Y7HUCrG8Xw+m/mIBgckKRN3JVDGbu1WdMhpmtsTB7Ibb DZCkHQqC+JRQgbd+TooRcqnPR9veAq1v1PrZLvzMz75ODgoJ70gOo0Rf8L7WCnXlAxRW Gpzq8oxhyhRpMn4jgswqzdfhTwOkLO/r3AWh8AzP1umVSCum6JDMQy5/rptN+OkW6i2S Ji/g== X-Gm-Message-State: APjAAAVPJd8bi7yaJgVWoA8LC7LOGxp0svxecUfZchStZEfPDgoFfV9k aj66fyM1nKf6zV6A5Xyf7neazg== X-Google-Smtp-Source: APXvYqwz9kUqnCaKFW4sD9UYVnNNuNuSpcNr96vBEnihRbjEVfUsLH9sZFAvVaOHljNGx1TINVvHfA== X-Received: by 2002:a62:6504:: with SMTP id z4mr15253515pfb.202.1554502160690; Fri, 05 Apr 2019 15:09:20 -0700 (PDT) Received: from [10.58.68.119] ([192.19.222.250]) by smtp.gmail.com with ESMTPSA id s4sm25904494pgp.89.2019.04.05.15.09.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Apr 2019 15:09:19 -0700 (PDT) User-Agent: Microsoft-MacOutlook/10.17.1.190326 Date: Fri, 05 Apr 2019 15:09:18 -0700 From: Jai Kumar To: Tom Herbert CC: "Pengshuping (Peng Shuping)" , 6man , ippm , "C. M. Heard" , Mikael Abrahamsson Message-ID: <57A32C37-AAE9-44F2-9C96-39AFA71BDC21@broadcom.com> Thread-Topic: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> <4278D47A901B3041A737953BAA078ADE1478D5E2@DGGEML532-MBX.china.huawei.com> <4278D47A901B3041A737953BAA078ADE1478EC8B@DGGEML532-MBX.china.huawei.com> <14A3D5C9-1EED-4E11-9329-B62B819271A2@broadcom.com> <20D6FCDB-3357-4728-BD52-8069C32F3CCA@broadcom.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3637321759_530724765" Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 22:09:26 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3637321759_530724765 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable =E2=80=9CThat is going to require justifying the protocol even in light of shortc= omings in existing protocoIs.=E2=80=9D =20 Agreed !!! True for any proposal. =20 -Jai =20 From: Tom Herbert Date: Friday, April 5, 2019 at 2:34 PM To: Jai Kumar Cc: "Pengshuping (Peng Shuping)" , 6man , ippm , "C. M. Heard" , Mikael Abrahams= son Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedba= ck (Re: v6 option types for IOAM data fields) =20 =20 On Fri, Apr 5, 2019, 2:07 PM Jai Kumar wrote: Tom, Its all explained in the requirements section of the draft. IFA header is e= ssentially treated as an EH both in IPv4 and IPv6 (very similar to AH/ESP EH= ). Just like in AH/ESP the IP protocol is copied in the AH header and IP proto= col field is replaced in the IP header with the AH proto. There are several advantages to this approach. - devise know how to parse AH header and can follow very similar approach - Protocol agnostics, silicon need not support N encaps (just like AH/ESP).= Single implementation works for all protocol types. - No need to creation options and teach devices that options is NOT an exce= ption path processing - Really worry about ordering in IPv6 options - Note that all the OAM data need to be deleted as well so position need to= be optimal for removal. We can always do tail stamping of the data but this= puts considerable constrains on the cell based architecture - L4 accessibility I have already mentioned I am happy to discuss with you in person and explain more but bottom line i= s that this proposal is what came out with MSDC discussions in light of shor= tcomings from other IETF proposals. =20 As they say, you are free to run whatever you want in your proprietary netw= ork, but if you expect to create an interoperable, deployable protocoI and g= et a protocol number assignment, you'll need to work in ietf. That is going = to require justifying the protocol even in light of shortcomings in existing= protocoIs. =20 Tom =20 Regards, -Jai =EF=BB=BFOn 4/5/19, 12:28 PM, "Tom Herbert" wrote: On Fri, Apr 5, 2019 at 12:03 PM Jai Kumar wrot= e: > > " Great, but this IETF" > Does it mean that drafts have no relevance to deployment and actual a= doption. > > For all your queries please take a look at IFA draft. > https://datatracker.ietf.org/doc/draft-kumar-ippm-ifa/ > I've looked at that draft. It's is creating a complete new IP protocolas well as a new packet format for TCP and UDP that somehow inserts meta data between the TCP header and payload. I don't understand why this could possibly be better than just using flow label for ECMP and teaching devices that need to extract transport information how to walk over EH, or just using some UDP encpasulation like in draft-herbert-ipv4-udpencap-eh-01. Tom > It handles IPv6, IPv4 TCP/UDP with altering the packet path (due to i= nserting options and/or encaping them in GRE header) as well as IPSec AH/ESP= /WESP both tunnel and transport and guess what it is successfully deployed. > > -Jai > > =EF=BB=BFOn 4/5/19, 11:54 AM, "Tom Herbert" wrote: > > On Fri, Apr 5, 2019 at 11:25 AM Jai Kumar wrote: > > > > Tom, > > > > I am speaking based on the actual deployment not based on if al= l the traffic is/will move to IPSec tunnel. > > > > I have 6 large customer deployments and one someone previously = called as "Yahoo" who insist on visibility in L4 even for IOAM packets. > > > And I've worked in datcenters much larger, and my first rule is t= hat I > don't want random router vendors dictating to me what protocols I= 'm > allowed to use in my datacenter. > > > I can quote you on that and lose my business :-) > > > > ECMP argument is weak as well as it works for IPv6 flow label. = What about IPv4 TCP/UDP traffic which typically is 80% of the traffic in MSD= C. > > > > draft-herbert-ipv4-udpencap-eh-01 > > > If someone tells me that proposal will work only for my 20% of = traffic then again as I said before, they will lose my business :-) > > > Great, but this IETF. Where are the protocol requirements? If you= are > saying that there are requirements for "visibility in L4" what ar= e > they? If you are saying that ACLs are now required for packet > forwarding, where is that described? Is it a MUST that teh only > transport protocols we're allowed to use are UDP or TCP? Are we > allowed to use extension headers at all? I suppose fragmentation = is > right out... Are we violating the requirements if we encrypt the > transport headers? If you say that we shouldn't send long headers > because we'll overflow parsing buffers, then what is the limit? P= lease > be SPECIFC in setting requirements; we are trying to build protoc= ols > that work and are interoperable and we need to get out of this mo= rass > of reverse engineering to discover the least common denominator. > > Tom > > > Regards, > > -Jai > > > > =EF=BB=BFOn 4/5/19, 11:15 AM, "Tom Herbert" wro= te: > > > > On Fri, Apr 5, 2019 at 10:55 AM Jai Kumar wrote: > > > > > > Even if we use flow label for ECMP, lack of accessibility= of L4 information (for various services, most simple is ACL) makes the prop= osal pretty much unusable. > > > > > That is convoluting router and firewall functionality and > > requirements. This a discussion about packet forwarding whi= ch does > > _not_ require ACLs. In a limited domain, for which IOAM is = intended, > > it is unlikely that they'll ACLs would be used in internal = nodes, but > > we do need good ECMP routing at all intermediate nodes need= to be > > consistent rather or not that the IOAM option is present. A= s side > > note, the ability to extract L4 information out of packets = is > > dwindling anyway thanks to encryption and other techniques = trying to > > undo protocol ossification. For instance, good luck getting= L4 > > information out of an IPsec tunnel :-). > > > > Tom > > > > > NIC cards are not used pervasively for ACLs and other ser= vices, I believe iptables in kernel are good enough for host but that=E2=80=99s no= t acceptable in networking elements. > > > > > > -Jai > > > > > > =EF=BB=BFOn 4/5/19, 10:31 AM, "ippm on behalf of Tom Herbert" <= ippm-bounces@ietf.org on behalf of tom@herbertland.com> wrote: > > > > > > On Fri, Apr 5, 2019 at 9:16 AM Pengshuping (Peng Shup= ing) > > > wrote: > > > > > > > > Hi Barak, > > > > > > > > We are certainly not designing for the lowest capab= le solutions but exploring optimal solutions which could help to keep the fo= rwarding performance while inserting the iOAM data with variable length. > > > > > > Shuping, > > > > > > That's exactly the argument for using the flow label = in ECMP. > > > Efficeint packet forwarding can be done solely by ins= pected the forty > > > byte fixed length header of the packet regardless of = the contents of > > > the rest of the packet. That is an optimal solution. = Anything else for > > > ECMP like doing DPI or hacking up IOAM to try do pull= transport layers > > > into the parsing buffer (whatever size that may be) a= re nothing more > > > than hacks and unnecessarily perpetuate techniques us= ed with IPv4 that > > > either don't work or are unnecessary in IPv6. > > > > > > Tom > > > > > > > > > > > > > > In terms of the forwarding efficiency, we would all= agree that a short and fixed header would be better than a variable header. > > > > > > > > Best regards > > > > Shuping > > > > > > > > > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Barak Gafni > > > > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Pengshuping (Peng Shuping);Frank Brockners (fbrockne);Mikael Abrahamss= on > > > > =E6=8A=84=E9=80=81=EF=BC=9A C. M. Heard;6man WG;Mark Smith;ippm > > > > =E4=B8=BB=E9=A2=98=EF=BC=9A RE: draft-ioametal-ippm-6man-ioam-ipv6-de= ployment-00 feedback (Re: v6 option types for IOAM data fields) > > > > =E6=97=B6=E9=97=B4=EF=BC=9A 2019-04-05 03:18:26 > > > > > > > > Hi Shuping, > > > > I think that the question is whether we design for = the lowest capable solutions. I assume someone can find solutions with even = lower amount of parsing.. The low end solutions for these capabilities may n= eed to either adopt with new designs or use solutions such as what is sugges= ted in this thread by Tom Herbert. > > > > Personally, I don't think we should go this way, bu= t to design appropriate solutions, with appropriate layers in the headers. F= or example, prevent dependencies between "remote" headers. > > > > > > > > Thanks, > > > > Barak > > > > > > > > -----Original Message----- > > > > From: ippm On Behalf Of Pen= gshuping (Peng Shuping) > > > > Sent: Wednesday, April 3, 2019 6:47 AM > > > > To: Frank Brockners (fbrockne) = ; Mikael Abrahamsson > > > > Cc: C. M. Heard ; 6man WG ; Mark Smith ; ippm@ietf.org > > > > Subject: [ippm] =E7=AD=94=E5=A4=8D: draft-ioametal-ippm-6man-io= am-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) > > > > > > > > Hi, > > > > > > > > The parsing depth of the early chips is 96B/128B. F= or the new chips the parsing depth has been increased but still limited. So = Mikael's concern makes sense especially in the tracing mode that the IOAM da= ta fields are going to increase significantly along the path, which will eve= n push the Routing Header out of the parsing depth of the chip. So it would = make sense to split the IOAM data part from the IOAM header/instruction part= , and place the IOAM data after the RH or even after the L4 header in order = to be able to read the L4 information to enable ECMP, as stated in the draft= https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.iet= f.org%2Fhtml%2Fdraft-li-6man-ipv6-sfc-ifit-00&data=3D02%7C01%7Cgbarak%40me= llanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f= 461b%7C0%7C0%7C636898960379485833&sdata=3DDob4zN%2F1jSGxLTlqGma29JJNvqJDBt= 4VzqHsN4OpxM4%3D&reserved=3D0. > > > > > > > > BR, > > > > Shuping > > > > > > > > > > > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: ippm [mailto:ippm-bounces@ietf.org] =E4=BB=A3=E8= =A1=A8 Frank Brockners (fbrockne) > > > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B44=E6=9C=882=E6=97=A5 17:40 > > > > =E6=94=B6=E4=BB=B6=E4=BA=BA: Mikael Abrahamsson > > > > =E6=8A=84=E9=80=81: C. M. Heard ; 6man WG ; Mark Smith ; ippm@ietf.org > > > > =E4=B8=BB=E9=A2=98: Re: [ippm] draft-ioametal-ippm-6man-ioam-ip= v6-deployment-00 feedback (Re: v6 option types for IOAM data fields) > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Mikael Abrahamsson > > > > Sent: Dienstag, 2. April 2019 08:06 > > > > To: Frank Brockners (fbrockne) > > > > Cc: Mark Smith ; C. M. Hear= d ; 6man WG ; ippm@ietf.org > > > > Subject: RE: draft-ioametal-ippm-6man-ioam-ipv6-dep= loyment-00 feedback (Re: v6 option types for IOAM data fields) > > > > > > > > On Mon, 1 Apr 2019, Frank Brockners (fbrockne) wrot= e: > > > > > > > > > ...FB: There is obviously no easy answer. Couple = of thoughts: > > > > > * IOAM is considered a "domain specific" feature = (see > > > > > draft-ietf-ippm-ioam-data-05, section 3). Routers= in the IOAM domain > > > > > should be IOAM capable. And IMHO, we should add= a statement to > > > > > draft-ioametal-ippm-6man-ioam-ipv6-deployment tha= t an implementation > > > > > of IOAM MUST ensure "C1". > > > > > > > > > > * That said, there can be situations, where C1 ca= nnot be achieved, e.g.. > > > > > consider a network which does ECMP scheduling bas= ed on packet length. > > > > > > > > > > * What one could consider - and which is one sugg= ested deployment > > > > > model > > > > > - is that by default IOAM data fields are added t= o _all_ customer > > > > > packets. The decapsulating node would decide whet= her the IOAM > > > > > information contained in a packet would be used (= and exported) or not. > > > > > That way one would not need to deal with the situ= ation that some > > > > > traffic carries IOAM while other does not - and m= ight thus be treated > > > > > differently. > > > > > > > > Yes, I think this is the only way. Is there a risk = that intermediate routers would not be IOAM capable? I think the C1 requirem= ent is really really hard to fulfil and I'm also afraid that adding the IOAM= header will actually make ECMP stop working on some platforms (because they= would not have the capability to look deep enough into the packet to find L= 4 information, so it'll go back to 2 tuple ECMP instead of 5 tuple. > > > > > > > > But this question can only be answered by people wi= th deep NPU knowledge... > > > > > > > > .....FB2: Given that IOAM is a domain specific feat= ure - I expect that folks initially start to use it in domains (like e.g. a = DC) where all boxes are IOAM capable and can trace the packet appropriately = - or per Tom's note, can be configured so that one would do ECMP based on ad= dresses and flow-label. There are chips with pretty deep parsing capability= (up to a few hundred bytes). > > > > > > > > > ...FB: The comparison to MPLS is interesting. How= often do MPLS > > > > > packets leak and cause harm? For IOAM, > > > > > draft-ioametal-ippm-6man-ioam-ipv6-options-02 pro= poses a deployment > > > > > model similar to what we do for MPLS: Unless an i= nterface is > > > > > explicitly configured for IOAM, packets with IOAM= data fields MUST be dropped. > > > > > Hence leakage would only occur, if we have a clea= rly misbehaving > > > > > router which violates this rule. Similar to you, = I'd also greatly > > > > > appreciate any pointers to research on how common= MPLS leaked packets are. > > > > > > > > When it comes to "cause harm" I imagine there are (= at least) two ways to cause harm, one is privacy/secrecy/security loss and t= he other one is actual operational loss. > > > > > > > > I know of bugs where labeled packets went the wrong= way and caused them to be lost, I've also seen bugs where bugs caused traff= ic to "hop" between VRFs in MPLS VPN (or to "global" VRF). I don't have numb= ers on this though. > > > > > > > > Depending on the deployment scenario, it might make= sense to make IOAM packets not valid for non-IOAM aware devices (basically = encap entire packet/payload), but that might be a problem for intermediate n= on-IOAM nodes then. This would affect the ECMP requirement. I can see cases = where one would operationally turn on IOAM for some customers traffic and th= en see the problem go away because now ECMP changed. > > > > > > > > > ...FB: One idea that Shwetha came up with to iden= tify the source AS of > > > > > a leaked packet, would be to add a new new IOAM E= 2E option - as > > > > > proposed in section 5.1.1 bullet 2 of > > > > > draft-ioametal-ippm-6man-ioam-ipv6-deployment-01. > > > > > > > > Yes, that'd solve that problem. > > > > > > > > How much has the silicon people been involved so fa= r in the design of the headers? What is the current thinking of amount of da= ta going into the IOAM header? Considering things like trace options etc it = seems to me the header can grow quite large? To satisfy the ECMP requirement= what about putting the IOAM information as a trailer behind the regular pay= load? Or is there a problem for the hw to manipulate information that far in= to the packet (I also imagine this will considerably lower the forwarding pe= rformance of IOAM packets on IOAM aware platforms). > > > > > > > > .....FB2: There are quite a few folks with hardware= background that co-author the IOAM drafts. Parsing capability differs betwe= en chips, as does the ability to deal with new/flexible headers and the abil= ity to modify data in the extension headers. So the unfortunate answer to th= at question is "it depends" (what information do you gather, how large is yo= ur domain, what are the capabilities of your hardware/software forwarder, et= c.), but I do expect that for specific deployment domains (e.g. DC, Enterpri= se) - but also for overlay networks / VPNs - we'll see an increasing amount = of chips that are well suited for processing large extension header. > > > > > > > > Cheers, Frank > > > > > > > > -- > > > > Mikael Abrahamsson email: swmike@swm.pp.se > > > > > > > > _______________________________________________ > > > > ippm mailing list > > > > ippm@ietf.org > > > > https://eur03.safelinks.protection.outlook.com/?url= =3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cg= barak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6= a4d149256f461b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef= 3BJFz6AQNNAtkgmAMDFKM%3D&reserved=3D0 > > > > _______________________________________________ > > > > ippm mailing list > > > > ippm@ietf.org > > > > https://eur03.safelinks.protection.outlook.com/?url= =3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cg= barak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6= a4d149256f461b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef= 3BJFz6AQNNAtkgmAMDFKM%3D&reserved=3D0 > > > > ---------------------------------------------------= ----------------- > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf.org > > > > Administrative Requests: https://www.ietf.org/mailm= an/listinfo/ipv6 > > > > ---------------------------------------------------= ----------------- > > > > > > _______________________________________________ > > > ippm mailing list > > > ippm@ietf.org > > > https://www.ietf.org/mailman/listinfo/ippm > > > > > > > > > > > > > > > > > > --B_3637321759_530724765 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

=E2=80=9CThat is going to require justifying the protocol even in lig= ht of shortcomings in existing protocoIs.=E2=80=9D

 

Agreed !!! True for any proposal.

 

-Jai

<= p class=3DMsoNormal> 

From: Tom Herbert <tom@herbertland.com>
Date: Fr= iday, April 5, 2019 at 2:34 PM
To: Jai Kumar <jai.kumar@broadco= m.com>
Cc: "Pengshuping (Peng Shuping)" <pengshupi= ng@huawei.com>, 6man <ipv6@ietf.org>, ippm <ippm@ietf.org>, &= quot;C. M. Heard" <heard@pobox.com>, Mikael Abrahamsson <swmik= e@swm.pp.se>
Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-= ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields)<= /o:p>

 

 

=

On Fri, Apr 5, 2019, 2:07 PM Jai Kumar <jai.kumar@broadcom.com> wrote:

Tom,

Its all explained in the requirements section of the d= raft. IFA header is essentially treated as an EH both in IPv4 and IPv6 (very= similar to AH/ESP EH).

Just like in AH/ESP the IP protocol is copied= in the AH header and IP protocol field is replaced in the IP header with th= e AH proto.

There are several advantages to this approach.
- devis= e know how to parse AH header and can follow very similar approach
- Prot= ocol agnostics, silicon need not support N encaps (just like AH/ESP). Single= implementation works for all protocol types.
- No need to creation optio= ns and teach devices that options is NOT an exception path processing
- R= eally worry about ordering in IPv6 options
- Note that all the OAM data n= eed to be deleted as well so position need to be optimal for removal. We can= always do tail stamping of the data but this puts considerable constrains o= n the cell based architecture
- L4 accessibility I have already mentioned=

I am happy to discuss with you in person and explain more but bottom= line is that this proposal is what came out with MSDC discussions in light = of shortcomings from other IETF proposals.

=

 

As they say, you are free to run whatever you want in your proprietary = network, but if you expect to create an interoperable, deployable protocoI a= nd get a protocol number assignment, you'll need to work in ietf. That is go= ing to require justifying the protocol even in light of shortcomings in exis= ting protocoIs.

 

Tom

 


Regards= ,
-Jai


=EF=BB=BFOn 4/5/19, 12:28 PM, "Tom Herbert" <tom@herbertland.com>= ; wrote:

    On Fri, Apr 5, 2019 at 12:03 PM Jai Kumar <= jai.kumar@broadcom.c= om> wrote:
    >
    > " Great, = but this IETF"
    > Does it mean that drafts have no r= elevance to deployment and actual adoption.
    >
  =   > For all your queries please take a look at IFA draft.
  =   > https://datatracker.ietf.org/doc/draft-kumar-ippm-ifa/<= br>    >
    I've looked at that draft. It's is cr= eating a complete new IP
    protocolas well as a new packet fo= rmat for TCP and UDP that somehow
    inserts meta data between= the TCP header and payload. I don't
    understand why this co= uld possibly be better than just using flow
    label for ECMP = and teaching devices that need to extract transport
    informa= tion how to walk over EH, or just using some UDP encpasulation
  &nb= sp; like in draft-herbert-ipv4-udpencap-eh-01.

    Tom
<= br>    > It handles IPv6, IPv4 TCP/UDP with altering the packet= path (due to inserting options and/or encaping them in GRE header) as well = as IPSec AH/ESP/WESP both tunnel and transport and guess what it is successf= ully deployed.
    >
    > -Jai
  &n= bsp; >
    > =EF=BB=BFOn 4/5/19, 11:54 AM, "Tom Herbert&qu= ot; <tom@herbertland= .com> wrote:
    >
    >   =  On Fri, Apr 5, 2019 at 11:25 AM Jai Kumar <jai.kumar@broadcom.com> wrote:
&n= bsp;   >     >
    >    =  > Tom,
    >     >
  &nbs= p; >     > I am speaking based on the actual deployment= not based on if all the traffic is/will move to IPSec tunnel.
  &nb= sp; >     >
    >     &g= t; I have 6 large customer deployments and one someone previously called as = "Yahoo" who insist on visibility in L4 even for IOAM packets.
&= nbsp;   >     >
    >   =  And I've worked in datcenters much larger, and my first rule is that = I
    >     don't want random router vendors = dictating to me what protocols I'm
    >     = allowed to use in my datacenter.
    >
    >=      > I can quote you on that and lose my business :-)    >     >
    >  &nbs= p;  > ECMP argument is weak as well as it works for IPv6 flow label.= What about IPv4 TCP/UDP traffic which typically is 80% of the traffic in MS= DC.
    >     >
    >
&= nbsp;   >     draft-herbert-ipv4-udpencap-eh-01
&n= bsp;   >
    >     > If someone te= lls me that proposal will work only for my 20% of traffic then again as I sa= id before, they will lose my business :-)
    >   =  >
    >     Great, but this IETF. W= here are the protocol requirements? If you are
    >  &= nbsp;  saying that there are requirements for "visibility in L4&qu= ot; what are
    >     they? If you are sayin= g that ACLs are now required for packet
    >    &= nbsp;forwarding, where is that described? Is it a MUST that teh only
&nbs= p;   >     transport protocols we're allowed to use a= re  UDP or TCP? Are we
    >     allowed= to use extension headers at all? I suppose fragmentation is
   = ; >     right out... Are we violating the requirements if = we encrypt the
    >     transport headers? I= f you say that we shouldn't send long headers
    >  &n= bsp;  because we'll overflow parsing buffers, then what is the limit? P= lease
    >     be SPECIFC in setting require= ments; we are trying to build protocols
    >    &= nbsp;that work and are interoperable and we need to get out of this morass    >     of reverse engineering to discover t= he least common denominator.
    >
    >&nbs= p;    Tom
    >
    >   =  > Regards,
    >     > -Jai
&= nbsp;   >     >
    >   =  > =EF=BB=BFOn 4/5/19, 11:15 AM, "Tom Herbert" <tom@herbertland.com> wrote:<= br>    >     >
    >  &n= bsp;  >     On Fri, Apr 5, 2019 at 10:55 AM Jai Kumar= <jai.kumar@broad= com.com> wrote:
    >     >  &= nbsp;  >
    >     >    =  > Even if we use flow label for ECMP, lack of accessibility of L4 i= nformation (for various services, most simple is ACL) makes the proposal pre= tty much unusable.
    >     >   = ;  >
    >     >    &nbs= p;That is convoluting router and firewall functionality and
   = >     >     requirements. This a discus= sion about packet forwarding which does
    >    &= nbsp;>     _not_ require ACLs. In a limited domain, for wh= ich IOAM is intended,
    >     >  &n= bsp;  it is unlikely that they'll ACLs would be used in internal nodes,= but
    >     >     we do = need good ECMP routing at all intermediate nodes need to be
   = >     >     consistent rather or not th= at the IOAM option is present. As side
    >    &n= bsp;>     note, the ability to extract L4 information out = of packets is
    >     >    &nb= sp;dwindling anyway thanks to encryption and other techniques trying to
&= nbsp;   >     >     undo protocol o= ssification. For instance, good luck getting L4
    >  =    >     information out of an IPsec tunnel :-).=
    >     >
    >  &= nbsp;  >     Tom
    >    &= nbsp;>
    >     >     &= gt; NIC cards are not used pervasively for ACLs and other services, I believ= e iptables in kernel are good enough for host but that=E2=80=99s not acceptable in= networking elements.
    >     >  &n= bsp;  >
    >     >    &= nbsp;> -Jai
    >     >    &n= bsp;>
    >     >     &g= t; =EF=BB=BFOn 4/5/19, 10:31 AM, "ippm on behalf of Tom Herbert" <ippm-bounces@ietf.org on behalf of tom@herb= ertland.com> wrote:
    >     >&nbs= p;    >
    >     >  &nb= sp;  >     On Fri, Apr 5, 2019 at 9:16 AM Pengshuping= (Peng Shuping)
    >     >    &= nbsp;>     <pengshuping@huawei.com> wrote:
    >&nbs= p;    >     >     >
&nbs= p;   >     >     >    =  > Hi Barak,
    >     >  &nb= sp;  >     >
    >    &n= bsp;>     >     > We are certainly no= t designing for the lowest capable solutions but exploring optimal solutions= which could help to keep the forwarding performance while inserting the iOA= M data with variable length.
    >     >&n= bsp;    >
    >     >  &= nbsp;  >     Shuping,
    >  &nb= sp;  >     >
    >    &n= bsp;>     >     That's exactly the argum= ent for using the flow label in ECMP.
    >    &nb= sp;>     >     Efficeint packet forwardi= ng can be done solely by inspected the forty
    >  &nb= sp;  >     >     byte fixed length = header of the packet regardless of the contents of
    >&nbs= p;    >     >     the rest of = the packet. That is an optimal solution. Anything else for
    = >     >     >     ECMP= like doing DPI or hacking up IOAM to try do pull transport layers
 =   >     >     >    &n= bsp;into the parsing buffer (whatever size that may be) are nothing more
=     >     >     >  &nb= sp;  than hacks and unnecessarily perpetuate techniques used with IPv4 = that
    >     >     >&n= bsp;    either don't work or are unnecessary in IPv6.
  &n= bsp; >     >     >
    &= gt;     >     >     Tom    >     >     >
&nbs= p;   >     >     >
  &nb= sp; >     >     >     = >
    >     >     >&n= bsp;    > In terms of the forwarding efficiency, we would all a= gree that a short and fixed header would be better than a variable header.    >     >     >  &= nbsp;  >
    >     >    =  >     > Best regards
    >  =    >     >     > Shuping    >     >     >  &n= bsp;  >
    >     >    &= nbsp;>     >
    >     &= gt;     >     > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A B= arak Gafni<gbarak@me= llanox.com>
    >     >   = ;  >     > =E6= =94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Pengshuping (Peng Shuping)<pengshuping@huawei.com>;Frank Brockners = (fbrockne)<fbrockne@c= isco.com>;Mikael Abrahamsson<swmike@swm.pp.se>
    >    &nb= sp;>     >     > =E6=8A=84=E9=80=81=EF=BC=9A C. M. Heard<heard@pobox.com>;6man WG<ipv6@ietf.org>;Mark Smith<markzzzsmith@gmail.com>;= ippm<ippm@ietf.org>=
    >     >     > =    > =E4=B8=BB=E9=A2=98=EF=BC=9A= RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v= 6 option types for IOAM data fields)
    >    &nbs= p;>     >     > =E6=97=B6=E9=97=B4=EF=BC=9A 2= 019-04-05 03:18:26
    >     >   = ;  >     >
    >    &nbs= p;>     >     > Hi Shuping,
 =   >     >     >    &n= bsp;> I think that the question is whether we design for the lowest capab= le solutions. I assume someone can find solutions with even lower amount of = parsing.. The low end solutions for these capabilities may need to either ad= opt with new designs or use solutions such as what is suggested in this thre= ad by Tom Herbert.
    >     >   = ;  >     > Personally, I don't think we should go = this way, but to design appropriate solutions, with appropriate layers in th= e headers. For example, prevent dependencies between "remote" head= ers.
    >     >     >&n= bsp;    >
    >     >  &= nbsp;  >     > Thanks,
    > =    >     >     > Barak
=     >     >     >  &nb= sp;  >
    >     >    &n= bsp;>     > -----Original Message-----
   = >     >     >     >= ; From: ippm <ippm= -bounces@ietf.org> On Behalf Of Pengshuping (Peng Shuping)
  =   >     >     >    &nb= sp;> Sent: Wednesday, April 3, 2019 6:47 AM
    >  &= nbsp;  >     >     > To: Frank B= rockners (fbrockne) <= fbrockne@cisco.com>; Mikael Abrahamsson <swmike@swm.pp.se>
    > = ;    >     >     > Cc: C. M= . Heard <heard@pobox.com= >; 6man WG <ipv6@ie= tf.org>; Mark Smith <markzzzsmith@gmail.com>; ippm@ietf.org
    >     >= ;     >     > Subject: [ippm] =E7=AD=94=E5=A4=8D: draft-ioametal-ippm-6man-ioam-ipv= 6-deployment-00 feedback (Re: v6 option types for IOAM data fields)
 = ;   >     >     >    &= nbsp;>
    >     >     &= gt;     > Hi,
    >     >= ;     >     >
    > = ;    >     >     > The pars= ing depth of the early chips is 96B/128B. For the new chips the parsing dept= h has been increased but still limited. So Mikael's concern makes sense espe= cially in the tracing mode that the IOAM data fields are going to increase s= ignificantly along the path, which will even push the Routing Header out of = the parsing depth of the chip. So it would make sense to split the IOAM data= part from the IOAM header/instruction part, and place the IOAM data after t= he RH or even after the L4 header in order to be able to read the L4 informa= tion to enable ECMP, as stated in the draft https://eur03.safelinks.protection.outl= ook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-li-6man-ipv6-sfc-if= it-00&amp;data=3D02%7C01%7Cgbarak%40mellanox.com%7C612ba6dc117440e68c4608d= 6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636898960379485833&am= p;amp;sdata=3DDob4zN%2F1jSGxLTlqGma29JJNvqJDBt4VzqHsN4OpxM4%3D&amp;reserve= d=3D0.
    >     >     &g= t;     >
    >     >&nbs= p;    >     > BR,
    > =    >     >     > Shuping    >     >     >  &= nbsp;  >
    >     >    =  >     >
    >     = >     >     > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
    >     >     &= gt;     > =E5=8F=91=E4=BB=B6=E4=BA=BA: ippm [mailto:ippm-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Frank Brockners (fbrockne)
&n= bsp;   >     >     >   = ;  > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4= : 2019=E5=B9=B44=E6=9C=882=E6=97=A5= 17:40
    >     >     >=      > =E6=94=B6=E4=BB=B6=E4=BA=BA: Mikael Abrahamsson <swmike@swm.pp.se>
    >     >&nbs= p;    >     > =E6=8A=84=E9=80=81: C. M. Heard <heard@pobox.com>; 6man WG <ipv6@ietf.org>; Mark Smith <markzzzsmith@gmail.com>; ippm@ietf.org
    &= gt;     >     >     > = =E4=B8=BB=E9=A2=98: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-0= 0 feedback (Re: v6 option types for IOAM data fields)
    >&= nbsp;    >     >     >
&= nbsp;   >     >     >  &nbs= p;  >
    >     >    &nb= sp;>     >
    >     >= ;     >     > -----Original Message-----=
    >     >     > =    > From: Mikael Abrahamsson <swmike@swm.pp.se>
    >  &= nbsp;  >     >     > Sent: Diens= tag, 2. April 2019 08:06
    >     > =    >     > To: Frank Brockners (fbrockne) &l= t;fbrockne@cisco.com= >
    >     >     >&n= bsp;    > Cc: Mark Smith <markzzzsmith@gmail.com>; C. M. Heard <heard@pobox.com>; 6man WG = <ipv6@ietf.org>; ippm@ietf.org
  &nb= sp; >     >     >     = > Subject: RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback = (Re: v6 option types for IOAM data fields)
    >   = ;  >     >     >
   = ; >     >     >     &g= t; On Mon, 1 Apr 2019, Frank Brockners (fbrockne) wrote:
    &g= t;     >     >     >    >     >     >  &= nbsp;  > > ...FB: There is obviously no easy answer. Couple of th= oughts:
    >     >     >= ;     > > * IOAM is considered a "domain specific&= quot; feature (see
    >     >   = ;  >     > > draft-ietf-ippm-ioam-data-05, sect= ion 3). Routers in the IOAM domain
    >     = >     >     > > should be IOAM cap= able.  And IMHO,  we should add a statement to
    &g= t;     >     >     > &= gt; draft-ioametal-ippm-6man-ioam-ipv6-deployment that an implementation
=     >     >     >  &nb= sp;  > > of IOAM MUST ensure "C1".
    >= ;     >     >     > &g= t;
    >     >     >&nbs= p;    > > * That said, there can be situations, where C1 can= not be achieved, e.g..
    >     >  &= nbsp;  >     > > consider a network which does = ECMP scheduling based on packet length.
    >    &= nbsp;>     >     > >
  &nb= sp; >     >     >     = > > * What one could consider - and which is one suggested deployment<= br>    >     >     >  =    > > model
    >     >&n= bsp;    >     > > - is that by default IOA= M data fields are added to _all_ customer
    >   =  >     >     > > packets. Th= e decapsulating node would decide whether the IOAM
    >&nbs= p;    >     >     > > in= formation contained in a packet would be used (and exported) or not.
&nbs= p;   >     >     >    =  > > That way one would not need to deal with the situation that = some
    >     >     >&n= bsp;    > > traffic carries IOAM while other does not - and = might thus be treated
    >     >  &n= bsp;  >     > > differently.
    &= gt;     >     >     ><= br>    >     >     >  =    > Yes, I think this is the only way. Is there a risk that in= termediate routers would not be IOAM capable? I think the C1 requirement is = really really hard to fulfil and I'm also afraid that adding the IOAM header= will actually make ECMP stop working on some platforms (because they would = not have the capability to look deep enough into the packet to find L4 infor= mation, so it'll go back to 2 tuple ECMP instead of 5 tuple.
   = ; >     >     >     &g= t;
    >     >     >&nbs= p;    > But this question can only be answered by people with d= eep NPU knowledge...
    >     >  &nb= sp;  >     >
    >    &n= bsp;>     >     > .....FB2: Given tha= t IOAM is a domain specific feature - I expect that folks initially start to= use it in domains (like e.g. a DC) where all boxes are IOAM capable and can= trace the packet appropriately - or per Tom's note, can be configured so th= at one would do ECMP based on addresses and flow-label.  There are chip= s with pretty deep parsing capability (up to a few hundred bytes).
 =   >     >     >    &n= bsp;>
    >     >     &g= t;     > > ...FB: The comparison to MPLS is interesting= . How often do MPLS
    >     >  &nbs= p;  >     > > packets leak and cause harm? For = IOAM,
    >     >     >&= nbsp;    > > draft-ioametal-ippm-6man-ioam-ipv6-options-02 p= roposes a deployment
    >     >  &nb= sp;  >     > > model similar to what we do for = MPLS: Unless an interface is
    >     >&n= bsp;    >     > > explicitly configured fo= r IOAM, packets with IOAM data fields MUST be dropped.
    >=      >     >     > >= ; Hence leakage would only occur, if we have a clearly misbehaving
 =   >     >     >    &n= bsp;> > router which violates this rule. Similar to you, I'd also grea= tly
    >     >     >&nb= sp;    > > appreciate any pointers to research on how common= MPLS leaked packets are.
    >     > = ;    >     >
    >  &nbs= p;  >     >     > When it comes = to "cause harm" I imagine there are (at least) two ways to cause h= arm, one is privacy/secrecy/security loss and the other one is actual operat= ional loss.
    >     >     = ;>     >
    >     >&= nbsp;    >     > I know of bugs where labeled= packets went the wrong way and caused them to be lost, I've also seen bugs = where bugs caused traffic to "hop" between VRFs in MPLS VPN (or to= "global" VRF). I don't have numbers on this though.
  &nb= sp; >     >     >     = >
    >     >     >&n= bsp;    > Depending on the deployment scenario, it might make s= ense to make IOAM packets not valid for non-IOAM aware devices (basically en= cap entire packet/payload), but that might be a problem for intermediate non= -IOAM nodes then. This would affect the ECMP requirement. I can see cases wh= ere one would operationally turn on IOAM for some customers traffic and then= see the problem go away because now ECMP changed.
    >&nbs= p;    >     >     >
&nbs= p;   >     >     >    =  > > ...FB: One idea that Shwetha came up with to identify the so= urce AS of
    >     >     = >     > > a leaked packet, would be to add a new new= IOAM E2E option - as
    >     >  &n= bsp;  >     > > proposed in section 5.1.1 bulle= t 2 of
    >     >     >=      > > draft-ioametal-ippm-6man-ioam-ipv6-deployment-= 01.
    >     >     >&nb= sp;    >
    >     >  &n= bsp;  >     > Yes, that'd solve that problem.
&= nbsp;   >     >     >  &nbs= p;  >
    >     >    &nb= sp;>     > How much has the silicon people been involve= d so far in the design of the headers? What is the current thinking of amoun= t of data going into the IOAM header? Considering things like trace options = etc it seems to me the header can grow quite large? To satisfy the ECMP requ= irement what about putting the IOAM information as a trailer behind the regu= lar payload? Or is there a problem for the hw to manipulate information that= far into the packet (I also imagine this will considerably lower the forwar= ding performance of IOAM packets on IOAM aware platforms).
    = >     >     >     >=
    >     >     > =    > .....FB2: There are quite a few folks with hardware backg= round that co-author the IOAM drafts. Parsing capability differs between chi= ps, as does the ability to deal with new/flexible headers and the ability to= modify data in the extension headers. So the unfortunate answer to that que= stion is "it depends" (what information do you gather, how large i= s your domain, what are the capabilities of your hardware/software forwarder= , etc.), but I do expect that for specific deployment domains (e.g. DC, Ente= rprise) - but also for overlay networks / VPNs - we'll see an increasing amo= unt of chips that are well suited for processing large extension header.
=     >     >     >  &nb= sp;  >
    >     >    &n= bsp;>     > Cheers, Frank
    >  &= nbsp;  >     >     >
  &= nbsp; >     >     >    &nbs= p;> --
    >     >     &= gt;     > Mikael Abrahamsson    email: swmike@swm.pp.se
  &nbs= p; >     >     >     &= gt;
    >     >     >&nb= sp;    > _______________________________________________
&nb= sp;   >     >     >   =  > ippm mailing list
    >     >&= nbsp;    >     > ippm@ietf.org
    >    &nbs= p;>     >     > https://eur03.safelinks.protection.outlook.c= om/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&amp;data=3D= 02%7C01%7Cgbarak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971= c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636898960379485833&amp;sdata=3DVjZ1Piw= ifYGCf159je0yef3BJFz6AQNNAtkgmAMDFKM%3D&amp;reserved=3D0
  &nb= sp; >     >     >     = > _______________________________________________
    >&n= bsp;    >     >     > ippm = mailing list
    >     >    &nbs= p;>     > ippm@ietf.org
    >     >  &nbs= p;  >     > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%= 2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&amp;data=3D02%7C01%7Cgbarak%= 40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149= 256f461b%7C0%7C0%7C636898960379485833&amp;sdata=3DVjZ1PiwifYGCf159je0yef3B= JFz6AQNNAtkgmAMDFKM%3D&amp;reserved=3D0
    >  &n= bsp;  >     >     > ------------= --------------------------------------------------------
    &g= t;     >     >     > I= ETF IPv6 working group mailing list
    >     = ;>     >     > ipv6@ietf.org
    >   = ;  >     >     > Administrative = Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > = ;    >     >     > --------= ------------------------------------------------------------
   = ; >     >     >
    >=      >     >     ________= _______________________________________
    >    &= nbsp;>     >     ippm mailing list
&n= bsp;   >     >     >   = ;  ippm@ietf.org
=     >     >     >  &nb= sp;  https://www.ietf.org/mailman/listinfo/ippm
    > = ;    >     >
    >  &nbs= p;  >     >
    >    &nb= sp;>     >
    >     >= ;
    >     >
    >  =    >
    >
    >
  &nbs= p; >


--B_3637321759_530724765-- From nobody Fri Apr 5 15:34:48 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037D91201EF for ; Fri, 5 Apr 2019 15:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 ItAke-OfH99g for ; Fri, 5 Apr 2019 15:34:42 -0700 (PDT) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E374012018D for ; Fri, 5 Apr 2019 15:34:41 -0700 (PDT) Received: by mail-qt1-x834.google.com with SMTP id z16so9305403qtn.4 for ; Fri, 05 Apr 2019 15:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gonVXawAs/s0EOD43ruf+DB7vdzLO5JT7sHRJxQos2E=; b=qi9l/xsJgJ+8MBsjjXbRXhUkRvRY62/C2ihZGNVirJzpxQiOHcN+6hr6HfVfNd1Vdl ztqP9sxrS94A4Jv4xJuYG4sNjHwYDxpkG+XZxSgtOevUS1DGof+tJztucO3BTyPInfno PzoHb0UjiFW49ZmcjO5lpBtmrHWwHvwYH6iVL1e0+HqfSr96C2rPWy09cckDy0XoenHd hJlHIdgRsYila+cXpo8vVntIe2QOKoQ/j7QvBUmFHWgY6M2PtQYreYLXwd9YJ6zlaodA 7tumU7aGAAZZDCYOiXbpuEdmljy+9BydEoqBNNvcMqBlBJDtFbghmBxwKBN6WmgchCsP AcuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gonVXawAs/s0EOD43ruf+DB7vdzLO5JT7sHRJxQos2E=; b=Ij7Z0zGspx2pYv/RFoJ+YSpfv+TX5R0yeBhEUyKzCF7e3gILFyuGGQ/61uVUeost8Y +lhDG1zyuHUvibkY2m003S7mKc5jH1zmyU89L3HPjQEbf/hZdRnA9gOPmtkus2IT0FbL 8Lm242KXIhB069FQf1K1ztKSkW6SlC59MU847D1chc9tnsrVj2lq6el6piiQWEMNNX7i eYjvCw9iQPRPSB1agIn7/dL83gegXsd3xG5PhR1J9U53sGr7Psow/yxHwPleK+PO8hIZ 0e/a6w0GBg723gd9I9zCstYcsF94WQFVu4WoCbtJAUJ29Hph3CgCIxFPlLGLtXCA7mpj gmwQ== X-Gm-Message-State: APjAAAVZmsb3xV+IXU9BZKI1EfmI00M3N3waI5cwUVRuMHL5sQyxJEBv gNuCTmY6Thf/ROigG8/htDxZVSwBkiWkn6WdR29f7Q== X-Google-Smtp-Source: APXvYqyektmf7WCvU7zguLBJYcSqgDcFG182GFMvMgVNIUH2kOIEJuMMaDMb0+0Hw2ekIupeIdQBuYaIs29a2hTXkfs= X-Received: by 2002:a0c:8aac:: with SMTP id 41mr12388228qvv.98.1554503680537; Fri, 05 Apr 2019 15:34:40 -0700 (PDT) MIME-Version: 1.0 References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> <4278D47A901B3041A737953BAA078ADE1478D5E2@DGGEML532-MBX.china.huawei.com> <4278D47A901B3041A737953BAA078ADE1478EC8B@DGGEML532-MBX.china.huawei.com> <14A3D5C9-1EED-4E11-9329-B62B819271A2@broadcom.com> <20D6FCDB-3357-4728-BD52-8069C32F3CCA@broadcom.com> <57A32C37-AAE9-44F2-9C96-39AFA71BDC21@broadcom.com> In-Reply-To: <57A32C37-AAE9-44F2-9C96-39AFA71BDC21@broadcom.com> From: Tom Herbert Date: Fri, 5 Apr 2019 15:34:28 -0700 Message-ID: To: Jai Kumar Cc: "Pengshuping (Peng Shuping)" , 6man , ippm , "C. M. Heard" , Mikael Abrahamsson Content-Type: multipart/alternative; boundary="000000000000ae4abb0585d01700" Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 22:34:47 -0000 --000000000000ae4abb0585d01700 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Jai, You might want to consider how IFA works in the presence of segment routing. The second someone puts an SRH in the packet the IFA headers get pushed down and the transport headers end up being deep in the packet anyway so that all the effort of IFA is nullified. If the requirement is to ensure that the transport layer information appear as early as possible in the packet, one could define a Hop-by-Hop option to carry some sort of pseudo header for the transport layer. This also would work in the case that the actual transport layer is obfuscated. Tom On Fri, Apr 5, 2019, 3:09 PM Jai Kumar wrote: > =E2=80=9CThat is going to require justifying the protocol even in light o= f > shortcomings in existing protocoIs.=E2=80=9D > > > > Agreed !!! True for any proposal. > > > > -Jai > > > > *From: *Tom Herbert > *Date: *Friday, April 5, 2019 at 2:34 PM > *To: *Jai Kumar > *Cc: *"Pengshuping (Peng Shuping)" , 6man < > ipv6@ietf.org>, ippm , "C. M. Heard" , > Mikael Abrahamsson > *Subject: *Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 > feedback (Re: v6 option types for IOAM data fields) > > > > > > On Fri, Apr 5, 2019, 2:07 PM Jai Kumar wrote: > > Tom, > > Its all explained in the requirements section of the draft. IFA header is > essentially treated as an EH both in IPv4 and IPv6 (very similar to AH/ES= P > EH). > > Just like in AH/ESP the IP protocol is copied in the AH header and IP > protocol field is replaced in the IP header with the AH proto. > > There are several advantages to this approach. > - devise know how to parse AH header and can follow very similar approach > - Protocol agnostics, silicon need not support N encaps (just like > AH/ESP). Single implementation works for all protocol types. > - No need to creation options and teach devices that options is NOT an > exception path processing > - Really worry about ordering in IPv6 options > - Note that all the OAM data need to be deleted as well so position need > to be optimal for removal. We can always do tail stamping of the data but > this puts considerable constrains on the cell based architecture > - L4 accessibility I have already mentioned > > I am happy to discuss with you in person and explain more but bottom line > is that this proposal is what came out with MSDC discussions in light of > shortcomings from other IETF proposals. > > > > As they say, you are free to run whatever you want in your proprietary > network, but if you expect to create an interoperable, deployable protoco= I > and get a protocol number assignment, you'll need to work in ietf. That i= s > going to require justifying the protocol even in light of shortcomings in > existing protocoIs. > > > > Tom > > > > > Regards, > -Jai > > > =EF=BB=BFOn 4/5/19, 12:28 PM, "Tom Herbert" wrote: > > On Fri, Apr 5, 2019 at 12:03 PM Jai Kumar > wrote: > > > > " Great, but this IETF" > > Does it mean that drafts have no relevance to deployment and actual > adoption. > > > > For all your queries please take a look at IFA draft. > > https://datatracker.ietf.org/doc/draft-kumar-ippm-ifa/ > > > I've looked at that draft. It's is creating a complete new IP > protocolas well as a new packet format for TCP and UDP that somehow > inserts meta data between the TCP header and payload. I don't > understand why this could possibly be better than just using flow > label for ECMP and teaching devices that need to extract transport > information how to walk over EH, or just using some UDP encpasulation > like in draft-herbert-ipv4-udpencap-eh-01. > > Tom > > > It handles IPv6, IPv4 TCP/UDP with altering the packet path (due to > inserting options and/or encaping them in GRE header) as well as IPSec > AH/ESP/WESP both tunnel and transport and guess what it is successfully > deployed. > > > > -Jai > > > > =EF=BB=BFOn 4/5/19, 11:54 AM, "Tom Herbert" w= rote: > > > > On Fri, Apr 5, 2019 at 11:25 AM Jai Kumar < > jai.kumar@broadcom.com> wrote: > > > > > > Tom, > > > > > > I am speaking based on the actual deployment not based on if > all the traffic is/will move to IPSec tunnel. > > > > > > I have 6 large customer deployments and one someone previousl= y > called as "Yahoo" who insist on visibility in L4 even for IOAM packets. > > > > > And I've worked in datcenters much larger, and my first rule is > that I > > don't want random router vendors dictating to me what protocols > I'm > > allowed to use in my datacenter. > > > > > I can quote you on that and lose my business :-) > > > > > > ECMP argument is weak as well as it works for IPv6 flow label= . > What about IPv4 TCP/UDP traffic which typically is 80% of the traffic in > MSDC. > > > > > > > draft-herbert-ipv4-udpencap-eh-01 > > > > > If someone tells me that proposal will work only for my 20% o= f > traffic then again as I said before, they will lose my business :-) > > > > > Great, but this IETF. Where are the protocol requirements? If > you are > > saying that there are requirements for "visibility in L4" what > are > > they? If you are saying that ACLs are now required for packet > > forwarding, where is that described? Is it a MUST that teh only > > transport protocols we're allowed to use are UDP or TCP? Are w= e > > allowed to use extension headers at all? I suppose fragmentatio= n > is > > right out... Are we violating the requirements if we encrypt th= e > > transport headers? If you say that we shouldn't send long heade= rs > > because we'll overflow parsing buffers, then what is the limit? > Please > > be SPECIFC in setting requirements; we are trying to build > protocols > > that work and are interoperable and we need to get out of this > morass > > of reverse engineering to discover the least common denominator= . > > > > Tom > > > > > Regards, > > > -Jai > > > > > > =EF=BB=BFOn 4/5/19, 11:15 AM, "Tom Herbert" > wrote: > > > > > > On Fri, Apr 5, 2019 at 10:55 AM Jai Kumar < > jai.kumar@broadcom.com> wrote: > > > > > > > > Even if we use flow label for ECMP, lack of > accessibility of L4 information (for various services, most simple is ACL= ) > makes the proposal pretty much unusable. > > > > > > > That is convoluting router and firewall functionality and > > > requirements. This a discussion about packet forwarding > which does > > > _not_ require ACLs. In a limited domain, for which IOAM i= s > intended, > > > it is unlikely that they'll ACLs would be used in interna= l > nodes, but > > > we do need good ECMP routing at all intermediate nodes > need to be > > > consistent rather or not that the IOAM option is present. > As side > > > note, the ability to extract L4 information out of packet= s > is > > > dwindling anyway thanks to encryption and other technique= s > trying to > > > undo protocol ossification. For instance, good luck > getting L4 > > > information out of an IPsec tunnel :-). > > > > > > Tom > > > > > > > NIC cards are not used pervasively for ACLs and other > services, I believe iptables in kernel are good enough for host but that= =E2=80=99s > not acceptable in networking elements. > > > > > > > > -Jai > > > > > > > > =EF=BB=BFOn 4/5/19, 10:31 AM, "ippm on behalf of Tom He= rbert" < > ippm-bounces@ietf.org on behalf of tom@herbertland.com> wrote: > > > > > > > > On Fri, Apr 5, 2019 at 9:16 AM Pengshuping (Peng > Shuping) > > > > wrote: > > > > > > > > > > Hi Barak, > > > > > > > > > > We are certainly not designing for the lowest > capable solutions but exploring optimal solutions which could help to kee= p > the forwarding performance while inserting the iOAM data with variable > length. > > > > > > > > Shuping, > > > > > > > > That's exactly the argument for using the flow labe= l > in ECMP. > > > > Efficeint packet forwarding can be done solely by > inspected the forty > > > > byte fixed length header of the packet regardless o= f > the contents of > > > > the rest of the packet. That is an optimal solution= . > Anything else for > > > > ECMP like doing DPI or hacking up IOAM to try do > pull transport layers > > > > into the parsing buffer (whatever size that may be) > are nothing more > > > > than hacks and unnecessarily perpetuate techniques > used with IPv4 that > > > > either don't work or are unnecessary in IPv6. > > > > > > > > Tom > > > > > > > > > > > > > > > > > > In terms of the forwarding efficiency, we would > all agree that a short and fixed header would be better than a variable > header. > > > > > > > > > > Best regards > > > > > Shuping > > > > > > > > > > > > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Barak Gafni<= gbarak@mellanox.com> > > > > > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Pengshuping = (Peng Shuping)< > pengshuping@huawei.com>;Frank Brockners (fbrockne);Mi= kael > Abrahamsson > > > > > =E6=8A=84=E9=80=81=EF=BC=9A C. M. Heard;6man WG< > ipv6@ietf.org>;Mark Smith;ippm > > > > > =E4=B8=BB=E9=A2=98=EF=BC=9A RE: > draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option > types for IOAM data fields) > > > > > =E6=97=B6=E9=97=B4=EF=BC=9A 2019-04-05 03:18:26 > > > > > > > > > > Hi Shuping, > > > > > I think that the question is whether we design fo= r > the lowest capable solutions. I assume someone can find solutions with ev= en > lower amount of parsing.. The low end solutions for these capabilities ma= y > need to either adopt with new designs or use solutions such as what is > suggested in this thread by Tom Herbert. > > > > > Personally, I don't think we should go this way, > but to design appropriate solutions, with appropriate layers in the > headers. For example, prevent dependencies between "remote" headers. > > > > > > > > > > Thanks, > > > > > Barak > > > > > > > > > > -----Original Message----- > > > > > From: ippm On Behalf Of > Pengshuping (Peng Shuping) > > > > > Sent: Wednesday, April 3, 2019 6:47 AM > > > > > To: Frank Brockners (fbrockne) ; > Mikael Abrahamsson > > > > > Cc: C. M. Heard ; 6man WG < > ipv6@ietf.org>; Mark Smith ; ippm@ietf.org > > > > > Subject: [ippm] =E7=AD=94=E5=A4=8D: > draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option > types for IOAM data fields) > > > > > > > > > > Hi, > > > > > > > > > > The parsing depth of the early chips is 96B/128B. > For the new chips the parsing depth has been increased but still limited. > So Mikael's concern makes sense especially in the tracing mode that the > IOAM data fields are going to increase significantly along the path, whic= h > will even push the Routing Header out of the parsing depth of the chip. S= o > it would make sense to split the IOAM data part from the IOAM > header/instruction part, and place the IOAM data after the RH or even aft= er > the L4 header in order to be able to read the L4 information to enable > ECMP, as stated in the draft > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= .ietf.org%2Fhtml%2Fdraft-li-6man-ipv6-sfc-ifit-00&data=3D02%7C01%7Cgbar= ak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4= d149256f461b%7C0%7C0%7C636898960379485833&sdata=3DDob4zN%2F1jSGxLTlqGma= 29JJNvqJDBt4VzqHsN4OpxM4%3D&reserved=3D0 > . > > > > > > > > > > BR, > > > > > Shuping > > > > > > > > > > > > > > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: ippm [mailto:ippm-bo= unces@ietf.org] =E4=BB=A3=E8=A1=A8 Frank > Brockners (fbrockne) > > > > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9= =B44=E6=9C=882=E6=97=A5 17:40 > > > > > =E6=94=B6=E4=BB=B6=E4=BA=BA: Mikael Abrahamsson <= swmike@swm.pp.se> > > > > > =E6=8A=84=E9=80=81: C. M. Heard = ; 6man WG < > ipv6@ietf.org>; Mark Smith ; ippm@ietf.org > > > > > =E4=B8=BB=E9=A2=98: Re: [ippm] > draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option > types for IOAM data fields) > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Mikael Abrahamsson > > > > > Sent: Dienstag, 2. April 2019 08:06 > > > > > To: Frank Brockners (fbrockne) > > > > > > Cc: Mark Smith ; C. M. > Heard ; 6man WG ; ippm@ietf.org > > > > > Subject: RE: > draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option > types for IOAM data fields) > > > > > > > > > > On Mon, 1 Apr 2019, Frank Brockners (fbrockne) > wrote: > > > > > > > > > > > ...FB: There is obviously no easy answer. Coupl= e > of thoughts: > > > > > > * IOAM is considered a "domain specific" featur= e > (see > > > > > > draft-ietf-ippm-ioam-data-05, section 3). > Routers in the IOAM domain > > > > > > should be IOAM capable. And IMHO, we should > add a statement to > > > > > > draft-ioametal-ippm-6man-ioam-ipv6-deployment > that an implementation > > > > > > of IOAM MUST ensure "C1". > > > > > > > > > > > > * That said, there can be situations, where C1 > cannot be achieved, e.g.. > > > > > > consider a network which does ECMP scheduling > based on packet length. > > > > > > > > > > > > * What one could consider - and which is one > suggested deployment > > > > > > model > > > > > > - is that by default IOAM data fields are added > to _all_ customer > > > > > > packets. The decapsulating node would decide > whether the IOAM > > > > > > information contained in a packet would be used > (and exported) or not. > > > > > > That way one would not need to deal with the > situation that some > > > > > > traffic carries IOAM while other does not - and > might thus be treated > > > > > > differently. > > > > > > > > > > Yes, I think this is the only way. Is there a ris= k > that intermediate routers would not be IOAM capable? I think the C1 > requirement is really really hard to fulfil and I'm also afraid that addi= ng > the IOAM header will actually make ECMP stop working on some platforms > (because they would not have the capability to look deep enough into the > packet to find L4 information, so it'll go back to 2 tuple ECMP instead o= f > 5 tuple. > > > > > > > > > > But this question can only be answered by people > with deep NPU knowledge... > > > > > > > > > > .....FB2: Given that IOAM is a domain specific > feature - I expect that folks initially start to use it in domains (like > e.g. a DC) where all boxes are IOAM capable and can trace the packet > appropriately - or per Tom's note, can be configured so that one would do > ECMP based on addresses and flow-label. There are chips with pretty deep > parsing capability (up to a few hundred bytes). > > > > > > > > > > > ...FB: The comparison to MPLS is interesting. > How often do MPLS > > > > > > packets leak and cause harm? For IOAM, > > > > > > draft-ioametal-ippm-6man-ioam-ipv6-options-02 > proposes a deployment > > > > > > model similar to what we do for MPLS: Unless an > interface is > > > > > > explicitly configured for IOAM, packets with > IOAM data fields MUST be dropped. > > > > > > Hence leakage would only occur, if we have a > clearly misbehaving > > > > > > router which violates this rule. Similar to you= , > I'd also greatly > > > > > > appreciate any pointers to research on how > common MPLS leaked packets are. > > > > > > > > > > When it comes to "cause harm" I imagine there are > (at least) two ways to cause harm, one is privacy/secrecy/security loss a= nd > the other one is actual operational loss. > > > > > > > > > > I know of bugs where labeled packets went the > wrong way and caused them to be lost, I've also seen bugs where bugs caus= ed > traffic to "hop" between VRFs in MPLS VPN (or to "global" VRF). I don't > have numbers on this though. > > > > > > > > > > Depending on the deployment scenario, it might > make sense to make IOAM packets not valid for non-IOAM aware devices > (basically encap entire packet/payload), but that might be a problem for > intermediate non-IOAM nodes then. This would affect the ECMP requirement.= I > can see cases where one would operationally turn on IOAM for some custome= rs > traffic and then see the problem go away because now ECMP changed. > > > > > > > > > > > ...FB: One idea that Shwetha came up with to > identify the source AS of > > > > > > a leaked packet, would be to add a new new IOAM > E2E option - as > > > > > > proposed in section 5.1.1 bullet 2 of > > > > > > draft-ioametal-ippm-6man-ioam-ipv6-deployment-0= 1. > > > > > > > > > > Yes, that'd solve that problem. > > > > > > > > > > How much has the silicon people been involved so > far in the design of the headers? What is the current thinking of amount = of > data going into the IOAM header? Considering things like trace options et= c > it seems to me the header can grow quite large? To satisfy the ECMP > requirement what about putting the IOAM information as a trailer behind t= he > regular payload? Or is there a problem for the hw to manipulate informati= on > that far into the packet (I also imagine this will considerably lower the > forwarding performance of IOAM packets on IOAM aware platforms). > > > > > > > > > > .....FB2: There are quite a few folks with > hardware background that co-author the IOAM drafts. Parsing capability > differs between chips, as does the ability to deal with new/flexible > headers and the ability to modify data in the extension headers. So the > unfortunate answer to that question is "it depends" (what information do > you gather, how large is your domain, what are the capabilities of your > hardware/software forwarder, etc.), but I do expect that for specific > deployment domains (e.g. DC, Enterprise) - but also for overlay networks = / > VPNs - we'll see an increasing amount of chips that are well suited for > processing large extension header. > > > > > > > > > > Cheers, Frank > > > > > > > > > > -- > > > > > Mikael Abrahamsson email: swmike@swm.pp.se > > > > > > > > > > _______________________________________________ > > > > > ippm mailing list > > > > > ippm@ietf.org > > > > > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cgbarak%40mellanox.= com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7= C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef3BJFz6AQNNAtk= gmAMDFKM%3D&reserved=3D0 > > > > > _______________________________________________ > > > > > ippm mailing list > > > > > ippm@ietf.org > > > > > > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cgbarak%40mellanox.= com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7= C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef3BJFz6AQNNAtk= gmAMDFKM%3D&reserved=3D0 > > > > > > -------------------------------------------------------------------- > > > > > IETF IPv6 working group mailing list > > > > > ipv6@ietf.org > > > > > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > > > > > > -------------------------------------------------------------------- > > > > > > > > _______________________________________________ > > > > ippm mailing list > > > > ippm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ippm > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --000000000000ae4abb0585d01700 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jai,

You might want = to consider how I= FA works in the presence of segment routing. The second someone puts= an SRH in= the packet the I= FA headers get pushed down and the transport headers end up being de= ep in the packet anyway so that all the effort of IFA is nullified. If the requiremen= t is to ensure that the transport layer information appear as early as poss= ible in the packet, one could define a Hop-by-Hop option to carry some sort= of pseudo header for the transport layer. This also would work in the case= that the actual transport layer is obfuscated.

To= m


On Fri, Apr 5, 2019, 3:09 PM Jai Kumar <jai.kumar@br= oadcom.com> wrote:

=E2=80= =9CThat is going to require justifying the protocol even in light of shortc= omings in existing protocoIs.=E2=80=9D

=C2=A0

Agreed !!!= True for any proposal.

<= /u>=C2=A0

-Jai=

=C2=A0

From: Tom Herbert <tom@herbertland= .com>
Date: Friday, April 5, 2019 at 2:34 PM
To: Jai Kumar <jai.kumar@broadcom.com>
Cc: "Pengs= huping (Peng Shuping)" <pengshuping@huawei.com>, 6man &l= t;ipv= 6@ietf.org>, ippm <ippm@ietf.org>, "C. M. Heard" <= hea= rd@pobox.com>, Mikael Abrahamsson <swmike@swm.pp.se>
S= ubject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 fee= dback (Re: v6 option types for IOAM data fields)

=C2=A0

=C2=A0

=

On Fri, Apr 5, 2019, 2:07 PM Jai Kumar <= ;jai.kumar@broadcom.com> wrote:

Tom,
<= br>Its all explained in the requirements section of the draft. IFA header i= s essentially treated as an EH both in IPv4 and IPv6 (very similar to AH/ES= P EH).

Just like in AH/ESP the IP protocol is copied in the AH heade= r and IP protocol field is replaced in the IP header with the AH proto.
=
There are several advantages to this approach.
- devise know how to = parse AH header and can follow very similar approach
- Protocol agnostic= s, silicon need not support N encaps (just like AH/ESP). Single implementat= ion works for all protocol types.
- No need to creation options and teac= h devices that options is NOT an exception path processing
- Really worr= y about ordering in IPv6 options
- Note that all the OAM data need to be= deleted as well so position need to be optimal for removal. We can always = do tail stamping of the data but this puts considerable constrains on the c= ell based architecture
- L4 accessibility I have already mentioned
I am happy to discuss with you in person and explain more but bottom line= is that this proposal is what came out with MSDC discussions in light of s= hortcomings from other IETF proposals.

=

=C2=A0

As they say, you are free to run whatever you want in your= proprietary network, but if you expect to create an interoperable, deploya= ble protocoI and get a protocol number assignment, you'll need to work = in ietf. That is going to require justifying the protocol even in light of = shortcomings in existing protocoIs.

=C2=A0

Tom

=C2=A0

<= /div>


Regards,
-Jai

<= br>=EF=BB=BFOn 4/5/19, 12:28 PM, "Tom Herbert" <tom@herbertla= nd.com> wrote:

=C2=A0 =C2=A0 On Fri, Apr 5, 2019 at 12:03 PM = Jai Kumar <jai.kumar@broadcom.com> wrote:
=C2=A0 =C2=A0 &g= t;
=C2=A0 =C2=A0 > " Great, but this IETF"
=C2=A0 =C2=A0= > Does it mean that drafts have no relevance to deployment and actual a= doption.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > For all your queries p= lease take a look at IFA draft.
=C2=A0 =C2=A0 > https://datatracker.ietf.org/doc/draft-kumar-ippm-ifa/
=C2= =A0 =C2=A0 >
=C2=A0 =C2=A0 I've looked at that draft. It's is= creating a complete new IP
=C2=A0 =C2=A0 protocolas well as a new packe= t format for TCP and UDP that somehow
=C2=A0 =C2=A0 inserts meta data be= tween the TCP header and payload. I don't
=C2=A0 =C2=A0 understand w= hy this could possibly be better than just using flow
=C2=A0 =C2=A0 labe= l for ECMP and teaching devices that need to extract transport
=C2=A0 = =C2=A0 information how to walk over EH, or just using some UDP encpasulatio= n
=C2=A0 =C2=A0 like in draft-herbert-ipv4-udpencap-eh-01.

=C2=A0= =C2=A0 Tom

=C2=A0 =C2=A0 > It handles IPv6, IPv4 TCP/UDP with al= tering the packet path (due to inserting options and/or encaping them in GR= E header) as well as IPSec AH/ESP/WESP both tunnel and transport and guess = what it is successfully deployed.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 &g= t; -Jai
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > =EF=BB=BFOn 4/5/19, 11:= 54 AM, "Tom Herbert" <tom@herbertland.com> wrote:
= =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On Fri, Apr 5, = 2019 at 11:25 AM Jai Kumar <jai.kumar@broadcom.com> wrote:=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 >=C2=A0 =C2= =A0 =C2=A0> Tom,
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>
=C2=A0= =C2=A0 >=C2=A0 =C2=A0 =C2=A0> I am speaking based on the actual depl= oyment not based on if all the traffic is/will move to IPSec tunnel.
=C2= =A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 = =C2=A0> I have 6 large customer deployments and one someone previously c= alled as "Yahoo" who insist on visibility in L4 even for IOAM pac= kets.
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 >= =C2=A0 =C2=A0 =C2=A0And I've worked in datcenters much larger, and my f= irst rule is that I
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0don't want= random router vendors dictating to me what protocols I'm
=C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0allowed to use in my datacenter.
=C2=A0 =C2= =A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> I can quote you on t= hat and lose my business :-)
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0><= br>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> ECMP argument is weak as well= as it works for IPv6 flow label. What about IPv4 TCP/UDP traffic which typ= ically is 80% of the traffic in MSDC.
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 = =C2=A0>
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0d= raft-herbert-ipv4-udpencap-eh-01
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >= ;=C2=A0 =C2=A0 =C2=A0> If someone tells me that proposal will work only = for my 20% of traffic then again as I said before, they will lose my busine= ss :-)
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 >= =C2=A0 =C2=A0 =C2=A0Great, but this IETF. Where are the protocol requiremen= ts? If you are
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0saying that there a= re requirements for "visibility in L4" what are
=C2=A0 =C2=A0 = >=C2=A0 =C2=A0 =C2=A0they? If you are saying that ACLs are now required = for packet
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0forwarding, where is th= at described? Is it a MUST that teh only
=C2=A0 =C2=A0 >=C2=A0 =C2=A0= =C2=A0transport protocols we're allowed to use are=C2=A0 UDP or TCP? A= re we
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0allowed to use extension hea= ders at all? I suppose fragmentation is
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 = =C2=A0right out... Are we violating the requirements if we encrypt the
= =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0transport headers? If you say that we= shouldn't send long headers
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0b= ecause we'll overflow parsing buffers, then what is the limit? Please=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0be SPECIFC in setting requirements;= we are trying to build protocols
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0= that work and are interoperable and we need to get out of this morass
= =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0of reverse engineering to discover th= e least common denominator.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2= =A0 =C2=A0 =C2=A0Tom
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >=C2=A0 =C2= =A0 =C2=A0> Regards,
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0> -Jai<= br>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 >=C2=A0 = =C2=A0 =C2=A0> =EF=BB=BFOn 4/5/19, 11:15 AM, "Tom Herbert" <= ;tom@herbertland.com> wrote:
=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=A0On= Fri, Apr 5, 2019 at 10:55 AM Jai Kumar <jai.kumar@broadcom.com&= gt; wrote:
=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 =C2=A0 =C2=A0&g= t; Even if we use flow label for ECMP, lack of accessibility of L4 informat= ion (for various services, most simple is ACL) makes the proposal pretty mu= ch unusable.
=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 =C2=A0 =C2=A0Th= at is convoluting router and firewall functionality and
=C2=A0 =C2=A0 &g= t;=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0requirements. This a discussi= on about packet forwarding which does
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 = =C2=A0>=C2=A0 =C2=A0 =C2=A0_not_ require ACLs. In a limited domain, for = which IOAM is intended,
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0= =C2=A0 =C2=A0it is unlikely that they'll ACLs would be used in interna= l nodes, but
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0we do need good ECMP routing at all intermediate nodes need to be
=C2= =A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0consistent rathe= r or not that the IOAM option is present. As side
=C2=A0 =C2=A0 >=C2= =A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0note, the ability to extract L4 in= formation out of packets is
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>= =C2=A0 =C2=A0 =C2=A0dwindling anyway thanks to encryption and other techniq= ues trying to
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 = =C2=A0undo protocol ossification. For instance, good luck getting L4
=C2= =A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0information out = of an IPsec tunnel :-).
=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=A0Tom
=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> NIC cards are not used pervasively for ACLs= and other services, I believe iptables in kernel are good enough for host = but that=E2=80=99s not acceptable in networking elements.
=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 =C2=A0 =C2=A0> -Jai
=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 =C2=A0 =C2=A0> =EF=BB=BFOn 4/5/19, 10:31 AM,= "ippm on behalf of Tom Herbert" <ippm-bounces@ietf.org= on behalf of tom@herbertland.com> wrote:
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0On Fri, Apr 5,= 2019 at 9:16 AM Pengshuping (Peng Shuping)
=C2=A0 =C2=A0 >=C2=A0 =C2= =A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0<pengshupi= ng@huawei.com> wrote:
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Hi Ba= rak,
=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 =C2=A0 =C2=A0>=C2= =A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> We are certainly not designin= g for the lowest capable solutions but exploring optimal solutions which co= uld help to keep the forwarding performance while inserting the iOAM data w= ith variable length.
=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 =C2= =A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Shuping,
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0That's exactly th= e argument for using the flow label in ECMP.
=C2=A0 =C2=A0 >=C2=A0 = =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Efficeint pack= et forwarding can be done solely by inspected the forty
=C2=A0 =C2=A0 &g= t;=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0byte = fixed length header of the packet regardless of the contents of
=C2=A0 = =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 = =C2=A0the rest of the packet. That is an optimal solution. Anything else fo= r
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2= =A0 =C2=A0 =C2=A0ECMP like doing DPI or hacking up IOAM to try do pull tran= sport layers
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0>=C2=A0 =C2=A0 =C2=A0into the parsing buffer (whatever size that may = be) are nothing more
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0than hacks and unnecessarily perpetuat= e techniques used with IPv4 that
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0&= gt;=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0either don't work or are= unnecessary in IPv6.
=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 =C2= =A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Tom
=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 =C2=A0 =C2=A0>
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0&g= t;=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>=C2=A0 =C2=A0 =C2=A0> In te= rms of the forwarding efficiency, we would all agree that a short and fixed= header would be better than a variable header.
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2= =A0 =C2=A0> Best regards
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>= =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Shuping
=C2=A0 =C2=A0 &= gt;=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>=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>=C2=A0 =C2=A0 =C2=A0> =E5=8F=91=E4=BB= =B6=E4=BA=BA=EF=BC=9A Barak Gafni<gbarak@mellanox.com>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> =E6=94= =B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Pengshuping (Peng Shuping)<pen= gshuping@huawei.com>;Frank Brockners (fbrockne)<fbrockne@cisco.co= m>;Mikael Abrahamsson<swmike@swm.pp.se>
=C2=A0 =C2=A0 >= ;=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> <= span style=3D"font-family:"MS Gothic"">=E6=8A=84=E9=80=81=EF=BC= =9A C. M. Heard<heard@pobox.com>;6man WG<ipv6@ietf.org>;= Mark Smith<markzzzsmith@gmail.com>;ippm<ippm@ietf.org>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> =E4=B8= =BB=E9=A2=98=EF=BC=9A RE: draft-ioametal-= ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM da= ta fields)
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0>=C2=A0 =C2=A0 =C2=A0> =E6=97= =B6=E9=97=B4=EF=BC= =9A 2019-04-05 03:18:26
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Hi Sh= uping,
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>= ;=C2=A0 =C2=A0 =C2=A0> I think that the question is whether we design fo= r the lowest capable solutions. I assume someone can find solutions with ev= en lower amount of parsing.. The low end solutions for these capabilities m= ay need to either adopt with new designs or use solutions such as what is s= uggested in this thread by Tom Herbert.
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 = =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Personally, I do= n't think we should go this way, but to design appropriate solutions, w= ith appropriate layers in the headers. For example, prevent dependencies be= tween "remote" headers.
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Th= anks,
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>= =C2=A0 =C2=A0 =C2=A0> Barak
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> -----= Original Message-----
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> From: ippm <ippm-bounces@ie= tf.org> On Behalf Of Pengshuping (Peng Shuping)
=C2=A0 =C2=A0 >= ;=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> S= ent: Wednesday, April 3, 2019 6:47 AM
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 = =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> To: Frank Brockn= ers (fbrockne) <fbrockne@cisco.com>; Mikael Abrahamsson <swmike@= swm.pp.se>
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2= =A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Cc: C. M. Heard <heard@pobox.com= >; 6man WG <ipv6@ietf.org>; Mark Smith <markzzzsmith@gmail.c= om>; ippm@ietf.org
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2= =A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Subject: [ippm] =E7=AD=94=E5=A4=8D: draft-ioa= metal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for I= OAM data fields)
=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 =C2=A0 =C2= =A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Hi,
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0&g= t;=C2=A0 =C2=A0 =C2=A0> The parsing depth of the early chips is 96B/128B= . For the new chips the parsing depth has been increased but still limited.= So Mikael's concern makes sense especially in the tracing mode that th= e IOAM data fields are going to increase significantly along the path, whic= h will even push the Routing Header out of the parsing depth of the chip. S= o it would make sense to split the IOAM data part from the IOAM header/inst= ruction part, and place the IOAM data after the RH or even after the L4 hea= der in order to be able to read the L4 information to enable ECMP, as state= d in the draft https://eur03.safelinks.protect= ion.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-li-6man-= ipv6-sfc-ifit-00&amp;data=3D02%7C01%7Cgbarak%40mellanox.com%7C612ba6dc1= 17440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636898= 960379485833&amp;sdata=3DDob4zN%2F1jSGxLTlqGma29JJNvqJDBt4VzqHsN4OpxM4%= 3D&amp;reserved=3D0.
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> BR,=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> Shuping
=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 = =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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 = =C2=A0> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0&g= t;=C2=A0 =C2=A0 =C2=A0> =E5=8F=91=E4=BB=B6=E4=BA=BA: ippm [mailto:ippm-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Frank Brockners (fbrockne= )
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2= =A0 =C2=A0 =C2=A0> =E5=8F=91<= span style=3D"font-family:"MS Gothic"">=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B44=E6=9C=882=E6=97=A5 17:40
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 = =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> =E6=94=B6=E4=BB=B6=E4=BA=BA: Mikae= l Abrahamsson <swmike@swm.pp.se>
=C2=A0 =C2=A0 >=C2=A0 =C2=A0= =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> =E6=8A=84=E9=80=81: C. M. Heard &= lt;= heard@pobox.com>; 6man WG <ipv6@ietf.org>; Mark Smith <markzzzsmith@gmail.com>; ippm@ietf.org
=C2=A0 =C2=A0 >=C2=A0 = =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> =E4=B8=BB=E9=A2=98: Re: [ippm] draft-ioametal-ippm-6man-ioa= m-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields)=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 =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 =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 =C2=A0 =C2=A0&g= t; -----Original Message-----
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>= =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> From: Mikael Abrahamsson &= lt;swmike@swm.pp.se>
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2= =A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Sent: Dienstag, 2. April 2019= 08:06
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>= ;=C2=A0 =C2=A0 =C2=A0> To: Frank Brockners (fbrockne) <fbrockne@cisco= .com>
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0>=C2=A0 =C2=A0 =C2=A0> Cc: Mark Smith <markzzzsmith@gmail.c= om>; C. M. Heard <heard@pobox.com>; 6man WG <ipv6@ietf.org&= gt;; = ippm@ietf.org
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2= =A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Subject: RE: draft-ioametal-ippm-6ma= n-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data field= s)
=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 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> On Mon, 1 Apr 2019, Frank Brockne= rs (fbrockne) wrote:
=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 =C2= =A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > ...FB: = There is obviously no easy answer. Couple of thoughts:
=C2=A0 =C2=A0 >= ;=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> &= gt; * IOAM is considered a "domain specific" feature (see
=C2= =A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2= =A0 =C2=A0> > draft-ietf-ippm-ioam-data-05, section 3). Routers in th= e IOAM domain
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 = =C2=A0>=C2=A0 =C2=A0 =C2=A0> > should be IOAM capable.=C2=A0 And I= MHO,=C2=A0 we should add a statement to
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 = =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > draft-ioame= tal-ippm-6man-ioam-ipv6-deployment that an implementation
=C2=A0 =C2=A0 = >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>= ; > of IOAM MUST ensure "C1".
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2= =A0 =C2=A0> > * That said, there can be situations, where C1 cannot b= e achieved, e.g..
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2= =A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > consider a network which does E= CMP scheduling based on packet length.
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 = =C2=A0> > * What one could consider - and which is one suggested depl= oyment
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>= ;=C2=A0 =C2=A0 =C2=A0> > model
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2= =A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > - is that by d= efault IOAM data fields are added to _all_ customer
=C2=A0 =C2=A0 >= =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> &g= t; packets. The decapsulating node would decide whether the IOAM
=C2=A0 = =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 = =C2=A0> > information contained in a packet would be used (and export= ed) or not.
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0>=C2=A0 =C2=A0 =C2=A0> > That way one would not need to deal wi= th the situation that some
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2= =A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > traffic carries IOAM whi= le other does not - and might thus be treated
=C2=A0 =C2=A0 >=C2=A0 = =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > diff= erently.
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0&= gt;=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> Yes, I think this is the o= nly way. Is there a risk that intermediate routers would not be IOAM capabl= e? I think the C1 requirement is really really hard to fulfil and I'm a= lso afraid that adding the IOAM header will actually make ECMP stop working= on some platforms (because they would not have the capability to look deep= enough into the packet to find L4 information, so it'll go back to 2 t= uple ECMP instead of 5 tuple.
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> But t= his question can only be answered by people with deep NPU knowledge...
= =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 =C2=A0 =C2=A0>=C2=A0 =C2= =A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> .....FB2: Given that IOAM is a domai= n specific feature - I expect that folks initially start to use it in domai= ns (like e.g. a DC) where all boxes are IOAM capable and can trace the pack= et appropriately - or per Tom's note, can be configured so that one wou= ld do ECMP based on addresses and flow-label.=C2=A0 There are chips with pr= etty deep parsing capability (up to a few hundred bytes).
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2= =A0 =C2=A0 =C2=A0> > ...FB: The comparison to MPLS is interesting. Ho= w often do MPLS
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 = =C2=A0>=C2=A0 =C2=A0 =C2=A0> > packets leak and cause harm? For IO= AM,
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>= =C2=A0 =C2=A0 =C2=A0> > draft-ioametal-ippm-6man-ioam-ipv6-options-02= proposes a deployment
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > model similar to what we do = for MPLS: Unless an interface is
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0&= gt;=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > explicitly configu= red for IOAM, packets with IOAM data fields MUST be dropped.
=C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0> > Hence leakage would only occur, if we have a clearly misbehavi= ng
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2= =A0 =C2=A0 =C2=A0> > router which violates this rule. Similar to you,= I'd also greatly
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > appreciate any pointers to r= esearch on how common MPLS leaked packets are.
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 = =C2=A0> When it comes to "cause harm" I imagine there are (at = least) two ways to cause harm, one is privacy/secrecy/security loss and the= other one is actual operational loss.
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0&g= t; I know of bugs where labeled packets went the wrong way and caused them = to be lost, I've also seen bugs where bugs caused traffic to "hop&= quot; between VRFs in MPLS VPN (or to "global" VRF). I don't = have numbers on this though.
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Depen= ding on the deployment scenario, it might make sense to make IOAM packets n= ot valid for non-IOAM aware devices (basically encap entire packet/payload)= , but that might be a problem for intermediate non-IOAM nodes then. This wo= uld affect the ECMP requirement. I can see cases where one would operationa= lly turn on IOAM for some customers traffic and then see the problem go awa= y because now ECMP changed.
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> > = ...FB: One idea that Shwetha came up with to identify the source AS of
= =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0> > a leaked packet, would be to add a new new IOAM E2E = option - as
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0>=C2=A0 =C2=A0 =C2=A0> > proposed in section 5.1.1 bullet 2 of<= br>=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0= =C2=A0 =C2=A0> > draft-ioametal-ippm-6man-ioam-ipv6-deployment-01.=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 =C2=A0 =C2=A0>=C2=A0 =C2= =A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Yes, that'd solve that problem.<= br>=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 =C2=A0 =C2=A0>=C2=A0 =C2= =A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> How much has the silicon people been= involved so far in the design of the headers? What is the current thinking= of amount of data going into the IOAM header? Considering things like trac= e options etc it seems to me the header can grow quite large? To satisfy th= e ECMP requirement what about putting the IOAM information as a trailer beh= ind the regular payload? Or is there a problem for the hw to manipulate inf= ormation that far into the packet (I also imagine this will considerably lo= wer the forwarding performance of IOAM packets on IOAM aware platforms).=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 =C2=A0 =C2=A0>=C2=A0 =C2= =A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> .....FB2: There are quite a few folk= s with hardware background that co-author the IOAM drafts. Parsing capabili= ty differs between chips, as does the ability to deal with new/flexible hea= ders and the ability to modify data in the extension headers. So the unfort= unate answer to that question is "it depends" (what information d= o you gather, how large is your domain, what are the capabilities of your h= ardware/software forwarder, etc.), but I do expect that for specific deploy= ment domains (e.g. DC, Enterprise) - but also for overlay networks / VPNs -= we'll see an increasing amount of chips that are well suited for proce= ssing large extension header.
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Cheer= s, Frank
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0&= gt;=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> --
=C2=A0 =C2=A0 >= =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Mi= kael Abrahamsson=C2=A0 =C2=A0 email: swmike@swm.pp.se
=C2=A0 =C2=A0 &g= t;=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0><= br>=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2= =A0 =C2=A0> ippm mailing list
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0&= gt;=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> ippm@ietf.org
=C2=A0 = =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 = =C2=A0> https://eur03.safelinks.protection.outlook.com/?u= rl=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&amp;data=3D= 02%7C01%7Cgbarak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca65297= 1c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636898960379485833&amp;sdata=3DVjZ= 1PiwifYGCf159je0yef3BJFz6AQNNAtkgmAMDFKM%3D&amp;reserved=3D0
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 = =C2=A0> ippm mailing list
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>= =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> ippm@ietf.org
=C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0> https://eur03.safelinks.protection.outlook.com/?url=3D= https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&amp;data=3D02%7C= 01%7Cgbarak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2= e4d9ba6a4d149256f461b%7C0%7C0%7C636898960379485833&amp;sdata=3DVjZ1Piwi= fYGCf159je0yef3BJFz6AQNNAtkgmAMDFKM%3D&amp;reserved=3D0
=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 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>= =C2=A0 =C2=A0 =C2=A0> IETF IPv6 working group mailing list
=C2=A0 =C2= =A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0> ipv6@ietf.org
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 = =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
=C2=A0 =C2=A0= >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0&g= t; --------------------------------------------------------------------
= =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 =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 =C2=A0 =C2=A0ipp= m mailing list
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 = =C2=A0>=C2=A0 =C2=A0 =C2=A0ippm@ietf.org
=C2=A0 =C2=A0 >=C2=A0 =C2= =A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0= https://www.ietf.org/mailman/listinfo/ippm
=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 =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 =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 =C2=A0 >
=C2= =A0 =C2=A0 >


--000000000000ae4abb0585d01700-- From nobody Fri Apr 5 16:40:27 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1E4E12021B for ; Fri, 5 Apr 2019 16:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.com 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 RSaJhP_-ogHb for ; Fri, 5 Apr 2019 16:40:20 -0700 (PDT) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3181201A8 for ; Fri, 5 Apr 2019 16:40:20 -0700 (PDT) Received: by mail-pg1-x52d.google.com with SMTP id e6so3853571pgc.4 for ; Fri, 05 Apr 2019 16:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version; bh=8Fw/BTqE447vHo8LL5w13Ep0DujwSUSqi7mDuJI1+2Q=; b=eNpHNSeckWqz7tq73XieYYFkiJlxJFHtJZ6YStYc5wsD+wXh5CJ7yI68LTLUImSmUH NgKiJURLFRLJ3YS8aoLaPLKWFJnpT0GrinLw8Y6odF/7p8lpARtQJ3F6ZQknooXvhEIa VYDjbXjXwn1uDv8YeJpiPMUtxJCOjKhl77eio= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version; bh=8Fw/BTqE447vHo8LL5w13Ep0DujwSUSqi7mDuJI1+2Q=; b=IhSauDPLZGFGkiBsC+eAJPHWkPy5IoeS7sQx6uWk3RyS/EdNFKyFZs6zcDBnMi3u5X MgGdDJX3fTb2gXDfOC9qfikqzQPMJhI7n395Ja8ozYN0mEuoYCceC40Q3KMQY9S4WHG+ JSbFX8vxD1Gcn6FebxLbOT/tA62mTfvvFFQ3O1Irjto9LiBpxwpw5YOh9hDV2gVHUaBV 0CaKE4MYWtny8rwJAD8db2qHBQVBkAtbXKS0K1U/mIK2HH2q7LFUFr85UjAj3iJ8mv1M 0bIg6i/s4PWT6y3Yrb+JdgSOKn/skXCZCLWNONlrqb3wwKLP/BG92qiXxWfRwrSPvRtW sQ3Q== X-Gm-Message-State: APjAAAVqVAOcYrMvVOHkWhYaNiop5KXhZ7wVVnQzpDnzGLCjWLBINpkX JaAiACKUCNmMfH76dOcfDLQIUA== X-Google-Smtp-Source: APXvYqy4hjj6ac6cs6hxeJBLE/TWF5ZXkMy8wxt39hhupanq4AyTUcp5mXsTFxvAkihIFJQM8RgMSw== X-Received: by 2002:a65:62ce:: with SMTP id m14mr3366382pgv.191.1554507619864; Fri, 05 Apr 2019 16:40:19 -0700 (PDT) Received: from [10.58.68.119] ([192.19.222.250]) by smtp.gmail.com with ESMTPSA id h20sm9443951pfj.40.2019.04.05.16.40.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Apr 2019 16:40:19 -0700 (PDT) User-Agent: Microsoft-MacOutlook/10.17.1.190326 Date: Fri, 05 Apr 2019 16:40:13 -0700 From: Jai Kumar To: Tom Herbert CC: "Pengshuping (Peng Shuping)" , 6man , ippm , "C. M. Heard" , Mikael Abrahamsson Message-ID: <36B9204A-D1EE-4067-92BB-6C33CB2DF791@broadcom.com> Thread-Topic: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> <4278D47A901B3041A737953BAA078ADE1478D5E2@DGGEML532-MBX.china.huawei.com> <4278D47A901B3041A737953BAA078ADE1478EC8B@DGGEML532-MBX.china.huawei.com> <14A3D5C9-1EED-4E11-9329-B62B819271A2@broadcom.com> <20D6FCDB-3357-4728-BD52-8069C32F3CCA@broadcom.com> <57A32C37-AAE9-44F2-9C96-39AFA71BDC21@broadcom.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3637327217_1761545825" Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 23:40:26 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3637327217_1761545825 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Tom, =20 You are right. There are two main cases where accessibility of transport he= ader becomes an issue. And that is mainly because of current generation of f= ixed pipeline cell based architecture parse depth (not so much an issue for = high end NPU where next packet header bytes can be DMA=E2=80=99ed in, though it im= pacts the performance. For eg. Cisco QFP NPU, EZ Chip, Juniper=E2=80=99s MX 3D NPU= , or Broadcom=E2=80=99s Jerricho NPU ). This was mentioned earlier by Mikael as we= ll. =20 Case 1. SRv6 Case 2. IPv6 with EH (mainly for 5G deployments where RH, DH, and IFA Heade= r)=20 =20 Typically NPUs provide capability that it will handle 3 or 4 EH or SRH with= out performance penalty. With the presence of IFA header this means that for= eg there can be only 2 or 3 SRH or EH. This is same as in MPLS label stack = depth handling (PUSH or POP at PE router). Given the evolution SRV6 and MPLS= -SR kind of headers, silicon vendors have taken a notice of it and are evolv= ing the silicon arch to handle more chained headers. =20 IFA supports fragmentation of metadata stack and also postcard mode so beyo= nd the transport header it=E2=80=99s not an issue. =20 Just a quick feedback on using IPv6 options, inserting hop by hop options f= or data path processing pushes the EH further down and impacts the node=E2=80=99s = forwarding function (say if it is not able to reach Destination EH) vs if IF= A header is the last EH then atmost transit node do not perform metadata col= lection which can be identified. =20 -Jai =20 From: Tom Herbert Date: Friday, April 5, 2019 at 3:34 PM To: Jai Kumar Cc: "Pengshuping (Peng Shuping)" , 6man , ippm , "C. M. Heard" , Mikael Abrahams= son Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedba= ck (Re: v6 option types for IOAM data fields) =20 Jai, =20 You might want to consider how IFA works in the presence of segment routing= . The second someone puts an SRH in the packet the IFA headers get pushed do= wn and the transport headers end up being deep in the packet anyway so that = all the effort of IFA is nullified. If the requirement is to ensure that the= transport layer information appear as early as possible in the packet, one = could define a Hop-by-Hop option to carry some sort of pseudo header for the= transport layer. This also would work in the case that the actual transport= layer is obfuscated. =20 Tom =20 On Fri, Apr 5, 2019, 3:09 PM Jai Kumar wrote: =E2=80=9CThat is going to require justifying the protocol even in light of shortc= omings in existing protocoIs.=E2=80=9D =20 Agreed !!! True for any proposal. =20 -Jai =20 From: Tom Herbert Date: Friday, April 5, 2019 at 2:34 PM To: Jai Kumar Cc: "Pengshuping (Peng Shuping)" , 6man , ippm , "C. M. Heard" , Mikael Abrahams= son Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedba= ck (Re: v6 option types for IOAM data fields) =20 =20 On Fri, Apr 5, 2019, 2:07 PM Jai Kumar wrote: Tom, Its all explained in the requirements section of the draft. IFA header is e= ssentially treated as an EH both in IPv4 and IPv6 (very similar to AH/ESP EH= ). Just like in AH/ESP the IP protocol is copied in the AH header and IP proto= col field is replaced in the IP header with the AH proto. There are several advantages to this approach. - devise know how to parse AH header and can follow very similar approach - Protocol agnostics, silicon need not support N encaps (just like AH/ESP).= Single implementation works for all protocol types. - No need to creation options and teach devices that options is NOT an exce= ption path processing - Really worry about ordering in IPv6 options - Note that all the OAM data need to be deleted as well so position need to= be optimal for removal. We can always do tail stamping of the data but this= puts considerable constrains on the cell based architecture - L4 accessibility I have already mentioned I am happy to discuss with you in person and explain more but bottom line i= s that this proposal is what came out with MSDC discussions in light of shor= tcomings from other IETF proposals. =20 As they say, you are free to run whatever you want in your proprietary netw= ork, but if you expect to create an interoperable, deployable protocoI and g= et a protocol number assignment, you'll need to work in ietf. That is going = to require justifying the protocol even in light of shortcomings in existing= protocoIs. =20 Tom =20 Regards, -Jai =EF=BB=BFOn 4/5/19, 12:28 PM, "Tom Herbert" wrote: On Fri, Apr 5, 2019 at 12:03 PM Jai Kumar wrot= e: > > " Great, but this IETF" > Does it mean that drafts have no relevance to deployment and actual a= doption. > > For all your queries please take a look at IFA draft. > https://datatracker.ietf.org/doc/draft-kumar-ippm-ifa/ > I've looked at that draft. It's is creating a complete new IP protocolas well as a new packet format for TCP and UDP that somehow inserts meta data between the TCP header and payload. I don't understand why this could possibly be better than just using flow label for ECMP and teaching devices that need to extract transport information how to walk over EH, or just using some UDP encpasulation like in draft-herbert-ipv4-udpencap-eh-01. Tom > It handles IPv6, IPv4 TCP/UDP with altering the packet path (due to i= nserting options and/or encaping them in GRE header) as well as IPSec AH/ESP= /WESP both tunnel and transport and guess what it is successfully deployed. > > -Jai > > =EF=BB=BFOn 4/5/19, 11:54 AM, "Tom Herbert" wrote: > > On Fri, Apr 5, 2019 at 11:25 AM Jai Kumar wrote: > > > > Tom, > > > > I am speaking based on the actual deployment not based on if al= l the traffic is/will move to IPSec tunnel. > > > > I have 6 large customer deployments and one someone previously = called as "Yahoo" who insist on visibility in L4 even for IOAM packets. > > > And I've worked in datcenters much larger, and my first rule is t= hat I > don't want random router vendors dictating to me what protocols I= 'm > allowed to use in my datacenter. > > > I can quote you on that and lose my business :-) > > > > ECMP argument is weak as well as it works for IPv6 flow label. = What about IPv4 TCP/UDP traffic which typically is 80% of the traffic in MSD= C. > > > > draft-herbert-ipv4-udpencap-eh-01 > > > If someone tells me that proposal will work only for my 20% of = traffic then again as I said before, they will lose my business :-) > > > Great, but this IETF. Where are the protocol requirements? If you= are > saying that there are requirements for "visibility in L4" what ar= e > they? If you are saying that ACLs are now required for packet > forwarding, where is that described? Is it a MUST that teh only > transport protocols we're allowed to use are UDP or TCP? Are we > allowed to use extension headers at all? I suppose fragmentation = is > right out... Are we violating the requirements if we encrypt the > transport headers? If you say that we shouldn't send long headers > because we'll overflow parsing buffers, then what is the limit? P= lease > be SPECIFC in setting requirements; we are trying to build protoc= ols > that work and are interoperable and we need to get out of this mo= rass > of reverse engineering to discover the least common denominator. > > Tom > > > Regards, > > -Jai > > > > =EF=BB=BFOn 4/5/19, 11:15 AM, "Tom Herbert" wro= te: > > > > On Fri, Apr 5, 2019 at 10:55 AM Jai Kumar wrote: > > > > > > Even if we use flow label for ECMP, lack of accessibility= of L4 information (for various services, most simple is ACL) makes the prop= osal pretty much unusable. > > > > > That is convoluting router and firewall functionality and > > requirements. This a discussion about packet forwarding whi= ch does > > _not_ require ACLs. In a limited domain, for which IOAM is = intended, > > it is unlikely that they'll ACLs would be used in internal = nodes, but > > we do need good ECMP routing at all intermediate nodes need= to be > > consistent rather or not that the IOAM option is present. A= s side > > note, the ability to extract L4 information out of packets = is > > dwindling anyway thanks to encryption and other techniques = trying to > > undo protocol ossification. For instance, good luck getting= L4 > > information out of an IPsec tunnel :-). > > > > Tom > > > > > NIC cards are not used pervasively for ACLs and other ser= vices, I believe iptables in kernel are good enough for host but that=E2=80=99s no= t acceptable in networking elements. > > > > > > -Jai > > > > > > =EF=BB=BFOn 4/5/19, 10:31 AM, "ippm on behalf of Tom Herbert" <= ippm-bounces@ietf.org on behalf of tom@herbertland.com> wrote: > > > > > > On Fri, Apr 5, 2019 at 9:16 AM Pengshuping (Peng Shup= ing) > > > wrote: > > > > > > > > Hi Barak, > > > > > > > > We are certainly not designing for the lowest capab= le solutions but exploring optimal solutions which could help to keep the fo= rwarding performance while inserting the iOAM data with variable length. > > > > > > Shuping, > > > > > > That's exactly the argument for using the flow label = in ECMP. > > > Efficeint packet forwarding can be done solely by ins= pected the forty > > > byte fixed length header of the packet regardless of = the contents of > > > the rest of the packet. That is an optimal solution. = Anything else for > > > ECMP like doing DPI or hacking up IOAM to try do pull= transport layers > > > into the parsing buffer (whatever size that may be) a= re nothing more > > > than hacks and unnecessarily perpetuate techniques us= ed with IPv4 that > > > either don't work or are unnecessary in IPv6. > > > > > > Tom > > > > > > > > > > > > > > In terms of the forwarding efficiency, we would all= agree that a short and fixed header would be better than a variable header. > > > > > > > > Best regards > > > > Shuping > > > > > > > > > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Barak Gafni > > > > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Pengshuping (Peng Shuping);Frank Brockners (fbrockne);Mikael Abrahamss= on > > > > =E6=8A=84=E9=80=81=EF=BC=9A C. M. Heard;6man WG;Mark Smith;ippm > > > > =E4=B8=BB=E9=A2=98=EF=BC=9A RE: draft-ioametal-ippm-6man-ioam-ipv6-de= ployment-00 feedback (Re: v6 option types for IOAM data fields) > > > > =E6=97=B6=E9=97=B4=EF=BC=9A 2019-04-05 03:18:26 > > > > > > > > Hi Shuping, > > > > I think that the question is whether we design for = the lowest capable solutions. I assume someone can find solutions with even = lower amount of parsing.. The low end solutions for these capabilities may n= eed to either adopt with new designs or use solutions such as what is sugges= ted in this thread by Tom Herbert. > > > > Personally, I don't think we should go this way, bu= t to design appropriate solutions, with appropriate layers in the headers. F= or example, prevent dependencies between "remote" headers. > > > > > > > > Thanks, > > > > Barak > > > > > > > > -----Original Message----- > > > > From: ippm On Behalf Of Pen= gshuping (Peng Shuping) > > > > Sent: Wednesday, April 3, 2019 6:47 AM > > > > To: Frank Brockners (fbrockne) = ; Mikael Abrahamsson > > > > Cc: C. M. Heard ; 6man WG ; Mark Smith ; ippm@ietf.org > > > > Subject: [ippm] =E7=AD=94=E5=A4=8D: draft-ioametal-ippm-6man-io= am-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) > > > > > > > > Hi, > > > > > > > > The parsing depth of the early chips is 96B/128B. F= or the new chips the parsing depth has been increased but still limited. So = Mikael's concern makes sense especially in the tracing mode that the IOAM da= ta fields are going to increase significantly along the path, which will eve= n push the Routing Header out of the parsing depth of the chip. So it would = make sense to split the IOAM data part from the IOAM header/instruction part= , and place the IOAM data after the RH or even after the L4 header in order = to be able to read the L4 information to enable ECMP, as stated in the draft= https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.iet= f.org%2Fhtml%2Fdraft-li-6man-ipv6-sfc-ifit-00&data=3D02%7C01%7Cgbarak%40me= llanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f= 461b%7C0%7C0%7C636898960379485833&sdata=3DDob4zN%2F1jSGxLTlqGma29JJNvqJDBt= 4VzqHsN4OpxM4%3D&reserved=3D0. > > > > > > > > BR, > > > > Shuping > > > > > > > > > > > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: ippm [mailto:ippm-bounces@ietf.org] =E4=BB=A3=E8= =A1=A8 Frank Brockners (fbrockne) > > > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B44=E6=9C=882=E6=97=A5 17:40 > > > > =E6=94=B6=E4=BB=B6=E4=BA=BA: Mikael Abrahamsson > > > > =E6=8A=84=E9=80=81: C. M. Heard ; 6man WG ; Mark Smith ; ippm@ietf.org > > > > =E4=B8=BB=E9=A2=98: Re: [ippm] draft-ioametal-ippm-6man-ioam-ip= v6-deployment-00 feedback (Re: v6 option types for IOAM data fields) > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: Mikael Abrahamsson > > > > Sent: Dienstag, 2. April 2019 08:06 > > > > To: Frank Brockners (fbrockne) > > > > Cc: Mark Smith ; C. M. Hear= d ; 6man WG ; ippm@ietf.org > > > > Subject: RE: draft-ioametal-ippm-6man-ioam-ipv6-dep= loyment-00 feedback (Re: v6 option types for IOAM data fields) > > > > > > > > On Mon, 1 Apr 2019, Frank Brockners (fbrockne) wrot= e: > > > > > > > > > ...FB: There is obviously no easy answer. Couple = of thoughts: > > > > > * IOAM is considered a "domain specific" feature = (see > > > > > draft-ietf-ippm-ioam-data-05, section 3). Routers= in the IOAM domain > > > > > should be IOAM capable. And IMHO, we should add= a statement to > > > > > draft-ioametal-ippm-6man-ioam-ipv6-deployment tha= t an implementation > > > > > of IOAM MUST ensure "C1". > > > > > > > > > > * That said, there can be situations, where C1 ca= nnot be achieved, e.g.. > > > > > consider a network which does ECMP scheduling bas= ed on packet length. > > > > > > > > > > * What one could consider - and which is one sugg= ested deployment > > > > > model > > > > > - is that by default IOAM data fields are added t= o _all_ customer > > > > > packets. The decapsulating node would decide whet= her the IOAM > > > > > information contained in a packet would be used (= and exported) or not. > > > > > That way one would not need to deal with the situ= ation that some > > > > > traffic carries IOAM while other does not - and m= ight thus be treated > > > > > differently. > > > > > > > > Yes, I think this is the only way. Is there a risk = that intermediate routers would not be IOAM capable? I think the C1 requirem= ent is really really hard to fulfil and I'm also afraid that adding the IOAM= header will actually make ECMP stop working on some platforms (because they= would not have the capability to look deep enough into the packet to find L= 4 information, so it'll go back to 2 tuple ECMP instead of 5 tuple. > > > > > > > > But this question can only be answered by people wi= th deep NPU knowledge... > > > > > > > > .....FB2: Given that IOAM is a domain specific feat= ure - I expect that folks initially start to use it in domains (like e.g. a = DC) where all boxes are IOAM capable and can trace the packet appropriately = - or per Tom's note, can be configured so that one would do ECMP based on ad= dresses and flow-label. There are chips with pretty deep parsing capability= (up to a few hundred bytes). > > > > > > > > > ...FB: The comparison to MPLS is interesting. How= often do MPLS > > > > > packets leak and cause harm? For IOAM, > > > > > draft-ioametal-ippm-6man-ioam-ipv6-options-02 pro= poses a deployment > > > > > model similar to what we do for MPLS: Unless an i= nterface is > > > > > explicitly configured for IOAM, packets with IOAM= data fields MUST be dropped. > > > > > Hence leakage would only occur, if we have a clea= rly misbehaving > > > > > router which violates this rule. Similar to you, = I'd also greatly > > > > > appreciate any pointers to research on how common= MPLS leaked packets are. > > > > > > > > When it comes to "cause harm" I imagine there are (= at least) two ways to cause harm, one is privacy/secrecy/security loss and t= he other one is actual operational loss. > > > > > > > > I know of bugs where labeled packets went the wrong= way and caused them to be lost, I've also seen bugs where bugs caused traff= ic to "hop" between VRFs in MPLS VPN (or to "global" VRF). I don't have numb= ers on this though. > > > > > > > > Depending on the deployment scenario, it might make= sense to make IOAM packets not valid for non-IOAM aware devices (basically = encap entire packet/payload), but that might be a problem for intermediate n= on-IOAM nodes then. This would affect the ECMP requirement. I can see cases = where one would operationally turn on IOAM for some customers traffic and th= en see the problem go away because now ECMP changed. > > > > > > > > > ...FB: One idea that Shwetha came up with to iden= tify the source AS of > > > > > a leaked packet, would be to add a new new IOAM E= 2E option - as > > > > > proposed in section 5.1.1 bullet 2 of > > > > > draft-ioametal-ippm-6man-ioam-ipv6-deployment-01. > > > > > > > > Yes, that'd solve that problem. > > > > > > > > How much has the silicon people been involved so fa= r in the design of the headers? What is the current thinking of amount of da= ta going into the IOAM header? Considering things like trace options etc it = seems to me the header can grow quite large? To satisfy the ECMP requirement= what about putting the IOAM information as a trailer behind the regular pay= load? Or is there a problem for the hw to manipulate information that far in= to the packet (I also imagine this will considerably lower the forwarding pe= rformance of IOAM packets on IOAM aware platforms). > > > > > > > > .....FB2: There are quite a few folks with hardware= background that co-author the IOAM drafts. Parsing capability differs betwe= en chips, as does the ability to deal with new/flexible headers and the abil= ity to modify data in the extension headers. So the unfortunate answer to th= at question is "it depends" (what information do you gather, how large is yo= ur domain, what are the capabilities of your hardware/software forwarder, et= c.), but I do expect that for specific deployment domains (e.g. DC, Enterpri= se) - but also for overlay networks / VPNs - we'll see an increasing amount = of chips that are well suited for processing large extension header. > > > > > > > > Cheers, Frank > > > > > > > > -- > > > > Mikael Abrahamsson email: swmike@swm.pp.se > > > > > > > > _______________________________________________ > > > > ippm mailing list > > > > ippm@ietf.org > > > > https://eur03.safelinks.protection.outlook.com/?url= =3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cg= barak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6= a4d149256f461b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef= 3BJFz6AQNNAtkgmAMDFKM%3D&reserved=3D0 > > > > _______________________________________________ > > > > ippm mailing list > > > > ippm@ietf.org > > > > https://eur03.safelinks.protection.outlook.com/?url= =3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cg= barak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6= a4d149256f461b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef= 3BJFz6AQNNAtkgmAMDFKM%3D&reserved=3D0 > > > > ---------------------------------------------------= ----------------- > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf.org > > > > Administrative Requests: https://www.ietf.org/mailm= an/listinfo/ipv6 > > > > ---------------------------------------------------= ----------------- > > > > > > _______________________________________________ > > > ippm mailing list > > > ippm@ietf.org > > > https://www.ietf.org/mailman/listinfo/ippm > > > > > > > > > > > > > > > > > > --B_3637327217_1761545825 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Tom,

 <= /o:p>

You are right. There are two main cases where ac= cessibility of transport header becomes an issue. And that is mainly because= of current generation of fixed pipeline cell based architecture parse depth= (not so much an issue for high end NPU where next packet header bytes can b= e DMA=E2=80=99ed in, though it impacts the performance. For eg. Cisco QFP NPU, EZ = Chip, Juniper=E2=80=99s MX 3D NPU, or Broadcom=E2=80=99s Jerricho NPU ). This was mentio= ned earlier by Mikael as well.

 <= /o:p>

Case 1. SRv6

Ca= se 2. IPv6 with EH (mainly for 5G deployments where RH, DH, and IFA Header) =

 

Ty= pically NPUs provide capability that it will handle 3 or 4 EH or SRH without= performance penalty. With the presence of IFA header this means that for eg= there can be only 2 or 3 SRH or EH. This is same as in MPLS label stack dep= th handling (PUSH or POP at PE router). Given the evolution SRV6 and MPLS-SR= kind of headers, silicon vendors have taken a notice of it and are evolving= the silicon arch to handle more chained headers.

 

IFA supports fragmentation of= metadata stack and also postcard mode so beyond the transport header it=E2=80=99s= not an issue.

 

Just a quick feedback on using IPv6 options, inserting hop by ho= p options for data path processing pushes the EH further down and impacts th= e node=E2=80=99s forwarding function (say if it is not able to reach Destination E= H) vs if IFA header is the last EH then atmost transit node do not perform m= etadata collection which can be identified.

 

-Jai

 

From: Tom Herbert <tom@herbertland.com>
Date: Friday, April 5, = 2019 at 3:34 PM
To: Jai Kumar <jai.kumar@broadcom.com>
Cc: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com&g= t;, 6man <ipv6@ietf.org>, ippm <ippm@ietf.org>, "C. M. Hear= d" <heard@pobox.com>, Mikael Abrahamsson <swmike@swm.pp.se>=
Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment= -00 feedback (Re: v6 option types for IOAM data fields)

 

Jai,

 =

You might want to consider how IFA w= orks in the presence of segment routing. The second someone puts an SRH in t= he packet the IFA headers get pushed down and the transport headers end up b= eing deep in the packet anyway so that all the effort of IFA is nullified. I= f the requirement is to ensure that the transport layer information appear a= s early as possible in the packet, one could define a Hop-by-Hop option to c= arry some sort of pseudo header for the transport layer. This also would wor= k in the case that the actual transport layer is obfuscated.

<= /div>

 

Tom

 

On Fri, Apr 5, 2019, = 3:09 PM Jai Kumar <jai.kumar@broadcom.com> wrote:

=E2=80=9CThat is going to require justifying the p= rotocol even in light of shortcomings in existing protocoIs.=E2=80=9D<= /o:p>

&n= bsp;

Agreed !!! True for any proposal.

 

= -Jai

 

From: Tom Herbert <tom@herbertland.com>
Date: Friday, April 5, 2019 at 2:3= 4 PM
To: Jai Kumar <jai.kumar@broadcom.com>
Cc: "Pengshuping = (Peng Shuping)" <pengshuping@huawei.com>, 6man <ipv6@ietf.org>, ippm <ippm@ietf.org>, "C. M. Heard" <heard@pobox.com>, Mikael = Abrahamsson <swmike@swm= .pp.se>
Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-i= pv6-deployment-00 feedback (Re: v6 option types for IOAM data fields)=

 

 

On Fri, Apr 5, 2019, 2:07 PM Jai Kumar <jai.kumar@broadcom.com> wrot= e:

Tom,

Its all explained in the requ= irements section of the draft. IFA header is essentially treated as an EH bo= th in IPv4 and IPv6 (very similar to AH/ESP EH).

Just like in AH/ESP = the IP protocol is copied in the AH header and IP protocol field is replaced= in the IP header with the AH proto.

There are several advantages to = this approach.
- devise know how to parse AH header and can follow very s= imilar approach
- Protocol agnostics, silicon need not support N encaps (= just like AH/ESP). Single implementation works for all protocol types.
- = No need to creation options and teach devices that options is NOT an excepti= on path processing
- Really worry about ordering in IPv6 options
- Not= e that all the OAM data need to be deleted as well so position need to be op= timal for removal. We can always do tail stamping of the data but this puts = considerable constrains on the cell based architecture
- L4 accessibility= I have already mentioned

I am happy to discuss with you in person an= d explain more but bottom line is that this proposal is what came out with M= SDC discussions in light of shortcomings from other IETF proposals.

 

As t= hey say, you are free to run whatever you want in your proprietary network, = but if you expect to create an interoperable, deployable protocoI and get a = protocol number assignment, you'll need to work in ietf. That is going to re= quire justifying the protocol even in light of shortcomings in existing prot= ocoIs.

 

Tom=

 


Regard= s,
-Jai


=EF=BB=BFOn 4/5/19, 12:28 PM, "Tom Herbert" <tom@herbertland.com&g= t; wrote:

    On Fri, Apr 5, 2019 at 12:03 PM Jai Kumar <= ;jai.kumar@broadcom.= com> wrote:
    >
    > " Great,= but this IETF"
    > Does it mean that drafts have no = relevance to deployment and actual adoption.
    >
 =   > For all your queries please take a look at IFA draft.
 =   > https://datatracker.ietf.org/doc/draft-kumar-ippm-ifa/=
    >
    I've looked at that draft. It's is c= reating a complete new IP
    protocolas well as a new packet f= ormat for TCP and UDP that somehow
    inserts meta data betwee= n the TCP header and payload. I don't
    understand why this c= ould possibly be better than just using flow
    label for ECMP= and teaching devices that need to extract transport
    inform= ation how to walk over EH, or just using some UDP encpasulation
  &n= bsp; like in draft-herbert-ipv4-udpencap-eh-01.

    Tom
=
    > It handles IPv6, IPv4 TCP/UDP with altering the packe= t path (due to inserting options and/or encaping them in GRE header) as well= as IPSec AH/ESP/WESP both tunnel and transport and guess what it is success= fully deployed.
    >
    > -Jai
  &= nbsp; >
    > =EF=BB=BFOn 4/5/19, 11:54 AM, "Tom Herbert&q= uot; <tom@herbertlan= d.com> wrote:
    >
    >   = ;  On Fri, Apr 5, 2019 at 11:25 AM Jai Kumar <jai.kumar@broadcom.com> wrote:
&= nbsp;   >     >
    >   =  > Tom,
    >     >
  &nb= sp; >     > I am speaking based on the actual deploymen= t not based on if all the traffic is/will move to IPSec tunnel.
  &n= bsp; >     >
    >     &= gt; I have 6 large customer deployments and one someone previously called as= "Yahoo" who insist on visibility in L4 even for IOAM packets.
=     >     >
    >   = ;  And I've worked in datcenters much larger, and my first rule is that= I
    >     don't want random router vendors= dictating to me what protocols I'm
    >     = ;allowed to use in my datacenter.
    >
    >= ;     > I can quote you on that and lose my business :-)    >     >
    >  &nb= sp;  > ECMP argument is weak as well as it works for IPv6 flow label= . What about IPv4 TCP/UDP traffic which typically is 80% of the traffic in M= SDC.
    >     >
    >
=     >     draft-herbert-ipv4-udpencap-eh-01
&= nbsp;   >
    >     > If someone t= ells me that proposal will work only for my 20% of traffic then again as I s= aid before, they will lose my business :-)
    >   = ;  >
    >     Great, but this IETF. = Where are the protocol requirements? If you are
    >  =    saying that there are requirements for "visibility in L4&q= uot; what are
    >     they? If you are sayi= ng that ACLs are now required for packet
    >    =  forwarding, where is that described? Is it a MUST that teh only
&nb= sp;   >     transport protocols we're allowed to use = are  UDP or TCP? Are we
    >     allowe= d to use extension headers at all? I suppose fragmentation is
  &nbs= p; >     right out... Are we violating the requirements if= we encrypt the
    >     transport headers? = If you say that we shouldn't send long headers
    >  &= nbsp;  because we'll overflow parsing buffers, then what is the limit? = Please
    >     be SPECIFC in setting requir= ements; we are trying to build protocols
    >    =  that work and are interoperable and we need to get out of this morass<= br>    >     of reverse engineering to discover = the least common denominator.
    >
    >&nb= sp;    Tom
    >
    >   = ;  > Regards,
    >     > -Jai
=     >     >
    >   = ;  > =EF=BB=BFOn 4/5/19, 11:15 AM, "Tom Herbert" <tom@herbertland.com> wrote:=
    >     >
    >  &= nbsp;  >     On Fri, Apr 5, 2019 at 10:55 AM Jai Kuma= r <jai.kumar@broa= dcom.com> wrote:
    >     >  =    >
    >     >   =  > Even if we use flow label for ECMP, lack of accessibility of L4 = information (for various services, most simple is ACL) makes the proposal pr= etty much unusable.
    >     >  &nbs= p;  >
    >     >    &nb= sp;That is convoluting router and firewall functionality and
   = ; >     >     requirements. This a discu= ssion about packet forwarding which does
    >    =  >     _not_ require ACLs. In a limited domain, for w= hich IOAM is intended,
    >     >  &= nbsp;  it is unlikely that they'll ACLs would be used in internal nodes= , but
    >     >     we do= need good ECMP routing at all intermediate nodes need to be
   = ; >     >     consistent rather or not t= hat the IOAM option is present. As side
    >    &= nbsp;>     note, the ability to extract L4 information out= of packets is
    >     >    &n= bsp;dwindling anyway thanks to encryption and other techniques trying to
=     >     >     undo protocol = ossification. For instance, good luck getting L4
    > =    >     information out of an IPsec tunnel :-)= .
    >     >
    >  =    >     Tom
    >    =  >
    >     >     = > NIC cards are not used pervasively for ACLs and other services, I belie= ve iptables in kernel are good enough for host but that=E2=80=99s not acceptable i= n networking elements.
    >     >  &= nbsp;  >
    >     >    =  > -Jai
    >     >    &= nbsp;>
    >     >     &= gt; =EF=BB=BFOn 4/5/19, 10:31 AM, "ippm on behalf of Tom Herbert" <ippm-bounces@ietf.org on behalf of tom@her= bertland.com> wrote:
    >     >&nb= sp;    >
    >     >  &n= bsp;  >     On Fri, Apr 5, 2019 at 9:16 AM Pengshupin= g (Peng Shuping)
    >     >    =  >     <pengshuping@huawei.com> wrote:
    >&nb= sp;    >     >     >
&nb= sp;   >     >     >   =  > Hi Barak,
    >     >  &n= bsp;  >     >
    >    &= nbsp;>     >     > We are certainly n= ot designing for the lowest capable solutions but exploring optimal solution= s which could help to keep the forwarding performance while inserting the iO= AM data with variable length.
    >     >&= nbsp;    >
    >     >  =    >     Shuping,
    >  &n= bsp;  >     >
    >    &= nbsp;>     >     That's exactly the argu= ment for using the flow label in ECMP.
    >    &n= bsp;>     >     Efficeint packet forward= ing can be done solely by inspected the forty
    >  &n= bsp;  >     >     byte fixed length= header of the packet regardless of the contents of
    >&nb= sp;    >     >     the rest of= the packet. That is an optimal solution. Anything else for
   = >     >     >     ECM= P like doing DPI or hacking up IOAM to try do pull transport layers
 = ;   >     >     >    &= nbsp;into the parsing buffer (whatever size that may be) are nothing more    >     >     >  &n= bsp;  than hacks and unnecessarily perpetuate techniques used with IPv4= that
    >     >     >&= nbsp;    either don't work or are unnecessary in IPv6.
  &= nbsp; >     >     >
    = >     >     >     Tom<= br>    >     >     >
&nb= sp;   >     >     >
  &n= bsp; >     >     >     = ;>
    >     >     >&= nbsp;    > In terms of the forwarding efficiency, we would all = agree that a short and fixed header would be better than a variable header.<= br>    >     >     >  =    >
    >     >   =  >     > Best regards
    > =    >     >     > Shuping    >     >     >  &= nbsp;  >
    >     >    =  >     >
    >     = >     >     > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A = Barak Gafni<gbarak@m= ellanox.com>
    >     >  &nbs= p;  >     > = =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Pengshuping (Peng Shuping)<pengshuping@huawei.com>;Frank Brockners= (fbrockne)<fbrockne@= cisco.com>;Mikael Abrahamsson<swmike@swm.pp.se>
    >    &n= bsp;>     >     > =E6=8A=84=E9=80=81=EF=BC=9A C. M. Heard<heard@pobox.com>;6man WG<ipv6@ietf.org>;Mark Smith<markzzzsmith@gmail.com>= ;ippm<ippm@ietf.org>= ;
    >     >     > = ;    > =E4=B8=BB=E9=A2=98=EF=BC= =9A RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: = v6 option types for IOAM data fields)
    >    &nb= sp;>     >     > =E6=97=B6=E9=97=B4=EF=BC=9A = 2019-04-05 03:18:26
    >     >  &nbs= p;  >     >
    >    &nb= sp;>     >     > Hi Shuping,
 = ;   >     >     >    &= nbsp;> I think that the question is whether we design for the lowest capa= ble solutions. I assume someone can find solutions with even lower amount of= parsing.. The low end solutions for these capabilities may need to either a= dopt with new designs or use solutions such as what is suggested in this thr= ead by Tom Herbert.
    >     >  &nbs= p;  >     > Personally, I don't think we should go= this way, but to design appropriate solutions, with appropriate layers in t= he headers. For example, prevent dependencies between "remote" hea= ders.
    >     >     >&= nbsp;    >
    >     >  =    >     > Thanks,
    > = ;    >     >     > Barak    >     >     >  &n= bsp;  >
    >     >    &= nbsp;>     > -----Original Message-----
   = ; >     >     >     &g= t; From: ippm <ipp= m-bounces@ietf.org> On Behalf Of Pengshuping (Peng Shuping)
 =   >     >     >    &n= bsp;> Sent: Wednesday, April 3, 2019 6:47 AM
    >  =    >     >     > To: Frank = Brockners (fbrockne) <fbrockne@cisco.com>; Mikael Abrahamsson <swmike@swm.pp.se>
    >&nbs= p;    >     >     > Cc: C. = M. Heard <heard@pobox.co= m>; 6man WG <ipv6@i= etf.org>; Mark Smith <markzzzsmith@gmail.com>; ippm@ietf.org
    >     &g= t;     >     > Subject: [ippm] =E7=AD=94=E5=A4=8D: draft-ioametal-ippm-6man-ioam-ip= v6-deployment-00 feedback (Re: v6 option types for IOAM data fields)
&nbs= p;   >     >     >    =  >
    >     >     = >     > Hi,
    >     &g= t;     >     >
    >&nbs= p;    >     >     > The par= sing depth of the early chips is 96B/128B. For the new chips the parsing dep= th has been increased but still limited. So Mikael's concern makes sense esp= ecially in the tracing mode that the IOAM data fields are going to increase = significantly along the path, which will even push the Routing Header out of= the parsing depth of the chip. So it would make sense to split the IOAM dat= a part from the IOAM header/instruction part, and place the IOAM data after = the RH or even after the L4 header in order to be able to read the L4 inform= ation to enable ECMP, as stated in the draft https://eur03.safelinks.protection.out= look.com/?url=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-li-6man-ipv6-sfc-i= fit-00&amp;data=3D02%7C01%7Cgbarak%40mellanox.com%7C612ba6dc117440e68c4608= d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636898960379485833&a= mp;amp;sdata=3DDob4zN%2F1jSGxLTlqGma29JJNvqJDBt4VzqHsN4OpxM4%3D&amp;reserv= ed=3D0.
    >     >     &= gt;     >
    >     >&nb= sp;    >     > BR,
    > = ;    >     >     > Shuping<= br>    >     >     >  =    >
    >     >   =  >     >
    >     = ;>     >     > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6-----
    >     >     = >     > =E5=8F=91=E4=BB=B6=E4=BA=BA: ippm [mailto:ippm-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Frank Brockners (fbrockne)
&= nbsp;   >     >     >  &nbs= p;  > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B44=E6=9C=882=E6=97=A5 17:40
    >     >     >= ;     > =E6=94=B6=E4=BB=B6=E4=BA=BA: Mikael Abrahamsson <swmike@swm.pp.se>
    >     >&nb= sp;    >     > =E6=8A=84=E9=80=81: C. M. Heard <heard@pobox.com>; 6man WG <ipv6@ietf.org>; Mark Smith <markzzzsmith@gmail.com>; ippm@ietf.org
    = >     >     >     >= =E4=B8=BB=E9=A2=98: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-= 00 feedback (Re: v6 option types for IOAM data fields)
    >=      >     >     >
=     >     >     >  &nb= sp;  >
    >     >    &n= bsp;>     >
    >     &g= t;     >     > -----Original Message----= -
    >     >     > = ;    > From: Mikael Abrahamsson <swmike@swm.pp.se>
    >  =    >     >     > Sent: Dien= stag, 2. April 2019 08:06
    >     > = ;    >     > To: Frank Brockners (fbrockne) &= lt;fbrockne@cisco.com>
    >     >     >&= nbsp;    > Cc: Mark Smith <markzzzsmith@gmail.com>; C. M. Heard <heard@pobox.com>; 6man WG= <ipv6@ietf.org>; <= a href=3D"mailto:ippm@ietf.org" target=3D"_blank">ippm@ietf.org
  &n= bsp; >     >     >     = ;> Subject: RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback= (Re: v6 option types for IOAM data fields)
    >  &nbs= p;  >     >     >
  &nbs= p; >     >     >     &= gt; On Mon, 1 Apr 2019, Frank Brockners (fbrockne) wrote:
    &= gt;     >     >     ><= br>    >     >     >  =    > > ...FB: There is obviously no easy answer. Couple of t= houghts:
    >     >     &g= t;     > > * IOAM is considered a "domain specific= " feature (see
    >     >  &nbs= p;  >     > > draft-ietf-ippm-ioam-data-05, sec= tion 3). Routers in the IOAM domain
    >     = ;>     >     > > should be IOAM ca= pable.  And IMHO,  we should add a statement to
    &= gt;     >     >     > = > draft-ioametal-ippm-6man-ioam-ipv6-deployment that an implementation    >     >     >  &n= bsp;  > > of IOAM MUST ensure "C1".
    &g= t;     >     >     > &= gt;
    >     >     >&nb= sp;    > > * That said, there can be situations, where C1 ca= nnot be achieved, e.g..
    >     >  =    >     > > consider a network which does= ECMP scheduling based on packet length.
    >    =  >     >     > >
  &n= bsp; >     >     >     = ;> > * What one could consider - and which is one suggested deployment=
    >     >     > =    > > model
    >     >&= nbsp;    >     > > - is that by default IO= AM data fields are added to _all_ customer
    >   = ;  >     >     > > packets. T= he decapsulating node would decide whether the IOAM
    >&nb= sp;    >     >     > > i= nformation contained in a packet would be used (and exported) or not.
&nb= sp;   >     >     >   =  > > That way one would not need to deal with the situation that= some
    >     >     >&= nbsp;    > > traffic carries IOAM while other does not - and= might thus be treated
    >     >  &= nbsp;  >     > > differently.
    = >     >     >     >=
    >     >     > =    > Yes, I think this is the only way. Is there a risk that i= ntermediate routers would not be IOAM capable? I think the C1 requirement is= really really hard to fulfil and I'm also afraid that adding the IOAM heade= r will actually make ECMP stop working on some platforms (because they would= not have the capability to look deep enough into the packet to find L4 info= rmation, so it'll go back to 2 tuple ECMP instead of 5 tuple.
  &nbs= p; >     >     >     &= gt;
    >     >     >&nb= sp;    > But this question can only be answered by people with = deep NPU knowledge...
    >     >  &n= bsp;  >     >
    >    &= nbsp;>     >     > .....FB2: Given th= at IOAM is a domain specific feature - I expect that folks initially start t= o use it in domains (like e.g. a DC) where all boxes are IOAM capable and ca= n trace the packet appropriately - or per Tom's note, can be configured so t= hat one would do ECMP based on addresses and flow-label.  There are chi= ps with pretty deep parsing capability (up to a few hundred bytes).
 = ;   >     >     >    &= nbsp;>
    >     >     &= gt;     > > ...FB: The comparison to MPLS is interestin= g. How often do MPLS
    >     >  &nb= sp;  >     > > packets leak and cause harm? For= IOAM,
    >     >     >=      > > draft-ioametal-ippm-6man-ioam-ipv6-options-02 = proposes a deployment
    >     >  &n= bsp;  >     > > model similar to what we do for= MPLS: Unless an interface is
    >     >&= nbsp;    >     > > explicitly configured f= or IOAM, packets with IOAM data fields MUST be dropped.
    >= ;     >     >     > &g= t; Hence leakage would only occur, if we have a clearly misbehaving
 = ;   >     >     >    &= nbsp;> > router which violates this rule. Similar to you, I'd also gre= atly
    >     >     >&n= bsp;    > > appreciate any pointers to research on how commo= n MPLS leaked packets are.
    >     >&nbs= p;    >     >
    >  &nb= sp;  >     >     > When it comes= to "cause harm" I imagine there are (at least) two ways to cause = harm, one is privacy/secrecy/security loss and the other one is actual opera= tional loss.
    >     >    &nbs= p;>     >
    >     >=      >     > I know of bugs where labele= d packets went the wrong way and caused them to be lost, I've also seen bugs= where bugs caused traffic to "hop" between VRFs in MPLS VPN (or t= o "global" VRF). I don't have numbers on this though.
  &n= bsp; >     >     >     = ;>
    >     >     >&= nbsp;    > Depending on the deployment scenario, it might make = sense to make IOAM packets not valid for non-IOAM aware devices (basically e= ncap entire packet/payload), but that might be a problem for intermediate no= n-IOAM nodes then. This would affect the ECMP requirement. I can see cases w= here one would operationally turn on IOAM for some customers traffic and the= n see the problem go away because now ECMP changed.
    >&nb= sp;    >     >     >
&nb= sp;   >     >     >   =  > > ...FB: One idea that Shwetha came up with to identify the s= ource AS of
    >     >     = ;>     > > a leaked packet, would be to add a new ne= w IOAM E2E option - as
    >     >  &= nbsp;  >     > > proposed in section 5.1.1 bull= et 2 of
    >     >     >= ;     > > draft-ioametal-ippm-6man-ioam-ipv6-deployment= -01.
    >     >     >&n= bsp;    >
    >     >  &= nbsp;  >     > Yes, that'd solve that problem.
=     >     >     >  &nb= sp;  >
    >     >    &n= bsp;>     > How much has the silicon people been involv= ed so far in the design of the headers? What is the current thinking of amou= nt of data going into the IOAM header? Considering things like trace options= etc it seems to me the header can grow quite large? To satisfy the ECMP req= uirement what about putting the IOAM information as a trailer behind the reg= ular payload? Or is there a problem for the hw to manipulate information tha= t far into the packet (I also imagine this will considerably lower the forwa= rding performance of IOAM packets on IOAM aware platforms).
   = >     >     >     >= ;
    >     >     > = ;    > .....FB2: There are quite a few folks with hardware back= ground that co-author the IOAM drafts. Parsing capability differs between ch= ips, as does the ability to deal with new/flexible headers and the ability t= o modify data in the extension headers. So the unfortunate answer to that qu= estion is "it depends" (what information do you gather, how large = is your domain, what are the capabilities of your hardware/software forwarde= r, etc.), but I do expect that for specific deployment domains (e.g. DC, Ent= erprise) - but also for overlay networks / VPNs - we'll see an increasing am= ount of chips that are well suited for processing large extension header.    >     >     >  &n= bsp;  >
    >     >    &= nbsp;>     > Cheers, Frank
    >  =    >     >     >
  =   >     >     >    &nb= sp;> --
    >     >     = >     > Mikael Abrahamsson    email: swmike@swm.pp.se
  &nb= sp; >     >     >     = >
    >     >     >&n= bsp;    > _______________________________________________
&n= bsp;   >     >     >   = ;  > ippm mailing list
    >     >=      >     > ippm@ietf.org
    >    &nb= sp;>     >     > https://eur03.safelinks.protection.outlook.= com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&amp;data= =3D02%7C01%7Cgbarak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca65297= 1c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636898960379485833&amp;sdata=3DVjZ1Pi= wifYGCf159je0yef3BJFz6AQNNAtkgmAMDFKM%3D&amp;reserved=3D0
  &n= bsp; >     >     >     = ;> _______________________________________________
    >&= nbsp;    >     >     > ippm= mailing list
    >     >    &nb= sp;>     > ippm@ietf.org
    >     >  &nb= sp;  >     > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A= %2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&amp;data=3D02%7C01%7Cgbarak= %40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d14= 9256f461b%7C0%7C0%7C636898960379485833&amp;sdata=3DVjZ1PiwifYGCf159je0yef3= BJFz6AQNNAtkgmAMDFKM%3D&amp;reserved=3D0
    >  &= nbsp;  >     >     > -----------= ---------------------------------------------------------
    &= gt;     >     >     > = IETF IPv6 working group mailing list
    >    &nbs= p;>     >     > ipv6@ietf.org
    >  &nbs= p;  >     >     > Administrative= Requests: https://www.ietf.org/mailman/listinfo/ipv6
    >&nbs= p;    >     >     > -------= -------------------------------------------------------------
  &nbs= p; >     >     >
    >= ;     >     >     _______= ________________________________________
    >    =  >     >     ippm mailing list
&= nbsp;   >     >     >  &nbs= p;  ippm@ietf.org    >     >     >  &n= bsp;  https://www.ietf.org/mailman/listinfo/ippm
    >&nbs= p;    >     >
    >  &nb= sp;  >     >
    >    &n= bsp;>     >
    >     &g= t;
    >     >
    > =    >
    >
    >
  &nb= sp; >

--B_3637327217_1761545825-- From nobody Fri Apr 5 17:05:46 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB6E12027C for ; Fri, 5 Apr 2019 17:05:44 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 cpV2Vb1QCyEt for ; Fri, 5 Apr 2019 17:05:40 -0700 (PDT) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40E06120280 for ; Fri, 5 Apr 2019 17:05:40 -0700 (PDT) Received: by mail-qt1-x830.google.com with SMTP id x12so9437318qts.7 for ; Fri, 05 Apr 2019 17:05:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=k/4DUA2gD/KUvVXsBh01d35JeizkT+0zJ5zVvkvybA4=; b=FQWvqfrFSbKL1ojGphgf1ourBfWS6Lt4JtKzY/SQZc/k8u3y+rnce+j0a1myiaINXr GIQbzkGVsDxb049ECd+6fMBpPREsiBgHisLuEH/FGDhVDAIs2ayDH90opMFjL3orfpJe LtekMiOqDEIqoluIZBNrcUlZQX728XJrF7z2R4J67Rrt5pAOCRAvQJrNXUZYBV2zlNqf 94Z1WEkHR4TVM8mM5vSbnKugKwsf+4rfFn6ujTFxrYnBENlfgeGUw8h9rqkq8/3oTgCf BiBqVY7qObtBJJ5oFphnATsb7zmO2fB/g+VAzS/7p0oMC4+2VJ8h0UC6GDHgKiS4WDNP HgbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=k/4DUA2gD/KUvVXsBh01d35JeizkT+0zJ5zVvkvybA4=; b=PrmrJSz8AWi5In1ZJob9Ltw7DzgGBGAvOvhTQsFrfSDACRDJ/XVk07sQtn4ek7Hg1h vhGzkmR5PhvSmAlz36PmqExeXqAWUCK0w7D/MAuhFO12yFmP2QmUYKEhpv8vz2xaesKt 9plvg5Pc0Occ9meP/HK98zOI2JYJT7JbwjYnWtXbzREhySnOxQXk0HizQ7CeHP6MfgCZ VVk7ey8OfLE94ONwdq4fG0QLLLZu2UnVjC/u9XnGhHE0uWJZPrV6I1H4L5y1B9mgC8jE 3IJ6JKHi0kdgeye0XywUoextqmeQSp8l3wAwoUdZoD7gM1wqJ39kMr9QT2Bk7Vw/MT6+ xFsw== X-Gm-Message-State: APjAAAU+6S5bzwQi3xYDklZ+eQhYZ+Qhtgu6B5N0AR7xZkmuzk+aHglO gC6dAnrE0/cxxp6KSjnwwwlr83xvHAB6vvbFiLwCVg== X-Google-Smtp-Source: APXvYqxEUWKIObWnd67eR//It0l/7OEIAWVJ5apIXsrtDKuiSOHdArFXpkI30eQYFp7wgcfCD1Z1ovUqZu+Xgx1ebTA= X-Received: by 2002:ac8:47d9:: with SMTP id d25mr12914679qtr.202.1554509139141; Fri, 05 Apr 2019 17:05:39 -0700 (PDT) MIME-Version: 1.0 References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> <4278D47A901B3041A737953BAA078ADE1478D5E2@DGGEML532-MBX.china.huawei.com> <4278D47A901B3041A737953BAA078ADE1478EC8B@DGGEML532-MBX.china.huawei.com> <14A3D5C9-1EED-4E11-9329-B62B819271A2@broadcom.com> <20D6FCDB-3357-4728-BD52-8069C32F3CCA@broadcom.com> <57A32C37-AAE9-44F2-9C96-39AFA71BDC21@broadcom.com> <36B9204A-D1EE-4067-92BB-6C33CB2DF791@broadcom.com> In-Reply-To: <36B9204A-D1EE-4067-92BB-6C33CB2DF791@broadcom.com> From: Tom Herbert Date: Fri, 5 Apr 2019 17:05:26 -0700 Message-ID: To: Jai Kumar Cc: "Pengshuping (Peng Shuping)" , 6man , ippm , "C. M. Heard" , Mikael Abrahamsson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 00:05:44 -0000 On Fri, Apr 5, 2019 at 4:40 PM Jai Kumar wrote: > > Tom, > > > > You are right. There are two main cases where accessibility of transport = header becomes an issue. And that is mainly because of current generation o= f fixed pipeline cell based architecture parse depth (not so much an issue = for high end NPU where next packet header bytes can be DMA=E2=80=99ed in, t= hough it impacts the performance. For eg. Cisco QFP NPU, EZ Chip, Juniper= =E2=80=99s MX 3D NPU, or Broadcom=E2=80=99s Jerricho NPU ). This was mentio= ned earlier by Mikael as well. > > > > Case 1. SRv6 > > Case 2. IPv6 with EH (mainly for 5G deployments where RH, DH, and IFA Hea= der) > > > > Typically NPUs provide capability that it will handle 3 or 4 EH or SRH wi= thout performance penalty. With the presence of IFA header this means that = for eg there can be only 2 or 3 SRH or EH. This is same as in MPLS label st= ack depth handling (PUSH or POP at PE router). Given the evolution SRV6 and= MPLS-SR kind of headers, silicon vendors have taken a notice of it and are= evolving the silicon arch to handle more chained headers. > > > > IFA supports fragmentation of metadata stack and also postcard mode so be= yond the transport header it=E2=80=99s not an issue. > > > > Just a quick feedback on using IPv6 options, inserting hop by hop options= for data path processing pushes the EH further down and impacts the node= =E2=80=99s forwarding function (say if it is not able to reach Destination = EH) vs if IFA header is the last EH then atmost transit node do not perform= metadata collection which can be identified. Maybe it does impact it, maybe it doesn't. It clearly depends on the device capabilities. For a device with a parsing buffer of 256 bytes that should be plenty of room for HBH options, SR header, transport layer, etc. > > > > -Jai > > > > From: Tom Herbert > Date: Friday, April 5, 2019 at 3:34 PM > To: Jai Kumar > Cc: "Pengshuping (Peng Shuping)" , 6man , ippm , "C. M. Heard" , Mikael Abrah= amsson > Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feed= back (Re: v6 option types for IOAM data fields) > > > > Jai, > > > > You might want to consider how IFA works in the presence of segment routi= ng. The second someone puts an SRH in the packet the IFA headers get pushed= down and the transport headers end up being deep in the packet anyway so t= hat all the effort of IFA is nullified. If the requirement is to ensure tha= t the transport layer information appear as early as possible in the packet= , one could define a Hop-by-Hop option to carry some sort of pseudo header = for the transport layer. This also would work in the case that the actual t= ransport layer is obfuscated. > > > > Tom > > > > On Fri, Apr 5, 2019, 3:09 PM Jai Kumar wrote: > > =E2=80=9CThat is going to require justifying the protocol even in light o= f shortcomings in existing protocoIs.=E2=80=9D > > > > Agreed !!! True for any proposal. > > > > -Jai > > > > From: Tom Herbert > Date: Friday, April 5, 2019 at 2:34 PM > To: Jai Kumar > Cc: "Pengshuping (Peng Shuping)" , 6man , ippm , "C. M. Heard" , Mikael Abrah= amsson > Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feed= back (Re: v6 option types for IOAM data fields) > > > > > > On Fri, Apr 5, 2019, 2:07 PM Jai Kumar wrote: > > Tom, > > Its all explained in the requirements section of the draft. IFA header is= essentially treated as an EH both in IPv4 and IPv6 (very similar to AH/ESP= EH). > > Just like in AH/ESP the IP protocol is copied in the AH header and IP pro= tocol field is replaced in the IP header with the AH proto. > > There are several advantages to this approach. > - devise know how to parse AH header and can follow very similar approach > - Protocol agnostics, silicon need not support N encaps (just like AH/ESP= ). Single implementation works for all protocol types. > - No need to creation options and teach devices that options is NOT an ex= ception path processing > - Really worry about ordering in IPv6 options > - Note that all the OAM data need to be deleted as well so position need = to be optimal for removal. We can always do tail stamping of the data but t= his puts considerable constrains on the cell based architecture > - L4 accessibility I have already mentioned > > I am happy to discuss with you in person and explain more but bottom line= is that this proposal is what came out with MSDC discussions in light of s= hortcomings from other IETF proposals. > > > > As they say, you are free to run whatever you want in your proprietary ne= twork, but if you expect to create an interoperable, deployable protocoI an= d get a protocol number assignment, you'll need to work in ietf. That is go= ing to require justifying the protocol even in light of shortcomings in exi= sting protocoIs. > > > > Tom > > > > > Regards, > -Jai > > > =EF=BB=BFOn 4/5/19, 12:28 PM, "Tom Herbert" wrote: > > On Fri, Apr 5, 2019 at 12:03 PM Jai Kumar wr= ote: > > > > " Great, but this IETF" > > Does it mean that drafts have no relevance to deployment and actual= adoption. > > > > For all your queries please take a look at IFA draft. > > https://datatracker.ietf.org/doc/draft-kumar-ippm-ifa/ > > > I've looked at that draft. It's is creating a complete new IP > protocolas well as a new packet format for TCP and UDP that somehow > inserts meta data between the TCP header and payload. I don't > understand why this could possibly be better than just using flow > label for ECMP and teaching devices that need to extract transport > information how to walk over EH, or just using some UDP encpasulation > like in draft-herbert-ipv4-udpencap-eh-01. > > Tom > > > It handles IPv6, IPv4 TCP/UDP with altering the packet path (due to= inserting options and/or encaping them in GRE header) as well as IPSec AH/= ESP/WESP both tunnel and transport and guess what it is successfully deploy= ed. > > > > -Jai > > > > =EF=BB=BFOn 4/5/19, 11:54 AM, "Tom Herbert" w= rote: > > > > On Fri, Apr 5, 2019 at 11:25 AM Jai Kumar wrote: > > > > > > Tom, > > > > > > I am speaking based on the actual deployment not based on if = all the traffic is/will move to IPSec tunnel. > > > > > > I have 6 large customer deployments and one someone previousl= y called as "Yahoo" who insist on visibility in L4 even for IOAM packets. > > > > > And I've worked in datcenters much larger, and my first rule is= that I > > don't want random router vendors dictating to me what protocols= I'm > > allowed to use in my datacenter. > > > > > I can quote you on that and lose my business :-) > > > > > > ECMP argument is weak as well as it works for IPv6 flow label= . What about IPv4 TCP/UDP traffic which typically is 80% of the traffic in = MSDC. > > > > > > > draft-herbert-ipv4-udpencap-eh-01 > > > > > If someone tells me that proposal will work only for my 20% o= f traffic then again as I said before, they will lose my business :-) > > > > > Great, but this IETF. Where are the protocol requirements? If y= ou are > > saying that there are requirements for "visibility in L4" what = are > > they? If you are saying that ACLs are now required for packet > > forwarding, where is that described? Is it a MUST that teh only > > transport protocols we're allowed to use are UDP or TCP? Are w= e > > allowed to use extension headers at all? I suppose fragmentatio= n is > > right out... Are we violating the requirements if we encrypt th= e > > transport headers? If you say that we shouldn't send long heade= rs > > because we'll overflow parsing buffers, then what is the limit?= Please > > be SPECIFC in setting requirements; we are trying to build prot= ocols > > that work and are interoperable and we need to get out of this = morass > > of reverse engineering to discover the least common denominator= . > > > > Tom > > > > > Regards, > > > -Jai > > > > > > =EF=BB=BFOn 4/5/19, 11:15 AM, "Tom Herbert" wrote: > > > > > > On Fri, Apr 5, 2019 at 10:55 AM Jai Kumar wrote: > > > > > > > > Even if we use flow label for ECMP, lack of accessibili= ty of L4 information (for various services, most simple is ACL) makes the p= roposal pretty much unusable. > > > > > > > That is convoluting router and firewall functionality and > > > requirements. This a discussion about packet forwarding w= hich does > > > _not_ require ACLs. In a limited domain, for which IOAM i= s intended, > > > it is unlikely that they'll ACLs would be used in interna= l nodes, but > > > we do need good ECMP routing at all intermediate nodes ne= ed to be > > > consistent rather or not that the IOAM option is present.= As side > > > note, the ability to extract L4 information out of packet= s is > > > dwindling anyway thanks to encryption and other technique= s trying to > > > undo protocol ossification. For instance, good luck getti= ng L4 > > > information out of an IPsec tunnel :-). > > > > > > Tom > > > > > > > NIC cards are not used pervasively for ACLs and other s= ervices, I believe iptables in kernel are good enough for host but that=E2= =80=99s not acceptable in networking elements. > > > > > > > > -Jai > > > > > > > > =EF=BB=BFOn 4/5/19, 10:31 AM, "ippm on behalf of Tom He= rbert" wrote: > > > > > > > > On Fri, Apr 5, 2019 at 9:16 AM Pengshuping (Peng Sh= uping) > > > > wrote: > > > > > > > > > > Hi Barak, > > > > > > > > > > We are certainly not designing for the lowest cap= able solutions but exploring optimal solutions which could help to keep the= forwarding performance while inserting the iOAM data with variable length. > > > > > > > > Shuping, > > > > > > > > That's exactly the argument for using the flow labe= l in ECMP. > > > > Efficeint packet forwarding can be done solely by i= nspected the forty > > > > byte fixed length header of the packet regardless o= f the contents of > > > > the rest of the packet. That is an optimal solution= . Anything else for > > > > ECMP like doing DPI or hacking up IOAM to try do pu= ll transport layers > > > > into the parsing buffer (whatever size that may be)= are nothing more > > > > than hacks and unnecessarily perpetuate techniques = used with IPv4 that > > > > either don't work or are unnecessary in IPv6. > > > > > > > > Tom > > > > > > > > > > > > > > > > > > In terms of the forwarding efficiency, we would a= ll agree that a short and fixed header would be better than a variable head= er. > > > > > > > > > > Best regards > > > > > Shuping > > > > > > > > > > > > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Barak Gafni<= gbarak@mellanox.com> > > > > > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Pengshuping = (Peng Shuping);Frank Brockners (fbrockne);Mikael Abrahamsson > > > > > =E6=8A=84=E9=80=81=EF=BC=9A C. M. Heard;6man WG;Mark Smith;ippm > > > > > =E4=B8=BB=E9=A2=98=EF=BC=9A RE: draft-ioametal-ip= pm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data= fields) > > > > > =E6=97=B6=E9=97=B4=EF=BC=9A 2019-04-05 03:18:26 > > > > > > > > > > Hi Shuping, > > > > > I think that the question is whether we design fo= r the lowest capable solutions. I assume someone can find solutions with ev= en lower amount of parsing.. The low end solutions for these capabilities m= ay need to either adopt with new designs or use solutions such as what is s= uggested in this thread by Tom Herbert. > > > > > Personally, I don't think we should go this way, = but to design appropriate solutions, with appropriate layers in the headers= . For example, prevent dependencies between "remote" headers. > > > > > > > > > > Thanks, > > > > > Barak > > > > > > > > > > -----Original Message----- > > > > > From: ippm On Behalf Of P= engshuping (Peng Shuping) > > > > > Sent: Wednesday, April 3, 2019 6:47 AM > > > > > To: Frank Brockners (fbrockne) ; Mikael Abrahamsson > > > > > Cc: C. M. Heard ; 6man WG ; Mark Smith ; ippm@ietf.org > > > > > Subject: [ippm] =E7=AD=94=E5=A4=8D: draft-ioameta= l-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM = data fields) > > > > > > > > > > Hi, > > > > > > > > > > The parsing depth of the early chips is 96B/128B.= For the new chips the parsing depth has been increased but still limited. = So Mikael's concern makes sense especially in the tracing mode that the IOA= M data fields are going to increase significantly along the path, which wil= l even push the Routing Header out of the parsing depth of the chip. So it = would make sense to split the IOAM data part from the IOAM header/instructi= on part, and place the IOAM data after the RH or even after the L4 header i= n order to be able to read the L4 information to enable ECMP, as stated in = the draft https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F= %2Ftools.ietf.org%2Fhtml%2Fdraft-li-6man-ipv6-sfc-ifit-00&data=3D02%7C0= 1%7Cgbarak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e= 4d9ba6a4d149256f461b%7C0%7C0%7C636898960379485833&sdata=3DDob4zN%2F1jSG= xLTlqGma29JJNvqJDBt4VzqHsN4OpxM4%3D&reserved=3D0. > > > > > > > > > > BR, > > > > > Shuping > > > > > > > > > > > > > > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: ippm [mailto:ippm-bo= unces@ietf.org] =E4=BB=A3=E8=A1=A8 Frank Brockners (fbrockne) > > > > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9= =B44=E6=9C=882=E6=97=A5 17:40 > > > > > =E6=94=B6=E4=BB=B6=E4=BA=BA: Mikael Abrahamsson <= swmike@swm.pp.se> > > > > > =E6=8A=84=E9=80=81: C. M. Heard = ; 6man WG ; Mark Smith ; ippm@ietf.o= rg > > > > > =E4=B8=BB=E9=A2=98: Re: [ippm] draft-ioametal-ipp= m-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data = fields) > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Mikael Abrahamsson > > > > > Sent: Dienstag, 2. April 2019 08:06 > > > > > To: Frank Brockners (fbrockne) > > > > > Cc: Mark Smith ; C. M. He= ard ; 6man WG ; ippm@ietf.org > > > > > Subject: RE: draft-ioametal-ippm-6man-ioam-ipv6-d= eployment-00 feedback (Re: v6 option types for IOAM data fields) > > > > > > > > > > On Mon, 1 Apr 2019, Frank Brockners (fbrockne) wr= ote: > > > > > > > > > > > ...FB: There is obviously no easy answer. Coupl= e of thoughts: > > > > > > * IOAM is considered a "domain specific" featur= e (see > > > > > > draft-ietf-ippm-ioam-data-05, section 3). Route= rs in the IOAM domain > > > > > > should be IOAM capable. And IMHO, we should a= dd a statement to > > > > > > draft-ioametal-ippm-6man-ioam-ipv6-deployment t= hat an implementation > > > > > > of IOAM MUST ensure "C1". > > > > > > > > > > > > * That said, there can be situations, where C1 = cannot be achieved, e.g.. > > > > > > consider a network which does ECMP scheduling b= ased on packet length. > > > > > > > > > > > > * What one could consider - and which is one su= ggested deployment > > > > > > model > > > > > > - is that by default IOAM data fields are added= to _all_ customer > > > > > > packets. The decapsulating node would decide wh= ether the IOAM > > > > > > information contained in a packet would be used= (and exported) or not. > > > > > > That way one would not need to deal with the si= tuation that some > > > > > > traffic carries IOAM while other does not - and= might thus be treated > > > > > > differently. > > > > > > > > > > Yes, I think this is the only way. Is there a ris= k that intermediate routers would not be IOAM capable? I think the C1 requi= rement is really really hard to fulfil and I'm also afraid that adding the = IOAM header will actually make ECMP stop working on some platforms (because= they would not have the capability to look deep enough into the packet to = find L4 information, so it'll go back to 2 tuple ECMP instead of 5 tuple. > > > > > > > > > > But this question can only be answered by people = with deep NPU knowledge... > > > > > > > > > > .....FB2: Given that IOAM is a domain specific fe= ature - I expect that folks initially start to use it in domains (like e.g.= a DC) where all boxes are IOAM capable and can trace the packet appropriat= ely - or per Tom's note, can be configured so that one would do ECMP based = on addresses and flow-label. There are chips with pretty deep parsing capa= bility (up to a few hundred bytes). > > > > > > > > > > > ...FB: The comparison to MPLS is interesting. H= ow often do MPLS > > > > > > packets leak and cause harm? For IOAM, > > > > > > draft-ioametal-ippm-6man-ioam-ipv6-options-02 p= roposes a deployment > > > > > > model similar to what we do for MPLS: Unless an= interface is > > > > > > explicitly configured for IOAM, packets with IO= AM data fields MUST be dropped. > > > > > > Hence leakage would only occur, if we have a cl= early misbehaving > > > > > > router which violates this rule. Similar to you= , I'd also greatly > > > > > > appreciate any pointers to research on how comm= on MPLS leaked packets are. > > > > > > > > > > When it comes to "cause harm" I imagine there are= (at least) two ways to cause harm, one is privacy/secrecy/security loss an= d the other one is actual operational loss. > > > > > > > > > > I know of bugs where labeled packets went the wro= ng way and caused them to be lost, I've also seen bugs where bugs caused tr= affic to "hop" between VRFs in MPLS VPN (or to "global" VRF). I don't have = numbers on this though. > > > > > > > > > > Depending on the deployment scenario, it might ma= ke sense to make IOAM packets not valid for non-IOAM aware devices (basical= ly encap entire packet/payload), but that might be a problem for intermedia= te non-IOAM nodes then. This would affect the ECMP requirement. I can see c= ases where one would operationally turn on IOAM for some customers traffic = and then see the problem go away because now ECMP changed. > > > > > > > > > > > ...FB: One idea that Shwetha came up with to id= entify the source AS of > > > > > > a leaked packet, would be to add a new new IOAM= E2E option - as > > > > > > proposed in section 5.1.1 bullet 2 of > > > > > > draft-ioametal-ippm-6man-ioam-ipv6-deployment-0= 1. > > > > > > > > > > Yes, that'd solve that problem. > > > > > > > > > > How much has the silicon people been involved so = far in the design of the headers? What is the current thinking of amount of= data going into the IOAM header? Considering things like trace options etc= it seems to me the header can grow quite large? To satisfy the ECMP requir= ement what about putting the IOAM information as a trailer behind the regul= ar payload? Or is there a problem for the hw to manipulate information that= far into the packet (I also imagine this will considerably lower the forwa= rding performance of IOAM packets on IOAM aware platforms). > > > > > > > > > > .....FB2: There are quite a few folks with hardwa= re background that co-author the IOAM drafts. Parsing capability differs be= tween chips, as does the ability to deal with new/flexible headers and the = ability to modify data in the extension headers. So the unfortunate answer = to that question is "it depends" (what information do you gather, how large= is your domain, what are the capabilities of your hardware/software forwar= der, etc.), but I do expect that for specific deployment domains (e.g. DC, = Enterprise) - but also for overlay networks / VPNs - we'll see an increasin= g amount of chips that are well suited for processing large extension heade= r. > > > > > > > > > > Cheers, Frank > > > > > > > > > > -- > > > > > Mikael Abrahamsson email: swmike@swm.pp.se > > > > > > > > > > _______________________________________________ > > > > > ippm mailing list > > > > > ippm@ietf.org > > > > > https://eur03.safelinks.protection.outlook.com/?u= rl=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7= C01%7Cgbarak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d= 2e4d9ba6a4d149256f461b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYG= Cf159je0yef3BJFz6AQNNAtkgmAMDFKM%3D&reserved=3D0 > > > > > _______________________________________________ > > > > > ippm mailing list > > > > > ippm@ietf.org > > > > > https://eur03.safelinks.protection.outlook.com/?u= rl=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7= C01%7Cgbarak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d= 2e4d9ba6a4d149256f461b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYG= Cf159je0yef3BJFz6AQNNAtkgmAMDFKM%3D&reserved=3D0 > > > > > -------------------------------------------------= ------------------- > > > > > IETF IPv6 working group mailing list > > > > > ipv6@ietf.org > > > > > Administrative Requests: https://www.ietf.org/mai= lman/listinfo/ipv6 > > > > > -------------------------------------------------= ------------------- > > > > > > > > _______________________________________________ > > > > ippm mailing list > > > > ippm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ippm > > > > > > > > > > > > > > > > > > > > > > > > > > > > From nobody Sat Apr 6 09:41:33 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6A212033D for ; Sat, 6 Apr 2019 09:41:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.com 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 5eve2E-4-V9F for ; Sat, 6 Apr 2019 09:41:27 -0700 (PDT) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D96941200F9 for ; Sat, 6 Apr 2019 09:41:26 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id z9so1829201pgu.10 for ; Sat, 06 Apr 2019 09:41:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=user-agent:date:subject:from:to:cc:message-id:thread-topic :references:in-reply-to:mime-version:content-transfer-encoding; bh=d4eP26ZkNo5iHes0MEcyA2smG6jbNgixhESHbttZokE=; b=IDsh4yuI0NWplodKjjwTd+G/08ar9sO6pC+q2iVHHyumcEGWhWW1updGfVScQojauT EPE85QvU/9+WRvAN8946+A6HgMwtIOo6U6r68WJZs2laKqQ/9Xp4USmf1gKYnte+hRa8 zlSLa9wZvRbdcHuZMiGTAd7WhRXT/5ExHxjk4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:cc:message-id :thread-topic:references:in-reply-to:mime-version :content-transfer-encoding; bh=d4eP26ZkNo5iHes0MEcyA2smG6jbNgixhESHbttZokE=; b=nPn+s4T5RnrfriEX6Pr1gcZmZ9hLv+tkMBpnNgAFOZDc+yCgZxD2IgCG65pFzm+FOx 5KoGHhLsuoLxYT1dnYepMky4p9eWTmdoUgp1+WQTsRYEjjOYqmp7M9/BLEuOEz79I7Ln viRE0B7kenHdmq+9T2Lj6WZbpb7yj0Im9Z4WnGndvM1UloA80DoUz8gfD8+iqETH5OjX aKs6mBi20RHSNVDSdDSJJXq8zPgqDCNn/hNHNJQroqOpFfv4DVpGejp3gRFVXyFpivCs 754rPjacXQoa+/x0rukwthpX8R+2Mjo5yl5EAtX7Zmz1nvUII4HBVSbXPf+y3TiQTWvn 1dCA== X-Gm-Message-State: APjAAAUHDsflPiV7HjHW+wEBosxDLrlfl+w3y7IQanh/CWA0E19+pDNK deHzcI4/DAiEySrz6herx4H+OXaCVzk= X-Google-Smtp-Source: APXvYqxbhEkQCIGYHWQVVj7m4vD7PEZMEdCvJB/3IHtL5wwxwRsigCYIxG35xw3xBMA4vy+1wWKx0A== X-Received: by 2002:a62:6f02:: with SMTP id k2mr5027248pfc.136.1554568885958; Sat, 06 Apr 2019 09:41:25 -0700 (PDT) Received: from [10.0.0.131] ([2601:641:c080:5dc3:b9da:151f:474c:7fe2]) by smtp.gmail.com with ESMTPSA id q80sm47290552pfa.66.2019.04.06.09.41.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Apr 2019 09:41:24 -0700 (PDT) User-Agent: Microsoft-MacOutlook/10.17.1.190326 Date: Sat, 06 Apr 2019 09:41:23 -0700 From: Jai Kumar To: Tom Herbert CC: "Pengshuping (Peng Shuping)" , 6man , ippm , "C. M. Heard" , Mikael Abrahamsson Message-ID: <6E177A89-8488-4E24-A37A-B4C14D8ACB0D@broadcom.com> Thread-Topic: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> <4278D47A901B3041A737953BAA078ADE1478D5E2@DGGEML532-MBX.china.huawei.com> <4278D47A901B3041A737953BAA078ADE1478EC8B@DGGEML532-MBX.china.huawei.com> <14A3D5C9-1EED-4E11-9329-B62B819271A2@broadcom.com> <20D6FCDB-3357-4728-BD52-8069C32F3CCA@broadcom.com> <57A32C37-AAE9-44F2-9C96-39AFA71BDC21@broadcom.com> <36B9204A-D1EE-4067-92BB-6C33CB2DF791@broadcom.com> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 16:41:31 -0000 Tom, Please read the IOAM draft again. There is a variable length metadata stack= as well with trace option. Forwarding becomes completely indeterministic. In short using options forwarding gets impacted for EH. You still want to p= ush for it go by all means but don't expect a silicon vendor or deployment t= o agree for it. -Jai =EF=BB=BFOn 4/5/19, 5:05 PM, "Tom Herbert" wrote: On Fri, Apr 5, 2019 at 4:40 PM Jai Kumar wrote= : > > Tom, > > > > You are right. There are two main cases where accessibility of transp= ort header becomes an issue. And that is mainly because of current generatio= n of fixed pipeline cell based architecture parse depth (not so much an issu= e for high end NPU where next packet header bytes can be DMA=E2=80=99ed in, though= it impacts the performance. For eg. Cisco QFP NPU, EZ Chip, Juniper=E2=80=99s MX = 3D NPU, or Broadcom=E2=80=99s Jerricho NPU ). This was mentioned earlier by Mikael= as well. > > > > Case 1. SRv6 > > Case 2. IPv6 with EH (mainly for 5G deployments where RH, DH, and IFA= Header) > > > > Typically NPUs provide capability that it will handle 3 or 4 EH or SR= H without performance penalty. With the presence of IFA header this means th= at for eg there can be only 2 or 3 SRH or EH. This is same as in MPLS label = stack depth handling (PUSH or POP at PE router). Given the evolution SRV6 an= d MPLS-SR kind of headers, silicon vendors have taken a notice of it and are= evolving the silicon arch to handle more chained headers. > > > > IFA supports fragmentation of metadata stack and also postcard mode s= o beyond the transport header it=E2=80=99s not an issue. > > > > Just a quick feedback on using IPv6 options, inserting hop by hop opt= ions for data path processing pushes the EH further down and impacts the nod= e=E2=80=99s forwarding function (say if it is not able to reach Destination EH) vs= if IFA header is the last EH then atmost transit node do not perform metada= ta collection which can be identified. =20 Maybe it does impact it, maybe it doesn't. It clearly depends on the device capabilities. For a device with a parsing buffer of 256 bytes that should be plenty of room for HBH options, SR header, transport layer, etc. =20 > > > > -Jai > > > > From: Tom Herbert > Date: Friday, April 5, 2019 at 3:34 PM > To: Jai Kumar > Cc: "Pengshuping (Peng Shuping)" , 6man , ippm , "C. M. Heard" , Mikael Ab= rahamsson > Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 = feedback (Re: v6 option types for IOAM data fields) > > > > Jai, > > > > You might want to consider how IFA works in the presence of segment r= outing. The second someone puts an SRH in the packet the IFA headers get pus= hed down and the transport headers end up being deep in the packet anyway so= that all the effort of IFA is nullified. If the requirement is to ensure th= at the transport layer information appear as early as possible in the packet= , one could define a Hop-by-Hop option to carry some sort of pseudo header f= or the transport layer. This also would work in the case that the actual tra= nsport layer is obfuscated. > > > > Tom > > > > On Fri, Apr 5, 2019, 3:09 PM Jai Kumar wrote= : > > =E2=80=9CThat is going to require justifying the protocol even in light of = shortcomings in existing protocoIs.=E2=80=9D > > > > Agreed !!! True for any proposal. > > > > -Jai > > > > From: Tom Herbert > Date: Friday, April 5, 2019 at 2:34 PM > To: Jai Kumar > Cc: "Pengshuping (Peng Shuping)" , 6man , ippm , "C. M. Heard" , Mikael Ab= rahamsson > Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 = feedback (Re: v6 option types for IOAM data fields) > > > > > > On Fri, Apr 5, 2019, 2:07 PM Jai Kumar wrote= : > > Tom, > > Its all explained in the requirements section of the draft. IFA heade= r is essentially treated as an EH both in IPv4 and IPv6 (very similar to AH/= ESP EH). > > Just like in AH/ESP the IP protocol is copied in the AH header and IP= protocol field is replaced in the IP header with the AH proto. > > There are several advantages to this approach. > - devise know how to parse AH header and can follow very similar appr= oach > - Protocol agnostics, silicon need not support N encaps (just like AH= /ESP). Single implementation works for all protocol types. > - No need to creation options and teach devices that options is NOT a= n exception path processing > - Really worry about ordering in IPv6 options > - Note that all the OAM data need to be deleted as well so position n= eed to be optimal for removal. We can always do tail stamping of the data bu= t this puts considerable constrains on the cell based architecture > - L4 accessibility I have already mentioned > > I am happy to discuss with you in person and explain more but bottom = line is that this proposal is what came out with MSDC discussions in light o= f shortcomings from other IETF proposals. > > > > As they say, you are free to run whatever you want in your proprietar= y network, but if you expect to create an interoperable, deployable protocoI= and get a protocol number assignment, you'll need to work in ietf. That is = going to require justifying the protocol even in light of shortcomings in ex= isting protocoIs. > > > > Tom > > > > > Regards, > -Jai > > > =EF=BB=BFOn 4/5/19, 12:28 PM, "Tom Herbert" wrote: > > On Fri, Apr 5, 2019 at 12:03 PM Jai Kumar wrote: > > > > " Great, but this IETF" > > Does it mean that drafts have no relevance to deployment and ac= tual adoption. > > > > For all your queries please take a look at IFA draft. > > https://datatracker.ietf.org/doc/draft-kumar-ippm-ifa/ > > > I've looked at that draft. It's is creating a complete new IP > protocolas well as a new packet format for TCP and UDP that someh= ow > inserts meta data between the TCP header and payload. I don't > understand why this could possibly be better than just using flow > label for ECMP and teaching devices that need to extract transpor= t > information how to walk over EH, or just using some UDP encpasula= tion > like in draft-herbert-ipv4-udpencap-eh-01. > > Tom > > > It handles IPv6, IPv4 TCP/UDP with altering the packet path (du= e to inserting options and/or encaping them in GRE header) as well as IPSec = AH/ESP/WESP both tunnel and transport and guess what it is successfully depl= oyed. > > > > -Jai > > > > =EF=BB=BFOn 4/5/19, 11:54 AM, "Tom Herbert" wro= te: > > > > On Fri, Apr 5, 2019 at 11:25 AM Jai Kumar wrote: > > > > > > Tom, > > > > > > I am speaking based on the actual deployment not based on= if all the traffic is/will move to IPSec tunnel. > > > > > > I have 6 large customer deployments and one someone previ= ously called as "Yahoo" who insist on visibility in L4 even for IOAM packets= . > > > > > And I've worked in datcenters much larger, and my first rul= e is that I > > don't want random router vendors dictating to me what proto= cols I'm > > allowed to use in my datacenter. > > > > > I can quote you on that and lose my business :-) > > > > > > ECMP argument is weak as well as it works for IPv6 flow l= abel. What about IPv4 TCP/UDP traffic which typically is 80% of the traffic = in MSDC. > > > > > > > draft-herbert-ipv4-udpencap-eh-01 > > > > > If someone tells me that proposal will work only for my 2= 0% of traffic then again as I said before, they will lose my business :-) > > > > > Great, but this IETF. Where are the protocol requirements? = If you are > > saying that there are requirements for "visibility in L4" w= hat are > > they? If you are saying that ACLs are now required for pack= et > > forwarding, where is that described? Is it a MUST that teh = only > > transport protocols we're allowed to use are UDP or TCP? A= re we > > allowed to use extension headers at all? I suppose fragment= ation is > > right out... Are we violating the requirements if we encryp= t the > > transport headers? If you say that we shouldn't send long h= eaders > > because we'll overflow parsing buffers, then what is the li= mit? Please > > be SPECIFC in setting requirements; we are trying to build = protocols > > that work and are interoperable and we need to get out of t= his morass > > of reverse engineering to discover the least common denomin= ator. > > > > Tom > > > > > Regards, > > > -Jai > > > > > > =EF=BB=BFOn 4/5/19, 11:15 AM, "Tom Herbert" wrote: > > > > > > On Fri, Apr 5, 2019 at 10:55 AM Jai Kumar wrote: > > > > > > > > Even if we use flow label for ECMP, lack of accessi= bility of L4 information (for various services, most simple is ACL) makes th= e proposal pretty much unusable. > > > > > > > That is convoluting router and firewall functionality= and > > > requirements. This a discussion about packet forwardi= ng which does > > > _not_ require ACLs. In a limited domain, for which IO= AM is intended, > > > it is unlikely that they'll ACLs would be used in int= ernal nodes, but > > > we do need good ECMP routing at all intermediate node= s need to be > > > consistent rather or not that the IOAM option is pres= ent. As side > > > note, the ability to extract L4 information out of pa= ckets is > > > dwindling anyway thanks to encryption and other techn= iques trying to > > > undo protocol ossification. For instance, good luck g= etting L4 > > > information out of an IPsec tunnel :-). > > > > > > Tom > > > > > > > NIC cards are not used pervasively for ACLs and oth= er services, I believe iptables in kernel are good enough for host but that=E2= =80=99s not acceptable in networking elements. > > > > > > > > -Jai > > > > > > > > =EF=BB=BFOn 4/5/19, 10:31 AM, "ippm on behalf of Tom Herb= ert" wrote: > > > > > > > > On Fri, Apr 5, 2019 at 9:16 AM Pengshuping (Pen= g Shuping) > > > > wrote: > > > > > > > > > > Hi Barak, > > > > > > > > > > We are certainly not designing for the lowest= capable solutions but exploring optimal solutions which could help to keep = the forwarding performance while inserting the iOAM data with variable lengt= h. > > > > > > > > Shuping, > > > > > > > > That's exactly the argument for using the flow = label in ECMP. > > > > Efficeint packet forwarding can be done solely = by inspected the forty > > > > byte fixed length header of the packet regardle= ss of the contents of > > > > the rest of the packet. That is an optimal solu= tion. Anything else for > > > > ECMP like doing DPI or hacking up IOAM to try d= o pull transport layers > > > > into the parsing buffer (whatever size that may= be) are nothing more > > > > than hacks and unnecessarily perpetuate techniq= ues used with IPv4 that > > > > either don't work or are unnecessary in IPv6. > > > > > > > > Tom > > > > > > > > > > > > > > > > > > In terms of the forwarding efficiency, we wou= ld all agree that a short and fixed header would be better than a variable h= eader. > > > > > > > > > > Best regards > > > > > Shuping > > > > > > > > > > > > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Barak Gafni > > > > > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Pengshuping (Peng Shuping);Frank Brockners (fbrockne);Mikael Abr= ahamsson > > > > > =E6=8A=84=E9=80=81=EF=BC=9A C. M. Heard;6man W= G;Mark Smith;ippm > > > > > =E4=B8=BB=E9=A2=98=EF=BC=9A RE: draft-ioametal-ippm-6man-ioam-i= pv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) > > > > > =E6=97=B6=E9=97=B4=EF=BC=9A 2019-04-05 03:18:26 > > > > > > > > > > Hi Shuping, > > > > > I think that the question is whether we desig= n for the lowest capable solutions. I assume someone can find solutions with= even lower amount of parsing.. The low end solutions for these capabilities= may need to either adopt with new designs or use solutions such as what is = suggested in this thread by Tom Herbert. > > > > > Personally, I don't think we should go this w= ay, but to design appropriate solutions, with appropriate layers in the head= ers. For example, prevent dependencies between "remote" headers. > > > > > > > > > > Thanks, > > > > > Barak > > > > > > > > > > -----Original Message----- > > > > > From: ippm On Behalf = Of Pengshuping (Peng Shuping) > > > > > Sent: Wednesday, April 3, 2019 6:47 AM > > > > > To: Frank Brockners (fbrockne) ; Mikael Abrahamsson > > > > > Cc: C. M. Heard ; 6man WG ; Mark Smith ; ippm@ietf.org > > > > > Subject: [ippm] =E7=AD=94=E5=A4=8D: draft-ioametal-ippm-6= man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fiel= ds) > > > > > > > > > > Hi, > > > > > > > > > > The parsing depth of the early chips is 96B/1= 28B. For the new chips the parsing depth has been increased but still limite= d. So Mikael's concern makes sense especially in the tracing mode that the I= OAM data fields are going to increase significantly along the path, which wi= ll even push the Routing Header out of the parsing depth of the chip. So it = would make sense to split the IOAM data part from the IOAM header/instructio= n part, and place the IOAM data after the RH or even after the L4 header in = order to be able to read the L4 information to enable ECMP, as stated in the= draft https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftoo= ls.ietf.org%2Fhtml%2Fdraft-li-6man-ipv6-sfc-ifit-00&data=3D02%7C01%7Cgbara= k%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d1= 49256f461b%7C0%7C0%7C636898960379485833&sdata=3DDob4zN%2F1jSGxLTlqGma29JJN= vqJDBt4VzqHsN4OpxM4%3D&reserved=3D0. > > > > > > > > > > BR, > > > > > Shuping > > > > > > > > > > > > > > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: ippm [mailto:ippm-bounces@ietf.org= ] =E4=BB=A3=E8=A1=A8 Frank Brockners (fbrockne) > > > > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B44=E6=9C=882=E6=97=A5 17:40 > > > > > =E6=94=B6=E4=BB=B6=E4=BA=BA: Mikael Abrahamsson > > > > > =E6=8A=84=E9=80=81: C. M. Heard ; 6man W= G ; Mark Smith ; ippm@ietf.org > > > > > =E4=B8=BB=E9=A2=98: Re: [ippm] draft-ioametal-ippm-6man-i= oam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Mikael Abrahamsson > > > > > Sent: Dienstag, 2. April 2019 08:06 > > > > > To: Frank Brockners (fbrockne) > > > > > Cc: Mark Smith ; C. M= . Heard ; 6man WG ; ippm@ietf.org > > > > > Subject: RE: draft-ioametal-ippm-6man-ioam-ip= v6-deployment-00 feedback (Re: v6 option types for IOAM data fields) > > > > > > > > > > On Mon, 1 Apr 2019, Frank Brockners (fbrockne= ) wrote: > > > > > > > > > > > ...FB: There is obviously no easy answer. C= ouple of thoughts: > > > > > > * IOAM is considered a "domain specific" fe= ature (see > > > > > > draft-ietf-ippm-ioam-data-05, section 3). R= outers in the IOAM domain > > > > > > should be IOAM capable. And IMHO, we shou= ld add a statement to > > > > > > draft-ioametal-ippm-6man-ioam-ipv6-deployme= nt that an implementation > > > > > > of IOAM MUST ensure "C1". > > > > > > > > > > > > * That said, there can be situations, where= C1 cannot be achieved, e.g.. > > > > > > consider a network which does ECMP scheduli= ng based on packet length. > > > > > > > > > > > > * What one could consider - and which is on= e suggested deployment > > > > > > model > > > > > > - is that by default IOAM data fields are a= dded to _all_ customer > > > > > > packets. The decapsulating node would decid= e whether the IOAM > > > > > > information contained in a packet would be = used (and exported) or not. > > > > > > That way one would not need to deal with th= e situation that some > > > > > > traffic carries IOAM while other does not -= and might thus be treated > > > > > > differently. > > > > > > > > > > Yes, I think this is the only way. Is there a= risk that intermediate routers would not be IOAM capable? I think the C1 re= quirement is really really hard to fulfil and I'm also afraid that adding th= e IOAM header will actually make ECMP stop working on some platforms (becaus= e they would not have the capability to look deep enough into the packet to = find L4 information, so it'll go back to 2 tuple ECMP instead of 5 tuple. > > > > > > > > > > But this question can only be answered by peo= ple with deep NPU knowledge... > > > > > > > > > > .....FB2: Given that IOAM is a domain specifi= c feature - I expect that folks initially start to use it in domains (like e= .g. a DC) where all boxes are IOAM capable and can trace the packet appropri= ately - or per Tom's note, can be configured so that one would do ECMP based= on addresses and flow-label. There are chips with pretty deep parsing capa= bility (up to a few hundred bytes). > > > > > > > > > > > ...FB: The comparison to MPLS is interestin= g. How often do MPLS > > > > > > packets leak and cause harm? For IOAM, > > > > > > draft-ioametal-ippm-6man-ioam-ipv6-options-= 02 proposes a deployment > > > > > > model similar to what we do for MPLS: Unles= s an interface is > > > > > > explicitly configured for IOAM, packets wit= h IOAM data fields MUST be dropped. > > > > > > Hence leakage would only occur, if we have = a clearly misbehaving > > > > > > router which violates this rule. Similar to= you, I'd also greatly > > > > > > appreciate any pointers to research on how = common MPLS leaked packets are. > > > > > > > > > > When it comes to "cause harm" I imagine there= are (at least) two ways to cause harm, one is privacy/secrecy/security loss= and the other one is actual operational loss. > > > > > > > > > > I know of bugs where labeled packets went the= wrong way and caused them to be lost, I've also seen bugs where bugs caused= traffic to "hop" between VRFs in MPLS VPN (or to "global" VRF). I don't hav= e numbers on this though. > > > > > > > > > > Depending on the deployment scenario, it migh= t make sense to make IOAM packets not valid for non-IOAM aware devices (basi= cally encap entire packet/payload), but that might be a problem for intermed= iate non-IOAM nodes then. This would affect the ECMP requirement. I can see = cases where one would operationally turn on IOAM for some customers traffic = and then see the problem go away because now ECMP changed. > > > > > > > > > > > ...FB: One idea that Shwetha came up with t= o identify the source AS of > > > > > > a leaked packet, would be to add a new new = IOAM E2E option - as > > > > > > proposed in section 5.1.1 bullet 2 of > > > > > > draft-ioametal-ippm-6man-ioam-ipv6-deployme= nt-01. > > > > > > > > > > Yes, that'd solve that problem. > > > > > > > > > > How much has the silicon people been involved= so far in the design of the headers? What is the current thinking of amount= of data going into the IOAM header? Considering things like trace options e= tc it seems to me the header can grow quite large? To satisfy the ECMP requi= rement what about putting the IOAM information as a trailer behind the regul= ar payload? Or is there a problem for the hw to manipulate information that = far into the packet (I also imagine this will considerably lower the forward= ing performance of IOAM packets on IOAM aware platforms). > > > > > > > > > > .....FB2: There are quite a few folks with ha= rdware background that co-author the IOAM drafts. Parsing capability differs= between chips, as does the ability to deal with new/flexible headers and th= e ability to modify data in the extension headers. So the unfortunate answer= to that question is "it depends" (what information do you gather, how large= is your domain, what are the capabilities of your hardware/software forward= er, etc.), but I do expect that for specific deployment domains (e.g. DC, En= terprise) - but also for overlay networks / VPNs - we'll see an increasing a= mount of chips that are well suited for processing large extension header. > > > > > > > > > > Cheers, Frank > > > > > > > > > > -- > > > > > Mikael Abrahamsson email: swmike@swm.pp.se > > > > > > > > > > _____________________________________________= __ > > > > > ippm mailing list > > > > > ippm@ietf.org > > > > > https://eur03.safelinks.protection.outlook.co= m/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C= 01%7Cgbarak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e= 4d9ba6a4d149256f461b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159= je0yef3BJFz6AQNNAtkgmAMDFKM%3D&reserved=3D0 > > > > > _____________________________________________= __ > > > > > ippm mailing list > > > > > ippm@ietf.org > > > > > https://eur03.safelinks.protection.outlook.co= m/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C= 01%7Cgbarak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e= 4d9ba6a4d149256f461b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159= je0yef3BJFz6AQNNAtkgmAMDFKM%3D&reserved=3D0 > > > > > ---------------------------------------------= ----------------------- > > > > > IETF IPv6 working group mailing list > > > > > ipv6@ietf.org > > > > > Administrative Requests: https://www.ietf.org= /mailman/listinfo/ipv6 > > > > > ---------------------------------------------= ----------------------- > > > > > > > > _______________________________________________ > > > > ippm mailing list > > > > ippm@ietf.org > > > > https://www.ietf.org/mailman/listinfo/ippm > > > > > > > > > > > > > > > > > > > > > > > > > > > > =20 From nobody Sat Apr 6 12:55:44 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5BE120363 for ; Sat, 6 Apr 2019 12:55:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 2KiODVRmV1Ff for ; Sat, 6 Apr 2019 12:55:32 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CD66120089 for ; Sat, 6 Apr 2019 12:55:32 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id z16so11249125qtn.4 for ; Sat, 06 Apr 2019 12:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0NZGC6Crxz2RdIZ7VaYTOa+oOHCbkQW+krHkCay1+Ns=; b=J4Eeiebj5XTQY8BtwGTbryPzuWH2WNucMf1qfSdbReg8nofLQwscx7oPR8R1hEMbhg HVf7B/tflPcNhbDs1J2j+Jta3MOErpKoHNI0gMZU4YOilKmEx0DtEb9JECUvJy4L1OC0 p+LUA0GAYwwKoxfbdztLe6GotMmaFAlrTEZMbtx5hemBwy6MSxhwMgs4z9wwfqcnUMCK Xw+O8U3sNayWSX+i4Nf8+iav13GMierxlHMehCQHl3Bs8iR9M4gERyxEJ7teOIheXhk5 hJpwFosqvxoSt6SxzVh5Tnj5TMeUUe0pjNvUuhF7OPqjbfVcawtWPs3Slcd8y2wStmIT 0jew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0NZGC6Crxz2RdIZ7VaYTOa+oOHCbkQW+krHkCay1+Ns=; b=IoABWcIBmLwPknNQV4k9tTYRkjND1kS+I8wy8jDr3wZh+F3ujC90K+8UiA/HOiuHbC Znv3Lt+o7yN7XH+vEb9NA4CmpwN+yQdaDvmdC1r42MJFghqw/Ameg9l6zEsiKXazBAd5 8MKs/ePP2jJYKnUuOv9qAkF+b+tdfTzSAOOF5Q9G5pQMg3rU886iWddl51L12clXN92y 11QSYDKLKEvDwKy82T8ZtQGT8rvg2VORMsPpBqiGNgQf5Y6J+DJ5w5pYEg/1NSNkHPUA wM+9iMGAkuBvG/hNQ8LoGPjp0Rgp+a1fDb7dsL/bbHbA2KeYn89Ba5+rPA8HbjIKsl9L 2pww== X-Gm-Message-State: APjAAAV2IXmBLw1KBDPnB/S4c+3IPzG7f7/Yi6K8eIOFnH0Tmuulzwjr NgXnILCLKYPRFVYg6VFzr0MXswIfE0v2soopMAbZLA== X-Google-Smtp-Source: APXvYqzH1HHeaJr5lTcq3b2zMGcAqXtXAsABELAi/I3IkZbqISdruW6pXaXxDjXhgiln2XiXwK4lEDS7oG1wLHgjVZ8= X-Received: by 2002:a0c:af02:: with SMTP id i2mr16879531qvc.40.1554580531097; Sat, 06 Apr 2019 12:55:31 -0700 (PDT) MIME-Version: 1.0 References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> <4278D47A901B3041A737953BAA078ADE1478D5E2@DGGEML532-MBX.china.huawei.com> <4278D47A901B3041A737953BAA078ADE1478EC8B@DGGEML532-MBX.china.huawei.com> <14A3D5C9-1EED-4E11-9329-B62B819271A2@broadcom.com> <20D6FCDB-3357-4728-BD52-8069C32F3CCA@broadcom.com> <57A32C37-AAE9-44F2-9C96-39AFA71BDC21@broadcom.com> <36B9204A-D1EE-4067-92BB-6C33CB2DF791@broadcom.com> <6E177A89-8488-4E24-A37A-B4C14D8ACB0D@broadcom.com> In-Reply-To: <6E177A89-8488-4E24-A37A-B4C14D8ACB0D@broadcom.com> From: Tom Herbert Date: Sat, 6 Apr 2019 12:55:20 -0700 Message-ID: To: Jai Kumar Cc: "Pengshuping (Peng Shuping)" , 6man , ippm , "C. M. Heard" , Mikael Abrahamsson Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 19:55:37 -0000 On Sat, Apr 6, 2019 at 9:41 AM Jai Kumar wrote: > > Tom, > > Please read the IOAM draft again. There is a variable length metadata sta= ck as well with trace option. Forwarding becomes completely indeterministic= . Jai, Use the flow label and addresses as input to ECMP forwarding _is_ deterministic. And not just for deterministic for TCP or UDP, but for _any_ protocol, combination of EH, encryptions, etc. that a packet carries. See RFC6438. > In short using options forwarding gets impacted for EH. You still want to= push for it go by all means but don't expect a silicon vendor or deploymen= t to agree for it. I'm not sure what we're trying to get agreement on. The only expectation we have is that vendors, and everyone else for that matter, conform to IETF standards. Extension headers have be defined for over twenty years and are full standard, and now that people want to use them there appears to be _some_ implementations (emphasis on the word "some") that seem to have a problem processing them. Frankly, that is a shortcoming of implementation, not of the protocol. The only protocol shortcoming that has thus far been identified in the IOAM discussion is the fact that EH don't exist in IPv4 and there is really no alternative that provides the necessary functionality-- this is something I believe IETF can work on. Tom > > -Jai > > =EF=BB=BFOn 4/5/19, 5:05 PM, "Tom Herbert" wrote: > > On Fri, Apr 5, 2019 at 4:40 PM Jai Kumar wro= te: > > > > Tom, > > > > > > > > You are right. There are two main cases where accessibility of tran= sport header becomes an issue. And that is mainly because of current genera= tion of fixed pipeline cell based architecture parse depth (not so much an = issue for high end NPU where next packet header bytes can be DMA=E2=80=99ed= in, though it impacts the performance. For eg. Cisco QFP NPU, EZ Chip, Jun= iper=E2=80=99s MX 3D NPU, or Broadcom=E2=80=99s Jerricho NPU ). This was me= ntioned earlier by Mikael as well. > > > > > > > > Case 1. SRv6 > > > > Case 2. IPv6 with EH (mainly for 5G deployments where RH, DH, and I= FA Header) > > > > > > > > Typically NPUs provide capability that it will handle 3 or 4 EH or = SRH without performance penalty. With the presence of IFA header this means= that for eg there can be only 2 or 3 SRH or EH. This is same as in MPLS la= bel stack depth handling (PUSH or POP at PE router). Given the evolution SR= V6 and MPLS-SR kind of headers, silicon vendors have taken a notice of it a= nd are evolving the silicon arch to handle more chained headers. > > > > > > > > IFA supports fragmentation of metadata stack and also postcard mode= so beyond the transport header it=E2=80=99s not an issue. > > > > > > > > Just a quick feedback on using IPv6 options, inserting hop by hop o= ptions for data path processing pushes the EH further down and impacts the = node=E2=80=99s forwarding function (say if it is not able to reach Destinat= ion EH) vs if IFA header is the last EH then atmost transit node do not per= form metadata collection which can be identified. > > Maybe it does impact it, maybe it doesn't. It clearly depends on the > device capabilities. For a device with a parsing buffer of 256 bytes > that should be plenty of room for HBH options, SR header, transport > layer, etc. > > > > > > > > > -Jai > > > > > > > > From: Tom Herbert > > Date: Friday, April 5, 2019 at 3:34 PM > > To: Jai Kumar > > Cc: "Pengshuping (Peng Shuping)" , 6man , ippm , "C. M. Heard" , Mikael= Abrahamsson > > Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-0= 0 feedback (Re: v6 option types for IOAM data fields) > > > > > > > > Jai, > > > > > > > > You might want to consider how IFA works in the presence of segment= routing. The second someone puts an SRH in the packet the IFA headers get = pushed down and the transport headers end up being deep in the packet anywa= y so that all the effort of IFA is nullified. If the requirement is to ensu= re that the transport layer information appear as early as possible in the = packet, one could define a Hop-by-Hop option to carry some sort of pseudo h= eader for the transport layer. This also would work in the case that the ac= tual transport layer is obfuscated. > > > > > > > > Tom > > > > > > > > On Fri, Apr 5, 2019, 3:09 PM Jai Kumar wro= te: > > > > =E2=80=9CThat is going to require justifying the protocol even in l= ight of shortcomings in existing protocoIs.=E2=80=9D > > > > > > > > Agreed !!! True for any proposal. > > > > > > > > -Jai > > > > > > > > From: Tom Herbert > > Date: Friday, April 5, 2019 at 2:34 PM > > To: Jai Kumar > > Cc: "Pengshuping (Peng Shuping)" , 6man , ippm , "C. M. Heard" , Mikael= Abrahamsson > > Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-0= 0 feedback (Re: v6 option types for IOAM data fields) > > > > > > > > > > > > On Fri, Apr 5, 2019, 2:07 PM Jai Kumar wro= te: > > > > Tom, > > > > Its all explained in the requirements section of the draft. IFA hea= der is essentially treated as an EH both in IPv4 and IPv6 (very similar to = AH/ESP EH). > > > > Just like in AH/ESP the IP protocol is copied in the AH header and = IP protocol field is replaced in the IP header with the AH proto. > > > > There are several advantages to this approach. > > - devise know how to parse AH header and can follow very similar ap= proach > > - Protocol agnostics, silicon need not support N encaps (just like = AH/ESP). Single implementation works for all protocol types. > > - No need to creation options and teach devices that options is NOT= an exception path processing > > - Really worry about ordering in IPv6 options > > - Note that all the OAM data need to be deleted as well so position= need to be optimal for removal. We can always do tail stamping of the data= but this puts considerable constrains on the cell based architecture > > - L4 accessibility I have already mentioned > > > > I am happy to discuss with you in person and explain more but botto= m line is that this proposal is what came out with MSDC discussions in ligh= t of shortcomings from other IETF proposals. > > > > > > > > As they say, you are free to run whatever you want in your propriet= ary network, but if you expect to create an interoperable, deployable proto= coI and get a protocol number assignment, you'll need to work in ietf. That= is going to require justifying the protocol even in light of shortcomings = in existing protocoIs. > > > > > > > > Tom > > > > > > > > > > Regards, > > -Jai > > > > > > =EF=BB=BFOn 4/5/19, 12:28 PM, "Tom Herbert" w= rote: > > > > On Fri, Apr 5, 2019 at 12:03 PM Jai Kumar wrote: > > > > > > " Great, but this IETF" > > > Does it mean that drafts have no relevance to deployment and = actual adoption. > > > > > > For all your queries please take a look at IFA draft. > > > https://datatracker.ietf.org/doc/draft-kumar-ippm-ifa/ > > > > > I've looked at that draft. It's is creating a complete new IP > > protocolas well as a new packet format for TCP and UDP that som= ehow > > inserts meta data between the TCP header and payload. I don't > > understand why this could possibly be better than just using fl= ow > > label for ECMP and teaching devices that need to extract transp= ort > > information how to walk over EH, or just using some UDP encpasu= lation > > like in draft-herbert-ipv4-udpencap-eh-01. > > > > Tom > > > > > It handles IPv6, IPv4 TCP/UDP with altering the packet path (= due to inserting options and/or encaping them in GRE header) as well as IPS= ec AH/ESP/WESP both tunnel and transport and guess what it is successfully = deployed. > > > > > > -Jai > > > > > > =EF=BB=BFOn 4/5/19, 11:54 AM, "Tom Herbert" wrote: > > > > > > On Fri, Apr 5, 2019 at 11:25 AM Jai Kumar wrote: > > > > > > > > Tom, > > > > > > > > I am speaking based on the actual deployment not based = on if all the traffic is/will move to IPSec tunnel. > > > > > > > > I have 6 large customer deployments and one someone pre= viously called as "Yahoo" who insist on visibility in L4 even for IOAM pack= ets. > > > > > > > And I've worked in datcenters much larger, and my first r= ule is that I > > > don't want random router vendors dictating to me what pro= tocols I'm > > > allowed to use in my datacenter. > > > > > > > I can quote you on that and lose my business :-) > > > > > > > > ECMP argument is weak as well as it works for IPv6 flow= label. What about IPv4 TCP/UDP traffic which typically is 80% of the traff= ic in MSDC. > > > > > > > > > > draft-herbert-ipv4-udpencap-eh-01 > > > > > > > If someone tells me that proposal will work only for my= 20% of traffic then again as I said before, they will lose my business :-) > > > > > > > Great, but this IETF. Where are the protocol requirements= ? If you are > > > saying that there are requirements for "visibility in L4"= what are > > > they? If you are saying that ACLs are now required for pa= cket > > > forwarding, where is that described? Is it a MUST that te= h only > > > transport protocols we're allowed to use are UDP or TCP?= Are we > > > allowed to use extension headers at all? I suppose fragme= ntation is > > > right out... Are we violating the requirements if we encr= ypt the > > > transport headers? If you say that we shouldn't send long= headers > > > because we'll overflow parsing buffers, then what is the = limit? Please > > > be SPECIFC in setting requirements; we are trying to buil= d protocols > > > that work and are interoperable and we need to get out of= this morass > > > of reverse engineering to discover the least common denom= inator. > > > > > > Tom > > > > > > > Regards, > > > > -Jai > > > > > > > > =EF=BB=BFOn 4/5/19, 11:15 AM, "Tom Herbert" wrote: > > > > > > > > On Fri, Apr 5, 2019 at 10:55 AM Jai Kumar wrote: > > > > > > > > > > Even if we use flow label for ECMP, lack of acces= sibility of L4 information (for various services, most simple is ACL) makes= the proposal pretty much unusable. > > > > > > > > > That is convoluting router and firewall functionali= ty and > > > > requirements. This a discussion about packet forwar= ding which does > > > > _not_ require ACLs. In a limited domain, for which = IOAM is intended, > > > > it is unlikely that they'll ACLs would be used in i= nternal nodes, but > > > > we do need good ECMP routing at all intermediate no= des need to be > > > > consistent rather or not that the IOAM option is pr= esent. As side > > > > note, the ability to extract L4 information out of = packets is > > > > dwindling anyway thanks to encryption and other tec= hniques trying to > > > > undo protocol ossification. For instance, good luck= getting L4 > > > > information out of an IPsec tunnel :-). > > > > > > > > Tom > > > > > > > > > NIC cards are not used pervasively for ACLs and o= ther services, I believe iptables in kernel are good enough for host but th= at=E2=80=99s not acceptable in networking elements. > > > > > > > > > > -Jai > > > > > > > > > > =EF=BB=BFOn 4/5/19, 10:31 AM, "ippm on behalf of = Tom Herbert" wrote= : > > > > > > > > > > On Fri, Apr 5, 2019 at 9:16 AM Pengshuping (P= eng Shuping) > > > > > wrote: > > > > > > > > > > > > Hi Barak, > > > > > > > > > > > > We are certainly not designing for the lowe= st capable solutions but exploring optimal solutions which could help to ke= ep the forwarding performance while inserting the iOAM data with variable l= ength. > > > > > > > > > > Shuping, > > > > > > > > > > That's exactly the argument for using the flo= w label in ECMP. > > > > > Efficeint packet forwarding can be done solel= y by inspected the forty > > > > > byte fixed length header of the packet regard= less of the contents of > > > > > the rest of the packet. That is an optimal so= lution. Anything else for > > > > > ECMP like doing DPI or hacking up IOAM to try= do pull transport layers > > > > > into the parsing buffer (whatever size that m= ay be) are nothing more > > > > > than hacks and unnecessarily perpetuate techn= iques used with IPv4 that > > > > > either don't work or are unnecessary in IPv6. > > > > > > > > > > Tom > > > > > > > > > > > > > > > > > > > > > > In terms of the forwarding efficiency, we w= ould all agree that a short and fixed header would be better than a variabl= e header. > > > > > > > > > > > > Best regards > > > > > > Shuping > > > > > > > > > > > > > > > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Barak = Gafni > > > > > > =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Pengsh= uping (Peng Shuping);Frank Brockners (fbrockne);Mikael Abrahamsson > > > > > > =E6=8A=84=E9=80=81=EF=BC=9A C. M. Heard;6man WG;Mark Smith;ipp= m > > > > > > =E4=B8=BB=E9=A2=98=EF=BC=9A RE: draft-ioame= tal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOA= M data fields) > > > > > > =E6=97=B6=E9=97=B4=EF=BC=9A 2019-04-05 03:1= 8:26 > > > > > > > > > > > > Hi Shuping, > > > > > > I think that the question is whether we des= ign for the lowest capable solutions. I assume someone can find solutions w= ith even lower amount of parsing.. The low end solutions for these capabili= ties may need to either adopt with new designs or use solutions such as wha= t is suggested in this thread by Tom Herbert. > > > > > > Personally, I don't think we should go this= way, but to design appropriate solutions, with appropriate layers in the h= eaders. For example, prevent dependencies between "remote" headers. > > > > > > > > > > > > Thanks, > > > > > > Barak > > > > > > > > > > > > -----Original Message----- > > > > > > From: ippm On Behal= f Of Pengshuping (Peng Shuping) > > > > > > Sent: Wednesday, April 3, 2019 6:47 AM > > > > > > To: Frank Brockners (fbrockne) ; Mikael Abrahamsson > > > > > > Cc: C. M. Heard ; 6man WG = ; Mark Smith ; ippm@ietf.org > > > > > > Subject: [ippm] =E7=AD=94=E5=A4=8D: draft-i= oametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for= IOAM data fields) > > > > > > > > > > > > Hi, > > > > > > > > > > > > The parsing depth of the early chips is 96B= /128B. For the new chips the parsing depth has been increased but still lim= ited. So Mikael's concern makes sense especially in the tracing mode that t= he IOAM data fields are going to increase significantly along the path, whi= ch will even push the Routing Header out of the parsing depth of the chip. = So it would make sense to split the IOAM data part from the IOAM header/ins= truction part, and place the IOAM data after the RH or even after the L4 he= ader in order to be able to read the L4 information to enable ECMP, as stat= ed in the draft https://eur03.safelinks.protection.outlook.com/?url=3Dhttps= %3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-li-6man-ipv6-sfc-ifit-00&data=3D= 02%7C01%7Cgbarak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca65297= 1c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636898960379485833&sdata=3DDob4zN%= 2F1jSGxLTlqGma29JJNvqJDBt4VzqHsN4OpxM4%3D&reserved=3D0. > > > > > > > > > > > > BR, > > > > > > Shuping > > > > > > > > > > > > > > > > > > -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6--= --- > > > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: ippm [mailto:i= ppm-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Frank Brockners (fbrockne) > > > > > > =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019= =E5=B9=B44=E6=9C=882=E6=97=A5 17:40 > > > > > > =E6=94=B6=E4=BB=B6=E4=BA=BA: Mikael Abraham= sson > > > > > > =E6=8A=84=E9=80=81: C. M. Heard ; 6man WG ; Mark Smith ; ippm@= ietf.org > > > > > > =E4=B8=BB=E9=A2=98: Re: [ippm] draft-ioamet= al-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM= data fields) > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Mikael Abrahamsson > > > > > > Sent: Dienstag, 2. April 2019 08:06 > > > > > > To: Frank Brockners (fbrockne) > > > > > > Cc: Mark Smith ; C.= M. Heard ; 6man WG ; ippm@ietf.org > > > > > > Subject: RE: draft-ioametal-ippm-6man-ioam-= ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) > > > > > > > > > > > > On Mon, 1 Apr 2019, Frank Brockners (fbrock= ne) wrote: > > > > > > > > > > > > > ...FB: There is obviously no easy answer.= Couple of thoughts: > > > > > > > * IOAM is considered a "domain specific" = feature (see > > > > > > > draft-ietf-ippm-ioam-data-05, section 3).= Routers in the IOAM domain > > > > > > > should be IOAM capable. And IMHO, we sh= ould add a statement to > > > > > > > draft-ioametal-ippm-6man-ioam-ipv6-deploy= ment that an implementation > > > > > > > of IOAM MUST ensure "C1". > > > > > > > > > > > > > > * That said, there can be situations, whe= re C1 cannot be achieved, e.g.. > > > > > > > consider a network which does ECMP schedu= ling based on packet length. > > > > > > > > > > > > > > * What one could consider - and which is = one suggested deployment > > > > > > > model > > > > > > > - is that by default IOAM data fields are= added to _all_ customer > > > > > > > packets. The decapsulating node would dec= ide whether the IOAM > > > > > > > information contained in a packet would b= e used (and exported) or not. > > > > > > > That way one would not need to deal with = the situation that some > > > > > > > traffic carries IOAM while other does not= - and might thus be treated > > > > > > > differently. > > > > > > > > > > > > Yes, I think this is the only way. Is there= a risk that intermediate routers would not be IOAM capable? I think the C1= requirement is really really hard to fulfil and I'm also afraid that addin= g the IOAM header will actually make ECMP stop working on some platforms (b= ecause they would not have the capability to look deep enough into the pack= et to find L4 information, so it'll go back to 2 tuple ECMP instead of 5 tu= ple. > > > > > > > > > > > > But this question can only be answered by p= eople with deep NPU knowledge... > > > > > > > > > > > > .....FB2: Given that IOAM is a domain speci= fic feature - I expect that folks initially start to use it in domains (lik= e e.g. a DC) where all boxes are IOAM capable and can trace the packet appr= opriately - or per Tom's note, can be configured so that one would do ECMP = based on addresses and flow-label. There are chips with pretty deep parsin= g capability (up to a few hundred bytes). > > > > > > > > > > > > > ...FB: The comparison to MPLS is interest= ing. How often do MPLS > > > > > > > packets leak and cause harm? For IOAM, > > > > > > > draft-ioametal-ippm-6man-ioam-ipv6-option= s-02 proposes a deployment > > > > > > > model similar to what we do for MPLS: Unl= ess an interface is > > > > > > > explicitly configured for IOAM, packets w= ith IOAM data fields MUST be dropped. > > > > > > > Hence leakage would only occur, if we hav= e a clearly misbehaving > > > > > > > router which violates this rule. Similar = to you, I'd also greatly > > > > > > > appreciate any pointers to research on ho= w common MPLS leaked packets are. > > > > > > > > > > > > When it comes to "cause harm" I imagine the= re are (at least) two ways to cause harm, one is privacy/secrecy/security l= oss and the other one is actual operational loss. > > > > > > > > > > > > I know of bugs where labeled packets went t= he wrong way and caused them to be lost, I've also seen bugs where bugs cau= sed traffic to "hop" between VRFs in MPLS VPN (or to "global" VRF). I don't= have numbers on this though. > > > > > > > > > > > > Depending on the deployment scenario, it mi= ght make sense to make IOAM packets not valid for non-IOAM aware devices (b= asically encap entire packet/payload), but that might be a problem for inte= rmediate non-IOAM nodes then. This would affect the ECMP requirement. I can= see cases where one would operationally turn on IOAM for some customers tr= affic and then see the problem go away because now ECMP changed. > > > > > > > > > > > > > ...FB: One idea that Shwetha came up with= to identify the source AS of > > > > > > > a leaked packet, would be to add a new ne= w IOAM E2E option - as > > > > > > > proposed in section 5.1.1 bullet 2 of > > > > > > > draft-ioametal-ippm-6man-ioam-ipv6-deploy= ment-01. > > > > > > > > > > > > Yes, that'd solve that problem. > > > > > > > > > > > > How much has the silicon people been involv= ed so far in the design of the headers? What is the current thinking of amo= unt of data going into the IOAM header? Considering things like trace optio= ns etc it seems to me the header can grow quite large? To satisfy the ECMP = requirement what about putting the IOAM information as a trailer behind the= regular payload? Or is there a problem for the hw to manipulate informatio= n that far into the packet (I also imagine this will considerably lower the= forwarding performance of IOAM packets on IOAM aware platforms). > > > > > > > > > > > > .....FB2: There are quite a few folks with = hardware background that co-author the IOAM drafts. Parsing capability diff= ers between chips, as does the ability to deal with new/flexible headers an= d the ability to modify data in the extension headers. So the unfortunate a= nswer to that question is "it depends" (what information do you gather, how= large is your domain, what are the capabilities of your hardware/software = forwarder, etc.), but I do expect that for specific deployment domains (e.g= . DC, Enterprise) - but also for overlay networks / VPNs - we'll see an inc= reasing amount of chips that are well suited for processing large extension= header. > > > > > > > > > > > > Cheers, Frank > > > > > > > > > > > > -- > > > > > > Mikael Abrahamsson email: swmike@swm.pp.= se > > > > > > > > > > > > ___________________________________________= ____ > > > > > > ippm mailing list > > > > > > ippm@ietf.org > > > > > > https://eur03.safelinks.protection.outlook.= com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data= =3D02%7C01%7Cgbarak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca65= 2971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1= PiwifYGCf159je0yef3BJFz6AQNNAtkgmAMDFKM%3D&reserved=3D0 > > > > > > ___________________________________________= ____ > > > > > > ippm mailing list > > > > > > ippm@ietf.org > > > > > > https://eur03.safelinks.protection.outlook.= com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data= =3D02%7C01%7Cgbarak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca65= 2971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1= PiwifYGCf159je0yef3BJFz6AQNNAtkgmAMDFKM%3D&reserved=3D0 > > > > > > -------------------------------------------= ------------------------- > > > > > > IETF IPv6 working group mailing list > > > > > > ipv6@ietf.org > > > > > > Administrative Requests: https://www.ietf.o= rg/mailman/listinfo/ipv6 > > > > > > -------------------------------------------= ------------------------- > > > > > > > > > > _____________________________________________= __ > > > > > ippm mailing list > > > > > ippm@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/ippm > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From nobody Sat Apr 6 14:06:09 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3461200A4 for ; Sat, 6 Apr 2019 14:06:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.com 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 7E_SDkCOeD_3 for ; Sat, 6 Apr 2019 14:05:58 -0700 (PDT) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D97B7120370 for ; Sat, 6 Apr 2019 14:05:55 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id k3so4969620pga.6 for ; Sat, 06 Apr 2019 14:05:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9QfsHZgcdZ5r8RPy7Ew7Yagiu28ULWD/r9hZ6wDvdUY=; b=c6a19jCViivDdP7BIm6W5ZJGvqFTcv8K+lHLB9jGuWMl7EY0uR4SGJlre62z56rE3e IdoUn5KNJ9x1vxRz5/1Yq+jZ0R/WwltwPy8MyKYkBvY0D+7YeLouapf9KQWOmCPpSlKy y06qrMFotLSCjzx0pgMgN46+Wg7PJviKD6GWk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9QfsHZgcdZ5r8RPy7Ew7Yagiu28ULWD/r9hZ6wDvdUY=; b=o1nMiFNgzwiw8VNYFLAAtttILfHtVac5yhYH3wr2dUvgKMsAtJyL9ho93x/0DdLeh2 mihCBxhWfoyepOlfP1MX9plO/nY7OTUF1N0QK2TxHUjLCzOvH33zyK67Bl4KHw1JnpSn g4XZ7l6Z14FWF4m6zkBFROjvVkej1HRqZK+TrtzMrei9u6+MwfUoIAfVUG9Y423jZp5u w3iqJW5VLNy8zERlgKxNVpvFaHhEDmPzxGD+Avhbdp0DUMzF4DpKyHAtd+KWvfw9qGDg IiTOKwnk06VERLE3Rpu8GniA5mYP1LZFWI7SdgNOCBg7fUD9mZrB9zEpkd+vNquL7juz i1fg== X-Gm-Message-State: APjAAAXOBPXysmWis0WsbQld/UEq0IzCjGu1A2F0jbnJWsfOyuoQNwkC g4YmPyXDVznWLXmVjWJtx0ocEwK2zSheefzJhr7sVOpTAFRvLbEghL1DEwjs5DX1J8zIR4SVXSi vUpjAmB0/B9EVAbXMMlgPaHKKWRRS/u2ri7q5/yTpQHfUFR398sEcUtSg X-Google-Smtp-Source: APXvYqxJvtl0v/Wnxc16fK4TQKZ5o7f+w2tdL3R0x1MixW7pZvhz7L+jvjYNpfCUt3mGcKN1C69h0Q== X-Received: by 2002:a65:6205:: with SMTP id d5mr19562568pgv.61.1554584754528; Sat, 06 Apr 2019 14:05:54 -0700 (PDT) Received: from ?IPv6:2600:380:4570:405e:11b2:14de:663e:3529? ([2600:380:4570:405e:11b2:14de:663e:3529]) by smtp.gmail.com with ESMTPSA id h1sm13430876pgs.67.2019.04.06.14.05.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 06 Apr 2019 14:05:53 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Jai Kumar X-Mailer: iPhone Mail (16C104) In-Reply-To: Date: Sat, 6 Apr 2019 14:05:52 -0700 Cc: "Pengshuping (Peng Shuping)" , 6man , ippm , "C. M. Heard" , Mikael Abrahamsson Content-Transfer-Encoding: quoted-printable Message-Id: <0B28F885-A556-4E1A-ABE5-42E5B078D257@broadcom.com> References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> <4278D47A901B3041A737953BAA078ADE1478D5E2@DGGEML532-MBX.china.huawei.com> <4278D47A901B3041A737953BAA078ADE1478EC8B@DGGEML532-MBX.china.huawei.com> <14A3D5C9-1EED-4E11-9329-B62B819271A2@broadcom.com> <20D6FCDB-3357-4728-BD52-8069C32F3CCA@broadcom.com> <57A32C37-AAE9-44F2-9C96-39AFA71BDC21@broadcom.com> <36B9204A-D1EE-4067-92BB-6C33CB2DF791@broadcom.com> <6E177A89-8488-4E24-A37A-B4C14D8ACB0D@broadcom.com> To: Tom Herbert Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 21:06:01 -0000 Tom, We are talking about nexthop I.e. packet forwarding not member link selectio= n in load balancing. Basic packet forwarding is broken with options. -Jai > On Apr 6, 2019, at 12:55 PM, Tom Herbert wrote: >=20 >> On Sat, Apr 6, 2019 at 9:41 AM Jai Kumar wrote: >>=20 >> Tom, >>=20 >> Please read the IOAM draft again. There is a variable length metadata sta= ck as well with trace option. Forwarding becomes completely indeterministic.= >=20 > Jai, >=20 > Use the flow label and addresses as input to ECMP forwarding _is_ > deterministic. And not just for deterministic for TCP or UDP, but for > _any_ protocol, combination of EH, encryptions, etc. that a packet > carries. See RFC6438. >=20 >> In short using options forwarding gets impacted for EH. You still want to= push for it go by all means but don't expect a silicon vendor or deployment= to agree for it. >=20 > I'm not sure what we're trying to get agreement on. The only > expectation we have is that vendors, and everyone else for that > matter, conform to IETF standards. Extension headers have be defined > for over twenty years and are full standard, and now that people want > to use them there appears to be _some_ implementations (emphasis on > the word "some") that seem to have a problem processing them. Frankly, > that is a shortcoming of implementation, not of the protocol. The only > protocol shortcoming that has thus far been identified in the IOAM > discussion is the fact that EH don't exist in IPv4 and there is really > no alternative that provides the necessary functionality-- this is > something I believe IETF can work on. >=20 > Tom >=20 >>=20 >> -Jai >>=20 >> =EF=BB=BFOn 4/5/19, 5:05 PM, "Tom Herbert" wrote: >>=20 >>> On Fri, Apr 5, 2019 at 4:40 PM Jai Kumar wro= te: >>>=20 >>> Tom, >>>=20 >>>=20 >>>=20 >>> You are right. There are two main cases where accessibility of transport= header becomes an issue. And that is mainly because of current generation o= f fixed pipeline cell based architecture parse depth (not so much an issue f= or high end NPU where next packet header bytes can be DMA=E2=80=99ed in, tho= ugh it impacts the performance. For eg. Cisco QFP NPU, EZ Chip, Juniper=E2=80= =99s MX 3D NPU, or Broadcom=E2=80=99s Jerricho NPU ). This was mentioned ear= lier by Mikael as well. >>>=20 >>>=20 >>>=20 >>> Case 1. SRv6 >>>=20 >>> Case 2. IPv6 with EH (mainly for 5G deployments where RH, DH, and IFA He= ader) >>>=20 >>>=20 >>>=20 >>> Typically NPUs provide capability that it will handle 3 or 4 EH or SRH w= ithout performance penalty. With the presence of IFA header this means that f= or eg there can be only 2 or 3 SRH or EH. This is same as in MPLS label stac= k depth handling (PUSH or POP at PE router). Given the evolution SRV6 and MP= LS-SR kind of headers, silicon vendors have taken a notice of it and are evo= lving the silicon arch to handle more chained headers. >>>=20 >>>=20 >>>=20 >>> IFA supports fragmentation of metadata stack and also postcard mode so b= eyond the transport header it=E2=80=99s not an issue. >>>=20 >>>=20 >>>=20 >>> Just a quick feedback on using IPv6 options, inserting hop by hop option= s for data path processing pushes the EH further down and impacts the node=E2= =80=99s forwarding function (say if it is not able to reach Destination EH) v= s if IFA header is the last EH then atmost transit node do not perform metad= ata collection which can be identified. >>=20 >> Maybe it does impact it, maybe it doesn't. It clearly depends on the >> device capabilities. For a device with a parsing buffer of 256 bytes >> that should be plenty of room for HBH options, SR header, transport >> layer, etc. >>=20 >>>=20 >>>=20 >>>=20 >>> -Jai >>>=20 >>>=20 >>>=20 >>> From: Tom Herbert >>> Date: Friday, April 5, 2019 at 3:34 PM >>> To: Jai Kumar >>> Cc: "Pengshuping (Peng Shuping)" , 6man , ippm , "C. M. Heard" , Mikael Abrah= amsson >>> Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 fee= dback (Re: v6 option types for IOAM data fields) >>>=20 >>>=20 >>>=20 >>> Jai, >>>=20 >>>=20 >>>=20 >>> You might want to consider how IFA works in the presence of segment rout= ing. The second someone puts an SRH in the packet the IFA headers get pushed= down and the transport headers end up being deep in the packet anyway so th= at all the effort of IFA is nullified. If the requirement is to ensure that t= he transport layer information appear as early as possible in the packet, on= e could define a Hop-by-Hop option to carry some sort of pseudo header for t= he transport layer. This also would work in the case that the actual transpo= rt layer is obfuscated. >>>=20 >>>=20 >>>=20 >>> Tom >>>=20 >>>=20 >>>=20 >>> On Fri, Apr 5, 2019, 3:09 PM Jai Kumar wrote: >>>=20 >>> =E2=80=9CThat is going to require justifying the protocol even in light o= f shortcomings in existing protocoIs.=E2=80=9D >>>=20 >>>=20 >>>=20 >>> Agreed !!! True for any proposal. >>>=20 >>>=20 >>>=20 >>> -Jai >>>=20 >>>=20 >>>=20 >>> From: Tom Herbert >>> Date: Friday, April 5, 2019 at 2:34 PM >>> To: Jai Kumar >>> Cc: "Pengshuping (Peng Shuping)" , 6man , ippm , "C. M. Heard" , Mikael Abrah= amsson >>> Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 fee= dback (Re: v6 option types for IOAM data fields) >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> On Fri, Apr 5, 2019, 2:07 PM Jai Kumar wrote: >>>=20 >>> Tom, >>>=20 >>> Its all explained in the requirements section of the draft. IFA header i= s essentially treated as an EH both in IPv4 and IPv6 (very similar to AH/ESP= EH). >>>=20 >>> Just like in AH/ESP the IP protocol is copied in the AH header and IP pr= otocol field is replaced in the IP header with the AH proto. >>>=20 >>> There are several advantages to this approach. >>> - devise know how to parse AH header and can follow very similar approac= h >>> - Protocol agnostics, silicon need not support N encaps (just like AH/ES= P). Single implementation works for all protocol types. >>> - No need to creation options and teach devices that options is NOT an e= xception path processing >>> - Really worry about ordering in IPv6 options >>> - Note that all the OAM data need to be deleted as well so position need= to be optimal for removal. We can always do tail stamping of the data but t= his puts considerable constrains on the cell based architecture >>> - L4 accessibility I have already mentioned >>>=20 >>> I am happy to discuss with you in person and explain more but bottom lin= e is that this proposal is what came out with MSDC discussions in light of s= hortcomings from other IETF proposals. >>>=20 >>>=20 >>>=20 >>> As they say, you are free to run whatever you want in your proprietary n= etwork, but if you expect to create an interoperable, deployable protocoI an= d get a protocol number assignment, you'll need to work in ietf. That is goi= ng to require justifying the protocol even in light of shortcomings in exist= ing protocoIs. >>>=20 >>>=20 >>>=20 >>> Tom >>>=20 >>>=20 >>>=20 >>>=20 >>> Regards, >>> -Jai >>>=20 >>>=20 >>> =EF=BB=BFOn 4/5/19, 12:28 PM, "Tom Herbert" wrote:= >>>=20 >>>> On Fri, Apr 5, 2019 at 12:03 PM Jai Kumar w= rote: >>>>=20 >>>> " Great, but this IETF" >>>> Does it mean that drafts have no relevance to deployment and actual ado= ption. >>>>=20 >>>> For all your queries please take a look at IFA draft. >>>> https://datatracker.ietf.org/doc/draft-kumar-ippm-ifa/ >>>>=20 >>> I've looked at that draft. It's is creating a complete new IP >>> protocolas well as a new packet format for TCP and UDP that somehow >>> inserts meta data between the TCP header and payload. I don't >>> understand why this could possibly be better than just using flow >>> label for ECMP and teaching devices that need to extract transport >>> information how to walk over EH, or just using some UDP encpasulation= >>> like in draft-herbert-ipv4-udpencap-eh-01. >>>=20 >>> Tom >>>=20 >>>> It handles IPv6, IPv4 TCP/UDP with altering the packet path (due to ins= erting options and/or encaping them in GRE header) as well as IPSec AH/ESP/W= ESP both tunnel and transport and guess what it is successfully deployed. >>>>=20 >>>> -Jai >>>>=20 >>>> =EF=BB=BFOn 4/5/19, 11:54 AM, "Tom Herbert" wrote= : >>>>=20 >>>>> On Fri, Apr 5, 2019 at 11:25 AM Jai Kumar w= rote: >>>>>=20 >>>>> Tom, >>>>>=20 >>>>> I am speaking based on the actual deployment not based on if all the t= raffic is/will move to IPSec tunnel. >>>>>=20 >>>>> I have 6 large customer deployments and one someone previously called a= s "Yahoo" who insist on visibility in L4 even for IOAM packets. >>>>>=20 >>>> And I've worked in datcenters much larger, and my first rule is that= I >>>> don't want random router vendors dictating to me what protocols I'm >>>> allowed to use in my datacenter. >>>>=20 >>>>> I can quote you on that and lose my business :-) >>>>>=20 >>>>> ECMP argument is weak as well as it works for IPv6 flow label. What ab= out IPv4 TCP/UDP traffic which typically is 80% of the traffic in MSDC. >>>>>=20 >>>>=20 >>>> draft-herbert-ipv4-udpencap-eh-01 >>>>=20 >>>>> If someone tells me that proposal will work only for my 20% of traffic= then again as I said before, they will lose my business :-) >>>>>=20 >>>> Great, but this IETF. Where are the protocol requirements? If you ar= e >>>> saying that there are requirements for "visibility in L4" what are >>>> they? If you are saying that ACLs are now required for packet >>>> forwarding, where is that described? Is it a MUST that teh only >>>> transport protocols we're allowed to use are UDP or TCP? Are we >>>> allowed to use extension headers at all? I suppose fragmentation is >>>> right out... Are we violating the requirements if we encrypt the >>>> transport headers? If you say that we shouldn't send long headers >>>> because we'll overflow parsing buffers, then what is the limit? Plea= se >>>> be SPECIFC in setting requirements; we are trying to build protocols= >>>> that work and are interoperable and we need to get out of this moras= s >>>> of reverse engineering to discover the least common denominator. >>>>=20 >>>> Tom >>>>=20 >>>>> Regards, >>>>> -Jai >>>>>=20 >>>>> =EF=BB=BFOn 4/5/19, 11:15 AM, "Tom Herbert" wrot= e: >>>>>=20 >>>>>> On Fri, Apr 5, 2019 at 10:55 AM Jai Kumar = wrote: >>>>>>=20 >>>>>> Even if we use flow label for ECMP, lack of accessibility of L4 infor= mation (for various services, most simple is ACL) makes the proposal pretty m= uch unusable. >>>>>>=20 >>>>> That is convoluting router and firewall functionality and >>>>> requirements. This a discussion about packet forwarding which does >>>>> _not_ require ACLs. In a limited domain, for which IOAM is intended= , >>>>> it is unlikely that they'll ACLs would be used in internal nodes, b= ut >>>>> we do need good ECMP routing at all intermediate nodes need to be >>>>> consistent rather or not that the IOAM option is present. As side >>>>> note, the ability to extract L4 information out of packets is >>>>> dwindling anyway thanks to encryption and other techniques trying t= o >>>>> undo protocol ossification. For instance, good luck getting L4 >>>>> information out of an IPsec tunnel :-). >>>>>=20 >>>>> Tom >>>>>=20 >>>>>> NIC cards are not used pervasively for ACLs and other services, I bel= ieve iptables in kernel are good enough for host but that=E2=80=99s not acce= ptable in networking elements. >>>>>>=20 >>>>>> -Jai >>>>>>=20 >>>>>> =EF=BB=BFOn 4/5/19, 10:31 AM, "ippm on behalf of Tom Herbert" wrote: >>>>>>=20 >>>>>> On Fri, Apr 5, 2019 at 9:16 AM Pengshuping (Peng Shuping) >>>>>> wrote: >>>>>>>=20 >>>>>>> Hi Barak, >>>>>>>=20 >>>>>>> We are certainly not designing for the lowest capable solutions but e= xploring optimal solutions which could help to keep the forwarding performan= ce while inserting the iOAM data with variable length. >>>>>>=20 >>>>>> Shuping, >>>>>>=20 >>>>>> That's exactly the argument for using the flow label in ECMP. >>>>>> Efficeint packet forwarding can be done solely by inspected the fo= rty >>>>>> byte fixed length header of the packet regardless of the contents o= f >>>>>> the rest of the packet. That is an optimal solution. Anything else= for >>>>>> ECMP like doing DPI or hacking up IOAM to try do pull transport la= yers >>>>>> into the parsing buffer (whatever size that may be) are nothing mo= re >>>>>> than hacks and unnecessarily perpetuate techniques used with IPv4 t= hat >>>>>> either don't work or are unnecessary in IPv6. >>>>>>=20 >>>>>> Tom >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> In terms of the forwarding efficiency, we would all agree that a sho= rt and fixed header would be better than a variable header. >>>>>>>=20 >>>>>>> Best regards >>>>>>> Shuping >>>>>>>=20 >>>>>>>=20 >>>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Barak Gafni >>>>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Pengshuping (Peng Shuping);Frank Brockners (fbrockne);Mikael Ab= rahamsson >>>>>>> =E6=8A=84=E9=80=81=EF=BC=9A C. M. Heard;6man WG;Mark Smith;ippm >>>>>>> =E4=B8=BB=E9=A2=98=EF=BC=9A RE: draft-ioametal-ippm-6man-ioam-ipv6-d= eployment-00 feedback (Re: v6 option types for IOAM data fields) >>>>>>> =E6=97=B6=E9=97=B4=EF=BC=9A 2019-04-05 03:18:26 >>>>>>>=20 >>>>>>> Hi Shuping, >>>>>>> I think that the question is whether we design for the lowest capabl= e solutions. I assume someone can find solutions with even lower amount of p= arsing.. The low end solutions for these capabilities may need to either ado= pt with new designs or use solutions such as what is suggested in this threa= d by Tom Herbert. >>>>>>> Personally, I don't think we should go this way, but to design appro= priate solutions, with appropriate layers in the headers. For example, preve= nt dependencies between "remote" headers. >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Barak >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: ippm On Behalf Of Pengshuping (Peng Sh= uping) >>>>>>> Sent: Wednesday, April 3, 2019 6:47 AM >>>>>>> To: Frank Brockners (fbrockne) ; Mikael Abrahams= son >>>>>>> Cc: C. M. Heard ; 6man WG ; Mark Smi= th ; ippm@ietf.org >>>>>>> Subject: [ippm] =E7=AD=94=E5=A4=8D: draft-ioametal-ippm-6man-ioam-ip= v6-deployment-00 feedback (Re: v6 option types for IOAM data fields) >>>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> The parsing depth of the early chips is 96B/128B. For the new chips t= he parsing depth has been increased but still limited. So Mikael's concern m= akes sense especially in the tracing mode that the IOAM data fields are goin= g to increase significantly along the path, which will even push the Routing= Header out of the parsing depth of the chip. So it would make sense to spli= t the IOAM data part from the IOAM header/instruction part, and place the IO= AM data after the RH or even after the L4 header in order to be able to read= the L4 information to enable ECMP, as stated in the draft https://eur03.saf= elinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtml%2Fd= raft-li-6man-ipv6-sfc-ifit-00&data=3D02%7C01%7Cgbarak%40mellanox.com%7C6= 12ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7= C636898960379485833&sdata=3DDob4zN%2F1jSGxLTlqGma29JJNvqJDBt4VzqHsN4OpxM= 4%3D&reserved=3D0. >>>>>>>=20 >>>>>>> BR, >>>>>>> Shuping >>>>>>>=20 >>>>>>>=20 >>>>>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- >>>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: ippm [mailto:ippm-bounces@ietf.org] =E4= =BB=A3=E8=A1=A8 Frank Brockners (fbrockne) >>>>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B44=E6=9C=882=E6=97= =A5 17:40 >>>>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Mikael Abrahamsson >>>>>>> =E6=8A=84=E9=80=81: C. M. Heard ; 6man WG ; Mark Smith ; ippm@ietf.org >>>>>>> =E4=B8=BB=E9=A2=98: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-de= ployment-00 feedback (Re: v6 option types for IOAM data fields) >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> -----Original Message----- >>>>>>> From: Mikael Abrahamsson >>>>>>> Sent: Dienstag, 2. April 2019 08:06 >>>>>>> To: Frank Brockners (fbrockne) >>>>>>> Cc: Mark Smith ; C. M. Heard ; 6man WG ; ippm@ietf.org >>>>>>> Subject: RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedba= ck (Re: v6 option types for IOAM data fields) >>>>>>>=20 >>>>>>>> On Mon, 1 Apr 2019, Frank Brockners (fbrockne) wrote: >>>>>>>>=20 >>>>>>>> ...FB: There is obviously no easy answer. Couple of thoughts: >>>>>>>> * IOAM is considered a "domain specific" feature (see >>>>>>>> draft-ietf-ippm-ioam-data-05, section 3). Routers in the IOAM domai= n >>>>>>>> should be IOAM capable. And IMHO, we should add a statement to >>>>>>>> draft-ioametal-ippm-6man-ioam-ipv6-deployment that an implementatio= n >>>>>>>> of IOAM MUST ensure "C1". >>>>>>>>=20 >>>>>>>> * That said, there can be situations, where C1 cannot be achieved, e= .g.. >>>>>>>> consider a network which does ECMP scheduling based on packet lengt= h. >>>>>>>>=20 >>>>>>>> * What one could consider - and which is one suggested deployment >>>>>>>> model >>>>>>>> - is that by default IOAM data fields are added to _all_ customer >>>>>>>> packets. The decapsulating node would decide whether the IOAM >>>>>>>> information contained in a packet would be used (and exported) or n= ot. >>>>>>>> That way one would not need to deal with the situation that some >>>>>>>> traffic carries IOAM while other does not - and might thus be treat= ed >>>>>>>> differently. >>>>>>>=20 >>>>>>> Yes, I think this is the only way. Is there a risk that intermediate= routers would not be IOAM capable? I think the C1 requirement is really rea= lly hard to fulfil and I'm also afraid that adding the IOAM header will actu= ally make ECMP stop working on some platforms (because they would not have t= he capability to look deep enough into the packet to find L4 information, so= it'll go back to 2 tuple ECMP instead of 5 tuple. >>>>>>>=20 >>>>>>> But this question can only be answered by people with deep NPU knowl= edge... >>>>>>>=20 >>>>>>> .....FB2: Given that IOAM is a domain specific feature - I expect th= at folks initially start to use it in domains (like e.g. a DC) where all box= es are IOAM capable and can trace the packet appropriately - or per Tom's no= te, can be configured so that one would do ECMP based on addresses and flow-= label. There are chips with pretty deep parsing capability (up to a few hun= dred bytes). >>>>>>>=20 >>>>>>>> ...FB: The comparison to MPLS is interesting. How often do MPLS >>>>>>>> packets leak and cause harm? For IOAM, >>>>>>>> draft-ioametal-ippm-6man-ioam-ipv6-options-02 proposes a deployment= >>>>>>>> model similar to what we do for MPLS: Unless an interface is >>>>>>>> explicitly configured for IOAM, packets with IOAM data fields MUST b= e dropped. >>>>>>>> Hence leakage would only occur, if we have a clearly misbehaving >>>>>>>> router which violates this rule. Similar to you, I'd also greatly >>>>>>>> appreciate any pointers to research on how common MPLS leaked packe= ts are. >>>>>>>=20 >>>>>>> When it comes to "cause harm" I imagine there are (at least) two way= s to cause harm, one is privacy/secrecy/security loss and the other one is a= ctual operational loss. >>>>>>>=20 >>>>>>> I know of bugs where labeled packets went the wrong way and caused t= hem to be lost, I've also seen bugs where bugs caused traffic to "hop" betwe= en VRFs in MPLS VPN (or to "global" VRF). I don't have numbers on this thoug= h. >>>>>>>=20 >>>>>>> Depending on the deployment scenario, it might make sense to make IO= AM packets not valid for non-IOAM aware devices (basically encap entire pack= et/payload), but that might be a problem for intermediate non-IOAM nodes the= n. This would affect the ECMP requirement. I can see cases where one would o= perationally turn on IOAM for some customers traffic and then see the proble= m go away because now ECMP changed. >>>>>>>=20 >>>>>>>> ...FB: One idea that Shwetha came up with to identify the source AS= of >>>>>>>> a leaked packet, would be to add a new new IOAM E2E option - as >>>>>>>> proposed in section 5.1.1 bullet 2 of >>>>>>>> draft-ioametal-ippm-6man-ioam-ipv6-deployment-01. >>>>>>>=20 >>>>>>> Yes, that'd solve that problem. >>>>>>>=20 >>>>>>> How much has the silicon people been involved so far in the design o= f the headers? What is the current thinking of amount of data going into the= IOAM header? Considering things like trace options etc it seems to me the h= eader can grow quite large? To satisfy the ECMP requirement what about putti= ng the IOAM information as a trailer behind the regular payload? Or is there= a problem for the hw to manipulate information that far into the packet (I a= lso imagine this will considerably lower the forwarding performance of IOAM p= ackets on IOAM aware platforms). >>>>>>>=20 >>>>>>> .....FB2: There are quite a few folks with hardware background that c= o-author the IOAM drafts. Parsing capability differs between chips, as does t= he ability to deal with new/flexible headers and the ability to modify data i= n the extension headers. So the unfortunate answer to that question is "it d= epends" (what information do you gather, how large is your domain, what are t= he capabilities of your hardware/software forwarder, etc.), but I do expect t= hat for specific deployment domains (e.g. DC, Enterprise) - but also for ove= rlay networks / VPNs - we'll see an increasing amount of chips that are well= suited for processing large extension header. >>>>>>>=20 >>>>>>> Cheers, Frank >>>>>>>=20 >>>>>>> -- >>>>>>> Mikael Abrahamsson email: swmike@swm.pp.se >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> ippm mailing list >>>>>>> ippm@ietf.org >>>>>>> https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= ww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cgbarak%40mellan= ox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b= %7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef3BJFz6AQNNAt= kgmAMDFKM%3D&reserved=3D0 >>>>>>> _______________________________________________ >>>>>>> ippm mailing list >>>>>>> ippm@ietf.org >>>>>>> https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fw= ww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cgbarak%40mellan= ox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b= %7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef3BJFz6AQNNAt= kgmAMDFKM%3D&reserved=3D0 >>>>>>> --------------------------------------------------------------------= >>>>>>> IETF IPv6 working group mailing list >>>>>>> ipv6@ietf.org >>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>> --------------------------------------------------------------------= >>>>>>=20 >>>>>> _______________________________________________ >>>>>> ippm mailing list >>>>>> ippm@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/ippm >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >>=20 From nobody Sat Apr 6 15:36:44 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F1F120175; Sat, 6 Apr 2019 15:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 DERmhTo7nndu; Sat, 6 Apr 2019 15:36:30 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F8D6120165; Sat, 6 Apr 2019 15:36:30 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id d24so8766687otl.11; Sat, 06 Apr 2019 15:36:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZpXXc2aAZ4dEKTjyj3k5/1uHizm/ixT4VLyEKlseOf8=; b=osiVJRQVK7HRcfqHKyWPUxmFNqtItVsZrRlbwgyqdn5E7jmMgEyPnk9qktiF+oVKtc JyEnPRYfw2szClY3p1R7Sxda8V6sB35UAuvtOApOMFBx3WTbswwLHmBhRLxxJnOutBZP dUcFn9porJp5z/bFICYvmCWtXMFszOPn6/Jqn0+0pH0kjY23V2qzHPFzVHLXU89ckhTw oaYz6BAHPsFWiC3CFE7RKwaeHu0LGWEei09QkiIk+RXVkfWgI+Fa6AlFE9TxCetsHfLk yLzJzdwzda4ReO4FEymEJZN/+S3+sun4RqVaPDWk7dOdMEwA0bsBU5LCs8JuSjeXceQ5 ebBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZpXXc2aAZ4dEKTjyj3k5/1uHizm/ixT4VLyEKlseOf8=; b=Y+g4wZJLV4Qb4pQgjRxYb2fOm+mhGZkFYOMnZROJj3ZeK/k0DTCVCS4ngkysHfKFIt wKkjZK3CitjkiPkZEZGLiOlaVh2MGLuFrpIzMxoKw2+E6prsxHNpc2auPqO9Yx66s2c8 OaK01z+W24B97zbQoK227WWugqy8S06uYVbHuQWJCl9Qs9Sp8dCV2gDYcw5LFzX/o6V1 CYeSeCKRfc2mxZU9+J//C/UBgVIHcb5bj2esn9RzfA+qMzykA99P5Rqvbg+VVTa5EZJ3 x2+epAgVe/QFSDVgor1RzwgwEDCnLom6XQHlI3xrlUM3cqqmn7KpT5+1+hLMB/Vbyckd LDKw== X-Gm-Message-State: APjAAAXomdRQDnTGSc0RY2qT1W6q2ifcz5RYLZkeaJvoHOCm1wmKGTbo iphnqte4jwlMkOInTUZhscVYqbXUIyddna+FUrQ= X-Google-Smtp-Source: APXvYqwgmBiTdV1Efju+TJVyBaOsE8VMpugJYpFAQLclu9zygPpanXBCwpjPmG9FS6RAhTgVn+z59NUjZcQF0sMHVD4= X-Received: by 2002:a9d:7ad9:: with SMTP id m25mr14560773otn.75.1554590189242; Sat, 06 Apr 2019 15:36:29 -0700 (PDT) MIME-Version: 1.0 References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> <4278D47A901B3041A737953BAA078ADE1478D5E2@DGGEML532-MBX.china.huawei.com> <4278D47A901B3041A737953BAA078ADE1478EC8B@DGGEML532-MBX.china.huawei.com> <14A3D5C9-1EED-4E11-9329-B62B819271A2@broadcom.com> <20D6FCDB-3357-4728-BD52-8069C32F3CCA@broadcom.com> <57A32C37-AAE9-44F2-9C96-39AFA71BDC21@broadcom.com> <36B9204A-D1EE-4067-92BB-6C33CB2DF791@broadcom.com> <6E177A89-8488-4E24-A37A-B4C14D8ACB0D@broadcom.com> <0B28F885-A556-4E1A-ABE5-42E5B078D257@broadcom.com> In-Reply-To: <0B28F885-A556-4E1A-ABE5-42E5B078D257@broadcom.com> From: Mark Smith Date: Sun, 7 Apr 2019 08:36:02 +1000 Message-ID: To: Jai Kumar Cc: Tom Herbert , "C. M. Heard" , 6man , ippm Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 22:36:33 -0000 On Sun, 7 Apr 2019 at 07:06, Jai Kumar wrote: > > Tom, > > We are talking about nexthop I.e. packet forwarding not member link selec= tion in load balancing. > Basic packet forwarding is broken with options. > If I understand this statement correctly, it isn't basic forwarding if options other than the Hop-by-Hop option is considered. IPv6 forwarding is designed to only use the fields in the fixed IPv6 header (with one exception) - that is why those fields are not optional. The only IPv6 option/EH that can be used in forwarding is the Hop-by-Hop option, and it is required to be directly after the IPv6 fixed header. Any other IPv6 options/EH are not designed nor intended to be used in IPv6 forwarding. Perhaps one thing people suggesting things to this Working Group can forget is that our protocol is more than two decades old and that we have a very large installed base of devices that support it and that are being used constantly (this email is coming over IPv6). So we can't just make arbitrary changes to the protocol to suit new requirements, unlike greenfield IETF Working Groups with no or a very limited installed base can. We have to try our hardest to accommodate those new requirements within the specifications and within existing deployments. So if a new method of doing something is proposed, we here are going to be looking to see how it can be done using existing, proven and well-known methods first (e.g, adding supplementary information to packets via IPv6-in-IPv6 encapsulation, ECMP via Flow Label rather than digging up the UDP/TCP headers.) Regards, Mark. > -Jai > > > On Apr 6, 2019, at 12:55 PM, Tom Herbert wrote: > > > >> On Sat, Apr 6, 2019 at 9:41 AM Jai Kumar wrot= e: > >> > >> Tom, > >> > >> Please read the IOAM draft again. There is a variable length metadata = stack as well with trace option. Forwarding becomes completely indeterminis= tic. > > > > Jai, > > > > Use the flow label and addresses as input to ECMP forwarding _is_ > > deterministic. And not just for deterministic for TCP or UDP, but for > > _any_ protocol, combination of EH, encryptions, etc. that a packet > > carries. See RFC6438. > > > >> In short using options forwarding gets impacted for EH. You still want= to push for it go by all means but don't expect a silicon vendor or deploy= ment to agree for it. > > > > I'm not sure what we're trying to get agreement on. The only > > expectation we have is that vendors, and everyone else for that > > matter, conform to IETF standards. Extension headers have be defined > > for over twenty years and are full standard, and now that people want > > to use them there appears to be _some_ implementations (emphasis on > > the word "some") that seem to have a problem processing them. Frankly, > > that is a shortcoming of implementation, not of the protocol. The only > > protocol shortcoming that has thus far been identified in the IOAM > > discussion is the fact that EH don't exist in IPv4 and there is really > > no alternative that provides the necessary functionality-- this is > > something I believe IETF can work on. > > > > Tom > > > >> > >> -Jai > >> > >> =EF=BB=BFOn 4/5/19, 5:05 PM, "Tom Herbert" wrote= : > >> > >>> On Fri, Apr 5, 2019 at 4:40 PM Jai Kumar = wrote: > >>> > >>> Tom, > >>> > >>> > >>> > >>> You are right. There are two main cases where accessibility of transp= ort header becomes an issue. And that is mainly because of current generati= on of fixed pipeline cell based architecture parse depth (not so much an is= sue for high end NPU where next packet header bytes can be DMA=E2=80=99ed i= n, though it impacts the performance. For eg. Cisco QFP NPU, EZ Chip, Junip= er=E2=80=99s MX 3D NPU, or Broadcom=E2=80=99s Jerricho NPU ). This was ment= ioned earlier by Mikael as well. > >>> > >>> > >>> > >>> Case 1. SRv6 > >>> > >>> Case 2. IPv6 with EH (mainly for 5G deployments where RH, DH, and IFA= Header) > >>> > >>> > >>> > >>> Typically NPUs provide capability that it will handle 3 or 4 EH or SR= H without performance penalty. With the presence of IFA header this means t= hat for eg there can be only 2 or 3 SRH or EH. This is same as in MPLS labe= l stack depth handling (PUSH or POP at PE router). Given the evolution SRV6= and MPLS-SR kind of headers, silicon vendors have taken a notice of it and= are evolving the silicon arch to handle more chained headers. > >>> > >>> > >>> > >>> IFA supports fragmentation of metadata stack and also postcard mode s= o beyond the transport header it=E2=80=99s not an issue. > >>> > >>> > >>> > >>> Just a quick feedback on using IPv6 options, inserting hop by hop opt= ions for data path processing pushes the EH further down and impacts the no= de=E2=80=99s forwarding function (say if it is not able to reach Destinatio= n EH) vs if IFA header is the last EH then atmost transit node do not perfo= rm metadata collection which can be identified. > >> > >> Maybe it does impact it, maybe it doesn't. It clearly depends on th= e > >> device capabilities. For a device with a parsing buffer of 256 byte= s > >> that should be plenty of room for HBH options, SR header, transport > >> layer, etc. > >> > >>> > >>> > >>> > >>> -Jai > >>> > >>> > >>> > >>> From: Tom Herbert > >>> Date: Friday, April 5, 2019 at 3:34 PM > >>> To: Jai Kumar > >>> Cc: "Pengshuping (Peng Shuping)" , 6man , ippm , "C. M. Heard" , Mikael A= brahamsson > >>> Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 = feedback (Re: v6 option types for IOAM data fields) > >>> > >>> > >>> > >>> Jai, > >>> > >>> > >>> > >>> You might want to consider how IFA works in the presence of segment r= outing. The second someone puts an SRH in the packet the IFA headers get pu= shed down and the transport headers end up being deep in the packet anyway = so that all the effort of IFA is nullified. If the requirement is to ensure= that the transport layer information appear as early as possible in the pa= cket, one could define a Hop-by-Hop option to carry some sort of pseudo hea= der for the transport layer. This also would work in the case that the actu= al transport layer is obfuscated. > >>> > >>> > >>> > >>> Tom > >>> > >>> > >>> > >>> On Fri, Apr 5, 2019, 3:09 PM Jai Kumar wrote= : > >>> > >>> =E2=80=9CThat is going to require justifying the protocol even in lig= ht of shortcomings in existing protocoIs.=E2=80=9D > >>> > >>> > >>> > >>> Agreed !!! True for any proposal. > >>> > >>> > >>> > >>> -Jai > >>> > >>> > >>> > >>> From: Tom Herbert > >>> Date: Friday, April 5, 2019 at 2:34 PM > >>> To: Jai Kumar > >>> Cc: "Pengshuping (Peng Shuping)" , 6man , ippm , "C. M. Heard" , Mikael A= brahamsson > >>> Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 = feedback (Re: v6 option types for IOAM data fields) > >>> > >>> > >>> > >>> > >>> > >>> On Fri, Apr 5, 2019, 2:07 PM Jai Kumar wrote= : > >>> > >>> Tom, > >>> > >>> Its all explained in the requirements section of the draft. IFA heade= r is essentially treated as an EH both in IPv4 and IPv6 (very similar to AH= /ESP EH). > >>> > >>> Just like in AH/ESP the IP protocol is copied in the AH header and IP= protocol field is replaced in the IP header with the AH proto. > >>> > >>> There are several advantages to this approach. > >>> - devise know how to parse AH header and can follow very similar appr= oach > >>> - Protocol agnostics, silicon need not support N encaps (just like AH= /ESP). Single implementation works for all protocol types. > >>> - No need to creation options and teach devices that options is NOT a= n exception path processing > >>> - Really worry about ordering in IPv6 options > >>> - Note that all the OAM data need to be deleted as well so position n= eed to be optimal for removal. We can always do tail stamping of the data b= ut this puts considerable constrains on the cell based architecture > >>> - L4 accessibility I have already mentioned > >>> > >>> I am happy to discuss with you in person and explain more but bottom = line is that this proposal is what came out with MSDC discussions in light = of shortcomings from other IETF proposals. > >>> > >>> > >>> > >>> As they say, you are free to run whatever you want in your proprietar= y network, but if you expect to create an interoperable, deployable protoco= I and get a protocol number assignment, you'll need to work in ietf. That i= s going to require justifying the protocol even in light of shortcomings in= existing protocoIs. > >>> > >>> > >>> > >>> Tom > >>> > >>> > >>> > >>> > >>> Regards, > >>> -Jai > >>> > >>> > >>> =EF=BB=BFOn 4/5/19, 12:28 PM, "Tom Herbert" wro= te: > >>> > >>>> On Fri, Apr 5, 2019 at 12:03 PM Jai Kumar wrote: > >>>> > >>>> " Great, but this IETF" > >>>> Does it mean that drafts have no relevance to deployment and actual = adoption. > >>>> > >>>> For all your queries please take a look at IFA draft. > >>>> https://datatracker.ietf.org/doc/draft-kumar-ippm-ifa/ > >>>> > >>> I've looked at that draft. It's is creating a complete new IP > >>> protocolas well as a new packet format for TCP and UDP that someho= w > >>> inserts meta data between the TCP header and payload. I don't > >>> understand why this could possibly be better than just using flow > >>> label for ECMP and teaching devices that need to extract transport > >>> information how to walk over EH, or just using some UDP encpasulat= ion > >>> like in draft-herbert-ipv4-udpencap-eh-01. > >>> > >>> Tom > >>> > >>>> It handles IPv6, IPv4 TCP/UDP with altering the packet path (due to = inserting options and/or encaping them in GRE header) as well as IPSec AH/E= SP/WESP both tunnel and transport and guess what it is successfully deploye= d. > >>>> > >>>> -Jai > >>>> > >>>> =EF=BB=BFOn 4/5/19, 11:54 AM, "Tom Herbert" wr= ote: > >>>> > >>>>> On Fri, Apr 5, 2019 at 11:25 AM Jai Kumar wrote: > >>>>> > >>>>> Tom, > >>>>> > >>>>> I am speaking based on the actual deployment not based on if all th= e traffic is/will move to IPSec tunnel. > >>>>> > >>>>> I have 6 large customer deployments and one someone previously call= ed as "Yahoo" who insist on visibility in L4 even for IOAM packets. > >>>>> > >>>> And I've worked in datcenters much larger, and my first rule is t= hat I > >>>> don't want random router vendors dictating to me what protocols I= 'm > >>>> allowed to use in my datacenter. > >>>> > >>>>> I can quote you on that and lose my business :-) > >>>>> > >>>>> ECMP argument is weak as well as it works for IPv6 flow label. What= about IPv4 TCP/UDP traffic which typically is 80% of the traffic in MSDC. > >>>>> > >>>> > >>>> draft-herbert-ipv4-udpencap-eh-01 > >>>> > >>>>> If someone tells me that proposal will work only for my 20% of traf= fic then again as I said before, they will lose my business :-) > >>>>> > >>>> Great, but this IETF. Where are the protocol requirements? If you= are > >>>> saying that there are requirements for "visibility in L4" what ar= e > >>>> they? If you are saying that ACLs are now required for packet > >>>> forwarding, where is that described? Is it a MUST that teh only > >>>> transport protocols we're allowed to use are UDP or TCP? Are we > >>>> allowed to use extension headers at all? I suppose fragmentation = is > >>>> right out... Are we violating the requirements if we encrypt the > >>>> transport headers? If you say that we shouldn't send long headers > >>>> because we'll overflow parsing buffers, then what is the limit? P= lease > >>>> be SPECIFC in setting requirements; we are trying to build protoc= ols > >>>> that work and are interoperable and we need to get out of this mo= rass > >>>> of reverse engineering to discover the least common denominator. > >>>> > >>>> Tom > >>>> > >>>>> Regards, > >>>>> -Jai > >>>>> > >>>>> =EF=BB=BFOn 4/5/19, 11:15 AM, "Tom Herbert" w= rote: > >>>>> > >>>>>> On Fri, Apr 5, 2019 at 10:55 AM Jai Kumar wrote: > >>>>>> > >>>>>> Even if we use flow label for ECMP, lack of accessibility of L4 in= formation (for various services, most simple is ACL) makes the proposal pre= tty much unusable. > >>>>>> > >>>>> That is convoluting router and firewall functionality and > >>>>> requirements. This a discussion about packet forwarding which do= es > >>>>> _not_ require ACLs. In a limited domain, for which IOAM is inten= ded, > >>>>> it is unlikely that they'll ACLs would be used in internal nodes= , but > >>>>> we do need good ECMP routing at all intermediate nodes need to b= e > >>>>> consistent rather or not that the IOAM option is present. As sid= e > >>>>> note, the ability to extract L4 information out of packets is > >>>>> dwindling anyway thanks to encryption and other techniques tryin= g to > >>>>> undo protocol ossification. For instance, good luck getting L4 > >>>>> information out of an IPsec tunnel :-). > >>>>> > >>>>> Tom > >>>>> > >>>>>> NIC cards are not used pervasively for ACLs and other services, I = believe iptables in kernel are good enough for host but that=E2=80=99s not = acceptable in networking elements. > >>>>>> > >>>>>> -Jai > >>>>>> > >>>>>> =EF=BB=BFOn 4/5/19, 10:31 AM, "ippm on behalf of Tom Herbert" wrote: > >>>>>> > >>>>>> On Fri, Apr 5, 2019 at 9:16 AM Pengshuping (Peng Shuping) > >>>>>> wrote: > >>>>>>> > >>>>>>> Hi Barak, > >>>>>>> > >>>>>>> We are certainly not designing for the lowest capable solutions b= ut exploring optimal solutions which could help to keep the forwarding perf= ormance while inserting the iOAM data with variable length. > >>>>>> > >>>>>> Shuping, > >>>>>> > >>>>>> That's exactly the argument for using the flow label in ECMP. > >>>>>> Efficeint packet forwarding can be done solely by inspected the= forty > >>>>>> byte fixed length header of the packet regardless of the conten= ts of > >>>>>> the rest of the packet. That is an optimal solution. Anything e= lse for > >>>>>> ECMP like doing DPI or hacking up IOAM to try do pull transport= layers > >>>>>> into the parsing buffer (whatever size that may be) are nothing= more > >>>>>> than hacks and unnecessarily perpetuate techniques used with IP= v4 that > >>>>>> either don't work or are unnecessary in IPv6. > >>>>>> > >>>>>> Tom > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> In terms of the forwarding efficiency, we would all agree that a = short and fixed header would be better than a variable header. > >>>>>>> > >>>>>>> Best regards > >>>>>>> Shuping > >>>>>>> > >>>>>>> > >>>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Barak Gafni > >>>>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Pengshuping (Peng Shuping);Frank Brockners (fbrockne);Mikae= l Abrahamsson > >>>>>>> =E6=8A=84=E9=80=81=EF=BC=9A C. M. Heard;6man WG<= ipv6@ietf.org>;Mark Smith;ippm > >>>>>>> =E4=B8=BB=E9=A2=98=EF=BC=9A RE: draft-ioametal-ippm-6man-ioam-ipv= 6-deployment-00 feedback (Re: v6 option types for IOAM data fields) > >>>>>>> =E6=97=B6=E9=97=B4=EF=BC=9A 2019-04-05 03:18:26 > >>>>>>> > >>>>>>> Hi Shuping, > >>>>>>> I think that the question is whether we design for the lowest cap= able solutions. I assume someone can find solutions with even lower amount = of parsing.. The low end solutions for these capabilities may need to eithe= r adopt with new designs or use solutions such as what is suggested in this= thread by Tom Herbert. > >>>>>>> Personally, I don't think we should go this way, but to design ap= propriate solutions, with appropriate layers in the headers. For example, p= revent dependencies between "remote" headers. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Barak > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: ippm On Behalf Of Pengshuping (Peng= Shuping) > >>>>>>> Sent: Wednesday, April 3, 2019 6:47 AM > >>>>>>> To: Frank Brockners (fbrockne) ; Mikael Abrah= amsson > >>>>>>> Cc: C. M. Heard ; 6man WG ; Mark = Smith ; ippm@ietf.org > >>>>>>> Subject: [ippm] =E7=AD=94=E5=A4=8D: draft-ioametal-ippm-6man-ioam= -ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> The parsing depth of the early chips is 96B/128B. For the new chi= ps the parsing depth has been increased but still limited. So Mikael's conc= ern makes sense especially in the tracing mode that the IOAM data fields ar= e going to increase significantly along the path, which will even push the = Routing Header out of the parsing depth of the chip. So it would make sense= to split the IOAM data part from the IOAM header/instruction part, and pla= ce the IOAM data after the RH or even after the L4 header in order to be ab= le to read the L4 information to enable ECMP, as stated in the draft https:= //eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.or= g%2Fhtml%2Fdraft-li-6man-ipv6-sfc-ifit-00&data=3D02%7C01%7Cgbarak%40mel= lanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f= 461b%7C0%7C0%7C636898960379485833&sdata=3DDob4zN%2F1jSGxLTlqGma29JJNvqJ= DBt4VzqHsN4OpxM4%3D&reserved=3D0. > >>>>>>> > >>>>>>> BR, > >>>>>>> Shuping > >>>>>>> > >>>>>>> > >>>>>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > >>>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: ippm [mailto:ippm-bounces@ietf.org] = =E4=BB=A3=E8=A1=A8 Frank Brockners (fbrockne) > >>>>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B44=E6=9C=882=E6= =97=A5 17:40 > >>>>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Mikael Abrahamsson > >>>>>>> =E6=8A=84=E9=80=81: C. M. Heard ; 6man WG ; Mark Smith ; ippm@ietf.org > >>>>>>> =E4=B8=BB=E9=A2=98: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6= -deployment-00 feedback (Re: v6 option types for IOAM data fields) > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Mikael Abrahamsson > >>>>>>> Sent: Dienstag, 2. April 2019 08:06 > >>>>>>> To: Frank Brockners (fbrockne) > >>>>>>> Cc: Mark Smith ; C. M. Heard ; 6man WG ; ippm@ietf.org > >>>>>>> Subject: RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 fee= dback (Re: v6 option types for IOAM data fields) > >>>>>>> > >>>>>>>> On Mon, 1 Apr 2019, Frank Brockners (fbrockne) wrote: > >>>>>>>> > >>>>>>>> ...FB: There is obviously no easy answer. Couple of thoughts: > >>>>>>>> * IOAM is considered a "domain specific" feature (see > >>>>>>>> draft-ietf-ippm-ioam-data-05, section 3). Routers in the IOAM do= main > >>>>>>>> should be IOAM capable. And IMHO, we should add a statement to > >>>>>>>> draft-ioametal-ippm-6man-ioam-ipv6-deployment that an implementa= tion > >>>>>>>> of IOAM MUST ensure "C1". > >>>>>>>> > >>>>>>>> * That said, there can be situations, where C1 cannot be achieve= d, e.g.. > >>>>>>>> consider a network which does ECMP scheduling based on packet le= ngth. > >>>>>>>> > >>>>>>>> * What one could consider - and which is one suggested deploymen= t > >>>>>>>> model > >>>>>>>> - is that by default IOAM data fields are added to _all_ custome= r > >>>>>>>> packets. The decapsulating node would decide whether the IOAM > >>>>>>>> information contained in a packet would be used (and exported) o= r not. > >>>>>>>> That way one would not need to deal with the situation that some > >>>>>>>> traffic carries IOAM while other does not - and might thus be tr= eated > >>>>>>>> differently. > >>>>>>> > >>>>>>> Yes, I think this is the only way. Is there a risk that intermedi= ate routers would not be IOAM capable? I think the C1 requirement is really= really hard to fulfil and I'm also afraid that adding the IOAM header will= actually make ECMP stop working on some platforms (because they would not = have the capability to look deep enough into the packet to find L4 informat= ion, so it'll go back to 2 tuple ECMP instead of 5 tuple. > >>>>>>> > >>>>>>> But this question can only be answered by people with deep NPU kn= owledge... > >>>>>>> > >>>>>>> .....FB2: Given that IOAM is a domain specific feature - I expect= that folks initially start to use it in domains (like e.g. a DC) where all= boxes are IOAM capable and can trace the packet appropriately - or per Tom= 's note, can be configured so that one would do ECMP based on addresses and= flow-label. There are chips with pretty deep parsing capability (up to a = few hundred bytes). > >>>>>>> > >>>>>>>> ...FB: The comparison to MPLS is interesting. How often do MPLS > >>>>>>>> packets leak and cause harm? For IOAM, > >>>>>>>> draft-ioametal-ippm-6man-ioam-ipv6-options-02 proposes a deploym= ent > >>>>>>>> model similar to what we do for MPLS: Unless an interface is > >>>>>>>> explicitly configured for IOAM, packets with IOAM data fields MU= ST be dropped. > >>>>>>>> Hence leakage would only occur, if we have a clearly misbehaving > >>>>>>>> router which violates this rule. Similar to you, I'd also greatl= y > >>>>>>>> appreciate any pointers to research on how common MPLS leaked pa= ckets are. > >>>>>>> > >>>>>>> When it comes to "cause harm" I imagine there are (at least) two = ways to cause harm, one is privacy/secrecy/security loss and the other one = is actual operational loss. > >>>>>>> > >>>>>>> I know of bugs where labeled packets went the wrong way and cause= d them to be lost, I've also seen bugs where bugs caused traffic to "hop" b= etween VRFs in MPLS VPN (or to "global" VRF). I don't have numbers on this = though. > >>>>>>> > >>>>>>> Depending on the deployment scenario, it might make sense to make= IOAM packets not valid for non-IOAM aware devices (basically encap entire = packet/payload), but that might be a problem for intermediate non-IOAM node= s then. This would affect the ECMP requirement. I can see cases where one w= ould operationally turn on IOAM for some customers traffic and then see the= problem go away because now ECMP changed. > >>>>>>> > >>>>>>>> ...FB: One idea that Shwetha came up with to identify the source= AS of > >>>>>>>> a leaked packet, would be to add a new new IOAM E2E option - as > >>>>>>>> proposed in section 5.1.1 bullet 2 of > >>>>>>>> draft-ioametal-ippm-6man-ioam-ipv6-deployment-01. > >>>>>>> > >>>>>>> Yes, that'd solve that problem. > >>>>>>> > >>>>>>> How much has the silicon people been involved so far in the desig= n of the headers? What is the current thinking of amount of data going into= the IOAM header? Considering things like trace options etc it seems to me = the header can grow quite large? To satisfy the ECMP requirement what about= putting the IOAM information as a trailer behind the regular payload? Or i= s there a problem for the hw to manipulate information that far into the pa= cket (I also imagine this will considerably lower the forwarding performanc= e of IOAM packets on IOAM aware platforms). > >>>>>>> > >>>>>>> .....FB2: There are quite a few folks with hardware background th= at co-author the IOAM drafts. Parsing capability differs between chips, as = does the ability to deal with new/flexible headers and the ability to modif= y data in the extension headers. So the unfortunate answer to that question= is "it depends" (what information do you gather, how large is your domain,= what are the capabilities of your hardware/software forwarder, etc.), but = I do expect that for specific deployment domains (e.g. DC, Enterprise) - bu= t also for overlay networks / VPNs - we'll see an increasing amount of chip= s that are well suited for processing large extension header. > >>>>>>> > >>>>>>> Cheers, Frank > >>>>>>> > >>>>>>> -- > >>>>>>> Mikael Abrahamsson email: swmike@swm.pp.se > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> ippm mailing list > >>>>>>> ippm@ietf.org > >>>>>>> https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cgbarak%40m= ellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d14925= 6f461b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef3BJFz= 6AQNNAtkgmAMDFKM%3D&reserved=3D0 > >>>>>>> _______________________________________________ > >>>>>>> ippm mailing list > >>>>>>> ippm@ietf.org > >>>>>>> https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F= %2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cgbarak%40m= ellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d14925= 6f461b%7C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef3BJFz= 6AQNNAtkgmAMDFKM%3D&reserved=3D0 > >>>>>>> -----------------------------------------------------------------= --- > >>>>>>> IETF IPv6 working group mailing list > >>>>>>> ipv6@ietf.org > >>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ip= v6 > >>>>>>> -----------------------------------------------------------------= --- > >>>>>> > >>>>>> _______________________________________________ > >>>>>> ippm mailing list > >>>>>> ippm@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/ippm > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >> > >> > >> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Sat Apr 6 16:06:51 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1873120167 for ; Sat, 6 Apr 2019 16:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 fsoAIr_CB8px for ; Sat, 6 Apr 2019 16:06:38 -0700 (PDT) Received: from mail-qt1-x844.google.com (mail-qt1-x844.google.com [IPv6:2607:f8b0:4864:20::844]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 056E11202D0 for ; Sat, 6 Apr 2019 16:06:36 -0700 (PDT) Received: by mail-qt1-x844.google.com with SMTP id t28so11471393qte.6 for ; Sat, 06 Apr 2019 16:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dLudskw2ivLynr1sk8PPC4FK13aE3fDOGxLg7py9rmE=; b=B89u7WyyTRjOnAxv2Gu30AjKQXzEVQ+d9riACfDRSD+FJONGlguUL36+XrWelss7Xf er833ks1TAT9bwPUPVTDovCysFiYD24vGQm2qsS1FpOIzSeXv/Is/lEgu6PTKksjDfEK lauI7o1cMj8htMy7ISdDiea43DQ2fOJAuTXTPz5Jvftt7hEx9OQH5bnkCZGyJ2GVHrDu /WwMswtNTnI/NZkfQrHmZpU5LDsEMubZSl/Y7Vtr5i+TeqyVMfH22Jg9mlh364ZMZQ/8 2EKB/Y9zrsQ66HL4XU5naSTHWzfJ5SiCoC/wl9nlAnljr0Rju9zxYQXZfbyHeCpzNIX9 Nvow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dLudskw2ivLynr1sk8PPC4FK13aE3fDOGxLg7py9rmE=; b=OBBnQTVLwrQ+BqeZ6pZh8XVtpcCTE1PPxOe6DOxEXfy2ORRmWNNdnzx00tj39l6iaR 1buhxomsAlzxh7Z0rNyRD+BRLpmv2fpkvetHT3N6lsqqvytwdWVaOPteAJL10XW6f/6f r8Vb1994XyxPEcV2A6+gwDH48SxGG+UFfVoKterhJP2QBKrd1Ddr81VMeodSQBbaha2S p9u1pJZELdb2bHknDE6fkUdnh6eSolqftTs4Ezecgx9I/SuzxG2PTvWtm+3VCoG4+vug L2m6oojZ9XWL5ekWYCUPilDbyPWDBQGOH1MLxV2DeafEy1CiE7FpontSyjRSrzN8aG/S MGWQ== X-Gm-Message-State: APjAAAX19ivDwCa4O5UzNmh7WvfIvjCsQWmtHQntGK/0Q6PadnJ4e+W3 9bzoQF5Vrn0efp+EXIPNdpdVZWOjBz91hjbS3zTmRw== X-Google-Smtp-Source: APXvYqyL7TgE5Sp1Vlu9GiTKC8LrlvPbdw4I20/G2of7+2XD5miD61lizn9Chg9Jo1jX7/ohLat6ovk7QfUw+kC2GL8= X-Received: by 2002:ac8:1833:: with SMTP id q48mr17871274qtj.133.1554591995713; Sat, 06 Apr 2019 16:06:35 -0700 (PDT) MIME-Version: 1.0 References: <505272eac2dd44fa891d4d36d14da9af@XCH-RCD-008.cisco.com> <7ea9049fe6f44a40aefe4801bd796322@XCH-RCD-008.cisco.com> <4278D47A901B3041A737953BAA078ADE1478D5E2@DGGEML532-MBX.china.huawei.com> <4278D47A901B3041A737953BAA078ADE1478EC8B@DGGEML532-MBX.china.huawei.com> <14A3D5C9-1EED-4E11-9329-B62B819271A2@broadcom.com> <20D6FCDB-3357-4728-BD52-8069C32F3CCA@broadcom.com> <57A32C37-AAE9-44F2-9C96-39AFA71BDC21@broadcom.com> <36B9204A-D1EE-4067-92BB-6C33CB2DF791@broadcom.com> <6E177A89-8488-4E24-A37A-B4C14D8ACB0D@broadcom.com> <0B28F885-A556-4E1A-ABE5-42E5B078D257@broadcom.com> In-Reply-To: From: Tom Herbert Date: Sat, 6 Apr 2019 15:56:47 -0700 Message-ID: To: Mark Smith Cc: Jai Kumar , "C. M. Heard" , 6man , ippm Content-Type: multipart/alternative; boundary="000000000000aceddf0585e4a791" Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 23:06:44 -0000 --000000000000aceddf0585e4a791 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Apr 6, 2019, 3:36 PM Mark Smith wrote: > On Sun, 7 Apr 2019 at 07:06, Jai Kumar > wrote: > > > > Tom, > > > > We are talking about nexthop I.e. packet forwarding not member link > selection in load balancing. > > Basic packet forwarding is broken with options. > > > > If I understand this statement correctly, it isn't basic forwarding if > options other than the Hop-by-Hop option is considered. > > IPv6 forwarding is designed to only use the fields in the fixed IPv6 > header (with one exception) - that is why those fields are not > optional. > Thanks for the explanation Mark. I would only add that RFC8200 essentially makes that one exception (HBH options) optional to process. Tom > The only IPv6 option/EH that can be used in forwarding is the > Hop-by-Hop option, and it is required to be directly after the IPv6 > fixed header. > > Any other IPv6 options/EH are not designed nor intended to be used in > IPv6 forwarding. > > > Perhaps one thing people suggesting things to this Working Group can > forget is that our protocol is more than two decades old and that we > have a very large installed base of devices that support it and that > are being used constantly (this email is coming over IPv6). > > So we can't just make arbitrary changes to the protocol to suit new > requirements, unlike greenfield IETF Working Groups with no or a very > limited installed base can. We have to try our hardest to accommodate > those new requirements within the specifications and within existing > deployments. > > So if a new method of doing something is proposed, we here are going > to be looking to see how it can be done using existing, proven and > well-known methods first (e.g, adding supplementary information to > packets via IPv6-in-IPv6 encapsulation, ECMP via Flow Label rather > than digging up the UDP/TCP headers.) > > Regards, > Mark. > > > > -Jai > > > > > On Apr 6, 2019, at 12:55 PM, Tom Herbert wrote: > > > > > >> On Sat, Apr 6, 2019 at 9:41 AM Jai Kumar > wrote: > > >> > > >> Tom, > > >> > > >> Please read the IOAM draft again. There is a variable length metadat= a > stack as well with trace option. Forwarding becomes completely > indeterministic. > > > > > > Jai, > > > > > > Use the flow label and addresses as input to ECMP forwarding _is_ > > > deterministic. And not just for deterministic for TCP or UDP, but for > > > _any_ protocol, combination of EH, encryptions, etc. that a packet > > > carries. See RFC6438. > > > > > >> In short using options forwarding gets impacted for EH. You still > want to push for it go by all means but don't expect a silicon vendor or > deployment to agree for it. > > > > > > I'm not sure what we're trying to get agreement on. The only > > > expectation we have is that vendors, and everyone else for that > > > matter, conform to IETF standards. Extension headers have be defined > > > for over twenty years and are full standard, and now that people want > > > to use them there appears to be _some_ implementations (emphasis on > > > the word "some") that seem to have a problem processing them. Frankly= , > > > that is a shortcoming of implementation, not of the protocol. The onl= y > > > protocol shortcoming that has thus far been identified in the IOAM > > > discussion is the fact that EH don't exist in IPv4 and there is reall= y > > > no alternative that provides the necessary functionality-- this is > > > something I believe IETF can work on. > > > > > > Tom > > > > > >> > > >> -Jai > > >> > > >> =EF=BB=BFOn 4/5/19, 5:05 PM, "Tom Herbert" wro= te: > > >> > > >>> On Fri, Apr 5, 2019 at 4:40 PM Jai Kumar > wrote: > > >>> > > >>> Tom, > > >>> > > >>> > > >>> > > >>> You are right. There are two main cases where accessibility of > transport header becomes an issue. And that is mainly because of current > generation of fixed pipeline cell based architecture parse depth (not so > much an issue for high end NPU where next packet header bytes can be DMA= =E2=80=99ed > in, though it impacts the performance. For eg. Cisco QFP NPU, EZ Chip, > Juniper=E2=80=99s MX 3D NPU, or Broadcom=E2=80=99s Jerricho NPU ). This w= as mentioned > earlier by Mikael as well. > > >>> > > >>> > > >>> > > >>> Case 1. SRv6 > > >>> > > >>> Case 2. IPv6 with EH (mainly for 5G deployments where RH, DH, and > IFA Header) > > >>> > > >>> > > >>> > > >>> Typically NPUs provide capability that it will handle 3 or 4 EH or > SRH without performance penalty. With the presence of IFA header this mea= ns > that for eg there can be only 2 or 3 SRH or EH. This is same as in MPLS > label stack depth handling (PUSH or POP at PE router). Given the evolutio= n > SRV6 and MPLS-SR kind of headers, silicon vendors have taken a notice of = it > and are evolving the silicon arch to handle more chained headers. > > >>> > > >>> > > >>> > > >>> IFA supports fragmentation of metadata stack and also postcard mode > so beyond the transport header it=E2=80=99s not an issue. > > >>> > > >>> > > >>> > > >>> Just a quick feedback on using IPv6 options, inserting hop by hop > options for data path processing pushes the EH further down and impacts t= he > node=E2=80=99s forwarding function (say if it is not able to reach Destin= ation EH) > vs if IFA header is the last EH then atmost transit node do not perform > metadata collection which can be identified. > > >> > > >> Maybe it does impact it, maybe it doesn't. It clearly depends on > the > > >> device capabilities. For a device with a parsing buffer of 256 > bytes > > >> that should be plenty of room for HBH options, SR header, transpo= rt > > >> layer, etc. > > >> > > >>> > > >>> > > >>> > > >>> -Jai > > >>> > > >>> > > >>> > > >>> From: Tom Herbert > > >>> Date: Friday, April 5, 2019 at 3:34 PM > > >>> To: Jai Kumar > > >>> Cc: "Pengshuping (Peng Shuping)" , 6man < > ipv6@ietf.org>, ippm , "C. M. Heard" , > Mikael Abrahamsson > > >>> Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-0= 0 > feedback (Re: v6 option types for IOAM data fields) > > >>> > > >>> > > >>> > > >>> Jai, > > >>> > > >>> > > >>> > > >>> You might want to consider how IFA works in the presence of segment > routing. The second someone puts an SRH in the packet the IFA headers get > pushed down and the transport headers end up being deep in the packet > anyway so that all the effort of IFA is nullified. If the requirement is = to > ensure that the transport layer information appear as early as possible i= n > the packet, one could define a Hop-by-Hop option to carry some sort of > pseudo header for the transport layer. This also would work in the case > that the actual transport layer is obfuscated. > > >>> > > >>> > > >>> > > >>> Tom > > >>> > > >>> > > >>> > > >>> On Fri, Apr 5, 2019, 3:09 PM Jai Kumar > wrote: > > >>> > > >>> =E2=80=9CThat is going to require justifying the protocol even in l= ight of > shortcomings in existing protocoIs.=E2=80=9D > > >>> > > >>> > > >>> > > >>> Agreed !!! True for any proposal. > > >>> > > >>> > > >>> > > >>> -Jai > > >>> > > >>> > > >>> > > >>> From: Tom Herbert > > >>> Date: Friday, April 5, 2019 at 2:34 PM > > >>> To: Jai Kumar > > >>> Cc: "Pengshuping (Peng Shuping)" , 6man < > ipv6@ietf.org>, ippm , "C. M. Heard" , > Mikael Abrahamsson > > >>> Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-deployment-0= 0 > feedback (Re: v6 option types for IOAM data fields) > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> On Fri, Apr 5, 2019, 2:07 PM Jai Kumar > wrote: > > >>> > > >>> Tom, > > >>> > > >>> Its all explained in the requirements section of the draft. IFA > header is essentially treated as an EH both in IPv4 and IPv6 (very simila= r > to AH/ESP EH). > > >>> > > >>> Just like in AH/ESP the IP protocol is copied in the AH header and > IP protocol field is replaced in the IP header with the AH proto. > > >>> > > >>> There are several advantages to this approach. > > >>> - devise know how to parse AH header and can follow very similar > approach > > >>> - Protocol agnostics, silicon need not support N encaps (just like > AH/ESP). Single implementation works for all protocol types. > > >>> - No need to creation options and teach devices that options is NOT > an exception path processing > > >>> - Really worry about ordering in IPv6 options > > >>> - Note that all the OAM data need to be deleted as well so position > need to be optimal for removal. We can always do tail stamping of the dat= a > but this puts considerable constrains on the cell based architecture > > >>> - L4 accessibility I have already mentioned > > >>> > > >>> I am happy to discuss with you in person and explain more but botto= m > line is that this proposal is what came out with MSDC discussions in ligh= t > of shortcomings from other IETF proposals. > > >>> > > >>> > > >>> > > >>> As they say, you are free to run whatever you want in your > proprietary network, but if you expect to create an interoperable, > deployable protocoI and get a protocol number assignment, you'll need to > work in ietf. That is going to require justifying the protocol even in > light of shortcomings in existing protocoIs. > > >>> > > >>> > > >>> > > >>> Tom > > >>> > > >>> > > >>> > > >>> > > >>> Regards, > > >>> -Jai > > >>> > > >>> > > >>> =EF=BB=BFOn 4/5/19, 12:28 PM, "Tom Herbert" w= rote: > > >>> > > >>>> On Fri, Apr 5, 2019 at 12:03 PM Jai Kumar < > jai.kumar@broadcom.com> wrote: > > >>>> > > >>>> " Great, but this IETF" > > >>>> Does it mean that drafts have no relevance to deployment and actua= l > adoption. > > >>>> > > >>>> For all your queries please take a look at IFA draft. > > >>>> https://datatracker.ietf.org/doc/draft-kumar-ippm-ifa/ > > >>>> > > >>> I've looked at that draft. It's is creating a complete new IP > > >>> protocolas well as a new packet format for TCP and UDP that > somehow > > >>> inserts meta data between the TCP header and payload. I don't > > >>> understand why this could possibly be better than just using flo= w > > >>> label for ECMP and teaching devices that need to extract transpo= rt > > >>> information how to walk over EH, or just using some UDP > encpasulation > > >>> like in draft-herbert-ipv4-udpencap-eh-01. > > >>> > > >>> Tom > > >>> > > >>>> It handles IPv6, IPv4 TCP/UDP with altering the packet path (due t= o > inserting options and/or encaping them in GRE header) as well as IPSec > AH/ESP/WESP both tunnel and transport and guess what it is successfully > deployed. > > >>>> > > >>>> -Jai > > >>>> > > >>>> =EF=BB=BFOn 4/5/19, 11:54 AM, "Tom Herbert" = wrote: > > >>>> > > >>>>> On Fri, Apr 5, 2019 at 11:25 AM Jai Kumar < > jai.kumar@broadcom.com> wrote: > > >>>>> > > >>>>> Tom, > > >>>>> > > >>>>> I am speaking based on the actual deployment not based on if all > the traffic is/will move to IPSec tunnel. > > >>>>> > > >>>>> I have 6 large customer deployments and one someone previously > called as "Yahoo" who insist on visibility in L4 even for IOAM packets. > > >>>>> > > >>>> And I've worked in datcenters much larger, and my first rule is > that I > > >>>> don't want random router vendors dictating to me what protocols > I'm > > >>>> allowed to use in my datacenter. > > >>>> > > >>>>> I can quote you on that and lose my business :-) > > >>>>> > > >>>>> ECMP argument is weak as well as it works for IPv6 flow label. > What about IPv4 TCP/UDP traffic which typically is 80% of the traffic in > MSDC. > > >>>>> > > >>>> > > >>>> draft-herbert-ipv4-udpencap-eh-01 > > >>>> > > >>>>> If someone tells me that proposal will work only for my 20% of > traffic then again as I said before, they will lose my business :-) > > >>>>> > > >>>> Great, but this IETF. Where are the protocol requirements? If > you are > > >>>> saying that there are requirements for "visibility in L4" what > are > > >>>> they? If you are saying that ACLs are now required for packet > > >>>> forwarding, where is that described? Is it a MUST that teh only > > >>>> transport protocols we're allowed to use are UDP or TCP? Are w= e > > >>>> allowed to use extension headers at all? I suppose fragmentatio= n > is > > >>>> right out... Are we violating the requirements if we encrypt th= e > > >>>> transport headers? If you say that we shouldn't send long heade= rs > > >>>> because we'll overflow parsing buffers, then what is the limit? > Please > > >>>> be SPECIFC in setting requirements; we are trying to build > protocols > > >>>> that work and are interoperable and we need to get out of this > morass > > >>>> of reverse engineering to discover the least common denominator= . > > >>>> > > >>>> Tom > > >>>> > > >>>>> Regards, > > >>>>> -Jai > > >>>>> > > >>>>> =EF=BB=BFOn 4/5/19, 11:15 AM, "Tom Herbert" = wrote: > > >>>>> > > >>>>>> On Fri, Apr 5, 2019 at 10:55 AM Jai Kumar < > jai.kumar@broadcom.com> wrote: > > >>>>>> > > >>>>>> Even if we use flow label for ECMP, lack of accessibility of L4 > information (for various services, most simple is ACL) makes the proposal > pretty much unusable. > > >>>>>> > > >>>>> That is convoluting router and firewall functionality and > > >>>>> requirements. This a discussion about packet forwarding which > does > > >>>>> _not_ require ACLs. In a limited domain, for which IOAM is > intended, > > >>>>> it is unlikely that they'll ACLs would be used in internal > nodes, but > > >>>>> we do need good ECMP routing at all intermediate nodes need to > be > > >>>>> consistent rather or not that the IOAM option is present. As > side > > >>>>> note, the ability to extract L4 information out of packets is > > >>>>> dwindling anyway thanks to encryption and other techniques > trying to > > >>>>> undo protocol ossification. For instance, good luck getting L4 > > >>>>> information out of an IPsec tunnel :-). > > >>>>> > > >>>>> Tom > > >>>>> > > >>>>>> NIC cards are not used pervasively for ACLs and other services, = I > believe iptables in kernel are good enough for host but that=E2=80=99s no= t > acceptable in networking elements. > > >>>>>> > > >>>>>> -Jai > > >>>>>> > > >>>>>> =EF=BB=BFOn 4/5/19, 10:31 AM, "ippm on behalf of Tom Herbert" < > ippm-bounces@ietf.org on behalf of tom@herbertland.com> wrote: > > >>>>>> > > >>>>>> On Fri, Apr 5, 2019 at 9:16 AM Pengshuping (Peng Shuping) > > >>>>>> wrote: > > >>>>>>> > > >>>>>>> Hi Barak, > > >>>>>>> > > >>>>>>> We are certainly not designing for the lowest capable solutions > but exploring optimal solutions which could help to keep the forwarding > performance while inserting the iOAM data with variable length. > > >>>>>> > > >>>>>> Shuping, > > >>>>>> > > >>>>>> That's exactly the argument for using the flow label in ECMP. > > >>>>>> Efficeint packet forwarding can be done solely by inspected > the forty > > >>>>>> byte fixed length header of the packet regardless of the > contents of > > >>>>>> the rest of the packet. That is an optimal solution. Anything > else for > > >>>>>> ECMP like doing DPI or hacking up IOAM to try do pull > transport layers > > >>>>>> into the parsing buffer (whatever size that may be) are > nothing more > > >>>>>> than hacks and unnecessarily perpetuate techniques used with > IPv4 that > > >>>>>> either don't work or are unnecessary in IPv6. > > >>>>>> > > >>>>>> Tom > > >>>>>> > > >>>>>> > > >>>>>>> > > >>>>>>> In terms of the forwarding efficiency, we would all agree that = a > short and fixed header would be better than a variable header. > > >>>>>>> > > >>>>>>> Best regards > > >>>>>>> Shuping > > >>>>>>> > > >>>>>>> > > >>>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Barak Gafni > > >>>>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Pengshuping (Peng Shuping)= ;Frank > Brockners (fbrockne);Mikael Abrahamsson< > swmike@swm.pp.se> > > >>>>>>> =E6=8A=84=E9=80=81=EF=BC=9A C. M. Heard;6man W= G;Mark > Smith;ippm > > >>>>>>> =E4=B8=BB=E9=A2=98=EF=BC=9A RE: draft-ioametal-ippm-6man-ioam-i= pv6-deployment-00 > feedback (Re: v6 option types for IOAM data fields) > > >>>>>>> =E6=97=B6=E9=97=B4=EF=BC=9A 2019-04-05 03:18:26 > > >>>>>>> > > >>>>>>> Hi Shuping, > > >>>>>>> I think that the question is whether we design for the lowest > capable solutions. I assume someone can find solutions with even lower > amount of parsing.. The low end solutions for these capabilities may need > to either adopt with new designs or use solutions such as what is suggest= ed > in this thread by Tom Herbert. > > >>>>>>> Personally, I don't think we should go this way, but to design > appropriate solutions, with appropriate layers in the headers. For exampl= e, > prevent dependencies between "remote" headers. > > >>>>>>> > > >>>>>>> Thanks, > > >>>>>>> Barak > > >>>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: ippm On Behalf Of Pengshuping > (Peng Shuping) > > >>>>>>> Sent: Wednesday, April 3, 2019 6:47 AM > > >>>>>>> To: Frank Brockners (fbrockne) ; Mikael > Abrahamsson > > >>>>>>> Cc: C. M. Heard ; 6man WG ; > Mark Smith ; ippm@ietf.org > > >>>>>>> Subject: [ippm] =E7=AD=94=E5=A4=8D: > draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option > types for IOAM data fields) > > >>>>>>> > > >>>>>>> Hi, > > >>>>>>> > > >>>>>>> The parsing depth of the early chips is 96B/128B. For the new > chips the parsing depth has been increased but still limited. So Mikael's > concern makes sense especially in the tracing mode that the IOAM data > fields are going to increase significantly along the path, which will eve= n > push the Routing Header out of the parsing depth of the chip. So it would > make sense to split the IOAM data part from the IOAM header/instruction > part, and place the IOAM data after the RH or even after the L4 header in > order to be able to read the L4 information to enable ECMP, as stated in > the draft > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= .ietf.org%2Fhtml%2Fdraft-li-6man-ipv6-sfc-ifit-00&data=3D02%7C01%7Cgbar= ak%40mellanox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4= d149256f461b%7C0%7C0%7C636898960379485833&sdata=3DDob4zN%2F1jSGxLTlqGma= 29JJNvqJDBt4VzqHsN4OpxM4%3D&reserved=3D0 > . > > >>>>>>> > > >>>>>>> BR, > > >>>>>>> Shuping > > >>>>>>> > > >>>>>>> > > >>>>>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6----- > > >>>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: ippm [mailto:ippm-bounces@ietf.org= ] =E4=BB=A3=E8=A1=A8 Frank Brockners > (fbrockne) > > >>>>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B44=E6=9C=882= =E6=97=A5 17:40 > > >>>>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Mikael Abrahamsson > > >>>>>>> =E6=8A=84=E9=80=81: C. M. Heard ; 6man WG ; > Mark Smith ; ippm@ietf.org > > >>>>>>> =E4=B8=BB=E9=A2=98: Re: [ippm] draft-ioametal-ippm-6man-ioam-ip= v6-deployment-00 > feedback (Re: v6 option types for IOAM data fields) > > >>>>>>> > > >>>>>>> > > >>>>>>> > > >>>>>>> -----Original Message----- > > >>>>>>> From: Mikael Abrahamsson > > >>>>>>> Sent: Dienstag, 2. April 2019 08:06 > > >>>>>>> To: Frank Brockners (fbrockne) > > >>>>>>> Cc: Mark Smith ; C. M. Heard < > heard@pobox.com>; 6man WG ; ippm@ietf.org > > >>>>>>> Subject: RE: draft-ioametal-ippm-6man-ioam-ipv6-deployment-00 > feedback (Re: v6 option types for IOAM data fields) > > >>>>>>> > > >>>>>>>> On Mon, 1 Apr 2019, Frank Brockners (fbrockne) wrote: > > >>>>>>>> > > >>>>>>>> ...FB: There is obviously no easy answer. Couple of thoughts: > > >>>>>>>> * IOAM is considered a "domain specific" feature (see > > >>>>>>>> draft-ietf-ippm-ioam-data-05, section 3). Routers in the IOAM > domain > > >>>>>>>> should be IOAM capable. And IMHO, we should add a statement = to > > >>>>>>>> draft-ioametal-ippm-6man-ioam-ipv6-deployment that an > implementation > > >>>>>>>> of IOAM MUST ensure "C1". > > >>>>>>>> > > >>>>>>>> * That said, there can be situations, where C1 cannot be > achieved, e.g.. > > >>>>>>>> consider a network which does ECMP scheduling based on packet > length. > > >>>>>>>> > > >>>>>>>> * What one could consider - and which is one suggested > deployment > > >>>>>>>> model > > >>>>>>>> - is that by default IOAM data fields are added to _all_ > customer > > >>>>>>>> packets. The decapsulating node would decide whether the IOAM > > >>>>>>>> information contained in a packet would be used (and exported) > or not. > > >>>>>>>> That way one would not need to deal with the situation that so= me > > >>>>>>>> traffic carries IOAM while other does not - and might thus be > treated > > >>>>>>>> differently. > > >>>>>>> > > >>>>>>> Yes, I think this is the only way. Is there a risk that > intermediate routers would not be IOAM capable? I think the C1 requiremen= t > is really really hard to fulfil and I'm also afraid that adding the IOAM > header will actually make ECMP stop working on some platforms (because th= ey > would not have the capability to look deep enough into the packet to find > L4 information, so it'll go back to 2 tuple ECMP instead of 5 tuple. > > >>>>>>> > > >>>>>>> But this question can only be answered by people with deep NPU > knowledge... > > >>>>>>> > > >>>>>>> .....FB2: Given that IOAM is a domain specific feature - I > expect that folks initially start to use it in domains (like e.g. a DC) > where all boxes are IOAM capable and can trace the packet appropriately - > or per Tom's note, can be configured so that one would do ECMP based on > addresses and flow-label. There are chips with pretty deep parsing > capability (up to a few hundred bytes). > > >>>>>>> > > >>>>>>>> ...FB: The comparison to MPLS is interesting. How often do MPL= S > > >>>>>>>> packets leak and cause harm? For IOAM, > > >>>>>>>> draft-ioametal-ippm-6man-ioam-ipv6-options-02 proposes a > deployment > > >>>>>>>> model similar to what we do for MPLS: Unless an interface is > > >>>>>>>> explicitly configured for IOAM, packets with IOAM data fields > MUST be dropped. > > >>>>>>>> Hence leakage would only occur, if we have a clearly misbehavi= ng > > >>>>>>>> router which violates this rule. Similar to you, I'd also > greatly > > >>>>>>>> appreciate any pointers to research on how common MPLS leaked > packets are. > > >>>>>>> > > >>>>>>> When it comes to "cause harm" I imagine there are (at least) tw= o > ways to cause harm, one is privacy/secrecy/security loss and the other on= e > is actual operational loss. > > >>>>>>> > > >>>>>>> I know of bugs where labeled packets went the wrong way and > caused them to be lost, I've also seen bugs where bugs caused traffic to > "hop" between VRFs in MPLS VPN (or to "global" VRF). I don't have numbers > on this though. > > >>>>>>> > > >>>>>>> Depending on the deployment scenario, it might make sense to > make IOAM packets not valid for non-IOAM aware devices (basically encap > entire packet/payload), but that might be a problem for intermediate > non-IOAM nodes then. This would affect the ECMP requirement. I can see > cases where one would operationally turn on IOAM for some customers traff= ic > and then see the problem go away because now ECMP changed. > > >>>>>>> > > >>>>>>>> ...FB: One idea that Shwetha came up with to identify the > source AS of > > >>>>>>>> a leaked packet, would be to add a new new IOAM E2E option - a= s > > >>>>>>>> proposed in section 5.1.1 bullet 2 of > > >>>>>>>> draft-ioametal-ippm-6man-ioam-ipv6-deployment-01. > > >>>>>>> > > >>>>>>> Yes, that'd solve that problem. > > >>>>>>> > > >>>>>>> How much has the silicon people been involved so far in the > design of the headers? What is the current thinking of amount of data goi= ng > into the IOAM header? Considering things like trace options etc it seems = to > me the header can grow quite large? To satisfy the ECMP requirement what > about putting the IOAM information as a trailer behind the regular payloa= d? > Or is there a problem for the hw to manipulate information that far into > the packet (I also imagine this will considerably lower the forwarding > performance of IOAM packets on IOAM aware platforms). > > >>>>>>> > > >>>>>>> .....FB2: There are quite a few folks with hardware background > that co-author the IOAM drafts. Parsing capability differs between chips, > as does the ability to deal with new/flexible headers and the ability to > modify data in the extension headers. So the unfortunate answer to that > question is "it depends" (what information do you gather, how large is yo= ur > domain, what are the capabilities of your hardware/software forwarder, > etc.), but I do expect that for specific deployment domains (e.g. DC, > Enterprise) - but also for overlay networks / VPNs - we'll see an > increasing amount of chips that are well suited for processing large > extension header. > > >>>>>>> > > >>>>>>> Cheers, Frank > > >>>>>>> > > >>>>>>> -- > > >>>>>>> Mikael Abrahamsson email: swmike@swm.pp.se > > >>>>>>> > > >>>>>>> _______________________________________________ > > >>>>>>> ippm mailing list > > >>>>>>> ippm@ietf.org > > >>>>>>> > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cgbarak%40mellanox.= com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7= C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef3BJFz6AQNNAtk= gmAMDFKM%3D&reserved=3D0 > > >>>>>>> _______________________________________________ > > >>>>>>> ippm mailing list > > >>>>>>> ippm@ietf.org > > >>>>>>> > https://eur03.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Fmailman%2Flistinfo%2Fippm&data=3D02%7C01%7Cgbarak%40mellanox.= com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7= C0%7C0%7C636898960379485833&sdata=3DVjZ1PiwifYGCf159je0yef3BJFz6AQNNAtk= gmAMDFKM%3D&reserved=3D0 > > >>>>>>> > -------------------------------------------------------------------- > > >>>>>>> IETF IPv6 working group mailing list > > >>>>>>> ipv6@ietf.org > > >>>>>>> Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 > > >>>>>>> > -------------------------------------------------------------------- > > >>>>>> > > >>>>>> _______________________________________________ > > >>>>>> ippm mailing list > > >>>>>> ippm@ietf.org > > >>>>>> https://www.ietf.org/mailman/listinfo/ippm > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>> > > >>>>> > > >>>>> > > >>>> > > >>>> > > >>>> > > >>> > > >> > > >> > > >> > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > --000000000000aceddf0585e4a791 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Apr 6, 2019, 3:36 PM Mark Smith <markzzzsmith@gmail.com> wrote:
On Sun, 7 Apr 2019 at 07:06, Jai Kumar <jai.kumar=3D40broadcom.com@dmarc.ietf.org> wrote:
>
> Tom,
>
> We are talking about nexthop I.e. packet forwarding not member link se= lection in load balancing.
> Basic packet forwarding is broken with options.
>

If I understand this statement correctly, it isn't basic forwarding if<= br> options other than the Hop-by-Hop option is considered.

IPv6 forwarding is designed to only use the fields in the fixed IPv6
header (with one exception) - that is why those fields are not
optional.

Thanks for the explanation Mark. I would only add that RFC8200 es= sentially makes that one exception (HBH options) optional to process.
=

Tom

The only IPv6 option/EH that can be used in forwarding is the
Hop-by-Hop option, and it is required to be directly after the IPv6
fixed header.

Any other IPv6 options/EH are not designed nor intended to be used in
IPv6 forwarding.


Perhaps one thing people suggesting things to this Working Group can
forget is that our protocol is more than two decades old and that we
have a very large installed base of devices that support it and that
are being used constantly (this email is coming over IPv6).

So we can't just make arbitrary changes to the protocol to suit new
requirements, unlike greenfield IETF Working Groups with no or a very
limited installed base can. We have to try our hardest to accommodate
those new requirements within the specifications and within existing
deployments.

So if a new method of doing something is proposed, we here are going
to be looking to see how it can be done using existing, proven and
well-known methods first (e.g, adding supplementary information to
packets via IPv6-in-IPv6 encapsulation, ECMP via Flow Label rather
than digging up the UDP/TCP headers.)

Regards,
Mark.


> -Jai
>
> > On Apr 6, 2019, at 12:55 PM, Tom Herbert <tom@herbertland.com= > wrote:
> >
> >> On Sat, Apr 6, 2019 at 9:41 AM Jai Kumar <jai.kumar@br= oadcom.com> wrote:
> >>
> >> Tom,
> >>
> >> Please read the IOAM draft again. There is a variable length = metadata stack as well with trace option. Forwarding becomes completely ind= eterministic.
> >
> > Jai,
> >
> > Use the flow label and addresses as input to ECMP forwarding _is_=
> > deterministic. And not just for deterministic for TCP or UDP, but= for
> > _any_ protocol, combination of EH, encryptions, etc. that a packe= t
> > carries. See RFC6438.
> >
> >> In short using options forwarding gets impacted for EH. You s= till want to push for it go by all means but don't expect a silicon ven= dor or deployment to agree for it.
> >
> > I'm not sure what we're trying to get agreement on. The o= nly
> > expectation we have is that vendors, and everyone else for that > > matter, conform to IETF standards. Extension headers have be defi= ned
> > for over twenty years and are full standard, and now that people = want
> > to use them there appears to be _some_ implementations (emphasis = on
> > the word "some") that seem to have a problem processing= them. Frankly,
> > that is a shortcoming of implementation, not of the protocol. The= only
> > protocol shortcoming that has thus far been identified in the IOA= M
> > discussion is the fact that EH don't exist in IPv4 and there = is really
> > no alternative that provides the necessary functionality-- this i= s
> > something I believe IETF can work on.
> >
> > Tom
> >
> >>
> >> -Jai
> >>
> >> =EF=BB=BFOn 4/5/19, 5:05 PM, "Tom Herbert" <tom= @herbertland.com> wrote:
> >>
> >>>=C2=A0 =C2=A0 On Fri, Apr 5, 2019 at 4:40 PM Jai Kumar <= ;jai.kumar@broadcom.com> wrote:
> >>>
> >>> Tom,
> >>>
> >>>
> >>>
> >>> You are right. There are two main cases where accessibili= ty of transport header becomes an issue. And that is mainly because of curr= ent generation of fixed pipeline cell based architecture parse depth (not s= o much an issue for high end NPU where next packet header bytes can be DMA= =E2=80=99ed in, though it impacts the performance. For eg. Cisco QFP NPU, E= Z Chip, Juniper=E2=80=99s MX 3D NPU, or Broadcom=E2=80=99s Jerricho NPU ). = This was mentioned earlier by Mikael as well.
> >>>
> >>>
> >>>
> >>> Case 1. SRv6
> >>>
> >>> Case 2. IPv6 with EH (mainly for 5G deployments where RH,= DH, and IFA Header)
> >>>
> >>>
> >>>
> >>> Typically NPUs provide capability that it will handle 3 o= r 4 EH or SRH without performance penalty. With the presence of IFA header = this means that for eg there can be only 2 or 3 SRH or EH. This is same as = in MPLS label stack depth handling (PUSH or POP at PE router). Given the ev= olution SRV6 and MPLS-SR kind of headers, silicon vendors have taken a noti= ce of it and are evolving the silicon arch to handle more chained headers.<= br> > >>>
> >>>
> >>>
> >>> IFA supports fragmentation of metadata stack and also pos= tcard mode so beyond the transport header it=E2=80=99s not an issue.
> >>>
> >>>
> >>>
> >>> Just a quick feedback on using IPv6 options, inserting ho= p by hop options for data path processing pushes the EH further down and im= pacts the node=E2=80=99s forwarding function (say if it is not able to reac= h Destination EH) vs if IFA header is the last EH then atmost transit node = do not perform metadata collection which can be identified.
> >>
> >>=C2=A0 =C2=A0 Maybe it does impact it, maybe it doesn't. I= t clearly depends on the
> >>=C2=A0 =C2=A0 device capabilities. For a device with a parsing= buffer of 256 bytes
> >>=C2=A0 =C2=A0 that should be plenty of room for HBH options, S= R header, transport
> >>=C2=A0 =C2=A0 layer, etc.
> >>
> >>>
> >>>
> >>>
> >>> -Jai
> >>>
> >>>
> >>>
> >>> From: Tom Herbert <tom@herbertland.com>
> >>> Date: Friday, April 5, 2019 at 3:34 PM
> >>> To: Jai Kumar <jai.kumar@broadcom.com>
> >>> Cc: "Pengshuping (Peng Shuping)" <pengsh= uping@huawei.com>, 6man <ipv6@ietf.org>, ippm <ippm@ietf.org= >, "C. M. Heard" <heard@pobox.com>, Mikael Abrahamsson = <swmike@swm.pp.se>
> >>> Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-de= ployment-00 feedback (Re: v6 option types for IOAM data fields)
> >>>
> >>>
> >>>
> >>> Jai,
> >>>
> >>>
> >>>
> >>> You might want to consider how IFA works in the presence = of segment routing. The second someone puts an SRH in the packet the IFA he= aders get pushed down and the transport headers end up being deep in the pa= cket anyway so that all the effort of IFA is nullified. If the requirement = is to ensure that the transport layer information appear as early as possib= le in the packet, one could define a Hop-by-Hop option to carry some sort o= f pseudo header for the transport layer. This also would work in the case t= hat the actual transport layer is obfuscated.
> >>>
> >>>
> >>>
> >>> Tom
> >>>
> >>>
> >>>
> >>> On Fri, Apr 5, 2019, 3:09 PM Jai Kumar <jai.kumar@= broadcom.com> wrote:
> >>>
> >>> =E2=80=9CThat is going to require justifying the protocol= even in light of shortcomings in existing protocoIs.=E2=80=9D
> >>>
> >>>
> >>>
> >>> Agreed !!! True for any proposal.
> >>>
> >>>
> >>>
> >>> -Jai
> >>>
> >>>
> >>>
> >>> From: Tom Herbert <tom@herbertland.com>
> >>> Date: Friday, April 5, 2019 at 2:34 PM
> >>> To: Jai Kumar <jai.kumar@broadcom.com>
> >>> Cc: "Pengshuping (Peng Shuping)" <pengsh= uping@huawei.com>, 6man <ipv6@ietf.org>, ippm <ippm@ietf.org= >, "C. M. Heard" <heard@pobox.com>, Mikael Abrahamsson = <swmike@swm.pp.se>
> >>> Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-de= ployment-00 feedback (Re: v6 option types for IOAM data fields)
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Fri, Apr 5, 2019, 2:07 PM Jai Kumar <jai.kumar@= broadcom.com> wrote:
> >>>
> >>> Tom,
> >>>
> >>> Its all explained in the requirements section of the draf= t. IFA header is essentially treated as an EH both in IPv4 and IPv6 (very s= imilar to AH/ESP EH).
> >>>
> >>> Just like in AH/ESP the IP protocol is copied in the AH h= eader and IP protocol field is replaced in the IP header with the AH proto.=
> >>>
> >>> There are several advantages to this approach.
> >>> - devise know how to parse AH header and can follow very = similar approach
> >>> - Protocol agnostics, silicon need not support N encaps (= just like AH/ESP). Single implementation works for all protocol types.
> >>> - No need to creation options and teach devices that opti= ons is NOT an exception path processing
> >>> - Really worry about ordering in IPv6 options
> >>> - Note that all the OAM data need to be deleted as well s= o position need to be optimal for removal. We can always do tail stamping o= f the data but this puts considerable constrains on the cell based architec= ture
> >>> - L4 accessibility I have already mentioned
> >>>
> >>> I am happy to discuss with you in person and explain more= but bottom line is that this proposal is what came out with MSDC discussio= ns in light of shortcomings from other IETF proposals.
> >>>
> >>>
> >>>
> >>> As they say, you are free to run whatever you want in you= r proprietary network, but if you expect to create an interoperable, deploy= able protocoI and get a protocol number assignment, you'll need to work= in ietf. That is going to require justifying the protocol even in light of= shortcomings in existing protocoIs.
> >>>
> >>>
> >>>
> >>> Tom
> >>>
> >>>
> >>>
> >>>
> >>> Regards,
> >>> -Jai
> >>>
> >>>
> >>> =EF=BB=BFOn 4/5/19, 12:28 PM, "Tom Herbert" <= ;tom@herbertland.com> wrote:
> >>>
> >>>>=C2=A0 =C2=A0 On Fri, Apr 5, 2019 at 12:03 PM Jai Kuma= r <jai.kumar@broadcom.com> wrote:
> >>>>
> >>>> " Great, but this IETF"
> >>>> Does it mean that drafts have no relevance to deploym= ent and actual adoption.
> >>>>
> >>>> For all your queries please take a look at IFA draft.=
> >>>> https://datat= racker.ietf.org/doc/draft-kumar-ippm-ifa/
> >>>>
> >>>=C2=A0 =C2=A0 I've looked at that draft. It's is c= reating a complete new IP
> >>>=C2=A0 =C2=A0 protocolas well as a new packet format for T= CP and UDP that somehow
> >>>=C2=A0 =C2=A0 inserts meta data between the TCP header and= payload. I don't
> >>>=C2=A0 =C2=A0 understand why this could possibly be better= than just using flow
> >>>=C2=A0 =C2=A0 label for ECMP and teaching devices that nee= d to extract transport
> >>>=C2=A0 =C2=A0 information how to walk over EH, or just usi= ng some UDP encpasulation
> >>>=C2=A0 =C2=A0 like in draft-herbert-ipv4-udpencap-eh-01. > >>>
> >>>=C2=A0 =C2=A0 Tom
> >>>
> >>>> It handles IPv6, IPv4 TCP/UDP with altering the packe= t path (due to inserting options and/or encaping them in GRE header) as wel= l as IPSec AH/ESP/WESP both tunnel and transport and guess what it is succe= ssfully deployed.
> >>>>
> >>>> -Jai
> >>>>
> >>>> =EF=BB=BFOn 4/5/19, 11:54 AM, "Tom Herbert"= <tom@herbertland.com> wrote:
> >>>>
> >>>>>=C2=A0 =C2=A0 On Fri, Apr 5, 2019 at 11:25 AM Jai = Kumar <jai.kumar@broadcom.com> wrote:
> >>>>>
> >>>>> Tom,
> >>>>>
> >>>>> I am speaking based on the actual deployment not = based on if all the traffic is/will move to IPSec tunnel.
> >>>>>
> >>>>> I have 6 large customer deployments and one someo= ne previously called as "Yahoo" who insist on visibility in L4 ev= en for IOAM packets.
> >>>>>
> >>>>=C2=A0 =C2=A0 And I've worked in datcenters much l= arger, and my first rule is that I
> >>>>=C2=A0 =C2=A0 don't want random router vendors dic= tating to me what protocols I'm
> >>>>=C2=A0 =C2=A0 allowed to use in my datacenter.
> >>>>
> >>>>> I can quote you on that and lose my business :-)<= br> > >>>>>
> >>>>> ECMP argument is weak as well as it works for IPv= 6 flow label. What about IPv4 TCP/UDP traffic which typically is 80% of the= traffic in MSDC.
> >>>>>
> >>>>
> >>>>=C2=A0 =C2=A0 draft-herbert-ipv4-udpencap-eh-01
> >>>>
> >>>>> If someone tells me that proposal will work only = for my 20% of traffic then again as I said before, they will lose my busine= ss :-)
> >>>>>
> >>>>=C2=A0 =C2=A0 Great, but this IETF. Where are the prot= ocol requirements? If you are
> >>>>=C2=A0 =C2=A0 saying that there are requirements for &= quot;visibility in L4" what are
> >>>>=C2=A0 =C2=A0 they? If you are saying that ACLs are no= w required for packet
> >>>>=C2=A0 =C2=A0 forwarding, where is that described? Is = it a MUST that teh only
> >>>>=C2=A0 =C2=A0 transport protocols we're allowed to= use are=C2=A0 UDP or TCP? Are we
> >>>>=C2=A0 =C2=A0 allowed to use extension headers at all?= I suppose fragmentation is
> >>>>=C2=A0 =C2=A0 right out... Are we violating the requir= ements if we encrypt the
> >>>>=C2=A0 =C2=A0 transport headers? If you say that we sh= ouldn't send long headers
> >>>>=C2=A0 =C2=A0 because we'll overflow parsing buffe= rs, then what is the limit? Please
> >>>>=C2=A0 =C2=A0 be SPECIFC in setting requirements; we a= re trying to build protocols
> >>>>=C2=A0 =C2=A0 that work and are interoperable and we n= eed to get out of this morass
> >>>>=C2=A0 =C2=A0 of reverse engineering to discover the l= east common denominator.
> >>>>
> >>>>=C2=A0 =C2=A0 Tom
> >>>>
> >>>>> Regards,
> >>>>> -Jai
> >>>>>
> >>>>> =EF=BB=BFOn 4/5/19, 11:15 AM, "Tom Herbert&q= uot; <tom@herbertland.com> wrote:
> >>>>>
> >>>>>>=C2=A0 =C2=A0 On Fri, Apr 5, 2019 at 10:55 AM = Jai Kumar <jai.kumar@broadcom.com> wrote:
> >>>>>>
> >>>>>> Even if we use flow label for ECMP, lack of a= ccessibility of L4 information (for various services, most simple is ACL) m= akes the proposal pretty much unusable.
> >>>>>>
> >>>>>=C2=A0 =C2=A0 That is convoluting router and firew= all functionality and
> >>>>>=C2=A0 =C2=A0 requirements. This a discussion abou= t packet forwarding which does
> >>>>>=C2=A0 =C2=A0 _not_ require ACLs. In a limited dom= ain, for which IOAM is intended,
> >>>>>=C2=A0 =C2=A0 it is unlikely that they'll ACLs= would be used in internal nodes, but
> >>>>>=C2=A0 =C2=A0 we do need good ECMP routing at all = intermediate nodes need to be
> >>>>>=C2=A0 =C2=A0 consistent rather or not that the IO= AM option is present. As side
> >>>>>=C2=A0 =C2=A0 note, the ability to extract L4 info= rmation out of packets is
> >>>>>=C2=A0 =C2=A0 dwindling anyway thanks to encryptio= n and other techniques trying to
> >>>>>=C2=A0 =C2=A0 undo protocol ossification. For inst= ance, good luck getting L4
> >>>>>=C2=A0 =C2=A0 information out of an IPsec tunnel := -).
> >>>>>
> >>>>>=C2=A0 =C2=A0 Tom
> >>>>>
> >>>>>> NIC cards are not used pervasively for ACLs a= nd other services, I believe iptables in kernel are good enough for host bu= t that=E2=80=99s not acceptable in networking elements.
> >>>>>>
> >>>>>> -Jai
> >>>>>>
> >>>>>> =EF=BB=BFOn 4/5/19, 10:31 AM, "ippm on b= ehalf of Tom Herbert" <ippm-bounces@ietf.org on behalf of t= om@herbertland.com> wrote:
> >>>>>>
> >>>>>>=C2=A0 =C2=A0 On Fri, Apr 5, 2019 at 9:16 AM P= engshuping (Peng Shuping)
> >>>>>>=C2=A0 =C2=A0 <pengshuping@huawei.com> wrote:
> >>>>>>>
> >>>>>>> Hi Barak,
> >>>>>>>
> >>>>>>> We are certainly not designing for the lo= west capable solutions but exploring optimal solutions which could help to = keep the forwarding performance while inserting the iOAM data with variable= length.
> >>>>>>
> >>>>>>=C2=A0 =C2=A0 Shuping,
> >>>>>>
> >>>>>>=C2=A0 =C2=A0 That's exactly the argument = for using the flow label in ECMP.
> >>>>>>=C2=A0 =C2=A0 Efficeint packet forwarding can = be done solely by inspected the forty
> >>>>>>=C2=A0 =C2=A0 byte fixed length header of the = packet regardless of the contents of
> >>>>>>=C2=A0 =C2=A0 the rest of the packet. That is = an optimal solution. Anything else for
> >>>>>>=C2=A0 =C2=A0 ECMP like doing DPI or hacking u= p IOAM to try do pull transport layers
> >>>>>>=C2=A0 =C2=A0 into the parsing buffer (whateve= r size that may be) are nothing more
> >>>>>>=C2=A0 =C2=A0 than hacks and unnecessarily per= petuate techniques used with IPv4 that
> >>>>>>=C2=A0 =C2=A0 either don't work or are unn= ecessary in IPv6.
> >>>>>>
> >>>>>>=C2=A0 =C2=A0 Tom
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> In terms of the forwarding efficiency, we= would all agree that a short and fixed header would be better than a varia= ble header.
> >>>>>>>
> >>>>>>> Best regards
> >>>>>>> Shuping
> >>>>>>>
> >>>>>>>
> >>>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9A Bara= k Gafni<gbarak@mellanox.com>
> >>>>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9A Peng= shuping (Peng Shuping)<pengshuping@huawei.com>;Frank Brockne= rs (fbrockne)<fbrockne@cisco.com>;Mikael Abrahamsson<swmike@sw= m.pp.se>
> >>>>>>> =E6=8A=84=E9=80=81=EF=BC=9A C. M. Heard&l= t;h= eard@pobox.com>;6man WG<ipv6@ietf.org>;Mark Smith<mar= kzzzsmith@gmail.com>;ippm<ippm@ietf.org>
> >>>>>>> =E4=B8=BB=E9=A2=98=EF=BC=9A RE: draft-ioa= metal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for I= OAM data fields)
> >>>>>>> =E6=97=B6=E9=97=B4=EF=BC=9A 2019-04-05 03= :18:26
> >>>>>>>
> >>>>>>> Hi Shuping,
> >>>>>>> I think that the question is whether we d= esign for the lowest capable solutions. I assume someone can find solutions= with even lower amount of parsing.. The low end solutions for these capabi= lities may need to either adopt with new designs or use solutions such as w= hat is suggested in this thread by Tom Herbert.
> >>>>>>> Personally, I don't think we should g= o this way, but to design appropriate solutions, with appropriate layers in= the headers. For example, prevent dependencies between "remote" = headers.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Barak
> >>>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: ippm <ippm-bounces@ietf.org> On Behalf Of Pengshuping (Peng Shuping)
> >>>>>>> Sent: Wednesday, April 3, 2019 6:47 AM > >>>>>>> To: Frank Brockners (fbrockne) <fbrock= ne@cisco.com>; Mikael Abrahamsson <swmike@swm.pp.se>
> >>>>>>> Cc: C. M. Heard <heard@pobox.com>;= 6man WG <ipv6@ietf.org>; Mark Smith <markzzzsmith@gmail.com>; ippm@ietf.org
> >>>>>>> Subject: [ippm] =E7=AD=94=E5=A4=8D: draft= -ioametal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types f= or IOAM data fields)
> >>>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> The parsing depth of the early chips is 9= 6B/128B. For the new chips the parsing depth has been increased but still l= imited. So Mikael's concern makes sense especially in the tracing mode = that the IOAM data fields are going to increase significantly along the pat= h, which will even push the Routing Header out of the parsing depth of the = chip. So it would make sense to split the IOAM data part from the IOAM head= er/instruction part, and place the IOAM data after the RH or even after the= L4 header in order to be able to read the L4 information to enable ECMP, a= s stated in the draft https://eur03= .safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.ietf.org%2Fhtm= l%2Fdraft-li-6man-ipv6-sfc-ifit-00&amp;data=3D02%7C01%7Cgbarak%40mellan= ox.com%7C612ba6dc117440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461= b%7C0%7C0%7C636898960379485833&amp;sdata=3DDob4zN%2F1jSGxLTlqGma29JJNvq= JDBt4VzqHsN4OpxM4%3D&amp;reserved=3D0.
> >>>>>>>
> >>>>>>> BR,
> >>>>>>> Shuping
> >>>>>>>
> >>>>>>>
> >>>>>>> -----=E9=82=AE=E4=BB=B6=E5=8E=9F=E4=BB=B6= -----
> >>>>>>> =E5=8F=91=E4=BB=B6=E4=BA=BA: ippm [mailto= :ippm-bounces@ietf.org] =E4=BB=A3=E8=A1=A8 Frank Brockners (fbrockne= )
> >>>>>>> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 201= 9=E5=B9=B44=E6=9C=882=E6=97=A5 17:40
> >>>>>>> =E6=94=B6=E4=BB=B6=E4=BA=BA: Mikael Abrah= amsson <swmike@swm.pp.se>
> >>>>>>> =E6=8A=84=E9=80=81: C. M. Heard <heard@po= box.com>; 6man WG <ipv6@ietf.org>; Mark Smith <markzzzsm= ith@gmail.com>; ippm@ietf.org
> >>>>>>> =E4=B8=BB=E9=A2=98: Re: [ippm] draft-ioam= etal-ippm-6man-ioam-ipv6-deployment-00 feedback (Re: v6 option types for IO= AM data fields)
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Mikael Abrahamsson <swmike@swm.pp.= se>
> >>>>>>> Sent: Dienstag, 2. April 2019 08:06
> >>>>>>> To: Frank Brockners (fbrockne) <fbrock= ne@cisco.com>
> >>>>>>> Cc: Mark Smith <markzzzsmith@gmail= .com>; C. M. Heard <heard@pobox.com>; 6man WG <ipv6@ietf.org>; ippm@ietf.org
> >>>>>>> Subject: RE: draft-ioametal-ippm-6man-ioa= m-ipv6-deployment-00 feedback (Re: v6 option types for IOAM data fields) > >>>>>>>
> >>>>>>>> On Mon, 1 Apr 2019, Frank Brockners (= fbrockne) wrote:
> >>>>>>>>
> >>>>>>>> ...FB: There is obviously no easy ans= wer. Couple of thoughts:
> >>>>>>>> * IOAM is considered a "domain s= pecific" feature (see
> >>>>>>>> draft-ietf-ippm-ioam-data-05, section= 3). Routers in the IOAM domain
> >>>>>>>> should be IOAM capable.=C2=A0 And IMH= O,=C2=A0 we should add a statement to
> >>>>>>>> draft-ioametal-ippm-6man-ioam-ipv6-de= ployment that an implementation
> >>>>>>>> of IOAM MUST ensure "C1". > >>>>>>>>
> >>>>>>>> * That said, there can be situations,= where C1 cannot be achieved, e.g..
> >>>>>>>> consider a network which does ECMP sc= heduling based on packet length.
> >>>>>>>>
> >>>>>>>> * What one could consider - and which= is one suggested deployment
> >>>>>>>> model
> >>>>>>>> - is that by default IOAM data fields= are added to _all_ customer
> >>>>>>>> packets. The decapsulating node would= decide whether the IOAM
> >>>>>>>> information contained in a packet wou= ld be used (and exported) or not.
> >>>>>>>> That way one would not need to deal w= ith the situation that some
> >>>>>>>> traffic carries IOAM while other does= not - and might thus be treated
> >>>>>>>> differently.
> >>>>>>>
> >>>>>>> Yes, I think this is the only way. Is the= re a risk that intermediate routers would not be IOAM capable? I think the = C1 requirement is really really hard to fulfil and I'm also afraid that= adding the IOAM header will actually make ECMP stop working on some platfo= rms (because they would not have the capability to look deep enough into th= e packet to find L4 information, so it'll go back to 2 tuple ECMP inste= ad of 5 tuple.
> >>>>>>>
> >>>>>>> But this question can only be answered by= people with deep NPU knowledge...
> >>>>>>>
> >>>>>>> .....FB2: Given that IOAM is a domain spe= cific feature - I expect that folks initially start to use it in domains (l= ike e.g. a DC) where all boxes are IOAM capable and can trace the packet ap= propriately - or per Tom's note, can be configured so that one would do= ECMP based on addresses and flow-label.=C2=A0 There are chips with pretty = deep parsing capability (up to a few hundred bytes).
> >>>>>>>
> >>>>>>>> ...FB: The comparison to MPLS is inte= resting. How often do MPLS
> >>>>>>>> packets leak and cause harm? For IOAM= ,
> >>>>>>>> draft-ioametal-ippm-6man-ioam-ipv6-op= tions-02 proposes a deployment
> >>>>>>>> model similar to what we do for MPLS:= Unless an interface is
> >>>>>>>> explicitly configured for IOAM, packe= ts with IOAM data fields MUST be dropped.
> >>>>>>>> Hence leakage would only occur, if we= have a clearly misbehaving
> >>>>>>>> router which violates this rule. Simi= lar to you, I'd also greatly
> >>>>>>>> appreciate any pointers to research o= n how common MPLS leaked packets are.
> >>>>>>>
> >>>>>>> When it comes to "cause harm" I= imagine there are (at least) two ways to cause harm, one is privacy/secrec= y/security loss and the other one is actual operational loss.
> >>>>>>>
> >>>>>>> I know of bugs where labeled packets went= the wrong way and caused them to be lost, I've also seen bugs where bu= gs caused traffic to "hop" between VRFs in MPLS VPN (or to "= global" VRF). I don't have numbers on this though.
> >>>>>>>
> >>>>>>> Depending on the deployment scenario, it = might make sense to make IOAM packets not valid for non-IOAM aware devices = (basically encap entire packet/payload), but that might be a problem for in= termediate non-IOAM nodes then. This would affect the ECMP requirement. I c= an see cases where one would operationally turn on IOAM for some customers = traffic and then see the problem go away because now ECMP changed.
> >>>>>>>
> >>>>>>>> ...FB: One idea that Shwetha came up = with to identify the source AS of
> >>>>>>>> a leaked packet, would be to add a ne= w new IOAM E2E option - as
> >>>>>>>> proposed in section 5.1.1 bullet 2 of=
> >>>>>>>> draft-ioametal-ippm-6man-ioam-ipv6-de= ployment-01.
> >>>>>>>
> >>>>>>> Yes, that'd solve that problem.
> >>>>>>>
> >>>>>>> How much has the silicon people been invo= lved so far in the design of the headers? What is the current thinking of a= mount of data going into the IOAM header? Considering things like trace opt= ions etc it seems to me the header can grow quite large? To satisfy the ECM= P requirement what about putting the IOAM information as a trailer behind t= he regular payload? Or is there a problem for the hw to manipulate informat= ion that far into the packet (I also imagine this will considerably lower t= he forwarding performance of IOAM packets on IOAM aware platforms).
> >>>>>>>
> >>>>>>> .....FB2: There are quite a few folks wit= h hardware background that co-author the IOAM drafts. Parsing capability di= ffers between chips, as does the ability to deal with new/flexible headers = and the ability to modify data in the extension headers. So the unfortunate= answer to that question is "it depends" (what information do you= gather, how large is your domain, what are the capabilities of your hardwa= re/software forwarder, etc.), but I do expect that for specific deployment = domains (e.g. DC, Enterprise) - but also for overlay networks / VPNs - we&#= 39;ll see an increasing amount of chips that are well suited for processing= large extension header.
> >>>>>>>
> >>>>>>> Cheers, Frank
> >>>>>>>
> >>>>>>> --
> >>>>>>> Mikael Abrahamsson=C2=A0 =C2=A0 email: swmi= ke@swm.pp.se
> >>>>>>>
> >>>>>>> _________________________________________= ______
> >>>>>>> ippm mailing list
> >>>>>>> ippm@ietf.org
> >>>>>>> https://eur03.saf= elinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2= Flistinfo%2Fippm&amp;data=3D02%7C01%7Cgbarak%40mellanox.com%7C612ba6dc1= 17440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636898= 960379485833&amp;sdata=3DVjZ1PiwifYGCf159je0yef3BJFz6AQNNAtkgmAMDFKM%3D= &amp;reserved=3D0
> >>>>>>> _________________________________________= ______
> >>>>>>> ippm mailing list
> >>>>>>> ippm@ietf.org
> >>>>>>> https://eur03.saf= elinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2= Flistinfo%2Fippm&amp;data=3D02%7C01%7Cgbarak%40mellanox.com%7C612ba6dc1= 17440e68c4608d6b83ae174%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636898= 960379485833&amp;sdata=3DVjZ1PiwifYGCf159je0yef3BJFz6AQNNAtkgmAMDFKM%3D= &amp;reserved=3D0
> >>>>>>> -----------------------------------------= ---------------------------
> >>>>>>> IETF IPv6 working group mailing list
> >>>>>>> ipv6@ietf.org
> >>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>>>>>> -----------------------------------------= ---------------------------
> >>>>>>
> >>>>>>=C2=A0 =C2=A0 ________________________________= _______________
> >>>>>>=C2=A0 =C2=A0 ippm mailing list
> >>>>>>=C2=A0 =C2=A0 ippm@ietf.org
> >>>>>>=C2=A0 =C2=A0 http= s://www.ietf.org/mailman/listinfo/ippm
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>
> >>
> >>
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> = ipv6@ietf.org
> Administrative Requests: https://www.ietf.= org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--000000000000aceddf0585e4a791-- From nobody Mon Apr 8 05:40:59 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2805E1202EA; Mon, 8 Apr 2019 05:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=iCVkBoPl; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=H1dtQOmQ 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 Jm1HugXpVFMu; Mon, 8 Apr 2019 05:40:46 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C961F1203E6; Mon, 8 Apr 2019 05:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7090; q=dns/txt; s=iport; t=1554727245; x=1555936845; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=mMlltHxATSz4xX9dXj6pt52qaQ+RwsBlo3xJfq219ZE=; b=iCVkBoPlp+MsiXRhjFU2nF7iokeKWH7s/ILTsaY+4lobrL6D31ttJWVf egsozD9XJoaVGa2ZtK/2Z8QgXb1KxI6BHCjN2TZHTbaG1LcnJd+ohjEic ltksRlLYCC7qzCoFl0erRGg+MvuQCd/qHfr7gTFFvij9AjKUxtxyi69b1 Q=; IronPort-PHdr: =?us-ascii?q?9a23=3AUhOxDBduL1eN8h99ROQmTjHJlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGQD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/YSYgG89BUlJN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAAA8QKtc/5pdJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgT0pJwNoVCAECycKhASDRwOEUopUgle?= =?us-ascii?q?JOI1ggS6BJANUDgEBGA0HhEACF4VOIjQJDQEBAwEBCQECAQJtHAyFSgEBAQE?= =?us-ascii?q?DAQEhEQwBASUHCwELBAIBCBEEAQEBAgIjAwICAh8GCxQBCAgCBAENBQiDG4F?= =?us-ascii?q?dAxUBAgyiLAKKFHGBL4J5AQEFgTEBAwICgz8NC4IMAwWBCyUBi0YXgUA/gRF?= =?us-ascii?q?Ggkw+gQSBFkcBAQOBNymDCDGCJopgD4InmD02CQKIAYg8g16CBYYWjEGLU4Y?= =?us-ascii?q?igUSMGAIEAgQFAg4BAQWBTziBVnAVO4JsggqBJAEBgkmFFIU/cgGBJ4x3gS4?= =?us-ascii?q?BgR8BAQ?= X-IronPort-AV: E=Sophos;i="5.60,325,1549929600"; d="scan'208";a="256627983" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Apr 2019 12:40:44 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x38Cei5l017509 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Apr 2019 12:40:44 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Apr 2019 07:40:43 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Apr 2019 07:40:43 -0500 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 8 Apr 2019 08:40:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mMlltHxATSz4xX9dXj6pt52qaQ+RwsBlo3xJfq219ZE=; b=H1dtQOmQiq4nPNjql8Zr9y/vp5vgn9LK34PV+zQjWfakRMbw4k7E9eBGe9i06+0PuSCeMhq8Ms2hie9sOWANGqEgAohuXvXXeuQhoaNdeS10uVwIk/47Tk2mTAU0byKD+xGRHDsD2lpthIdeU6UKPhtVGK4lMQaQ7DnYflJHKl8= Received: from MN2PR11MB3629.namprd11.prod.outlook.com (20.178.252.31) by MN2PR11MB3712.namprd11.prod.outlook.com (20.178.253.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.15; Mon, 8 Apr 2019 12:40:41 +0000 Received: from MN2PR11MB3629.namprd11.prod.outlook.com ([fe80::ad94:267b:a12e:1a64]) by MN2PR11MB3629.namprd11.prod.outlook.com ([fe80::ad94:267b:a12e:1a64%2]) with mapi id 15.20.1771.016; Mon, 8 Apr 2019 12:40:41 +0000 From: "Frank Brockners (fbrockne)" To: "Shwetha Bhandari (shwethab)" , Brian E Carpenter , Mark Smith CC: 6man WG , "ippm@ietf.org" Thread-Topic: draft-ioametal-ippm-6man-ioam-ipv6-options and RFC4302 Thread-Index: AQHU7ZsQBNpblfNakEeVkMFddv/mRqYxZEuAgAAcGACAALLEAIAAAhew Date: Mon, 8 Apr 2019 12:40:41 +0000 Message-ID: References: <3b1c3ecb-960f-2294-9943-e01a8ef80f27@gmail.com> <21B42A6C-AB87-42C1-B315-4B5FEE770542@cisco.com> In-Reply-To: <21B42A6C-AB87-42C1-B315-4B5FEE770542@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=fbrockne@cisco.com; x-originating-ip: [173.38.220.59] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1a7e69da-e185-4577-6b5c-08d6bc1f693c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:MN2PR11MB3712; x-ms-traffictypediagnostic: MN2PR11MB3712: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(396003)(136003)(366004)(13464003)(189003)(199004)(8676002)(316002)(86362001)(81166006)(14454004)(966005)(81156014)(6116002)(3846002)(106356001)(5660300002)(105586002)(2906002)(478600001)(66066001)(52536014)(9686003)(486006)(6306002)(55016002)(6246003)(53936002)(7696005)(4326008)(305945005)(6506007)(71200400001)(561944003)(11346002)(26005)(25786009)(68736007)(186003)(446003)(99286004)(53546011)(102836004)(76176011)(74316002)(476003)(7736002)(256004)(14444005)(6436002)(229853002)(33656002)(97736004)(8936002)(93886005)(71190400001)(110136005)(54906003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3712; H:MN2PR11MB3629.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: mvVP0rUyMOLx25ri5OFVRzc2uAJYLmGZKzNjbo/+0LykYh4YxXazBIio1XzhI64yqh/nKWXFHDE1JQKwwKEMWa3YmYXPy7o177U3pHqWElF5H2Yr7jgRNMFXiNWZEcaZ8xQnI5BqFzEuQUDkrYHkWRmqwoFR35ENXJV00y+WskFYWcnXvAmKItaDo+X4fkGArYuwgWUFr4mnpFGK3Go1bpdONu+FLLB9Lx9hXfp0Qn7OQtjOMOS9Om8rHjtUSRxNh5zhZDbJpktjZC5q7DSQTrxxg0aAZo0FiqMf5GXWEeWRXA4tZrvKFTmyukLLqm4WZFFacAkzwrHBibaAlbpBFcHvcpeqclBvSujPHPTpvE15AaIPMzZBd+jjVAeGc76QNGqagik4i+AJrTVYVZL1jGi1fz2k2WkVem7ztB1gTYo= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1a7e69da-e185-4577-6b5c-08d6bc1f693c X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2019 12:40:41.3588 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3712 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.23, xch-aln-013.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [ippm] draft-ioametal-ippm-6man-ioam-ipv6-options and RFC4302 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 12:40:52 -0000 Q2MnaW5nIElQUE0gYXMgd2VsbC4gDQoNCkZyYW5rDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogaXB2NiA8aXB2Ni1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2Yg U2h3ZXRoYSBCaGFuZGFyaSAoc2h3ZXRoYWIpDQo+IFNlbnQ6IE1vbnRhZywgOC4gQXByaWwgMjAx OSAxNDozMw0KPiBUbzogQnJpYW4gRSBDYXJwZW50ZXIgPGJyaWFuLmUuY2FycGVudGVyQGdtYWls LmNvbT47IE1hcmsgU21pdGgNCj4gPG1hcmt6enpzbWl0aEBnbWFpbC5jb20+DQo+IENjOiA2bWFu IFdHIDxpcHY2QGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogZHJhZnQtaW9hbWV0YWwtaXBwbS02 bWFuLWlvYW0taXB2Ni1vcHRpb25zIGFuZCBSRkM0MzAyDQo+IA0KPiBKdXN0IHRvIGNsYXJpZnkg b24gdGhlIGluY3JlbWVudGFsIHRyYWNpbmcsIGRyYWZ0LWlldGYtaXBwbS1pb2FtLWRhdGENCj4g W2h0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlwcG0taW9hbS1kYXRhLTA1 XSBkZWZpbmVzIHRyYWNpbmcgdGhhdA0KPiBjYW4gYmUgYWNoaWV2ZWQgaW4gMyBtb2RlczoNCj4g MS4gUHJlLWFsbG9jYXRlZCBUcmFjZSBbU2VjdGlvbiA0LjIuMV06IHRoYXQgZG9lcyBub3QgY2hh bmdlIHRoZSBzaXplIG9mIHRoZSB0cmFjZQ0KPiBvcHRpb24gaW4gdHJhbnNpdC4NCj4gMi4gSW5j cmVtZW50YWwgVHJhY2UgW1NlY3Rpb24gNC4yLjJdOiB3aGljaCB3YXMgZGVzaWduZWQgYmFzZWQg b24gaGFyZHdhcmUNCj4gcHJvdG90eXBpbmcgYW5kIG9wdGltaXphdGlvbiB0byBpbnNlcnQgdHJh Y2UgZGF0YSBhdCBmaXhlZCBvZmZzZXQgZnJvbSB0aGUgaGVhZGVyDQo+IGFuZCBncm93IHRoZSBv cHRpb24gaW4gdHJhbnNpdC4NCj4gMy4gV2UgYWxzbyBoYXZlIGFub3RoZXIgbW9kZSBvZiB0cmFj aW5nIGJlaW5nIGRpc2N1c3NlZCBjYWxsZWQgSW1tZWRpYXRlDQo+IGV4cG9ydCBvciBQb3N0IGNh cmQgbW9kZSogdGhhdCBoYXMgbWluaW1hbCB0cmFjaW5nIGRhdGEgYWRkZWQgdG8gdGhlIG9wdGlv bi4NCj4gDQo+IE5vdCBhbGwgZW5jYXBzdWxhdGlvbiBvZiBJT0FNIGRhdGEgYXJlIGV4cGVjdGVk IHRvIHJlY29tbWVuZC9pbXBsZW1lbnQgYWxsDQo+IHRoZSBtb2RlcyBvZiB0cmFjaW5nLg0KPiBX ZSBjb3VsZCBub3QgZ2V0IHRvIHRoZSBkaXNjdXNzaW9uIGluIDZtYW4gYWJvdXQgaW5jcmVtZW50 YWwgdHJhY2Ugb3B0aW9uLA0KPiBwbGVhc2UgcmVmZXIgdG8gU2xpZGUgMTYgaW4NCj4gW2h0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDQvbWF0ZXJpYWxzL3NsaWRlcy0xMDQt Nm1hbi1zZXNzYi1pbi0NCj4gc2l0dS1vYW0taW9hbS1pbi1pcHY2LWFuZC1kZXBsb3ltZW50LWNv bnNpZGVyYXRpb25zLWZvci1pbi1zaXR1LW9hbS13aXRoLQ0KPiBpcHY2LW9wdGlvbnMtMDBdLiBC YXNlZCBvbiBmZWVkYmFjayB3ZSBjYW4gZGVjaWRlIGlmIHRoaXMgb3B0aW9uIG1ha2VzIHNlbnNl IGluDQo+IHY2IHJlcHJlc2VudGF0aW9uIG9mIElPQU0gdHJhY2UgZGF0YSBhdCBhbGwuDQo+IFdl IHdpbGwgZXhwYW5kIHRoZSBkaXNjdXNzaW9uIG9mIGluY3JlbWVudGFsIHRyYWNpbmcgYW5kIHRo ZSBjYXZlYXRzIGluIHRoZSBuZXh0DQo+IHJldmlzaW9uIG9mIGRyYWZ0LWlvYW1ldGFsLWlwcG0t Nm1hbi1pb2FtLWlwdjYtZGVwbG95bWVudC4NCj4gDQo+IFRoYW5rcywNCj4gU2h3ZXRoYQ0KPiAN Cj4gKiBJbW1lZGlhdGUgZXhwb3J0L1Bvc3QgY2FyZCBtb2RlIHRyYWNpbmcgOiBkb2VzIG5vdCBy ZXF1aXJlIHRoZSB0cmFjaW5nIGRhdGENCj4gdG8gYmUgY2FycmllZCB3aXRoaW4gdGhlIG9wdGlv biBpbiB0aGUgcGFja2V0LCBidXQgaGFzIGluc3RydWN0aW9ucyBvbiB3aGF0IHRvDQo+IGNvbGxl Y3QgYW5kIGV4cG9ydCB3aXRoIG1pbmltYWwgY29udGV4dCBmb3IgY29ycmVsYXRpb24uDQo+IGRy YWZ0LWlldGYtaXBwbS1pb2FtLWRhdGEtMDUg4oCTIEltbWVkaWF0ZSBleHBvcnQgZmxhZyBkcmFm dC1zb25nLWlwcG0tDQo+IHBvc3RjYXJkLWJhc2VkLXRlbGVtZXRyeQ0KPiANCj4g77u/T24gNC84 LzE5LCA3OjIzIEFNLCAiaXB2NiBvbiBiZWhhbGYgb2YgQnJpYW4gRSBDYXJwZW50ZXIiIDxpcHY2 LQ0KPiBib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBicmlhbi5lLmNhcnBlbnRlckBnbWFp bC5jb20+IHdyb3RlOg0KPiANCj4gICAgIFRvcC1wb3N0aW5nIGZvciBvbmUgcG9pbnQ6DQo+ICAg ICBBcyBmYXIgYXMgSSBhbSBhd2FyZSwgUkZDODIwMCBkb2VzICpub3QqIHN0YXRlIHRoYXQgdGhl DQo+ICAgICBvcHRpb24gZGF0YSBsZW5ndGggbXVzdCBub3QgYmUgY2hhbmdlZCBpbiBhIG11dGFi bGUNCj4gICAgIGhvcC1ieS1ob3Agb3B0aW9uLg0KPiANCj4gICAgIFJlZ2FyZHMNCj4gICAgICAg IEJyaWFuDQo+IA0KPiAgICAgT24gMDgtQXByLTE5IDEyOjEyLCBNYXJrIFNtaXRoIHdyb3RlOg0K PiAgICAgPg0KPiAgICAgPg0KPiAgICAgPiBPbiBNb24uLCA4IEFwci4gMjAxOSwgMDk6MzggQnJp YW4gRSBDYXJwZW50ZXIsDQo+IDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20gPG1haWx0bzpi cmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+PiB3cm90ZToNCj4gICAgID4NCj4gICAgID4gICAg IEhpLA0KPiAgICAgPg0KPiAgICAgPiAgICAgQXMgZmFyIGFzIEkgdW5kZXJzdGFuZCB0aGUgSU9B TSAiSW5jcmVtZW50YWwgVHJhY2UgT3B0aW9uIiBhbmQgdGhlDQo+ICAgICA+ICAgICBwcm9wb3Nl ZCBtYXBwaW5nIHRvIElQdjYgb3B0aW9ucywgdGhlIGRyYWZ0IHNlZW1zIHRvIGltcGx5IHRoYXQg YW4NCj4gICAgID4gICAgIElBT00gb3B0aW9uIG1pZ2h0IGdldCBiaWdnZXIgYXMgdGhlIHBhY2tl dCBmbG93cyB0aHJvdWdoIG11bHRpcGxlDQo+ICAgICA+ICAgICBJQU9NLWF3YXJlIHJvdXRlcnMu DQo+ICAgICA+DQo+ICAgICA+ICAgICAoSW4gZmFjdCBJIHNlZSB0aGF0IHRoaXMgaXMgY29uZmly bWVkIGV4cGxpY2l0bHkgaW4NCj4gICAgID4gICAgIGRyYWZ0LWlvYW1ldGFsLWlwcG0tNm1hbi1p b2FtLWlwdjYtZGVwbG95bWVudC4pDQo+ICAgICA+DQo+ICAgICA+ICAgICBUaGF0IGlzIGluIGRp cmVjdCBjb25mbGljdCB3aXRoIFJGQzQzMDIgKHBhZ2UgMjYpLCBzaW5jZSB0aGUgb3B0aW9uDQo+ ICAgICA+ICAgICBkYXRhIGxlbmd0aCBpcyBpbmNsdWRlZCBpbiB0aGUgSUNWIGNhbGN1bGF0aW9u LCBldmVuIGlmIHRoZSBvcHRpb24NCj4gICAgID4gICAgIGRhdGEgaXMgZXhjbHVkZWQuDQo+ICAg ICA+DQo+ICAgICA+ICAgICBJIGRvbid0IGtub3cgaWYgdGhhdCBpcyBhIHNob3cgc3RvcHBlciwg YnV0IGF0IHRoZSB2ZXJ5IGxlYXN0IHRoZSBkcmFmdA0KPiAgICAgPiAgICAgc2hvdWxkIHN0YXRl IHRoYXQgaXQgd2lsbCBicmVhayB0aGUgSVBzZWMgQXV0aGVudGljYXRpb24gSGVhZGVyIG1lY2hh bmlzbS4NCj4gICAgID4NCj4gICAgID4gICAgIEl0IHdpbGwgYWxzbyBwb3RlbnRpYWxseSBicmVh ayBQTVRVRC4gQWdhaW4sIEkgZG9uJ3Qga25vdyBpZiB0aGF0IHJlYWxseQ0KPiAgICAgPiAgICAg bWF0dGVycywgYnV0IEkgdGhpbmsgaXQgbmVlZHMgdG8gYmUgc3RhdGVkLg0KPiAgICAgPg0KPiAg ICAgPiAgICAgSSBhbHNvIG5vdGUgdGhhdCB0aGlzIHByb3Bvc2FsIGlzIGFub3RoZXIgZ29vZCBl eGFtcGxlIGZvcg0KPiAgICAgPiAgICAgZHJhZnQtY2FycGVudGVyLWxpbWl0ZWQtZG9tYWlucy4g V2UncmUgZ2V0dGluZyB0byB0aGUgcG9pbnQgd2hlcmUNCj4gICAgID4gICAgIG1vc3QgcHJvcG9z YWxzIGZvciBJUHY2IGV4dGVuc2lvbnMgYXJlIGxpbWl0ZWQtZG9tYWluIHByb3RvY29scy4NCj4g ICAgID4NCj4gICAgID4NCj4gICAgID4NCj4gICAgID4gQW5kIGV2ZW4gaW4gYSBsaW1pdGVkIGRv bWFpbiwgaWYgdGhlIHByb2Nlc3NpbmcgYmVoYXZpb3VyIGRvZXNuJ3QgY29tcGx5DQo+IHdpdGgg UkZDODIwMCwgdGhlbiBpdCBpc24ndCBJUHY2IGFueW1vcmUuDQo+ICAgICA+DQo+ICAgICA+IFBy b3RvY29sIHNwZWNzIGFyZW4ndCBqdXN0IHBhY2tldCBmb3JtYXRzIChvZiBjb3Vyc2UgaXQgd291 bGQgYmUgbXVjaCBlYXNpZXINCj4gZm9yIGV2ZXJ5Ym9keSBpZiB0aGV5IHdlcmUsIGJ1dCB0aGVu IHRoZXkgYXJlbid0IGEgcHJvdG9jb2wgLSBhbiBhZ3JlZW1lbnQgb24NCj4gYmVoYXZpb3VyLikN Cj4gICAgID4NCj4gICAgID4NCj4gICAgID4NCj4gICAgID4gICAgIFJlZ2FyZHMNCj4gICAgID4g ICAgICAgIEJyaWFuIENhcnBlbnRlcg0KPiAgICAgPg0KPiAgICAgPiAgICAgLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gICAgID4gICAgIElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiAgICAg PiAgICAgaXB2NkBpZXRmLm9yZyA8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+DQo+ICAgICA+ICAgICBB ZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9pcHY2DQo+ICAgICA+ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgICAgPg0KPiANCj4gICAgIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+ICAgICBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4g ICAgIGlwdjZAaWV0Zi5vcmcNCj4gICAgIEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gICAgIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBs aXN0DQo+IGlwdjZAaWV0Zi5vcmcNCj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K From nobody Sun Apr 14 22:54:24 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D946120159; Sun, 14 Apr 2019 22:54:22 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 M_FyPm6FjPYx; Sun, 14 Apr 2019 22:54:20 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A91112003E; Sun, 14 Apr 2019 22:54:20 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id w5so17752286qtb.11; Sun, 14 Apr 2019 22:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=uCljBfcz8AAl+52kHh9CQbsn/4Rti88eBTVkDyW9KSg=; b=ALPjHmrSp01cuJNiWMPD9tajoyvVRUbLrXs8RaOGEoyj8YHjS4bGNDzoYFNJ+rYX42 7Sy744uFH4ExksFAArmS3DwYPHJ5CJv0LYip+HLI/msRe1jhggTYMLj3BRXNhaE5/7eU yozpYN/GgD0Yg6bCtZvC1+OqTE66gz3q2KS35tvL3SDi/Iffu/TFRY6Ch107rvoYzYZ0 z/L3x3qYxXV1n9G6xlpjWGIgVFsCoaEmYnI8LmZqF5iMi3xQUws9ZMXbPkXM1IE83eed EAj5FB/D5GP3b4GP5dJGeKtGUmklqz0nMnWQ9Z1fa+tOC9hZ2LujxTtHQgebjwCdtOet sYgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=uCljBfcz8AAl+52kHh9CQbsn/4Rti88eBTVkDyW9KSg=; b=T/T52AyLgmjcDJKlfFaAcxv1BuROZKfUUAUYhVe1eAN+2nQQoTLHzaU6tsc4hwZuTU za46cfhylyDt/jCV9Xs3LV2N+SG/pMV5ZQvFQvNNT0DWVMRqxCwQWEpD0da9JzWrt6xU XJze5D5NQrCuRUyQHUQoE6HWvSIc5eLbWGo4VOJa1cBvUoKGWIv74l6VhM1q9y9u5B10 hTStXgtJBcNdVWhAgeX8JdutgDTOK6BsKlnd+Nw48SmlZi5PQYNnyCVye5GD2gxLvKlY VwGebaosh8bHQahaUI1c2kDrbRevwvoHpDCYiIp1giPi0CLMvKhJ5O1F1J4QCMYIdjZO trPA== X-Gm-Message-State: APjAAAWHm7fAb65wtql49h9BAwviJX7OFMiM3zPjpEvVfP0mVCHW9gcs 09mrJIW0fgFpBGOdFoDcjzqp2jkehdj7ISgf4Ew= X-Google-Smtp-Source: APXvYqwPnsJs2xvYP4tiwsVb3DC3Hdfa/9OcZXLol6Ubr8qT1Er0K16MrDIY7yD9U7RzvJpixLZh3z+w2aoV+zHLBLY= X-Received: by 2002:ac8:17ee:: with SMTP id r43mr58680266qtk.169.1555307659213; Sun, 14 Apr 2019 22:54:19 -0700 (PDT) MIME-Version: 1.0 From: Tal Mizrahi Date: Mon, 15 Apr 2019 08:54:08 +0300 Message-ID: To: Greg Mirsky , footer.foote@nokia.com, guo.jun2@zte.com.cn, Henrik Nydell , IETF IPPM WG Cc: ippm-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000008b411605868b4842" Archived-At: Subject: [ippm] Shepherd Review of draft-ietf-ippm-stamp-05 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 05:54:23 -0000 --0000000000008b411605868b4842 Content-Type: text/plain; charset="UTF-8" Dear Authors, Having reviewed the document, I found that it is clear and straightforward, and that it is almost ready to be submitted to the IESG, with a few minor comments below. I will highly appreciate if you can post an updated draft, and afterwards we will proceed with the publication process. Thanks, Tal. Comments: - Section 1: I would suggest to mention that TWAMP Light is a lightweight architecture of a TWAMP deployment that is presented in RFC 5357. - Section 2: - The term OSS/BSS should be defined. - The acronym SDN should be spelled out in its first appearance. - Section 4: - "Unauthenticated STAMP test packets are compatible on the wire with unauthenticated TWAMP-Test [RFC5357] packet formats." Please explain what "compatible" means. The format defined in STAMP is identical to RFC 5357? Can be configured to a specific mode in which it is identical to RFC 5357? An RFC 5357 TWAMP node can interoperate with a STAMP node? You may want to add a reference here to section 4.4. - Section 4.1.1.: - Please clarify that the timestamp field is as specified in RFC 5357 and RFC 8186. - "The Reflect Octets capability defined in [RFC6038]." ==> "This field is used for the Reflect Octets capability defined in [RFC6038]." - Section 4.1.2. + 4.2.2. + 4.3: - Please clarify that the HMAC field is as defined in RFC 5357, and covers the same fields as defined in RFC 5357. - Section 4.2.1.: - "the TTL field" ==> "the TTL field in IPv4 (or Hop Limit in IPv6)" - Section 4.3: - "If confidentiality protection for STAMP is required, encryption at the higher level MUST be used." Please elaborate, preferably with an example. IPsec is at a lower layer than STAMP, so not sure "higher level" is clear to the reader. - Section 5: - This section should be more detailed. You may want to say that the general security considerations of TWAMP are discussed in RFC 5357. You may also want to explain that the main difference between STAMP and TWAMP is the control plane, and you may want to make note that STAMP configuration procedures should be secured in order to mitigate attacks at the control plane. - References: - I suggest to move "[BBF.TR-390]" to the informative references. - draft-ietf-ippm-port-twamp-test ==> RFC 8545. - Minor nit: - "less the length" ==> "minus the length" --0000000000008b411605868b4842 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Authors,

Having r= eviewed the document, I found that it is clear and straightforward, and tha= t it is almost ready to be submitted to the IESG, with a few minor comments= below.

I will highly appreciate if you can post a= n updated draft, and afterwards we will proceed with the publication proces= s.

Thanks,
Tal.

=

Comments:

- Section 1: I = would suggest to mention that TWAMP Light is a lightweight architecture of = a TWAMP deployment that is presented in RFC 5357.
- Section 2:
- The term OSS/BSS should b= e defined.
- The acronym = SDN should be spelled out in its first appearance.
- Section 4:= =C2=A0
- "Unauthenti= cated STAMP test packets are compatible on the wire with unauthenticated TW= AMP-Test [RFC5357] packet formats."
=C2=A0 Please explain what "compatible" means. Th= e format defined in STAMP is identical to RFC 5357? Can be configured to a = specific mode in which it is identical to RFC 5357? An RFC 5357 TWAMP node = can interoperate with a STAMP node? You may want to add a reference here to= section 4.4.
- Section 4.1.1.:
- Please clarify that the ti= mestamp field is as specified in RFC 5357 and RFC 8186.
- "The Reflect Octets capability define= d in [RFC6038]." =3D=3D> "This field is used for the Reflect O= ctets capability defined in [RFC6038]."
- Section 4.1.2. + 4= .2.2. + 4.3:
- Please cla= rify that the HMAC field is as defined in RFC 5357, and covers the same fie= lds as defined in RFC 5357.
- Section 4= .2.1.:
- "the TT= L field" =3D=3D> "the TTL field in IPv4 (or Hop Limit in IPv6)= "
- Section 4.3:=C2=A0
- "If confidentiality protection for STAMP is required, e= ncryption at the higher level MUST be used."
=C2=A0 Please elaborate, preferably with an exampl= e. IPsec is at a lower layer than STAMP, so not sure "higher level&quo= t; is clear to the reader.
- Section 5:
- This section should be more detailed. You may wa= nt to say that the general security considerations of TWAMP are discussed i= n RFC 5357. You may also want to explain that the main difference between S= TAMP and TWAMP is the control plane, and you may want to make note that STA= MP configuration procedures should be secured in order to mitigate attacks = at the control plane.
- References:
- I suggest to move "[BBF.TR-390]" to the in= formative references.
- d= raft-ietf-ippm-port-twamp-test =3D=3D> RFC 8545.
- Minor nit:<= /div>
- "less the length&q= uot; =3D=3D> "minus the length"

--0000000000008b411605868b4842-- From nobody Tue Apr 16 18:32:28 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8514D12009A; Tue, 16 Apr 2019 18:32:26 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Q9Ud6olNlAez; Tue, 16 Apr 2019 18:32:24 -0700 (PDT) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC0F6120088; Tue, 16 Apr 2019 18:32:23 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id v13so20875112ljk.4; Tue, 16 Apr 2019 18:32:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zpvOGvcZnJR1Z6gNWw+kEmQsCioBNjxMrsmQ3K3pxb0=; b=EN8Ezp37UwpTGUdzbejDwhLxMNsl2zREDzDpdc+QWbeToui8ZZZQ86OS+N3E3Ao2dq 7YJVr/onf9rzbKqsB+3O7b6895ktvhIXP7VujIePzfttYlku9TSqR7TWFp9bQ0Jff8z4 zpn6wsOq8hxcBKoqCo3hLzc460UwfgoAbVzWdDKZw0ok0PABMlw6E7btqUyRzEVl2p+f yP5uXww1JS1/eyuh53mfr3Rcru1wsS89HSlamwWAnoXZgRGE5BPZGLi0j1fCWLnoiGvZ BfHB78BGtqoMBMqjwFJ5LMhmyAX1NSpcdbASOzkAd9/5x8Xk9hPLOcyiEv2Qz+bbxT1H g9Eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zpvOGvcZnJR1Z6gNWw+kEmQsCioBNjxMrsmQ3K3pxb0=; b=LYW1SaL/w0UlruCopUriEHB+mv9hhlzi0q5FaZdwjdTdGDzRtjslH4xgIE7aaQxjZ5 O+0/8bdoQuZ3jEWn4PoVgmehA0xERpbCXtinpKpN18H+FarfCqATaqIB/ubwM2smC+kl R947kNBainaFfWu1zd3urlU/V+tJ5Egj2VCy+NwzzoByvPQYew3iesYeWEoOtYQ5sYxA N/b67Xl9POJShBVin0tInM5BVnFt5kRVmzHIdugGz84BjPVHk/tEtDQ9Rx4O0jiIJV2u d75N/eIr5hy2NQR0JyPpDA77pMAF4wsTNEt8kmEastdt7q9zVaG5Jn7YcvnkedadNaPE hK1w== X-Gm-Message-State: APjAAAXEjGkPYlEsrw1rIqZkPGa7vYMuQSBEnh8Qdfcb2Ymf8YeaekoK H2guYUPqSMnxosexFcddNws33ihK8PAftYIGoeo= X-Google-Smtp-Source: APXvYqykUWWngBvOTssVhup2bSJKd/2IyEhRvTK0GaLY+6DQgDbsCv0j9DEoiYuRXyI6Yjy+Oy5NgUaSRKPC8UW2xIA= X-Received: by 2002:a2e:810d:: with SMTP id d13mr32530047ljg.93.1555464742123; Tue, 16 Apr 2019 18:32:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Tue, 16 Apr 2019 18:32:12 -0700 Message-ID: To: Tal Mizrahi Cc: "Foote, Footer (Nokia - CA)" , guo.jun2@zte.com.cn, Henrik Nydell , IETF IPPM WG , IPPM Chairs Content-Type: multipart/alternative; boundary="0000000000006a3d270586afdb30" Archived-At: Subject: Re: [ippm] Shepherd Review of draft-ietf-ippm-stamp-05 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 01:32:27 -0000 --0000000000006a3d270586afdb30 Content-Type: text/plain; charset="UTF-8" Dear Tal, thank you for your thorough review and clear, to the point comments. I'll be working on updating the draft to address your comments and will share the proposed changes before uploading the new version of the draft. Regards, Greg On Sun, Apr 14, 2019 at 10:54 PM Tal Mizrahi wrote: > Dear Authors, > > Having reviewed the document, I found that it is clear and > straightforward, and that it is almost ready to be submitted to the IESG, > with a few minor comments below. > > I will highly appreciate if you can post an updated draft, and afterwards > we will proceed with the publication process. > > Thanks, > Tal. > > > Comments: > > - Section 1: I would suggest to mention that TWAMP Light is a lightweight > architecture of a TWAMP deployment that is presented in RFC 5357. > - Section 2: > - The term OSS/BSS should be defined. > - The acronym SDN should be spelled out in its first appearance. > - Section 4: > - "Unauthenticated STAMP test packets are compatible on the wire with > unauthenticated TWAMP-Test [RFC5357] packet formats." > Please explain what "compatible" means. The format defined in STAMP is > identical to RFC 5357? Can be configured to a specific mode in which it is > identical to RFC 5357? An RFC 5357 TWAMP node can interoperate with a STAMP > node? You may want to add a reference here to section 4.4. > - Section 4.1.1.: > - Please clarify that the timestamp field is as specified in RFC 5357 and > RFC 8186. > - "The Reflect Octets capability defined in [RFC6038]." ==> "This field is > used for the Reflect Octets capability defined in [RFC6038]." > - Section 4.1.2. + 4.2.2. + 4.3: > - Please clarify that the HMAC field is as defined in RFC 5357, and covers > the same fields as defined in RFC 5357. > - Section 4.2.1.: > - "the TTL field" ==> "the TTL field in IPv4 (or Hop Limit in IPv6)" > - Section 4.3: > - "If confidentiality protection for STAMP is required, encryption at the > higher level MUST be used." > Please elaborate, preferably with an example. IPsec is at a lower layer > than STAMP, so not sure "higher level" is clear to the reader. > - Section 5: > - This section should be more detailed. You may want to say that the > general security considerations of TWAMP are discussed in RFC 5357. You may > also want to explain that the main difference between STAMP and TWAMP is > the control plane, and you may want to make note that STAMP configuration > procedures should be secured in order to mitigate attacks at the control > plane. > - References: > - I suggest to move "[BBF.TR-390]" to the informative references. > - draft-ietf-ippm-port-twamp-test ==> RFC 8545. > - Minor nit: > - "less the length" ==> "minus the length" > > --0000000000006a3d270586afdb30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Tal,
thank you for your thorough review and clear= , to the point comments. I'll be working on updating the draft to addre= ss your comments and will share the=C2=A0proposed changes before uploading = the new version of the draft.

Regards,
G= reg

On Sun, Apr 14, 2019 at 10:54 PM Tal Mizrahi <tal.mizrahi.phd@gmail.com> wrote:
Dear Authors,

Having reviewed the document, = I found that it is clear and straightforward, and that it is almost ready t= o be submitted to the IESG, with a few minor comments below.

=
I will highly appreciate if you can post an updated draft, and a= fterwards we will proceed with the publication process.

Thanks,
Tal.


Co= mments:

- Section 1: I would suggest to menti= on that TWAMP Light is a lightweight architecture of a TWAMP deployment tha= t is presented in RFC 5357.
- Section 2:
- The term OSS/BSS should be defined.
<= div> - The acronym SDN should b= e spelled out in its first appearance.
- Section 4:=C2=A0
- "Unauthenticated STA= MP test packets are compatible on the wire with unauthenticated TWAMP-Test = [RFC5357] packet formats."
=C2=A0 Please explain what "compatible" means. The fo= rmat defined in STAMP is identical to RFC 5357? Can be configured to a spec= ific mode in which it is identical to RFC 5357? An RFC 5357 TWAMP node can = interoperate with a STAMP node? You may want to add a reference here to sec= tion 4.4.
- Section 4= .1.1.:
- Please = clarify that the timestamp field is as specified in RFC 5357 and RFC 8186.<= /div>
- "The Reflect = Octets capability defined in [RFC6038]." =3D=3D> "This field i= s used for the Reflect Octets capability defined in [RFC6038]."
<= div>- Section 4.1.2. + 4.2.2. + 4.3:
- Please clarify that the HMAC field is as defined in RFC = 5357, and covers the same fields as defined in RFC 5357.
- Sectio= n 4.2.1.:
- "the TTL field" =3D=3D>= ; "the TTL field in IPv4 (or Hop Limit in IPv6)"
- Sect= ion 4.3:=C2=A0
- &qu= ot;If confidentiality protection for STAMP is required, encryption at the h= igher level MUST be used."
=C2=A0 Please elaborate, preferably with an example. IPsec is a= t a lower layer than STAMP, so not sure "higher level" is clear t= o the reader.
- Section 5:
- This section should be more detailed. You may want to sa= y that the general security considerations of TWAMP are discussed in RFC 53= 57. You may also want to explain that the main difference between STAMP and= TWAMP is the control plane, and you may want to make note that STAMP confi= guration procedures should be secured in order to mitigate attacks at the c= ontrol plane.
- References:
- I suggest to move "[BBF.TR-390]" to the infor= mative references.
-= draft-ietf-ippm-port-twamp-test =3D=3D> RFC 8545.
- Minor nit= :
- "less the l= ength" =3D=3D> "minus the length"

--0000000000006a3d270586afdb30-- From nobody Wed Apr 17 12:44:45 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6B7712014F; Wed, 17 Apr 2019 12:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 fRWaGj_-FfAV; Wed, 17 Apr 2019 12:44:33 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A72B1120104; Wed, 17 Apr 2019 12:44:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9390; q=dns/txt; s=iport; t=1555530272; x=1556739872; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pQFAg3yFutG8O9ctq30lgU6KxSctZhtueHH02y3v/vQ=; b=UwQhoF4TFDfqqHho+70DvCYZ6d0X9KhvQ/OOKlsgwaknrlRUOhCs1lxV hxcBPsSODkS1Eu7ZBaNpUpxxA0qy0osLKJE5k2EChvMcUpZYMS/Zd0nZu DCqMRWUZSE0cnlT4AOq+gnUjP0A631J9gTYbJ2uNxlZkYRsLLj8XTxJNI w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAD4gLdc/5hdJa1cChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVMCAQEBAQELAYFhBSpogQQoCoQElRAliTqPEBSBZw4?= =?us-ascii?q?BARgLhEoCF4V+IzYHDgEDAQEEAQIBAm0cDIVKAQEBAwEBASEROgsFCwIBCBg?= =?us-ascii?q?CAiYCAgIfBgsVEAIEDgWDIgGBaQMNDw+qTYEvh38NghsGgQsnAYtJF4FAP4E?= =?us-ascii?q?RJwwTgU5+PoIaRwEBgSkNFRUBgwoxgiYEjSmMIYwQLDcJAoIGil2Dd4NKG4I?= =?us-ascii?q?Jhh2DZ4hwjQ+GWIk8gnUCERWBMCYDLoFWcBU7KgGCQT6CdAECh1yFP0Exj1G?= =?us-ascii?q?BIQEB?= X-IronPort-AV: E=Sophos;i="5.60,363,1549929600"; d="scan'208";a="463041419" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Apr 2019 19:44:31 +0000 Received: from XCH-RTP-017.cisco.com (xch-rtp-017.cisco.com [64.101.220.157]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x3HJiVcI005890 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 17 Apr 2019 19:44:31 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-017.cisco.com (64.101.220.157) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 17 Apr 2019 15:44:30 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1473.003; Wed, 17 Apr 2019 15:44:30 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: "draft-ietf-nvo3-vxlan-gpe@ietf.org" , NVO3 , IETF IPPM WG Thread-Topic: [nvo3] Comments on draft-ietf-nvo3-vxlan-gpe Thread-Index: AQHU8Pwb4PQUm0Sk6kyANyiY2S4odqY4th6AgAhKgYCAAAxngA== Date: Wed, 17 Apr 2019 19:44:30 +0000 Message-ID: <3AFD4751-CF3A-4939-A49A-FB981C68CADF@cisco.com> References: <12ACA02A-BB51-4214-A72B-1AEFCCB914AC@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.104.8) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.116.132] Content-Type: text/plain; charset="utf-8" Content-ID: <9462EB032C2F0A489DE451FFA12FE189@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.157, xch-rtp-017.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [ippm] [nvo3] Comments on draft-ietf-nvo3-vxlan-gpe X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 19:44:36 -0000 SGksIEdyZWcsDQoNCkFkZGluZyB0aGUgSVBQTSBtYWlsaW5nIGxpc3QsIHNpbmNlIHlvdSByZWZl cmVuY2UgaXQgYmVsb3csIGFuZCBwb2ludCB0byBSRkMgNzc5OS4NCg0KUGxlYXNlIHNlZSBpbmxp bmUuDQoNCj4gT24gQXByIDE3LCAyMDE5LCBhdCAzOjAwIFBNLCBHcmVnIE1pcnNreSA8Z3JlZ2lt aXJza3lAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IEhpIENhcmxvcywNCj4gdGhhbmsgeW91IGZv ciBzaGFyaW5nIHlvdXIgdmlldyBvbiB0aGUgZGVzaWduIG9mIHRoZSBWWExBTi1HUEUgcHJvdG9j b2wuIFBsZWFzZSBmaW5kIG15IGNvbW1lbnRzIGluLWxpbmUgdGFnZ2VkIEdJTT4+Lg0KPiANCj4g UmVnYXJkcywNCj4gR3JlZw0KPiANCj4gT24gRnJpLCBBcHIgMTIsIDIwMTkgYXQgNToyMyBBTSBD YXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgPGNwaWduYXRhQGNpc2NvLmNvbT4gd3JvdGU6DQo+ IEdyZWcsDQo+IA0KPiBZb3Ugc2VlbSB0byBiZSBjb25mdXNpbmcgYW5kIG1peGluZyB0aGluZ3Mg dXAuDQo+IA0KPiBQbGVhc2Ugc2VlIGlubGluZS4NCj4gDQo+ID4gT24gQXByIDEyLCAyMDE5LCBh dCAyOjUwIEFNLCBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPiB3cm90ZToNCj4g PiANCj4gPiBEZWFyIEVkaXRvcnMsIGV0IGFsLiwNCj4gPiBJJ3ZlIHJlYWQgdGhlIGxhdGVzdCAt MDcgdmVyc2lvbiBhbmQgd291bGQgbGlrZSB0byBzaGFyZSBteSBjb21tZW50cyBhbmQgcXVlc3Rp b25zIHdpdGggeW91Og0KPiA+ICAgICAgIOKAoiBpbiB0aGUgZWFybGllciB2ZXJzaW9uIG9mIHRo ZSBkcmFmdCwgdGhlIE8tYml0IHdhcyBpbnRyb2R1Y2VkIGFuZCBkZWZpbmVkIGFzOg0KPiA+IE9B TSBGbGFnIEJpdCAoTyBiaXQpOiAgVGhlIE8gYml0IGlzIHNldCB0byBpbmRpY2F0ZSB0aGF0IHRo ZSBwYWNrZXQgaXMgYW4gT0FNIHBhY2tldC4NCj4gPiBBdCB0aGUgc2FtZSB0aW1lLCBpbiB0aGUg bGF0ZXN0IHZlcnNpb24sIHRoZSBuZXcgTmV4dCBQcm90b2NvbCB2YWx1ZSAoMHg4MSkgdG8gaWRl bnRpZnkgaU9BTSBEYXRhIHdhcyBpbnRyb2R1Y2VkLiBIZW5jZSBhcmUgbXkgcXVlc3Rpb25zOg0K PiA+ICAgICAgIOKAoiBXaGF0IG11c3QgYmUgdGhlIHZhbHVlIG9mIHRoZSBPLWJpdCB3aGVuIHRo ZSB2YWx1ZSBvZiB0aGUgTmV4dCBQcm90b2NvbCBmaWVsZCBpcyBpT0FNPw0KPiANCj4gVGhlIE8g Yml0IOKAnGlzIHNldCB0byBpbmRpY2F0ZSB0aGF0IHRoZSBwYWNrZXQgaXMgYW4gT0FNIHBhY2tl dOKAnS4NCj4gSUFPTSBpcyBub3QgYW4gT0FNIHBhY2tldC4gSGVuY2UsIE8gYml0IGNsZWFyIGlm IFZYTEFOLUdQRSBlbmNhcHN1bGF0ZXMgYSBub24tT0FNIHBhY2tldCBhbmQgYWRkcyBhbiBJT0FN IHNoaW0uDQo+IEdJTT4+IEl0IGlzIGEgdmVyeSB1bmV4cGVjdGVkIHN0YXRlbWVudCBmcm9tIHlv dSwNCg0KSSB3b3VsZCB0ZWxsIHlvdSDigJhleHBlY3QgdGhlIHVuZXhwZWN0ZWTigJksIGJ1dCB0 aGF0IGlzIG5vdCB0aGUgY2FzZSBoZXJlLi4uIDotKQ0KDQpJZiB5b3UgYWN0dWFsbHkgcmVhZCBt eSBzdGF0ZW1lbnQsIHlvdSB3aWxsIHNlZSAiSUFPTSBpcyBub3QgYW4gT0FNICpwYWNrZXQqLuKA nSBOZXcgZW1waGFzaXMgYWRkZWQg4oCUIGl0IGlzIF9ub3RfICphbiBPQU0gcGFja2V0Ki4NCg0K SSBzdGFuZCBieSBpdC4gSXTigJlzIGFuIGF1Z21lbnRlZCBkYXRhIHBhY2tldCBvZiBpbnRlcmVz dC4NCg0KPiBvbmUgb2YgdGhlIGNvLWF1dGhvcnMgb2YgZHJhZnQtaWV0Zi1pcHBtLWlvYW0tZGF0 YSAgd2hlcmUgdGhlIGZpcnN0IHBhcmFncmFwaCBvZiB0aGUgSW50cm9kdWN0aW9uIHNlY3Rpb24g ZGVmaW5lcyBpT0FNIGFzIEh5YnJpZCBUeXBlIDEgT0FNLCBhY2NvcmRpbmcgdG8gUkZDIDc3OTkg Y2xhc3NpZmljYXRpb246DQoNClRoaXMgaXMgc3RpbGwgcXVpdGUgY29uc2lzdGVudCB3aXRoIHRo YXQgZGVmaW5pdGlvbiwgd2hpY2ggSSByZWNvbW1lbmQgeW91IHJlLXJlYWQ6DQoNClJGQyA3Nzk5 IGlzIGFib3V0IG1ldHJpY3MgYW5kIG1ldGhvZHMsIG5vdCBwYWNrZXQgZGVmaW5pdGlvbnMuDQoN CllvdSB3aWxsIHNlZSB0aGF0IEFjdGl2ZSBtZXRob2RzIGluY2x1ZGUgYSDigJxkZWRpY2F0ZWQg bWVhc3VyZW1lbnQgcGFja2V0IHN0cmVhbeKAnS4g4oCcQWN0aXZlIE1ldGhvZHMgZ2VuZXJhdGUg cGFja2V0IHN0cmVhbXMu4oCdDQoNCkhvd2V2ZXIsIEh5YnJpZCBUeXBlIEkgbGV2ZXJhZ2VzIOKA nEF1Z21lbnRhdGlvbiBvciBtb2RpZmljYXRpb24gb2YgdGhlIHN0cmVhbSBvZiBpbnRlcmVzdCIN Cg0KRm9sbG93aW5nIHlvdXIgbG9naWMsIGlmIHlvdSBjaGFuZ2UgYSBwYWNrZXQgZmllbGQgc3Vj aCBhcyBUVEwvSEwgdG8gcHJvdmlkZSBwYWNrZXQgY29sb3JpbmcsIGRvIHlvdSBuZWVkIHRvIHNl dCB0aGUgTy1iaXQ/DQoNCj4gICAgSU9BTSBpcyB0byBjb21wbGVtZW50DQo+ICAgIG1lY2hhbmlz bXMgc3VjaCBhcyBQaW5nIG9yIFRyYWNlcm91dGUsIG9yIG1vcmUgcmVjZW50IGFjdGl2ZSBwcm9i aW5nDQo+ICAgIG1lY2hhbmlzbXMgYXMgZGVzY3JpYmVkIGluIFtJLUQubGFwdWtob3YtZGF0YXBs YW5lLXByb2JlXS4gIEluIHRlcm1zDQo+ICAgIG9mICJhY3RpdmUiIG9yICJwYXNzaXZlIiBPQU0s ICJpbi1zaXR1IiBPQU0gY2FuIGJlIGNvbnNpZGVyZWQgYQ0KPiAgICBoeWJyaWQgT0FNIHR5cGUu ICBXaGlsZSBubyBleHRyYSBwYWNrZXRzIGFyZSBzZW50LCBJT0FNIGFkZHMNCj4gICAgaW5mb3Jt YXRpb24gdG8gdGhlIHBhY2tldHMgdGhlcmVmb3JlIGNhbm5vdCBiZSBjb25zaWRlcmVkIHBhc3Np dmUuDQo+ICAgIEluIHRlcm1zIG9mIHRoZSBjbGFzc2lmaWNhdGlvbiBnaXZlbiBpbiBbUkZDNzc5 OV0gSU9BTSBjb3VsZCBiZQ0KPiAgICBwb3J0cmF5ZWQgYXMgSHlicmlkIFR5cGUgMS4NCj4gDQo+ ID4gICAgICAg4oCiIERvIHlvdSBwbGFuIHRvIGRlZmluZSB0aGUgTmV4dCBQcm90b2NvbCB2YWx1 ZXMgZm9yIGFjdGl2ZSBPQU0gcHJvdG9jb2xzLCBlLmcuLCBFY2hvIFJlcXVlc3QvUmVwbHksIEJG RCwgUGVyZm9ybWFuY2UgTW9uaXRvcmluZz8NCj4gDQo+IEkgY2Fubm90IHNwZWFrIHRvIOKAnHBs YW5z4oCdIChyZXBseWluZyBhcyDigJxldCBhbC7igJ0sIG5vdCBhcyDigJxlZGl0b3LigJ0pLCBi dXQgSSBleHBlY3QgT0FNIGRvY3VtZW50cyBvdWdodCB0byBoYXZlIHRob3NlIHJlcXVlc3RlZCwg YW5kIHlvdSBkbyBub3QgbmVlZCBuZWNlc3NhcmlseSBhbGwgb2YgdGhvc2Ug4oCUIHRoZSBuZXgg cHJvdG9jb2wgSVB2NCAvIElQdjYgY2FuIGVuY2Fwc3VsYXRlIElDTVAsIFVEUC9CRkQsIGV0Yy4s IGV0Yy4sIGV0Yy4sIGV0Yy4NCj4gR0lNPj4gT2YgY291cnNlLCB1c2Ugb2YgdGhlIHdlbGwta25v d24gcG9ydCBudW1iZXIsIHVzdWFsbHkgaXQgaXMgVURQIGRlc3RpbmF0aW9uIHBvcnQsIGlzIG9u ZSBvZiB0aGUgbWV0aG9kcyB0byBkZW11bHRpcGxleCBwcm90b2NvbHMuIFRoaXMgbWV0aG9kIGlz IGJyb2FkbHkgdXNlZCwgZm9yIGV4YW1wbGUsIGluIE1QTFMgT0FNLiBCdXQgdGhpcyBtZXRob2Qg aGFzIHNvbWUgZGlzYWR2YW50YWdlcyB0aGF0IHdlcmUgcG9pbnRlZCBvdXQgaW4gdGhlIGRpc2N1 c3Npb24gb2YgQkZEIG92ZXIgR0VORVZFIGluIFByYWd1ZSBieSBEYXZpZCBCbGFjayAodGhlIGxh c3QgcHJlc2VudGF0aW9uIGluIHRoZSBtaW51dGVzKToNCj4gRGF2aWQ6IEkgd2FudCB0aGUgQkZE IGhlYWRlciB0byBiZSBhcyBjbG9zZSB0byB0aGUgdGhpbmcgd2hvc2UgbGl2ZW5lc3MgSSdtIHRl c3RpbmcuIFRoZSBtb3JlIGhlYWRlcnMgeW91IGFkZCBpbiB0aGUgbWlkZGxlLCB0aGUgbW9yZSB3 YXlzIHRoZXJlIGFyZSB0byBicmVhayBCRkQgd2l0aG91dCBicmVha2luZyB0aGUgZm9yd2FyZGlu ZyBlbmdpbmUuIFRoZSBmdXJ0aGVyIGF3YXkgSSBtb3ZlIEJGRCBmcm9tIHRoZSBjaHVuayBvZiBo YXJkd2FyZSdzIGxpdmVuZXNzIEkgY2FyZSBhYm91dCwgdGhlIG1vcmUgb3Bwb3J0dW5pdGllcyBh cmUgZm9yIEJGRCBhbmQgdGhlIGhhcmR3YXJlIHRvIG5vdCB0byB0ZWxsIG1lIHRoZSBzYW1lIHRo aW5nLg0KPiANCg0KVGhlb3J5IGFuZCBwcmFjdGljZSBtYXRjaCBpbiB0aGVvcnksIGxlc3Mgc28g aW4gcHJhY3RpY2Ug4oCUIHVubGVzcyB5b3UgYXJlIHBsYW5uaW5nIHRvIHVwZGF0ZSBSRkMgNTg4 MS4NCg0KVGhpcyBjYW4gYmUgYXJndWVkIGJvdGggd2F5cyAoZS5nLiwgYmV0dGVyIHRvIGhhdmUg Y29tbW9uIGhhbmRsZXJzLCBldGMuKSwgYnV0IEkgdGFrZSBubyBwb3NpdGlvbi4gSSBkbyBzYXkg dGhhdCBpbiBwcmVzZW5jZSBvZiBkZXBsb3llZCBPQU0gZW5jYXBzdWxhdGlvbnMsIHRoZXJl4oCZ cyBubyBiYXNpcyBmb3IgeW91ciB5b3VyIGNvbW1lbnQgYWJvdXQgZGVmaW5pbmcgYSBwcm90b2Nv bCB0eXBlIGZvciDigJxQZXJmb3JtYW5jZSBNb25pdG9yaW5n4oCdIGFzIGEgcHJvdG9jb2wuLi4N Cg0KDQo+IA0KPiA+ICAgICAgIOKAoiBIb3cgdG8gaW50ZXJwcmV0IHRoZSBzaXR1YXRpb24gd2hl biB0aGUgTy1iaXQgdmFsdWUgaXMgMSBidXQgdGhlIHZhbHVlIG9mIHRoZSBOZXh0IFByb3RvY29s IGZpZWxkIGlzLCBmb3IgZXhhbXBsZSwgTlNILCBpLmUuLiwgbm90IGFueSBvZiBPQU0gcHJvdG9j b2xzPw0KPiANCj4gSSBleHBlY3QgaXQgbWVhbnMgdGhlcmXigJlzIE9BTSB3aXRoaW4gdGhhdCBO U0ggKHNvbWV0aW1lcyB0aGVyZeKAmXMgbm8gc3VjaCB0aGluZ3MgYXMg4oCcT0FNIFByb3RvY29s c+KAnSksIG9yIGFuIHVuaGFuZGxlZCBPQU0gcHJvdG9jb2wuDQo+IEdJTT4+IFNob3VsZCB0aGF0 LCBpLmUuLCBPQU0gaW4gTlNIIG9yIGltbWVkaWF0ZWx5IGZvbGxvd2luZyBOU0ggYmUgc2lnbmFs ZWQgdXNpbmcgU0ZDIE5TSCBtZXRob2RzIHRoYXQgYXJlIGFscmVhZHkgZGVmaW5lZCBpbiBkcmFm dC1pZXRmLXNmYy1tdWx0aS1sYXllci1vYW0/DQoNCg0KTm9uIHNlcXVpdHVyIOKAlCBJIGRvIG5v dCBmb2xsb3cgd2hhdCBzaWduYWxpbmcgaGFzIHRvIGRvIHdpdGggdGhlIGNvbnZlcnNhdGlvbiwg bm9yIGhvdyB0aGF0IGRyYWZ0IG1pZ2h0IGJlIHJlbGV2YW50Lg0KDQo+IFVzaW5nIHRoZSBzZXJ2 ZXIgbGF5ZXIsIGFzIHlvdSd2ZSBzdWdnZXN0ZWQsIHNlZW1zIGFzIGxheWVyIHZpb2xhdGlvbi4g DQo+IA0KDQpUaGlzIGlzIGEgZnVubnkgc3RhdGVtZW50IOKAlCBOVk8zIGlzIGEgbGF5ZXIgdmlv bGF0aW9uIDotKSBTbyBhcmUgUHNldWRvd2lyZXMuIFBsZWFzZSBkbyBub3QgdGFrZSB0aGlzIHN0 YXRlbWVudCB0b28gc2VyaW91c2x5LCBpdCBpcyBub3QgaW52aXRpbmcgZGlzY3Vzc2lvbi4NCg0K PiA+ICAgICAgIOKAoiBJIGJlbGlldmUgdGhhdCB0aGUgdXNlIG9mIHRoZSBkZWRpY2F0ZWQgT0FN IGZsYWcgYW5kIHRoZSBOZXh0IFByb3RvY29sIGZpZWxkIGZvciBhIGZpeGVkLXNpemUgaGVhZGVy IHRoYXQgY2Fubm90IGluY2x1ZGUgbWV0YS1kYXRhIGlzIHVud2FycmFudGVkIGFuZCBhZGRzIHVu bmVjZXNzYXJ5IGNvbXBsZXhpdHkuDQo+IA0KPiBEaXNhZ3JlZS4gDQo+IA0KPiBTZWUgZXhhbXBs ZSB3aGVyZSBwcm90b2NvbCBpcyBJUCBjYXJyeWluZyBhbiBPQU0gcGFja2V0Lg0KPiBHSU0+PiBX aGVuIElQL1VEUCBlbmNhcHN1bGF0aW9uIGlzIHVzZWQgZm9yIE9BTSwgdGhlcmUncyBubywgaW4g bXkgb3BpbmlvbiwgYW55IG5lZWQgdG8gdXNlIHRoZSBPLWJpdC4gVGhlIGRlc3RpbmF0aW9uIElQ IGFkZHJlc3MgbXVzdCBiZSBhcyBkZXNjcmliZWQgaW4gUkZDIDgwMjkgb3IgUkZDIDU4ODQgYW5k IHRoZSBkZW11bHRpcGxleGluZyBpcyBkb25lIGJhc2VkIG9uIHRoZSBkZXN0aW5hdGlvbiBVRFAg cG9ydCBudW1iZXIuIENsZWFybHksIE8tYml0IGlzIHVubmVjZXNzYXJ5IGlmIElQL1VEUCBlbmNh cHN1bGF0aW9uIGZvciBPQU0gYmVpbmcgdXNlZC4NCj4gDQoNCkZvcnR1bmF0ZWx5LCBiaXQgdXNh Z2UgaXMgYSBtYXR0ZXIgb2YgZGVmaW5pdGlvbiBhbmQgbm90IG9waW5pb24gOi0pDQoNCktpbmQg cmVnYXJkcywNCg0KQ2FybG9zLg0KDQoNCj4gPiBJIHN1Z2dlc3Qgbm90IHRvIHVzZSBPLWJpdCBp biB0aGUgVlhMQU4tR1BFIGhlYWRlciBhbmQgcmVsZWFzZSBpdCBpbnRvIHRoZSBSZXNlcnZlZCBm aWVsZC4gIEkgZG9uJ3Qgc2VlIHRoZSBhcHBhcmVudCBiZW5lZml0IG9mIHVzaW5nIHRoZSBmbGFn LCBhcyB0aGUgVlhMQS1HUEUgdXNlcyB0aGUgZml4ZWQgc2l6ZSBoZWFkZXIgYW5kIHRoZSBoZWFk ZXIgY2Fubm90IGNhcnJ5IE9BTSBkYXRhIGluIGl0LiBUaGUgb25seSByb2xlIHRoZSBWWExBTi1H UEUgaGVhZGVyIG11c3QgcGVyZm9ybSwgaW4gbXkgb3BpbmlvbiwgaXMgdG8gdW5hbWJpZ3VvdXNs eSBpZGVudGlmeSB0aGUgcGF5bG9hZCB0eXBlIHRoYXQgaW1tZWRpYXRlbHkgZm9sbG93cyB0aGUg aGVhZGVyIGFzIE9BTSAoZGVtdWx0aXBsZXhpbmcgT0FNIHByb3RvY29scyBtYXkgYmUgZG9uZSBp biBPQU0gSGVhZGVyIHNoaW0pLg0KPiA+IE11Y2ggYXBwcmVjaWF0ZSB5b3VyIGNvbnNpZGVyYXRp b24uDQo+ID4gDQo+IA0KPiBCZXN0LA0KPiANCj4g4oCUDQo+IENhcmxvcyBQaWduYXRhcm8sIGNh cmxvc0BjaXNjby5jb20NCj4gDQo+IOKAnFNvbWV0aW1lcyBJIHVzZSBiaWcgd29yZHMgdGhhdCBJ IGRvIG5vdCBmdWxseSB1bmRlcnN0YW5kLCB0byBtYWtlIG15c2VsZiBzb3VuZCBtb3JlIHBob3Rv c3ludGhlc2lzLiINCj4gDQo+ID4gUmVnYXJkcywNCj4gPiBHcmVnDQo+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBudm8zIG1haWxpbmcgbGlz dA0KPiA+IG52bzNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL252bzMNCj4gDQoNCg== From nobody Wed Apr 17 14:55:15 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E56CE120143; Wed, 17 Apr 2019 14:55:05 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 aFNdwhKONwOR; Wed, 17 Apr 2019 14:55:02 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F41D1200FE; Wed, 17 Apr 2019 14:55:01 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id p14so81956ljg.5; Wed, 17 Apr 2019 14:55:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hLq+bUSMN84B9NJChP8lmurophEDG63RP4w2r53yvZ8=; b=Ro++NXeKdK6jSKL2ZvvF7KAfDhS3SFMfhlPpse04yfkNda6J+W4ZxkkKx322buQSJB xLvANaHHck+D5qIHIaFpDBLA5OIzm4HBJ+yUWXegFR0f2xQmsBu1EfgLv4nuJ59gUxa8 J9Dt9MxrLvU0nepVAXnp/glzB7UlADuDQeKFsDv7+FM7Iv1kcl54Vg+eafLsslHFyrab VfocVHYetBAHUC41bxHiIyCW9VKHtsLnAQ5SDt3+chNQsPybcEoromOR8J1Z0za4aM4I pLaq5Uc06xcYsueY/yx8MuAWPLYoaUNATdANVU/Pytx7gIadhCd/Qg+tLQIr2rS4xw5Z JkiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hLq+bUSMN84B9NJChP8lmurophEDG63RP4w2r53yvZ8=; b=S03gKvaW+hhX0WuCOqEJtN74cIuEAWE6zx87sQ4JTa9gtmOPY3CcPBlj+JnIKu4me7 7VNPk1RO5hSAsRE91oRwBGDKYe3PjluLV/UTYUhCJkllFiKVHCPOp/Vc4sK6lenXJtRu R0MHtZ3y13uA6+LJACTu49B8D9zKUDemgRX1A8MruAH0MTlhyA3QBOmwZ6Btkwh7VEa5 HwTlFWFH5w2pct70N3hPMfnbNwHWX9n3OYptVHYgJhLsduOWBR1ZV2oTWXZrY+lCfIln DbC5QhStA0NGaAfCixeiayLJ2cFoZvVG5n54Cw40wU5VjfNhlYAYGvLUwXt5iUQ0yx94 aZeg== X-Gm-Message-State: APjAAAVhSGckt+mW4uEkwGGpYL02RkopScsLM/siOIZovA2O4dn4EhrR 1/dccIQY+U/V3RvUsoq/Gmiw2j4jYam8AGK/k3A= X-Google-Smtp-Source: APXvYqwaozuetZyWdKUbQyILAokXAxGp6drYThDTvMixNUU6CQy6rgKhh3mn71MOuFLaCIvfVW3eXK1t7ZboaweecGE= X-Received: by 2002:a2e:974d:: with SMTP id f13mr48401865ljj.140.1555538099460; Wed, 17 Apr 2019 14:54:59 -0700 (PDT) MIME-Version: 1.0 References: <12ACA02A-BB51-4214-A72B-1AEFCCB914AC@cisco.com> <3AFD4751-CF3A-4939-A49A-FB981C68CADF@cisco.com> In-Reply-To: <3AFD4751-CF3A-4939-A49A-FB981C68CADF@cisco.com> From: Greg Mirsky Date: Wed, 17 Apr 2019 14:54:52 -0700 Message-ID: To: "Carlos Pignataro (cpignata)" Cc: "draft-ietf-nvo3-vxlan-gpe@ietf.org" , NVO3 , IETF IPPM WG Content-Type: multipart/alternative; boundary="000000000000da614c0586c0ef8a" Archived-At: Subject: Re: [ippm] [nvo3] Comments on draft-ietf-nvo3-vxlan-gpe X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2019 21:55:06 -0000 --000000000000da614c0586c0ef8a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Carlos, to add another quote from the draft-ietf-sfc-ioam-nsh that you've co-authored, Packets with IOAM data included MUST follow this definition, i.e. the O bit MUST NOT be set for regular customer traffic which also carries IOAM data and the O bit MUST be set for OAM packets which carry only IOAM data without any regular data payload. So, if the only iOAM message is carried in or after an NSH, it is identified as OAM. And, by your own example in the earlier note, so should VXLAN-GPE. Regards, Greg On Wed, Apr 17, 2019 at 12:44 PM Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Hi, Greg, > > Adding the IPPM mailing list, since you reference it below, and point to > RFC 7799. > > Please see inline. > > > On Apr 17, 2019, at 3:00 PM, Greg Mirsky wrote: > > > > Hi Carlos, > > thank you for sharing your view on the design of the VXLAN-GPE protocol= . > Please find my comments in-line tagged GIM>>. > > > > Regards, > > Greg > > > > On Fri, Apr 12, 2019 at 5:23 AM Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > > Greg, > > > > You seem to be confusing and mixing things up. > > > > Please see inline. > > > > > On Apr 12, 2019, at 2:50 AM, Greg Mirsky > wrote: > > > > > > Dear Editors, et al., > > > I've read the latest -07 version and would like to share my comments > and questions with you: > > > =E2=80=A2 in the earlier version of the draft, the O-bit was in= troduced > and defined as: > > > OAM Flag Bit (O bit): The O bit is set to indicate that the packet i= s > an OAM packet. > > > At the same time, in the latest version, the new Next Protocol value > (0x81) to identify iOAM Data was introduced. Hence are my questions: > > > =E2=80=A2 What must be the value of the O-bit when the value of= the Next > Protocol field is iOAM? > > > > The O bit =E2=80=9Cis set to indicate that the packet is an OAM packet= =E2=80=9D. > > IAOM is not an OAM packet. Hence, O bit clear if VXLAN-GPE encapsulates > a non-OAM packet and adds an IOAM shim. > > GIM>> It is a very unexpected statement from you, > > I would tell you =E2=80=98expect the unexpected=E2=80=99, but that is not= the case here... > :-) > > If you actually read my statement, you will see "IAOM is not an OAM > *packet*.=E2=80=9D New emphasis added =E2=80=94 it is _not_ *an OAM packe= t*. > > I stand by it. It=E2=80=99s an augmented data packet of interest. > > > one of the co-authors of draft-ietf-ippm-ioam-data where the first > paragraph of the Introduction section defines iOAM as Hybrid Type 1 OAM, > according to RFC 7799 classification: > > This is still quite consistent with that definition, which I recommend yo= u > re-read: > > RFC 7799 is about metrics and methods, not packet definitions. > > You will see that Active methods include a =E2=80=9Cdedicated measurement= packet > stream=E2=80=9D. =E2=80=9CActive Methods generate packet streams.=E2=80= =9D > > However, Hybrid Type I leverages =E2=80=9CAugmentation or modification of= the > stream of interest" > > Following your logic, if you change a packet field such as TTL/HL to > provide packet coloring, do you need to set the O-bit? > > > IOAM is to complement > > mechanisms such as Ping or Traceroute, or more recent active probing > > mechanisms as described in [I-D.lapukhov-dataplane-probe]. In terms > > of "active" or "passive" OAM, "in-situ" OAM can be considered a > > hybrid OAM type. While no extra packets are sent, IOAM adds > > information to the packets therefore cannot be considered passive. > > In terms of the classification given in [RFC7799] IOAM could be > > portrayed as Hybrid Type 1. > > > > > =E2=80=A2 Do you plan to define the Next Protocol values for ac= tive OAM > protocols, e.g., Echo Request/Reply, BFD, Performance Monitoring? > > > > I cannot speak to =E2=80=9Cplans=E2=80=9D (replying as =E2=80=9Cet al.= =E2=80=9D, not as =E2=80=9Ceditor=E2=80=9D), but I > expect OAM documents ought to have those requested, and you do not need > necessarily all of those =E2=80=94 the nex protocol IPv4 / IPv6 can encap= sulate > ICMP, UDP/BFD, etc., etc., etc., etc. > > GIM>> Of course, use of the well-known port number, usually it is UDP > destination port, is one of the methods to demultiplex protocols. This > method is broadly used, for example, in MPLS OAM. But this method has som= e > disadvantages that were pointed out in the discussion of BFD over GENEVE = in > Prague by David Black (the last presentation in the minutes): > > David: I want the BFD header to be as close to the thing whose liveness > I'm testing. The more headers you add in the middle, the more ways there > are to break BFD without breaking the forwarding engine. The further away= I > move BFD from the chunk of hardware's liveness I care about, the more > opportunities are for BFD and the hardware to not to tell me the same thi= ng. > > > > Theory and practice match in theory, less so in practice =E2=80=94 unless= you are > planning to update RFC 5881. > > This can be argued both ways (e.g., better to have common handlers, etc.)= , > but I take no position. I do say that in presence of deployed OAM > encapsulations, there=E2=80=99s no basis for your your comment about defi= ning a > protocol type for =E2=80=9CPerformance Monitoring=E2=80=9D as a protocol.= .. > > > > > > > =E2=80=A2 How to interpret the situation when the O-bit value i= s 1 but > the value of the Next Protocol field is, for example, NSH, i.e.., not any > of OAM protocols? > > > > I expect it means there=E2=80=99s OAM within that NSH (sometimes there= =E2=80=99s no such > things as =E2=80=9COAM Protocols=E2=80=9D), or an unhandled OAM protocol. > > GIM>> Should that, i.e., OAM in NSH or immediately following NSH be > signaled using SFC NSH methods that are already defined in > draft-ietf-sfc-multi-layer-oam? > > > Non sequitur =E2=80=94 I do not follow what signaling has to do with the > conversation, nor how that draft might be relevant. > > > Using the server layer, as you've suggested, seems as layer violation. > > > > This is a funny statement =E2=80=94 NVO3 is a layer violation :-) So are > Pseudowires. Please do not take this statement too seriously, it is not > inviting discussion. > > > > =E2=80=A2 I believe that the use of the dedicated OAM flag and = the Next > Protocol field for a fixed-size header that cannot include meta-data is > unwarranted and adds unnecessary complexity. > > > > Disagree. > > > > See example where protocol is IP carrying an OAM packet. > > GIM>> When IP/UDP encapsulation is used for OAM, there's no, in my > opinion, any need to use the O-bit. The destination IP address must be as > described in RFC 8029 or RFC 5884 and the demultiplexing is done based on > the destination UDP port number. Clearly, O-bit is unnecessary if IP/UDP > encapsulation for OAM being used. > > > > Fortunately, bit usage is a matter of definition and not opinion :-) > > Kind regards, > > Carlos. > > > > > I suggest not to use O-bit in the VXLAN-GPE header and release it int= o > the Reserved field. I don't see the apparent benefit of using the flag, = as > the VXLA-GPE uses the fixed size header and the header cannot carry OAM > data in it. The only role the VXLAN-GPE header must perform, in my opinio= n, > is to unambiguously identify the payload type that immediately follows th= e > header as OAM (demultiplexing OAM protocols may be done in OAM Header shi= m). > > > Much appreciate your consideration. > > > > > > > Best, > > > > =E2=80=94 > > Carlos Pignataro, carlos@cisco.com > > > > =E2=80=9CSometimes I use big words that I do not fully understand, to m= ake > myself sound more photosynthesis." > > > > > Regards, > > > Greg > > > _______________________________________________ > > > nvo3 mailing list > > > nvo3@ietf.org > > > https://www.ietf.org/mailman/listinfo/nvo3 > > > > --000000000000da614c0586c0ef8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carlos,
to add an= other quote from the draft-ietf-sfc-ioam-nsh that you've co-aut= hored,=C2=A0
=C2=A0 =C2=A0Packets with IOAM data included MU= ST follow this
=C2=A0 =C2=A0definition, i.e. the O bit MUST NOT b= e set for regular customer
=C2=A0 =C2=A0traffic which also carrie= s IOAM data and the O bit MUST be set for
=C2=A0 =C2=A0OAM packet= s which carry only IOAM data without any regular data
=C2=A0 =C2= =A0payload.

So, if the only iOAM message is = carried in or after an NSH, it is identified as OAM. And, by your own examp= le in the earlier note, so should VXLAN-GPE.

Regar= ds,
Greg

On Wed, Apr 17, 2019 at 12:44 PM Carlos= Pignataro (cpignata) <cpignata@ci= sco.com> wrote:
Hi, Greg,

Adding the IPPM mailing list, since you reference it below, and point to RF= C 7799.

Please see inline.

> On Apr 17, 2019, at 3:00 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
>
> Hi Carlos,
> thank you for sharing your view on the design of the VXLAN-GPE protoco= l. Please find my comments in-line tagged GIM>>.
>
> Regards,
> Greg
>
> On Fri, Apr 12, 2019 at 5:23 AM Carlos Pignataro (cpignata) <cpignata@cisco.com>= ; wrote:
> Greg,
>
> You seem to be confusing and mixing things up.
>
> Please see inline.
>
> > On Apr 12, 2019, at 2:50 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:=
> >
> > Dear Editors, et al.,
> > I've read the latest -07 version and would like to share my c= omments and questions with you:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 in the earlier version of the= draft, the O-bit was introduced and defined as:
> > OAM Flag Bit (O bit):=C2=A0 The O bit is set to indicate that the= packet is an OAM packet.
> > At the same time, in the latest version, the new Next Protocol va= lue (0x81) to identify iOAM Data was introduced. Hence are my questions: > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 What must be the value of the= O-bit when the value of the Next Protocol field is iOAM?
>
> The O bit =E2=80=9Cis set to indicate that the packet is an OAM packet= =E2=80=9D.
> IAOM is not an OAM packet. Hence, O bit clear if VXLAN-GPE encapsulate= s a non-OAM packet and adds an IOAM shim.
> GIM>> It is a very unexpected statement from you,

I would tell you =E2=80=98expect the unexpected=E2=80=99, but that is not t= he case here... :-)

If you actually read my statement, you will see "IAOM is not an OAM *p= acket*.=E2=80=9D New emphasis added =E2=80=94 it is _not_ *an OAM packet*.<= br>
I stand by it. It=E2=80=99s an augmented data packet of interest.

> one of the co-authors of draft-ietf-ippm-ioam-data=C2=A0 where the fir= st paragraph of the Introduction section defines iOAM as Hybrid Type 1 OAM,= according to RFC 7799 classification:

This is still quite consistent with that definition, which I recommend you = re-read:

RFC 7799 is about metrics and methods, not packet definitions.

You will see that Active methods include a =E2=80=9Cdedicated measurement p= acket stream=E2=80=9D. =E2=80=9CActive Methods generate packet streams.=E2= =80=9D

However, Hybrid Type I leverages =E2=80=9CAugmentation or modification of t= he stream of interest"

Following your logic, if you change a packet field such as TTL/HL to provid= e packet coloring, do you need to set the O-bit?

>=C2=A0 =C2=A0 IOAM is to complement
>=C2=A0 =C2=A0 mechanisms such as Ping or Traceroute, or more recent act= ive probing
>=C2=A0 =C2=A0 mechanisms as described in [I-D.lapukhov-dataplane-probe]= .=C2=A0 In terms
>=C2=A0 =C2=A0 of "active" or "passive" OAM, "i= n-situ" OAM can be considered a
>=C2=A0 =C2=A0 hybrid OAM type.=C2=A0 While no extra packets are sent, I= OAM adds
>=C2=A0 =C2=A0 information to the packets therefore cannot be considered= passive.
>=C2=A0 =C2=A0 In terms of the classification given in [RFC7799] IOAM co= uld be
>=C2=A0 =C2=A0 portrayed as Hybrid Type 1.
>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Do you plan to define the Nex= t Protocol values for active OAM protocols, e.g., Echo Request/Reply, BFD, = Performance Monitoring?
>
> I cannot speak to =E2=80=9Cplans=E2=80=9D (replying as =E2=80=9Cet al.= =E2=80=9D, not as =E2=80=9Ceditor=E2=80=9D), but I expect OAM documents oug= ht to have those requested, and you do not need necessarily all of those = =E2=80=94 the nex protocol IPv4 / IPv6 can encapsulate ICMP, UDP/BFD, etc.,= etc., etc., etc.
> GIM>> Of course, use of the well-known port number, usually it i= s UDP destination port, is one of the methods to demultiplex protocols. Thi= s method is broadly used, for example, in MPLS OAM. But this method has som= e disadvantages that were pointed out in the discussion of BFD over GENEVE = in Prague by David Black (the last presentation in the minutes):
> David: I want the BFD header to be as close to the thing whose livenes= s I'm testing. The more headers you add in the middle, the more ways th= ere are to break BFD without breaking the forwarding engine. The further aw= ay I move BFD from the chunk of hardware's liveness I care about, the m= ore opportunities are for BFD and the hardware to not to tell me the same t= hing.
>

Theory and practice match in theory, less so in practice =E2=80=94 unless y= ou are planning to update RFC 5881.

This can be argued both ways (e.g., better to have common handlers, etc.), = but I take no position. I do say that in presence of deployed OAM encapsula= tions, there=E2=80=99s no basis for your your comment about defining a prot= ocol type for =E2=80=9CPerformance Monitoring=E2=80=9D as a protocol...


>
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 How to interpret the situatio= n when the O-bit value is 1 but the value of the Next Protocol field is, fo= r example, NSH, i.e.., not any of OAM protocols?
>
> I expect it means there=E2=80=99s OAM within that NSH (sometimes there= =E2=80=99s no such things as =E2=80=9COAM Protocols=E2=80=9D), or an unhand= led OAM protocol.
> GIM>> Should that, i.e., OAM in NSH or immediately following NSH= be signaled using SFC NSH methods that are already defined in draft-ietf-s= fc-multi-layer-oam?


Non sequitur =E2=80=94 I do not follow what signaling has to do with the co= nversation, nor how that draft might be relevant.

> Using the server layer, as you've suggested, seems as layer violat= ion.
>

This is a funny statement =E2=80=94 NVO3 is a layer violation :-) So are Ps= eudowires. Please do not take this statement too seriously, it is not invit= ing discussion.

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 I believe that the use of the= dedicated OAM flag and the Next Protocol field for a fixed-size header tha= t cannot include meta-data is unwarranted and adds unnecessary complexity.<= br> >
> Disagree.
>
> See example where protocol is IP carrying an OAM packet.
> GIM>> When IP/UDP encapsulation is used for OAM, there's no,= in my opinion, any need to use the O-bit. The destination IP address must = be as described in RFC 8029 or RFC 5884 and the demultiplexing is done base= d on the destination UDP port number. Clearly, O-bit is unnecessary if IP/U= DP encapsulation for OAM being used.
>

Fortunately, bit usage is a matter of definition and not opinion :-)

Kind regards,

Carlos.


> > I suggest not to use O-bit in the VXLAN-GPE header and release it= into the Reserved field.=C2=A0 I don't see the apparent benefit of usi= ng the flag, as the VXLA-GPE uses the fixed size header and the header cann= ot carry OAM data in it. The only role the VXLAN-GPE header must perform, i= n my opinion, is to unambiguously identify the payload type that immediatel= y follows the header as OAM (demultiplexing OAM protocols may be done in OA= M Header shim).
> > Much appreciate your consideration.
> >
>
> Best,
>
> =E2=80=94
> Carlos Pignataro, carlos@cisco.com
>
> =E2=80=9CSometimes I use big words that I do not fully understand, to = make myself sound more photosynthesis."
>
> > Regards,
> > Greg
> > _______________________________________________
> > nvo3 mailing list
> > nvo3@ietf.org<= /a>
> > https://www.ietf.org/mailman/listinfo/nvo3 >

--000000000000da614c0586c0ef8a-- From nobody Wed Apr 17 17:18:55 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E158F120026; Wed, 17 Apr 2019 17:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 j9eUtmcyGE8l; Wed, 17 Apr 2019 17:18:36 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71BA7120033; Wed, 17 Apr 2019 17:18:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13126; q=dns/txt; s=iport; t=1555546716; x=1556756316; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SVrd0U93Ar4D/yndE+YJt08voiaRKFFejRqDMDA15X8=; b=KpwZLRADjMiUBC851ljtp3A4sMxX0dHVCcPbFYwtVj6c0RrrulplevnE vbK0cz3ADiCIpkra4fGIUMgBuRyJMWJyRenTNjf8rik8ZZUX0TQM0Hrlr kspRIaBXkSEjWMU9aIK0GN6Pq+E1XAgdtAnq73kAYYUzYahRk4mDOV5Ap s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAACmwbdc/5BdJa1cChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVQBAQEBAQELAYFmKmiBBCgKhASVNok6jySBZw4BAYR?= =?us-ascii?q?tAheFfiM3Bg4BAwEBBAECAQJtKIVKAQEBAwEjETMHCwULAgEIGAICJgICAh8?= =?us-ascii?q?RFRACBA4FgyIBgWkDDQ+qB4Evh38NghsGgQsnAYtJF4FAP4ERJx+BTn4+ghq?= =?us-ascii?q?Bcg0VBBGDCzGCJgSNKZgxLDcJAoIGil2Dd4NKG4IJhh2DZ4hwjQ+GWIk8gnU?= =?us-ascii?q?CERWBMDUigVZwFTsqAYJBPoJ0AQKNG0Exj1GBIQEB?= X-IronPort-AV: E=Sophos;i="5.60,363,1549929600"; d="scan'208";a="463105773" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Apr 2019 00:18:31 +0000 Received: from XCH-RTP-016.cisco.com (xch-rtp-016.cisco.com [64.101.220.156]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x3I0IUti008862 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 18 Apr 2019 00:18:30 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-016.cisco.com (64.101.220.156) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 17 Apr 2019 20:18:29 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1473.003; Wed, 17 Apr 2019 20:18:29 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: NVO3 , "draft-ietf-nvo3-vxlan-gpe@ietf.org" , IETF IPPM WG , "sfc@ietf.org" Thread-Topic: [SUSPICIOUS] Re: [nvo3] Comments on draft-ietf-nvo3-vxlan-gpe Thread-Index: AQHU8Pwb4PQUm0Sk6kyANyiY2S4odqY4th6AgAhKgYCAAAxngIAAJG4AgAAoIIA= Date: Thu, 18 Apr 2019 00:18:29 +0000 Message-ID: <4C9CDD29-BDF8-425E-998F-B12C1BD7CA7C@cisco.com> References: <12ACA02A-BB51-4214-A72B-1AEFCCB914AC@cisco.com> <3AFD4751-CF3A-4939-A49A-FB981C68CADF@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.104.8) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.116.132] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.156, xch-rtp-016.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [ippm] [SUSPICIOUS] Re: [nvo3] Comments on draft-ietf-nvo3-vxlan-gpe X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 00:18:41 -0000 RGVhciBHcmVnLA0KDQpbTm93IGFkZGluZyB0aGUgU0ZDIFdHIE1haWxpbmcgbGlzdCBzaW5jZSB5 b3UgdGFrZSB1cyB0byBhIGRpZmZlcmVudCBXRyBhZ2Fpbl0NCg0KVGhhbmsgeW91IHZlcnkgbXVj aCBmb3IgZmluZS1jb21iaW5nIHdpdGggYSBtYWduaWZ5aW5nIGdsYXNzIHRocm91Z2ggYWxsIHRo ZSBkb2N1bWVudHMgSeKAmW0gY3VycmVudGx5IGNvLWF1dGhvcmluZyA6LSkNCg0KSXQgaXMgcmVm cmVzaGluZyB0byBzZWUgdGhhdCB0aGUgb25seSBpc3N1ZXMgeW91IGZpbmQgYXJlIG5vbi1pc3N1 ZXMsIGFuZCB5b3VyIHF1ZXN0aW9ucyBlYXN5IHRvIHJlLWFuc3dlciA6LSkNCg0KQXQgdGhpcyBw b2ludCBJIGFtIGEgYml0IGF0IGEgbG9zcyBvZiB3aGF0IHlvdXIgcG9pbnQgaXMsIG9yIHdoYXQg eW91IGFyZSB0cnlpbmcgdG8gcHJvdmUgYmVuZGluZyB0ZXh0LiBBcmUgeW91IGNvZGluZywgZGVw bG95aW5nLCBvciB0ZXN0aW5nIElPQU0gb24gTlNIIHdpdGhvdXQgZGF0YSBwYWNrZXRzIG9uIFZY TEFOLUdQRSBvdmVyIElQPyBOU0ggaXMgZGF0YSBhcyBmYXIgYXMgVlhMQU4tR1BFIGlzIGNvbmNl cm5lZC4gSU9BTSBzaGltbWVkIGluIE5TSCBpcyBvcnRob2dvbmFsIHRvIElPQU0gc2hpbW1lZCBp biBWWExBTi1HUEUuDQoNCkkgZmVlbCB0aGlzIGRpc2N1c3Npb24gYWJvdXQgdGhlIE8tYml0IGFs cmVhZHkgdG9vayBwbGFjZSBvbmNlIG9yIHR3aWNlLg0KDQpLaW5kIFJlZ2FyZHMsDQoNCuKAlCBD YXJsb3MgUGlnbmF0YXJvDQoNClBTOiBUaGUgRXZpbCBiaXQgaXMgZGVmaW5lZCBmb3IgSVB2NCwg c2hvdWxkIHdlIHRoZXJlZm9yZSBhbHNvIGRlZmluZSBpdCBoZXJlPw0KDQoNCj4gT24gQXByIDE3 LCAyMDE5LCBhdCA1OjU0IFBNLCBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPiB3 cm90ZToNCj4gDQo+IEhpIENhcmxvcywNCj4gdG8gYWRkIGFub3RoZXIgcXVvdGUgZnJvbSB0aGUg ZHJhZnQtaWV0Zi1zZmMtaW9hbS1uc2ggdGhhdCB5b3UndmUgY28tYXV0aG9yZWQsIA0KPiAgICBQ YWNrZXRzIHdpdGggSU9BTSBkYXRhIGluY2x1ZGVkIE1VU1QgZm9sbG93IHRoaXMNCj4gICAgZGVm aW5pdGlvbiwgaS5lLiB0aGUgTyBiaXQgTVVTVCBOT1QgYmUgc2V0IGZvciByZWd1bGFyIGN1c3Rv bWVyDQo+ICAgIHRyYWZmaWMgd2hpY2ggYWxzbyBjYXJyaWVzIElPQU0gZGF0YSBhbmQgdGhlIE8g Yml0IE1VU1QgYmUgc2V0IGZvcg0KPiAgICBPQU0gcGFja2V0cyB3aGljaCBjYXJyeSBvbmx5IElP QU0gZGF0YSB3aXRob3V0IGFueSByZWd1bGFyIGRhdGENCj4gICAgcGF5bG9hZC4NCj4gDQo+IFNv LCBpZiB0aGUgb25seSBpT0FNIG1lc3NhZ2UgaXMgY2FycmllZCBpbiBvciBhZnRlciBhbiBOU0gs IGl0IGlzIGlkZW50aWZpZWQgYXMgT0FNLiBBbmQsIGJ5IHlvdXIgb3duIGV4YW1wbGUgaW4gdGhl IGVhcmxpZXIgbm90ZSwgc28gc2hvdWxkIFZYTEFOLUdQRS4NCj4gDQo+IFJlZ2FyZHMsDQo+IEdy ZWcNCj4gDQo+IE9uIFdlZCwgQXByIDE3LCAyMDE5IGF0IDEyOjQ0IFBNIENhcmxvcyBQaWduYXRh cm8gKGNwaWduYXRhKSA8Y3BpZ25hdGFAY2lzY28uY29tPiB3cm90ZToNCj4gSGksIEdyZWcsDQo+ IA0KPiBBZGRpbmcgdGhlIElQUE0gbWFpbGluZyBsaXN0LCBzaW5jZSB5b3UgcmVmZXJlbmNlIGl0 IGJlbG93LCBhbmQgcG9pbnQgdG8gUkZDIDc3OTkuDQo+IA0KPiBQbGVhc2Ugc2VlIGlubGluZS4N Cj4gDQo+ID4gT24gQXByIDE3LCAyMDE5LCBhdCAzOjAwIFBNLCBHcmVnIE1pcnNreSA8Z3JlZ2lt aXJza3lAZ21haWwuY29tPiB3cm90ZToNCj4gPiANCj4gPiBIaSBDYXJsb3MsDQo+ID4gdGhhbmsg eW91IGZvciBzaGFyaW5nIHlvdXIgdmlldyBvbiB0aGUgZGVzaWduIG9mIHRoZSBWWExBTi1HUEUg cHJvdG9jb2wuIFBsZWFzZSBmaW5kIG15IGNvbW1lbnRzIGluLWxpbmUgdGFnZ2VkIEdJTT4+Lg0K PiA+IA0KPiA+IFJlZ2FyZHMsDQo+ID4gR3JlZw0KPiA+IA0KPiA+IE9uIEZyaSwgQXByIDEyLCAy MDE5IGF0IDU6MjMgQU0gQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIDxjcGlnbmF0YUBjaXNj by5jb20+IHdyb3RlOg0KPiA+IEdyZWcsDQo+ID4gDQo+ID4gWW91IHNlZW0gdG8gYmUgY29uZnVz aW5nIGFuZCBtaXhpbmcgdGhpbmdzIHVwLg0KPiA+IA0KPiA+IFBsZWFzZSBzZWUgaW5saW5lLg0K PiA+IA0KPiA+ID4gT24gQXByIDEyLCAyMDE5LCBhdCAyOjUwIEFNLCBHcmVnIE1pcnNreSA8Z3Jl Z2ltaXJza3lAZ21haWwuY29tPiB3cm90ZToNCj4gPiA+IA0KPiA+ID4gRGVhciBFZGl0b3JzLCBl dCBhbC4sDQo+ID4gPiBJJ3ZlIHJlYWQgdGhlIGxhdGVzdCAtMDcgdmVyc2lvbiBhbmQgd291bGQg bGlrZSB0byBzaGFyZSBteSBjb21tZW50cyBhbmQgcXVlc3Rpb25zIHdpdGggeW91Og0KPiA+ID4g ICAgICAg4oCiIGluIHRoZSBlYXJsaWVyIHZlcnNpb24gb2YgdGhlIGRyYWZ0LCB0aGUgTy1iaXQg d2FzIGludHJvZHVjZWQgYW5kIGRlZmluZWQgYXM6DQo+ID4gPiBPQU0gRmxhZyBCaXQgKE8gYml0 KTogIFRoZSBPIGJpdCBpcyBzZXQgdG8gaW5kaWNhdGUgdGhhdCB0aGUgcGFja2V0IGlzIGFuIE9B TSBwYWNrZXQuDQo+ID4gPiBBdCB0aGUgc2FtZSB0aW1lLCBpbiB0aGUgbGF0ZXN0IHZlcnNpb24s IHRoZSBuZXcgTmV4dCBQcm90b2NvbCB2YWx1ZSAoMHg4MSkgdG8gaWRlbnRpZnkgaU9BTSBEYXRh IHdhcyBpbnRyb2R1Y2VkLiBIZW5jZSBhcmUgbXkgcXVlc3Rpb25zOg0KPiA+ID4gICAgICAg4oCi IFdoYXQgbXVzdCBiZSB0aGUgdmFsdWUgb2YgdGhlIE8tYml0IHdoZW4gdGhlIHZhbHVlIG9mIHRo ZSBOZXh0IFByb3RvY29sIGZpZWxkIGlzIGlPQU0/DQo+ID4gDQo+ID4gVGhlIE8gYml0IOKAnGlz IHNldCB0byBpbmRpY2F0ZSB0aGF0IHRoZSBwYWNrZXQgaXMgYW4gT0FNIHBhY2tldOKAnS4NCj4g PiBJQU9NIGlzIG5vdCBhbiBPQU0gcGFja2V0LiBIZW5jZSwgTyBiaXQgY2xlYXIgaWYgVlhMQU4t R1BFIGVuY2Fwc3VsYXRlcyBhIG5vbi1PQU0gcGFja2V0IGFuZCBhZGRzIGFuIElPQU0gc2hpbS4N Cj4gPiBHSU0+PiBJdCBpcyBhIHZlcnkgdW5leHBlY3RlZCBzdGF0ZW1lbnQgZnJvbSB5b3UsDQo+ IA0KPiBJIHdvdWxkIHRlbGwgeW91IOKAmGV4cGVjdCB0aGUgdW5leHBlY3RlZOKAmSwgYnV0IHRo YXQgaXMgbm90IHRoZSBjYXNlIGhlcmUuLi4gOi0pDQo+IA0KPiBJZiB5b3UgYWN0dWFsbHkgcmVh ZCBteSBzdGF0ZW1lbnQsIHlvdSB3aWxsIHNlZSAiSUFPTSBpcyBub3QgYW4gT0FNICpwYWNrZXQq LuKAnSBOZXcgZW1waGFzaXMgYWRkZWQg4oCUIGl0IGlzIF9ub3RfICphbiBPQU0gcGFja2V0Ki4N Cj4gDQo+IEkgc3RhbmQgYnkgaXQuIEl04oCZcyBhbiBhdWdtZW50ZWQgZGF0YSBwYWNrZXQgb2Yg aW50ZXJlc3QuDQo+IA0KPiA+IG9uZSBvZiB0aGUgY28tYXV0aG9ycyBvZiBkcmFmdC1pZXRmLWlw cG0taW9hbS1kYXRhICB3aGVyZSB0aGUgZmlyc3QgcGFyYWdyYXBoIG9mIHRoZSBJbnRyb2R1Y3Rp b24gc2VjdGlvbiBkZWZpbmVzIGlPQU0gYXMgSHlicmlkIFR5cGUgMSBPQU0sIGFjY29yZGluZyB0 byBSRkMgNzc5OSBjbGFzc2lmaWNhdGlvbjoNCj4gDQo+IFRoaXMgaXMgc3RpbGwgcXVpdGUgY29u c2lzdGVudCB3aXRoIHRoYXQgZGVmaW5pdGlvbiwgd2hpY2ggSSByZWNvbW1lbmQgeW91IHJlLXJl YWQ6DQo+IA0KPiBSRkMgNzc5OSBpcyBhYm91dCBtZXRyaWNzIGFuZCBtZXRob2RzLCBub3QgcGFj a2V0IGRlZmluaXRpb25zLg0KPiANCj4gWW91IHdpbGwgc2VlIHRoYXQgQWN0aXZlIG1ldGhvZHMg aW5jbHVkZSBhIOKAnGRlZGljYXRlZCBtZWFzdXJlbWVudCBwYWNrZXQgc3RyZWFt4oCdLiDigJxB Y3RpdmUgTWV0aG9kcyBnZW5lcmF0ZSBwYWNrZXQgc3RyZWFtcy7igJ0NCj4gDQo+IEhvd2V2ZXIs IEh5YnJpZCBUeXBlIEkgbGV2ZXJhZ2VzIOKAnEF1Z21lbnRhdGlvbiBvciBtb2RpZmljYXRpb24g b2YgdGhlIHN0cmVhbSBvZiBpbnRlcmVzdCINCj4gDQo+IEZvbGxvd2luZyB5b3VyIGxvZ2ljLCBp ZiB5b3UgY2hhbmdlIGEgcGFja2V0IGZpZWxkIHN1Y2ggYXMgVFRML0hMIHRvIHByb3ZpZGUgcGFj a2V0IGNvbG9yaW5nLCBkbyB5b3UgbmVlZCB0byBzZXQgdGhlIE8tYml0Pw0KPiANCj4gPiAgICBJ T0FNIGlzIHRvIGNvbXBsZW1lbnQNCj4gPiAgICBtZWNoYW5pc21zIHN1Y2ggYXMgUGluZyBvciBU cmFjZXJvdXRlLCBvciBtb3JlIHJlY2VudCBhY3RpdmUgcHJvYmluZw0KPiA+ICAgIG1lY2hhbmlz bXMgYXMgZGVzY3JpYmVkIGluIFtJLUQubGFwdWtob3YtZGF0YXBsYW5lLXByb2JlXS4uICBJbiB0 ZXJtcw0KPiA+ICAgIG9mICJhY3RpdmUiIG9yICJwYXNzaXZlIiBPQU0sICJpbi1zaXR1IiBPQU0g Y2FuIGJlIGNvbnNpZGVyZWQgYQ0KPiA+ICAgIGh5YnJpZCBPQU0gdHlwZS4gIFdoaWxlIG5vIGV4 dHJhIHBhY2tldHMgYXJlIHNlbnQsIElPQU0gYWRkcw0KPiA+ICAgIGluZm9ybWF0aW9uIHRvIHRo ZSBwYWNrZXRzIHRoZXJlZm9yZSBjYW5ub3QgYmUgY29uc2lkZXJlZCBwYXNzaXZlLg0KPiA+ICAg IEluIHRlcm1zIG9mIHRoZSBjbGFzc2lmaWNhdGlvbiBnaXZlbiBpbiBbUkZDNzc5OV0gSU9BTSBj b3VsZCBiZQ0KPiA+ICAgIHBvcnRyYXllZCBhcyBIeWJyaWQgVHlwZSAxLg0KPiA+IA0KPiA+ID4g ICAgICAg4oCiIERvIHlvdSBwbGFuIHRvIGRlZmluZSB0aGUgTmV4dCBQcm90b2NvbCB2YWx1ZXMg Zm9yIGFjdGl2ZSBPQU0gcHJvdG9jb2xzLCBlLmcuLCBFY2hvIFJlcXVlc3QvUmVwbHksIEJGRCwg UGVyZm9ybWFuY2UgTW9uaXRvcmluZz8NCj4gPiANCj4gPiBJIGNhbm5vdCBzcGVhayB0byDigJxw bGFuc+KAnSAocmVwbHlpbmcgYXMg4oCcZXQgYWwu4oCdLCBub3QgYXMg4oCcZWRpdG9y4oCdKSwg YnV0IEkgZXhwZWN0IE9BTSBkb2N1bWVudHMgb3VnaHQgdG8gaGF2ZSB0aG9zZSByZXF1ZXN0ZWQs IGFuZCB5b3UgZG8gbm90IG5lZWQgbmVjZXNzYXJpbHkgYWxsIG9mIHRob3NlIOKAlCB0aGUgbmV4 IHByb3RvY29sIElQdjQgLyBJUHY2IGNhbiBlbmNhcHN1bGF0ZSBJQ01QLCBVRFAvQkZELCBldGMu LCBldGMuLCBldGMuLCBldGMuDQo+ID4gR0lNPj4gT2YgY291cnNlLCB1c2Ugb2YgdGhlIHdlbGwt a25vd24gcG9ydCBudW1iZXIsIHVzdWFsbHkgaXQgaXMgVURQIGRlc3RpbmF0aW9uIHBvcnQsIGlz IG9uZSBvZiB0aGUgbWV0aG9kcyB0byBkZW11bHRpcGxleCBwcm90b2NvbHMuIFRoaXMgbWV0aG9k IGlzIGJyb2FkbHkgdXNlZCwgZm9yIGV4YW1wbGUsIGluIE1QTFMgT0FNLiBCdXQgdGhpcyBtZXRo b2QgaGFzIHNvbWUgZGlzYWR2YW50YWdlcyB0aGF0IHdlcmUgcG9pbnRlZCBvdXQgaW4gdGhlIGRp c2N1c3Npb24gb2YgQkZEIG92ZXIgR0VORVZFIGluIFByYWd1ZSBieSBEYXZpZCBCbGFjayAodGhl IGxhc3QgcHJlc2VudGF0aW9uIGluIHRoZSBtaW51dGVzKToNCj4gPiBEYXZpZDogSSB3YW50IHRo ZSBCRkQgaGVhZGVyIHRvIGJlIGFzIGNsb3NlIHRvIHRoZSB0aGluZyB3aG9zZSBsaXZlbmVzcyBJ J20gdGVzdGluZy4gVGhlIG1vcmUgaGVhZGVycyB5b3UgYWRkIGluIHRoZSBtaWRkbGUsIHRoZSBt b3JlIHdheXMgdGhlcmUgYXJlIHRvIGJyZWFrIEJGRCB3aXRob3V0IGJyZWFraW5nIHRoZSBmb3J3 YXJkaW5nIGVuZ2luZS4gVGhlIGZ1cnRoZXIgYXdheSBJIG1vdmUgQkZEIGZyb20gdGhlIGNodW5r IG9mIGhhcmR3YXJlJ3MgbGl2ZW5lc3MgSSBjYXJlIGFib3V0LCB0aGUgbW9yZSBvcHBvcnR1bml0 aWVzIGFyZSBmb3IgQkZEIGFuZCB0aGUgaGFyZHdhcmUgdG8gbm90IHRvIHRlbGwgbWUgdGhlIHNh bWUgdGhpbmcuDQo+ID4gDQo+IA0KPiBUaGVvcnkgYW5kIHByYWN0aWNlIG1hdGNoIGluIHRoZW9y eSwgbGVzcyBzbyBpbiBwcmFjdGljZSDigJQgdW5sZXNzIHlvdSBhcmUgcGxhbm5pbmcgdG8gdXBk YXRlIFJGQyA1ODgxLg0KPiANCj4gVGhpcyBjYW4gYmUgYXJndWVkIGJvdGggd2F5cyAoZS5nLiwg YmV0dGVyIHRvIGhhdmUgY29tbW9uIGhhbmRsZXJzLCBldGMuKSwgYnV0IEkgdGFrZSBubyBwb3Np dGlvbi4gSSBkbyBzYXkgdGhhdCBpbiBwcmVzZW5jZSBvZiBkZXBsb3llZCBPQU0gZW5jYXBzdWxh dGlvbnMsIHRoZXJl4oCZcyBubyBiYXNpcyBmb3IgeW91ciB5b3VyIGNvbW1lbnQgYWJvdXQgZGVm aW5pbmcgYSBwcm90b2NvbCB0eXBlIGZvciDigJxQZXJmb3JtYW5jZSBNb25pdG9yaW5n4oCdIGFz IGEgcHJvdG9jb2wuLi4NCj4gDQo+IA0KPiA+IA0KPiA+ID4gICAgICAg4oCiIEhvdyB0byBpbnRl cnByZXQgdGhlIHNpdHVhdGlvbiB3aGVuIHRoZSBPLWJpdCB2YWx1ZSBpcyAxIGJ1dCB0aGUgdmFs dWUgb2YgdGhlIE5leHQgUHJvdG9jb2wgZmllbGQgaXMsIGZvciBleGFtcGxlLCBOU0gsIGkuZS4u LCBub3QgYW55IG9mIE9BTSBwcm90b2NvbHM/DQo+ID4gDQo+ID4gSSBleHBlY3QgaXQgbWVhbnMg dGhlcmXigJlzIE9BTSB3aXRoaW4gdGhhdCBOU0ggKHNvbWV0aW1lcyB0aGVyZeKAmXMgbm8gc3Vj aCB0aGluZ3MgYXMg4oCcT0FNIFByb3RvY29sc+KAnSksIG9yIGFuIHVuaGFuZGxlZCBPQU0gcHJv dG9jb2wuDQo+ID4gR0lNPj4gU2hvdWxkIHRoYXQsIGkuZS4sIE9BTSBpbiBOU0ggb3IgaW1tZWRp YXRlbHkgZm9sbG93aW5nIE5TSCBiZSBzaWduYWxlZCB1c2luZyBTRkMgTlNIIG1ldGhvZHMgdGhh dCBhcmUgYWxyZWFkeSBkZWZpbmVkIGluIGRyYWZ0LWlldGYtc2ZjLW11bHRpLWxheWVyLW9hbT8N Cj4gDQo+IA0KPiBOb24gc2VxdWl0dXIg4oCUIEkgZG8gbm90IGZvbGxvdyB3aGF0IHNpZ25hbGlu ZyBoYXMgdG8gZG8gd2l0aCB0aGUgY29udmVyc2F0aW9uLCBub3IgaG93IHRoYXQgZHJhZnQgbWln aHQgYmUgcmVsZXZhbnQuDQo+IA0KPiA+IFVzaW5nIHRoZSBzZXJ2ZXIgbGF5ZXIsIGFzIHlvdSd2 ZSBzdWdnZXN0ZWQsIHNlZW1zIGFzIGxheWVyIHZpb2xhdGlvbi4gDQo+ID4gDQo+IA0KPiBUaGlz IGlzIGEgZnVubnkgc3RhdGVtZW50IOKAlCBOVk8zIGlzIGEgbGF5ZXIgdmlvbGF0aW9uIDotKSBT byBhcmUgUHNldWRvd2lyZXMuIFBsZWFzZSBkbyBub3QgdGFrZSB0aGlzIHN0YXRlbWVudCB0b28g c2VyaW91c2x5LCBpdCBpcyBub3QgaW52aXRpbmcgZGlzY3Vzc2lvbi4NCj4gDQo+ID4gPiAgICAg ICDigKIgSSBiZWxpZXZlIHRoYXQgdGhlIHVzZSBvZiB0aGUgZGVkaWNhdGVkIE9BTSBmbGFnIGFu ZCB0aGUgTmV4dCBQcm90b2NvbCBmaWVsZCBmb3IgYSBmaXhlZC1zaXplIGhlYWRlciB0aGF0IGNh bm5vdCBpbmNsdWRlIG1ldGEtZGF0YSBpcyB1bndhcnJhbnRlZCBhbmQgYWRkcyB1bm5lY2Vzc2Fy eSBjb21wbGV4aXR5Lg0KPiA+IA0KPiA+IERpc2FncmVlLiANCj4gPiANCj4gPiBTZWUgZXhhbXBs ZSB3aGVyZSBwcm90b2NvbCBpcyBJUCBjYXJyeWluZyBhbiBPQU0gcGFja2V0Lg0KPiA+IEdJTT4+ IFdoZW4gSVAvVURQIGVuY2Fwc3VsYXRpb24gaXMgdXNlZCBmb3IgT0FNLCB0aGVyZSdzIG5vLCBp biBteSBvcGluaW9uLCBhbnkgbmVlZCB0byB1c2UgdGhlIE8tYml0LiBUaGUgZGVzdGluYXRpb24g SVAgYWRkcmVzcyBtdXN0IGJlIGFzIGRlc2NyaWJlZCBpbiBSRkMgODAyOSBvciBSRkMgNTg4NCBh bmQgdGhlIGRlbXVsdGlwbGV4aW5nIGlzIGRvbmUgYmFzZWQgb24gdGhlIGRlc3RpbmF0aW9uIFVE UCBwb3J0IG51bWJlci4gQ2xlYXJseSwgTy1iaXQgaXMgdW5uZWNlc3NhcnkgaWYgSVAvVURQIGVu Y2Fwc3VsYXRpb24gZm9yIE9BTSBiZWluZyB1c2VkLg0KPiA+IA0KPiANCj4gRm9ydHVuYXRlbHks IGJpdCB1c2FnZSBpcyBhIG1hdHRlciBvZiBkZWZpbml0aW9uIGFuZCBub3Qgb3BpbmlvbiA6LSkN Cj4gDQo+IEtpbmQgcmVnYXJkcywNCj4gDQo+IENhcmxvcy4NCj4gDQo+IA0KPiA+ID4gSSBzdWdn ZXN0IG5vdCB0byB1c2UgTy1iaXQgaW4gdGhlIFZYTEFOLUdQRSBoZWFkZXIgYW5kIHJlbGVhc2Ug aXQgaW50byB0aGUgUmVzZXJ2ZWQgZmllbGQuICBJIGRvbid0IHNlZSB0aGUgYXBwYXJlbnQgYmVu ZWZpdCBvZiB1c2luZyB0aGUgZmxhZywgYXMgdGhlIFZYTEEtR1BFIHVzZXMgdGhlIGZpeGVkIHNp emUgaGVhZGVyIGFuZCB0aGUgaGVhZGVyIGNhbm5vdCBjYXJyeSBPQU0gZGF0YSBpbiBpdC4gVGhl IG9ubHkgcm9sZSB0aGUgVlhMQU4tR1BFIGhlYWRlciBtdXN0IHBlcmZvcm0sIGluIG15IG9waW5p b24sIGlzIHRvIHVuYW1iaWd1b3VzbHkgaWRlbnRpZnkgdGhlIHBheWxvYWQgdHlwZSB0aGF0IGlt bWVkaWF0ZWx5IGZvbGxvd3MgdGhlIGhlYWRlciBhcyBPQU0gKGRlbXVsdGlwbGV4aW5nIE9BTSBw cm90b2NvbHMgbWF5IGJlIGRvbmUgaW4gT0FNIEhlYWRlciBzaGltKS4NCj4gPiA+IE11Y2ggYXBw cmVjaWF0ZSB5b3VyIGNvbnNpZGVyYXRpb24uDQo+ID4gPiANCj4gPiANCj4gPiBCZXN0LA0KPiA+ IA0KPiA+IOKAlA0KPiA+IENhcmxvcyBQaWduYXRhcm8sIGNhcmxvc0BjaXNjby5jb20NCj4gPiAN Cj4gPiDigJxTb21ldGltZXMgSSB1c2UgYmlnIHdvcmRzIHRoYXQgSSBkbyBub3QgZnVsbHkgdW5k ZXJzdGFuZCwgdG8gbWFrZSBteXNlbGYgc291bmQgbW9yZSBwaG90b3N5bnRoZXNpcy4iDQo+ID4g DQo+ID4gPiBSZWdhcmRzLA0KPiA+ID4gR3JlZw0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IG52bzMgbWFpbGluZyBsaXN0DQo+ID4g PiBudm8zQGlldGYub3JnDQo+ID4gPiBodHRwczovL3NlY3VyZS13ZWIuY2lzY28uY29tLzFqLWpy NjR5aDJEOHlPOTJpYmNxYU4tSDk4WkNQM2xRZEhtc1lQc0g4bGtqc2E0V2xKNGtnM1c0SEw4cVQy NXJDVml0dFQ1YkZRb3hfX09uU2tuVjV3X3dXNjlGdlVoWGt4cXhLaGk5TUNpeTVvSC1KVHVjWE5f N0ZLODVxN2pELXFFd1JNNUlYWTY4X1ZmZWJfWEkyckt4eXp3VnNHXzA2S1RHRjA5Qnc5b0hBT1hV TkZjZEN3X29vbl9lcnVVaFJQdGR3TGM5VVFOejJUaFlQOHlzZjJwcjY0VlUwNFZqTUttR3dxWXZ6 enlBc0xURWJIcnM3R1ZDcXBoVDU4VDBzdDc4Xzk2OHJNNU1LRkxrN0VpV0JqN2daUG1fckRlQmY2 M2dVdHhrY2otdzhYeWJKaWlPMnRjRmFlb0FMXzhtLVpUNUw5LTFWSzR3WmtIbVI1Q19MZGcvaHR0 cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZudm8zDQo+ID4g DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBudm8zIG1haWxpbmcgbGlzdA0KPiBudm8zQGlldGYub3JnDQo+IGh0dHBzOi8vc2VjdXJlLXdl Yi5jaXNjby5jb20vMWotanI2NHloMkQ4eU85MmliY3FhTi1IOThaQ1AzbFFkSG1zWVBzSDhsa2pz YTRXbEo0a2czVzRITDhxVDI1ckNWaXR0VDViRlFveF9fT25Ta25WNXdfd1c2OUZ2VWhYa3hxeEto aTlNQ2l5NW9ILUpUdWNYTl83Rks4NXE3akQtcUV3Uk01SVhZNjhfVmZlYl9YSTJyS3h5endWc0df MDZLVEdGMDlCdzlvSEFPWFVORmNkQ3dfb29uX2VydVVoUlB0ZHdMYzlVUU56MlRoWVA4eXNmMnBy NjRWVTA0VmpNS21Hd3FZdnp6eUFzTFRFYkhyczdHVkNxcGhUNThUMHN0NzhfOTY4ck01TUtGTGs3 RWlXQmo3Z1pQbV9yRGVCZjYzZ1V0eGtjai13OFh5YkppaU8ydGNGYWVvQUxfOG0tWlQ1TDktMVZL NHdaa0htUjVDX0xkZy9odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0 aW5mbyUyRm52bzMNCg0K From nobody Wed Apr 17 17:49:24 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5411201A2; Wed, 17 Apr 2019 17:49:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 XnWwcVhP-3rX; Wed, 17 Apr 2019 17:49:14 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADA45120033; Wed, 17 Apr 2019 17:49:13 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id h21so318927ljk.13; Wed, 17 Apr 2019 17:49:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CWa0oGr0pe1svZPWxNBzRmESGnGjYp6DFSbq8/v3MUs=; b=GShRXdhuPfFpKkHwQjWw2l1LGw6b4BoBvJ2+bNSZY2DTiU/ONY6MzaWtpPfw8s6OY/ YwCNx4Rz6RJpZVjWVdU7Ult18Egtaw521lJMPbWZ6o7NkH/tSOLO9EsZEwNWLkNpvoZQ z9Rlr6ZJBdZYG/CKKfVwXnSa7jzT+lBLyCBcThiQq4YCZ6ZPclOndIgApjMiIax6ONvB uggnzoDiBRE52zRkaKNWcxJGfbbgvi68F0LAARiq4HHmVo+wXqepz+BJjaB4d0qT33u1 Ewz0FVggknyPXNvZ/cUnOA6jsevYugL84/JS12XMWxK4G2bp+YhzqYvjUWC8205KFoTH BAYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CWa0oGr0pe1svZPWxNBzRmESGnGjYp6DFSbq8/v3MUs=; b=LYwINxGceBXX90yunEb3o4Ge1tcAJJpaIcKyCkZegTtdhUWPL8yPN/lhXj39oBpvCI y3wSHYCzKcA2gxz2w8e5shd5dn4qACokNWjyNu0O7h5Bdsoe1H8ZhWU0lO9h091eKD7e ImyQi0UBu8zkYoia0Dutr/dkSu61BxbvqbaSrJXwUV9HOW+npnrNRXqFYTkCsZG7H7c7 +Z5e0K07oug/iq/teZzka1Zzh9hf6Af9g3ynFtZerU0V7wvLvuI+puXqBrAGOPY1F7Nx 6vEGMfRnC07PnF/MsiTkg5F5E2PKMbV9O9LuX+ZiVq2dtgLnKS9Qwy1Ra9+WyTHjRxc0 XO8w== X-Gm-Message-State: APjAAAWrj/2sWqPMgmZfILLtut/s9hYgqhOn1w1UYGUOl7ISuwEN87vh 4gH/dsRLeBueJtmjSCS5NoITvAf3Buqxr9S1Sg4= X-Google-Smtp-Source: APXvYqzpJeHXpYpzLAdgQ4P1myEem8WNHGwWqO5/2LSOskbloD2oA5CI0r/6Y/Q2qO4bKBiYsYbIWZYw6j4O7aqVVM0= X-Received: by 2002:a2e:5d56:: with SMTP id r83mr49576870ljb.74.1555548551719; Wed, 17 Apr 2019 17:49:11 -0700 (PDT) MIME-Version: 1.0 References: <12ACA02A-BB51-4214-A72B-1AEFCCB914AC@cisco.com> <3AFD4751-CF3A-4939-A49A-FB981C68CADF@cisco.com> <4C9CDD29-BDF8-425E-998F-B12C1BD7CA7C@cisco.com> In-Reply-To: <4C9CDD29-BDF8-425E-998F-B12C1BD7CA7C@cisco.com> From: Greg Mirsky Date: Wed, 17 Apr 2019 17:49:04 -0700 Message-ID: To: "Carlos Pignataro (cpignata)" Cc: NVO3 , "draft-ietf-nvo3-vxlan-gpe@ietf.org" , IETF IPPM WG , "sfc@ietf.org" Content-Type: multipart/alternative; boundary="000000000000db2fac0586c35e28" Archived-At: Subject: Re: [ippm] [SUSPICIOUS] Re: [nvo3] Comments on draft-ietf-nvo3-vxlan-gpe X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 00:49:17 -0000 --000000000000db2fac0586c35e28 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Carlos, thank you for the discussion. As the VXLAN-GPE is on the Informational track, there may be little point to discuss it. But as the draft has been adopted by NVO3 WG, I'm curious about the updates the editors have been making without the WG agreeing to that. I'm looking forward to hearing from any of the editors of VXLAN-GPE about the updates in the last two versions. Also, hope editors of the draft will find time to reply to my questions and consider my comments. Regards, Greg On Wed, Apr 17, 2019 at 5:18 PM Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Dear Greg, > > [Now adding the SFC WG Mailing list since you take us to a different WG > again] > > Thank you very much for fine-combing with a magnifying glass through all > the documents I=E2=80=99m currently co-authoring :-) > > It is refreshing to see that the only issues you find are non-issues, and > your questions easy to re-answer :-) > > At this point I am a bit at a loss of what your point is, or what you are > trying to prove bending text. Are you coding, deploying, or testing IOAM = on > NSH without data packets on VXLAN-GPE over IP? NSH is data as far as > VXLAN-GPE is concerned. IOAM shimmed in NSH is orthogonal to IOAM shimmed > in VXLAN-GPE. > > I feel this discussion about the O-bit already took place once or twice. > > Kind Regards, > > =E2=80=94 Carlos Pignataro > > PS: The Evil bit is defined for IPv4, should we therefore also define it > here? > > > > On Apr 17, 2019, at 5:54 PM, Greg Mirsky wrote: > > > > Hi Carlos, > > to add another quote from the draft-ietf-sfc-ioam-nsh that you've > co-authored, > > Packets with IOAM data included MUST follow this > > definition, i.e. the O bit MUST NOT be set for regular customer > > traffic which also carries IOAM data and the O bit MUST be set for > > OAM packets which carry only IOAM data without any regular data > > payload. > > > > So, if the only iOAM message is carried in or after an NSH, it is > identified as OAM. And, by your own example in the earlier note, so shoul= d > VXLAN-GPE. > > > > Regards, > > Greg > > > > On Wed, Apr 17, 2019 at 12:44 PM Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > > Hi, Greg, > > > > Adding the IPPM mailing list, since you reference it below, and point t= o > RFC 7799. > > > > Please see inline. > > > > > On Apr 17, 2019, at 3:00 PM, Greg Mirsky > wrote: > > > > > > Hi Carlos, > > > thank you for sharing your view on the design of the VXLAN-GPE > protocol. Please find my comments in-line tagged GIM>>. > > > > > > Regards, > > > Greg > > > > > > On Fri, Apr 12, 2019 at 5:23 AM Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > > > Greg, > > > > > > You seem to be confusing and mixing things up. > > > > > > Please see inline. > > > > > > > On Apr 12, 2019, at 2:50 AM, Greg Mirsky > wrote: > > > > > > > > Dear Editors, et al., > > > > I've read the latest -07 version and would like to share my comment= s > and questions with you: > > > > =E2=80=A2 in the earlier version of the draft, the O-bit was > introduced and defined as: > > > > OAM Flag Bit (O bit): The O bit is set to indicate that the packet > is an OAM packet. > > > > At the same time, in the latest version, the new Next Protocol valu= e > (0x81) to identify iOAM Data was introduced. Hence are my questions: > > > > =E2=80=A2 What must be the value of the O-bit when the value = of the > Next Protocol field is iOAM? > > > > > > The O bit =E2=80=9Cis set to indicate that the packet is an OAM packe= t=E2=80=9D. > > > IAOM is not an OAM packet. Hence, O bit clear if VXLAN-GPE > encapsulates a non-OAM packet and adds an IOAM shim. > > > GIM>> It is a very unexpected statement from you, > > > > I would tell you =E2=80=98expect the unexpected=E2=80=99, but that is n= ot the case > here... :-) > > > > If you actually read my statement, you will see "IAOM is not an OAM > *packet*.=E2=80=9D New emphasis added =E2=80=94 it is _not_ *an OAM packe= t*. > > > > I stand by it. It=E2=80=99s an augmented data packet of interest. > > > > > one of the co-authors of draft-ietf-ippm-ioam-data where the first > paragraph of the Introduction section defines iOAM as Hybrid Type 1 OAM, > according to RFC 7799 classification: > > > > This is still quite consistent with that definition, which I recommend > you re-read: > > > > RFC 7799 is about metrics and methods, not packet definitions. > > > > You will see that Active methods include a =E2=80=9Cdedicated measureme= nt packet > stream=E2=80=9D. =E2=80=9CActive Methods generate packet streams.=E2=80= =9D > > > > However, Hybrid Type I leverages =E2=80=9CAugmentation or modification = of the > stream of interest" > > > > Following your logic, if you change a packet field such as TTL/HL to > provide packet coloring, do you need to set the O-bit? > > > > > IOAM is to complement > > > mechanisms such as Ping or Traceroute, or more recent active probi= ng > > > mechanisms as described in [I-D.lapukhov-dataplane-probe].. In > terms > > > of "active" or "passive" OAM, "in-situ" OAM can be considered a > > > hybrid OAM type. While no extra packets are sent, IOAM adds > > > information to the packets therefore cannot be considered passive. > > > In terms of the classification given in [RFC7799] IOAM could be > > > portrayed as Hybrid Type 1. > > > > > > > =E2=80=A2 Do you plan to define the Next Protocol values for = active > OAM protocols, e.g., Echo Request/Reply, BFD, Performance Monitoring? > > > > > > I cannot speak to =E2=80=9Cplans=E2=80=9D (replying as =E2=80=9Cet al= .=E2=80=9D, not as =E2=80=9Ceditor=E2=80=9D), but > I expect OAM documents ought to have those requested, and you do not need > necessarily all of those =E2=80=94 the nex protocol IPv4 / IPv6 can encap= sulate > ICMP, UDP/BFD, etc., etc., etc., etc. > > > GIM>> Of course, use of the well-known port number, usually it is UDP > destination port, is one of the methods to demultiplex protocols. This > method is broadly used, for example, in MPLS OAM. But this method has som= e > disadvantages that were pointed out in the discussion of BFD over GENEVE = in > Prague by David Black (the last presentation in the minutes): > > > David: I want the BFD header to be as close to the thing whose > liveness I'm testing. The more headers you add in the middle, the more wa= ys > there are to break BFD without breaking the forwarding engine. The furthe= r > away I move BFD from the chunk of hardware's liveness I care about, the > more opportunities are for BFD and the hardware to not to tell me the sam= e > thing. > > > > > > > Theory and practice match in theory, less so in practice =E2=80=94 unle= ss you > are planning to update RFC 5881. > > > > This can be argued both ways (e.g., better to have common handlers, > etc.), but I take no position. I do say that in presence of deployed OAM > encapsulations, there=E2=80=99s no basis for your your comment about defi= ning a > protocol type for =E2=80=9CPerformance Monitoring=E2=80=9D as a protocol.= .. > > > > > > > > > > > =E2=80=A2 How to interpret the situation when the O-bit value= is 1 but > the value of the Next Protocol field is, for example, NSH, i.e.., not any > of OAM protocols? > > > > > > I expect it means there=E2=80=99s OAM within that NSH (sometimes ther= e=E2=80=99s no > such things as =E2=80=9COAM Protocols=E2=80=9D), or an unhandled OAM prot= ocol. > > > GIM>> Should that, i.e., OAM in NSH or immediately following NSH be > signaled using SFC NSH methods that are already defined in > draft-ietf-sfc-multi-layer-oam? > > > > > > Non sequitur =E2=80=94 I do not follow what signaling has to do with th= e > conversation, nor how that draft might be relevant. > > > > > Using the server layer, as you've suggested, seems as layer violation= . > > > > > > > This is a funny statement =E2=80=94 NVO3 is a layer violation :-) So ar= e > Pseudowires. Please do not take this statement too seriously, it is not > inviting discussion. > > > > > > =E2=80=A2 I believe that the use of the dedicated OAM flag an= d the > Next Protocol field for a fixed-size header that cannot include meta-data > is unwarranted and adds unnecessary complexity. > > > > > > Disagree. > > > > > > See example where protocol is IP carrying an OAM packet. > > > GIM>> When IP/UDP encapsulation is used for OAM, there's no, in my > opinion, any need to use the O-bit. The destination IP address must be as > described in RFC 8029 or RFC 5884 and the demultiplexing is done based on > the destination UDP port number. Clearly, O-bit is unnecessary if IP/UDP > encapsulation for OAM being used. > > > > > > > Fortunately, bit usage is a matter of definition and not opinion :-) > > > > Kind regards, > > > > Carlos. > > > > > > > > I suggest not to use O-bit in the VXLAN-GPE header and release it > into the Reserved field. I don't see the apparent benefit of using the > flag, as the VXLA-GPE uses the fixed size header and the header cannot > carry OAM data in it. The only role the VXLAN-GPE header must perform, in > my opinion, is to unambiguously identify the payload type that immediatel= y > follows the header as OAM (demultiplexing OAM protocols may be done in OA= M > Header shim). > > > > Much appreciate your consideration. > > > > > > > > > > Best, > > > > > > =E2=80=94 > > > Carlos Pignataro, carlos@cisco.com > > > > > > =E2=80=9CSometimes I use big words that I do not fully understand, to= make > myself sound more photosynthesis." > > > > > > > Regards, > > > > Greg > > > > _______________________________________________ > > > > nvo3 mailing list > > > > nvo3@ietf.org > > > > > https://secure-web.cisco.com/1j-jr64yh2D8yO92ibcqaN-H98ZCP3lQdHmsYPsH8lkj= sa4WlJ4kg3W4HL8qT25rCVittT5bFQox__OnSknV5w_wW69FvUhXkxqxKhi9MCiy5oH-JTucXN_= 7FK85q7jD-qEwRM5IXY68_Vfeb_XI2rKxyzwVsG_06KTGF09Bw9oHAOXUNFcdCw_oon_eruUhRP= tdwLc9UQNz2ThYP8ysf2pr64VU04VjMKmGwqYvzzyAsLTEbHrs7GVCqphT58T0st78_968rM5MK= FLk7EiWBj7gZPm_rDeBf63gUtxkcj-w8XybJiiO2tcFaeoAL_8m-ZT5L9-1VK4wZkHmR5C_Ldg/= https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fnvo3 > > > > > > > _______________________________________________ > > nvo3 mailing list > > nvo3@ietf.org > > > https://secure-web.cisco.com/1j-jr64yh2D8yO92ibcqaN-H98ZCP3lQdHmsYPsH8lkj= sa4WlJ4kg3W4HL8qT25rCVittT5bFQox__OnSknV5w_wW69FvUhXkxqxKhi9MCiy5oH-JTucXN_= 7FK85q7jD-qEwRM5IXY68_Vfeb_XI2rKxyzwVsG_06KTGF09Bw9oHAOXUNFcdCw_oon_eruUhRP= tdwLc9UQNz2ThYP8ysf2pr64VU04VjMKmGwqYvzzyAsLTEbHrs7GVCqphT58T0st78_968rM5MK= FLk7EiWBj7gZPm_rDeBf63gUtxkcj-w8XybJiiO2tcFaeoAL_8m-ZT5L9-1VK4wZkHmR5C_Ldg/= https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fnvo3 > > --000000000000db2fac0586c35e28 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carlos,
thank you for the discussion.
As = the VXLAN-GPE is on the Informational track, there may be little point to d= iscuss it. But as the draft has been adopted by NVO3 WG, I'm curious ab= out the updates the editors have been making without the WG agreeing to tha= t. I'm looking forward to hearing from any of the editors of VXLAN-GPE = about the updates in the last two versions. Also, hope editors of the draft= will find time to reply to my questions and consider my comments.

Regards,
Greg

On Wed, Apr 17, 2019 at 5:18 = PM Carlos Pignataro (cpignata) <cp= ignata@cisco.com> wrote:
Dear Greg,

[Now adding the SFC WG Mailing list since you take us to a different WG aga= in]

Thank you very much for fine-combing with a magnifying glass through all th= e documents I=E2=80=99m currently co-authoring :-)

It is refreshing to see that the only issues you find are non-issues, and y= our questions easy to re-answer :-)

At this point I am a bit at a loss of what your point is, or what you are t= rying to prove bending text. Are you coding, deploying, or testing IOAM on = NSH without data packets on VXLAN-GPE over IP? NSH is data as far as VXLAN-= GPE is concerned. IOAM shimmed in NSH is orthogonal to IOAM shimmed in VXLA= N-GPE.

I feel this discussion about the O-bit already took place once or twice.
Kind Regards,

=E2=80=94 Carlos Pignataro

PS: The Evil bit is defined for IPv4, should we therefore also define it he= re?


> On Apr 17, 2019, at 5:54 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
>
> Hi Carlos,
> to add another quote from the draft-ietf-sfc-ioam-nsh that you've = co-authored,
>=C2=A0 =C2=A0 Packets with IOAM data included MUST follow this
>=C2=A0 =C2=A0 definition, i.e. the O bit MUST NOT be set for regular cu= stomer
>=C2=A0 =C2=A0 traffic which also carries IOAM data and the O bit MUST b= e set for
>=C2=A0 =C2=A0 OAM packets which carry only IOAM data without any regula= r data
>=C2=A0 =C2=A0 payload.
>
> So, if the only iOAM message is carried in or after an NSH, it is iden= tified as OAM. And, by your own example in the earlier note, so should VXLA= N-GPE.
>
> Regards,
> Greg
>
> On Wed, Apr 17, 2019 at 12:44 PM Carlos Pignataro (cpignata) <cpignata@cisco.com&g= t; wrote:
> Hi, Greg,
>
> Adding the IPPM mailing list, since you reference it below, and point = to RFC 7799.
>
> Please see inline.
>
> > On Apr 17, 2019, at 3:00 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:=
> >
> > Hi Carlos,
> > thank you for sharing your view on the design of the VXLAN-GPE pr= otocol. Please find my comments in-line tagged GIM>>.
> >
> > Regards,
> > Greg
> >
> > On Fri, Apr 12, 2019 at 5:23 AM Carlos Pignataro (cpignata) <<= a href=3D"mailto:cpignata@cisco.com" target=3D"_blank">cpignata@cisco.com> wrote:
> > Greg,
> >
> > You seem to be confusing and mixing things up.
> >
> > Please see inline.
> >
> > > On Apr 12, 2019, at 2:50 AM, Greg Mirsky <gregimirsky@gmail.com> w= rote:
> > >
> > > Dear Editors, et al.,
> > > I've read the latest -07 version and would like to share= my comments and questions with you:
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 in the earlier version o= f the draft, the O-bit was introduced and defined as:
> > > OAM Flag Bit (O bit):=C2=A0 The O bit is set to indicate tha= t the packet is an OAM packet.
> > > At the same time, in the latest version, the new Next Protoc= ol value (0x81) to identify iOAM Data was introduced. Hence are my question= s:
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 What must be the value o= f the O-bit when the value of the Next Protocol field is iOAM?
> >
> > The O bit =E2=80=9Cis set to indicate that the packet is an OAM p= acket=E2=80=9D.
> > IAOM is not an OAM packet. Hence, O bit clear if VXLAN-GPE encaps= ulates a non-OAM packet and adds an IOAM shim.
> > GIM>> It is a very unexpected statement from you,
>
> I would tell you =E2=80=98expect the unexpected=E2=80=99, but that is = not the case here... :-)
>
> If you actually read my statement, you will see "IAOM is not an O= AM *packet*.=E2=80=9D New emphasis added =E2=80=94 it is _not_ *an OAM pack= et*.
>
> I stand by it. It=E2=80=99s an augmented data packet of interest.
>
> > one of the co-authors of draft-ietf-ippm-ioam-data=C2=A0 where th= e first paragraph of the Introduction section defines iOAM as Hybrid Type 1= OAM, according to RFC 7799 classification:
>
> This is still quite consistent with that definition, which I recommend= you re-read:
>
> RFC 7799 is about metrics and methods, not packet definitions.
>
> You will see that Active methods include a =E2=80=9Cdedicated measurem= ent packet stream=E2=80=9D. =E2=80=9CActive Methods generate packet streams= .=E2=80=9D
>
> However, Hybrid Type I leverages =E2=80=9CAugmentation or modification= of the stream of interest"
>
> Following your logic, if you change a packet field such as TTL/HL to p= rovide packet coloring, do you need to set the O-bit?
>
> >=C2=A0 =C2=A0 IOAM is to complement
> >=C2=A0 =C2=A0 mechanisms such as Ping or Traceroute, or more recen= t active probing
> >=C2=A0 =C2=A0 mechanisms as described in [I-D.lapukhov-dataplane-p= robe]..=C2=A0 In terms
> >=C2=A0 =C2=A0 of "active" or "passive" OAM, &q= uot;in-situ" OAM can be considered a
> >=C2=A0 =C2=A0 hybrid OAM type.=C2=A0 While no extra packets are se= nt, IOAM adds
> >=C2=A0 =C2=A0 information to the packets therefore cannot be consi= dered passive.
> >=C2=A0 =C2=A0 In terms of the classification given in [RFC7799] IO= AM could be
> >=C2=A0 =C2=A0 portrayed as Hybrid Type 1.
> >
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Do you plan to define th= e Next Protocol values for active OAM protocols, e.g., Echo Request/Reply, = BFD, Performance Monitoring?
> >
> > I cannot speak to =E2=80=9Cplans=E2=80=9D (replying as =E2=80=9Ce= t al.=E2=80=9D, not as =E2=80=9Ceditor=E2=80=9D), but I expect OAM document= s ought to have those requested, and you do not need necessarily all of tho= se =E2=80=94 the nex protocol IPv4 / IPv6 can encapsulate ICMP, UDP/BFD, et= c., etc., etc., etc.
> > GIM>> Of course, use of the well-known port number, usually= it is UDP destination port, is one of the methods to demultiplex protocols= . This method is broadly used, for example, in MPLS OAM. But this method ha= s some disadvantages that were pointed out in the discussion of BFD over GE= NEVE in Prague by David Black (the last presentation in the minutes):
> > David: I want the BFD header to be as close to the thing whose li= veness I'm testing. The more headers you add in the middle, the more wa= ys there are to break BFD without breaking the forwarding engine. The furth= er away I move BFD from the chunk of hardware's liveness I care about, = the more opportunities are for BFD and the hardware to not to tell me the s= ame thing.
> >
>
> Theory and practice match in theory, less so in practice =E2=80=94 unl= ess you are planning to update RFC 5881.
>
> This can be argued both ways (e.g., better to have common handlers, et= c.), but I take no position. I do say that in presence of deployed OAM enca= psulations, there=E2=80=99s no basis for your your comment about defining a= protocol type for =E2=80=9CPerformance Monitoring=E2=80=9D as a protocol..= .
>
>
> >
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 How to interpret the sit= uation when the O-bit value is 1 but the value of the Next Protocol field i= s, for example, NSH, i.e.., not any of OAM protocols?
> >
> > I expect it means there=E2=80=99s OAM within that NSH (sometimes = there=E2=80=99s no such things as =E2=80=9COAM Protocols=E2=80=9D), or an u= nhandled OAM protocol.
> > GIM>> Should that, i.e., OAM in NSH or immediately followin= g NSH be signaled using SFC NSH methods that are already defined in draft-i= etf-sfc-multi-layer-oam?
>
>
> Non sequitur =E2=80=94 I do not follow what signaling has to do with t= he conversation, nor how that draft might be relevant.
>
> > Using the server layer, as you've suggested, seems as layer v= iolation.
> >
>
> This is a funny statement =E2=80=94 NVO3 is a layer violation :-) So a= re Pseudowires. Please do not take this statement too seriously, it is not = inviting discussion.
>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 I believe that the use o= f the dedicated OAM flag and the Next Protocol field for a fixed-size heade= r that cannot include meta-data is unwarranted and adds unnecessary complex= ity.
> >
> > Disagree.
> >
> > See example where protocol is IP carrying an OAM packet.
> > GIM>> When IP/UDP encapsulation is used for OAM, there'= s no, in my opinion, any need to use the O-bit. The destination IP address = must be as described in RFC 8029 or RFC 5884 and the demultiplexing is done= based on the destination UDP port number. Clearly, O-bit is unnecessary if= IP/UDP encapsulation for OAM being used.
> >
>
> Fortunately, bit usage is a matter of definition and not opinion :-) >
> Kind regards,
>
> Carlos.
>
>
> > > I suggest not to use O-bit in the VXLAN-GPE header and relea= se it into the Reserved field.=C2=A0 I don't see the apparent benefit o= f using the flag, as the VXLA-GPE uses the fixed size header and the header= cannot carry OAM data in it. The only role the VXLAN-GPE header must perfo= rm, in my opinion, is to unambiguously identify the payload type that immed= iately follows the header as OAM (demultiplexing OAM protocols may be done = in OAM Header shim).
> > > Much appreciate your consideration.
> > >
> >
> > Best,
> >
> > =E2=80=94
> > Carlos Pignataro, carlos@cisco.com
> >
> > =E2=80=9CSometimes I use big words that I do not fully understand= , to make myself sound more photosynthesis."
> >
> > > Regards,
> > > Greg
> > > _______________________________________________
> > > nvo3 mailing list
> > > nvo3@ietf= .org
> > > https://secure-web.cisco.com/1j-j= r64yh2D8yO92ibcqaN-H98ZCP3lQdHmsYPsH8lkjsa4WlJ4kg3W4HL8qT25rCVittT5bFQox__O= nSknV5w_wW69FvUhXkxqxKhi9MCiy5oH-JTucXN_7FK85q7jD-qEwRM5IXY68_Vfeb_XI2rKxyz= wVsG_06KTGF09Bw9oHAOXUNFcdCw_oon_eruUhRPtdwLc9UQNz2ThYP8ysf2pr64VU04VjMKmGw= qYvzzyAsLTEbHrs7GVCqphT58T0st78_968rM5MKFLk7EiWBj7gZPm_rDeBf63gUtxkcj-w8Xyb= JiiO2tcFaeoAL_8m-ZT5L9-1VK4wZkHmR5C_Ldg/https%3A%2F%2Fwww.ietf.org%2Fmailma= n%2Flistinfo%2Fnvo3
> >
>
> _______________________________________________
> nvo3 mailing list
> nvo3@ietf.org > https://secure-web.cisco.com/1j-jr64yh2D8= yO92ibcqaN-H98ZCP3lQdHmsYPsH8lkjsa4WlJ4kg3W4HL8qT25rCVittT5bFQox__OnSknV5w_= wW69FvUhXkxqxKhi9MCiy5oH-JTucXN_7FK85q7jD-qEwRM5IXY68_Vfeb_XI2rKxyzwVsG_06K= TGF09Bw9oHAOXUNFcdCw_oon_eruUhRPtdwLc9UQNz2ThYP8ysf2pr64VU04VjMKmGwqYvzzyAs= LTEbHrs7GVCqphT58T0st78_968rM5MKFLk7EiWBj7gZPm_rDeBf63gUtxkcj-w8XybJiiO2tcF= aeoAL_8m-ZT5L9-1VK4wZkHmR5C_Ldg/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flist= info%2Fnvo3

--000000000000db2fac0586c35e28-- From nobody Wed Apr 17 18:08:07 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3FD120096; Wed, 17 Apr 2019 18:08:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 c3GeructIx2W; Wed, 17 Apr 2019 18:07:59 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF7E4120033; Wed, 17 Apr 2019 18:07:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42928; q=dns/txt; s=iport; t=1555549679; x=1556759279; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TetsWSy/95PjxMFyLIA2V9dP7DhvvcT+BDVEHBIzj3o=; b=OTTQsteR90jR+Qe7OUZnpSYUZFvNZZ90AtoWNgg6Bst72As1WBV7LoKY bXUI5meXCdQn+Pyo2IPRz/ZLaODeL03Qp1esABpl223a/F60w3+5zlXaU tjYP1MRSsouGscZ5oErDIiuo1P6jVNF0HHa1M1S+PagF47/t0Nk0o7DP2 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAAqzbdc/5ldJa1cChkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVMCAQEBAQELAYEOUwUqaIEEKAqEBJU2iTqPEBSBZw4?= =?us-ascii?q?BARgBCYRLAheFfiM2Bw4BAwEBBAECAQJtHAyFSgEBAQMBAQEYCQRABwsFCwI?= =?us-ascii?q?BCBEDAQIBIAcDAgICHwYLFAkIAgQOBYMiAYEdTAMNDw+pVnwzhDYCg0gNghs?= =?us-ascii?q?GgTIBi0kXgUA/gREnH4FOfj6CGkcBAQIYgQ8NFQQyFoJUMYImBI0phDqHZ4w?= =?us-ascii?q?QLDcJAoIGhguEUoN3g0obggmGHYNniHCND4URgUeMMQIRFYEwJgkogVZwFTs?= =?us-ascii?q?qAYJBgzIBAoJIhRSFP0ExAQEKj0WBIQEB?= X-IronPort-AV: E=Sophos;i="5.60,364,1549929600"; d="scan'208,217";a="263524500" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Apr 2019 01:07:57 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x3I17vDS013117 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 18 Apr 2019 01:07:57 GMT Received: from xch-rtp-020.cisco.com (64.101.220.160) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 17 Apr 2019 21:07:56 -0400 Received: from xch-rtp-020.cisco.com ([64.101.220.160]) by XCH-RTP-020.cisco.com ([64.101.220.160]) with mapi id 15.00.1473.003; Wed, 17 Apr 2019 21:07:56 -0400 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: NVO3 , "draft-ietf-nvo3-vxlan-gpe@ietf.org" , IETF IPPM WG , "sfc@ietf.org" Thread-Topic: [SUSPICIOUS] Re: [nvo3] Comments on draft-ietf-nvo3-vxlan-gpe Thread-Index: AQHU8Pwb4PQUm0Sk6kyANyiY2S4odqY4th6AgAhKgYCAAAxngIAAJG4AgAAoIICAAAiMAP//wjaA Date: Thu, 18 Apr 2019 01:07:56 +0000 Message-ID: <5C94C616-82BD-49CE-BB20-A31F843E8806@cisco.com> References: <12ACA02A-BB51-4214-A72B-1AEFCCB914AC@cisco.com> <3AFD4751-CF3A-4939-A49A-FB981C68CADF@cisco.com> <4C9CDD29-BDF8-425E-998F-B12C1BD7CA7C@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.18.0.190414 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.118.116.132] Content-Type: multipart/alternative; boundary="_000_5C94C61682BD49CEBB20A31F843E8806ciscocom_" MIME-Version: 1.0 X-Outbound-SMTP-Client: 64.101.220.158, xch-rtp-018.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [ippm] [SUSPICIOUS] Re: [nvo3] Comments on draft-ietf-nvo3-vxlan-gpe X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 01:08:05 -0000 --_000_5C94C61682BD49CEBB20A31F843E8806ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBHcmVnLA0KDQpBcyBhbiBpbm5vY2VudCBieXN0YW5kZXIsIEkgaGF2ZSBubyBkb2cgaW4g dGhpcyBmaWdodCAoaS5lLiwgbm8gcGVyc29uYWwgc3Rha2UgaW4gdGhlIGlzc3VlIHlvdSBrZWVw IHJhaXNpbmcpLCBidXQgeW91IHNlZW0gdG8gYmUgbWFraW5nIGEgcmF0aGVyIHN0cm9uZyBhY2N1 c2F0aW9uOiDigJx0aGUgdXBkYXRlcyB0aGUgZWRpdG9ycyBoYXZlIGJlZW4gbWFraW5nIHdpdGhv dXQgdGhlIFdHIGFncmVlaW5nIHRvIHRoYXTigJ0uIFlvdSB0YWxrIGFib3V0IHBsdXJhbCDigJx1 cGRhdGVz4oCdLCBhbmQgeW91IHVzZSBhIGNvbnRpbnVlZCB0ZW5zZSBvZiDigJxoYXZlIGJlZW4g bWFraW5n4oCdIChpbXBseWluZyBtb3JlIHRoYW4gb25jZSwgb3IgcmVwZWF0ZWRseSkuDQoNCkxv b2tpbmcgYXQgdGhlIGRpZmZzIGZyb20gZHJhZnQtaWV0Zi1udm8zLXZ4bGFuLWdwZS0wMCB0byBk cmFmdC1pZXRmLW52bzMtdnhsYW4tZ3BlLTA3Og0KaHR0cHM6Ly93d3c2LmlldGYub3JnL3JmY2Rp ZmYvP3VybDE9ZHJhZnQtaWV0Zi1udm8zLXZ4bGFuLWdwZS0wMCZ1cmwyPWRyYWZ0LWlldGYtbnZv My12eGxhbi1ncGUtMDcNCg0KSSBzZWUgbm8gY2hhbmdlcyBpbiB0aGUgZGVmaW5pdGlvbiBvZiB0 aGUgTy1iaXQuDQoNCkkgd2lsbCBzdG9wIHJlcGx5aW5nIHRvIHRoaXMgdGhyZWFkIHdpdGggdGhp cyBmaW5hbCBub3RlLCBhbmQgbGV0IHRoZSBFZGl0b3JzIG9mIHRoYXQgZG9jdW1lbnQgYW5zd2Vy IHlvdXIgZXhwbGljaXQgY2FsbCDigJMgaG93ZXZlciwgZm9yIHRoZSBiZW5lZml0IG9mIGNsYXJp dHkgZm9yIHRoZSBXRywgd2hhdCBzcGVjaWZpYyB1cGRhdGVzIHlvdSByZWZlciB0bz8NCg0KWW91 IG1lbnRpb24g4oCcdGhlIGxhc3QgdHdvIHZlcnNpb25z4oCdIG9mIFZYTEFOLUdSRS4NCjA1IC0+ IDA2OiBodHRwczovL3d3dzYuaWV0Zi5vcmcvcmZjZGlmZi8/dXJsMT1kcmFmdC1pZXRmLW52bzMt dnhsYW4tZ3BlLTA1JnVybDI9ZHJhZnQtaWV0Zi1udm8zLXZ4bGFuLWdwZS0wNg0KSSBzZWUgbm8g Y29udGVudCBjaGFuZ2VzIOKAkyBvbmx5IHVwZGF0aW5nIHJlZmVyZW5jZXMgYW5kIHNwYWNlcw0K DQowNiAtPiAwNzogaHR0cHM6Ly93d3c2LmlldGYub3JnL3JmY2RpZmYvP3VybDE9ZHJhZnQtaWV0 Zi1udm8zLXZ4bGFuLWdwZS0wNiZ1cmwyPWRyYWZ0LWlldGYtbnZvMy12eGxhbi1ncGUtMDcNCkRl ZmluaXRpb24gb2YgTmV4dCBQcm90b2NvbCByYW5nZSBmb3Igc2hpbSBoZWFkZXJzLCBhbmQgYXNz aWdubWVudCBvZiBhIE5leHQgUHJvdG9jb2wgdmFsdWUgZm9yIHRoZSBJT0FNIHNoaW0uDQoNCldo aWNoIG9uZSBpcyBpdD8NCg0KQ2FybG9zLg0KDQoNCkZyb206IEdyZWcgTWlyc2t5IDxncmVnaW1p cnNreUBnbWFpbC5jb20+DQpEYXRlOiBXZWRuZXNkYXksIEFwcmlsIDE3LCAyMDE5IGF0IDg6NDkg UE0NClRvOiAiQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIiA8Y3BpZ25hdGFAY2lzY28uY29t Pg0KQ2M6IE5WTzMgPG52bzNAaWV0Zi5vcmc+LCAiZHJhZnQtaWV0Zi1udm8zLXZ4bGFuLWdwZUBp ZXRmLm9yZyIgPGRyYWZ0LWlldGYtbnZvMy12eGxhbi1ncGVAaWV0Zi5vcmc+LCBJRVRGIElQUE0g V0cgPGlwcG1AaWV0Zi5vcmc+LCAic2ZjQGlldGYub3JnIiA8c2ZjQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtTVVNQSUNJT1VTXSBSZTogW252bzNdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtbnZv My12eGxhbi1ncGUNCg0KSGkgQ2FybG9zLA0KdGhhbmsgeW91IGZvciB0aGUgZGlzY3Vzc2lvbi4N CkFzIHRoZSBWWExBTi1HUEUgaXMgb24gdGhlIEluZm9ybWF0aW9uYWwgdHJhY2ssIHRoZXJlIG1h eSBiZSBsaXR0bGUgcG9pbnQgdG8gZGlzY3VzcyBpdC4gQnV0IGFzIHRoZSBkcmFmdCBoYXMgYmVl biBhZG9wdGVkIGJ5IE5WTzMgV0csIEknbSBjdXJpb3VzIGFib3V0IHRoZSB1cGRhdGVzIHRoZSBl ZGl0b3JzIGhhdmUgYmVlbiBtYWtpbmcgd2l0aG91dCB0aGUgV0cgYWdyZWVpbmcgdG8gdGhhdC4g SSdtIGxvb2tpbmcgZm9yd2FyZCB0byBoZWFyaW5nIGZyb20gYW55IG9mIHRoZSBlZGl0b3JzIG9m IFZYTEFOLUdQRSBhYm91dCB0aGUgdXBkYXRlcyBpbiB0aGUgbGFzdCB0d28gdmVyc2lvbnMuIEFs c28sIGhvcGUgZWRpdG9ycyBvZiB0aGUgZHJhZnQgd2lsbCBmaW5kIHRpbWUgdG8gcmVwbHkgdG8g bXkgcXVlc3Rpb25zIGFuZCBjb25zaWRlciBteSBjb21tZW50cy4NCg0KUmVnYXJkcywNCkdyZWcN Cg0KT24gV2VkLCBBcHIgMTcsIDIwMTkgYXQgNToxOCBQTSBDYXJsb3MgUGlnbmF0YXJvIChjcGln bmF0YSkgPGNwaWduYXRhQGNpc2NvLmNvbTxtYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tPj4gd3Jv dGU6DQpEZWFyIEdyZWcsDQoNCltOb3cgYWRkaW5nIHRoZSBTRkMgV0cgTWFpbGluZyBsaXN0IHNp bmNlIHlvdSB0YWtlIHVzIHRvIGEgZGlmZmVyZW50IFdHIGFnYWluXQ0KDQpUaGFuayB5b3UgdmVy eSBtdWNoIGZvciBmaW5lLWNvbWJpbmcgd2l0aCBhIG1hZ25pZnlpbmcgZ2xhc3MgdGhyb3VnaCBh bGwgdGhlIGRvY3VtZW50cyBJ4oCZbSBjdXJyZW50bHkgY28tYXV0aG9yaW5nIDotKQ0KDQpJdCBp cyByZWZyZXNoaW5nIHRvIHNlZSB0aGF0IHRoZSBvbmx5IGlzc3VlcyB5b3UgZmluZCBhcmUgbm9u LWlzc3VlcywgYW5kIHlvdXIgcXVlc3Rpb25zIGVhc3kgdG8gcmUtYW5zd2VyIDotKQ0KDQpBdCB0 aGlzIHBvaW50IEkgYW0gYSBiaXQgYXQgYSBsb3NzIG9mIHdoYXQgeW91ciBwb2ludCBpcywgb3Ig d2hhdCB5b3UgYXJlIHRyeWluZyB0byBwcm92ZSBiZW5kaW5nIHRleHQuIEFyZSB5b3UgY29kaW5n LCBkZXBsb3lpbmcsIG9yIHRlc3RpbmcgSU9BTSBvbiBOU0ggd2l0aG91dCBkYXRhIHBhY2tldHMg b24gVlhMQU4tR1BFIG92ZXIgSVA/IE5TSCBpcyBkYXRhIGFzIGZhciBhcyBWWExBTi1HUEUgaXMg Y29uY2VybmVkLiBJT0FNIHNoaW1tZWQgaW4gTlNIIGlzIG9ydGhvZ29uYWwgdG8gSU9BTSBzaGlt bWVkIGluIFZYTEFOLUdQRS4NCg0KSSBmZWVsIHRoaXMgZGlzY3Vzc2lvbiBhYm91dCB0aGUgTy1i aXQgYWxyZWFkeSB0b29rIHBsYWNlIG9uY2Ugb3IgdHdpY2UuDQoNCktpbmQgUmVnYXJkcywNCg0K 4oCUIENhcmxvcyBQaWduYXRhcm8NCg0KUFM6IFRoZSBFdmlsIGJpdCBpcyBkZWZpbmVkIGZvciBJ UHY0LCBzaG91bGQgd2UgdGhlcmVmb3JlIGFsc28gZGVmaW5lIGl0IGhlcmU/DQoNCg0KPiBPbiBB cHIgMTcsIDIwMTksIGF0IDU6NTQgUE0sIEdyZWcgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFpbC5j b208bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbT4+IHdyb3RlOg0KPg0KPiBIaSBDYXJsb3Ms DQo+IHRvIGFkZCBhbm90aGVyIHF1b3RlIGZyb20gdGhlIGRyYWZ0LWlldGYtc2ZjLWlvYW0tbnNo IHRoYXQgeW91J3ZlIGNvLWF1dGhvcmVkLA0KPiAgICBQYWNrZXRzIHdpdGggSU9BTSBkYXRhIGlu Y2x1ZGVkIE1VU1QgZm9sbG93IHRoaXMNCj4gICAgZGVmaW5pdGlvbiwgaS5lLiB0aGUgTyBiaXQg TVVTVCBOT1QgYmUgc2V0IGZvciByZWd1bGFyIGN1c3RvbWVyDQo+ICAgIHRyYWZmaWMgd2hpY2gg YWxzbyBjYXJyaWVzIElPQU0gZGF0YSBhbmQgdGhlIE8gYml0IE1VU1QgYmUgc2V0IGZvcg0KPiAg ICBPQU0gcGFja2V0cyB3aGljaCBjYXJyeSBvbmx5IElPQU0gZGF0YSB3aXRob3V0IGFueSByZWd1 bGFyIGRhdGENCj4gICAgcGF5bG9hZC4NCj4NCj4gU28sIGlmIHRoZSBvbmx5IGlPQU0gbWVzc2Fn ZSBpcyBjYXJyaWVkIGluIG9yIGFmdGVyIGFuIE5TSCwgaXQgaXMgaWRlbnRpZmllZCBhcyBPQU0u IEFuZCwgYnkgeW91ciBvd24gZXhhbXBsZSBpbiB0aGUgZWFybGllciBub3RlLCBzbyBzaG91bGQg VlhMQU4tR1BFLg0KPg0KPiBSZWdhcmRzLA0KPiBHcmVnDQo+DQo+IE9uIFdlZCwgQXByIDE3LCAy MDE5IGF0IDEyOjQ0IFBNIENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSA8Y3BpZ25hdGFAY2lz Y28uY29tPG1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20+PiB3cm90ZToNCj4gSGksIEdyZWcsDQo+ DQo+IEFkZGluZyB0aGUgSVBQTSBtYWlsaW5nIGxpc3QsIHNpbmNlIHlvdSByZWZlcmVuY2UgaXQg YmVsb3csIGFuZCBwb2ludCB0byBSRkMgNzc5OS4NCj4NCj4gUGxlYXNlIHNlZSBpbmxpbmUuDQo+ DQo+ID4gT24gQXByIDE3LCAyMDE5LCBhdCAzOjAwIFBNLCBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJz a3lAZ21haWwuY29tPG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+PiB3cm90ZToNCj4gPg0K PiA+IEhpIENhcmxvcywNCj4gPiB0aGFuayB5b3UgZm9yIHNoYXJpbmcgeW91ciB2aWV3IG9uIHRo ZSBkZXNpZ24gb2YgdGhlIFZYTEFOLUdQRSBwcm90b2NvbC4gUGxlYXNlIGZpbmQgbXkgY29tbWVu dHMgaW4tbGluZSB0YWdnZWQgR0lNPj4uDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+IEdyZWcNCj4g Pg0KPiA+IE9uIEZyaSwgQXByIDEyLCAyMDE5IGF0IDU6MjMgQU0gQ2FybG9zIFBpZ25hdGFybyAo Y3BpZ25hdGEpIDxjcGlnbmF0YUBjaXNjby5jb208bWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbT4+ IHdyb3RlOg0KPiA+IEdyZWcsDQo+ID4NCj4gPiBZb3Ugc2VlbSB0byBiZSBjb25mdXNpbmcgYW5k IG1peGluZyB0aGluZ3MgdXAuDQo+ID4NCj4gPiBQbGVhc2Ugc2VlIGlubGluZS4NCj4gPg0KPiA+ ID4gT24gQXByIDEyLCAyMDE5LCBhdCAyOjUwIEFNLCBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lA Z21haWwuY29tPG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+PiB3cm90ZToNCj4gPiA+DQo+ ID4gPiBEZWFyIEVkaXRvcnMsIGV0IGFsLiwNCj4gPiA+IEkndmUgcmVhZCB0aGUgbGF0ZXN0IC0w NyB2ZXJzaW9uIGFuZCB3b3VsZCBsaWtlIHRvIHNoYXJlIG15IGNvbW1lbnRzIGFuZCBxdWVzdGlv bnMgd2l0aCB5b3U6DQo+ID4gPiAgICAgICDigKIgaW4gdGhlIGVhcmxpZXIgdmVyc2lvbiBvZiB0 aGUgZHJhZnQsIHRoZSBPLWJpdCB3YXMgaW50cm9kdWNlZCBhbmQgZGVmaW5lZCBhczoNCj4gPiA+ IE9BTSBGbGFnIEJpdCAoTyBiaXQpOiAgVGhlIE8gYml0IGlzIHNldCB0byBpbmRpY2F0ZSB0aGF0 IHRoZSBwYWNrZXQgaXMgYW4gT0FNIHBhY2tldC4NCj4gPiA+IEF0IHRoZSBzYW1lIHRpbWUsIGlu IHRoZSBsYXRlc3QgdmVyc2lvbiwgdGhlIG5ldyBOZXh0IFByb3RvY29sIHZhbHVlICgweDgxKSB0 byBpZGVudGlmeSBpT0FNIERhdGEgd2FzIGludHJvZHVjZWQuIEhlbmNlIGFyZSBteSBxdWVzdGlv bnM6DQo+ID4gPiAgICAgICDigKIgV2hhdCBtdXN0IGJlIHRoZSB2YWx1ZSBvZiB0aGUgTy1iaXQg d2hlbiB0aGUgdmFsdWUgb2YgdGhlIE5leHQgUHJvdG9jb2wgZmllbGQgaXMgaU9BTT8NCj4gPg0K PiA+IFRoZSBPIGJpdCDigJxpcyBzZXQgdG8gaW5kaWNhdGUgdGhhdCB0aGUgcGFja2V0IGlzIGFu IE9BTSBwYWNrZXTigJ0uDQo+ID4gSUFPTSBpcyBub3QgYW4gT0FNIHBhY2tldC4gSGVuY2UsIE8g Yml0IGNsZWFyIGlmIFZYTEFOLUdQRSBlbmNhcHN1bGF0ZXMgYSBub24tT0FNIHBhY2tldCBhbmQg YWRkcyBhbiBJT0FNIHNoaW0uDQo+ID4gR0lNPj4gSXQgaXMgYSB2ZXJ5IHVuZXhwZWN0ZWQgc3Rh dGVtZW50IGZyb20geW91LA0KPg0KPiBJIHdvdWxkIHRlbGwgeW91IOKAmGV4cGVjdCB0aGUgdW5l eHBlY3RlZOKAmSwgYnV0IHRoYXQgaXMgbm90IHRoZSBjYXNlIGhlcmUuLi4gOi0pDQo+DQo+IElm IHlvdSBhY3R1YWxseSByZWFkIG15IHN0YXRlbWVudCwgeW91IHdpbGwgc2VlICJJQU9NIGlzIG5v dCBhbiBPQU0gKnBhY2tldCou4oCdIE5ldyBlbXBoYXNpcyBhZGRlZCDigJQgaXQgaXMgX25vdF8g KmFuIE9BTSBwYWNrZXQqLg0KPg0KPiBJIHN0YW5kIGJ5IGl0LiBJdOKAmXMgYW4gYXVnbWVudGVk IGRhdGEgcGFja2V0IG9mIGludGVyZXN0Lg0KPg0KPiA+IG9uZSBvZiB0aGUgY28tYXV0aG9ycyBv ZiBkcmFmdC1pZXRmLWlwcG0taW9hbS1kYXRhICB3aGVyZSB0aGUgZmlyc3QgcGFyYWdyYXBoIG9m IHRoZSBJbnRyb2R1Y3Rpb24gc2VjdGlvbiBkZWZpbmVzIGlPQU0gYXMgSHlicmlkIFR5cGUgMSBP QU0sIGFjY29yZGluZyB0byBSRkMgNzc5OSBjbGFzc2lmaWNhdGlvbjoNCj4NCj4gVGhpcyBpcyBz dGlsbCBxdWl0ZSBjb25zaXN0ZW50IHdpdGggdGhhdCBkZWZpbml0aW9uLCB3aGljaCBJIHJlY29t bWVuZCB5b3UgcmUtcmVhZDoNCj4NCj4gUkZDIDc3OTkgaXMgYWJvdXQgbWV0cmljcyBhbmQgbWV0 aG9kcywgbm90IHBhY2tldCBkZWZpbml0aW9ucy4NCj4NCj4gWW91IHdpbGwgc2VlIHRoYXQgQWN0 aXZlIG1ldGhvZHMgaW5jbHVkZSBhIOKAnGRlZGljYXRlZCBtZWFzdXJlbWVudCBwYWNrZXQgc3Ry ZWFt4oCdLiDigJxBY3RpdmUgTWV0aG9kcyBnZW5lcmF0ZSBwYWNrZXQgc3RyZWFtcy7igJ0NCj4N Cj4gSG93ZXZlciwgSHlicmlkIFR5cGUgSSBsZXZlcmFnZXMg4oCcQXVnbWVudGF0aW9uIG9yIG1v ZGlmaWNhdGlvbiBvZiB0aGUgc3RyZWFtIG9mIGludGVyZXN0Ig0KPg0KPiBGb2xsb3dpbmcgeW91 ciBsb2dpYywgaWYgeW91IGNoYW5nZSBhIHBhY2tldCBmaWVsZCBzdWNoIGFzIFRUTC9ITCB0byBw cm92aWRlIHBhY2tldCBjb2xvcmluZywgZG8geW91IG5lZWQgdG8gc2V0IHRoZSBPLWJpdD8NCj4N Cj4gPiAgICBJT0FNIGlzIHRvIGNvbXBsZW1lbnQNCj4gPiAgICBtZWNoYW5pc21zIHN1Y2ggYXMg UGluZyBvciBUcmFjZXJvdXRlLCBvciBtb3JlIHJlY2VudCBhY3RpdmUgcHJvYmluZw0KPiA+ICAg IG1lY2hhbmlzbXMgYXMgZGVzY3JpYmVkIGluIFtJLUQubGFwdWtob3YtZGF0YXBsYW5lLXByb2Jl XS4uICBJbiB0ZXJtcw0KPiA+ICAgIG9mICJhY3RpdmUiIG9yICJwYXNzaXZlIiBPQU0sICJpbi1z aXR1IiBPQU0gY2FuIGJlIGNvbnNpZGVyZWQgYQ0KPiA+ICAgIGh5YnJpZCBPQU0gdHlwZS4gIFdo aWxlIG5vIGV4dHJhIHBhY2tldHMgYXJlIHNlbnQsIElPQU0gYWRkcw0KPiA+ICAgIGluZm9ybWF0 aW9uIHRvIHRoZSBwYWNrZXRzIHRoZXJlZm9yZSBjYW5ub3QgYmUgY29uc2lkZXJlZCBwYXNzaXZl Lg0KPiA+ICAgIEluIHRlcm1zIG9mIHRoZSBjbGFzc2lmaWNhdGlvbiBnaXZlbiBpbiBbUkZDNzc5 OV0gSU9BTSBjb3VsZCBiZQ0KPiA+ICAgIHBvcnRyYXllZCBhcyBIeWJyaWQgVHlwZSAxLg0KPiA+ DQo+ID4gPiAgICAgICDigKIgRG8geW91IHBsYW4gdG8gZGVmaW5lIHRoZSBOZXh0IFByb3RvY29s IHZhbHVlcyBmb3IgYWN0aXZlIE9BTSBwcm90b2NvbHMsIGUuZy4sIEVjaG8gUmVxdWVzdC9SZXBs eSwgQkZELCBQZXJmb3JtYW5jZSBNb25pdG9yaW5nPw0KPiA+DQo+ID4gSSBjYW5ub3Qgc3BlYWsg dG8g4oCccGxhbnPigJ0gKHJlcGx5aW5nIGFzIOKAnGV0IGFsLuKAnSwgbm90IGFzIOKAnGVkaXRv cuKAnSksIGJ1dCBJIGV4cGVjdCBPQU0gZG9jdW1lbnRzIG91Z2h0IHRvIGhhdmUgdGhvc2UgcmVx dWVzdGVkLCBhbmQgeW91IGRvIG5vdCBuZWVkIG5lY2Vzc2FyaWx5IGFsbCBvZiB0aG9zZSDigJQg dGhlIG5leCBwcm90b2NvbCBJUHY0IC8gSVB2NiBjYW4gZW5jYXBzdWxhdGUgSUNNUCwgVURQL0JG RCwgZXRjLiwgZXRjLiwgZXRjLiwgZXRjLg0KPiA+IEdJTT4+IE9mIGNvdXJzZSwgdXNlIG9mIHRo ZSB3ZWxsLWtub3duIHBvcnQgbnVtYmVyLCB1c3VhbGx5IGl0IGlzIFVEUCBkZXN0aW5hdGlvbiBw b3J0LCBpcyBvbmUgb2YgdGhlIG1ldGhvZHMgdG8gZGVtdWx0aXBsZXggcHJvdG9jb2xzLiBUaGlz IG1ldGhvZCBpcyBicm9hZGx5IHVzZWQsIGZvciBleGFtcGxlLCBpbiBNUExTIE9BTS4gQnV0IHRo aXMgbWV0aG9kIGhhcyBzb21lIGRpc2FkdmFudGFnZXMgdGhhdCB3ZXJlIHBvaW50ZWQgb3V0IGlu IHRoZSBkaXNjdXNzaW9uIG9mIEJGRCBvdmVyIEdFTkVWRSBpbiBQcmFndWUgYnkgRGF2aWQgQmxh Y2sgKHRoZSBsYXN0IHByZXNlbnRhdGlvbiBpbiB0aGUgbWludXRlcyk6DQo+ID4gRGF2aWQ6IEkg d2FudCB0aGUgQkZEIGhlYWRlciB0byBiZSBhcyBjbG9zZSB0byB0aGUgdGhpbmcgd2hvc2UgbGl2 ZW5lc3MgSSdtIHRlc3RpbmcuIFRoZSBtb3JlIGhlYWRlcnMgeW91IGFkZCBpbiB0aGUgbWlkZGxl LCB0aGUgbW9yZSB3YXlzIHRoZXJlIGFyZSB0byBicmVhayBCRkQgd2l0aG91dCBicmVha2luZyB0 aGUgZm9yd2FyZGluZyBlbmdpbmUuIFRoZSBmdXJ0aGVyIGF3YXkgSSBtb3ZlIEJGRCBmcm9tIHRo ZSBjaHVuayBvZiBoYXJkd2FyZSdzIGxpdmVuZXNzIEkgY2FyZSBhYm91dCwgdGhlIG1vcmUgb3Bw b3J0dW5pdGllcyBhcmUgZm9yIEJGRCBhbmQgdGhlIGhhcmR3YXJlIHRvIG5vdCB0byB0ZWxsIG1l IHRoZSBzYW1lIHRoaW5nLg0KPiA+DQo+DQo+IFRoZW9yeSBhbmQgcHJhY3RpY2UgbWF0Y2ggaW4g dGhlb3J5LCBsZXNzIHNvIGluIHByYWN0aWNlIOKAlCB1bmxlc3MgeW91IGFyZSBwbGFubmluZyB0 byB1cGRhdGUgUkZDIDU4ODEuDQo+DQo+IFRoaXMgY2FuIGJlIGFyZ3VlZCBib3RoIHdheXMgKGUu Zy4sIGJldHRlciB0byBoYXZlIGNvbW1vbiBoYW5kbGVycywgZXRjLiksIGJ1dCBJIHRha2Ugbm8g cG9zaXRpb24uIEkgZG8gc2F5IHRoYXQgaW4gcHJlc2VuY2Ugb2YgZGVwbG95ZWQgT0FNIGVuY2Fw c3VsYXRpb25zLCB0aGVyZeKAmXMgbm8gYmFzaXMgZm9yIHlvdXIgeW91ciBjb21tZW50IGFib3V0 IGRlZmluaW5nIGEgcHJvdG9jb2wgdHlwZSBmb3Ig4oCcUGVyZm9ybWFuY2UgTW9uaXRvcmluZ+KA nSBhcyBhIHByb3RvY29sLi4uDQo+DQo+DQo+ID4NCj4gPiA+ICAgICAgIOKAoiBIb3cgdG8gaW50 ZXJwcmV0IHRoZSBzaXR1YXRpb24gd2hlbiB0aGUgTy1iaXQgdmFsdWUgaXMgMSBidXQgdGhlIHZh bHVlIG9mIHRoZSBOZXh0IFByb3RvY29sIGZpZWxkIGlzLCBmb3IgZXhhbXBsZSwgTlNILCBpLmUu Liwgbm90IGFueSBvZiBPQU0gcHJvdG9jb2xzPw0KPiA+DQo+ID4gSSBleHBlY3QgaXQgbWVhbnMg dGhlcmXigJlzIE9BTSB3aXRoaW4gdGhhdCBOU0ggKHNvbWV0aW1lcyB0aGVyZeKAmXMgbm8gc3Vj aCB0aGluZ3MgYXMg4oCcT0FNIFByb3RvY29sc+KAnSksIG9yIGFuIHVuaGFuZGxlZCBPQU0gcHJv dG9jb2wuDQo+ID4gR0lNPj4gU2hvdWxkIHRoYXQsIGkuZS4sIE9BTSBpbiBOU0ggb3IgaW1tZWRp YXRlbHkgZm9sbG93aW5nIE5TSCBiZSBzaWduYWxlZCB1c2luZyBTRkMgTlNIIG1ldGhvZHMgdGhh dCBhcmUgYWxyZWFkeSBkZWZpbmVkIGluIGRyYWZ0LWlldGYtc2ZjLW11bHRpLWxheWVyLW9hbT8N Cj4NCj4NCj4gTm9uIHNlcXVpdHVyIOKAlCBJIGRvIG5vdCBmb2xsb3cgd2hhdCBzaWduYWxpbmcg aGFzIHRvIGRvIHdpdGggdGhlIGNvbnZlcnNhdGlvbiwgbm9yIGhvdyB0aGF0IGRyYWZ0IG1pZ2h0 IGJlIHJlbGV2YW50Lg0KPg0KPiA+IFVzaW5nIHRoZSBzZXJ2ZXIgbGF5ZXIsIGFzIHlvdSd2ZSBz dWdnZXN0ZWQsIHNlZW1zIGFzIGxheWVyIHZpb2xhdGlvbi4NCj4gPg0KPg0KPiBUaGlzIGlzIGEg ZnVubnkgc3RhdGVtZW50IOKAlCBOVk8zIGlzIGEgbGF5ZXIgdmlvbGF0aW9uIDotKSBTbyBhcmUg UHNldWRvd2lyZXMuIFBsZWFzZSBkbyBub3QgdGFrZSB0aGlzIHN0YXRlbWVudCB0b28gc2VyaW91 c2x5LCBpdCBpcyBub3QgaW52aXRpbmcgZGlzY3Vzc2lvbi4NCj4NCj4gPiA+ICAgICAgIOKAoiBJ IGJlbGlldmUgdGhhdCB0aGUgdXNlIG9mIHRoZSBkZWRpY2F0ZWQgT0FNIGZsYWcgYW5kIHRoZSBO ZXh0IFByb3RvY29sIGZpZWxkIGZvciBhIGZpeGVkLXNpemUgaGVhZGVyIHRoYXQgY2Fubm90IGlu Y2x1ZGUgbWV0YS1kYXRhIGlzIHVud2FycmFudGVkIGFuZCBhZGRzIHVubmVjZXNzYXJ5IGNvbXBs ZXhpdHkuDQo+ID4NCj4gPiBEaXNhZ3JlZS4NCj4gPg0KPiA+IFNlZSBleGFtcGxlIHdoZXJlIHBy b3RvY29sIGlzIElQIGNhcnJ5aW5nIGFuIE9BTSBwYWNrZXQuDQo+ID4gR0lNPj4gV2hlbiBJUC9V RFAgZW5jYXBzdWxhdGlvbiBpcyB1c2VkIGZvciBPQU0sIHRoZXJlJ3Mgbm8sIGluIG15IG9waW5p b24sIGFueSBuZWVkIHRvIHVzZSB0aGUgTy1iaXQuIFRoZSBkZXN0aW5hdGlvbiBJUCBhZGRyZXNz IG11c3QgYmUgYXMgZGVzY3JpYmVkIGluIFJGQyA4MDI5IG9yIFJGQyA1ODg0IGFuZCB0aGUgZGVt dWx0aXBsZXhpbmcgaXMgZG9uZSBiYXNlZCBvbiB0aGUgZGVzdGluYXRpb24gVURQIHBvcnQgbnVt YmVyLiBDbGVhcmx5LCBPLWJpdCBpcyB1bm5lY2Vzc2FyeSBpZiBJUC9VRFAgZW5jYXBzdWxhdGlv biBmb3IgT0FNIGJlaW5nIHVzZWQuDQo+ID4NCj4NCj4gRm9ydHVuYXRlbHksIGJpdCB1c2FnZSBp cyBhIG1hdHRlciBvZiBkZWZpbml0aW9uIGFuZCBub3Qgb3BpbmlvbiA6LSkNCj4NCj4gS2luZCBy ZWdhcmRzLA0KPg0KPiBDYXJsb3MuDQo+DQo+DQo+ID4gPiBJIHN1Z2dlc3Qgbm90IHRvIHVzZSBP LWJpdCBpbiB0aGUgVlhMQU4tR1BFIGhlYWRlciBhbmQgcmVsZWFzZSBpdCBpbnRvIHRoZSBSZXNl cnZlZCBmaWVsZC4gIEkgZG9uJ3Qgc2VlIHRoZSBhcHBhcmVudCBiZW5lZml0IG9mIHVzaW5nIHRo ZSBmbGFnLCBhcyB0aGUgVlhMQS1HUEUgdXNlcyB0aGUgZml4ZWQgc2l6ZSBoZWFkZXIgYW5kIHRo ZSBoZWFkZXIgY2Fubm90IGNhcnJ5IE9BTSBkYXRhIGluIGl0LiBUaGUgb25seSByb2xlIHRoZSBW WExBTi1HUEUgaGVhZGVyIG11c3QgcGVyZm9ybSwgaW4gbXkgb3BpbmlvbiwgaXMgdG8gdW5hbWJp Z3VvdXNseSBpZGVudGlmeSB0aGUgcGF5bG9hZCB0eXBlIHRoYXQgaW1tZWRpYXRlbHkgZm9sbG93 cyB0aGUgaGVhZGVyIGFzIE9BTSAoZGVtdWx0aXBsZXhpbmcgT0FNIHByb3RvY29scyBtYXkgYmUg ZG9uZSBpbiBPQU0gSGVhZGVyIHNoaW0pLg0KPiA+ID4gTXVjaCBhcHByZWNpYXRlIHlvdXIgY29u c2lkZXJhdGlvbi4NCj4gPiA+DQo+ID4NCj4gPiBCZXN0LA0KPiA+DQo+ID4g4oCUDQo+ID4gQ2Fy bG9zIFBpZ25hdGFybywgY2FybG9zQGNpc2NvLmNvbTxtYWlsdG86Y2FybG9zQGNpc2NvLmNvbT4N Cj4gPg0KPiA+IOKAnFNvbWV0aW1lcyBJIHVzZSBiaWcgd29yZHMgdGhhdCBJIGRvIG5vdCBmdWxs eSB1bmRlcnN0YW5kLCB0byBtYWtlIG15c2VsZiBzb3VuZCBtb3JlIHBob3Rvc3ludGhlc2lzLiIN Cj4gPg0KPiA+ID4gUmVnYXJkcywNCj4gPiA+IEdyZWcNCj4gPiA+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBudm8zIG1haWxpbmcgbGlzdA0K PiA+ID4gbnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz4NCj4gPiA+IGh0dHBzOi8v c2VjdXJlLXdlYi5jaXNjby5jb20vMWotanI2NHloMkQ4eU85MmliY3FhTi1IOThaQ1AzbFFkSG1z WVBzSDhsa2pzYTRXbEo0a2czVzRITDhxVDI1ckNWaXR0VDViRlFveF9fT25Ta25WNXdfd1c2OUZ2 VWhYa3hxeEtoaTlNQ2l5NW9ILUpUdWNYTl83Rks4NXE3akQtcUV3Uk01SVhZNjhfVmZlYl9YSTJy S3h5endWc0dfMDZLVEdGMDlCdzlvSEFPWFVORmNkQ3dfb29uX2VydVVoUlB0ZHdMYzlVUU56MlRo WVA4eXNmMnByNjRWVTA0VmpNS21Hd3FZdnp6eUFzTFRFYkhyczdHVkNxcGhUNThUMHN0NzhfOTY4 ck01TUtGTGs3RWlXQmo3Z1pQbV9yRGVCZjYzZ1V0eGtjai13OFh5YkppaU8ydGNGYWVvQUxfOG0t WlQ1TDktMVZLNHdaa0htUjVDX0xkZy9odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxt YW4lMkZsaXN0aW5mbyUyRm52bzMNCj4gPg0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBudm8zIG1haWxpbmcgbGlzdA0KPiBudm8zQGlldGYu b3JnPG1haWx0bzpudm8zQGlldGYub3JnPg0KPiBodHRwczovL3NlY3VyZS13ZWIuY2lzY28uY29t LzFqLWpyNjR5aDJEOHlPOTJpYmNxYU4tSDk4WkNQM2xRZEhtc1lQc0g4bGtqc2E0V2xKNGtnM1c0 SEw4cVQyNXJDVml0dFQ1YkZRb3hfX09uU2tuVjV3X3dXNjlGdlVoWGt4cXhLaGk5TUNpeTVvSC1K VHVjWE5fN0ZLODVxN2pELXFFd1JNNUlYWTY4X1ZmZWJfWEkyckt4eXp3VnNHXzA2S1RHRjA5Qnc5 b0hBT1hVTkZjZEN3X29vbl9lcnVVaFJQdGR3TGM5VVFOejJUaFlQOHlzZjJwcjY0VlUwNFZqTUtt R3dxWXZ6enlBc0xURWJIcnM3R1ZDcXBoVDU4VDBzdDc4Xzk2OHJNNU1LRkxrN0VpV0JqN2daUG1f ckRlQmY2M2dVdHhrY2otdzhYeWJKaWlPMnRjRmFlb0FMXzhtLVpUNUw5LTFWSzR3WmtIbVI1Q19M ZGcvaHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZudm8z DQo= --_000_5C94C61682BD49CEBB20A31F843E8806ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <7E4C364AFA98144E8F9DD3737B762D0F@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJZdSBNaW5j aG8iOw0KCXBhbm9zZS0xOjIgMiA0IDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseToiXEBZdSBNaW5jaG8iO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5t c29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFt ZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBp bjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9u dC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFu LkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RGVhciBHcmVnLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBhbiBpbm5v Y2VudCBieXN0YW5kZXIsIEkgaGF2ZSBubyBkb2cgaW4gdGhpcyBmaWdodCAoaS5lLiwgbm8gcGVy c29uYWwgc3Rha2UgaW4gdGhlIGlzc3VlIHlvdSBrZWVwIHJhaXNpbmcpLCBidXQgeW91IHNlZW0g dG8gYmUgbWFraW5nIGEgcmF0aGVyIHN0cm9uZyBhY2N1c2F0aW9uOiDigJw8aT50aGUgdXBkYXRl cyB0aGUgZWRpdG9ycyBoYXZlIGJlZW4gbWFraW5nIHdpdGhvdXQgdGhlIFdHIGFncmVlaW5nIHRv DQogdGhhdDwvaT7igJ0uIFlvdSB0YWxrIGFib3V0IHBsdXJhbCDigJx1cGRhdGVz4oCdLCBhbmQg eW91IHVzZSBhIGNvbnRpbnVlZCB0ZW5zZSBvZiDigJxoYXZlIGJlZW4gbWFraW5n4oCdIChpbXBs eWluZyBtb3JlIHRoYW4gb25jZSwgb3IgcmVwZWF0ZWRseSkuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkxvb2tpbmcgYXQgdGhlIGRpZmZzIGZyb20gZHJhZnQtaWV0Zi1udm8zLXZ4bGFuLWdwZS0w MCB0byBkcmFmdC1pZXRmLW52bzMtdnhsYW4tZ3BlLTA3OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly93d3c2LmlldGYub3JnL3JmY2RpZmYvP3Vy bDE9ZHJhZnQtaWV0Zi1udm8zLXZ4bGFuLWdwZS0wMCZhbXA7dXJsMj1kcmFmdC1pZXRmLW52bzMt dnhsYW4tZ3BlLTA3Ij5odHRwczovL3d3dzYuaWV0Zi5vcmcvcmZjZGlmZi8/dXJsMT1kcmFmdC1p ZXRmLW52bzMtdnhsYW4tZ3BlLTAwJmFtcDt1cmwyPWRyYWZ0LWlldGYtbnZvMy12eGxhbi1ncGUt MDc8L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgc2VlIG5vIGNoYW5nZXMgaW4gdGhlIGRl ZmluaXRpb24gb2YgdGhlIE8tYml0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHdpbGwgc3Rv cCByZXBseWluZyB0byB0aGlzIHRocmVhZCB3aXRoIHRoaXMgZmluYWwgbm90ZSwgYW5kIGxldCB0 aGUgRWRpdG9ycyBvZiB0aGF0IGRvY3VtZW50IGFuc3dlciB5b3VyIGV4cGxpY2l0IGNhbGwg4oCT IGhvd2V2ZXIsIGZvciB0aGUgYmVuZWZpdCBvZiBjbGFyaXR5IGZvciB0aGUgV0csIHdoYXQgc3Bl Y2lmaWMgdXBkYXRlcyB5b3UgcmVmZXIgdG8/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPllvdSBt ZW50aW9uIOKAnHRoZSBsYXN0IHR3byB2ZXJzaW9uc+KAnSBvZiBWWExBTi1HUkUuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4wNSAtJmd0OyAwNjogPGEgaHJlZj0iaHR0cHM6 Ly93d3c2LmlldGYub3JnL3JmY2RpZmYvP3VybDE9ZHJhZnQtaWV0Zi1udm8zLXZ4bGFuLWdwZS0w NSZhbXA7dXJsMj1kcmFmdC1pZXRmLW52bzMtdnhsYW4tZ3BlLTA2Ij4NCmh0dHBzOi8vd3d3Ni5p ZXRmLm9yZy9yZmNkaWZmLz91cmwxPWRyYWZ0LWlldGYtbnZvMy12eGxhbi1ncGUtMDUmYW1wO3Vy bDI9ZHJhZnQtaWV0Zi1udm8zLXZ4bGFuLWdwZS0wNjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgc2VlIG5vIGNvbnRlbnQgY2hhbmdlcyDigJMgb25seSB1cGRhdGlu ZyByZWZlcmVuY2VzIGFuZCBzcGFjZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MDYgLSZndDsg MDc6IDxhIGhyZWY9Imh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9yZmNkaWZmLz91cmwxPWRyYWZ0LWll dGYtbnZvMy12eGxhbi1ncGUtMDYmYW1wO3VybDI9ZHJhZnQtaWV0Zi1udm8zLXZ4bGFuLWdwZS0w NyI+DQpodHRwczovL3d3dzYuaWV0Zi5vcmcvcmZjZGlmZi8/dXJsMT1kcmFmdC1pZXRmLW52bzMt dnhsYW4tZ3BlLTA2JmFtcDt1cmwyPWRyYWZ0LWlldGYtbnZvMy12eGxhbi1ncGUtMDc8L2E+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWZpbml0aW9uIG9mIE5leHQgUHJv dG9jb2wgcmFuZ2UgZm9yIHNoaW0gaGVhZGVycywgYW5kIGFzc2lnbm1lbnQgb2YgYSBOZXh0IFBy b3RvY29sIHZhbHVlIGZvciB0aGUgSU9BTSBzaGltLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X aGljaCBvbmUgaXMgaXQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNhcmxvcy48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+R3JlZyBNaXJza3kgJmx0O2dyZWdpbWlyc2t5QGdtYWlsLmNv bSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBBcHJpbCAxNywgMjAxOSBhdCA4OjQ5 IFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDtDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkmcXVv dDsgJmx0O2NwaWduYXRhQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPk5WTzMgJmx0O252 bzNAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtkcmFmdC1pZXRmLW52bzMtdnhsYW4tZ3BlQGlldGYub3Jn JnF1b3Q7ICZsdDtkcmFmdC1pZXRmLW52bzMtdnhsYW4tZ3BlQGlldGYub3JnJmd0OywgSUVURiBJ UFBNIFdHICZsdDtpcHBtQGlldGYub3JnJmd0OywgJnF1b3Q7c2ZjQGlldGYub3JnJnF1b3Q7ICZs dDtzZmNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbU1VTUElDSU9VU10g UmU6IFtudm8zXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLW52bzMtdnhsYW4tZ3BlPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBD YXJsb3MsIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoYW5r IHlvdSBmb3IgdGhlIGRpc2N1c3Npb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyB0aGUgVlhMQU4tR1BFIGlzIG9uIHRoZSBJbmZvcm1hdGlv bmFsIHRyYWNrLCB0aGVyZSBtYXkgYmUgbGl0dGxlIHBvaW50IHRvIGRpc2N1c3MgaXQuIEJ1dCBh cyB0aGUgZHJhZnQgaGFzIGJlZW4gYWRvcHRlZCBieSBOVk8zIFdHLCBJJ20gY3VyaW91cyBhYm91 dCB0aGUgdXBkYXRlcyB0aGUgZWRpdG9ycyBoYXZlIGJlZW4gbWFraW5nIHdpdGhvdXQgdGhlIFdH IGFncmVlaW5nIHRvIHRoYXQuIEknbSBsb29raW5nDQogZm9yd2FyZCB0byBoZWFyaW5nIGZyb20g YW55IG9mIHRoZSBlZGl0b3JzIG9mIFZYTEFOLUdQRSBhYm91dCB0aGUgdXBkYXRlcyBpbiB0aGUg bGFzdCB0d28gdmVyc2lvbnMuIEFsc28sIGhvcGUgZWRpdG9ycyBvZiB0aGUgZHJhZnQgd2lsbCBm aW5kIHRpbWUgdG8gcmVwbHkgdG8gbXkgcXVlc3Rpb25zIGFuZCBjb25zaWRlciBteSBjb21tZW50 cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkdyZWc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gV2VkLCBBcHIgMTcsIDIwMTkgYXQgNToxOCBQTSBDYXJsb3MgUGlnbmF0YXJvIChj cGlnbmF0YSkgJmx0OzxhIGhyZWY9Im1haWx0bzpjcGlnbmF0YUBjaXNjby5jb20iPmNwaWduYXRh QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5E ZWFyIEdyZWcsPGJyPg0KPGJyPg0KW05vdyBhZGRpbmcgdGhlIFNGQyBXRyBNYWlsaW5nIGxpc3Qg c2luY2UgeW91IHRha2UgdXMgdG8gYSBkaWZmZXJlbnQgV0cgYWdhaW5dPGJyPg0KPGJyPg0KVGhh bmsgeW91IHZlcnkgbXVjaCBmb3IgZmluZS1jb21iaW5nIHdpdGggYSBtYWduaWZ5aW5nIGdsYXNz IHRocm91Z2ggYWxsIHRoZSBkb2N1bWVudHMgSeKAmW0gY3VycmVudGx5IGNvLWF1dGhvcmluZyA6 LSk8YnI+DQo8YnI+DQpJdCBpcyByZWZyZXNoaW5nIHRvIHNlZSB0aGF0IHRoZSBvbmx5IGlzc3Vl cyB5b3UgZmluZCBhcmUgbm9uLWlzc3VlcywgYW5kIHlvdXIgcXVlc3Rpb25zIGVhc3kgdG8gcmUt YW5zd2VyIDotKTxicj4NCjxicj4NCkF0IHRoaXMgcG9pbnQgSSBhbSBhIGJpdCBhdCBhIGxvc3Mg b2Ygd2hhdCB5b3VyIHBvaW50IGlzLCBvciB3aGF0IHlvdSBhcmUgdHJ5aW5nIHRvIHByb3ZlIGJl bmRpbmcgdGV4dC4gQXJlIHlvdSBjb2RpbmcsIGRlcGxveWluZywgb3IgdGVzdGluZyBJT0FNIG9u IE5TSCB3aXRob3V0IGRhdGEgcGFja2V0cyBvbiBWWExBTi1HUEUgb3ZlciBJUD8gTlNIIGlzIGRh dGEgYXMgZmFyIGFzIFZYTEFOLUdQRSBpcyBjb25jZXJuZWQuIElPQU0gc2hpbW1lZCBpbg0KIE5T SCBpcyBvcnRob2dvbmFsIHRvIElPQU0gc2hpbW1lZCBpbiBWWExBTi1HUEUuPGJyPg0KPGJyPg0K SSBmZWVsIHRoaXMgZGlzY3Vzc2lvbiBhYm91dCB0aGUgTy1iaXQgYWxyZWFkeSB0b29rIHBsYWNl IG9uY2Ugb3IgdHdpY2UuPGJyPg0KPGJyPg0KS2luZCBSZWdhcmRzLDxicj4NCjxicj4NCuKAlCBD YXJsb3MgUGlnbmF0YXJvPGJyPg0KPGJyPg0KUFM6IFRoZSBFdmlsIGJpdCBpcyBkZWZpbmVkIGZv ciBJUHY0LCBzaG91bGQgd2UgdGhlcmVmb3JlIGFsc28gZGVmaW5lIGl0IGhlcmU/PGJyPg0KPGJy Pg0KPGJyPg0KJmd0OyBPbiBBcHIgMTcsIDIwMTksIGF0IDU6NTQgUE0sIEdyZWcgTWlyc2t5ICZs dDs8YSBocmVmPSJtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+ Z3JlZ2ltaXJza3lAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IEhpIENhcmxvcyw8YnI+DQomZ3Q7IHRvIGFkZCBhbm90aGVyIHF1b3RlIGZyb20gdGhlIGRyYWZ0 LWlldGYtc2ZjLWlvYW0tbnNoIHRoYXQgeW91J3ZlIGNvLWF1dGhvcmVkLCA8YnI+DQomZ3Q7Jm5i c3A7ICZuYnNwOyBQYWNrZXRzIHdpdGggSU9BTSBkYXRhIGluY2x1ZGVkIE1VU1QgZm9sbG93IHRo aXM8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBkZWZpbml0aW9uLCBpLmUuIHRoZSBPIGJpdCBNVVNU IE5PVCBiZSBzZXQgZm9yIHJlZ3VsYXIgY3VzdG9tZXI8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyB0 cmFmZmljIHdoaWNoIGFsc28gY2FycmllcyBJT0FNIGRhdGEgYW5kIHRoZSBPIGJpdCBNVVNUIGJl IHNldCBmb3I8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBPQU0gcGFja2V0cyB3aGljaCBjYXJyeSBv bmx5IElPQU0gZGF0YSB3aXRob3V0IGFueSByZWd1bGFyIGRhdGE8YnI+DQomZ3Q7Jm5ic3A7ICZu YnNwOyBwYXlsb2FkLjxicj4NCiZndDsgPGJyPg0KJmd0OyBTbywgaWYgdGhlIG9ubHkgaU9BTSBt ZXNzYWdlIGlzIGNhcnJpZWQgaW4gb3IgYWZ0ZXIgYW4gTlNILCBpdCBpcyBpZGVudGlmaWVkIGFz IE9BTS4gQW5kLCBieSB5b3VyIG93biBleGFtcGxlIGluIHRoZSBlYXJsaWVyIG5vdGUsIHNvIHNo b3VsZCBWWExBTi1HUEUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyBH cmVnPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIFdlZCwgQXByIDE3LCAyMDE5IGF0IDEyOjQ0IFBN IENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNwaWduYXRh QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNwaWduYXRhQGNpc2NvLmNvbTwvYT4mZ3Q7IHdy b3RlOjxicj4NCiZndDsgSGksIEdyZWcsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFkZGluZyB0aGUg SVBQTSBtYWlsaW5nIGxpc3QsIHNpbmNlIHlvdSByZWZlcmVuY2UgaXQgYmVsb3csIGFuZCBwb2lu dCB0byBSRkMgNzc5OS48YnI+DQomZ3Q7IDxicj4NCiZndDsgUGxlYXNlIHNlZSBpbmxpbmUuPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgT24gQXByIDE3LCAyMDE5LCBhdCAzOjAwIFBNLCBHcmVn IE1pcnNreSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgSGkgQ2FybG9zLDxicj4NCiZndDsgJmd0OyB0aGFuayB5b3Ug Zm9yIHNoYXJpbmcgeW91ciB2aWV3IG9uIHRoZSBkZXNpZ24gb2YgdGhlIFZYTEFOLUdQRSBwcm90 b2NvbC4gUGxlYXNlIGZpbmQgbXkgY29tbWVudHMgaW4tbGluZSB0YWdnZWQgR0lNJmd0OyZndDsu PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBSZWdhcmRzLDxicj4NCiZndDsgJmd0OyBH cmVnPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBPbiBGcmksIEFwciAxMiwgMjAxOSBh dCA1OjIzIEFNIENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSAmbHQ7PGEgaHJlZj0ibWFpbHRv OmNwaWduYXRhQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNwaWduYXRhQGNpc2NvLmNvbTwv YT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0OyBHcmVnLDxicj4NCiZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgWW91IHNlZW0gdG8gYmUgY29uZnVzaW5nIGFuZCBtaXhpbmcgdGhpbmdzIHVwLjxi cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgUGxlYXNlIHNlZSBpbmxpbmUuPGJyPg0KJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IE9uIEFwciAxMiwgMjAxOSwgYXQgMjo1MCBBTSwg R3JlZyBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8YnI+DQom Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBEZWFyIEVkaXRvcnMsIGV0IGFsLiw8 YnI+DQomZ3Q7ICZndDsgJmd0OyBJJ3ZlIHJlYWQgdGhlIGxhdGVzdCAtMDcgdmVyc2lvbiBhbmQg d291bGQgbGlrZSB0byBzaGFyZSBteSBjb21tZW50cyBhbmQgcXVlc3Rpb25zIHdpdGggeW91Ojxi cj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A74oCiIGluIHRoZSBl YXJsaWVyIHZlcnNpb24gb2YgdGhlIGRyYWZ0LCB0aGUgTy1iaXQgd2FzIGludHJvZHVjZWQgYW5k IGRlZmluZWQgYXM6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgT0FNIEZsYWcgQml0IChPIGJpdCk6Jm5i c3A7IFRoZSBPIGJpdCBpcyBzZXQgdG8gaW5kaWNhdGUgdGhhdCB0aGUgcGFja2V0IGlzIGFuIE9B TSBwYWNrZXQuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgQXQgdGhlIHNhbWUgdGltZSwgaW4gdGhlIGxh dGVzdCB2ZXJzaW9uLCB0aGUgbmV3IE5leHQgUHJvdG9jb2wgdmFsdWUgKDB4ODEpIHRvIGlkZW50 aWZ5IGlPQU0gRGF0YSB3YXMgaW50cm9kdWNlZC4gSGVuY2UgYXJlIG15IHF1ZXN0aW9uczo8YnI+ DQomZ3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO+KAoiBXaGF0IG11c3Qg YmUgdGhlIHZhbHVlIG9mIHRoZSBPLWJpdCB3aGVuIHRoZSB2YWx1ZSBvZiB0aGUgTmV4dCBQcm90 b2NvbCBmaWVsZCBpcyBpT0FNPzxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhlIE8g Yml0IOKAnGlzIHNldCB0byBpbmRpY2F0ZSB0aGF0IHRoZSBwYWNrZXQgaXMgYW4gT0FNIHBhY2tl dOKAnS48YnI+DQomZ3Q7ICZndDsgSUFPTSBpcyBub3QgYW4gT0FNIHBhY2tldC4gSGVuY2UsIE8g Yml0IGNsZWFyIGlmIFZYTEFOLUdQRSBlbmNhcHN1bGF0ZXMgYSBub24tT0FNIHBhY2tldCBhbmQg YWRkcyBhbiBJT0FNIHNoaW0uPGJyPg0KJmd0OyAmZ3Q7IEdJTSZndDsmZ3Q7IEl0IGlzIGEgdmVy eSB1bmV4cGVjdGVkIHN0YXRlbWVudCBmcm9tIHlvdSw8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSB3 b3VsZCB0ZWxsIHlvdSDigJhleHBlY3QgdGhlIHVuZXhwZWN0ZWTigJksIGJ1dCB0aGF0IGlzIG5v dCB0aGUgY2FzZSBoZXJlLi4uIDotKTxicj4NCiZndDsgPGJyPg0KJmd0OyBJZiB5b3UgYWN0dWFs bHkgcmVhZCBteSBzdGF0ZW1lbnQsIHlvdSB3aWxsIHNlZSAmcXVvdDtJQU9NIGlzIG5vdCBhbiBP QU0gKnBhY2tldCou4oCdIE5ldyBlbXBoYXNpcyBhZGRlZCDigJQgaXQgaXMgX25vdF8gKmFuIE9B TSBwYWNrZXQqLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJIHN0YW5kIGJ5IGl0LiBJdOKAmXMgYW4g YXVnbWVudGVkIGRhdGEgcGFja2V0IG9mIGludGVyZXN0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyAm Z3Q7IG9uZSBvZiB0aGUgY28tYXV0aG9ycyBvZiBkcmFmdC1pZXRmLWlwcG0taW9hbS1kYXRhJm5i c3A7IHdoZXJlIHRoZSBmaXJzdCBwYXJhZ3JhcGggb2YgdGhlIEludHJvZHVjdGlvbiBzZWN0aW9u IGRlZmluZXMgaU9BTSBhcyBIeWJyaWQgVHlwZSAxIE9BTSwgYWNjb3JkaW5nIHRvIFJGQyA3Nzk5 IGNsYXNzaWZpY2F0aW9uOjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGlzIGlzIHN0aWxsIHF1aXRl IGNvbnNpc3RlbnQgd2l0aCB0aGF0IGRlZmluaXRpb24sIHdoaWNoIEkgcmVjb21tZW5kIHlvdSBy ZS1yZWFkOjxicj4NCiZndDsgPGJyPg0KJmd0OyBSRkMgNzc5OSBpcyBhYm91dCBtZXRyaWNzIGFu ZCBtZXRob2RzLCBub3QgcGFja2V0IGRlZmluaXRpb25zLjxicj4NCiZndDsgPGJyPg0KJmd0OyBZ b3Ugd2lsbCBzZWUgdGhhdCBBY3RpdmUgbWV0aG9kcyBpbmNsdWRlIGEg4oCcZGVkaWNhdGVkIG1l YXN1cmVtZW50IHBhY2tldCBzdHJlYW3igJ0uIOKAnEFjdGl2ZSBNZXRob2RzIGdlbmVyYXRlIHBh Y2tldCBzdHJlYW1zLuKAnTxicj4NCiZndDsgPGJyPg0KJmd0OyBIb3dldmVyLCBIeWJyaWQgVHlw ZSBJIGxldmVyYWdlcyDigJxBdWdtZW50YXRpb24gb3IgbW9kaWZpY2F0aW9uIG9mIHRoZSBzdHJl YW0gb2YgaW50ZXJlc3QmcXVvdDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgRm9sbG93aW5nIHlvdXIg bG9naWMsIGlmIHlvdSBjaGFuZ2UgYSBwYWNrZXQgZmllbGQgc3VjaCBhcyBUVEwvSEwgdG8gcHJv dmlkZSBwYWNrZXQgY29sb3JpbmcsIGRvIHlvdSBuZWVkIHRvIHNldCB0aGUgTy1iaXQ/PGJyPg0K Jmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7IElPQU0gaXMgdG8gY29tcGxlbWVudDxi cj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgbWVjaGFuaXNtcyBzdWNoIGFzIFBpbmcgb3IgVHJh Y2Vyb3V0ZSwgb3IgbW9yZSByZWNlbnQgYWN0aXZlIHByb2Jpbmc8YnI+DQomZ3Q7ICZndDsmbmJz cDsgJm5ic3A7IG1lY2hhbmlzbXMgYXMgZGVzY3JpYmVkIGluIFtJLUQubGFwdWtob3YtZGF0YXBs YW5lLXByb2JlXS4uJm5ic3A7IEluIHRlcm1zPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyBv ZiAmcXVvdDthY3RpdmUmcXVvdDsgb3IgJnF1b3Q7cGFzc2l2ZSZxdW90OyBPQU0sICZxdW90O2lu LXNpdHUmcXVvdDsgT0FNIGNhbiBiZSBjb25zaWRlcmVkIGE8YnI+DQomZ3Q7ICZndDsmbmJzcDsg Jm5ic3A7IGh5YnJpZCBPQU0gdHlwZS4mbmJzcDsgV2hpbGUgbm8gZXh0cmEgcGFja2V0cyBhcmUg c2VudCwgSU9BTSBhZGRzPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyBpbmZvcm1hdGlvbiB0 byB0aGUgcGFja2V0cyB0aGVyZWZvcmUgY2Fubm90IGJlIGNvbnNpZGVyZWQgcGFzc2l2ZS48YnI+ DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7IEluIHRlcm1zIG9mIHRoZSBjbGFzc2lmaWNhdGlvbiBn aXZlbiBpbiBbUkZDNzc5OV0gSU9BTSBjb3VsZCBiZTxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJz cDsgcG9ydHJheWVkIGFzIEh5YnJpZCBUeXBlIDEuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A74oCiIERvIHlvdSBwbGFuIHRvIGRl ZmluZSB0aGUgTmV4dCBQcm90b2NvbCB2YWx1ZXMgZm9yIGFjdGl2ZSBPQU0gcHJvdG9jb2xzLCBl LmcuLCBFY2hvIFJlcXVlc3QvUmVwbHksIEJGRCwgUGVyZm9ybWFuY2UgTW9uaXRvcmluZz88YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEkgY2Fubm90IHNwZWFrIHRvIOKAnHBsYW5z4oCd IChyZXBseWluZyBhcyDigJxldCBhbC7igJ0sIG5vdCBhcyDigJxlZGl0b3LigJ0pLCBidXQgSSBl eHBlY3QgT0FNIGRvY3VtZW50cyBvdWdodCB0byBoYXZlIHRob3NlIHJlcXVlc3RlZCwgYW5kIHlv dSBkbyBub3QgbmVlZCBuZWNlc3NhcmlseSBhbGwgb2YgdGhvc2Ug4oCUIHRoZSBuZXggcHJvdG9j b2wgSVB2NCAvIElQdjYgY2FuIGVuY2Fwc3VsYXRlIElDTVAsIFVEUC9CRkQsIGV0Yy4sIGV0Yy4s IGV0Yy4sIGV0Yy48YnI+DQomZ3Q7ICZndDsgR0lNJmd0OyZndDsgT2YgY291cnNlLCB1c2Ugb2Yg dGhlIHdlbGwta25vd24gcG9ydCBudW1iZXIsIHVzdWFsbHkgaXQgaXMgVURQIGRlc3RpbmF0aW9u IHBvcnQsIGlzIG9uZSBvZiB0aGUgbWV0aG9kcyB0byBkZW11bHRpcGxleCBwcm90b2NvbHMuIFRo aXMgbWV0aG9kIGlzIGJyb2FkbHkgdXNlZCwgZm9yIGV4YW1wbGUsIGluIE1QTFMgT0FNLiBCdXQg dGhpcyBtZXRob2QgaGFzIHNvbWUgZGlzYWR2YW50YWdlcyB0aGF0IHdlcmUgcG9pbnRlZCBvdXQg aW4NCiB0aGUgZGlzY3Vzc2lvbiBvZiBCRkQgb3ZlciBHRU5FVkUgaW4gUHJhZ3VlIGJ5IERhdmlk IEJsYWNrICh0aGUgbGFzdCBwcmVzZW50YXRpb24gaW4gdGhlIG1pbnV0ZXMpOjxicj4NCiZndDsg Jmd0OyBEYXZpZDogSSB3YW50IHRoZSBCRkQgaGVhZGVyIHRvIGJlIGFzIGNsb3NlIHRvIHRoZSB0 aGluZyB3aG9zZSBsaXZlbmVzcyBJJ20gdGVzdGluZy4gVGhlIG1vcmUgaGVhZGVycyB5b3UgYWRk IGluIHRoZSBtaWRkbGUsIHRoZSBtb3JlIHdheXMgdGhlcmUgYXJlIHRvIGJyZWFrIEJGRCB3aXRo b3V0IGJyZWFraW5nIHRoZSBmb3J3YXJkaW5nIGVuZ2luZS4gVGhlIGZ1cnRoZXIgYXdheSBJIG1v dmUgQkZEIGZyb20gdGhlIGNodW5rIG9mIGhhcmR3YXJlJ3MNCiBsaXZlbmVzcyBJIGNhcmUgYWJv dXQsIHRoZSBtb3JlIG9wcG9ydHVuaXRpZXMgYXJlIGZvciBCRkQgYW5kIHRoZSBoYXJkd2FyZSB0 byBub3QgdG8gdGVsbCBtZSB0aGUgc2FtZSB0aGluZy48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IFRoZW9yeSBhbmQgcHJhY3RpY2UgbWF0Y2ggaW4gdGhlb3J5LCBsZXNzIHNv IGluIHByYWN0aWNlIOKAlCB1bmxlc3MgeW91IGFyZSBwbGFubmluZyB0byB1cGRhdGUgUkZDIDU4 ODEuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoaXMgY2FuIGJlIGFyZ3VlZCBib3RoIHdheXMgKGUu Zy4sIGJldHRlciB0byBoYXZlIGNvbW1vbiBoYW5kbGVycywgZXRjLiksIGJ1dCBJIHRha2Ugbm8g cG9zaXRpb24uIEkgZG8gc2F5IHRoYXQgaW4gcHJlc2VuY2Ugb2YgZGVwbG95ZWQgT0FNIGVuY2Fw c3VsYXRpb25zLCB0aGVyZeKAmXMgbm8gYmFzaXMgZm9yIHlvdXIgeW91ciBjb21tZW50IGFib3V0 IGRlZmluaW5nIGEgcHJvdG9jb2wgdHlwZSBmb3Ig4oCcUGVyZm9ybWFuY2UgTW9uaXRvcmluZ+KA nQ0KIGFzIGEgcHJvdG9jb2wuLi48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7 IDxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A74oCiIEhvdyB0 byBpbnRlcnByZXQgdGhlIHNpdHVhdGlvbiB3aGVuIHRoZSBPLWJpdCB2YWx1ZSBpcyAxIGJ1dCB0 aGUgdmFsdWUgb2YgdGhlIE5leHQgUHJvdG9jb2wgZmllbGQgaXMsIGZvciBleGFtcGxlLCBOU0gs IGkuZS4uLCBub3QgYW55IG9mIE9BTSBwcm90b2NvbHM/PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyBJIGV4cGVjdCBpdCBtZWFucyB0aGVyZeKAmXMgT0FNIHdpdGhpbiB0aGF0IE5TSCAo c29tZXRpbWVzIHRoZXJl4oCZcyBubyBzdWNoIHRoaW5ncyBhcyDigJxPQU0gUHJvdG9jb2xz4oCd KSwgb3IgYW4gdW5oYW5kbGVkIE9BTSBwcm90b2NvbC48YnI+DQomZ3Q7ICZndDsgR0lNJmd0OyZn dDsgU2hvdWxkIHRoYXQsIGkuZS4sIE9BTSBpbiBOU0ggb3IgaW1tZWRpYXRlbHkgZm9sbG93aW5n IE5TSCBiZSBzaWduYWxlZCB1c2luZyBTRkMgTlNIIG1ldGhvZHMgdGhhdCBhcmUgYWxyZWFkeSBk ZWZpbmVkIGluIGRyYWZ0LWlldGYtc2ZjLW11bHRpLWxheWVyLW9hbT88YnI+DQomZ3Q7IDxicj4N CiZndDsgPGJyPg0KJmd0OyBOb24gc2VxdWl0dXIg4oCUIEkgZG8gbm90IGZvbGxvdyB3aGF0IHNp Z25hbGluZyBoYXMgdG8gZG8gd2l0aCB0aGUgY29udmVyc2F0aW9uLCBub3IgaG93IHRoYXQgZHJh ZnQgbWlnaHQgYmUgcmVsZXZhbnQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgVXNpbmcgdGhl IHNlcnZlciBsYXllciwgYXMgeW91J3ZlIHN1Z2dlc3RlZCwgc2VlbXMgYXMgbGF5ZXIgdmlvbGF0 aW9uLiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoaXMgaXMgYSBmdW5u eSBzdGF0ZW1lbnQg4oCUIE5WTzMgaXMgYSBsYXllciB2aW9sYXRpb24gOi0pIFNvIGFyZSBQc2V1 ZG93aXJlcy4gUGxlYXNlIGRvIG5vdCB0YWtlIHRoaXMgc3RhdGVtZW50IHRvbyBzZXJpb3VzbHks IGl0IGlzIG5vdCBpbnZpdGluZyBkaXNjdXNzaW9uLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7 ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDvigKIgSSBiZWxpZXZlIHRoYXQgdGhlIHVz ZSBvZiB0aGUgZGVkaWNhdGVkIE9BTSBmbGFnIGFuZCB0aGUgTmV4dCBQcm90b2NvbCBmaWVsZCBm b3IgYSBmaXhlZC1zaXplIGhlYWRlciB0aGF0IGNhbm5vdCBpbmNsdWRlIG1ldGEtZGF0YSBpcyB1 bndhcnJhbnRlZCBhbmQgYWRkcyB1bm5lY2Vzc2FyeSBjb21wbGV4aXR5Ljxicj4NCiZndDsgJmd0 OyA8YnI+DQomZ3Q7ICZndDsgRGlzYWdyZWUuIDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZn dDsgU2VlIGV4YW1wbGUgd2hlcmUgcHJvdG9jb2wgaXMgSVAgY2FycnlpbmcgYW4gT0FNIHBhY2tl dC48YnI+DQomZ3Q7ICZndDsgR0lNJmd0OyZndDsgV2hlbiBJUC9VRFAgZW5jYXBzdWxhdGlvbiBp cyB1c2VkIGZvciBPQU0sIHRoZXJlJ3Mgbm8sIGluIG15IG9waW5pb24sIGFueSBuZWVkIHRvIHVz ZSB0aGUgTy1iaXQuIFRoZSBkZXN0aW5hdGlvbiBJUCBhZGRyZXNzIG11c3QgYmUgYXMgZGVzY3Jp YmVkIGluIFJGQyA4MDI5IG9yIFJGQyA1ODg0IGFuZCB0aGUgZGVtdWx0aXBsZXhpbmcgaXMgZG9u ZSBiYXNlZCBvbiB0aGUgZGVzdGluYXRpb24gVURQIHBvcnQgbnVtYmVyLiBDbGVhcmx5LA0KIE8t Yml0IGlzIHVubmVjZXNzYXJ5IGlmIElQL1VEUCBlbmNhcHN1bGF0aW9uIGZvciBPQU0gYmVpbmcg dXNlZC48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEZvcnR1bmF0ZWx5LCBi aXQgdXNhZ2UgaXMgYSBtYXR0ZXIgb2YgZGVmaW5pdGlvbiBhbmQgbm90IG9waW5pb24gOi0pPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IEtpbmQgcmVnYXJkcyw8YnI+DQomZ3Q7IDxicj4NCiZndDsgQ2Fy bG9zLjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBJIHN1Z2dlc3Qg bm90IHRvIHVzZSBPLWJpdCBpbiB0aGUgVlhMQU4tR1BFIGhlYWRlciBhbmQgcmVsZWFzZSBpdCBp bnRvIHRoZSBSZXNlcnZlZCBmaWVsZC4mbmJzcDsgSSBkb24ndCBzZWUgdGhlIGFwcGFyZW50IGJl bmVmaXQgb2YgdXNpbmcgdGhlIGZsYWcsIGFzIHRoZSBWWExBLUdQRSB1c2VzIHRoZSBmaXhlZCBz aXplIGhlYWRlciBhbmQgdGhlIGhlYWRlciBjYW5ub3QgY2FycnkgT0FNIGRhdGEgaW4gaXQuIFRo ZSBvbmx5IHJvbGUgdGhlIFZYTEFOLUdQRQ0KIGhlYWRlciBtdXN0IHBlcmZvcm0sIGluIG15IG9w aW5pb24sIGlzIHRvIHVuYW1iaWd1b3VzbHkgaWRlbnRpZnkgdGhlIHBheWxvYWQgdHlwZSB0aGF0 IGltbWVkaWF0ZWx5IGZvbGxvd3MgdGhlIGhlYWRlciBhcyBPQU0gKGRlbXVsdGlwbGV4aW5nIE9B TSBwcm90b2NvbHMgbWF5IGJlIGRvbmUgaW4gT0FNIEhlYWRlciBzaGltKS48YnI+DQomZ3Q7ICZn dDsgJmd0OyBNdWNoIGFwcHJlY2lhdGUgeW91ciBjb25zaWRlcmF0aW9uLjxicj4NCiZndDsgJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgQmVzdCw8YnI+DQomZ3Q7ICZn dDsgPGJyPg0KJmd0OyAmZ3Q7IOKAlDxicj4NCiZndDsgJmd0OyBDYXJsb3MgUGlnbmF0YXJvLCA8 YSBocmVmPSJtYWlsdG86Y2FybG9zQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNhcmxvc0Bj aXNjby5jb208L2E+PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyDigJxTb21ldGltZXMg SSB1c2UgYmlnIHdvcmRzIHRoYXQgSSBkbyBub3QgZnVsbHkgdW5kZXJzdGFuZCwgdG8gbWFrZSBt eXNlbGYgc291bmQgbW9yZSBwaG90b3N5bnRoZXNpcy4mcXVvdDs8YnI+DQomZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7ICZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7ICZndDsgJmd0OyBHcmVnPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7ICZndDsgJmd0OyBudm8zIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0 OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpudm8zQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bnZv M0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3NlY3Vy ZS13ZWIuY2lzY28uY29tLzFqLWpyNjR5aDJEOHlPOTJpYmNxYU4tSDk4WkNQM2xRZEhtc1lQc0g4 bGtqc2E0V2xKNGtnM1c0SEw4cVQyNXJDVml0dFQ1YkZRb3hfX09uU2tuVjV3X3dXNjlGdlVoWGt4 cXhLaGk5TUNpeTVvSC1KVHVjWE5fN0ZLODVxN2pELXFFd1JNNUlYWTY4X1ZmZWJfWEkyckt4eXp3 VnNHXzA2S1RHRjA5Qnc5b0hBT1hVTkZjZEN3X29vbl9lcnVVaFJQdGR3TGM5VVFOejJUaFlQOHlz ZjJwcjY0VlUwNFZqTUttR3dxWXZ6enlBc0xURWJIcnM3R1ZDcXBoVDU4VDBzdDc4Xzk2OHJNNU1L RkxrN0VpV0JqN2daUG1fckRlQmY2M2dVdHhrY2otdzhYeWJKaWlPMnRjRmFlb0FMXzhtLVpUNUw5 LTFWSzR3WmtIbVI1Q19MZGcvaHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJG bGlzdGluZm8lMkZudm8zIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3NlY3VyZS13ZWIuY2lz Y28uY29tLzFqLWpyNjR5aDJEOHlPOTJpYmNxYU4tSDk4WkNQM2xRZEhtc1lQc0g4bGtqc2E0V2xK NGtnM1c0SEw4cVQyNXJDVml0dFQ1YkZRb3hfX09uU2tuVjV3X3dXNjlGdlVoWGt4cXhLaGk5TUNp eTVvSC1KVHVjWE5fN0ZLODVxN2pELXFFd1JNNUlYWTY4X1ZmZWJfWEkyckt4eXp3VnNHXzA2S1RH RjA5Qnc5b0hBT1hVTkZjZEN3X29vbl9lcnVVaFJQdGR3TGM5VVFOejJUaFlQOHlzZjJwcjY0VlUw NFZqTUttR3dxWXZ6enlBc0xURWJIcnM3R1ZDcXBoVDU4VDBzdDc4Xzk2OHJNNU1LRkxrN0VpV0Jq N2daUG1fckRlQmY2M2dVdHhrY2otdzhYeWJKaWlPMnRjRmFlb0FMXzhtLVpUNUw5LTFWSzR3WmtI bVI1Q19MZGcvaHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8l MkZudm8zPC9hPjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IG52bzMgbWFp bGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86bnZvM0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPm52bzNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3Nl Y3VyZS13ZWIuY2lzY28uY29tLzFqLWpyNjR5aDJEOHlPOTJpYmNxYU4tSDk4WkNQM2xRZEhtc1lQ c0g4bGtqc2E0V2xKNGtnM1c0SEw4cVQyNXJDVml0dFQ1YkZRb3hfX09uU2tuVjV3X3dXNjlGdlVo WGt4cXhLaGk5TUNpeTVvSC1KVHVjWE5fN0ZLODVxN2pELXFFd1JNNUlYWTY4X1ZmZWJfWEkyckt4 eXp3VnNHXzA2S1RHRjA5Qnc5b0hBT1hVTkZjZEN3X29vbl9lcnVVaFJQdGR3TGM5VVFOejJUaFlQ OHlzZjJwcjY0VlUwNFZqTUttR3dxWXZ6enlBc0xURWJIcnM3R1ZDcXBoVDU4VDBzdDc4Xzk2OHJN NU1LRkxrN0VpV0JqN2daUG1fckRlQmY2M2dVdHhrY2otdzhYeWJKaWlPMnRjRmFlb0FMXzhtLVpU NUw5LTFWSzR3WmtIbVI1Q19MZGcvaHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFu JTJGbGlzdGluZm8lMkZudm8zIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3NlY3VyZS13ZWIu Y2lzY28uY29tLzFqLWpyNjR5aDJEOHlPOTJpYmNxYU4tSDk4WkNQM2xRZEhtc1lQc0g4bGtqc2E0 V2xKNGtnM1c0SEw4cVQyNXJDVml0dFQ1YkZRb3hfX09uU2tuVjV3X3dXNjlGdlVoWGt4cXhLaGk5 TUNpeTVvSC1KVHVjWE5fN0ZLODVxN2pELXFFd1JNNUlYWTY4X1ZmZWJfWEkyckt4eXp3VnNHXzA2 S1RHRjA5Qnc5b0hBT1hVTkZjZEN3X29vbl9lcnVVaFJQdGR3TGM5VVFOejJUaFlQOHlzZjJwcjY0 VlUwNFZqTUttR3dxWXZ6enlBc0xURWJIcnM3R1ZDcXBoVDU4VDBzdDc4Xzk2OHJNNU1LRkxrN0Vp V0JqN2daUG1fckRlQmY2M2dVdHhrY2otdzhYeWJKaWlPMnRjRmFlb0FMXzhtLVpUNUw5LTFWSzR3 WmtIbVI1Q19MZGcvaHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGlu Zm8lMkZudm8zPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5C94C61682BD49CEBB20A31F843E8806ciscocom_-- From nobody Fri Apr 19 11:59:16 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 107ED12032D for ; Fri, 19 Apr 2019 11:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 cvUzanO4h7kv for ; Fri, 19 Apr 2019 11:59:13 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D87C12031C for ; Fri, 19 Apr 2019 11:59:13 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id i14so6324361qtr.10 for ; Fri, 19 Apr 2019 11:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=LzurZCx/khB7fV+LgAHXDkT7SlTp+/uBMpX22rlBXiw=; b=hDOcyZTOQDgc67fw2iGQ+tW75l48oVEYy7Gm7ALoNjKYIpZr3vnofXp6FK7KIe3eu1 7wy6jrT4o7Wh1ZRTpvaakwBSYXlX3pVnmwG3ZkTizjbNGJjlgXMClE5uxq0Am0GBpvy3 NASp+FQMFEcny1OettmZKpgkgaVLP6TGBavijZ7LPfEXBc+9DgdLr2pwlvLEk5ssXOg6 rv6f01NHHtdRfHSmFWl2m29jz1rlNTgfTfIQODcDrertPwDNa/wzYi7rl6EcgHcl6c9d oXb0lckqtdFKYxXoG8ireqaWLxcDABoKUCAVN1suHLK7mmgdXjeC4C79zxrJEChtITts 29WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=LzurZCx/khB7fV+LgAHXDkT7SlTp+/uBMpX22rlBXiw=; b=eI5sTtGo5yKSyqS/F+Si7Yu9OZ2qaN4+eX8LaVUGiofhrdUxiRq9qE4qWrhyNWP8Jy 43XfIN/0bz8SU6yX5V89Ac7d04vCM+zt43MgAXRkHGDFq7p0M2e/05clziF3NnBoSaV+ yEeO258zWLKOEqjCl51XGLeco49aRjVcOv6VIFctLGjTNDnZgqxyV3izqL337NnWKbvd TC4XS+zGE8ki8KqjJjBi5zeDuEWYHUw934OJLN5/ildV4j6d7J74rC1gzk0umOFuSk7g uZ/mUG3wd9HaIHtxKGyzeel5momLEwA6+7hfFV8HhPerOflhAeClNYnj+bPLahUcuaRz VyNA== X-Gm-Message-State: APjAAAVjzOdU1sgBZli7cuvqwFkoEUMuFFDfXUh1suws/ClhqTH8zZTX g7oGCN0EUXiAqvJ3VTNLhWefLzuefXkGz+RFidR1Q9uFGT0= X-Google-Smtp-Source: APXvYqxqT2QlTYB6DMrCe+J7IDSCnk/+AaBl9myFXnFh2qE/CMipwi/TX75peMZs+vq0v7AAsdO19IfXEH54mmbTDk0= X-Received: by 2002:aed:2196:: with SMTP id l22mr4731192qtc.226.1555700351988; Fri, 19 Apr 2019 11:59:11 -0700 (PDT) MIME-Version: 1.0 From: Tom Herbert Date: Fri, 19 Apr 2019 11:59:00 -0700 Message-ID: To: IETF IPPM WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [ippm] Loopback bit in draft-brockners-inband-oam-data-05 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2019 18:59:15 -0000 Hello, As I understand it, when the loopback bit is set intermediate nodes "create a copy of the received packet and send the copy back to the source of the packet". And the "source address is used as the destination address of the copied packet". This begs a few questions: - Wouldn't the copied packet take on the attributes of the orginal packet, so the that the receiver of it thinks its getting a packet to process all the way of the stack. For instance, if the original packet is TCP, wouldn't it look like the copied packet is a TCP packet being sent to the original source? It seems like the copied packet should be wrapped in ICMP or something like that to ensure it's processed as a control message. - How many transit nodes are expected to send back copies of these packets? It seems like it could be considerable number which might be used in a DOS reflection attack. - Wouldn't the loopback bit force the packet into a slow path to do the work of copying and sending back packets. This doesn't seem all that different from cases where ICMP needs to be sent and some routers don't support that. - Also, it looks like IOAM is intended to be done on loopback packets in the return path. I'm not sure how much value there is in that. The returned packet wouldn't have the same characteristics of an actual packet in the flow being sent back from the real peer destination, and in fact the return path might be very different and not even hit the same routers. A possilble alternative (or addition) I might suggest is to reflect the IOAM option at the destination. So, for instance, if a destination node receives a packet for a flow that contains the IOAM option, it can attach the option on response packets back to the source as being reflected. Option reflection may be a common concept as Path MTU option (draft-hinden-6man-mtu-option-00) and FAST (draft-herbert-fast-04) do this. This only requires additional work at end points, and because data is piggybacked on real data packets there is no overhead of additional out of band packets. Tom From nobody Mon Apr 22 10:01:30 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BA012012B; Mon, 22 Apr 2019 10:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Q0KQKvFcom_n; Mon, 22 Apr 2019 10:01:22 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 261CA120091; Mon, 22 Apr 2019 10:01:21 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id u17so9480792lfi.3; Mon, 22 Apr 2019 10:01:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BLIga0CDyV82UjHE38lNX25FDO6tJry8uAI6TIM1qKQ=; b=Sb40+UXbPCmfQskOnwwjB2HT7S+2UhIyb8ztIBD3oTkjItwRkrmcFLTZoCkovOTW4g tu7tgodX25jMHHOIVTFggIy7G6p2LcpdaxBC/h0+JkQs7cJOU/wvthSOvdwIFZE7N3tt NcOfb9DX1U4f2OIBm5E6xjmrGdfZCTxihp3bxyirmaKM2pp87Sci0BxiwEJ5zYEEbjzq fztnShqIAhwasvH6vjRW+9Kx+2kt8S6YWtZe7QtxTt1yoQm1uD2y/4weJcwh2QbIW/nx /m91s2WSPe3XMrVSalNi3qlNU89YybE5OM8olimhMiplqwcqecW0Ejm0jSs6uYQPAUHV r8Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BLIga0CDyV82UjHE38lNX25FDO6tJry8uAI6TIM1qKQ=; b=M+yJomx3kyy1bu9yYdujJ1ZL0QPpWbU6pafQQgwy3h9tz2a2G8ZI0R84/d19u5zvmo AVusGVSamwGc80PGrElfkwpZYrT7Fbx1AhpsH+Df9X0g50LddoNzmXVqjPcgf+kurlxf bL7qV4gQff9vtFL+uqnBHGqUiWOgWtzEJnqDSFrpBjqZVWhoUE8cenoUUR9zfY0hOT1Y WNVUBzO9EZo1+WxwElwyyITxNqzgDwIwHGwkc8sxUP+bgIhF5FaaQmDd1ITNoA69R4TB 2gvEYJuTkNgNbZbvnD1zQUQ2ow16asJ0loCueidIFiwd42St+ZAeH8GGE/nPavrmx+oP S8Jw== X-Gm-Message-State: APjAAAV1Ycn9Nax3MGI9fBKF/KcSRE4+CEwNQs6pImxndJdighGR7Xql 88yJYp3wRSf1bnD2JwtkKqBTe3BGFZCy/xV2SrI= X-Google-Smtp-Source: APXvYqwYryDY1M9tPpN9aReXXt4JkpK5PKfIqDJd615Am3any5EkoSepw3qDTFnGkPTTFYWArE422opoS5pQrjrp7Ys= X-Received: by 2002:a19:7014:: with SMTP id h20mr11352184lfc.158.1555952479229; Mon, 22 Apr 2019 10:01:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Mon, 22 Apr 2019 10:01:07 -0700 Message-ID: To: Tal Mizrahi Cc: "Foote, Footer (Nokia - CA)" , guo.jun2@zte.com.cn, Henrik Nydell , IETF IPPM WG , IPPM Chairs Content-Type: multipart/mixed; boundary="000000000000d0001a0587216a08" Archived-At: Subject: Re: [ippm] Shepherd Review of draft-ietf-ippm-stamp-05 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 17:01:28 -0000 --000000000000d0001a0587216a08 Content-Type: multipart/alternative; boundary="000000000000d000180587216a06" --000000000000d000180587216a06 Content-Type: text/plain; charset="UTF-8" Hi Tal, please find the proposed updates in-lined and tagged GIM>>. Also, attached are the diff and the updated working version of the draft. Much appreciate your comments. Regards, Greg On Sun, Apr 14, 2019 at 10:54 PM Tal Mizrahi wrote: > Dear Authors, > > Having reviewed the document, I found that it is clear and > straightforward, and that it is almost ready to be submitted to the IESG, > with a few minor comments below. > > I will highly appreciate if you can post an updated draft, and afterwards > we will proceed with the publication process. > > Thanks, > Tal. > > > Comments: > > - Section 1: I would suggest to mention that TWAMP Light is a lightweight > architecture of a TWAMP deployment that is presented in RFC 5357. > GIM>> I've used the characterization of the TWAMP Light as provided in RFC 8545: OLD TEXT: One of such is Performance Measurement from IP Edge to Customer Equipment using TWAMP Light from Broadband Forum ([BBF.TR-390]). NEW TEXT: One of such is Performance Measurement from IP Edge to Customer Equipment using TWAMP Light from Broadband Forum [BBF.TR-390] used as the reference TWAMP Light that, according to [RFC8545], includes sub-set of TWAMP-Test functions in combination with other applications that provide, for example, control and security. - Section 2: > - The term OSS/BSS should be defined. > - The acronym SDN should be spelled out in its first appearance. > GIM>> I've added the explanation of what OSS/BSS does and removed the SDN acronym as it is the only place being used in the draft: OLD TEXT: Command Line Interface, OSS/BSS using SNMP or SDN using Netconf/YANG are but a few examples. NEW TEXT: Command Line Interface, OSS/BSS (operations support system/business support system as a combination of two systems used to support a range of telecommunication services) using SNMP or controllers in Software-Defined Networking using Netconf/YANG are but a few examples. - Section 4: > - "Unauthenticated STAMP test packets are compatible on the wire with > unauthenticated TWAMP-Test [RFC5357] packet formats." > Please explain what "compatible" means. The format defined in STAMP is > identical to RFC 5357? Can be configured to a specific mode in which it is > identical to RFC 5357? An RFC 5357 TWAMP node can interoperate with a STAMP > node? You may want to add a reference here to section 4.4. > GIM>> Thank you for the detailed questions and the recommendation. Please consider the update below: OLD TEXT: Unauthenticated STAMP test packets are compatible on the wire with unauthenticated TWAMP-Test [RFC5357] packet formats. NEW TEXT: Unauthenticated STAMP test packets, defined in Section 4.1.1 and Section 4.2.1, ensure interworking between STAMP and TWAMP Light as described in Section 4.4. packet formats. - Section 4.1.1.: > - Please clarify that the timestamp field is as specified in RFC 5357 and > RFC 8186. > GIM>> I've added references to RFC 5357 and RFC 8186 as follows: OLD TEXT: o Timestamp is eight octets long field. STAMP node MUST support Network Time Protocol (NTP) version 4 64-bit timestamp format [RFC5905]. STAMP node MAY support IEEE 1588v2 Precision Time Protocol truncated 64-bit timestamp format [IEEE.1588.2008]. NEW TEXT: o Timestamp is eight octets long field. STAMP node MUST support Network Time Protocol (NTP) version 4 64-bit timestamp format [RFC5905], the format used in [RFC5357]. STAMP node MAY support IEEE 1588v2 Precision Time Protocol truncated 64-bit timestamp format [IEEE.1588.2008], the format used in [RFC8186]. - "The Reflect Octets capability defined in [RFC6038]." ==> "This field is > used for the Reflect Octets capability defined in [RFC6038]." > GIM>> Thank you for the helpful suggestion. Done. - Section 4.1.2. + 4.2.2. + 4.3: > - Please clarify that the HMAC field is as defined in RFC 5357, and covers > the same fields as defined in RFC 5357. > GIM>> Hashed Message Authentication Code is defined in RFC 2104. Unlike OWAMP or TWAMP that use HMAC-SHA-1, in STAMP we use HMAC-SHA-256. And in STAMP HMAC also protects optional extensions. I hope that the addition of the forward reference to Section 4.3 in 4.1.2 and 4.2.2 is acceptable. > - Section 4.2.1.: > - "the TTL field" ==> "the TTL field in IPv4 (or Hop Limit in IPv6)" > GIM>> Thank you. Accepted and done. > - Section 4.3: > - "If confidentiality protection for STAMP is required, encryption at the > higher level MUST be used." > Please elaborate, preferably with an example. IPsec is at a lower layer > than STAMP, so not sure "higher level" is clear to the reader. > GIM>> STAMP can be sent over its IPsec tunnel or share the IPsec tunnel of the flow which performance is monitored. Please consider this update: OLD TEXT: If confidentiality protection for STAMP is required, encryption at the higher level MUST be used. NEW TEXT: If confidentiality protection for STAMP is required, encryption at the higher level MUST be used. For example, STAMP packets could be transmitted in the dedicated IPsec tunnel or share the IPsec tunnel with the monitored flow. - Section 5: > - This section should be more detailed. You may want to say that the > general security considerations of TWAMP are discussed in RFC 5357. You may > also want to explain that the main difference between STAMP and TWAMP is > the control plane, and you may want to make note that STAMP configuration > procedures should be secured in order to mitigate attacks at the control > plane. > GIM>> Yes, agree. The Security Considerations section is a bit terse. Here's the updated text: 6. Security Considerations In general, all the security considerations related to TWAMP-Test, discussed in [RFC5357]apply to STAMP. Since STAMP uses the well- known UDP port number allocated for the OWAMP-Test/TWAMP-Test Receiver port, the security considerations and measures to mitigate the risk of the attack using the registered port number documented in Section 6 [RFC8545] equally apply to STAMP. Because the control and management of a STAMP test are outside the scope of this specification only the more general requirement is set: To mitigate the possible attack vector, the control and management of a STAMP test session MUST use the secured transport. Use of HMAC-SHA-256 in the authenticated mode protects the data integrity of the STAMP test packets. - References: > - I suggest to move "[BBF.TR-390]" to the informative references. > GIM>> Agreed and done. > - draft-ietf-ippm-port-twamp-test ==> RFC 8545. > GIM>> Done > - Minor nit: > - "less the length" ==> "minus the length" > GIM>> Thank you. Done. --000000000000d000180587216a06 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tal,
please find the proposed updates in-lined and tagg= ed GIM>>. Also, attached are the diff and the updated working version= of the draft.
Much appreciate your comments.

Regards,
Greg

On Sun, Apr 14, 2019 at 10:54 PM Tal Miz= rahi <tal= .mizrahi.phd@gmail.com> wrote:
Dear Authors,
<= br>
Having reviewed the document, I found that it is clear and st= raightforward, and that it is almost ready to be submitted to the IESG, wit= h a few minor comments below.

I will highly apprec= iate if you can post an updated draft, and afterwards we will proceed with = the publication process.

Thanks,
Tal= .


Comments:

- Section 1: I would suggest to mention that TWAMP Light is a lightw= eight architecture of a TWAMP deployment that is presented in RFC 5357.
GIM>> I've used the charact= erization of the TWAMP Light as provided in RFC 8545:=C2=A0
OLD T= EXT:
=C2=A0 =C2=A0One of such is Performance=C2=A0Measurement fro= m IP Edge to Customer Equipment using TWAMP Light from
=C2=A0 =C2= =A0Broadband Forum ([BBF.TR-390]).
NEW TEXT:
=C2=A0 =C2= =A0One of such is Performance Measurement from IP Edge to Customer Equipmen= t using TWAMP Light from
=C2=A0 =C2=A0Broadband Forum [BBF.TR-390= ] used as the reference TWAMP Light that, according to [RFC8545], includes<= /div>
=C2=A0 =C2=A0sub-set of TWAMP-Test functions in combination with = other applications that provide, for example, control
=C2=A0 =C2= =A0and security.

- Section 2:
<= div> - The term OSS/BSS should = be defined.
- The ac= ronym SDN should be spelled out in its first appearance.
<= /div>
GIM>> I've added the explanation of what O= SS/BSS does and removed the SDN acronym as it is the only place being used = in the draft:=C2=A0
OLD TEXT:
=C2=A0 =C2=A0Command Line= Interface, OSS/BSS using SNMP or
=C2=A0 =C2=A0SDN using Netconf/= YANG are but a few examples.
NEW TEXT:
=C2=A0 =C2=A0Com= mand Line Interface, OSS/BSS (operations support
=C2=A0 =C2=A0sys= tem/business support system as a combination of two
=C2=A0 =C2=A0= systems used to support a range of telecommunication
=C2=A0 =C2= =A0services) using SNMP or controllers in Software-Defined
=C2=A0= =C2=A0Networking using Netconf/YANG are but a few examples.
=
- Section 4:=C2=A0
- "Unauthenticated STAMP test packets are = compatible on the wire with unauthenticated TWAMP-Test [RFC5357] packet for= mats."
=C2=A0 P= lease explain what "compatible" means. The format defined in STAM= P is identical to RFC 5357? Can be configured to a specific mode in which i= t is identical to RFC 5357? An RFC 5357 TWAMP node can interoperate with a = STAMP node? You may want to add a reference here to section 4.4.
GIM>> Thank you for the detailed quest= ions and the recommendation. Please consider the update below:=C2=A0
<= div>OLD TEXT:
=C2=A0 =C2=A0Unauthenticated STAMP test
= =C2=A0 =C2=A0packets are compatible on the wire with unauthenticated TWAMP-= Test
=C2=A0 =C2=A0[RFC5357] packet formats.=C2=A0
NEW T= EXT:
=C2=A0 =C2=A0Unauthenticated STAMP test
=C2= =A0 =C2=A0packets, defined in Section 4.1.1 and Section 4.2.1, ensure
=
=C2=A0 =C2=A0interworking between STAMP and TWAMP Light as described i= n
=C2=A0 =C2=A0Section 4.4.=C2=A0 packet formats.

- Section 4.1.1.:
- Please clarify that the timestamp field is as specified in RFC 5357 and = RFC 8186.
GIM>> I've add= ed references to RFC 5357 and RFC 8186 as follows:
OLD TEXT:
=C2=A0 =C2=A0o=C2=A0 Timestamp is eight octets long field.=C2=A0 STAM= P node MUST support
=C2=A0 =C2=A0 =C2=A0 Network Time Protocol (N= TP) version 4 64-bit timestamp format
=C2=A0 =C2=A0 =C2=A0 [RFC59= 05].=C2=A0 STAMP node MAY support IEEE 1588v2 Precision Time
=C2= =A0 =C2=A0 =C2=A0 Protocol truncated 64-bit timestamp format [IEEE.1588.200= 8].
NEW TEXT:
=C2=A0 =C2=A0 o=C2=A0 Timestamp is eight = octets long field.=C2=A0 STAMP node MUST support
=C2=A0 =C2=A0 = =C2=A0 Network Time Protocol (NTP) version 4 64-bit timestamp format
<= div>=C2=A0 =C2=A0 =C2=A0 [RFC5905], the format used in [RFC5357].=C2=A0 STA= MP node MAY support
=C2=A0 =C2=A0 =C2=A0 IEEE 1588v2 Precision Ti= me Protocol truncated 64-bit timestamp
=C2=A0 =C2=A0 =C2=A0 forma= t [IEEE.1588.2008], the format used in [RFC8186].

- "The Refl= ect Octets capability defined in [RFC6038]." =3D=3D> "This fie= ld is used for the Reflect Octets capability defined in [RFC6038]."
GIM>> Thank you for the helpfu= l suggestion. Done.=C2=A0

- Section = 4.1.2. + 4.2.2. + 4.3:
- Please clarify that the HMAC field is as defined in RFC 5357, and cove= rs the same fields as defined in RFC 5357.
GIM>>=C2=A0Hashed Message Authentication Code is defined in = RFC 2104. Unlike OWAMP or TWAMP that use HMAC-SHA-1, in STAMP we use HMAC-S= HA-256. And in STAMP HMAC also protects optional extensions. I hope that th= e addition of the forward reference to Section 4.3 in 4.1.2 and 4.2.2 is ac= ceptable.
- Section 4.2.1.:
= - "the TTL field" =3D=3D> "the TTL field in IPv4 (= or Hop Limit in IPv6)"
GIM>= ;> Thank you. Accepted and done.=C2=A0
- Section= 4.3:=C2=A0
- "= If confidentiality protection for STAMP is required, encryption at the high= er level MUST be used."
=C2=A0 Please elaborate, preferably with an example. IPsec is at a= lower layer than STAMP, so not sure "higher level" is clear to t= he reader.
GIM>> STAMP can b= e sent over its IPsec tunnel or share the IPsec tunnel of the flow which pe= rformance is monitored. Please consider this update:
OLD TEXT:
=C2=A0 =C2=A0If confidentiality protection for STAMP is requir= ed, encryption at
=C2=A0 =C2=A0the higher level MUST be used.
NEW TEXT:
=C2=A0 =C2=A0If confidentiality prote= ction for STAMP is required, encryption at
=C2=A0 =C2=A0the highe= r level MUST be used.=C2=A0 For example, STAMP packets could be
= =C2=A0 =C2=A0transmitted in the dedicated IPsec tunnel or share the IPsec t= unnel
=C2=A0 =C2=A0with the monitored flow.

<= /div>
- Section 5:
- This section should be more detailed. You may want to sa= y that the general security considerations of TWAMP are discussed in RFC 53= 57. You may also want to explain that the main difference between STAMP and= TWAMP is the control plane, and you may want to make note that STAMP confi= guration procedures should be secured in order to mitigate attacks at the c= ontrol plane.
GIM>> Yes, agr= ee. The Security Considerations section is a bit terse. Here's the upda= ted text:
=C2=A06.=C2=A0 Security Considerations

=C2=A0 =C2=A0In general, all the security considerations related t= o TWAMP-Test,
=C2=A0 =C2=A0discussed in [RFC5357]apply to STAMP.= =C2=A0 Since STAMP uses the well-
=C2=A0 =C2=A0known UDP port num= ber allocated for the OWAMP-Test/TWAMP-Test
=C2=A0 =C2=A0Receiver= port, the security considerations and measures to mitigate
=C2= =A0 =C2=A0the risk of the attack using the registered port number documente= d in
=C2=A0 =C2=A0Section 6 [RFC8545] equally apply to STAMP.=C2= =A0 Because the control and
=C2=A0 =C2=A0management of a STAMP te= st are outside the scope of this
=C2=A0 =C2=A0specification only = the more general requirement is set:

=C2=A0 =C2=A0= =C2=A0 To mitigate the possible attack vector, the control and management<= /div>
=C2=A0 =C2=A0 =C2=A0 of a STAMP test session MUST use the secured= transport.

=C2=A0 =C2=A0Use of HMAC-SHA-256 in th= e authenticated mode protects the data
=C2=A0 =C2=A0integrity of = the STAMP test packets.

- References= :
- I suggest to mov= e "[BBF.TR-390]" to the informative references.
=
GIM>> Agreed and done.=C2=A0
- draft-ietf-ippm-port= -twamp-test =3D=3D> RFC 8545.
G= IM>> Done=C2=A0
- Minor nit:
- "less the length" =3D=3D= > "minus the length"
= GIM>> Thank you. Done.=C2=A0
--000000000000d000180587216a06-- --000000000000d0001a0587216a08 Content-Type: text/plain; charset="US-ASCII"; name="draft-ietf-ippm-stamp-06.txt" Content-Disposition: attachment; filename="draft-ietf-ippm-stamp-06.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_juslwkr41 CgoKCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEcuIE1pcnNreQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBaVEUgQ29ycC4KSW50ZW5kZWQgc3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRy4gSnVuCkV4cGly ZXM6IE9jdG9iZXIgMjQsIDIwMTkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFpURSBD b3Jwb3JhdGlvbgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBILiBOeWRlbGwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEFjY2VkaWFuIE5ldHdvcmtzCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSLiBGb290 ZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgTm9raWEKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEFwcmlsIDIyLCAyMDE5CgoKICAgICAgICAgICAgICAgU2ltcGxl IFR3by13YXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29sCiAgICAgICAgICAgICAgICAgICAg ICAgIGRyYWZ0LWlldGYtaXBwbS1zdGFtcC0wNgoKQWJzdHJhY3QKCiAgIFRoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIGEgU2ltcGxlIFR3by13YXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29sCiAg IHdoaWNoIGVuYWJsZXMgdGhlIG1lYXN1cmVtZW50IG9mIGJvdGggb25lLXdheSBhbmQgcm91bmQt dHJpcAogICBwZXJmb3JtYW5jZSBtZXRyaWNzIGxpa2UgZGVsYXksIGRlbGF5IHZhcmlhdGlvbiwg YW5kIHBhY2tldCBsb3NzLgoKU3RhdHVzIG9mIFRoaXMgTWVtbwoKICAgVGhpcyBJbnRlcm5ldC1E cmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQogICBwcm92aXNp b25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5n IGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAoSUVU RikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUKICAgd29ya2lu ZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRl cm5ldC0KICAgRHJhZnRzIGlzIGF0IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRz L2N1cnJlbnQvLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQg Zm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFj ZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55CiAgIHRpbWUuICBJdCBp cyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1h dGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIK CiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gT2N0b2JlciAyNCwgMjAxOS4K CkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoYykgMjAxOSBJRVRGIFRydXN0IGFuZCB0 aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJp Z2h0cyByZXNlcnZlZC4KCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5k IHRoZSBJRVRGIFRydXN0J3MgTGVnYWwKICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERv Y3VtZW50cwogICAoaHR0cHM6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZm ZWN0IG9uIHRoZSBkYXRlIG9mCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVh c2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cwogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUg eW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QKICAgdG8gdGhpcyBkb2N1 bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QK CgoKTWlyc2t5LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDI0LCAyMDE5ICAgICAg ICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIFNU QU1QICAgICAgICAgICAgICAgICAgICAgICBBcHJpbCAyMDE5CgoKICAgaW5jbHVkZSBTaW1wbGlm aWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mCiAgIHRo ZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50 eSBhcwogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuCgpUYWJsZSBv ZiBDb250ZW50cwoKICAgMS4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAyCiAgIDIuICBDb252ZW50aW9ucyB1c2VkIGluIHRo aXMgZG9jdW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMwogICAgIDIuMS4gIFRl cm1pbm9sb2d5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg IDMKICAgICAyLjIuICBSZXF1aXJlbWVudHMgTGFuZ3VhZ2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gICAzCiAgIDMuICBTb2Z0d2FyaXphdGlvbiBvZiBQZXJmb3JtYW5jZSBN ZWFzdXJlbWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMwogICA0LiAgVGhlb3J5IG9mIE9wZXJh dGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQKICAgICA0 LjEuICBTZXNzaW9uLVNlbmRlciBCZWhhdmlvciBhbmQgUGFja2V0IEZvcm1hdCAuIC4gLiAuIC4g LiAuIC4gICA0CiAgICAgICA0LjEuMS4gIFNlc3Npb24tU2VuZGVyIFBhY2tldCBGb3JtYXQgaW4g VW5hdXRoZW50aWNhdGVkIE1vZGUgICAgNAogICAgICAgNC4xLjIuICBTZXNzaW9uLVNlbmRlciBQ YWNrZXQgRm9ybWF0IGluIEF1dGhlbnRpY2F0ZWQgTW9kZSAgLiAgIDcKICAgICA0LjIuICBTZXNz aW9uLVJlZmxlY3RvciBCZWhhdmlvciBhbmQgUGFja2V0IEZvcm1hdCAgLiAuIC4gLiAuIC4gICA4 CiAgICAgICA0LjIuMS4gIFNlc3Npb24tUmVmbGVjdG9yIFBhY2tldCBGb3JtYXQgaW4gVW5hdXRo ZW50aWNhdGVkCiAgICAgICAgICAgICAgIE1vZGUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOAogICAgICAgNC4yLjIuICBTZXNzaW9uLVJlZmxlY3Rv ciBQYWNrZXQgRm9ybWF0IGluIEF1dGhlbnRpY2F0ZWQgTW9kZSAgMTAKICAgICA0LjMuICBJbnRl Z3JpdHkgYW5kIENvbmZpZGVudGlhbGl0eSBQcm90ZWN0aW9uIGluIFNUQU1QIC4gLiAuIC4gIDEy CiAgICAgNC40LiAgSW50ZXJvcGVyYWJpbGl0eSB3aXRoIFRXQU1QIExpZ2h0IC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAxMgogICA1LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTMKICAgNi4gIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEzCiAgIDcuICBB Y2tub3dsZWRnbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAxMwogICA4LiAgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgMTMKICAgICA4LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEzCiAgICAgOC4yLiAgSW5mb3Jt YXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNAog ICBBdXRob3JzJyBBZGRyZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgMTUKCjEuICBJbnRyb2R1Y3Rpb24KCiAgIERldmVsb3BtZW50IGFuZCBkZXBs b3ltZW50IG9mIFR3by1XYXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29sCiAgIChUV0FNUCkg W1JGQzUzNTddIGFuZCBpdHMgZXh0ZW5zaW9ucywgZS5nLiwgW1JGQzYwMzhdIHRoYXQgZGVmaW5l ZAogICBmZWF0dXJlcyBzdWNoIGFzIFJlZmxlY3QgT2N0ZXRzIGFuZCBTeW1tZXRyaWNhbCBTaXpl IGZvciBUV0FNUAogICBwcm92aWRlZCBpbnZhbHVhYmxlIGV4cGVyaWVuY2UuICBTZXZlcmFsIGlu ZGVwZW5kZW50IGltcGxlbWVudGF0aW9ucwogICBleGlzdCwgaGF2ZSBiZWVuIGRlcGxveWVkIGFu ZCBwcm92aWRlIGltcG9ydGFudCBvcGVyYXRpb25hbAogICBwZXJmb3JtYW5jZSBtZWFzdXJlbWVu dHMuICBBdCB0aGUgc2FtZSB0aW1lLCB0aGVyZSBoYXMgYmVlbgogICBub3RpY2VhYmxlIGludGVy ZXN0IGluIHVzaW5nIGEgc2ltcGxlciBtZWNoYW5pc20gZm9yIGFjdGl2ZQogICBwZXJmb3JtYW5j ZSBtb25pdG9yaW5nIHRoYXQgY2FuIHByb3ZpZGUgZGV0ZXJtaW5pc3RpYyBiZWhhdmlvciBhbmQK ICAgaW5oZXJpdCBzZXBhcmF0aW9uIG9mIGNvbnRyb2wgKHZlbmRvci1zcGVjaWZpYyBjb25maWd1 cmF0aW9uIG9yCiAgIG9yY2hlc3RyYXRpb24pIGFuZCB0ZXN0IGZ1bmN0aW9ucy4gIE9uZSBvZiBz dWNoIGlzIFBlcmZvcm1hbmNlCiAgIE1lYXN1cmVtZW50IGZyb20gSVAgRWRnZSB0byBDdXN0b21l ciBFcXVpcG1lbnQgdXNpbmcgVFdBTVAgTGlnaHQgZnJvbQogICBCcm9hZGJhbmQgRm9ydW0gW0JC Ri5UUi0zOTBdIHVzZWQgYXMgdGhlIHJlZmVyZW5jZSBUV0FNUCBMaWdodCB0aGF0LAogICBhY2Nv cmRpbmcgdG8gW1JGQzg1NDVdLCBpbmNsdWRlcyBzdWItc2V0IG9mIFRXQU1QLVRlc3QgZnVuY3Rp b25zIGluCiAgIGNvbWJpbmF0aW9uIHdpdGggb3RoZXIgYXBwbGljYXRpb25zIHRoYXQgcHJvdmlk ZSwgZm9yIGV4YW1wbGUsCiAgIGNvbnRyb2wgYW5kIHNlY3VyaXR5LiAgVGhpcyBkb2N1bWVudCBk ZWZpbmVzIGFjdGl2ZSBwZXJmb3JtYW5jZQogICBtZWFzdXJlbWVudCB0ZXN0IHByb3RvY29sLCBT aW1wbGUgVHdvLXdheSBBY3RpdmUgTWVhc3VyZW1lbnQgUHJvdG9jb2wKCgoKCk1pcnNreSwgZXQg YWwuICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyNCwgMjAxOSAgICAgICAgICAgICAgICBbUGFn ZSAyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBTVEFNUCAgICAgICAgICAg ICAgICAgICAgICAgQXByaWwgMjAxOQoKCiAgIChTVEFNUCksIHRoYXQgZW5hYmxlcyBtZWFzdXJl bWVudCBvZiBib3RoIG9uZS13YXkgYW5kIHJvdW5kLXRyaXAKICAgcGVyZm9ybWFuY2UgbWV0cmlj cyBsaWtlIGRlbGF5LCBkZWxheSB2YXJpYXRpb24sIGFuZCBwYWNrZXQgbG9zcy4KCjIuICBDb252 ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9jdW1lbnQKCjIuMS4gIFRlcm1pbm9sb2d5CgogICBBRVMg QWR2YW5jZWQgRW5jcnlwdGlvbiBTdGFuZGFyZAoKICAgQ0JDIENpcGhlciBCbG9jayBDaGFpbmlu ZwoKICAgRUNCIEVsZWN0cm9uaWMgQ29va2Jvb2sKCiAgIEtFSyBLZXktZW5jcnlwdGlvbiBLZXkK CiAgIFNUQU1QIC0gU2ltcGxlIFR3by13YXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29sCgog ICBOVFAgLSBOZXR3b3JrIFRpbWUgUHJvdG9jb2wKCiAgIFBUUCAtIFByZWNpc2lvbiBUaW1lIFBy b3RvY29sCgogICBITUFDIEhhc2hlZCBNZXNzYWdlIEF1dGhlbnRpY2F0aW9uIENvZGUKCiAgIE9X QU1QIE9uZS1XYXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29sCgogICBUV0FNUCBUd28tV2F5 IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbAoKMi4yLiAgUmVxdWlyZW1lbnRzIExhbmd1YWdl CgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxM IiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIs ICJOT1QgUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kCiAgICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1 bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIEJDUAogICAxNCBbUkZD MjExOV0gW1JGQzgxNzRdIHdoZW4sIGFuZCBvbmx5IHdoZW4sIHRoZXkgYXBwZWFyIGluIGFsbAog ICBjYXBpdGFscywgYXMgc2hvd24gaGVyZS4KCjMuICBTb2Z0d2FyaXphdGlvbiBvZiBQZXJmb3Jt YW5jZSBNZWFzdXJlbWVudAoKICAgRmlndXJlIDEgcHJlc2VudHMgU2ltcGxlIFR3by13YXkgQWN0 aXZlIE1lYXN1cmVtZW50IFByb3RvY29sIChTVEFNUCkKICAgU2Vzc2lvbi1TZW5kZXIgYW5kIFNl c3Npb24tUmVmbGVjdG9yIHdpdGggYSBtZWFzdXJlbWVudCBzZXNzaW9uLiAgVGhlCiAgIGNvbmZp Z3VyYXRpb24gYW5kIG1hbmFnZW1lbnQgb2YgdGhlIFNUQU1QIFNlc3Npb24tU2VuZGVyLCBTZXNz aW9uLQogICBSZWZsZWN0b3IgYW5kIG1hbmFnZW1lbnQgb2YgdGhlIFNUQU1QIHNlc3Npb25zIGNh biBiZSBhY2hpZXZlZAogICB0aHJvdWdoIHZhcmlvdXMgbWVhbnMuICBDb21tYW5kIExpbmUgSW50 ZXJmYWNlLCBPU1MvQlNTIChvcGVyYXRpb25zCiAgIHN1cHBvcnQgc3lzdGVtL2J1c2luZXNzIHN1 cHBvcnQgc3lzdGVtIGFzIGEgY29tYmluYXRpb24gb2YgdHdvCiAgIHN5c3RlbXMgdXNlZCB0byBz dXBwb3J0IGEgcmFuZ2Ugb2YgdGVsZWNvbW11bmljYXRpb24gc2VydmljZXMpIHVzaW5nCiAgIFNO TVAgb3IgY29udHJvbGxlcnMgaW4gU29mdHdhcmUtRGVmaW5lZCBOZXR3b3JraW5nIHVzaW5nIE5l dGNvbmYvWUFORwogICBhcmUgYnV0IGEgZmV3IGV4YW1wbGVzLgoKCgoKCk1pcnNreSwgZXQgYWwu ICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyNCwgMjAxOSAgICAgICAgICAgICAgICBbUGFnZSAz XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBTVEFNUCAgICAgICAgICAgICAg ICAgICAgICAgQXByaWwgMjAxOQoKCiAgICAgICAgIG8tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tbwogICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgIENvbmZpZ3VyYXRpb24gYW5kICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICBNYW5hZ2VtZW50ICAgICAgICAgICAgICAgICAgICAg ICB8CiAgICAgICAgIG8tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tbwogICAgICAgICAgICAgICAgfHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8fAogICAgICAgICAgICAgICAgfHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8fAogICAgICAgICAgICAgICAgfHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8fAogICAgICstLS0tLS0tLS0tLS0tLS0t LS0tLS0tKyAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICB8 IFNUQU1QIFNlc3Npb24tU2VuZGVyIHwgPC0tLSBTVEFNUC0tLT4gfCBTVEFNUCBTZXNzaW9uLVJl ZmxlY3RvciB8CiAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKwoKCiAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUg MTogU1RBTVAgUmVmZXJlbmNlIE1vZGVsCgo0LiAgVGhlb3J5IG9mIE9wZXJhdGlvbgoKICAgU1RB TVAgU2Vzc2lvbi1TZW5kZXIgdHJhbnNtaXRzIHRlc3QgcGFja2V0cyB0b3dhcmQgU1RBTVAgU2Vz c2lvbi0KICAgUmVmbGVjdG9yLiAgU1RBTVAgU2Vzc2lvbi1SZWZsZWN0b3IgcmVjZWl2ZXMgU2Vz c2lvbi1TZW5kZXIncyBwYWNrZXQKICAgYW5kIGFjdHMgYWNjb3JkaW5nIHRvIHRoZSBjb25maWd1 cmF0aW9uIGFuZCBvcHRpb25hbCBjb250cm9sCiAgIGluZm9ybWF0aW9uIGNvbW11bmljYXRlZCBp biB0aGUgU2Vzc2lvbi1TZW5kZXIncyB0ZXN0IHBhY2tldC4gIFNUQU1QCiAgIGRlZmluZXMgdHdv IGRpZmZlcmVudCB0ZXN0IHBhY2tldCBmb3JtYXRzLCBvbmUgZm9yIHBhY2tldHMKICAgdHJhbnNt aXR0ZWQgYnkgdGhlIFNUQU1QLVNlc3Npb24tU2VuZGVyIGFuZCBvbmUgZm9yIHBhY2tldHMKICAg dHJhbnNtaXR0ZWQgYnkgdGhlIFNUQU1QLVNlc3Npb24tUmVmbGVjdG9yLiAgU1RBTVAgc3VwcG9y dHMgdHdvCiAgIG1vZGVzOiB1bmF1dGhlbnRpY2F0ZWQgYW5kIGF1dGhlbnRpY2F0ZWQuICBVbmF1 dGhlbnRpY2F0ZWQgU1RBTVAgdGVzdAogICBwYWNrZXRzLCBkZWZpbmVkIGluIFNlY3Rpb24gNC4x LjEgYW5kIFNlY3Rpb24gNC4yLjEsIGVuc3VyZQogICBpbnRlcndvcmtpbmcgYmV0d2VlbiBTVEFN UCBhbmQgVFdBTVAgTGlnaHQgYXMgZGVzY3JpYmVkIGluCiAgIFNlY3Rpb24gNC40LiAgcGFja2V0 IGZvcm1hdHMuCgogICBCeSBkZWZhdWx0LCBTVEFNUCB1c2VzIHN5bW1ldHJpY2FsIHBhY2tldHMs IGkuZS4sIHNpemUgb2YgdGhlIHBhY2tldAogICB0cmFuc21pdHRlZCBieSBTZXNzaW9uLVJlZmxl Y3RvciBlcXVhbHMgdGhlIHNpemUgb2YgdGhlIHBhY2tldAogICByZWNlaXZlZCBieSB0aGUgU2Vz c2lvbi1SZWZsZWN0b3IuCgo0LjEuICBTZXNzaW9uLVNlbmRlciBCZWhhdmlvciBhbmQgUGFja2V0 IEZvcm1hdAoKNC4xLjEuICBTZXNzaW9uLVNlbmRlciBQYWNrZXQgRm9ybWF0IGluIFVuYXV0aGVu dGljYXRlZCBNb2RlCgogICBCZWNhdXNlIFNUQU1QIHN1cHBvcnRzIHN5bW1ldHJpY2FsIHRlc3Qg cGFja2V0cywgU1RBTVAgU2Vzc2lvbi1TZW5kZXIKICAgcGFja2V0IGhhcyBhIG1pbmltdW0gc2l6 ZSBvZiA0NCBvY3RldHMgaW4gdW5hdXRoZW50aWNhdGVkIG1vZGUsIHNlZQogICBGaWd1cmUgMiwg YW5kIDQ4IG9jdGV0cyBpbiB0aGUgYXV0aGVudGljYXRlZCBtb2RlLCBzZWUgRmlndXJlIDQuCgog ICBGb3IgdW5hdXRoZW50aWNhdGVkIG1vZGU6CgoKCgoKCgoKCgpNaXJza3ksIGV0IGFsLiAgICAg ICAgICBFeHBpcmVzIE9jdG9iZXIgMjQsIDIwMTkgICAgICAgICAgICAgICAgW1BhZ2UgNF0KDApJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgU1RBTVAgICAgICAgICAgICAgICAgICAg ICAgIEFwcmlsIDIwMTkKCgogICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAg ICAgICAgIDIgICAgICAgICAgICAgICAgICAgMwogICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r CiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBTZXF1ZW5jZSBOdW1iZXIgICAgICAgICAg ICAgICAgICAgICAgICB8CiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgIFRpbWVzdGFtcCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8CiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rCiAgICAgIHwgICAgICAgICBFcnJvciBFc3RpbWF0ZSAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArCiAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8CiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8CiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgTUJa ICgyNyBvY3RldHMpICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8CiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICsgICAgICAgICAgICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgIHwgICAgICAgICAg ICAgICB8ICAgICAgICAgIFNlcnZlciBPY3RldHMgICAgICAgIHwgICAgICAgICAgICAgICB8CiAg ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgICAg ICAgICAgICAgICArCiAgICAgIHwgICAgICAgICAgIFJlbWFpbmluZyBQYWNrZXQgUGFkZGluZyAo dG8gYmUgcmVmbGVjdGVkKSAgICAgICAgICB8CiAgICAgIH4gICAgICAgICAgKGxlbmd0aCBpbiBv Y3RldHMgc3BlY2lmaWVkIGluIFNlcnZlciBPY3RldHMpICAgICAgICB+CiAgICAgICsgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstKy0rLSstKy0rLSstKy0r CiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgQ29tcC5NQlogICB8CiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgIHwgICAgICAgICAgICAgVHlwZSAg ICAgICAgICAgICAgfCAgICAgICAgICAgTGVuZ3RoICAgICAgICAgICAgICB8CiAgICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rCiAgICAgIH4gICAgICAgICAgICAgICAgICAgICAgICAgICAgVmFsdWUgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB+CiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCgogICBGaWd1cmUgMjogU1RBTVAgU2Vz c2lvbi1TZW5kZXIgdGVzdCBwYWNrZXQgZm9ybWF0IGluIHVuYXV0aGVudGljYXRlZAogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vZGUKCiAgIHdoZXJlIGZpZWxkcyBhcmUgZGVm aW5lZCBhcyB0aGUgZm9sbG93aW5nOgoKICAgbyAgU2VxdWVuY2UgTnVtYmVyIGlzIGZvdXIgb2N0 ZXRzIGxvbmcgZmllbGQuICBGb3IgZWFjaCBuZXcgc2Vzc2lvbgogICAgICBpdHMgdmFsdWUgc3Rh cnRzIGF0IHplcm8gYW5kIGlzIGluY3JlbWVudGVkIHdpdGggZWFjaCB0cmFuc21pdHRlZAogICAg ICBwYWNrZXQuCgogICBvICBUaW1lc3RhbXAgaXMgZWlnaHQgb2N0ZXRzIGxvbmcgZmllbGQuICBT VEFNUCBub2RlIE1VU1Qgc3VwcG9ydAogICAgICBOZXR3b3JrIFRpbWUgUHJvdG9jb2wgKE5UUCkg dmVyc2lvbiA0IDY0LWJpdCB0aW1lc3RhbXAgZm9ybWF0CiAgICAgIFtSRkM1OTA1XSwgdGhlIGZv cm1hdCB1c2VkIGluIFtSRkM1MzU3XS4gIFNUQU1QIG5vZGUgTUFZIHN1cHBvcnQKICAgICAgSUVF RSAxNTg4djIgUHJlY2lzaW9uIFRpbWUgUHJvdG9jb2wgdHJ1bmNhdGVkIDY0LWJpdCB0aW1lc3Rh bXAKICAgICAgZm9ybWF0IFtJRUVFLjE1ODguMjAwOF0sIHRoZSBmb3JtYXQgdXNlZCBpbiBbUkZD ODE4Nl0uCgogICBvICBFcnJvciBFc3RpbWF0ZSBpcyB0d28gb2N0ZXRzIGxvbmcgZmllbGQgd2l0 aCBmb3JtYXQgZGlzcGxheWVkIGluCiAgICAgIEZpZ3VyZSAzCgoKCgoKTWlyc2t5LCBldCBhbC4g ICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDI0LCAyMDE5ICAgICAgICAgICAgICAgIFtQYWdlIDVd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIFNUQU1QICAgICAgICAgICAgICAg ICAgICAgICBBcHJpbCAyMDE5CgoKICAgICAgICAgICAgMCAgICAgICAgICAgICAgICAgICAxCiAg ICAgICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUKICAgICAgICAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICAgICAgICB8U3xafCAgIFNjYWxlICAg fCAgIE11bHRpcGxpZXIgIHwKICAgICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsKCiAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMzogRXJyb3IgRXN0aW1hdGUgRm9y bWF0CgogICAgICB3aGVyZSBTLCBTY2FsZSwgYW5kIE11bHRpcGxpZXIgZmllbGRzIGFyZSBpbnRl cnByZXRlZCBhcyB0aGV5IGhhdmUKICAgICAgYmVlbiBkZWZpbmVkIGluIHNlY3Rpb24gNC4xLjIg W1JGQzQ2NTZdOyBhbmQgWiBmaWVsZCAtIGFzIGhhcyBiZWVuCiAgICAgIGRlZmluZWQgaW4gc2Vj dGlvbiAyLjMgW1JGQzgxODZdOgoKICAgICAgKiAgMCAtIE5UUCA2NCBiaXQgZm9ybWF0IG9mIGEg dGltZXN0YW1wOwoKICAgICAgKiAgMSAtIFBUUHYyIHRydW5jYXRlZCBmb3JtYXQgb2YgYSB0aW1l c3RhbXAuCgogICAgICBUaGUgU1RBTVAgU2Vzc2lvbi1TZW5kZXIgYW5kIFNlc3Npb24tUmVmbGVj dG9yIE1BWSB1c2UsIG5vdCB1c2UsCiAgICAgIG9yIHNldCB2YWx1ZSBvZiB0aGUgWiBmaWVsZCBp biBhY2NvcmRhbmNlIHdpdGggdGhlIHRpbWVzdGFtcAogICAgICBmb3JtYXQgaW4gdXNlLiAgVGhp cyBvcHRpb25hbCBmaWVsZCBpcyB0byBlbmhhbmNlIG9wZXJhdGlvbnMsIGJ1dAogICAgICBsb2Nh bCBjb25maWd1cmF0aW9uIG9yIGRlZmF1bHRzIGNvdWxkIGJlIHVzZWQgaW4gaXRzIHBsYWNlLgoK ICAgbyAgTXVzdC1iZS1aZXJvIChNQlopIGZpZWxkIGluIHRoZSBzZXNzaW9uLXNlbmRlciB1bmF1 dGhlbnRpY2F0ZWQKICAgICAgcGFja2V0IGlzIDI3IG9jdGV0cyBsb25nLiAgSXQgTVVTVCBiZSBh bGwgemVyb2VkIG9uIHRoZQogICAgICB0cmFuc21pc3Npb24gYW5kIGlnbm9yZWQgb24gcmVjZWlw dC4KCiAgIG8gIFNlcnZlciBPY3RldHMgZmllbGQgaXMgdHdvIG9jdGV0cyBsb25nIGZpZWxkLiAg SXQgTVVTVCBmb2xsb3cgdGhlCiAgICAgIDI3IG9jdGV0cyBsb25nIE1CWiBmaWVsZC4gIFRoaXMg ZmllbGQgaXMgdXNlZCBmb3IgdGhlIFJlZmxlY3QKICAgICAgT2N0ZXRzIGNhcGFiaWxpdHkgZGVm aW5lZCBpbiBbUkZDNjAzOF0uICBUaGUgdmFsdWUgaW4gdGhlIFNlcnZlcgogICAgICBPY3RldHMg ZmllbGQgZXF1YWxzIHRoZSBudW1iZXIgb2Ygb2N0ZXRzIHRoZSBTZXNzaW9uLVJlZmxlY3RvciBp cwogICAgICBleHBlY3RlZCB0byBjb3B5IGJhY2sgdG8gdGhlIFNlc3Npb24tU2VuZGVyIHN0YXJ0 aW5nIHdpdGggdGhlCiAgICAgIFNlcnZlciBPY3RldHMgZmllbGQuICBUaHVzIHRoZSBtaW5pbWFs IG5vbi16ZXJvIHZhbHVlIGZvciB0aGUKICAgICAgU2VydmVyIE9jdGV0cyBmaWVsZCBpcyB0d28u ICBUaGVyZWZvcmUsIHRoZSB2YWx1ZSBvZiBvbmUgaXMKICAgICAgaW52YWxpZC4gIElmIG5vbmUg b2YgUGF5bG9hZCB0byBiZSBjb3BpZWQsIHRoZSB2YWx1ZSBvZiB0aGUgU2VydmVyCiAgICAgIE9j dGV0cyBmaWVsZCBNVVNUIGJlIHNldCB0byB6ZXJvIG9uIHRyYW5zbWl0LgoKICAgbyAgUmVtYWlu aW5nIFBhY2tldCBQYWRkaW5nIGlzIGFuIG9wdGlvbmFsIGZpZWxkIG9mIHZhcmlhYmxlIGxlbmd0 aC4KICAgICAgVGhlIG51bWJlciBvZiBvY3RldHMgaW4gdGhlIFJlbWFpbmluZyBQYWNrZXQgUGFk ZGluZyBmaWVsZCBpcyB0aGUKICAgICAgdmFsdWUgb2YgdGhlIFNlcnZlciBPY3RldHMgZmllbGQg bWludXMgdGhlIGxlbmd0aCBvZiB0aGUgU2VydmVyCiAgICAgIE9jdGV0cyBmaWVsZC4KCiAgIG8g IENvbXAuTUJaIGlzIHZhcmlhYmxlIGxlbmd0aCBmaWVsZCB1c2VkIHRvIGFjaGlldmUgYWxpZ25t ZW50IG9uIGEKICAgICAgd29yZCBib3VuZGFyeS4gIFRodXMgdGhlIGxlbmd0aCBvZiBDb21wLk1C WiBmaWVsZCBtYXkgYmUgb25seSAwLAogICAgICAxLCAyIG9yIDMgb2N0ZXRzLiAgVGhlIHZhbHVl IG9mIHRoZSBmaWVsZCBNVVNUIGJlIHplcm9lZCBvbgogICAgICB0cmFuc21pc3Npb24gYW5kIGln bm9yZWQgb24gcmVjZWlwdC4KCgoKCgoKCk1pcnNreSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMg T2N0b2JlciAyNCwgMjAxOSAgICAgICAgICAgICAgICBbUGFnZSA2XQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgICAgICBTVEFNUCAgICAgICAgICAgICAgICAgICAgICAgQXByaWwgMjAx OQoKCjQuMS4yLiAgU2Vzc2lvbi1TZW5kZXIgUGFja2V0IEZvcm1hdCBpbiBBdXRoZW50aWNhdGVk IE1vZGUKCiAgIEZvciBhdXRoZW50aWNhdGVkIG1vZGU6CgogICAgIDAgICAgICAgICAgICAgICAg ICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMKICAgICAwIDEgMiAz IDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEK ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rCiAgICB8ICAgICAgICAgICAgICAgICAgICAgIFNlcXVlbmNlIE51bWJlciAg ICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8 ICAgICAgICAgICAgICAgICAgICAgIE1CWiAoMTIgb2N0ZXRzKSAgICAgICAgICAgICAgICAgICAg ICAgICAgfAogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwKICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgVGltZXN0YW1wICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwKICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rCiAgICB8ICAgICAgICBFcnJvciBFc3RpbWF0ZSAgICAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICsKICAgIH4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB+CiAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgIE1CWiAoNzAgb2N0ZXRzKSAgICAgICAgICAgICAg ICAgICAgICAgfAogICAgfiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIH4KICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICB8ICAgICAgICAgICAgIFR5 cGUgICAgICAgICAgICAgIHwgICAgICAgICAgIExlbmd0aCAgICAgICAgICAgICAgfAogICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsKICAgIH4gICAgICAgICAgICAgICAgICAgICAgICAgICAgVmFsdWUgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB+CiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgfiAgICAgICAgICAgICAgICAgICAg ICAgICAgIENvbXAuTUJaICAgICAgICAgICAgICAgICAgICAgICAgICAgIH4KICAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r CiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfAogICAgfCAgICAgICAgICAgICAgICAgICAgICAgSE1BQyAoMTYgb2N0ZXRz KSAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsKCiAgICBGaWd1cmUgNDogU1RBTVAgU2Vzc2lvbi1TZW5kZXIgdGVzdCBwYWNrZXQg Zm9ybWF0IGluIGF1dGhlbnRpY2F0ZWQKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBtb2RlCgogICBUaGUgZmllbGQgZGVmaW5pdGlvbnMgYXJlIHRoZSBzYW1lIGFzIHRoZSB1bmF1 dGhlbnRpY2F0ZWQgbW9kZSwKICAgbGlzdGVkIGluIFNlY3Rpb24gNC4xLjEuICBBbHNvLCBDb21w Lk1CWiBmaWVsZCBpcyB2YXJpYWJsZSBsZW5ndGgKICAgZmllbGQgdG8gYWxpZ24gdGhlIHBhY2tl dCBvbiAxNiBvY3RldHMgYm91bmRhcnkuICBBbHNvLCB0aGUgcGFja2V0CiAgIGluY2x1ZGVzIGEg a2V5LWhhc2hlZCBtZXNzYWdlIGF1dGhlbnRpY2F0aW9uIGNvZGUgKEhNQUMpIChbUkZDMjEwNF0p CiAgIGhhc2ggYXQgdGhlIGVuZCBvZiB0aGUgUERVLiAgVGhlIGRldGFpbGVkIHVzZSBvZiB0aGUg SE1BQyBmaWVsZCBpcyBpbgogICBTZWN0aW9uIDQuMy4KCgoKCgoKCgpNaXJza3ksIGV0IGFsLiAg ICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjQsIDIwMTkgICAgICAgICAgICAgICAgW1BhZ2UgN10K DApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgU1RBTVAgICAgICAgICAgICAgICAg ICAgICAgIEFwcmlsIDIwMTkKCgo0LjIuICBTZXNzaW9uLVJlZmxlY3RvciBCZWhhdmlvciBhbmQg UGFja2V0IEZvcm1hdAoKICAgVGhlIFNlc3Npb24tUmVmbGVjdG9yIHJlY2VpdmVzIHRoZSBTVEFN UCB0ZXN0IHBhY2tldCwgdmVyaWZpZXMgaXQsCiAgIHByZXBhcmVzIGFuZCB0cmFuc21pdHMgdGhl IHJlZmxlY3RlZCB0ZXN0IHBhY2tldC4KCiAgIFR3byBtb2RlcyBvZiBTVEFNUCBTZXNzaW9uLVJl ZmxlY3RvciBjaGFyYWN0ZXJpemUgdGhlIGV4cGVjdGVkCiAgIGJlaGF2aW9yIGFuZCwgY29uc2Vx dWVudGx5LCBwZXJmb3JtYW5jZSBtZXRyaWNzIHRoYXQgY2FuIGJlIG1lYXN1cmVkOgoKICAgbyAg U3RhdGVsZXNzIC0gU1RBTVAgU2Vzc2lvbi1SZWZsZWN0b3IgZG9lcyBub3QgbWFpbnRhaW4gdGVz dCBzdGF0ZQogICAgICBhbmQgd2lsbCByZWZsZWN0IHRoZSByZWNlaXZlZCBzZXF1ZW5jZSBudW1i ZXIgd2l0aG91dAogICAgICBtb2RpZmljYXRpb24uICBBcyBhIHJlc3VsdCwgb25seSByb3VuZC10 cmlwIHBhY2tldCBsb3NzIGNhbiBiZQogICAgICBjYWxjdWxhdGVkIHdoaWxlIHRoZSByZWZsZWN0 b3IgaXMgb3BlcmF0aW5nIGluIHN0YXRlbGVzcyBtb2RlLgoKICAgbyAgU3RhdGVmdWwgLSBTVEFN UCBTZXNzaW9uLVJlZmxlY3RvciBtYWludGFpbnMgdGVzdCBzdGF0ZSB0aHVzCiAgICAgIGVuYWJs aW5nIHRoZSBhYmlsaXR5IHRvIGRldGVybWluZSBmb3J3YXJkIGxvc3MsIGdhcHMgcmVjb2duaXpl ZCBpbgogICAgICB0aGUgcmVjZWl2ZWQgc2VxdWVuY2UgbnVtYmVyLiAgQXMgYSByZXN1bHQsIGJv dGggbmVhci1lbmQKICAgICAgKGZvcndhcmQpIGFuZCBmYXItZW5kIChiYWNrd2FyZCkgcGFja2V0 IGxvc3MgY2FuIGJlIGNvbXB1dGVkLgogICAgICBUaGF0IGltcGxpZXMgdGhhdCB0aGUgU1RBTVAg U2Vzc2lvbi1SZWZsZWN0b3IgTVVTVCBrZWVwIGEgc3RhdGUKICAgICAgZm9yIGVhY2ggYWNjZXB0 ZWQgU1RBTVAtdGVzdCBzZXNzaW9uLCB1bmlxdWVseSBpZGVudGlmeWluZyBTVEFNUC0KICAgICAg dGVzdCBwYWNrZXRzIHRvIG9uZSBzdWNoIHNlc3Npb24gaW5zdGFuY2UsIGFuZCBlbmFibGluZyBh ZGRpbmcgYQogICAgICBzZXF1ZW5jZSBudW1iZXIgaW4gdGhlIHRlc3QgcmVwbHkgdGhhdCBpcyBp bmRpdmlkdWFsbHkgaW5jcmVtZW50ZWQKICAgICAgb24gYSBwZXItc2Vzc2lvbiBiYXNpcy4KCjQu Mi4xLiAgU2Vzc2lvbi1SZWZsZWN0b3IgUGFja2V0IEZvcm1hdCBpbiBVbmF1dGhlbnRpY2F0ZWQg TW9kZQoKICAgRm9yIHVuYXV0aGVudGljYXRlZCBtb2RlOgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKTWlyc2t5LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDI0LCAyMDE5ICAgICAg ICAgICAgICAgIFtQYWdlIDhdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIFNU QU1QICAgICAgICAgICAgICAgICAgICAgICBBcHJpbCAyMDE5CgoKICAgICAwICAgICAgICAgICAg ICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzCiAgICAgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxCiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKwogICAgfCAgICAgICAgICAgICAgICAgICAgICAgIFNlcXVlbmNlIE51 bWJlciAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICB8ICAgICAgICAg ICAgICAgICAgICAgICAgICBUaW1lc3RhbXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAog ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwKICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICB8ICAgICAgICAgRXJyb3IgRXN0aW1hdGUgICAg ICAgIHwgICAgICAgICAgIE1CWiAgICAgICAgICAgICAgICAgfAogICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgIFJlY2VpdmUgVGltZXN0YW1wICAgICAgICAgICAgICAg ICAgICB8CiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfAogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgIHwgICAgICAgICAgICAgICAgIFNl c3Npb24tU2VuZGVyIFNlcXVlbmNlIE51bWJlciAgICAgICAgICAgICAgICB8CiAgICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst KwogICAgfCAgICAgICAgICAgICAgICAgIFNlc3Npb24tU2VuZGVyIFRpbWVzdGFtcCAgICAgICAg ICAgICAgICAgICAgIHwKICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgfCBTZXNzaW9uLVNl bmRlciBFcnJvciBFc3RpbWF0ZSB8ICAgICAgICAgICBNQlogICAgICAgICAgICAgICAgIHwKICAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rCiAgICB8U2VzLVNlbmRlciBUVEwgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfAogICAgKy0rLSstKy0rLSstKy0rLSsgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICsKICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB+ICAg ICAgICAgICAgICAgIFBhY2tldCBQYWRkaW5nIChyZWZsZWN0ZWQpICAgICAgICAgICAgICAgICAg ICAgfgogICAgKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Ky0rLSstKy0rLSstKy0rLSsKICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgQ29tcC5NQlogICB8CiAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgfCAgICAgICAg ICAgICBUeXBlICAgICAgICAgICAgICB8ICAgICAgICAgICBMZW5ndGggICAgICAgICAgICAgIHwK ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rCiAgICB+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFZhbHVlICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfgogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKCiAgICAgICAgICBGaWd1cmUg NTogU1RBTVAgU2Vzc2lvbi1SZWZsZWN0b3IgdGVzdCBwYWNrZXQgZm9ybWF0IGluCiAgICAgICAg ICAgICAgICAgICAgICAgICAgIHVuYXV0aGVudGljYXRlZCBtb2RlCgogICB3aGVyZSBmaWVsZHMg YXJlIGRlZmluZWQgYXMgdGhlIGZvbGxvd2luZzoKCiAgIG8gIFNlcXVlbmNlIE51bWJlciBpcyBm b3VyIG9jdGV0cyBsb25nIGZpZWxkLiAgVGhlIHZhbHVlIG9mIHRoZQogICAgICBTZXF1ZW5jZSBO dW1iZXIgZmllbGQgaXMgc2V0IGFjY29yZGluZyB0byB0aGUgbW9kZSBvZiB0aGUgU1RBTVAKICAg ICAgU2Vzc2lvbi1SZWZsZWN0b3I6CgogICAgICAqICBpbiB0aGUgc3RhdGVsZXNzIG1vZGUgdGhl IFNlc3Npb24tUmVmbGVjdG9yIGNvcGllcyB0aGUgdmFsdWUKICAgICAgICAgZnJvbSB0aGUgcmVj ZWl2ZWQgU1RBTVAgdGVzdCBwYWNrZXQncyBTZXF1ZW5jZSBOdW1iZXIgZmllbGQ7CgogICAgICAq ICBpbiB0aGUgc3RhdGVmdWwgbW9kZSB0aGUgU2Vzc2lvbi1SZWZsZWN0b3IgY291bnRzIHRoZSBy ZWNlaXZlZAogICAgICAgICBTVEFNUCB0ZXN0IHBhY2tldHMgaW4gZWFjaCB0ZXN0IHNlc3Npb24g YW5kIHVzZXMgdGhhdCBjb3VudGVyCiAgICAgICAgIHRvIHNldCB0aGUgdmFsdWUgb2YgdGhlIFNl cXVlbmNlIE51bWJlciBmaWVsZC4KCgoKCk1pcnNreSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMg T2N0b2JlciAyNCwgMjAxOSAgICAgICAgICAgICAgICBbUGFnZSA5XQoMCkludGVybmV0LURyYWZ0 ICAgICAgICAgICAgICAgICAgICBTVEFNUCAgICAgICAgICAgICAgICAgICAgICAgQXByaWwgMjAx OQoKCiAgIG8gIFRpbWVzdGFtcCBhbmQgUmVjZWl2ZXIgVGltZXN0YW1wIGZpZWxkcyBhcmUgZWFj aCBlaWdodCBvY3RldHMKICAgICAgbG9uZy4gIFRoZSBmb3JtYXQgb2YgdGhlc2UgZmllbGRzLCBO VFAgb3IgUFRQdjIsIGluZGljYXRlZCBieSB0aGUKICAgICAgWiBmbGFnIG9mIHRoZSBFcnJvciBF c3RpbWF0ZSBmaWVsZCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LjEuCgogICBvICBFcnJvciBF c3RpbWF0ZSBoYXMgdGhlIHNhbWUgc2l6ZSBhbmQgaW50ZXJwcmV0YXRpb24gYXMgZGVzY3JpYmVk CiAgICAgIGluIFNlY3Rpb24gNC4xLgoKICAgbyAgU2Vzc2lvbi1TZW5kZXIgU2VxdWVuY2UgTnVt YmVyLCBTZXNzaW9uLVNlbmRlciBUaW1lc3RhbXAsIGFuZAogICAgICBTZXNzaW9uLVNlbmRlciBF cnJvciBFc3RpbWF0ZSBhcmUgY29waWVzIG9mIHRoZSBjb3JyZXNwb25kaW5nCiAgICAgIGZpZWxk cyBpbiB0aGUgU1RBTVAgdGVzdCBwYWNrZXQgc2VudCBieSB0aGUgU2Vzc2lvbi1TZW5kZXIuCgog ICBvICBTZXNzaW9uLVNlbmRlciBUVEwgaXMgb25lIG9jdGV0IGxvbmcgZmllbGQsIGFuZCBpdHMg dmFsdWUgaXMgdGhlCiAgICAgIGNvcHkgb2YgdGhlIFRUTCBmaWVsZCBpbiBJUHY0IChvciBIb3Ag TGltaXQgaW4gSVB2NikgZnJvbSB0aGUKICAgICAgcmVjZWl2ZWQgU1RBTVAgdGVzdCBwYWNrZXQu CgogICBvICBQYWNrZXQgUGFkZGluZyAocmVmbGVjdGVkKSBpcyBhbiBvcHRpb25hbCB2YXJpYWJs ZSBsZW5ndGggZmllbGQuCiAgICAgIFRoZSBsZW5ndGggb2YgdGhlIFBhY2tldCBQYWRkaW5nIChy ZWZsZWN0ZWQpIGZpZWxkIE1VU1QgYmUgZXF1YWwKICAgICAgdG8gdGhlIHZhbHVlIG9mIHRoZSBT ZXJ2ZXIgT2N0ZXRzIGZpZWxkIChGaWd1cmUgMikuICBJZiB0aGUgdmFsdWUKICAgICAgaXMgbm9u LXplcm8sIHRoZSBTZXNzaW9uLVJlZmxlY3RvciBNVVNUIGNvcHkgbnVtYmVyIG9mIG9jdGV0cwog ICAgICBlcXVhbCB0byB0aGUgdmFsdWUgb2YgU2VydmVyIE9jdGV0cyBmaWVsZCBzdGFydGluZyB3 aXRoIHRoZSBTZXJ2ZXIKICAgICAgT2N0ZXRzIGZpZWxkLgoKICAgbyAgQ29tcC5NQlogaXMgdmFy aWFibGUgbGVuZ3RoIGZpZWxkIHVzZWQgdG8gYWNoaWV2ZSBhbGlnbm1lbnQgb24gYQogICAgICB3 b3JkIGJvdW5kYXJ5LiAgVGh1cyB0aGUgbGVuZ3RoIG9mIENvbXAuTUJaIGZpZWxkIG1heSBiZSBv bmx5IDAsCiAgICAgIDEsIDIgb3IgMyBvY3RldHMuICBUaGUgdmFsdWUgb2YgdGhlIGZpZWxkIE1V U1QgYmUgemVyb2VkIG9uCiAgICAgIHRyYW5zbWlzc2lvbiBhbmQgaWdub3JlZCBvbiByZWNlaXB0 LgoKNC4yLjIuICBTZXNzaW9uLVJlZmxlY3RvciBQYWNrZXQgRm9ybWF0IGluIEF1dGhlbnRpY2F0 ZWQgTW9kZQoKICAgRm9yIHRoZSBhdXRoZW50aWNhdGVkIG1vZGU6CgogICAgICAwICAgICAgICAg ICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzCiAgICAg IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcg OCA5IDAgMQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgU2Vx dWVuY2UgTnVtYmVyICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgTUJaICgxMiBvY3RldHMpICAgICAgICAgICAgICAg ICAgICAgICAgfAogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwog ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICBUaW1lc3RhbXAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfAogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICB8ICAgICAg ICAgRXJyb3IgRXN0aW1hdGUgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fAogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKwogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgTUJaICg2IG9j dGV0cykgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgUmVjZWl2ZSBUaW1lc3RhbXAgICAgICAgICAgICAgICAgICAg ICAgfAoKCgpNaXJza3ksIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjQsIDIwMTkg ICAgICAgICAgICAgICBbUGFnZSAxMF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAg ICAgU1RBTVAgICAgICAgICAgICAgICAgICAgICAgIEFwcmlsIDIwMTkKCgogICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fAogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKwogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgTUJaICg4IG9j dGV0cykgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKwogICAgICB8ICAgICAgICAgICAgICAgICBTZXNzaW9uLVNlbmRlciBTZXF1ZW5jZSBOdW1i ZXIgICAgICAgICAgICAgICAgfAogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICB8ICAgICAgICAgICAgICAg ICAgICAgICAgTUJaICgxMiBvY3RldHMpICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfAogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfAogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICB8ICAgICAgICAgICAg ICAgICBTZXNzaW9uLVNlbmRlciBUaW1lc3RhbXAgICAgICAgICAgICAgICAgICAgICAgfAogICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfAogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICB8IFNlc3Npb24tU2VuZGVyIEVycm9yIEVz dGltYXRlIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKwog ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgTUJaICg2IG9jdGV0cykgICAgICAgICAgICAg ICAgICAgICAgICAgfAogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICB8U2VzLVNlbmRlciBUVEwgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICArLSstKy0r LSstKy0rLSstKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg KwogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfAogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgTUJaICgxNSBv Y3RldHMpICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKwogICAgICB8ICAgICAgICAgICAgIFR5cGUgICAgICAgICAgICAgIHwgICAgICAgICAgIExl bmd0aCAgICAgICAgICAgICAgfAogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICB+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFZhbHVlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfgogICAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKwogICAgICB+ICAgICAgICAgICAgICAgICAgICAgICAgICAgQ29tcC5NQlogICAgICAg ICAgICAgICAgICAgICAgICAgICAgfgogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgSE1BQyAoMTYgb2N0ZXRzKSAgICAgICAgICAgICAgICAgICAgICAgfAogICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfAogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwoK CiAgIEZpZ3VyZSA2OiBTVEFNUCBTZXNzaW9uLVJlZmxlY3RvciB0ZXN0IHBhY2tldCBmb3JtYXQg aW4gYXV0aGVudGljYXRlZAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vZGUK CiAgIFRoZSBmaWVsZCBkZWZpbml0aW9ucyBhcmUgdGhlIHNhbWUgYXMgdGhlIHVuYXV0aGVudGlj YXRlZCBtb2RlLAogICBsaXN0ZWQgaW4gU2VjdGlvbiA0LjIuMS4gIEFkZGl0aW9uYWxseSwgdGhl IHBhY2tldCBNQVkgaW5jbHVkZQogICBDb21wLk1CWiBmaWVsZCBpcyB2YXJpYWJsZSBsZW5ndGgg ZmllbGQgdG8gYWxpZ24gdGhlIHBhY2tldCBvbiAxNgogICBvY3RldHMgYm91bmRhcnkuICBBbHNv LCBTVEFNUCBTZXNzaW9uLVJlZmxlY3RvciB0ZXN0IHBhY2tldCBmb3JtYXQgaW4KICAgYXV0aGVu dGljYXRlZCBtb2RlIGluY2x1ZGVzIGEga2V5IChITUFDKSAoW1JGQzIxMDRdKSBoYXNoIGF0IHRo ZSBlbmQKICAgb2YgdGhlIFBEVS4gIFRoZSBkZXRhaWxlZCB1c2Ugb2YgdGhlIEhNQUMgZmllbGQg aXMgaW4gU2VjdGlvbiA0LjMuCgoKCgoKTWlyc2t5LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBP Y3RvYmVyIDI0LCAyMDE5ICAgICAgICAgICAgICAgW1BhZ2UgMTFdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICAgICAgIFNUQU1QICAgICAgICAgICAgICAgICAgICAgICBBcHJpbCAyMDE5 CgoKNC4zLiAgSW50ZWdyaXR5IGFuZCBDb25maWRlbnRpYWxpdHkgUHJvdGVjdGlvbiBpbiBTVEFN UAoKICAgVG8gcHJvdmlkZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbiwgZWFjaCBTVEFNUCBtZXNzYWdl IGlzIGJlaW5nCiAgIGF1dGhlbnRpY2F0ZWQgYnkgYWRkaW5nIEhhc2hlZCBNZXNzYWdlIEF1dGhl bnRpY2F0aW9uIENvZGUgKEhNQUMpLgogICBTVEFNUCB1c2VzIEhNQUMtU0hBLTI1NiB0cnVuY2F0 ZWQgdG8gMTI4IGJpdHMgKHNpbWlsYXJseSB0byB0aGUgdXNlCiAgIG9mIGl0IGluIElQU2VjIGRl ZmluZWQgaW4gW1JGQzQ4NjhdKTsgaGVuY2UgdGhlIGxlbmd0aCBvZiB0aGUgSE1BQwogICBmaWVs ZCBpcyAxNiBvY3RldHMuICBITUFDIHVzZXMgb3duIGtleSBhbmQgdGhlIGRlZmluaXRpb24gb2Yg dGhlCiAgIG1lY2hhbmlzbSB0byBkaXN0cmlidXRlIHRoZSBITUFDIGtleSBpcyBvdXRzaWRlIHRo ZSBzY29wZSBvZiB0aGlzCiAgIHNwZWNpZmljYXRpb24uICBPbmUgZXhhbXBsZSBpcyB0byB1c2Ug YW4gb3JjaGVzdHJhdG9yIHRvIGNvbmZpZ3VyZQogICBITUFDIGtleSBiYXNlZCBvbiBTVEFNUCBZ QU5HIGRhdGEgbW9kZWwgW0ktRC5pZXRmLWlwcG0tc3RhbXAteWFuZ10uCiAgIEhNQUMgTVVTVCBi ZSB2ZXJpZmllZCBhcyBlYXJseSBhcyBwb3NzaWJsZSB0byBhdm9pZCB1c2luZyBvcgogICBwcm9w YWdhdGluZyBjb3JydXB0ZWQgZGF0YS4KCiAgIElmIGNvbmZpZGVudGlhbGl0eSBwcm90ZWN0aW9u IGZvciBTVEFNUCBpcyByZXF1aXJlZCwgZW5jcnlwdGlvbiBhdAogICB0aGUgaGlnaGVyIGxldmVs IE1VU1QgYmUgdXNlZC4gIEZvciBleGFtcGxlLCBTVEFNUCBwYWNrZXRzIGNvdWxkIGJlCiAgIHRy YW5zbWl0dGVkIGluIHRoZSBkZWRpY2F0ZWQgSVBzZWMgdHVubmVsIG9yIHNoYXJlIHRoZSBJUHNl YyB0dW5uZWwKICAgd2l0aCB0aGUgbW9uaXRvcmVkIGZsb3cuCgo0LjQuICBJbnRlcm9wZXJhYmls aXR5IHdpdGggVFdBTVAgTGlnaHQKCiAgIE9uZSBvZiB0aGUgZXNzZW50aWFsIHJlcXVpcmVtZW50 cyB0byBTVEFNUCBpcyB0aGUgYWJpbGl0eSB0bwogICBpbnRlcndvcmsgd2l0aCBUV0FNUCBMaWdo dCBkZXZpY2UuICBUaGVyZSBhcmUgdHdvIHBvc3NpYmxlCiAgIGNvbWJpbmF0aW9ucyBmb3Igc3Vj aCB1c2UgY2FzZToKCiAgIG8gIFNUQU1QIFNlc3Npb24tU2VuZGVyIHdpdGggVFdBTVAgTGlnaHQg U2Vzc2lvbi1SZWZsZWN0b3I7CgogICBvICBUV0FNUCBMaWdodCBTZXNzaW9uLVNlbmRlciB3aXRo IFNUQU1QIFNlc3Npb24tUmVmbGVjdG9yLgoKICAgSW4gdGhlIGZvcm1lciBjYXNlLCBTZXNzaW9u LVNlbmRlciBNQVkgbm90IGJlIGF3YXJlIHRoYXQgaXRzIFNlc3Npb24tCiAgIFJlZmxlY3RvciBk b2VzIG5vdCBzdXBwb3J0IFNUQU1QLiAgRm9yIGV4YW1wbGUsIFRXQU1QIExpZ2h0IFNlc3Npb24t CiAgIFJlZmxlY3RvciBtYXkgbm90IHN1cHBvcnQgdGhlIHVzZSBvZiBVRFAgcG9ydCA4NjIgYXMg ZGVmaW5lZCBpbgogICBbUkZDODU0NV0uICBUaHVzIFNUQU1QIFNlc3Npb24tU2VuZGVyIE1VU1Qg YmUgYWJsZSB0byBzZW5kIHRlc3QKICAgcGFja2V0cyB0byBkZXN0aW5hdGlvbiBVRFAgcG9ydCBu dW1iZXIgZnJvbSB0aGUgRHluYW1pYyBhbmQvb3IKICAgUHJpdmF0ZSBQb3J0cyByYW5nZSA0OTE1 Mi02NTUzNSwgdGVzdCBtYW5hZ2VtZW50IHN5c3RlbSBzaG91bGQgZmluZAogICBwb3J0IG51bWJl ciB0aGF0IGJvdGggZGV2aWNlcyBjYW4gdXNlLiAgQW5kIGlmIGFueSBvZiBUTFYtYmFzZWQgU1RB TVAKICAgZXh0ZW5zaW9ucyBhcmUgdXNlZCwgdGhlIFRXQU1QIExpZ2h0IFNlc3Npb24tUmVmbGVj dG9yIHdpbGwgdmlldyB0aGVtCiAgIGFzIFBhY2tldCBQYWRkaW5nIGZpZWxkLiAgVGhlIFNlc3Np b24tU2VuZGVyIFNIT1VMRCB1c2UgdGhlIGRlZmF1bHQKICAgZm9ybWF0IGZvciBpdHMgdGltZXN0 YW1wcyAtIE5UUC4gIEFuZCBpdCBNQVkgdXNlIFBUUHYyIHRpbWVzdGFtcAogICBmb3JtYXQuCgog ICBJbiB0aGUgbGF0dGVyIHNjZW5hcmlvLCB0aGUgdGVzdCBtYW5hZ2VtZW50IHN5c3RlbSBzaG91 bGQgc2V0IFNUQU1QCiAgIFNlc3Npb24tUmVmbGVjdG9yIHRvIHVzZSBVRFAgcG9ydCBudW1iZXIg ZnJvbSB0aGUgRHluYW1pYyBhbmQvb3IKICAgUHJpdmF0ZSBQb3J0cyByYW5nZS4gIEFzIGZvciBQ YWNrZXQgUGFkZGluZyBmaWVsZCB0aGF0IHRoZSBUV0FNUAogICBMaWdodCBTZXNzaW9uLVNlbmRl ciBpbmNsdWRlcyBpbiBpdHMgdHJhbnNtaXR0ZWQgcGFja2V0LCB0aGUgU1RBTVAKICAgU2Vzc2lv bi1SZWZsZWN0b3Igd2lsbCBwcm9jZXNzIGl0IGFjY29yZGluZyB0byBbUkZDNjAzOF0gYW5kIHJl dHVybgogICByZWZsZWN0ZWQgcGFja2V0IG9mIHRoZSBzeW1tZXRyaWNhbCBzaXplLiAgVGhlIFNl c3Npb24tUmVmbGVjdG9yIE1VU1QKICAgdXNlIHRoZSBkZWZhdWx0IGZvcm1hdCBmb3IgaXRzIHRp bWVzdGFtcHMgLSBOVFAuCgoKCgpNaXJza3ksIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIE9jdG9i ZXIgMjQsIDIwMTkgICAgICAgICAgICAgICBbUGFnZSAxMl0KDApJbnRlcm5ldC1EcmFmdCAgICAg ICAgICAgICAgICAgICAgU1RBTVAgICAgICAgICAgICAgICAgICAgICAgIEFwcmlsIDIwMTkKCgo1 LiAgSUFOQSBDb25zaWRlcmF0aW9ucwoKICAgVGhpcyBkb2N1bWVudCBkb2Vzbid0IGhhdmUgYW55 IElBTkEgYWN0aW9uLiAgVGhpcyBzZWN0aW9uIG1heSBiZQogICByZW1vdmVkIGJlZm9yZSB0aGUg cHVibGljYXRpb24uCgo2LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIEluIGdlbmVyYWws IGFsbCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgcmVsYXRlZCB0byBUV0FNUC1UZXN0LAog ICBkaXNjdXNzZWQgaW4gW1JGQzUzNTddIGFwcGx5IHRvIFNUQU1QLiAgU2luY2UgU1RBTVAgdXNl cyB0aGUgd2VsbC0KICAga25vd24gVURQIHBvcnQgbnVtYmVyIGFsbG9jYXRlZCBmb3IgdGhlIE9X QU1QLVRlc3QvVFdBTVAtVGVzdAogICBSZWNlaXZlciBwb3J0LCB0aGUgc2VjdXJpdHkgY29uc2lk ZXJhdGlvbnMgYW5kIG1lYXN1cmVzIHRvIG1pdGlnYXRlCiAgIHRoZSByaXNrIG9mIHRoZSBhdHRh Y2sgdXNpbmcgdGhlIHJlZ2lzdGVyZWQgcG9ydCBudW1iZXIgZG9jdW1lbnRlZCBpbgogICBTZWN0 aW9uIDYgW1JGQzg1NDVdIGVxdWFsbHkgYXBwbHkgdG8gU1RBTVAuICBCZWNhdXNlIHRoZSBjb250 cm9sIGFuZAogICBtYW5hZ2VtZW50IG9mIGEgU1RBTVAgdGVzdCBhcmUgb3V0c2lkZSB0aGUgc2Nv cGUgb2YgdGhpcwogICBzcGVjaWZpY2F0aW9uIG9ubHkgdGhlIG1vcmUgZ2VuZXJhbCByZXF1aXJl bWVudCBpcyBzZXQ6CgogICAgICBUbyBtaXRpZ2F0ZSB0aGUgcG9zc2libGUgYXR0YWNrIHZlY3Rv ciwgdGhlIGNvbnRyb2wgYW5kIG1hbmFnZW1lbnQKICAgICAgb2YgYSBTVEFNUCB0ZXN0IHNlc3Np b24gTVVTVCB1c2UgdGhlIHNlY3VyZWQgdHJhbnNwb3J0LgoKICAgVXNlIG9mIEhNQUMtU0hBLTI1 NiBpbiB0aGUgYXV0aGVudGljYXRlZCBtb2RlIHByb3RlY3RzIHRoZSBkYXRhCiAgIGludGVncml0 eSBvZiB0aGUgU1RBTVAgdGVzdCBwYWNrZXRzLgoKNy4gIEFja25vd2xlZGdtZW50cwoKICAgQXV0 aG9ycyBleHByZXNzIHRoZWlyIGFwcHJlY2lhdGlvbiB0byBKb3NlIElnbmFjaW8gQWx2YXJlei1I YW1lbGluCiAgIGFuZCBCcmlhbiBXZWlzIGZvciB0aGVpciBncmVhdCBpbnNpZ2h0cyBpbnRvIHRo ZSBzZWN1cml0eSBhbmQKICAgaWRlbnRpdHkgcHJvdGVjdGlvbiwgYW5kIHRoZSBtb3N0IGhlbHBm dWwgYW5kIHByYWN0aWNhbCBzdWdnZXN0aW9ucy4KCjguICBSZWZlcmVuY2VzCgo4LjEuICBOb3Jt YXRpdmUgUmVmZXJlbmNlcwoKICAgW0lFRUUuMTU4OC4yMDA4XQogICAgICAgICAgICAgICJTdGFu ZGFyZCBmb3IgYSBQcmVjaXNpb24gQ2xvY2sgU3luY2hyb25pemF0aW9uIFByb3RvY29sCiAgICAg ICAgICAgICAgZm9yIE5ldHdvcmtlZCBNZWFzdXJlbWVudCBhbmQgQ29udHJvbCBTeXN0ZW1zIiwK ICAgICAgICAgICAgICBJRUVFIFN0YW5kYXJkIDE1ODgsIE1hcmNoIDIwMDguCgogICBbUkZDMjEx OV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZQog ICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksCiAgICAg ICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzIxMTksIE1hcmNoIDE5OTcsCiAgICAgICAgICAgICAg PGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjMjExOT4uCgogICBbUkZDNDY1Nl0g IFNoYWx1bm92LCBTLiwgVGVpdGVsYmF1bSwgQi4sIEthcnAsIEEuLCBCb290ZSwgSi4sIGFuZCBN LgogICAgICAgICAgICAgIFpla2F1c2thcywgIkEgT25lLXdheSBBY3RpdmUgTWVhc3VyZW1lbnQg UHJvdG9jb2wKICAgICAgICAgICAgICAoT1dBTVApIiwgUkZDIDQ2NTYsIERPSSAxMC4xNzQ4Ny9S RkM0NjU2LCBTZXB0ZW1iZXIgMjAwNiwKICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cucmZjLWVk aXRvci5vcmcvaW5mby9yZmM0NjU2Pi4KCgoKCgpNaXJza3ksIGV0IGFsLiAgICAgICAgICBFeHBp cmVzIE9jdG9iZXIgMjQsIDIwMTkgICAgICAgICAgICAgICBbUGFnZSAxM10KDApJbnRlcm5ldC1E cmFmdCAgICAgICAgICAgICAgICAgICAgU1RBTVAgICAgICAgICAgICAgICAgICAgICAgIEFwcmls IDIwMTkKCgogICBbUkZDNTM1N10gIEhlZGF5YXQsIEsuLCBLcnphbm93c2tpLCBSLiwgTW9ydG9u LCBBLiwgWXVtLCBLLiwgYW5kIEouCiAgICAgICAgICAgICAgQmFiaWFyeiwgIkEgVHdvLVdheSBB Y3RpdmUgTWVhc3VyZW1lbnQgUHJvdG9jb2wgKFRXQU1QKSIsCiAgICAgICAgICAgICAgUkZDIDUz NTcsIERPSSAxMC4xNzQ4Ny9SRkM1MzU3LCBPY3RvYmVyIDIwMDgsCiAgICAgICAgICAgICAgPGh0 dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNTM1Nz4uCgogICBbUkZDNTkwNV0gIE1p bGxzLCBELiwgTWFydGluLCBKLiwgRWQuLCBCdXJiYW5rLCBKLiwgYW5kIFcuIEthc2NoLAogICAg ICAgICAgICAgICJOZXR3b3JrIFRpbWUgUHJvdG9jb2wgVmVyc2lvbiA0OiBQcm90b2NvbCBhbmQg QWxnb3JpdGhtcwogICAgICAgICAgICAgIFNwZWNpZmljYXRpb24iLCBSRkMgNTkwNSwgRE9JIDEw LjE3NDg3L1JGQzU5MDUsIEp1bmUgMjAxMCwKICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cucmZj LWVkaXRvci5vcmcvaW5mby9yZmM1OTA1Pi4KCiAgIFtSRkM2MDM4XSAgTW9ydG9uLCBBLiBhbmQg TC4gQ2lhdmF0dG9uZSwgIlR3by1XYXkgQWN0aXZlIE1lYXN1cmVtZW50CiAgICAgICAgICAgICAg UHJvdG9jb2wgKFRXQU1QKSBSZWZsZWN0IE9jdGV0cyBhbmQgU3ltbWV0cmljYWwgU2l6ZQogICAg ICAgICAgICAgIEZlYXR1cmVzIiwgUkZDIDYwMzgsIERPSSAxMC4xNzQ4Ny9SRkM2MDM4LCBPY3Rv YmVyIDIwMTAsCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8v cmZjNjAzOD4uCgogICBbUkZDODE3NF0gIExlaWJhLCBCLiwgIkFtYmlndWl0eSBvZiBVcHBlcmNh c2UgdnMgTG93ZXJjYXNlIGluIFJGQwogICAgICAgICAgICAgIDIxMTkgS2V5IFdvcmRzIiwgQkNQ IDE0LCBSRkMgODE3NCwgRE9JIDEwLjE3NDg3L1JGQzgxNzQsCiAgICAgICAgICAgICAgTWF5IDIw MTcsIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzgxNzQ+LgoKICAgW1JGQzgx ODZdICBNaXJza3ksIEcuIGFuZCBJLiBNZWlsaWssICJTdXBwb3J0IG9mIHRoZSBJRUVFIDE1ODgK ICAgICAgICAgICAgICBUaW1lc3RhbXAgRm9ybWF0IGluIGEgVHdvLVdheSBBY3RpdmUgTWVhc3Vy ZW1lbnQgUHJvdG9jb2wKICAgICAgICAgICAgICAoVFdBTVApIiwgUkZDIDgxODYsIERPSSAxMC4x NzQ4Ny9SRkM4MTg2LCBKdW5lIDIwMTcsCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1l ZGl0b3Iub3JnL2luZm8vcmZjODE4Nj4uCgogICBbUkZDODU0NV0gIE1vcnRvbiwgQS4sIEVkLiBh bmQgRy4gTWlyc2t5LCBFZC4sICJXZWxsLUtub3duIFBvcnQKICAgICAgICAgICAgICBBc3NpZ25t ZW50cyBmb3IgdGhlIE9uZS1XYXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29sCiAgICAgICAg ICAgICAgKE9XQU1QKSBhbmQgdGhlIFR3by1XYXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29s CiAgICAgICAgICAgICAgKFRXQU1QKSIsIFJGQyA4NTQ1LCBET0kgMTAuMTc0ODcvUkZDODU0NSwg TWFyY2ggMjAxOSwKICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5m by9yZmM4NTQ1Pi4KCjguMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtCQkYuVFItMzkw XQogICAgICAgICAgICAgICJQZXJmb3JtYW5jZSBNZWFzdXJlbWVudCBmcm9tIElQIEVkZ2UgdG8g Q3VzdG9tZXIKICAgICAgICAgICAgICBFcXVpcG1lbnQgdXNpbmcgVFdBTVAgTGlnaHQiLCBCQkYg VFItMzkwLCBNYXkgMjAxNy4KCiAgIFtJLUQuaWV0Zi1pcHBtLXN0YW1wLXlhbmddCiAgICAgICAg ICAgICAgTWlyc2t5LCBHLiwgWGlhbywgTS4sIGFuZCBXLiBMdW8sICJTaW1wbGUgVHdvLXdheSBB Y3RpdmUKICAgICAgICAgICAgICBNZWFzdXJlbWVudCBQcm90b2NvbCAoU1RBTVApIERhdGEgTW9k ZWwiLCBkcmFmdC1pZXRmLWlwcG0tCiAgICAgICAgICAgICAgc3RhbXAteWFuZy0wMyAod29yayBp biBwcm9ncmVzcyksIE1hcmNoIDIwMTkuCgogICBbUkZDMjEwNF0gIEtyYXdjenlrLCBILiwgQmVs bGFyZSwgTS4sIGFuZCBSLiBDYW5ldHRpLCAiSE1BQzogS2V5ZWQtCiAgICAgICAgICAgICAgSGFz aGluZyBmb3IgTWVzc2FnZSBBdXRoZW50aWNhdGlvbiIsIFJGQyAyMTA0LAogICAgICAgICAgICAg IERPSSAxMC4xNzQ4Ny9SRkMyMTA0LCBGZWJydWFyeSAxOTk3LAogICAgICAgICAgICAgIDxodHRw czovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzIxMDQ+LgoKCgoKCgpNaXJza3ksIGV0IGFs LiAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjQsIDIwMTkgICAgICAgICAgICAgICBbUGFnZSAx NF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgU1RBTVAgICAgICAgICAgICAg ICAgICAgICAgIEFwcmlsIDIwMTkKCgogICBbUkZDNDg2OF0gIEtlbGx5LCBTLiBhbmQgUy4gRnJh bmtlbCwgIlVzaW5nIEhNQUMtU0hBLTI1NiwgSE1BQy1TSEEtCiAgICAgICAgICAgICAgMzg0LCBh bmQgSE1BQy1TSEEtNTEyIHdpdGggSVBzZWMiLCBSRkMgNDg2OCwKICAgICAgICAgICAgICBET0kg MTAuMTc0ODcvUkZDNDg2OCwgTWF5IDIwMDcsCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJm Yy1lZGl0b3Iub3JnL2luZm8vcmZjNDg2OD4uCgpBdXRob3JzJyBBZGRyZXNzZXMKCiAgIEdyZWcg TWlyc2t5CiAgIFpURSBDb3JwLgoKICAgRW1haWw6IGdyZWdpbWlyc2t5QGdtYWlsLmNvbQoKCiAg IEd1byBKdW4KICAgWlRFIENvcnBvcmF0aW9uCiAgIDY4IyBaaWppbmdodWEgUm9hZAogICBOYW5q aW5nLCBKaWFuZ3N1ICAyMTAwMTIKICAgUC5SLkNoaW5hCgogICBQaG9uZTogKzg2IDE4MTA1MTgz NjYzCiAgIEVtYWlsOiBndW8uanVuMkB6dGUuY29tLmNuCgoKICAgSGVucmlrIE55ZGVsbAogICBB Y2NlZGlhbiBOZXR3b3JrcwoKICAgRW1haWw6IGhueWRlbGxAYWNjZWRpYW4uY29tCgoKICAgUmlj aGFyZCBGb290ZQogICBOb2tpYQoKICAgRW1haWw6IGZvb3Rlci5mb290ZUBub2tpYS5jb20KCgoK CgoKCgoKCgoKCgoKCgoKTWlyc2t5LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDI0 LCAyMDE5ICAgICAgICAgICAgICAgW1BhZ2UgMTVdCg== --000000000000d0001a0587216a08 Content-Type: text/html; charset="UTF-8"; name="Diff_ draft-ietf-ippm-stamp-05.txt - draft-ietf-ippm-stamp-06.txt.html" Content-Disposition: attachment; filename="Diff_ draft-ietf-ippm-stamp-05.txt - draft-ietf-ippm-stamp-06.txt.html" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_juslwev60 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPgo8IS0tIHNhdmVkIGZyb20gdXJsPSgwMDQyKWh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9y ZmNkaWZmL3JmY2RpZmYucHlodCAtLT4KPGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5 OTkveGh0bWwiIGNsYXNzPSJncl9fd3d3Nl9pZXRmX29yZyI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPiAKICAg CiAgPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1TdHlsZS1UeXBlIiBjb250ZW50PSJ0ZXh0L2Nz cyI+IAogIDx0aXRsZT5EaWZmOiBkcmFmdC1pZXRmLWlwcG0tc3RhbXAtMDUudHh0IC0gZHJhZnQt aWV0Zi1pcHBtLXN0YW1wLTA2LnR4dDwvdGl0bGU+IAogIDxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+ IAogICAgYm9keSAgICB7IG1hcmdpbjogMC40ZXg7IG1hcmdpbi1yaWdodDogYXV0bzsgfSAKICAg IHRyICAgICAgeyB9IAogICAgdGQgICAgICB7IHdoaXRlLXNwYWNlOiBwcmU7IGZvbnQtZmFtaWx5 OiBtb25vc3BhY2U7IHZlcnRpY2FsLWFsaWduOiB0b3A7IGZvbnQtc2l6ZTogMC44NmVtO30gCiAg ICB0aCAgICAgIHsgZm9udC1zaXplOiAwLjg2ZW07IH0gCiAgICAuc21hbGwgIHsgZm9udC1zaXpl OiAwLjZlbTsgZm9udC1zdHlsZTogaXRhbGljOyBmb250LWZhbWlseTogVmVyZGFuYSwgSGVsdmV0 aWNhLCBzYW5zLXNlcmlmOyB9IAogICAgLmxlZnQgICB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7 IH0gCiAgICAucmlnaHQgIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgfSAKICAgIC5kaWZmICAg eyBiYWNrZ3JvdW5kLWNvbG9yOiAjQ0NGOyB9IAogICAgLmxibG9jayB7IGJhY2tncm91bmQtY29s b3I6ICNCRkI7IH0gCiAgICAucmJsb2NrIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGODsgfSAKICAg IC5pbnNlcnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjOEZGOyB9IAogICAgLmRlbGV0ZSB7IGJhY2tn cm91bmQtY29sb3I6ICNBQ0Y7IH0gCiAgICAudm9pZCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZG QjsgfSAKICAgIC5jb250ICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxpbmVi ciB7IGJhY2tncm91bmQtY29sb3I6ICNBQUE7IH0gCiAgICAubGluZW5vIHsgY29sb3I6IHJlZDsg YmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgZm9udC1zaXplOiAwLjdlbTsgdGV4dC1hbGlnbjogcmln aHQ7IHBhZGRpbmc6IDAgMnB4OyB9IAogICAgLmVsaXBzaXN7IGJhY2tncm91bmQtY29sb3I6ICNB QUE7IH0gCiAgICAubGVmdCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICNEREQ7IH0gCiAgICAu cmlnaHQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxibG9jayAuY29u dCB7IGJhY2tncm91bmQtY29sb3I6ICM5RDk7IH0gCiAgICAucmJsb2NrIC5jb250IHsgYmFja2dy b3VuZC1jb2xvcjogI0RENjsgfSAKICAgIC5pbnNlcnQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9y OiAjMEREOyB9IAogICAgLmRlbGV0ZSAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICM4QUQ7IH0g CiAgICAuc3RhdHMsIC5zdGF0cyB0ZCwgLnN0YXRzIHRoIHsgYmFja2dyb3VuZC1jb2xvcjogI0VF RTsgcGFkZGluZzogMnB4IDA7IH0gCiAgICBzcGFuLmhpZGUgeyBkaXNwbGF5OiBub25lOyBjb2xv cjogI2FhYTt9ICAgIGE6aG92ZXIgc3BhbiB7IGRpc3BsYXk6IGlubGluZTsgfSAgICB0ci5jaGFu Z2UgeyBiYWNrZ3JvdW5kLWNvbG9yOiBncmF5OyB9IAogICAgdHIuY2hhbmdlIGEgeyB0ZXh0LWRl Y29yYXRpb246IG5vbmU7IGNvbG9yOiBibGFjayB9IAogIDwvc3R5bGU+IAogICAgIDxzY3JpcHQ+ CnZhciBjaHVua19pbmRleCA9IDA7CnZhciBvbGRfY2h1bmsgPSBudWxsOwoKZnVuY3Rpb24gZm9y bWF0X2NodW5rKGluZGV4KSB7CiAgICB2YXIgcHJlZml4ID0gImRpZmYiOwogICAgdmFyIHN0ciA9 IGluZGV4LnRvU3RyaW5nKCk7CiAgICBmb3IgKHg9MDsgeDwoNC1zdHIubGVuZ3RoKTsgKyt4KSB7 CiAgICAgICAgcHJlZml4Kz0nMCc7CiAgICB9CiAgICByZXR1cm4gcHJlZml4ICsgc3RyOwp9Cgpm dW5jdGlvbiBmaW5kX2NodW5rKG4pewogICAgcmV0dXJuIGRvY3VtZW50LnF1ZXJ5U2VsZWN0b3Io J3RyW2lkJD0iJyArIG4gKyAnIl0nKTsKfQoKZnVuY3Rpb24gY2hhbmdlX2NodW5rKG9mZnNldCkg ewogICAgdmFyIGluZGV4ID0gY2h1bmtfaW5kZXggKyBvZmZzZXQ7CiAgICB2YXIgbmV3X3N0cjsK ICAgIHZhciBuZXdfY2h1bms7CgogICAgbmV3X3N0ciA9IGZvcm1hdF9jaHVuayhpbmRleCk7CiAg ICBuZXdfY2h1bmsgPSBmaW5kX2NodW5rKG5ld19zdHIpOwogICAgaWYgKCFuZXdfY2h1bmspIHsK ICAgICAgICByZXR1cm47CiAgICB9CiAgICBpZiAob2xkX2NodW5rKSB7CiAgICAgICAgb2xkX2No dW5rLnN0eWxlLm91dGxpbmUgPSAiIjsKICAgIH0KICAgIG9sZF9jaHVuayA9IG5ld19jaHVuazsK ICAgIG9sZF9jaHVuay5zdHlsZS5vdXRsaW5lID0gIjFweCBzb2xpZCByZWQiOwogICAgd2luZG93 LmxvY2F0aW9uLnJlcGxhY2UoIiMiICsgbmV3X3N0cikKICAgIHdpbmRvdy5zY3JvbGxCeSgwLC0x MDApOwogICAgY2h1bmtfaW5kZXggPSBpbmRleDsKfQoKZG9jdW1lbnQub25rZXlkb3duID0gZnVu Y3Rpb24oZSkgewogICAgc3dpdGNoIChlLmtleUNvZGUpIHsKICAgIGNhc2UgNzg6CiAgICAgICAg Y2hhbmdlX2NodW5rKDEpOwogICAgICAgIGJyZWFrOwogICAgY2FzZSA4MDoKICAgICAgICBjaGFu Z2VfY2h1bmsoLTEpOwogICAgICAgIGJyZWFrOwogICAgfQp9OwogICA8L3NjcmlwdD4gCjwvaGVh ZD4gCjxib2R5IGRhdGEtZ3ItYy1zLWxvYWRlZD0idHJ1ZSI+IAogIDx0YWJsZSBib3JkZXI9IjAi IGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+IAogIDx0Ym9keT48dHIgaWQ9InBhcnQt MSIgYmdjb2xvcj0ib3JhbmdlIj48dGg+PC90aD48dGg+PGEgaHJlZj0iaHR0cHM6Ly93d3c2Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWlwcG0tc3RhbXAtMDUudHh0IiBzdHlsZT0i Y29sb3I6IzAwODsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij4mbHQ7PC9hPiZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlwcG0tc3RhbXAtMDUudHh0 IiBzdHlsZT0iY29sb3I6IzAwOCI+ZHJhZnQtaWV0Zi1pcHBtLXN0YW1wLTA1LnR4dDwvYT4mbmJz cDs8L3RoPjx0aD4gPC90aD48dGg+Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtaXBwbS1zdGFtcC0wNi50eHQiIHN0eWxlPSJjb2xvcjojMDA4Ij5k cmFmdC1pZXRmLWlwcG0tc3RhbXAtMDYudHh0PC9hPiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3 Ni5pZXRmLm9yZy9yZmNkaWZmP3VybDE9ZHJhZnQtaWV0Zi1pcHBtLXN0YW1wLTA2LnR4dCIgc3R5 bGU9ImNvbG9yOiMwMDg7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+Jmd0OzwvYT48L3RoPjx0aD48 L3RoPjwvdHI+IAogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEcuIE1pcnNreTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi Pk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEcuIE1pcnNreTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+SW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWlRFIENv cnAuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+SW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWlRFIENvcnAuPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5JbnRlbmRlZCBzdGF0dXM6IFN0YW5kYXJkcyBUcmFjayAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHLiBKdW48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij5JbnRlbmRlZCBzdGF0dXM6IFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBHLiBKdW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDEiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+RXhwaXJlczogPHNwYW4g Y2xhc3M9ImRlbGV0ZSI+SnVuZSAxLCAyMDE5ICAgIDwvc3Bhbj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFpURSBDb3Jwb3JhdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj5FeHBpcmVzOiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5PY3RvYmVyIDI0LCAyMDE5PC9zcGFu PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWlRFIENvcnBvcmF0aW9uPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBILiBOeWRlbGw8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBILiBOeWRlbGw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBY2Nl ZGlhbiBOZXR3b3JrczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBY2NlZGlhbiBOZXR3 b3JrczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFIuIEZvb3RlPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFIuIEZvb3RlPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgTm9raWE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgTm9raWE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0ciBpZD0iZGlmZjAwMDIiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPk5vdmVtYmVy IDI4LCAyMDE4PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHNwYW4gY2xh c3M9Imluc2VydCI+ICAgQXByaWwgMjIsIDIwMTk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgIFNpbXBsZSBUd28td2F5IEFjdGl2ZSBNZWFzdXJl bWVudCBQcm90b2NvbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAg ICAgIFNpbXBsZSBUd28td2F5IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwMyI+PHRkPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICAgICAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLWlwcG0tc3RhbXAtMDxzcGFuIGNs YXNzPSJkZWxldGUiPjU8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg ICAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtaXBwbS1zdGFtcC0wPHNwYW4gY2xhc3M9 Imluc2VydCI+Njwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+QWJzdHJh Y3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5BYnN0cmFjdDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIFNpbXBsZSBU d28td2F5IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgU2ltcGxlIFR3by13YXkgQWN0 aXZlIE1lYXN1cmVtZW50IFByb3RvY29sPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB3 aGljaCBlbmFibGVzIHRoZSBtZWFzdXJlbWVudCBvZiBib3RoIG9uZS13YXkgYW5kIHJvdW5kLXRy aXA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB3aGljaCBlbmFibGVzIHRoZSBt ZWFzdXJlbWVudCBvZiBib3RoIG9uZS13YXkgYW5kIHJvdW5kLXRyaXA8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIHBlcmZvcm1hbmNlIG1ldHJpY3MgbGlrZSBkZWxheSwgZGVsYXkgdmFy aWF0aW9uLCBhbmQgcGFja2V0IGxvc3MuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgcGVyZm9ybWFuY2UgbWV0cmljcyBsaWtlIGRlbGF5LCBkZWxheSB2YXJpYXRpb24sIGFuZCBw YWNrZXQgbG9zcy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+U3RhdHVzIG9mIFRo aXMgTWVtbzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPlN0YXR1cyBvZiBUaGlzIE1l bW88L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBJbnRlcm5ldC1EcmFm dCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGlu IGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTIiIGNsYXNzPSJjaGFuZ2UiPjx0ZD48L3RkPjx0 aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3 dzYuaWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQjcGFydC0yIj48ZW0+IHBhZ2UgMSwgbGlu ZSAzNzxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGg+IDwvdGg+ PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0dHBzOi8v d3d3Ni5pZXRmLm9yZy9yZmNkaWZmL3JmY2RpZmYucHlodCNwYXJ0LTIiPjxlbT4gcGFnZSAxLCBs aW5lIDM3PHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0 IEVuZ2luZWVyaW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW50ZXJuZXQt RHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmc8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0 aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBz IG1heSBhbHNvIGRpc3RyaWJ1dGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHdvcmtp bmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50 ZXJuZXQtPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgd29ya2luZyBkb2N1bWVu dHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC08L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIERyYWZ0cyBpcyBhdCBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBEcmFmdHMgaXMgYXQgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMv Y3VycmVudC8uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEludGVybmV0LURy YWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRo czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEludGVybmV0LURyYWZ0cyBhcmUg ZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRoczwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Ig b2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQg Ynkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg dGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZl cmVuY2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0aW1lLiAgSXQgaXMgaW5h cHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4g YXMgIndvcmsgaW4gcHJvZ3Jlc3MuIjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNz LiI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJk aWZmMDAwNCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9u IDxzcGFuIGNsYXNzPSJkZWxldGUiPkp1bmUgMTwvc3Bhbj4sIDIwMTkuPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24g PHNwYW4gY2xhc3M9Imluc2VydCI+T2N0b2JlciAyNDwvc3Bhbj4sIDIwMTkuPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPkNvcHlyaWdodCBOb3RpY2U8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij5Db3B5cmlnaHQgTm90aWNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDUiPjx0ZD48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgQ29weXJp Z2h0IChjKSAyMDE8c3BhbiBjbGFzcz0iZGVsZXRlIj44PC9zcGFuPiBJRVRGIFRydXN0IGFuZCB0 aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICBDb3B5cmlnaHQgKGMpIDIwMTxzcGFuIGNsYXNzPSJpbnNlcnQiPjk8L3NwYW4+IElF VEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkb2N1bWVudCBhdXRob3JzLiAgQWxs IHJpZ2h0cyByZXNlcnZlZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhp cyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdh bDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgZG9jdW1lbnQgaXMgc3Vi amVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWw8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHM8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElF VEYgRG9jdW1lbnRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAoaHR0cHM6Ly90cnVz dGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKGh0dHBzOi8vdHJ1c3RlZS5pZXRmLm9yZy9s aWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcg dGhlc2UgZG9jdW1lbnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcHVibGlj YXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUg eW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3Q8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdo dHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20g dGhpcyBkb2N1bWVudCBtdXN0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdG8g dGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3Vt ZW50IG11c3Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGluY2x1ZGUgU2ltcGxpZmll ZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5z ZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3 aXRob3V0IHdhcnJhbnR5IGFzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhl IFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5 IGFzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0i cGFydC0zIiBjbGFzcz0iY2hhbmdlIj48dGQ+PC90ZD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNo YW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93d3c2LmlldGYub3JnL3JmY2RpZmYvcmZj ZGlmZi5weWh0I3BhcnQtMyI+PGVtPiBwYWdlIDIsIGxpbmUgMTk8c3BhbiBjbGFzcz0iaGlkZSI+ IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48c21hbGw+c2tpcHBpbmcgdG8g Y2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3dzYuaWV0Zi5vcmcvcmZjZGlmZi9y ZmNkaWZmLnB5aHQjcGFydC0zIj48ZW0+IHBhZ2UgMiwgbGluZSAxOTxzcGFuIGNsYXNzPSJoaWRl Ij4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDEuICBJbnRyb2R1Y3Rp b24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDEuICBJbnRyb2R1Y3Rpb24gIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgMi4gIENvbnZlbnRpb25zIHVzZWQgaW4gdGhpcyBkb2N1bWVu dCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgMi4gIENvbnZlbnRpb25zIHVzZWQgaW4gdGhpcyBkb2N1bWVudCAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAg IDIuMS4gIFRlcm1pbm9sb2d5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgIDM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDIuMS4gIFRl cm1pbm9sb2d5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg IDM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgMi4yLiAgUmVxdWlyZW1lbnRzIExh bmd1YWdlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMzwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgMi4yLiAgUmVxdWlyZW1lbnRzIExhbmd1YWdlIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMzwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgMy4gIFNvZnR3YXJpemF0aW9uIG9mIFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50 IC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgMy4gIFNvZnR3YXJpemF0aW9uIG9mIFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50IC4gLiAuIC4g LiAuIC4gLiAuIC4gICAzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICA0LiAgVGhlb3J5 IG9mIE9wZXJhdGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg IDQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICA0LiAgVGhlb3J5IG9mIE9wZXJh dGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQ8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgNC4xLiAgU2Vzc2lvbi1TZW5kZXIgQmVoYXZpb3Ig YW5kIFBhY2tldCBGb3JtYXQgLiAuIC4gLiAuIC4gLiAuICAgNDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgNC4xLiAgU2Vzc2lvbi1TZW5kZXIgQmVoYXZpb3IgYW5kIFBhY2tl dCBGb3JtYXQgLiAuIC4gLiAuIC4gLiAuICAgNDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgIDQuMS4xLiAgU2Vzc2lvbi1TZW5kZXIgUGFja2V0IEZvcm1hdCBpbiBVbmF1dGhlbnRp Y2F0ZWQgTW9kZSAgICA0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgIDQu MS4xLiAgU2Vzc2lvbi1TZW5kZXIgUGFja2V0IEZvcm1hdCBpbiBVbmF1dGhlbnRpY2F0ZWQgTW9k ZSAgICA0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgNC4xLjIuICBTZXNzaW9u LVNlbmRlciBQYWNrZXQgRm9ybWF0IGluIEF1dGhlbnRpY2F0ZWQgTW9kZSAgLiAgIDc8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgNC4xLjIuICBTZXNzaW9uLVNlbmRlciBQ YWNrZXQgRm9ybWF0IGluIEF1dGhlbnRpY2F0ZWQgTW9kZSAgLiAgIDc8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDYiPjx0ZD48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg ICA0LjIuICBTZXNzaW9uLVJlZmxlY3RvciBCZWhhdmlvciBhbmQgUGFja2V0IEZvcm1hdCAgLiAu IC4gLiAuIC4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj43PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICAgIDQuMi4gIFNlc3Npb24tUmVmbGVjdG9yIEJlaGF2aW9yIGFu ZCBQYWNrZXQgRm9ybWF0ICAuIC4gLiAuIC4gLiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjg8L3Nw YW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgNC4yLjEuICBTZXNzaW9uLVJl ZmxlY3RvciBQYWNrZXQgRm9ybWF0IGluIFVuYXV0aGVudGljYXRlZDwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgICAgICA0LjIuMS4gIFNlc3Npb24tUmVmbGVjdG9yIFBhY2tldCBG b3JtYXQgaW4gVW5hdXRoZW50aWNhdGVkPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAg ICAgICAgICAgICBNb2RlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgIDg8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAg ICBNb2RlICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg IDg8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICA0LjIuMi4gIFNlc3Npb24tUmVm bGVjdG9yIFBhY2tldCBGb3JtYXQgaW4gQXV0aGVudGljYXRlZCBNb2RlICAxMDwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICA0LjIuMi4gIFNlc3Npb24tUmVmbGVjdG9yIFBh Y2tldCBGb3JtYXQgaW4gQXV0aGVudGljYXRlZCBNb2RlICAxMDwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgICA0LjMuICBJbnRlZ3JpdHkgYW5kIENvbmZpZGVudGlhbGl0eSBQcm90ZWN0 aW9uIGluIFNUQU1QIC4gLiAuIC4gIDEyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICA0LjMuICBJbnRlZ3JpdHkgYW5kIENvbmZpZGVudGlhbGl0eSBQcm90ZWN0aW9uIGluIFNU QU1QIC4gLiAuIC4gIDEyPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDQuNC4gIElu dGVyb3BlcmFiaWxpdHkgd2l0aCBUV0FNUCBMaWdodCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg MTI8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDQuNC4gIEludGVyb3BlcmFi aWxpdHkgd2l0aCBUV0FNUCBMaWdodCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTI8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDUuICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMzwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIDUuICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgNi4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gIDEzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgNi4gIFNl Y3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDEzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICA3LiAgQWNrbm93bGVkZ21lbnRz IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTM8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICA3LiAgQWNrbm93bGVkZ21lbnRzIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTM8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIDguICBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIDguICBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAxMzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICA4LjEu ICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDEzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICA4LjEuICBOb3JtYXRp dmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEzPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDguMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5j ZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTQ8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDguMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDciPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgQXV0aG9ycycg QWRkcmVzc2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g IDE8c3BhbiBjbGFzcz0iZGVsZXRlIj40PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICBBdXRob3JzJyBBZGRyZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgMTxzcGFuIGNsYXNzPSJpbnNlcnQiPjU8L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjEuICBJbnRyb2R1Y3Rpb248L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4xLiAgSW50cm9kdWN0aW9uPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIERldmVsb3BtZW50IGFuZCBkZXBsb3ltZW50IG9mIFR3by1XYXkgQWN0 aXZlIE1lYXN1cmVtZW50IFByb3RvY29sPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgRGV2ZWxvcG1lbnQgYW5kIGRlcGxveW1lbnQgb2YgVHdvLVdheSBBY3RpdmUgTWVhc3VyZW1l bnQgUHJvdG9jb2w8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIChUV0FNUCkgW1JGQzUz NTddIGFuZCBpdHMgZXh0ZW5zaW9ucywgZS5nLiwgW1JGQzYwMzhdIHRoYXQgZGVmaW5lZDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIChUV0FNUCkgW1JGQzUzNTddIGFuZCBpdHMg ZXh0ZW5zaW9ucywgZS5nLiwgW1JGQzYwMzhdIHRoYXQgZGVmaW5lZDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgZmVhdHVyZXMgc3VjaCBhcyBSZWZsZWN0IE9jdGV0cyBhbmQgU3ltbWV0 cmljYWwgU2l6ZSBmb3IgVFdBTVA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBm ZWF0dXJlcyBzdWNoIGFzIFJlZmxlY3QgT2N0ZXRzIGFuZCBTeW1tZXRyaWNhbCBTaXplIGZvciBU V0FNUDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcHJvdmlkZWQgaW52YWx1YWJsZSBl eHBlcmllbmNlLiAgU2V2ZXJhbCBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbnM8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBwcm92aWRlZCBpbnZhbHVhYmxlIGV4cGVyaWVuY2Uu ICBTZXZlcmFsIGluZGVwZW5kZW50IGltcGxlbWVudGF0aW9uczwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgZXhpc3QsIGhhdmUgYmVlbiBkZXBsb3llZCBhbmQgcHJvdmlkZSBpbXBvcnRh bnQgb3BlcmF0aW9uYWw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBleGlzdCwg aGF2ZSBiZWVuIGRlcGxveWVkIGFuZCBwcm92aWRlIGltcG9ydGFudCBvcGVyYXRpb25hbDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnRzLiAgQXQg dGhlIHNhbWUgdGltZSwgdGhlcmUgaGFzIGJlZW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBwZXJmb3JtYW5jZSBtZWFzdXJlbWVudHMuICBBdCB0aGUgc2FtZSB0aW1lLCB0aGVy ZSBoYXMgYmVlbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbm90aWNlYWJsZSBpbnRl cmVzdCBpbiB1c2luZyBhIHNpbXBsZXIgbWVjaGFuaXNtIGZvciBhY3RpdmU8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBub3RpY2VhYmxlIGludGVyZXN0IGluIHVzaW5nIGEgc2lt cGxlciBtZWNoYW5pc20gZm9yIGFjdGl2ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg cGVyZm9ybWFuY2UgbW9uaXRvcmluZyB0aGF0IGNhbiBwcm92aWRlIGRldGVybWluaXN0aWMgYmVo YXZpb3IgYW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcGVyZm9ybWFuY2Ug bW9uaXRvcmluZyB0aGF0IGNhbiBwcm92aWRlIGRldGVybWluaXN0aWMgYmVoYXZpb3IgYW5kPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpbmhlcml0IHNlcGFyYXRpb24gb2YgY29udHJv bCAodmVuZG9yLXNwZWNpZmljIGNvbmZpZ3VyYXRpb24gb3I8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBpbmhlcml0IHNlcGFyYXRpb24gb2YgY29udHJvbCAodmVuZG9yLXNwZWNp ZmljIGNvbmZpZ3VyYXRpb24gb3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG9yY2hl c3RyYXRpb24pIGFuZCB0ZXN0IGZ1bmN0aW9ucy4gIE9uZSBvZiBzdWNoIGlzIFBlcmZvcm1hbmNl PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgb3JjaGVzdHJhdGlvbikgYW5kIHRl c3QgZnVuY3Rpb25zLiAgT25lIG9mIHN1Y2ggaXMgUGVyZm9ybWFuY2U8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIE1lYXN1cmVtZW50IGZyb20gSVAgRWRnZSB0byBDdXN0b21lciBFcXVp cG1lbnQgdXNpbmcgVFdBTVAgTGlnaHQgZnJvbTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIE1lYXN1cmVtZW50IGZyb20gSVAgRWRnZSB0byBDdXN0b21lciBFcXVpcG1lbnQgdXNp bmcgVFdBTVAgTGlnaHQgZnJvbTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyIGlkPSJkaWZmMDAwOCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBCcm9hZGJhbmQgRm9ydW0gPHNwYW4g Y2xhc3M9ImRlbGV0ZSI+KFtCQkYuVFItMzkwXSkuPC9zcGFuPiAgVGhpcyBkb2N1bWVudCBkZWZp bmVzIGFjdGl2ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBCcm9hZGJhbmQg Rm9ydW0gPHNwYW4gY2xhc3M9Imluc2VydCI+W0JCRi5UUi0zOTBdIHVzZWQgYXMgdGhlIHJlZmVy ZW5jZSBUV0FNUCBMaWdodCB0aGF0LDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnQgdGVzdCBwcm90b2NvbCwgU2ltcGxlIFR3by13 YXkgQWN0aXZlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJp bnNlcnQiPiAgIGFjY29yZGluZyB0byBbUkZDODU0NV0sIGluY2x1ZGVzIHN1Yi1zZXQgb2YgVFdB TVAtVGVzdCBmdW5jdGlvbnMgaW48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgIE1lYXN1cmVtZW50IFByb3RvY29sIChTVEFNUCksIHRoYXQgZW5hYmxlcyBtZWFzdXJlbWVu dCBvZiBib3RoIDxzcGFuIGNsYXNzPSJkZWxldGUiPm9uZS08L3NwYW4+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGNvbWJpbmF0aW9uIHdp dGggb3RoZXIgYXBwbGljYXRpb25zIHRoYXQgcHJvdmlkZSwgZm9yIGV4YW1wbGUsPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICB3YXk8 L3NwYW4+IGFuZCByb3VuZC10cmlwIHBlcmZvcm1hbmNlIG1ldHJpY3MgbGlrZSBkZWxheSwgZGVs YXkgdmFyaWF0aW9uLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFz cz0iaW5zZXJ0Ij4gICBjb250cm9sIGFuZCBzZWN1cml0eS48L3NwYW4+ICBUaGlzIGRvY3VtZW50 IGRlZmluZXMgYWN0aXZlIHBlcmZvcm1hbmNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgIGFuZCBwYWNrZXQgbG9zcy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg bWVhc3VyZW1lbnQgdGVzdCBwcm90b2NvbCwgU2ltcGxlIFR3by13YXkgQWN0aXZlIE1lYXN1cmVt ZW50IFByb3RvY29sPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gICAoU1RBTVApLCB0aGF0IGVuYWJsZXMgbWVhc3VyZW1lbnQg b2YgYm90aCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5vbmUtd2F5PC9zcGFuPiBhbmQgcm91bmQtdHJp cDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgcGVyZm9ybWFuY2UgbWV0cmljcyBsaWtlIGRlbGF5LCBkZWxheSB2YXJpYXRp b24sIGFuZCBwYWNrZXQgbG9zcy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Mi4g IENvbnZlbnRpb25zIHVzZWQgaW4gdGhpcyBkb2N1bWVudDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjIuICBDb252ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9jdW1lbnQ8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Mi4xLiAgVGVybWlub2xvZ3k8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4yLjEuICBUZXJtaW5vbG9neTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBBRVMgQWR2YW5jZWQgRW5jcnlwdGlvbiBTdGFuZGFyZDwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEFFUyBBZHZhbmNlZCBFbmNyeXB0aW9uIFN0YW5kYXJk PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIENCQyBDaXBoZXIgQmxvY2sgQ2hh aW5pbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBDQkMgQ2lwaGVyIEJsb2Nr IENoYWluaW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEVDQiBFbGVjdHJv bmljIENvb2tib29rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRUNCIEVsZWN0 cm9uaWMgQ29va2Jvb2s8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyIGlkPSJwYXJ0LTQiIGNsYXNzPSJjaGFuZ2UiPjx0ZD48L3RkPjx0aD48c21hbGw+c2tp cHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3dzYuaWV0Zi5vcmcv cmZjZGlmZi9yZmNkaWZmLnB5aHQjcGFydC00Ij48ZW0+IHBhZ2UgMywgbGluZSA0MzxzcGFuIGNs YXNzPSJoaWRlIj4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5z a2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0dHBzOi8vd3d3Ni5pZXRmLm9y Zy9yZmNkaWZmL3JmY2RpZmYucHlodCNwYXJ0LTQiPjxlbT4gcGFnZSAzLCBsaW5lIDQ1PHNwYW4g Y2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICJPUFRJT05B TCIgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGlu IEJDUDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICJPUFRJT05BTCIgaW4gdGhp cyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIEJDUDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgMTQgW1JGQzIxMTldIFtSRkM4MTc0XSB3aGVuLCBh bmQgb25seSB3aGVuLCB0aGV5IGFwcGVhciBpbiBhbGw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAxNCBbUkZDMjExOV0gW1JGQzgxNzRdIHdoZW4sIGFuZCBvbmx5IHdoZW4sIHRo ZXkgYXBwZWFyIGluIGFsbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY2FwaXRhbHMs IGFzIHNob3duIGhlcmUuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgY2FwaXRh bHMsIGFzIHNob3duIGhlcmUuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjMuICBT b2Z0d2FyaXphdGlvbiBvZiBQZXJmb3JtYW5jZSBNZWFzdXJlbWVudDwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjMuICBTb2Z0d2FyaXphdGlvbiBvZiBQZXJmb3JtYW5jZSBNZWFzdXJl bWVudDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBGaWd1cmUgMSBwcmVzZW50 cyBTaW1wbGUgVHdvLXdheSBBY3RpdmUgTWVhc3VyZW1lbnQgUHJvdG9jb2wgKFNUQU1QKTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEZpZ3VyZSAxIHByZXNlbnRzIFNpbXBsZSBU d28td2F5IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbCAoU1RBTVApPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBTZXNzaW9uLVNlbmRlciBhbmQgU2Vzc2lvbi1SZWZsZWN0b3Igd2l0 aCBhIG1lYXN1cmVtZW50IHNlc3Npb24uICBUaGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBTZXNzaW9uLVNlbmRlciBhbmQgU2Vzc2lvbi1SZWZsZWN0b3Igd2l0aCBhIG1lYXN1 cmVtZW50IHNlc3Npb24uICBUaGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGNvbmZp Z3VyYXRpb24gYW5kIG1hbmFnZW1lbnQgb2YgdGhlIFNUQU1QIFNlc3Npb24tU2VuZGVyLCBTZXNz aW9uLTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNvbmZpZ3VyYXRpb24gYW5k IG1hbmFnZW1lbnQgb2YgdGhlIFNUQU1QIFNlc3Npb24tU2VuZGVyLCBTZXNzaW9uLTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUmVmbGVjdG9yIGFuZCBtYW5hZ2VtZW50IG9mIHRoZSBT VEFNUCBzZXNzaW9ucyBjYW4gYmUgYWNoaWV2ZWQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBSZWZsZWN0b3IgYW5kIG1hbmFnZW1lbnQgb2YgdGhlIFNUQU1QIHNlc3Npb25zIGNh biBiZSBhY2hpZXZlZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy IGlkPSJkaWZmMDAwOSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICB0aHJvdWdoIHZhcmlvdXMgbWVhbnMuICBDb21t YW5kIExpbmUgSW50ZXJmYWNlLCBPU1MvQlNTIHVzaW5nIFNOTVAgb3I8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgdGhyb3VnaCB2YXJpb3VzIG1lYW5zLiAgQ29tbWFuZCBMaW5l IEludGVyZmFjZSwgT1NTL0JTUyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij4ob3BlcmF0aW9uczwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ U0ROPC9zcGFuPiB1c2luZyBOZXRjb25mL1lBTkcgYXJlIGJ1dCBhIGZldyBleGFtcGxlcy48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgc3Vw cG9ydCBzeXN0ZW0vYnVzaW5lc3Mgc3VwcG9ydCBzeXN0ZW0gYXMgYSBjb21iaW5hdGlvbiBvZiB0 d288L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBzeXN0ZW1zIHVzZWQgdG8g c3VwcG9ydCBhIHJhbmdlIG9mIHRlbGVjb21tdW5pY2F0aW9uIHNlcnZpY2VzKTwvc3Bhbj4gdXNp bmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgIFNOTVAgb3IgPHNwYW4gY2xhc3M9Imluc2VydCI+Y29udHJvbGxlcnMgaW4g U29mdHdhcmUtRGVmaW5lZCBOZXR3b3JraW5nPC9zcGFuPiB1c2luZyBOZXRjb25mL1lBTkc8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgIGFyZSBidXQgYSBmZXcgZXhhbXBsZXMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgICAgIG8tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tbzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg ICAgIG8tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tbzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICBDb25maWd1cmF0aW9uIGFuZCAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICBD b25maWd1cmF0aW9uIGFuZCAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgIE1hbmFnZW1lbnQgICAg ICAgICAgICAgICAgICAgICAgIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgIE1hbmFnZW1lbnQgICAgICAgICAgICAgICAg ICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgIG8tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tbzwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgIG8tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tbzwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgICAgICAgICAgICAgIHx8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAg ICAgICAgfHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8fDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgIHx8ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAgICAgICAgICAgICAgfHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8fDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgIHx8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfHw8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgfHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8fDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICArLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSsgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0rPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIHwgU1RBTVAgU2Vzc2lvbi1TZW5k ZXIgfCAmbHQ7LS0tIFNUQU1QLS0tJmd0OyB8IFNUQU1QIFNlc3Npb24tUmVmbGVjdG9yIHw8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIHwgU1RBTVAgU2Vzc2lvbi1TZW5kZXIg fCAmbHQ7LS0tIFNUQU1QLS0tJmd0OyB8IFNUQU1QIFNlc3Npb24tUmVmbGVjdG9yIHw8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTUiIGNs YXNzPSJjaGFuZ2UiPjx0ZD48L3RkPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9z bWFsbD48YSBocmVmPSJodHRwczovL3d3dzYuaWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQj cGFydC01Ij48ZW0+IHBhZ2UgNCwgbGluZSAyODxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8L3NwYW4+ PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8 L3NtYWxsPjxhIGhyZWY9Imh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9yZmNkaWZmL3JmY2RpZmYucHlo dCNwYXJ0LTUiPjxlbT4gcGFnZSA0LCBsaW5lIDI4PHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bh bj48L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjQuICBUaGVvcnkgb2YgT3BlcmF0aW9uPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+NC4gIFRoZW9yeSBvZiBPcGVyYXRpb248L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgU1RBTVAgU2Vzc2lvbi1TZW5kZXIgdHJhbnNtaXRz IHRlc3QgcGFja2V0cyB0b3dhcmQgU1RBTVAgU2Vzc2lvbi08L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBTVEFNUCBTZXNzaW9uLVNlbmRlciB0cmFuc21pdHMgdGVzdCBwYWNrZXRz IHRvd2FyZCBTVEFNUCBTZXNzaW9uLTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgUmVm bGVjdG9yLiAgU1RBTVAgU2Vzc2lvbi1SZWZsZWN0b3IgcmVjZWl2ZXMgU2Vzc2lvbi1TZW5kZXIn cyBwYWNrZXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBSZWZsZWN0b3IuICBT VEFNUCBTZXNzaW9uLVJlZmxlY3RvciByZWNlaXZlcyBTZXNzaW9uLVNlbmRlcidzIHBhY2tldDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYW5kIGFjdHMgYWNjb3JkaW5nIHRvIHRoZSBj b25maWd1cmF0aW9uIGFuZCBvcHRpb25hbCBjb250cm9sPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgYW5kIGFjdHMgYWNjb3JkaW5nIHRvIHRoZSBjb25maWd1cmF0aW9uIGFuZCBv cHRpb25hbCBjb250cm9sPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpbmZvcm1hdGlv biBjb21tdW5pY2F0ZWQgaW4gdGhlIFNlc3Npb24tU2VuZGVyJ3MgdGVzdCBwYWNrZXQuICBTVEFN UDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGluZm9ybWF0aW9uIGNvbW11bmlj YXRlZCBpbiB0aGUgU2Vzc2lvbi1TZW5kZXIncyB0ZXN0IHBhY2tldC4gIFNUQU1QPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkZWZpbmVzIHR3byBkaWZmZXJlbnQgdGVzdCBwYWNrZXQg Zm9ybWF0cywgb25lIGZvciBwYWNrZXRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgZGVmaW5lcyB0d28gZGlmZmVyZW50IHRlc3QgcGFja2V0IGZvcm1hdHMsIG9uZSBmb3IgcGFj a2V0czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdHJhbnNtaXR0ZWQgYnkgdGhlIFNU QU1QLVNlc3Npb24tU2VuZGVyIGFuZCBvbmUgZm9yIHBhY2tldHM8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICB0cmFuc21pdHRlZCBieSB0aGUgU1RBTVAtU2Vzc2lvbi1TZW5kZXIg YW5kIG9uZSBmb3IgcGFja2V0czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdHJhbnNt aXR0ZWQgYnkgdGhlIFNUQU1QLVNlc3Npb24tUmVmbGVjdG9yLiAgU1RBTVAgc3VwcG9ydHMgdHdv PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdHJhbnNtaXR0ZWQgYnkgdGhlIFNU QU1QLVNlc3Npb24tUmVmbGVjdG9yLiAgU1RBTVAgc3VwcG9ydHMgdHdvPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBtb2RlczogdW5hdXRoZW50aWNhdGVkIGFuZCBhdXRoZW50aWNhdGVk LiAgVW5hdXRoZW50aWNhdGVkIFNUQU1QIHRlc3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBtb2RlczogdW5hdXRoZW50aWNhdGVkIGFuZCBhdXRoZW50aWNhdGVkLiAgVW5hdXRo ZW50aWNhdGVkIFNUQU1QIHRlc3Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0ciBpZD0iZGlmZjAwMTAiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ cGFja2V0cyBhcmUgY29tcGF0aWJsZSBvbiB0aGUgd2lyZSB3aXRoIHVuYXV0aGVudGljYXRlZCBU V0FNUC1UZXN0PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA8c3Bh biBjbGFzcz0iaW5zZXJ0Ij5wYWNrZXRzLCBkZWZpbmVkIGluIFNlY3Rpb24gNC4xLjEgYW5kIFNl Y3Rpb24gNC4yLjEsIGVuc3VyZTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgW1JGQzUzNTddPC9zcGFuPiBwYWNrZXQgZm9ybWF0cy48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAg aW50ZXJ3b3JraW5nIGJldHdlZW4gU1RBTVAgYW5kIFRXQU1QIExpZ2h0IGFzIGRlc2NyaWJlZCBp bjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIFNlY3Rpb24gNC40Ljwvc3Bh bj4gIHBhY2tldCBmb3JtYXRzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBC eSBkZWZhdWx0LCBTVEFNUCB1c2VzIHN5bW1ldHJpY2FsIHBhY2tldHMsIGkuZS4sIHNpemUgb2Yg dGhlIHBhY2tldDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEJ5IGRlZmF1bHQs IFNUQU1QIHVzZXMgc3ltbWV0cmljYWwgcGFja2V0cywgaS5lLiwgc2l6ZSBvZiB0aGUgcGFja2V0 PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0cmFuc21pdHRlZCBieSBTZXNzaW9uLVJl ZmxlY3RvciBlcXVhbHMgdGhlIHNpemUgb2YgdGhlIHBhY2tldDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIHRyYW5zbWl0dGVkIGJ5IFNlc3Npb24tUmVmbGVjdG9yIGVxdWFscyB0 aGUgc2l6ZSBvZiB0aGUgcGFja2V0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICByZWNl aXZlZCBieSB0aGUgU2Vzc2lvbi1SZWZsZWN0b3IuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgcmVjZWl2ZWQgYnkgdGhlIFNlc3Npb24tUmVmbGVjdG9yLjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij40LjEuICBTZXNzaW9uLVNlbmRlciBCZWhhdmlvciBhbmQgUGFj a2V0IEZvcm1hdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjQuMS4gIFNlc3Npb24t U2VuZGVyIEJlaGF2aW9yIGFuZCBQYWNrZXQgRm9ybWF0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjQuMS4xLiAgU2Vzc2lvbi1TZW5kZXIgUGFja2V0IEZvcm1hdCBpbiBVbmF1dGhl bnRpY2F0ZWQgTW9kZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjQuMS4xLiAgU2Vz c2lvbi1TZW5kZXIgUGFja2V0IEZvcm1hdCBpbiBVbmF1dGhlbnRpY2F0ZWQgTW9kZTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBCZWNhdXNlIFNUQU1QIHN1cHBvcnRzIHN5bW1l dHJpY2FsIHRlc3QgcGFja2V0cywgU1RBTVAgU2Vzc2lvbi1TZW5kZXI8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBCZWNhdXNlIFNUQU1QIHN1cHBvcnRzIHN5bW1ldHJpY2FsIHRl c3QgcGFja2V0cywgU1RBTVAgU2Vzc2lvbi1TZW5kZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTYiIGNsYXNzPSJjaGFuZ2UiPjx0ZD48 L3RkPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRw czovL3d3dzYuaWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQjcGFydC02Ij48ZW0+IHBhZ2Ug NSwgbGluZSA0NTxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGg+ IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0 dHBzOi8vd3d3Ni5pZXRmLm9yZy9yZmNkaWZmL3JmY2RpZmYucHlodCNwYXJ0LTYiPjxlbT4gcGFn ZSA1LCBsaW5lIDQ1PHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0 ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW9kZTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg bW9kZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB3aGVyZSBmaWVsZHMgYXJl IGRlZmluZWQgYXMgdGhlIGZvbGxvd2luZzo8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICB3aGVyZSBmaWVsZHMgYXJlIGRlZmluZWQgYXMgdGhlIGZvbGxvd2luZzo8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbyAgU2VxdWVuY2UgTnVtYmVyIGlzIGZvdXIgb2N0 ZXRzIGxvbmcgZmllbGQuICBGb3IgZWFjaCBuZXcgc2Vzc2lvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIG8gIFNlcXVlbmNlIE51bWJlciBpcyBmb3VyIG9jdGV0cyBsb25nIGZp ZWxkLiAgRm9yIGVhY2ggbmV3IHNlc3Npb248L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgIGl0cyB2YWx1ZSBzdGFydHMgYXQgemVybyBhbmQgaXMgaW5jcmVtZW50ZWQgd2l0aCBlYWNo IHRyYW5zbWl0dGVkPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgaXRzIHZh bHVlIHN0YXJ0cyBhdCB6ZXJvIGFuZCBpcyBpbmNyZW1lbnRlZCB3aXRoIGVhY2ggdHJhbnNtaXR0 ZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHBhY2tldC48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBwYWNrZXQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIG8gIFRpbWVzdGFtcCBpcyBlaWdodCBvY3RldHMgbG9uZyBmaWVsZC4gIFNU QU1QIG5vZGUgTVVTVCBzdXBwb3J0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg byAgVGltZXN0YW1wIGlzIGVpZ2h0IG9jdGV0cyBsb25nIGZpZWxkLiAgU1RBTVAgbm9kZSBNVVNU IHN1cHBvcnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIE5ldHdvcmsgVGltZSBQ cm90b2NvbCAoTlRQKSB2ZXJzaW9uIDQgNjQtYml0IHRpbWVzdGFtcCBmb3JtYXQ8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBOZXR3b3JrIFRpbWUgUHJvdG9jb2wgKE5UUCkg dmVyc2lvbiA0IDY0LWJpdCB0aW1lc3RhbXAgZm9ybWF0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDExIj48dGQ+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgIDxzcGFu IGNsYXNzPSJkZWxldGUiPltSRkM1OTA1XS48L3NwYW4+ICBTVEFNUCBub2RlIE1BWSBzdXBwb3J0 IElFRUUgMTU4OHYyIFByZWNpc2lvbiBUaW1lPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPltSRkM1OTA1XSwgdGhlIGZvcm1hdCB1c2Vk IGluIFtSRkM1MzU3XS48L3NwYW4+ICBTVEFNUCBub2RlIE1BWSBzdXBwb3J0PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgIFByb3RvY29sIHRydW5jYXRlZCA2NC1iaXQgdGltZXN0 YW1wIGZvcm1hdCA8c3BhbiBjbGFzcz0iZGVsZXRlIj5bSUVFRS4xNTg4LjIwMDhdLjwvc3Bhbj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgSUVFRSAxNTg4djIgUHJlY2lz aW9uIFRpbWUgUHJvdG9jb2wgdHJ1bmNhdGVkIDY0LWJpdCB0aW1lc3RhbXA8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAg IGZvcm1hdCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5bSUVFRS4xNTg4LjIwMDhdLCB0aGUgZm9ybWF0 IHVzZWQgaW4gW1JGQzgxODZdLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgbyAgRXJyb3IgRXN0aW1hdGUgaXMgdHdvIG9jdGV0cyBsb25nIGZpZWxkIHdpdGggZm9y bWF0IGRpc3BsYXllZCBpbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG8gIEVy cm9yIEVzdGltYXRlIGlzIHR3byBvY3RldHMgbG9uZyBmaWVsZCB3aXRoIGZvcm1hdCBkaXNwbGF5 ZWQgaW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIEZpZ3VyZSAzPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgRmlndXJlIDM8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICAgICAgICAgIDAgICAgICAgICAgICAgICAgICAgMTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgIDAgICAgICAgICAgICAgICAgICAgMTwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDEgMiAzIDQgNTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgIDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgfFN8WnwgICBT Y2FsZSAgIHwgICBNdWx0aXBsaWVyICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgICAgICB8U3xafCAgIFNjYWxlICAgfCAgIE11bHRpcGxpZXIgIHw8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAzOiBFcnJvciBFc3RpbWF0ZSBGb3JtYXQ8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgRmlndXJl IDM6IEVycm9yIEVzdGltYXRlIEZvcm1hdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHIgaWQ9InBhcnQtNyIgY2xhc3M9ImNoYW5nZSI+PHRkPjwvdGQ+PHRo PjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0dHBzOi8vd3d3 Ni5pZXRmLm9yZy9yZmNkaWZmL3JmY2RpZmYucHlodCNwYXJ0LTciPjxlbT4gcGFnZSA2LCBsaW5l IDMwPHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48 dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93 d3c2LmlldGYub3JnL3JmY2RpZmYvcmZjZGlmZi5weWh0I3BhcnQtNyI+PGVtPiBwYWdlIDYsIGxp bmUgMzA8c3BhbiBjbGFzcz0iaGlkZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgVGhlIFNUQU1QIFNlc3Npb24tU2VuZGVyIGFuZCBTZXNzaW9uLVJlZmxlY3RvciBNQVkg dXNlLCBub3QgdXNlLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIFRoZSBT VEFNUCBTZXNzaW9uLVNlbmRlciBhbmQgU2Vzc2lvbi1SZWZsZWN0b3IgTUFZIHVzZSwgbm90IHVz ZSw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIG9yIHNldCB2YWx1ZSBvZiB0aGUg WiBmaWVsZCBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIHRpbWVzdGFtcDwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgICAgIG9yIHNldCB2YWx1ZSBvZiB0aGUgWiBmaWVsZCBpbiBhY2Nv cmRhbmNlIHdpdGggdGhlIHRpbWVzdGFtcDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICAgZm9ybWF0IGluIHVzZS4gIFRoaXMgb3B0aW9uYWwgZmllbGQgaXMgdG8gZW5oYW5jZSBvcGVy YXRpb25zLCBidXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBmb3JtYXQg aW4gdXNlLiAgVGhpcyBvcHRpb25hbCBmaWVsZCBpcyB0byBlbmhhbmNlIG9wZXJhdGlvbnMsIGJ1 dDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgbG9jYWwgY29uZmlndXJhdGlvbiBv ciBkZWZhdWx0cyBjb3VsZCBiZSB1c2VkIGluIGl0cyBwbGFjZS48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAgICBsb2NhbCBjb25maWd1cmF0aW9uIG9yIGRlZmF1bHRzIGNvdWxk IGJlIHVzZWQgaW4gaXRzIHBsYWNlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBvICBNdXN0LWJlLVplcm8gKE1CWikgZmllbGQgaW4gdGhlIHNlc3Npb24tc2VuZGVyIHVuYXV0 aGVudGljYXRlZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG8gIE11c3QtYmUt WmVybyAoTUJaKSBmaWVsZCBpbiB0aGUgc2Vzc2lvbi1zZW5kZXIgdW5hdXRoZW50aWNhdGVkPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBwYWNrZXQgaXMgMjcgb2N0ZXRzIGxvbmcu ICBJdCBNVVNUIGJlIGFsbCB6ZXJvZWQgb24gdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgcGFja2V0IGlzIDI3IG9jdGV0cyBsb25nLiAgSXQgTVVTVCBiZSBhbGwgemVy b2VkIG9uIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgdHJhbnNtaXNzaW9u IGFuZCBpZ25vcmVkIG9uIHJlY2VpcHQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgdHJhbnNtaXNzaW9uIGFuZCBpZ25vcmVkIG9uIHJlY2VpcHQuPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG8gIFNlcnZlciBPY3RldHMgZmllbGQgaXMgdHdvIG9jdGV0 cyBsb25nIGZpZWxkLiAgSXQgTVVTVCBmb2xsb3cgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgbyAgU2VydmVyIE9jdGV0cyBmaWVsZCBpcyB0d28gb2N0ZXRzIGxvbmcgZmll bGQuICBJdCBNVVNUIGZvbGxvdyB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0ciBpZD0iZGlmZjAwMTIiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgMjcgb2N0ZXRzIGxvbmcg TUJaIGZpZWxkLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+VGhlPC9zcGFuPiBSZWZsZWN0IE9jdGV0 cyBjYXBhYmlsaXR5IGRlZmluZWQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg ICAgMjcgb2N0ZXRzIGxvbmcgTUJaIGZpZWxkLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+VGhpcyBm aWVsZCBpcyB1c2VkIGZvciB0aGU8L3NwYW4+IFJlZmxlY3Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgICAgaW4gW1JGQzYwMzhdLiAgVGhlIHZhbHVlIGluIHRoZSBTZXJ2ZXIgT2N0 ZXRzIGZpZWxkIGVxdWFscyB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg ICAgT2N0ZXRzIGNhcGFiaWxpdHkgZGVmaW5lZCBpbiBbUkZDNjAzOF0uICBUaGUgdmFsdWUgaW4g dGhlIFNlcnZlcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICBudW1iZXIgb2Yg b2N0ZXRzIHRoZSBTZXNzaW9uLVJlZmxlY3RvciBpcyBleHBlY3RlZCB0byBjb3B5IGJhY2sgdG88 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgT2N0ZXRzIGZpZWxkIGVxdWFs cyB0aGUgbnVtYmVyIG9mIG9jdGV0cyB0aGUgU2Vzc2lvbi1SZWZsZWN0b3IgaXM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgdGhlIFNlc3Npb24tU2VuZGVyIHN0YXJ0aW5nIHdp dGggdGhlIFNlcnZlciBPY3RldHMgZmllbGQuICBUaHVzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgICAgIGV4cGVjdGVkIHRvIGNvcHkgYmFjayB0byB0aGUgU2Vzc2lvbi1TZW5k ZXIgc3RhcnRpbmcgd2l0aCB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAg dGhlIG1pbmltYWwgbm9uLXplcm8gdmFsdWUgZm9yIHRoZSBTZXJ2ZXIgT2N0ZXRzIGZpZWxkIGlz IHR3by48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgU2VydmVyIE9jdGV0 cyBmaWVsZC4gIFRodXMgdGhlIG1pbmltYWwgbm9uLXplcm8gdmFsdWUgZm9yIHRoZTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICBUaGVyZWZvcmUsIHRoZSB2YWx1ZSBvZiBvbmUg aXMgaW52YWxpZC4gIElmIG5vbmUgb2YgUGF5bG9hZCB0byBiZTwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICAgICBTZXJ2ZXIgT2N0ZXRzIGZpZWxkIGlzIHR3by4gIFRoZXJlZm9y ZSwgdGhlIHZhbHVlIG9mIG9uZSBpczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAg ICBjb3BpZWQsIHRoZSB2YWx1ZSBvZiB0aGUgU2VydmVyIE9jdGV0cyBmaWVsZCBNVVNUIGJlIHNl dCB0byB6ZXJvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgIGludmFsaWQu ICBJZiBub25lIG9mIFBheWxvYWQgdG8gYmUgY29waWVkLCB0aGUgdmFsdWUgb2YgdGhlIFNlcnZl cjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICBvbiB0cmFuc21pdC48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgT2N0ZXRzIGZpZWxkIE1VU1QgYmUgc2V0 IHRvIHplcm8gb24gdHJhbnNtaXQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IG8gIFJlbWFpbmluZyBQYWNrZXQgUGFkZGluZyBpcyBhbiBvcHRpb25hbCBmaWVsZCBvZiB2YXJp YWJsZSBsZW5ndGguPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbyAgUmVtYWlu aW5nIFBhY2tldCBQYWRkaW5nIGlzIGFuIG9wdGlvbmFsIGZpZWxkIG9mIHZhcmlhYmxlIGxlbmd0 aC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIFRoZSBudW1iZXIgb2Ygb2N0ZXRz IGluIHRoZSBSZW1haW5pbmcgUGFja2V0IFBhZGRpbmcgZmllbGQgaXMgdGhlPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgVGhlIG51bWJlciBvZiBvY3RldHMgaW4gdGhlIFJl bWFpbmluZyBQYWNrZXQgUGFkZGluZyBmaWVsZCBpcyB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTMiPjx0ZD48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgdmFs dWUgb2YgdGhlIFNlcnZlciBPY3RldHMgZmllbGQgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+bGVzPC9z cGFuPnMgdGhlIGxlbmd0aCBvZiB0aGUgU2VydmVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgICAgIHZhbHVlIG9mIHRoZSBTZXJ2ZXIgT2N0ZXRzIGZpZWxkIDxzcGFuIGNsYXNz PSJpbnNlcnQiPm1pbnU8L3NwYW4+cyB0aGUgbGVuZ3RoIG9mIHRoZSBTZXJ2ZXI8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIE9jdGV0cyBmaWVsZC48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAgICBPY3RldHMgZmllbGQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIG8gIENvbXAuTUJaIGlzIHZhcmlhYmxlIGxlbmd0aCBmaWVsZCB1c2VkIHRv IGFjaGlldmUgYWxpZ25tZW50IG9uIGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBvICBDb21wLk1CWiBpcyB2YXJpYWJsZSBsZW5ndGggZmllbGQgdXNlZCB0byBhY2hpZXZlIGFs aWdubWVudCBvbiBhPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICB3b3JkIGJvdW5k YXJ5LiAgVGh1cyB0aGUgbGVuZ3RoIG9mIENvbXAuTUJaIGZpZWxkIG1heSBiZSBvbmx5IDAsPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgd29yZCBib3VuZGFyeS4gIFRodXMg dGhlIGxlbmd0aCBvZiBDb21wLk1CWiBmaWVsZCBtYXkgYmUgb25seSAwLDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgICAgMSwgMiBvciAzIG9jdGV0cy4gIFRoZSB2YWx1ZSBvZiB0aGUg ZmllbGQgTVVTVCBiZSB6ZXJvZWQgb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAgICAxLCAyIG9yIDMgb2N0ZXRzLiAgVGhlIHZhbHVlIG9mIHRoZSBmaWVsZCBNVVNUIGJlIHpl cm9lZCBvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgdHJhbnNtaXNzaW9uIGFu ZCBpZ25vcmVkIG9uIHJlY2VpcHQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg ICAgdHJhbnNtaXNzaW9uIGFuZCBpZ25vcmVkIG9uIHJlY2VpcHQuPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjQuMS4yLiAgU2Vzc2lvbi1TZW5kZXIgUGFja2V0IEZvcm1hdCBpbiBB dXRoZW50aWNhdGVkIE1vZGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij40LjEuMi4g IFNlc3Npb24tU2VuZGVyIFBhY2tldCBGb3JtYXQgaW4gQXV0aGVudGljYXRlZCBNb2RlPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEZvciBhdXRoZW50aWNhdGVkIG1vZGU6PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRm9yIGF1dGhlbnRpY2F0ZWQgbW9kZTo8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0 LTgiIGNsYXNzPSJjaGFuZ2UiPjx0ZD48L3RkPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdl IGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3dzYuaWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZm LnB5aHQjcGFydC04Ij48ZW0+IHBhZ2UgNywgbGluZSA0NjxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8 L3NwYW4+PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFu Z2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9yZmNkaWZmL3JmY2Rp ZmYucHlodCNwYXJ0LTgiPjxlbT4gcGFnZSA3LCBsaW5lIDQ2PHNwYW4gY2xhc3M9ImhpZGUiPiDC tjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfDwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICBGaWd1cmUgNDogU1RBTVAg U2Vzc2lvbi1TZW5kZXIgdGVzdCBwYWNrZXQgZm9ybWF0IGluIGF1dGhlbnRpY2F0ZWQ8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgRmlndXJlIDQ6IFNUQU1QIFNlc3Npb24tU2Vu ZGVyIHRlc3QgcGFja2V0IGZvcm1hdCBpbiBhdXRoZW50aWNhdGVkPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vZGU8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIG1vZGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIGZpZWxkIGRl ZmluaXRpb25zIGFyZSB0aGUgc2FtZSBhcyB0aGUgdW5hdXRoZW50aWNhdGVkIG1vZGUsPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIGZpZWxkIGRlZmluaXRpb25zIGFyZSB0 aGUgc2FtZSBhcyB0aGUgdW5hdXRoZW50aWNhdGVkIG1vZGUsPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBsaXN0ZWQgaW4gU2VjdGlvbiA0LjEuMS4gIEFsc28sIENvbXAuTUJaIGZpZWxk IGlzIHZhcmlhYmxlIGxlbmd0aDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGxp c3RlZCBpbiBTZWN0aW9uIDQuMS4xLiAgQWxzbywgQ29tcC5NQlogZmllbGQgaXMgdmFyaWFibGUg bGVuZ3RoPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBmaWVsZCB0byBhbGlnbiB0aGUg cGFja2V0IG9uIDE2IG9jdGV0cyBib3VuZGFyeS4gIEFsc28sIHRoZSBwYWNrZXQ8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBmaWVsZCB0byBhbGlnbiB0aGUgcGFja2V0IG9uIDE2 IG9jdGV0cyBib3VuZGFyeS4gIEFsc28sIHRoZSBwYWNrZXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIGluY2x1ZGVzIGEga2V5LWhhc2hlZCBtZXNzYWdlIGF1dGhlbnRpY2F0aW9uIGNv ZGUgKEhNQUMpIChbUkZDMjEwNF0pPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg aW5jbHVkZXMgYSBrZXktaGFzaGVkIG1lc3NhZ2UgYXV0aGVudGljYXRpb24gY29kZSAoSE1BQykg KFtSRkMyMTA0XSk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBp ZD0iZGlmZjAwMTQiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgaGFzaCBhdCB0aGUgZW5kIG9mIHRoZSBQRFUuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGhhc2ggYXQgdGhlIGVuZCBvZiB0aGUg UERVLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+VGhlIGRldGFpbGVkIHVzZSBvZiB0aGUgSE1BQyBm aWVsZCBpcyBpbjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIFNlY3Rpb24g NC4zLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+NC4yLiAgU2Vzc2lv bi1SZWZsZWN0b3IgQmVoYXZpb3IgYW5kIFBhY2tldCBGb3JtYXQ8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij40LjIuICBTZXNzaW9uLVJlZmxlY3RvciBCZWhhdmlvciBhbmQgUGFja2V0 IEZvcm1hdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUgU2Vzc2lvbi1S ZWZsZWN0b3IgcmVjZWl2ZXMgdGhlIFNUQU1QIHRlc3QgcGFja2V0LCB2ZXJpZmllcyBpdCw8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgU2Vzc2lvbi1SZWZsZWN0b3IgcmVj ZWl2ZXMgdGhlIFNUQU1QIHRlc3QgcGFja2V0LCB2ZXJpZmllcyBpdCw8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIHByZXBhcmVzIGFuZCB0cmFuc21pdHMgdGhlIHJlZmxlY3RlZCB0ZXN0 IHBhY2tldC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBwcmVwYXJlcyBhbmQg dHJhbnNtaXRzIHRoZSByZWZsZWN0ZWQgdGVzdCBwYWNrZXQuPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIFR3byBtb2RlcyBvZiBTVEFNUCBTZXNzaW9uLVJlZmxlY3RvciBjaGFy YWN0ZXJpemUgdGhlIGV4cGVjdGVkPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg VHdvIG1vZGVzIG9mIFNUQU1QIFNlc3Npb24tUmVmbGVjdG9yIGNoYXJhY3Rlcml6ZSB0aGUgZXhw ZWN0ZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGJlaGF2aW9yIGFuZCwgY29uc2Vx dWVudGx5LCBwZXJmb3JtYW5jZSBtZXRyaWNzIHRoYXQgY2FuIGJlIG1lYXN1cmVkOjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGJlaGF2aW9yIGFuZCwgY29uc2VxdWVudGx5LCBw ZXJmb3JtYW5jZSBtZXRyaWNzIHRoYXQgY2FuIGJlIG1lYXN1cmVkOjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBvICBTdGF0ZWxlc3MgLSBTVEFNUCBTZXNzaW9uLVJlZmxlY3Rv ciBkb2VzIG5vdCBtYWludGFpbiB0ZXN0IHN0YXRlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgbyAgU3RhdGVsZXNzIC0gU1RBTVAgU2Vzc2lvbi1SZWZsZWN0b3IgZG9lcyBub3Qg bWFpbnRhaW4gdGVzdCBzdGF0ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHIgaWQ9InBhcnQtOSIgY2xhc3M9ImNoYW5nZSI+PHRkPjwvdGQ+PHRoPjxzbWFs bD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0dHBzOi8vd3d3Ni5pZXRm Lm9yZy9yZmNkaWZmL3JmY2RpZmYucHlodCNwYXJ0LTkiPjxlbT4gcGFnZSAxMCwgbGluZSAxNzxz cGFuIGNsYXNzPSJoaWRlIj4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxz bWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0dHBzOi8vd3d3Ni5p ZXRmLm9yZy9yZmNkaWZmL3JmY2RpZmYucHlodCNwYXJ0LTkiPjxlbT4gcGFnZSAxMCwgbGluZSAx NzxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAg ICBaIGZsYWcgb2YgdGhlIEVycm9yIEVzdGltYXRlIGZpZWxkIGFzIGRlc2NyaWJlZCBpbiBTZWN0 aW9uIDQuMS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBaIGZsYWcgb2Yg dGhlIEVycm9yIEVzdGltYXRlIGZpZWxkIGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuMS48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbyAgRXJyb3IgRXN0aW1hdGUgaGFzIHRo ZSBzYW1lIHNpemUgYW5kIGludGVycHJldGF0aW9uIGFzIGRlc2NyaWJlZDwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIG8gIEVycm9yIEVzdGltYXRlIGhhcyB0aGUgc2FtZSBzaXpl IGFuZCBpbnRlcnByZXRhdGlvbiBhcyBkZXNjcmliZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgICAgIGluIFNlY3Rpb24gNC4xLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgICAgIGluIFNlY3Rpb24gNC4xLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBvICBTZXNzaW9uLVNlbmRlciBTZXF1ZW5jZSBOdW1iZXIsIFNlc3Npb24tU2VuZGVyIFRpbWVz dGFtcCwgYW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbyAgU2Vzc2lvbi1T ZW5kZXIgU2VxdWVuY2UgTnVtYmVyLCBTZXNzaW9uLVNlbmRlciBUaW1lc3RhbXAsIGFuZDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgU2Vzc2lvbi1TZW5kZXIgRXJyb3IgRXN0aW1h dGUgYXJlIGNvcGllcyBvZiB0aGUgY29ycmVzcG9uZGluZzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgIFNlc3Npb24tU2VuZGVyIEVycm9yIEVzdGltYXRlIGFyZSBjb3BpZXMg b2YgdGhlIGNvcnJlc3BvbmRpbmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGZp ZWxkcyBpbiB0aGUgU1RBTVAgdGVzdCBwYWNrZXQgc2VudCBieSB0aGUgU2Vzc2lvbi1TZW5kZXIu PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgZmllbGRzIGluIHRoZSBTVEFN UCB0ZXN0IHBhY2tldCBzZW50IGJ5IHRoZSBTZXNzaW9uLVNlbmRlci48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgbyAgU2Vzc2lvbi1TZW5kZXIgVFRMIGlzIG9uZSBvY3RldCBs b25nIGZpZWxkLCBhbmQgaXRzIHZhbHVlIGlzIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIG8gIFNlc3Npb24tU2VuZGVyIFRUTCBpcyBvbmUgb2N0ZXQgbG9uZyBmaWVsZCwg YW5kIGl0cyB2YWx1ZSBpcyB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0ciBpZD0iZGlmZjAwMTUiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgY29weSBvZiB0aGUgVFRMIGZp ZWxkIGZyb20gdGhlIHJlY2VpdmVkIFNUQU1QIHRlc3QgcGFja2V0LjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICAgICBjb3B5IG9mIHRoZSBUVEwgZmllbGQgPHNwYW4gY2xhc3M9 Imluc2VydCI+aW4gSVB2NCAob3IgSG9wIExpbWl0IGluIElQdjYpPC9zcGFuPiBmcm9tIHRoZTwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgICAgcmVjZWl2ZWQgU1RBTVAgdGVzdCBwYWNrZXQuPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIG8gIFBhY2tldCBQYWRkaW5nIChyZWZsZWN0ZWQpIGlzIGFuIG9w dGlvbmFsIHZhcmlhYmxlIGxlbmd0aCBmaWVsZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBvICBQYWNrZXQgUGFkZGluZyAocmVmbGVjdGVkKSBpcyBhbiBvcHRpb25hbCB2YXJp YWJsZSBsZW5ndGggZmllbGQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBUaGUg bGVuZ3RoIG9mIHRoZSBQYWNrZXQgUGFkZGluZyAocmVmbGVjdGVkKSBmaWVsZCBNVVNUIGJlIGVx dWFsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgVGhlIGxlbmd0aCBvZiB0 aGUgUGFja2V0IFBhZGRpbmcgKHJlZmxlY3RlZCkgZmllbGQgTVVTVCBiZSBlcXVhbDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgdG8gdGhlIHZhbHVlIG9mIHRoZSBTZXJ2ZXIgT2N0 ZXRzIGZpZWxkIChGaWd1cmUgMikuICBJZiB0aGUgdmFsdWU8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAgICB0byB0aGUgdmFsdWUgb2YgdGhlIFNlcnZlciBPY3RldHMgZmllbGQg KEZpZ3VyZSAyKS4gIElmIHRoZSB2YWx1ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICAgaXMgbm9uLXplcm8sIHRoZSBTZXNzaW9uLVJlZmxlY3RvciBNVVNUIGNvcHkgbnVtYmVyIG9m IG9jdGV0czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIGlzIG5vbi16ZXJv LCB0aGUgU2Vzc2lvbi1SZWZsZWN0b3IgTVVTVCBjb3B5IG51bWJlciBvZiBvY3RldHM8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGVxdWFsIHRvIHRoZSB2YWx1ZSBvZiBTZXJ2ZXIg T2N0ZXRzIGZpZWxkIHN0YXJ0aW5nIHdpdGggdGhlIFNlcnZlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgIGVxdWFsIHRvIHRoZSB2YWx1ZSBvZiBTZXJ2ZXIgT2N0ZXRzIGZp ZWxkIHN0YXJ0aW5nIHdpdGggdGhlIFNlcnZlcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgT2N0ZXRzIGZpZWxkLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg IE9jdGV0cyBmaWVsZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgbyAgQ29t cC5NQlogaXMgdmFyaWFibGUgbGVuZ3RoIGZpZWxkIHVzZWQgdG8gYWNoaWV2ZSBhbGlnbm1lbnQg b24gYTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG8gIENvbXAuTUJaIGlzIHZh cmlhYmxlIGxlbmd0aCBmaWVsZCB1c2VkIHRvIGFjaGlldmUgYWxpZ25tZW50IG9uIGE8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHdvcmQgYm91bmRhcnkuICBUaHVzIHRoZSBsZW5n dGggb2YgQ29tcC5NQlogZmllbGQgbWF5IGJlIG9ubHkgMCw8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAgICB3b3JkIGJvdW5kYXJ5LiAgVGh1cyB0aGUgbGVuZ3RoIG9mIENvbXAu TUJaIGZpZWxkIG1heSBiZSBvbmx5IDAsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0ciBpZD0icGFydC0xMCIgY2xhc3M9ImNoYW5nZSI+PHRkPjwvdGQ+PHRo PjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0dHBzOi8vd3d3 Ni5pZXRmLm9yZy9yZmNkaWZmL3JmY2RpZmYucHlodCNwYXJ0LTEwIj48ZW0+IHBhZ2UgMTEsIGxp bmUgNDc8c3BhbiBjbGFzcz0iaGlkZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3Ro Pjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczov L3d3dzYuaWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQjcGFydC0xMCI+PGVtPiBwYWdlIDEx LCBsaW5lIDQ4PHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRmlndXJlIDY6IFNU QU1QIFNlc3Npb24tUmVmbGVjdG9yIHRlc3QgcGFja2V0IGZvcm1hdCBpbiBhdXRoZW50aWNhdGVk PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRmlndXJlIDY6IFNUQU1QIFNlc3Np b24tUmVmbGVjdG9yIHRlc3QgcGFja2V0IGZvcm1hdCBpbiBhdXRoZW50aWNhdGVkPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1v ZGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIG1vZGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhl IGZpZWxkIGRlZmluaXRpb25zIGFyZSB0aGUgc2FtZSBhcyB0aGUgdW5hdXRoZW50aWNhdGVkIG1v ZGUsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIGZpZWxkIGRlZmluaXRp b25zIGFyZSB0aGUgc2FtZSBhcyB0aGUgdW5hdXRoZW50aWNhdGVkIG1vZGUsPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBsaXN0ZWQgaW4gU2VjdGlvbiA0LjIuMS4gIEFkZGl0aW9uYWxs eSwgdGhlIHBhY2tldCBNQVkgaW5jbHVkZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIGxpc3RlZCBpbiBTZWN0aW9uIDQuMi4xLiAgQWRkaXRpb25hbGx5LCB0aGUgcGFja2V0IE1B WSBpbmNsdWRlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBDb21wLk1CWiBmaWVsZCBp cyB2YXJpYWJsZSBsZW5ndGggZmllbGQgdG8gYWxpZ24gdGhlIHBhY2tldCBvbiAxNjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIENvbXAuTUJaIGZpZWxkIGlzIHZhcmlhYmxlIGxl bmd0aCBmaWVsZCB0byBhbGlnbiB0aGUgcGFja2V0IG9uIDE2PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBvY3RldHMgYm91bmRhcnkuICBBbHNvLCBTVEFNUCBTZXNzaW9uLVJlZmxlY3Rv ciB0ZXN0IHBhY2tldCBmb3JtYXQgaW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBvY3RldHMgYm91bmRhcnkuICBBbHNvLCBTVEFNUCBTZXNzaW9uLVJlZmxlY3RvciB0ZXN0IHBh Y2tldCBmb3JtYXQgaW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGF1dGhlbnRpY2F0 ZWQgbW9kZSBpbmNsdWRlcyBhIGtleSAoSE1BQykgKFtSRkMyMTA0XSkgaGFzaCBhdCB0aGUgZW5k PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYXV0aGVudGljYXRlZCBtb2RlIGlu Y2x1ZGVzIGEga2V5IChITUFDKSAoW1JGQzIxMDRdKSBoYXNoIGF0IHRoZSBlbmQ8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTYiPjx0ZD48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgb2YgdGhlIFBEVS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgb2Yg dGhlIFBEVS48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gIFRoZSBkZXRhaWxlZCB1c2Ugb2YgdGhlIEhN QUMgZmllbGQgaXMgaW4gU2VjdGlvbiA0LjMuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij40LjMuICBJbnRlZ3JpdHkgYW5kIENvbmZpZGVudGlhbGl0eSBQcm90ZWN0aW9u IGluIFNUQU1QPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+NC4zLiAgSW50ZWdyaXR5 IGFuZCBDb25maWRlbnRpYWxpdHkgUHJvdGVjdGlvbiBpbiBTVEFNUDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBUbyBwcm92aWRlIGludGVncml0eSBwcm90ZWN0aW9uLCBlYWNo IFNUQU1QIG1lc3NhZ2UgaXMgYmVpbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBUbyBwcm92aWRlIGludGVncml0eSBwcm90ZWN0aW9uLCBlYWNoIFNUQU1QIG1lc3NhZ2UgaXMg YmVpbmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGF1dGhlbnRpY2F0ZWQgYnkgYWRk aW5nIEhhc2hlZCBNZXNzYWdlIEF1dGhlbnRpY2F0aW9uIENvZGUgKEhNQUMpLjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGF1dGhlbnRpY2F0ZWQgYnkgYWRkaW5nIEhhc2hlZCBN ZXNzYWdlIEF1dGhlbnRpY2F0aW9uIENvZGUgKEhNQUMpLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgU1RBTVAgdXNlcyBITUFDLVNIQS0yNTYgdHJ1bmNhdGVkIHRvIDEyOCBiaXRzIChz aW1pbGFybHkgdG8gdGhlIHVzZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFNU QU1QIHVzZXMgSE1BQy1TSEEtMjU2IHRydW5jYXRlZCB0byAxMjggYml0cyAoc2ltaWxhcmx5IHRv IHRoZSB1c2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG9mIGl0IGluIElQU2VjIGRl ZmluZWQgaW4gW1JGQzQ4NjhdKTsgaGVuY2UgdGhlIGxlbmd0aCBvZiB0aGUgSE1BQzwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9mIGl0IGluIElQU2VjIGRlZmluZWQgaW4gW1JG QzQ4NjhdKTsgaGVuY2UgdGhlIGxlbmd0aCBvZiB0aGUgSE1BQzwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgZmllbGQgaXMgMTYgb2N0ZXRzLiAgSE1BQyB1c2VzIG93biBrZXkgYW5kIHRo ZSBkZWZpbml0aW9uIG9mIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGZp ZWxkIGlzIDE2IG9jdGV0cy4gIEhNQUMgdXNlcyBvd24ga2V5IGFuZCB0aGUgZGVmaW5pdGlvbiBv ZiB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG1lY2hhbmlzbSB0byBkaXN0cmli dXRlIHRoZSBITUFDIGtleSBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbWVjaGFuaXNtIHRvIGRpc3RyaWJ1dGUgdGhlIEhNQUMg a2V5IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIHNwZWNpZmljYXRpb24uICBPbmUgZXhhbXBsZSBpcyB0byB1c2UgYW4gb3JjaGVzdHJh dG9yIHRvIGNvbmZpZ3VyZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHNwZWNp ZmljYXRpb24uICBPbmUgZXhhbXBsZSBpcyB0byB1c2UgYW4gb3JjaGVzdHJhdG9yIHRvIGNvbmZp Z3VyZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSE1BQyBrZXkgYmFzZWQgb24gU1RB TVAgWUFORyBkYXRhIG1vZGVsIFtJLUQuaWV0Zi1pcHBtLXN0YW1wLXlhbmddLjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEhNQUMga2V5IGJhc2VkIG9uIFNUQU1QIFlBTkcgZGF0 YSBtb2RlbCBbSS1ELmlldGYtaXBwbS1zdGFtcC15YW5nXS48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIEhNQUMgTVVTVCBiZSB2ZXJpZmllZCBhcyBlYXJseSBhcyBwb3NzaWJsZSB0byBh dm9pZCB1c2luZyBvcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEhNQUMgTVVT VCBiZSB2ZXJpZmllZCBhcyBlYXJseSBhcyBwb3NzaWJsZSB0byBhdm9pZCB1c2luZyBvcjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcHJvcGFnYXRpbmcgY29ycnVwdGVkIGRhdGEuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcHJvcGFnYXRpbmcgY29ycnVwdGVkIGRh dGEuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIElmIGNvbmZpZGVudGlhbGl0 eSBwcm90ZWN0aW9uIGZvciBTVEFNUCBpcyByZXF1aXJlZCwgZW5jcnlwdGlvbiBhdDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIElmIGNvbmZpZGVudGlhbGl0eSBwcm90ZWN0aW9u IGZvciBTVEFNUCBpcyByZXF1aXJlZCwgZW5jcnlwdGlvbiBhdDwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxNyI+PHRkPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICB0aGUg aGlnaGVyIGxldmVsIE1VU1QgYmUgdXNlZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgdGhlIGhpZ2hlciBsZXZlbCBNVVNUIGJlIHVzZWQuICA8c3BhbiBjbGFzcz0iaW5zZXJ0 Ij5Gb3IgZXhhbXBsZSwgU1RBTVAgcGFja2V0cyBjb3VsZCBiZTwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFu IGNsYXNzPSJpbnNlcnQiPiAgIHRyYW5zbWl0dGVkIGluIHRoZSBkZWRpY2F0ZWQgSVBzZWMgdHVu bmVsIG9yIHNoYXJlIHRoZSBJUHNlYyB0dW5uZWw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0i aW5zZXJ0Ij4gICB3aXRoIHRoZSBtb25pdG9yZWQgZmxvdy48L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjQuNC4gIEludGVyb3BlcmFiaWxpdHkgd2l0aCBUV0FNUCBMaWdo dDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjQuNC4gIEludGVyb3BlcmFiaWxpdHkg d2l0aCBUV0FNUCBMaWdodDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBPbmUg b2YgdGhlIGVzc2VudGlhbCByZXF1aXJlbWVudHMgdG8gU1RBTVAgaXMgdGhlIGFiaWxpdHkgdG88 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBPbmUgb2YgdGhlIGVzc2VudGlhbCBy ZXF1aXJlbWVudHMgdG8gU1RBTVAgaXMgdGhlIGFiaWxpdHkgdG88L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIGludGVyd29yayB3aXRoIFRXQU1QIExpZ2h0IGRldmljZS4gIFRoZXJlIGFy ZSB0d28gcG9zc2libGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpbnRlcndv cmsgd2l0aCBUV0FNUCBMaWdodCBkZXZpY2UuICBUaGVyZSBhcmUgdHdvIHBvc3NpYmxlPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBjb21iaW5hdGlvbnMgZm9yIHN1Y2ggdXNlIGNhc2U6 PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgY29tYmluYXRpb25zIGZvciBzdWNo IHVzZSBjYXNlOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvICBTVEFNUCBT ZXNzaW9uLVNlbmRlciB3aXRoIFRXQU1QIExpZ2h0IFNlc3Npb24tUmVmbGVjdG9yOzwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG8gIFNUQU1QIFNlc3Npb24tU2VuZGVyIHdpdGgg VFdBTVAgTGlnaHQgU2Vzc2lvbi1SZWZsZWN0b3I7PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIG8gIFRXQU1QIExpZ2h0IFNlc3Npb24tU2VuZGVyIHdpdGggU1RBTVAgU2Vzc2lv bi1SZWZsZWN0b3IuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbyAgVFdBTVAg TGlnaHQgU2Vzc2lvbi1TZW5kZXIgd2l0aCBTVEFNUCBTZXNzaW9uLVJlZmxlY3Rvci48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW4gdGhlIGZvcm1lciBjYXNlLCBTZXNzaW9u LVNlbmRlciBNQVkgbm90IGJlIGF3YXJlIHRoYXQgaXRzIFNlc3Npb24tPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgSW4gdGhlIGZvcm1lciBjYXNlLCBTZXNzaW9uLVNlbmRlciBN QVkgbm90IGJlIGF3YXJlIHRoYXQgaXRzIFNlc3Npb24tPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBSZWZsZWN0b3IgZG9lcyBub3Qgc3VwcG9ydCBTVEFNUC4gIEZvciBleGFtcGxlLCBU V0FNUCBMaWdodCBTZXNzaW9uLTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFJl ZmxlY3RvciBkb2VzIG5vdCBzdXBwb3J0IFNUQU1QLiAgRm9yIGV4YW1wbGUsIFRXQU1QIExpZ2h0 IFNlc3Npb24tPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBSZWZsZWN0b3IgbWF5IG5v dCBzdXBwb3J0IHRoZSB1c2Ugb2YgVURQIHBvcnQgODYyIGFzIGRlZmluZWQgaW48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBSZWZsZWN0b3IgbWF5IG5vdCBzdXBwb3J0IHRoZSB1 c2Ugb2YgVURQIHBvcnQgODYyIGFzIGRlZmluZWQgaW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTgiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgPHNwYW4gY2xh c3M9ImRlbGV0ZSI+W0ktRC5pZXRmLWlwcG0tcG9ydC10d2FtcC10ZXN0XS48L3NwYW4+ICBUaHVz IFNUQU1QIFNlc3Npb24tU2VuZGVyIE1VU1QgYmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+W1JGQzg1NDVdLjwvc3Bhbj4gIFRodXMgU1RB TVAgU2Vzc2lvbi1TZW5kZXIgTVVTVCBiZSBhYmxlIHRvIHNlbmQgdGVzdDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICBhYmxlIHRvIHNlbmQgdGVzdCBwYWNrZXRzIHRvIGRlc3RpbmF0 aW9uIFVEUCBwb3J0IG51bWJlciBmcm9tIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICBwYWNrZXRzIHRvIGRlc3RpbmF0aW9uIFVEUCBwb3J0IG51bWJlciBmcm9tIHRoZSBE eW5hbWljIGFuZC9vcjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBEeW5hbWljIGFu ZC9vciBQcml2YXRlIFBvcnRzIHJhbmdlIDQ5MTUyLTY1NTM1LCB0ZXN0IG1hbmFnZW1lbnQ8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgUHJpdmF0ZSBQb3J0cyByYW5nZSA0OTE1 Mi02NTUzNSwgdGVzdCBtYW5hZ2VtZW50IHN5c3RlbSBzaG91bGQgZmluZDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICBzeXN0ZW0gc2hvdWxkIGZpbmQgcG9ydCBudW1iZXIgdGhhdCBi b3RoIGRldmljZXMgY2FuIHVzZS4gIEFuZCBpZiBhbnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgcG9ydCBudW1iZXIgdGhhdCBib3RoIGRldmljZXMgY2FuIHVzZS4gIEFuZCBp ZiBhbnkgb2YgVExWLWJhc2VkIFNUQU1QPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAg IG9mIFRMVi1iYXNlZCBTVEFNUCBleHRlbnNpb25zIGFyZSB1c2VkLCB0aGUgVFdBTVAgTGlnaHQg PHNwYW4gY2xhc3M9ImRlbGV0ZSI+U2Vzc2lvbi08L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPiAgIGV4dGVuc2lvbnMgYXJlIHVzZWQsIHRoZSBUV0FNUCBMaWdodCA8c3Bh biBjbGFzcz0iaW5zZXJ0Ij5TZXNzaW9uLVJlZmxlY3Rvcjwvc3Bhbj4gd2lsbCB2aWV3IHRoZW08 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgUmVm bGVjdG9yPC9zcGFuPiB3aWxsIHZpZXcgdGhlbSBhcyBQYWNrZXQgUGFkZGluZyBmaWVsZC4gIFRo ZSBTZXNzaW9uLVNlbmRlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBhcyBQ YWNrZXQgUGFkZGluZyBmaWVsZC4gIFRoZSBTZXNzaW9uLVNlbmRlciBTSE9VTEQgdXNlIHRoZSBk ZWZhdWx0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFNIT1VMRCB1c2UgdGhlIGRl ZmF1bHQgZm9ybWF0IGZvciBpdHMgdGltZXN0YW1wcyAtIE5UUC4gIEFuZCBpdCBNQVk8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgZm9ybWF0IGZvciBpdHMgdGltZXN0YW1wcyAt IE5UUC4gIEFuZCBpdCBNQVkgdXNlIFBUUHYyIHRpbWVzdGFtcDwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICB1c2UgUFRQdjIgdGltZXN0YW1wIGZvcm1hdC48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgZm9ybWF0LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBJbiB0aGUgbGF0dGVyIHNjZW5hcmlvLCB0aGUgdGVzdCBtYW5hZ2VtZW50IHN5c3Rl bSBzaG91bGQgc2V0IFNUQU1QPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW4g dGhlIGxhdHRlciBzY2VuYXJpbywgdGhlIHRlc3QgbWFuYWdlbWVudCBzeXN0ZW0gc2hvdWxkIHNl dCBTVEFNUDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgU2Vzc2lvbi1SZWZsZWN0b3Ig dG8gdXNlIFVEUCBwb3J0IG51bWJlciBmcm9tIHRoZSBEeW5hbWljIGFuZC9vcjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFNlc3Npb24tUmVmbGVjdG9yIHRvIHVzZSBVRFAgcG9y dCBudW1iZXIgZnJvbSB0aGUgRHluYW1pYyBhbmQvb3I8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIFByaXZhdGUgUG9ydHMgcmFuZ2UuICBBcyBmb3IgUGFja2V0IFBhZGRpbmcgZmllbGQg dGhhdCB0aGUgVFdBTVA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBQcml2YXRl IFBvcnRzIHJhbmdlLiAgQXMgZm9yIFBhY2tldCBQYWRkaW5nIGZpZWxkIHRoYXQgdGhlIFRXQU1Q PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBMaWdodCBTZXNzaW9uLVNlbmRlciBpbmNs dWRlcyBpbiBpdHMgdHJhbnNtaXR0ZWQgcGFja2V0LCB0aGUgU1RBTVA8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBMaWdodCBTZXNzaW9uLVNlbmRlciBpbmNsdWRlcyBpbiBpdHMg dHJhbnNtaXR0ZWQgcGFja2V0LCB0aGUgU1RBTVA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIFNlc3Npb24tUmVmbGVjdG9yIHdpbGwgcHJvY2VzcyBpdCBhY2NvcmRpbmcgdG8gW1JGQzYw MzhdIGFuZCByZXR1cm48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBTZXNzaW9u LVJlZmxlY3RvciB3aWxsIHByb2Nlc3MgaXQgYWNjb3JkaW5nIHRvIFtSRkM2MDM4XSBhbmQgcmV0 dXJuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICByZWZsZWN0ZWQgcGFja2V0IG9mIHRo ZSBzeW1tZXRyaWNhbCBzaXplLiAgVGhlIFNlc3Npb24tUmVmbGVjdG9yIE1VU1Q8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICByZWZsZWN0ZWQgcGFja2V0IG9mIHRoZSBzeW1tZXRy aWNhbCBzaXplLiAgVGhlIFNlc3Npb24tUmVmbGVjdG9yIE1VU1Q8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIHVzZSB0aGUgZGVmYXVsdCBmb3JtYXQgZm9yIGl0cyB0aW1lc3RhbXBzIC0g TlRQLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHVzZSB0aGUgZGVmYXVsdCBm b3JtYXQgZm9yIGl0cyB0aW1lc3RhbXBzIC0gTlRQLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij41LiAgSUFOQSBDb25zaWRlcmF0aW9uczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjUuICBJQU5BIENvbnNpZGVyYXRpb25zPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIFRoaXMgZG9jdW1lbnQgZG9lc24ndCBoYXZlIGFueSBJQU5BIGFjdGlvbi4gIFRo aXMgc2VjdGlvbiBtYXkgYmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGlz IGRvY3VtZW50IGRvZXNuJ3QgaGF2ZSBhbnkgSUFOQSBhY3Rpb24uICBUaGlzIHNlY3Rpb24gbWF5 IGJlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICByZW1vdmVkIGJlZm9yZSB0aGUgcHVi bGljYXRpb24uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcmVtb3ZlZCBiZWZv cmUgdGhlIHB1YmxpY2F0aW9uLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij42LiAg U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij42 LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxOSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+SW4gZ2VuZXJhbCwg YWxsIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyByZWxhdGVkIHRvIFRXQU1QLVRlc3QsPC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgZGlzY3Vzc2VkIGluIFtSRkM1MzU3 XSBhcHBseSB0byBTVEFNUC4gIFNpbmNlIFNUQU1QIHVzZXMgdGhlIHdlbGwtPC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAga25vd24gVURQIHBvcnQgbnVtYmVyIGFsbG9jYXRl ZCBmb3IgdGhlIE9XQU1QLVRlc3QvVFdBTVAtVGVzdDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNz PSJpbnNlcnQiPiAgIFJlY2VpdmVyIHBvcnQsIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBh bmQgbWVhc3VyZXMgdG8gbWl0aWdhdGU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0 Ij4gICB0aGUgcmlzayBvZiB0aGUgYXR0YWNrIHVzaW5nIHRoZSByZWdpc3RlcmVkIHBvcnQgbnVt YmVyIGRvY3VtZW50ZWQgaW48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBT ZWN0aW9uIDYgW1JGQzg1NDVdIGVxdWFsbHkgYXBwbHkgdG8gU1RBTVAuICBCZWNhdXNlIHRoZSBj b250cm9sIGFuZDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIG1hbmFnZW1l bnQgb2YgYSBTVEFNUCB0ZXN0IGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgc3BlY2lmaWNhdGlvbiBvbmx5IHRoZSBtb3Jl IGdlbmVyYWwgcmVxdWlyZW1lbnQgaXMgc2V0Ojwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJp bnNlcnQiPjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgIFRvIG1pdGln YXRlIHRoZSBwb3NzaWJsZSBhdHRhY2sgdmVjdG9yLCB0aGUgY29udHJvbCBhbmQgbWFuYWdlbWVu dDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgIG9mIGEgU1RBTVAgdGVz dCBzZXNzaW9uIE1VU1QgdXNlIHRoZSBzZWN1cmVkIHRyYW5zcG9ydC48L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBVc2Ugb2YgSE1B Qy1TSEEtMjU2IGluIHRoZSBhdXRoZW50aWNhdGVkIG1vZGUgcHJvdGVjdHMgdGhlIGRhdGE8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBVc2Ugb2YgSE1BQy1TSEEtMjU2IGluIHRo ZSBhdXRoZW50aWNhdGVkIG1vZGUgcHJvdGVjdHMgdGhlIGRhdGE8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIGludGVncml0eSBvZiB0aGUgU1RBTVAgdGVzdCBwYWNrZXRzLjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGludGVncml0eSBvZiB0aGUgU1RBTVAgdGVzdCBw YWNrZXRzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij43LiAgQWNrbm93bGVkZ21l bnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+Ny4gIEFja25vd2xlZGdtZW50czwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBBdXRob3JzIGV4cHJlc3MgdGhlaXIg YXBwcmVjaWF0aW9uIHRvIEpvc2UgSWduYWNpbyBBbHZhcmV6LUhhbWVsaW48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBdXRob3JzIGV4cHJlc3MgdGhlaXIgYXBwcmVjaWF0aW9u IHRvIEpvc2UgSWduYWNpbyBBbHZhcmV6LUhhbWVsaW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIGFuZCBCcmlhbiBXZWlzIGZvciB0aGVpciBncmVhdCBpbnNpZ2h0cyBpbnRvIHRoZSBz ZWN1cml0eSBhbmQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBhbmQgQnJpYW4g V2VpcyBmb3IgdGhlaXIgZ3JlYXQgaW5zaWdodHMgaW50byB0aGUgc2VjdXJpdHkgYW5kPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBpZGVudGl0eSBwcm90ZWN0aW9uLCBhbmQgdGhlIG1v c3QgaGVscGZ1bCBhbmQgcHJhY3RpY2FsIHN1Z2dlc3Rpb25zLjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIGlkZW50aXR5IHByb3RlY3Rpb24sIGFuZCB0aGUgbW9zdCBoZWxwZnVs IGFuZCBwcmFjdGljYWwgc3VnZ2VzdGlvbnMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjguICBSZWZlcmVuY2VzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+OC4gIFJl ZmVyZW5jZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+OC4xLiAgTm9ybWF0aXZl IFJlZmVyZW5jZXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij44LjEuICBOb3JtYXRp dmUgUmVmZXJlbmNlczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHIgaWQ9ImRpZmYwMDIwIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPltC QkYuVFItMzkwXTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgICAgICAg ICAgIlBlcmZvcm1hbmNlIE1lYXN1cmVtZW50IGZyb20gSVAgRWRnZSB0byBDdXN0b21lcjwvc3Bh bj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgICAgICAgICAgRXF1aXBtZW50IHVz aW5nIFRXQU1QIExpZ2h0IiwgQkJGIFRSLTM5MCwgTWF5IDIwMTcuPC9zcGFuPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNw YW4gY2xhc3M9ImRlbGV0ZSI+PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAg W0ktRC5pZXRmLWlwcG0tcG9ydC10d2FtcC10ZXN0XTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNz PSJkZWxldGUiPiAgICAgICAgICAgICAgTW9ydG9uLCBBLiBhbmQgRy4gTWlyc2t5LCAiT1dBTVAg YW5kIFRXQU1QIFdlbGwtS25vd24gUG9ydDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxl dGUiPiAgICAgICAgICAgICAgQXNzaWdubWVudHMiLCBkcmFmdC1pZXRmLWlwcG0tcG9ydC10d2Ft cC10ZXN0LTAzICh3b3JrIGluPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAg ICAgICAgICAgICBwcm9ncmVzcyksIE5vdmVtYmVyIDIwMTguPC9zcGFuPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIFtJRUVFLjE1ODguMjAwOF08L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBbSUVFRS4xNTg4LjIwMDhdPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgICAgICAgICAgICJTdGFuZGFyZCBmb3IgYSBQcmVjaXNpb24gQ2xvY2sgU3luY2hyb25p emF0aW9uIFByb3RvY29sPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAg ICAgICAiU3RhbmRhcmQgZm9yIGEgUHJlY2lzaW9uIENsb2NrIFN5bmNocm9uaXphdGlvbiBQcm90 b2NvbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBmb3IgTmV0d29y a2VkIE1lYXN1cmVtZW50IGFuZCBDb250cm9sIFN5c3RlbXMiLDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgZm9yIE5ldHdvcmtlZCBNZWFzdXJlbWVudCBhbmQg Q29udHJvbCBTeXN0ZW1zIiw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAg ICAgSUVFRSBTdGFuZGFyZCAxNTg4LCBNYXJjaCAyMDA4LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgICAgICAgICAgICAgSUVFRSBTdGFuZGFyZCAxNTg4LCBNYXJjaCAyMDA4Ljwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBbUkZDMjExOV0gIEJyYWRuZXIsIFMu LCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRpY2F0ZTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9y IHVzZSBpbiBSRkNzIHRvIEluZGljYXRlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAg ICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMi LCBCQ1AgMTQsIFJGQyAyMTE5LDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAg ICAgICBET0kgMTAuMTc0ODcvUkZDMjExOSwgTWFyY2ggMTk5Nyw8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkMyMTE5LCBNYXJjaCAx OTk3LDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAmbHQ7aHR0cHM6 Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmMyMTE5Jmd0Oy48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICZsdDtodHRwczovL3d3dy5yZmMtZWRpdG9yLm9y Zy9pbmZvL3JmYzIxMTkmZ3Q7LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0ciBpZD0icGFydC0xMSIgY2xhc3M9ImNoYW5nZSI+PHRkPjwvdGQ+PHRo PjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0dHBzOi8vd3d3 Ni5pZXRmLm9yZy9yZmNkaWZmL3JmY2RpZmYucHlodCNwYXJ0LTExIj48ZW0+IHBhZ2UgMTQsIGxp bmUgMjQ8c3BhbiBjbGFzcz0iaGlkZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3Ro Pjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczov L3d3dzYuaWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQjcGFydC0xMSI+PGVtPiBwYWdlIDE0 LCBsaW5lIDI5PHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgW1JGQzgxNzRdICBMZWliYSwgQi4sICJBbWJpZ3VpdHkgb2YgVXBwZXJjYXNl IHZzIExvd2VyY2FzZSBpbiBSRkM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBb UkZDODE3NF0gIExlaWJhLCBCLiwgIkFtYmlndWl0eSBvZiBVcHBlcmNhc2UgdnMgTG93ZXJjYXNl IGluIFJGQzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAyMTE5IEtl eSBXb3JkcyIsIEJDUCAxNCwgUkZDIDgxNzQsIERPSSAxMC4xNzQ4Ny9SRkM4MTc0LDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgMjExOSBLZXkgV29yZHMiLCBC Q1AgMTQsIFJGQyA4MTc0LCBET0kgMTAuMTc0ODcvUkZDODE3NCw8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICAgICAgICAgICAgTWF5IDIwMTcsICZsdDtodHRwczovL3d3dy5yZmMtZWRp dG9yLm9yZy9pbmZvL3JmYzgxNzQmZ3Q7LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgICAgICAgICAgICAgTWF5IDIwMTcsICZsdDtodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9p bmZvL3JmYzgxNzQmZ3Q7LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBbUkZD ODE4Nl0gIE1pcnNreSwgRy4gYW5kIEkuIE1laWxpaywgIlN1cHBvcnQgb2YgdGhlIElFRUUgMTU4 ODwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtSRkM4MTg2XSAgTWlyc2t5LCBH LiBhbmQgSS4gTWVpbGlrLCAiU3VwcG9ydCBvZiB0aGUgSUVFRSAxNTg4PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgIFRpbWVzdGFtcCBGb3JtYXQgaW4gYSBUd28tV2F5 IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICAgICAgICAgICAgVGltZXN0YW1wIEZvcm1hdCBpbiBhIFR3by1XYXkgQWN0aXZlIE1l YXN1cmVtZW50IFByb3RvY29sPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAg ICAgIChUV0FNUCkiLCBSRkMgODE4NiwgRE9JIDEwLjE3NDg3L1JGQzgxODYsIEp1bmUgMjAxNyw8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIChUV0FNUCkiLCBS RkMgODE4NiwgRE9JIDEwLjE3NDg3L1JGQzgxODYsIEp1bmUgMjAxNyw8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgJmx0O2h0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3Jn L2luZm8vcmZjODE4NiZndDsuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg ICAgICAgICAmbHQ7aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM4MTg2Jmd0Oy48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZm MDAyMSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNw YW4gY2xhc3M9Imluc2VydCI+W1JGQzg1NDVdICBNb3J0b24sIEEuLCBFZC4gYW5kIEcuIE1pcnNr eSwgRWQuLCAiV2VsbC1Lbm93biBQb3J0PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2Vy dCI+ICAgICAgICAgICAgICBBc3NpZ25tZW50cyBmb3IgdGhlIE9uZS1XYXkgQWN0aXZlIE1lYXN1 cmVtZW50IFByb3RvY29sPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAg ICAgICAgICAoT1dBTVApIGFuZCB0aGUgVHdvLVdheSBBY3RpdmUgTWVhc3VyZW1lbnQgUHJvdG9j b2w8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAgIChUV0FN UCkiLCBSRkMgODU0NSwgRE9JIDEwLjE3NDg3L1JGQzg1NDUsIE1hcmNoIDIwMTksPC9zcGFuPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJi bG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgICAgICAmbHQ7aHR0cHM6Ly93d3cu cmZjLWVkaXRvci5vcmcvaW5mby9yZmM4NTQ1Jmd0Oy48L3NwYW4+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij44LjIuICBJbmZvcm1hdGl2ZSBSZWZl cmVuY2VzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+OC4yLiAgSW5mb3JtYXRpdmUg UmVmZXJlbmNlczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHIgaWQ9ImRpZmYwMDIyIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5bQkJGLlRSLTM5MF08L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48 c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICAgICAgICJQZXJmb3JtYW5jZSBNZWFzdXJlbWVu dCBmcm9tIElQIEVkZ2UgdG8gQ3VzdG9tZXI8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4gICAgICAgICAgICAgIEVxdWlwbWVudCB1c2luZyBUV0FNUCBMaWdodCIsIEJCRiBUUi0z OTAsIE1heSAyMDE3Ljwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIFtJLUQuaWV0Zi1pcHBtLXN0YW1wLXlhbmddPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgW0ktRC5pZXRmLWlwcG0tc3RhbXAteWFuZ108L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgTWlyc2t5LCBHLiwgWGlhbywgTS4s IGFuZCBXLiBMdW8sICJTaW1wbGUgVHdvLXdheSBBY3RpdmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAgICAgICAgICAgIE1pcnNreSwgRy4sIFhpYW8sIE0uLCBhbmQgVy4gTHVv LCAiU2ltcGxlIFR3by13YXkgQWN0aXZlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAg ICAgICAgICAgIE1lYXN1cmVtZW50IFByb3RvY29sIChTVEFNUCkgRGF0YSBNb2RlbCIsIGRyYWZ0 LWlldGYtaXBwbS08L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAg IE1lYXN1cmVtZW50IFByb3RvY29sIChTVEFNUCkgRGF0YSBNb2RlbCIsIGRyYWZ0LWlldGYtaXBw bS08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAw MjMiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICBzdGFtcC15YW5nLTA8c3BhbiBjbGFzcz0iZGVs ZXRlIj4yICh3b3JrIGluIHByb2dyZXNzKSwgU2VwdGVtYmVyIDIwMTg8L3NwYW4+LjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgIHN0YW1wLXlhbmctMDxzcGFu IGNsYXNzPSJpbnNlcnQiPjMgKHdvcmsgaW4gcHJvZ3Jlc3MpLCBNYXJjaCAyMDE5PC9zcGFuPi48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW1JGQzIxMDRdICBLcmF3Y3p5aywg SC4sIEJlbGxhcmUsIE0uLCBhbmQgUi4gQ2FuZXR0aSwgIkhNQUM6IEtleWVkLTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtSRkMyMTA0XSAgS3Jhd2N6eWssIEguLCBCZWxsYXJl LCBNLiwgYW5kIFIuIENhbmV0dGksICJITUFDOiBLZXllZC08L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgICAgICAgICAgSGFzaGluZyBmb3IgTWVzc2FnZSBBdXRoZW50aWNhdGlvbiIs IFJGQyAyMTA0LDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAg SGFzaGluZyBmb3IgTWVzc2FnZSBBdXRoZW50aWNhdGlvbiIsIFJGQyAyMTA0LDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDMjEwNCwgRmVi cnVhcnkgMTk5Nyw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAg IERPSSAxMC4xNzQ4Ny9SRkMyMTA0LCBGZWJydWFyeSAxOTk3LDwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgICAgICAgICAgICAmbHQ7aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5m by9yZmMyMTA0Jmd0Oy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAg ICAgICZsdDtodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzIxMDQmZ3Q7LjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBbUkZDNDg2OF0gIEtlbGx5LCBTLiBhbmQg Uy4gRnJhbmtlbCwgIlVzaW5nIEhNQUMtU0hBLTI1NiwgSE1BQy1TSEEtPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgW1JGQzQ4NjhdICBLZWxseSwgUy4gYW5kIFMuIEZyYW5rZWws ICJVc2luZyBITUFDLVNIQS0yNTYsIEhNQUMtU0hBLTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICAgICAgICAgICAzODQsIGFuZCBITUFDLVNIQS01MTIgd2l0aCBJUHNlYyIsIFJGQyA0 ODY4LDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgMzg0LCBh bmQgSE1BQy1TSEEtNTEyIHdpdGggSVBzZWMiLCBSRkMgNDg2OCw8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzQ4NjgsIE1heSAyMDA3LDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3 L1JGQzQ4NjgsIE1heSAyMDA3LDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAg ICAgICAmbHQ7aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM0ODY4Jmd0Oy48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICZsdDtodHRwczovL3d3 dy5yZmMtZWRpdG9yLm9yZy9pbmZvL3JmYzQ4NjgmZ3Q7LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KCiAgICAgPHRyPjx0ZD48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQ+PC90ZD48L3RyPgogICAgIDx0ciBpZD0i ZW5kIiBiZ2NvbG9yPSJncmF5Ij48dGggY29sc3Bhbj0iNSIgYWxpZ249ImNlbnRlciI+Jm5ic3A7 RW5kIG9mIGNoYW5nZXMuIDIzIGNoYW5nZSBibG9ja3MuJm5ic3A7PC90aD48L3RyPgogICAgIDx0 ciBjbGFzcz0ic3RhdHMiPjx0ZD48L3RkPjx0aD48aT40OSBsaW5lcyBjaGFuZ2VkIG9yIGRlbGV0 ZWQ8L2k+PC90aD48dGg+PGk+IDwvaT48L3RoPjx0aD48aT43MyBsaW5lcyBjaGFuZ2VkIG9yIGFk ZGVkPC9pPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICA8dHI+PHRkIGNvbHNwYW49IjUiIGFsaWdu PSJjZW50ZXIiIGNsYXNzPSJzbWFsbCI+PGJyPlRoaXMgaHRtbCBkaWZmIHdhcyBwcm9kdWNlZCBi eSByZmNkaWZmIDEuNDcuIFRoZSBsYXRlc3QgdmVyc2lvbiBpcyBhdmFpbGFibGUgZnJvbSA8YSBo cmVmPSJodHRwOi8vd3d3LnRvb2xzLmlldGYub3JnL3Rvb2xzL3JmY2RpZmYvIj5odHRwOi8vdG9v bHMuaWV0Zi5vcmcvdG9vbHMvcmZjZGlmZi88L2E+IDwvdGQ+PC90cj4KICAgPC90Ym9keT48L3Rh YmxlPgogICAKICAgCjwvYm9keT48ZGl2PjxkaXYgY2xhc3M9ImdyXy1lZGl0b3IgZ3ItaWZyYW1l LWZpcnN0LWxvYWQiIHN0eWxlPSJkaXNwbGF5OiBub25lOyI+PGRpdiBjbGFzcz0iZ3JfLWVkaXRv cl9iYWNrIj48L2Rpdj48aWZyYW1lIGNsYXNzPSJncl8taWZyIGdyLV9kaWFsb2ctY29udGVudCIg c3JjPSIuL0RpZmZfIGRyYWZ0LWlldGYtaXBwbS1zdGFtcC0wNS50eHQgLSBkcmFmdC1pZXRmLWlw cG0tc3RhbXAtMDYudHh0X2ZpbGVzL3NhdmVkX3Jlc291cmNlLmh0bWwiPjwvaWZyYW1lPjwvZGl2 PjwvZGl2PjxncmFtbWFybHktY2FyZD48ZGl2PjwvZGl2PjwvZ3JhbW1hcmx5LWNhcmQ+PHNwYW4g Y2xhc3M9ImdyX190b29sdGlwIj48c3BhbiBjbGFzcz0iZ3JfX3Rvb2x0aXAtY29udGVudCI+PC9z cGFuPjxpIGNsYXNzPSJncl9fdG9vbHRpcC1sb2dvIj48L2k+PHNwYW4gY2xhc3M9ImdyX190cmlh bmdsZSI+PC9zcGFuPjwvc3Bhbj48L2h0bWw+ --000000000000d0001a0587216a08-- From nobody Mon Apr 22 11:07:09 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62B7B120122; Mon, 22 Apr 2019 11:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 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_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=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 EzfLgjNwaRgH; Mon, 22 Apr 2019 11:07:06 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C036E120077; Mon, 22 Apr 2019 11:07:05 -0700 (PDT) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 9588115BCE9B5A58A53C; Mon, 22 Apr 2019 19:07:03 +0100 (IST) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 22 Apr 2019 19:07:02 +0100 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.31]) by SJCEML703-CHM.china.huawei.com ([169.254.5.85]) with mapi id 14.03.0439.000; Mon, 22 Apr 2019 11:07:00 -0700 From: Haoyu song To: IETF IPPM WG , "draft-ietf-ippm-ioam-data@ietf.org" Thread-Topic: [ippm] updated postcard-based telemetry draft Thread-Index: AdT5Ni1I/N+4OysGSnGXpY8JMakpsQ== Date: Mon, 22 Apr 2019 18:06:59 +0000 Message-ID: <78A2745BE9B57D4F9D27F86655EB87F9376A7CF0@sjceml521-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.209.217.2] Content-Type: multipart/alternative; boundary="_000_78A2745BE9B57D4F9D27F86655EB87F9376A7CF0sjceml521mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [ippm] updated postcard-based telemetry draft X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 18:07:07 -0000 --_000_78A2745BE9B57D4F9D27F86655EB87F9376A7CF0sjceml521mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, We just updated the draft which reflects the side-meeting discussion result= s from IETF104. PBT-I is renamed as an IOAM mode, PHP (Per Hop Postcard) mode. The common = header fields are arranged to align with IOAM trace mode header and their s= pecification are supposed to be specified in the IOAM data draft. Please review the draft and provide your comments. Thank you very much! https://www.ietf.org/internet-drafts/draft-song-ippm-postcard-based-telemet= ry-03.txt Best regards, Haoyu --_000_78A2745BE9B57D4F9D27F86655EB87F9376A7CF0sjceml521mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

We just updated the draft which reflects the side-me= eting discussion results from IETF104.

PBT-I is renamed as an IOAM mode,  PHP (Per Hop= Postcard) mode. The common header fields are arranged to align with IOAM t= race mode header and their specification are supposed to be specified in th= e IOAM data draft.

Please review the draft and provide your comments. T= hank you very much!

 

https://www.ietf.org/internet-drafts/draft-song-ipp= m-postcard-based-telemetry-03.txt

 

Best regards,

Haoyu

--_000_78A2745BE9B57D4F9D27F86655EB87F9376A7CF0sjceml521mbschi_-- From nobody Mon Apr 22 21:39:52 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438721203D7; Mon, 22 Apr 2019 21:39:44 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 kPgwybHUBXxA; Mon, 22 Apr 2019 21:39:40 -0700 (PDT) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 396661203CE; Mon, 22 Apr 2019 21:39:40 -0700 (PDT) Received: by mail-qk1-x72a.google.com with SMTP id p185so7679913qkb.8; Mon, 22 Apr 2019 21:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vLF0KhRqyHZ8SgXCatWow+is9TJoNlUSO41iihU4jh4=; b=N/qJ0g6NU8wnc0SBvlPVFyRGgWw6hdSJKGUL28DCyoKxH6SPuJAJRBU889jUmam1ZW pDqocgBqrYueBehFhYEtz6UHpoO4E7Pun+4dH1WMrlKeS4ncjY3UKxBJQu5DKmBQM3Lg dnaia1eFQtyiOvJC36Ug6bY8za59YcrAo9yGw+Q1iLKuAJ6gMNsJItcpaAPMztwRRtEZ OZ5pMfyCtB5gk1DGTKdtzVfMhJ1WGMx6a9hl/CyXlkLG6kNfFwIZfkWxsC0ng4NDBgPR X7WTrpmvUas+h15h7S5c+QQrPZNAxmYuCKZZiLVrUn7+J0BFFqquqV5+iRFZaLFKajI5 XS2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vLF0KhRqyHZ8SgXCatWow+is9TJoNlUSO41iihU4jh4=; b=ECjk4EK3VE5WKdtDSwWAI6WJmsXErE8qZYogykImxDtIuZuvTvVryV+2ceehTbPByx HAu7XXLQwy/8ovESQjo6O1gxGpzZ+C945VYoXu1XxRp0g4XxAOV9j9lN6VHylEdqawfA CNVfGQftF56Dx+NBjFXdGS03uTNu4V8uhS3iitrmTzBW+0rQmxH7uMGe3w9gh+NY5Q1T MzYSXlmOSSyE7BiyNhSBpapUYoGHp0qCW32tTQv9b3+4oDPqtEOhrnm3r+CPdDHArUfc 4/+JgE7Q8UWK4wa2l+gpek6A+6kV5191uZQEV6g+J+uNeWqY2WrtSDDS+0qBRtST7+hX 1SIw== X-Gm-Message-State: APjAAAVB6X9W0835/u6aK9954lU8rUJ/6mMGU0XVL1Lpr0jEVU0/vz7i tyVMqSg6l53oiLHbrh4hW45pWGvxnsVROxa4g8k= X-Google-Smtp-Source: APXvYqyVLA5+Ut3ytBBvfmp2inrIFYgnAIFfEftesDun5pcHMMzjWoRkMkUZ1bJ/Fm7S1iRCeFyVP32yQjIl/G1pi9g= X-Received: by 2002:a37:4ed5:: with SMTP id c204mr17875103qkb.68.1555994379309; Mon, 22 Apr 2019 21:39:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tal Mizrahi Date: Tue, 23 Apr 2019 07:39:27 +0300 Message-ID: To: Greg Mirsky Cc: "Foote, Footer (Nokia - CA)" , guo.jun2@zte.com.cn, Henrik Nydell , IETF IPPM WG , IPPM Chairs Content-Type: multipart/alternative; boundary="00000000000040567b05872b2c6a" Archived-At: Subject: Re: [ippm] Shepherd Review of draft-ietf-ippm-stamp-05 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 04:39:52 -0000 --00000000000040567b05872b2c6a Content-Type: text/plain; charset="UTF-8" Hi Greg, Looks good. Many thanks for addressing the comments. There were some comments in WG LC which also need to be addressed: https://mailarchive.ietf.org/arch/msg/ippm/nAOnkGH9vD60hF4vcFAEqxVWLnI Please feel free to upload a new version once this update is complete. Thanks, Tal. On Mon, Apr 22, 2019 at 8:01 PM Greg Mirsky wrote: > Hi Tal, > please find the proposed updates in-lined and tagged GIM>>. Also, attached > are the diff and the updated working version of the draft. > Much appreciate your comments. > > Regards, > Greg > > On Sun, Apr 14, 2019 at 10:54 PM Tal Mizrahi > wrote: > >> Dear Authors, >> >> Having reviewed the document, I found that it is clear and >> straightforward, and that it is almost ready to be submitted to the IESG, >> with a few minor comments below. >> >> I will highly appreciate if you can post an updated draft, and afterwards >> we will proceed with the publication process. >> >> Thanks, >> Tal. >> >> >> Comments: >> >> - Section 1: I would suggest to mention that TWAMP Light is a lightweight >> architecture of a TWAMP deployment that is presented in RFC 5357. >> > GIM>> I've used the characterization of the TWAMP Light as provided in RFC > 8545: > OLD TEXT: > One of such is Performance Measurement from IP Edge to Customer > Equipment using TWAMP Light from > Broadband Forum ([BBF.TR-390]). > NEW TEXT: > One of such is Performance Measurement from IP Edge to Customer > Equipment using TWAMP Light from > Broadband Forum [BBF.TR-390] used as the reference TWAMP Light that, > according to [RFC8545], includes > sub-set of TWAMP-Test functions in combination with other applications > that provide, for example, control > and security. > > - Section 2: >> - The term OSS/BSS should be defined. >> - The acronym SDN should be spelled out in its first appearance. >> > GIM>> I've added the explanation of what OSS/BSS does and removed the SDN > acronym as it is the only place being used in the draft: > OLD TEXT: > Command Line Interface, OSS/BSS using SNMP or > SDN using Netconf/YANG are but a few examples. > NEW TEXT: > Command Line Interface, OSS/BSS (operations support > system/business support system as a combination of two > systems used to support a range of telecommunication > services) using SNMP or controllers in Software-Defined > Networking using Netconf/YANG are but a few examples. > > - Section 4: >> - "Unauthenticated STAMP test packets are compatible on the wire with >> unauthenticated TWAMP-Test [RFC5357] packet formats." >> Please explain what "compatible" means. The format defined in STAMP is >> identical to RFC 5357? Can be configured to a specific mode in which it is >> identical to RFC 5357? An RFC 5357 TWAMP node can interoperate with a STAMP >> node? You may want to add a reference here to section 4.4. >> > GIM>> Thank you for the detailed questions and the recommendation. Please > consider the update below: > OLD TEXT: > Unauthenticated STAMP test > packets are compatible on the wire with unauthenticated TWAMP-Test > [RFC5357] packet formats. > NEW TEXT: > Unauthenticated STAMP test > packets, defined in Section 4.1.1 and Section 4.2.1, ensure > interworking between STAMP and TWAMP Light as described in > Section 4.4. packet formats. > > - Section 4.1.1.: >> - Please clarify that the timestamp field is as specified in RFC 5357 and >> RFC 8186. >> > GIM>> I've added references to RFC 5357 and RFC 8186 as follows: > OLD TEXT: > o Timestamp is eight octets long field. STAMP node MUST support > Network Time Protocol (NTP) version 4 64-bit timestamp format > [RFC5905]. STAMP node MAY support IEEE 1588v2 Precision Time > Protocol truncated 64-bit timestamp format [IEEE.1588.2008]. > NEW TEXT: > o Timestamp is eight octets long field. STAMP node MUST support > Network Time Protocol (NTP) version 4 64-bit timestamp format > [RFC5905], the format used in [RFC5357]. STAMP node MAY support > IEEE 1588v2 Precision Time Protocol truncated 64-bit timestamp > format [IEEE.1588.2008], the format used in [RFC8186]. > > - "The Reflect Octets capability defined in [RFC6038]." ==> "This field is >> used for the Reflect Octets capability defined in [RFC6038]." >> > GIM>> Thank you for the helpful suggestion. Done. > > - Section 4.1.2. + 4.2.2. + 4.3: >> - Please clarify that the HMAC field is as defined in RFC 5357, and >> covers the same fields as defined in RFC 5357. >> > GIM>> Hashed Message Authentication Code is defined in RFC 2104. Unlike > OWAMP or TWAMP that use HMAC-SHA-1, in STAMP we use HMAC-SHA-256. And in > STAMP HMAC also protects optional extensions. I hope that the addition of > the forward reference to Section 4.3 in 4.1.2 and 4.2.2 is acceptable. > >> - Section 4.2.1.: >> - "the TTL field" ==> "the TTL field in IPv4 (or Hop Limit in IPv6)" >> > GIM>> Thank you. Accepted and done. > >> - Section 4.3: >> - "If confidentiality protection for STAMP is required, encryption at the >> higher level MUST be used." >> Please elaborate, preferably with an example. IPsec is at a lower layer >> than STAMP, so not sure "higher level" is clear to the reader. >> > GIM>> STAMP can be sent over its IPsec tunnel or share the IPsec tunnel of > the flow which performance is monitored. Please consider this update: > OLD TEXT: > If confidentiality protection for STAMP is required, encryption at > the higher level MUST be used. > NEW TEXT: > If confidentiality protection for STAMP is required, encryption at > the higher level MUST be used. For example, STAMP packets could be > transmitted in the dedicated IPsec tunnel or share the IPsec tunnel > with the monitored flow. > > - Section 5: >> - This section should be more detailed. You may want to say that the >> general security considerations of TWAMP are discussed in RFC 5357. You may >> also want to explain that the main difference between STAMP and TWAMP is >> the control plane, and you may want to make note that STAMP configuration >> procedures should be secured in order to mitigate attacks at the control >> plane. >> > GIM>> Yes, agree. The Security Considerations section is a bit terse. > Here's the updated text: > 6. Security Considerations > > In general, all the security considerations related to TWAMP-Test, > discussed in [RFC5357]apply to STAMP. Since STAMP uses the well- > known UDP port number allocated for the OWAMP-Test/TWAMP-Test > Receiver port, the security considerations and measures to mitigate > the risk of the attack using the registered port number documented in > Section 6 [RFC8545] equally apply to STAMP. Because the control and > management of a STAMP test are outside the scope of this > specification only the more general requirement is set: > > To mitigate the possible attack vector, the control and management > of a STAMP test session MUST use the secured transport. > > Use of HMAC-SHA-256 in the authenticated mode protects the data > integrity of the STAMP test packets. > > - References: >> - I suggest to move "[BBF.TR-390]" to the informative references. >> > GIM>> Agreed and done. > >> - draft-ietf-ippm-port-twamp-test ==> RFC 8545. >> > GIM>> Done > >> - Minor nit: >> - "less the length" ==> "minus the length" >> > GIM>> Thank you. Done. > --00000000000040567b05872b2c6a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Greg,

Looks good. Many thanks for ad= dressing the comments.

There were some comments in= WG LC which also need to be addressed:
<= br>
Please feel free to upload a new version once this update is = complete.

Thanks,
Tal.=C2=A0




On Mon, Apr 22, 2019 at 8:01 PM = Greg Mirsky <gregimirsky@gmail.= com> wrote:
<= div dir=3D"ltr">Hi Tal,
please find the proposed updates in-lined and t= agged GIM>>. Also, attached are the diff and the updated working vers= ion of the draft.
Much appreciate your comments.

Regards,
Greg

=
On Sun, Apr 14, 2019 at 10:54 PM Tal = Mizrahi <= tal.mizrahi.phd@gmail.com> wrote:
Dear Authors,
Having reviewed the document, I found that it is clear and= straightforward, and that it is almost ready to be submitted to the IESG, = with a few minor comments below.

I will highly app= reciate if you can post an updated draft, and afterwards we will proceed wi= th the publication process.

Thanks,
= Tal.


Comments:

=
- Section 1: I would suggest to mention that TWAMP Light is a lig= htweight architecture of a TWAMP deployment that is presented in RFC 5357.<= /div>
GIM>> I've used the char= acterization of the TWAMP Light as provided in RFC 8545:=C2=A0
OL= D TEXT:
=C2=A0 =C2=A0One of such is Performance=C2=A0Measurement = from IP Edge to Customer Equipment using TWAMP Light from
=C2=A0 = =C2=A0Broadband Forum ([BBF.TR-390]).
NEW TEXT:
=C2=A0 = =C2=A0One of such is Performance Measurement from IP Edge to Customer Equip= ment using TWAMP Light from
=C2=A0 =C2=A0Broadband Forum [BBF.TR-= 390] used as the reference TWAMP Light that, according to [RFC8545], includ= es
=C2=A0 =C2=A0sub-set of TWAMP-Test functions in combination wi= th other applications that provide, for example, control
=C2=A0 = =C2=A0and security.

- Section 2:
- The term OSS/BSS shou= ld be defined.
- The= acronym SDN should be spelled out in its first appearance.
GIM>> I've added the explanation of wha= t OSS/BSS does and removed the SDN acronym as it is the only place being us= ed in the draft:=C2=A0
OLD TEXT:
=C2=A0 =C2=A0Command L= ine Interface, OSS/BSS using SNMP or
=C2=A0 =C2=A0SDN using Netco= nf/YANG are but a few examples.
NEW TEXT:
=C2=A0 =C2=A0= Command Line Interface, OSS/BSS (operations support
=C2=A0 =C2=A0= system/business support system as a combination of two
=C2=A0 =C2= =A0systems used to support a range of telecommunication
=C2=A0 = =C2=A0services) using SNMP or controllers in Software-Defined
=C2= =A0 =C2=A0Networking using Netconf/YANG are but a few examples.

- Section 4:=C2=A0
- "Unauthenticated STAMP test packets a= re compatible on the wire with unauthenticated TWAMP-Test [RFC5357] packet = formats."
=C2= =A0 Please explain what "compatible" means. The format defined in= STAMP is identical to RFC 5357? Can be configured to a specific mode in wh= ich it is identical to RFC 5357? An RFC 5357 TWAMP node can interoperate wi= th a STAMP node? You may want to add a reference here to section 4.4.
=
GIM>> Thank you for the detailed = questions and the recommendation. Please consider the update below:=C2=A0
OLD TEXT:
=C2=A0 =C2=A0Unauthenticated STAMP test
<= div>=C2=A0 =C2=A0packets are compatible on the wire with unauthenticated TW= AMP-Test
=C2=A0 =C2=A0[RFC5357] packet formats.=C2=A0
N= EW TEXT:
=C2=A0 =C2=A0Unauthenticated STAMP test
= =C2=A0 =C2=A0packets, defined in Section 4.1.1 and Section 4.2.1, ensure
=C2=A0 =C2=A0interworking between STAMP and TWAMP Light as describe= d in
=C2=A0 =C2=A0Section 4.4.=C2=A0 packet formats.
<= div>
- Section 4.1.1.:
- Please clarify that the timestamp field is as specified in RFC 5357 a= nd RFC 8186.
GIM>> I've = added references to RFC 5357 and RFC 8186 as follows:
OLD TEXT:
=C2=A0 =C2=A0o=C2=A0 Timestamp is eight octets long field.=C2=A0 S= TAMP node MUST support
=C2=A0 =C2=A0 =C2=A0 Network Time Protocol= (NTP) version 4 64-bit timestamp format
=C2=A0 =C2=A0 =C2=A0 [RF= C5905].=C2=A0 STAMP node MAY support IEEE 1588v2 Precision Time
= =C2=A0 =C2=A0 =C2=A0 Protocol truncated 64-bit timestamp format [IEEE.1588.= 2008].
NEW TEXT:
=C2=A0 =C2=A0 o=C2=A0 Timestamp is eig= ht octets long field.=C2=A0 STAMP node MUST support
=C2=A0 =C2=A0= =C2=A0 Network Time Protocol (NTP) version 4 64-bit timestamp format
=
=C2=A0 =C2=A0 =C2=A0 [RFC5905], the format used in [RFC5357].=C2=A0 ST= AMP node MAY support
=C2=A0 =C2=A0 =C2=A0 IEEE 1588v2 Precision T= ime Protocol truncated 64-bit timestamp
=C2=A0 =C2=A0 =C2=A0 form= at [IEEE.1588.2008], the format used in [RFC8186].

- "The Ref= lect Octets capability defined in [RFC6038]." =3D=3D> "This fi= eld is used for the Reflect Octets capability defined in [RFC6038]."
GIM>> Thank you for the helpf= ul suggestion. Done.=C2=A0

- Section= 4.1.2. + 4.2.2. + 4.3:
- Please clarify that the HMAC field is as defined in RFC 5357, and cov= ers the same fields as defined in RFC 5357.
GIM>>=C2=A0Hashed Message Authentication Code is defined in= RFC 2104. Unlike OWAMP or TWAMP that use HMAC-SHA-1, in STAMP we use HMAC-= SHA-256. And in STAMP HMAC also protects optional extensions. I hope that t= he addition of the forward reference to Section 4.3 in 4.1.2 and 4.2.2 is a= cceptable.
- Section 4.2.1.:
= - "the TTL field" =3D=3D> "the TTL field in IPv4 (= or Hop Limit in IPv6)"
GIM>= ;> Thank you. Accepted and done.=C2=A0
- Section= 4.3:=C2=A0
- "= If confidentiality protection for STAMP is required, encryption at the high= er level MUST be used."
=C2=A0 Please elaborate, preferably with an example. IPsec is at a= lower layer than STAMP, so not sure "higher level" is clear to t= he reader.
GIM>> STAMP can b= e sent over its IPsec tunnel or share the IPsec tunnel of the flow which pe= rformance is monitored. Please consider this update:
OLD TEXT:
=C2=A0 =C2=A0If confidentiality protection for STAMP is requir= ed, encryption at
=C2=A0 =C2=A0the higher level MUST be used.
NEW TEXT:
=C2=A0 =C2=A0If confidentiality prote= ction for STAMP is required, encryption at
=C2=A0 =C2=A0the highe= r level MUST be used.=C2=A0 For example, STAMP packets could be
= =C2=A0 =C2=A0transmitted in the dedicated IPsec tunnel or share the IPsec t= unnel
=C2=A0 =C2=A0with the monitored flow.

<= /div>
- Section 5:
- This section should be more detailed. You may want to sa= y that the general security considerations of TWAMP are discussed in RFC 53= 57. You may also want to explain that the main difference between STAMP and= TWAMP is the control plane, and you may want to make note that STAMP confi= guration procedures should be secured in order to mitigate attacks at the c= ontrol plane.
GIM>> Yes, agr= ee. The Security Considerations section is a bit terse. Here's the upda= ted text:
=C2=A06.=C2=A0 Security Considerations

=C2=A0 =C2=A0In general, all the security considerations related t= o TWAMP-Test,
=C2=A0 =C2=A0discussed in [RFC5357]apply to STAMP.= =C2=A0 Since STAMP uses the well-
=C2=A0 =C2=A0known UDP port num= ber allocated for the OWAMP-Test/TWAMP-Test
=C2=A0 =C2=A0Receiver= port, the security considerations and measures to mitigate
=C2= =A0 =C2=A0the risk of the attack using the registered port number documente= d in
=C2=A0 =C2=A0Section 6 [RFC8545] equally apply to STAMP.=C2= =A0 Because the control and
=C2=A0 =C2=A0management of a STAMP te= st are outside the scope of this
=C2=A0 =C2=A0specification only = the more general requirement is set:

=C2=A0 =C2=A0= =C2=A0 To mitigate the possible attack vector, the control and management<= /div>
=C2=A0 =C2=A0 =C2=A0 of a STAMP test session MUST use the secured= transport.

=C2=A0 =C2=A0Use of HMAC-SHA-256 in th= e authenticated mode protects the data
=C2=A0 =C2=A0integrity of = the STAMP test packets.

- References= :
- I suggest to mov= e "[BBF.TR-390]" to the informative references.
=
GIM>> Agreed and done.=C2=A0
- draft-ietf-ippm-port= -twamp-test =3D=3D> RFC 8545.
G= IM>> Done=C2=A0
- Minor nit:
- "less the length" =3D=3D= > "minus the length"
= GIM>> Thank you. Done.=C2=A0
--00000000000040567b05872b2c6a-- From nobody Tue Apr 23 13:42:01 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09AC12037B for ; Tue, 23 Apr 2019 13:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 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_COMMENT_SAVED_URL=1.391, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 FtGwmRwltM9f for ; Tue, 23 Apr 2019 13:41:52 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0039120374 for ; Tue, 23 Apr 2019 13:41:50 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id h21so14712073ljk.13 for ; Tue, 23 Apr 2019 13:41:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1nVLCBYsjS4qmNNI6AK5acuNVW/oFtloVXsBXuDacMY=; b=Kh1euaBRwAT1smtHURe0TXs4t8SKA+oJoZTABU+I6LvYuACxJg7QERMVbPZOT/XQlD fYbUY3h8t2dVFtEj1svqKqgOc69c36g2TIQhcnu4RIAWR4I8Bleur+EWV6D2Zyp2/8Zw jnmqihUjWiF5UKuME61hpo23v1n+vm5ojh6ItWODUF+BvovxYIuRv+JwPAiSpm3ko0ig 8ql9knqz5A1XBV9ERrfM0N4GTKLib721CBpP778stX2Ea+huimQpAhcXKjUeWlcizLw3 p3GyrseOjvsCh79pVZBHQV7eSmEQhDM642WvdE3aMcA8lJHrrgpxuzvf4Se/UaKGLtCV 1YrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1nVLCBYsjS4qmNNI6AK5acuNVW/oFtloVXsBXuDacMY=; b=DhO7RFVjzQkeqNI5hdJ4Izd4+PCBW69Ba49m3xN5ILw2HH/AJoZiPVU1Mi8H9mPgvq /3hc9DaCxWWTKpCRRo/KA9yl8sMRVZnnKlLzlH8OLYf4/aCry03YZ3NedjUZrl2pf3iT OrjEby+mZnMTuZz8F+n01KJAu9FPSlDGyZBAhPTg9REudVpn2RV7L7Os87vUES5C9eoR z90idOlN2r8zFtLvb3mHJIoHZEM/lofunRcgml4vq+Q2ZNqjuZAXoQwcY1sTNzV8RKB9 Xp0kdQiFoUTElGZl/AFxysLtEDbx+rKxICxqWyTbZ76eFNxA7CR7214dL49JwXGX/f8S Hn+Q== X-Gm-Message-State: APjAAAVUrE9HQjEFQoYuYhf+5R4uRvLpPPKwo71Ui6l0hQEPNDTs8ImC P/mDmlP0maYNjm8mZPVZBgfCG2JAIbZmebQiMAU= X-Google-Smtp-Source: APXvYqzLKF082FFx24BizxVj/GTvbRQWlyzXwCuPtRTXcrqFdZbc4f6NtzsqEu8SkosmuThRx7MPKbdHWou5m6oje8k= X-Received: by 2002:a2e:3009:: with SMTP id w9mr121263ljw.14.1556052108959; Tue, 23 Apr 2019 13:41:48 -0700 (PDT) MIME-Version: 1.0 References: <3600b860-32f8-0636-7093-eaddd2fb380d@cisco.com> In-Reply-To: <3600b860-32f8-0636-7093-eaddd2fb380d@cisco.com> From: Greg Mirsky Date: Tue, 23 Apr 2019 13:41:38 -0700 Message-ID: To: David Ball , Tal Mizrahi Cc: IETF IPPM WG Content-Type: multipart/mixed; boundary="000000000000350e7c0587389d02" Archived-At: Subject: Re: [ippm] Working Group Last Call on draft-ietf-ippm-stamp-05 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 20:41:59 -0000 --000000000000350e7c0587389d02 Content-Type: multipart/alternative; boundary="000000000000350e7a0587389d00" --000000000000350e7a0587389d00 Content-Type: text/plain; charset="UTF-8" Hi David, apologies for the delayed update. I've prepared the new version of the draft to address your comments and comments by the draft Shepherd Tal Mizrahi. Please find the diff, the updated new version attached. Also, I've added a couple explaining notes in-line below under the GIM>> tag. Much appreciate your feedback. Regards, Greg On Tue, Mar 5, 2019 at 8:26 AM David Ball wrote: > Hi, > > I have reviewed the document and am fine with it progressing. > > A few nits: > > - The text at the start of Sn 4.1.1 should be before the 4.1.1 heading > (after the 4.1 heading). > > GIM>> Accepted and done. > > - Sn 4.1.1 - the bullet about Server Octets has a spurious extra > part-sentence: "The Reflect Octets capability defined in [RFC6038]." - this > should be deleted. > > GIM>> The comment from Shepherd suggested re-wording the sentence. Please let me know if the following change is acceptable: OLD TEXT: The Reflect Octets capability defined in [RFC6038]. NEW TEXT: This field is used for the Reflect Octets capability defined in [RFC6038]. > > - > - Fig 4 shows a min length of 112 (if I counted right); but text at > the start of 4.1.1 says the min length in authenticated mode is 48. > > GIM>> Great catch, thank you! It must be 112 - corrected the text. > > - The wording/grammar in the paragraph after bullets in Sn 4.4 is a > little awkward - suggested edits below: > > "In the former case, the Session-Sender MAY not be aware that its Session- > Reflector does not support STAMP. For example, a TWAMP Light Session- > Reflector may not support the use of UDP port 862 as defined in > [I-D.ietf-ippm-port-twamp-test ]. Thus, the STAMP Session-Sender MUST be > able to send test packets to destination UDP port numbers taken from the > Dynamic and/or Private Ports range 49152-65535. The test management > system should find a port number that both devices can use. If any > of the TLV-based STAMP extensions are used, the TWAMP Light Session- > Reflector will view them as Packet Padding field. The Session-Sender > SHOULD use the default format for its timestamps (NTP) but it MAY > use PTPv2 timestamp format." > > GIM>> Many thanks. Accepted. > > David > > > -- > David Ball > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > --000000000000350e7a0587389d00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi David,
apologies = for the delayed update. I've prepared the new version of the draft to a= ddress your comments and comments by the draft Shepherd Tal Mizrahi. Please= find the diff, the updated new version attached. Also, I've added a co= uple explaining notes in-line below under the GIM>> tag.
Mu= ch appreciate your feedback.

Regards,
Gr= eg


On Tue, Mar 5, 2019 at 8:26 AM David Ball <daviball@cisco.com> wrote:
=
=20 =20 =20

Hi,

I have reviewed the document and am fine with it progressing.

A few nits:

  • The text at the start of Sn 4.1.1 should be before the 4.1.1 heading (after the 4.1 heading).
G= IM>> Accepted and done.=C2=A0
  • Sn 4.1.1 - the bullet about Server Octets has a spurious extra part-sentence: "The Reflect Octets capability defined in [RFC6038]." - this should be deleted.
GIM>> The comment from Shepherd suggested re-wording the= sentence. Please let me know if the following change is acceptable:
<= div>OLD TEXT:
The Reflect Octets capability defined in [RFC6038].= =C2=A0
NEW TEXT:
This field is used for the Reflect Oct= ets capability defined in [RFC6038].=C2=A0
  • Fig 4 shows a min length of 112 (if I counted right); but text at the start of 4.1.1 says the min length in authenticated mode is 48.
GIM>> Great catch, th= ank you! It must be 112 - corrected the text.=C2=A0
  • The wording/grammar in the paragraph after bullets in Sn 4.4 is a little awkward - suggested edits below:
  "In the forme=
r case, the Session-Sender MAY not be aware =
that its Session-
   Reflector does not support STAMP.  For example, =
a TWAMP Light Session-
   Reflector may not support the use of UDP port 862 as defined in
   [I-D.ietf-ippm-port-twamp-test].  T=
hus, the STAMP Session-Sender MUST be
   able to send test packets to destination UDP port numbers taken from the
   Dynamic and/or Private Ports range 49152-65535. =
 The test management
   system should find a port number that bot=
h devices can use.  If any
   of the TLV-based STAMP extensions are use=
d, the TWAMP Light Session-
   Reflector will view them as Packet Padding field.  The Session-Sender
   SHOULD use the default format for its timestamps (NTP) but it MAY
   use PTPv2 timestamp format."
GIM>&g= t; Many thanks. Accepted.=C2=A0

=C2=A0=C2=A0=C2=A0 David


--=
=20
David Ball
<daviball@cisco.com>
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
--000000000000350e7a0587389d00-- --000000000000350e7c0587389d02 Content-Type: text/plain; charset="US-ASCII"; name="draft-ietf-ippm-stamp-06.txt" Content-Disposition: attachment; filename="draft-ietf-ippm-stamp-06.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_juu97bos1 CgoKCk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIEcuIE1pcnNreQpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBaVEUgQ29ycC4KSW50ZW5kZWQgc3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRy4gSnVuCkV4cGly ZXM6IE9jdG9iZXIgMjUsIDIwMTkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFpURSBD b3Jwb3JhdGlvbgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBILiBOeWRlbGwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIEFjY2VkaWFuIE5ldHdvcmtzCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSLiBGb290 ZQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgTm9raWEKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEFwcmlsIDIzLCAyMDE5CgoKICAgICAgICAgICAgICAgU2ltcGxl IFR3by13YXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29sCiAgICAgICAgICAgICAgICAgICAg ICAgIGRyYWZ0LWlldGYtaXBwbS1zdGFtcC0wNgoKQWJzdHJhY3QKCiAgIFRoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIGEgU2ltcGxlIFR3by13YXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29sCiAg IHdoaWNoIGVuYWJsZXMgdGhlIG1lYXN1cmVtZW50IG9mIGJvdGggb25lLXdheSBhbmQgcm91bmQt dHJpcAogICBwZXJmb3JtYW5jZSBtZXRyaWNzIGxpa2UgZGVsYXksIGRlbGF5IHZhcmlhdGlvbiwg YW5kIHBhY2tldCBsb3NzLgoKU3RhdHVzIG9mIFRoaXMgTWVtbwoKICAgVGhpcyBJbnRlcm5ldC1E cmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZQogICBwcm92aXNp b25zIG9mIEJDUCA3OCBhbmQgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSB3b3JraW5n IGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcKICAgVGFzayBGb3JjZSAoSUVU RikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUKICAgd29ya2lu ZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRl cm5ldC0KICAgRHJhZnRzIGlzIGF0IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZHJhZnRz L2N1cnJlbnQvLgoKICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQg Zm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFj ZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1bWVudHMgYXQgYW55CiAgIHRpbWUuICBJdCBp cyBpbmFwcHJvcHJpYXRlIHRvIHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1h dGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIK CiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gT2N0b2JlciAyNSwgMjAxOS4K CkNvcHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoYykgMjAxOSBJRVRGIFRydXN0IGFuZCB0 aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJp Z2h0cyByZXNlcnZlZC4KCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5k IHRoZSBJRVRGIFRydXN0J3MgTGVnYWwKICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERv Y3VtZW50cwogICAoaHR0cHM6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZm ZWN0IG9uIHRoZSBkYXRlIG9mCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVh c2UgcmV2aWV3IHRoZXNlIGRvY3VtZW50cwogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUg eW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QKICAgdG8gdGhpcyBkb2N1 bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QK CgoKTWlyc2t5LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDI1LCAyMDE5ICAgICAg ICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIFNU QU1QICAgICAgICAgICAgICAgICAgICAgICBBcHJpbCAyMDE5CgoKICAgaW5jbHVkZSBTaW1wbGlm aWVkIEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mCiAgIHRo ZSBUcnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50 eSBhcwogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuCgpUYWJsZSBv ZiBDb250ZW50cwoKICAgMS4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAyCiAgIDIuICBDb252ZW50aW9ucyB1c2VkIGluIHRo aXMgZG9jdW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMwogICAgIDIuMS4gIFRl cm1pbm9sb2d5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg IDMKICAgICAyLjIuICBSZXF1aXJlbWVudHMgTGFuZ3VhZ2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gICAzCiAgIDMuICBTb2Z0d2FyaXphdGlvbiBvZiBQZXJmb3JtYW5jZSBN ZWFzdXJlbWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMwogICA0LiAgVGhlb3J5IG9mIE9wZXJh dGlvbiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQKICAgICA0 LjEuICBTZXNzaW9uLVNlbmRlciBCZWhhdmlvciBhbmQgUGFja2V0IEZvcm1hdCAuIC4gLiAuIC4g LiAuIC4gICA0CiAgICAgICA0LjEuMS4gIFNlc3Npb24tU2VuZGVyIFBhY2tldCBGb3JtYXQgaW4g VW5hdXRoZW50aWNhdGVkIE1vZGUgICAgNAogICAgICAgNC4xLjIuICBTZXNzaW9uLVNlbmRlciBQ YWNrZXQgRm9ybWF0IGluIEF1dGhlbnRpY2F0ZWQgTW9kZSAgLiAgIDYKICAgICA0LjIuICBTZXNz aW9uLVJlZmxlY3RvciBCZWhhdmlvciBhbmQgUGFja2V0IEZvcm1hdCAgLiAuIC4gLiAuIC4gICA3 CiAgICAgICA0LjIuMS4gIFNlc3Npb24tUmVmbGVjdG9yIFBhY2tldCBGb3JtYXQgaW4gVW5hdXRo ZW50aWNhdGVkCiAgICAgICAgICAgICAgIE1vZGUgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOAogICAgICAgNC4yLjIuICBTZXNzaW9uLVJlZmxlY3Rv ciBQYWNrZXQgRm9ybWF0IGluIEF1dGhlbnRpY2F0ZWQgTW9kZSAgIDkKICAgICA0LjMuICBJbnRl Z3JpdHkgYW5kIENvbmZpZGVudGlhbGl0eSBQcm90ZWN0aW9uIGluIFNUQU1QIC4gLiAuIC4gIDEx CiAgICAgNC40LiAgSW50ZXJvcGVyYWJpbGl0eSB3aXRoIFRXQU1QIExpZ2h0IC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuICAxMQogICA1LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgMTIKICAgNi4gIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEyCiAgIDcuICBB Y2tub3dsZWRnbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuICAxMgogICA4LiAgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgMTIKICAgICA4LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gIDEyCiAgICAgOC4yLiAgSW5mb3Jt YXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxMwog ICBBdXRob3JzJyBBZGRyZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAgMTQKCjEuICBJbnRyb2R1Y3Rpb24KCiAgIERldmVsb3BtZW50IGFuZCBkZXBs b3ltZW50IG9mIFR3by1XYXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29sCiAgIChUV0FNUCkg W1JGQzUzNTddIGFuZCBpdHMgZXh0ZW5zaW9ucywgZS5nLiwgW1JGQzYwMzhdIHRoYXQgZGVmaW5l ZAogICBmZWF0dXJlcyBzdWNoIGFzIFJlZmxlY3QgT2N0ZXRzIGFuZCBTeW1tZXRyaWNhbCBTaXpl IGZvciBUV0FNUAogICBwcm92aWRlZCBpbnZhbHVhYmxlIGV4cGVyaWVuY2UuICBTZXZlcmFsIGlu ZGVwZW5kZW50IGltcGxlbWVudGF0aW9ucwogICBleGlzdCwgaGF2ZSBiZWVuIGRlcGxveWVkIGFu ZCBwcm92aWRlIGltcG9ydGFudCBvcGVyYXRpb25hbAogICBwZXJmb3JtYW5jZSBtZWFzdXJlbWVu dHMuICBBdCB0aGUgc2FtZSB0aW1lLCB0aGVyZSBoYXMgYmVlbgogICBub3RpY2VhYmxlIGludGVy ZXN0IGluIHVzaW5nIGEgc2ltcGxlciBtZWNoYW5pc20gZm9yIGFjdGl2ZQogICBwZXJmb3JtYW5j ZSBtb25pdG9yaW5nIHRoYXQgY2FuIHByb3ZpZGUgZGV0ZXJtaW5pc3RpYyBiZWhhdmlvciBhbmQK ICAgaW5oZXJpdCBzZXBhcmF0aW9uIG9mIGNvbnRyb2wgKHZlbmRvci1zcGVjaWZpYyBjb25maWd1 cmF0aW9uIG9yCiAgIG9yY2hlc3RyYXRpb24pIGFuZCB0ZXN0IGZ1bmN0aW9ucy4gIE9uZSBvZiBz dWNoIGlzIFBlcmZvcm1hbmNlCiAgIE1lYXN1cmVtZW50IGZyb20gSVAgRWRnZSB0byBDdXN0b21l ciBFcXVpcG1lbnQgdXNpbmcgVFdBTVAgTGlnaHQgZnJvbQogICBCcm9hZGJhbmQgRm9ydW0gW0JC Ri5UUi0zOTBdIHVzZWQgYXMgdGhlIHJlZmVyZW5jZSBUV0FNUCBMaWdodCB0aGF0LAogICBhY2Nv cmRpbmcgdG8gW1JGQzg1NDVdLCBpbmNsdWRlcyBzdWItc2V0IG9mIFRXQU1QLVRlc3QgZnVuY3Rp b25zIGluCiAgIGNvbWJpbmF0aW9uIHdpdGggb3RoZXIgYXBwbGljYXRpb25zIHRoYXQgcHJvdmlk ZSwgZm9yIGV4YW1wbGUsCiAgIGNvbnRyb2wgYW5kIHNlY3VyaXR5LiAgVGhpcyBkb2N1bWVudCBk ZWZpbmVzIGFjdGl2ZSBwZXJmb3JtYW5jZQogICBtZWFzdXJlbWVudCB0ZXN0IHByb3RvY29sLCBT aW1wbGUgVHdvLXdheSBBY3RpdmUgTWVhc3VyZW1lbnQgUHJvdG9jb2wKCgoKCk1pcnNreSwgZXQg YWwuICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyNSwgMjAxOSAgICAgICAgICAgICAgICBbUGFn ZSAyXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBTVEFNUCAgICAgICAgICAg ICAgICAgICAgICAgQXByaWwgMjAxOQoKCiAgIChTVEFNUCksIHRoYXQgZW5hYmxlcyBtZWFzdXJl bWVudCBvZiBib3RoIG9uZS13YXkgYW5kIHJvdW5kLXRyaXAKICAgcGVyZm9ybWFuY2UgbWV0cmlj cyBsaWtlIGRlbGF5LCBkZWxheSB2YXJpYXRpb24sIGFuZCBwYWNrZXQgbG9zcy4KCjIuICBDb252 ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9jdW1lbnQKCjIuMS4gIFRlcm1pbm9sb2d5CgogICBBRVMg QWR2YW5jZWQgRW5jcnlwdGlvbiBTdGFuZGFyZAoKICAgQ0JDIENpcGhlciBCbG9jayBDaGFpbmlu ZwoKICAgRUNCIEVsZWN0cm9uaWMgQ29va2Jvb2sKCiAgIEtFSyBLZXktZW5jcnlwdGlvbiBLZXkK CiAgIFNUQU1QIC0gU2ltcGxlIFR3by13YXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29sCgog ICBOVFAgLSBOZXR3b3JrIFRpbWUgUHJvdG9jb2wKCiAgIFBUUCAtIFByZWNpc2lvbiBUaW1lIFBy b3RvY29sCgogICBITUFDIEhhc2hlZCBNZXNzYWdlIEF1dGhlbnRpY2F0aW9uIENvZGUKCiAgIE9X QU1QIE9uZS1XYXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29sCgogICBUV0FNUCBUd28tV2F5 IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbAoKMi4yLiAgUmVxdWlyZW1lbnRzIExhbmd1YWdl CgogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxM IiwgIlNIQUxMIE5PVCIsCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIs ICJOT1QgUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kCiAgICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1 bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGluIEJDUAogICAxNCBbUkZD MjExOV0gW1JGQzgxNzRdIHdoZW4sIGFuZCBvbmx5IHdoZW4sIHRoZXkgYXBwZWFyIGluIGFsbAog ICBjYXBpdGFscywgYXMgc2hvd24gaGVyZS4KCjMuICBTb2Z0d2FyaXphdGlvbiBvZiBQZXJmb3Jt YW5jZSBNZWFzdXJlbWVudAoKICAgRmlndXJlIDEgcHJlc2VudHMgdGhlIFNpbXBsZSBUd28td2F5 IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbAogICAoU1RBTVApIFNlc3Npb24tU2VuZGVyIGFu ZCBTZXNzaW9uLVJlZmxlY3RvciB3aXRoIGEgbWVhc3VyZW1lbnQKICAgc2Vzc2lvbi4gIFRoZSBj b25maWd1cmF0aW9uIGFuZCBtYW5hZ2VtZW50IG9mIHRoZSBTVEFNUCBTZXNzaW9uLQogICBTZW5k ZXIsIFNlc3Npb24tUmVmbGVjdG9yIGFuZCBtYW5hZ2VtZW50IG9mIHRoZSBTVEFNUCBzZXNzaW9u cyBjYW4gYmUKICAgYWNoaWV2ZWQgdGhyb3VnaCB2YXJpb3VzIG1lYW5zLiAgQ29tbWFuZCBMaW5l IEludGVyZmFjZSwgT1NTL0JTUwogICAob3BlcmF0aW9ucyBzdXBwb3J0IHN5c3RlbS9idXNpbmVz cyBzdXBwb3J0IHN5c3RlbSBhcyBhIGNvbWJpbmF0aW9uCiAgIG9mIHR3byBzeXN0ZW1zIHVzZWQg dG8gc3VwcG9ydCBhIHJhbmdlIG9mIHRlbGVjb21tdW5pY2F0aW9uIHNlcnZpY2VzKQogICB1c2lu ZyBTTk1QIG9yIGNvbnRyb2xsZXJzIGluIFNvZnR3YXJlLURlZmluZWQgTmV0d29ya2luZyB1c2lu ZwogICBOZXRjb25mL1lBTkcgYXJlIGJ1dCBhIGZldyBleGFtcGxlcy4KCgoKCgpNaXJza3ksIGV0 IGFsLiAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjUsIDIwMTkgICAgICAgICAgICAgICAgW1Bh Z2UgM10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgU1RBTVAgICAgICAgICAg ICAgICAgICAgICAgIEFwcmlsIDIwMTkKCgogICAgICAgICBvLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLW8KICAgICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICBDb25maWd1cmF0aW9uIGFuZCAgICAgICAgICAgICAgICAgICB8CiAgICAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgTWFuYWdlbWVudCAgICAgICAgICAgICAgICAg ICAgICAgfAogICAgICAgICBvLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLW8KICAgICAgICAgICAgICAgIHx8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfHwKICAgICAgICAgICAgICAgIHx8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfHwKICAgICAgICAgICAgICAgIHx8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfHwKICAgICArLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSsgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rCiAg ICAgfCBTVEFNUCBTZXNzaW9uLVNlbmRlciB8IDwtLS0gU1RBTVAtLS0+IHwgU1RBTVAgU2Vzc2lv bi1SZWZsZWN0b3IgfAogICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tKyAgICAgICAgICAgICAg ICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKCgogICAgICAgICAgICAgICAgICAgICAgRmln dXJlIDE6IFNUQU1QIFJlZmVyZW5jZSBNb2RlbAoKNC4gIFRoZW9yeSBvZiBPcGVyYXRpb24KCiAg IFNUQU1QIFNlc3Npb24tU2VuZGVyIHRyYW5zbWl0cyB0ZXN0IHBhY2tldHMgdG93YXJkIFNUQU1Q IFNlc3Npb24tCiAgIFJlZmxlY3Rvci4gIFNUQU1QIFNlc3Npb24tUmVmbGVjdG9yIHJlY2VpdmVz IFNlc3Npb24tU2VuZGVyJ3MgcGFja2V0CiAgIGFuZCBhY3RzIGFjY29yZGluZyB0byB0aGUgY29u ZmlndXJhdGlvbiBhbmQgb3B0aW9uYWwgY29udHJvbAogICBpbmZvcm1hdGlvbiBjb21tdW5pY2F0 ZWQgaW4gdGhlIFNlc3Npb24tU2VuZGVyJ3MgdGVzdCBwYWNrZXQuICBTVEFNUAogICBkZWZpbmVz IHR3byBkaWZmZXJlbnQgdGVzdCBwYWNrZXQgZm9ybWF0cywgb25lIGZvciBwYWNrZXRzCiAgIHRy YW5zbWl0dGVkIGJ5IHRoZSBTVEFNUC1TZXNzaW9uLVNlbmRlciBhbmQgb25lIGZvciBwYWNrZXRz CiAgIHRyYW5zbWl0dGVkIGJ5IHRoZSBTVEFNUC1TZXNzaW9uLVJlZmxlY3Rvci4gIFNUQU1QIHN1 cHBvcnRzIHR3bwogICBtb2RlczogdW5hdXRoZW50aWNhdGVkIGFuZCBhdXRoZW50aWNhdGVkLiAg VW5hdXRoZW50aWNhdGVkIFNUQU1QIHRlc3QKICAgcGFja2V0cywgZGVmaW5lZCBpbiBTZWN0aW9u IDQuMS4xIGFuZCBTZWN0aW9uIDQuMi4xLCBlbnN1cmUKICAgaW50ZXJ3b3JraW5nIGJldHdlZW4g U1RBTVAgYW5kIFRXQU1QIExpZ2h0IGFzIGRlc2NyaWJlZCBpbgogICBTZWN0aW9uIDQuNCBwYWNr ZXQgZm9ybWF0cy4KCiAgIEJ5IGRlZmF1bHQsIFNUQU1QIHVzZXMgc3ltbWV0cmljYWwgcGFja2V0 cywgaS5lLiwgc2l6ZSBvZiB0aGUgcGFja2V0CiAgIHRyYW5zbWl0dGVkIGJ5IFNlc3Npb24tUmVm bGVjdG9yIGVxdWFscyB0aGUgc2l6ZSBvZiB0aGUgcGFja2V0CiAgIHJlY2VpdmVkIGJ5IHRoZSBT ZXNzaW9uLVJlZmxlY3Rvci4KCjQuMS4gIFNlc3Npb24tU2VuZGVyIEJlaGF2aW9yIGFuZCBQYWNr ZXQgRm9ybWF0CgogICBCZWNhdXNlIFNUQU1QIHN1cHBvcnRzIHN5bW1ldHJpY2FsIHRlc3QgcGFj a2V0cywgU1RBTVAgU2Vzc2lvbi1TZW5kZXIKICAgcGFja2V0IGhhcyBhIG1pbmltdW0gc2l6ZSBv ZiA0NCBvY3RldHMgaW4gdW5hdXRoZW50aWNhdGVkIG1vZGUsIHNlZQogICBGaWd1cmUgMiwgYW5k IDExMiBvY3RldHMgaW4gdGhlIGF1dGhlbnRpY2F0ZWQgbW9kZSwgc2VlIEZpZ3VyZSA0LgoKNC4x LjEuICBTZXNzaW9uLVNlbmRlciBQYWNrZXQgRm9ybWF0IGluIFVuYXV0aGVudGljYXRlZCBNb2Rl CgogICBTVEFNUCBTZXNzaW9uLVNlbmRlciBwYWNrZXQgZm9ybWF0IGluIHVuYXV0aGVudGljYXRl ZCBtb2RlOgoKCgoKCgoKCgoKTWlyc2t5LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBPY3RvYmVy IDI1LCAyMDE5ICAgICAgICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgICAgICAgIFNUQU1QICAgICAgICAgICAgICAgICAgICAgICBBcHJpbCAyMDE5CgoKICAg ICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAg ICAgICAgIDMKICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgU2VxdWVuY2UgTnVtYmVyICAgICAgICAgICAgICAgICAgICAgICAgfAogICAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKwogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICBUaW1lc3RhbXAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwog ICAgICB8ICAgICAgICAgRXJyb3IgRXN0aW1hdGUgICAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfAogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKwogICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fAogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgIE1CWiAoMjcgb2N0ZXRzKSAgICAgICAg ICAgICAgICAgICAgICAgfAogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfAogICAgICArICAgICAgICAgICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKwogICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICBTZXJ2 ZXIgT2N0ZXRzICAgICAgICB8ICAgICAgICAgICAgICAgfAogICAgICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICAgICAgICAgICAgICAgKwogICAgICB8 ICAgICAgICAgICBSZW1haW5pbmcgUGFja2V0IFBhZGRpbmcgKHRvIGJlIHJlZmxlY3RlZCkgICAg ICAgICAgfAogICAgICB+ICAgICAgICAgIChsZW5ndGggaW4gb2N0ZXRzIHNwZWNpZmllZCBpbiBT ZXJ2ZXIgT2N0ZXRzKSAgICAgICAgfgogICAgICArICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICArLSstKy0rLSstKy0rLSstKwogICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKCiAgIEZpZ3VyZSAyOiBTVEFNUCBT ZXNzaW9uLVNlbmRlciB0ZXN0IHBhY2tldCBmb3JtYXQgaW4gdW5hdXRoZW50aWNhdGVkCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW9kZQoKICAgd2hlcmUgZmllbGRzIGFyZSBk ZWZpbmVkIGFzIHRoZSBmb2xsb3dpbmc6CgogICBvICBTZXF1ZW5jZSBOdW1iZXIgaXMgZm91ciBv Y3RldHMgbG9uZyBmaWVsZC4gIEZvciBlYWNoIG5ldyBzZXNzaW9uCiAgICAgIGl0cyB2YWx1ZSBz dGFydHMgYXQgemVybyBhbmQgaXMgaW5jcmVtZW50ZWQgd2l0aCBlYWNoIHRyYW5zbWl0dGVkCiAg ICAgIHBhY2tldC4KCiAgIG8gIFRpbWVzdGFtcCBpcyBlaWdodCBvY3RldHMgbG9uZyBmaWVsZC4g IFNUQU1QIG5vZGUgTVVTVCBzdXBwb3J0CiAgICAgIE5ldHdvcmsgVGltZSBQcm90b2NvbCAoTlRQ KSB2ZXJzaW9uIDQgNjQtYml0IHRpbWVzdGFtcCBmb3JtYXQKICAgICAgW1JGQzU5MDVdLCB0aGUg Zm9ybWF0IHVzZWQgaW4gW1JGQzUzNTddLiAgU1RBTVAgbm9kZSBNQVkgc3VwcG9ydAogICAgICBJ RUVFIDE1ODh2MiBQcmVjaXNpb24gVGltZSBQcm90b2NvbCB0cnVuY2F0ZWQgNjQtYml0IHRpbWVz dGFtcAogICAgICBmb3JtYXQgW0lFRUUuMTU4OC4yMDA4XSwgdGhlIGZvcm1hdCB1c2VkIGluIFtS RkM4MTg2XS4KCiAgIG8gIEVycm9yIEVzdGltYXRlIGlzIHR3byBvY3RldHMgbG9uZyBmaWVsZCB3 aXRoIGZvcm1hdCBkaXNwbGF5ZWQgaW4KICAgICAgRmlndXJlIDMKCgoKCgoKCgoKTWlyc2t5LCBl dCBhbC4gICAgICAgICAgRXhwaXJlcyBPY3RvYmVyIDI1LCAyMDE5ICAgICAgICAgICAgICAgIFtQ YWdlIDVdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgICAgIFNUQU1QICAgICAgICAg ICAgICAgICAgICAgICBBcHJpbCAyMDE5CgoKICAgICAgICAgICAgMCAgICAgICAgICAgICAgICAg ICAxCiAgICAgICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUKICAgICAgICAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICAgICAgICB8U3xafCAgIFNj YWxlICAgfCAgIE11bHRpcGxpZXIgIHwKICAgICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsKCiAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMzogRXJyb3IgRXN0aW1h dGUgRm9ybWF0CgogICAgICB3aGVyZSBTLCBTY2FsZSwgYW5kIE11bHRpcGxpZXIgZmllbGRzIGFy ZSBpbnRlcnByZXRlZCBhcyB0aGV5IGhhdmUKICAgICAgYmVlbiBkZWZpbmVkIGluIHNlY3Rpb24g NC4xLjIgW1JGQzQ2NTZdOyBhbmQgWiBmaWVsZCAtIGFzIGhhcyBiZWVuCiAgICAgIGRlZmluZWQg aW4gc2VjdGlvbiAyLjMgW1JGQzgxODZdOgoKICAgICAgKiAgMCAtIE5UUCA2NCBiaXQgZm9ybWF0 IG9mIGEgdGltZXN0YW1wOwoKICAgICAgKiAgMSAtIFBUUHYyIHRydW5jYXRlZCBmb3JtYXQgb2Yg YSB0aW1lc3RhbXAuCgogICAgICBUaGUgU1RBTVAgU2Vzc2lvbi1TZW5kZXIgYW5kIFNlc3Npb24t UmVmbGVjdG9yIE1BWSB1c2UsIG5vdCB1c2UsCiAgICAgIG9yIHNldCB2YWx1ZSBvZiB0aGUgWiBm aWVsZCBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIHRpbWVzdGFtcAogICAgICBmb3JtYXQgaW4gdXNl LiAgVGhpcyBvcHRpb25hbCBmaWVsZCBpcyB0byBlbmhhbmNlIG9wZXJhdGlvbnMsIGJ1dAogICAg ICBsb2NhbCBjb25maWd1cmF0aW9uIG9yIGRlZmF1bHRzIGNvdWxkIGJlIHVzZWQgaW4gaXRzIHBs YWNlLgoKICAgbyAgTXVzdC1iZS1aZXJvIChNQlopIGZpZWxkIGluIHRoZSBzZXNzaW9uLXNlbmRl ciB1bmF1dGhlbnRpY2F0ZWQKICAgICAgcGFja2V0IGlzIDI3IG9jdGV0cyBsb25nLiAgSXQgTVVT VCBiZSBhbGwgemVyb2VkIG9uIHRoZQogICAgICB0cmFuc21pc3Npb24gYW5kIGlnbm9yZWQgb24g cmVjZWlwdC4KCiAgIG8gIFNlcnZlciBPY3RldHMgZmllbGQgaXMgb3B0aW9uYWwgdHdvIG9jdGV0 cyBsb25nIGZpZWxkLiAgVGhpcyBmaWVsZAogICAgICBpcyB1c2VkIGZvciB0aGUgUmVmbGVjdCBP Y3RldHMgY2FwYWJpbGl0eSBkZWZpbmVkIGluIFtSRkM2MDM4XS4KICAgICAgSWYgYmVpbmcgdXNl ZCwgdGhlIFNlcnZlciBPY3RldHMgZmllbGQgTVVTVCBmb2xsb3cgdGhlIDI3IG9jdGV0cwogICAg ICBsb25nIE1CWiBmaWVsZC4gIFRoZSB2YWx1ZSBpbiB0aGUgU2VydmVyIE9jdGV0cyBmaWVsZCBl cXVhbHMgdGhlCiAgICAgIG51bWJlciBvZiBvY3RldHMgdGhlIFNlc3Npb24tUmVmbGVjdG9yIGlz IGV4cGVjdGVkIHRvIGNvcHkgYmFjayB0bwogICAgICB0aGUgU2Vzc2lvbi1TZW5kZXIgc3RhcnRp bmcgd2l0aCB0aGUgU2VydmVyIE9jdGV0cyBmaWVsZC4gIFRodXMKICAgICAgdGhlIG1pbmltdW0g bm9uLXplcm8gdmFsdWUgZm9yIHRoZSBTZXJ2ZXIgT2N0ZXRzIGZpZWxkIGlzIHR3by4KICAgICAg VGhlcmVmb3JlLCB0aGUgdmFsdWUgb2Ygb25lIGlzIGludmFsaWQuICBJZiBub25lIG9mIFBheWxv YWQgdG8gYmUKICAgICAgY29waWVkLCB0aGUgdmFsdWUgb2YgdGhlIFNlcnZlciBPY3RldHMgZmll bGQgTVVTVCBiZSBzZXQgdG8gemVybwogICAgICBvbiB0cmFuc21pdC4KCiAgIG8gIFJlbWFpbmlu ZyBQYWNrZXQgUGFkZGluZyBpcyBhbiBvcHRpb25hbCBmaWVsZCBvZiB2YXJpYWJsZSBsZW5ndGgu CiAgICAgIFRoZSBudW1iZXIgb2Ygb2N0ZXRzIGluIHRoZSBSZW1haW5pbmcgUGFja2V0IFBhZGRp bmcgZmllbGQgaXMgdGhlCiAgICAgIHZhbHVlIG9mIHRoZSBTZXJ2ZXIgT2N0ZXRzIGZpZWxkIG1p bnVzIHRoZSBsZW5ndGggb2YgdGhlIFNlcnZlcgogICAgICBPY3RldHMgZmllbGQuCgo0LjEuMi4g IFNlc3Npb24tU2VuZGVyIFBhY2tldCBGb3JtYXQgaW4gQXV0aGVudGljYXRlZCBNb2RlCgogICBT VEFNUCBTZXNzaW9uLVNlbmRlciBwYWNrZXQgZm9ybWF0IGluIGF1dGhlbnRpY2F0ZWQgbW9kZToK CgoKCgoKCk1pcnNreSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyNSwgMjAxOSAg ICAgICAgICAgICAgICBbUGFnZSA2XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAg ICBTVEFNUCAgICAgICAgICAgICAgICAgICAgICAgQXByaWwgMjAxOQoKCiAgICAgMCAgICAgICAg ICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMwogICAg IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcg OCA5IDAgMQogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSsKICAgIHwgICAgICAgICAgICAgICAgICAgICAgU2VxdWVuY2Ug TnVtYmVyICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwKICAgIHwgICAgICAgICAgICAgICAgICAgICAgTUJaICgxMiBvY3RldHMpICAgICAgICAgICAg ICAgICAgICAgICAgICB8CiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICBUaW1lc3RhbXAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfAogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgIHwgICAgICAgIEVycm9yIEVzdGltYXRlICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKwogICAgfiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIH4KICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgTUJaICg3MCBvY3RldHMpICAgICAg ICAgICAgICAgICAgICAgICB8CiAgICB+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfgogICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 CiAgICB8ICAgICAgICAgICAgICAgICAgICAgICBITUFDICgxNiBvY3RldHMpICAgICAgICAgICAg ICAgICAgICAgICAgfAogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwoKICAg IEZpZ3VyZSA0OiBTVEFNUCBTZXNzaW9uLVNlbmRlciB0ZXN0IHBhY2tldCBmb3JtYXQgaW4gYXV0 aGVudGljYXRlZAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vZGUKCiAgIFRo ZSBmaWVsZCBkZWZpbml0aW9ucyBhcmUgdGhlIHNhbWUgYXMgdGhlIHVuYXV0aGVudGljYXRlZCBt b2RlLAogICBsaXN0ZWQgaW4gU2VjdGlvbiA0LjEuMS4gIEFsc28sIENvbXAuTUJaIGZpZWxkIGlz IGEgdmFyaWFibGUgbGVuZ3RoCiAgIGZpZWxkIHRvIGFsaWduIHRoZSBwYWNrZXQgb24gMTYgb2N0 ZXRzIGJvdW5kYXJ5LiAgQWxzbywgdGhlIHBhY2tldAogICBpbmNsdWRlcyBhIGtleS1oYXNoZWQg bWVzc2FnZSBhdXRoZW50aWNhdGlvbiBjb2RlIChITUFDKSAoW1JGQzIxMDRdKQogICBoYXNoIGF0 IHRoZSBlbmQgb2YgdGhlIFBEVS4gIFRoZSBkZXRhaWxlZCB1c2Ugb2YgdGhlIEhNQUMgZmllbGQg aXMKICAgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC4zLgoKNC4yLiAgU2Vzc2lvbi1SZWZsZWN0b3Ig QmVoYXZpb3IgYW5kIFBhY2tldCBGb3JtYXQKCiAgIFRoZSBTZXNzaW9uLVJlZmxlY3RvciByZWNl aXZlcyB0aGUgU1RBTVAgdGVzdCBwYWNrZXQsIHZlcmlmaWVzIGl0LAogICBwcmVwYXJlcyBhbmQg dHJhbnNtaXRzIHRoZSByZWZsZWN0ZWQgdGVzdCBwYWNrZXQuCgogICBUd28gbW9kZXMgb2YgU1RB TVAgU2Vzc2lvbi1SZWZsZWN0b3IgY2hhcmFjdGVyaXplIHRoZSBleHBlY3RlZAogICBiZWhhdmlv ciBhbmQsIGNvbnNlcXVlbnRseSwgcGVyZm9ybWFuY2UgbWV0cmljcyB0aGF0IGNhbiBiZSBtZWFz dXJlZDoKCiAgIG8gIFN0YXRlbGVzcyAtIFNUQU1QIFNlc3Npb24tUmVmbGVjdG9yIGRvZXMgbm90 IG1haW50YWluIHRlc3Qgc3RhdGUKICAgICAgYW5kIHdpbGwgcmVmbGVjdCB0aGUgcmVjZWl2ZWQg c2VxdWVuY2UgbnVtYmVyIHdpdGhvdXQKICAgICAgbW9kaWZpY2F0aW9uLiAgQXMgYSByZXN1bHQs IG9ubHkgcm91bmQtdHJpcCBwYWNrZXQgbG9zcyBjYW4gYmUKICAgICAgY2FsY3VsYXRlZCB3aGls ZSB0aGUgcmVmbGVjdG9yIGlzIG9wZXJhdGluZyBpbiBzdGF0ZWxlc3MgbW9kZS4KCgoKCgpNaXJz a3ksIGV0IGFsLiAgICAgICAgICBFeHBpcmVzIE9jdG9iZXIgMjUsIDIwMTkgICAgICAgICAgICAg ICAgW1BhZ2UgN10KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgU1RBTVAgICAg ICAgICAgICAgICAgICAgICAgIEFwcmlsIDIwMTkKCgogICBvICBTdGF0ZWZ1bCAtIFNUQU1QIFNl c3Npb24tUmVmbGVjdG9yIG1haW50YWlucyB0ZXN0IHN0YXRlIHRodXMKICAgICAgZW5hYmxpbmcg dGhlIGFiaWxpdHkgdG8gZGV0ZXJtaW5lIGZvcndhcmQgbG9zcywgZ2FwcyByZWNvZ25pemVkIGlu CiAgICAgIHRoZSByZWNlaXZlZCBzZXF1ZW5jZSBudW1iZXIuICBBcyBhIHJlc3VsdCwgYm90aCBu ZWFyLWVuZAogICAgICAoZm9yd2FyZCkgYW5kIGZhci1lbmQgKGJhY2t3YXJkKSBwYWNrZXQgbG9z cyBjYW4gYmUgY29tcHV0ZWQuCiAgICAgIFRoYXQgaW1wbGllcyB0aGF0IHRoZSBTVEFNUCBTZXNz aW9uLVJlZmxlY3RvciBNVVNUIGtlZXAgYSBzdGF0ZQogICAgICBmb3IgZWFjaCBhY2NlcHRlZCBT VEFNUC10ZXN0IHNlc3Npb24sIHVuaXF1ZWx5IGlkZW50aWZ5aW5nIFNUQU1QLQogICAgICB0ZXN0 IHBhY2tldHMgdG8gb25lIHN1Y2ggc2Vzc2lvbiBpbnN0YW5jZSwgYW5kIGVuYWJsaW5nIGFkZGlu ZyBhCiAgICAgIHNlcXVlbmNlIG51bWJlciBpbiB0aGUgdGVzdCByZXBseSB0aGF0IGlzIGluZGl2 aWR1YWxseSBpbmNyZW1lbnRlZAogICAgICBvbiBhIHBlci1zZXNzaW9uIGJhc2lzLgoKNC4yLjEu ICBTZXNzaW9uLVJlZmxlY3RvciBQYWNrZXQgRm9ybWF0IGluIFVuYXV0aGVudGljYXRlZCBNb2Rl CgogICBGb3IgdW5hdXRoZW50aWNhdGVkIG1vZGU6CgogICAgIDAgICAgICAgICAgICAgICAgICAg MSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMKICAgICAwIDEgMiAzIDQg NSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEKICAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgU2VxdWVuY2UgTnVtYmVyICAg ICAgICAgICAgICAgICAgICAgICAgfAogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgIFRpbWVzdGFtcCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfAogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsKICAgIHwgICAgICAgICBFcnJvciBFc3RpbWF0ZSAgICAgICAgfCAg ICAgICAgICAgTUJaICAgICAgICAgICAgICAgICB8CiAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgUmVjZWl2ZSBUaW1lc3RhbXAgICAgICAgICAgICAgICAgICAgIHwK ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8CiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgfCAgICAgICAgICAgICAgICAgU2Vzc2lvbi1T ZW5kZXIgU2VxdWVuY2UgTnVtYmVyICAgICAgICAgICAgICAgIHwKICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICB8 ICAgICAgICAgICAgICAgICAgU2Vzc2lvbi1TZW5kZXIgVGltZXN0YW1wICAgICAgICAgICAgICAg ICAgICAgfAogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwKICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICB8IFNlc3Npb24tU2VuZGVyIEVy cm9yIEVzdGltYXRlIHwgICAgICAgICAgIE1CWiAgICAgICAgICAgICAgICAgfAogICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsKICAgIHxTZXMtU2VuZGVyIFRUTCB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8CiAgICArLSstKy0rLSstKy0rLSstKyAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKwogICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIH4gICAgICAgICAg ICAgICAgUGFja2V0IFBhZGRpbmcgKHJlZmxlY3RlZCkgICAgICAgICAgICAgICAgICAgICB+CiAg ICArICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLSstKy0r LSstKy0rLSstKwogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfAogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKwoKICAgICAgICAgIEZpZ3VyZSA1OiBTVEFNUCBTZXNzaW9uLVJlZmxlY3RvciB0ZXN0IHBh Y2tldCBmb3JtYXQgaW4KICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5hdXRoZW50aWNhdGVk IG1vZGUKCiAgIHdoZXJlIGZpZWxkcyBhcmUgZGVmaW5lZCBhcyB0aGUgZm9sbG93aW5nOgoKCgoK Ck1pcnNreSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyNSwgMjAxOSAgICAgICAg ICAgICAgICBbUGFnZSA4XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBTVEFN UCAgICAgICAgICAgICAgICAgICAgICAgQXByaWwgMjAxOQoKCiAgIG8gIFNlcXVlbmNlIE51bWJl ciBpcyBmb3VyIG9jdGV0cyBsb25nIGZpZWxkLiAgVGhlIHZhbHVlIG9mIHRoZQogICAgICBTZXF1 ZW5jZSBOdW1iZXIgZmllbGQgaXMgc2V0IGFjY29yZGluZyB0byB0aGUgbW9kZSBvZiB0aGUgU1RB TVAKICAgICAgU2Vzc2lvbi1SZWZsZWN0b3I6CgogICAgICAqICBpbiB0aGUgc3RhdGVsZXNzIG1v ZGUgdGhlIFNlc3Npb24tUmVmbGVjdG9yIGNvcGllcyB0aGUgdmFsdWUKICAgICAgICAgZnJvbSB0 aGUgcmVjZWl2ZWQgU1RBTVAgdGVzdCBwYWNrZXQncyBTZXF1ZW5jZSBOdW1iZXIgZmllbGQ7Cgog ICAgICAqICBpbiB0aGUgc3RhdGVmdWwgbW9kZSB0aGUgU2Vzc2lvbi1SZWZsZWN0b3IgY291bnRz IHRoZSByZWNlaXZlZAogICAgICAgICBTVEFNUCB0ZXN0IHBhY2tldHMgaW4gZWFjaCB0ZXN0IHNl c3Npb24gYW5kIHVzZXMgdGhhdCBjb3VudGVyCiAgICAgICAgIHRvIHNldCB0aGUgdmFsdWUgb2Yg dGhlIFNlcXVlbmNlIE51bWJlciBmaWVsZC4KCiAgIG8gIFRpbWVzdGFtcCBhbmQgUmVjZWl2ZXIg VGltZXN0YW1wIGZpZWxkcyBhcmUgZWFjaCBlaWdodCBvY3RldHMKICAgICAgbG9uZy4gIFRoZSBm b3JtYXQgb2YgdGhlc2UgZmllbGRzLCBOVFAgb3IgUFRQdjIsIGluZGljYXRlZCBieSB0aGUKICAg ICAgWiBmbGFnIG9mIHRoZSBFcnJvciBFc3RpbWF0ZSBmaWVsZCBhcyBkZXNjcmliZWQgaW4gU2Vj dGlvbiA0LjEuCgogICBvICBFcnJvciBFc3RpbWF0ZSBoYXMgdGhlIHNhbWUgc2l6ZSBhbmQgaW50 ZXJwcmV0YXRpb24gYXMgZGVzY3JpYmVkCiAgICAgIGluIFNlY3Rpb24gNC4xLgoKICAgbyAgU2Vz c2lvbi1TZW5kZXIgU2VxdWVuY2UgTnVtYmVyLCBTZXNzaW9uLVNlbmRlciBUaW1lc3RhbXAsIGFu ZAogICAgICBTZXNzaW9uLVNlbmRlciBFcnJvciBFc3RpbWF0ZSBhcmUgY29waWVzIG9mIHRoZSBj b3JyZXNwb25kaW5nCiAgICAgIGZpZWxkcyBpbiB0aGUgU1RBTVAgdGVzdCBwYWNrZXQgc2VudCBi eSB0aGUgU2Vzc2lvbi1TZW5kZXIuCgogICBvICBTZXNzaW9uLVNlbmRlciBUVEwgaXMgb25lIG9j dGV0IGxvbmcgZmllbGQsIGFuZCBpdHMgdmFsdWUgaXMgdGhlCiAgICAgIGNvcHkgb2YgdGhlIFRU TCBmaWVsZCBpbiBJUHY0IChvciBIb3AgTGltaXQgaW4gSVB2NikgZnJvbSB0aGUKICAgICAgcmVj ZWl2ZWQgU1RBTVAgdGVzdCBwYWNrZXQuCgogICBvICBQYWNrZXQgUGFkZGluZyAocmVmbGVjdGVk KSBpcyBhbiBvcHRpb25hbCB2YXJpYWJsZSBsZW5ndGggZmllbGQuCiAgICAgIFRoZSBsZW5ndGgg b2YgdGhlIFBhY2tldCBQYWRkaW5nIChyZWZsZWN0ZWQpIGZpZWxkIE1VU1QgYmUgZXF1YWwKICAg ICAgdG8gdGhlIHZhbHVlIG9mIHRoZSBTZXJ2ZXIgT2N0ZXRzIGZpZWxkIChGaWd1cmUgMikuICBJ ZiB0aGUgdmFsdWUKICAgICAgaXMgbm9uLXplcm8sIHRoZSBTZXNzaW9uLVJlZmxlY3RvciBNVVNU IGNvcHkgbnVtYmVyIG9mIG9jdGV0cwogICAgICBlcXVhbCB0byB0aGUgdmFsdWUgb2YgU2VydmVy IE9jdGV0cyBmaWVsZCBzdGFydGluZyB3aXRoIHRoZSBTZXJ2ZXIKICAgICAgT2N0ZXRzIGZpZWxk LgoKICAgbyAgQ29tcC5NQlogaXMgYSB2YXJpYWJsZSBsZW5ndGggZmllbGQgdXNlZCB0byBhY2hp ZXZlIGFsaWdubWVudCBvbiBhCiAgICAgIHdvcmQgYm91bmRhcnkuICBUaHVzIHRoZSBsZW5ndGgg b2YgQ29tcC5NQlogZmllbGQgbWF5IGJlIG9ubHkgMCwKICAgICAgMSwgMiBvciAzIG9jdGV0cy4g IFRoZSB2YWx1ZSBvZiB0aGUgZmllbGQgTVVTVCBiZSB6ZXJvZWQgb24KICAgICAgdHJhbnNtaXNz aW9uIGFuZCBpZ25vcmVkIG9uIHJlY2VpcHQuCgo0LjIuMi4gIFNlc3Npb24tUmVmbGVjdG9yIFBh Y2tldCBGb3JtYXQgaW4gQXV0aGVudGljYXRlZCBNb2RlCgogICBGb3IgdGhlIGF1dGhlbnRpY2F0 ZWQgbW9kZToKCiAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAy ICAgICAgICAgICAgICAgICAgIDMKICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQg NSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICBTZXF1ZW5jZSBOdW1iZXIgICAgICAgICAgICAgICAgICAg ICAgICB8CiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBNQlog KDEyIG9jdGV0cykgICAgICAgICAgICAgICAgICAgICAgICB8CgoKCk1pcnNreSwgZXQgYWwuICAg ICAgICAgIEV4cGlyZXMgT2N0b2JlciAyNSwgMjAxOSAgICAgICAgICAgICAgICBbUGFnZSA5XQoM CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBTVEFNUCAgICAgICAgICAgICAgICAg ICAgICAgQXByaWwgMjAxOQoKCiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rCiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIFRpbWVzdGFtcCAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8CiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAg IHwgICAgICAgICBFcnJvciBFc3RpbWF0ZSAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8CiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICArCiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBN QlogKDYgb2N0ZXRzKSAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBSZWNlaXZlIFRpbWVzdGFtcCAgICAgICAgICAg ICAgICAgICAgICB8CiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICBNQlogKDggb2N0ZXRzKSAgICAgICAgICAgICAgICAgICAgICAgICB8 CiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8CiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgIHwgICAgICAgICAgICAgICAgIFNl c3Npb24tU2VuZGVyIFNlcXVlbmNlIE51bWJlciAgICAgICAgICAgICAgICB8CiAgICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rCiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBNQlogKDEyIG9jdGV0cykgICAgICAg ICAgICAgICAgICAgICAgICB8CiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rCiAgICAgIHwgICAgICAgICAgICAgICAgIFNlc3Npb24tU2VuZGVyIFRpbWVzdGFtcCAg ICAgICAgICAgICAgICAgICAgICB8CiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAg IHwgU2Vzc2lvbi1TZW5kZXIgRXJyb3IgRXN0aW1hdGUgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8CiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICArCiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBN QlogKDYgb2N0ZXRzKSAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAg ICAgIHxTZXMtU2VuZGVyIFRUTCB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8CiAgICAgICstKy0rLSstKy0rLSstKy0rICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICArCiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICBNQlogKDE1IG9jdGV0cykgICAgICAgICAgICAgICAgICAgICAgICB8 CiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8CiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICBITUFDICgxNiBvY3RldHMpICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8CiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8CiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCgoKICAgRmln dXJlIDY6IFNUQU1QIFNlc3Npb24tUmVmbGVjdG9yIHRlc3QgcGFja2V0IGZvcm1hdCBpbiBhdXRo ZW50aWNhdGVkCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbW9kZQoKICAgVGhl IGZpZWxkIGRlZmluaXRpb25zIGFyZSB0aGUgc2FtZSBhcyB0aGUgdW5hdXRoZW50aWNhdGVkIG1v ZGUsCiAgIGxpc3RlZCBpbiBTZWN0aW9uIDQuMi4xLiAgQWRkaXRpb25hbGx5LCB0aGUgcGFja2V0 IE1BWSBpbmNsdWRlCiAgIENvbXAuTUJaIGZpZWxkIGlzIGEgdmFyaWFibGUgbGVuZ3RoIGZpZWxk IHRvIGFsaWduIHRoZSBwYWNrZXQgb24gMTYKCgoKTWlyc2t5LCBldCBhbC4gICAgICAgICAgRXhw aXJlcyBPY3RvYmVyIDI1LCAyMDE5ICAgICAgICAgICAgICAgW1BhZ2UgMTBdCgwKSW50ZXJuZXQt RHJhZnQgICAgICAgICAgICAgICAgICAgIFNUQU1QICAgICAgICAgICAgICAgICAgICAgICBBcHJp bCAyMDE5CgoKICAgb2N0ZXRzIGJvdW5kYXJ5LiAgQWxzbywgU1RBTVAgU2Vzc2lvbi1SZWZsZWN0 b3IgdGVzdCBwYWNrZXQgZm9ybWF0IGluCiAgIGF1dGhlbnRpY2F0ZWQgbW9kZSBpbmNsdWRlcyBh IGtleSAoSE1BQykgKFtSRkMyMTA0XSkgaGFzaCBhdCB0aGUgZW5kCiAgIG9mIHRoZSBQRFUuICBU aGUgZGV0YWlsZWQgdXNlIG9mIHRoZSBITUFDIGZpZWxkIGlzIGluIFNlY3Rpb24gNC4zLgoKNC4z LiAgSW50ZWdyaXR5IGFuZCBDb25maWRlbnRpYWxpdHkgUHJvdGVjdGlvbiBpbiBTVEFNUAoKICAg VG8gcHJvdmlkZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbiwgZWFjaCBTVEFNUCBtZXNzYWdlIGlzIGJl aW5nCiAgIGF1dGhlbnRpY2F0ZWQgYnkgYWRkaW5nIEhhc2hlZCBNZXNzYWdlIEF1dGhlbnRpY2F0 aW9uIENvZGUgKEhNQUMpLgogICBTVEFNUCB1c2VzIEhNQUMtU0hBLTI1NiB0cnVuY2F0ZWQgdG8g MTI4IGJpdHMgKHNpbWlsYXJseSB0byB0aGUgdXNlCiAgIG9mIGl0IGluIElQU2VjIGRlZmluZWQg aW4gW1JGQzQ4NjhdKTsgaGVuY2UgdGhlIGxlbmd0aCBvZiB0aGUgSE1BQwogICBmaWVsZCBpcyAx NiBvY3RldHMuICBITUFDIHVzZXMgb3duIGtleSBhbmQgdGhlIGRlZmluaXRpb24gb2YgdGhlCiAg IG1lY2hhbmlzbSB0byBkaXN0cmlidXRlIHRoZSBITUFDIGtleSBpcyBvdXRzaWRlIHRoZSBzY29w ZSBvZiB0aGlzCiAgIHNwZWNpZmljYXRpb24uICBPbmUgZXhhbXBsZSBpcyB0byB1c2UgYW4gb3Jj aGVzdHJhdG9yIHRvIGNvbmZpZ3VyZQogICBITUFDIGtleSBiYXNlZCBvbiBTVEFNUCBZQU5HIGRh dGEgbW9kZWwgW0ktRC5pZXRmLWlwcG0tc3RhbXAteWFuZ10uCiAgIEhNQUMgTVVTVCBiZSB2ZXJp ZmllZCBhcyBlYXJseSBhcyBwb3NzaWJsZSB0byBhdm9pZCB1c2luZyBvcgogICBwcm9wYWdhdGlu ZyBjb3JydXB0ZWQgZGF0YS4KCiAgIElmIGNvbmZpZGVudGlhbGl0eSBwcm90ZWN0aW9uIGZvciBT VEFNUCBpcyByZXF1aXJlZCwgZW5jcnlwdGlvbiBhdAogICB0aGUgaGlnaGVyIGxldmVsIE1VU1Qg YmUgdXNlZC4gIEZvciBleGFtcGxlLCBTVEFNUCBwYWNrZXRzIGNvdWxkIGJlCiAgIHRyYW5zbWl0 dGVkIGluIHRoZSBkZWRpY2F0ZWQgSVBzZWMgdHVubmVsIG9yIHNoYXJlIHRoZSBJUHNlYyB0dW5u ZWwKICAgd2l0aCB0aGUgbW9uaXRvcmVkIGZsb3cuCgo0LjQuICBJbnRlcm9wZXJhYmlsaXR5IHdp dGggVFdBTVAgTGlnaHQKCiAgIE9uZSBvZiB0aGUgZXNzZW50aWFsIHJlcXVpcmVtZW50cyB0byBT VEFNUCBpcyB0aGUgYWJpbGl0eSB0bwogICBpbnRlcndvcmsgd2l0aCBhIFRXQU1QIExpZ2h0IGRl dmljZS4gIFRoZXJlIGFyZSB0d28gcG9zc2libGUKICAgY29tYmluYXRpb25zIGZvciBzdWNoIHVz ZSBjYXNlOgoKICAgbyAgU1RBTVAgU2Vzc2lvbi1TZW5kZXIgd2l0aCBUV0FNUCBMaWdodCBTZXNz aW9uLVJlZmxlY3RvcjsKCiAgIG8gIFRXQU1QIExpZ2h0IFNlc3Npb24tU2VuZGVyIHdpdGggU1RB TVAgU2Vzc2lvbi1SZWZsZWN0b3IuCgogICBJbiB0aGUgZm9ybWVyIGNhc2UsIHRoZSBTZXNzaW9u LVNlbmRlciBNQVkgbm90IGJlIGF3YXJlIHRoYXQgaXRzCiAgIFNlc3Npb24tUmVmbGVjdG9yIGRv ZXMgbm90IHN1cHBvcnQgU1RBTVAuICBGb3IgZXhhbXBsZSwgYSBUV0FNUCBMaWdodAogICBTZXNz aW9uLVJlZmxlY3RvciBtYXkgbm90IHN1cHBvcnQgdGhlIHVzZSBvZiBVRFAgcG9ydCA4NjIgYXMg ZGVmaW5lZAogICBpbiBbUkZDODU0NV0uICBUaHVzIFNUQU1QIFNlc3Npb24tU2VuZGVyIE1VU1Qg YmUgYWJsZSB0byBzZW5kIHRlc3QKICAgcGFja2V0cyB0byBkZXN0aW5hdGlvbiBVRFAgcG9ydCBu dW1iZXIgZnJvbSB0aGUgRHluYW1pYyBhbmQvb3IKICAgUHJpdmF0ZSBQb3J0cyByYW5nZSA0OTE1 Mi02NTUzNSwgdGVzdCBtYW5hZ2VtZW50IHN5c3RlbSBzaG91bGQgZmluZCBhCiAgIHBvcnQgbnVt YmVyIHRoYXQgYm90aCBkZXZpY2VzIGNhbiB1c2UuICBBbmQgaWYgYW55IG9mIFNUQU1QCiAgIGV4 dGVuc2lvbnMgYXJlIHVzZWQsIHRoZSBUV0FNUCBMaWdodCBTZXNzaW9uLVJlZmxlY3RvciB3aWxs IHZpZXcgdGhlbQogICBhcyBQYWNrZXQgUGFkZGluZyBmaWVsZC4gIFRoZSBTZXNzaW9uLVNlbmRl ciBTSE9VTEQgdXNlIHRoZSBkZWZhdWx0CiAgIGZvcm1hdCBmb3IgaXRzIHRpbWVzdGFtcHMgLSBO VFAuICBBbmQgaXQgTUFZIHVzZSBQVFB2MiB0aW1lc3RhbXAKICAgZm9ybWF0LgoKICAgSW4gdGhl IGxhdHRlciBzY2VuYXJpbywgdGhlIHRlc3QgbWFuYWdlbWVudCBzeXN0ZW0gc2hvdWxkIHNldCBT VEFNUAogICBTZXNzaW9uLVJlZmxlY3RvciB0byB1c2UgVURQIHBvcnQgbnVtYmVyIGZyb20gdGhl IER5bmFtaWMgYW5kL29yCiAgIFByaXZhdGUgUG9ydHMgcmFuZ2UuICBBcyBmb3IgUGFja2V0IFBh ZGRpbmcgZmllbGQgdGhhdCB0aGUgVFdBTVAKICAgTGlnaHQgU2Vzc2lvbi1TZW5kZXIgaW5jbHVk ZXMgaW4gaXRzIHRyYW5zbWl0dGVkIHBhY2tldCwgdGhlIFNUQU1QCgoKCk1pcnNreSwgZXQgYWwu ICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyNSwgMjAxOSAgICAgICAgICAgICAgIFtQYWdlIDEx XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBTVEFNUCAgICAgICAgICAgICAg ICAgICAgICAgQXByaWwgMjAxOQoKCiAgIFNlc3Npb24tUmVmbGVjdG9yIHdpbGwgcHJvY2VzcyBp dCBhY2NvcmRpbmcgdG8gW1JGQzYwMzhdIGFuZCByZXR1cm4KICAgcmVmbGVjdGVkIHBhY2tldCBv ZiB0aGUgc3ltbWV0cmljYWwgc2l6ZS4gIFRoZSBTZXNzaW9uLVJlZmxlY3RvciBNVVNUCiAgIHVz ZSB0aGUgZGVmYXVsdCBmb3JtYXQgZm9yIGl0cyB0aW1lc3RhbXBzIC0gTlRQLgoKNS4gIElBTkEg Q29uc2lkZXJhdGlvbnMKCiAgIFRoaXMgZG9jdW1lbnQgZG9lc24ndCBoYXZlIGFueSBJQU5BIGFj dGlvbi4gIFRoaXMgc2VjdGlvbiBtYXkgYmUKICAgcmVtb3ZlZCBiZWZvcmUgdGhlIHB1YmxpY2F0 aW9uLgoKNi4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zCgogICBJbiBnZW5lcmFsLCBhbGwgdGhl IHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHJlbGF0ZWQgdG8gVFdBTVAtVGVzdCwKICAgZGlzY3Vz c2VkIGluIFtSRkM1MzU3XSBhcHBseSB0byBTVEFNUC4gIFNpbmNlIFNUQU1QIHVzZXMgdGhlIHdl bGwtCiAgIGtub3duIFVEUCBwb3J0IG51bWJlciBhbGxvY2F0ZWQgZm9yIHRoZSBPV0FNUC1UZXN0 L1RXQU1QLVRlc3QKICAgUmVjZWl2ZXIgcG9ydCwgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25z IGFuZCBtZWFzdXJlcyB0byBtaXRpZ2F0ZQogICB0aGUgcmlzayBvZiB0aGUgYXR0YWNrIHVzaW5n IHRoZSByZWdpc3RlcmVkIHBvcnQgbnVtYmVyIGRvY3VtZW50ZWQgaW4KICAgU2VjdGlvbiA2IFtS RkM4NTQ1XSBlcXVhbGx5IGFwcGx5IHRvIFNUQU1QLiAgQmVjYXVzZSBvZiB0aGUgY29udHJvbAog ICBhbmQgbWFuYWdlbWVudCBvZiBhIFNUQU1QIHRlc3QgYmVpbmcgb3V0c2lkZSB0aGUgc2NvcGUg b2YgdGhpcwogICBzcGVjaWZpY2F0aW9uIG9ubHkgdGhlIG1vcmUgZ2VuZXJhbCByZXF1aXJlbWVu dCBpcyBzZXQ6CgogICAgICBUbyBtaXRpZ2F0ZSB0aGUgcG9zc2libGUgYXR0YWNrIHZlY3Rvciwg dGhlIGNvbnRyb2wgYW5kIG1hbmFnZW1lbnQKICAgICAgb2YgYSBTVEFNUCB0ZXN0IHNlc3Npb24g TVVTVCB1c2UgdGhlIHNlY3VyZWQgdHJhbnNwb3J0LgoKICAgVXNlIG9mIEhNQUMtU0hBLTI1NiBp biB0aGUgYXV0aGVudGljYXRlZCBtb2RlIHByb3RlY3RzIHRoZSBkYXRhCiAgIGludGVncml0eSBv ZiB0aGUgU1RBTVAgdGVzdCBwYWNrZXRzLgoKNy4gIEFja25vd2xlZGdtZW50cwoKICAgQXV0aG9y cyBleHByZXNzIHRoZWlyIGFwcHJlY2lhdGlvbiB0byBKb3NlIElnbmFjaW8gQWx2YXJlei1IYW1l bGluCiAgIGFuZCBCcmlhbiBXZWlzIGZvciB0aGVpciBncmVhdCBpbnNpZ2h0cyBpbnRvIHRoZSBz ZWN1cml0eSBhbmQKICAgaWRlbnRpdHkgcHJvdGVjdGlvbiwgYW5kIHRoZSBtb3N0IGhlbHBmdWwg YW5kIHByYWN0aWNhbCBzdWdnZXN0aW9ucy4KICAgQWxzbywgb3VyIHNpbmNlcmUgdGhhbmtzIHRv IERhdmlkIEJhbGwgZm9yIGhpcyB0aG9yb3VnaCByZXZpZXcgYW5kCiAgIGhlbHBmdWwgY29tbWVu dHMuCgo4LiAgUmVmZXJlbmNlcwoKOC4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtJRUVF LjE1ODguMjAwOF0KICAgICAgICAgICAgICAiU3RhbmRhcmQgZm9yIGEgUHJlY2lzaW9uIENsb2Nr IFN5bmNocm9uaXphdGlvbiBQcm90b2NvbAogICAgICAgICAgICAgIGZvciBOZXR3b3JrZWQgTWVh c3VyZW1lbnQgYW5kIENvbnRyb2wgU3lzdGVtcyIsCiAgICAgICAgICAgICAgSUVFRSBTdGFuZGFy ZCAxNTg4LCBNYXJjaCAyMDA4LgoKICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwgIktleSB3b3Jk cyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGUKICAgICAgICAgICAgICBSZXF1aXJlbWVudCBM ZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LAogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkMy MTE5LCBNYXJjaCAxOTk3LAogICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9y Zy9pbmZvL3JmYzIxMTk+LgoKCgoKTWlyc2t5LCBldCBhbC4gICAgICAgICAgRXhwaXJlcyBPY3Rv YmVyIDI1LCAyMDE5ICAgICAgICAgICAgICAgW1BhZ2UgMTJdCgwKSW50ZXJuZXQtRHJhZnQgICAg ICAgICAgICAgICAgICAgIFNUQU1QICAgICAgICAgICAgICAgICAgICAgICBBcHJpbCAyMDE5CgoK ICAgW1JGQzQ2NTZdICBTaGFsdW5vdiwgUy4sIFRlaXRlbGJhdW0sIEIuLCBLYXJwLCBBLiwgQm9v dGUsIEouLCBhbmQgTS4KICAgICAgICAgICAgICBaZWthdXNrYXMsICJBIE9uZS13YXkgQWN0aXZl IE1lYXN1cmVtZW50IFByb3RvY29sCiAgICAgICAgICAgICAgKE9XQU1QKSIsIFJGQyA0NjU2LCBE T0kgMTAuMTc0ODcvUkZDNDY1NiwgU2VwdGVtYmVyIDIwMDYsCiAgICAgICAgICAgICAgPGh0dHBz Oi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNDY1Nj4uCgogICBbUkZDNTM1N10gIEhlZGF5 YXQsIEsuLCBLcnphbm93c2tpLCBSLiwgTW9ydG9uLCBBLiwgWXVtLCBLLiwgYW5kIEouCiAgICAg ICAgICAgICAgQmFiaWFyeiwgIkEgVHdvLVdheSBBY3RpdmUgTWVhc3VyZW1lbnQgUHJvdG9jb2wg KFRXQU1QKSIsCiAgICAgICAgICAgICAgUkZDIDUzNTcsIERPSSAxMC4xNzQ4Ny9SRkM1MzU3LCBP Y3RvYmVyIDIwMDgsCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2lu Zm8vcmZjNTM1Nz4uCgogICBbUkZDNTkwNV0gIE1pbGxzLCBELiwgTWFydGluLCBKLiwgRWQuLCBC dXJiYW5rLCBKLiwgYW5kIFcuIEthc2NoLAogICAgICAgICAgICAgICJOZXR3b3JrIFRpbWUgUHJv dG9jb2wgVmVyc2lvbiA0OiBQcm90b2NvbCBhbmQgQWxnb3JpdGhtcwogICAgICAgICAgICAgIFNw ZWNpZmljYXRpb24iLCBSRkMgNTkwNSwgRE9JIDEwLjE3NDg3L1JGQzU5MDUsIEp1bmUgMjAxMCwK ICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM1OTA1Pi4K CiAgIFtSRkM2MDM4XSAgTW9ydG9uLCBBLiBhbmQgTC4gQ2lhdmF0dG9uZSwgIlR3by1XYXkgQWN0 aXZlIE1lYXN1cmVtZW50CiAgICAgICAgICAgICAgUHJvdG9jb2wgKFRXQU1QKSBSZWZsZWN0IE9j dGV0cyBhbmQgU3ltbWV0cmljYWwgU2l6ZQogICAgICAgICAgICAgIEZlYXR1cmVzIiwgUkZDIDYw MzgsIERPSSAxMC4xNzQ4Ny9SRkM2MDM4LCBPY3RvYmVyIDIwMTAsCiAgICAgICAgICAgICAgPGh0 dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNjAzOD4uCgogICBbUkZDODE3NF0gIExl aWJhLCBCLiwgIkFtYmlndWl0eSBvZiBVcHBlcmNhc2UgdnMgTG93ZXJjYXNlIGluIFJGQwogICAg ICAgICAgICAgIDIxMTkgS2V5IFdvcmRzIiwgQkNQIDE0LCBSRkMgODE3NCwgRE9JIDEwLjE3NDg3 L1JGQzgxNzQsCiAgICAgICAgICAgICAgTWF5IDIwMTcsIDxodHRwczovL3d3dy5yZmMtZWRpdG9y Lm9yZy9pbmZvL3JmYzgxNzQ+LgoKICAgW1JGQzgxODZdICBNaXJza3ksIEcuIGFuZCBJLiBNZWls aWssICJTdXBwb3J0IG9mIHRoZSBJRUVFIDE1ODgKICAgICAgICAgICAgICBUaW1lc3RhbXAgRm9y bWF0IGluIGEgVHdvLVdheSBBY3RpdmUgTWVhc3VyZW1lbnQgUHJvdG9jb2wKICAgICAgICAgICAg ICAoVFdBTVApIiwgUkZDIDgxODYsIERPSSAxMC4xNzQ4Ny9SRkM4MTg2LCBKdW5lIDIwMTcsCiAg ICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjODE4Nj4uCgog ICBbUkZDODU0NV0gIE1vcnRvbiwgQS4sIEVkLiBhbmQgRy4gTWlyc2t5LCBFZC4sICJXZWxsLUtu b3duIFBvcnQKICAgICAgICAgICAgICBBc3NpZ25tZW50cyBmb3IgdGhlIE9uZS1XYXkgQWN0aXZl IE1lYXN1cmVtZW50IFByb3RvY29sCiAgICAgICAgICAgICAgKE9XQU1QKSBhbmQgdGhlIFR3by1X YXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29sCiAgICAgICAgICAgICAgKFRXQU1QKSIsIFJG QyA4NTQ1LCBET0kgMTAuMTc0ODcvUkZDODU0NSwgTWFyY2ggMjAxOSwKICAgICAgICAgICAgICA8 aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM4NTQ1Pi4KCjguMi4gIEluZm9ybWF0 aXZlIFJlZmVyZW5jZXMKCiAgIFtCQkYuVFItMzkwXQogICAgICAgICAgICAgICJQZXJmb3JtYW5j ZSBNZWFzdXJlbWVudCBmcm9tIElQIEVkZ2UgdG8gQ3VzdG9tZXIKICAgICAgICAgICAgICBFcXVp cG1lbnQgdXNpbmcgVFdBTVAgTGlnaHQiLCBCQkYgVFItMzkwLCBNYXkgMjAxNy4KCiAgIFtJLUQu aWV0Zi1pcHBtLXN0YW1wLXlhbmddCiAgICAgICAgICAgICAgTWlyc2t5LCBHLiwgWGlhbywgTS4s IGFuZCBXLiBMdW8sICJTaW1wbGUgVHdvLXdheSBBY3RpdmUKICAgICAgICAgICAgICBNZWFzdXJl bWVudCBQcm90b2NvbCAoU1RBTVApIERhdGEgTW9kZWwiLCBkcmFmdC1pZXRmLWlwcG0tCiAgICAg ICAgICAgICAgc3RhbXAteWFuZy0wMyAod29yayBpbiBwcm9ncmVzcyksIE1hcmNoIDIwMTkuCgoK CgoKCk1pcnNreSwgZXQgYWwuICAgICAgICAgIEV4cGlyZXMgT2N0b2JlciAyNSwgMjAxOSAgICAg ICAgICAgICAgIFtQYWdlIDEzXQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICBT VEFNUCAgICAgICAgICAgICAgICAgICAgICAgQXByaWwgMjAxOQoKCiAgIFtSRkMyMTA0XSAgS3Jh d2N6eWssIEguLCBCZWxsYXJlLCBNLiwgYW5kIFIuIENhbmV0dGksICJITUFDOiBLZXllZC0KICAg ICAgICAgICAgICBIYXNoaW5nIGZvciBNZXNzYWdlIEF1dGhlbnRpY2F0aW9uIiwgUkZDIDIxMDQs CiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzIxMDQsIEZlYnJ1YXJ5IDE5OTcsCiAgICAg ICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjMjEwND4uCgogICBb UkZDNDg2OF0gIEtlbGx5LCBTLiBhbmQgUy4gRnJhbmtlbCwgIlVzaW5nIEhNQUMtU0hBLTI1Niwg SE1BQy1TSEEtCiAgICAgICAgICAgICAgMzg0LCBhbmQgSE1BQy1TSEEtNTEyIHdpdGggSVBzZWMi LCBSRkMgNDg2OCwKICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDNDg2OCwgTWF5IDIwMDcs CiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNDg2OD4u CgpBdXRob3JzJyBBZGRyZXNzZXMKCiAgIEdyZWcgTWlyc2t5CiAgIFpURSBDb3JwLgoKICAgRW1h aWw6IGdyZWdpbWlyc2t5QGdtYWlsLmNvbQoKCiAgIEd1byBKdW4KICAgWlRFIENvcnBvcmF0aW9u CiAgIDY4IyBaaWppbmdodWEgUm9hZAogICBOYW5qaW5nLCBKaWFuZ3N1ICAyMTAwMTIKICAgUC5S LkNoaW5hCgogICBQaG9uZTogKzg2IDE4MTA1MTgzNjYzCiAgIEVtYWlsOiBndW8uanVuMkB6dGUu Y29tLmNuCgoKICAgSGVucmlrIE55ZGVsbAogICBBY2NlZGlhbiBOZXR3b3JrcwoKICAgRW1haWw6 IGhueWRlbGxAYWNjZWRpYW4uY29tCgoKICAgUmljaGFyZCBGb290ZQogICBOb2tpYQoKICAgRW1h aWw6IGZvb3Rlci5mb290ZUBub2tpYS5jb20KCgoKCgoKCgoKCgoKCk1pcnNreSwgZXQgYWwuICAg ICAgICAgIEV4cGlyZXMgT2N0b2JlciAyNSwgMjAxOSAgICAgICAgICAgICAgIFtQYWdlIDE0XQo= --000000000000350e7c0587389d02 Content-Type: text/html; charset="UTF-8"; name="Diff_ draft-ietf-ippm-stamp-05.txt - draft-ietf-ippm-stamp-06.txt.html" Content-Disposition: attachment; filename="Diff_ draft-ietf-ippm-stamp-05.txt - draft-ietf-ippm-stamp-06.txt.html" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_juu976by0 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPgo8IS0tIHNhdmVkIGZyb20gdXJsPSgwMDQyKWh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9y ZmNkaWZmL3JmY2RpZmYucHlodCAtLT4KPGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5 OTkveGh0bWwiIGNsYXNzPSJncl9fd3d3Nl9pZXRmX29yZyI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPiAKICAg CiAgPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1TdHlsZS1UeXBlIiBjb250ZW50PSJ0ZXh0L2Nz cyI+IAogIDx0aXRsZT5EaWZmOiBkcmFmdC1pZXRmLWlwcG0tc3RhbXAtMDUudHh0IC0gZHJhZnQt aWV0Zi1pcHBtLXN0YW1wLTA2LnR4dDwvdGl0bGU+IAogIDxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+ IAogICAgYm9keSAgICB7IG1hcmdpbjogMC40ZXg7IG1hcmdpbi1yaWdodDogYXV0bzsgfSAKICAg IHRyICAgICAgeyB9IAogICAgdGQgICAgICB7IHdoaXRlLXNwYWNlOiBwcmU7IGZvbnQtZmFtaWx5 OiBtb25vc3BhY2U7IHZlcnRpY2FsLWFsaWduOiB0b3A7IGZvbnQtc2l6ZTogMC44NmVtO30gCiAg ICB0aCAgICAgIHsgZm9udC1zaXplOiAwLjg2ZW07IH0gCiAgICAuc21hbGwgIHsgZm9udC1zaXpl OiAwLjZlbTsgZm9udC1zdHlsZTogaXRhbGljOyBmb250LWZhbWlseTogVmVyZGFuYSwgSGVsdmV0 aWNhLCBzYW5zLXNlcmlmOyB9IAogICAgLmxlZnQgICB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7 IH0gCiAgICAucmlnaHQgIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgfSAKICAgIC5kaWZmICAg eyBiYWNrZ3JvdW5kLWNvbG9yOiAjQ0NGOyB9IAogICAgLmxibG9jayB7IGJhY2tncm91bmQtY29s b3I6ICNCRkI7IH0gCiAgICAucmJsb2NrIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZGODsgfSAKICAg IC5pbnNlcnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjOEZGOyB9IAogICAgLmRlbGV0ZSB7IGJhY2tn cm91bmQtY29sb3I6ICNBQ0Y7IH0gCiAgICAudm9pZCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0ZG QjsgfSAKICAgIC5jb250ICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxpbmVi ciB7IGJhY2tncm91bmQtY29sb3I6ICNBQUE7IH0gCiAgICAubGluZW5vIHsgY29sb3I6IHJlZDsg YmFja2dyb3VuZC1jb2xvcjogI0ZGRjsgZm9udC1zaXplOiAwLjdlbTsgdGV4dC1hbGlnbjogcmln aHQ7IHBhZGRpbmc6IDAgMnB4OyB9IAogICAgLmVsaXBzaXN7IGJhY2tncm91bmQtY29sb3I6ICNB QUE7IH0gCiAgICAubGVmdCAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICNEREQ7IH0gCiAgICAu cmlnaHQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9IAogICAgLmxibG9jayAuY29u dCB7IGJhY2tncm91bmQtY29sb3I6ICM5RDk7IH0gCiAgICAucmJsb2NrIC5jb250IHsgYmFja2dy b3VuZC1jb2xvcjogI0RENjsgfSAKICAgIC5pbnNlcnQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9y OiAjMEREOyB9IAogICAgLmRlbGV0ZSAuY29udCB7IGJhY2tncm91bmQtY29sb3I6ICM4QUQ7IH0g CiAgICAuc3RhdHMsIC5zdGF0cyB0ZCwgLnN0YXRzIHRoIHsgYmFja2dyb3VuZC1jb2xvcjogI0VF RTsgcGFkZGluZzogMnB4IDA7IH0gCiAgICBzcGFuLmhpZGUgeyBkaXNwbGF5OiBub25lOyBjb2xv cjogI2FhYTt9ICAgIGE6aG92ZXIgc3BhbiB7IGRpc3BsYXk6IGlubGluZTsgfSAgICB0ci5jaGFu Z2UgeyBiYWNrZ3JvdW5kLWNvbG9yOiBncmF5OyB9IAogICAgdHIuY2hhbmdlIGEgeyB0ZXh0LWRl Y29yYXRpb246IG5vbmU7IGNvbG9yOiBibGFjayB9IAogIDwvc3R5bGU+IAogICAgIDxzY3JpcHQ+ CnZhciBjaHVua19pbmRleCA9IDA7CnZhciBvbGRfY2h1bmsgPSBudWxsOwoKZnVuY3Rpb24gZm9y bWF0X2NodW5rKGluZGV4KSB7CiAgICB2YXIgcHJlZml4ID0gImRpZmYiOwogICAgdmFyIHN0ciA9 IGluZGV4LnRvU3RyaW5nKCk7CiAgICBmb3IgKHg9MDsgeDwoNC1zdHIubGVuZ3RoKTsgKyt4KSB7 CiAgICAgICAgcHJlZml4Kz0nMCc7CiAgICB9CiAgICByZXR1cm4gcHJlZml4ICsgc3RyOwp9Cgpm dW5jdGlvbiBmaW5kX2NodW5rKG4pewogICAgcmV0dXJuIGRvY3VtZW50LnF1ZXJ5U2VsZWN0b3Io J3RyW2lkJD0iJyArIG4gKyAnIl0nKTsKfQoKZnVuY3Rpb24gY2hhbmdlX2NodW5rKG9mZnNldCkg ewogICAgdmFyIGluZGV4ID0gY2h1bmtfaW5kZXggKyBvZmZzZXQ7CiAgICB2YXIgbmV3X3N0cjsK ICAgIHZhciBuZXdfY2h1bms7CgogICAgbmV3X3N0ciA9IGZvcm1hdF9jaHVuayhpbmRleCk7CiAg ICBuZXdfY2h1bmsgPSBmaW5kX2NodW5rKG5ld19zdHIpOwogICAgaWYgKCFuZXdfY2h1bmspIHsK ICAgICAgICByZXR1cm47CiAgICB9CiAgICBpZiAob2xkX2NodW5rKSB7CiAgICAgICAgb2xkX2No dW5rLnN0eWxlLm91dGxpbmUgPSAiIjsKICAgIH0KICAgIG9sZF9jaHVuayA9IG5ld19jaHVuazsK ICAgIG9sZF9jaHVuay5zdHlsZS5vdXRsaW5lID0gIjFweCBzb2xpZCByZWQiOwogICAgd2luZG93 LmxvY2F0aW9uLnJlcGxhY2UoIiMiICsgbmV3X3N0cikKICAgIHdpbmRvdy5zY3JvbGxCeSgwLC0x MDApOwogICAgY2h1bmtfaW5kZXggPSBpbmRleDsKfQoKZG9jdW1lbnQub25rZXlkb3duID0gZnVu Y3Rpb24oZSkgewogICAgc3dpdGNoIChlLmtleUNvZGUpIHsKICAgIGNhc2UgNzg6CiAgICAgICAg Y2hhbmdlX2NodW5rKDEpOwogICAgICAgIGJyZWFrOwogICAgY2FzZSA4MDoKICAgICAgICBjaGFu Z2VfY2h1bmsoLTEpOwogICAgICAgIGJyZWFrOwogICAgfQp9OwogICA8L3NjcmlwdD4gCjwvaGVh ZD4gCjxib2R5IGRhdGEtZ3ItYy1zLWxvYWRlZD0idHJ1ZSI+IAogIDx0YWJsZSBib3JkZXI9IjAi IGNlbGxwYWRkaW5nPSIwIiBjZWxsc3BhY2luZz0iMCI+IAogIDx0Ym9keT48dHIgaWQ9InBhcnQt MSIgYmdjb2xvcj0ib3JhbmdlIj48dGg+PC90aD48dGg+PGEgaHJlZj0iaHR0cHM6Ly93d3c2Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWlwcG0tc3RhbXAtMDUudHh0IiBzdHlsZT0i Y29sb3I6IzAwODsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij4mbHQ7PC9hPiZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlwcG0tc3RhbXAtMDUudHh0 IiBzdHlsZT0iY29sb3I6IzAwOCI+ZHJhZnQtaWV0Zi1pcHBtLXN0YW1wLTA1LnR4dDwvYT4mbmJz cDs8L3RoPjx0aD4gPC90aD48dGg+Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtaXBwbS1zdGFtcC0wNi50eHQiIHN0eWxlPSJjb2xvcjojMDA4Ij5k cmFmdC1pZXRmLWlwcG0tc3RhbXAtMDYudHh0PC9hPiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3 Ni5pZXRmLm9yZy9yZmNkaWZmP3VybDE9ZHJhZnQtaWV0Zi1pcHBtLXN0YW1wLTA2LnR4dCIgc3R5 bGU9ImNvbG9yOiMwMDg7IHRleHQtZGVjb3JhdGlvbjpub25lOyI+Jmd0OzwvYT48L3RoPjx0aD48 L3RoPjwvdHI+IAogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIEcuIE1pcnNreTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi Pk5ldHdvcmsgV29ya2luZyBHcm91cCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEcuIE1pcnNreTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+SW50ZXJuZXQtRHJh ZnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWlRFIENv cnAuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+SW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWlRFIENvcnAuPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5JbnRlbmRlZCBzdGF0dXM6IFN0YW5kYXJkcyBUcmFjayAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBHLiBKdW48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij5JbnRlbmRlZCBzdGF0dXM6IFN0YW5kYXJkcyBUcmFjayAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBHLiBKdW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDEiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+RXhwaXJlczogPHNwYW4g Y2xhc3M9ImRlbGV0ZSI+SnVuZSAxLCAyMDE5ICAgIDwvc3Bhbj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFpURSBDb3Jwb3JhdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj5FeHBpcmVzOiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5PY3RvYmVyIDI1LCAyMDE5PC9zcGFu PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgWlRFIENvcnBvcmF0aW9uPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBILiBOeWRlbGw8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBILiBOeWRlbGw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBY2Nl ZGlhbiBOZXR3b3JrczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBBY2NlZGlhbiBOZXR3 b3JrczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFIuIEZvb3RlPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFIuIEZvb3RlPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgTm9raWE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgTm9raWE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0ciBpZD0iZGlmZjAwMDIiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPk5vdmVtYmVy IDI4LCAyMDE4PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHNwYW4gY2xh c3M9Imluc2VydCI+ICAgQXByaWwgMjMsIDIwMTk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgIFNpbXBsZSBUd28td2F5IEFjdGl2ZSBNZWFzdXJl bWVudCBQcm90b2NvbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAg ICAgIFNpbXBsZSBUd28td2F5IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwMyI+PHRkPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICAgICAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLWlwcG0tc3RhbXAtMDxzcGFuIGNs YXNzPSJkZWxldGUiPjU8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAg ICAgICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtaXBwbS1zdGFtcC0wPHNwYW4gY2xhc3M9 Imluc2VydCI+Njwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+QWJzdHJh Y3Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5BYnN0cmFjdDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIFNpbXBsZSBU d28td2F5IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgU2ltcGxlIFR3by13YXkgQWN0 aXZlIE1lYXN1cmVtZW50IFByb3RvY29sPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB3 aGljaCBlbmFibGVzIHRoZSBtZWFzdXJlbWVudCBvZiBib3RoIG9uZS13YXkgYW5kIHJvdW5kLXRy aXA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB3aGljaCBlbmFibGVzIHRoZSBt ZWFzdXJlbWVudCBvZiBib3RoIG9uZS13YXkgYW5kIHJvdW5kLXRyaXA8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIHBlcmZvcm1hbmNlIG1ldHJpY3MgbGlrZSBkZWxheSwgZGVsYXkgdmFy aWF0aW9uLCBhbmQgcGFja2V0IGxvc3MuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgcGVyZm9ybWFuY2UgbWV0cmljcyBsaWtlIGRlbGF5LCBkZWxheSB2YXJpYXRpb24sIGFuZCBw YWNrZXQgbG9zcy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+U3RhdHVzIG9mIFRo aXMgTWVtbzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPlN0YXR1cyBvZiBUaGlzIE1l bW88L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBJbnRlcm5ldC1EcmFm dCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3JtYW5jZSB3aXRoIHRoZTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgaXMgc3VibWl0dGVkIGlu IGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTIiIGNsYXNzPSJjaGFuZ2UiPjx0ZD48L3RkPjx0 aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3 dzYuaWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQjcGFydC0yIj48ZW0+IHBhZ2UgMSwgbGlu ZSAzNzxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGg+IDwvdGg+ PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0dHBzOi8v d3d3Ni5pZXRmLm9yZy9yZmNkaWZmL3JmY2RpZmYucHlodCNwYXJ0LTIiPjxlbT4gcGFnZSAxLCBs aW5lIDM3PHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1bWVudHMgb2YgdGhlIEludGVybmV0 IEVuZ2luZWVyaW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW50ZXJuZXQt RHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmc8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRhc2sgRm9yY2UgKElFVEYpLiAgTm90ZSB0 aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBz IG1heSBhbHNvIGRpc3RyaWJ1dGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHdvcmtp bmcgZG9jdW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50 ZXJuZXQtPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgd29ya2luZyBkb2N1bWVu dHMgYXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC08L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIERyYWZ0cyBpcyBhdCBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBEcmFmdHMgaXMgYXQgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMv Y3VycmVudC8uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEludGVybmV0LURy YWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRo czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEludGVybmV0LURyYWZ0cyBhcmUg ZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBhIG1heGltdW0gb2Ygc2l4IG1vbnRoczwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Ig b2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQg Ynkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg dGltZS4gIEl0IGlzIGluYXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZl cmVuY2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0aW1lLiAgSXQgaXMgaW5h cHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4g YXMgIndvcmsgaW4gcHJvZ3Jlc3MuIjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IG1hdGVyaWFsIG9yIHRvIGNpdGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNz LiI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJk aWZmMDAwNCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9u IDxzcGFuIGNsYXNzPSJkZWxldGUiPkp1bmUgMTwvc3Bhbj4sIDIwMTkuPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24g PHNwYW4gY2xhc3M9Imluc2VydCI+T2N0b2JlciAyNTwvc3Bhbj4sIDIwMTkuPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPkNvcHlyaWdodCBOb3RpY2U8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij5Db3B5cmlnaHQgTm90aWNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDUiPjx0ZD48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgQ29weXJp Z2h0IChjKSAyMDE8c3BhbiBjbGFzcz0iZGVsZXRlIj44PC9zcGFuPiBJRVRGIFRydXN0IGFuZCB0 aGUgcGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj4gICBDb3B5cmlnaHQgKGMpIDIwMTxzcGFuIGNsYXNzPSJpbnNlcnQiPjk8L3NwYW4+IElF VEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkb2N1bWVudCBhdXRob3JzLiAgQWxs IHJpZ2h0cyByZXNlcnZlZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhp cyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1c3QncyBMZWdh bDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgZG9jdW1lbnQgaXMgc3Vi amVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWw8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1bWVudHM8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElF VEYgRG9jdW1lbnRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAoaHR0cHM6Ly90cnVz dGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRlIG9mPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKGh0dHBzOi8vdHJ1c3RlZS5pZXRmLm9yZy9s aWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcg dGhlc2UgZG9jdW1lbnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcHVibGlj YXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUg eW91ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3Q8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91ciByaWdo dHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIHRvIHRoaXMgZG9jdW1lbnQuICBDb2RlIENvbXBvbmVudHMgZXh0cmFjdGVkIGZyb20g dGhpcyBkb2N1bWVudCBtdXN0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdG8g dGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3Vt ZW50IG11c3Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGluY2x1ZGUgU2ltcGxpZmll ZCBCU0QgTGljZW5zZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGluY2x1ZGUgU2ltcGxpZmllZCBCU0QgTGljZW5z ZSB0ZXh0IGFzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDQuZSBvZjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgdGhlIFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3 aXRob3V0IHdhcnJhbnR5IGFzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgdGhl IFRydXN0IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5 IGFzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0i cGFydC0zIiBjbGFzcz0iY2hhbmdlIj48dGQ+PC90ZD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNo YW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93d3c2LmlldGYub3JnL3JmY2RpZmYvcmZj ZGlmZi5weWh0I3BhcnQtMyI+PGVtPiBwYWdlIDIsIGxpbmUgMTg8c3BhbiBjbGFzcz0iaGlkZSI+ IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48c21hbGw+c2tpcHBpbmcgdG8g Y2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3dzYuaWV0Zi5vcmcvcmZjZGlmZi9y ZmNkaWZmLnB5aHQjcGFydC0zIj48ZW0+IHBhZ2UgMiwgbGluZSAxODxzcGFuIGNsYXNzPSJoaWRl Ij4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5UYWJsZSBvZiBDb250ZW50czwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPlRhYmxlIG9mIENvbnRlbnRzPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDEuICBJbnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIDEuICBJbnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgMi4gIENvbnZlbnRpb25zIHVzZWQgaW4gdGhpcyBkb2N1bWVudCAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gICAzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgMi4gIENv bnZlbnRpb25zIHVzZWQgaW4gdGhpcyBkb2N1bWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICAzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDIuMS4gIFRlcm1pbm9sb2d5 IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDM8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDIuMS4gIFRlcm1pbm9sb2d5IC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDM8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgMi4yLiAgUmVxdWlyZW1lbnRzIExhbmd1YWdlIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICAgMi4yLiAgUmVxdWlyZW1lbnRzIExhbmd1YWdlIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAgMzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgMy4gIFNv ZnR3YXJpemF0aW9uIG9mIFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50IC4gLiAuIC4gLiAuIC4gLiAu IC4gICAzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgMy4gIFNvZnR3YXJpemF0 aW9uIG9mIFBlcmZvcm1hbmNlIE1lYXN1cmVtZW50IC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICA0LiAgVGhlb3J5IG9mIE9wZXJhdGlvbiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQ8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICA0LiAgVGhlb3J5IG9mIE9wZXJhdGlvbiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgICAgNC4xLiAgU2Vzc2lvbi1TZW5kZXIgQmVoYXZpb3IgYW5kIFBhY2tldCBGb3JtYXQg LiAuIC4gLiAuIC4gLiAuICAgNDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg NC4xLiAgU2Vzc2lvbi1TZW5kZXIgQmVoYXZpb3IgYW5kIFBhY2tldCBGb3JtYXQgLiAuIC4gLiAu IC4gLiAuICAgNDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIDQuMS4xLiAgU2Vz c2lvbi1TZW5kZXIgUGFja2V0IEZvcm1hdCBpbiBVbmF1dGhlbnRpY2F0ZWQgTW9kZSAgICA0PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgIDQuMS4xLiAgU2Vzc2lvbi1TZW5k ZXIgUGFja2V0IEZvcm1hdCBpbiBVbmF1dGhlbnRpY2F0ZWQgTW9kZSAgICA0PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA2Ij48dGQ+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgICAgICA0LjEuMi4gIFNlc3Npb24tU2VuZGVyIFBhY2tldCBGb3JtYXQgaW4gQXV0aGVudGlj YXRlZCBNb2RlICAuICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Nzwvc3Bhbj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgIDQuMS4yLiAgU2Vzc2lvbi1TZW5kZXIgUGFja2V0 IEZvcm1hdCBpbiBBdXRoZW50aWNhdGVkIE1vZGUgIC4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij42 PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICA0LjIuICBTZXNzaW9uLVJl ZmxlY3RvciBCZWhhdmlvciBhbmQgUGFja2V0IEZvcm1hdCAgLiAuIC4gLiAuIC4gICA3PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICA0LjIuICBTZXNzaW9uLVJlZmxlY3RvciBC ZWhhdmlvciBhbmQgUGFja2V0IEZvcm1hdCAgLiAuIC4gLiAuIC4gICA3PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgICAgNC4yLjEuICBTZXNzaW9uLVJlZmxlY3RvciBQYWNrZXQgRm9y bWF0IGluIFVuYXV0aGVudGljYXRlZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg ICAgICA0LjIuMS4gIFNlc3Npb24tUmVmbGVjdG9yIFBhY2tldCBGb3JtYXQgaW4gVW5hdXRoZW50 aWNhdGVkPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICBNb2RlICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDg8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICBNb2RlICAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDg8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDciPjx0ZD48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg ICAgIDQuMi4yLiAgU2Vzc2lvbi1SZWZsZWN0b3IgUGFja2V0IEZvcm1hdCBpbiBBdXRoZW50aWNh dGVkIE1vZGUgIDxzcGFuIGNsYXNzPSJkZWxldGUiPjEwPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgNC4yLjIuICBTZXNzaW9uLVJlZmxlY3RvciBQYWNrZXQg Rm9ybWF0IGluIEF1dGhlbnRpY2F0ZWQgTW9kZSAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjk8L3Nw YW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgNC4zLiAgSW50ZWdyaXR5IGFu ZCBDb25maWRlbnRpYWxpdHkgUHJvdGVjdGlvbiBpbiBTVEFNUCAuIC4gLiAuICA8c3BhbiBjbGFz cz0iZGVsZXRlIj4xMjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg ICA0LjMuICBJbnRlZ3JpdHkgYW5kIENvbmZpZGVudGlhbGl0eSBQcm90ZWN0aW9uIGluIFNUQU1Q IC4gLiAuIC4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjExPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICAgIDQuNC4gIEludGVyb3BlcmFiaWxpdHkgd2l0aCBUV0FNUCBMaWdo dCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTI8L3NwYW4+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgNC40LiAgSW50ZXJvcGVyYWJp bGl0eSB3aXRoIFRXQU1QIExpZ2h0IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA8c3BhbiBjbGFz cz0iaW5zZXJ0Ij4xMTwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgNS4g IElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPjEzPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICA1LiAgSUFOQSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+MTI8L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDYuICBTZWN1cml0eSBDb25zaWRlcmF0 aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0i ZGVsZXRlIj4xMzwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgNi4g IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjEyPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICA3LiAgQWNrbm93bGVkZ21lbnRzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTM8L3NwYW4+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDcuICBBY2tub3dsZWRnbWVudHMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0i aW5zZXJ0Ij4xMjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgOC4gIFJl ZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDxzcGFuIGNsYXNzPSJkZWxldGUiPjEzPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICA4LiAgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+MTI8L3NwYW4+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgOC4xLiAgTm9ybWF0aXZlIFJlZmVyZW5j ZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iZGVs ZXRlIj4xMzwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICA4LjEu ICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjEyPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj4gICAgIDguMi4gIEluZm9ybWF0aXZlIFJlZmVyZW5jZXMgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+MTQ8L3NwYW4+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgOC4yLiAgSW5mb3JtYXRpdmUgUmVmZXJl bmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICA8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4xMzwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEF1dGhvcnMnIEFk ZHJlc3NlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAx NDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEF1dGhvcnMnIEFkZHJlc3NlcyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAxNDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4xLiAgSW50cm9kdWN0aW9uPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+MS4gIEludHJvZHVjdGlvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBEZXZlbG9wbWVudCBhbmQgZGVwbG95bWVudCBvZiBUd28tV2F5IEFjdGl2 ZSBNZWFzdXJlbWVudCBQcm90b2NvbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IERldmVsb3BtZW50IGFuZCBkZXBsb3ltZW50IG9mIFR3by1XYXkgQWN0aXZlIE1lYXN1cmVtZW50 IFByb3RvY29sPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAoVFdBTVApIFtSRkM1MzU3 XSBhbmQgaXRzIGV4dGVuc2lvbnMsIGUuZy4sIFtSRkM2MDM4XSB0aGF0IGRlZmluZWQ8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAoVFdBTVApIFtSRkM1MzU3XSBhbmQgaXRzIGV4 dGVuc2lvbnMsIGUuZy4sIFtSRkM2MDM4XSB0aGF0IGRlZmluZWQ8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIGZlYXR1cmVzIHN1Y2ggYXMgUmVmbGVjdCBPY3RldHMgYW5kIFN5bW1ldHJp Y2FsIFNpemUgZm9yIFRXQU1QPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZmVh dHVyZXMgc3VjaCBhcyBSZWZsZWN0IE9jdGV0cyBhbmQgU3ltbWV0cmljYWwgU2l6ZSBmb3IgVFdB TVA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHByb3ZpZGVkIGludmFsdWFibGUgZXhw ZXJpZW5jZS4gIFNldmVyYWwgaW5kZXBlbmRlbnQgaW1wbGVtZW50YXRpb25zPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcHJvdmlkZWQgaW52YWx1YWJsZSBleHBlcmllbmNlLiAg U2V2ZXJhbCBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIGV4aXN0LCBoYXZlIGJlZW4gZGVwbG95ZWQgYW5kIHByb3ZpZGUgaW1wb3J0YW50 IG9wZXJhdGlvbmFsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZXhpc3QsIGhh dmUgYmVlbiBkZXBsb3llZCBhbmQgcHJvdmlkZSBpbXBvcnRhbnQgb3BlcmF0aW9uYWw8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50cy4gIEF0IHRo ZSBzYW1lIHRpbWUsIHRoZXJlIGhhcyBiZWVuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgcGVyZm9ybWFuY2UgbWVhc3VyZW1lbnRzLiAgQXQgdGhlIHNhbWUgdGltZSwgdGhlcmUg aGFzIGJlZW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG5vdGljZWFibGUgaW50ZXJl c3QgaW4gdXNpbmcgYSBzaW1wbGVyIG1lY2hhbmlzbSBmb3IgYWN0aXZlPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgbm90aWNlYWJsZSBpbnRlcmVzdCBpbiB1c2luZyBhIHNpbXBs ZXIgbWVjaGFuaXNtIGZvciBhY3RpdmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHBl cmZvcm1hbmNlIG1vbml0b3JpbmcgdGhhdCBjYW4gcHJvdmlkZSBkZXRlcm1pbmlzdGljIGJlaGF2 aW9yIGFuZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHBlcmZvcm1hbmNlIG1v bml0b3JpbmcgdGhhdCBjYW4gcHJvdmlkZSBkZXRlcm1pbmlzdGljIGJlaGF2aW9yIGFuZDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaW5oZXJpdCBzZXBhcmF0aW9uIG9mIGNvbnRyb2wg KHZlbmRvci1zcGVjaWZpYyBjb25maWd1cmF0aW9uIG9yPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgaW5oZXJpdCBzZXBhcmF0aW9uIG9mIGNvbnRyb2wgKHZlbmRvci1zcGVjaWZp YyBjb25maWd1cmF0aW9uIG9yPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvcmNoZXN0 cmF0aW9uKSBhbmQgdGVzdCBmdW5jdGlvbnMuICBPbmUgb2Ygc3VjaCBpcyBQZXJmb3JtYW5jZTwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9yY2hlc3RyYXRpb24pIGFuZCB0ZXN0 IGZ1bmN0aW9ucy4gIE9uZSBvZiBzdWNoIGlzIFBlcmZvcm1hbmNlPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBNZWFzdXJlbWVudCBmcm9tIElQIEVkZ2UgdG8gQ3VzdG9tZXIgRXF1aXBt ZW50IHVzaW5nIFRXQU1QIExpZ2h0IGZyb208L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBNZWFzdXJlbWVudCBmcm9tIElQIEVkZ2UgdG8gQ3VzdG9tZXIgRXF1aXBtZW50IHVzaW5n IFRXQU1QIExpZ2h0IGZyb208L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0ciBpZD0iZGlmZjAwMDgiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgQnJvYWRiYW5kIEZvcnVtIDxzcGFuIGNs YXNzPSJkZWxldGUiPihbQkJGLlRSLTM5MF0pLjwvc3Bhbj4gIFRoaXMgZG9jdW1lbnQgZGVmaW5l cyBhY3RpdmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgQnJvYWRiYW5kIEZv cnVtIDxzcGFuIGNsYXNzPSJpbnNlcnQiPltCQkYuVFItMzkwXSB1c2VkIGFzIHRoZSByZWZlcmVu Y2UgVFdBTVAgTGlnaHQgdGhhdCw8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgIHBlcmZvcm1hbmNlIG1lYXN1cmVtZW50IHRlc3QgcHJvdG9jb2wsIFNpbXBsZSBUd28td2F5 IEFjdGl2ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4gICBhY2NvcmRpbmcgdG8gW1JGQzg1NDVdLCBpbmNsdWRlcyBzdWItc2V0IG9mIFRXQU1Q LVRlc3QgZnVuY3Rpb25zIGluPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICBNZWFzdXJlbWVudCBQcm90b2NvbCAoU1RBTVApLCB0aGF0IGVuYWJsZXMgbWVhc3VyZW1lbnQg b2YgYm90aCA8c3BhbiBjbGFzcz0iZGVsZXRlIj5vbmUtPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBjb21iaW5hdGlvbiB3aXRo IG90aGVyIGFwcGxpY2F0aW9ucyB0aGF0IHByb3ZpZGUsIGZvciBleGFtcGxlLDwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgd2F5PC9z cGFuPiBhbmQgcm91bmQtdHJpcCBwZXJmb3JtYW5jZSBtZXRyaWNzIGxpa2UgZGVsYXksIGRlbGF5 IHZhcmlhdGlvbiw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9 Imluc2VydCI+ICAgY29udHJvbCBhbmQgc2VjdXJpdHkuPC9zcGFuPiAgVGhpcyBkb2N1bWVudCBk ZWZpbmVzIGFjdGl2ZSBwZXJmb3JtYW5jZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICBhbmQgcGFja2V0IGxvc3MuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIG1l YXN1cmVtZW50IHRlc3QgcHJvdG9jb2wsIFNpbXBsZSBUd28td2F5IEFjdGl2ZSBNZWFzdXJlbWVu dCBQcm90b2NvbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgKFNUQU1QKSwgdGhhdCBlbmFibGVzIG1lYXN1cmVtZW50IG9m IGJvdGggPHNwYW4gY2xhc3M9Imluc2VydCI+b25lLXdheTwvc3Bhbj4gYW5kIHJvdW5kLXRyaXA8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgIHBlcmZvcm1hbmNlIG1ldHJpY3MgbGlrZSBkZWxheSwgZGVsYXkgdmFyaWF0aW9u LCBhbmQgcGFja2V0IGxvc3MuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjIuICBD b252ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9jdW1lbnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4yLiAgQ29udmVudGlvbnMgdXNlZCBpbiB0aGlzIGRvY3VtZW50PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjIuMS4gIFRlcm1pbm9sb2d5PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+Mi4xLiAgVGVybWlub2xvZ3k8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgQUVTIEFkdmFuY2VkIEVuY3J5cHRpb24gU3RhbmRhcmQ8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBRVMgQWR2YW5jZWQgRW5jcnlwdGlvbiBTdGFuZGFyZDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBDQkMgQ2lwaGVyIEJsb2NrIENoYWlu aW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQ0JDIENpcGhlciBCbG9jayBD aGFpbmluZzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBFQ0IgRWxlY3Ryb25p YyBDb29rYm9vazwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEVDQiBFbGVjdHJv bmljIENvb2tib29rPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0ciBpZD0icGFydC00IiBjbGFzcz0iY2hhbmdlIj48dGQ+PC90ZD48dGg+PHNtYWxsPnNraXBw aW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93d3c2LmlldGYub3JnL3Jm Y2RpZmYvcmZjZGlmZi5weWh0I3BhcnQtNCI+PGVtPiBwYWdlIDMsIGxpbmUgMzk8c3BhbiBjbGFz cz0iaGlkZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48c21hbGw+c2tp cHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3dzYuaWV0Zi5vcmcv cmZjZGlmZi9yZmNkaWZmLnB5aHQjcGFydC00Ij48ZW0+IHBhZ2UgMywgbGluZSA0MTxzcGFuIGNs YXNzPSJoaWRlIj4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4yLjIuICBSZXF1aXJl bWVudHMgTGFuZ3VhZ2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4yLjIuICBSZXF1 aXJlbWVudHMgTGFuZ3VhZ2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhl IGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFM TCBOT1QiLDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBrZXkgd29yZHMg Ik1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiw8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNP TU1FTkRFRCIsICJOT1QgUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwg Ik5PVCBSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMg ZGVzY3JpYmVkIGluIEJDUDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICJPUFRJ T05BTCIgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVk IGluIEJDUDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgMTQgW1JGQzIxMTldIFtSRkM4 MTc0XSB3aGVuLCBhbmQgb25seSB3aGVuLCB0aGV5IGFwcGVhciBpbiBhbGw8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAxNCBbUkZDMjExOV0gW1JGQzgxNzRdIHdoZW4sIGFuZCBv bmx5IHdoZW4sIHRoZXkgYXBwZWFyIGluIGFsbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgY2FwaXRhbHMsIGFzIHNob3duIGhlcmUuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgY2FwaXRhbHMsIGFzIHNob3duIGhlcmUuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjMuICBTb2Z0d2FyaXphdGlvbiBvZiBQZXJmb3JtYW5jZSBNZWFzdXJlbWVudDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjMuICBTb2Z0d2FyaXphdGlvbiBvZiBQZXJmb3Jt YW5jZSBNZWFzdXJlbWVudDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHIgaWQ9ImRpZmYwMDA5Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIEZpZ3VyZSAxIHByZXNlbnRzIFNp bXBsZSBUd28td2F5IEFjdGl2ZSBNZWFzdXJlbWVudCBQcm90b2NvbCAoU1RBTVApPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIEZpZ3VyZSAxIHByZXNlbnRzIDxzcGFuIGNsYXNz PSJpbnNlcnQiPnRoZTwvc3Bhbj4gU2ltcGxlIFR3by13YXkgQWN0aXZlIE1lYXN1cmVtZW50IFBy b3RvY29sPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFNlc3Npb24tU2VuZGVyIGFu ZCBTZXNzaW9uLVJlZmxlY3RvciB3aXRoIGEgbWVhc3VyZW1lbnQgc2Vzc2lvbi4gIFRoZTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAoU1RBTVApIFNlc3Npb24tU2VuZGVyIGFu ZCBTZXNzaW9uLVJlZmxlY3RvciB3aXRoIGEgbWVhc3VyZW1lbnQ8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+ICAgY29uZmlndXJhdGlvbiBhbmQgbWFuYWdlbWVudCBvZiB0aGUgU1RBTVAg PHNwYW4gY2xhc3M9ImRlbGV0ZSI+U2Vzc2lvbi1TZW5kZXIsPC9zcGFuPiBTZXNzaW9uLTwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBzZXNzaW9uLiAgVGhlIGNvbmZpZ3VyYXRp b24gYW5kIG1hbmFnZW1lbnQgb2YgdGhlIFNUQU1QIFNlc3Npb24tPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPlJlZmxlY3Rvcjwvc3Bhbj4gYW5k IG1hbmFnZW1lbnQgb2YgdGhlIFNUQU1QIHNlc3Npb25zIGNhbiBiZSBhY2hpZXZlZDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5TZW5kZXIs IFNlc3Npb24tUmVmbGVjdG9yPC9zcGFuPiBhbmQgbWFuYWdlbWVudCBvZiB0aGUgU1RBTVAgc2Vz c2lvbnMgY2FuIGJlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHRocm91Z2ggdmFy aW91cyBtZWFucy4gIENvbW1hbmQgTGluZSBJbnRlcmZhY2UsIE9TUy9CU1MgdXNpbmcgU05NUCBv cjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBhY2hpZXZlZCB0aHJvdWdoIHZh cmlvdXMgbWVhbnMuICBDb21tYW5kIExpbmUgSW50ZXJmYWNlLCBPU1MvQlNTPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPlNETjwvc3Bhbj4gdXNp bmcgTmV0Y29uZi9ZQU5HIGFyZSBidXQgYSBmZXcgZXhhbXBsZXMuPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPihvcGVyYXRpb25zIHN1cHBv cnQgc3lzdGVtL2J1c2luZXNzIHN1cHBvcnQgc3lzdGVtIGFzIGEgY29tYmluYXRpb248L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBvZiB0d28gc3lzdGVtcyB1c2VkIHRvIHN1 cHBvcnQgYSByYW5nZSBvZiB0ZWxlY29tbXVuaWNhdGlvbiBzZXJ2aWNlcyk8L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICB1c2luZyBTTk1QIG9yIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmNvbnRyb2xsZXJzIGluIFNv ZnR3YXJlLURlZmluZWQgTmV0d29ya2luZzwvc3Bhbj4gdXNpbmc8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIE5ldGNvbmYv WUFORyBhcmUgYnV0IGEgZmV3IGV4YW1wbGVzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAgICAgICBvLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLW88L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAg ICBvLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLW88L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgQ29uZmlndXJhdGlvbiBhbmQgICAgICAgICAgICAgICAgICAgfDwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgQ29u ZmlndXJhdGlvbiBhbmQgICAgICAgICAgICAgICAgICAgfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICBNYW5hZ2VtZW50ICAgICAg ICAgICAgICAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICBNYW5hZ2VtZW50ICAgICAgICAgICAgICAgICAg ICAgICB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICBvLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLW88L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICBvLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLW88L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgICAgICAgICAgICB8fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHx8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAg ICAgIHx8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfHw8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICB8fCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHx8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgICAgICAgICAgIHx8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICB8fCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHx8PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgIHx8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg Ky0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgKy0tLS0tLS0t LS0tLS0tLS0tLS0tLS0rICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t KzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICB8IFNUQU1QIFNlc3Npb24tU2VuZGVy IHwgJmx0Oy0tLSBTVEFNUC0tLSZndDsgfCBTVEFNUCBTZXNzaW9uLVJlZmxlY3RvciB8PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICB8IFNUQU1QIFNlc3Npb24tU2VuZGVyIHwg Jmx0Oy0tLSBTVEFNUC0tLSZndDsgfCBTVEFNUCBTZXNzaW9uLVJlZmxlY3RvciB8PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0icGFydC01IiBjbGFz cz0iY2hhbmdlIj48dGQ+PC90ZD48dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21h bGw+PGEgaHJlZj0iaHR0cHM6Ly93d3c2LmlldGYub3JnL3JmY2RpZmYvcmZjZGlmZi5weWh0I3Bh cnQtNSI+PGVtPiBwYWdlIDQsIGxpbmUgMjg8c3BhbiBjbGFzcz0iaGlkZSI+IMK2PC9zcGFuPjwv ZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9z bWFsbD48YSBocmVmPSJodHRwczovL3d3dzYuaWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQj cGFydC01Ij48ZW0+IHBhZ2UgNCwgbGluZSAyODxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8L3NwYW4+ PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij40LiAgVGhlb3J5IG9mIE9wZXJhdGlvbjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjQuICBUaGVvcnkgb2YgT3BlcmF0aW9uPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFNUQU1QIFNlc3Npb24tU2VuZGVyIHRyYW5zbWl0cyB0 ZXN0IHBhY2tldHMgdG93YXJkIFNUQU1QIFNlc3Npb24tPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgU1RBTVAgU2Vzc2lvbi1TZW5kZXIgdHJhbnNtaXRzIHRlc3QgcGFja2V0cyB0 b3dhcmQgU1RBTVAgU2Vzc2lvbi08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFJlZmxl Y3Rvci4gIFNUQU1QIFNlc3Npb24tUmVmbGVjdG9yIHJlY2VpdmVzIFNlc3Npb24tU2VuZGVyJ3Mg cGFja2V0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgUmVmbGVjdG9yLiAgU1RB TVAgU2Vzc2lvbi1SZWZsZWN0b3IgcmVjZWl2ZXMgU2Vzc2lvbi1TZW5kZXIncyBwYWNrZXQ8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGFuZCBhY3RzIGFjY29yZGluZyB0byB0aGUgY29u ZmlndXJhdGlvbiBhbmQgb3B0aW9uYWwgY29udHJvbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgIGFuZCBhY3RzIGFjY29yZGluZyB0byB0aGUgY29uZmlndXJhdGlvbiBhbmQgb3B0 aW9uYWwgY29udHJvbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaW5mb3JtYXRpb24g Y29tbXVuaWNhdGVkIGluIHRoZSBTZXNzaW9uLVNlbmRlcidzIHRlc3QgcGFja2V0LiAgU1RBTVA8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpbmZvcm1hdGlvbiBjb21tdW5pY2F0 ZWQgaW4gdGhlIFNlc3Npb24tU2VuZGVyJ3MgdGVzdCBwYWNrZXQuICBTVEFNUDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgZGVmaW5lcyB0d28gZGlmZmVyZW50IHRlc3QgcGFja2V0IGZv cm1hdHMsIG9uZSBmb3IgcGFja2V0czwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IGRlZmluZXMgdHdvIGRpZmZlcmVudCB0ZXN0IHBhY2tldCBmb3JtYXRzLCBvbmUgZm9yIHBhY2tl dHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRyYW5zbWl0dGVkIGJ5IHRoZSBTVEFN UC1TZXNzaW9uLVNlbmRlciBhbmQgb25lIGZvciBwYWNrZXRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgdHJhbnNtaXR0ZWQgYnkgdGhlIFNUQU1QLVNlc3Npb24tU2VuZGVyIGFu ZCBvbmUgZm9yIHBhY2tldHM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRyYW5zbWl0 dGVkIGJ5IHRoZSBTVEFNUC1TZXNzaW9uLVJlZmxlY3Rvci4gIFNUQU1QIHN1cHBvcnRzIHR3bzwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRyYW5zbWl0dGVkIGJ5IHRoZSBTVEFN UC1TZXNzaW9uLVJlZmxlY3Rvci4gIFNUQU1QIHN1cHBvcnRzIHR3bzwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgbW9kZXM6IHVuYXV0aGVudGljYXRlZCBhbmQgYXV0aGVudGljYXRlZC4g IFVuYXV0aGVudGljYXRlZCBTVEFNUCB0ZXN0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgbW9kZXM6IHVuYXV0aGVudGljYXRlZCBhbmQgYXV0aGVudGljYXRlZC4gIFVuYXV0aGVu dGljYXRlZCBTVEFNUCB0ZXN0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHIgaWQ9ImRpZmYwMDEwIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPnBh Y2tldHMgYXJlIGNvbXBhdGlibGUgb24gdGhlIHdpcmUgd2l0aCB1bmF1dGhlbnRpY2F0ZWQgVFdB TVAtVGVzdDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4g Y2xhc3M9Imluc2VydCI+cGFja2V0cywgZGVmaW5lZCBpbiBTZWN0aW9uIDQuMS4xIGFuZCBTZWN0 aW9uIDQuMi4xLCBlbnN1cmU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxz cGFuIGNsYXNzPSJkZWxldGUiPiAgIFtSRkM1MzU3XTwvc3Bhbj4gcGFja2V0IGZvcm1hdHMuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGlu dGVyd29ya2luZyBiZXR3ZWVuIFNUQU1QIGFuZCBUV0FNUCBMaWdodCBhcyBkZXNjcmliZWQgaW48 L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBTZWN0aW9uIDQuNDwvc3Bhbj4g cGFja2V0IGZvcm1hdHMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEJ5IGRl ZmF1bHQsIFNUQU1QIHVzZXMgc3ltbWV0cmljYWwgcGFja2V0cywgaS5lLiwgc2l6ZSBvZiB0aGUg cGFja2V0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQnkgZGVmYXVsdCwgU1RB TVAgdXNlcyBzeW1tZXRyaWNhbCBwYWNrZXRzLCBpLmUuLCBzaXplIG9mIHRoZSBwYWNrZXQ8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRyYW5zbWl0dGVkIGJ5IFNlc3Npb24tUmVmbGVj dG9yIGVxdWFscyB0aGUgc2l6ZSBvZiB0aGUgcGFja2V0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgdHJhbnNtaXR0ZWQgYnkgU2Vzc2lvbi1SZWZsZWN0b3IgZXF1YWxzIHRoZSBz aXplIG9mIHRoZSBwYWNrZXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHJlY2VpdmVk IGJ5IHRoZSBTZXNzaW9uLVJlZmxlY3Rvci48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICByZWNlaXZlZCBieSB0aGUgU2Vzc2lvbi1SZWZsZWN0b3IuPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjQuMS4gIFNlc3Npb24tU2VuZGVyIEJlaGF2aW9yIGFuZCBQYWNrZXQg Rm9ybWF0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+NC4xLiAgU2Vzc2lvbi1TZW5k ZXIgQmVoYXZpb3IgYW5kIFBhY2tldCBGb3JtYXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxMSI+PHRkPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFz cz0iZGVsZXRlIj40LjEuMS4gIFNlc3Npb24tU2VuZGVyIFBhY2tldCBGb3JtYXQgaW4gVW5hdXRo ZW50aWNhdGVkIE1vZGU8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQmVj YXVzZSBTVEFNUCBzdXBwb3J0cyBzeW1tZXRyaWNhbCB0ZXN0IHBhY2tldHMsIFNUQU1QIFNlc3Np b24tU2VuZGVyPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQmVjYXVzZSBTVEFN UCBzdXBwb3J0cyBzeW1tZXRyaWNhbCB0ZXN0IHBhY2tldHMsIFNUQU1QIFNlc3Npb24tU2VuZGVy PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBwYWNrZXQgaGFzIGEgbWluaW11bSBzaXpl IG9mIDQ0IG9jdGV0cyBpbiB1bmF1dGhlbnRpY2F0ZWQgbW9kZSwgc2VlPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgcGFja2V0IGhhcyBhIG1pbmltdW0gc2l6ZSBvZiA0NCBvY3Rl dHMgaW4gdW5hdXRoZW50aWNhdGVkIG1vZGUsIHNlZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxMiI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBGaWd1cmUgMiwg YW5kIDxzcGFuIGNsYXNzPSJkZWxldGUiPjQ4PC9zcGFuPiBvY3RldHMgaW4gdGhlIGF1dGhlbnRp Y2F0ZWQgbW9kZSwgc2VlIEZpZ3VyZSA0LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICBGaWd1cmUgMiwgYW5kIDxzcGFuIGNsYXNzPSJpbnNlcnQiPjExMjwvc3Bhbj4gb2N0ZXRz IGluIHRoZSBhdXRoZW50aWNhdGVkIG1vZGUsIHNlZSBGaWd1cmUgNC48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxMyI+PHRkPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5Gb3I8L3NwYW4+IHVuYXV0aGVudGljYXRlZCBtb2Rl OjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij40 LjEuMS4gIFNlc3Npb24tU2VuZGVyIFBhY2tldCBGb3JtYXQgaW4gVW5hdXRoZW50aWNhdGVkIE1v ZGU8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij48L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3Bh biBjbGFzcz0iaW5zZXJ0Ij4gICBTVEFNUCBTZXNzaW9uLVNlbmRlciBwYWNrZXQgZm9ybWF0IGlu PC9zcGFuPiB1bmF1dGhlbnRpY2F0ZWQgbW9kZTo8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAg ICAgICAgICAgICAgICAgIDM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAg MCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAg ICAgMzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMg NCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICBTZXF1ZW5jZSBOdW1iZXIgICAgICAgICAgICAgICAgICAgICAgICB8PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgfCAgICAgICAgICAgICAgICAgICAg ICAgIFNlcXVlbmNlIE51bWJlciAgICAgICAgICAgICAgICAgICAgICAgIHw8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgIFRpbWVzdGFtcCAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgVGltZXN0YW1wICAgICAgICAgICAgICAgICAgICAgICAgICAgIHw8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHwgICAgICAgICBFcnJvciBF c3RpbWF0ZSAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgfCAgICAgICAgIEVycm9yIEVzdGltYXRlICAg ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTYiIGNsYXNzPSJjaGFuZ2Ui Pjx0ZD48L3RkPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVm PSJodHRwczovL3d3dzYuaWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQjcGFydC02Ij48ZW0+ IHBhZ2UgNSwgbGluZSAyNzxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8L3NwYW4+PC9lbT48L2E+PC90 aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhy ZWY9Imh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9yZmNkaWZmL3JmY2RpZmYucHlodCNwYXJ0LTYiPjxl bT4gcGFnZSA1LCBsaW5lIDI3PHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48 L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgTUJaICgyNyBvY3Rl dHMpICAgICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICBNQlogKDI3IG9jdGV0cykgICAgICAg ICAgICAgICAgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHw8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICsgICAgICAgICAgICAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgKyAgICAgICAgICAgICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgIFNlcnZlciBPY3RldHMgICAg ICAgIHwgICAgICAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg ICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgU2VydmVyIE9jdGV0cyAgICAgICAgfCAgICAg ICAgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsgICAgICAgICAgICAgICArPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKyAgICAgICAgICAgICAgICs8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgICAgIHwgICAgICAgICAgIFJlbWFpbmluZyBQYWNrZXQgUGFkZGlu ZyAodG8gYmUgcmVmbGVjdGVkKSAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgfCAgICAgICAgICAgUmVtYWluaW5nIFBhY2tldCBQYWRkaW5nICh0byBiZSBy ZWZsZWN0ZWQpICAgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIH4g ICAgICAgICAgKGxlbmd0aCBpbiBvY3RldHMgc3BlY2lmaWVkIGluIFNlcnZlciBPY3RldHMpICAg ICAgICB+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgfiAgICAgICAgICAo bGVuZ3RoIGluIG9jdGV0cyBzcGVjaWZpZWQgaW4gU2VydmVyIE9jdGV0cykgICAgICAgIH48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICsgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTQiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICA8c3BhbiBjbGFzcz0i ZGVsZXRlIj5Db21wLk1CWiAgIHw8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAg ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSs8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAg IDxzcGFuIGNsYXNzPSJpbnNlcnQiPistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSs8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFu IGNsYXNzPSJkZWxldGUiPiAgICAgIHwgICAgICAgICAgICAgVHlwZSAgICAgICAgICAgICAgfCAg ICAgICAgICAgTGVuZ3RoICAgICAgICAgICAgICB8PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9 ImRlbGV0ZSI+ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSs8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRl Ij4gICAgICB+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFZhbHVlICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRmlndXJlIDI6IFNUQU1QIFNlc3Npb24tU2Vu ZGVyIHRlc3QgcGFja2V0IGZvcm1hdCBpbiB1bmF1dGhlbnRpY2F0ZWQ8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBGaWd1cmUgMjogU1RBTVAgU2Vzc2lvbi1TZW5kZXIgdGVzdCBw YWNrZXQgZm9ybWF0IGluIHVuYXV0aGVudGljYXRlZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb2RlPC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb2Rl PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHdoZXJlIGZpZWxkcyBhcmUgZGVm aW5lZCBhcyB0aGUgZm9sbG93aW5nOjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IHdoZXJlIGZpZWxkcyBhcmUgZGVmaW5lZCBhcyB0aGUgZm9sbG93aW5nOjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvICBTZXF1ZW5jZSBOdW1iZXIgaXMgZm91ciBvY3RldHMg bG9uZyBmaWVsZC4gIEZvciBlYWNoIG5ldyBzZXNzaW9uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgbyAgU2VxdWVuY2UgTnVtYmVyIGlzIGZvdXIgb2N0ZXRzIGxvbmcgZmllbGQu ICBGb3IgZWFjaCBuZXcgc2Vzc2lvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAg aXRzIHZhbHVlIHN0YXJ0cyBhdCB6ZXJvIGFuZCBpcyBpbmNyZW1lbnRlZCB3aXRoIGVhY2ggdHJh bnNtaXR0ZWQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBpdHMgdmFsdWUg c3RhcnRzIGF0IHplcm8gYW5kIGlzIGluY3JlbWVudGVkIHdpdGggZWFjaCB0cmFuc21pdHRlZDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgcGFja2V0LjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgICAgIHBhY2tldC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgbyAgVGltZXN0YW1wIGlzIGVpZ2h0IG9jdGV0cyBsb25nIGZpZWxkLiAgU1RBTVAg bm9kZSBNVVNUIHN1cHBvcnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvICBU aW1lc3RhbXAgaXMgZWlnaHQgb2N0ZXRzIGxvbmcgZmllbGQuICBTVEFNUCBub2RlIE1VU1Qgc3Vw cG9ydDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgTmV0d29yayBUaW1lIFByb3Rv Y29sIChOVFApIHZlcnNpb24gNCA2NC1iaXQgdGltZXN0YW1wIGZvcm1hdDwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIE5ldHdvcmsgVGltZSBQcm90b2NvbCAoTlRQKSB2ZXJz aW9uIDQgNjQtYml0IHRpbWVzdGFtcCBmb3JtYXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTUiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgPHNwYW4gY2xh c3M9ImRlbGV0ZSI+W1JGQzU5MDVdLjwvc3Bhbj4gIFNUQU1QIG5vZGUgTUFZIHN1cHBvcnQgSUVF RSAxNTg4djIgUHJlY2lzaW9uIFRpbWU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgICAgPHNwYW4gY2xhc3M9Imluc2VydCI+W1JGQzU5MDVdLCB0aGUgZm9ybWF0IHVzZWQgaW4g W1JGQzUzNTddLjwvc3Bhbj4gIFNUQU1QIG5vZGUgTUFZIHN1cHBvcnQ8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+ICAgICAgUHJvdG9jb2wgdHJ1bmNhdGVkIDY0LWJpdCB0aW1lc3RhbXAg Zm9ybWF0IDxzcGFuIGNsYXNzPSJkZWxldGUiPltJRUVFLjE1ODguMjAwOF0uPC9zcGFuPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICBJRUVFIDE1ODh2MiBQcmVjaXNpb24g VGltZSBQcm90b2NvbCB0cnVuY2F0ZWQgNjQtYml0IHRpbWVzdGFtcDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgZm9y bWF0IDxzcGFuIGNsYXNzPSJpbnNlcnQiPltJRUVFLjE1ODguMjAwOF0sIHRoZSBmb3JtYXQgdXNl ZCBpbiBbUkZDODE4Nl0uPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBvICBFcnJvciBFc3RpbWF0ZSBpcyB0d28gb2N0ZXRzIGxvbmcgZmllbGQgd2l0aCBmb3JtYXQg ZGlzcGxheWVkIGluPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbyAgRXJyb3Ig RXN0aW1hdGUgaXMgdHdvIG9jdGV0cyBsb25nIGZpZWxkIHdpdGggZm9ybWF0IGRpc3BsYXllZCBp bjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgRmlndXJlIDM8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBGaWd1cmUgMzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgICAgICAgICAgMCAgICAgICAgICAgICAgICAgICAxPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgMCAgICAgICAgICAgICAgICAgICAxPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgMCAxIDIg MyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICB8U3xafCAgIFNjYWxl ICAgfCAgIE11bHRpcGxpZXIgIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg ICAgICAgIHxTfFp8ICAgU2NhbGUgICB8ICAgTXVsdGlwbGllciAgfDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAg ICAgICAgICAgICAgICAgICAgRmlndXJlIDM6IEVycm9yIEVzdGltYXRlIEZvcm1hdDwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMzog RXJyb3IgRXN0aW1hdGUgRm9ybWF0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0ciBpZD0icGFydC03IiBjbGFzcz0iY2hhbmdlIj48dGQ+PC90ZD48dGg+PHNt YWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93d3c2Lmll dGYub3JnL3JmY2RpZmYvcmZjZGlmZi5weWh0I3BhcnQtNyI+PGVtPiBwYWdlIDYsIGxpbmUgMjk8 c3BhbiBjbGFzcz0iaGlkZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48 c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3dzYu aWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQjcGFydC03Ij48ZW0+IHBhZ2UgNiwgbGluZSAy OTxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgIFRoZSBTVEFNUCBTZXNzaW9uLVNlbmRlciBhbmQgU2Vzc2lvbi1SZWZsZWN0b3IgTUFZ IHVzZSwgbm90IHVzZSw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBUaGUg U1RBTVAgU2Vzc2lvbi1TZW5kZXIgYW5kIFNlc3Npb24tUmVmbGVjdG9yIE1BWSB1c2UsIG5vdCB1 c2UsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBvciBzZXQgdmFsdWUgb2YgdGhl IFogZmllbGQgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSB0aW1lc3RhbXA8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBvciBzZXQgdmFsdWUgb2YgdGhlIFogZmllbGQgaW4gYWNj b3JkYW5jZSB3aXRoIHRoZSB0aW1lc3RhbXA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgIGZvcm1hdCBpbiB1c2UuICBUaGlzIG9wdGlvbmFsIGZpZWxkIGlzIHRvIGVuaGFuY2Ugb3Bl cmF0aW9ucywgYnV0PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgZm9ybWF0 IGluIHVzZS4gIFRoaXMgb3B0aW9uYWwgZmllbGQgaXMgdG8gZW5oYW5jZSBvcGVyYXRpb25zLCBi dXQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIGxvY2FsIGNvbmZpZ3VyYXRpb24g b3IgZGVmYXVsdHMgY291bGQgYmUgdXNlZCBpbiBpdHMgcGxhY2UuPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgbG9jYWwgY29uZmlndXJhdGlvbiBvciBkZWZhdWx0cyBjb3Vs ZCBiZSB1c2VkIGluIGl0cyBwbGFjZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgbyAgTXVzdC1iZS1aZXJvIChNQlopIGZpZWxkIGluIHRoZSBzZXNzaW9uLXNlbmRlciB1bmF1 dGhlbnRpY2F0ZWQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvICBNdXN0LWJl LVplcm8gKE1CWikgZmllbGQgaW4gdGhlIHNlc3Npb24tc2VuZGVyIHVuYXV0aGVudGljYXRlZDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgcGFja2V0IGlzIDI3IG9jdGV0cyBsb25n LiAgSXQgTVVTVCBiZSBhbGwgemVyb2VkIG9uIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgICAgIHBhY2tldCBpcyAyNyBvY3RldHMgbG9uZy4gIEl0IE1VU1QgYmUgYWxsIHpl cm9lZCBvbiB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHRyYW5zbWlzc2lv biBhbmQgaWdub3JlZCBvbiByZWNlaXB0LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgICAgIHRyYW5zbWlzc2lvbiBhbmQgaWdub3JlZCBvbiByZWNlaXB0LjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDE2Ij48dGQ+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxv Y2siPiAgIG8gIFNlcnZlciBPY3RldHMgZmllbGQgaXMgdHdvIG9jdGV0cyBsb25nIGZpZWxkLiAg PHNwYW4gY2xhc3M9ImRlbGV0ZSI+SXQ8L3NwYW4+IE1VU1QgZm9sbG93IHRoZTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBvICBTZXJ2ZXIgT2N0ZXRzIGZpZWxkIGlzIDxzcGFu IGNsYXNzPSJpbnNlcnQiPm9wdGlvbmFsPC9zcGFuPiB0d28gb2N0ZXRzIGxvbmcgZmllbGQuICA8 c3BhbiBjbGFzcz0iaW5zZXJ0Ij5UaGlzIGZpZWxkPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj4gICAgICAyNyBvY3RldHMgbG9uZyBNQlogZmllbGQuICA8c3BhbiBjbGFzcz0i ZGVsZXRlIj5UaGUgUmVmbGVjdCBPY3RldHMgY2FwYWJpbGl0eSBkZWZpbmVkPC9zcGFuPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBp cyB1c2VkIGZvciB0aGUgUmVmbGVjdCBPY3RldHMgY2FwYWJpbGl0eSBkZWZpbmVkIGluIFtSRkM2 MDM4XS48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJk ZWxldGUiPiAgICAgIGluIFtSRkM2MDM4XS48L3NwYW4+ICBUaGUgdmFsdWUgaW4gdGhlIFNlcnZl ciBPY3RldHMgZmllbGQgZXF1YWxzIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICBJZiBiZWluZyB1c2VkLCB0aGUgU2VydmVyIE9j dGV0cyBmaWVsZDwvc3Bhbj4gTVVTVCBmb2xsb3cgdGhlIDI3IG9jdGV0czwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAg bG9uZyBNQlogZmllbGQuICBUaGUgdmFsdWUgaW4gdGhlIFNlcnZlciBPY3RldHMgZmllbGQgZXF1 YWxzIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgbnVtYmVyIG9mIG9jdGV0 cyB0aGUgU2Vzc2lvbi1SZWZsZWN0b3IgaXMgZXhwZWN0ZWQgdG8gY29weSBiYWNrIHRvPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgbnVtYmVyIG9mIG9jdGV0cyB0aGUgU2Vz c2lvbi1SZWZsZWN0b3IgaXMgZXhwZWN0ZWQgdG8gY29weSBiYWNrIHRvPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgICB0aGUgU2Vzc2lvbi1TZW5kZXIgc3RhcnRpbmcgd2l0aCB0aGUg U2VydmVyIE9jdGV0cyBmaWVsZC4gIFRodXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgICB0aGUgU2Vzc2lvbi1TZW5kZXIgc3RhcnRpbmcgd2l0aCB0aGUgU2VydmVyIE9jdGV0 cyBmaWVsZC4gIFRodXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 ciBpZD0iZGlmZjAwMTciPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgdGhlIG1pbmltPHNwYW4gY2xhc3M9ImRl bGV0ZSI+YWw8L3NwYW4+IG5vbi16ZXJvIHZhbHVlIGZvciB0aGUgU2VydmVyIE9jdGV0cyBmaWVs ZCBpcyB0d28uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgIHRoZSBtaW5p bTxzcGFuIGNsYXNzPSJpbnNlcnQiPnVtPC9zcGFuPiBub24temVybyB2YWx1ZSBmb3IgdGhlIFNl cnZlciBPY3RldHMgZmllbGQgaXMgdHdvLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICAgVGhlcmVmb3JlLCB0aGUgdmFsdWUgb2Ygb25lIGlzIGludmFsaWQuICBJZiBub25lIG9mIFBh eWxvYWQgdG8gYmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBUaGVyZWZv cmUsIHRoZSB2YWx1ZSBvZiBvbmUgaXMgaW52YWxpZC4gIElmIG5vbmUgb2YgUGF5bG9hZCB0byBi ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgY29waWVkLCB0aGUgdmFsdWUgb2Yg dGhlIFNlcnZlciBPY3RldHMgZmllbGQgTVVTVCBiZSBzZXQgdG8gemVybzwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIGNvcGllZCwgdGhlIHZhbHVlIG9mIHRoZSBTZXJ2ZXIg T2N0ZXRzIGZpZWxkIE1VU1QgYmUgc2V0IHRvIHplcm88L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgICAgIG9uIHRyYW5zbWl0LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg ICAgIG9uIHRyYW5zbWl0LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBvICBS ZW1haW5pbmcgUGFja2V0IFBhZGRpbmcgaXMgYW4gb3B0aW9uYWwgZmllbGQgb2YgdmFyaWFibGUg bGVuZ3RoLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG8gIFJlbWFpbmluZyBQ YWNrZXQgUGFkZGluZyBpcyBhbiBvcHRpb25hbCBmaWVsZCBvZiB2YXJpYWJsZSBsZW5ndGguPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBUaGUgbnVtYmVyIG9mIG9jdGV0cyBpbiB0 aGUgUmVtYWluaW5nIFBhY2tldCBQYWRkaW5nIGZpZWxkIGlzIHRoZTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgICAgIFRoZSBudW1iZXIgb2Ygb2N0ZXRzIGluIHRoZSBSZW1haW5p bmcgUGFja2V0IFBhZGRpbmcgZmllbGQgaXMgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDE4Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgIHZhbHVlIG9m IHRoZSBTZXJ2ZXIgT2N0ZXRzIGZpZWxkIDxzcGFuIGNsYXNzPSJkZWxldGUiPmxlczwvc3Bhbj5z IHRoZSBsZW5ndGggb2YgdGhlIFNlcnZlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICAgICB2YWx1ZSBvZiB0aGUgU2VydmVyIE9jdGV0cyBmaWVsZCA8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij5taW51PC9zcGFuPnMgdGhlIGxlbmd0aCBvZiB0aGUgU2VydmVyPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgICBPY3RldHMgZmllbGQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgICAgT2N0ZXRzIGZpZWxkLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDE5Ij48dGQ+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxzcGFuIGNs YXNzPSJkZWxldGUiPm8gIENvbXAuTUJaIGlzIHZhcmlhYmxlIGxlbmd0aCBmaWVsZCB1c2VkIHRv IGFjaGlldmUgYWxpZ25tZW50IG9uIGE8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRl Ij4gICAgICB3b3JkIGJvdW5kYXJ5LiAgVGh1cyB0aGUgbGVuZ3RoIG9mIENvbXAuTUJaIGZpZWxk IG1heSBiZSBvbmx5IDAsPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAg MSwgMiBvciAzIG9jdGV0cy4gIFRoZSB2YWx1ZSBvZiB0aGUgZmllbGQgTVVTVCBiZSB6ZXJvZWQg b248L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICAgICB0cmFuc21pc3Npb24g YW5kIGlnbm9yZWQgb24gcmVjZWlwdC48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+NC4xLjIuICBTZXNzaW9uLVNlbmRlciBQYWNrZXQgRm9ybWF0IGluIEF1dGhlbnRpY2F0ZWQg TW9kZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjQuMS4yLiAgU2Vzc2lvbi1TZW5k ZXIgUGFja2V0IEZvcm1hdCBpbiBBdXRoZW50aWNhdGVkIE1vZGU8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAyMCI+PHRkPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5Gb3I8L3NwYW4+IGF1dGhlbnRpY2F0ZWQgbW9kZTo8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+U1RB TVAgU2Vzc2lvbi1TZW5kZXIgcGFja2V0IGZvcm1hdCBpbjwvc3Bhbj4gYXV0aGVudGljYXRlZCBt b2RlOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDAgICAgICAgICAgICAg ICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDM8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAg ICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMg NCA1IDYgNyA4IDkgMCAxPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAwIDEg MiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAw IDE8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgIHwgICAgICAgICAgICAgICAgICAgICAgU2VxdWVuY2UgTnVtYmVyICAgICAgICAgICAg ICAgICAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgIHwgICAg ICAgICAgICAgICAgICAgICAgU2VxdWVuY2UgTnVtYmVyICAgICAgICAgICAgICAgICAgICAgICAg ICB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgIHwgICAgICAgICAgICAgICAgICAg ICAgTUJaICgxMiBvY3RldHMpICAgICAgICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgIHwgICAgICAgICAgICAgICAgICAgICAgTUJaICgxMiBv Y3RldHMpICAgICAgICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICArLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBUaW1lc3RhbXAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICBUaW1lc3RhbXAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHw8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgIHwgICAgICAgIEVycm9yIEVz dGltYXRlICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgIHwgICAgICAgIEVycm9yIEVzdGltYXRlICAgICAg ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICB+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICB+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgTUJaICg3MCBvY3RldHMpICAg ICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgTUJaICg3MCBvY3RldHMpICAgICAgICAgICAgICAg ICAgICAgICB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgfiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgfiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg ICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlk PSJkaWZmMDAyMSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+fCAgICAgICAg ICAgICBUeXBlICAgICAgICAgICAgICB8ICAgICAgICAgICBMZW5ndGggICAgICAgICAgICAgIHw8 L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3NwYW4+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICAgfiAgICAgICAgICAgICAgICAgICAgICAgICAg ICBWYWx1ZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIH48L3NwYW4+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3Bh biBjbGFzcz0iZGVsZXRlIj4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0i ZGVsZXRlIj4gICAgfiAgICAgICAgICAgICAgICAgICAgICAgICAgIENvbXAuTUJaICAgICAgICAg ICAgICAgICAgICAgICAgICAgIH48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4g ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSs8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAg fCAgICAgICAgICAgICAgICAgICAgICAgSE1BQyAoMTYgb2N0ZXRzKSAgICAgICAgICAgICAgICAg ICAgICAgIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgfCAgICAgICAgICAg ICAgICAgICAgICAgSE1BQyAoMTYgb2N0ZXRzKSAgICAgICAgICAgICAgICAgICAgICAgIHw8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgIEZpZ3VyZSA0OiBTVEFNUCBTZXNzaW9uLVNlbmRlciB0ZXN0IHBhY2tldCBmb3JtYXQg aW4gYXV0aGVudGljYXRlZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICBGaWd1 cmUgNDogU1RBTVAgU2Vzc2lvbi1TZW5kZXIgdGVzdCBwYWNrZXQgZm9ybWF0IGluIGF1dGhlbnRp Y2F0ZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgbW9kZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgbW9kZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBUaGUgZmllbGQgZGVmaW5pdGlvbnMgYXJlIHRoZSBzYW1lIGFzIHRoZSB1bmF1 dGhlbnRpY2F0ZWQgbW9kZSw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUg ZmllbGQgZGVmaW5pdGlvbnMgYXJlIHRoZSBzYW1lIGFzIHRoZSB1bmF1dGhlbnRpY2F0ZWQgbW9k ZSw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAw MjIiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+ICAgbGlzdGVkIGluIFNlY3Rpb24gNC4xLjEuICBBbHNvLCBDb21wLk1C WiBmaWVsZCBpcyB2YXJpYWJsZSBsZW5ndGg8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgbGlzdGVkIGluIFNlY3Rpb24gNC4xLjEuICBBbHNvLCBDb21wLk1CWiBmaWVsZCBpcyA8 c3BhbiBjbGFzcz0iaW5zZXJ0Ij5hIDwvc3Bhbj52YXJpYWJsZSBsZW5ndGg8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIGZpZWxkIHRvIGFsaWduIHRoZSBwYWNrZXQgb24gMTYgb2N0ZXRz IGJvdW5kYXJ5LiAgQWxzbywgdGhlIHBhY2tldDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIGZpZWxkIHRvIGFsaWduIHRoZSBwYWNrZXQgb24gMTYgb2N0ZXRzIGJvdW5kYXJ5LiAg QWxzbywgdGhlIHBhY2tldDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaW5jbHVkZXMg YSBrZXktaGFzaGVkIG1lc3NhZ2UgYXV0aGVudGljYXRpb24gY29kZSAoSE1BQykgKFtSRkMyMTA0 XSk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBpbmNsdWRlcyBhIGtleS1oYXNo ZWQgbWVzc2FnZSBhdXRoZW50aWNhdGlvbiBjb2RlIChITUFDKSAoW1JGQzIxMDRdKTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAyMyI+PHRkPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj4gICBoYXNoIGF0IHRoZSBlbmQgb2YgdGhlIFBEVS48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgaGFzaCBhdCB0aGUgZW5kIG9mIHRoZSBQRFUuICA8c3BhbiBjbGFzcz0i aW5zZXJ0Ij5UaGUgZGV0YWlsZWQgdXNlIG9mIHRoZSBITUFDIGZpZWxkIGlzPC9zcGFuPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC4zLjwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+NC4yLiAgU2Vzc2lvbi1SZWZsZWN0 b3IgQmVoYXZpb3IgYW5kIFBhY2tldCBGb3JtYXQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij40LjIuICBTZXNzaW9uLVJlZmxlY3RvciBCZWhhdmlvciBhbmQgUGFja2V0IEZvcm1hdDwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUgU2Vzc2lvbi1SZWZsZWN0b3Ig cmVjZWl2ZXMgdGhlIFNUQU1QIHRlc3QgcGFja2V0LCB2ZXJpZmllcyBpdCw8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBUaGUgU2Vzc2lvbi1SZWZsZWN0b3IgcmVjZWl2ZXMgdGhl IFNUQU1QIHRlc3QgcGFja2V0LCB2ZXJpZmllcyBpdCw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIHByZXBhcmVzIGFuZCB0cmFuc21pdHMgdGhlIHJlZmxlY3RlZCB0ZXN0IHBhY2tldC48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBwcmVwYXJlcyBhbmQgdHJhbnNtaXRz IHRoZSByZWZsZWN0ZWQgdGVzdCBwYWNrZXQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIFR3byBtb2RlcyBvZiBTVEFNUCBTZXNzaW9uLVJlZmxlY3RvciBjaGFyYWN0ZXJpemUg dGhlIGV4cGVjdGVkPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVHdvIG1vZGVz IG9mIFNUQU1QIFNlc3Npb24tUmVmbGVjdG9yIGNoYXJhY3Rlcml6ZSB0aGUgZXhwZWN0ZWQ8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGJlaGF2aW9yIGFuZCwgY29uc2VxdWVudGx5LCBw ZXJmb3JtYW5jZSBtZXRyaWNzIHRoYXQgY2FuIGJlIG1lYXN1cmVkOjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIGJlaGF2aW9yIGFuZCwgY29uc2VxdWVudGx5LCBwZXJmb3JtYW5j ZSBtZXRyaWNzIHRoYXQgY2FuIGJlIG1lYXN1cmVkOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBvICBTdGF0ZWxlc3MgLSBTVEFNUCBTZXNzaW9uLVJlZmxlY3RvciBkb2VzIG5v dCBtYWludGFpbiB0ZXN0IHN0YXRlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg byAgU3RhdGVsZXNzIC0gU1RBTVAgU2Vzc2lvbi1SZWZsZWN0b3IgZG9lcyBub3QgbWFpbnRhaW4g dGVzdCBzdGF0ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHIgaWQ9InBhcnQtOCIgY2xhc3M9ImNoYW5nZSI+PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lwcGlu ZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9yZmNk aWZmL3JmY2RpZmYucHlodCNwYXJ0LTgiPjxlbT4gcGFnZSA5LCBsaW5lIDMwPHNwYW4gY2xhc3M9 ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNtYWxsPnNraXBw aW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93d3c2LmlldGYub3JnL3Jm Y2RpZmYvcmZjZGlmZi5weWh0I3BhcnQtOCI+PGVtPiBwYWdlIDgsIGxpbmUgNDQ8c3BhbiBjbGFz cz0iaGlkZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgIHwgICAgICAgICAg ICAgICAgICBTZXNzaW9uLVNlbmRlciBUaW1lc3RhbXAgICAgICAgICAgICAgICAgICAgICB8PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgIHwgICAgICAgICAgICAgICAgICBTZXNz aW9uLVNlbmRlciBUaW1lc3RhbXAgICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgIHwgU2Vzc2lvbi1TZW5kZXIgRXJyb3IgRXN0aW1hdGUgfCAgICAg ICAgICAgTUJaICAgICAgICAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgIHwgU2Vzc2lvbi1TZW5kZXIgRXJyb3IgRXN0aW1hdGUgfCAgICAgICAgICAgTUJaICAg ICAgICAgICAgICAgICB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgICB8U2VzLVNlbmRlciBUVEwgfCAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgICB8U2VzLVNlbmRlciBUVEwgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICstKy0rLSst Ky0rLSstKy0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAr PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICstKy0rLSstKy0rLSstKy0rICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICB+ICAgICAg ICAgICAgICAgIFBhY2tldCBQYWRkaW5nIChyZWZsZWN0ZWQpICAgICAgICAgICAgICAgICAgICAg fjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICB+ICAgICAgICAgICAgICAgIFBh Y2tldCBQYWRkaW5nIChyZWZsZWN0ZWQpICAgICAgICAgICAgICAgICAgICAgfjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICstKy0rLSstKy0rLSstKy0rPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHIgaWQ9ImRpZmYwMDI0Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPkNvbXAu TUJaICAgfDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgIHwgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHw8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC9zcGFu PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgPHNwYW4gY2xhc3M9Imluc2Vy dCI+Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAg IHwgICAgICAgICAgICAgVHlwZSAgICAgICAgICAgICAgfCAgICAgICAgICAgTGVuZ3RoICAgICAg ICAgICAgICB8PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgIH4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgVmFsdWUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB+PC9zcGFuPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC9zcGFuPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgICAgIEZpZ3VyZSA1OiBTVEFNUCBTZXNzaW9uLVJlZmxlY3RvciB0ZXN0IHBhY2tldCBm b3JtYXQgaW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgRmlndXJl IDU6IFNUQU1QIFNlc3Npb24tUmVmbGVjdG9yIHRlc3QgcGFja2V0IGZvcm1hdCBpbjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgdW5hdXRoZW50 aWNhdGVkIG1vZGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAg ICAgICAgICAgICAgICB1bmF1dGhlbnRpY2F0ZWQgbW9kZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICB3aGVyZSBmaWVsZHMgYXJlIGRlZmluZWQgYXMgdGhlIGZvbGxvd2luZzo8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB3aGVyZSBmaWVsZHMgYXJlIGRlZmlu ZWQgYXMgdGhlIGZvbGxvd2luZzo8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg byAgU2VxdWVuY2UgTnVtYmVyIGlzIGZvdXIgb2N0ZXRzIGxvbmcgZmllbGQuICBUaGUgdmFsdWUg b2YgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbyAgU2VxdWVuY2UgTnVt YmVyIGlzIGZvdXIgb2N0ZXRzIGxvbmcgZmllbGQuICBUaGUgdmFsdWUgb2YgdGhlPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBTZXF1ZW5jZSBOdW1iZXIgZmllbGQgaXMgc2V0IGFj Y29yZGluZyB0byB0aGUgbW9kZSBvZiB0aGUgU1RBTVA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgICBTZXF1ZW5jZSBOdW1iZXIgZmllbGQgaXMgc2V0IGFjY29yZGluZyB0byB0 aGUgbW9kZSBvZiB0aGUgU1RBTVA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIFNl c3Npb24tUmVmbGVjdG9yOjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIFNl c3Npb24tUmVmbGVjdG9yOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0ciBpZD0icGFydC05IiBjbGFzcz0iY2hhbmdlIj48dGQ+PC90ZD48dGg+PHNt YWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93d3c2Lmll dGYub3JnL3JmY2RpZmYvcmZjZGlmZi5weWh0I3BhcnQtOSI+PGVtPiBwYWdlIDEwLCBsaW5lIDE3 PHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+ PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93d3c2 LmlldGYub3JnL3JmY2RpZmYvcmZjZGlmZi5weWh0I3BhcnQtOSI+PGVtPiBwYWdlIDksIGxpbmUg Mjg8c3BhbiBjbGFzcz0iaGlkZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAg ICAgWiBmbGFnIG9mIHRoZSBFcnJvciBFc3RpbWF0ZSBmaWVsZCBhcyBkZXNjcmliZWQgaW4gU2Vj dGlvbiA0LjEuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgWiBmbGFnIG9m IHRoZSBFcnJvciBFc3RpbWF0ZSBmaWVsZCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LjEuPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG8gIEVycm9yIEVzdGltYXRlIGhhcyB0 aGUgc2FtZSBzaXplIGFuZCBpbnRlcnByZXRhdGlvbiBhcyBkZXNjcmliZWQ8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBvICBFcnJvciBFc3RpbWF0ZSBoYXMgdGhlIHNhbWUgc2l6 ZSBhbmQgaW50ZXJwcmV0YXRpb24gYXMgZGVzY3JpYmVkPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAgICBpbiBTZWN0aW9uIDQuMS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgICBpbiBTZWN0aW9uIDQuMS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgbyAgU2Vzc2lvbi1TZW5kZXIgU2VxdWVuY2UgTnVtYmVyLCBTZXNzaW9uLVNlbmRlciBUaW1l c3RhbXAsIGFuZDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG8gIFNlc3Npb24t U2VuZGVyIFNlcXVlbmNlIE51bWJlciwgU2Vzc2lvbi1TZW5kZXIgVGltZXN0YW1wLCBhbmQ8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIFNlc3Npb24tU2VuZGVyIEVycm9yIEVzdGlt YXRlIGFyZSBjb3BpZXMgb2YgdGhlIGNvcnJlc3BvbmRpbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAgICBTZXNzaW9uLVNlbmRlciBFcnJvciBFc3RpbWF0ZSBhcmUgY29waWVz IG9mIHRoZSBjb3JyZXNwb25kaW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBm aWVsZHMgaW4gdGhlIFNUQU1QIHRlc3QgcGFja2V0IHNlbnQgYnkgdGhlIFNlc3Npb24tU2VuZGVy LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIGZpZWxkcyBpbiB0aGUgU1RB TVAgdGVzdCBwYWNrZXQgc2VudCBieSB0aGUgU2Vzc2lvbi1TZW5kZXIuPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG8gIFNlc3Npb24tU2VuZGVyIFRUTCBpcyBvbmUgb2N0ZXQg bG9uZyBmaWVsZCwgYW5kIGl0cyB2YWx1ZSBpcyB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBvICBTZXNzaW9uLVNlbmRlciBUVEwgaXMgb25lIG9jdGV0IGxvbmcgZmllbGQs IGFuZCBpdHMgdmFsdWUgaXMgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHIgaWQ9ImRpZmYwMDI1Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgIGNvcHkgb2YgdGhlIFRUTCBm aWVsZCBmcm9tIHRoZSByZWNlaXZlZCBTVEFNUCB0ZXN0IHBhY2tldC48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+ICAgICAgY29weSBvZiB0aGUgVFRMIGZpZWxkIDxzcGFuIGNsYXNz PSJpbnNlcnQiPmluIElQdjQgKG9yIEhvcCBMaW1pdCBpbiBJUHY2KTwvc3Bhbj4gZnJvbSB0aGU8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgICAgIHJlY2VpdmVkIFNUQU1QIHRlc3QgcGFja2V0LjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBvICBQYWNrZXQgUGFkZGluZyAocmVmbGVjdGVkKSBpcyBhbiBv cHRpb25hbCB2YXJpYWJsZSBsZW5ndGggZmllbGQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgbyAgUGFja2V0IFBhZGRpbmcgKHJlZmxlY3RlZCkgaXMgYW4gb3B0aW9uYWwgdmFy aWFibGUgbGVuZ3RoIGZpZWxkLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgVGhl IGxlbmd0aCBvZiB0aGUgUGFja2V0IFBhZGRpbmcgKHJlZmxlY3RlZCkgZmllbGQgTVVTVCBiZSBl cXVhbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIFRoZSBsZW5ndGggb2Yg dGhlIFBhY2tldCBQYWRkaW5nIChyZWZsZWN0ZWQpIGZpZWxkIE1VU1QgYmUgZXF1YWw8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHRvIHRoZSB2YWx1ZSBvZiB0aGUgU2VydmVyIE9j dGV0cyBmaWVsZCAoRmlndXJlIDIpLiAgSWYgdGhlIHZhbHVlPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgICAgdG8gdGhlIHZhbHVlIG9mIHRoZSBTZXJ2ZXIgT2N0ZXRzIGZpZWxk IChGaWd1cmUgMikuICBJZiB0aGUgdmFsdWU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgIGlzIG5vbi16ZXJvLCB0aGUgU2Vzc2lvbi1SZWZsZWN0b3IgTVVTVCBjb3B5IG51bWJlciBv ZiBvY3RldHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBpcyBub24temVy bywgdGhlIFNlc3Npb24tUmVmbGVjdG9yIE1VU1QgY29weSBudW1iZXIgb2Ygb2N0ZXRzPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBlcXVhbCB0byB0aGUgdmFsdWUgb2YgU2VydmVy IE9jdGV0cyBmaWVsZCBzdGFydGluZyB3aXRoIHRoZSBTZXJ2ZXI8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAgICBlcXVhbCB0byB0aGUgdmFsdWUgb2YgU2VydmVyIE9jdGV0cyBm aWVsZCBzdGFydGluZyB3aXRoIHRoZSBTZXJ2ZXI8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgIE9jdGV0cyBmaWVsZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg ICBPY3RldHMgZmllbGQuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0ciBpZD0iZGlmZjAwMjYiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgbyAgQ29tcC5NQlogaXMgdmFyaWFi bGUgbGVuZ3RoIGZpZWxkIHVzZWQgdG8gYWNoaWV2ZSBhbGlnbm1lbnQgb24gYTwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBvICBDb21wLk1CWiBpcyA8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij5hIDwvc3Bhbj52YXJpYWJsZSBsZW5ndGggZmllbGQgdXNlZCB0byBhY2hpZXZlIGFsaWdu bWVudCBvbiBhPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICB3b3JkIGJvdW5kYXJ5 LiAgVGh1cyB0aGUgbGVuZ3RoIG9mIENvbXAuTUJaIGZpZWxkIG1heSBiZSBvbmx5IDAsPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgd29yZCBib3VuZGFyeS4gIFRodXMgdGhl IGxlbmd0aCBvZiBDb21wLk1CWiBmaWVsZCBtYXkgYmUgb25seSAwLDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgMSwgMiBvciAzIG9jdGV0cy4gIFRoZSB2YWx1ZSBvZiB0aGUgZmll bGQgTVVTVCBiZSB6ZXJvZWQgb248L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg ICAxLCAyIG9yIDMgb2N0ZXRzLiAgVGhlIHZhbHVlIG9mIHRoZSBmaWVsZCBNVVNUIGJlIHplcm9l ZCBvbjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgdHJhbnNtaXNzaW9uIGFuZCBp Z25vcmVkIG9uIHJlY2VpcHQuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg dHJhbnNtaXNzaW9uIGFuZCBpZ25vcmVkIG9uIHJlY2VpcHQuPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjQuMi4yLiAgU2Vzc2lvbi1SZWZsZWN0b3IgUGFja2V0IEZvcm1hdCBpbiBB dXRoZW50aWNhdGVkIE1vZGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij40LjIuMi4g IFNlc3Npb24tUmVmbGVjdG9yIFBhY2tldCBGb3JtYXQgaW4gQXV0aGVudGljYXRlZCBNb2RlPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEZvciB0aGUgYXV0aGVudGljYXRlZCBt b2RlOjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEZvciB0aGUgYXV0aGVudGlj YXRlZCBtb2RlOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAwICAgICAg ICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgMCAgICAgICAgICAgICAgICAgICAx ICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMzwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0ciBpZD0icGFydC0xMCIgY2xhc3M9ImNoYW5nZSI+PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lw cGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9y ZmNkaWZmL3JmY2RpZmYucHlodCNwYXJ0LTEwIj48ZW0+IHBhZ2UgMTEsIGxpbmUgMjc8c3BhbiBj bGFzcz0iaGlkZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48c21hbGw+ c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3dzYuaWV0Zi5v cmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQjcGFydC0xMCI+PGVtPiBwYWdlIDEwLCBsaW5lIDM5PHNw YW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHwg U2Vzc2lvbi1TZW5kZXIgRXJyb3IgRXN0aW1hdGUgfCAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgfCBTZXNzaW9uLVNl bmRlciBFcnJvciBFc3RpbWF0ZSB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHw8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICBNQlogKDYgb2N0ZXRzKSAgICAgICAgICAg ICAgICAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgfCAg ICAgICAgICAgICAgICAgICAgICAgIE1CWiAoNiBvY3RldHMpICAgICAgICAgICAgICAgICAgICAg ICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICAgIHxTZXMtU2VuZGVyIFRUTCB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgfFNlcy1TZW5kZXIgVFRMIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICstKy0rLSst Ky0rLSstKy0rICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAr PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgKy0rLSstKy0rLSstKy0rLSsg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICs8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICBNQlogKDE1IG9jdGV0cykgICAgICAgICAgICAgICAg ICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgfCAgICAgICAg ICAgICAgICAgICAgICAgIE1CWiAoMTUgb2N0ZXRzKSAgICAgICAgICAgICAgICAgICAgICAgIHw8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0i ZGlmZjAwMjciPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+fCAgICAgICAg ICAgICBUeXBlICAgICAgICAgICAgICB8ICAgICAgICAgICBMZW5ndGggICAgICAgICAgICAgIHw8 L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICAgICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvc3Bhbj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgIH4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgVmFsdWUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB+PC9zcGFuPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBj bGFzcz0iZGVsZXRlIj4gICAgICB+ICAgICAgICAgICAgICAgICAgICAgICAgICAgQ29tcC5NQlog ICAgICAgICAgICAgICAgICAgICAgICAgICAgfjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJk ZWxldGUiPiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJs b2NrIj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHwgICAgICAgICAgICAgICAg ICAgICAgICBITUFDICgxNiBvY3RldHMpICAgICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgIEhN QUMgKDE2IG9jdGV0cykgICAgICAgICAgICAgICAgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHw8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgRmlndXJlIDY6IFNUQU1QIFNlc3Np b24tUmVmbGVjdG9yIHRlc3QgcGFja2V0IGZvcm1hdCBpbiBhdXRoZW50aWNhdGVkPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRmlndXJlIDY6IFNUQU1QIFNlc3Npb24tUmVmbGVj dG9yIHRlc3QgcGFja2V0IGZvcm1hdCBpbiBhdXRoZW50aWNhdGVkPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vZGU8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIG1vZGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIGZpZWxkIGRl ZmluaXRpb25zIGFyZSB0aGUgc2FtZSBhcyB0aGUgdW5hdXRoZW50aWNhdGVkIG1vZGUsPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIGZpZWxkIGRlZmluaXRpb25zIGFyZSB0 aGUgc2FtZSBhcyB0aGUgdW5hdXRoZW50aWNhdGVkIG1vZGUsPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBsaXN0ZWQgaW4gU2VjdGlvbiA0LjIuMS4gIEFkZGl0aW9uYWxseSwgdGhlIHBh Y2tldCBNQVkgaW5jbHVkZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGxpc3Rl ZCBpbiBTZWN0aW9uIDQuMi4xLiAgQWRkaXRpb25hbGx5LCB0aGUgcGFja2V0IE1BWSBpbmNsdWRl PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDI4 Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgIENvbXAuTUJaIGZpZWxkIGlzIHZhcmlhYmxlIGxlbmd0aCBmaWVsZCB0 byBhbGlnbiB0aGUgcGFja2V0IG9uIDE2PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PiAgIENvbXAuTUJaIGZpZWxkIGlzIDxzcGFuIGNsYXNzPSJpbnNlcnQiPmEgPC9zcGFuPnZhcmlh YmxlIGxlbmd0aCBmaWVsZCB0byBhbGlnbiB0aGUgcGFja2V0IG9uIDE2PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBvY3RldHMgYm91bmRhcnkuICBBbHNvLCBTVEFNUCBTZXNzaW9uLVJl ZmxlY3RvciB0ZXN0IHBhY2tldCBmb3JtYXQgaW48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBvY3RldHMgYm91bmRhcnkuICBBbHNvLCBTVEFNUCBTZXNzaW9uLVJlZmxlY3RvciB0 ZXN0IHBhY2tldCBmb3JtYXQgaW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGF1dGhl bnRpY2F0ZWQgbW9kZSBpbmNsdWRlcyBhIGtleSAoSE1BQykgKFtSRkMyMTA0XSkgaGFzaCBhdCB0 aGUgZW5kPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYXV0aGVudGljYXRlZCBt b2RlIGluY2x1ZGVzIGEga2V5IChITUFDKSAoW1JGQzIxMDRdKSBoYXNoIGF0IHRoZSBlbmQ8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMjkiPjx0 ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+ICAgb2YgdGhlIFBEVS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgb2YgdGhlIFBEVS48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gIFRoZSBkZXRhaWxlZCB1c2Ugb2Yg dGhlIEhNQUMgZmllbGQgaXMgaW4gU2VjdGlvbiA0LjMuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij40LjMuICBJbnRlZ3JpdHkgYW5kIENvbmZpZGVudGlhbGl0eSBQcm90 ZWN0aW9uIGluIFNUQU1QPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+NC4zLiAgSW50 ZWdyaXR5IGFuZCBDb25maWRlbnRpYWxpdHkgUHJvdGVjdGlvbiBpbiBTVEFNUDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUbyBwcm92aWRlIGludGVncml0eSBwcm90ZWN0aW9u LCBlYWNoIFNUQU1QIG1lc3NhZ2UgaXMgYmVpbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBUbyBwcm92aWRlIGludGVncml0eSBwcm90ZWN0aW9uLCBlYWNoIFNUQU1QIG1lc3Nh Z2UgaXMgYmVpbmc8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGF1dGhlbnRpY2F0ZWQg YnkgYWRkaW5nIEhhc2hlZCBNZXNzYWdlIEF1dGhlbnRpY2F0aW9uIENvZGUgKEhNQUMpLjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGF1dGhlbnRpY2F0ZWQgYnkgYWRkaW5nIEhh c2hlZCBNZXNzYWdlIEF1dGhlbnRpY2F0aW9uIENvZGUgKEhNQUMpLjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgU1RBTVAgdXNlcyBITUFDLVNIQS0yNTYgdHJ1bmNhdGVkIHRvIDEyOCBi aXRzIChzaW1pbGFybHkgdG8gdGhlIHVzZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIFNUQU1QIHVzZXMgSE1BQy1TSEEtMjU2IHRydW5jYXRlZCB0byAxMjggYml0cyAoc2ltaWxh cmx5IHRvIHRoZSB1c2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG9mIGl0IGluIElQ U2VjIGRlZmluZWQgaW4gW1JGQzQ4NjhdKTsgaGVuY2UgdGhlIGxlbmd0aCBvZiB0aGUgSE1BQzwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG9mIGl0IGluIElQU2VjIGRlZmluZWQg aW4gW1JGQzQ4NjhdKTsgaGVuY2UgdGhlIGxlbmd0aCBvZiB0aGUgSE1BQzwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgZmllbGQgaXMgMTYgb2N0ZXRzLiAgSE1BQyB1c2VzIG93biBrZXkg YW5kIHRoZSBkZWZpbml0aW9uIG9mIHRoZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIGZpZWxkIGlzIDE2IG9jdGV0cy4gIEhNQUMgdXNlcyBvd24ga2V5IGFuZCB0aGUgZGVmaW5p dGlvbiBvZiB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG1lY2hhbmlzbSB0byBk aXN0cmlidXRlIHRoZSBITUFDIGtleSBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbWVjaGFuaXNtIHRvIGRpc3RyaWJ1dGUgdGhl IEhNQUMga2V5IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXM8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIHNwZWNpZmljYXRpb24uICBPbmUgZXhhbXBsZSBpcyB0byB1c2UgYW4gb3Jj aGVzdHJhdG9yIHRvIGNvbmZpZ3VyZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IHNwZWNpZmljYXRpb24uICBPbmUgZXhhbXBsZSBpcyB0byB1c2UgYW4gb3JjaGVzdHJhdG9yIHRv IGNvbmZpZ3VyZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSE1BQyBrZXkgYmFzZWQg b24gU1RBTVAgWUFORyBkYXRhIG1vZGVsIFtJLUQuaWV0Zi1pcHBtLXN0YW1wLXlhbmddLjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEhNQUMga2V5IGJhc2VkIG9uIFNUQU1QIFlB TkcgZGF0YSBtb2RlbCBbSS1ELmlldGYtaXBwbS1zdGFtcC15YW5nXS48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIEhNQUMgTVVTVCBiZSB2ZXJpZmllZCBhcyBlYXJseSBhcyBwb3NzaWJs ZSB0byBhdm9pZCB1c2luZyBvcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEhN QUMgTVVTVCBiZSB2ZXJpZmllZCBhcyBlYXJseSBhcyBwb3NzaWJsZSB0byBhdm9pZCB1c2luZyBv cjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcHJvcGFnYXRpbmcgY29ycnVwdGVkIGRh dGEuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcHJvcGFnYXRpbmcgY29ycnVw dGVkIGRhdGEuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIElmIGNvbmZpZGVu dGlhbGl0eSBwcm90ZWN0aW9uIGZvciBTVEFNUCBpcyByZXF1aXJlZCwgZW5jcnlwdGlvbiBhdDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIElmIGNvbmZpZGVudGlhbGl0eSBwcm90 ZWN0aW9uIGZvciBTVEFNUCBpcyByZXF1aXJlZCwgZW5jcnlwdGlvbiBhdDwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAzMCI+PHRkPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICB0aGUgaGlnaGVyIGxldmVsIE1VU1QgYmUgdXNlZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgdGhlIGhpZ2hlciBsZXZlbCBNVVNUIGJlIHVzZWQuICA8c3BhbiBjbGFzcz0i aW5zZXJ0Ij5Gb3IgZXhhbXBsZSwgU1RBTVAgcGFja2V0cyBjb3VsZCBiZTwvc3Bhbj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2si PjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIHRyYW5zbWl0dGVkIGluIHRoZSBkZWRpY2F0ZWQgSVBz ZWMgdHVubmVsIG9yIHNoYXJlIHRoZSBJUHNlYyB0dW5uZWw8L3NwYW4+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBj bGFzcz0iaW5zZXJ0Ij4gICB3aXRoIHRoZSBtb25pdG9yZWQgZmxvdy48L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjQuNC4gIEludGVyb3BlcmFiaWxpdHkgd2l0aCBUV0FN UCBMaWdodDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjQuNC4gIEludGVyb3BlcmFi aWxpdHkgd2l0aCBUV0FNUCBMaWdodDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBPbmUgb2YgdGhlIGVzc2VudGlhbCByZXF1aXJlbWVudHMgdG8gU1RBTVAgaXMgdGhlIGFiaWxp dHkgdG88L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBPbmUgb2YgdGhlIGVzc2Vu dGlhbCByZXF1aXJlbWVudHMgdG8gU1RBTVAgaXMgdGhlIGFiaWxpdHkgdG88L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMzEiPjx0ZD48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgaW50ZXJ3b3JrIHdpdGggVFdBTVAgTGlnaHQgZGV2aWNlLiAgVGhlcmUgYXJlIHR3byBwb3Nz aWJsZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBpbnRlcndvcmsgd2l0aCA8 c3BhbiBjbGFzcz0iaW5zZXJ0Ij5hIDwvc3Bhbj5UV0FNUCBMaWdodCBkZXZpY2UuICBUaGVyZSBh cmUgdHdvIHBvc3NpYmxlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBjb21iaW5hdGlv bnMgZm9yIHN1Y2ggdXNlIGNhc2U6PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg Y29tYmluYXRpb25zIGZvciBzdWNoIHVzZSBjYXNlOjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBvICBTVEFNUCBTZXNzaW9uLVNlbmRlciB3aXRoIFRXQU1QIExpZ2h0IFNlc3Np b24tUmVmbGVjdG9yOzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG8gIFNUQU1Q IFNlc3Npb24tU2VuZGVyIHdpdGggVFdBTVAgTGlnaHQgU2Vzc2lvbi1SZWZsZWN0b3I7PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG8gIFRXQU1QIExpZ2h0IFNlc3Npb24tU2Vu ZGVyIHdpdGggU1RBTVAgU2Vzc2lvbi1SZWZsZWN0b3IuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgbyAgVFdBTVAgTGlnaHQgU2Vzc2lvbi1TZW5kZXIgd2l0aCBTVEFNUCBTZXNz aW9uLVJlZmxlY3Rvci48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyIGlkPSJkaWZmMDAzMiI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBJbiB0aGUgZm9ybWVyIGNhc2UsIFNl c3Npb24tU2VuZGVyIE1BWSBub3QgYmUgYXdhcmUgdGhhdCBpdHMgPHNwYW4gY2xhc3M9ImRlbGV0 ZSI+U2Vzc2lvbi08L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIElu IHRoZSBmb3JtZXIgY2FzZSwgPHNwYW4gY2xhc3M9Imluc2VydCI+dGhlPC9zcGFuPiBTZXNzaW9u LVNlbmRlciBNQVkgbm90IGJlIGF3YXJlIHRoYXQgaXRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIFJlZmxlY3Rvcjwvc3Bhbj4gZG9lcyBub3Qg c3VwcG9ydCBTVEFNUC4gIEZvciBleGFtcGxlLCBUV0FNUCBMaWdodCA8c3BhbiBjbGFzcz0iZGVs ZXRlIj5TZXNzaW9uLTwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg PHNwYW4gY2xhc3M9Imluc2VydCI+U2Vzc2lvbi1SZWZsZWN0b3I8L3NwYW4+IGRvZXMgbm90IHN1 cHBvcnQgU1RBTVAuICBGb3IgZXhhbXBsZSwgPHNwYW4gY2xhc3M9Imluc2VydCI+YTwvc3Bhbj4g VFdBTVAgTGlnaHQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRl bGV0ZSI+ICAgUmVmbGVjdG9yPC9zcGFuPiBtYXkgbm90IHN1cHBvcnQgdGhlIHVzZSBvZiBVRFAg cG9ydCA4NjIgYXMgZGVmaW5lZCBpbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4g ICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5TZXNzaW9uLVJlZmxlY3Rvcjwvc3Bhbj4gbWF5IG5vdCBz dXBwb3J0IHRoZSB1c2Ugb2YgVURQIHBvcnQgODYyIGFzIGRlZmluZWQ8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+ICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+W0ktRC5pZXRmLWlwcG0tcG9y dC10d2FtcC10ZXN0XS48L3NwYW4+ICBUaHVzIFNUQU1QIFNlc3Npb24tU2VuZGVyIE1VU1QgYmU8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgaW4gPHNwYW4gY2xhc3M9Imluc2Vy dCI+W1JGQzg1NDVdLjwvc3Bhbj4gIFRodXMgU1RBTVAgU2Vzc2lvbi1TZW5kZXIgTVVTVCBiZSBh YmxlIHRvIHNlbmQgdGVzdDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBhYmxlIHRv IHNlbmQgdGVzdCBwYWNrZXRzIHRvIGRlc3RpbmF0aW9uIFVEUCBwb3J0IG51bWJlciBmcm9tIHRo ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBwYWNrZXRzIHRvIGRlc3RpbmF0 aW9uIFVEUCBwb3J0IG51bWJlciBmcm9tIHRoZSBEeW5hbWljIGFuZC9vcjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICBEeW5hbWljIGFuZC9vciBQcml2YXRlIFBvcnRzIHJhbmdlIDQ5 MTUyLTY1NTM1LCB0ZXN0IG1hbmFnZW1lbnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgUHJpdmF0ZSBQb3J0cyByYW5nZSA0OTE1Mi02NTUzNSwgdGVzdCBtYW5hZ2VtZW50IHN5 c3RlbSBzaG91bGQgZmluZCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5hPC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBzeXN0ZW0gc2hvdWxkIGZpbmQgcG9ydCBudW1iZXIgdGhh dCBib3RoIGRldmljZXMgY2FuIHVzZS4gIEFuZCBpZiBhbnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgcG9ydCBudW1iZXIgdGhhdCBib3RoIGRldmljZXMgY2FuIHVzZS4gIEFu ZCBpZiBhbnkgb2YgU1RBTVA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgb2YgPHNw YW4gY2xhc3M9ImRlbGV0ZSI+VExWLWJhc2VkPC9zcGFuPiBTVEFNUCBleHRlbnNpb25zIGFyZSB1 c2VkLCB0aGUgVFdBTVAgTGlnaHQgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+U2Vzc2lvbi08L3NwYW4+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGV4dGVuc2lvbnMgYXJlIHVzZWQs IHRoZSBUV0FNUCBMaWdodCA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5TZXNzaW9uLVJlZmxlY3Rvcjwv c3Bhbj4gd2lsbCB2aWV3IHRoZW08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4g Y2xhc3M9ImRlbGV0ZSI+ICAgUmVmbGVjdG9yPC9zcGFuPiB3aWxsIHZpZXcgdGhlbSBhcyBQYWNr ZXQgUGFkZGluZyBmaWVsZC4gIFRoZSBTZXNzaW9uLVNlbmRlcjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmJsb2NrIj4gICBhcyBQYWNrZXQgUGFkZGluZyBmaWVsZC4gIFRoZSBTZXNzaW9uLVNl bmRlciBTSE9VTEQgdXNlIHRoZSBkZWZhdWx0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2si PiAgIFNIT1VMRCB1c2UgdGhlIGRlZmF1bHQgZm9ybWF0IGZvciBpdHMgdGltZXN0YW1wcyAtIE5U UC4gIEFuZCBpdCBNQVk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgZm9ybWF0 IGZvciBpdHMgdGltZXN0YW1wcyAtIE5UUC4gIEFuZCBpdCBNQVkgdXNlIFBUUHYyIHRpbWVzdGFt cDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICB1c2UgUFRQdjIgdGltZXN0YW1wIGZv cm1hdC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgZm9ybWF0LjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBJbiB0aGUgbGF0dGVyIHNjZW5hcmlvLCB0aGUg dGVzdCBtYW5hZ2VtZW50IHN5c3RlbSBzaG91bGQgc2V0IFNUQU1QPC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgSW4gdGhlIGxhdHRlciBzY2VuYXJpbywgdGhlIHRlc3QgbWFuYWdl bWVudCBzeXN0ZW0gc2hvdWxkIHNldCBTVEFNUDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgU2Vzc2lvbi1SZWZsZWN0b3IgdG8gdXNlIFVEUCBwb3J0IG51bWJlciBmcm9tIHRoZSBEeW5h bWljIGFuZC9vcjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFNlc3Npb24tUmVm bGVjdG9yIHRvIHVzZSBVRFAgcG9ydCBudW1iZXIgZnJvbSB0aGUgRHluYW1pYyBhbmQvb3I8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFByaXZhdGUgUG9ydHMgcmFuZ2UuICBBcyBmb3Ig UGFja2V0IFBhZGRpbmcgZmllbGQgdGhhdCB0aGUgVFdBTVA8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBQcml2YXRlIFBvcnRzIHJhbmdlLiAgQXMgZm9yIFBhY2tldCBQYWRkaW5n IGZpZWxkIHRoYXQgdGhlIFRXQU1QPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBMaWdo dCBTZXNzaW9uLVNlbmRlciBpbmNsdWRlcyBpbiBpdHMgdHJhbnNtaXR0ZWQgcGFja2V0LCB0aGUg U1RBTVA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBMaWdodCBTZXNzaW9uLVNl bmRlciBpbmNsdWRlcyBpbiBpdHMgdHJhbnNtaXR0ZWQgcGFja2V0LCB0aGUgU1RBTVA8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFNlc3Npb24tUmVmbGVjdG9yIHdpbGwgcHJvY2VzcyBp dCBhY2NvcmRpbmcgdG8gW1JGQzYwMzhdIGFuZCByZXR1cm48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBTZXNzaW9uLVJlZmxlY3RvciB3aWxsIHByb2Nlc3MgaXQgYWNjb3JkaW5n IHRvIFtSRkM2MDM4XSBhbmQgcmV0dXJuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBy ZWZsZWN0ZWQgcGFja2V0IG9mIHRoZSBzeW1tZXRyaWNhbCBzaXplLiAgVGhlIFNlc3Npb24tUmVm bGVjdG9yIE1VU1Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICByZWZsZWN0ZWQg cGFja2V0IG9mIHRoZSBzeW1tZXRyaWNhbCBzaXplLiAgVGhlIFNlc3Npb24tUmVmbGVjdG9yIE1V U1Q8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHVzZSB0aGUgZGVmYXVsdCBmb3JtYXQg Zm9yIGl0cyB0aW1lc3RhbXBzIC0gTlRQLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIHVzZSB0aGUgZGVmYXVsdCBmb3JtYXQgZm9yIGl0cyB0aW1lc3RhbXBzIC0gTlRQLjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij41LiAgSUFOQSBDb25zaWRlcmF0aW9uczwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjUuICBJQU5BIENvbnNpZGVyYXRpb25zPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMgZG9jdW1lbnQgZG9lc24ndCBoYXZl IGFueSBJQU5BIGFjdGlvbi4gIFRoaXMgc2VjdGlvbiBtYXkgYmU8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBUaGlzIGRvY3VtZW50IGRvZXNuJ3QgaGF2ZSBhbnkgSUFOQSBhY3Rp b24uICBUaGlzIHNlY3Rpb24gbWF5IGJlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBy ZW1vdmVkIGJlZm9yZSB0aGUgcHVibGljYXRpb24uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgcmVtb3ZlZCBiZWZvcmUgdGhlIHB1YmxpY2F0aW9uLjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij42LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij42LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAzMyI+PHRk PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9 Imluc2VydCI+SW4gZ2VuZXJhbCwgYWxsIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyByZWxh dGVkIHRvIFRXQU1QLVRlc3QsPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAg ZGlzY3Vzc2VkIGluIFtSRkM1MzU3XSBhcHBseSB0byBTVEFNUC4gIFNpbmNlIFNUQU1QIHVzZXMg dGhlIHdlbGwtPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAga25vd24gVURQ IHBvcnQgbnVtYmVyIGFsbG9jYXRlZCBmb3IgdGhlIE9XQU1QLVRlc3QvVFdBTVAtVGVzdDwvc3Bh bj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIFJlY2VpdmVyIHBvcnQsIHRoZSBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBhbmQgbWVhc3VyZXMgdG8gbWl0aWdhdGU8L3NwYW4+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICB0aGUgcmlzayBvZiB0aGUgYXR0YWNrIHVzaW5nIHRo ZSByZWdpc3RlcmVkIHBvcnQgbnVtYmVyIGRvY3VtZW50ZWQgaW48L3NwYW4+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3Bh biBjbGFzcz0iaW5zZXJ0Ij4gICBTZWN0aW9uIDYgW1JGQzg1NDVdIGVxdWFsbHkgYXBwbHkgdG8g U1RBTVAuICBCZWNhdXNlIG9mIHRoZSBjb250cm9sPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9 Imluc2VydCI+ICAgYW5kIG1hbmFnZW1lbnQgb2YgYSBTVEFNUCB0ZXN0IGJlaW5nIG91dHNpZGUg dGhlIHNjb3BlIG9mIHRoaXM8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBz cGVjaWZpY2F0aW9uIG9ubHkgdGhlIG1vcmUgZ2VuZXJhbCByZXF1aXJlbWVudCBpcyBzZXQ6PC9z cGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xh c3M9Imluc2VydCI+ICAgICAgVG8gbWl0aWdhdGUgdGhlIHBvc3NpYmxlIGF0dGFjayB2ZWN0b3Is IHRoZSBjb250cm9sIGFuZCBtYW5hZ2VtZW50PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imlu c2VydCI+ICAgICAgb2YgYSBTVEFNUCB0ZXN0IHNlc3Npb24gTVVTVCB1c2UgdGhlIHNlY3VyZWQg dHJhbnNwb3J0Ljwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIFVzZSBvZiBITUFDLVNIQS0yNTYgaW4gdGhlIGF1dGhlbnRpY2F0ZWQg bW9kZSBwcm90ZWN0cyB0aGUgZGF0YTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IFVzZSBvZiBITUFDLVNIQS0yNTYgaW4gdGhlIGF1dGhlbnRpY2F0ZWQgbW9kZSBwcm90ZWN0cyB0 aGUgZGF0YTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgaW50ZWdyaXR5IG9mIHRoZSBT VEFNUCB0ZXN0IHBhY2tldHMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaW50 ZWdyaXR5IG9mIHRoZSBTVEFNUCB0ZXN0IHBhY2tldHMuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjcuICBBY2tub3dsZWRnbWVudHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij43LiAgQWNrbm93bGVkZ21lbnRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIEF1dGhvcnMgZXhwcmVzcyB0aGVpciBhcHByZWNpYXRpb24gdG8gSm9zZSBJZ25hY2lvIEFs dmFyZXotSGFtZWxpbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEF1dGhvcnMg ZXhwcmVzcyB0aGVpciBhcHByZWNpYXRpb24gdG8gSm9zZSBJZ25hY2lvIEFsdmFyZXotSGFtZWxp bjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYW5kIEJyaWFuIFdlaXMgZm9yIHRoZWly IGdyZWF0IGluc2lnaHRzIGludG8gdGhlIHNlY3VyaXR5IGFuZDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIGFuZCBCcmlhbiBXZWlzIGZvciB0aGVpciBncmVhdCBpbnNpZ2h0cyBp bnRvIHRoZSBzZWN1cml0eSBhbmQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGlkZW50 aXR5IHByb3RlY3Rpb24sIGFuZCB0aGUgbW9zdCBoZWxwZnVsIGFuZCBwcmFjdGljYWwgc3VnZ2Vz dGlvbnMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgaWRlbnRpdHkgcHJvdGVj dGlvbiwgYW5kIHRoZSBtb3N0IGhlbHBmdWwgYW5kIHByYWN0aWNhbCBzdWdnZXN0aW9ucy48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMzQiPjx0 ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDxzcGFuIGNsYXNz PSJpbnNlcnQiPkFsc28sIG91ciBzaW5jZXJlIHRoYW5rcyB0byBEYXZpZCBCYWxsIGZvciBoaXMg dGhvcm91Z2ggcmV2aWV3IGFuZDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAg IGhlbHBmdWwgY29tbWVudHMuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij44LiAgUmVmZXJlbmNlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjguICBSZWZl cmVuY2VzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjguMS4gIE5vcm1hdGl2ZSBS ZWZlcmVuY2VzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+OC4xLiAgTm9ybWF0aXZl IFJlZmVyZW5jZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyIGlkPSJkaWZmMDAzNSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5bQkJG LlRSLTM5MF08L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICAgICAgICAgICAg ICJQZXJmb3JtYW5jZSBNZWFzdXJlbWVudCBmcm9tIElQIEVkZ2UgdG8gQ3VzdG9tZXI8L3NwYW4+ PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4gICAgICAgICAgICAgIEVxdWlwbWVudCB1c2lu ZyBUV0FNUCBMaWdodCIsIEJCRiBUUi0zOTAsIE1heSAyMDE3Ljwvc3Bhbj48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFu IGNsYXNzPSJkZWxldGUiPjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgIFtJ LUQuaWV0Zi1pcHBtLXBvcnQtdHdhbXAtdGVzdF08L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyYmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0i ZGVsZXRlIj4gICAgICAgICAgICAgIE1vcnRvbiwgQS4gYW5kIEcuIE1pcnNreSwgIk9XQU1QIGFu ZCBUV0FNUCBXZWxsLUtub3duIFBvcnQ8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRl Ij4gICAgICAgICAgICAgIEFzc2lnbm1lbnRzIiwgZHJhZnQtaWV0Zi1pcHBtLXBvcnQtdHdhbXAt dGVzdC0wMyAod29yayBpbjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAg ICAgICAgICAgcHJvZ3Jlc3MpLCBOb3ZlbWJlciAyMDE4Ljwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBbSUVFRS4xNTg4LjIwMDhdPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgW0lFRUUuMTU4OC4yMDA4XTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICAgICAgICAgICAiU3RhbmRhcmQgZm9yIGEgUHJlY2lzaW9uIENsb2NrIFN5bmNocm9uaXph dGlvbiBQcm90b2NvbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAg ICAgIlN0YW5kYXJkIGZvciBhIFByZWNpc2lvbiBDbG9jayBTeW5jaHJvbml6YXRpb24gUHJvdG9j b2w8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgZm9yIE5ldHdvcmtl ZCBNZWFzdXJlbWVudCBhbmQgQ29udHJvbCBTeXN0ZW1zIiw8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAgICAgICAgICAgIGZvciBOZXR3b3JrZWQgTWVhc3VyZW1lbnQgYW5kIENv bnRyb2wgU3lzdGVtcyIsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAg IElFRUUgU3RhbmRhcmQgMTU4OCwgTWFyY2ggMjAwOC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgICAgICAgICAgIElFRUUgU3RhbmRhcmQgMTU4OCwgTWFyY2ggMjAwOC48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW1JGQzIxMTldICBCcmFkbmVyLCBTLiwg IktleSB3b3JkcyBmb3IgdXNlIGluIFJGQ3MgdG8gSW5kaWNhdGU8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICBbUkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1 c2UgaW4gUkZDcyB0byBJbmRpY2F0ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAg ICAgICAgICBSZXF1aXJlbWVudCBMZXZlbHMiLCBCQ1AgMTQsIFJGQyAyMTE5LDwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgUmVxdWlyZW1lbnQgTGV2ZWxzIiwg QkNQIDE0LCBSRkMgMjExOSw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAg ICAgRE9JIDEwLjE3NDg3L1JGQzIxMTksIE1hcmNoIDE5OTcsPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgICAgICAgICAgICBET0kgMTAuMTc0ODcvUkZDMjExOSwgTWFyY2ggMTk5 Nyw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgJmx0O2h0dHBzOi8v d3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjMjExOSZndDsuPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgICAgICAgICAgICAmbHQ7aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcv aW5mby9yZmMyMTE5Jmd0Oy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHIgaWQ9InBhcnQtMTEiIGNsYXNzPSJjaGFuZ2UiPjx0ZD48L3RkPjx0aD48 c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3dzYu aWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQjcGFydC0xMSI+PGVtPiBwYWdlIDE0LCBsaW5l IDI0PHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48 dGg+PHNtYWxsPnNraXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93 d3c2LmlldGYub3JnL3JmY2RpZmYvcmZjZGlmZi5weWh0I3BhcnQtMTEiPjxlbT4gcGFnZSAxMywg bGluZSAzNDxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIFtSRkM4MTc0XSAgTGVpYmEsIEIuLCAiQW1iaWd1aXR5IG9mIFVwcGVyY2FzZSB2 cyBMb3dlcmNhc2UgaW4gUkZDPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgW1JG QzgxNzRdICBMZWliYSwgQi4sICJBbWJpZ3VpdHkgb2YgVXBwZXJjYXNlIHZzIExvd2VyY2FzZSBp biBSRkM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgMjExOSBLZXkg V29yZHMiLCBCQ1AgMTQsIFJGQyA4MTc0LCBET0kgMTAuMTc0ODcvUkZDODE3NCw8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIDIxMTkgS2V5IFdvcmRzIiwgQkNQ IDE0LCBSRkMgODE3NCwgRE9JIDEwLjE3NDg3L1JGQzgxNzQsPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAgICAgICAgICAgIE1heSAyMDE3LCAmbHQ7aHR0cHM6Ly93d3cucmZjLWVkaXRv ci5vcmcvaW5mby9yZmM4MTc0Jmd0Oy48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAgICAgICAgICAgIE1heSAyMDE3LCAmbHQ7aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5m by9yZmM4MTc0Jmd0Oy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW1JGQzgx ODZdICBNaXJza3ksIEcuIGFuZCBJLiBNZWlsaWssICJTdXBwb3J0IG9mIHRoZSBJRUVFIDE1ODg8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbUkZDODE4Nl0gIE1pcnNreSwgRy4g YW5kIEkuIE1laWxpaywgIlN1cHBvcnQgb2YgdGhlIElFRUUgMTU4ODwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgICAgICAgICBUaW1lc3RhbXAgRm9ybWF0IGluIGEgVHdvLVdheSBB Y3RpdmUgTWVhc3VyZW1lbnQgUHJvdG9jb2w8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICAgICAgICAgICAgIFRpbWVzdGFtcCBGb3JtYXQgaW4gYSBUd28tV2F5IEFjdGl2ZSBNZWFz dXJlbWVudCBQcm90b2NvbDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAg ICAoVFdBTVApIiwgUkZDIDgxODYsIERPSSAxMC4xNzQ4Ny9SRkM4MTg2LCBKdW5lIDIwMTcsPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAoVFdBTVApIiwgUkZD IDgxODYsIERPSSAxMC4xNzQ4Ny9SRkM4MTg2LCBKdW5lIDIwMTcsPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICZsdDtodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9p bmZvL3JmYzgxODYmZ3Q7LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAg ICAgICAgJmx0O2h0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjODE4NiZndDsuPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAw MzYiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDxzcGFu IGNsYXNzPSJpbnNlcnQiPltSRkM4NTQ1XSAgTW9ydG9uLCBBLiwgRWQuIGFuZCBHLiBNaXJza3ks IEVkLiwgIldlbGwtS25vd24gUG9ydDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQi PiAgICAgICAgICAgICAgQXNzaWdubWVudHMgZm9yIHRoZSBPbmUtV2F5IEFjdGl2ZSBNZWFzdXJl bWVudCBQcm90b2NvbDwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAg ICAgICAgKE9XQU1QKSBhbmQgdGhlIFR3by1XYXkgQWN0aXZlIE1lYXN1cmVtZW50IFByb3RvY29s PC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgICAgICAoVFdBTVAp IiwgUkZDIDg1NDUsIERPSSAxMC4xNzQ4Ny9SRkM4NTQ1LCBNYXJjaCAyMDE5LDwvc3Bhbj48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgICAgICAgICAgICAgJmx0O2h0dHBzOi8vd3d3LnJm Yy1lZGl0b3Iub3JnL2luZm8vcmZjODU0NSZndDsuPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+OC4yLiAgSW5mb3JtYXRpdmUgUmVmZXJl bmNlczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjguMi4gIEluZm9ybWF0aXZlIFJl ZmVyZW5jZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy IGlkPSJkaWZmMDAzNyI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9j ayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+W0JCRi5UUi0zOTBdPC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNw YW4gY2xhc3M9Imluc2VydCI+ICAgICAgICAgICAgICAiUGVyZm9ybWFuY2UgTWVhc3VyZW1lbnQg ZnJvbSBJUCBFZGdlIHRvIEN1c3RvbWVyPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9Imluc2Vy dCI+ICAgICAgICAgICAgICBFcXVpcG1lbnQgdXNpbmcgVFdBTVAgTGlnaHQiLCBCQkYgVFItMzkw LCBNYXkgMjAxNy48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij4gICBbSS1ELmlldGYtaXBwbS1zdGFtcC15YW5nXTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIFtJLUQuaWV0Zi1pcHBtLXN0YW1wLXlhbmddPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgIE1pcnNreSwgRy4sIFhpYW8sIE0uLCBh bmQgVy4gTHVvLCAiU2ltcGxlIFR3by13YXkgQWN0aXZlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgICAgICAgICAgICBNaXJza3ksIEcuLCBYaWFvLCBNLiwgYW5kIFcuIEx1bywg IlNpbXBsZSBUd28td2F5IEFjdGl2ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAg ICAgICAgICBNZWFzdXJlbWVudCBQcm90b2NvbCAoU1RBTVApIERhdGEgTW9kZWwiLCBkcmFmdC1p ZXRmLWlwcG0tPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBN ZWFzdXJlbWVudCBQcm90b2NvbCAoU1RBTVApIERhdGEgTW9kZWwiLCBkcmFmdC1pZXRmLWlwcG0t PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDM4 Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPiAgICAgICAgICAgICAgc3RhbXAteWFuZy0wPHNwYW4gY2xhc3M9ImRlbGV0 ZSI+MiAod29yayBpbiBwcm9ncmVzcyksIFNlcHRlbWJlciAyMDE4PC9zcGFuPi48L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgICAgICBzdGFtcC15YW5nLTA8c3BhbiBj bGFzcz0iaW5zZXJ0Ij4zICh3b3JrIGluIHByb2dyZXNzKSwgTWFyY2ggMjAxOTwvc3Bhbj4uPC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFtSRkMyMTA0XSAgS3Jhd2N6eWssIEgu LCBCZWxsYXJlLCBNLiwgYW5kIFIuIENhbmV0dGksICJITUFDOiBLZXllZC08L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbUkZDMjEwNF0gIEtyYXdjenlrLCBILiwgQmVsbGFyZSwg TS4sIGFuZCBSLiBDYW5ldHRpLCAiSE1BQzogS2V5ZWQtPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICAgICAgICAgICAgIEhhc2hpbmcgZm9yIE1lc3NhZ2UgQXV0aGVudGljYXRpb24iLCBS RkMgMjEwNCw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIEhh c2hpbmcgZm9yIE1lc3NhZ2UgQXV0aGVudGljYXRpb24iLCBSRkMgMjEwNCw8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzIxMDQsIEZlYnJ1 YXJ5IDE5OTcsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICBE T0kgMTAuMTc0ODcvUkZDMjEwNCwgRmVicnVhcnkgMTk5Nyw8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgICAgICAgICAgICAgJmx0O2h0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8v cmZjMjEwNCZndDsuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAg ICAmbHQ7aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmMyMTA0Jmd0Oy48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgW1JGQzQ4NjhdICBLZWxseSwgUy4gYW5kIFMu IEZyYW5rZWwsICJVc2luZyBITUFDLVNIQS0yNTYsIEhNQUMtU0hBLTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIFtSRkM0ODY4XSAgS2VsbHksIFMuIGFuZCBTLiBGcmFua2VsLCAi VXNpbmcgSE1BQy1TSEEtMjU2LCBITUFDLVNIQS08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgICAgICAgICAgICAgMzg0LCBhbmQgSE1BQy1TSEEtNTEyIHdpdGggSVBzZWMiLCBSRkMgNDg2 OCw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIDM4NCwgYW5k IEhNQUMtU0hBLTUxMiB3aXRoIElQc2VjIiwgUkZDIDQ4NjgsPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM0ODY4LCBNYXkgMjAwNyw8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9S RkM0ODY4LCBNYXkgMjAwNyw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAg ICAgJmx0O2h0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjNDg2OCZndDsuPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAmbHQ7aHR0cHM6Ly93d3cu cmZjLWVkaXRvci5vcmcvaW5mby9yZmM0ODY4Jmd0Oy48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CgogICAgIDx0cj48dGQ+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkPjwvdGQ+PC90cj4KICAgICA8dHIgaWQ9ImVu ZCIgYmdjb2xvcj0iZ3JheSI+PHRoIGNvbHNwYW49IjUiIGFsaWduPSJjZW50ZXIiPiZuYnNwO0Vu ZCBvZiBjaGFuZ2VzLiAzOCBjaGFuZ2UgYmxvY2tzLiZuYnNwOzwvdGg+PC90cj4KICAgICA8dHIg Y2xhc3M9InN0YXRzIj48dGQ+PC90ZD48dGg+PGk+OTggbGluZXMgY2hhbmdlZCBvciBkZWxldGVk PC9pPjwvdGg+PHRoPjxpPiA8L2k+PC90aD48dGg+PGk+MTAwIGxpbmVzIGNoYW5nZWQgb3IgYWRk ZWQ8L2k+PC90aD48dGQ+PC90ZD48L3RyPgogICAgIDx0cj48dGQgY29sc3Bhbj0iNSIgYWxpZ249 ImNlbnRlciIgY2xhc3M9InNtYWxsIj48YnI+VGhpcyBodG1sIGRpZmYgd2FzIHByb2R1Y2VkIGJ5 IHJmY2RpZmYgMS40Ny4gVGhlIGxhdGVzdCB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBmcm9tIDxhIGhy ZWY9Imh0dHA6Ly93d3cudG9vbHMuaWV0Zi5vcmcvdG9vbHMvcmZjZGlmZi8iPmh0dHA6Ly90b29s cy5pZXRmLm9yZy90b29scy9yZmNkaWZmLzwvYT4gPC90ZD48L3RyPgogICA8L3Rib2R5PjwvdGFi bGU+CiAgIAogICAKPC9ib2R5PjxkaXY+PGRpdiBjbGFzcz0iZ3JfLWVkaXRvciBnci1pZnJhbWUt Zmlyc3QtbG9hZCIgc3R5bGU9ImRpc3BsYXk6IG5vbmU7Ij48ZGl2IGNsYXNzPSJncl8tZWRpdG9y X2JhY2siPjwvZGl2PjxpZnJhbWUgY2xhc3M9ImdyXy1pZnIgZ3ItX2RpYWxvZy1jb250ZW50IiBz cmM9Ii4vRGlmZl8gZHJhZnQtaWV0Zi1pcHBtLXN0YW1wLTA1LnR4dCAtIGRyYWZ0LWlldGYtaXBw bS1zdGFtcC0wNi50eHRfZmlsZXMvc2F2ZWRfcmVzb3VyY2UuaHRtbCI+PC9pZnJhbWU+PC9kaXY+ PC9kaXY+PGdyYW1tYXJseS1jYXJkPjxkaXY+PC9kaXY+PC9ncmFtbWFybHktY2FyZD48c3BhbiBj bGFzcz0iZ3JfX3Rvb2x0aXAiPjxzcGFuIGNsYXNzPSJncl9fdG9vbHRpcC1jb250ZW50Ij48L3Nw YW4+PGkgY2xhc3M9ImdyX190b29sdGlwLWxvZ28iPjwvaT48c3BhbiBjbGFzcz0iZ3JfX3RyaWFu Z2xlIj48L3NwYW4+PC9zcGFuPjwvaHRtbD4= --000000000000350e7c0587389d02-- From nobody Tue Apr 23 15:00:02 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF764120615 for ; Tue, 23 Apr 2019 14:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 S355wVv1Y3_W for ; Tue, 23 Apr 2019 14:59:57 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 250A4120608 for ; Tue, 23 Apr 2019 14:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10415; q=dns/txt; s=iport; t=1556056797; x=1557266397; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=rguU3DfsYJZlwsGRcnXIgBXm5UsotfmfZiqPyA3NuIg=; b=g2BeLoVgs8Z4Tw6Y283+EEVg3Yl2RsBoXzjmUssfUqJXP47BD97kzgBB fpLsfCSeUt+Zm9gTQVzMgxPbcYeVm9uv9bTuflBj+N7WRCpvv3znhPCH2 Ln8aYTwNIAXDWQwpgCxOjLgj4jZ2LubD24PWke2mtwrvHIftT7yBX+RXS E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAABmib9c/xbLJq1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgnhRATIohA6IHF+MPZJRhXqBexAYAQy?= =?us-ascii?q?ESAKGSjQJDgEDAQEEAQECAQJtHAyFSwEBAQMBASFLCxALGCcDAgInHxEGAQw?= =?us-ascii?q?GAgEBgx4BgggPqQ2BLx+FKIRiBoEyAYZHhRmBQD+BESeCaz6CYQEBAgGBSIM?= =?us-ascii?q?gglcEmVqMGGQJggqGD4wVBhuCC4Ypg0GJH4wEgR6FH4Yyh3SBTzgogS4zGgg?= =?us-ascii?q?bFTuCbIsShUA+AzABkHEBAQ?= X-IronPort-AV: E=Sophos; i="5.60,387,1549929600"; d="scan'208,217"; a="11570767" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Apr 2019 21:59:53 +0000 Received: from [10.61.167.55] ([10.61.167.55]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id x3NLxqKj002019; Tue, 23 Apr 2019 21:59:52 GMT To: Greg Mirsky , Tal Mizrahi Cc: IETF IPPM WG References: <3600b860-32f8-0636-7093-eaddd2fb380d@cisco.com> From: David Ball Message-ID: <2a9df237-d43f-fc31-ff2f-455aa66016cf@cisco.com> Date: Tue, 23 Apr 2019 22:59:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8FDF7C8F74C13DFDE78B1707" Content-Language: en-US X-Outbound-SMTP-Client: 10.61.167.55, [10.61.167.55] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [ippm] Working Group Last Call on draft-ietf-ippm-stamp-05 X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 22:00:00 -0000 This is a multi-part message in MIME format. --------------8FDF7C8F74C13DFDE78B1707 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Looks good, thanks Greg.     David On 23/04/2019 21:41, Greg Mirsky wrote: > Hi David, > apologies for the delayed update. I've prepared the new version of the > draft to address your comments and comments by the draft Shepherd Tal > Mizrahi. Please find the diff, the updated new version attached. Also, > I've added a couple explaining notes in-line below under the GIM>> tag. > Much appreciate your feedback. > > Regards, > Greg > > > On Tue, Mar 5, 2019 at 8:26 AM David Ball > wrote: > > Hi, > > I have reviewed the document and am fine with it progressing. > > A few nits: > > * The text at the start of Sn 4.1.1 should be before the 4.1.1 > heading (after the 4.1 heading). > > GIM>> Accepted and done. > > * Sn 4.1.1 - the bullet about Server Octets has a spurious extra > part-sentence: "The Reflect Octets capability defined in > [RFC6038]." - this should be deleted. > > GIM>> The comment from Shepherd suggested re-wording the sentence. > Please let me know if the following change is acceptable: > OLD TEXT: > The Reflect Octets capability defined in [RFC6038]. > NEW TEXT: > This field is used for the Reflect Octets capability defined in > [RFC6038]. > > * > > > * Fig 4 shows a min length of 112 (if I counted right); but text > at the start of 4.1.1 says the min length in authenticated > mode is 48. > > GIM>> Great catch, thank you! It must be 112 - corrected the text. > > * The wording/grammar in the paragraph after bullets in Sn 4.4 > is a little awkward - suggested edits below: > > "In the former case,the Session-Sender MAY not be aware that its Session- > Reflector does not support STAMP. For example,a TWAMP Light Session- > Reflector may not support the use of UDP port 862 as defined in > [I-D.ietf-ippm-port-twamp-test ]. Thus, the STAMP Session-Sender MUST be > able to send test packets to destination UDP port numbers taken from the > Dynamic and/or Private Ports range 49152-65535. The test management > system should finda port number that both devices can use.If any > ofthe TLV-based STAMP extensions are used, the TWAMP Light Session- > Reflector will view them as Packet Padding field. The Session-Sender > SHOULD use the default format for its timestamps(NTP) but it MAY > use PTPv2 timestamp format." > > GIM>> Many thanks. Accepted. > >     David > > > -- > David Ball > > > _______________________________________________ > ippm mailing list > ippm@ietf.org > https://www.ietf.org/mailman/listinfo/ippm > -- David Ball --------------8FDF7C8F74C13DFDE78B1707 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Looks good, thanks Greg.


    David


On 23/04/2019 21:41, Greg Mirsky wrote:
Hi David,
apologies for the delayed update. I've prepared the new version of the draft to address your comments and comments by the draft Shepherd Tal Mizrahi. Please find the diff, the updated new version attached. Also, I've added a couple explaining notes in-line below under the GIM>> tag.
Much appreciate your feedback.

Regards,
Greg


On Tue, Mar 5, 2019 at 8:26 AM David Ball <daviball@cisco.com> wrote:

Hi,

I have reviewed the document and am fine with it progressing.

A few nits:

  • The text at the start of Sn 4.1.1 should be before the 4.1.1 heading (after the 4.1 heading).
GIM>> Accepted and done. 
  • Sn 4.1.1 - the bullet about Server Octets has a spurious extra part-sentence: "The Reflect Octets capability defined in [RFC6038]." - this should be deleted.
GIM>> The comment from Shepherd suggested re-wording the sentence. Please let me know if the following change is acceptable:
OLD TEXT:
The Reflect Octets capability defined in [RFC6038]. 
NEW TEXT:
This field is used for the Reflect Octets capability defined in [RFC6038]. 

  • Fig 4 shows a min length of 112 (if I counted right); but text at the start of 4.1.1 says the min length in authenticated mode is 48.
GIM>> Great catch, thank you! It must be 112 - corrected the text. 
  • The wording/grammar in the paragraph after bullets in Sn 4.4 is a little awkward - suggested edits below:
  "In the former case, the Session-Sender MAY not be aware that its Session-
   Reflector does not support STAMP.  For example, a TWAMP Light Session-
   Reflector may not support the use of UDP port 862 as defined in
   [I-D.ietf-ippm-port-twamp-test].  Thus, the STAMP Session-Sender MUST be
   able to send test packets to destination UDP port numbers taken from the
   Dynamic and/or Private Ports range 49152-65535.  The test management
   system should find a port number that both devices can use.  If any
   of the TLV-based STAMP extensions are used, the TWAMP Light Session-
   Reflector will view them as Packet Padding field.  The Session-Sender
   SHOULD use the default format for its timestamps (NTP) but it MAY
   use PTPv2 timestamp format."
GIM>> Many thanks. Accepted. 

    David


-- 
David Ball
<daviball@cisco.com>
_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
-- 
David Ball
<daviball@cisco.com>
--------------8FDF7C8F74C13DFDE78B1707-- From nobody Tue Apr 23 15:40:21 2019 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6F7120633; Tue, 23 Apr 2019 15:40:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: ippm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: ippm@ietf.org Message-ID: <155605921949.32405.10298509647683563015@ietfa.amsl.com> Date: Tue, 23 Apr 2019 15:40:19 -0700 Archived-At: Subject: [ippm] I-D Action: draft-ietf-ippm-stamp-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 22:40:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : Simple Two-way Active Measurement Protocol Authors : Greg Mirsky Guo Jun Henrik Nydell Richard Foote Filename : draft-ietf-ippm-stamp-06.txt Pages : 14 Date : 2019-04-23 Abstract: This document describes a Simple Two-way Active Measurement Protocol which enables the measurement of both one-way and round-trip performance metrics like delay, delay variation, and packet loss. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-stamp-06 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-stamp-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 23 15:42:47 2019 Return-Path: X-Original-To: ippm@ietfa.amsl.com Delivered-To: ippm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FCDD12063A for ; Tue, 23 Apr 2019 15:42: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6pNw1U3Fils2 for ; Tue, 23 Apr 2019 15:42:43 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 362F0120633 for ; Tue, 23 Apr 2019 15:42:43 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id t4so14984201ljc.2 for ; Tue, 23 Apr 2019 15:42:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=ftFCI2jF7P+noxKRxlkmBLFqKMdVvd6VqDQX6rlbZBY=; b=HnFpeT5xQTY0/9Vkar/zbrfUajRBeOCbyOlUfPCYfQ1g2q2yfmCOm1kMZtEBmS75Vn /GKK6Z+sT/MTZHoRceVHZDjr0VNC460x/kapwU8l8Gwl9SBxp3d7d3H3+b5aX47RZlCm +d3b47V/4dUJQDt7t6NZmC7ucjzQtzONzTTC9Q5YevEG5wSwh3EuUqWItDCdZ3NqaTX2 WMuBIn32+XFrStv68jNNyXJWFMPwnUBI6CLwv0RSiCIaN/ecXIN5+L6HhVGvOraNsGwB R9YkQE6XYT2ADZYFQ96krX6QrBeWFQV91JV/ugnUKnYcp+dduqxc4Q/leuAQ6f2WwOrF rfzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=ftFCI2jF7P+noxKRxlkmBLFqKMdVvd6VqDQX6rlbZBY=; b=ClbpWFinH4AMz+v5cvcGzBRqxJDnqXJA+anOYANZiM41r43/dr3xkzgK9nC9AOgYmG 0+UApSYKpm81lMY2qnx3Z8nfIxTGranyNtFgLSROdNuOvXitWkklscIWWiNoYgngE4E1 aOgVwX6GerABIp0Ef1RbAyI0G2WIEqf4waxpNlWVbYBJSHzsfhDYio+1QWJDRDwVyDPo 6aomRRsWo/2/lyr1VP1YSM6+aSfmmn3sxkTh7H8fcskojaH43k7WKvvmgZvPhC0VIRik PB4lW4/R9Tfnb61m3AjkWuwQMtuWR/8JPKWYkLazP7sKw6ps/Bt/rMtQL2TLmPLmkAeW 4lew== X-Gm-Message-State: APjAAAX14x7you6hIw41yc1KMHhrOzwYFStZrjjnaWOxSFz8PlJ2JuAL GdlPTWtYDfdPFSiXFy0JXMvHkhboNd8MU/Rot+R5Uw== X-Google-Smtp-Source: APXvYqym5piOB1fZZuSJun0GER0r5tsRR3T9FAmgckRLko0vkJxBPKcDJx6GiB4t5+mPUUTYS4yr6pTq5DialrCX2ds= X-Received: by 2002:a2e:974d:: with SMTP id f13mr15331891ljj.140.1556059361102; Tue, 23 Apr 2019 15:42:41 -0700 (PDT) MIME-Version: 1.0 References: <155605921949.32405.10298509647683563015@ietfa.amsl.com> In-Reply-To: <155605921949.32405.10298509647683563015@ietfa.amsl.com> From: Greg Mirsky Date: Tue, 23 Apr 2019 15:42:30 -0700 Message-ID: To: IETF IPPM WG , Tal Mizrahi Content-Type: multipart/alternative; boundary="00000000000077d0fd05873a4df9" Archived-At: Subject: [ippm] Fwd: I-D Action: draft-ietf-ippm-stamp-06.txt X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 22:42:46 -0000 --00000000000077d0fd05873a4df9 Content-Type: text/plain; charset="UTF-8" Dear All, this version includes updates that address comments we've received during WGLC and from the draft's Shepherd. Regards, Greg ---------- Forwarded message --------- From: Date: Tue, Apr 23, 2019 at 3:40 PM Subject: [ippm] I-D Action: draft-ietf-ippm-stamp-06.txt To: Cc: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Performance Measurement WG of the IETF. Title : Simple Two-way Active Measurement Protocol Authors : Greg Mirsky Guo Jun Henrik Nydell Richard Foote Filename : draft-ietf-ippm-stamp-06.txt Pages : 14 Date : 2019-04-23 Abstract: This document describes a Simple Two-way Active Measurement Protocol which enables the measurement of both one-way and round-trip performance metrics like delay, delay variation, and packet loss. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ippm-stamp-06 https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ippm-stamp-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/ _______________________________________________ ippm mailing list ippm@ietf.org https://www.ietf.org/mailman/listinfo/ippm --00000000000077d0fd05873a4df9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
this version includes updates that address c= omments we've received during WGLC and from the draft's Shepherd.

Regards,
Greg

---------- Forwarded message -= --------
From: <internet-drafts@ietf.org>
Date: Tue, Apr 23, 2019= at 3:40 PM
Subject: [ippm] I-D Action: draft-ietf-ippm-stamp-06.txt
= To: <i-d-announce@ietf.org= >
Cc: <ippm@ietf.org>
=



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the IP Performance Measurement WG of the IETF.=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Simple Two-way Active Measurement Protocol
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Greg= Mirsky
=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 Guo Jun
=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 Henrik Nydell
=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 Richard Foote
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-ippm-stamp-06.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 14
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2019-04-23

Abstract:
=C2=A0 =C2=A0This document describes a Simple Two-way Active Measurement Pr= otocol
=C2=A0 =C2=A0which enables the measurement of both one-way and round-trip =C2=A0 =C2=A0performance metrics like delay, delay variation, and packet lo= ss.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i= ppm-stamp/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-ippm-stam= p-06
https://datatracker.ietf.org/doc/html/= draft-ietf-ippm-stamp-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Ddraf= t-ietf-ippm-stamp-06


Please note that it may take a couple of minutes from the time of submissio= n
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/

_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm
--00000000000077d0fd05873a4df9-- From nobody Thu Apr 25 11:51:58 2019 Return-Path: X-Original-To: ippm@ietf.org Delivered-To: ippm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DEBBB120161; Thu, 25 Apr 2019 08:49:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Liaison Statement Management Tool To: "ITU-T SG12 TSB" , "A. C. Morton" Cc: giulio.maggiore@TELECOMITALIA.IT, tsbsg11@itu.int, tsbsg12@itu.int, Scott Mansfield , Bill Cerveny , h.w.gierlich@head-acoustics.de, IP Performance Measurement Discussion List , Brian Trammell , Magnus Westerlund , David Sinicrope , scott.mansfield@ericsson.com, itu-t-liaison@iab.org, Tommy Pauly , =?utf-8?q?Mirja_K=C3=BChlewind?= X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155620738282.23426.14555210207012428770.idtracker@ietfa.amsl.com> Date: Thu, 25 Apr 2019 08:49:42 -0700 Archived-At: X-Mailman-Approved-At: Thu, 25 Apr 2019 11:51:52 -0700 Subject: [ippm] New Liaison Statement, "Reply to ITU-T SG12 LS - Harmonization of IP Capacity and Latency" X-BeenThere: ippm@ietf.org X-Mailman-Version: 2.1.29 List-Id: IETF IP Performance Metrics Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 15:49:43 -0000 Title: Reply to ITU-T SG12 LS - Harmonization of IP Capacity and Latency Submission Date: 2019-04-25 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1641/ From: Scott Mansfield To: A. C. Morton , ITU-T SG12 TSB Cc: Scott Mansfield ,Bill Cerveny ,IP Performance Measurement Discussion List ,Mirja Kühlewind ,Brian Trammell ,Magnus Westerlund ,itu-t-liaison@iab.org,Tommy Pauly ,David Sinicrope ,giulio.maggiore@TELECOMITALIA.IT,tsbsg11@itu.int,tsbsg12@itu.int,h.w.gierlich@head-acoustics.de Response Contacts: Brian Trammell ,Bill Cerveny ,Tommy Pauly Technical Contacts: scott.mansfield@ericsson.com Purpose: For information Referenced liaison: LS - Harmonization of IP Capacity and Latency Parameters: Revision of Draft Rec. Y.1540 on IP packet transfer performance parameters and New Annex A with Lab Evaluation Plan (https://datatracker.ietf.org/liaison/1632/) Body: IETF IPPM working group thanks ITU-T SG12 for your liaison describing results from your evaluation of IP Capacity and Latency Metrics and methods of measurement. The harmonization of these measurements is welcome in our industry. We have the following comments on the preliminary results, and the evaluation plan: After noting the efficacy of UDP measurements in your results, we can state that UDP transport is the basis for most IPPM measurement implementations, and IPPM's measurement protocols. When assessing IP Capacity and Latency, there should be no attempt to determine the technology involved in the path, such as AQM. The method should measure the path as a black box. The presence of packet-marking-sensitive technologies, such as Diff-serv queues add complexity to IP Capacity and Latency. There is not yet a metric that characterizes the BW-Delay product in the IPPM-literature. Live network testing may be affected by Network operator policy, it could change from the lab measurements - the test traffic is part of the background traffic. OTOH, the operator could be prioritizing test traffic, especially their own authorized testing. We also suggest to include QUIC-based measurements in your Lab evaluation, if possible. Where a model or post-processing needs to be applied to the measurements, this aspect must also be specified, especially for transport with multiple connections (averaging the connection performance). Some of the IPPM WG participants who indicated their interest in November 2019 have begun to share their comments informally, as planned. Please keep the IPPM WG informed of your progress, especially if there are ways in which IPPM WG participants assist further. Regards, IPPM Chairs Bill Cerveny (ietf@wjcerveny.com) Brian Trammell (ietf@trammell.ch) Tommy Pauly (tpauly@apple.com) Attachments: No document has been attached