From nobody Tue Jun 4 13:40:45 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4437E1202E7; Tue, 4 Jun 2019 13:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 aX4bpqZtNMqC; Tue, 4 Jun 2019 13:40:27 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 3811912004C; Tue, 4 Jun 2019 13:40:27 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id 131so8487538ljf.4; Tue, 04 Jun 2019 13:40:27 -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=UojGCpH5K3RrHd5m15zt9lvTn9YsSLGvqeGvMY649xo=; b=fF4++0IX9KxowwMCM1KZripNGjTNbE5ZjFuuxuQRbZfhkBh28JrewXZbBLWn8IS8rK fTFzZBiuGmApemfbdxsUCPC15B89fhnX1k1qLlYlRKKyHQultbnnBua7+K9cvtzMYYUe nhuxRT7MysJSq9Aqcy5esFAfm0pqx9OHGgsrZKmFAqD/H89Ul13oEHdgE8OmTrkaLaV0 ZWZ11cwlIO4YUgI9Bmkp79vX7T3PiVukp+C1L3bLFo4GSZw1HXQxScQIGkKFjnon2M4A AyQraXFebX4Ezymj8/gD4917Y5j1BLnpzG3jayAQaZMXYXa7ufhqkz60YXD2nqA5LDLA uv5A== 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=UojGCpH5K3RrHd5m15zt9lvTn9YsSLGvqeGvMY649xo=; b=HJtiNcsG7KMeujorG5N3+T3TgrYelkmiTASS6yyLqWq6QJUXH4suqHjTWN8miV21SB S3g0SZtdmet08bpg3grdzWS4VLDrwcRTcx4kWqM5BWrioQylRvXtnwyxQBRHQ+1vH5Un ewFROP4rWJ0CouI1zP9+EA8utCPQYsqooCXhteXOPGJBHcrtaXymwJ5ssb8IGOk0/Rvl tRX4XeVr3czB/XUzCKudH8ykrKz739pkdFeeWTkcBDSnwkKT1sVqzf2SIS6rLbs+ZedB U98BROspuwWrsdkjo46XsWo10HddT08QJDX+53HQRb2eK8zRqkKZ5/yLxRUaULaWMHtz Hb6w== X-Gm-Message-State: APjAAAWYa8zloUImRmUnv2J3FUFr9riGAOCeZj+7xmyKsb5jyKlqRXI4 JX1muOj6Q7vsLkiIA6L4q1rbnwifgChz8xEp/mg= X-Google-Smtp-Source: APXvYqyxN1iG60HjjRSYzFmeCUc5G6KASfO7ak4A0CsqgxOIZvBOHveod1WjPGG7s1wXZXPaBYcaju1oa3aJDSzCvKo= X-Received: by 2002:a2e:654d:: with SMTP id z74mr2538397ljb.111.1559680825406; Tue, 04 Jun 2019 13:40:25 -0700 (PDT) MIME-Version: 1.0 References: <155842371303.2459.12357511675299405749@ietfa.amsl.com> In-Reply-To: <155842371303.2459.12357511675299405749@ietfa.amsl.com> From: Greg Mirsky Date: Tue, 4 Jun 2019 13:40:13 -0700 Message-ID: Subject: Re: Opsdir last call review of draft-ietf-bfd-vxlan-07 To: =?UTF-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= Cc: ops-dir@ietf.org, rtg-bfd WG , draft-ietf-bfd-vxlan.all@ietf.org, IETF list Content-Type: multipart/alternative; boundary="0000000000008fba59058a857d2b" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 20:40:29 -0000 --0000000000008fba59058a857d2b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jurgen, thank you for your review, detailed and precise questions. Please find my answers in-line and tagged GIM>>. Regards, Greg On Tue, May 21, 2019 at 12:28 AM J=C3=BCrgen Sch=C3=B6nw=C3=A4lder via Data= tracker < noreply@ietf.org> wrote: > Reviewer: J=C3=BCrgen Sch=C3=B6nw=C3=A4lder > Review result: Has Issues > > I only have a very limited understanding of VXLAN ands BFD technology. > Hence, some of my question may look odd to the insiders. > > - RFC 7348 defining VXLAN is informational, why would BFD for VXLAN be > standards track? > GIM>> That has been somewhat of the way to bring the de-facto standard into the IETF standardization process. - Section 2.1 "Terminology" expands acronyms but it does say where > these "terms" are actually defined. Some pointers to the relevant > RFCs may be useful. > GIM>> That might be useful, thank you. But, AFAIK, at IETF that is not the traditional format (though I know that other SDOs refer to the source of the definition used in the document.) > > - Section 3 starts talking about VNI numbers but acronym VNI has not > been introduced before. I assume VNI =3D VXLAN Network Identifier. > GIM>> Thank you. Adding to the Terminology "VXLAN Network Identifier (or VXLAN Segment ID)" and will expand on the first use. > > - I am not familiar with VXLAN but I wonder how the endpoints > addresses are obtained in practice. This BFD document says for > example "The details of how the MAC address of the destination VTEP > is obtained are outside the scope of this document." Well, OK, but > how does this work? Is there a document where this is explained? > Well, I am actually less concerned about how the inner address is > obtained, I think I am more urgently missing how the VTEP determines > the remote tunnel endpoint address. > GIM>> One of the ways could be through exchange of the BFD packets when the DA MAC is the dedicated MAC. More on that below. > > - Why do you need a special MAC address? The text says I can use this > address or the address of the destination VTEP but there is no > reasoning when to use what or why a dedicated address is needed. > GIM> Would the following text added at the end of Section 4.1 address your question: NEW TEXT: The use of the dedicated MAC allows starting BFD session before learning the MAC address of the remote VTEP. As a result, after the BFD session has reached the Up state the operational state of the VXLAN tunnel to may be set to Up. > > - What is a 'reasonable upper bound' on the number of BFD sessions > that can be created between the same pair of VTEPs? 1? 2? 8? 64? > 256? 4096? How does the choice of this upper bound impact security? > GIM>> I agree, that is too vague. Would changing the text to recommend that the control mechanism be provided if multiple BFD sessions between the same piar of VTEP allowed: OLD TEXT: The implementation SHOULD have a reasonable upper bound on the number of BFD sessions that can be created between the same pair of VTEPs. NEW TEXT: If the implementation supports establishing multiple BFD sessions between the same pair of VTEPs, there SHOULD be a mechanism to control the maximum number of such session that can be active at the same time. > > - Which BFD mode is assumed to be used, asynchronous or demand? Or > does this not matter for this usage of BFD, i.e., both work just > fine and will be interoperable? > GIM>> For p2p VXLAN tunnel, the Asynchronous mode of BFD is recommended: The asynchronous mode of BFD, as defined in [RFC5880], can be used to monitor a p2p VXLAN tunnel. The Demand mode is used in RFC 8293 that is recommended if the Multicast Service Node resides behind the NVE: In the case where a Multicast Service Node (MSN) (as described in Section 3.3 of [RFC8293]) resides behind an NVE, the mechanisms described in this document apply and can, therefore, be used to test the connectivity from the source NVE to the MSN. > > - Why is echo BFD outside the scope of this document? Can I just turn > on echo mode or will extra specifications be needed? > GIM>> The BFD Echo mode is underspecified in RFC 5880. To achieve interoperability we need to standardize it first. --0000000000008fba59058a857d2b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jurgen,
thank you for your review,= detailed and precise questions. Please find my answers in-line and tagged = GIM>>.

Regards,
Greg
On Tue, = May 21, 2019 at 12:28 AM J=C3=BCrgen Sch=C3=B6nw=C3=A4lder via Datatracker = <noreply@ietf.org<= /a>> wrote:
R= eviewer: J=C3=BCrgen Sch=C3=B6nw=C3=A4lder
Review result: Has Issues

I only have a very limited understanding of VXLAN ands BFD technology.
Hence, some of my question may look odd to the insiders.

- RFC 7348 defining VXLAN is informational, why would BFD for VXLAN be
=C2=A0 standards track?

- Section 2.1 "Terminology" expands acronyms but it does say wher= e
=C2=A0 these "terms" are actually defined. Some pointers to the r= elevant
=C2=A0 RFCs may be useful.

- Section 3 starts talking about VNI numbers but acronym VNI has not
=C2=A0 been introduced before. I assume VNI =3D VXLAN Network Identifier.

- I am not familiar with VXLAN but I wonder how the endpoints
=C2=A0 addresses are obtained in practice. This BFD document says for
=C2=A0 example "The details of how the MAC address of the destination = VTEP
=C2=A0 is obtained are outside the scope of this document." Well, OK, = but
=C2=A0 how does this work? Is there a document where this is explained?
=C2=A0 Well, I am actually less concerned about how the inner address is =C2=A0 obtained, I think I am more urgently missing how the VTEP determines=
=C2=A0 the remote tunnel endpoint address.

- Why do you need a special MAC address? The text says I can use this
=C2=A0 address or the address of the destination VTEP but there is no
=C2=A0 reasoning when to use what or why a dedicated address is needed.
=
=C2=A0VXLAN tunnel to may be set to Up.

- What is a 'reasonable upper bound' on the number of BFD sessions<= br> =C2=A0 that can be created between the same pair of VTEPs? 1? 2? 8? 64?
=C2=A0 256? 4096? How does the choice of this upper bound impact security?<= br>

- Which BFD mode is assumed to be used, asynchronous or demand? Or
=C2=A0 does this not matter for this usage of BFD, i.e., both work just
=C2=A0 fine and will be interoperable?
The as= ynchronous mode of BFD, as defined in [RFC5880],
=C2=A0 =C2=A0can b= e used to monitor a p2p VXLAN tunnel.
The Demand mode is used in = RFC 8293 that is recommended if the Multicast Service Node resides behind t= he NVE:
=C2=A0 =C2=A0In the case where a Multicast Service Node (= MSN) (as described in
=C2=A0 =C2=A0Section 3.3 of [RFC8293]) resides beh= ind an NVE, the mechanisms
=C2=A0 =C2=A0described in this document apply= and can, therefore, be used to test
=C2=A0 =C2=A0the connectivity from = the source NVE to the MSN.

- Why is echo BFD outside the scope of this document? Can I just turn
=C2=A0 on echo mode or will extra specifications be needed?
GIM>> The BFD Echo mode is underspecified in RFC 5880. To achie= ve interoperability we need to standardize it first.=C2=A0
--0000000000008fba59058a857d2b-- From nobody Tue Jun 4 13:40:54 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F5812060F; Tue, 4 Jun 2019 13:40:43 -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_HELO_NONE=0.001, 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 vnPAFzNv4eL9; Tue, 4 Jun 2019 13:40:40 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (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 6E8D912061B; Tue, 4 Jun 2019 13:40:40 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id 16so7446873ljv.10; Tue, 04 Jun 2019 13:40: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=OdnKdaJngQuot7pZALiG+PqQxJnthSeCa3nTqhA4Amw=; b=SN//33rSkjThjoUPmYs0sB5rcRUbhm61KQZZZuCVMp6Lxik4tOQA7F+ZJ1lHy2yZNx dkHYURiHNYUC2xLnLcBRHNCmdywuUszA/YepM+ma3VBQ8w6rrIH+Epb2QV6CTfrm0Vlr d2gO6rsjfoRrBWtPpz+INusnSWgaZfbREA5xobR8ekCCZrtceUTyN5wgZfiOCCWcUy6C BfYZLP13A9PsI9auZBwr+OQYKGgIPDFq78VQv4f8GcsLtsApVy1WXLMP/bM8pCNwUnNR 8KqYH3VJsJyF/vDDVtPq+VzOPKEG+Y6ViZZB3RU3frCarYjsJ/XZy0j48jW5syk95OwT P+AQ== 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=OdnKdaJngQuot7pZALiG+PqQxJnthSeCa3nTqhA4Amw=; b=nkdxhcB7MIuzyCF6P0z9nFmwLQxLymKRQ7XbwrN5T8n6+kcaeQl36bA0SAt7To2GLy 100KZ+0iuQu4H1mF4L/SlNC+PuNnl6EDG10wXkJ428eSzTTfjNfhwHv5UStkiJt6P0Fg msuH6IgXs3CGys4ug3yvYfJrDBcH9KnrtaYMcm74uRKCnc+aFK6xzGzqs7o+G7zmqwXR YPcq/Bca3p9PY5G5/6n1fZttZ5695jlenJa4B9tz7P6D1rmTZuRQremaEyjwak6nX+U4 fNehBvfJmFXv9uMbPGrTM243a3uOHzpz0Ojoyx9PCYci3MpB2z28KPENXs4bEU1Hzhig RvsA== X-Gm-Message-State: APjAAAVvlnSFLJSTwSbwUyTIensvagOKDLbX/mudMSiIl4h7Mpekcble lHzA6DIlvOxHE+u24jmqHXHFO3nhxOiI56wyxH7mHLz9 X-Google-Smtp-Source: APXvYqwvu7NiBWRB5nRpl9cBh6sFPQA+9z5z5rwbjsKGIk2QXm8bexHuX9jkW0xtGyqaaY9EMG88AGpK07QM3fHvECo= X-Received: by 2002:a2e:874b:: with SMTP id q11mr18164523ljj.48.1559680838656; Tue, 04 Jun 2019 13:40:38 -0700 (PDT) MIME-Version: 1.0 References: <155898931713.535.11384466531705238791@ietfa.amsl.com> In-Reply-To: <155898931713.535.11384466531705238791@ietfa.amsl.com> From: Greg Mirsky Date: Tue, 4 Jun 2019 13:40:26 -0700 Message-ID: Subject: Re: Genart last call review of draft-ietf-bfd-vxlan-07 To: Erik Kline Cc: gen-art@ietf.org, rtg-bfd WG , draft-ietf-bfd-vxlan.all@ietf.org, IETF list Content-Type: multipart/alternative; boundary="00000000000059e711058a857e91" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 20:40:53 -0000 --00000000000059e711058a857e91 Content-Type: text/plain; charset="UTF-8" Hi Erik, thank you for your review, pointed questions, and helpful suggestions. Please find responses in-lined tagged GIM>>. Regards, Greg On Mon, May 27, 2019 at 1:35 PM Erik Kline via Datatracker wrote: > Reviewer: Erik Kline > Review result: On the Right Track > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-bfd-vxlan-07 > Reviewer: Erik Kline > Review Date: 2019-05-27 > IETF LC End Date: 2019-05-31 > IESG Telechat date: Not scheduled for a telechat > > Summary: > > If my understanding is correct (which it may well not be), this document > places restrictions on the inner Ethernet and IP layer deployment that > previously may not have been present. > > My reading if this document is that the outer IP header and the inner IP > header have the same VTEP src and dst IPs. The outer and inner Ethernet > headers have the same source MAC and may have the same dst MAC. Is this > correct? > GIM>> I think that you're right in regard to IP headers. Because the VXLAN packet is routed at the Layer 3 and not switched on the Layer 2, the DA MAC of the outer Ethernet header is the MAC of the Next Hop underlay router, not of the VTEP. > > If so, this would mean that the VTEP's MAC address (or the special dest > MAC) > cannot be used within the VXLAN network (or at least not on the same host. > GIM>> The dedicated MAC is to be used only as of the DA MAC in the inner Ethernet frame that includes a BFD control message. > Similarly, it appears that the VTEP's IP addresses are no longer free to > be used within the encapsulated VXLAN VNI. Do I understand this correctly? > Was this always the case? > GIM>> I believe that this specification does not add any new restrictions on how VTEPs IP addresses may be used. > > If there is a document defining restrictions that VTEPs place on the > inner VXLAN segment, that might be good to reference. > > Failing that, I think I would like to see some discussion of alternatives > that were rejected with reasons behind their rejection. > GIM>> Alternative encapsulations of BFD control message in VXLAN? I don't recall such discussions because the presented encapsulation of a BFD control message in VXLAN is pretty much the only possible way to do that given that VXLAN supports only Ethernet frames as its native payload. Thus anything must be Ethernet-encapsulated in VXLAN tunnels. > > One possible solution might be to use "impossible" Ethernet addresses and > "impossible" IP addresses in the inner packet. For example, a source > IP address of all ones or all zeros would be very unlikely to ever be a > valid IP packet. I'm not 100% sure, but I suspect that a source MAC of > all ones would also never really be treated as valid. Clever use of > multicast IP and Ethernet addresses in the source fields might also be > sufficient to render the inner packet "invalid" in the sense that it would > never collide with legitimate traffic. > GIM>> Not using the real source IP address in the encapsulation of a BFD control message in VXLAN may create an attack vector and require an additional mechanism to bootstrap a BFD session between two VTEPs. > > If I have misread this document, or VTEPs are already placing constraints > on the inner VXLAN environment similar to those above, then this review > should instead be treated as "Ready with Nits". > > Major issues: > > Only my concern/misunderstanding described above. > > Minor issues: > > None. > > Nits/editorial comments: > > * The document generally does a really good job of Expanding Acronyms > At First Use (EAAFU) -- very much appreciated. In section 1 though, > NVE is used without accompanying expansion, I think. > GIM>> Thank you. Updated the working version with the added expansion as Network Virtualization Endpoint. > > * There is no 4.2 so maybe sections 4 and 4.1 could just be section 4. > GIM>> Agreed. Minor editorial changes to the first paragraph of Section 4. --00000000000059e711058a857e91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Erik,
thank you for your review, p= ointed questions, and helpful suggestions. Please find responses in-lined t= agged GIM>>.

Regards,
Greg

On= Mon, May 27, 2019 at 1:35 PM Erik Kline via Datatracker <noreply@ietf.org> wrote:
=
Reviewer: Erik Klin= e
Review result: On the Right Track

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.=C2=A0 Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq&g= t;.

Document: draft-ietf-bfd-vxlan-07
Reviewer: Erik Kline
Review Date: 2019-05-27
IETF LC End Date: 2019-05-31
IESG Telechat date: Not scheduled for a telechat

Summary:

If my understanding is correct (which it may well not be), this document places restrictions on the inner Ethernet and IP layer deployment that
previously may not have been present.

My reading if this document is that the outer IP header and the inner IP header have the same VTEP src and dst IPs.=C2=A0 The outer and inner Ethern= et
headers have the same source MAC and may have the same dst MAC. Is this
correct?
GIM>> I think that you're right in = regard to IP headers. Because the VXLAN packet is routed at the Layer 3 and= not switched on the Layer 2, the DA MAC of the outer Ethernet header is th= e MAC of the Next Hop underlay router, not of the VTEP.

If so, this would mean that the VTEP's MAC address (or the special dest= MAC)
cannot be used within the VXLAN network (or at least not on the same host.<= br>
GIM>> The dedicated MAC is to be used only as of= the DA MAC in the inner Ethernet frame that includes a BFD control message= .
=C2=A0
Similarly, it appears that the VTEP's IP addresses are no longer free t= o
be used within the encapsulated VXLAN VNI. Do I understand this correctly?<= br> Was this always the case?
GIM>> I believe that t= his specification does not add any new restrictions on how VTEPs IP address= es may be used.

If there is a document defining restrictions that VTEPs place on the
inner VXLAN segment, that might be good to reference.

Failing that, I think I would like to see some discussion of alternatives that were rejected with reasons behind their rejection.
GIM>> Alternative encapsulations of BFD control message in VXLAN? I= don't recall such discussions because the presented encapsulation of a= BFD control message in VXLAN is pretty much the only possible way to do th= at given that VXLAN supports only Ethernet frames as its native payload. Th= us anything must be Ethernet-encapsulated in VXLAN tunnels.=C2=A0

One possible solution might be to use "impossible" Ethernet addre= sses and
"impossible" IP addresses in the inner packet.=C2=A0 For example,= a source
IP address of all ones or all zeros would be very unlikely to ever be a
valid IP packet.=C2=A0 I'm not 100% sure, but I suspect that a source M= AC of
all ones would also never really be treated as valid.=C2=A0 Clever use of multicast IP and Ethernet addresses in the source fields might also be
sufficient to render the inner packet "invalid" in the sense that= it would
never collide with legitimate traffic.
GIM>> Not= using the real source IP address in the encapsulation of a BFD control mes= sage in VXLAN may create an attack vector and require an additional mechani= sm to bootstrap a BFD session between two VTEPs.

If I have misread this document, or VTEPs are already placing constraints on the inner VXLAN environment similar to those above, then this review
should instead be treated as "Ready with Nits".

Major issues:

Only my concern/misunderstanding described above.

Minor issues:

None.

Nits/editorial comments:

* The document generally does a really good job of Expanding Acronyms
=C2=A0 At First Use (EAAFU) -- very much appreciated. In section 1 though,<= br> =C2=A0 NVE is used without accompanying expansion, I think.
GIM>> Thank you. Updated the working version with the added exp= ansion as=C2=A0Network Virtualization Endpoint.

* There is no 4.2 so maybe sections 4 and 4.1 could just be section 4.
<= /blockquote>
GIM>> Agreed. Minor editorial changes to the first p= aragraph of Section 4.=C2=A0
--00000000000059e711058a857e91-- From nobody Tue Jun 4 17:36:06 2019 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C357C12003E; Tue, 4 Jun 2019 17:35:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-optimizing-authentication-08.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtg-bfd@ietf.org Message-ID: <155969495775.27982.17048401712516718558@ietfa.amsl.com> Date: Tue, 04 Jun 2019 17:35:57 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 00:35:58 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection WG of the IETF. Title : Optimizing BFD Authentication Authors : Mahesh Jethanandani Ashesh Mishra Ankur Saxena Manav Bhatia Filename : draft-ietf-bfd-optimizing-authentication-08.txt Pages : 7 Date : 2019-06-04 Abstract: This document describes an optimization to BFD Authentication as described in Section 6.7 of BFD RFC5880. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-optimizing-authentication-08 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-optimizing-authentication-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-optimizing-authentication-08 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 Wed Jun 5 02:40:58 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB1A12063C; Wed, 5 Jun 2019 02:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=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 yYrSq7Llh5Nn; Wed, 5 Jun 2019 02:40:38 -0700 (PDT) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 419E4120105; Wed, 5 Jun 2019 02:40:38 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id E7D3765C; Wed, 5 Jun 2019 11:40:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id oG71iHoSDlUG; Wed, 5 Jun 2019 11:40:35 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 5 Jun 2019 11:40:35 +0200 (CEST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id CCB2120129; Wed, 5 Jun 2019 11:40:35 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id ZRuXq7jwyAG6; Wed, 5 Jun 2019 11:40:35 +0200 (CEST) Received: from exchange.jacobs-university.de (SXCHMB02.jacobs.jacobs-university.de [10.70.0.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id 5520720128; Wed, 5 Jun 2019 11:40:35 +0200 (CEST) Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Wed, 5 Jun 2019 11:40:34 +0200 Received: by anna.localdomain (Postfix, from userid 501) id 719FA3009DB2C0; Wed, 5 Jun 2019 11:40:33 +0200 (CEST) Date: Wed, 5 Jun 2019 11:40:33 +0200 From: Juergen Schoenwaelder To: Greg Mirsky CC: , rtg-bfd WG , , IETF list Subject: Re: Opsdir last call review of draft-ietf-bfd-vxlan-07 Message-ID: <20190605094033.g25ailxjsrhmy4i7@anna.jacobs.jacobs-university.de> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Greg Mirsky , ops-dir@ietf.org, rtg-bfd WG , draft-ietf-bfd-vxlan.all@ietf.org, IETF list References: <155842371303.2459.12357511675299405749@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 X-ClientProxiedBy: SXCHMB04.jacobs.jacobs-university.de (10.70.0.156) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155) X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 09:40:42 -0000 On Tue, Jun 04, 2019 at 01:40:13PM -0700, Greg Mirsky wrote: > Hi Jurgen, > thank you for your review, detailed and precise questions. Please find = my > answers in-line and tagged GIM>>. >=20 > Regards, > Greg >=20 > On Tue, May 21, 2019 at 12:28 AM J=FCrgen Sch=F6nw=E4lder via Datatrack= er < > noreply@ietf.org> wrote: >=20 > > Reviewer: J=FCrgen Sch=F6nw=E4lder > > Review result: Has Issues > > > > I only have a very limited understanding of VXLAN ands BFD technology= . > > Hence, some of my question may look odd to the insiders. > > > > - RFC 7348 defining VXLAN is informational, why would BFD for VXLAN b= e > > standards track? > > > GIM>> That has been somewhat of the way to bring the de-facto standard = into > the IETF standardization process. I leave this to the IESG. =20 > - Section 2.1 "Terminology" expands acronyms but it does say where > > these "terms" are actually defined. Some pointers to the relevant > > RFCs may be useful. > > > GIM>> That might be useful, thank you. But, AFAIK, at IETF that is not = the > traditional format (though I know that other SDOs refer to the source o= f > the definition used in the document.) Perhaps conventions different between different parts of the IETF, as a review, I find it helpful to know where things are actually defined (and I assume the same is true for implementors). > > - I am not familiar with VXLAN but I wonder how the endpoints > > addresses are obtained in practice. This BFD document says for > > example "The details of how the MAC address of the destination VTEP > > is obtained are outside the scope of this document." Well, OK, but > > how does this work? Is there a document where this is explained? > > Well, I am actually less concerned about how the inner address is > > obtained, I think I am more urgently missing how the VTEP determine= s > > the remote tunnel endpoint address. > > > GIM>> One of the ways could be through exchange of the BFD packets when= the > DA MAC is the dedicated MAC. More on that below. >=20 > > > > - Why do you need a special MAC address? The text says I can use this > > address or the address of the destination VTEP but there is no > > reasoning when to use what or why a dedicated address is needed. > > > GIM> Would the following text added at the end of Section 4.1 address y= our > question: > NEW TEXT: > The use of the dedicated MAC allows starting BFD session before > learning the MAC address of the remote VTEP. As a result, after the > BFD session has reached the Up state the operational state of the > VXLAN tunnel to may be set to Up. Not sure I managed to parse the second sentence. So is the idea that the dedicated MAC address is only do be used until the MAC address has been discovered? But yes, any text that helps readers to understand this is appreciated. > > - What is a 'reasonable upper bound' on the number of BFD sessions > > that can be created between the same pair of VTEPs? 1? 2? 8? 64? > > 256? 4096? How does the choice of this upper bound impact security? > > > GIM>> I agree, that is too vague. Would changing the text to recommend > that the control mechanism be provided if multiple BFD sessions between= the > same piar of VTEP allowed: > OLD TEXT: > The implementation SHOULD have a reasonable upper bound on the numbe= r > of BFD sessions that can be created between the same pair of VTEPs. > NEW TEXT: > If the implementation supports establishing multiple BFD sessions > between the same pair of VTEPs, there SHOULD be a mechanism to contr= ol > the maximum number of such session that can be active at the same > time. Works for me. I read this as "the maximum number of such session should be configurable", which is great advice for implementors. > > - Which BFD mode is assumed to be used, asynchronous or demand? Or > > does this not matter for this usage of BFD, i.e., both work just > > fine and will be interoperable? > > > GIM>> For p2p VXLAN tunnel, the Asynchronous mode of BFD is recommended= : > The asynchronous mode of BFD, as defined in [RFC5880], > can be used to monitor a p2p VXLAN tunnel. > The Demand mode is used in RFC 8293 that is recommended if the Multicas= t > Service Node resides behind the NVE: > In the case where a Multicast Service Node (MSN) (as described in > Section 3.3 of [RFC8293]) resides behind an NVE, the mechanisms > described in this document apply and can, therefore, be used to test > the connectivity from the source NVE to the MSN. Perhaps say more explicitely that in the Multicast Service Node case, demand mode of BFD is used? =20 > > > > - Why is echo BFD outside the scope of this document? Can I just turn > > on echo mode or will extra specifications be needed? > > > GIM>> The BFD Echo mode is underspecified in RFC 5880. To achieve > interoperability we need to standardize it first. OK /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Jun 5 14:21:27 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A866F12004C; Wed, 5 Jun 2019 14:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 d1utVarKOTIz; Wed, 5 Jun 2019 14:21:17 -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 B75CE120159; Wed, 5 Jun 2019 14:21:11 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id v18so3359699ljh.6; Wed, 05 Jun 2019 14:21:11 -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=GDFhfx2GqmeQsn9DWlq0Y7KHs3tfmJPIfcJHJ1d3APc=; b=KsmIDSFyhhkFQ8cBIUSDi5zCjdTkG12EBUwHeA+TGXHN+7SzBch6jQNuqER9bvDxd6 5GwwLxM3Ac35+ifk+jHhRj6vIdrtBJDn4Ly5sx4Je2Pqw6aUlpiiW5VNjxMgNK26BCxi aurwOQmU9/7qJFVYEzsniZjtK+XdixLeOYsGB8i6amG2teK+lZOa5HFBx9cP60Qb3WXz 8T8tKM8bIh3Yp/PGFuMogsnMKkvdmI88t3/x5XO5cbqMPUdXqSWBj0IfRjZSsvklnfGe AZdfKsQ+kG5M9d09VMuVTZviEPfrP4nIaZlVd5gX5XSECbNZ7ZVtyj7OQpVbgoyjzE6b S5Fg== 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=GDFhfx2GqmeQsn9DWlq0Y7KHs3tfmJPIfcJHJ1d3APc=; b=GZgvhF40h8+Ep3U1U0PhOvyyx6d5V1gpvEYOpEIh9m/5nFSuI6SymyLKWwGFlEXcEh MOLNG7S9o6JaMdxT8C30bPghFXqLgFWF47mP5T20QAL82hQc0lDvidAgdb2KWLdXVLmg QVsVDIk6k1j0nSAXMiX8XK400LfZozRxK7zHkYPgvwk679Y0dzBQW9GqyvZFudTRHl4g YvFqCZ8MBgXSDRPwGIWjzdUydBYCro+KMbMjlB67lMEax7Loc8B7hn4XOQy681IuvvNb 1bhV8N8cpXXhouTldho04S6wHUkahYA++iND4wkrgWCoe9eqTfbR0ksKIdtJiSvlRJsZ VolA== X-Gm-Message-State: APjAAAXsNjbgrSv3//prg8iq0rDhn04r4ziaBgTrqBOZB8+54kulE8m4 3NGRu9JU6+cpgpCONt7VtmOduCxp0tUJQJQ/AtA4Y1Xu7DD1uw== X-Google-Smtp-Source: APXvYqzfIfWbrg1Y2BFt5jBjuFJ0x46qfyWi27WN1v7esEF2uHcWhRySirUDvb0IH8C3mi6TwbdLcvkOLHMASsK7v1c= X-Received: by 2002:a2e:56dd:: with SMTP id k90mr9773800lje.204.1559769669918; Wed, 05 Jun 2019 14:21:09 -0700 (PDT) MIME-Version: 1.0 References: <155864919758.8626.11137277913302380197@ietfa.amsl.com> In-Reply-To: <155864919758.8626.11137277913302380197@ietfa.amsl.com> From: Greg Mirsky Date: Wed, 5 Jun 2019 14:20:57 -0700 Message-ID: Subject: Re: Rtgdir last call review of draft-ietf-bfd-vxlan-07 To: Joel Halpern Cc: rtg-dir@ietf.org, rtg-bfd WG , draft-ietf-bfd-vxlan.all@ietf.org, IETF list Content-Type: multipart/alternative; boundary="0000000000001b6635058a9a2d4d" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 21:21:20 -0000 --0000000000001b6635058a9a2d4d Content-Type: text/plain; charset="UTF-8" Hi Joel, thank you for your review and the pointed questions. Please find my answers, comments in-line and tagged GIM>>. Regards, Greg On Thu, May 23, 2019 at 3:06 PM Joel Halpern via Datatracker < noreply@ietf.org> wrote: > Reviewer: Joel Halpern > Review result: Has Issues > > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The > Routing Directorate seeks to review all routing or routing-related drafts > as > they pass through IETF last call and IESG review, and sometimes on special > request. The purpose of the review is to provide assistance to the Routing > ADs. > For more information about the Routing Directorate, please see > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, it > would > be helpful if you could consider them along with any other IETF Last Call > comments that you receive, and strive to resolve them through discussion > or by > updating the draft. > > Document: ddraft-ietf-bfd-vxlan-07 > Reviewer: your-name > Review Date: date > IETF LC End Date: date-if-known > Intended Status: copy-from-I-D > > Summary: This document does not appear to be ready for publication as a > Proposed Standard RFC. > > Major issues: > The scoping of the BFD usage is unclear. In places, this looks like > it is > intended to be used by the underlay service provider, who will > monitor the > connectivity between VTEPs. GIM>> I think that the DCI provider would not be able to instantiate a BFD session using VXLAN encapsulation and, possibly, monitor that VXLAN part of forwarding operates properly. Such BFD session may monitor the path between the two VTEP but, if there exists ECMP environment in the transport, ensuring that that BFD session follows the same path as VXLAN data may be challenging. > In other places it seems to be aimed at > monitoring individual VNIs. GIM>> The BFD session between VTEPs is not actually used to monitor the particular VNI but MAY be used to communicate, as concatenated path state signaling, the change of VNI state using the method described in Section 6.8.17 RFC 5880 . > This is made worse when the packet format is > laid out. The inner packet is an Ethernet Packet with an IP packet > (with > UDP, with BFD). This means that it is a tenant packet. GIM>> Could you please point to the text which suggests that the BFD control packet is a tenant packet? Meant to be delivered to a tenant? > The IP address is > a tenant IP. GIM>> The explanation of the format states in regard to the inner IP header: IP header: Source IP: IP address of the originating VTEP. Destination IP: IP address of the terminating VTEP. But the diagram shows this as being the IP address of the > VTEP. Which is not a tenant entity. > > There is further confusion as to whether the processing is driven by > the VNI > the packet arrived with, or the VNI is ignored. > GIM>> The use of VNI is implementation specific. Section 6 states: 6. Use of the Specific VNI In most cases, a single BFD session is sufficient for the given VTEP to monitor the reachability of a remote VTEP, regardless of the number of VNIs in common. When the single BFD session is used to monitor the reachability of the remote VTEP, an implementation SHOULD choose any of the VNIs but MAY choose VNI = 0. > > > Minor Issues: > N/A > > Nits: N/A > > --0000000000001b6635058a9a2d4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Joel,
thank you for your revi= ew and the pointed questions. Please find my answers, comments in-line and = tagged GIM>>.

Regards,
Greg


On Thu, May 23, 2019 at 3:06 PM Joel Halpern via Datatrac= ker <noreply@ietf.org> wrote:=
Reviewer: Joel = Halpern
Review result: Has Issues

Hello,

I have been selected as the Routing Directorate reviewer for this draft. Th= e
Routing Directorate seeks to review all routing or routing-related drafts a= s
they pass through IETF last call and IESG review, and sometimes on special<= br> request. The purpose of the review is to provide assistance to the Routing = ADs.
For more information about the Routing Directorate, please see
http://trac.tools.ietf.org/area/rtg/trac/wiki/Rt= gDir

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

Document: ddraft-ietf-bfd-vxlan-07
Reviewer: your-name
Review Date: date
IETF LC End Date: date-if-known
Intended Status: copy-from-I-D

Summary: This document does not appear to be ready for publication as a
Proposed Standard RFC.

Major issues:
=C2=A0 =C2=A0 The scoping of the BFD usage is unclear.=C2=A0 In places, thi= s looks like it is
=C2=A0 =C2=A0 intended to be used by the underlay service provider,=C2=A0 w= ho will monitor the
=C2=A0 =C2=A0 connectivity between VTEPs.=C2=A0
GIM>&g= t; I think that the DCI provider would not be able to instantiate a BFD ses= sion using VXLAN encapsulation and, possibly, monitor that VXLAN part of fo= rwarding operates properly. Such BFD session may monitor the path between t= he two VTEP but, if there exists ECMP environment in the transport, ensurin= g that that BFD session follows the same path as VXLAN data may be challeng= ing.=C2=A0
In other = places it seems to be aimed at
=C2=A0 =C2=A0 monitoring individual VNIs.
GIM>> The= BFD session between VTEPs is not actually used to monitor the particular V= NI but MAY be used to communicate, as concatenated path state signaling, th= e change of VNI state using the method described in Section 6.8.17 RFC 5880.=C2=A0<= /div>
This is made worse w= hen the packet format is
=C2=A0 =C2=A0 laid out.=C2=A0 The inner packet is an Ethernet Packet with a= n IP packet (with
=C2=A0 =C2=A0 UDP, with BFD).=C2=A0 This means that it is a tenant packet.= =C2=A0
GIM>> Could you please point to the text whic= h suggests that the BFD control packet is a tenant packet? Meant to be deli= vered to a tenant?=C2=A0
The IP address is
=C2=A0 =C2=A0 a tenant IP.=C2=A0
GIM>> The explanat= ion of the format states in regard to the inner IP header:
=C2=A0= =C2=A0 =C2=A0 =C2=A0IP header:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Source IP: IP address of the originating VTEP.

=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Destination IP: IP address of the terminating VTEP.

But the diagram shows this as being the IP address of the
=C2=A0 =C2=A0 VTEP.=C2=A0 Which is not a tenant entity.
=C2=A0
=C2=A0 =C2=A0There is further confusion as to whether the processing is dri= ven by the VNI
=C2=A0 =C2=A0the packet arrived with, or the VNI is ignored.
GIM>> The use of VNI is implementation specific. Section 6 sta= tes:
=C2=A06.=C2=A0 Use of the Specific VNI

=C2=A0 =C2= =A0In most cases, a single BFD session is sufficient for the given VTEP
= =C2=A0 =C2=A0to monitor the reachability of a remote VTEP, regardless of th= e
=C2=A0 =C2=A0number of VNIs in common.=C2=A0 When the single BFD sessi= on is used to
=C2=A0 =C2=A0monitor the reachability of the remote VTEP, = an implementation SHOULD
=C2=A0 =C2=A0choose any of the VNIs but MAY cho= ose VNI =3D 0.

Minor Issues:
=C2=A0 =C2=A0N/A

Nits: N/A

--0000000000001b6635058a9a2d4d-- From nobody Wed Jun 5 14:48:03 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E43A12009E; Wed, 5 Jun 2019 14:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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=joelhalpern.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 A__qTXbEvuWL; Wed, 5 Jun 2019 14:47:51 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 41CA412008B; Wed, 5 Jun 2019 14:47:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 45K2TL6bB2z1rq6f; Wed, 5 Jun 2019 14:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1559771270; bh=INLPkialerR+o9HUBMTp7zdvlHZ/laBnllZk7Mk4eQM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=VBJvw8YDVpsdDdUQJW8l0SzpUCuxCmbPOw9eNKYmrV04KuuFPEat5V0OaiopGK9kj ogBhkGYxs1LT4wiNEzRGE2XGvkeFPCUePhKWs396987zQa75njPBspNbwrb+x49T4a Y0GSATrbo9GInGu1zv7X2u2XXhMuyb3DEymNBlYQ= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 45K2TL0Nbtz1rq6X; Wed, 5 Jun 2019 14:47:49 -0700 (PDT) Subject: Re: Rtgdir last call review of draft-ietf-bfd-vxlan-07 To: Greg Mirsky Cc: rtg-dir@ietf.org, rtg-bfd WG , draft-ietf-bfd-vxlan.all@ietf.org, IETF list References: <155864919758.8626.11137277913302380197@ietfa.amsl.com> From: "Joel M. Halpern" Message-ID: <98825f67-6958-8845-d5d5-3e0ac5e996e1@joelhalpern.com> Date: Wed, 5 Jun 2019 17:47:49 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 21:47:54 -0000 The inner packet of a VxLAN header with a VNI is a tenant packet for the tenant identified by the VNI. That is the meaning of the inner packet. If you declare that the flag bits change that meaning, then that flag bit has to adjust the packet processing at the VTEP such taht it will intercept the packet. As such, it doesn;t need special inner source or dest mac addresses or IP addresses. In fact, the inner packet can just be OAM payload. If that is not what you intend, then how is it that the VTEP knows that the inner addresses are for it to examine, rather than belonging to the tenant. As far as I know we are not free to take addresses away from the tenant. It may be that I am completely missing how this is supposed to work. If so, it needs better explanation. Yours, Joel On 6/5/19 5:20 PM, Greg Mirsky wrote: > Hi Joel, > thank you for your review and the pointed questions. Please find my > answers, comments in-line and tagged GIM>>. > > Regards, > Greg > > > On Thu, May 23, 2019 at 3:06 PM Joel Halpern via Datatracker > > wrote: > > Reviewer: Joel Halpern > Review result: Has Issues > > Hello, > > I have been selected as the Routing Directorate reviewer for this > draft. The > Routing Directorate seeks to review all routing or routing-related > drafts as > they pass through IETF last call and IESG review, and sometimes on > special > request. The purpose of the review is to provide assistance to the > Routing ADs. > For more information about the Routing Directorate, please see > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing > ADs, it would > be helpful if you could consider them along with any other IETF Last > Call > comments that you receive, and strive to resolve them through > discussion or by > updating the draft. > > Document: ddraft-ietf-bfd-vxlan-07 > Reviewer: your-name > Review Date: date > IETF LC End Date: date-if-known > Intended Status: copy-from-I-D > > Summary: This document does not appear to be ready for publication as a > Proposed Standard RFC. > > Major issues: >     The scoping of the BFD usage is unclear.  In places, this looks > like it is >     intended to be used by the underlay service provider,  who will > monitor the >     connectivity between VTEPs. > > GIM>> I think that the DCI provider would not be able to instantiate a > BFD session using VXLAN encapsulation and, possibly, monitor that VXLAN > part of forwarding operates properly. Such BFD session may monitor the > path between the two VTEP but, if there exists ECMP environment in the > transport, ensuring that that BFD session follows the same path as VXLAN > data may be challenging. > > In other places it seems to be aimed at >     monitoring individual VNIs. > > GIM>> The BFD session between VTEPs is not actually used to monitor the > particular VNI but MAY be used to communicate, as concatenated path > state signaling, the change of VNI state using the method described in > Section 6.8.17 RFC 5880 > . > > This is made worse when the packet format is >     laid out.  The inner packet is an Ethernet Packet with an IP > packet (with >     UDP, with BFD).  This means that it is a tenant packet. > > GIM>> Could you please point to the text which suggests that the BFD > control packet is a tenant packet? Meant to be delivered to a tenant? > > The IP address is >     a tenant IP. > > GIM>> The explanation of the format states in regard to the inner IP header: >        IP header: > >          Source IP: IP address of the originating VTEP. > >          Destination IP: IP address of the terminating VTEP. > > But the diagram shows this as being the IP address of the >     VTEP.  Which is not a tenant entity. > >    There is further confusion as to whether the processing is > driven by the VNI >    the packet arrived with, or the VNI is ignored. > > GIM>> The use of VNI is implementation specific. Section 6 states: >  6.  Use of the Specific VNI > >    In most cases, a single BFD session is sufficient for the given VTEP >    to monitor the reachability of a remote VTEP, regardless of the >    number of VNIs in common.  When the single BFD session is used to >    monitor the reachability of the remote VTEP, an implementation SHOULD >    choose any of the VNIs but MAY choose VNI = 0. > > > Minor Issues: >    N/A > > Nits: N/A > From nobody Wed Jun 5 18:56:07 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BB42120148; Wed, 5 Jun 2019 18:55:58 -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_HELO_NONE=0.001, 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 sz4K2jZd-FoO; Wed, 5 Jun 2019 18:55:55 -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 C74BE120130; Wed, 5 Jun 2019 18:55:54 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id v18so446175ljh.6; Wed, 05 Jun 2019 18:55:54 -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=RdZXByvPbjW9iuktL1dJ9lzp9sCzQSmGjGA2S8ccPiY=; b=GctEbuhMNorSezERch64qze2nFx3uyGmxnpxl4426pjHSJyC5jFDVRBJjpqyeVgC96 dxAHL0j2GIBE+wiHRaqUY7O40Z5U2bDfx+88+THwHOwzZ38BZum4/UHl/Fiz0dVGb3nn QXA4kDr0ab0CrZeQQKjCN3WUDeD7a5D+yY+aaYwHOO2yXnM4JYlyRXImcsZg57tQMezY 6iFzC7/roaCdNEouwfHKL23zcMst2UXxZdbcIy5EmmIAqn+jct39N7BuEv6K9oCbMUVh JGD5ylrjkJxCm5woC//vwpxO1GqmLVxIqss9UExkACWjLc8HNeU/Cjob3adBUPNYHVcD c2Tg== 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=RdZXByvPbjW9iuktL1dJ9lzp9sCzQSmGjGA2S8ccPiY=; b=kNhPo0iS7dgTve42gUeNhy1xvakNG2mCE9DWCLRk1Na7ig4pGj1DlkJnTfzYOrBoJn R4JwJK/5BOAwEFpiLy8aYqF3WB6tav8gi3Wy9zx06cBjMR2rwxTJhVYb0Ai2YulI1tuD rNL2Yalhb80LiNGrp3BOm8jiOuzmADCV/qnx9yxu3ZHS9QUF7hQQPbPHyATqOCMKRhKO 4TMPIU1kp30mUQnSfAZoBHpVBPwtfWc51IadAZ9UAR0q+xdlVDQWZ26iTdDKJ2zD0ezA ylwzmHefF2L9x1Y1RVSuw7wGOy8MiRyYTssLm4TnLN97G5JU3d9lkYj0dyBTcK7Ir4rH pXig== X-Gm-Message-State: APjAAAXUiue4Ea9MU92wR5IwxLzrmF8uUEyTiEHZ7rlvQiUuIRNKWyvY uJr02dyrFd8RC/qx4uR2AiUlTDiRfWWcwVBPuObHgCOnX9EWEQ== X-Google-Smtp-Source: APXvYqy9XH/ATJO8yrpGa3KMlIyvKUE4mN2z8n0MShS1nsjYpoCb+o3DOLfphHunImcgelmtu8V1KFIpohFaIW0IJJY= X-Received: by 2002:a2e:96c3:: with SMTP id d3mr11250883ljj.68.1559786152870; Wed, 05 Jun 2019 18:55:52 -0700 (PDT) MIME-Version: 1.0 References: <155864919758.8626.11137277913302380197@ietfa.amsl.com> <98825f67-6958-8845-d5d5-3e0ac5e996e1@joelhalpern.com> In-Reply-To: <98825f67-6958-8845-d5d5-3e0ac5e996e1@joelhalpern.com> From: Greg Mirsky Date: Wed, 5 Jun 2019 18:55:42 -0700 Message-ID: Subject: Re: Rtgdir last call review of draft-ietf-bfd-vxlan-07 To: "Joel M. Halpern" Cc: rtg-dir@ietf.org, rtg-bfd WG , draft-ietf-bfd-vxlan.all@ietf.org, IETF list Content-Type: multipart/alternative; boundary="0000000000009146e9058a9e0352" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 01:55:58 -0000 --0000000000009146e9058a9e0352 Content-Type: text/plain; charset="UTF-8" Hi Joel, I cannot find the text in RFC 7348 that suggests that any VXLAN-encapsulated frame received by VTEP must be forwarded to a VM associated with the specified VNI. But I've found the text in section 4.1 that makes the forwarding of the inner frame to VM conditional to the destination MAC address matching to VM's MAC: Upon reception, the remote VTEP verifies the validity of the VNI and whether or not there is a VM on that VNI using a MAC address that matches the inner destination MAC address. If so, the packet is stripped of its encapsulating headers and passed on to the destination VM. BFD over VXLAN specification in section 5 clarifies the processing of the received VXLAN packet by the remote VXLAN: Once a packet is received, VTEP MUST validate the packet. If the Destination MAC of the inner MAC frame matches the MAC address of the VTEP the packet MUST be processed further. The UDP destination port and the TTL of the inner IP packet MUST be validated to determine if the received packet can be processed by BFD. BFD packet with inner MAC set to VTEP's MAC address MUST NOT be forwarded to VMs. Would this text address your concern? Regards, Greg On Wed, Jun 5, 2019 at 2:47 PM Joel M. Halpern wrote: > The inner packet of a VxLAN header with a VNI is a tenant packet for the > tenant identified by the VNI. That is the meaning of the inner packet. > > If you declare that the flag bits change that meaning, then that flag > bit has to adjust the packet processing at the VTEP such taht it will > intercept the packet. As such, it doesn;t need special inner source or > dest mac addresses or IP addresses. In fact, the inner packet can just > be OAM payload. > > If that is not what you intend, then how is it that the VTEP knows that > the inner addresses are for it to examine, rather than belonging to the > tenant. As far as I know we are not free to take addresses away from > the tenant. > > It may be that I am completely missing how this is supposed to work. If > so, it needs better explanation. > > Yours, > Joel > > On 6/5/19 5:20 PM, Greg Mirsky wrote: > > Hi Joel, > > thank you for your review and the pointed questions. Please find my > > answers, comments in-line and tagged GIM>>. > > > > Regards, > > Greg > > > > > > On Thu, May 23, 2019 at 3:06 PM Joel Halpern via Datatracker > > > wrote: > > > > Reviewer: Joel Halpern > > Review result: Has Issues > > > > Hello, > > > > I have been selected as the Routing Directorate reviewer for this > > draft. The > > Routing Directorate seeks to review all routing or routing-related > > drafts as > > they pass through IETF last call and IESG review, and sometimes on > > special > > request. The purpose of the review is to provide assistance to the > > Routing ADs. > > For more information about the Routing Directorate, please see > > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > > > Although these comments are primarily for the use of the Routing > > ADs, it would > > be helpful if you could consider them along with any other IETF Last > > Call > > comments that you receive, and strive to resolve them through > > discussion or by > > updating the draft. > > > > Document: ddraft-ietf-bfd-vxlan-07 > > Reviewer: your-name > > Review Date: date > > IETF LC End Date: date-if-known > > Intended Status: copy-from-I-D > > > > Summary: This document does not appear to be ready for publication > as a > > Proposed Standard RFC. > > > > Major issues: > > The scoping of the BFD usage is unclear. In places, this looks > > like it is > > intended to be used by the underlay service provider, who will > > monitor the > > connectivity between VTEPs. > > > > GIM>> I think that the DCI provider would not be able to instantiate a > > BFD session using VXLAN encapsulation and, possibly, monitor that VXLAN > > part of forwarding operates properly. Such BFD session may monitor the > > path between the two VTEP but, if there exists ECMP environment in the > > transport, ensuring that that BFD session follows the same path as VXLAN > > data may be challenging. > > > > In other places it seems to be aimed at > > monitoring individual VNIs. > > > > GIM>> The BFD session between VTEPs is not actually used to monitor the > > particular VNI but MAY be used to communicate, as concatenated path > > state signaling, the change of VNI state using the method described in > > Section 6.8.17 RFC 5880 > > . > > > > This is made worse when the packet format is > > laid out. The inner packet is an Ethernet Packet with an IP > > packet (with > > UDP, with BFD). This means that it is a tenant packet. > > > > GIM>> Could you please point to the text which suggests that the BFD > > control packet is a tenant packet? Meant to be delivered to a tenant? > > > > The IP address is > > a tenant IP. > > > > GIM>> The explanation of the format states in regard to the inner IP > header: > > IP header: > > > > Source IP: IP address of the originating VTEP. > > > > Destination IP: IP address of the terminating VTEP. > > > > But the diagram shows this as being the IP address of the > > VTEP. Which is not a tenant entity. > > > > There is further confusion as to whether the processing is > > driven by the VNI > > the packet arrived with, or the VNI is ignored. > > > > GIM>> The use of VNI is implementation specific. Section 6 states: > > 6. Use of the Specific VNI > > > > In most cases, a single BFD session is sufficient for the given VTEP > > to monitor the reachability of a remote VTEP, regardless of the > > number of VNIs in common. When the single BFD session is used to > > monitor the reachability of the remote VTEP, an implementation SHOULD > > choose any of the VNIs but MAY choose VNI = 0. > > > > > > Minor Issues: > > N/A > > > > Nits: N/A > > > --0000000000009146e9058a9e0352 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joel,
I cannot find the text in RFC 7348 that sugge= sts that any VXLAN-encapsulated frame received by VTEP must be forwarded to= a VM associated with the specified VNI. But I've found the text in sec= tion 4.1 that makes the forwarding of the inner frame to VM conditional to = the destination MAC address matching to VM's MAC:
=C2=A0 =C2= =A0Upon reception, the remote VTEP
=C2=A0 =C2=A0verifies the validity of= the VNI and whether or not there is a VM on
=C2=A0 =C2=A0that VNI using= a MAC address that matches the inner destination MAC
=C2=A0 =C2=A0addre= ss.=C2=A0 If so, the packet is stripped of its encapsulating headers
=C2= =A0 =C2=A0and passed on to the destination VM.
BFD over VXLAN= specification in section 5 clarifies the processing of the received VXLAN = packet by the remote VXLAN:
=C2=A0 =C2=A0Once a packet is receive= d, VTEP MUST validate the packet.=C2=A0 If the
=C2=A0 =C2=A0Destination = MAC of the inner MAC frame matches the MAC address of the
=C2=A0 =C2=A0V= TEP the packet MUST be processed further.

=C2=A0 =C2=A0The UDP desti= nation port and the TTL of the inner IP packet MUST be
=C2=A0 =C2=A0vali= dated to determine if the received packet can be processed by
=C2=A0 =C2= =A0BFD.=C2=A0 BFD packet with inner MAC set to VTEP's MAC address MUST = NOT be
=C2=A0 =C2=A0forwarded to VMs.
Would this text addr= ess your concern?

Regards,
Greg

On = Wed, Jun 5, 2019 at 2:47 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:
The inner packet of a VxLAN header with a = VNI is a tenant packet for the
tenant identified by the VNI.=C2=A0 That is the meaning of the inner packet= .

If you declare that the flag bits change that meaning, then that flag
bit has to adjust the packet processing at the VTEP such taht it will
intercept the packet.=C2=A0 As such, it doesn;t need special inner source o= r
dest mac addresses or IP addresses.=C2=A0 In fact, the inner packet can jus= t
be OAM payload.

If that is not what you intend, then how is it that the VTEP knows that the inner addresses are for it to examine, rather than belonging to the tenant.=C2=A0 As far as I know we are not free to take addresses away from =
the tenant.

It may be that I am completely missing how this is supposed to work.=C2=A0 = If
so, it needs better explanation.

Yours,
Joel

On 6/5/19 5:20 PM, Greg Mirsky wrote:
> Hi=C2=A0Joel,
> thank you for your review and the pointed questions. Please find my > answers, comments in-line and tagged GIM>>.
>
> Regards,
> Greg
>
>
> On Thu, May 23, 2019 at 3:06 PM Joel Halpern via Datatracker
> <noreply@ietf= .org <mailto:n= oreply@ietf.org>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Reviewer: Joel Halpern
>=C2=A0 =C2=A0 =C2=A0Review result: Has Issues
>
>=C2=A0 =C2=A0 =C2=A0Hello,
>
>=C2=A0 =C2=A0 =C2=A0I have been selected as the Routing Directorate rev= iewer for this
>=C2=A0 =C2=A0 =C2=A0draft. The
>=C2=A0 =C2=A0 =C2=A0Routing Directorate seeks to review all routing or = routing-related
>=C2=A0 =C2=A0 =C2=A0drafts as
>=C2=A0 =C2=A0 =C2=A0they pass through IETF last call and IESG review, a= nd sometimes on
>=C2=A0 =C2=A0 =C2=A0special
>=C2=A0 =C2=A0 =C2=A0request. The purpose of the review is to provide as= sistance to the
>=C2=A0 =C2=A0 =C2=A0Routing ADs.
>=C2=A0 =C2=A0 =C2=A0For more information about the Routing Directorate,= please see
>=C2=A0 =C2=A0 =C2=A0http://trac.tools.ietf.o= rg/area/rtg/trac/wiki/RtgDir
>
>=C2=A0 =C2=A0 =C2=A0Although these comments are primarily for the use o= f the Routing
>=C2=A0 =C2=A0 =C2=A0ADs, it would
>=C2=A0 =C2=A0 =C2=A0be helpful if you could consider them along with an= y other IETF Last
>=C2=A0 =C2=A0 =C2=A0Call
>=C2=A0 =C2=A0 =C2=A0comments that you receive, and strive to resolve th= em through
>=C2=A0 =C2=A0 =C2=A0discussion or by
>=C2=A0 =C2=A0 =C2=A0updating the draft.
>
>=C2=A0 =C2=A0 =C2=A0Document: ddraft-ietf-bfd-vxlan-07
>=C2=A0 =C2=A0 =C2=A0Reviewer: your-name
>=C2=A0 =C2=A0 =C2=A0Review Date: date
>=C2=A0 =C2=A0 =C2=A0IETF LC End Date: date-if-known
>=C2=A0 =C2=A0 =C2=A0Intended Status: copy-from-I-D
>
>=C2=A0 =C2=A0 =C2=A0Summary: This document does not appear to be ready = for publication as a
>=C2=A0 =C2=A0 =C2=A0Proposed Standard RFC.
>
>=C2=A0 =C2=A0 =C2=A0Major issues:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The scoping of the BFD usage is uncl= ear.=C2=A0 In places, this looks
>=C2=A0 =C2=A0 =C2=A0like it is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 intended to be used by the underlay = service provider,=C2=A0 who will
>=C2=A0 =C2=A0 =C2=A0monitor the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 connectivity between VTEPs.
>
> GIM>> I think that the DCI provider would not be able to instant= iate a
> BFD session using VXLAN encapsulation and, possibly, monitor that VXLA= N
> part of forwarding operates properly. Such BFD session may monitor the=
> path between the two VTEP but, if there exists ECMP environment in the=
> transport, ensuring that that BFD session follows the same path as VXL= AN
> data may be challenging.
>
>=C2=A0 =C2=A0 =C2=A0In other places it seems to be aimed at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 monitoring individual VNIs.
>
> GIM>> The BFD session between VTEPs is not actually used to moni= tor the
> particular VNI but MAY be used to communicate, as concatenated path > state signaling, the change of VNI state using the method described in=
> Section 6.8.17 RFC 5880
> <https://tools.ietf.org/html/rfc5880#secti= on-6.8.17>.
>
>=C2=A0 =C2=A0 =C2=A0This is made worse when the packet format is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 laid out.=C2=A0 The inner packet is = an Ethernet Packet with an IP
>=C2=A0 =C2=A0 =C2=A0packet (with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 UDP, with BFD).=C2=A0 This means tha= t it is a tenant packet.
>
> GIM>> Could you please point to the text which suggests that the= BFD
> control packet is a tenant packet? Meant to be delivered to a tenant?<= br> >
>=C2=A0 =C2=A0 =C2=A0The IP address is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a tenant IP.
>
> GIM>> The explanation of the format states in regard to the inne= r IP header:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IP header:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Source IP: IP address of the o= riginating VTEP.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Destination IP: IP address of = the terminating VTEP.
>
>=C2=A0 =C2=A0 =C2=A0But the diagram shows this as being the IP address = of the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 VTEP.=C2=A0 Which is not a tenant en= tity.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0There is further confusion as to whet= her the processing is
>=C2=A0 =C2=A0 =C2=A0driven by the VNI
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the packet arrived with, or the VNI i= s ignored.
>
> GIM>> The use of VNI is implementation specific. Section 6 state= s:
>=C2=A0 =C2=A06.=C2=A0 Use of the Specific VNI
>
>=C2=A0 =C2=A0 =C2=A0In most cases, a single BFD session is sufficient f= or the given VTEP
>=C2=A0 =C2=A0 =C2=A0to monitor the reachability of a remote VTEP, regar= dless of the
>=C2=A0 =C2=A0 =C2=A0number of VNIs in common.=C2=A0 When the single BFD= session is used to
>=C2=A0 =C2=A0 =C2=A0monitor the reachability of the remote VTEP, an imp= lementation SHOULD
>=C2=A0 =C2=A0 =C2=A0choose any of the VNIs but MAY choose VNI =3D 0. >
>
>=C2=A0 =C2=A0 =C2=A0Minor Issues:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0N/A
>
>=C2=A0 =C2=A0 =C2=A0Nits: N/A
>
--0000000000009146e9058a9e0352-- From nobody Wed Jun 5 20:20:52 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5591200A4; Wed, 5 Jun 2019 20:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 vF2UUNyWnmae; Wed, 5 Jun 2019 20:20:41 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 A07F0120094; Wed, 5 Jun 2019 20:20:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 45K9sN5szyz1Z4h3; Wed, 5 Jun 2019 20:20:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1559791240; bh=Gb8HeyoHVUUsB7U0CoveDVBhhVvSNEXXFKqRJWuWDQ0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=fRriH7VUUZrO9LRbKYOeSBGO770estjRlGWOWyO2C3hR562+eZoi8zP9nKyqEltnT yGBeXPWG8UjHBAgXkAP0V0k19ZkmHeA5T6R5S8fpoX/K52uTR1gvbrg2idNFBZ5CJz YTcNIQZfLQrIaxNAI20N1/RBzhf7d4sxIbFczTaE= X-Virus-Scanned: Debian amavisd-new at maila2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 45K9sM5rMwz1Z4h2; Wed, 5 Jun 2019 20:20:39 -0700 (PDT) Subject: Re: Rtgdir last call review of draft-ietf-bfd-vxlan-07 To: Greg Mirsky Cc: rtg-dir@ietf.org, rtg-bfd WG , draft-ietf-bfd-vxlan.all@ietf.org, IETF list References: <155864919758.8626.11137277913302380197@ietfa.amsl.com> <98825f67-6958-8845-d5d5-3e0ac5e996e1@joelhalpern.com> From: "Joel M. Halpern" Message-ID: Date: Wed, 5 Jun 2019 23:20:38 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 03:20:44 -0000 I am having trouble parsing your response. Apologies. The first part talks about a VTEP receiving a packet, and determining if there is a receiver VM for the inner MAC. That is a quote from 7348 Section 4.1. I understand it. You then go on to quote from section 5 of the BFD over VxLAN specification saying that it modifies this to specify that the VTEP checks for its own MAC address. The only problem is that the VTEP is not part of the tenant network. Any MAC address you want it to use may be in use by the tenant network. As far as I know, in normal VxLAN oepration, VTEPs do NOT have their own MAC addresses within the scope of the VNI. Now, if you say that BFD will only be used with VNI 0 (i.e. a VNI that is not assigned to a tenant), then the conflict goes away. But again, there is no need for special MAC checking. Just declare that the VTEP looks for OAM content on VNI 0. So no, your proposed change does not address my concern, as "VTEP's MAC address is not, to the best of my knowledge, a well-defined term. I am happy to be shown where such a thing is defined for use within tenant VNIs. Yours, Joel On 6/5/19 9:55 PM, Greg Mirsky wrote: > Hi Joel, > I cannot find the text in RFC 7348 that suggests that any > VXLAN-encapsulated frame received by VTEP must be forwarded to a VM > associated with the specified VNI. But I've found the text in section > 4.1 that makes the forwarding of the inner frame to VM conditional to > the destination MAC address matching to VM's MAC: >    Upon reception, the remote VTEP >    verifies the validity of the VNI and whether or not there is a VM on >    that VNI using a MAC address that matches the inner destination MAC >    address.  If so, the packet is stripped of its encapsulating headers >    and passed on to the destination VM. > BFD over VXLAN specification in section 5 clarifies the processing of > the received VXLAN packet by the remote VXLAN: >    Once a packet is received, VTEP MUST validate the packet.  If the >    Destination MAC of the inner MAC frame matches the MAC address of the >    VTEP the packet MUST be processed further. > >    The UDP destination port and the TTL of the inner IP packet MUST be >    validated to determine if the received packet can be processed by >    BFD.  BFD packet with inner MAC set to VTEP's MAC address MUST NOT be >    forwarded to VMs. > Would this text address your concern? > > Regards, > Greg > > On Wed, Jun 5, 2019 at 2:47 PM Joel M. Halpern > wrote: > > The inner packet of a VxLAN header with a VNI is a tenant packet for > the > tenant identified by the VNI.  That is the meaning of the inner packet. > > If you declare that the flag bits change that meaning, then that flag > bit has to adjust the packet processing at the VTEP such taht it will > intercept the packet.  As such, it doesn;t need special inner source or > dest mac addresses or IP addresses.  In fact, the inner packet can just > be OAM payload. > > If that is not what you intend, then how is it that the VTEP knows that > the inner addresses are for it to examine, rather than belonging to the > tenant.  As far as I know we are not free to take addresses away from > the tenant. > > It may be that I am completely missing how this is supposed to > work.  If > so, it needs better explanation. > > Yours, > Joel > > On 6/5/19 5:20 PM, Greg Mirsky wrote: > > Hi Joel, > > thank you for your review and the pointed questions. Please find my > > answers, comments in-line and tagged GIM>>. > > > > Regards, > > Greg > > > > > > On Thu, May 23, 2019 at 3:06 PM Joel Halpern via Datatracker > > > >> wrote: > > > >     Reviewer: Joel Halpern > >     Review result: Has Issues > > > >     Hello, > > > >     I have been selected as the Routing Directorate reviewer for this > >     draft. The > >     Routing Directorate seeks to review all routing or > routing-related > >     drafts as > >     they pass through IETF last call and IESG review, and > sometimes on > >     special > >     request. The purpose of the review is to provide assistance > to the > >     Routing ADs. > >     For more information about the Routing Directorate, please see > > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > > >     Although these comments are primarily for the use of the Routing > >     ADs, it would > >     be helpful if you could consider them along with any other > IETF Last > >     Call > >     comments that you receive, and strive to resolve them through > >     discussion or by > >     updating the draft. > > > >     Document: ddraft-ietf-bfd-vxlan-07 > >     Reviewer: your-name > >     Review Date: date > >     IETF LC End Date: date-if-known > >     Intended Status: copy-from-I-D > > > >     Summary: This document does not appear to be ready for > publication as a > >     Proposed Standard RFC. > > > >     Major issues: > >          The scoping of the BFD usage is unclear.  In places, > this looks > >     like it is > >          intended to be used by the underlay service provider, > who will > >     monitor the > >          connectivity between VTEPs. > > > > GIM>> I think that the DCI provider would not be able to > instantiate a > > BFD session using VXLAN encapsulation and, possibly, monitor that > VXLAN > > part of forwarding operates properly. Such BFD session may > monitor the > > path between the two VTEP but, if there exists ECMP environment > in the > > transport, ensuring that that BFD session follows the same path > as VXLAN > > data may be challenging. > > > >     In other places it seems to be aimed at > >          monitoring individual VNIs. > > > > GIM>> The BFD session between VTEPs is not actually used to > monitor the > > particular VNI but MAY be used to communicate, as concatenated path > > state signaling, the change of VNI state using the method > described in > > Section 6.8.17 RFC 5880 > > . > > > >     This is made worse when the packet format is > >          laid out.  The inner packet is an Ethernet Packet with an IP > >     packet (with > >          UDP, with BFD).  This means that it is a tenant packet. > > > > GIM>> Could you please point to the text which suggests that the BFD > > control packet is a tenant packet? Meant to be delivered to a tenant? > > > >     The IP address is > >          a tenant IP. > > > > GIM>> The explanation of the format states in regard to the inner > IP header: > >         IP header: > > > >           Source IP: IP address of the originating VTEP. > > > >           Destination IP: IP address of the terminating VTEP. > > > >     But the diagram shows this as being the IP address of the > >          VTEP.  Which is not a tenant entity. > > > >         There is further confusion as to whether the processing is > >     driven by the VNI > >         the packet arrived with, or the VNI is ignored. > > > > GIM>> The use of VNI is implementation specific. Section 6 states: > >   6.  Use of the Specific VNI > > > >     In most cases, a single BFD session is sufficient for the > given VTEP > >     to monitor the reachability of a remote VTEP, regardless of the > >     number of VNIs in common.  When the single BFD session is used to > >     monitor the reachability of the remote VTEP, an > implementation SHOULD > >     choose any of the VNIs but MAY choose VNI = 0. > > > > > >     Minor Issues: > >         N/A > > > >     Nits: N/A > > > From nobody Thu Jun 6 17:18:40 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 734A312010D; Thu, 6 Jun 2019 17:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 vhCK3zNns9B0; Thu, 6 Jun 2019 17:18:21 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (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 3ECB01200FD; Thu, 6 Jun 2019 17:18:21 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id a25so264993lfg.2; Thu, 06 Jun 2019 17:18: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=2gAv6iJxOVjXD6ovFqTB8/lmq86/+Id7R450wTdGbRM=; b=J8N5Fysxd98xYMonkbB9W6WaY750l4Dv2qO3fpGIoInFeSFlD2oXNxPPeNdAmPDFpp zN5J/flpworAXRBWzNFtdIZvNZ/ePjJANyzKh3NnIr2N3SA7zbE+HMJVhDuIKDv5kqIO xhzv5rFMCkXnyc9e0r0gAr6oCI1QhYHWO6DWY3NQ53tdkEm7W1gziHpv9nokYuALbMFS 8hX+w6dlaGA0/PE8R3oLkuC1jY0Pt8rYtv40m8EaFICoZjamPkbbtyJCu5lM7Y4h5LTx 5QDUx16Cxp5qBat3SSy+QUU5CUfHQ5tiEuzc+X19nbxUT3PE5iJEpghS8J1JoXIOpANF TeDQ== 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=2gAv6iJxOVjXD6ovFqTB8/lmq86/+Id7R450wTdGbRM=; b=IsJz0nh/x9AT7QmvXSff2spxt1ZvDUo88fy6D8P0n1sZ+BQgRY6q5tgPL2Y/cwggIi ZYfYy8SQmmwFeTY+pksT7huGf/3JzW0d3/PlSoQYIN1WwnX5twzs36K2kvtl+g1xvLeA ywrewyqpDStzFOMQpDS1tTijcjEF47WiSf21983NGVxchAPTcICzEiYKv9iYfoxtx9SO zjbzyTDBm3sVLwsXyVX8m+nHfAea16GyKxbZiLL+WLnLMw1Y83XrwZWVMRWZ5gEG4q6D CmKvy73gG6Q/7B9rsXipxXZuKn4NaoE0nMSStxpT3t6F6hqrkfOw7d0K9uuFGP53MEys Bwkw== X-Gm-Message-State: APjAAAVm9lB2EgpfKlbw3ydSzmtrrARIlwAzdAEypEgzVgqvYmFAqyQg SL5GPDXqqJfHJhnSUDEckz3I0YVrbbNKZPGiRa/xI124iLE= X-Google-Smtp-Source: APXvYqykTflPjaystIv3ZSwCoxN0j0HFtCHErdefFZMByk63fUghg9fryuYfU+DejeoTaWPdExyMQ2JCzRFe2KSRPOo= X-Received: by 2002:ac2:569c:: with SMTP id 28mr11751814lfr.147.1559866699287; Thu, 06 Jun 2019 17:18:19 -0700 (PDT) MIME-Version: 1.0 References: <155864919758.8626.11137277913302380197@ietfa.amsl.com> <98825f67-6958-8845-d5d5-3e0ac5e996e1@joelhalpern.com> In-Reply-To: From: Greg Mirsky Date: Thu, 6 Jun 2019 17:18:08 -0700 Message-ID: Subject: Re: Rtgdir last call review of draft-ietf-bfd-vxlan-07 To: "Joel M. Halpern" Cc: rtg-dir@ietf.org, rtg-bfd WG , draft-ietf-bfd-vxlan.all@ietf.org, IETF list Content-Type: multipart/alternative; boundary="0000000000008210e6058ab0c4d3" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 00:18:25 -0000 --0000000000008210e6058ab0c4d3 Content-Type: text/plain; charset="UTF-8" Hi Joel, thank you for the clarification of your concern. For the inner Ethernet header, the destination and source MAC addresses are as described in Section 5 of RFC 7348 for VXLAN's outer Ethernet header: The outer destination MAC address in this frame may be the address of the target VTEP or of an intermediate Layer 3 router. As I understand this example, a VTEP must have MAC address assigned. The address used as the source MAC address of the outer Ethernet frame and may be used by a remote VTEP as destination MAC address in the outer Ethernet frame. This MAC address is not, as I understand, associated with any VNI. Perhaps we can add text to point to Section 5 RFC 7348 and how VTEP MAC address is used in the outer Ethernet header of a VXLAN packet. If you agree, I'll polish the new update in a day. Regards, Greg On Wed, Jun 5, 2019 at 8:20 PM Joel M. Halpern wrote: > I am having trouble parsing your response. Apologies. > The first part talks about a VTEP receiving a packet, and determining if > there is a receiver VM for the inner MAC. That is a quote from 7348 > Section 4.1. I understand it. > > You then go on to quote from section 5 of the BFD over VxLAN > specification saying that it modifies this to specify that the VTEP > checks for its own MAC address. > The only problem is that the VTEP is not part of the tenant network. > Any MAC address you want it to use may be in use by the tenant network. > As far as I know, in normal VxLAN oepration, VTEPs do NOT have their own > MAC addresses within the scope of the VNI. > > Now, if you say that BFD will only be used with VNI 0 (i.e. a VNI that > is not assigned to a tenant), then the conflict goes away. But again, > there is no need for special MAC checking. Just declare that the VTEP > looks for OAM content on VNI 0. > > So no, your proposed change does not address my concern, as "VTEP's MAC > address is not, to the best of my knowledge, a well-defined term. I am > happy to be shown where such a thing is defined for use within tenant VNIs. > > Yours, > Joel > > On 6/5/19 9:55 PM, Greg Mirsky wrote: > > Hi Joel, > > I cannot find the text in RFC 7348 that suggests that any > > VXLAN-encapsulated frame received by VTEP must be forwarded to a VM > > associated with the specified VNI. But I've found the text in section > > 4.1 that makes the forwarding of the inner frame to VM conditional to > > the destination MAC address matching to VM's MAC: > > Upon reception, the remote VTEP > > verifies the validity of the VNI and whether or not there is a VM on > > that VNI using a MAC address that matches the inner destination MAC > > address. If so, the packet is stripped of its encapsulating headers > > and passed on to the destination VM. > > BFD over VXLAN specification in section 5 clarifies the processing of > > the received VXLAN packet by the remote VXLAN: > > Once a packet is received, VTEP MUST validate the packet. If the > > Destination MAC of the inner MAC frame matches the MAC address of the > > VTEP the packet MUST be processed further. > > > > The UDP destination port and the TTL of the inner IP packet MUST be > > validated to determine if the received packet can be processed by > > BFD. BFD packet with inner MAC set to VTEP's MAC address MUST NOT be > > forwarded to VMs. > > Would this text address your concern? > > > > Regards, > > Greg > > > > On Wed, Jun 5, 2019 at 2:47 PM Joel M. Halpern > > wrote: > > > > The inner packet of a VxLAN header with a VNI is a tenant packet for > > the > > tenant identified by the VNI. That is the meaning of the inner > packet. > > > > If you declare that the flag bits change that meaning, then that flag > > bit has to adjust the packet processing at the VTEP such taht it will > > intercept the packet. As such, it doesn;t need special inner source > or > > dest mac addresses or IP addresses. In fact, the inner packet can > just > > be OAM payload. > > > > If that is not what you intend, then how is it that the VTEP knows > that > > the inner addresses are for it to examine, rather than belonging to > the > > tenant. As far as I know we are not free to take addresses away from > > the tenant. > > > > It may be that I am completely missing how this is supposed to > > work. If > > so, it needs better explanation. > > > > Yours, > > Joel > > > > On 6/5/19 5:20 PM, Greg Mirsky wrote: > > > Hi Joel, > > > thank you for your review and the pointed questions. Please find > my > > > answers, comments in-line and tagged GIM>>. > > > > > > Regards, > > > Greg > > > > > > > > > On Thu, May 23, 2019 at 3:06 PM Joel Halpern via Datatracker > > > > > >> wrote: > > > > > > Reviewer: Joel Halpern > > > Review result: Has Issues > > > > > > Hello, > > > > > > I have been selected as the Routing Directorate reviewer for > this > > > draft. The > > > Routing Directorate seeks to review all routing or > > routing-related > > > drafts as > > > they pass through IETF last call and IESG review, and > > sometimes on > > > special > > > request. The purpose of the review is to provide assistance > > to the > > > Routing ADs. > > > For more information about the Routing Directorate, please see > > > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > > > > > Although these comments are primarily for the use of the > Routing > > > ADs, it would > > > be helpful if you could consider them along with any other > > IETF Last > > > Call > > > comments that you receive, and strive to resolve them through > > > discussion or by > > > updating the draft. > > > > > > Document: ddraft-ietf-bfd-vxlan-07 > > > Reviewer: your-name > > > Review Date: date > > > IETF LC End Date: date-if-known > > > Intended Status: copy-from-I-D > > > > > > Summary: This document does not appear to be ready for > > publication as a > > > Proposed Standard RFC. > > > > > > Major issues: > > > The scoping of the BFD usage is unclear. In places, > > this looks > > > like it is > > > intended to be used by the underlay service provider, > > who will > > > monitor the > > > connectivity between VTEPs. > > > > > > GIM>> I think that the DCI provider would not be able to > > instantiate a > > > BFD session using VXLAN encapsulation and, possibly, monitor that > > VXLAN > > > part of forwarding operates properly. Such BFD session may > > monitor the > > > path between the two VTEP but, if there exists ECMP environment > > in the > > > transport, ensuring that that BFD session follows the same path > > as VXLAN > > > data may be challenging. > > > > > > In other places it seems to be aimed at > > > monitoring individual VNIs. > > > > > > GIM>> The BFD session between VTEPs is not actually used to > > monitor the > > > particular VNI but MAY be used to communicate, as concatenated > path > > > state signaling, the change of VNI state using the method > > described in > > > Section 6.8.17 RFC 5880 > > > . > > > > > > This is made worse when the packet format is > > > laid out. The inner packet is an Ethernet Packet with > an IP > > > packet (with > > > UDP, with BFD). This means that it is a tenant packet. > > > > > > GIM>> Could you please point to the text which suggests that the > BFD > > > control packet is a tenant packet? Meant to be delivered to a > tenant? > > > > > > The IP address is > > > a tenant IP. > > > > > > GIM>> The explanation of the format states in regard to the inner > > IP header: > > > IP header: > > > > > > Source IP: IP address of the originating VTEP. > > > > > > Destination IP: IP address of the terminating VTEP. > > > > > > But the diagram shows this as being the IP address of the > > > VTEP. Which is not a tenant entity. > > > > > > There is further confusion as to whether the processing is > > > driven by the VNI > > > the packet arrived with, or the VNI is ignored. > > > > > > GIM>> The use of VNI is implementation specific. Section 6 states: > > > 6. Use of the Specific VNI > > > > > > In most cases, a single BFD session is sufficient for the > > given VTEP > > > to monitor the reachability of a remote VTEP, regardless of > the > > > number of VNIs in common. When the single BFD session is > used to > > > monitor the reachability of the remote VTEP, an > > implementation SHOULD > > > choose any of the VNIs but MAY choose VNI = 0. > > > > > > > > > Minor Issues: > > > N/A > > > > > > Nits: N/A > > > > > > --0000000000008210e6058ab0c4d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joel,
thank you for the clarification of your conce= rn. For the inner Ethernet header, the destination and source MAC addresses= are as described in Section 5 of RFC 7348 for VXLAN's outer Ethernet h= eader:
=C2=A0 =C2=A0 =C2=A0The outer destination MAC address in t= his frame may
=C2=A0 =C2=A0 =C2=A0 be the address of the target VTEP or = of an intermediate Layer 3
=C2=A0 =C2=A0 =C2=A0 router.
As= I understand this example, a VTEP must have MAC address assigned. The addr= ess used as the source MAC address of the outer Ethernet frame and may be u= sed by a remote VTEP as destination MAC address in the outer Ethernet frame= . This MAC address is not, as I understand, associated with any VNI. Perhap= s we can add text to point to Section 5 RFC 7348 and how VTEP MAC address i= s used in the outer Ethernet header of a VXLAN packet. If you agree, I'= ll polish the new update in a day.

Regards,
<= div>Greg

On Wed, Jun 5, 2019 at 8:20 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:
I am having trouble pars= ing your response.=C2=A0 Apologies.
The first part talks about a VTEP receiving a packet, and determining if there is a receiver VM for the inner MAC.=C2=A0 That is a quote from 7348 <= br> Section 4.1.=C2=A0 I understand it.

You then go on to quote from section 5 of the BFD over VxLAN
specification saying that it modifies this to specify that the VTEP
checks for its own MAC address.
The only problem is that the VTEP is not part of the tenant network.
Any MAC address you want it to use may be in use by the tenant network. As far as I know, in normal VxLAN oepration, VTEPs do NOT have their own MAC addresses within the scope of the VNI.

Now, if you say that BFD will only be used with VNI 0 (i.e. a VNI that
is not assigned to a tenant), then the conflict goes away.=C2=A0 But again,=
there is no need for special MAC checking.=C2=A0 Just declare that the VTEP=
looks for OAM content on VNI 0.

So no, your proposed change does not address my concern, as "VTEP'= s MAC
address is not, to the best of my knowledge, a well-defined term.=C2=A0 I a= m
happy to be shown where such a thing is defined for use within tenant VNIs.=

Yours,
Joel

On 6/5/19 9:55 PM, Greg Mirsky wrote:
> Hi Joel,
> I cannot find the text in RFC 7348 that suggests that any
> VXLAN-encapsulated frame received by VTEP must be forwarded to a VM > associated with the specified VNI. But I've found the text in sect= ion
> 4.1 that makes the forwarding of the inner frame to VM conditional to =
> the destination MAC address matching to VM's MAC:
>=C2=A0 =C2=A0 =C2=A0Upon reception, the remote VTEP
>=C2=A0 =C2=A0 =C2=A0verifies the validity of the VNI and whether or not= there is a VM on
>=C2=A0 =C2=A0 =C2=A0that VNI using a MAC address that matches the inner= destination MAC
>=C2=A0 =C2=A0 =C2=A0address.=C2=A0 If so, the packet is stripped of its= encapsulating headers
>=C2=A0 =C2=A0 =C2=A0and passed on to the destination VM.
> BFD over VXLAN specification in section 5 clarifies the processing of =
> the received VXLAN packet by the remote VXLAN:
>=C2=A0 =C2=A0 =C2=A0Once a packet is received, VTEP MUST validate the p= acket.=C2=A0 If the
>=C2=A0 =C2=A0 =C2=A0Destination MAC of the inner MAC frame matches the = MAC address of the
>=C2=A0 =C2=A0 =C2=A0VTEP the packet MUST be processed further.
>
>=C2=A0 =C2=A0 =C2=A0The UDP destination port and the TTL of the inner I= P packet MUST be
>=C2=A0 =C2=A0 =C2=A0validated to determine if the received packet can b= e processed by
>=C2=A0 =C2=A0 =C2=A0BFD.=C2=A0 BFD packet with inner MAC set to VTEP= 9;s MAC address MUST NOT be
>=C2=A0 =C2=A0 =C2=A0forwarded to VMs.
> Would this text address your concern?
>
> Regards,
> Greg
>
> On Wed, Jun 5, 2019 at 2:47 PM Joel M. Halpern <jmh@joelhalpern.com
> <mailto:jm= h@joelhalpern.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0The inner packet of a VxLAN header with a VNI is a = tenant packet for
>=C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0tenant identified by the VNI.=C2=A0 That is the mea= ning of the inner packet.
>
>=C2=A0 =C2=A0 =C2=A0If you declare that the flag bits change that meani= ng, then that flag
>=C2=A0 =C2=A0 =C2=A0bit has to adjust the packet processing at the VTEP= such taht it will
>=C2=A0 =C2=A0 =C2=A0intercept the packet.=C2=A0 As such, it doesn;t nee= d special inner source or
>=C2=A0 =C2=A0 =C2=A0dest mac addresses or IP addresses.=C2=A0 In fact, = the inner packet can just
>=C2=A0 =C2=A0 =C2=A0be OAM payload.
>
>=C2=A0 =C2=A0 =C2=A0If that is not what you intend, then how is it that= the VTEP knows that
>=C2=A0 =C2=A0 =C2=A0the inner addresses are for it to examine, rather t= han belonging to the
>=C2=A0 =C2=A0 =C2=A0tenant.=C2=A0 As far as I know we are not free to t= ake addresses away from
>=C2=A0 =C2=A0 =C2=A0the tenant.
>
>=C2=A0 =C2=A0 =C2=A0It may be that I am completely missing how this is = supposed to
>=C2=A0 =C2=A0 =C2=A0work.=C2=A0 If
>=C2=A0 =C2=A0 =C2=A0so, it needs better explanation.
>
>=C2=A0 =C2=A0 =C2=A0Yours,
>=C2=A0 =C2=A0 =C2=A0Joel
>
>=C2=A0 =C2=A0 =C2=A0On 6/5/19 5:20 PM, Greg Mirsky wrote:
>=C2=A0 =C2=A0 =C2=A0 > Hi=C2=A0Joel,
>=C2=A0 =C2=A0 =C2=A0 > thank you for your review and the pointed que= stions. Please find my
>=C2=A0 =C2=A0 =C2=A0 > answers, comments in-line and tagged GIM>&= gt;.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Regards,
>=C2=A0 =C2=A0 =C2=A0 > Greg
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > On Thu, May 23, 2019 at 3:06 PM Joel Halpern = via Datatracker
>=C2=A0 =C2=A0 =C2=A0 > <noreply@ietf.org <mailto:noreply@ietf.org>
>=C2=A0 =C2=A0 =C2=A0<mailto:noreply@ietf.org <mailto:noreply@ietf.org>>> wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Reviewer: Joel Halpern
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Review result: Has Issues<= br> >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Hello,
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I have been selected as th= e Routing Directorate reviewer for this
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0draft. The
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Routing Directorate seeks = to review all routing or
>=C2=A0 =C2=A0 =C2=A0routing-related
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0drafts as
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0they pass through IETF las= t call and IESG review, and
>=C2=A0 =C2=A0 =C2=A0sometimes on
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0special
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0request. The purpose of th= e review is to provide assistance
>=C2=A0 =C2=A0 =C2=A0to the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Routing ADs.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0For more information about= the Routing Directorate, please see
>=C2=A0 =C2=A0 =C2=A0 > http://trac.tools.= ietf.org/area/rtg/trac/wiki/RtgDir
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Although these comments ar= e primarily for the use of the Routing
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0ADs, it would
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0be helpful if you could co= nsider them along with any other
>=C2=A0 =C2=A0 =C2=A0IETF Last
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Call
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0comments that you receive,= and strive to resolve them through
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0discussion or by
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0updating the draft.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Document: ddraft-ietf-bfd-= vxlan-07
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Reviewer: your-name
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Review Date: date
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0IETF LC End Date: date-if-= known
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Intended Status: copy-from= -I-D
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Summary: This document doe= s not appear to be ready for
>=C2=A0 =C2=A0 =C2=A0publication as a
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Proposed Standard RFC.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Major issues:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The scoping= of the BFD usage is unclear.=C2=A0 In places,
>=C2=A0 =C2=A0 =C2=A0this looks
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0like it is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 intended to= be used by the underlay service provider,
>=C2=A0 =C2=A0 =C2=A0who will
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0monitor the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 connectivit= y between VTEPs.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > GIM>> I think that the DCI provider wou= ld not be able to
>=C2=A0 =C2=A0 =C2=A0instantiate a
>=C2=A0 =C2=A0 =C2=A0 > BFD session using VXLAN encapsulation and, po= ssibly, monitor that
>=C2=A0 =C2=A0 =C2=A0VXLAN
>=C2=A0 =C2=A0 =C2=A0 > part of forwarding operates properly. Such BF= D session may
>=C2=A0 =C2=A0 =C2=A0monitor the
>=C2=A0 =C2=A0 =C2=A0 > path between the two VTEP but, if there exist= s ECMP environment
>=C2=A0 =C2=A0 =C2=A0in the
>=C2=A0 =C2=A0 =C2=A0 > transport, ensuring that that BFD session fol= lows the same path
>=C2=A0 =C2=A0 =C2=A0as VXLAN
>=C2=A0 =C2=A0 =C2=A0 > data may be challenging.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0In other places it seems t= o be aimed at
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 monitoring = individual VNIs.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > GIM>> The BFD session between VTEPs is = not actually used to
>=C2=A0 =C2=A0 =C2=A0monitor the
>=C2=A0 =C2=A0 =C2=A0 > particular VNI but MAY be used to communicate= , as concatenated path
>=C2=A0 =C2=A0 =C2=A0 > state signaling, the change of VNI state usin= g the method
>=C2=A0 =C2=A0 =C2=A0described in
>=C2=A0 =C2=A0 =C2=A0 > Section 6.8.17 RFC 5880
>=C2=A0 =C2=A0 =C2=A0 > <https://tools.ie= tf.org/html/rfc5880#section-6.8.17>.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0This is made worse when th= e packet format is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 laid out.= =C2=A0 The inner packet is an Ethernet Packet with an IP
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0packet (with
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 UDP, with B= FD).=C2=A0 This means that it is a tenant packet.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > GIM>> Could you please point to the tex= t which suggests that the BFD
>=C2=A0 =C2=A0 =C2=A0 > control packet is a tenant packet? Meant to b= e delivered to a tenant?
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0The IP address is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 a tenant IP= .
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > GIM>> The explanation of the format sta= tes in regard to the inner
>=C2=A0 =C2=A0 =C2=A0IP header:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IP header: >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sourc= e IP: IP address of the originating VTEP.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Desti= nation IP: IP address of the terminating VTEP.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0But the diagram shows this= as being the IP address of the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 VTEP.=C2=A0= Which is not a tenant entity.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0There is fur= ther confusion as to whether the processing is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0driven by the VNI
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the packet a= rrived with, or the VNI is ignored.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > GIM>> The use of VNI is implementation = specific. Section 6 states:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A06.=C2=A0 Use of the Specific VNI<= br> >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0In most cases, a single BF= D session is sufficient for the
>=C2=A0 =C2=A0 =C2=A0given VTEP
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0to monitor the reachabilit= y of a remote VTEP, regardless of the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0number of VNIs in common.= =C2=A0 When the single BFD session is used to
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0monitor the reachability o= f the remote VTEP, an
>=C2=A0 =C2=A0 =C2=A0implementation SHOULD
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0choose any of the VNIs but= MAY choose VNI =3D 0.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Minor Issues:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0N/A
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Nits: N/A
>=C2=A0 =C2=A0 =C2=A0 >
>
--0000000000008210e6058ab0c4d3-- From nobody Thu Jun 6 17:53:16 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 225BD1200FD; Thu, 6 Jun 2019 17:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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=joelhalpern.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 jGBHjQ-BVw7c; Thu, 6 Jun 2019 17:53:13 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 5FE6F120071; Thu, 6 Jun 2019 17:53:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 45KkXn0ysxz15NyR; Thu, 6 Jun 2019 17:53:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1559868793; bh=ol4MrMM+7DfIbgVaN5+5ea02vbzAM+PuS9w7e6Nc0ig=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=IBBDPZAHu+3oFK8gbNMVDUiLyU0HcR8ajUv/L5n9kABo7K2vMUQQPculcqgTd2M7l 5P3Sx5zfSgogNfei4tOjh1vF8qUI/fOXPpPzf5MnuineSGlH0101KBP4TW7S9YapWP x2M8GHjVVZ4fpbSp+FpukIrvnFCZcYa3tejhqRtM= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 45KkXm1bHmz15NjH; Thu, 6 Jun 2019 17:53:12 -0700 (PDT) Subject: Re: Rtgdir last call review of draft-ietf-bfd-vxlan-07 To: Greg Mirsky Cc: rtg-dir@ietf.org, rtg-bfd WG , draft-ietf-bfd-vxlan.all@ietf.org, IETF list References: <155864919758.8626.11137277913302380197@ietfa.amsl.com> <98825f67-6958-8845-d5d5-3e0ac5e996e1@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <4903980b-49e2-1f8c-7575-2af4614e2c6b@joelhalpern.com> Date: Thu, 6 Jun 2019 20:53:11 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 00:53:16 -0000 There is a reason the "Outer Ethernet Header" in section 5 of 7348 is labeled as "example". That outer header will actually vary hop by hop along the IP network between the source VTEP and the desination VTEP. Unless the source and destination VTEP are one IP hope apart, the source VTEP will not even know the Ethernet MAC address of the destination VP. It will simply address the outer IP packet, and let IP rotuing do its job (that is the whole point of VxLAN.) More importantly, it is not associated with any VNI as it is the outer header. Your usage is as an inner Ethernet Destination address. The inner Ethernet header is the tenant space. The VTEPs do not impinge on that space. Nor use any values from it. Yours, Joel On 6/6/19 8:18 PM, Greg Mirsky wrote: > Hi Joel, > thank you for the clarification of your concern. For the inner Ethernet > header, the destination and source MAC addresses are as described in > Section 5 of RFC 7348 for VXLAN's outer Ethernet header: >      The outer destination MAC address in this frame may >       be the address of the target VTEP or of an intermediate Layer 3 >       router. > As I understand this example, a VTEP must have MAC address assigned. The > address used as the source MAC address of the outer Ethernet frame and > may be used by a remote VTEP as destination MAC address in the outer > Ethernet frame. This MAC address is not, as I understand, associated > with any VNI. Perhaps we can add text to point to Section 5 RFC 7348 and > how VTEP MAC address is used in the outer Ethernet header of a VXLAN > packet. If you agree, I'll polish the new update in a day. > > Regards, > Greg > > On Wed, Jun 5, 2019 at 8:20 PM Joel M. Halpern > wrote: > > I am having trouble parsing your response.  Apologies. > The first part talks about a VTEP receiving a packet, and > determining if > there is a receiver VM for the inner MAC.  That is a quote from 7348 > Section 4.1.  I understand it. > > You then go on to quote from section 5 of the BFD over VxLAN > specification saying that it modifies this to specify that the VTEP > checks for its own MAC address. > The only problem is that the VTEP is not part of the tenant network. > Any MAC address you want it to use may be in use by the tenant network. > As far as I know, in normal VxLAN oepration, VTEPs do NOT have their > own > MAC addresses within the scope of the VNI. > > Now, if you say that BFD will only be used with VNI 0 (i.e. a VNI that > is not assigned to a tenant), then the conflict goes away.  But again, > there is no need for special MAC checking.  Just declare that the VTEP > looks for OAM content on VNI 0. > > So no, your proposed change does not address my concern, as "VTEP's MAC > address is not, to the best of my knowledge, a well-defined term.  I am > happy to be shown where such a thing is defined for use within > tenant VNIs. > > Yours, > Joel > > On 6/5/19 9:55 PM, Greg Mirsky wrote: > > Hi Joel, > > I cannot find the text in RFC 7348 that suggests that any > > VXLAN-encapsulated frame received by VTEP must be forwarded to a VM > > associated with the specified VNI. But I've found the text in > section > > 4.1 that makes the forwarding of the inner frame to VM > conditional to > > the destination MAC address matching to VM's MAC: > >     Upon reception, the remote VTEP > >     verifies the validity of the VNI and whether or not there is > a VM on > >     that VNI using a MAC address that matches the inner > destination MAC > >     address.  If so, the packet is stripped of its encapsulating > headers > >     and passed on to the destination VM. > > BFD over VXLAN specification in section 5 clarifies the > processing of > > the received VXLAN packet by the remote VXLAN: > >     Once a packet is received, VTEP MUST validate the packet.  If the > >     Destination MAC of the inner MAC frame matches the MAC > address of the > >     VTEP the packet MUST be processed further. > > > >     The UDP destination port and the TTL of the inner IP packet > MUST be > >     validated to determine if the received packet can be processed by > >     BFD.  BFD packet with inner MAC set to VTEP's MAC address > MUST NOT be > >     forwarded to VMs. > > Would this text address your concern? > > > > Regards, > > Greg > > > > On Wed, Jun 5, 2019 at 2:47 PM Joel M. Halpern > > > >> wrote: > > > >     The inner packet of a VxLAN header with a VNI is a tenant > packet for > >     the > >     tenant identified by the VNI.  That is the meaning of the > inner packet. > > > >     If you declare that the flag bits change that meaning, then > that flag > >     bit has to adjust the packet processing at the VTEP such taht > it will > >     intercept the packet.  As such, it doesn;t need special inner > source or > >     dest mac addresses or IP addresses.  In fact, the inner > packet can just > >     be OAM payload. > > > >     If that is not what you intend, then how is it that the VTEP > knows that > >     the inner addresses are for it to examine, rather than > belonging to the > >     tenant.  As far as I know we are not free to take addresses > away from > >     the tenant. > > > >     It may be that I am completely missing how this is supposed to > >     work.  If > >     so, it needs better explanation. > > > >     Yours, > >     Joel > > > >     On 6/5/19 5:20 PM, Greg Mirsky wrote: > >      > Hi Joel, > >      > thank you for your review and the pointed questions. > Please find my > >      > answers, comments in-line and tagged GIM>>. > >      > > >      > Regards, > >      > Greg > >      > > >      > > >      > On Thu, May 23, 2019 at 3:06 PM Joel Halpern via Datatracker > >      > > > > >      > >>> wrote: > >      > > >      >     Reviewer: Joel Halpern > >      >     Review result: Has Issues > >      > > >      >     Hello, > >      > > >      >     I have been selected as the Routing Directorate > reviewer for this > >      >     draft. The > >      >     Routing Directorate seeks to review all routing or > >     routing-related > >      >     drafts as > >      >     they pass through IETF last call and IESG review, and > >     sometimes on > >      >     special > >      >     request. The purpose of the review is to provide > assistance > >     to the > >      >     Routing ADs. > >      >     For more information about the Routing Directorate, > please see > >      > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > >      > > >      >     Although these comments are primarily for the use of > the Routing > >      >     ADs, it would > >      >     be helpful if you could consider them along with any other > >     IETF Last > >      >     Call > >      >     comments that you receive, and strive to resolve them > through > >      >     discussion or by > >      >     updating the draft. > >      > > >      >     Document: ddraft-ietf-bfd-vxlan-07 > >      >     Reviewer: your-name > >      >     Review Date: date > >      >     IETF LC End Date: date-if-known > >      >     Intended Status: copy-from-I-D > >      > > >      >     Summary: This document does not appear to be ready for > >     publication as a > >      >     Proposed Standard RFC. > >      > > >      >     Major issues: > >      >          The scoping of the BFD usage is unclear.  In places, > >     this looks > >      >     like it is > >      >          intended to be used by the underlay service > provider, > >     who will > >      >     monitor the > >      >          connectivity between VTEPs. > >      > > >      > GIM>> I think that the DCI provider would not be able to > >     instantiate a > >      > BFD session using VXLAN encapsulation and, possibly, > monitor that > >     VXLAN > >      > part of forwarding operates properly. Such BFD session may > >     monitor the > >      > path between the two VTEP but, if there exists ECMP > environment > >     in the > >      > transport, ensuring that that BFD session follows the same > path > >     as VXLAN > >      > data may be challenging. > >      > > >      >     In other places it seems to be aimed at > >      >          monitoring individual VNIs. > >      > > >      > GIM>> The BFD session between VTEPs is not actually used to > >     monitor the > >      > particular VNI but MAY be used to communicate, as > concatenated path > >      > state signaling, the change of VNI state using the method > >     described in > >      > Section 6.8.17 RFC 5880 > >      > . > >      > > >      >     This is made worse when the packet format is > >      >          laid out.  The inner packet is an Ethernet Packet > with an IP > >      >     packet (with > >      >          UDP, with BFD).  This means that it is a tenant > packet. > >      > > >      > GIM>> Could you please point to the text which suggests > that the BFD > >      > control packet is a tenant packet? Meant to be delivered > to a tenant? > >      > > >      >     The IP address is > >      >          a tenant IP. > >      > > >      > GIM>> The explanation of the format states in regard to > the inner > >     IP header: > >      >         IP header: > >      > > >      >           Source IP: IP address of the originating VTEP. > >      > > >      >           Destination IP: IP address of the terminating VTEP. > >      > > >      >     But the diagram shows this as being the IP address of the > >      >          VTEP.  Which is not a tenant entity. > >      > > >      >         There is further confusion as to whether the > processing is > >      >     driven by the VNI > >      >         the packet arrived with, or the VNI is ignored. > >      > > >      > GIM>> The use of VNI is implementation specific. Section 6 > states: > >      >   6.  Use of the Specific VNI > >      > > >      >     In most cases, a single BFD session is sufficient for the > >     given VTEP > >      >     to monitor the reachability of a remote VTEP, > regardless of the > >      >     number of VNIs in common.  When the single BFD session > is used to > >      >     monitor the reachability of the remote VTEP, an > >     implementation SHOULD > >      >     choose any of the VNIs but MAY choose VNI = 0. > >      > > >      > > >      >     Minor Issues: > >      >         N/A > >      > > >      >     Nits: N/A > >      > > > > From nobody Thu Jun 6 18:21:28 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D96120077; Thu, 6 Jun 2019 18:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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=joelhalpern.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 HV7Zrf91qgNF; Thu, 6 Jun 2019 18:21:16 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 BABA41200FF; Thu, 6 Jun 2019 18:21:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 45Kl981R5Zz15NyR; Thu, 6 Jun 2019 18:21:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1559870476; bh=0suMN+baZMs3h9n/zISEoe+tjDtOgEWLTcMhttSOdzI=; h=Subject:From:To:Cc:References:Date:In-Reply-To:From; b=lGLMjNL93ZYbGSfft6p7bTkrBhMpMTwiXpo4DvGY7n0DYiT8B1s77nuxtscyVBkpB VfzpKQ9RanGU012j2F9RlEHj6IenCUyCK56wR6J3Xr0Te+fEf10tswBK8FULP+qzX6 0qSIIfCDp720PAej6ADLRB0UYdk6LnhlY7gUWXYI= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 45Kl9720R6z15NjH; Thu, 6 Jun 2019 18:21:14 -0700 (PDT) Subject: Re: [RTG-DIR] Rtgdir last call review of draft-ietf-bfd-vxlan-07 From: "Joel M. Halpern" To: Greg Mirsky Cc: rtg-dir@ietf.org, rtg-bfd WG , draft-ietf-bfd-vxlan.all@ietf.org, IETF list References: <155864919758.8626.11137277913302380197@ietfa.amsl.com> <98825f67-6958-8845-d5d5-3e0ac5e996e1@joelhalpern.com> <4903980b-49e2-1f8c-7575-2af4614e2c6b@joelhalpern.com> Message-ID: <83e80a61-39f5-8bd2-09df-5692fda8bce8@joelhalpern.com> Date: Thu, 6 Jun 2019 21:21:14 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <4903980b-49e2-1f8c-7575-2af4614e2c6b@joelhalpern.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 01:21:20 -0000 I have looked again at the base VxLAN spec, the BFD spec, and the draft we are discussing. There seems to be a MUCH simpler frame encapsulation which avoids messing with the inner Ethernet header address space. 1) Declare that VxLAN BFD always uses VNI 0 2) Use one of the reserved bits, and define it to mean that the VxLAN payload, when the VNI is 0, is a BFD payload without any Ethernet, IP, or UDP header. That would seem to monitor what the document says it wants to monitor. Yours, Joel On 6/6/19 8:53 PM, Joel M. Halpern wrote: > There is a reason the "Outer Ethernet Header" in section 5 of 7348 is > labeled as "example".  That outer header will actually vary hop by hop > along the IP network between the source VTEP and the desination VTEP. > Unless the source and destination VTEP are one IP hope apart, the source > VTEP will not even know the Ethernet MAC address of the destination VP. > It will simply address the outer IP packet, and let IP rotuing do its > job (that is the whole point of VxLAN.) > > More importantly, it is not associated with any VNI as it is the outer > header.  Your usage is as an inner Ethernet Destination address.  The > inner Ethernet header is the tenant space.  The VTEPs do not impinge on > that space.  Nor use any values from it. > > Yours, > Joel > > On 6/6/19 8:18 PM, Greg Mirsky wrote: >> Hi Joel, >> thank you for the clarification of your concern. For the inner >> Ethernet header, the destination and source MAC addresses are as >> described in Section 5 of RFC 7348 for VXLAN's outer Ethernet header: >>       The outer destination MAC address in this frame may >>        be the address of the target VTEP or of an intermediate Layer 3 >>        router. >> As I understand this example, a VTEP must have MAC address assigned. >> The address used as the source MAC address of the outer Ethernet frame >> and may be used by a remote VTEP as destination MAC address in the >> outer Ethernet frame. This MAC address is not, as I understand, >> associated with any VNI. Perhaps we can add text to point to Section 5 >> RFC 7348 and how VTEP MAC address is used in the outer Ethernet header >> of a VXLAN packet. If you agree, I'll polish the new update in a day. >> >> Regards, >> Greg >> >> On Wed, Jun 5, 2019 at 8:20 PM Joel M. Halpern > > wrote: >> >>     I am having trouble parsing your response.  Apologies. >>     The first part talks about a VTEP receiving a packet, and >>     determining if >>     there is a receiver VM for the inner MAC.  That is a quote from 7348 >>     Section 4.1.  I understand it. >> >>     You then go on to quote from section 5 of the BFD over VxLAN >>     specification saying that it modifies this to specify that the VTEP >>     checks for its own MAC address. >>     The only problem is that the VTEP is not part of the tenant network. >>     Any MAC address you want it to use may be in use by the tenant >> network. >>     As far as I know, in normal VxLAN oepration, VTEPs do NOT have their >>     own >>     MAC addresses within the scope of the VNI. >> >>     Now, if you say that BFD will only be used with VNI 0 (i.e. a VNI >> that >>     is not assigned to a tenant), then the conflict goes away.  But >> again, >>     there is no need for special MAC checking.  Just declare that the >> VTEP >>     looks for OAM content on VNI 0. >> >>     So no, your proposed change does not address my concern, as >> "VTEP's MAC >>     address is not, to the best of my knowledge, a well-defined term. >> I am >>     happy to be shown where such a thing is defined for use within >>     tenant VNIs. >> >>     Yours, >>     Joel >> >>     On 6/5/19 9:55 PM, Greg Mirsky wrote: >>      > Hi Joel, >>      > I cannot find the text in RFC 7348 that suggests that any >>      > VXLAN-encapsulated frame received by VTEP must be forwarded to >> a VM >>      > associated with the specified VNI. But I've found the text in >>     section >>      > 4.1 that makes the forwarding of the inner frame to VM >>     conditional to >>      > the destination MAC address matching to VM's MAC: >>      >     Upon reception, the remote VTEP >>      >     verifies the validity of the VNI and whether or not there is >>     a VM on >>      >     that VNI using a MAC address that matches the inner >>     destination MAC >>      >     address.  If so, the packet is stripped of its encapsulating >>     headers >>      >     and passed on to the destination VM. >>      > BFD over VXLAN specification in section 5 clarifies the >>     processing of >>      > the received VXLAN packet by the remote VXLAN: >>      >     Once a packet is received, VTEP MUST validate the packet. >> If the >>      >     Destination MAC of the inner MAC frame matches the MAC >>     address of the >>      >     VTEP the packet MUST be processed further. >>      > >>      >     The UDP destination port and the TTL of the inner IP packet >>     MUST be >>      >     validated to determine if the received packet can be >> processed by >>      >     BFD.  BFD packet with inner MAC set to VTEP's MAC address >>     MUST NOT be >>      >     forwarded to VMs. >>      > Would this text address your concern? >>      > >>      > Regards, >>      > Greg >>      > >>      > On Wed, Jun 5, 2019 at 2:47 PM Joel M. Halpern >>     >>      > >> wrote: >>      > >>      >     The inner packet of a VxLAN header with a VNI is a tenant >>     packet for >>      >     the >>      >     tenant identified by the VNI.  That is the meaning of the >>     inner packet. >>      > >>      >     If you declare that the flag bits change that meaning, then >>     that flag >>      >     bit has to adjust the packet processing at the VTEP such taht >>     it will >>      >     intercept the packet.  As such, it doesn;t need special inner >>     source or >>      >     dest mac addresses or IP addresses.  In fact, the inner >>     packet can just >>      >     be OAM payload. >>      > >>      >     If that is not what you intend, then how is it that the VTEP >>     knows that >>      >     the inner addresses are for it to examine, rather than >>     belonging to the >>      >     tenant.  As far as I know we are not free to take addresses >>     away from >>      >     the tenant. >>      > >>      >     It may be that I am completely missing how this is supposed to >>      >     work.  If >>      >     so, it needs better explanation. >>      > >>      >     Yours, >>      >     Joel >>      > >>      >     On 6/5/19 5:20 PM, Greg Mirsky wrote: >>      >      > Hi Joel, >>      >      > thank you for your review and the pointed questions. >>     Please find my >>      >      > answers, comments in-line and tagged GIM>>. >>      >      > >>      >      > Regards, >>      >      > Greg >>      >      > >>      >      > >>      >      > On Thu, May 23, 2019 at 3:06 PM Joel Halpern via >> Datatracker >>      >      > >>     > >>      >      >>     >>> wrote: >>      >      > >>      >      >     Reviewer: Joel Halpern >>      >      >     Review result: Has Issues >>      >      > >>      >      >     Hello, >>      >      > >>      >      >     I have been selected as the Routing Directorate >>     reviewer for this >>      >      >     draft. The >>      >      >     Routing Directorate seeks to review all routing or >>      >     routing-related >>      >      >     drafts as >>      >      >     they pass through IETF last call and IESG review, and >>      >     sometimes on >>      >      >     special >>      >      >     request. The purpose of the review is to provide >>     assistance >>      >     to the >>      >      >     Routing ADs. >>      >      >     For more information about the Routing Directorate, >>     please see >>      >      > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir >>      >      > >>      >      >     Although these comments are primarily for the use of >>     the Routing >>      >      >     ADs, it would >>      >      >     be helpful if you could consider them along with any >> other >>      >     IETF Last >>      >      >     Call >>      >      >     comments that you receive, and strive to resolve them >>     through >>      >      >     discussion or by >>      >      >     updating the draft. >>      >      > >>      >      >     Document: ddraft-ietf-bfd-vxlan-07 >>      >      >     Reviewer: your-name >>      >      >     Review Date: date >>      >      >     IETF LC End Date: date-if-known >>      >      >     Intended Status: copy-from-I-D >>      >      > >>      >      >     Summary: This document does not appear to be ready for >>      >     publication as a >>      >      >     Proposed Standard RFC. >>      >      > >>      >      >     Major issues: >>      >      >          The scoping of the BFD usage is unclear.  In >> places, >>      >     this looks >>      >      >     like it is >>      >      >          intended to be used by the underlay service >>     provider, >>      >     who will >>      >      >     monitor the >>      >      >          connectivity between VTEPs. >>      >      > >>      >      > GIM>> I think that the DCI provider would not be able to >>      >     instantiate a >>      >      > BFD session using VXLAN encapsulation and, possibly, >>     monitor that >>      >     VXLAN >>      >      > part of forwarding operates properly. Such BFD session may >>      >     monitor the >>      >      > path between the two VTEP but, if there exists ECMP >>     environment >>      >     in the >>      >      > transport, ensuring that that BFD session follows the same >>     path >>      >     as VXLAN >>      >      > data may be challenging. >>      >      > >>      >      >     In other places it seems to be aimed at >>      >      >          monitoring individual VNIs. >>      >      > >>      >      > GIM>> The BFD session between VTEPs is not actually used to >>      >     monitor the >>      >      > particular VNI but MAY be used to communicate, as >>     concatenated path >>      >      > state signaling, the change of VNI state using the method >>      >     described in >>      >      > Section 6.8.17 RFC 5880 >>      >      > . >>      >      > >>      >      >     This is made worse when the packet format is >>      >      >          laid out.  The inner packet is an Ethernet Packet >>     with an IP >>      >      >     packet (with >>      >      >          UDP, with BFD).  This means that it is a tenant >>     packet. >>      >      > >>      >      > GIM>> Could you please point to the text which suggests >>     that the BFD >>      >      > control packet is a tenant packet? Meant to be delivered >>     to a tenant? >>      >      > >>      >      >     The IP address is >>      >      >          a tenant IP. >>      >      > >>      >      > GIM>> The explanation of the format states in regard to >>     the inner >>      >     IP header: >>      >      >         IP header: >>      >      > >>      >      >           Source IP: IP address of the originating VTEP. >>      >      > >>      >      >           Destination IP: IP address of the terminating >> VTEP. >>      >      > >>      >      >     But the diagram shows this as being the IP address >> of the >>      >      >          VTEP.  Which is not a tenant entity. >>      >      > >>      >      >         There is further confusion as to whether the >>     processing is >>      >      >     driven by the VNI >>      >      >         the packet arrived with, or the VNI is ignored. >>      >      > >>      >      > GIM>> The use of VNI is implementation specific. Section 6 >>     states: >>      >      >   6.  Use of the Specific VNI >>      >      > >>      >      >     In most cases, a single BFD session is sufficient >> for the >>      >     given VTEP >>      >      >     to monitor the reachability of a remote VTEP, >>     regardless of the >>      >      >     number of VNIs in common.  When the single BFD session >>     is used to >>      >      >     monitor the reachability of the remote VTEP, an >>      >     implementation SHOULD >>      >      >     choose any of the VNIs but MAY choose VNI = 0. >>      >      > >>      >      > >>      >      >     Minor Issues: >>      >      >         N/A >>      >      > >>      >      >     Nits: N/A >>      >      > >>      > >> > > From nobody Thu Jun 6 19:43:57 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16449120159; Thu, 6 Jun 2019 19:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 FuwZjJ2msajS; Thu, 6 Jun 2019 19:43:43 -0700 (PDT) Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (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 C22E41200D5; Thu, 6 Jun 2019 19:43:42 -0700 (PDT) Received: by mail-oi1-x22d.google.com with SMTP id u64so458403oib.1; Thu, 06 Jun 2019 19:43:42 -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=6lcUckF60lLFks5vjF4Dmda76zNbxVoUoSWMr7cn0lY=; b=M6Gx5l1dMgtSpsIVbdQ6xQRp57EFfmPXKh3MvtwiDwvxf9weOF2FGcnMW+0+iASnLs XH8HFbSzNbw67rgQRRv0GBLHd7v4qOjYKgatis6z965VaZa5nsHz2ATKJe9s23Ht3LZl WrI65S08T7XCeW/fH7ta7AjF64yyZlAGfw7hkVn1zu0tCuqjeIVbnvbyHAc9XPDv3fRF 7PxD/iwokQ4CfTPS7uKYxjXswAm4WIZ6YuWJNNTlFRrZoXhFLrV8OxHojYdTvit3pyXB LDJcWTfs+pXZXYQdspBgFsU9rk8S9uFsAhRoR3ByYjqAZRb62P08HYZVNflRUukvc4jk 567w== 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=6lcUckF60lLFks5vjF4Dmda76zNbxVoUoSWMr7cn0lY=; b=o5PRmSdtecpqxjqeIeXMQf9l40YR4t8lxeD9h05a97/SoGLU66ajh+c9FxFcow0U9F cYZuZ0pRKS4nppfpsTKQacxS+Ycpy48WnsXkCOWISm6/lismiG4Sr5bRbpXLCYBnJYWJ ojEPi/tDQgGrJn98CZNT+MtKLhI4FIn8mBGuSbiZotdGxP5Kw5KA/jUMxbjrZM3wCZ7N ONhvy6c0Psk2bYv4qd5WoRs8AcOpamE5XpNn2XlXYUHQ32hioRsc//8sO691OnGslEUV JiRfW81wQ01BhiKZVBziWM2Xy9PqzYEFPHMygqSAneHTAS7kVVG59gvXkla13rH7ir/Q VV2Q== X-Gm-Message-State: APjAAAXNLZlpTnQiey9gyEbZGTRGmcg5LMwHjx5v3tpzayC9WsuPAgDE fCCHyjLwlQenLzZqNFo6gc5TJ/4bOICDhmvGWKF36KEepXo= X-Google-Smtp-Source: APXvYqyQngY6u9mNLWGtIJCadSGZun4XwTMVeDgOk19KDUZ+V2N9uiyHgywRZVKMCRwXdW1mkvLu2PMoYUgk5isaydk= X-Received: by 2002:aca:5f8b:: with SMTP id t133mr2343857oib.85.1559875421836; Thu, 06 Jun 2019 19:43:41 -0700 (PDT) MIME-Version: 1.0 References: <155864919758.8626.11137277913302380197@ietfa.amsl.com> <98825f67-6958-8845-d5d5-3e0ac5e996e1@joelhalpern.com> <4903980b-49e2-1f8c-7575-2af4614e2c6b@joelhalpern.com> In-Reply-To: <4903980b-49e2-1f8c-7575-2af4614e2c6b@joelhalpern.com> From: Greg Mirsky Date: Thu, 6 Jun 2019 19:43:32 -0700 Message-ID: Subject: Re: Rtgdir last call review of draft-ietf-bfd-vxlan-07 To: "Joel M. Halpern" Cc: rtg-dir@ietf.org, rtg-bfd WG , draft-ietf-bfd-vxlan.all@ietf.org, IETF list Content-Type: multipart/alternative; boundary="000000000000699b7e058ab2ccd8" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 02:43:47 -0000 --000000000000699b7e058ab2ccd8 Content-Type: text/plain; charset="UTF-8" Hi Joel, in the previous mail you've said: > As far as I know, in normal VxLAN oepration, VTEPs do NOT have their > own > MAC addresses within the scope of the VNI. I agree and note that VTEP's MAC addresses used in the inner Ethernet header don't have to be associated with a VNI. They are the same as used in the outer Ethernet header. And the BFD over VXLAN specification does modify the processing of the inner Ethernet frame comparing to the procedure described in RFC 7348. I don't say that the described method of encapsulating BFD over VXLAN is the only one, but it is what has been discussed and supported by BFD WG. Also, AFAIK, at least one implementation already exists. Regards, Greg On Thu, Jun 6, 2019 at 5:53 PM Joel M. Halpern wrote: > There is a reason the "Outer Ethernet Header" in section 5 of 7348 is > labeled as "example". That outer header will actually vary hop by hop > along the IP network between the source VTEP and the desination VTEP. > Unless the source and destination VTEP are one IP hope apart, the source > VTEP will not even know the Ethernet MAC address of the destination VP. > It will simply address the outer IP packet, and let IP rotuing do its > job (that is the whole point of VxLAN.) > > More importantly, it is not associated with any VNI as it is the outer > header. Your usage is as an inner Ethernet Destination address. The > inner Ethernet header is the tenant space. The VTEPs do not impinge on > that space. Nor use any values from it. > > Yours, > Joel > > On 6/6/19 8:18 PM, Greg Mirsky wrote: > > Hi Joel, > > thank you for the clarification of your concern. For the inner Ethernet > > header, the destination and source MAC addresses are as described in > > Section 5 of RFC 7348 for VXLAN's outer Ethernet header: > > The outer destination MAC address in this frame may > > be the address of the target VTEP or of an intermediate Layer 3 > > router. > > As I understand this example, a VTEP must have MAC address assigned. The > > address used as the source MAC address of the outer Ethernet frame and > > may be used by a remote VTEP as destination MAC address in the outer > > Ethernet frame. This MAC address is not, as I understand, associated > > with any VNI. Perhaps we can add text to point to Section 5 RFC 7348 and > > how VTEP MAC address is used in the outer Ethernet header of a VXLAN > > packet. If you agree, I'll polish the new update in a day. > > > > Regards, > > Greg > > > > On Wed, Jun 5, 2019 at 8:20 PM Joel M. Halpern > > wrote: > > > > I am having trouble parsing your response. Apologies. > > The first part talks about a VTEP receiving a packet, and > > determining if > > there is a receiver VM for the inner MAC. That is a quote from 7348 > > Section 4.1. I understand it. > > > > You then go on to quote from section 5 of the BFD over VxLAN > > specification saying that it modifies this to specify that the VTEP > > checks for its own MAC address. > > The only problem is that the VTEP is not part of the tenant network. > > Any MAC address you want it to use may be in use by the tenant > network. > > As far as I know, in normal VxLAN oepration, VTEPs do NOT have their > > own > > MAC addresses within the scope of the VNI. > > > > Now, if you say that BFD will only be used with VNI 0 (i.e. a VNI > that > > is not assigned to a tenant), then the conflict goes away. But > again, > > there is no need for special MAC checking. Just declare that the > VTEP > > looks for OAM content on VNI 0. > > > > So no, your proposed change does not address my concern, as "VTEP's > MAC > > address is not, to the best of my knowledge, a well-defined term. I > am > > happy to be shown where such a thing is defined for use within > > tenant VNIs. > > > > Yours, > > Joel > > > > On 6/5/19 9:55 PM, Greg Mirsky wrote: > > > Hi Joel, > > > I cannot find the text in RFC 7348 that suggests that any > > > VXLAN-encapsulated frame received by VTEP must be forwarded to a > VM > > > associated with the specified VNI. But I've found the text in > > section > > > 4.1 that makes the forwarding of the inner frame to VM > > conditional to > > > the destination MAC address matching to VM's MAC: > > > Upon reception, the remote VTEP > > > verifies the validity of the VNI and whether or not there is > > a VM on > > > that VNI using a MAC address that matches the inner > > destination MAC > > > address. If so, the packet is stripped of its encapsulating > > headers > > > and passed on to the destination VM. > > > BFD over VXLAN specification in section 5 clarifies the > > processing of > > > the received VXLAN packet by the remote VXLAN: > > > Once a packet is received, VTEP MUST validate the packet. If > the > > > Destination MAC of the inner MAC frame matches the MAC > > address of the > > > VTEP the packet MUST be processed further. > > > > > > The UDP destination port and the TTL of the inner IP packet > > MUST be > > > validated to determine if the received packet can be > processed by > > > BFD. BFD packet with inner MAC set to VTEP's MAC address > > MUST NOT be > > > forwarded to VMs. > > > Would this text address your concern? > > > > > > Regards, > > > Greg > > > > > > On Wed, Jun 5, 2019 at 2:47 PM Joel M. Halpern > > > > > >> wrote: > > > > > > The inner packet of a VxLAN header with a VNI is a tenant > > packet for > > > the > > > tenant identified by the VNI. That is the meaning of the > > inner packet. > > > > > > If you declare that the flag bits change that meaning, then > > that flag > > > bit has to adjust the packet processing at the VTEP such taht > > it will > > > intercept the packet. As such, it doesn;t need special inner > > source or > > > dest mac addresses or IP addresses. In fact, the inner > > packet can just > > > be OAM payload. > > > > > > If that is not what you intend, then how is it that the VTEP > > knows that > > > the inner addresses are for it to examine, rather than > > belonging to the > > > tenant. As far as I know we are not free to take addresses > > away from > > > the tenant. > > > > > > It may be that I am completely missing how this is supposed to > > > work. If > > > so, it needs better explanation. > > > > > > Yours, > > > Joel > > > > > > On 6/5/19 5:20 PM, Greg Mirsky wrote: > > > > Hi Joel, > > > > thank you for your review and the pointed questions. > > Please find my > > > > answers, comments in-line and tagged GIM>>. > > > > > > > > Regards, > > > > Greg > > > > > > > > > > > > On Thu, May 23, 2019 at 3:06 PM Joel Halpern via > Datatracker > > > > > > > > > > > > >>> wrote: > > > > > > > > Reviewer: Joel Halpern > > > > Review result: Has Issues > > > > > > > > Hello, > > > > > > > > I have been selected as the Routing Directorate > > reviewer for this > > > > draft. The > > > > Routing Directorate seeks to review all routing or > > > routing-related > > > > drafts as > > > > they pass through IETF last call and IESG review, and > > > sometimes on > > > > special > > > > request. The purpose of the review is to provide > > assistance > > > to the > > > > Routing ADs. > > > > For more information about the Routing Directorate, > > please see > > > > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > > > > > > > Although these comments are primarily for the use of > > the Routing > > > > ADs, it would > > > > be helpful if you could consider them along with any > other > > > IETF Last > > > > Call > > > > comments that you receive, and strive to resolve them > > through > > > > discussion or by > > > > updating the draft. > > > > > > > > Document: ddraft-ietf-bfd-vxlan-07 > > > > Reviewer: your-name > > > > Review Date: date > > > > IETF LC End Date: date-if-known > > > > Intended Status: copy-from-I-D > > > > > > > > Summary: This document does not appear to be ready for > > > publication as a > > > > Proposed Standard RFC. > > > > > > > > Major issues: > > > > The scoping of the BFD usage is unclear. In > places, > > > this looks > > > > like it is > > > > intended to be used by the underlay service > > provider, > > > who will > > > > monitor the > > > > connectivity between VTEPs. > > > > > > > > GIM>> I think that the DCI provider would not be able to > > > instantiate a > > > > BFD session using VXLAN encapsulation and, possibly, > > monitor that > > > VXLAN > > > > part of forwarding operates properly. Such BFD session may > > > monitor the > > > > path between the two VTEP but, if there exists ECMP > > environment > > > in the > > > > transport, ensuring that that BFD session follows the same > > path > > > as VXLAN > > > > data may be challenging. > > > > > > > > In other places it seems to be aimed at > > > > monitoring individual VNIs. > > > > > > > > GIM>> The BFD session between VTEPs is not actually used to > > > monitor the > > > > particular VNI but MAY be used to communicate, as > > concatenated path > > > > state signaling, the change of VNI state using the method > > > described in > > > > Section 6.8.17 RFC 5880 > > > > . > > > > > > > > This is made worse when the packet format is > > > > laid out. The inner packet is an Ethernet Packet > > with an IP > > > > packet (with > > > > UDP, with BFD). This means that it is a tenant > > packet. > > > > > > > > GIM>> Could you please point to the text which suggests > > that the BFD > > > > control packet is a tenant packet? Meant to be delivered > > to a tenant? > > > > > > > > The IP address is > > > > a tenant IP. > > > > > > > > GIM>> The explanation of the format states in regard to > > the inner > > > IP header: > > > > IP header: > > > > > > > > Source IP: IP address of the originating VTEP. > > > > > > > > Destination IP: IP address of the terminating > VTEP. > > > > > > > > But the diagram shows this as being the IP address of > the > > > > VTEP. Which is not a tenant entity. > > > > > > > > There is further confusion as to whether the > > processing is > > > > driven by the VNI > > > > the packet arrived with, or the VNI is ignored. > > > > > > > > GIM>> The use of VNI is implementation specific. Section 6 > > states: > > > > 6. Use of the Specific VNI > > > > > > > > In most cases, a single BFD session is sufficient for > the > > > given VTEP > > > > to monitor the reachability of a remote VTEP, > > regardless of the > > > > number of VNIs in common. When the single BFD session > > is used to > > > > monitor the reachability of the remote VTEP, an > > > implementation SHOULD > > > > choose any of the VNIs but MAY choose VNI = 0. > > > > > > > > > > > > Minor Issues: > > > > N/A > > > > > > > > Nits: N/A > > > > > > > > > > --000000000000699b7e058ab2ccd8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Joel,
in the previous mail you'= ;ve said:
>=C2=A0 =C2=A0 =C2=A0As far as I know, in normal VxL= AN oepration, VTEPs do NOT have their
>=C2=A0 =C2=A0 =C2=A0own
>= ;=C2=A0 =C2=A0 =C2=A0MAC addresses within the scope of the VNI.=C2=A0
=
I agree and note that VTEP's MAC addresses used in the inner Ether= net header don't have to be associated with a VNI. They are the same as= used in the outer Ethernet header. And the BFD over VXLAN specification do= es modify the processing of the inner Ethernet frame comparing to the proce= dure described in RFC 7348.
I don't say that the describe= d method of encapsulating BFD over VXLAN is the only one, but it is what ha= s been discussed and supported by BFD WG. Also, AFAIK, at least one impleme= ntation already exists.


Regards,
Greg

On Thu, Jun 6, 2019 at 5:53 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:
There is a reason the &= quot;Outer Ethernet Header" in section 5 of 7348 is
labeled as "example".=C2=A0 That outer header will actually vary = hop by hop
along the IP network between the source VTEP and the desination VTEP.
Unless the source and destination VTEP are one IP hope apart, the source VTEP will not even know the Ethernet MAC address of the destination VP. It will simply address the outer IP packet, and let IP rotuing do its
job (that is the whole point of VxLAN.)

More importantly, it is not associated with any VNI as it is the outer
header.=C2=A0 Your usage is as an inner Ethernet Destination address.=C2=A0= The
inner Ethernet header is the tenant space.=C2=A0 The VTEPs do not impinge o= n
that space.=C2=A0 Nor use any values from it.

Yours,
Joel

On 6/6/19 8:18 PM, Greg Mirsky wrote:
> Hi Joel,
> thank you for the clarification of your concern. For the inner Etherne= t
> header, the destination and source MAC addresses are as described in <= br> > Section 5 of RFC 7348 for VXLAN's outer Ethernet header:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0The outer destination MAC address in this fr= ame may
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 be the address of the target VTEP or of an = intermediate Layer 3
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 router.
> As I understand this example, a VTEP must have MAC address assigned. T= he
> address used as the source MAC address of the outer Ethernet frame and=
> may be used by a remote VTEP as destination MAC address in the outer <= br> > Ethernet frame. This MAC address is not, as I understand, associated <= br> > with any VNI. Perhaps we can add text to point to Section 5 RFC 7348 a= nd
> how VTEP MAC address is used in the outer Ethernet header of a VXLAN <= br> > packet. If you agree, I'll polish the new update in a day.
>
> Regards,
> Greg
>
> On Wed, Jun 5, 2019 at 8:20 PM Joel M. Halpern <jmh@joelhalpern.com
> <mailto:jm= h@joelhalpern.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0I am having trouble parsing your response.=C2=A0 Ap= ologies.
>=C2=A0 =C2=A0 =C2=A0The first part talks about a VTEP receiving a packe= t, and
>=C2=A0 =C2=A0 =C2=A0determining if
>=C2=A0 =C2=A0 =C2=A0there is a receiver VM for the inner MAC.=C2=A0 Tha= t is a quote from 7348
>=C2=A0 =C2=A0 =C2=A0Section 4.1.=C2=A0 I understand it.
>
>=C2=A0 =C2=A0 =C2=A0You then go on to quote from section 5 of the BFD o= ver VxLAN
>=C2=A0 =C2=A0 =C2=A0specification saying that it modifies this to speci= fy that the VTEP
>=C2=A0 =C2=A0 =C2=A0checks for its own MAC address.
>=C2=A0 =C2=A0 =C2=A0The only problem is that the VTEP is not part of th= e tenant network.
>=C2=A0 =C2=A0 =C2=A0Any MAC address you want it to use may be in use by= the tenant network.
>=C2=A0 =C2=A0 =C2=A0As far as I know, in normal VxLAN oepration, VTEPs = do NOT have their
>=C2=A0 =C2=A0 =C2=A0own
>=C2=A0 =C2=A0 =C2=A0MAC addresses within the scope of the VNI.
>
>=C2=A0 =C2=A0 =C2=A0Now, if you say that BFD will only be used with VNI= 0 (i.e. a VNI that
>=C2=A0 =C2=A0 =C2=A0is not assigned to a tenant), then the conflict goe= s away.=C2=A0 But again,
>=C2=A0 =C2=A0 =C2=A0there is no need for special MAC checking.=C2=A0 Ju= st declare that the VTEP
>=C2=A0 =C2=A0 =C2=A0looks for OAM content on VNI 0.
>
>=C2=A0 =C2=A0 =C2=A0So no, your proposed change does not address my con= cern, as "VTEP's MAC
>=C2=A0 =C2=A0 =C2=A0address is not, to the best of my knowledge, a well= -defined term.=C2=A0 I am
>=C2=A0 =C2=A0 =C2=A0happy to be shown where such a thing is defined for= use within
>=C2=A0 =C2=A0 =C2=A0tenant VNIs.
>
>=C2=A0 =C2=A0 =C2=A0Yours,
>=C2=A0 =C2=A0 =C2=A0Joel
>
>=C2=A0 =C2=A0 =C2=A0On 6/5/19 9:55 PM, Greg Mirsky wrote:
>=C2=A0 =C2=A0 =C2=A0 > Hi Joel,
>=C2=A0 =C2=A0 =C2=A0 > I cannot find the text in RFC 7348 that sugge= sts that any
>=C2=A0 =C2=A0 =C2=A0 > VXLAN-encapsulated frame received by VTEP mus= t be forwarded to a VM
>=C2=A0 =C2=A0 =C2=A0 > associated with the specified VNI. But I'= ve found the text in
>=C2=A0 =C2=A0 =C2=A0section
>=C2=A0 =C2=A0 =C2=A0 > 4.1 that makes the forwarding of the inner fr= ame to VM
>=C2=A0 =C2=A0 =C2=A0conditional to
>=C2=A0 =C2=A0 =C2=A0 > the destination MAC address matching to VM= 9;s MAC:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Upon reception, the remote= VTEP
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0verifies the validity of t= he VNI and whether or not there is
>=C2=A0 =C2=A0 =C2=A0a VM on
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0that VNI using a MAC addre= ss that matches the inner
>=C2=A0 =C2=A0 =C2=A0destination MAC
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0address.=C2=A0 If so, the = packet is stripped of its encapsulating
>=C2=A0 =C2=A0 =C2=A0headers
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0and passed on to the desti= nation VM.
>=C2=A0 =C2=A0 =C2=A0 > BFD over VXLAN specification in section 5 cla= rifies the
>=C2=A0 =C2=A0 =C2=A0processing of
>=C2=A0 =C2=A0 =C2=A0 > the received VXLAN packet by the remote VXLAN= :
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Once a packet is received,= VTEP MUST validate the packet.=C2=A0 If the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Destination MAC of the inn= er MAC frame matches the MAC
>=C2=A0 =C2=A0 =C2=A0address of the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0VTEP the packet MUST be pr= ocessed further.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0The UDP destination port a= nd the TTL of the inner IP packet
>=C2=A0 =C2=A0 =C2=A0MUST be
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0validated to determine if = the received packet can be processed by
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0BFD.=C2=A0 BFD packet with= inner MAC set to VTEP's MAC address
>=C2=A0 =C2=A0 =C2=A0MUST NOT be
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0forwarded to VMs.
>=C2=A0 =C2=A0 =C2=A0 > Would this text address your concern?
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Regards,
>=C2=A0 =C2=A0 =C2=A0 > Greg
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > On Wed, Jun 5, 2019 at 2:47 PM Joel M. Halper= n
>=C2=A0 =C2=A0 =C2=A0<jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>
>=C2=A0 =C2=A0 =C2=A0 > <mailto:jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>>>= wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0The inner packet of a VxLA= N header with a VNI is a tenant
>=C2=A0 =C2=A0 =C2=A0packet for
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0tenant identified by the V= NI.=C2=A0 That is the meaning of the
>=C2=A0 =C2=A0 =C2=A0inner packet.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0If you declare that the fl= ag bits change that meaning, then
>=C2=A0 =C2=A0 =C2=A0that flag
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0bit has to adjust the pack= et processing at the VTEP such taht
>=C2=A0 =C2=A0 =C2=A0it will
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0intercept the packet.=C2= =A0 As such, it doesn;t need special inner
>=C2=A0 =C2=A0 =C2=A0source or
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0dest mac addresses or IP a= ddresses.=C2=A0 In fact, the inner
>=C2=A0 =C2=A0 =C2=A0packet can just
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0be OAM payload.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0If that is not what you in= tend, then how is it that the VTEP
>=C2=A0 =C2=A0 =C2=A0knows that
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0the inner addresses are fo= r it to examine, rather than
>=C2=A0 =C2=A0 =C2=A0belonging to the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0tenant.=C2=A0 As far as I = know we are not free to take addresses
>=C2=A0 =C2=A0 =C2=A0away from
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0the tenant.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0It may be that I am comple= tely missing how this is supposed to
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0work.=C2=A0 If
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0so, it needs better explan= ation.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Yours,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Joel
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On 6/5/19 5:20 PM, Greg Mi= rsky wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Hi=C2=A0Joel,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > thank you for your r= eview and the pointed questions.
>=C2=A0 =C2=A0 =C2=A0Please find my
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > answers, comments in= -line and tagged GIM>>.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =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 =C2=A0 > Greg
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=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 Thu, May 23, 2019= at 3:06 PM Joel Halpern via Datatracker
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > <noreply@ietf.org <mailto:noreply@ietf.org> >=C2=A0 =C2=A0 =C2=A0<mailto:noreply@ietf.org <mailto:noreply@ietf.org>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<mailto:noreply@ietf.org <mailto:noreply@ietf.org><= br> >=C2=A0 =C2=A0 =C2=A0<mailto:noreply@ietf.org <mailto:noreply@ietf.org>>>> 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=A0R= eviewer: Joel Halpern
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0R= eview result: Has Issues
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0H= ello,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I= have been selected as the Routing Directorate
>=C2=A0 =C2=A0 =C2=A0reviewer for this
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0d= raft. The
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0R= outing Directorate seeks to review all routing or
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0routing-related
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0d= rafts as
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0t= hey pass through IETF last call and IESG review, and
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0sometimes on
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0s= pecial
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0r= equest. The purpose of the review is to provide
>=C2=A0 =C2=A0 =C2=A0assistance
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0to the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0R= outing ADs.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0F= or more information about the Routing Directorate,
>=C2=A0 =C2=A0 =C2=A0please see
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0A= lthough these comments are primarily for the use of
>=C2=A0 =C2=A0 =C2=A0the Routing
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0A= Ds, it would
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0b= e helpful if you could consider them along with any other
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0IETF Last
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0C= all
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0c= omments that you receive, and strive to resolve them
>=C2=A0 =C2=A0 =C2=A0through
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0d= iscussion or by
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0u= pdating the draft.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0D= ocument: ddraft-ietf-bfd-vxlan-07
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0R= eviewer: your-name
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0R= eview Date: date
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I= ETF LC End Date: date-if-known
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I= ntended Status: copy-from-I-D
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0S= ummary: This document does not appear to be ready for
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0publication as a
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0P= roposed Standard RFC.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0M= ajor issues:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 The scoping of the BFD usage is unclear.=C2=A0 In places,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0this looks
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0l= ike it is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 intended to be used by the underlay service
>=C2=A0 =C2=A0 =C2=A0provider,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0who will
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0m= onitor the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 connectivity between VTEPs.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > GIM>> I think = that the DCI provider would not be able to
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0instantiate a
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > BFD session using VX= LAN encapsulation and, possibly,
>=C2=A0 =C2=A0 =C2=A0monitor that
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0VXLAN
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > part of forwarding o= perates properly. Such BFD session may
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0monitor the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > path between the two= VTEP but, if there exists ECMP
>=C2=A0 =C2=A0 =C2=A0environment
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0in the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > transport, ensuring = that that BFD session follows the same
>=C2=A0 =C2=A0 =C2=A0path
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0as VXLAN
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > data may be challeng= ing.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I= n other places it seems to be aimed at
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 monitoring individual VNIs.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > GIM>> The BFD = session between VTEPs is not actually used to
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0monitor the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > particular VNI but M= AY be used to communicate, as
>=C2=A0 =C2=A0 =C2=A0concatenated path
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > state signaling, the= change of VNI state using the method
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0described in
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Section 6.8.17 RFC 5= 880
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > <https://tools.ietf.org/html/rfc5880#section-6.8.17>.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0T= his is made worse when the packet format is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 laid out.=C2=A0 The inner packet is an Ethernet Packet
>=C2=A0 =C2=A0 =C2=A0with an IP
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0p= acket (with
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 UDP, with BFD).=C2=A0 This means that it is a tenant
>=C2=A0 =C2=A0 =C2=A0packet.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > GIM>> Could yo= u please point to the text which suggests
>=C2=A0 =C2=A0 =C2=A0that the BFD
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > control packet is a = tenant packet? Meant to be delivered
>=C2=A0 =C2=A0 =C2=A0to a tenant?
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0T= he IP address is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 a tenant IP.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > GIM>> The expl= anation of the format states in regard to
>=C2=A0 =C2=A0 =C2=A0the inner
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0IP header:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0IP 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=A0Source IP: IP address of the originating VTEP.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0Destination IP: IP address of the terminating VTEP.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0B= ut the diagram shows this as being the IP address of the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 VTEP.=C2=A0 Which is not a tenant entity.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0There is further confusion as to whether the
>=C2=A0 =C2=A0 =C2=A0processing is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0d= riven by the VNI
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0the packet arrived with, or the VNI is ignored.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > GIM>> The use = of VNI is implementation specific. Section 6
>=C2=A0 =C2=A0 =C2=A0states:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A06.=C2=A0= Use of the Specific VNI
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0I= n most cases, a single BFD session is sufficient for the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0given VTEP
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0t= o monitor the reachability of a remote VTEP,
>=C2=A0 =C2=A0 =C2=A0regardless of the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0n= umber of VNIs in common.=C2=A0 When the single BFD session
>=C2=A0 =C2=A0 =C2=A0is used to
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0m= onitor the reachability of the remote VTEP, an
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0implementation SHOULD
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0c= hoose any of the VNIs but MAY choose VNI =3D 0.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0M= inor Issues:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0N/A
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0N= its: N/A
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>
--000000000000699b7e058ab2ccd8-- From nobody Thu Jun 6 20:05:20 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3616120156; Thu, 6 Jun 2019 20:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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_LOW=-0.7, 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=joelhalpern.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 Z173-eDZxE6i; Thu, 6 Jun 2019 20:05:15 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (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 DE8F21200B6; Thu, 6 Jun 2019 20:05:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 45KnT60r6Sz15Qpv; Thu, 6 Jun 2019 20:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1559876714; bh=5D0iggVtblcVmp6SB+UoMdolyufi6w0bSglYkB1AVSY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=dXqE+ZVRVD2iluJYUUbLp1eBdfoLEYJbqucV8zGAjP7+wpLAwrd+U3l7uMp20pXip P/3QVMT8rLkq+S7gsXLRf72tjWGfapot5GXRIJc1lF1fRfyy5BwjGzf/5ww1Z2Kepd updwM/gnuDPVKAuNnfZ7ycuCtxJZl3gSa8TGL7hA= X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 45KnT50dl9z15Qps; Thu, 6 Jun 2019 20:05:12 -0700 (PDT) Subject: Re: [RTG-DIR] Rtgdir last call review of draft-ietf-bfd-vxlan-07 To: Greg Mirsky Cc: rtg-dir@ietf.org, rtg-bfd WG , draft-ietf-bfd-vxlan.all@ietf.org, IETF list References: <155864919758.8626.11137277913302380197@ietfa.amsl.com> <98825f67-6958-8845-d5d5-3e0ac5e996e1@joelhalpern.com> <4903980b-49e2-1f8c-7575-2af4614e2c6b@joelhalpern.com> From: "Joel M. Halpern" Message-ID: Date: Thu, 6 Jun 2019 23:05:11 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 03:05:19 -0000 As far as I can tell, what you describe violates the base VxLAN specification by requiring that the VTEP have a MAC address within the tenant space. If there were no other way to make BFD work for VxLAN except biolating the spec, then I would epect the document to be very explicit that it was taking MAC address away from the tenant space. Given that there clearly are other ways to achieve the goal that do not violate the underlying VxLAN spec, I think the IETF is obliged to use something else. Yours, Joel PS: Having said that, I grant that for this purpose I have no more standing than any other WG member. On 6/6/19 10:43 PM, Greg Mirsky wrote: > Hi Joel, > in the previous mail you've said: > >     As far as I know, in normal VxLAN oepration, VTEPs do NOT have their > >     own > >     MAC addresses within the scope of the VNI. > I agree and note that VTEP's MAC addresses used in the inner Ethernet > header don't have to be associated with a VNI. They are the same as used > in the outer Ethernet header. And the BFD over VXLAN specification does > modify the processing of the inner Ethernet frame comparing to the > procedure described in RFC 7348. > I don't say that the described method of encapsulating BFD over VXLAN is > the only one, but it is what has been discussed and supported by BFD WG. > Also, AFAIK, at least one implementation already exists. > > > Regards, > Greg > > On Thu, Jun 6, 2019 at 5:53 PM Joel M. Halpern > wrote: > > There is a reason the "Outer Ethernet Header" in section 5 of 7348 is > labeled as "example".  That outer header will actually vary hop by hop > along the IP network between the source VTEP and the desination VTEP. > Unless the source and destination VTEP are one IP hope apart, the > source > VTEP will not even know the Ethernet MAC address of the destination VP. > It will simply address the outer IP packet, and let IP rotuing do its > job (that is the whole point of VxLAN.) > > More importantly, it is not associated with any VNI as it is the outer > header.  Your usage is as an inner Ethernet Destination address.  The > inner Ethernet header is the tenant space.  The VTEPs do not impinge on > that space.  Nor use any values from it. > > Yours, > Joel > > On 6/6/19 8:18 PM, Greg Mirsky wrote: > > Hi Joel, > > thank you for the clarification of your concern. For the inner > Ethernet > > header, the destination and source MAC addresses are as described in > > Section 5 of RFC 7348 for VXLAN's outer Ethernet header: > >       The outer destination MAC address in this frame may > >        be the address of the target VTEP or of an intermediate > Layer 3 > >        router. > > As I understand this example, a VTEP must have MAC address > assigned. The > > address used as the source MAC address of the outer Ethernet > frame and > > may be used by a remote VTEP as destination MAC address in the outer > > Ethernet frame. This MAC address is not, as I understand, associated > > with any VNI. Perhaps we can add text to point to Section 5 RFC > 7348 and > > how VTEP MAC address is used in the outer Ethernet header of a VXLAN > > packet. If you agree, I'll polish the new update in a day. > > > > Regards, > > Greg > > > > On Wed, Jun 5, 2019 at 8:20 PM Joel M. Halpern > > > >> wrote: > > > >     I am having trouble parsing your response.  Apologies. > >     The first part talks about a VTEP receiving a packet, and > >     determining if > >     there is a receiver VM for the inner MAC.  That is a quote > from 7348 > >     Section 4.1.  I understand it. > > > >     You then go on to quote from section 5 of the BFD over VxLAN > >     specification saying that it modifies this to specify that > the VTEP > >     checks for its own MAC address. > >     The only problem is that the VTEP is not part of the tenant > network. > >     Any MAC address you want it to use may be in use by the > tenant network. > >     As far as I know, in normal VxLAN oepration, VTEPs do NOT > have their > >     own > >     MAC addresses within the scope of the VNI. > > > >     Now, if you say that BFD will only be used with VNI 0 (i.e. a > VNI that > >     is not assigned to a tenant), then the conflict goes away. > But again, > >     there is no need for special MAC checking.  Just declare that > the VTEP > >     looks for OAM content on VNI 0. > > > >     So no, your proposed change does not address my concern, as > "VTEP's MAC > >     address is not, to the best of my knowledge, a well-defined > term.  I am > >     happy to be shown where such a thing is defined for use within > >     tenant VNIs. > > > >     Yours, > >     Joel > > > >     On 6/5/19 9:55 PM, Greg Mirsky wrote: > >      > Hi Joel, > >      > I cannot find the text in RFC 7348 that suggests that any > >      > VXLAN-encapsulated frame received by VTEP must be > forwarded to a VM > >      > associated with the specified VNI. But I've found the text in > >     section > >      > 4.1 that makes the forwarding of the inner frame to VM > >     conditional to > >      > the destination MAC address matching to VM's MAC: > >      >     Upon reception, the remote VTEP > >      >     verifies the validity of the VNI and whether or not > there is > >     a VM on > >      >     that VNI using a MAC address that matches the inner > >     destination MAC > >      >     address.  If so, the packet is stripped of its > encapsulating > >     headers > >      >     and passed on to the destination VM. > >      > BFD over VXLAN specification in section 5 clarifies the > >     processing of > >      > the received VXLAN packet by the remote VXLAN: > >      >     Once a packet is received, VTEP MUST validate the > packet.  If the > >      >     Destination MAC of the inner MAC frame matches the MAC > >     address of the > >      >     VTEP the packet MUST be processed further. > >      > > >      >     The UDP destination port and the TTL of the inner IP > packet > >     MUST be > >      >     validated to determine if the received packet can be > processed by > >      >     BFD.  BFD packet with inner MAC set to VTEP's MAC address > >     MUST NOT be > >      >     forwarded to VMs. > >      > Would this text address your concern? > >      > > >      > Regards, > >      > Greg > >      > > >      > On Wed, Jun 5, 2019 at 2:47 PM Joel M. Halpern > >      > > > >      > > >>> wrote: > >      > > >      >     The inner packet of a VxLAN header with a VNI is a tenant > >     packet for > >      >     the > >      >     tenant identified by the VNI.  That is the meaning of the > >     inner packet. > >      > > >      >     If you declare that the flag bits change that meaning, > then > >     that flag > >      >     bit has to adjust the packet processing at the VTEP > such taht > >     it will > >      >     intercept the packet.  As such, it doesn;t need > special inner > >     source or > >      >     dest mac addresses or IP addresses.  In fact, the inner > >     packet can just > >      >     be OAM payload. > >      > > >      >     If that is not what you intend, then how is it that > the VTEP > >     knows that > >      >     the inner addresses are for it to examine, rather than > >     belonging to the > >      >     tenant.  As far as I know we are not free to take > addresses > >     away from > >      >     the tenant. > >      > > >      >     It may be that I am completely missing how this is > supposed to > >      >     work.  If > >      >     so, it needs better explanation. > >      > > >      >     Yours, > >      >     Joel > >      > > >      >     On 6/5/19 5:20 PM, Greg Mirsky wrote: > >      >      > Hi Joel, > >      >      > thank you for your review and the pointed questions. > >     Please find my > >      >      > answers, comments in-line and tagged GIM>>. > >      >      > > >      >      > Regards, > >      >      > Greg > >      >      > > >      >      > > >      >      > On Thu, May 23, 2019 at 3:06 PM Joel Halpern via > Datatracker > >      >      > > > > >      > >> > >      >      > > > >      > >>>> wrote: > >      >      > > >      >      >     Reviewer: Joel Halpern > >      >      >     Review result: Has Issues > >      >      > > >      >      >     Hello, > >      >      > > >      >      >     I have been selected as the Routing Directorate > >     reviewer for this > >      >      >     draft. The > >      >      >     Routing Directorate seeks to review all routing or > >      >     routing-related > >      >      >     drafts as > >      >      >     they pass through IETF last call and IESG > review, and > >      >     sometimes on > >      >      >     special > >      >      >     request. The purpose of the review is to provide > >     assistance > >      >     to the > >      >      >     Routing ADs. > >      >      >     For more information about the Routing Directorate, > >     please see > >      >      > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > >      >      > > >      >      >     Although these comments are primarily for the > use of > >     the Routing > >      >      >     ADs, it would > >      >      >     be helpful if you could consider them along > with any other > >      >     IETF Last > >      >      >     Call > >      >      >     comments that you receive, and strive to > resolve them > >     through > >      >      >     discussion or by > >      >      >     updating the draft. > >      >      > > >      >      >     Document: ddraft-ietf-bfd-vxlan-07 > >      >      >     Reviewer: your-name > >      >      >     Review Date: date > >      >      >     IETF LC End Date: date-if-known > >      >      >     Intended Status: copy-from-I-D > >      >      > > >      >      >     Summary: This document does not appear to be > ready for > >      >     publication as a > >      >      >     Proposed Standard RFC. > >      >      > > >      >      >     Major issues: > >      >      >          The scoping of the BFD usage is unclear. > In places, > >      >     this looks > >      >      >     like it is > >      >      >          intended to be used by the underlay service > >     provider, > >      >     who will > >      >      >     monitor the > >      >      >          connectivity between VTEPs. > >      >      > > >      >      > GIM>> I think that the DCI provider would not be > able to > >      >     instantiate a > >      >      > BFD session using VXLAN encapsulation and, possibly, > >     monitor that > >      >     VXLAN > >      >      > part of forwarding operates properly. Such BFD > session may > >      >     monitor the > >      >      > path between the two VTEP but, if there exists ECMP > >     environment > >      >     in the > >      >      > transport, ensuring that that BFD session follows > the same > >     path > >      >     as VXLAN > >      >      > data may be challenging. > >      >      > > >      >      >     In other places it seems to be aimed at > >      >      >          monitoring individual VNIs. > >      >      > > >      >      > GIM>> The BFD session between VTEPs is not actually > used to > >      >     monitor the > >      >      > particular VNI but MAY be used to communicate, as > >     concatenated path > >      >      > state signaling, the change of VNI state using the > method > >      >     described in > >      >      > Section 6.8.17 RFC 5880 > >      >      > . > >      >      > > >      >      >     This is made worse when the packet format is > >      >      >          laid out.  The inner packet is an Ethernet > Packet > >     with an IP > >      >      >     packet (with > >      >      >          UDP, with BFD).  This means that it is a > tenant > >     packet. > >      >      > > >      >      > GIM>> Could you please point to the text which suggests > >     that the BFD > >      >      > control packet is a tenant packet? Meant to be > delivered > >     to a tenant? > >      >      > > >      >      >     The IP address is > >      >      >          a tenant IP. > >      >      > > >      >      > GIM>> The explanation of the format states in regard to > >     the inner > >      >     IP header: > >      >      >         IP header: > >      >      > > >      >      >           Source IP: IP address of the originating > VTEP. > >      >      > > >      >      >           Destination IP: IP address of the > terminating VTEP. > >      >      > > >      >      >     But the diagram shows this as being the IP > address of the > >      >      >          VTEP.  Which is not a tenant entity. > >      >      > > >      >      >         There is further confusion as to whether the > >     processing is > >      >      >     driven by the VNI > >      >      >         the packet arrived with, or the VNI is ignored. > >      >      > > >      >      > GIM>> The use of VNI is implementation specific. > Section 6 > >     states: > >      >      >   6.  Use of the Specific VNI > >      >      > > >      >      >     In most cases, a single BFD session is > sufficient for the > >      >     given VTEP > >      >      >     to monitor the reachability of a remote VTEP, > >     regardless of the > >      >      >     number of VNIs in common.  When the single BFD > session > >     is used to > >      >      >     monitor the reachability of the remote VTEP, an > >      >     implementation SHOULD > >      >      >     choose any of the VNIs but MAY choose VNI = 0. > >      >      > > >      >      > > >      >      >     Minor Issues: > >      >      >         N/A > >      >      > > >      >      >     Nits: N/A > >      >      > > >      > > > > From nobody Fri Jun 7 03:51:57 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 328C5120223 for ; Fri, 7 Jun 2019 03:51:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 drSnf6SY0KGO for ; Fri, 7 Jun 2019 03:51:53 -0700 (PDT) Received: from de-out1.bosch-org.com (de-out1.bosch-org.com [139.15.230.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5A1120157 for ; Fri, 7 Jun 2019 03:51:53 -0700 (PDT) Received: from fe0vm1649.rbesz01.com (unknown [139.15.230.188]) by si0vms0216.rbdmz01.com (Postfix) with ESMTPS id 45KzqW1wnNz1XLGLy for ; Fri, 7 Jun 2019 12:51:51 +0200 (CEST) Received: from si0vm4642.rbesz01.com (unknown [10.58.172.176]) by fe0vm1649.rbesz01.com (Postfix) with ESMTPS id 45KzqW1CC0z1K3 for ; Fri, 7 Jun 2019 12:51:51 +0200 (CEST) X-AuditID: 0a3aad12-bfbff70000006e39-5b-5cfa41c633d6 Received: from fe0vm1652.rbesz01.com ( [10.58.173.29]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by si0vm4642.rbesz01.com (SMG Outbound) with SMTP id AD.FF.28217.6C14AFC5; Fri, 7 Jun 2019 12:51:51 +0200 (CEST) Received: from SI-MBX2054.de.bosch.com (si-mbx2054.de.bosch.com [10.3.230.148]) by fe0vm1652.rbesz01.com (Postfix) with ESMTPS id 45KzqV6kzmz5gX for ; Fri, 7 Jun 2019 12:51:50 +0200 (CEST) Received: from SI-MBX2054.de.bosch.com (10.3.230.148) by SI-MBX2054.de.bosch.com (10.3.230.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Fri, 7 Jun 2019 12:51:50 +0200 Received: from SI-MBX2054.de.bosch.com ([fe80::187:74e0:f8c8:c9b1]) by SI-MBX2054.de.bosch.com ([fe80::187:74e0:f8c8:c9b1%4]) with mapi id 15.01.1713.006; Fri, 7 Jun 2019 12:51:50 +0200 From: "Schwarz Albrecht (ETAS/ESY1)" To: "rtg-bfd@ietf.org" Subject: Direct BFD over Ethernet? Thread-Topic: Direct BFD over Ethernet? Thread-Index: AdUdHwIY3QLc2dE1SwCr012LbinkaA== Date: Fri, 7 Jun 2019 10:51:50 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.224.142] Content-Type: multipart/alternative; boundary="_000_e06e6a9189eb4174a6777da720d31294etascom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA22TfUwbdRjH+V3fjoazx0HHs25IvC1Z1KwCsokMFc10RrdhFo0JdrJjHG2V tuSuNID/NNuMs4puExwjUMpotgUDowh0UZGsxgE6szpeRJ2RDcLLGjdMHS8dAe88WPuH//zy /X2e5/s8zz2XHy6jGnEdbrbaWc7KlNJKtVyd05a6vf/5iCE9GMKyw8s9KA+97PUuYa+hAnVu MVtqdrDcE88eUpuqpzsVZffpinOeVaUTdaW5UDwOZBac/nRI5kJqnCLrMJhqGFFJlyEEH/jD CulyB0E4soSJForsRfDPXIKolWQeDI4eVYo6mXwU2hr8ClEnkTT4R/owiW+DSee0oHFB62Hh /G4Ry8mt0LXYqhIxQT4F1TW5IkZkKnR0XJOJWkamwG+TTZg0KAnebyQOpBZmJ1YUohWETp9P 7ZXSC6Glz//fMASZCINnJuUnUFJ9TKX6mLT6mDSJ62GstkYp6cfhXHNIJuntULcSkMdyD1K1 Ii1vTndYsnZmZeq5IpavSs/QH7ZZOpH0U6hLyDdaEkAkjugEwr4lYqAUjIOvtATQDhyjtYRd I6CHimzFlSaGNxVy5aUsT+uIzcFXDFTSA8yXF1nMPG+2WQMIcBmdTDiCiwaKKGYqq1jOJtkC aBMup1MII55voEgjY2ffZdkylluP7sJxGojMPKFhIsca2YoSc6l9PUynEiguLo7aEBuJbYvh 8QH0JJ4g9PY8J5Qg+DLGwpuNa/aNkp1ap1HrD+gN/MRs41kZfvl7t3D+3eoVzgXxpORWm5XV pRCvi0ORotdUbn0wk24z8c7pBQOljQlE695Gt5Cw1SQiTTQnCK8hOg0Qm8QFJq7BqCmzXfCQ zRiEjxyAU3VuFbx/b1wFPV3XNeD13SLh6rHmNDi+Mr4VZsaasqDB+fUO6J9ofxp+vfvVLhho v/IMuL1HX4RTq717YPju8D5YvPpTPswM9L0J7uBfb8HS7/MHYeZ+owU+ro5Y4FJwmYcbYzXV CGbmTp5E0D7+cy2CDv/wBQSLXX9eRPCjc84nPCxfSzcCd+TIFQS1Ic8vCFZvTobQbWHnmLBz TXBe3Lmdsf/Pztdo9DN1TgSHbxw7OEphH52dduzxhkKee9kF3575Qz02mz2/pUlfsIxfr+xU 5DvvVI1MDB0a6VWENu4/ULhh6oWKnOmpXO3uthT2mivsTja6B7pvXv6Sc52P+y5v4IvEbcc/ fLjxpQzX3p5XB9/+TBufrVrNaSnp9s1mlGjS3tv5iFpzoZ+4mPMJLedNTMZjMo5n/gVFQOTz sAQAAA== Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 10:51:56 -0000 --_000_e06e6a9189eb4174a6777da720d31294etascom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear BFD experts, just a simple question: which BFD RFC would be applicable for applying BFD = over an Ethernet link (no VLAN, no LAG)? Direct over Ethernet, without IP. Thanks, Albrecht Mit freundlichen Gr=FC=DFen / Best regards Dr. Albrecht Schwarz Systems Engineering (ETAS/ESY1) Tel. +49 711 3423-2380 | Mobil +49 173 9792 632 | Albrecht.Schwarz@etas.com= --_000_e06e6a9189eb4174a6777da720d31294etascom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear BFD experts,

just a simple question: which BFD RFC would be applic= able for applying BFD over an Ethernet link (no VLAN, no LAG)?

Direct over Ethernet, without IP.

 

Thanks,

Albrecht

 

Mi= t freundlichen Gr=FC=DFen / Best regards

Dr. Albrecht Schwarz

Systems Engineering (ETAS/ESY1)
Tel. +49 711 3423-2380 | M= obil +49 173 9792 632 | Alb= recht.Schwarz@etas.com


--_000_e06e6a9189eb4174a6777da720d31294etascom_-- From nobody Fri Jun 7 04:13:25 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14621120228 for ; Fri, 7 Jun 2019 04:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=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=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.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 GvdzAAghExEm for ; Fri, 7 Jun 2019 04:13:22 -0700 (PDT) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.115]) (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 93BEC1201E7 for ; Fri, 7 Jun 2019 04:13:18 -0700 (PDT) Received: from [85.158.142.193] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-4.bemta.az-b.eu-central-1.aws.symcld.net id AD/16-22257-CC64AFC5; Fri, 07 Jun 2019 11:13:16 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBJsWRWlGSWpSXmKPExsViIr2lQve0268 Yg7YlOhbL7nlYfP6zjdGByWPytANMHkuW/GQKYIpizcxLyq9IYM34t6WFreCFasWFjn+sDYx/ FLoYuThYBNYyS+xbfJwdxBES6GeSmLHuFRuEc49RYnbvFuYuRk4ONgFbiU2r77KB2CICdhKHO /4xdTFycDALaErMm8sJEhYWUJM49/4kK0SJusSThudgJSICRhKNzw1AwiwCKhIXj7SwgNi8Ar ESb7e/AZsoJGAu0ffiGCOIzSlgIfH0xyywOKOAmMT3U2uYQGxmAXGJW0/mg9kSAgISS/acZ4a wRSVePv7HClGfJHH/6UJGiLiixP33V1ggbFmJS/O7oeK+Etfe/2IBOU1CQFliy4tYkG8lBB4z Sizp+ARVoyUx9c5EZoiaHImFE4UgwmoSU9Z/glorI7H59XpGiN4pbBJvJ8D8kixxYs5nqL1yE qt6H0LZF5gldh0wh/glT+LP1FMsExi1ZiF5bRaS1CxwEAlKnJz5hAUiridxY+oUNghbW2LZwt fMELauxIx/h1iQxRcwsq9itEgqykzPKMlNzMzRNTQw0DU0NNY10bUw1Eus0k3SSy3VTU7NKyl KBErqJZYX6xVX5ibnpOjlpZZsYgQmrJRClsAdjE+OvNY7xCjJwaQkylvC/ytGiC8pP6UyI7E4 I76oNCe1+BCjDAeHkgSvhytQTrAoNT21Ii0zB5g8YdISHDxKIrzMIGne4oLE3OLMdIjUKUZLj gkv5y5i5vi4agmQ/A4ihVjy8vNSpcR5c0EaBEAaMkrz4MbBEvwlRlkpYV5GBgYGIZ6C1KLczB JU+VeM4hyMSsK8/12ApvBk5pXAbX0FdBAT0EH8F76BHFSSiJCSamBqPiDm+73iHXdKcpLl1TO Cs+RcmpRS7/vbczAFfRRz1Zn+u+PIJq33hz+lWFsf32M65djdrju5BbLZzTPyTU/yybYvkzoR spCH71BA8v7Wxx01PxvYXW8vetbp+6X1KL+k74GadQfb824bWd86u+3C5TmGWeJ3219P43T2u OWzc4P9jn18IlYPWPfPbb+05Kj2s6mxh9XzangXBTQsfaQz99/O1sdfXfg+NAtPcQxRzvXamb r/248FXbdyMlMsrdZ/elsY0VP/9e3mWNWHfv475k0JZpbP32St/jA64UDt4bWTIwQ7RfYcOc0 9b4LnfK7HBoKzRM/ynJnDaPkxyeGXTId8+48O+6395fvOLdVUYinOSDTUYi4qTgQAy54XzWsE AAA= X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-26.tower-238.messagelabs.com!1559905991!6520041!1 X-Originating-IP: [52.27.180.120] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.31.5; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 1194 invoked from network); 7 Jun 2019 11:13:14 -0000 Received: from us-west-2c.mta.dlp.protect.symantec.com (HELO EUR01-HE1-obe.outbound.protection.outlook.com) (52.27.180.120) by server-26.tower-238.messagelabs.com with AES256-SHA256 encrypted SMTP; 7 Jun 2019 11:13:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ECI365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t7tuhtkpCuBuuEoOq83DcCjtsJovm4VvLBYKwKcSp9Q=; b=f3uZd+aOvrQyecNwCAwrHGnPCwNov7YBNvGUcpseYzypfLM+aAs5Vp+VkR4fkCmub4UWJrK3u78gt0LR2wtFN9alfJu22nfFFq8oWs3nxfBn6idjHWn75XOlGtdmd2XzieTxF0dLhzKH+NZ0iRk5qFOfU9JTwwjUZ772YN8h3J8= Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.159) by AM0PR03MB4578.eurprd03.prod.outlook.com (20.177.40.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.12; Fri, 7 Jun 2019 11:13:10 +0000 Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::91f3:6bd1:1631:9b4a]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::91f3:6bd1:1631:9b4a%6]) with mapi id 15.20.1943.023; Fri, 7 Jun 2019 11:13:10 +0000 From: Alexander Vainshtein To: "Schwarz Albrecht (ETAS/ESY1)" CC: "Rtg-bfd@ietf.org" Subject: Re: Direct BFD over Ethernet? Thread-Topic: Direct BFD over Ethernet? Thread-Index: AdUdHwIY3QLc2dE1SwCr012LbinkaAAAvtBv Date: Fri, 7 Jun 2019 11:13:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [40.67.249.249] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e1e33c51-6fd8-48a6-ab33-08d6eb392038 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM0PR03MB4578; x-ms-traffictypediagnostic: AM0PR03MB4578: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0061C35778 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(136003)(346002)(376002)(39850400004)(189003)(199004)(5660300002)(4744005)(8936002)(229853002)(81156014)(26005)(6916009)(52536014)(68736007)(71190400001)(71200400001)(8676002)(3480700005)(53546011)(6506007)(186003)(76176011)(74316002)(316002)(2906002)(81166006)(7696005)(66066001)(99286004)(6116002)(7736002)(3846002)(256004)(66946007)(446003)(11346002)(102836004)(72206003)(25786009)(6436002)(6246003)(4326008)(236005)(9686003)(33656002)(66556008)(66476007)(64756008)(54896002)(55016002)(73956011)(66446008)(86362001)(76116006)(53936002)(14454004)(486006)(91956017)(478600001)(476003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB4578; H:AM0PR03MB3828.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: sz/xj1J+aNb5lTsssSFyEnXuRw1gzHxROQIuZfnzqqAkpFSBlu3KDuzmjy+rALCREvew8swRZn4J+msWKmBb4wruMd7m5drK7K2O4Yi09hIE/3q5Bwf+Pba0n2EtVEd/OM+3ADefWcL47kE83XO6AIYZ62EiCZC8za5zxyzCcca1BV3+oDA0RgwnTXgg/8+xDW+CGxc4qShYT/Bxc0mD/O7gpFaOhJPy3H0cgZCSTPzUGJMJ4eopmKqXkaww2algjMNH52pTM+BBcQLGmkOX5QVkuqhWua0q4W6nVaKo9p+kHWtBx1XzahB7RJKLFRRbeMeZf7nkAu1EyVj53rYMueDld1cRAoDOskVzPR8Ko3xBKkL53T/8SIyXaRdNPNhwo6wrrbNc1Xev9f3V7ao/1dhDMhrnuUIZU2AC+O588PU= Content-Type: multipart/alternative; boundary="_000_AM0PR03MB3828C11241B4118A96BAFB7A9D100AM0PR03MB3828eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: e1e33c51-6fd8-48a6-ab33-08d6eb392038 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2019 11:13:10.4242 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: alexvain@ecitele.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB4578 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 11:13:23 -0000 --_000_AM0PR03MB3828C11241B4118A96BAFB7A9D100AM0PR03MB3828eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Albrecht, AFAIK there is no such thing. IMHO and FWIW IEEE802.1ag is the closest thing to what you are probably lo= oking for, but it is quite different from BFD. Thumb typed by Sasha Vainshtein From: Schwarz Albrecht (ETAS/ESY1) Sent: Friday, June 7, 13:52 Subject: Direct BFD over Ethernet? To: rtg-bfd@ietf.org Dear BFD experts, just a simple question: which BFD RFC would be applicable for applying BFD= over an Ethernet link (no VLAN, no LAG)? Direct over Ethernet, without IP. Thanks, Albrecht Mit freundlichen Gr=FC=DFen / Best regards Dr. Albrecht Schwarz Systems Engineering (ETAS/ESY1) Tel. +49 711 3423-2380 | Mobil +49 173 9792 632 | Albrecht.Schwarz@etas.co= m __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_AM0PR03MB3828C11241B4118A96BAFB7A9D100AM0PR03MB3828eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Albrecht,
AFAIK there is no such thing.

IMHO and FWIW IEEE802.1ag is the closest thing to what you are probably lo= oking for, but it is quite different from BFD.

Thumb typed by Sasha Vainshtein



From: Schwarz Albrecht (ETAS/ESY1)
Sent: Friday, June 7, 13:52
Subject: Direct BFD over Ethernet?
To: rtg-bfd@ietf.org


Dear BFD experts,
just a simple question: which BFD RFC would be applicable for applying BFD= over an Ethernet link (no VLAN, no LAG)?
Direct over Ethernet, without IP.
 
Thanks,
Albrecht
 
Mit freundlichen Gr=FC=DFen / Best regards

Dr. Albrecht Schwarz

Systems Engineering (ETAS/ESY1)
Tel. +49 711 3423-2380 | Mobil +49 173 9792 632 | Albrecht.Schwarz@etas.com





__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_AM0PR03MB3828C11241B4118A96BAFB7A9D100AM0PR03MB3828eurp_-- From nobody Fri Jun 7 04:20:33 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 359D11200FB for ; Fri, 7 Jun 2019 04:20:32 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 bkEVVs43SZDB for ; Fri, 7 Jun 2019 04:20:30 -0700 (PDT) Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450: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 A1269120045 for ; Fri, 7 Jun 2019 04:20:30 -0700 (PDT) Received: by mail-wm1-x333.google.com with SMTP id v19so1535448wmj.5 for ; Fri, 07 Jun 2019 04:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=EFWA5s+ocAGsIy9Y+LU6oCiGNLYtWR5SVWC2f4PoKXE=; b=YG907I3ZIDxX533LFFBlot8EXUarjfgDc5/ZjVOqLv0N3iychSuwK87fuGszvNffAe mKqDU5SpZQ1B4eEf5c0AZDeHmwwlrxyLL184RF8PCueYyvvnB/c3PY/VobdD6lbGGN1F AJdoTDtx9Xr7w2/CbiLDLRkLpVtWNiG8K4mZZPKwD+PZR2bjCHv5R4Xe7LBAV1ypK/aN q0+MG3W5Ulyd2zHV50gkj0LGGHK18A1L5hcTNvct0rVC+CXztJTpiq62nfTmRjq4UTKA VL919Bpu17Uotp25io7ygFBfZUKhAkSEPZ50i/xdbBOnZMKA+p84mhQZtI1XXw/Omh7R aORg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=EFWA5s+ocAGsIy9Y+LU6oCiGNLYtWR5SVWC2f4PoKXE=; b=NiE4/fF4sHZXVvxQxliH00QqXH47K9QCxYvo5XlJ3liF5hm2TnG6js+vnawMbHHc7x yFMqWRJ+bi21h3YL3OEuEOrLJ/G9QLm+Vgg5Z8n/LW3GfkdCdc8bR/vBojLFii0mBc6G PqWmw23HD+1cpUNtOp43TECJ+WQVAFZiG/oOoY8AJ8zgq4nYQYpT5VKg/CTPEmxJAlZ/ xiIpGbYlp/KijB+bV69HaBIVb8kPhh2J3qzWd6e4AYASUN/0/TKBHeYl8sU+ePt45s91 tePERv1SIqvBsq4BojqzVX1LkipvCvT3OCQJ9ck8nI2TJg8bwmi/B0tePuYpQDbsJuz2 jvJA== X-Gm-Message-State: APjAAAWxepaNUD6syR9Fg5/cyIjGF1GTwRalikl++D9MWoSBxgeQqFr1 xAGV71SR2apUZj1PFe4yffhjW71n X-Google-Smtp-Source: APXvYqzQ5jAQV1pHGb0CabAgsADllIQiz4/72PFFHrtgqY90nF6oqhvQ7xlbTLah3lo4aBYDVAkWPA== X-Received: by 2002:a1c:7ec3:: with SMTP id z186mr3534849wmc.76.1559906428952; Fri, 07 Jun 2019 04:20:28 -0700 (PDT) Received: from [192.168.178.22] ([62.3.64.16]) by smtp.gmail.com with ESMTPSA id q15sm1042068wrr.19.2019.06.07.04.20.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Jun 2019 04:20:28 -0700 (PDT) Subject: Re: Direct BFD over Ethernet? To: Alexander Vainshtein , "Schwarz Albrecht (ETAS/ESY1)" Cc: "Rtg-bfd@ietf.org" References: From: Stewart Bryant Message-ID: Date: Fri, 7 Jun 2019 12:20:30 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 11:20:32 -0000 +1 However if you really want BFD, you only need a lightweight IP implementation to carry it. Stewart On 07/06/2019 12:13, Alexander Vainshtein wrote: > Albrecht, > AFAIK there is no such thing. > > IMHO and FWIW IEEE802.1ag is the closest thing to what you are probably > looking for, but it is quite different from BFD. > > Thumb typed by Sasha Vainshtein > > > > From: Schwarz Albrecht (ETAS/ESY1) > Sent: Friday, June 7, 13:52 > Subject: Direct BFD over Ethernet? > To: rtg-bfd@ietf.org > > > Dear BFD experts, > just a simple question: which BFD RFC would be applicable for applying > BFD over an Ethernet link (no VLAN, no LAG)? > Direct over Ethernet, without IP. > > Thanks, > Albrecht > > Mit freundlichen Grüßen / Best regards > > *Dr. Albrecht Schwarz* > > Systems Engineering (ETAS/ESY1) > Tel. +49 711 3423-2380 | Mobil +49 173 9792 632 | > Albrecht.Schwarz@etas.com > > > > > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and > then delete the original > and all copies thereof. > ___________________________________________________________________________ From nobody Fri Jun 7 04:55:26 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4EE120086 for ; Fri, 7 Jun 2019 04:55:24 -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, SPF_PASS=-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 WezPU3muNcSH for ; Fri, 7 Jun 2019 04:55:23 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 2B537120158 for ; Fri, 7 Jun 2019 04:55:22 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 666671E2F1; Fri, 7 Jun 2019 07:56:18 -0400 (EDT) Date: Fri, 7 Jun 2019 07:56:17 -0400 From: Jeffrey Haas To: Stewart Bryant Cc: Alexander Vainshtein , "Schwarz Albrecht (ETAS/ESY1)" , "Rtg-bfd@ietf.org" Subject: Re: Direct BFD over Ethernet? Message-ID: <20190607115617.GC15506@pfrc.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 11:55:25 -0000 On Fri, Jun 07, 2019 at 12:20:30PM +0100, Stewart Bryant wrote: > > +1 > > However if you really want BFD, you only need a lightweight IP > implementation to carry it. During the work for BFD for LAG, IETF already went a bit too close to stepping into IEEE territory. Raw BFD over Ethernet would not be received very well by that organization, I think. (Even if it'd be trivial to specify.) -- Jeff From nobody Sat Jun 8 01:47:24 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F2A12002E for ; Sat, 8 Jun 2019 01:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 Avfvy6meUiwN for ; Sat, 8 Jun 2019 01:47:18 -0700 (PDT) Received: from de-out1.bosch-org.com (de-out1.bosch-org.com [139.15.230.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3853F1200EA for ; Sat, 8 Jun 2019 01:47:14 -0700 (PDT) Received: from fe0vm1650.rbesz01.com (unknown [139.15.230.188]) by fe0vms0186.rbdmz01.com (Postfix) with ESMTPS id 45LY195KLvz1XLFjK; Sat, 8 Jun 2019 10:47:08 +0200 (CEST) Received: from fe0vm7918.rbesz01.com (unknown [10.58.172.176]) by fe0vm1650.rbesz01.com (Postfix) with ESMTPS id 45LY184LxQz1CL; Sat, 8 Jun 2019 10:47:08 +0200 (CEST) X-AuditID: 0a3aad10-03fff70000007f88-9b-5cfb760c534a Received: from si0vm1950.rbesz01.com ( [10.58.173.29]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by fe0vm7918.rbesz01.com (SMG Outbound) with SMTP id D7.B4.32648.C067BFC5; Sat, 8 Jun 2019 10:47:08 +0200 (CEST) Received: from SI-MBX2055.de.bosch.com (unknown [10.3.230.149]) by si0vm1950.rbesz01.com (Postfix) with ESMTPS id 45LY1827sKz5ff; Sat, 8 Jun 2019 10:47:08 +0200 (CEST) Received: from SI-MBX2054.de.bosch.com (10.3.230.148) by SI-MBX2055.de.bosch.com (10.3.230.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Sat, 8 Jun 2019 10:47:08 +0200 Received: from SI-MBX2054.de.bosch.com ([fe80::187:74e0:f8c8:c9b1]) by SI-MBX2054.de.bosch.com ([fe80::187:74e0:f8c8:c9b1%4]) with mapi id 15.01.1713.006; Sat, 8 Jun 2019 10:47:07 +0200 From: "Schwarz Albrecht (ETAS/ESY1)" To: Jeffrey Haas , Stewart Bryant CC: Alexander Vainshtein , "Rtg-bfd@ietf.org" Subject: RE: Direct BFD over Ethernet? Thread-Topic: Direct BFD over Ethernet? Thread-Index: AdUdHwIY3QLc2dE1SwCr012LbinkaAAAvtBv///ghQCAAAoAgP/+hUYw Date: Sat, 8 Jun 2019 08:47:07 +0000 Message-ID: <7a42f74e46484476a8b642a29649a471@etas.com> References: <20190607115617.GC15506@pfrc.org> In-Reply-To: <20190607115617.GC15506@pfrc.org> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.225.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA21TbUwbdRzm37uWo/TkOOj6o4DRyiBhE8E3ilvqPhiDxkS/6AfSbF7loNXS kl4hQHwBTZa6SER0AWrsxniJLnthKEwGWFvWTF6mhDJ1OBwIy4BKA0My3qTecbD2g1/+ee55 /s/ze/nnCIz+kVATJoudtVkYs0Ymx+XPnU99XFG+qc9u2QDtya4lTOv2LEq1K1vdSDs0xRzB 8zu3r6H8HudkdH5r67ok31/bJX0NL5AfLmTNpnLW9oTuTbnx7uBUdKlPXjG/6MOq0QRxAsUQ QD0NXw+NoxNITtBUowQcf6zKxI9zCBo//lIi3KKpIILawH5R6EfQf31FJggy6ggM/voRjwki kXoFBgc5gcaoQhjbXN25kkClw9jInFTAiVQGzFbflYj4Rfi3pm0H41QaNLiXcQGTVC7ca57F xVrTCBZGa5AgxFBZMH6neicIUanQ0fELJhZTwcTsKYk4DgWtfSIPlBLmZ7alIn4UPmu5IRXv H4TTvfdkIj4A7c0BTCwcD4NNs3gdUjkjYp0RFmeExRlhOY3ws0hZxGaXl+Tm5WizbAaWq8rO yXrLWtKJxAekvkc9Q0VeRBFIoyAbjm3qaSlTzlWWeNEzhESjJO1xG3r6IYO1sNLIcMZjtjIz y2nUZMroy3o64QHNlRlKTBxnslq8CAhMk0iWj67pabKQqaxibVbR5kXJBK5RkcXEq3qaKmbs 7DssW8ra9tRDBKEB0mfne4i3scVsRZHJbN+TNakkioqKovdFKpFlJUSMFz1FKPja7RwfQXKl TAlnKt61J4l2eo8NW4fQ60Td/FdnMMLjc/Gn/zfhDK63nMFo3GK1sGoVOSUkUoLXWGZ50JM6 hXy74b6eVkYI4dwFdBPxW00gG4SJFPyfE+4GyGRhgfG7ZNj0ZBvvocZl0Hl7GIPt+mYZNE73 RMO56eOxcDHkiAWXqzcW5kZ+UkB9yK+Aq/4LJGw0nYyD7u/G4uD39s+VcGUztA/+7HCowN35 M0Dw5qVUcF8eeARWnQ1p4NieSoPxzftp4K71pENoZisdXH1XMuAL11YGOG6tZULjUv8BcPy1 nsXHT+TBRH2fDgLL558H79ngCxD0/JO/wK9awq/6om9DWLWdsf/PqnfZ8HTqalR3fTLvVm9g ZjJXt6HWXrgxPCx9w/+YteJ46FnVu0mXWM3U7R9GA2u04WDB30meD0cWP5DIj37adLjXHdQe PdVSHQi9N9ddcMh6R5KSXNWmy0ybyLXItLrSrRrX0tXQwLr5JWL7Yfza8jcGL1PqKfykqUu2 X2647FlJHkjkvvW/r8E5I5OTidk45j9VV0W10wQAAA== Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2019 08:47:23 -0000 Thanks Sasha, Jeff & Stewart for your reply! OK, understood, more a technology ownership question (IEEE 802 vs IETF) tha= n a technical issue. Running BFD directly over Ethernet would (at least) require to assign an Et= hertype codepoint (https://www.iana.org/assignments/ieee-802-numbers/ieee-8= 02-numbers.xml ) for BFD. But BFD-over-Ethernet seems to be then in direct competition with the IEEE = 802.1ag defined OAM capabilities (guess the Connectivity Fault Management p= rotocols), i.e., the IEEE Continuity Check protocol. My rough understanding. Thanks again! Albrecht -----Original Message----- From: Jeffrey Haas =20 Sent: 07 June 2019 13:56 To: Stewart Bryant Cc: Alexander Vainshtein ; Schwarz Albrec= ht (ETAS/ESY1) ; Rtg-bfd@ietf.org Subject: Re: Direct BFD over Ethernet? On Fri, Jun 07, 2019 at 12:20:30PM +0100, Stewart Bryant wrote: >=20 > +1 >=20 > However if you really want BFD, you only need a lightweight IP=20 > implementation to carry it. During the work for BFD for LAG, IETF already went a bit too close to stepp= ing into IEEE territory. Raw BFD over Ethernet would not be received very = well by that organization, I think. (Even if it'd be trivial to specify.) -- Jeff From nobody Sat Jun 8 02:04:46 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90EAB120094 for ; Sat, 8 Jun 2019 02:04: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_HELO_NONE=0.001, 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 jpEXeY-gfNDq for ; Sat, 8 Jun 2019 02:04:42 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 F381612004D for ; Sat, 8 Jun 2019 02:04:41 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id c2so4360472wrm.8 for ; Sat, 08 Jun 2019 02:04:41 -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=YFBYB1WkPPHRXHyky0SsE0NhqW2YGdQBrYshvrPu9Bg=; b=czbF/iis0xtJl2HHbk04mOittzjvHwV+mwAtos1LJTfwXJZh5ccMv/nGaMyFxaxisx dq3oPjTGkCs2ZInjsRlYbkABn+C5K83yim3AJ5IbgoKaect8PVtXat3slSvWhhEeZQx+ OX5ku4hACi+5ogoZPgaD11j5Q45ntC6uQOMerSocBRy+D9K4sN1YBBJ32xtzLHmk79N2 1tLbutniSpFTz2dY4CV0b+NewTqRXnvBeAfypKS26r+OVncwR9aOQEhRTPrjybT4N0d1 GndQQWqHvTumRNNsAyRykCFFqDWVyqX0zbjandDYfL9x7ni6NSfpBtbo9pNA75uDwD3I JYeg== 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=YFBYB1WkPPHRXHyky0SsE0NhqW2YGdQBrYshvrPu9Bg=; b=fd37DQN7vo7ylCacAkyHfyLyTGBj169BI4acQea5LvaP8AwvQwX58axqSA55IfL/3n vMMVSsNyi3/fhO4+E30sNwgjNkBo5W+cPBGxR5GT+J3NukmHo0qNe3DBzc4HAPPMRuRp AziTOWzaX5g1qE6eCOWtx7G04JI5ZOeOA4a75/8m4/p/B4/jjMtB9l29xXptFI+PjiHn usg5cnBvRJ9tAzps3rW19v+CPcV33EnMTUj0eahnEdNJYLFz0xDRtFGiSIeSEhNqJ0vI aHlJkXgozqXTZP/SMwi3M5+s+baxnjD//Oww56seWVru4kmxvTPkuUxty9ROVCM+mNpV HM0A== X-Gm-Message-State: APjAAAUXrEtDcSOmxCRo7vD+9zuB7l1hGFweVuns+kWniM9oVWipdwVt ouoprkSMzWK6CSeau2XrVb7uLYW1gt1u4MPO210= X-Google-Smtp-Source: APXvYqxPuXRVc1EFv1z6Eq8I4wIT0UaVPaamx6EzhXuAoBjCN9ar2edtQdNs6w9Er56MZy+mXEYVxc0qMA/xlNemBNc= X-Received: by 2002:adf:f3cc:: with SMTP id g12mr34887949wrp.149.1559984680530; Sat, 08 Jun 2019 02:04:40 -0700 (PDT) MIME-Version: 1.0 References: <20190607115617.GC15506@pfrc.org> <7a42f74e46484476a8b642a29649a471@etas.com> In-Reply-To: <7a42f74e46484476a8b642a29649a471@etas.com> From: Santosh P K Date: Sat, 8 Jun 2019 14:34:29 +0530 Message-ID: Subject: Re: Direct BFD over Ethernet? To: "Schwarz Albrecht (ETAS/ESY1)" Cc: Jeffrey Haas , Stewart Bryant , "Rtg-bfd@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bcf7a7058acc3c3a" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2019 09:04:45 -0000 --000000000000bcf7a7058acc3c3a Content-Type: text/plain; charset="UTF-8" Schwarz, Just curious to know why do you have this use case? I mean why not use CFM itself? Thanks Santosh P K On Sat, Jun 8, 2019 at 2:17 PM Schwarz Albrecht (ETAS/ESY1) < Albrecht.Schwarz@etas.com> wrote: > Thanks Sasha, Jeff & Stewart for your reply! > > OK, understood, more a technology ownership question (IEEE 802 vs IETF) > than a technical issue. > Running BFD directly over Ethernet would (at least) require to assign an > Ethertype codepoint ( > https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xml ) > for BFD. > > But BFD-over-Ethernet seems to be then in direct competition with the IEEE > 802.1ag defined OAM capabilities (guess the Connectivity Fault Management > protocols), i.e., the IEEE Continuity Check protocol. > My rough understanding. > > Thanks again! > Albrecht > > -----Original Message----- > From: Jeffrey Haas > Sent: 07 June 2019 13:56 > To: Stewart Bryant > Cc: Alexander Vainshtein ; Schwarz > Albrecht (ETAS/ESY1) ; Rtg-bfd@ietf.org > Subject: Re: Direct BFD over Ethernet? > > On Fri, Jun 07, 2019 at 12:20:30PM +0100, Stewart Bryant wrote: > > > > +1 > > > > However if you really want BFD, you only need a lightweight IP > > implementation to carry it. > > During the work for BFD for LAG, IETF already went a bit too close to > stepping into IEEE territory. Raw BFD over Ethernet would not be received > very well by that organization, I think. (Even if it'd be trivial to > specify.) > > -- Jeff > > --000000000000bcf7a7058acc3c3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Schwarz,
=C2=A0 =C2=A0 Just curious to know why do you= have this use case? I mean why not use CFM itself?=C2=A0

Thanks
Santosh P K=C2=A0

On Sat, Jun 8, 2019 at 2:17= PM Schwarz Albrecht (ETAS/ESY1) <Albrecht.Schwarz@etas.com> wrote:
Thanks Sasha, Jeff & Stewart for your = reply!

OK, understood, more a technology ownership question (IEEE 802 vs IETF) tha= n a technical issue.
Running BFD directly over Ethernet would (at least) require to assign an Et= hertype codepoint (https://www= .iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xml ) for BFD.<= br>
But BFD-over-Ethernet seems to be then in direct competition with the IEEE = 802.1ag defined OAM capabilities (guess the Connectivity Fault Management p= rotocols), i.e., the IEEE Continuity Check protocol.
My rough understanding.

Thanks again!
Albrecht

-----Original Message-----
From: Jeffrey Haas <= jhaas@pfrc.org>
Sent: 07 June 2019 13:56
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>; Schwarz A= lbrecht (ETAS/ESY1) <Albrecht.Schwarz@etas.com>; Rtg-bfd@ietf.org
Subject: Re: Direct BFD over Ethernet?

On Fri, Jun 07, 2019 at 12:20:30PM +0100, Stewart Bryant wrote:
>
> +1
>
> However if you really want BFD, you only need a lightweight IP
> implementation to carry it.

During the work for BFD for LAG, IETF already went a bit too close to stepp= ing into IEEE territory.=C2=A0 Raw BFD over Ethernet would not be received = very well by that organization, I think.=C2=A0 (Even if it'd be trivial= to
specify.)

-- Jeff

--000000000000bcf7a7058acc3c3a-- From nobody Sat Jun 8 05:46:06 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2C8120091 for ; Sat, 8 Jun 2019 05:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=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=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.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 KSrnM17Oxp_B for ; Sat, 8 Jun 2019 05:46:01 -0700 (PDT) Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.4]) (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 93C5E120019 for ; Sat, 8 Jun 2019 05:46:00 -0700 (PDT) Received: from [46.226.52.101] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-4.bemta.az-a.eu-west-1.aws.symcld.net id E5/FE-22125-50EABFC5; Sat, 08 Jun 2019 12:45:57 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJsWRWlGSWpSXmKPExsViougQq8u67ne Mwfq3rBbL7nlY7D8IZHz+s43R4tSDRAcWj8nTDjB57Jx1l91jyZKfTB6Xe7eyBrBEsWbmJeVX JLBm/F/uXnDXvKL/1ifWBsZT+l2MXBwsAmuZJZ7eX88O4ggJTGCSaNm+jgnCucco0XroGHMXI ycHm4CtxKbVd9lAbBEBO4nDHf+Aijg4mAVKJCa8CQUJCwuoSZx7f5IVokRd4knDcyYI20/izb rlYK0sAioSp668ZwGxeQViJQ5snscGsauLSaLj6GRGkASngIVE87l2sAZGATGJ76fWgA1iFhC XuPVkPpgtISAgsWTPeWYIW1Ti5eN/rBD1SRL3ny5khIgrSZxp7oeql5W4NL8bKu4r0f3hPTvI /RICyhJbXsSC3CAh8JhR4t3nVewQNVoS3zpOQ9k5EqtOzYOy1SRuvOmA2isjcW7vaUaI5lVsE msaL4EdLSSQLHFizmcWiCI5iVW9D1kgii4wS9z9AdHNLJAnsfT7E/YJjFqzkDw3C0lqFjiUBC VOznzCAhHXkViw+xMbhK0tsWzha2YY+8yBx0zI4gsY2VcxmicVZaZnlOQmZuboGhoY6BoaGuk aWhrrmpvqJVbpJuqlluqWpxaX6BrqJZYX6xVX5ibnpOjlpZZsYgSmtpSCg947GE8feK13iFGS g0lJlLeE/1eMEF9SfkplRmJxRnxRaU5q8SFGGQ4OJQneV2t+xwgJFqWmp1akZeYA0yxMWoKDR 0mEtxckzVtckJhbnJkOkTrF6Mox4eXcRcwcl6/PA5Lvfi4Gkh9XLQGS30GkEEtefl6qlDgv51 qgZgGQ5ozSPLjRsBxxiVFWSpiXkYGBQYinILUoN7MEVf4VozgHo5Iw7z+QE3gy80rgLngFdBw T0HHrj/4COa4kESEl1cA0kyHNyXjGRPWeW7HeGZul9u60eDWF32S/+J6VGoWb5uwR+PKC0WvW FOuax9kPy+USJh4OtnzT2Os47/a+0MrQVuUb94wv217mZTzNlWq/MDFqYVtbTkr+x1Ubjqi2t IkU/3ryr0+4Ib3l2FkN+zO7mt9vLFE48P+a9a17q3y8nu6xbrJeXlh2cPI/NpfohB9GTI0Wuw 8ePLz8dEiz3Orbhzo7eV+e31o9t/twY820sP1SXgWmzF95fL9OeXTwYuKDRl/HFZPO/G6MiF9 h8jI66FNDUdqvFsGnJgYpDRzKTEfktTMDTS7k7Hx6QTnE5aEbc9w/6/A++dW7Hs+4GfVn0QX7 5c4hJbNWaNt3cU9VYinOSDTUYi4qTgQAJK1KC4wEAAA= X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-20.tower-265.messagelabs.com!1559997953!279725!1 X-Originating-IP: [52.33.64.93] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.43.9; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 24995 invoked from network); 8 Jun 2019 12:45:56 -0000 Received: from us-west-2b.mta.dlp.protect.symantec.com (HELO EUR01-VE1-obe.outbound.protection.outlook.com) (52.33.64.93) by server-20.tower-265.messagelabs.com with ECDHE-RSA-AES256-SHA384 encrypted SMTP; 8 Jun 2019 12:45:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ECI365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MIYorKrZeWt0kUpfoyPXt5cCTZVeR+zUERF0/7z/JEM=; b=G1AVn1lY9Mr1dhsJLYUkpDTqReYJ4pUr3wENLT2NfCNQ6tF9f9FwnegM7F2IWSlk1VznIBeQ+lG6VHqOoZ8jliR7LF4um2Lrvji00yxbKd5HKNOOvi7dU6WoL8bi4f6gqxN+mw4SBi/8bOQvGk+FjbdvLcHcESRnsOSF5i9M0c0= Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.159) by AM0PR03MB3844.eurprd03.prod.outlook.com (52.135.146.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.15; Sat, 8 Jun 2019 12:45:51 +0000 Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::91f3:6bd1:1631:9b4a]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::91f3:6bd1:1631:9b4a%6]) with mapi id 15.20.1965.017; Sat, 8 Jun 2019 12:45:51 +0000 From: Alexander Vainshtein To: "Schwarz Albrecht (ETAS/ESY1)" CC: "rtg-bfd@ietf.org" , Stewart Bryant , Jeffrey Haas Subject: Re: Direct BFD over Ethernet? Thread-Topic: Direct BFD over Ethernet? Thread-Index: AdUdHwIY3QLc2dE1SwCr012LbinkaAAAvtBvAABBlQAAAT/tgAArr1KAAAfpV5k= Date: Sat, 8 Jun 2019 12:45:50 +0000 Message-ID: References: <20190607115617.GC15506@pfrc.org>, <7a42f74e46484476a8b642a29649a471@etas.com> In-Reply-To: <7a42f74e46484476a8b642a29649a471@etas.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [52.142.119.221] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d255e346-7875-40e2-8b31-08d6ec0f3cfe x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM0PR03MB3844; x-ms-traffictypediagnostic: AM0PR03MB3844: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0062BDD52C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(136003)(366004)(396003)(346002)(376002)(199004)(189003)(13464003)(76116006)(6436002)(91956017)(26005)(53936002)(6116002)(3846002)(66556008)(478600001)(64756008)(5660300002)(4326008)(7696005)(8676002)(316002)(6306002)(54896002)(66446008)(256004)(66066001)(54906003)(25786009)(72206003)(9686003)(14444005)(66946007)(68736007)(74316002)(73956011)(66476007)(229853002)(76176011)(14454004)(6246003)(102836004)(99286004)(7736002)(86362001)(55016002)(186003)(446003)(6916009)(11346002)(476003)(486006)(3480700005)(2906002)(6506007)(71190400001)(71200400001)(81156014)(53546011)(33656002)(81166006)(8936002)(52536014); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB3844; H:AM0PR03MB3828.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 7STjR5JkG0Ht+ZKNBWDboiqBRBDIDfUYKOjVwPoFmksR4tqilLf3uVfqj7MWaTdhJ5vvs0dqxHL83o4IxkzfBWKN3hM2CdSkHUxfTkHVWcxEN1U2Jlm2DRbQnhC90fe8qR9l6UTqavn+yjCQKmgsGOSP/goXotLXYP7kfctHfGEz2mYdGxWAsJVCS9HJjhIiiyecf4jl13W3VIFqw2NvjyjZRfps6e60pIIA8mNzcsE4VECiHfEuZOljwcTM095xNl9n8lu4//sDkx3ZkTztfbWI3CLsPjyNAWIpvE5zE2utPWVpv6c0VnXE94ktejCbD4qft2mVM/gLEdpLaSCPP2aDRfCkYpbUVb4dBL2Ty31qOY7/dOfAWOpQ+GxoTXo+9iHTxmBvq3M19X70wdnxlE8PfQh2CE47JQwzrKDC5e8= Content-Type: multipart/alternative; boundary="_000_AM0PR03MB3828A71E881294059A5BB8829D110AM0PR03MB3828eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: d255e346-7875-40e2-8b31-08d6ec0f3cfe X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jun 2019 12:45:50.9674 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: alexvain@ecitele.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB3844 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2019 12:46:04 -0000 --_000_AM0PR03MB3828A71E881294059A5BB8829D110AM0PR03MB3828eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Albrecht, I guess you are right and it is indeed mainly the technology ownership iss= ue. To the best of my recollection the BFD WG hss tried to cooperate with IEEE= 802.1, but these attempts have failed. At the same time I think there is a difference in the overall attitude wit= h regard to OAM between IETF and IEEE 802.1. The former seems to consider OAM sessions (and, specifically, BFD) as "hel= pers" for some other protocols (e.g., routing): these sessions are usually= set up when the "client protocol" peers establish a peering relationship,= and failure of the OAM session is an indication of failure of the peering= relationship of the client protocol (see RFC 5882 for details). The latter seems to treat OAM mainly as providing indications (alarms) to = the operator. My 2c. Thumb typed by Sasha Vainshtein From: Schwarz Albrecht (ETAS/ESY1) Sent: Saturday, June 8, 11:47 Subject: RE: Direct BFD over Ethernet? To: Jeffrey Haas, Stewart Bryant Cc: Alexander Vainshtein, rtg-bfd@ietf.org Thanks Sasha, Jeff & Stewart for your reply! OK, understood, more a techno= logy ownership question (IEEE 802 vs IETF) than a technical issue. Running= BFD directly over Ethernet would (at least) require to assign an Ethertyp= e codepoint (https://www.iana.org/assignments/ieee-802-numbers/ieee-802-nu= mbers.xml ) for BFD. But BFD-over-Ethernet seems to be then in direct comp= etition with the IEEE 802.1ag defined OAM capabilities (guess the Connecti= vity Fault Management protocols), i.e., the IEEE Continuity Check protocol= . My rough understanding. Thanks again! Albrecht -----Original Message----= - From: Jeffrey Haas Sent: 07 June 2019 13:56 To: Stewart Bryant Cc: Alexa= nder Vainshtein ; Schwarz Albrecht (ETAS/ESY1) ; Rtg-bfd@ietf.org Subject:= Re: Direct BFD over Ethernet? On Fri, Jun 07, 2019 at 12:20:30PM +0100, S= tewart Bryant wrote: > > +1 > > However if you really want BFD, you only n= eed a lightweight IP > implementation to carry it. During the work for BFD= for LAG, IETF already went a bit too close to stepping into IEEE territor= y. Raw BFD over Ethernet would not be received very well by that organizat= ion, I think. (Even if it'd be trivial to specify.) -- Jeff __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_AM0PR03MB3828A71E881294059A5BB8829D110AM0PR03MB3828eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Albrecht,
I guess you are right and it is indeed mainly the technology ownership iss= ue.

To the best of my recollection the BFD WG hss tried to cooperate with IEEE= 802.1, but these attempts have failed.

At the same time I think there is a difference in the overall attitude wit= h regard to OAM between IETF and IEEE 802.1.

The former seems to consider OAM sessions (and, specifically, BFD) as &quo= t;helpers" for some other protocols (e.g., routing): these sessions a= re usually set up when the "client protocol" peers establish a p= eering relationship, and failure of the OAM session is an indication of failure of the peering relationship of the client protoc= ol (see RFC 5882 for details). 

The latter seems to treat OAM mainly as providing indications (alarms) to = the operator.

My 2c.

Thumb typed by Sasha Vainshtein

From: Schwarz Albrecht (ETAS/ESY1)
Sent: Saturday, June 8, 11:47
Subject: RE: Direct BFD over Ethernet?
To: Jeffrey Haas, Stewart Bryant
Cc: Alexander Vainshtein, rtg-bfd@ietf.org


Thanks Sasha, Jeff & Stewart for your reply! OK, understood, more a te= chnology ownership question (IEEE 802 vs IETF) than a technical issue. Run= ning BFD directly over Ethernet would (at least) require to assign an Ethe= rtype codepoint (https://www.iana.org/assignments/ieee-802-numbers/ieee-80= 2-numbers.xml ) for BFD. But BFD-over-Ethernet seems to be then in direct competition w= ith the IEEE 802.1ag defined OAM capabilities (guess the Connectivity Faul= t Management protocols), i.e., the IEEE Continuity Check protocol. My roug= h understanding. Thanks again! Albrecht -----Original Message----- From: Jeffrey Haas Sent: 07 June 2019 13:56 To= : Stewart Bryant Cc: Alexander Vainshtein ; Schwarz Albrecht (ETAS/ESY1) ;= Rtg-bfd@ietf.org Subject: Re: Direct BFD over Ethernet? On Fri, Jun 07, 2= 019 at 12:20:30PM +0100, Stewart Bryant wrote: > > +1 > > However if you really want BFD, you onl= y need a lightweight IP > implementation to carry it. During the work f= or BFD for LAG, IETF already went a bit too close to stepping into IEEE te= rritory. Raw BFD over Ethernet would not be received very well by that organization, I think. (Even if it'd be trivial to specify.)= -- Jeff


__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_AM0PR03MB3828A71E881294059A5BB8829D110AM0PR03MB3828eurp_-- From nobody Tue Jun 11 00:04:54 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8751C1200C1 for ; Tue, 11 Jun 2019 00:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 tzNh5O_udDne for ; Tue, 11 Jun 2019 00:04:48 -0700 (PDT) Received: from de-out1.bosch-org.com (de-out1.bosch-org.com [139.15.230.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8F9120047 for ; Tue, 11 Jun 2019 00:04:48 -0700 (PDT) Received: from si0vm1948.rbesz01.com (unknown [139.15.230.188]) by si0vms0216.rbdmz01.com (Postfix) with ESMTPS id 45NLbd0zl5z1XLG79; Tue, 11 Jun 2019 09:04:45 +0200 (CEST) Received: from fe0vm02900.rbesz01.com (unknown [10.58.172.176]) by si0vm1948.rbesz01.com (Postfix) with ESMTPS id 45NLbd0ZQnz1Tt; Tue, 11 Jun 2019 09:04:45 +0200 (CEST) X-AuditID: 0a3aad0c-d19ff700000039d6-07-5cff528c2232 Received: from fe0vm1652.rbesz01.com ( [10.58.173.29]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by fe0vm02900.rbesz01.com (SMG Outbound) with SMTP id C6.53.14806.C825FFC5; Tue, 11 Jun 2019 09:04:44 +0200 (CEST) Received: from SI-MBX2054.de.bosch.com (unknown [10.3.230.148]) by fe0vm1652.rbesz01.com (Postfix) with ESMTPS id 45NLbc3nhNz5gT; Tue, 11 Jun 2019 09:04:44 +0200 (CEST) Received: from SI-MBX2054.de.bosch.com (10.3.230.148) by SI-MBX2054.de.bosch.com (10.3.230.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Tue, 11 Jun 2019 09:04:44 +0200 Received: from SI-MBX2054.de.bosch.com ([fe80::187:74e0:f8c8:c9b1]) by SI-MBX2054.de.bosch.com ([fe80::187:74e0:f8c8:c9b1%4]) with mapi id 15.01.1713.006; Tue, 11 Jun 2019 09:04:44 +0200 From: "Schwarz Albrecht (ETAS/ESY1)" To: Alexander Vainshtein , Santosh P K CC: "rtg-bfd@ietf.org" , Stewart Bryant , Jeffrey Haas Subject: RE: Direct BFD over Ethernet? Thread-Topic: Direct BFD over Ethernet? Thread-Index: AdUdHwIY3QLc2dE1SwCr012LbinkaAAAvtBv///ghQCAAAoAgP/+hUYwgAMa5gD/+4vSQA== Date: Tue, 11 Jun 2019 07:04:44 +0000 Message-ID: <8e213e313f2c4fcab9fa9481b8cbc7df@etas.com> References: <20190607115617.GC15506@pfrc.org>, <7a42f74e46484476a8b642a29649a471@etas.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.35.83.170] Content-Type: multipart/alternative; boundary="_000_8e213e313f2c4fcab9fa9481b8cbc7dfetascom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA21Tf1AUZRjm2927W45bXZZfL8hVcxZWlJ1a0xXl+EfTMNZM2lBTzjW4xHp3 Ixx0e6DQNB5KhpdMiFEHAYLHOBNzHgZKMlTIJSGIg3EzoQ4XIogoioUmweFduyzI/dE/7zz7 vO/zPu/3ft+SODNBJpAms5WzmNksjVxJKF89rn7+4LtBvbZo+Gldxam/cF1H5x2Z7t58K9KN X7+G63qvsptkqc2BbpTaVuVTpDY0zGKp3tJTsi3ENuVrmVyWKZ+zvLBxu9JY3NWFcsedaHd7 /3cKG/KXITsKJ4F+EUYenleImKErMSiq+UTCLgRjh5R2pBTwXQT3Djlx6eMXBP9+75GJVXJ6 E/T8sU9uRyQZTZtg8PNdIo3TeTDcXUOIOIpOgoG+iYXyaHoNjNluYFL5+zB7LEmkCfopaJ10 4CKm6Jeh7YejcsnqKgZN939d6BNOfwQlrpaFoRGthhMn+nHJKw6ujB3BpMPQ0PCTxAMdAzdH AzIJPwGDvTcIqT4dAjY3IZlFQk/lGFGGYqtCWlWFlFWFlEn8c1DXPi2XcDIcq5/El3DfmVEs lK9DikYUu4PT5mdr17+i1a61ZHB8oXbd2o9zspuRdL2q06irweBBNIk0KiojJahnZGw+X5Dt QS+RmCaG0hgDemZFRk5mgZHljemWvCyO1yRQiRc365moRzSfl5Ft4nlTjtmDgMQ10ZR9RtBR mWxBIWfJkWQetIokNHGUgXxHz9AG1srt5LhczrKUTSFJDVDPCM+NibRwBm73DlOWdSmtUVMo LCyMiQ3NhNpiZLgHbSBVgrdyq9CC4nPZbN5kWJTHS3JmiV2W9iKWLLtZcxQnO7tqhegdFOPU rFOIfzc2CHFGjAxhzjFzCXHUWbE7LfYx5pkfzZeQSDkP+vVMTEhi2eMWGkTChqOo1C2CWCX8 Y8uTAbVKXGbkIrksWu8UNPSXcVDieRNqz3DQcdmLoG7uKwzKSusxaB4+j0Px5J8EzA/7CWh6 OE+Aw/mjDALl9XK4WO2Xg2OkTQHlwZ8V0NH9jwIO3N4fDl+7G8Ph0vgDJbhG9kdAU7AkAspn qiOgtrY9Aib6zqkEhVcFZ71uCg77zq2AucqKldB6cmAltOx10NBXZmPA1WdnYKrdx9wSlo4J S09rFy+ct7LW/1n6Irt8tgQbspycXkP2tKS98dbQk98mbescKL6mLtJ/sDHwadIut8H/dpLO qibtxwvvqqrV+N6UtDu+UsfvFx5cuZQ8uNqxQf3h4/Gj4/dPJ3/h9aTXRgWHyNzbrw+5jmwd a1ZPbfdfuM6PfLPZPf2b7cCefTvdMf2JU5Eqg2/Pe/Hy1cHPHquYu8xoCN7IrnsWt/Dsf8vz 1/j7BAAA Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2019 07:04:52 -0000 --_000_8e213e313f2c4fcab9fa9481b8cbc7dfetascom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Sasha, understood. There are two different types of served user instances (routing= logic versus fault/alarm management of operators). Santosh, > Just curious to know why do you have this use case? I mean why not use= CFM itself? we are considering a use case of 1. a private network domain, 2. with roughly 80% Ethernet and 20% non-Ethernet at link layer, and 3. a traffic mix of IP-based and IP-less applications, 4. primarily static routing, and with the objective of 5. continuity supervision (at link segments) and 6. connectivity supervision (end-to-end, at network routes). IEEE CFM might be then the candidate for (5) and Ethernet, but not the non-= Ethernet link layer technologies. IETF BFD would be the candidate for (6), for IP, but also non-IP-based end-= to-end transport connections. The engineering goal would be preferably a single supervision technology (f= or 5 and 6, for IP and non-IP, for Ethernet and non-Ethernet link level con= nections). And that technology for this networking use case might be BFD, particularil= y when we could cover the 80% of Ethernet links as well. Regards, Albrecht From: Alexander Vainshtein Sent: 08 June 2019 14:46 To: Schwarz Albrecht (ETAS/ESY1) Cc: rtg-bfd@ietf.org; Stewart Bryant ; Jeffrey Ha= as Subject: Re: Direct BFD over Ethernet? Albrecht, I guess you are right and it is indeed mainly the technology ownership issu= e. To the best of my recollection the BFD WG hss tried to cooperate with IEEE = 802.1, but these attempts have failed. At the same time I think there is a difference in the overall attitude with= regard to OAM between IETF and IEEE 802.1. The former seems to consider OAM sessions (and, specifically, BFD) as "help= ers" for some other protocols (e.g., routing): these sessions are usually s= et up when the "client protocol" peers establish a peering relationship, an= d failure of the OAM session is an indication of failure of the peering rel= ationship of the client protocol (see RFC 5882 for details). The latter seems to treat OAM mainly as providing indications (alarms) to t= he operator. My 2c. Thumb typed by Sasha Vainshtein From: Schwarz Albrecht (ETAS/ESY1) Sent: Saturday, June 8, 11:47 Subject: RE: Direct BFD over Ethernet? To: Jeffrey Haas, Stewart Bryant Cc: Alexander Vainshtein, rtg-bfd@ietf.org Thanks Sasha, Jeff & Stewart for your reply! OK, understood, more a technol= ogy ownership question (IEEE 802 vs IETF) than a technical issue. Running B= FD directly over Ethernet would (at least) require to assign an Ethertype c= odepoint (https://www.iana.org/assignments/ieee-802-numbers/ieee-802-number= s.xml ) for BFD. But BFD-over-Ethernet seems to be then in direct competiti= on with the IEEE 802.1ag defined OAM capabilities (guess the Connectivity F= ault Management protocols), i.e., the IEEE Continuity Check protocol. My ro= ugh understanding. Thanks again! Albrecht -----Original Message----- From: = Jeffrey Haas Sent: 07 June 2019 13:56 To: Stewart Bryant Cc: Alexander Vain= shtein ; Schwarz Albrecht (ETAS/ESY1) ; Rtg-bfd@ietf.org Subject: Re: Direct BFD over Ethernet? On Fri, Jun 07, 2019 at 12:20= :30PM +0100, Stewart Bryant wrote: > > +1 > > However if you really want BF= D, you only need a lightweight IP > implementation to carry it. During the = work for BFD for LAG, IETF already went a bit too close to stepping into IE= EE territory. Raw BFD over Ethernet would not be received very well by that= organization, I think. (Even if it'd be trivial to specify.) -- Jeff ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have recei= ved this transmission in error, please inform us by e-mail, phone or fax, and then d= elete the original and all copies thereof. ___________________________________________________________________________ --_000_8e213e313f2c4fcab9fa9481b8cbc7dfetascom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks Sasha,

understood. There are two = different types of served user instances (routing logic versus fault/alarm = management of operators).

 

Santosh,=

>    Just curious to know why do you ha= ve this use case? I mean why not use CFM itself? 

we are considering a use c= ase of

1. = ;    a private network = domain,

2. = ;    with roughly 80% E= thernet and 20% non-Ethernet at link layer, and

3. = ;    a traffic mix of I= P-based and IP-less applications,

4. = ;    primarily static r= outing,

and with the objective of<= o:p>

5. = ;    continuity supervi= sion (at link segments) and

6. = ;    connectivity super= vision (end-to-end, at network routes).

 

IEEE CFM might be then the candidate for = (5) and Ethernet, but not the non-Ethernet link layer technologies.

IETF BFD would be the candidate for (6), = for IP, but also non-IP-based end-to-end transport connections.<= /span>

 

The engineering goal would be preferably = a single supervision technology (for 5 and 6, for IP and non-IP, for Ethern= et and non-Ethernet link level connections).

And that technology for this networking u= se case might be BFD, particularily when we could cover the 80% of Ethernet= links as well.

 

Regards,

Albrecht

From: = Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Sent: 08 June 2019 14:46
To: Schwarz Albrecht (ETAS/ESY1) <Albrecht.Schwarz@etas.com> Cc: rtg-bfd@ietf.org; Stewart Bryant <stewart.bryant@gmail.com>= ;; Jeffrey Haas <jhaas@pfrc.org>
Subject: Re: Direct BFD over Ethernet?

 

Albrecht,

I guess yo= u are right and it is indeed mainly the technology ownership issue.

To the bes= t of my recollection the BFD WG hss tried to cooperate with IEEE 802.1, but= these attempts have failed.

At the sam= e time I think there is a difference in the overall attitude with regard to= OAM between IETF and IEEE 802.1.

The former= seems to consider OAM sessions (and, specifically, BFD) as "helpers&q= uot; for some other protocols (e.g., routing): these sessions are usually set up when the "client protocol" peers establish a = peering relationship, and failure of the OAM session is an indication of fa= ilure of the peering relationship of the client protocol (see RFC 5882 for = details). 

The latter= seems to treat OAM mainly as providing indications (alarms) to the operato= r.

My 2c.

Thumb typed by Sasha Vainshtein

 

From: Schwarz Albrecht (ETAS/ESY1)

Sent: Saturday, June 8, 11:47

Subject: RE: Direct BFD over Ethernet?

To: Jeffrey Haas, Stewart Bryant

Cc: Alexan= der Vainshtein, rtg-bfd@ietf.org

Thanks Sas= ha, Jeff & Stewart for your reply! OK, understood, more a technology ow= nership question (IEEE 802 vs IETF) than a technical issue. Running BFD directly over Ethernet would (at least) require to assi= gn an Ethertype codepoint (https://www.iana.org/assignments/ieee-80= 2-numbers/ieee-802-numbers.xml ) for BFD. But BFD-over-Ethernet seems to be then in direct competition wi= th the IEEE 802.1ag defined OAM capabilities (guess the Connectivity Fault = Management protocols), i.e., the IEEE Continuity Check protocol. My rough u= nderstanding. Thanks again! Albrecht -----Original Message----- From: Jeffrey Haas Sent: 07 June 2019 13:56 To:= Stewart Bryant Cc: Alexander Vainshtein ; Schwarz Albrecht (ETAS/ESY1) ; Rtg-bfd@ietf.org Subject: Re: Direc= t BFD over Ethernet? On Fri, Jun 07, 2019 at 12:20:30PM +0100, Stewart = Bryant wrote: > > +1 > > However if you really want BFD, yo= u only need a lightweight IP > implementation to carry it. During the work for BFD for LAG, IETF already went a bit too close to = stepping into IEEE territory. Raw BFD over Ethernet would not be received v= ery well by that organization, I think. (Even if it'd be trivial to specify= .) -- Jeff


___________________________________________________________________________=

This e-mail message is intended for the recipient only and contains informa= tion which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have recei= ved this
transmission in error, please inform us by e-mail, phone or fax, and then d= elete the original
and all copies thereof.
___________________________________________________________________________=

--_000_8e213e313f2c4fcab9fa9481b8cbc7dfetascom_-- From nobody Tue Jun 11 00:19:03 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92F9120119 for ; Tue, 11 Jun 2019 00:18:59 -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_HELO_NONE=0.001, 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 c7NnLz9D89Sp for ; Tue, 11 Jun 2019 00:18:57 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 59046120047 for ; Tue, 11 Jun 2019 00:18:57 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id w9so1222394wmd.1 for ; Tue, 11 Jun 2019 00:18:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eUk0rolTXyjP61soSHv0t0Q2K/5lo1jO/ELO6yllTyo=; b=NwBmDm/+wyL5W71tWLsuCsoZaKPuyYXx/s8iooNeSZ6eV68XB+e4FAaXMX2q5/aAwq QV8p9TswhlMvhG/9wZSXa95cZ5EXLqHdv0Y8QGGyVqF6Y20cSOdR60/v29h/tuJbxZzu d5MZOnxjFUmsc5gUW21p8NrV/l59Mvqe0hN2Rkh9oecNLKPvVYuq9oTmwBnFYdLH4dfQ MK6lBFis46gvJlnhKEjEqsXFDnmyHj/FFBjJWAu2/uUi+SFKraQwWbmUUr2Vvc5gxyUR 7XjHlGr6kRhLMYdfVA8rZwrK5lvRdhl3cXy7YgJPgAzgkuXuniczoXzogM7WkrLS9zP7 lf3g== 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=eUk0rolTXyjP61soSHv0t0Q2K/5lo1jO/ELO6yllTyo=; b=Me+okIkjKkdxUL1JwcaLTY/SAsOIiwDg9u7Fap2VktQpnzBQRKbLbRNDvF718l4Bpa OeOr8v76oFLqbeNfwP5a1yRjRHdGJ3R+WTHe+yBHu+q2sMJg5PvAyYJWB0EBS5yHMWf9 89GlXSMmipjYL6jFNsPKK15cCnqb4TJ5UD80NM18u++5qMhdagDI/awqnqEpwqv2UTEg PfNg6IuEocK15Ck5VcfR2gPks61g8bIonRrmU97DZwh6EbtftrFLQI3Z4KXKb03kljaA XKnCbu8x1Z/f2pL/pAYzc2dwjCjc+/mdGURIjfGcbaDaXrKV0V7HwPONZBGrbevfQdR0 B32A== X-Gm-Message-State: APjAAAVnfPpkN+k+XudgG24HJkF8DYQbj+5Z6CZRMrHlEskSEma+buwK +NSwSukWYmkhuz511q0KwjY= X-Google-Smtp-Source: APXvYqwE2c3zPL6IZ0Q45zVMTiPkZiaa225NVZq2XucatPl2QHDF5+pYC1me2xo5L2/iKzmc35NrMw== X-Received: by 2002:a1c:1bc1:: with SMTP id b184mr17669571wmb.42.1560237535747; Tue, 11 Jun 2019 00:18:55 -0700 (PDT) Received: from [192.168.2.105] (host213-123-124-182.in-addr.btopenworld.com. [213.123.124.182]) by smtp.gmail.com with ESMTPSA id o11sm1893763wmh.37.2019.06.11.00.18.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jun 2019 00:18:55 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-A693B73F-E862-49F5-BE4E-586E069EF263 Mime-Version: 1.0 (1.0) Subject: Re: Direct BFD over Ethernet? From: Stewart Bryant X-Mailer: iPad Mail (16F203) In-Reply-To: <8e213e313f2c4fcab9fa9481b8cbc7df@etas.com> Date: Tue, 11 Jun 2019 08:18:54 +0100 Cc: Alexander Vainshtein , Santosh P K , "rtg-bfd@ietf.org" , Jeffrey Haas Content-Transfer-Encoding: 7bit Message-Id: References: <20190607115617.GC15506@pfrc.org> <7a42f74e46484476a8b642a29649a471@etas.com> <8e213e313f2c4fcab9fa9481b8cbc7df@etas.com> To: "Schwarz Albrecht (ETAS/ESY1)" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2019 07:19:01 -0000 --Apple-Mail-A693B73F-E862-49F5-BE4E-586E069EF263 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable If you have an Ethernet that is not carrying IP, and want to use BFD you cou= ld still wrap the BFD in IP, and pull those packets off by recognising the I= P Ethertype. No other protocol on the wire can be using that Ethertype, so t= here is no ambiguity. You no need to send the payload to an IP handler if th= ere is no IP, just treat the IP as opaque data. If you do have IP on the Ethernet and want to check before the packet gets t= o the IP handler you could use a well-known IP address and pull those packet= s off first as a special case. - Stewart Sent from my iPad > On 11 Jun 2019, at 08:04, Schwarz Albrecht (ETAS/ESY1) wrote: >=20 > Thanks Sasha, > understood. There are two different types of served user instances (routin= g logic versus fault/alarm management of operators). > =20 > Santosh, > > Just curious to know why do you have this use case? I mean why not us= e CFM itself?=20 > we are considering a use case of > 1. a private network domain, > 2. with roughly 80% Ethernet and 20% non-Ethernet at link layer, and > 3. a traffic mix of IP-based and IP-less applications, > 4. primarily static routing, > and with the objective of > 5. continuity supervision (at link segments) and > 6. connectivity supervision (end-to-end, at network routes). > =20 > IEEE CFM might be then the candidate for (5) and Ethernet, but not the non= -Ethernet link layer technologies. > IETF BFD would be the candidate for (6), for IP, but also non-IP-based end= -to-end transport connections. > =20 > The engineering goal would be preferably a single supervision technology (= for 5 and 6, for IP and non-IP, for Ethernet and non-Ethernet link level con= nections). > And that technology for this networking use case might be BFD, particulari= ly when we could cover the 80% of Ethernet links as well. > =20 > Regards, > Albrecht >=20 > From: Alexander Vainshtein =20 > Sent: 08 June 2019 14:46 > To: Schwarz Albrecht (ETAS/ESY1) > Cc: rtg-bfd@ietf.org; Stewart Bryant ; Jeffrey H= aas > Subject: Re: Direct BFD over Ethernet? > =20 > Albrecht, > I guess you are right and it is indeed mainly the technology ownership iss= ue. >=20 > To the best of my recollection the BFD WG hss tried to cooperate with IEEE= 802.1, but these attempts have failed. >=20 > At the same time I think there is a difference in the overall attitude wit= h regard to OAM between IETF and IEEE 802.1. >=20 > The former seems to consider OAM sessions (and, specifically, BFD) as "hel= pers" for some other protocols (e.g., routing): these sessions are usually s= et up when the "client protocol" peers establish a peering relationship, and= failure of the OAM session is an indication of failure of the peering relat= ionship of the client protocol (see RFC 5882 for details).=20 >=20 > The latter seems to treat OAM mainly as providing indications (alarms) to t= he operator. >=20 > My 2c. >=20 > Thumb typed by Sasha Vainshtein > =20 > From: Schwarz Albrecht (ETAS/ESY1) > Sent: Saturday, June 8, 11:47 > Subject: RE: Direct BFD over Ethernet? > To: Jeffrey Haas, Stewart Bryant > Cc: Alexander Vainshtein, rtg-bfd@ietf.org=20 >=20 >=20 > Thanks Sasha, Jeff & Stewart for your reply! OK, understood, more a techno= logy ownership question (IEEE 802 vs IETF) than a technical issue. Running B= FD directly over Ethernet would (at least) require to assign an Ethertype co= depoint (https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.= xml ) for BFD. But BFD-over-Ethernet seems to be then in direct competition w= ith the IEEE 802.1ag defined OAM capabilities (guess the Connectivity Fault M= anagement protocols), i.e., the IEEE Continuity Check protocol. My rough und= erstanding. Thanks again! Albrecht -----Original Message----- From: Jeffrey H= aas Sent: 07 June 2019 13:56 To: Stewart Bryant Cc: Alexander Vainshtein ; S= chwarz Albrecht (ETAS/ESY1) ; Rtg-bfd@ietf.org Subject: Re: Direct BFD over E= thernet? On Fri, Jun 07, 2019 at 12:20:30PM +0100, Stewart Bryant wrote: > >= +1 > > However if you really want BFD, you only need a lightweight IP > imp= lementation to carry it. During the work for BFD for LAG, IETF already went a= bit too close to stepping into IEEE territory. Raw BFD over Ethernet would n= ot be received very well by that organization, I think. (Even if it'd be tri= vial to specify.) -- Jeff >=20 >=20 > __________________________________________________________________________= _ >=20 > This e-mail message is intended for the recipient only and contains inform= ation which is=20 > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 > transmission in error, please inform us by e-mail, phone or fax, and then d= elete the original=20 > and all copies thereof. > __________________________________________________________________________= _ --Apple-Mail-A693B73F-E862-49F5-BE4E-586E069EF263 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit If you have an Ethernet that is not carrying IP, and want to use BFD you could still wrap the BFD in IP, and pull those packets off by recognising the IP Ethertype. No other protocol on the wire can be using that Ethertype, so there is no ambiguity. You no need to send the payload to an IP handler if there is no IP, just treat the IP as opaque data.

If you do have IP on the Ethernet and want to check before the packet gets to the IP handler you could use a well-known IP address and pull those packets off first as a special case.

- Stewart

Sent from my iPad

On 11 Jun 2019, at 08:04, Schwarz Albrecht (ETAS/ESY1) <Albrecht.Schwarz@etas.com> wrote:

Thanks Sasha,

understood. There are two different types of served user instances (routing logic versus fault/alarm management of operators).

 

Santosh,

>    Just curious to know why do you have this use case? I mean why not use CFM itself? 

we are considering a use case of

1.     a private network domain,

2.     with roughly 80% Ethernet and 20% non-Ethernet at link layer, and

3.     a traffic mix of IP-based and IP-less applications,

4.     primarily static routing,

and with the objective of

5.     continuity supervision (at link segments) and

6.     connectivity supervision (end-to-end, at network routes).

 

IEEE CFM might be then the candidate for (5) and Ethernet, but not the non-Ethernet link layer technologies.

IETF BFD would be the candidate for (6), for IP, but also non-IP-based end-to-end transport connections.

 

The engineering goal would be preferably a single supervision technology (for 5 and 6, for IP and non-IP, for Ethernet and non-Ethernet link level connections).

And that technology for this networking use case might be BFD, particularily when we could cover the 80% of Ethernet links as well.

 

Regards,

Albrecht

From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Sent: 08 June 2019 14:46
To: Schwarz Albrecht (ETAS/ESY1) <Albrecht.Schwarz@etas.com>
Cc: rtg-bfd@ietf.org; Stewart Bryant <stewart.bryant@gmail.com>; Jeffrey Haas <jhaas@pfrc.org>
Subject: Re: Direct BFD over Ethernet?

 

Albrecht,

I guess you are right and it is indeed mainly the technology ownership issue.

To the best of my recollection the BFD WG hss tried to cooperate with IEEE 802.1, but these attempts have failed.

At the same time I think there is a difference in the overall attitude with regard to OAM between IETF and IEEE 802.1.

The former seems to consider OAM sessions (and, specifically, BFD) as "helpers" for some other protocols (e.g., routing): these sessions are usually set up when the "client protocol" peers establish a peering relationship, and failure of the OAM session is an indication of failure of the peering relationship of the client protocol (see RFC 5882 for details). 

The latter seems to treat OAM mainly as providing indications (alarms) to the operator.

My 2c.

Thumb typed by Sasha Vainshtein

 

From: Schwarz Albrecht (ETAS/ESY1)

Sent: Saturday, June 8, 11:47

Subject: RE: Direct BFD over Ethernet?

To: Jeffrey Haas, Stewart Bryant

Cc: Alexander Vainshtein, rtg-bfd@ietf.org

Thanks Sasha, Jeff & Stewart for your reply! OK, understood, more a technology ownership question (IEEE 802 vs IETF) than a technical issue. Running BFD directly over Ethernet would (at least) require to assign an Ethertype codepoint (https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xml ) for BFD. But BFD-over-Ethernet seems to be then in direct competition with the IEEE 802.1ag defined OAM capabilities (guess the Connectivity Fault Management protocols), i.e., the IEEE Continuity Check protocol. My rough understanding. Thanks again! Albrecht -----Original Message----- From: Jeffrey Haas Sent: 07 June 2019 13:56 To: Stewart Bryant Cc: Alexander Vainshtein ; Schwarz Albrecht (ETAS/ESY1) ; Rtg-bfd@ietf.org Subject: Re: Direct BFD over Ethernet? On Fri, Jun 07, 2019 at 12:20:30PM +0100, Stewart Bryant wrote: > > +1 > > However if you really want BFD, you only need a lightweight IP > implementation to carry it. During the work for BFD for LAG, IETF already went a bit too close to stepping into IEEE territory. Raw BFD over Ethernet would not be received very well by that organization, I think. (Even if it'd be trivial to specify.) -- Jeff


___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.
___________________________________________________________________________

--Apple-Mail-A693B73F-E862-49F5-BE4E-586E069EF263-- From nobody Tue Jun 11 00:29:42 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD4712024C for ; Tue, 11 Jun 2019 00:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=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=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.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 uxl0xa8_FYj6 for ; Tue, 11 Jun 2019 00:29:36 -0700 (PDT) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.116]) (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 87BA7120233 for ; Tue, 11 Jun 2019 00:29:35 -0700 (PDT) Received: from [85.158.142.200] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-5.bemta.az-b.eu-central-1.aws.symcld.net id 88/19-04807-B585FFC5; Tue, 11 Jun 2019 07:29:31 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphl+JIrShJLcpLzFFi42Ixkd5SoRsd8T/ G4EUvr8Wyex4W+w++ZbX4/Gcbo8Wzp4+YLU49SHRg9Zg87QCTx85Zd9k9liz5yeRxuXcrawBL FGtmXlJ+RQJrRndTM3vBli6miomr3RsY37QxdTFycbAIrGWWaFvxnAXEERKYyCTR+/0VK4Rzn 1FiztLjbF2MnBxsArYSm1bfBbNFBLIkDvctYAWxmQVKJVZPegdmCwuoSVw684IVokZd4knDcy YIO1mi5+1JdhCbRUBV4v/kS8wgNq9ArETv652MILaQwG5miR9ng0BsTqBdu18vA9vFKCAm8f3 UGiaIXeISt57MB7MlBAQkluw5zwxhi0q8fPyPFaI+SeL+04WMEHFFiRn35rBD2LISl+Z3Q8V9 JTY9PAj0MQeQrSyx5UUsyL8SAo8ZJQ4e2M4OEdeSmLdQDqJcSuLExaOsEHaOxJSlk6BGqku0f JwHFZeRmHB3OzPEnONsEovebWaC+CtZ4sSczywQRXISq3ofskAUXWCW2HXxJfMERu1ZSH6DsP Mk7v75wDILHEaCEidnPgGyOYDimhLrd+lDlChKTOl+yA5ha0i0zpnLjiy+gJF9FaNlUlFmekZ JbmJmjq6hgYGuoaGxromuobGpXmKVbpJeaqlucmpeSVEiUFYvsbxYr7gyNzknRS8vtWQTIzDR pRSytO9g7D/yWu8QoyQHk5Ior1LGvxghvqT8lMqMxOKM+KLSnNTiQ4wyHBxKErzzwv/HCAkWp aanVqRl5gCTLkxagoNHSYR3JUiat7ggMbc4Mx0idYoxkGPCy7mLmDkuX58HJN/9XAwkP65aAi S/g8kLZ0HkkblLFzELseTl56VKifNeBBkkADIoozQPbg0sk1xilJUS5mVkYGAQ4ilILcrNLEG Vf8UozsGoJAxxDk9mXgncNa+ADmUCOjRk9z+QQ0sSEVJSDUwKR+dPjfoU+LJa8+6jqx3Mpw6v OBZ+8dOJaS5LfruFdpSpq9/vYn1puXTn5vUv82PTbDX4ry+R2+k3u/f6tGtXtf0NClv1+mOOG 74zcFu1Q6Vy2r6FAul2bre/rr56+6xZsEHxQc3j30I6VO7NkrXh37R2ctT+R5yfZIp3x7u2zb 0SPeNppPd99bNdX6LaF8jqRVmdnTw53+OGWaLdrv4kZbb1v+a9C9208Pbjk9936T8se88ra/t vy8WQwoxNkgdvLuM1uNCq8tkzfdEGJS3bv9lim2QW+661uvnE4HKd5pkfPHHSGh8ZvPwP/p19 3+31o98hyyqunviQklpms6LK8UXhGeVSR8mnm+urq8stlViKMxINtZiLihMBkW7jQ58EAAA= X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-12.tower-245.messagelabs.com!1560238166!7515240!1 X-Originating-IP: [52.27.180.120] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.31.5; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 14924 invoked from network); 11 Jun 2019 07:29:30 -0000 Received: from us-west-2c.mta.dlp.protect.symantec.com (HELO EUR01-HE1-obe.outbound.protection.outlook.com) (52.27.180.120) by server-12.tower-245.messagelabs.com with AES256-SHA256 encrypted SMTP; 11 Jun 2019 07:29:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ECI365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2eZgULaImj0VG54Xln9jOaoqpURhwep8zc+VeFF8cZo=; b=tjG/wx3OUQpXSrzLoYgF1nHSTMvP9cau2VPp1MXxfIC8JwveB2Ob5OzV+0pp92wQUWQVok41W7gFpyEcmPFaYFSBabez8jy4t2dGa6jf0D9CtA36SLSi8DZEBog83hZyJZzOkahTJA3gZlPx0dK2odD5o+uPxNwXSFLQOvy1V+E= Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.159) by AM0PR03MB3778.eurprd03.prod.outlook.com (52.135.151.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.17; Tue, 11 Jun 2019 07:29:24 +0000 Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::91f3:6bd1:1631:9b4a]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::91f3:6bd1:1631:9b4a%6]) with mapi id 15.20.1965.017; Tue, 11 Jun 2019 07:29:24 +0000 From: Alexander Vainshtein To: Stewart Bryant , "Schwarz Albrecht (ETAS/ESY1)" CC: Santosh P K , "rtg-bfd@ietf.org" , Jeffrey Haas Subject: RE: Direct BFD over Ethernet? Thread-Topic: Direct BFD over Ethernet? Thread-Index: AdUdHwIY3QLc2dE1SwCr012LbinkaAAAvtBvAABBlQAAAT/tgAArr1KAAAfpV5kAi2MYAAAAfqkAAABGw0A= Date: Tue, 11 Jun 2019 07:29:24 +0000 Message-ID: References: <20190607115617.GC15506@pfrc.org> <7a42f74e46484476a8b642a29649a471@etas.com> <8e213e313f2c4fcab9fa9481b8cbc7df@etas.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9172bb64-d59c-4b88-4d75-08d6ee3e8721 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM0PR03MB3778; x-ms-traffictypediagnostic: AM0PR03MB3778: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 006546F32A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(39860400002)(366004)(136003)(199004)(189003)(51444003)(13464003)(7736002)(790700001)(14444005)(316002)(6116002)(11346002)(52536014)(476003)(486006)(446003)(66066001)(71200400001)(3846002)(8936002)(478600001)(81156014)(3480700005)(71190400001)(5660300002)(54906003)(8676002)(2906002)(33656002)(81166006)(74316002)(110136005)(86362001)(14454004)(256004)(102836004)(76176011)(99286004)(186003)(26005)(7696005)(606006)(53546011)(72206003)(6506007)(236005)(9686003)(55016002)(25786009)(68736007)(66946007)(73956011)(66556008)(66476007)(76116006)(229853002)(54896002)(6306002)(66446008)(4326008)(64756008)(6246003)(53936002)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB3778; H:AM0PR03MB3828.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: LLO3xbqu+ZR+m+nxSWFyATfDQhrrs1hzpP/11LdBXXJgUe26UmRHbuwx4qrb/NuXtycstFctiuzabXp6HutS+2C5cjPGkbXU7btmaM8p16T/y+m+y3fcg6d63wcuvZEuYVsCu/wHpiwT6WeONah9Z1hopG47SulLspMyvje3AUxADygZdfXsdMHN+R0GFxlxqh5gI0bjBgTK9wdACbq6bTpHKRQK5QgGNkjLkv9uZIoBDwDMAC4I7w1Iniz+wqeVCJrH0D73T6Ns3NeQcM18gUwkbWIAVkndr/kd9hESg5XJCZGtXkr/tV+GraweROvuTOJo8ZM+KIEXP+uMMAll14T36E4DyRlrc5olpQcNoyZ8H7nh/vea67pYdQUZjxEuOp4p6DAmocQjBkzmRKIc1WleNMFklQaOLVUKhhcW610= Content-Type: multipart/alternative; boundary="_000_AM0PR03MB38283363BD4F738478E650849DED0AM0PR03MB3828eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9172bb64-d59c-4b88-4d75-08d6ee3e8721 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2019 07:29:24.0754 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: alexvain@ecitele.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB3778 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2019 07:29:41 -0000 --_000_AM0PR03MB38283363BD4F738478E650849DED0AM0PR03MB3828eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgc2VlbXMgdGhlcmUgYXJlIOKAnDIwJSBub24tRXRoZXJuZXQgYXQgbGluayBsYXllcuKAnSBp biB0aGUgbmV0d29yayBpbiBxdWVzdGlvbi4KVGhlcmVmb3JlIEkgdGhpbmsgdGhhdCBJUC1iYXNl ZCBCRkQgaXMgdGhlIG9ubHkgd2F5IHRvIGFkZHJlc3MgZW5kLXRvLWVuZCBjb25uZWN0aXZpdHku CkFzIFN0ZXdhcnQgaGFzIHNhaWQsIHlvdSBvbmx5IG5lZWQgc29tZSBsaWdodHdlaWdodCBJUCBp biB5b3VyIGRldmljZXMgdG8gZG8gdGhhdC4KClJlZ2FyZHMsClNhc2hhCgpPZmZpY2U6ICs5NzIt MzkyNjYzMDIKQ2VsbDogICAgICArOTcyLTU0OTI2NjMwMgpFbWFpbDogICBBbGV4YW5kZXIuVmFp bnNodGVpbkBlY2l0ZWxlLmNvbQoKRnJvbTogU3Rld2FydCBCcnlhbnQgPHN0ZXdhcnQuYnJ5YW50 QGdtYWlsLmNvbT4KU2VudDogVHVlc2RheSwgSnVuZSAxMSwgMjAxOSAxMDoxOSBBTQpUbzogU2No d2FyeiBBbGJyZWNodCAoRVRBUy9FU1kxKSA8QWxicmVjaHQuU2Nod2FyekBldGFzLmNvbT4KQ2M6 IEFsZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT47 IFNhbnRvc2ggUCBLIDxzYW50b3NoLnBhbGxhZ2F0dGlAZ21haWwuY29tPjsgcnRnLWJmZEBpZXRm Lm9yZzsgSmVmZnJleSBIYWFzIDxqaGFhc0BwZnJjLm9yZz4KU3ViamVjdDogUmU6IERpcmVjdCBC RkQgb3ZlciBFdGhlcm5ldD8KCklmIHlvdSBoYXZlIGFuIEV0aGVybmV0IHRoYXQgaXMgbm90IGNh cnJ5aW5nIElQLCBhbmQgd2FudCB0byB1c2UgQkZEIHlvdSBjb3VsZCBzdGlsbCB3cmFwIHRoZSBC RkQgaW4gSVAsIGFuZCBwdWxsIHRob3NlIHBhY2tldHMgb2ZmIGJ5IHJlY29nbmlzaW5nIHRoZSBJ UCBFdGhlcnR5cGUuIE5vIG90aGVyIHByb3RvY29sIG9uIHRoZSB3aXJlIGNhbiBiZSB1c2luZyB0 aGF0IEV0aGVydHlwZSwgc28gdGhlcmUgaXMgbm8gYW1iaWd1aXR5LiBZb3Ugbm8gbmVlZCB0byBz ZW5kIHRoZSBwYXlsb2FkIHRvIGFuIElQIGhhbmRsZXIgaWYgdGhlcmUgaXMgbm8gSVAsIGp1c3Qg dHJlYXQgdGhlIElQIGFzIG9wYXF1ZSBkYXRhLgoKSWYgeW91IGRvIGhhdmUgSVAgb24gdGhlIEV0 aGVybmV0IGFuZCB3YW50IHRvIGNoZWNrIGJlZm9yZSB0aGUgcGFja2V0IGdldHMgdG8gdGhlIElQ IGhhbmRsZXIgeW91IGNvdWxkIHVzZSBhIHdlbGwta25vd24gSVAgYWRkcmVzcyBhbmQgcHVsbCB0 aG9zZSBwYWNrZXRzIG9mZiBmaXJzdCBhcyBhIHNwZWNpYWwgY2FzZS4KCi0gU3Rld2FydAoKU2Vu dCBmcm9tIG15IGlQYWQKCk9uIDExIEp1biAyMDE5LCBhdCAwODowNCwgU2Nod2FyeiBBbGJyZWNo dCAoRVRBUy9FU1kxKSA8QWxicmVjaHQuU2Nod2FyekBldGFzLmNvbTxtYWlsdG86QWxicmVjaHQu U2Nod2FyekBldGFzLmNvbT4+IHdyb3RlOgpUaGFua3MgU2FzaGEsCnVuZGVyc3Rvb2QuIFRoZXJl IGFyZSB0d28gZGlmZmVyZW50IHR5cGVzIG9mIHNlcnZlZCB1c2VyIGluc3RhbmNlcyAocm91dGlu ZyBsb2dpYyB2ZXJzdXMgZmF1bHQvYWxhcm0gbWFuYWdlbWVudCBvZiBvcGVyYXRvcnMpLgoKU2Fu dG9zaCwKPiAgICBKdXN0IGN1cmlvdXMgdG8ga25vdyB3aHkgZG8geW91IGhhdmUgdGhpcyB1c2Ug Y2FzZT8gSSBtZWFuIHdoeSBub3QgdXNlIENGTSBpdHNlbGY/CndlIGFyZSBjb25zaWRlcmluZyBh IHVzZSBjYXNlIG9mCgoxLiAgICAgIGEgcHJpdmF0ZSBuZXR3b3JrIGRvbWFpbiwKCjIuICAgICAg d2l0aCByb3VnaGx5IDgwJSBFdGhlcm5ldCBhbmQgMjAlIG5vbi1FdGhlcm5ldCBhdCBsaW5rIGxh eWVyLCBhbmQKCjMuICAgICAgYSB0cmFmZmljIG1peCBvZiBJUC1iYXNlZCBhbmQgSVAtbGVzcyBh cHBsaWNhdGlvbnMsCgo0LiAgICAgIHByaW1hcmlseSBzdGF0aWMgcm91dGluZywKYW5kIHdpdGgg dGhlIG9iamVjdGl2ZSBvZgoKNS4gICAgICBjb250aW51aXR5IHN1cGVydmlzaW9uIChhdCBsaW5r IHNlZ21lbnRzKSBhbmQKCjYuICAgICAgY29ubmVjdGl2aXR5IHN1cGVydmlzaW9uIChlbmQtdG8t ZW5kLCBhdCBuZXR3b3JrIHJvdXRlcykuCgpJRUVFIENGTSBtaWdodCBiZSB0aGVuIHRoZSBjYW5k aWRhdGUgZm9yICg1KSBhbmQgRXRoZXJuZXQsIGJ1dCBub3QgdGhlIG5vbi1FdGhlcm5ldCBsaW5r IGxheWVyIHRlY2hub2xvZ2llcy4KSUVURiBCRkQgd291bGQgYmUgdGhlIGNhbmRpZGF0ZSBmb3Ig KDYpLCBmb3IgSVAsIGJ1dCBhbHNvIG5vbi1JUC1iYXNlZCBlbmQtdG8tZW5kIHRyYW5zcG9ydCBj b25uZWN0aW9ucy4KClRoZSBlbmdpbmVlcmluZyBnb2FsIHdvdWxkIGJlIHByZWZlcmFibHkgYSBz aW5nbGUgc3VwZXJ2aXNpb24gdGVjaG5vbG9neSAoZm9yIDUgYW5kIDYsIGZvciBJUCBhbmQgbm9u LUlQLCBmb3IgRXRoZXJuZXQgYW5kIG5vbi1FdGhlcm5ldCBsaW5rIGxldmVsIGNvbm5lY3Rpb25z KS4KQW5kIHRoYXQgdGVjaG5vbG9neSBmb3IgdGhpcyBuZXR3b3JraW5nIHVzZSBjYXNlIG1pZ2h0 IGJlIEJGRCwgcGFydGljdWxhcmlseSB3aGVuIHdlIGNvdWxkIGNvdmVyIHRoZSA4MCUgb2YgRXRo ZXJuZXQgbGlua3MgYXMgd2VsbC4KClJlZ2FyZHMsCkFsYnJlY2h0CgoKRnJvbTogQWxleGFuZGVy IFZhaW5zaHRlaW4gPEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPG1haWx0bzpBbGV4 YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxlLmNvbT4+ClNlbnQ6IDA4IEp1bmUgMjAxOSAxNDo0NgpU bzogU2Nod2FyeiBBbGJyZWNodCAoRVRBUy9FU1kxKSA8QWxicmVjaHQuU2Nod2FyekBldGFzLmNv bTxtYWlsdG86QWxicmVjaHQuU2Nod2FyekBldGFzLmNvbT4+CkNjOiBydGctYmZkQGlldGYub3Jn PG1haWx0bzpydGctYmZkQGlldGYub3JnPjsgU3Rld2FydCBCcnlhbnQgPHN0ZXdhcnQuYnJ5YW50 QGdtYWlsLmNvbTxtYWlsdG86c3Rld2FydC5icnlhbnRAZ21haWwuY29tPj47IEplZmZyZXkgSGFh cyA8amhhYXNAcGZyYy5vcmc8bWFpbHRvOmpoYWFzQHBmcmMub3JnPj4KU3ViamVjdDogUmU6IERp cmVjdCBCRkQgb3ZlciBFdGhlcm5ldD8KCkFsYnJlY2h0LApJIGd1ZXNzIHlvdSBhcmUgcmlnaHQg YW5kIGl0IGlzIGluZGVlZCBtYWlubHkgdGhlIHRlY2hub2xvZ3kgb3duZXJzaGlwIGlzc3VlLgpU byB0aGUgYmVzdCBvZiBteSByZWNvbGxlY3Rpb24gdGhlIEJGRCBXRyBoc3MgdHJpZWQgdG8gY29v cGVyYXRlIHdpdGggSUVFRSA4MDIuMSwgYnV0IHRoZXNlIGF0dGVtcHRzIGhhdmUgZmFpbGVkLgpB dCB0aGUgc2FtZSB0aW1lIEkgdGhpbmsgdGhlcmUgaXMgYSBkaWZmZXJlbmNlIGluIHRoZSBvdmVy YWxsIGF0dGl0dWRlIHdpdGggcmVnYXJkIHRvIE9BTSBiZXR3ZWVuIElFVEYgYW5kIElFRUUgODAy LjEuClRoZSBmb3JtZXIgc2VlbXMgdG8gY29uc2lkZXIgT0FNIHNlc3Npb25zIChhbmQsIHNwZWNp ZmljYWxseSwgQkZEKSBhcyAiaGVscGVycyIgZm9yIHNvbWUgb3RoZXIgcHJvdG9jb2xzIChlLmcu LCByb3V0aW5nKTogdGhlc2Ugc2Vzc2lvbnMgYXJlIHVzdWFsbHkgc2V0IHVwIHdoZW4gdGhlICJj bGllbnQgcHJvdG9jb2wiIHBlZXJzIGVzdGFibGlzaCBhIHBlZXJpbmcgcmVsYXRpb25zaGlwLCBh bmQgZmFpbHVyZSBvZiB0aGUgT0FNIHNlc3Npb24gaXMgYW4gaW5kaWNhdGlvbiBvZiBmYWlsdXJl IG9mIHRoZSBwZWVyaW5nIHJlbGF0aW9uc2hpcCBvZiB0aGUgY2xpZW50IHByb3RvY29sIChzZWUg UkZDIDU4ODIgZm9yIGRldGFpbHMpLgpUaGUgbGF0dGVyIHNlZW1zIHRvIHRyZWF0IE9BTSBtYWlu bHkgYXMgcHJvdmlkaW5nIGluZGljYXRpb25zIChhbGFybXMpIHRvIHRoZSBvcGVyYXRvci4KTXkg MmMuClRodW1iIHR5cGVkIGJ5IFNhc2hhIFZhaW5zaHRlaW4KCkZyb206IFNjaHdhcnogQWxicmVj aHQgKEVUQVMvRVNZMSkKU2VudDogU2F0dXJkYXksIEp1bmUgOCwgMTE6NDcKU3ViamVjdDogUkU6 IERpcmVjdCBCRkQgb3ZlciBFdGhlcm5ldD8KVG86IEplZmZyZXkgSGFhcywgU3Rld2FydCBCcnlh bnQKQ2M6IEFsZXhhbmRlciBWYWluc2h0ZWluLCBydGctYmZkQGlldGYub3JnPG1haWx0bzpydGct YmZkQGlldGYub3JnPgoKClRoYW5rcyBTYXNoYSwgSmVmZiAmIFN0ZXdhcnQgZm9yIHlvdXIgcmVw bHkhIE9LLCB1bmRlcnN0b29kLCBtb3JlIGEgdGVjaG5vbG9neSBvd25lcnNoaXAgcXVlc3Rpb24g KElFRUUgODAyIHZzIElFVEYpIHRoYW4gYSB0ZWNobmljYWwgaXNzdWUuIFJ1bm5pbmcgQkZEIGRp cmVjdGx5IG92ZXIgRXRoZXJuZXQgd291bGQgKGF0IGxlYXN0KSByZXF1aXJlIHRvIGFzc2lnbiBh biBFdGhlcnR5cGUgY29kZXBvaW50IChodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9p ZWVlLTgwMi1udW1iZXJzL2llZWUtODAyLW51bWJlcnMueG1sICkgZm9yIEJGRC4gQnV0IEJGRC1v dmVyLUV0aGVybmV0IHNlZW1zIHRvIGJlIHRoZW4gaW4gZGlyZWN0IGNvbXBldGl0aW9uIHdpdGgg dGhlIElFRUUgODAyLjFhZyBkZWZpbmVkIE9BTSBjYXBhYmlsaXRpZXMgKGd1ZXNzIHRoZSBDb25u ZWN0aXZpdHkgRmF1bHQgTWFuYWdlbWVudCBwcm90b2NvbHMpLCBpLmUuLCB0aGUgSUVFRSBDb250 aW51aXR5IENoZWNrIHByb3RvY29sLiBNeSByb3VnaCB1bmRlcnN0YW5kaW5nLiBUaGFua3MgYWdh aW4hIEFsYnJlY2h0IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206IEplZmZyZXkgSGFh cyBTZW50OiAwNyBKdW5lIDIwMTkgMTM6NTYgVG86IFN0ZXdhcnQgQnJ5YW50IENjOiBBbGV4YW5k ZXIgVmFpbnNodGVpbiA7IFNjaHdhcnogQWxicmVjaHQgKEVUQVMvRVNZMSkgOyBSdGctYmZkQGll dGYub3JnPG1haWx0bzpSdGctYmZkQGlldGYub3JnPiBTdWJqZWN0OiBSZTogRGlyZWN0IEJGRCBv dmVyIEV0aGVybmV0PyBPbiBGcmksIEp1biAwNywgMjAxOSBhdCAxMjoyMDozMFBNICswMTAwLCBT dGV3YXJ0IEJyeWFudCB3cm90ZTogPiA+ICsxID4gPiBIb3dldmVyIGlmIHlvdSByZWFsbHkgd2Fu dCBCRkQsIHlvdSBvbmx5IG5lZWQgYSBsaWdodHdlaWdodCBJUCA+IGltcGxlbWVudGF0aW9uIHRv IGNhcnJ5IGl0LiBEdXJpbmcgdGhlIHdvcmsgZm9yIEJGRCBmb3IgTEFHLCBJRVRGIGFscmVhZHkg d2VudCBhIGJpdCB0b28gY2xvc2UgdG8gc3RlcHBpbmcgaW50byBJRUVFIHRlcnJpdG9yeS4gUmF3 IEJGRCBvdmVyIEV0aGVybmV0IHdvdWxkIG5vdCBiZSByZWNlaXZlZCB2ZXJ5IHdlbGwgYnkgdGhh dCBvcmdhbml6YXRpb24sIEkgdGhpbmsuIChFdmVuIGlmIGl0J2QgYmUgdHJpdmlhbCB0byBzcGVj aWZ5LikgLS0gSmVmZgoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpUaGlzIGUtbWFpbCBtZXNzYWdlIGlz IGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zIGluZm9ybWF0aW9u IHdoaWNoIGlzCkNPTkZJREVOVElBTCBhbmQgd2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVD SSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzCnRyYW5zbWlzc2lvbiBpbiBlcnJv ciwgcGxlYXNlIGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVs ZXRlIHRoZSBvcmlnaW5hbAphbmQgYWxsIGNvcGllcyB0aGVyZW9mLgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwoKVGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBm b3IgdGhlIHJlY2lwaWVudCBvbmx5IGFuZCBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBpcyAK Q09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8gRUNJIFRlbGVjb20u IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgCnRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNl IGluZm9ybSB1cyBieSBlLW1haWwsIHBob25lIG9yIGZheCwgYW5kIHRoZW4gZGVsZXRlIHRoZSBv cmlnaW5hbCAKYW5kIGFsbCBjb3BpZXMgdGhlcmVvZi4KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCg== --_000_AM0PR03MB38283363BD4F738478E650849DED0AM0PR03MB3828eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+CjxoZWFkPgo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNv bnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+CjxtZXRhIG5hbWU9IkdlbmVyYXRvciIg Y29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPgo8c3R5bGU+PCEt LQovKiBGb250IERlZmluaXRpb25zICovCkBmb250LWZhY2UKCXtmb250LWZhbWlseToiQ2FtYnJp YSBNYXRoIjsKCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQpAZm9udC1mYWNlCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsKCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bAoJe21hcmdpbjowY207CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7Cglmb250LXNpemU6MTIuMHB0 OwoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5OwoJY29sb3I6IzA1NjNDMTsKCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQKCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7Cgljb2xvcjojOTU0RjcyOwoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9CnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwg ZGl2Lk1zb0xpc3RQYXJhZ3JhcGgKCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7CgltYXJnaW4tdG9w OjBjbTsKCW1hcmdpbi1yaWdodDowY207CgltYXJnaW4tYm90dG9tOjBjbTsKCW1hcmdpbi1sZWZ0 OjM2LjBwdDsKCW1hcmdpbi1ib3R0b206LjAwMDFwdDsKCWZvbnQtc2l6ZToxMi4wcHQ7Cglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9CnAubXNvbm9ybWFsMCwgbGkubXNvbm9y bWFsMCwgZGl2Lm1zb25vcm1hbDAKCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7Cgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsKCW1hcmdpbi1yaWdodDowY207Cgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsKCW1hcmdpbi1sZWZ0OjBjbTsKCWZvbnQtc2l6ZToxMi4wcHQ7Cglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9CnNwYW4uRW1haWxTdHlsZTE5Cgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7Cglmb250LWZhbWlseToiQXJpYWwiLHNhbnMtc2VyaWY7Cgljb2xvcjp3 aW5kb3d0ZXh0OwoJZm9udC13ZWlnaHQ6bm9ybWFsOwoJZm9udC1zdHlsZTpub3JtYWw7fQpzcGFu LkVtYWlsU3R5bGUyMAoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5OwoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7Cgljb2xvcjojMUY0OTdEO30KLk1zb0NocERlZmF1bHQK CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsKCWZvbnQtc2l6ZToxMC4wcHQ7fQpAcGFnZSBX b3JkU2VjdGlvbjEKCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsKCW1hcmdpbjo3Mi4wcHQgNzIuMHB0 IDcyLjBwdCA3Mi4wcHQ7fQpkaXYuV29yZFNlY3Rpb24xCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQov KiBMaXN0IERlZmluaXRpb25zICovCkBsaXN0IGwwCgl7bXNvLWxpc3QtaWQ6NDQyMTk0MzgzOwoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NTg3MTMzOTg4IDEz NDgwNzU2NyAxMzQ4MDc1NzcgMTM0ODA3NTc5IDEzNDgwNzU2NyAxMzQ4MDc1NzcgMTM0ODA3NTc5 IDEzNDgwNzU2NyAxMzQ4MDc1NzcgMTM0ODA3NTc5O30KQGxpc3QgbDA6bGV2ZWwxCgl7bXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7Cgl0ZXh0 LWluZGVudDotMTguMHB0O30KQGxpc3QgbDA6bGV2ZWwyCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YWxwaGEtbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsKCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQpAbGlzdCBsMDpsZXZlbDMK CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsKCW1zby1sZXZlbC10YWItc3Rv cDpub25lOwoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsKCXRleHQtaW5kZW50Oi05 LjBwdDt9CkBsaXN0IGwwOmxldmVsNAoJe21zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9CkBsaXN0IGww OmxldmVsNQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOwoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7Cgl0ZXh0LWlu ZGVudDotMTguMHB0O30KQGxpc3QgbDA6bGV2ZWw2Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 cm9tYW4tbG93ZXI7Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246cmlnaHQ7Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQpAbGlzdCBsMDpsZXZlbDcKCXtt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsKCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsK CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQpAbGlzdCBsMDpsZXZlbDgKCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDphbHBoYS1sb3dlcjsKCW1zby1sZXZlbC10YWItc3RvcDpub25lOwoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0OwoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9CkBsaXN0IGwwOmxl dmVsOQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOwoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0OwoJdGV4dC1pbmRl bnQ6LTkuMHB0O30Kb2wKCXttYXJnaW4tYm90dG9tOjBjbTt9CnVsCgl7bWFyZ2luLWJvdHRvbTow Y207fQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPgo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPgo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPgo8bzppZG1hcCB2 OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pgo8L2hlYWQ+Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3 MiI+CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JdCBzZWVtcyB0aGVyZSBhcmUg4oCcPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPjIwJSBub24tRXRoZXJuZXQgYXQgbGluayBsYXllcjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+4oCdCiBpbiB0aGUgbmV0d29yayBpbiBxdWVzdGlvbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5UaGVyZWZvcmUgSSB0aGluayB0aGF0IElQLWJhc2VkIEJGRCBpcyB0 aGUgb25seSB3YXkgdG8gYWRkcmVzcyBlbmQtdG8tZW5kIGNvbm5lY3Rpdml0eS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5BcyBTdGV3YXJ0IGhhcyBzYWlkLCB5b3Ugb25seSBuZWVkIHNvbWUgbGlnaHR3ZWln aHQgSVAgaW4geW91ciBkZXZpY2VzIHRvIGRvIHRoYXQuPG86cD48L286cD48L3NwYW4+PC9wPgo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TYXNoYTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPk9mZmljZTogJiM0Mzs5NzIt MzkyNjYzMDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DZWxsOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmIzQzOzk3Mi01NDkyNjYzMDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+CjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5FbWFpbDombmJzcDsmbmJz cDsgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb208bzpwPjwvbzpwPjwvc3Bhbj48L3A+ CjwvZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPgo8ZGl2Pgo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFN0ZXdhcnQgQnJ5YW50ICZsdDtzdGV3YXJ0LmJyeWFu dEBnbWFpbC5jb20mZ3Q7Cjxicj4KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEp1bmUgMTEsIDIwMTkg MTA6MTkgQU08YnI+CjxiPlRvOjwvYj4gU2Nod2FyeiBBbGJyZWNodCAoRVRBUy9FU1kxKSAmbHQ7 QWxicmVjaHQuU2Nod2FyekBldGFzLmNvbSZndDs8YnI+CjxiPkNjOjwvYj4gQWxleGFuZGVyIFZh aW5zaHRlaW4gJmx0O0FsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tJmd0OzsgU2FudG9z aCBQIEsgJmx0O3NhbnRvc2gucGFsbGFnYXR0aUBnbWFpbC5jb20mZ3Q7OyBydGctYmZkQGlldGYu b3JnOyBKZWZmcmV5IEhhYXMgJmx0O2poYWFzQHBmcmMub3JnJmd0Ozxicj4KPGI+U3ViamVjdDo8 L2I+IFJlOiBEaXJlY3QgQkZEIG92ZXIgRXRoZXJuZXQ/PG86cD48L286cD48L3NwYW4+PC9wPgo8 L2Rpdj4KPC9kaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB5b3UgaGF2ZSBhbiBFdGhlcm5ldCB0aGF0IGlzIG5vdCBj YXJyeWluZyBJUCwgYW5kIHdhbnQgdG8gdXNlIEJGRCB5b3UgY291bGQgc3RpbGwgd3JhcCB0aGUg QkZEIGluIElQLCBhbmQgcHVsbCB0aG9zZSBwYWNrZXRzIG9mZiBieSByZWNvZ25pc2luZyB0aGUg SVAgRXRoZXJ0eXBlLiBObyBvdGhlciBwcm90b2NvbCBvbiB0aGUgd2lyZSBjYW4gYmUgdXNpbmcg dGhhdCBFdGhlcnR5cGUsIHNvIHRoZXJlIGlzCiBubyBhbWJpZ3VpdHkuIFlvdSBubyBuZWVkIHRv IHNlbmQgdGhlIHBheWxvYWQgdG8gYW4gSVAgaGFuZGxlciBpZiB0aGVyZSBpcyBubyBJUCwganVz dCB0cmVhdCB0aGUgSVAgYXMgb3BhcXVlIGRhdGEuPG86cD48L286cD48L3A+CjxkaXY+CjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SWYgeW91IGRvIGhhdmUgSVAgb24gdGhlIEV0aGVybmV0IGFuZCB3YW50 IHRvIGNoZWNrIGJlZm9yZSB0aGUgcGFja2V0IGdldHMgdG8gdGhlIElQIGhhbmRsZXIgeW91IGNv dWxkIHVzZSBhIHdlbGwta25vd24gSVAgYWRkcmVzcyBhbmQgcHVsbCB0aG9zZSBwYWNrZXRzIG9m ZiBmaXJzdCBhcyBhIHNwZWNpYWwgY2FzZS48bzpwPjwvbzpwPjwvcD4KPGRpdj4KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0i TXNvTm9ybWFsIj4tIFN0ZXdhcnQ8bzpwPjwvbzpwPjwvcD4KPGRpdj4KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+CjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+ CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlbnQgZnJvbSBteSBpUGFkPG86cD48L286cD48L3A+Cjwv ZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPjxicj4KT24gMTEgSnVuIDIwMTksIGF0IDA4OjA0LCBTY2h3YXJ6IEFsYnJlY2h0IChFVEFT L0VTWTEpICZsdDs8YSBocmVmPSJtYWlsdG86QWxicmVjaHQuU2Nod2FyekBldGFzLmNvbSI+QWxi cmVjaHQuU2Nod2FyekBldGFzLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPgo8L2Rp dj4KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyBTYXNo YSw8L3NwYW4+PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2Vy aWYiPnVuZGVyc3Rvb2QuIFRoZXJlIGFyZSB0d28gZGlmZmVyZW50IHR5cGVzIG9mIHNlcnZlZCB1 c2VyIGluc3RhbmNlcyAocm91dGluZyBsb2dpYyB2ZXJzdXMgZmF1bHQvYWxhcm0gbWFuYWdlbWVu dCBvZiBvcGVyYXRvcnMpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5TYW50b3NoLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZuYnNwOyAmbmJzcDsgSnVzdCBjdXJpb3VzIHRvIGtu b3cgd2h5IGRvIHlvdSBoYXZlIHRoaXMgdXNlIGNhc2U/IEkgbWVhbiB3aHkgbm90IHVzZSBDRk0g aXRzZWxmPyZuYnNwOzxvOnA+PC9vOnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmIj53ZSBhcmUgY29uc2lkZXJpbmcgYSB1c2UgY2FzZSBvZgo8L3NwYW4+PG86cD48L286 cD48L3A+CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4 LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi PmEgcHJpdmF0ZSBuZXR3b3JrIGRvbWFpbiwKPC9zcGFuPjxvOnA+PC9vOnA+PC9wPgo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlz dDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKPC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj53aXRoIHJvdWdobHkg ODAlIEV0aGVybmV0IGFuZCAyMCUgbm9uLUV0aGVybmV0IGF0IGxpbmsgbGF5ZXIsIGFuZAo8L3Nw YW4+PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4 dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRM aXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+My48c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOwo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPmEgdHJhZmZpYyBtaXggb2YgSVAtYmFzZWQgYW5kIElQLWxlc3MgYXBwbGlj YXRpb25zLAo8L3NwYW4+PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+PCFb aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+NC48c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9IkxU UiI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPnByaW1hcmlseSBzdGF0aWMgcm91dGluZyw8L3NwYW4+ PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPmFuZCB3 aXRoIHRoZSBvYmplY3RpdmUgb2Y8L3NwYW4+PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZl bDEgbGZvMiI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+NS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPmNvbnRpbnVpdHkgc3VwZXJ2aXNp b24gKGF0IGxpbmsgc2VnbWVudHMpIGFuZDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0Omww IGxldmVsMSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj42LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Cjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+Y29ubmVjdGl2aXR5IHN1 cGVydmlzaW9uIChlbmQtdG8tZW5kLCBhdCBuZXR3b3JrIHJvdXRlcykuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPklFRUUgQ0ZNIG1pZ2h0IGJlIHRoZW4gdGhlIGNhbmRpZGF0ZSBm b3IgKDUpIGFuZCBFdGhlcm5ldCwgYnV0IG5vdCB0aGUgbm9uLUV0aGVybmV0IGxpbmsgbGF5ZXIg dGVjaG5vbG9naWVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SUVURiBCRkQgd291bGQgYmUgdGhlIGNhbmRpZGF0 ZSBmb3IgKDYpLCBmb3IgSVAsIGJ1dCBhbHNvIG5vbi1JUC1iYXNlZCBlbmQtdG8tZW5kIHRyYW5z cG9ydCBjb25uZWN0aW9ucy48L3NwYW4+PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VGhlIGVu Z2luZWVyaW5nIGdvYWwgd291bGQgYmUgcHJlZmVyYWJseSBhIHNpbmdsZSBzdXBlcnZpc2lvbiB0 ZWNobm9sb2d5IChmb3IgNSBhbmQgNiwgZm9yIElQIGFuZCBub24tSVAsIGZvciBFdGhlcm5ldCBh bmQgbm9uLUV0aGVybmV0IGxpbmsgbGV2ZWwgY29ubmVjdGlvbnMpLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+QW5k IHRoYXQgdGVjaG5vbG9neSBmb3IgdGhpcyBuZXR3b3JraW5nIHVzZSBjYXNlIG1pZ2h0IGJlIEJG RCwgcGFydGljdWxhcmlseSB3aGVuIHdlIGNvdWxkIGNvdmVyIHRoZSA4MCUgb2YgRXRoZXJuZXQg bGlua3MgYXMgd2VsbC48L3NwYW4+PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+UmVnYXJkcyw8 L3NwYW4+PG86cD48L286cD48L3A+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPkFsYnJlY2h0PGJyPgo8YnI+Cjxicj4KPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pgo8ZGl2Pgo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEFsZXhh bmRlciBWYWluc2h0ZWluICZsdDs8YSBocmVmPSJtYWlsdG86QWxleGFuZGVyLlZhaW5zaHRlaW5A ZWNpdGVsZS5jb20iPkFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPC9hPiZndDsKPGJy Pgo8Yj5TZW50OjwvYj4gMDggSnVuZSAyMDE5IDE0OjQ2PGJyPgo8Yj5Ubzo8L2I+IFNjaHdhcnog QWxicmVjaHQgKEVUQVMvRVNZMSkgJmx0OzxhIGhyZWY9Im1haWx0bzpBbGJyZWNodC5TY2h3YXJ6 QGV0YXMuY29tIj5BbGJyZWNodC5TY2h3YXJ6QGV0YXMuY29tPC9hPiZndDs8YnI+CjxiPkNjOjwv Yj4gPGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmciPnJ0Zy1iZmRAaWV0Zi5vcmc8L2E+ OyBTdGV3YXJ0IEJyeWFudCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZXdhcnQuYnJ5YW50QGdtYWls LmNvbSI+c3Rld2FydC5icnlhbnRAZ21haWwuY29tPC9hPiZndDs7IEplZmZyZXkgSGFhcyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmpoYWFzQHBmcmMub3JnIj5qaGFhc0BwZnJjLm9yZzwvYT4mZ3Q7PGJy Pgo8Yj5TdWJqZWN0OjwvYj4gUmU6IERpcmVjdCBCRkQgb3ZlciBFdGhlcm5ldD88L3NwYW4+PG86 cD48L286cD48L3A+CjwvZGl2Pgo8L2Rpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPkFsYnJlY2h0LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4KPC9kaXY+CjxkaXY+Cjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+SSBndWVzcyB5b3UgYXJlIHJpZ2h0IGFuZCBpdCBpcyBpbmRlZWQg bWFpbmx5IHRoZSB0ZWNobm9sb2d5IG93bmVyc2hpcCBpc3N1ZS48L3NwYW4+PG86cD48L286cD48 L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRvIHRoZSBiZXN0IG9mIG15IHJl Y29sbGVjdGlvbiB0aGUgQkZEIFdHIGhzcyB0cmllZCB0byBjb29wZXJhdGUgd2l0aCBJRUVFIDgw Mi4xLCBidXQgdGhlc2UgYXR0ZW1wdHMgaGF2ZSBmYWlsZWQuCjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+QXQgdGhlIHNhbWUgdGltZSBJIHRo aW5rIHRoZXJlIGlzIGEgZGlmZmVyZW5jZSBpbiB0aGUgb3ZlcmFsbCBhdHRpdHVkZSB3aXRoIHJl Z2FyZCB0byBPQU0gYmV0d2VlbiBJRVRGIGFuZCBJRUVFIDgwMi4xLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VGhlIGZvcm1lciBzZWVtcyB0 byBjb25zaWRlciBPQU0gc2Vzc2lvbnMgKGFuZCwgc3BlY2lmaWNhbGx5LCBCRkQpIGFzICZxdW90 O2hlbHBlcnMmcXVvdDsgZm9yIHNvbWUgb3RoZXIgcHJvdG9jb2xzIChlLmcuLCByb3V0aW5nKTog dGhlc2Ugc2Vzc2lvbnMKIGFyZSB1c3VhbGx5IHNldCB1cCB3aGVuIHRoZSAmcXVvdDtjbGllbnQg cHJvdG9jb2wmcXVvdDsgcGVlcnMgZXN0YWJsaXNoIGEgcGVlcmluZyByZWxhdGlvbnNoaXAsIGFu ZCBmYWlsdXJlIG9mIHRoZSBPQU0gc2Vzc2lvbiBpcyBhbiBpbmRpY2F0aW9uIG9mIGZhaWx1cmUg b2YgdGhlIHBlZXJpbmcgcmVsYXRpb25zaGlwIG9mIHRoZSBjbGllbnQgcHJvdG9jb2wgKHNlZSBS RkMgNTg4MiBmb3IgZGV0YWlscykuJm5ic3A7Cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4KPC9kaXY+ CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VGhlIGxhdHRlciBzZWVtcyB0byB0cmVhdCBPQU0g bWFpbmx5IGFzIHByb3ZpZGluZyBpbmRpY2F0aW9ucyAoYWxhcm1zKSB0byB0aGUgb3BlcmF0b3Iu Cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ TXkgMmMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPGRpdj4KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VGh1bWIgdHlwZWQgYnkgU2Fz aGEgVmFpbnNodGVpbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4KPC9kaXY+CjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4KPC9kaXY+CjxkaXY+CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPkZyb206IFNjaHdhcnogQWxicmVjaHQgKEVUQVMvRVNZMSkKPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+U2VudDogU2F0dXJkYXksIEp1bmUgOCwgMTE6NDcKPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+U3ViamVjdDogUkU6IERpcmVjdCBCRkQgb3ZlciBFdGhlcm5ldD8KPC9z cGFuPjxvOnA+PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VG86IEplZmZyZXkgSGFhcywgU3Rld2FydCBCcnlhbnQK PC9zcGFuPjxvOnA+PC9vOnA+PC9wPgo8L2Rpdj4KPGRpdj4KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5D YzogQWxleGFuZGVyIFZhaW5zaHRlaW4sCjxhIGhyZWY9Im1haWx0bzpydGctYmZkQGlldGYub3Jn Ij5ydGctYmZkQGlldGYub3JnPC9hPiA8YnI+Cjxicj4KPGJyPgo8L3NwYW4+PG86cD48L286cD48 L3A+CjwvZGl2Pgo8ZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRoYW5rcyBTYXNoYSwgSmVmZiAm YW1wOyBTdGV3YXJ0IGZvciB5b3VyIHJlcGx5ISBPSywgdW5kZXJzdG9vZCwgbW9yZSBhIHRlY2hu b2xvZ3kgb3duZXJzaGlwIHF1ZXN0aW9uIChJRUVFIDgwMiB2cyBJRVRGKSB0aGFuIGEgdGVjaG5p Y2FsCiBpc3N1ZS4gUnVubmluZyBCRkQgZGlyZWN0bHkgb3ZlciBFdGhlcm5ldCB3b3VsZCAoYXQg bGVhc3QpIHJlcXVpcmUgdG8gYXNzaWduIGFuIEV0aGVydHlwZSBjb2RlcG9pbnQgKDxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2llZWUtODAyLW51bWJlcnMvaWVlZS04 MDItbnVtYmVycy54bWwiPmh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2llZWUtODAy LW51bWJlcnMvaWVlZS04MDItbnVtYmVycy54bWw8L2E+CiApIGZvciBCRkQuIEJ1dCBCRkQtb3Zl ci1FdGhlcm5ldCBzZWVtcyB0byBiZSB0aGVuIGluIGRpcmVjdCBjb21wZXRpdGlvbiB3aXRoIHRo ZSBJRUVFIDgwMi4xYWcgZGVmaW5lZCBPQU0gY2FwYWJpbGl0aWVzIChndWVzcyB0aGUgQ29ubmVj dGl2aXR5IEZhdWx0IE1hbmFnZW1lbnQgcHJvdG9jb2xzKSwgaS5lLiwgdGhlIElFRUUgQ29udGlu dWl0eSBDaGVjayBwcm90b2NvbC4gTXkgcm91Z2ggdW5kZXJzdGFuZGluZy4gVGhhbmtzIGFnYWlu ISBBbGJyZWNodAogLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gRnJvbTogSmVmZnJleSBIYWFz IFNlbnQ6IDA3IEp1bmUgMjAxOSAxMzo1NiBUbzogU3Rld2FydCBCcnlhbnQgQ2M6IEFsZXhhbmRl ciBWYWluc2h0ZWluIDsgU2Nod2FyeiBBbGJyZWNodCAoRVRBUy9FU1kxKSA7CjxhIGhyZWY9Im1h aWx0bzpSdGctYmZkQGlldGYub3JnIj5SdGctYmZkQGlldGYub3JnPC9hPiBTdWJqZWN0OiBSZTog RGlyZWN0IEJGRCBvdmVyIEV0aGVybmV0PyBPbiBGcmksIEp1biAwNywgMjAxOSBhdCAxMjoyMDoz MFBNICYjNDM7MDEwMCwgU3Rld2FydCBCcnlhbnQgd3JvdGU6ICZndDsgJmd0OyAmIzQzOzEgJmd0 OyAmZ3Q7IEhvd2V2ZXIgaWYgeW91IHJlYWxseSB3YW50IEJGRCwgeW91IG9ubHkgbmVlZCBhIGxp Z2h0d2VpZ2h0IElQICZndDsgaW1wbGVtZW50YXRpb24gdG8gY2FycnkKIGl0LiBEdXJpbmcgdGhl IHdvcmsgZm9yIEJGRCBmb3IgTEFHLCBJRVRGIGFscmVhZHkgd2VudCBhIGJpdCB0b28gY2xvc2Ug dG8gc3RlcHBpbmcgaW50byBJRUVFIHRlcnJpdG9yeS4gUmF3IEJGRCBvdmVyIEV0aGVybmV0IHdv dWxkIG5vdCBiZSByZWNlaXZlZCB2ZXJ5IHdlbGwgYnkgdGhhdCBvcmdhbml6YXRpb24sIEkgdGhp bmsuIChFdmVuIGlmIGl0J2QgYmUgdHJpdmlhbCB0byBzcGVjaWZ5LikgLS0gSmVmZgo8L3NwYW4+ PG86cD48L286cD48L3A+CjwvZGl2Pgo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+Cl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxicj4KPGJyPgpUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0 aGUgcmVjaXBpZW50IG9ubHkgYW5kIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzCjxicj4K Q09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8gRUNJIFRlbGVjb20u IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMKPGJyPgp0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBs ZWFzZSBpbmZvcm0gdXMgYnkgZS1tYWlsLCBwaG9uZSBvciBmYXgsIGFuZCB0aGVuIGRlbGV0ZSB0 aGUgb3JpZ2luYWwKPGJyPgphbmQgYWxsIGNvcGllcyB0aGVyZW9mLjxicj4KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPG86cD48L286cD48L3A+CjwvZGl2Pgo8L2Jsb2NrcXVvdGU+CjwvZGl2Pgo8L2Rpdj4K PC9kaXY+CjwvZGl2Pgo8YnIgY2xlYXI9ImJvdGgiPgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+CjxC Uj4KVGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBmb3IgdGhlIHJlY2lwaWVudCBvbmx5 IGFuZCBjb250YWlucyBpbmZvcm1hdGlvbiB3aGljaCBpcyA8QlI+CkNPTkZJREVOVElBTCBhbmQg d2hpY2ggbWF5IGJlIHByb3ByaWV0YXJ5IHRvIEVDSSBUZWxlY29tLiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIDxCUj4KdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW5mb3JtIHVzIGJ5 IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIDxCUj4K YW5kIGFsbCBjb3BpZXMgdGhlcmVvZi48QlI+Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxCUj4KPC9ib2R5 Pgo8L2h0bWw+Cgo= --_000_AM0PR03MB38283363BD4F738478E650849DED0AM0PR03MB3828eurp_-- From nobody Tue Jun 11 14:22:07 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24707120059 for ; Tue, 11 Jun 2019 14:22:06 -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, SPF_PASS=-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 bEfPq7yBPHL3 for ; Tue, 11 Jun 2019 14:22:04 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6F81A120018 for ; Tue, 11 Jun 2019 14:22:04 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A23C91E2F1; Tue, 11 Jun 2019 17:23:05 -0400 (EDT) Date: Tue, 11 Jun 2019 17:23:05 -0400 From: Jeffrey Haas To: Alexander Vainshtein Cc: "Schwarz Albrecht (ETAS/ESY1)" , "rtg-bfd@ietf.org" , Stewart Bryant Subject: Re: Direct BFD over Ethernet? Message-ID: <20190611212305.GB12590@pfrc.org> References: <20190607115617.GC15506@pfrc.org> <7a42f74e46484476a8b642a29649a471@etas.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2019 21:22:06 -0000 On Sat, Jun 08, 2019 at 12:45:50PM +0000, Alexander Vainshtein wrote: > To the best of my recollection the BFD WG hss tried to cooperate with IEEE 802.1, but these attempts have failed. I think that's a mis-characterization. Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces https://tools.ietf.org/html/rfc7130 IEEE wasn't really interested in having BFD running native. Much of this has to do with the OAM and layering models that IEEE has for Ethernet. And yet, IETF was getting push to solve at least a problem relating to layer 3 issues for traffic balancing over LAGs. That was somewhat out of the realm of IEEE. So, while it took us a while to frame the problem, we eventually found a place where we were able to solve our respective problems without stepping too much on organizational and layer-wise boundaries. > At the same time I think there is a difference in the overall attitude with regard to OAM between IETF and IEEE 802.1. I think I would state this as "IETF doesn't have a useful OAM model". Many people would prefer us to have one, and see BFD as a useful component for it. However, that's bigger work than just BFD. -- Jeff From nobody Wed Jun 12 07:16:26 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E0612024A for ; Wed, 12 Jun 2019 07:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.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 0w6YPKyh8iaM for ; Wed, 12 Jun 2019 07:16:16 -0700 (PDT) Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.131]) (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 6FB161201D5 for ; Wed, 12 Jun 2019 07:16:16 -0700 (PDT) Received: from [46.226.53.55] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta.az-c.eu-west-1.aws.symcld.net id 62/2E-09115-D29010D5; Wed, 12 Jun 2019 14:16:13 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSf0wTZxjH+95dy0E4dhQZD/VHtCoy4DrKELs /0MW/Oh3RZVuywZrtoGfbpLSsLSm4xBCyZVTHBDTNIDiUMaLCzGS2k3QIg4nIZOVHJY7RyqRI wZjFKtEZBuv10G1/3ed9v9/neb7v5SFxaY9ERnIVNs5iYo1ySRyR+9KTbQwTizTZrlPrVe0Bt ar3p/ti1cNlN1INz7CvEeoTzj5M3d3kj1G3tf2FqSdqXeKDRKHYYCo2V3wo1j+6PB1TtkpXTA U+xarQ39RRFEcS9Lc4DNcGMf4gpesxcFd14sLhNoJQ/UhEiSUldD50dfglPK+jt0DLqiPKON2 AwDdJ8ZxEp8H4jZBY8OyAYNU8JnARhBur0VFERsZth+7jFfw1RWsg2DePhFmrGPzS4yB4IZZW wFLXg2gtol+Ex8OdmDArBaaCLVEGmoa2H724wMmwMLsiFvzFcHvuDBLut8CXgeYYgTfCeMuxa AagC8DlqBRwK1wKafgIQM8iOHn12lppBlx8HBQLLIOhsatrbAT3nRpC4DT4YdK7FmcDuEYcuN DonAR8tZ5oNildAkPND9cKNsH52j8IwTSKQ5P7Ol6Hspr+8zaBs+C0JywROBPaz9zDm6I/LBG uNwaJ04g4j3YVWww6va2UNRgZZXY2o1TmMDmRb16egj3MlCi4csbOWW2MUsHarQprZWmJUasw cbYuFNkkbdnQ3suo4+d7in6USmLyZCqtV6SRJhSbtZV61qr/wFJu5Kz9aANJyoF6GoM00kQLp +MqDhmMkX18JgMZL19HUbxMWcvYUqtBJ0jDiCHrFk614lLCZDZxshRqljfRvElfbnre4tlWj6 ONsiQKiUQiaXwZZyk12P6vL6IUEsmTKDPfJd5gsj2ftBgJgUVCvO1ZeT8Swsb+K8mqsN6p8N6 E0cKljFsNhPV3jbtBPHLDpT5hVzcsveBttefEfXIoWZTbk7351/dcPXbD/ievjmVlOpl5zcv5 yuMzBZuOqD733jE6/QcWd3/nWdlv6NyZ/Erxub708DJzaeTCriMLE42NJ78JffGZ97eiVFfHu /cXKuem5y/YugvO5u28UuAXpSYdjmWZxfSa9rvNX9fM79663nTgzWuvuwf/XMkx4lUPYvbkT0 L5V7655G0zRWa/JRzuLUn/KPdmHO2o2ex7FEITzjeWBwcsA87u6u/HtIXTe3SDPs+czjdz09v p3N5q6N/nuFW0Y0R39+PMmdErdU9n6wfy30oMBC4mvKOtPiYnrHpWmYFbrOw/mudoRVAEAAA= X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-11.tower-307.messagelabs.com!1560348969!9734111!1 X-Originating-IP: [52.41.248.36] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.31.5; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 24140 invoked from network); 12 Jun 2019 14:16:12 -0000 Received: from us-west-2a.mta.dlp.protect.symantec.com (HELO EUR04-VI1-obe.outbound.protection.outlook.com) (52.41.248.36) by server-11.tower-307.messagelabs.com with AES256-SHA256 encrypted SMTP; 12 Jun 2019 14:16:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ECI365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7HF5LNnAgu0cSsPQIXAqcp2T+27eLM8t/Oh9qjWoeJA=; b=Gdt/u/U166dxC+3mq43g5ht18hfBBsKo3AJTe9XElLdHdhktX/whg9ofoTxzfm+qk/QOzRJEg/t5J/ed38jrnsxUEWylDpb+YAhlhhji7fNIoPqzDUx80Py5O4yjFdmCzh7rxwzKOnYx1Os0grqx6NzRU1kNGrg7tSWbUcBYmBk= Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.159) by AM0PR03MB4689.eurprd03.prod.outlook.com (20.177.41.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.11; Wed, 12 Jun 2019 14:16:08 +0000 Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::91f3:6bd1:1631:9b4a]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::91f3:6bd1:1631:9b4a%6]) with mapi id 15.20.1965.017; Wed, 12 Jun 2019 14:16:08 +0000 From: Alexander Vainshtein To: Jeffrey Haas CC: "Schwarz Albrecht (ETAS/ESY1)" , "rtg-bfd@ietf.org" , Stewart Bryant Subject: RE: Direct BFD over Ethernet? Thread-Topic: Direct BFD over Ethernet? Thread-Index: AdUdHwIY3QLc2dE1SwCr012LbinkaAAAvtBvAABBlQAAAT/tgAArr1KAAAfpV5kAqV1XgAAjL4Lg Date: Wed, 12 Jun 2019 14:16:08 +0000 Message-ID: References: <20190607115617.GC15506@pfrc.org> <7a42f74e46484476a8b642a29649a471@etas.com> <20190611212305.GB12590@pfrc.org> In-Reply-To: <20190611212305.GB12590@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e022da39-93b9-4e11-de4b-08d6ef4083ce x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM0PR03MB4689; x-ms-traffictypediagnostic: AM0PR03MB4689: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0066D63CE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(39860400002)(396003)(366004)(346002)(376002)(13464003)(51444003)(199004)(189003)(72206003)(229853002)(3480700005)(478600001)(86362001)(966005)(2906002)(54906003)(316002)(8936002)(71190400001)(14454004)(71200400001)(6116002)(3846002)(66476007)(4326008)(6916009)(6436002)(66946007)(76116006)(73956011)(52536014)(6246003)(6306002)(9686003)(66556008)(64756008)(66446008)(55016002)(53936002)(5660300002)(11346002)(256004)(476003)(486006)(25786009)(446003)(68736007)(33656002)(186003)(74316002)(305945005)(66066001)(7696005)(99286004)(6506007)(26005)(102836004)(7736002)(81166006)(8676002)(53546011)(81156014)(76176011); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB4689; H:AM0PR03MB3828.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: hBQDAlq0eZgTOFd2SKQrqpB5zPC/YIL4kNbgOuCbetjBeBr4MOiYk321/FL13xaywDKrB7ttUxF5VRuTSvKm5UmmJa2XhqlWiOPMvpTMt+hiCT2T9Hz4HKOEREFJWRNfs/8spbjx6sl0xqRGZe8LdBBuJXf5WF+iwoIEBLXJutHMbn1wwavHpnCzcutL2C7UQ69VHv6M6aD3aYocVLI+Dmlp/j8Exemgsp4hjkPqChj3oQj4YHwWVjMRx9Nt8FJPTB3Lv+KZ0rjAzIvmuFtYtvhdlL/hbvAcYJ4MgMbn5aVLzu5dPreb7WQuCVeq/ud0dgRyGJSZFf/j5oMyUp6/MilEQcl8MJBjnWAmcuJJxHvH1xcYyNres4DKyvMpELgkb7gpONbTwW5uv64xvAN7LRBOMDq/0ysKME2hJZ/H0P4= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: e022da39-93b9-4e11-de4b-08d6ef4083ce X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2019 14:16:08.5143 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: alexvain@ecitele.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB4689 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2019 14:16:25 -0000 Jeffrey, Lots of thanks for a prompt response. I tend to agree with your statement that " IETF doesn't have a useful OAM = model". But I would add that, in spite of that, IETF has a rich set of OAM tools t= hat are widely deployed and serve the real needs of the IETF community rea= sonably well, and from time to time adds to this set when new issues are i= dentified. Whether a useful OAM model is really needed in his situation, or not, is, = IMHO, a matter of personal preferences. "If it is not broken we don't fix it". My 2c, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: Jeffrey Haas =20 Sent: Wednesday, June 12, 2019 12:23 AM To: Alexander Vainshtein Cc: Schwarz Albrecht (ETAS/ESY1) ; rtg-bfd@ietf= .org; Stewart Bryant Subject: Re: Direct BFD over Ethernet? On Sat, Jun 08, 2019 at 12:45:50PM +0000, Alexander Vainshtein wrote: > To the best of my recollection the BFD WG hss tried to cooperate with IE= EE 802.1, but these attempts have failed. I think that's a mis-characterization. Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) I= nterfaces https://tools.ietf.org/html/rfc7130 IEEE wasn't really interested in having BFD running native. Much of this = has to do with the OAM and layering models that IEEE has for Ethernet. And yet, IETF was getting push to solve at least a problem relating to lay= er 3 issues for traffic balancing over LAGs. That was somewhat out of the= realm of IEEE. So, while it took us a while to frame the problem, we eventually found a p= lace where we were able to solve our respective problems without stepping = too much on organizational and layer-wise boundaries. > At the same time I think there is a difference in the overall attitude w= ith regard to OAM between IETF and IEEE 802.1. I think I would state this as "IETF doesn't have a useful OAM model". Man= y people would prefer us to have one,=20and see BFD as a useful component = for it. However, that's bigger work than just BFD. -- Jeff __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ From nobody Wed Jun 12 07:29:47 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A6B12011B for ; Wed, 12 Jun 2019 07:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 zJH107NfV0Gu for ; Wed, 12 Jun 2019 07:29:42 -0700 (PDT) Received: from de-out1.bosch-org.com (de-out1.bosch-org.com [139.15.230.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FD331200A4 for ; Wed, 12 Jun 2019 07:29:35 -0700 (PDT) Received: from fe0vm1650.rbesz01.com (unknown [139.15.230.188]) by fe0vms0187.rbdmz01.com (Postfix) with ESMTPS id 45P8QN3Fy9z1XLDR1; Wed, 12 Jun 2019 16:29:32 +0200 (CEST) Received: from si0vm02576.rbesz01.com (unknown [10.58.172.176]) by fe0vm1650.rbesz01.com (Postfix) with ESMTPS id 45P8QN2vryz1Qg; Wed, 12 Jun 2019 16:29:32 +0200 (CEST) X-AuditID: 0a3aad0d-173ff700000036fe-3e-5d010c4c3334 Received: from fe0vm1651.rbesz01.com ( [10.58.173.29]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by si0vm02576.rbesz01.com (SMG Outbound) with SMTP id 60.ED.14078.C4C010D5; Wed, 12 Jun 2019 16:29:32 +0200 (CEST) Received: from SI-MBX2055.de.bosch.com (unknown [10.3.230.149]) by fe0vm1651.rbesz01.com (Postfix) with ESMTPS id 45P8QN0BZJznqf; Wed, 12 Jun 2019 16:29:32 +0200 (CEST) Received: from SI-MBX2054.de.bosch.com (10.3.230.148) by SI-MBX2055.de.bosch.com (10.3.230.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Wed, 12 Jun 2019 16:29:31 +0200 Received: from SI-MBX2054.de.bosch.com ([fe80::187:74e0:f8c8:c9b1]) by SI-MBX2054.de.bosch.com ([fe80::187:74e0:f8c8:c9b1%4]) with mapi id 15.01.1713.006; Wed, 12 Jun 2019 16:29:31 +0200 From: "Schwarz Albrecht (ETAS/ESY1)" To: Alexander Vainshtein , Jeffrey Haas CC: "rtg-bfd@ietf.org" , Stewart Bryant Subject: RE: Direct BFD over Ethernet? Thread-Topic: Direct BFD over Ethernet? Thread-Index: AdUdHwIY3QLc2dE1SwCr012LbinkaAAAvtBv///ghQCAAAoAgP/+hUYwgAMa5gCABUeEgIABGwoA///cAzA= Date: Wed, 12 Jun 2019 14:29:31 +0000 Message-ID: References: <20190607115617.GC15506@pfrc.org> <7a42f74e46484476a8b642a29649a471@etas.com> <20190611212305.GB12590@pfrc.org> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.35.83.170] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA21Tb0wTdxjmd3dtr4Vjx1HouxYCuSgujDFkOprNEb+NLSb6wZi40G2HHLSR ttgrDPywFJFISERCRGiFyZ+OOcGJiJUKg9jINglhE5J1dOokkjCFiRvsD8yUXTmw/bAvl+ee P+/7+z2XI3FmgNSSJoudt1m4ElauIlRvXU5+bV8MMmR916XSN11/hutHb/0m0y8/9yD9+ENu L5HXH/wW5Xld9xV5bvcqljd9+rrsAPGBak8hX2Iq522v536sMgbOt8lLW3UVrd1LMgdqS6xD ShLoXfD8brOiDqlIhnZiUH92TBESGLoXwZqbloQlBL/fDGDSywiCyUt+ecglp/fCnR+rN7Ca zofVlpaNNE4fgoWOhg0+nk6DqYlfZZJnB8w55jEJF8DVgJeoQyRJ0NthoTMjBCk6BwZ6dkmr /Dh8dWqaCNmVtAFWhq/gIYzoZOjr+x6XVmkgMHcBk25Dg3tY4oFOgMePgjIJp4J/fJ6Q/BnQ PvSHXMKvQnfHwoafouPgjnOOaEAaV8RYV0TEFRFxRUTaEXEJJQqmrHJzVvbunDczbQW8cDxr Z+YRq7kfSR+QGkSTfxX5EE0iNoaKkyMDI+PKhUqzD+0mMTaBShuNMjCxBdbCSiMnGD+ylZXw Aqulkn54P5+Jf0ELZQVmkyCYrBYfAhJn1VT2UTFHFXKVx3mbVYr5kI4kWA1VTO7PZ+hizs4f 5flS3ralvk2SLFDz0eIZ4mx8MV9RZCqxb8lsMoWioqKYxEglci1GKn3oDTJG3L0tNIISSjmz YCrejL8sxZktNhwdR++RDY/bOnHy1thnnThDWKwWXquhDoWm0CG/sczy4hzaJGqxaj2fSYgQ wrOeoBkkNhlPvasSwzHi3xI+AVC6UGlxm2Q4lP25mKE9DLSvncFg4sQoBj1Tqxi4/vwFh8GT szi0+N0EnFx4QMB6l1sG9cF/ZBBs7JDD8vSwHC42r8th5uGAAlpmvQrw1i4roPbeUyU0/t0a DTO9NbFw4Rvx4RmYegkmGhwMBL5sZODp0H0GvBfvqeHmv+uJ8KCvVgODK26AnxZ7ATq7bgPM Dq1poWelWwdn6vy6J2K9mFjvwaFgvlivnbP/T72bbPh2WgfaNkRXRZO3y8fSPz19qvuKp73p xitFX/QmVfXnnk8ZUVeeKwhU/zxCnW2t3z55znHMuye39Jr6ampTSlzGJzrntQpiMaemqebD sh13n71zLD0Td6bcaN+Hj3jYg40nfLF2trpZX3QgdqA71ZcaiymP9HLGoCnta4NzbMq9NOw9 /IglBCO3Mx23Cdx/fS0c3scEAAA= Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2019 14:29:46 -0000 Thanks again all for recommendations and background information. With regards to RFC 7130: > Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) = Interfaces Actually, I was thinking about a group size of one ("whereas the normal LAG= is > 1") to emulate BFD over a single physical Ethernet link, - something = like a dedicated "BFD-over-LAG protocol profile". However, didn't investigate so far the overhead. Regards, Albrecht -----Original Message----- From: Alexander Vainshtein =20 Sent: 12 June 2019 16:16 To: Jeffrey Haas Cc: Schwarz Albrecht (ETAS/ESY1) ; rtg-bfd@ietf.= org; Stewart Bryant Subject: RE: Direct BFD over Ethernet? Jeffrey, Lots of thanks for a prompt response. I tend to agree with your statement that " IETF doesn't have a useful OAM m= odel". But I would add that, in spite of that, IETF has a rich set of OAM tools th= at are widely deployed and serve the real needs of the IETF community reaso= nably well, and from time to time adds to this set when new issues are iden= tified. Whether a useful OAM model is really needed in his situation, or not, is, I= MHO, a matter of personal preferences. "If it is not broken we don't fix it". My 2c, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: Jeffrey Haas Sent: Wednesday, June 12, 2019 12:23 AM To: Alexander Vainshtein Cc: Schwarz Albrecht (ETAS/ESY1) ; rtg-bfd@ietf.= org; Stewart Bryant Subject: Re: Direct BFD over Ethernet? On Sat, Jun 08, 2019 at 12:45:50PM +0000, Alexander Vainshtein wrote: > To the best of my recollection the BFD WG hss tried to cooperate with IEE= E 802.1, but these attempts have failed. I think that's a mis-characterization. Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) In= terfaces https://tools.ietf.org/html/rfc7130 IEEE wasn't really interested in having BFD running native. Much of this h= as to do with the OAM and layering models that IEEE has for Ethernet. And yet, IETF was getting push to solve at least a problem relating to laye= r 3 issues for traffic balancing over LAGs. That was somewhat out of the r= ealm of IEEE. So, while it took us a while to frame the problem, we eventually found a pl= ace where we were able to solve our respective problems without stepping to= o much on organizational and layer-wise boundaries. > At the same time I think there is a difference in the overall attitude wi= th regard to OAM between IETF and IEEE 802.1. I think I would state this as "IETF doesn't have a useful OAM model". Many= people would prefer us to have one, and see BFD as a useful component for = it. However, that's bigger work than just BFD. -- Jeff ___________________________________________________________________________ This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. ___________________________________________________________________________ From nobody Wed Jun 12 07:35:53 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8361201C7 for ; Wed, 12 Jun 2019 07:35:50 -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=G9Tzty1E; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=tyVmSgEs 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 Rmz_pk8RG6Fr for ; Wed, 12 Jun 2019 07:35:48 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09D61120121 for ; Wed, 12 Jun 2019 07:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5408; q=dns/txt; s=iport; t=1560350145; x=1561559745; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=NHdja0PY43u1yY3fiNl4TkbnsPJ/wN8QHMLULUGHl1Q=; b=G9Tzty1EWICaiuaqAQv2ckYaRWDMSDojPhsTMr21MS+bMyvihEK9hG77 kd17gjxmeHaOXpVFFObDCrSvFH5oDO/c6p2hCIv7E9DABZ76sg1YoELou tue+1vDZVWARTWKaqcYM3BfqnGz8eaQYPFk4XUHQc9Y9VOg6A6ZNbgnnK s=; IronPort-PHdr: =?us-ascii?q?9a23=3AFwWsgRaVPGLpUYGSuY1p3Yz/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gebRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavwdSU6Gc1EfFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIAACEDAFd/5JdJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBPVADalUgBAsoCoQLg0cDhFKKDYJXfohFjXC?= =?us-ascii?q?BLhSBEANUCQEBAQwBAR8OAgEBhEACF4ItIzQJDgEDAQEEAQECAQRtHAyFSgE?= =?us-ascii?q?BAQECARIREQwBATcBCwICAgEIEQQBAQECAiYCAgIUCxEVCAgCBAENBRQOgwA?= =?us-ascii?q?BgWoDDg8BDp1cAoE4iF9xgTGCeQEBBYUBDQuCDwMGBYEHKAGLXBeBQD+BESc?= =?us-ascii?q?fghc1PoIaRwEBA4ErARIBHwcQIQKCUDKCJotLEoJUhxOTRD4JAoIQhkeBOYd?= =?us-ascii?q?fg2sbgiWHAY4CjRiHF4FljU0CBAIEBQIOAQEFgU84Kj1xcBVlAYJBgg+DcIU?= =?us-ascii?q?UgSeEGHKBKYwfgSIBgSABAQ?= X-IronPort-AV: E=Sophos;i="5.63,366,1557187200"; d="scan'208";a="286673610" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Jun 2019 14:35:43 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x5CEZhfC003922 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 12 Jun 2019 14:35:43 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 12 Jun 2019 09:35:42 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 12 Jun 2019 09:35:42 -0500 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 12 Jun 2019 09:35:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NHdja0PY43u1yY3fiNl4TkbnsPJ/wN8QHMLULUGHl1Q=; b=tyVmSgEsBXscNUjCJnGd3XYkdXhX0qKNrJX9cFTBYQE3STfmHTYazngT9nj952dtA1G8Etd3V3CSbEexCtPpQZKJtcDoYKvTqK3j5CpHEV2DLNBGYgOkYC6q7NvtvXY7F3cXKyYIK8Lg1b9zJa34EZYWej1Pp2CSTjGp4FpPBZc= Received: from DM5PR1101MB2105.namprd11.prod.outlook.com (10.174.104.151) by DM5PR1101MB2329.namprd11.prod.outlook.com (10.173.169.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.11; Wed, 12 Jun 2019 14:35:41 +0000 Received: from DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::b57b:a39a:5e67:16c6]) by DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::b57b:a39a:5e67:16c6%2]) with mapi id 15.20.1987.010; Wed, 12 Jun 2019 14:35:41 +0000 From: "Reshad Rahman (rrahman)" To: "Schwarz Albrecht (ETAS/ESY1)" , "Alexander Vainshtein" , Jeffrey Haas CC: "rtg-bfd@ietf.org" Subject: Re: Direct BFD over Ethernet? Thread-Topic: Direct BFD over Ethernet? Thread-Index: AdUdHwIY3QLc2dE1SwCr012LbinkaAAAvtBvAABBlQAAAT/tgAArr1KAAAfpV5kAqV1XgAAjL4LgAACphoD//76ogA== Date: Wed, 12 Jun 2019 14:35:41 +0000 Message-ID: <48023C71-074E-4C8C-AFF4-CD1706FB0F54@cisco.com> References: <20190607115617.GC15506@pfrc.org> <7a42f74e46484476a8b642a29649a471@etas.com> <20190611212305.GB12590@pfrc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.6.190114 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; x-originating-ip: [173.38.117.82] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 50e2083e-be26-4f81-c705-08d6ef433ed6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR1101MB2329; x-ms-traffictypediagnostic: DM5PR1101MB2329: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0066D63CE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(136003)(366004)(346002)(39860400002)(199004)(51444003)(189003)(13464003)(6506007)(7736002)(36756003)(5660300002)(8676002)(81156014)(99286004)(64756008)(478600001)(6116002)(102836004)(3846002)(8936002)(81166006)(66446008)(66476007)(73956011)(76116006)(66946007)(305945005)(68736007)(91956017)(53546011)(110136005)(2906002)(26005)(966005)(71190400001)(71200400001)(66556008)(58126008)(66066001)(76176011)(11346002)(256004)(186003)(2616005)(486006)(53936002)(6246003)(4326008)(33656002)(446003)(6436002)(3480700005)(86362001)(14454004)(229853002)(25786009)(6486002)(6512007)(14444005)(316002)(476003)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1101MB2329; H:DM5PR1101MB2105.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: C5Oo0Bs2kVES803+RTSfNIpzenEWc+qE+iwUQtXVel7WRknIADrhOormysW4c361yvyh5t3h85bRhEe2dFIlxIwDc2bJRZ8IrIOj5aOWD/i0c6t19613UsKXYl1MZIyNmFZr/qwZH4uB49B5iffhuM/z6ztOMLiWrH1+FiIukVUG3p4Sr7hDhIsPlM+1CyDR1J4dlA418254z6gvDzHKaTcwGx/rAypsPJDAjlYrCYqqgA+9H3H795kCu6eYvj8Y5UFtcKBAawgg2ZNvNRWLt9ItJ8UVhmJ6vCGlEdRK44r624cFXRnHHBVoQxwXvnpsVwZ6oTXaIOOct4AcQWTzi1sV0VYH+ScIHbPTwuet4+d5UCW+unj/wlAyNtwl8GgCw9xDzV5vj1ZNaoYiqZ4t3M1VdPNJQ7xs4aSr1lX9GPg= Content-Type: text/plain; charset="utf-8" Content-ID: <8EF532C8E95E8A42A0574CB246C94079@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 50e2083e-be26-4f81-c705-08d6ef433ed6 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2019 14:35:41.4213 (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-CrossTenant-userprincipalname: rrahman@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2329 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.21, xch-aln-011.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2019 14:35:51 -0000 SGksDQoNClRoYXQgc2hvdWxkIHdvcmsuIEFyZSB5b3UgcmVmZXJyaW5nIHRvIHRoZSBlbmNhcHN1 bGF0aW9uIG92ZXJoZWFkPw0KDQpSZWdhcmRzLA0KUmVzaGFkLg0KDQrvu79PbiAyMDE5LTA2LTEy LCAxMDozMCBBTSwgIlJ0Zy1iZmQgb24gYmVoYWxmIG9mIFNjaHdhcnogQWxicmVjaHQgKEVUQVMv RVNZMSkiIDxydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIEFsYnJlY2h0LlNj aHdhcnpAZXRhcy5jb20+IHdyb3RlOg0KDQogICAgVGhhbmtzIGFnYWluIGFsbCBmb3IgcmVjb21t ZW5kYXRpb25zIGFuZCBiYWNrZ3JvdW5kIGluZm9ybWF0aW9uLg0KICAgIA0KICAgIFdpdGggcmVn YXJkcyB0byBSRkMgNzEzMDoNCiAgICA+IEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rp b24gKEJGRCkgb24gTGluayBBZ2dyZWdhdGlvbiBHcm91cCAoTEFHKSBJbnRlcmZhY2VzDQogICAg DQogICAgQWN0dWFsbHksIEkgd2FzIHRoaW5raW5nIGFib3V0IGEgZ3JvdXAgc2l6ZSBvZiBvbmUg KCJ3aGVyZWFzIHRoZSBub3JtYWwgTEFHIGlzID4gMSIpIHRvIGVtdWxhdGUgQkZEIG92ZXIgYSBz aW5nbGUgcGh5c2ljYWwgRXRoZXJuZXQgbGluaywgLSBzb21ldGhpbmcgbGlrZSBhIGRlZGljYXRl ZCAgIkJGRC1vdmVyLUxBRyBwcm90b2NvbCBwcm9maWxlIi4NCiAgICBIb3dldmVyLCBkaWRuJ3Qg aW52ZXN0aWdhdGUgc28gZmFyIHRoZSBvdmVyaGVhZC4NCiAgICANCiAgICBSZWdhcmRzLA0KICAg IEFsYnJlY2h0DQogICAgDQogICAgDQogICAgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAg ICBGcm9tOiBBbGV4YW5kZXIgVmFpbnNodGVpbiA8QWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVs ZS5jb20+IA0KICAgIFNlbnQ6IDEyIEp1bmUgMjAxOSAxNjoxNg0KICAgIFRvOiBKZWZmcmV5IEhh YXMgPGpoYWFzQHBmcmMub3JnPg0KICAgIENjOiBTY2h3YXJ6IEFsYnJlY2h0IChFVEFTL0VTWTEp IDxBbGJyZWNodC5TY2h3YXJ6QGV0YXMuY29tPjsgcnRnLWJmZEBpZXRmLm9yZzsgU3Rld2FydCBC cnlhbnQgPHN0ZXdhcnQuYnJ5YW50QGdtYWlsLmNvbT4NCiAgICBTdWJqZWN0OiBSRTogRGlyZWN0 IEJGRCBvdmVyIEV0aGVybmV0Pw0KICAgIA0KICAgIEplZmZyZXksDQogICAgTG90cyBvZiB0aGFu a3MgZm9yIGEgcHJvbXB0IHJlc3BvbnNlLg0KICAgIA0KICAgIEkgdGVuZCB0byBhZ3JlZSB3aXRo IHlvdXIgc3RhdGVtZW50IHRoYXQgIiBJRVRGIGRvZXNuJ3QgaGF2ZSBhIHVzZWZ1bCBPQU0gbW9k ZWwiLg0KICAgIEJ1dCBJIHdvdWxkIGFkZCB0aGF0LCBpbiBzcGl0ZSBvZiB0aGF0LCBJRVRGIGhh cyBhIHJpY2ggc2V0IG9mIE9BTSB0b29scyB0aGF0IGFyZSB3aWRlbHkgZGVwbG95ZWQgYW5kIHNl cnZlIHRoZSByZWFsIG5lZWRzIG9mIHRoZSBJRVRGIGNvbW11bml0eSByZWFzb25hYmx5IHdlbGws IGFuZCBmcm9tIHRpbWUgdG8gdGltZSBhZGRzIHRvIHRoaXMgc2V0IHdoZW4gbmV3IGlzc3VlcyBh cmUgaWRlbnRpZmllZC4NCiAgICANCiAgICBXaGV0aGVyIGEgdXNlZnVsIE9BTSBtb2RlbCBpcyBy ZWFsbHkgbmVlZGVkIGluIGhpcyBzaXR1YXRpb24sIG9yIG5vdCwgaXMsIElNSE8sIGEgbWF0dGVy IG9mIHBlcnNvbmFsIHByZWZlcmVuY2VzLg0KICAgIA0KICAgICJJZiBpdCBpcyBub3QgYnJva2Vu IHdlIGRvbid0IGZpeCBpdCIuDQogICAgDQogICAgTXkgMmMsDQogICAgU2FzaGENCiAgICANCiAg ICBPZmZpY2U6ICs5NzItMzkyNjYzMDINCiAgICBDZWxsOiAgICAgICs5NzItNTQ5MjY2MzAyDQog ICAgRW1haWw6ICAgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5jb20NCiAgICANCiAgICAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KICAgIEZyb206IEplZmZyZXkgSGFhcyA8amhhYXNA cGZyYy5vcmc+DQogICAgU2VudDogV2VkbmVzZGF5LCBKdW5lIDEyLCAyMDE5IDEyOjIzIEFNDQog ICAgVG86IEFsZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVpbkBlY2l0ZWxl LmNvbT4NCiAgICBDYzogU2Nod2FyeiBBbGJyZWNodCAoRVRBUy9FU1kxKSA8YWxicmVjaHQuc2No d2FyekBldGFzLmNvbT47IHJ0Zy1iZmRAaWV0Zi5vcmc7IFN0ZXdhcnQgQnJ5YW50IDxzdGV3YXJ0 LmJyeWFudEBnbWFpbC5jb20+DQogICAgU3ViamVjdDogUmU6IERpcmVjdCBCRkQgb3ZlciBFdGhl cm5ldD8NCiAgICANCiAgICBPbiBTYXQsIEp1biAwOCwgMjAxOSBhdCAxMjo0NTo1MFBNICswMDAw LCBBbGV4YW5kZXIgVmFpbnNodGVpbiB3cm90ZToNCiAgICA+IFRvIHRoZSBiZXN0IG9mIG15IHJl Y29sbGVjdGlvbiB0aGUgQkZEIFdHIGhzcyB0cmllZCB0byBjb29wZXJhdGUgd2l0aCBJRUVFIDgw Mi4xLCBidXQgdGhlc2UgYXR0ZW1wdHMgaGF2ZSBmYWlsZWQuDQogICAgDQogICAgSSB0aGluayB0 aGF0J3MgYSBtaXMtY2hhcmFjdGVyaXphdGlvbi4NCiAgICANCiAgICBCaWRpcmVjdGlvbmFsIEZv cndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpIG9uIExpbmsgQWdncmVnYXRpb24gR3JvdXAgKExBRykg SW50ZXJmYWNlcw0KICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3MTMwDQogICAg DQogICAgSUVFRSB3YXNuJ3QgcmVhbGx5IGludGVyZXN0ZWQgaW4gaGF2aW5nIEJGRCBydW5uaW5n IG5hdGl2ZS4gIE11Y2ggb2YgdGhpcyBoYXMgdG8gZG8gd2l0aCB0aGUgT0FNIGFuZCBsYXllcmlu ZyBtb2RlbHMgdGhhdCBJRUVFIGhhcyBmb3IgRXRoZXJuZXQuDQogICAgDQogICAgQW5kIHlldCwg SUVURiB3YXMgZ2V0dGluZyBwdXNoIHRvIHNvbHZlIGF0IGxlYXN0IGEgcHJvYmxlbSByZWxhdGlu ZyB0byBsYXllciAzIGlzc3VlcyBmb3IgdHJhZmZpYyBiYWxhbmNpbmcgb3ZlciBMQUdzLiAgVGhh dCB3YXMgc29tZXdoYXQgb3V0IG9mIHRoZSByZWFsbSBvZiBJRUVFLg0KICAgIA0KICAgIFNvLCB3 aGlsZSBpdCB0b29rIHVzIGEgd2hpbGUgdG8gZnJhbWUgdGhlIHByb2JsZW0sIHdlIGV2ZW50dWFs bHkgZm91bmQgYSBwbGFjZSB3aGVyZSB3ZSB3ZXJlIGFibGUgdG8gc29sdmUgb3VyIHJlc3BlY3Rp dmUgcHJvYmxlbXMgd2l0aG91dCBzdGVwcGluZyB0b28gbXVjaCBvbiBvcmdhbml6YXRpb25hbCBh bmQgbGF5ZXItd2lzZSBib3VuZGFyaWVzLg0KICAgIA0KICAgID4gQXQgdGhlIHNhbWUgdGltZSBJ IHRoaW5rIHRoZXJlIGlzIGEgZGlmZmVyZW5jZSBpbiB0aGUgb3ZlcmFsbCBhdHRpdHVkZSB3aXRo IHJlZ2FyZCB0byBPQU0gYmV0d2VlbiBJRVRGIGFuZCBJRUVFIDgwMi4xLg0KICAgIA0KICAgIEkg dGhpbmsgSSB3b3VsZCBzdGF0ZSB0aGlzIGFzICJJRVRGIGRvZXNuJ3QgaGF2ZSBhIHVzZWZ1bCBP QU0gbW9kZWwiLiAgTWFueSBwZW9wbGUgd291bGQgcHJlZmVyIHVzIHRvIGhhdmUgb25lLCBhbmQg c2VlIEJGRCBhcyBhIHVzZWZ1bCBjb21wb25lbnQgZm9yIGl0LiAgSG93ZXZlciwgdGhhdCdzIGJp Z2dlciB3b3JrIHRoYW4ganVzdCBCRkQuDQogICAgDQogICAgLS0gSmVmZg0KICAgIA0KICAgIF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KICAgIA0KICAgIFRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5k ZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBhbmQgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2gg aXMgQ09ORklERU5USUFMIGFuZCB3aGljaCBtYXkgYmUgcHJvcHJpZXRhcnkgdG8gRUNJIFRlbGVj b20uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVh c2UgaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhl IG9yaWdpbmFsIGFuZCBhbGwgY29waWVzIHRoZXJlb2YuDQogICAgX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQogICAgDQogICAgDQoNCg== From nobody Wed Jun 12 07:46:37 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05AD9120248 for ; Wed, 12 Jun 2019 07:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.691 X-Spam-Level: X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.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 dg5q7_s3aJ6v for ; Wed, 12 Jun 2019 07:46:30 -0700 (PDT) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.3]) (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 A2BE71201EC for ; Wed, 12 Jun 2019 07:46:02 -0700 (PDT) Received: from [85.158.142.101] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta.az-a.eu-central-1.aws.symcld.net id F1/8F-07021-720110D5; Wed, 12 Jun 2019 14:45:59 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKJsWRWlGSWpSXmKPExsViovlDRVddgDH W4P1MBYtl9zws9h98y2pxbUUru8XnP9sYHVg8pvzeyOoxedoBJo8lS34yeVzu3coawBLFmpmX lF+RwJpxbetd1oKXRhXdc3cyNjBOMepi5OJgEVjLLNE/7ywbiCMkMJFJ4vvU54wQzn1GiW2nH zN1MXJysAnYSmxafZcNxBYRyJM49+E8I4jNLOAh0XbkNDOILSygJnHpzAtWiBp1iScNz4F6OY DsfInm3dkgYRYBVYkz7UfYQWxegViJBYsvM0Hs2sAi8XH9W7BdnEC7rt/dwAJiMwqISXw/tYY JYpe4xK0n88FsCQEBiSV7zjND2KISLx//Y4WoT5K4/3QhI0RcUWLGvTnsELasxKX53VBxX4nm W5fZQW6TEFCW2PIiFiL8mFGiYTHUSC2Jxz8PQq2Skjhx8SgrhJ0jcaVxE1RcTeLGmw6oehmJr Wc7mUF+kRDYyiaxYskPsAYhgWSJE3M+s0AUyUms6n3IAlF0gVni/JNDTBMYdWYh+W0W0E3MAp oS63fpQ4QVJaZ0P2SfBQ4vQYmTM5+wLGBkWcVomVSUmZ5RkpuYmaNraGCga2horGuoa2hqqZd YpZuol1qqm5yaV1KUCJTVSywv1iuuzE3OSdHLSy3ZxAhMSymFjPN3MO4/8lrvEKMkB5OSKK/a foZYIb6k/JTKjMTijPii0pzU4kOMMhwcShK8u/gYY4UEi1LTUyvSMnOAKRImLcHBoyTC68EPl OYtLkjMLc5Mh0idYjTmmPBy7iJmjiNzly5iFmLJy89LlRLnfQoySQCkNKM0D24QLHVfYpSVEu ZlZGBgEOIpSC3KzSxBlX/FKM7BqCTMOwNkIU9mXgncvldApzABnRKy+18M0CkliQgpqQYmhwX zZ7QsCTr3z0Gc6+XT+fsXszHc6Wb4wZLD6Sitdt97d/u66jCZSbsncRlUC7hvrJq8hS9kmQZT aLzcfSnWY9UfN8ipSsxS7Pu1Ll9RYYHmvOBfgeJRB7kSr2Xv/CQv+730qs0s1k8XZSWvNVjYl 3StiWEuXZo3vWCVy6X+JsarL8wSirfJC1WEspi81+Bb08DapK5TH2ivHyK0pX2+VehJwYo53u 9vLzVqubaz32RmBqtO261HO9d8KPinotCz4LCfW30Dc8C+XSE/tgiY6jKs3z9jy6rNU6ae72R 4rLuseZbStj2vjcOfaYRovJn28I30P+6zjxMqMvJ0t7+ZkVr8KVp7t25eaFf7NWclluKMREMt 5qLiRAAZ7ZwmWAQAAA== X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-11.tower-226.messagelabs.com!1560350756!136756!1 X-Originating-IP: [52.41.248.36] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.43.9; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 1343 invoked from network); 12 Jun 2019 14:45:58 -0000 Received: from us-west-2a.mta.dlp.protect.symantec.com (HELO EUR03-AM5-obe.outbound.protection.outlook.com) (52.41.248.36) by server-11.tower-226.messagelabs.com with ECDHE-RSA-AES256-SHA384 encrypted SMTP; 12 Jun 2019 14:45:58 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ECI365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tW5MF0XifrRkf9irbkiJxk6hMK4yy5jqbbuXEFGtfJ0=; b=YLhVKEzdNDKUa2hBbF17daMQZ+Hi1YSVNUVv0/LA+gNDVOpz7h+5VHhlMnUXsa/Yt3QCH+CzE/V7Z2HY0wLhD9qm0A2gCfknItLhZ3EQK0g+Vfu6tr6+OXe/UBMSVz6uODqgi7Uf3brsW++J0LkXxcmWJtDyu5qQkW1syqrbsPQ= Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.159) by AM0PR03MB4738.eurprd03.prod.outlook.com (20.177.41.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1965.17; Wed, 12 Jun 2019 14:45:54 +0000 Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::91f3:6bd1:1631:9b4a]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::91f3:6bd1:1631:9b4a%6]) with mapi id 15.20.1965.017; Wed, 12 Jun 2019 14:45:54 +0000 From: Alexander Vainshtein To: "Schwarz Albrecht (ETAS/ESY1)" , "Reshad Rahman (rrahman)" CC: "rtg-bfd@ietf.org" , Jeffrey Haas Subject: RE: Direct BFD over Ethernet? Thread-Topic: Direct BFD over Ethernet? Thread-Index: AdUdHwIY3QLc2dE1SwCr012LbinkaAAAvtBvAABBlQAAAT/tgAArr1KAAAfpV5kAqV1XgAAjL4LgAACphoD//76ogP//u2Zg Date: Wed, 12 Jun 2019 14:45:54 +0000 Message-ID: References: <20190607115617.GC15506@pfrc.org> <7a42f74e46484476a8b642a29649a471@etas.com> <20190611212305.GB12590@pfrc.org> <48023C71-074E-4C8C-AFF4-CD1706FB0F54@cisco.com> In-Reply-To: <48023C71-074E-4C8C-AFF4-CD1706FB0F54@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9d247254-452d-4bcf-d9bd-08d6ef44ac5e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM0PR03MB4738; x-ms-traffictypediagnostic: AM0PR03MB4738: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0066D63CE6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(136003)(366004)(396003)(39860400002)(13464003)(199004)(189003)(51444003)(71190400001)(486006)(6246003)(11346002)(26005)(5660300002)(446003)(7696005)(53546011)(102836004)(6506007)(99286004)(71200400001)(68736007)(81156014)(8676002)(186003)(52536014)(14454004)(76176011)(229853002)(86362001)(3480700005)(6436002)(81166006)(8936002)(476003)(9686003)(7736002)(4326008)(6306002)(14444005)(966005)(256004)(66476007)(6116002)(72206003)(55016002)(74316002)(25786009)(54906003)(66066001)(64756008)(66556008)(3846002)(76116006)(110136005)(305945005)(316002)(66446008)(66946007)(53936002)(73956011)(33656002)(2906002)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB4738; H:AM0PR03MB3828.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: /mFLVzEbIJEs43Ppvg/CAuh4BXYaI6gPcs0EFd96wwCcCeI0t2l36eoGTONM/LDtirQjC9kIV+0ES0Jq1miC1LTzulmSfF6xERXndQWqmwAa1ffpaCbi5q/M8toqRY27taEXso9oXz4v0m6XC2g0DaemFq95ep4ms6CX84MUlSUFsSbKuJuVir18SAHAgE169e0DG/68H0IVooMnRx4SxWCFsoMqfWQI+PGQK4cM9i0RuwXkJKz7x4axCCGaRHzcgG7VuiOdnRyN97a8x90ETW2h2gLmdWdWKyj1T2420bFJ3CuZua44IXXRpaycT0p44c/CqAsOxLovDi4kOGRzJbcMcx3Rzt4j58USe1IA9gpvLoZRTWnsMOSC5D3HNxRw903sF32qMbBEupZkDSlOwG0DOHel6bikDvEs+l0MYBc= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9d247254-452d-4bcf-d9bd-08d6ef44ac5e X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2019 14:45:54.7316 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: alexvain@ecitele.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB4738 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2019 14:46:35 -0000 QWxicmVjaHQsIFJlc2hhZCBhbmQgYWxsLApJIGNvbmN1ciB3aXRoIFJlc2hhZCAtIGl0IHdpbGwg d29yayAoUkZDIDcxMzAgbmV2ZXIgc2F5cyBhbnl0aGluZyBhYm91dCB0aGUgbnVtYmVyIG9mIGxp bmtzIGluIHRoZSBMQUcpLgoKU3VjaCBhIHNlc3Npb24gd291bGQgc3RpbGwgdXNlIGVuY2Fwc3Vs YXRpb24gaW4gSVAvVURQIHdpdGggdGhlIFVEUCBkZXN0aW5hdGlvbiBwb3J0IHNldCB0byA2Nzg0 IGFuZCB0aGUgRGVzdGluYXRpb24gSVAgYWRkcmVzcyAiIHRoYXQgaXMgY29uZmlndXJlZCBvbiB0 aGUgcGVlciBzeXN0ZW0gYW5kIGNhbiBiZSByZWFjaGVkIHZpYSB0aGUgTEFHIGludGVyZmFjZSAi LiBJLmUuLCBzb21lIGxpZ2h0d2VpZ2h0IElQIGZ1bmN0aW9uYWxpdHkgd291bGQgYmUgc3RpbGwg cmVxdWlyZWQuCgpSZWdhcmRzLApTYXNoYQoKT2ZmaWNlOiArOTcyLTM5MjY2MzAyCkNlbGw6ICAg ICAgKzk3Mi01NDkyNjYzMDIKRW1haWw6ICAgQWxleGFuZGVyLlZhaW5zaHRlaW5AZWNpdGVsZS5j b20KCgotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQpGcm9tOiBSZXNoYWQgUmFobWFuIChycmFo bWFuKSA8cnJhaG1hbkBjaXNjby5jb20+IApTZW50OiBXZWRuZXNkYXksIEp1bmUgMTIsIDIwMTkg NTozNiBQTQpUbzogU2Nod2FyeiBBbGJyZWNodCAoRVRBUy9FU1kxKSA8QWxicmVjaHQuU2Nod2Fy ekBldGFzLmNvbT47IEFsZXhhbmRlciBWYWluc2h0ZWluIDxBbGV4YW5kZXIuVmFpbnNodGVpbkBl Y2l0ZWxlLmNvbT47IEplZmZyZXkgSGFhcyA8amhhYXNAcGZyYy5vcmc+CkNjOiBydGctYmZkQGll dGYub3JnClN1YmplY3Q6IFJlOiBEaXJlY3QgQkZEIG92ZXIgRXRoZXJuZXQ/CgpIaSwKClRoYXQg c2hvdWxkIHdvcmsuIEFyZSB5b3UgcmVmZXJyaW5nIHRvIHRoZSBlbmNhcHN1bGF0aW9uIG92ZXJo ZWFkPwoKUmVnYXJkcywKUmVzaGFkLgoK77u/T24gMjAxOS0wNi0xMiwgMTA6MzAgQU0sICJSdGct YmZkIG9uIGJlaGFsZiBvZiBTY2h3YXJ6IEFsYnJlY2h0IChFVEFTL0VTWTEpIiA8cnRnLWJmZC1i b3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBBbGJyZWNodC5TY2h3YXJ6QGV0YXMuY29tPiB3 cm90ZToKCiAgICBUaGFua3MgYWdhaW4gYWxsIGZvciByZWNvbW1lbmRhdGlvbnMgYW5kIGJhY2tn cm91bmQgaW5mb3JtYXRpb24uCiAgICAKICAgIFdpdGggcmVnYXJkcyB0byBSRkMgNzEzMDoKICAg ID4gQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiAoQkZEKSBvbiBMaW5rIEFnZ3Jl Z2F0aW9uIEdyb3VwIChMQUcpIEludGVyZmFjZXMKICAgIAogICAgQWN0dWFsbHksIEkgd2FzIHRo aW5raW5nIGFib3V0IGEgZ3JvdXAgc2l6ZSBvZiBvbmUgKCJ3aGVyZWFzIHRoZSBub3JtYWwgTEFH IGlzID4gMSIpIHRvIGVtdWxhdGUgQkZEIG92ZXIgYSBzaW5nbGUgcGh5c2ljYWwgRXRoZXJuZXQg bGluaywgLSBzb21ldGhpbmcgbGlrZSBhIGRlZGljYXRlZCAgIkJGRC1vdmVyLUxBRyBwcm90b2Nv bCBwcm9maWxlIi4KICAgIEhvd2V2ZXIsIGRpZG4ndCBpbnZlc3RpZ2F0ZSBzbyBmYXIgdGhlIG92 ZXJoZWFkLgogICAgCiAgICBSZWdhcmRzLAogICAgQWxicmVjaHQKICAgIAogICAgCiAgICAtLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQogICAgRnJvbTogQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFs ZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tPiAKICAgIFNlbnQ6IDEyIEp1bmUgMjAxOSAx NjoxNgogICAgVG86IEplZmZyZXkgSGFhcyA8amhhYXNAcGZyYy5vcmc+CiAgICBDYzogU2Nod2Fy eiBBbGJyZWNodCAoRVRBUy9FU1kxKSA8QWxicmVjaHQuU2Nod2FyekBldGFzLmNvbT47IHJ0Zy1i ZmRAaWV0Zi5vcmc7IFN0ZXdhcnQgQnJ5YW50IDxzdGV3YXJ0LmJyeWFudEBnbWFpbC5jb20+CiAg ICBTdWJqZWN0OiBSRTogRGlyZWN0IEJGRCBvdmVyIEV0aGVybmV0PwogICAgCiAgICBKZWZmcmV5 LAogICAgTG90cyBvZiB0aGFua3MgZm9yIGEgcHJvbXB0IHJlc3BvbnNlLgogICAgCiAgICBJIHRl bmQgdG8gYWdyZWUgd2l0aCB5b3VyIHN0YXRlbWVudCB0aGF0ICIgSUVURiBkb2Vzbid0IGhhdmUg YSB1c2VmdWwgT0FNIG1vZGVsIi4KICAgIEJ1dCBJIHdvdWxkIGFkZCB0aGF0LCBpbiBzcGl0ZSBv ZiB0aGF0LCBJRVRGIGhhcyBhIHJpY2ggc2V0IG9mIE9BTSB0b29scyB0aGF0IGFyZSB3aWRlbHkg ZGVwbG95ZWQgYW5kIHNlcnZlIHRoZSByZWFsIG5lZWRzIG9mIHRoZSBJRVRGIGNvbW11bml0eSBy ZWFzb25hYmx5IHdlbGwsIGFuZCBmcm9tIHRpbWUgdG8gdGltZSBhZGRzIHRvIHRoaXMgc2V0IHdo ZW4gbmV3IGlzc3VlcyBhcmUgaWRlbnRpZmllZC4KICAgIAogICAgV2hldGhlciBhIHVzZWZ1bCBP QU0gbW9kZWwgaXMgcmVhbGx5IG5lZWRlZCBpbiBoaXMgc2l0dWF0aW9uLCBvciBub3QsIGlzLCBJ TUhPLCBhIG1hdHRlciBvZiBwZXJzb25hbCBwcmVmZXJlbmNlcy4KICAgIAogICAgIklmIGl0IGlz IG5vdCBicm9rZW4gd2UgZG9uJ3QgZml4IGl0Ii4KICAgIAogICAgTXkgMmMsCiAgICBTYXNoYQog ICAgCiAgICBPZmZpY2U6ICs5NzItMzkyNjYzMDIKICAgIENlbGw6ICAgICAgKzk3Mi01NDkyNjYz MDIKICAgIEVtYWlsOiAgIEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUuY29tCiAgICAKICAg IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tCiAgICBGcm9tOiBKZWZmcmV5IEhhYXMgPGpoYWFz QHBmcmMub3JnPgogICAgU2VudDogV2VkbmVzZGF5LCBKdW5lIDEyLCAyMDE5IDEyOjIzIEFNCiAg ICBUbzogQWxleGFuZGVyIFZhaW5zaHRlaW4gPEFsZXhhbmRlci5WYWluc2h0ZWluQGVjaXRlbGUu Y29tPgogICAgQ2M6IFNjaHdhcnogQWxicmVjaHQgKEVUQVMvRVNZMSkgPGFsYnJlY2h0LnNjaHdh cnpAZXRhcy5jb20+OyBydGctYmZkQGlldGYub3JnOyBTdGV3YXJ0IEJyeWFudCA8c3Rld2FydC5i cnlhbnRAZ21haWwuY29tPgogICAgU3ViamVjdDogUmU6IERpcmVjdCBCRkQgb3ZlciBFdGhlcm5l dD8KICAgIAogICAgT24gU2F0LCBKdW4gMDgsIDIwMTkgYXQgMTI6NDU6NTBQTSArMDAwMCwgQWxl eGFuZGVyIFZhaW5zaHRlaW4gd3JvdGU6CiAgICA+IFRvIHRoZSBiZXN0IG9mIG15IHJlY29sbGVj dGlvbiB0aGUgQkZEIFdHIGhzcyB0cmllZCB0byBjb29wZXJhdGUgd2l0aCBJRUVFIDgwMi4xLCBi dXQgdGhlc2UgYXR0ZW1wdHMgaGF2ZSBmYWlsZWQuCiAgICAKICAgIEkgdGhpbmsgdGhhdCdzIGEg bWlzLWNoYXJhY3Rlcml6YXRpb24uCiAgICAKICAgIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBE ZXRlY3Rpb24gKEJGRCkgb24gTGluayBBZ2dyZWdhdGlvbiBHcm91cCAoTEFHKSBJbnRlcmZhY2Vz CiAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzEzMAogICAgCiAgICBJRUVFIHdh c24ndCByZWFsbHkgaW50ZXJlc3RlZCBpbiBoYXZpbmcgQkZEIHJ1bm5pbmcgbmF0aXZlLiAgTXVj aCBvZiB0aGlzIGhhcyB0byBkbyB3aXRoIHRoZSBPQU0gYW5kIGxheWVyaW5nIG1vZGVscyB0aGF0 IElFRUUgaGFzIGZvciBFdGhlcm5ldC4KICAgIAogICAgQW5kIHlldCwgSUVURiB3YXMgZ2V0dGlu ZyBwdXNoIHRvIHNvbHZlIGF0IGxlYXN0IGEgcHJvYmxlbSByZWxhdGluZyB0byBsYXllciAzIGlz c3VlcyBmb3IgdHJhZmZpYyBiYWxhbmNpbmcgb3ZlciBMQUdzLiAgVGhhdCB3YXMgc29tZXdoYXQg b3V0IG9mIHRoZSByZWFsbSBvZiBJRUVFLgogICAgCiAgICBTbywgd2hpbGUgaXQgdG9vayB1cyBh IHdoaWxlIHRvIGZyYW1lIHRoZSBwcm9ibGVtLCB3ZSBldmVudHVhbGx5IGZvdW5kIGEgcGxhY2Ug d2hlcmUgd2Ugd2VyZSBhYmxlIHRvIHNvbHZlIG91ciByZXNwZWN0aXZlIHByb2JsZW1zIHdpdGhv dXQgc3RlcHBpbmcgdG9vIG11Y2ggb24gb3JnYW5pemF0aW9uYWwgYW5kIGxheWVyLXdpc2UgYm91 bmRhcmllcy4KICAgIAogICAgPiBBdCB0aGUgc2FtZSB0aW1lIEkgdGhpbmsgdGhlcmUgaXMgYSBk aWZmZXJlbmNlIGluIHRoZSBvdmVyYWxsIGF0dGl0dWRlIHdpdGggcmVnYXJkIHRvIE9BTSBiZXR3 ZWVuIElFVEYgYW5kIElFRUUgODAyLjEuCiAgICAKICAgIEkgdGhpbmsgSSB3b3VsZCBzdGF0ZSB0 aGlzIGFzICJJRVRGIGRvZXNuJ3QgaGF2ZSBhIHVzZWZ1bCBPQU0gbW9kZWwiLiAgTWFueSBwZW9w bGUgd291bGQgcHJlZmVyIHVzIHRvIGhhdmUgb25lLCBhbmQgc2VlIEJGRCBhcyBhIHVzZWZ1bCBj b21wb25lbnQgZm9yIGl0LiAgSG93ZXZlciwgdGhhdCdzIGJpZ2dlciB3b3JrIHRoYW4ganVzdCBC RkQuCiAgICAKICAgIC0tIEplZmYKICAgIAogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCiAgICAKICAg IFRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgZm9yIHRoZSByZWNpcGllbnQgb25seSBh bmQgY29udGFpbnMgaW5mb3JtYXRpb24gd2hpY2ggaXMgQ09ORklERU5USUFMIGFuZCB3aGljaCBt YXkgYmUgcHJvcHJpZXRhcnkgdG8gRUNJIFRlbGVjb20uIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW5mb3JtIHVzIGJ5IGUtbWFpbCwgcGhv bmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIGFuZCBhbGwgY29waWVzIHRo ZXJlb2YuCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18KICAgIAogICAgCgoKX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fCgpUaGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIGZvciB0aGUgcmVjaXBpZW50IG9u bHkgYW5kIGNvbnRhaW5zIGluZm9ybWF0aW9uIHdoaWNoIGlzIApDT05GSURFTlRJQUwgYW5kIHdo aWNoIG1heSBiZSBwcm9wcmlldGFyeSB0byBFQ0kgVGVsZWNvbS4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyAKdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW5mb3JtIHVzIGJ5IGUtbWFp bCwgcGhvbmUgb3IgZmF4LCBhbmQgdGhlbiBkZWxldGUgdGhlIG9yaWdpbmFsIAphbmQgYWxsIGNv cGllcyB0aGVyZW9mLgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K From nobody Wed Jun 12 10:51:45 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2407412016F for ; Wed, 12 Jun 2019 10:51:44 -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, SPF_PASS=-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 Q-YQLsW0fqsG for ; Wed, 12 Jun 2019 10:51:42 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id C80A4120144 for ; Wed, 12 Jun 2019 10:51:31 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 342A71E2F1; Wed, 12 Jun 2019 13:52:32 -0400 (EDT) Date: Wed, 12 Jun 2019 13:52:32 -0400 From: Jeffrey Haas To: Alexander Vainshtein Cc: "Schwarz Albrecht (ETAS/ESY1)" , "Reshad Rahman (rrahman)" , "rtg-bfd@ietf.org" Subject: Re: Direct BFD over Ethernet? Message-ID: <20190612175232.GC23231@pfrc.org> References: <20190607115617.GC15506@pfrc.org> <7a42f74e46484476a8b642a29649a471@etas.com> <20190611212305.GB12590@pfrc.org> <48023C71-074E-4C8C-AFF4-CD1706FB0F54@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2019 17:51:44 -0000 On Wed, Jun 12, 2019 at 02:45:54PM +0000, Alexander Vainshtein wrote: > Albrecht, Reshad and all, > I concur with Reshad - it will work (RFC 7130 never says anything about the number of links in the LAG). A somewhat perverse use of the feature. Cute. :-) > Such a session would still use encapsulation in IP/UDP with the UDP destination port set to 6784 and the Destination IP address " that is configured on the peer system and can be reached via the LAG interface ". I.e., some lightweight IP functionality would be still required. I'd expect there to be two interesting headaches: 1. In some implementations, you're shutting down "the lag" rather than the link. You'll effectively stop forwarding traffic, I think, but you may not get the expected ifDown event on the link, only on the LAG-of-1 virtual interface. Clearly this is an implementation detail, but such things are what make LAGs painful in IP protocols land. 2. The bootstrapping provisions require a bit more than just the light-weight IP stack. My employer's developers liked to say that they had to operate at "layer 2.5" in order to get stuff to work before IP was actually up. -- Jeff From nobody Mon Jun 17 05:34:49 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC263120129; Sun, 16 Jun 2019 21:59:33 -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_HELO_NONE=0.001, 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 Aj_fgET_LJeL; Sun, 16 Jun 2019 21:59:29 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (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 6A5AD120111; Sun, 16 Jun 2019 21:59:26 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id p24so5480258lfo.6; Sun, 16 Jun 2019 21:59:26 -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=lfofZ0dnkqjksBu6GnFH5pPqNRIKY2xmc2s6+toWAuI=; b=m6hzKkoba0FQ8suNPMYZB9VGjmCdnbiFUtffahUxel7FuAW9nt8m0DZhvkCD+YtFiN BWkz+Aja9r58B/08jmUItbyeYE2ABQs1PHKImHvyR9HztW9JDKDB+5mpM9Mv5APX/iXF betLIfG/B9qULUoi+a55DvInTKNK6HTLndb4VHdqkoDWa/Ful8ngyy8h7EWW4fIHORr1 qovFJtDgrTxIG246Mku+oxaWPy241ne9kN+ZXGXZ9ytBA9UdaM+KXLUejbFB3oUhzokA BKdm9mfv7xDck/xW7Lfd7NEkxAQCuy2tWRybOeZapIh088ynMx32OhsnEkt/GmD6prlm ytdg== 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=lfofZ0dnkqjksBu6GnFH5pPqNRIKY2xmc2s6+toWAuI=; b=Wu+UChBdpln121uaeAC0iPdG9Pd7aE4JzrZmIhCoYL7kJ8OBzvINeqIJ2EfuA+XB/P A2VI9yxx2MXipZxJjC1Zp9zqkaeUucxuBxVC3RfjGBdHzMuUa017t+InwNPsEwPeQZl3 TeXXodnRbyoAIbUhfF7Q2vwlvhTjsJf5Nv9CcUBrKj7bXIY0tNrY87vtrR05UTgelF+6 Rx0twVwb40OLDtvg9C+/VTCFJv9CM8M0D+mKI6BkE6DODc5E2aqVPAOyDE6q9DSUTDVh V6lSpGOEkRue/1nnXMJhwjsDLrwlml4HaO+Zvoj4XnXnhtPTgZ3NLlXphwt3Eo6CEHU2 DW3w== X-Gm-Message-State: APjAAAXg3NJ55h64v0F+cLcRClzTsrl8e+HPVvoKx53DYYyc321rhgY+ xKidKnptAmZ/BFGITLdJrgKzKtMFq6rATeiplFY= X-Google-Smtp-Source: APXvYqzAgtSgE/B8apsGmwtuJAnXaVCpkgn1muFc294nzYDjVftXA9F50gfeGcjJ9cVlJiJ1wS/aVCj7RgIBn3A/gC4= X-Received: by 2002:a05:6512:24a:: with SMTP id b10mr51615835lfo.37.1560747564565; Sun, 16 Jun 2019 21:59:24 -0700 (PDT) MIME-Version: 1.0 References: <155933149484.6565.7386019489022348116@ietfa.amsl.com> In-Reply-To: <155933149484.6565.7386019489022348116@ietfa.amsl.com> From: Greg Mirsky Date: Mon, 17 Jun 2019 13:58:05 +0900 Message-ID: Subject: Re: Tsvart last call review of draft-ietf-bfd-vxlan-07 To: Olivier Bonaventure Cc: tsv-art@ietf.org, rtg-bfd WG , draft-ietf-bfd-vxlan.all@ietf.org, IETF list Content-Type: multipart/mixed; boundary="0000000000002bb946058b7ddcb6" Archived-At: X-Mailman-Approved-At: Mon, 17 Jun 2019 05:34:48 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 04:59:34 -0000 --0000000000002bb946058b7ddcb6 Content-Type: multipart/alternative; boundary="0000000000002bb944058b7ddcb4" --0000000000002bb944058b7ddcb4 Content-Type: text/plain; charset="UTF-8" Hi Oliver, thank you for your thorough review, clear and detailed questions. My apologies for the delay to respond. Please find my answers below in-line tagged GIM>>. Regards, Greg On Fri, May 31, 2019 at 12:38 PM Olivier Bonaventure via Datatracker < noreply@ietf.org> wrote: > Reviewer: Olivier Bonaventure > Review result: Ready with Issues > > This document has been reviewed as part of the transport area review team's > ongoing effort to review key IETF documents. These comments were written > primarily for the transport area directors, but are copied to the > document's > authors and WG to allow them to address any issues raised and also to the > IETF > discussion list for information. > > When done at the time of IETF Last Call, the authors should consider this > review as part of the last-call comments they receive. Please always CC > tsv-art@ietf.org if you reply to or forward this review. > > I have only limited knowledge of VXLAN and do not know all subtleties of > BFD. > This review is thus more from a generalist than a specialist in this topic. > > Major issues > > Section 4 requires that " Implementations SHOULD ensure that the BFD > packets follow the same lookup path as VXLAN data packets within the > sender system." > > Why is this requirement only relevant for the lookup path on the sender > system > ? What does this sentence really implies ? > GIM>> RFC 5880 set the scope of the fault detection of BFD protocol as ... the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves ... The requirement aimed to the forwarding engine of a BFD system that transmits BFD control packets over VXLAN tunnel. > > Is it a requirement that the BFD packets follow the same path as the data > packet for a given VXLAN ? I guess so. In this case, the document should > discuss how Equal Cost Multipath could affect this. > GIM>> I think that ECMP environment is more likely to be experienced by a transit node in the underlay. If the BFD session is used to monitor the specific underlay path, then, I agree, we should explain that using the VXLAN payload information to draw path entropy may cause data and BFD packets following different underlay routes. But, on the other hand, that is the case for OAM and fault detection in all overlay networks in general. > > Minor issues > > Section 1 > > You write "The asynchronous mode of BFD, as defined in [RFC5880], > can be used to monitor a p2p VXLAN tunnel." > > Why do you use the word can ? It is a possibility or a requirement ? > GIM>> In principle, BFD Demand mode may be used to monitor p2p paths as well, I agree, will re-word to more assertive: The asynchronous mode of BFD, as defined in [RFC5880], is used to monitor a p2p VXLAN tunnel. > > > NVE has not been defined before and is not in the terminology. > GIM>> Will add to the Terminology and expand as: NVE Network Virtualization Endpoint > > This entire section is not easy to read for an outsider. > > Section 3 > > VNI has not been defined > GIM>> Will add to the Terminology section: VNI VXLAN Network Identifier (or VXLAN Segment ID) > > Figure 1 could take less space > GIM>> Yes, can make it bit denser. Would the following be an improvement? +------------+-------------+ | Server 1 | | +----+----+ +----+----+ | | |VM1-1 | |VM1-2 | | | |VNI 100 | |VNI 200 | | | | | | | | | +---------+ +---------+ | | Hypervisor VTEP (IP1) | +--------------------------+ | | +-------------+ | | Layer 3 | +---| Network | +-------------+ | +-----------+ | +------------+-------------+ | Hypervisor VTEP (IP2) | | +----+----+ +----+----+ | | |VM2-1 | |VM2-2 | | | |VNI 100 | |VNI 200 | | | | | | | | | +---------+ +---------+ | | Server 2 | +--------------------------+ > Section 4 > > I do not see the benefits of having one paragraph in Section 4 followed by > only > Section 4.1 > GIM>> Will merge Section 4.1 into 4 with minor required re-wording: 4. BFD Packet Transmission over VXLAN Tunnel BFD packet MUST be encapsulated and sent to a remote VTEP as explained in this section. Implementations SHOULD ensure that the BFD packets follow the same lookup path as VXLAN data packets within the sender system. BFD packets are encapsulated in VXLAN as described below. The VXLAN packet format is defined in Section 5 of [RFC7348]. The Outer IP/UDP and VXLAN headers MUST be encoded by the sender as defined in [RFC7348]. > > Section 4.1 > > The document does not specify when a dedicated MAC address or the MAC > address > of the destination VTEP must be used. This could affect the > interoperability of > implementations. Should all implementations support both the dedicated MAC > address and the destination MAC address ? > GIM>> After further discussion, authors decided to remove the request for the dedicated MAC address allocation. Only the MAC address of the remote VTEP must be used as the destination MAC address in the inner Ethernet frame. Please check the attached diff between the -07 and the working versions or the working version of the draft. > > It is unclear from this section whether IPv4 inside IPv6 and the opposite > should be supported or not. > GIM>> Any combination of outer IPvX and inner IPvX is possible. > > Section 5. > > If the received packet does not match the dedicated MAC address nor the MAC > address of the VTEP, should the packet be silently discarded or treated > differently ? > GIM>> As I've mentioned earlier, authors have decided to remove the use of the dedicated MAC address for BFD over VXLAN. > > Section 5.1 > > Is this a modification to section 6.3 of RFC5880 ? This is not clear > GIM>> I think that this section is not modification but the definition of the application-specific procedure that is outside the scope of RFC 5880: The method of demultiplexing the initial packets (in which Your Discriminator is zero) is application dependent, and is thus outside the scope of this specification. > > Section 9 > > The sentence " Throttling MAY be relaxed for BFD packets > based on port number." is unclear. > GIM>> Yes, thank you for pointing to this. The updated text, in the whole paragraph, is as follows: NEW TEXT: The document requires setting the inner IP TTL to 1, which could be used as a DDoS attack vector. Thus the implementation MUST have throttling in place to control the rate of BFD control packets sent to the control plane. On the other hand, over aggressive throttling of BFD control packets may become the cause of the inability to form and maintain BFD session at scale. Hence, throttling of BFD control packets SHOULD be adjusted to permit BFD to work according to its procedures. --0000000000002bb944058b7ddcb4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Oliver,
thank you for your thoroug= h review, clear and detailed questions. My apologies for the delay to respo= nd. Please find my answers below in-line tagged GIM>>.

=
Regards,
Greg

On Fri, May 31, 2019 at 12:38 PM Ol= ivier Bonaventure via Datatracker <noreply@ietf.org> wrote:
Reviewer: Olivier Bonaventure
Review result: Ready with Issues

This document has been reviewed as part of the transport area review team&#= 39;s
ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document&= #39;s
authors and WG to allow them to address any issues raised and also to the I= ETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org = if you reply to or forward this review.

I have only limited knowledge of VXLAN and do not know all subtleties of BF= D.
This review is thus more from a generalist than a specialist in this topic.=

Major issues

Section 4 requires that " Implementations SHOULD ensure that the BFD =C2=A0 =C2=A0packets follow the same lookup path as VXLAN data packets with= in the
=C2=A0 =C2=A0sender system."

Why is this requirement only relevant for the lookup path on the sender sys= tem
? What does this sentence really implies ?
GIM>>= RFC 5880 set the scope of the fault detection of BFD protocol as=C2=A0=C2=A0 =C2=A0... the bidirectional path between two forwarding engines, i= ncluding
=C2=A0 =C2=A0interfaces, data link(s), and to the extent possib= le the forwarding
=C2=A0 =C2=A0engines themselves ...
The= requirement aimed to the forwarding engine of a BFD system that transmits = BFD control packets over VXLAN tunnel.

Is it a requirement that the BFD packets follow the same path as the data packet for a given VXLAN ? I guess so. In this case, the document should discuss how Equal Cost Multipath could affect this.
GI= M>> I think that ECMP environment is more likely to be experienced by= a transit node in the underlay. If the BFD session is used to monitor the = specific underlay path, then, I agree, we should explain that using the VXL= AN payload information to draw path entropy may cause data and BFD packets = following different underlay routes. But, on the other hand, that is the ca= se for OAM and fault detection in all overlay networks in general.

Minor issues

Section 1

You write "The asynchronous mode of BFD, as defined in [RFC5880],
=C2=A0can be used to monitor a p2p VXLAN tunnel."

Why do you use the word can ? It is a possibility or a requirement ?
GIM>> In principle, BFD Demand mode may be used to mon= itor p2p paths as well, I agree, will re-word to more assertive:
= =C2=A0The asynchronous mode of BFD, as defined in [RFC5880],
=C2=A0is = used to monitor a p2p VXLAN tunnel.

NVE has not been defined before and is not in the terminology.
GIM>> Will add to the Terminology and expand as:
N= VE =C2=A0 =C2=A0 =C2=A0 =C2=A0Network Virtualization Endpoint=C2=A0

This entire section is not easy to read for an outsider.

Section 3

VNI has not been defined
GIM>> Will add to the T= erminology section:
VNI=C2=A0 =C2=A0 VXLAN Network Identifier (or= VXLAN Segment ID)

Figure 1 could take less space
GIM>> Yes, can ma= ke it bit denser. Would the following be an improvement?
=C2=A0
      +------=
------+-------------+
      |        Server 1          |
      | +----+----+  +----+----+ |
      | |VM1-1    |  |VM1-2    | |
      | |VNI 100  |  |VNI 200  | |
      | |         |  |         | |
      | +---------+  +---------+ |
      | Hypervisor VTEP (IP1)    |
      +--------------------------+
                            |
                            |   +-------------+
                            |   |   Layer 3   |
                            +---|   Network   |
                                +-------------+
                                    |
                                    +-----------+
                                                |
                                         +------------+-------------+
                                         |    Hypervisor VTEP (IP2) |
                                         | +----+----+  +----+----+ |
                                         | |VM2-1    |  |VM2-2    | |
                                         | |VNI 100  |  |VNI 200  | |
                                         | |         |  |         | |
                                         | +---------+  +---------+ |
                                         |      Server 2            |
                                         +--------------------------+
=

Section 4

I do not see the benefits of having one paragraph in Section 4 followed by = only
Section 4.1
GIM>> Will merge Section 4.1 into 4 = with minor required re-wording:
4.=C2=A0 BFD Packet Transmission = over VXLAN Tunnel

=C2=A0 =C2=A0BFD packet MUST be encapsulated and s= ent to a remote VTEP as
=C2=A0 =C2=A0explained in this section.=C2=A0 Im= plementations SHOULD ensure that the
=C2=A0 =C2=A0BFD packets follow the= same lookup path as VXLAN data packets within
=C2=A0 =C2=A0the sender s= ystem.

=C2=A0 =C2=A0BFD packets are encapsulated in VXLAN as describ= ed below.=C2=A0 The VXLAN
=C2=A0 =C2=A0packet format is defined in Secti= on 5 of [RFC7348].=C2=A0 The Outer IP/UDP
=C2=A0 =C2=A0and VXLAN headers= MUST be encoded by the sender as defined in
=C2=A0 =C2=A0[RFC7348].
=

Section 4.1

The document does not specify when a dedicated MAC address or the MAC addre= ss
of the destination VTEP must be used. This could affect the interoperabilit= y of
implementations. Should all implementations support both the dedicated MAC<= br> address and the destination MAC address ?
GIM>> = After further discussion, authors decided to remove the request for the ded= icated MAC address allocation. Only the MAC address of the remote VTEP must= be used as the destination MAC address in the inner Ethernet frame. Please= check the attached diff between the -07 and the working versions or the wo= rking version of the draft.

It is unclear from this section whether IPv4 inside IPv6 and the opposite should be supported or not.
GIM>> Any combinatio= n of outer IPvX and inner IPvX is possible.

Section 5.

If the received packet does not match the dedicated MAC address nor the MAC=
address of the VTEP, should the packet be silently discarded or treated
differently ?
GIM>> As I've mentioned earlie= r, authors have decided to remove the use of the dedicated MAC address for = BFD over VXLAN.

Section 5.1

Is this a modification to section 6.3 of RFC5880 ? This is not clear
GIM>> I think that this section is not modification bu= t the definition of the application-specific procedure that is outside the = scope of RFC 5880:
=C2=A0 =C2=A0The method of demultiplexing the = initial packets (in which Your
=C2=A0 =C2=A0Discriminator is zero) is ap= plication dependent, and is thus outside
=C2=A0 =C2=A0the scope of this = specification.

Section 9

The sentence " Throttling MAY be relaxed for BFD packets
=C2=A0 =C2=A0based on port number." is unclear.
G= IM>> Yes, thank you for pointing to this. The updated text, in the wh= ole paragraph, is as follows:
NEW TEXT:
=C2=A0 =C2=A0Th= e document requires setting the inner IP TTL to 1, which could be
=C2=A0= =C2=A0used as a DDoS attack vector.=C2=A0 Thus the implementation MUST hav= e
=C2=A0 =C2=A0throttling in place to control the rate of BFD control pa= ckets sent
=C2=A0 =C2=A0to the control plane.=C2=A0 On the other hand, o= ver aggressive throttling
=C2=A0 =C2=A0of BFD control packets may become= the cause of the inability to form
=C2=A0 =C2=A0and maintain BFD sessio= n at scale.=C2=A0 Hence, throttling of BFD control
=C2=A0 =C2=A0packets = SHOULD be adjusted to permit BFD to work according to its
=C2=A0 =C2=A0p= rocedures.
--0000000000002bb944058b7ddcb4-- --0000000000002bb946058b7ddcb6 Content-Type: text/plain; charset="US-ASCII"; name="draft-ietf-bfd-vxlan-08.txt" Content-Disposition: attachment; filename="draft-ietf-bfd-vxlan-08.txt" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jwzwr41p1 CgoKCkJGRCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IFMuIFBhbGxhZ2F0dGksIEVkLgpJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJ0YnJpY2sKSW50ZW5kZWQgc3RhdHVzOiBTdGFu ZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFMuIFBhcmFnaXJpCkV4cGly ZXM6IERlY2VtYmVyIDE4LCAyMDE5ICAgICAgICAgICAgICAgICAgICAgICAgSW5kaXZpZHVhbCBD b250cmlidXRvcgogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgVi4gR292aW5kYW4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTS4gTXVkaWdvbmRhCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaXNj bwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBHLiBNaXJza3kKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgWlRFIENvcnAuCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSnVuZSAxNiwgMjAxOQoKCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgQkZEIGZvciBWWExBTgogICAgICAgICAgICAgICAgICAg ICAgICBkcmFmdC1pZXRmLWJmZC12eGxhbi0wOAoKQWJzdHJhY3QKCiAgIFRoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIHRoZSB1c2Ugb2YgdGhlIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZwogICBEZXRl Y3Rpb24gKEJGRCkgcHJvdG9jb2wgaW4gcG9pbnQtdG8tcG9pbnQgVmlydHVhbCBlWHRlbnNpYmxl IExvY2FsCiAgIEFyZWEgTmV0d29yayAoVlhMQU4pIHR1bm5lbHMgZm9ybWluZyB1cCBhbiBvdmVy bGF5IG5ldHdvcmsuCgpTdGF0dXMgb2YgVGhpcyBNZW1vCgogICBUaGlzIEludGVybmV0LURyYWZ0 IGlzIHN1Ym1pdHRlZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlCiAgIHByb3Zpc2lvbnMg b2YgQkNQIDc4IGFuZCBCQ1AgNzkuCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9j dW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZwogICBUYXNrIEZvcmNlIChJRVRGKS4g IE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZQogICB3b3JraW5nIGRv Y3VtZW50cyBhcyBJbnRlcm5ldC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0 LQogICBEcmFmdHMgaXMgYXQgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kcmFmdHMvY3Vy cmVudC8uCgogICBJbnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3Ig YSBtYXhpbXVtIG9mIHNpeCBtb250aHMKICAgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwg b3Igb2Jzb2xldGVkIGJ5IG90aGVyIGRvY3VtZW50cyBhdCBhbnkKICAgdGltZS4gIEl0IGlzIGlu YXBwcm9wcmlhdGUgdG8gdXNlIEludGVybmV0LURyYWZ0cyBhcyByZWZlcmVuY2UKICAgbWF0ZXJp YWwgb3IgdG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIgoKICAg VGhpcyBJbnRlcm5ldC1EcmFmdCB3aWxsIGV4cGlyZSBvbiBEZWNlbWJlciAxOCwgMjAxOS4KCkNv cHlyaWdodCBOb3RpY2UKCiAgIENvcHlyaWdodCAoYykgMjAxOSBJRVRGIFRydXN0IGFuZCB0aGUg cGVyc29ucyBpZGVudGlmaWVkIGFzIHRoZQogICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0 cyByZXNlcnZlZC4KCiAgIFRoaXMgZG9jdW1lbnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRo ZSBJRVRGIFRydXN0J3MgTGVnYWwKICAgUHJvdmlzaW9ucyBSZWxhdGluZyB0byBJRVRGIERvY3Vt ZW50cwogICAoaHR0cHM6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0 IG9uIHRoZSBkYXRlIG9mCiAgIHB1YmxpY2F0aW9uIG9mIHRoaXMgZG9jdW1lbnQuICBQbGVhc2Ug cmV2aWV3IHRoZXNlIGRvY3VtZW50cwogICBjYXJlZnVsbHksIGFzIHRoZXkgZGVzY3JpYmUgeW91 ciByaWdodHMgYW5kIHJlc3RyaWN0aW9ucyB3aXRoIHJlc3BlY3QKCgoKUGFsbGFnYXR0aSwgZXQg YWwuICAgICAgRXhwaXJlcyBEZWNlbWJlciAxOCwgMjAxOSAgICAgICAgICAgICAgIFtQYWdlIDFd CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgQkZEIGZvciBWWExBTiAgICAgICAgICAg ICAgICAgICAgSnVuZSAyMDE5CgoKICAgdG8gdGhpcyBkb2N1bWVudC4gIENvZGUgQ29tcG9uZW50 cyBleHRyYWN0ZWQgZnJvbSB0aGlzIGRvY3VtZW50IG11c3QKICAgaW5jbHVkZSBTaW1wbGlmaWVk IEJTRCBMaWNlbnNlIHRleHQgYXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gNC5lIG9mCiAgIHRoZSBU cnVzdCBMZWdhbCBQcm92aXNpb25zIGFuZCBhcmUgcHJvdmlkZWQgd2l0aG91dCB3YXJyYW50eSBh cwogICBkZXNjcmliZWQgaW4gdGhlIFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuCgpUYWJsZSBvZiBD b250ZW50cwoKICAgMS4gIEludHJvZHVjdGlvbiAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gICAyCiAgIDIuICBDb252ZW50aW9ucyB1c2VkIGluIHRoaXMg ZG9jdW1lbnQgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMwogICAgIDIuMS4gIFRlcm1p bm9sb2d5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDMK ICAgICAyLjIuICBSZXF1aXJlbWVudHMgTGFuZ3VhZ2UgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gICAzCiAgIDMuICBEZXBsb3ltZW50ICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNAogICA0LiAgQkZEIFBhY2tldCBUcmFuc21p c3Npb24gb3ZlciBWWExBTiBUdW5uZWwgLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDUKICAgNS4gIFJl Y2VwdGlvbiBvZiBCRkQgUGFja2V0IGZyb20gVlhMQU4gVHVubmVsIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA3CiAgICAgNS4xLiAgRGVtdWx0aXBsZXhpbmcgb2YgdGhlIEJGRCBQYWNrZXQgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAgNwogICA2LiAgVXNlIG9mIHRoZSBTcGVjaWZpYyBWTkkgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDgKICAgNy4gIEVjaG8gQkZEICAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4CiAg IDguICBJQU5BIENvbnNpZGVyYXRpb25zIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAgOAogICA5LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDgKICAgMTAuIENvbnRyaWJ1dG9ycyAgLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4CiAgIDExLiBBY2tu b3dsZWRnbWVudHMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAgOQogICAxMi4gUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgIDkKICAgICAxMi4xLiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMgLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA5CiAgICAgMTIuMi4gIEluZm9ybWF0 aW9uYWwgUmVmZXJlbmNlcyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgOQogICBB dXRob3JzJyBBZGRyZXNzZXMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgMTAKCjEuICBJbnRyb2R1Y3Rpb24KCiAgICJWaXJ0dWFsIGVYdGVuc2libGUgTG9j YWwgQXJlYSBOZXR3b3JrIiAoVlhMQU4pIFtSRkM3MzQ4XSBwcm92aWRlcyBhbgogICBlbmNhcHN1 bGF0aW9uIHNjaGVtZSB0aGF0IGFsbG93cyBidWlsZGluZyBhbiBvdmVybGF5IG5ldHdvcmsgYnkK ICAgZGVjb3VwbGluZyB0aGUgYWRkcmVzcyBzcGFjZSBvZiB0aGUgYXR0YWNoZWQgdmlydHVhbCBo b3N0cyBmcm9tIHRoYXQKICAgb2YgdGhlIG5ldHdvcmsuCgogICBPbmUgdXNlIG9mIFZYTEFOIGlz IGluIGRhdGEgY2VudGVycyBpbnRlcmNvbm5lY3RpbmcgdmlydHVhbCBtYWNoaW5lcwogICAoVk1z KSBvZiBhIHRlbmFudC4gIFZYTEFOIGFkZHJlc3NlcyByZXF1aXJlbWVudHMgb2YgdGhlIExheWVy IDIgYW5kCiAgIExheWVyIDMgZGF0YSBjZW50ZXIgbmV0d29yayBpbmZyYXN0cnVjdHVyZSBpbiB0 aGUgcHJlc2VuY2Ugb2YgVk1zIGluCiAgIGEgbXVsdGktdGVuYW50IGVudmlyb25tZW50IGJ5IHBy b3ZpZGluZyBhIExheWVyIDIgb3ZlcmxheSBzY2hlbWUgb24gYQogICBMYXllciAzIG5ldHdvcmsg W1JGQzczNDhdLiAgQW5vdGhlciB1c2UgaXMgYXMgYW4gZW5jYXBzdWxhdGlvbiBmb3IKICAgRXRo ZXJuZXQgVlBOIFtSRkM4MzY1XS4KCiAgIFRoaXMgZG9jdW1lbnQgaXMgd3JpdHRlbiBhc3N1bWlu ZyB0aGUgdXNlIG9mIFZYTEFOIGZvciB2aXJ0dWFsaXplZAogICBob3N0cyBhbmQgcmVmZXJzIHRv IFZNcyBhbmQgVlhMQU4gVHVubmVsIEVuZCBQb2ludHMgKFZURVBzKSBpbgogICBoeXBlcnZpc29y cy4gIEhvd2V2ZXIsIHRoZSBjb25jZXB0cyBhcmUgZXF1YWxseSBhcHBsaWNhYmxlIHRvIG5vbi0K ICAgdmlydHVhbGl6ZWQgaG9zdHMgYXR0YWNoZWQgdG8gVlRFUHMgaW4gc3dpdGNoZXMuCgogICBJ biB0aGUgYWJzZW5jZSBvZiBhIHJvdXRlciBpbiB0aGUgb3ZlcmxheSwgYSBWTSBjYW4gY29tbXVu aWNhdGUgd2l0aAogICBhbm90aGVyIFZNIG9ubHkgaWYgdGhleSBhcmUgb24gdGhlIHNhbWUgVlhM QU4gc2VnbWVudC4gIFZNcyBhcmUKICAgdW5hd2FyZSBvZiBWWExBTiB0dW5uZWxzIGFzIGEgVlhM QU4gdHVubmVsIGlzIHRlcm1pbmF0ZWQgb24gYSBWVEVQLgoKCgpQYWxsYWdhdHRpLCBldCBhbC4g ICAgICBFeHBpcmVzIERlY2VtYmVyIDE4LCAyMDE5ICAgICAgICAgICAgICAgW1BhZ2UgMl0KDApJ bnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICBCRkQgZm9yIFZYTEFOICAgICAgICAgICAgICAg ICAgICBKdW5lIDIwMTkKCgogICBWVEVQcyBhcmUgcmVzcG9uc2libGUgZm9yIGVuY2Fwc3VsYXRp bmcgYW5kIGRlY2Fwc3VsYXRpbmcgZnJhbWVzCiAgIGV4Y2hhbmdlZCBhbW9uZyBWTXMuCgogICBB YmlsaXR5IHRvIG1vbml0b3IgcGF0aCBjb250aW51aXR5LCBpLmUuLCBwZXJmb3JtIHByb2FjdGl2 ZQogICBjb250aW51aXR5IGNoZWNrIChDQykgZm9yIHBvaW50LXRvLXBvaW50IChwMnApIFZYTEFO IHR1bm5lbHMsIGlzCiAgIGltcG9ydGFudC4gIFRoZSBhc3luY2hyb25vdXMgbW9kZSBvZiBCRkQs IGFzIGRlZmluZWQgaW4gW1JGQzU4ODBdLCBpcwogICB1c2VkIHRvIG1vbml0b3IgYSBwMnAgVlhM QU4gdHVubmVsLgoKICAgSW4gdGhlIGNhc2Ugd2hlcmUgYSBNdWx0aWNhc3QgU2VydmljZSBOb2Rl IChNU04pIChhcyBkZXNjcmliZWQgaW4KICAgU2VjdGlvbiAzLjMgb2YgW1JGQzgyOTNdKSByZXNp ZGVzIGJlaGluZCBhbiBOZXR3b3JrIFZpcnR1YWxpemF0aW9uCiAgIEVuZHBvaW50IChOVkUpLCB0 aGUgbWVjaGFuaXNtcyBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCBhcHBseSBhbmQKICAgY2Fu LCB0aGVyZWZvcmUsIGJlIHVzZWQgdG8gdGVzdCB0aGUgY29ubmVjdGl2aXR5IGZyb20gdGhlIHNv dXJjZSBOVkUKICAgdG8gdGhlIE1TTi4KCiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSB1 c2Ugb2YgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbgogICAoQkZEKSBwcm90b2Nv bCB0byBlbmFibGUgbW9uaXRvcmluZyBjb250aW51aXR5IG9mIHRoZSBwYXRoIGJldHdlZW4KICAg VlhMQU4gVlRFUHMsIHBlcmZvcm1pbmcgYXMgTmV0d29yayBWaXJ0dWFsaXphdGlvbiBFbmRwb2lu dHMsIGFuZC9vcgogICBhdmFpbGFiaWxpdHkgb2YgYSByZXBsaWNhdG9yIG11bHRpY2FzdCBzZXJ2 aWNlIG5vZGUuCgoyLiAgQ29udmVudGlvbnMgdXNlZCBpbiB0aGlzIGRvY3VtZW50CgoyLjEuICBU ZXJtaW5vbG9neQoKICAgQkZEIEJpZGlyZWN0aW9uYWwgRm9yd2FyZGluZyBEZXRlY3Rpb24KCiAg IENDIENvbnRpbnVpdHkgQ2hlY2sKCiAgIHAycCBQb2ludC10by1wb2ludAoKICAgTVNOIE11bHRp Y2FzdCBTZXJ2aWNlIE5vZGUKCiAgIE5WRSBOZXR3b3JrIFZpcnR1YWxpemF0aW9uIEVuZHBvaW50 CgogICBWRkkgVmlydHVhbCBGb3J3YXJkaW5nIEluc3RhbmNlCgogICBWTSBWaXJ0dWFsIE1hY2hp bmUKCiAgIFZOSSBWWExBTiBOZXR3b3JrIElkZW50aWZpZXIgKG9yIFZYTEFOIFNlZ21lbnQgSUQp CgogICBWVEVQIFZYTEFOIFR1bm5lbCBFbmQgUG9pbnQKCiAgIFZYTEFOIFZpcnR1YWwgZVh0ZW5z aWJsZSBMb2NhbCBBcmVhIE5ldHdvcmsKCjIuMi4gIFJlcXVpcmVtZW50cyBMYW5ndWFnZQoKICAg VGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJT SEFMTCBOT1QiLAogICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTk9U IFJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZAogICAiT1BUSU9OQUwiIGluIHRoaXMgZG9jdW1lbnQg YXJlIHRvIGJlIGludGVycHJldGVkIGFzIGRlc2NyaWJlZCBpbiBCQ1AKCgoKUGFsbGFnYXR0aSwg ZXQgYWwuICAgICAgRXhwaXJlcyBEZWNlbWJlciAxOCwgMjAxOSAgICAgICAgICAgICAgIFtQYWdl IDNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgQkZEIGZvciBWWExBTiAgICAgICAg ICAgICAgICAgICAgSnVuZSAyMDE5CgoKICAgMTQgW1JGQzIxMTldIFtSRkM4MTc0XSB3aGVuLCBh bmQgb25seSB3aGVuLCB0aGV5IGFwcGVhciBpbiBhbGwKICAgY2FwaXRhbHMsIGFzIHNob3duIGhl cmUuCgozLiAgRGVwbG95bWVudAoKICAgRmlndXJlIDEgaWxsdXN0cmF0ZXMgdGhlIHNjZW5hcmlv IHdpdGggdHdvIHNlcnZlcnMsIGVhY2ggb2YgdGhlbQogICBob3N0aW5nIHR3byBWTXMuICBUaGUg c2VydmVycyBob3N0IFZURVBzIHRoYXQgdGVybWluYXRlIHR3byBWWExBTgogICB0dW5uZWxzIHdp dGggVlhMQU4gTmV0d29yayBJZGVudGlmaWVyIChWTkkpIG51bWJlciAxMDAgYW5kIDIwMAogICBy ZXNwZWN0aXZlbHkuICBTZXBhcmF0ZSBCRkQgc2Vzc2lvbnMgY2FuIGJlIGVzdGFibGlzaGVkIGJl dHdlZW4gdGhlCiAgIFZURVBzIChJUDEgYW5kIElQMikgZm9yIG1vbml0b3JpbmcgZWFjaCBvZiB0 aGUgVlhMQU4gdHVubmVscyAoVk5JIDEwMAogICBhbmQgMjAwKS4gIEFuIGltcGxlbWVudGF0aW9u IHRoYXQgc3VwcG9ydHMgdGhpcyBzcGVjaWZpY2F0aW9uIE1VU1QgYmUKICAgYWJsZSB0byBjb250 cm9sIHRoZSBudW1iZXIgb2YgQkZEIHNlc3Npb25zIHRoYXQgY2FuIGJlIGNyZWF0ZWQKICAgYmV0 d2VlbiB0aGUgc2FtZSBwYWlyIG9mIFZURVBzLiAgQkZEIHBhY2tldHMgaW50ZW5kZWQgZm9yIGEK ICAgSHlwZXJ2aXNvciBWVEVQIE1VU1QgTk9UIGJlIGZvcndhcmRlZCB0byBhIFZNIGFzIGEgVk0g bWF5IGRyb3AgQkZECiAgIHBhY2tldHMgbGVhZGluZyB0byBhIGZhbHNlIG5lZ2F0aXZlLiAgVGhp cyBtZXRob2QgaXMgYXBwbGljYWJsZQogICB3aGV0aGVyIHRoZSBWVEVQIGlzIGEgdmlydHVhbCBv ciBwaHlzaWNhbCBkZXZpY2UuCgoKICAgICAgKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKwog ICAgICB8ICAgICAgICBTZXJ2ZXIgMSAgICAgICAgICB8CiAgICAgIHwgKy0tLS0rLS0tLSsgICst LS0tKy0tLS0rIHwKICAgICAgfCB8Vk0xLTEgICAgfCAgfFZNMS0yICAgIHwgfAogICAgICB8IHxW TkkgMTAwICB8ICB8Vk5JIDIwMCAgfCB8CiAgICAgIHwgfCAgICAgICAgIHwgIHwgICAgICAgICB8 IHwKICAgICAgfCArLS0tLS0tLS0tKyAgKy0tLS0tLS0tLSsgfAogICAgICB8IEh5cGVydmlzb3Ig VlRFUCAoSVAxKSAgICB8CiAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsKICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAr LS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICB8ICAgTGF5ZXIg MyAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS18ICAgTmV0d29yayAgIHwKICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLSsKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICArLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgICBIeXBlcnZpc29yIFZURVAgKElQMikgfAogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwgKy0tLS0rLS0tLSsgICstLS0tKy0tLS0rIHwKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHxWTTItMSAgICB8ICB8Vk0yLTIg ICAgfCB8CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCB8Vk5JIDEw MCAgfCAgfFZOSSAyMDAgIHwgfAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgfCAgICAgICAgIHwgIHwgICAgICAgICB8IHwKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8ICstLS0tLS0tLS0rICArLS0tLS0tLS0tKyB8CiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgIFNlcnZlciAyICAgICAgICAgICAg fAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSsKCgogICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMTogUmVmZXJlbmNl IFZYTEFOIERvbWFpbgoKCgoKUGFsbGFnYXR0aSwgZXQgYWwuICAgICAgRXhwaXJlcyBEZWNlbWJl ciAxOCwgMjAxOSAgICAgICAgICAgICAgIFtQYWdlIDRdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAg ICAgICAgICAgQkZEIGZvciBWWExBTiAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDE5CgoKNC4g IEJGRCBQYWNrZXQgVHJhbnNtaXNzaW9uIG92ZXIgVlhMQU4gVHVubmVsCgogICBCRkQgcGFja2V0 IE1VU1QgYmUgZW5jYXBzdWxhdGVkIGFuZCBzZW50IHRvIGEgcmVtb3RlIFZURVAgYXMKICAgZXhw bGFpbmVkIGluIHRoaXMgc2VjdGlvbi4gIEltcGxlbWVudGF0aW9ucyBTSE9VTEQgZW5zdXJlIHRo YXQgdGhlCiAgIEJGRCBwYWNrZXRzIGZvbGxvdyB0aGUgc2FtZSBsb29rdXAgcGF0aCBhcyBWWExB TiBkYXRhIHBhY2tldHMgd2l0aGluCiAgIHRoZSBzZW5kZXIgc3lzdGVtLgoKICAgQkZEIHBhY2tl dHMgYXJlIGVuY2Fwc3VsYXRlZCBpbiBWWExBTiBhcyBkZXNjcmliZWQgYmVsb3cuICBUaGUgVlhM QU4KICAgcGFja2V0IGZvcm1hdCBpcyBkZWZpbmVkIGluIFNlY3Rpb24gNSBvZiBbUkZDNzM0OF0u ICBUaGUgT3V0ZXIgSVAvVURQCiAgIGFuZCBWWExBTiBoZWFkZXJzIE1VU1QgYmUgZW5jb2RlZCBi eSB0aGUgc2VuZGVyIGFzIGRlZmluZWQgaW4KICAgW1JGQzczNDhdLgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKUGFsbGFnYXR0aSwgZXQgYWwuICAgICAgRXhwaXJlcyBE ZWNlbWJlciAxOCwgMjAxOSAgICAgICAgICAgICAgIFtQYWdlIDVdCgwKSW50ZXJuZXQtRHJhZnQg ICAgICAgICAgICAgICAgQkZEIGZvciBWWExBTiAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDE5 CgoKICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAg ICAgICAgICAgICAzCiAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIH4g ICAgICAgICAgICAgICAgICAgICAgT3V0ZXIgRXRoZXJuZXQgSGVhZGVyICAgICAgICAgICAgICAg ICAgICB+CiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfAogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgIHwgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB+ICAgICAg ICAgICAgICAgICAgICAgICAgT3V0ZXIgSVB2WCBIZWFkZXIgICAgICAgICAgICAgICAgICAgICAg fgogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwKICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgfiAgICAgICAgICAg ICAgICAgICAgICAgIE91dGVyIFVEUCBIZWFkZXIgICAgICAgICAgICAgICAgICAgICAgIH4KICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8CiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKwogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgIH4gICAgICAgICAgICAgICAg ICAgICAgICAgICBWWExBTiBIZWFkZXIgICAgICAgICAgICAgICAgICAgICAgICB+CiAgICB8ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfAogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSsKICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICB+ICAgICAgICAgICAgICAgICAgICBJ bm5lciBFdGhlcm5ldCBIZWFkZXIgICAgICAgICAgICAgICAgICAgICAgfgogICAgfCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rCiAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgfiAgICAgICAgICAgICAgICAgICAgICAgIElu bmVyIElQdlggSGVhZGVyICAgICAgICAgICAgICAgICAgICAgIH4KICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKwogICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwKICAgIH4gICAgICAgICAgICAgICAgICAgICAgICAgSW5uZXIg VURQIEhlYWRlciAgICAgICAgICAgICAgICAgICAgICB+CiAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsKICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8CiAgICB+ICAgICAgICAgICAgICAgICAgICAgICBCRkQgQ29udHJvbCBN ZXNzYWdlICAgICAgICAgICAgICAgICAgICAgfgogICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rCiAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEZDUyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfAogICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsKCiAgICAgICAgICAgRmlndXJlIDI6IFZYTEFOIEVuY2Fw c3VsYXRpb24gb2YgQkZEIENvbnRyb2wgTWVzc2FnZQoKICAgVGhlIEJGRCBwYWNrZXQgTVVTVCBi ZSBjYXJyaWVkIGluc2lkZSB0aGUgaW5uZXIgTUFDIGZyYW1lIG9mIHRoZQogICBWWExBTiBwYWNr ZXQuICBUaGUgaW5uZXIgTUFDIGZyYW1lIGNhcnJ5aW5nIHRoZSBCRkQgcGF5bG9hZCBoYXMgdGhl CiAgIGZvbGxvd2luZyBmb3JtYXQ6CgogICAgICBFdGhlcm5ldCBIZWFkZXI6CgogICAgICAgICBE ZXN0aW5hdGlvbiBNQUM6IFRoaXMgTVVTVCBiZSB0aGUgTUFDIGFkZHJlc3Mgb2YgdGhlCiAgICAg ICAgIGRlc3RpbmF0aW9uIFZURVAuICBUaGUgTUFDIGFkZHJlc3MgTUFZIGJlIGNvbmZpZ3VyZWQg b3IgaXQgTUFZCgoKClBhbGxhZ2F0dGksIGV0IGFsLiAgICAgIEV4cGlyZXMgRGVjZW1iZXIgMTgs IDIwMTkgICAgICAgICAgICAgICBbUGFnZSA2XQoMCkludGVybmV0LURyYWZ0ICAgICAgICAgICAg ICAgIEJGRCBmb3IgVlhMQU4gICAgICAgICAgICAgICAgICAgIEp1bmUgMjAxOQoKCiAgICAgICAg IGJlIGxlYXJuZWQgdmlhIGEgY29udHJvbCBwbGFuZSBwcm90b2NvbC4gIFRoZSBkZXRhaWxzIG9m IGhvdwogICAgICAgICB0aGUgTUFDIGFkZHJlc3Mgb2YgdGhlIGRlc3RpbmF0aW9uIFZURVAgaXMg b2J0YWluZWQgYXJlIG91dHNpZGUKICAgICAgICAgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQu CgogICAgICAgICBTb3VyY2UgTUFDOiBNQUMgYWRkcmVzcyBvZiB0aGUgb3JpZ2luYXRpbmcgVlRF UAoKICAgICAgSVAgaGVhZGVyOgoKICAgICAgICAgU291cmNlIElQOiBJUCBhZGRyZXNzIG9mIHRo ZSBvcmlnaW5hdGluZyBWVEVQLgoKICAgICAgICAgRGVzdGluYXRpb24gSVA6IElQIGFkZHJlc3Mg b2YgdGhlIHRlcm1pbmF0aW5nIFZURVAuCgogICAgICAgICBUVEw6IE1VU1QgYmUgc2V0IHRvIDEg dG8gZW5zdXJlIHRoYXQgdGhlIEJGRCBwYWNrZXQgaXMgbm90CiAgICAgICAgIHJvdXRlZCB3aXRo aW4gdGhlIEwzIHVuZGVybGF5IG5ldHdvcmsuCgogICAgICBUaGUgZmllbGRzIG9mIHRoZSBVRFAg aGVhZGVyIGFuZCB0aGUgQkZEIGNvbnRyb2wgcGFja2V0IGFyZQogICAgICBlbmNvZGVkIGFzIHNw ZWNpZmllZCBpbiBbUkZDNTg4MV0uCgo1LiAgUmVjZXB0aW9uIG9mIEJGRCBQYWNrZXQgZnJvbSBW WExBTiBUdW5uZWwKCiAgIE9uY2UgYSBwYWNrZXQgaXMgcmVjZWl2ZWQsIFZURVAgTVVTVCB2YWxp ZGF0ZSB0aGUgcGFja2V0LiAgSWYgdGhlCiAgIERlc3RpbmF0aW9uIE1BQyBvZiB0aGUgaW5uZXIg TUFDIGZyYW1lIG1hdGNoZXMgdGhlIE1BQyBhZGRyZXNzIG9mIHRoZQogICBWVEVQIHRoZSBwYWNr ZXQgTVVTVCBiZSBwcm9jZXNzZWQgZnVydGhlci4KCiAgIFRoZSBVRFAgZGVzdGluYXRpb24gcG9y dCBhbmQgdGhlIFRUTCBvZiB0aGUgaW5uZXIgSVAgcGFja2V0IE1VU1QgYmUKICAgdmFsaWRhdGVk IHRvIGRldGVybWluZSBpZiB0aGUgcmVjZWl2ZWQgcGFja2V0IGNhbiBiZSBwcm9jZXNzZWQgYnkK ICAgQkZELiAgQkZEIHBhY2tldCB3aXRoIGlubmVyIE1BQyBzZXQgdG8gVlRFUCdzIE1BQyBhZGRy ZXNzIE1VU1QgTk9UIGJlCiAgIGZvcndhcmRlZCB0byBWTXMuCgo1LjEuICBEZW11bHRpcGxleGlu ZyBvZiB0aGUgQkZEIFBhY2tldAoKICAgRGVtdWx0aXBsZXhpbmcgb2YgSVAgQkZEIHBhY2tldCBo YXMgYmVlbiBkZWZpbmVkIGluIFNlY3Rpb24gMyBvZgogICBbUkZDNTg4MV0uICBTaW5jZSBtdWx0 aXBsZSBCRkQgc2Vzc2lvbnMgbWF5IGJlIHJ1bm5pbmcgYmV0d2VlbiB0d28KICAgVlRFUHMsIHRo ZXJlIG5lZWRzIHRvIGJlIGEgbWVjaGFuaXNtIGZvciBkZW11bHRpcGxleGluZyByZWNlaXZlZCBC RkQKICAgcGFja2V0cyB0byB0aGUgcHJvcGVyIHNlc3Npb24uICBUaGUgcHJvY2VkdXJlIGZvciBk ZW11bHRpcGxleGluZwogICBwYWNrZXRzIHdpdGggWW91ciBEaXNjcmltaW5hdG9yIGVxdWFsIHRv IDAgaXMgZGlmZmVyZW50IGZyb20KICAgW1JGQzU4ODBdLiAgRm9yIHN1Y2ggcGFja2V0cywgdGhl IEJGRCBzZXNzaW9uIE1VU1QgYmUgaWRlbnRpZmllZAogICB1c2luZyB0aGUgaW5uZXIgaGVhZGVy cywgaS5lLiwgdGhlIHNvdXJjZSBJUCwgdGhlIGRlc3RpbmF0aW9uIElQLCBhbmQKICAgdGhlIHNv dXJjZSBVRFAgcG9ydCBudW1iZXIgcHJlc2VudCBpbiB0aGUgSVAgaGVhZGVyIGNhcnJpZWQgYnkg dGhlCiAgIHBheWxvYWQgb2YgdGhlIFZYTEFOIGVuY2Fwc3VsYXRlZCBwYWNrZXQuICBUaGUgVk5J IG9mIHRoZSBwYWNrZXQKICAgU0hPVUxEIGJlIHVzZWQgdG8gZGVyaXZlIGludGVyZmFjZS1yZWxh dGVkIGluZm9ybWF0aW9uIGZvcgogICBkZW11bHRpcGxleGluZyB0aGUgcGFja2V0LiAgSWYgQkZE IHBhY2tldCBpcyByZWNlaXZlZCB3aXRoIG5vbi16ZXJvCiAgIFlvdXIgRGlzY3JpbWluYXRvciwg dGhlbiBCRkQgc2Vzc2lvbiBNVVNUIGJlIGRlbXVsdGlwbGV4ZWQgb25seSB3aXRoCiAgIFlvdXIg RGlzY3JpbWluYXRvciBhcyB0aGUga2V5LgoKCgoKCgoKUGFsbGFnYXR0aSwgZXQgYWwuICAgICAg RXhwaXJlcyBEZWNlbWJlciAxOCwgMjAxOSAgICAgICAgICAgICAgIFtQYWdlIDddCgwKSW50ZXJu ZXQtRHJhZnQgICAgICAgICAgICAgICAgQkZEIGZvciBWWExBTiAgICAgICAgICAgICAgICAgICAg SnVuZSAyMDE5CgoKNi4gIFVzZSBvZiB0aGUgU3BlY2lmaWMgVk5JCgogICBJbiBtb3N0IGNhc2Vz LCBhIHNpbmdsZSBCRkQgc2Vzc2lvbiBpcyBzdWZmaWNpZW50IGZvciB0aGUgZ2l2ZW4gVlRFUAog ICB0byBtb25pdG9yIHRoZSByZWFjaGFiaWxpdHkgb2YgYSByZW1vdGUgVlRFUCwgcmVnYXJkbGVz cyBvZiB0aGUKICAgbnVtYmVyIG9mIFZOSXMgaW4gY29tbW9uLiAgV2hlbiB0aGUgc2luZ2xlIEJG RCBzZXNzaW9uIGlzIHVzZWQgdG8KICAgbW9uaXRvciB0aGUgcmVhY2hhYmlsaXR5IG9mIHRoZSBy ZW1vdGUgVlRFUCwgYW4gaW1wbGVtZW50YXRpb24gU0hPVUxECiAgIGNob29zZSBhbnkgb2YgdGhl IFZOSXMgYnV0IE1BWSBjaG9vc2UgVk5JID0gMC4KCjcuICBFY2hvIEJGRAoKICAgU3VwcG9ydCBm b3IgZWNobyBCRkQgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4KCjguICBJ QU5BIENvbnNpZGVyYXRpb25zCgogICBUaGlzIHNwZWNpZmljYXRpb24gaGFzIG5vIElBTkEgYWN0 aW9uIHJlcXVlc3RlZC4gIFRoaXMgc2VjdGlvbiBtYXkgYmUKICAgZGVsZXRlZCBiZWZvcmUgdGhl IHB1YmxpY2F0aW9uLgoKOS4gIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zCgogICBUaGUgZG9jdW1l bnQgcmVxdWlyZXMgc2V0dGluZyB0aGUgaW5uZXIgSVAgVFRMIHRvIDEsIHdoaWNoIGNvdWxkIGJl CiAgIHVzZWQgYXMgYSBERG9TIGF0dGFjayB2ZWN0b3IuICBUaHVzIHRoZSBpbXBsZW1lbnRhdGlv biBNVVNUIGhhdmUKICAgdGhyb3R0bGluZyBpbiBwbGFjZSB0byBjb250cm9sIHRoZSByYXRlIG9m IEJGRCBjb250cm9sIHBhY2tldHMgc2VudAogICB0byB0aGUgY29udHJvbCBwbGFuZS4gIE9uIHRo ZSBvdGhlciBoYW5kLCBvdmVyIGFnZ3Jlc3NpdmUgdGhyb3R0bGluZwogICBvZiBCRkQgY29udHJv bCBwYWNrZXRzIG1heSBiZWNvbWUgdGhlIGNhdXNlIG9mIHRoZSBpbmFiaWxpdHkgdG8gZm9ybQog ICBhbmQgbWFpbnRhaW4gQkZEIHNlc3Npb24gYXQgc2NhbGUuICBIZW5jZSwgdGhyb3R0bGluZyBv ZiBCRkQgY29udHJvbAogICBwYWNrZXRzIFNIT1VMRCBiZSBhZGp1c3RlZCB0byBwZXJtaXQgQkZE IHRvIHdvcmsgYWNjb3JkaW5nIHRvIGl0cwogICBwcm9jZWR1cmVzLgoKICAgSWYgdGhlIGltcGxl bWVudGF0aW9uIHN1cHBvcnRzIGVzdGFibGlzaGluZyBtdWx0aXBsZSBCRkQgc2Vzc2lvbnMKICAg YmV0d2VlbiB0aGUgc2FtZSBwYWlyIG9mIFZURVBzLCB0aGVyZSBTSE9VTEQgYmUgYSBtZWNoYW5p c20gdG8KICAgY29udHJvbCB0aGUgbWF4aW11bSBudW1iZXIgb2Ygc3VjaCBzZXNzaW9uIHRoYXQg Y2FuIGJlIGFjdGl2ZSBhdCB0aGUKICAgc2FtZSB0aW1lLgoKICAgT3RoZXIgdGhhbiBpbm5lciBJ UCBUVEwgc2V0IHRvIDEgYW5kIGxpbWl0IHRoZSBudW1iZXIgb2YgQkZEIHNlc3Npb25zCiAgIGJl dHdlZW4gdGhlIHNhbWUgcGFpciBvZiBWVEVQcywgdGhpcyBzcGVjaWZpY2F0aW9uIGRvZXMgbm90 IHJhaXNlIGFueQogICBhZGRpdGlvbmFsIHNlY3VyaXR5IGlzc3VlcyBiZXlvbmQgdGhvc2Ugb2Yg dGhlIHNwZWNpZmljYXRpb25zCiAgIHJlZmVycmVkIHRvIGluIHRoZSBsaXN0IG9mIG5vcm1hdGl2 ZSByZWZlcmVuY2VzLgoKMTAuICBDb250cmlidXRvcnMKCgogICBSZXNoYWQgUmFobWFuCiAgIHJy YWhtYW5AY2lzY28uY29tCiAgIENpc2NvCgoKCgoKCgpQYWxsYWdhdHRpLCBldCBhbC4gICAgICBF eHBpcmVzIERlY2VtYmVyIDE4LCAyMDE5ICAgICAgICAgICAgICAgW1BhZ2UgOF0KDApJbnRlcm5l dC1EcmFmdCAgICAgICAgICAgICAgICBCRkQgZm9yIFZYTEFOICAgICAgICAgICAgICAgICAgICBK dW5lIDIwMTkKCgoxMS4gIEFja25vd2xlZGdtZW50cwoKICAgQXV0aG9ycyB3b3VsZCBsaWtlIHRv IHRoYW5rIEplZmYgSGFhcyBvZiBKdW5pcGVyIE5ldHdvcmtzIGZvciBoaXMKICAgcmV2aWV3cyBh bmQgZmVlZGJhY2sgb24gdGhpcyBtYXRlcmlhbC4KCiAgIEF1dGhvcnMgd291bGQgYWxzbyBsaWtl IHRvIHRoYW5rIE5vYm8gQWtpeWEsIE1hcmMgQmluZGVyYmVyZ2VyLAogICBTaGFocmFtIERhdmFy aSwgRG9uYWxkIEUuICBFYXN0bGFrZSAzcmQsIGFuZCBBbm9vcCBHaGFud2FuaSBmb3IgdGhlCiAg IGV4dGVuc2l2ZSByZXZpZXdzIGFuZCB0aGUgbW9zdCBkZXRhaWxlZCBhbmQgaGVscGZ1bCBjb21t ZW50cy4KCjEyLiAgUmVmZXJlbmNlcwoKMTIuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzCgogICBb UkZDMjExOV0gIEJyYWRuZXIsIFMuLCAiS2V5IHdvcmRzIGZvciB1c2UgaW4gUkZDcyB0byBJbmRp Y2F0ZQogICAgICAgICAgICAgIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTks CiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzIxMTksIE1hcmNoIDE5OTcsCiAgICAgICAg ICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjMjExOT4uCgogICBbUkZD NTg4MF0gIEthdHosIEQuIGFuZCBELiBXYXJkLCAiQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERl dGVjdGlvbgogICAgICAgICAgICAgIChCRkQpIiwgUkZDIDU4ODAsIERPSSAxMC4xNzQ4Ny9SRkM1 ODgwLCBKdW5lIDIwMTAsCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3Jn L2luZm8vcmZjNTg4MD4uCgogICBbUkZDNTg4MV0gIEthdHosIEQuIGFuZCBELiBXYXJkLCAiQmlk aXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbgogICAgICAgICAgICAgIChCRkQpIGZvciBJ UHY0IGFuZCBJUHY2IChTaW5nbGUgSG9wKSIsIFJGQyA1ODgxLAogICAgICAgICAgICAgIERPSSAx MC4xNzQ4Ny9SRkM1ODgxLCBKdW5lIDIwMTAsCiAgICAgICAgICAgICAgPGh0dHBzOi8vd3d3LnJm Yy1lZGl0b3Iub3JnL2luZm8vcmZjNTg4MT4uCgogICBbUkZDNzM0OF0gIE1haGFsaW5nYW0sIE0u LCBEdXR0LCBELiwgRHVkYSwgSy4sIEFnYXJ3YWwsIFAuLCBLcmVlZ2VyLAogICAgICAgICAgICAg IEwuLCBTcmlkaGFyLCBULiwgQnVyc2VsbCwgTS4sIGFuZCBDLiBXcmlnaHQsICJWaXJ0dWFsCiAg ICAgICAgICAgICAgZVh0ZW5zaWJsZSBMb2NhbCBBcmVhIE5ldHdvcmsgKFZYTEFOKTogQSBGcmFt ZXdvcmsgZm9yCiAgICAgICAgICAgICAgT3ZlcmxheWluZyBWaXJ0dWFsaXplZCBMYXllciAyIE5l dHdvcmtzIG92ZXIgTGF5ZXIgMwogICAgICAgICAgICAgIE5ldHdvcmtzIiwgUkZDIDczNDgsIERP SSAxMC4xNzQ4Ny9SRkM3MzQ4LCBBdWd1c3QgMjAxNCwKICAgICAgICAgICAgICA8aHR0cHM6Ly93 d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM3MzQ4Pi4KCiAgIFtSRkM4MTc0XSAgTGVpYmEsIEIu LCAiQW1iaWd1aXR5IG9mIFVwcGVyY2FzZSB2cyBMb3dlcmNhc2UgaW4gUkZDCiAgICAgICAgICAg ICAgMjExOSBLZXkgV29yZHMiLCBCQ1AgMTQsIFJGQyA4MTc0LCBET0kgMTAuMTc0ODcvUkZDODE3 NCwKICAgICAgICAgICAgICBNYXkgMjAxNywgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2lu Zm8vcmZjODE3ND4uCgoxMi4yLiAgSW5mb3JtYXRpb25hbCBSZWZlcmVuY2VzCgogICBbUkZDODI5 M10gIEdoYW53YW5pLCBBLiwgRHVuYmFyLCBMLiwgTWNCcmlkZSwgTS4sIEJhbm5haSwgVi4sIGFu ZCBSLgogICAgICAgICAgICAgIEtyaXNobmFuLCAiQSBGcmFtZXdvcmsgZm9yIE11bHRpY2FzdCBp biBOZXR3b3JrCiAgICAgICAgICAgICAgVmlydHVhbGl6YXRpb24gb3ZlciBMYXllciAzIiwgUkZD IDgyOTMsCiAgICAgICAgICAgICAgRE9JIDEwLjE3NDg3L1JGQzgyOTMsIEphbnVhcnkgMjAxOCwK ICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvaW5mby9yZmM4MjkzPi4K CgoKCgoKUGFsbGFnYXR0aSwgZXQgYWwuICAgICAgRXhwaXJlcyBEZWNlbWJlciAxOCwgMjAxOSAg ICAgICAgICAgICAgIFtQYWdlIDldCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgICAgICAgICAgQkZE IGZvciBWWExBTiAgICAgICAgICAgICAgICAgICAgSnVuZSAyMDE5CgoKICAgW1JGQzgzNjVdICBT YWphc3NpLCBBLiwgRWQuLCBEcmFrZSwgSi4sIEVkLiwgQml0YXIsIE4uLCBTaGVraGFyLCBSLiwK ICAgICAgICAgICAgICBVdHRhcm8sIEouLCBhbmQgVy4gSGVuZGVyaWNreCwgIkEgTmV0d29yayBW aXJ0dWFsaXphdGlvbgogICAgICAgICAgICAgIE92ZXJsYXkgU29sdXRpb24gVXNpbmcgRXRoZXJu ZXQgVlBOIChFVlBOKSIsIFJGQyA4MzY1LAogICAgICAgICAgICAgIERPSSAxMC4xNzQ4Ny9SRkM4 MzY1LCBNYXJjaCAyMDE4LAogICAgICAgICAgICAgIDxodHRwczovL3d3dy5yZmMtZWRpdG9yLm9y Zy9pbmZvL3JmYzgzNjU+LgoKQXV0aG9ycycgQWRkcmVzc2VzCgogICBTYW50b3NoIFBhbGxhZ2F0 dGkgKGVkaXRvcikKICAgUnRicmljawoKICAgRW1haWw6IHNhbnRvc2gucGFsbGFnYXR0aUBnbWFp bC5jb20KCgogICBTdWRhcnNhbiBQYXJhZ2lyaQogICBJbmRpdmlkdWFsIENvbnRyaWJ1dG9yCgog ICBFbWFpbDogc3VkYXJzYW4uMjI1QGdtYWlsLmNvbQoKCiAgIFZlbmdhZGEgUHJhc2FkIEdvdmlu ZGFuCiAgIENpc2NvCgogICBFbWFpbDogdmVuZ2dvdmlAY2lzY28uY29tCgoKICAgTWFsbGlrIE11 ZGlnb25kYQogICBDaXNjbwoKICAgRW1haWw6IG1tdWRpZ29uQGNpc2NvLmNvbQoKCiAgIEdyZWcg TWlyc2t5CiAgIFpURSBDb3JwLgoKICAgRW1haWw6IGdyZWdpbWlyc2t5QGdtYWlsLmNvbQoKCgoK CgoKCgoKCgoKCgpQYWxsYWdhdHRpLCBldCBhbC4gICAgICBFeHBpcmVzIERlY2VtYmVyIDE4LCAy MDE5ICAgICAgICAgICAgICBbUGFnZSAxMF0K --0000000000002bb946058b7ddcb6 Content-Type: text/html; charset="UTF-8"; name="Diff_ draft-ietf-bfd-vxlan-07.txt - draft-ietf-bfd-vxlan-08.txt.html" Content-Disposition: attachment; filename="Diff_ draft-ietf-bfd-vxlan-07.txt - draft-ietf-bfd-vxlan-08.txt.html" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jwzwqxpj0 PCFET0NUWVBFIGh0bWwgUFVCTElDICItLy9XM0MvL0RURCBYSFRNTCAxLjAgVHJhbnNpdGlvbmFs Ly9FTiIgImh0dHA6Ly93d3cudzMub3JnL1RSL3hodG1sMS9EVEQveGh0bWwxLXRyYW5zaXRpb25h bC5kdGQiPgo8IS0tIHNhdmVkIGZyb20gdXJsPSgwMDQyKWh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9y ZmNkaWZmL3JmY2RpZmYucHlodCAtLT4KPGh0bWwgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzE5 OTkveGh0bWwiIGNsYXNzPSJncl9fd3d3Nl9pZXRmX29yZyI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPiAKICAg CiAgPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1TdHlsZS1UeXBlIiBjb250ZW50PSJ0ZXh0L2Nz cyI+IAogIDx0aXRsZT5EaWZmOiBkcmFmdC1pZXRmLWJmZC12eGxhbi0wNy50eHQgLSBkcmFmdC1p ZXRmLWJmZC12eGxhbi0wOC50eHQ8L3RpdGxlPiAKICA8c3R5bGUgdHlwZT0idGV4dC9jc3MiPiAK ICAgIGJvZHkgICAgeyBtYXJnaW46IDAuNGV4OyBtYXJnaW4tcmlnaHQ6IGF1dG87IH0gCiAgICB0 ciAgICAgIHsgfSAKICAgIHRkICAgICAgeyB3aGl0ZS1zcGFjZTogcHJlOyBmb250LWZhbWlseTog bW9ub3NwYWNlOyB2ZXJ0aWNhbC1hbGlnbjogdG9wOyBmb250LXNpemU6IDAuODZlbTt9IAogICAg dGggICAgICB7IGZvbnQtc2l6ZTogMC44NmVtOyB9IAogICAgLnNtYWxsICB7IGZvbnQtc2l6ZTog MC42ZW07IGZvbnQtc3R5bGU6IGl0YWxpYzsgZm9udC1mYW1pbHk6IFZlcmRhbmEsIEhlbHZldGlj YSwgc2Fucy1zZXJpZjsgfSAKICAgIC5sZWZ0ICAgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjRUVFOyB9 IAogICAgLnJpZ2h0ICB7IGJhY2tncm91bmQtY29sb3I6ICNGRkY7IH0gCiAgICAuZGlmZiAgIHsg YmFja2dyb3VuZC1jb2xvcjogI0NDRjsgfSAKICAgIC5sYmxvY2sgeyBiYWNrZ3JvdW5kLWNvbG9y OiAjQkZCOyB9IAogICAgLnJibG9jayB7IGJhY2tncm91bmQtY29sb3I6ICNGRjg7IH0gCiAgICAu aW5zZXJ0IHsgYmFja2dyb3VuZC1jb2xvcjogIzhGRjsgfSAKICAgIC5kZWxldGUgeyBiYWNrZ3Jv dW5kLWNvbG9yOiAjQUNGOyB9IAogICAgLnZvaWQgICB7IGJhY2tncm91bmQtY29sb3I6ICNGRkI7 IH0gCiAgICAuY29udCAgIHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgfSAKICAgIC5saW5lYnIg eyBiYWNrZ3JvdW5kLWNvbG9yOiAjQUFBOyB9IAogICAgLmxpbmVubyB7IGNvbG9yOiByZWQ7IGJh Y2tncm91bmQtY29sb3I6ICNGRkY7IGZvbnQtc2l6ZTogMC43ZW07IHRleHQtYWxpZ246IHJpZ2h0 OyBwYWRkaW5nOiAwIDJweDsgfSAKICAgIC5lbGlwc2lzeyBiYWNrZ3JvdW5kLWNvbG9yOiAjQUFB OyB9IAogICAgLmxlZnQgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjREREOyB9IAogICAgLnJp Z2h0IC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjogI0VFRTsgfSAKICAgIC5sYmxvY2sgLmNvbnQg eyBiYWNrZ3JvdW5kLWNvbG9yOiAjOUQ5OyB9IAogICAgLnJibG9jayAuY29udCB7IGJhY2tncm91 bmQtY29sb3I6ICNERDY7IH0gCiAgICAuaW5zZXJ0IC5jb250IHsgYmFja2dyb3VuZC1jb2xvcjog IzBERDsgfSAKICAgIC5kZWxldGUgLmNvbnQgeyBiYWNrZ3JvdW5kLWNvbG9yOiAjOEFEOyB9IAog ICAgLnN0YXRzLCAuc3RhdHMgdGQsIC5zdGF0cyB0aCB7IGJhY2tncm91bmQtY29sb3I6ICNFRUU7 IHBhZGRpbmc6IDJweCAwOyB9IAogICAgc3Bhbi5oaWRlIHsgZGlzcGxheTogbm9uZTsgY29sb3I6 ICNhYWE7fSAgICBhOmhvdmVyIHNwYW4geyBkaXNwbGF5OiBpbmxpbmU7IH0gICAgdHIuY2hhbmdl IHsgYmFja2dyb3VuZC1jb2xvcjogZ3JheTsgfSAKICAgIHRyLmNoYW5nZSBhIHsgdGV4dC1kZWNv cmF0aW9uOiBub25lOyBjb2xvcjogYmxhY2sgfSAKICA8L3N0eWxlPiAKICAgICA8c2NyaXB0Pgp2 YXIgY2h1bmtfaW5kZXggPSAwOwp2YXIgb2xkX2NodW5rID0gbnVsbDsKCmZ1bmN0aW9uIGZvcm1h dF9jaHVuayhpbmRleCkgewogICAgdmFyIHByZWZpeCA9ICJkaWZmIjsKICAgIHZhciBzdHIgPSBp bmRleC50b1N0cmluZygpOwogICAgZm9yICh4PTA7IHg8KDQtc3RyLmxlbmd0aCk7ICsreCkgewog ICAgICAgIHByZWZpeCs9JzAnOwogICAgfQogICAgcmV0dXJuIHByZWZpeCArIHN0cjsKfQoKZnVu Y3Rpb24gZmluZF9jaHVuayhuKXsKICAgIHJldHVybiBkb2N1bWVudC5xdWVyeVNlbGVjdG9yKCd0 cltpZCQ9IicgKyBuICsgJyJdJyk7Cn0KCmZ1bmN0aW9uIGNoYW5nZV9jaHVuayhvZmZzZXQpIHsK ICAgIHZhciBpbmRleCA9IGNodW5rX2luZGV4ICsgb2Zmc2V0OwogICAgdmFyIG5ld19zdHI7CiAg ICB2YXIgbmV3X2NodW5rOwoKICAgIG5ld19zdHIgPSBmb3JtYXRfY2h1bmsoaW5kZXgpOwogICAg bmV3X2NodW5rID0gZmluZF9jaHVuayhuZXdfc3RyKTsKICAgIGlmICghbmV3X2NodW5rKSB7CiAg ICAgICAgcmV0dXJuOwogICAgfQogICAgaWYgKG9sZF9jaHVuaykgewogICAgICAgIG9sZF9jaHVu ay5zdHlsZS5vdXRsaW5lID0gIiI7CiAgICB9CiAgICBvbGRfY2h1bmsgPSBuZXdfY2h1bms7CiAg ICBvbGRfY2h1bmsuc3R5bGUub3V0bGluZSA9ICIxcHggc29saWQgcmVkIjsKICAgIHdpbmRvdy5s b2NhdGlvbi5yZXBsYWNlKCIjIiArIG5ld19zdHIpCiAgICB3aW5kb3cuc2Nyb2xsQnkoMCwtMTAw KTsKICAgIGNodW5rX2luZGV4ID0gaW5kZXg7Cn0KCmRvY3VtZW50Lm9ua2V5ZG93biA9IGZ1bmN0 aW9uKGUpIHsKICAgIHN3aXRjaCAoZS5rZXlDb2RlKSB7CiAgICBjYXNlIDc4OgogICAgICAgIGNo YW5nZV9jaHVuaygxKTsKICAgICAgICBicmVhazsKICAgIGNhc2UgODA6CiAgICAgICAgY2hhbmdl X2NodW5rKC0xKTsKICAgICAgICBicmVhazsKICAgIH0KfTsKICAgPC9zY3JpcHQ+IAo8L2hlYWQ+ IAo8Ym9keSBkYXRhLWdyLWMtcy1sb2FkZWQ9InRydWUiPiAKICA8dGFibGUgYm9yZGVyPSIwIiBj ZWxscGFkZGluZz0iMCIgY2VsbHNwYWNpbmc9IjAiPiAKICA8dGJvZHk+PHRyIGlkPSJwYXJ0LTEi IGJnY29sb3I9Im9yYW5nZSI+PHRoPjwvdGg+PHRoPjxhIGhyZWY9Imh0dHBzOi8vd3d3Ni5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1iZmQtdnhsYW4tMDcudHh0IiBzdHlsZT0iY29s b3I6IzAwODsgdGV4dC1kZWNvcmF0aW9uOm5vbmU7Ij4mbHQ7PC9hPiZuYnNwOzxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWJmZC12eGxhbi0wNy50eHQiIHN0 eWxlPSJjb2xvcjojMDA4Ij5kcmFmdC1pZXRmLWJmZC12eGxhbi0wNy50eHQ8L2E+Jm5ic3A7PC90 aD48dGg+IDwvdGg+PHRoPiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLWJmZC12eGxhbi0wOC50eHQiIHN0eWxlPSJjb2xvcjojMDA4Ij5kcmFmdC1p ZXRmLWJmZC12eGxhbi0wOC50eHQ8L2E+Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3c2LmlldGYu b3JnL3JmY2RpZmY/dXJsMT1kcmFmdC1pZXRmLWJmZC12eGxhbi0wOC50eHQiIHN0eWxlPSJjb2xv cjojMDA4OyB0ZXh0LWRlY29yYXRpb246bm9uZTsiPiZndDs8L2E+PC90aD48dGg+PC90aD48L3Ry PiAKICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij5CRkQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBT LiBQYWxsYWdhdHRpLCBFZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij5CRkQgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTLiBQYWxsYWdh dHRpLCBFZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkludGVybmV0LURyYWZ0ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUnRicmljazwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUnRicmljazwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+SW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIFMuIFBhcmFnaXJpPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+SW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIFMuIFBhcmFnaXJpPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHIgaWQ9ImRpZmYwMDAxIj48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPkV4cGlyZXM6IDxzcGFuIGNsYXNzPSJk ZWxldGUiPk5vdjwvc3Bhbj5lbWJlciAxOCwgMjAxOSAgICAgICAgICAgICAgICAgICAgICAgIElu ZGl2aWR1YWwgQ29udHJpYnV0b3I8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+RXhw aXJlczogPHNwYW4gY2xhc3M9Imluc2VydCI+RGVjPC9zcGFuPmVtYmVyIDE4LCAyMDE5ICAgICAg ICAgICAgICAgICAgICAgICAgSW5kaXZpZHVhbCBDb250cmlidXRvcjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIFYuIEdvdmluZGFuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFYuIEdvdmluZGFuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNLiBNdWRp Z29uZGE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBNLiBNdWRpZ29uZGE8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBDaXNjbzwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBDaXNjbzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgRy4gTWlyc2t5PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Ry4gTWlyc2t5PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBaVEUgQ29ycC48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBaVEUgQ29ycC48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDIiPjx0ZD48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8c3BhbiBjbGFzcz0iZGVsZXRlIj4gTWF5IDE3PC9zcGFuPiwgMjAxOTwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPkp1bmUgMTY8L3NwYW4+ LCAyMDE5PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgQkZEIGZvciBWWExBTjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQkZEIGZvciBWWExBTjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAwMyI+PHRkPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICAgICAgICAgICAgICAgICAgICAgICBkcmFmdC1pZXRmLWJmZC12eGxhbi0wPHNwYW4gY2xhc3M9 ImRlbGV0ZSI+Nzwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAg ICAgICAgICAgICAgICAgICAgZHJhZnQtaWV0Zi1iZmQtdnhsYW4tMDxzcGFuIGNsYXNzPSJpbnNl cnQiPjg8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPkFic3RyYWN0PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+QWJzdHJhY3Q8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIHVzZSBvZiB0aGUg QmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIHVzZSBvZiB0aGUgQmlkaXJlY3Rpb25hbCBG b3J3YXJkaW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBEZXRlY3Rpb24gKEJGRCkg cHJvdG9jb2wgaW4gcG9pbnQtdG8tcG9pbnQgVmlydHVhbCBlWHRlbnNpYmxlIExvY2FsPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRGV0ZWN0aW9uIChCRkQpIHByb3RvY29sIGlu IHBvaW50LXRvLXBvaW50IFZpcnR1YWwgZVh0ZW5zaWJsZSBMb2NhbDwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgQXJlYSBOZXR3b3JrIChWWExBTikgdHVubmVscyBmb3JtaW5nIHVwIGFu IG92ZXJsYXkgbmV0d29yay48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBBcmVh IE5ldHdvcmsgKFZYTEFOKSB0dW5uZWxzIGZvcm1pbmcgdXAgYW4gb3ZlcmxheSBuZXR3b3JrLjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdo dCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij5TdGF0dXMgb2YgVGhpcyBNZW1vPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+U3RhdHVzIG9mIFRoaXMgTWVtbzwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGlzIEludGVybmV0LURyYWZ0IGlzIHN1Ym1pdHRl ZCBpbiBmdWxsIGNvbmZvcm1hbmNlIHdpdGggdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgVGhpcyBJbnRlcm5ldC1EcmFmdCBpcyBzdWJtaXR0ZWQgaW4gZnVsbCBjb25mb3Jt YW5jZSB3aXRoIHRoZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+ PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHIgaWQ9InBhcnQtMiIgY2xhc3M9ImNoYW5nZSI+PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lw cGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9y ZmNkaWZmL3JmY2RpZmYucHlodCNwYXJ0LTIiPjxlbT4gcGFnZSAxLCBsaW5lIDM4PHNwYW4gY2xh c3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0aD4gPC90aD48dGg+PHNtYWxsPnNr aXBwaW5nIHRvIGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93d3c2LmlldGYub3Jn L3JmY2RpZmYvcmZjZGlmZi5weWh0I3BhcnQtMiI+PGVtPiBwYWdlIDEsIGxpbmUgMzg8c3BhbiBj bGFzcz0iaGlkZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRkPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW50ZXJuZXQt RHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmc8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBJbnRlcm5ldC1EcmFmdHMgYXJlIHdv cmtpbmcgZG9jdW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZzwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+ICAgVGFzayBGb3JjZSAoSUVURikuICBOb3RlIHRoYXQgb3RoZXIgZ3Jv dXBzIG1heSBhbHNvIGRpc3RyaWJ1dGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBUYXNrIEZvcmNlIChJRVRGKS4gIE5vdGUgdGhhdCBvdGhlciBncm91cHMgbWF5IGFsc28gZGlz dHJpYnV0ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgd29ya2luZyBkb2N1bWVudHMg YXMgSW50ZXJuZXQtRHJhZnRzLiAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC08L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB3b3JraW5nIGRvY3VtZW50cyBhcyBJbnRlcm5l dC1EcmFmdHMuICBUaGUgbGlzdCBvZiBjdXJyZW50IEludGVybmV0LTwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgRHJhZnRzIGlzIGF0IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZHJhZnRzL2N1cnJlbnQvLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIERyYWZ0 cyBpcyBhdCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJyZW50Ly48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFm dCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVu dHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9udGhzPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBvciBvYnNvbGV0ZWQgYnkg b3RoZXIgZG9jdW1lbnRzIGF0IGFueTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBvdGhlciBkb2N1 bWVudHMgYXQgYW55PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB0aW1lLiAgSXQgaXMg aW5hcHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRv IHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs ZWZ0Ij4gICBtYXRlcmlhbCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBw cm9ncmVzcy4iPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgbWF0ZXJpYWwgb3Ig dG8gY2l0ZSB0aGVtIG90aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA0Ij48dGQ+ PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJs YmxvY2siPiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQgd2lsbCBleHBpcmUgb24gPHNwYW4gY2xhc3M9 ImRlbGV0ZSI+Tm92PC9zcGFuPmVtYmVyIDE4LCAyMDE5LjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICBUaGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIDxzcGFuIGNs YXNzPSJpbnNlcnQiPkRlYzwvc3Bhbj5lbWJlciAxOCwgMjAxOS48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+Q29weXJpZ2h0IE5vdGljZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPkNvcHlyaWdodCBOb3RpY2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgQ29weXJpZ2h0IChjKSAyMDE5IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZp ZWQgYXMgdGhlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQ29weXJpZ2h0IChj KSAyMDE5IElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJzb25zIGlkZW50aWZpZWQgYXMgdGhlPC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkb2N1bWVudCBhdXRob3JzLiAgQWxsIHJpZ2h0cyBy ZXNlcnZlZC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBkb2N1bWVudCBhdXRo b3JzLiAgQWxsIHJpZ2h0cyByZXNlcnZlZC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+ICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElFVEYgVHJ1 c3QncyBMZWdhbDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgZG9jdW1l bnQgaXMgc3ViamVjdCB0byBCQ1AgNzggYW5kIHRoZSBJRVRGIFRydXN0J3MgTGVnYWw8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFByb3Zpc2lvbnMgUmVsYXRpbmcgdG8gSUVURiBEb2N1 bWVudHM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBQcm92aXNpb25zIFJlbGF0 aW5nIHRvIElFVEYgRG9jdW1lbnRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAoaHR0 cHM6Ly90cnVzdGVlLmlldGYub3JnL2xpY2Vuc2UtaW5mbykgaW4gZWZmZWN0IG9uIHRoZSBkYXRl IG9mPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgKGh0dHBzOi8vdHJ1c3RlZS5p ZXRmLm9yZy9saWNlbnNlLWluZm8pIGluIGVmZmVjdCBvbiB0aGUgZGF0ZSBvZjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFz ZSByZXZpZXcgdGhlc2UgZG9jdW1lbnRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZpZXcgdGhlc2UgZG9j dW1lbnRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBp ZD0icGFydC0zIiBjbGFzcz0iY2hhbmdlIj48dGQ+PC90ZD48dGg+PHNtYWxsPnNraXBwaW5nIHRv IGNoYW5nZSBhdDwvc21hbGw+PGEgaHJlZj0iaHR0cHM6Ly93d3c2LmlldGYub3JnL3JmY2RpZmYv cmZjZGlmZi5weWh0I3BhcnQtMyI+PGVtPiBwYWdlIDIsIGxpbmUgMTc8c3BhbiBjbGFzcz0iaGlk ZSI+IMK2PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48c21hbGw+c2tpcHBpbmcg dG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3dzYuaWV0Zi5vcmcvcmZjZGlm Zi9yZmNkaWZmLnB5aHQjcGFydC0zIj48ZW0+IHBhZ2UgMiwgbGluZSAxNzxzcGFuIGNsYXNzPSJo aWRlIj4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBkZXNjcmliZWQgaW4gdGhl IFNpbXBsaWZpZWQgQlNEIExpY2Vuc2UuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgZGVzY3JpYmVkIGluIHRoZSBTaW1wbGlmaWVkIEJTRCBMaWNlbnNlLjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij5UYWJsZSBvZiBDb250ZW50czwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPlRhYmxlIG9mIENvbnRlbnRzPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIDEuICBJbnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuICAgMjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IDEuICBJbnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAgMjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgMi4gIENvbnZlbnRp b25zIHVzZWQgaW4gdGhpcyBkb2N1bWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAz PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgMi4gIENvbnZlbnRpb25zIHVzZWQg aW4gdGhpcyBkb2N1bWVudCAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzPC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgIDIuMS4gIFRlcm1pbm9sb2d5IC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDM8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICAgIDIuMS4gIFRlcm1pbm9sb2d5IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgMi4yLiAgUmVxdWlyZW1lbnRzIExhbmd1YWdlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuICAgMzwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgMi4yLiAg UmVxdWlyZW1lbnRzIExhbmd1YWdlIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu ICAgMzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgMy4gIERlcGxveW1lbnQgIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgMy4gIERlcGxveW1lbnQgIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA0PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICA0LiAgQkZEIFBhY2tldCBUcmFuc21pc3Npb24gb3ZlciBWWExBTiBUdW5u ZWwgLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICA0LiAgQkZEIFBhY2tldCBUcmFuc21pc3Npb24gb3ZlciBWWExBTiBUdW5uZWwgLiAuIC4g LiAuIC4gLiAuIC4gLiAgIDU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0ciBpZD0iZGlmZjAwMDUiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICA0 LjEuICBCRkQgUGFja2V0IEVuY2Fwc3VsYXRpb24gaW4gVlhMQU4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gICA2PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIDUuICBSZWNlcHRpb24gb2YgQkZEIFBhY2tldCBmcm9t IFZYTEFOIFR1bm5lbCAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNzwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIDUuICBSZWNlcHRpb24gb2YgQkZEIFBhY2tldCBmcm9tIFZYTEFOIFR1 bm5lbCAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNzwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgICA1LjEuICBEZW11bHRpcGxleGluZyBvZiB0aGUgQkZEIFBhY2tldCAgLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gICA3PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICA1LjEu ICBEZW11bHRpcGxleGluZyBvZiB0aGUgQkZEIFBhY2tldCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA3PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICA2LiAgVXNlIG9mIHRoZSBTcGVj aWZpYyBWTkkgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDg8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICA2LiAgVXNlIG9mIHRoZSBTcGVjaWZpYyBWTkkg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDg8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIDcuICBFY2hvIEJGRCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgODwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmln aHQiPiAgIDcuICBFY2hvIEJGRCAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAgODwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgOC4gIElB TkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gICA4PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgOC4gIElBTkEgQ29uc2lk ZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA4PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICA5LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDg8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICA5LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDg8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgIDEwLiBDb250cmlidXRvcnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuICAgODwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIDEw LiBDb250cmlidXRvcnMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAgODwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgMTEuIEFja25vd2xlZGdt ZW50cyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA5PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgMTEuIEFja25vd2xlZGdtZW50cyAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICA5PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAxMi4gUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAgIDk8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAxMi4gUmVmZXJlbmNlcyAgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAgIDk8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg MTIuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuICAgOTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgMTIuMS4gIE5v cm1hdGl2ZSBSZWZlcmVuY2VzIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAg OTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9InBh cnQtNCIgY2xhc3M9ImNoYW5nZSI+PHRkPjwvdGQ+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFu Z2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9yZmNkaWZmL3JmY2Rp ZmYucHlodCNwYXJ0LTQiPjxlbT4gcGFnZSAzLCBsaW5lIDU8c3BhbiBjbGFzcz0iaGlkZSI+IMK2 PC9zcGFuPjwvZW0+PC9hPjwvdGg+PHRoPiA8L3RoPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hh bmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3dzYuaWV0Zi5vcmcvcmZjZGlmZi9yZmNk aWZmLnB5aHQjcGFydC00Ij48ZW0+IHBhZ2UgMywgbGluZSA0PHNwYW4gY2xhc3M9ImhpZGUiPiDC tjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEV0aGVybmV0IFZQTiBbUkZDODM2NV0u PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRXRoZXJuZXQgVlBOIFtSRkM4MzY1 XS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhpcyBkb2N1bWVudCBpcyB3 cml0dGVuIGFzc3VtaW5nIHRoZSB1c2Ugb2YgVlhMQU4gZm9yIHZpcnR1YWxpemVkPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhpcyBkb2N1bWVudCBpcyB3cml0dGVuIGFzc3Vt aW5nIHRoZSB1c2Ugb2YgVlhMQU4gZm9yIHZpcnR1YWxpemVkPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICBob3N0cyBhbmQgcmVmZXJzIHRvIFZNcyBhbmQgVlhMQU4gVHVubmVsIEVuZCBQ b2ludHMgKFZURVBzKSBpbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGhvc3Rz IGFuZCByZWZlcnMgdG8gVk1zIGFuZCBWWExBTiBUdW5uZWwgRW5kIFBvaW50cyAoVlRFUHMpIGlu PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBoeXBlcnZpc29ycy4gIEhvd2V2ZXIsIHRo ZSBjb25jZXB0cyBhcmUgZXF1YWxseSBhcHBsaWNhYmxlIHRvIG5vbi08L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBoeXBlcnZpc29ycy4gIEhvd2V2ZXIsIHRoZSBjb25jZXB0cyBh cmUgZXF1YWxseSBhcHBsaWNhYmxlIHRvIG5vbi08L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PiAgIHZpcnR1YWxpemVkIGhvc3RzIGF0dGFjaGVkIHRvIFZURVBzIGluIHN3aXRjaGVzLjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHZpcnR1YWxpemVkIGhvc3RzIGF0dGFjaGVk IHRvIFZURVBzIGluIHN3aXRjaGVzLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBJbiB0aGUgYWJzZW5jZSBvZiBhIHJvdXRlciBpbiB0aGUgb3ZlcmxheSwgYSBWTSBjYW4gY29t bXVuaWNhdGUgd2l0aDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEluIHRoZSBh YnNlbmNlIG9mIGEgcm91dGVyIGluIHRoZSBvdmVybGF5LCBhIFZNIGNhbiBjb21tdW5pY2F0ZSB3 aXRoPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBhbm90aGVyIFZNIG9ubHkgaWYgdGhl eSBhcmUgb24gdGhlIHNhbWUgVlhMQU4gc2VnbWVudC4gIFZNcyBhcmU8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBhbm90aGVyIFZNIG9ubHkgaWYgdGhleSBhcmUgb24gdGhlIHNh bWUgVlhMQU4gc2VnbWVudC4gIFZNcyBhcmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IHVuYXdhcmUgb2YgVlhMQU4gdHVubmVscyBhcyBhIFZYTEFOIHR1bm5lbCBpcyB0ZXJtaW5hdGVk IG9uIGEgVlRFUC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB1bmF3YXJlIG9m IFZYTEFOIHR1bm5lbHMgYXMgYSBWWExBTiB0dW5uZWwgaXMgdGVybWluYXRlZCBvbiBhIFZURVAu PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDA2 Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFz cz0iaW5zZXJ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgVlRFUHMgYXJlIHJlc3BvbnNpYmxlIGZvciBlbmNhcHN1bGF0aW5nIGFuZCBkZWNh cHN1bGF0aW5nIGZyYW1lczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFZURVBz IGFyZSByZXNwb25zaWJsZSBmb3IgZW5jYXBzdWxhdGluZyBhbmQgZGVjYXBzdWxhdGluZyBmcmFt ZXM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIGV4Y2hhbmdlZCBhbW9uZyBWTXMuPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgZXhjaGFuZ2VkIGFtb25nIFZNcy48L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgQWJpbGl0eSB0byBtb25pdG9yIHBhdGgg Y29udGludWl0eSwgaS5lLiwgcGVyZm9ybSBwcm9hY3RpdmU8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICBBYmlsaXR5IHRvIG1vbml0b3IgcGF0aCBjb250aW51aXR5LCBpLmUuLCBw ZXJmb3JtIHByb2FjdGl2ZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgY29udGludWl0 eSBjaGVjayAoQ0MpIGZvciBwb2ludC10by1wb2ludCAocDJwKSBWWExBTiB0dW5uZWxzLCBpczwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNvbnRpbnVpdHkgY2hlY2sgKENDKSBm b3IgcG9pbnQtdG8tcG9pbnQgKHAycCkgVlhMQU4gdHVubmVscywgaXM8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDciPjx0ZD48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAg aW1wb3J0YW50LiAgVGhlIGFzeW5jaHJvbm91cyBtb2RlIG9mIEJGRCwgYXMgZGVmaW5lZCBpbiBb UkZDNTg4MF0sPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGltcG9ydGFudC4g IFRoZSBhc3luY2hyb25vdXMgbW9kZSBvZiBCRkQsIGFzIGRlZmluZWQgaW4gW1JGQzU4ODBdLCA8 c3BhbiBjbGFzcz0iaW5zZXJ0Ij5pczwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9j ayI+ICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+Y2FuIGJlPC9zcGFuPiB1c2VkIHRvIG1vbml0b3Ig YSBwMnAgVlhMQU4gdHVubmVsLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICB1 c2VkIHRvIG1vbml0b3IgYSBwMnAgVlhMQU4gdHVubmVsLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBJbiB0aGUgY2FzZSB3aGVyZSBhIE11bHRpY2FzdCBTZXJ2aWNlIE5vZGUg KE1TTikgKGFzIGRlc2NyaWJlZCBpbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IEluIHRoZSBjYXNlIHdoZXJlIGEgTXVsdGljYXN0IFNlcnZpY2UgTm9kZSAoTVNOKSAoYXMgZGVz Y3JpYmVkIGluPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9 ImRpZmYwMDA4Ij48dGQ+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIFNlY3Rpb24gMy4zIG9mIFtSRkM4MjkzXSkgcmVzaWRl cyBiZWhpbmQgYW4gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+TlZFLDwvc3Bhbj4gdGhlIG1lY2hhbmlz bXM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgU2VjdGlvbiAzLjMgb2YgW1JG QzgyOTNdKSByZXNpZGVzIGJlaGluZCBhbiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5OZXR3b3JrIFZp cnR1YWxpemF0aW9uPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBkZXNj cmliZWQgaW4gdGhpcyBkb2N1bWVudCBhcHBseSBhbmQgY2FuLCB0aGVyZWZvcmUsIGJlIHVzZWQg dG8gdGVzdDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5z ZXJ0Ij4gICBFbmRwb2ludCAoTlZFKSw8L3NwYW4+IHRoZSBtZWNoYW5pc21zIGRlc2NyaWJlZCBp biB0aGlzIGRvY3VtZW50IGFwcGx5IGFuZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4g ICB0aGUgY29ubmVjdGl2aXR5IGZyb20gdGhlIHNvdXJjZSBOVkUgdG8gdGhlIE1TTi48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgY2FuLCB0aGVyZWZvcmUsIGJlIHVzZWQgdG8g dGVzdCB0aGUgY29ubmVjdGl2aXR5IGZyb20gdGhlIHNvdXJjZSBOVkU8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHRvIHRo ZSBNU04uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFRoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIHRoZSB1c2Ugb2YgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVz IHRoZSB1c2Ugb2YgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgKEJGRCkgcHJvdG9jb2wgdG8gZW5hYmxlIG1vbml0b3Jpbmcg Y29udGludWl0eSBvZiB0aGUgcGF0aCBiZXR3ZWVuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgKEJGRCkgcHJvdG9jb2wgdG8gZW5hYmxlIG1vbml0b3JpbmcgY29udGludWl0eSBv ZiB0aGUgcGF0aCBiZXR3ZWVuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBWWExBTiBW VEVQcywgcGVyZm9ybWluZyBhcyBOZXR3b3JrIFZpcnR1YWxpemF0aW9uIEVuZHBvaW50cywgYW5k L29yPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVlhMQU4gVlRFUHMsIHBlcmZv cm1pbmcgYXMgTmV0d29yayBWaXJ0dWFsaXphdGlvbiBFbmRwb2ludHMsIGFuZC9vcjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYXZhaWxhYmlsaXR5IG9mIGEgcmVwbGljYXRvciBtdWx0 aWNhc3Qgc2VydmljZSBub2RlLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGF2 YWlsYWJpbGl0eSBvZiBhIHJlcGxpY2F0b3IgbXVsdGljYXN0IHNlcnZpY2Ugbm9kZS48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Mi4gIENvbnZlbnRpb25zIHVzZWQgaW4gdGhpcyBk b2N1bWVudDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjIuICBDb252ZW50aW9ucyB1 c2VkIGluIHRoaXMgZG9jdW1lbnQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+Mi4x LiAgVGVybWlub2xvZ3k8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4yLjEuICBUZXJt aW5vbG9neTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBCRkQgQmlkaXJlY3Rp b25hbCBGb3J3YXJkaW5nIERldGVjdGlvbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIEJGRCBCaWRpcmVjdGlvbmFsIEZvcndhcmRpbmcgRGV0ZWN0aW9uPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgIENDIENvbnRpbnVpdHkgQ2hlY2s8L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij4gICBDQyBDb250aW51aXR5IENoZWNrPC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgIHAycCBQb2ludC10by1wb2ludDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgIHAycCBQb2ludC10by1wb2ludDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICBNU04gTXVsdGljYXN0IFNlcnZpY2UgTm9kZTwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgIE1TTiBNdWx0aWNhc3QgU2VydmljZSBOb2RlPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMDkiPjx0ZD48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxi bG9jayI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJp bnNlcnQiPk5WRSBOZXR3b3JrIFZpcnR1YWxpemF0aW9uIEVuZHBvaW50PC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVkZJIFZpcnR1 YWwgRm9yd2FyZGluZyBJbnN0YW5jZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IFZGSSBWaXJ0dWFsIEZvcndhcmRpbmcgSW5zdGFuY2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgVk0gVmlydHVhbCBNYWNoaW5lPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgVk0gVmlydHVhbCBNYWNoaW5lPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTAiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIDxzcGFuIGNsYXNzPSJpbnNlcnQiPlZOSSBWWExBTiBO ZXR3b3JrIElkZW50aWZpZXIgKG9yIFZYTEFOIFNlZ21lbnQgSUQpPC9zcGFuPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVlRFUCBWWExBTiBU dW5uZWwgRW5kIFBvaW50PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVlRFUCBW WExBTiBUdW5uZWwgRW5kIFBvaW50PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg IFZYTEFOIFZpcnR1YWwgZVh0ZW5zaWJsZSBMb2NhbCBBcmVhIE5ldHdvcms8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBWWExBTiBWaXJ0dWFsIGVYdGVuc2libGUgTG9jYWwgQXJl YSBOZXR3b3JrPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjIuMi4gIFJlcXVpcmVt ZW50cyBMYW5ndWFnZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjIuMi4gIFJlcXVp cmVtZW50cyBMYW5ndWFnZTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUg a2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxM IE5PVCIsPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIGtleSB3b3JkcyAi TVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLDwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09N TUVOREVEIiwgIk5PVCBSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQ8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAiU0hPVUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAi Tk9UIFJFQ09NTUVOREVEIiwgIk1BWSIsIGFuZDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ ICAgIk9QVElPTkFMIiBpbiB0aGlzIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBk ZXNjcmliZWQgaW4gQkNQPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgIk9QVElP TkFMIiBpbiB0aGlzIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQg aW4gQkNQPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAxNCBbUkZDMjExOV0gW1JGQzgx NzRdIHdoZW4sIGFuZCBvbmx5IHdoZW4sIHRoZXkgYXBwZWFyIGluIGFsbDwvdGQ+PHRkPiA8L3Rk Pjx0ZCBjbGFzcz0icmlnaHQiPiAgIDE0IFtSRkMyMTE5XSBbUkZDODE3NF0gd2hlbiwgYW5kIG9u bHkgd2hlbiwgdGhleSBhcHBlYXIgaW4gYWxsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4g ICBjYXBpdGFscywgYXMgc2hvd24gaGVyZS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij4gICBjYXBpdGFscywgYXMgc2hvd24gaGVyZS48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+My4gIERlcGxveW1lbnQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4zLiAg RGVwbG95bWVudDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBGaWd1cmUgMSBp bGx1c3RyYXRlcyB0aGUgc2NlbmFyaW8gd2l0aCB0d28gc2VydmVycywgZWFjaCBvZiB0aGVtPC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgRmlndXJlIDEgaWxsdXN0cmF0ZXMgdGhl IHNjZW5hcmlvIHdpdGggdHdvIHNlcnZlcnMsIGVhY2ggb2YgdGhlbTwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+ICAgaG9zdGluZyB0d28gVk1zLiAgVGhlIHNlcnZlcnMgaG9zdCBWVEVQcyB0 aGF0IHRlcm1pbmF0ZSB0d28gVlhMQU48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICBob3N0aW5nIHR3byBWTXMuICBUaGUgc2VydmVycyBob3N0IFZURVBzIHRoYXQgdGVybWluYXRl IHR3byBWWExBTjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlk PSJkaWZmMDAxMSI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICB0dW5uZWxzIHdpdGggPHNwYW4gY2xhc3M9ImRlbGV0 ZSI+Vk5JPC9zcGFuPiBudW1iZXIgMTAwIGFuZCAyMDAgcmVzcGVjdGl2ZWx5LiAgU2VwYXJhdGUg QkZEPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHR1bm5lbHMgd2l0aCA8c3Bh biBjbGFzcz0iaW5zZXJ0Ij5WWExBTiBOZXR3b3JrIElkZW50aWZpZXIgKFZOSSk8L3NwYW4+IG51 bWJlciAxMDAgYW5kIDIwMDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBzZXNzaW9u cyBjYW4gYmUgZXN0YWJsaXNoZWQgYmV0d2VlbiB0aGUgVlRFUHMgKElQMSBhbmQgSVAyKSBmb3I8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgcmVzcGVjdGl2ZWx5LiAgU2VwYXJh dGUgQkZEIHNlc3Npb25zIGNhbiBiZSBlc3RhYmxpc2hlZCBiZXR3ZWVuIHRoZTwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBtb25pdG9yaW5nIGVhY2ggb2YgdGhlIFZYTEFOIHR1bm5l bHMgKFZOSSAxMDAgYW5kIDIwMCkuICBBbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij4gICBWVEVQcyAoSVAxIGFuZCBJUDIpIGZvciBtb25pdG9yaW5nIGVhY2ggb2YgdGhlIFZYTEFO IHR1bm5lbHMgKFZOSSAxMDA8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgaW1wbGVt ZW50YXRpb24gdGhhdCBzdXBwb3J0cyB0aGlzIHNwZWNpZmljYXRpb24gTVVTVCBiZSBhYmxlIHRv PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIGFuZCAyMDApLiAgQW4gaW1wbGVt ZW50YXRpb24gdGhhdCBzdXBwb3J0cyB0aGlzIHNwZWNpZmljYXRpb24gTVVTVCBiZTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBjb250cm9sIHRoZSBudW1iZXIgb2YgQkZEIHNlc3Np b25zIHRoYXQgY2FuIGJlIGNyZWF0ZWQgYmV0d2VlbiB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgYWJsZSB0byBjb250cm9sIHRoZSBudW1iZXIgb2YgQkZEIHNlc3Npb25z IHRoYXQgY2FuIGJlIGNyZWF0ZWQ8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgc2Ft ZSBwYWlyIG9mIFZURVBzLiAgQkZEIHBhY2tldHMgaW50ZW5kZWQgZm9yIGEgSHlwZXJ2aXNvciBW VEVQIE1VU1Q8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgYmV0d2VlbiB0aGUg c2FtZSBwYWlyIG9mIFZURVBzLiAgQkZEIHBhY2tldHMgaW50ZW5kZWQgZm9yIGE8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgTk9UIGJlIGZvcndhcmRlZCB0byBhIFZNIGFzIGEgVk0g bWF5IGRyb3AgQkZEIHBhY2tldHMgbGVhZGluZyB0byBhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyYmxvY2siPiAgIEh5cGVydmlzb3IgVlRFUCBNVVNUIE5PVCBiZSBmb3J3YXJkZWQgdG8gYSBW TSBhcyBhIFZNIG1heSBkcm9wIEJGRDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBm YWxzZSBuZWdhdGl2ZS4gIFRoaXMgbWV0aG9kIGlzIGFwcGxpY2FibGUgd2hldGhlciB0aGUgVlRF UCBpcyBhPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHBhY2tldHMgbGVhZGlu ZyB0byBhIGZhbHNlIG5lZ2F0aXZlLiAgVGhpcyBtZXRob2QgaXMgYXBwbGljYWJsZTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICB2aXJ0dWFsIG9yIHBoeXNpY2FsIGRldmljZS48L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgd2hldGhlciB0aGUgVlRFUCBpcyBhIHZp cnR1YWwgb3IgcGh5c2ljYWwgZGV2aWNlLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90 cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICAgICArLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+ICAgICAgKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKzwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgfCAgICAgICAgU2VydmVyIDEgICAgICAgICAgfDwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIHwgICAgICAgIFNlcnZlciAxICAgICAg ICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlm ZjAwMTIiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgfDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICB8ICstLS0tKy0tLS0rICArLS0tLSst LS0tKyB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgfCArLS0tLSstLS0t KyAgKy0tLS0rLS0tLSsgfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgfCB8Vk0x LTEgICAgfCAgfFZNMS0yICAgIHwgfDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg ICAgIHwgfFZNMS0xICAgIHwgIHxWTTEtMiAgICB8IHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPiAgICAgIHwgfFZOSSAxMDAgIHwgIHxWTkkgMjAwICB8IHw8L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij4gICAgICB8IHxWTkkgMTAwICB8ICB8Vk5JIDIwMCAgfCB8PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICB8IHwgICAgICAgICB8ICB8ICAgICAgICAgfCB8PC90 ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgfCB8ICAgICAgICAgfCAgfCAgICAg ICAgIHwgfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgfCArLS0tLS0tLS0tKyAg Ky0tLS0tLS0tLSsgfDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgIHwgKy0t LS0tLS0tLSsgICstLS0tLS0tLS0rIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAg IHwgSHlwZXJ2aXNvciBWVEVQIChJUDEpICAgIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAgICB8IEh5cGVydmlzb3IgVlRFUCAoSVAxKSAgICB8PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKzwv dGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHw8 L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZm MDAxMyI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgPHNwYW4gY2xhc3M9 ImRlbGV0ZSI+fDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2Nr Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8ICAgKy0tLS0tLS0tLS0tLS0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICArLS0tLS0tLS0tLS0tLSs8L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgfCAgIExheWVy IDMgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwgICB8ICAgTGF5ZXIgMyAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTQiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgIDxzcGFuIGNsYXNzPSJkZWxldGUiPnwtLS18PC9zcGFuPiAgIE5ldHdvcmsg ICA8c3BhbiBjbGFzcz0iZGVsZXRlIj58PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgPHNwYW4gY2xhc3M9Imluc2VydCI+ Ky0tLXw8L3NwYW4+ICAgTmV0d29yayAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8PC9z cGFuPiAgICAgICAgICAgICB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAr LS0tLS0tLS0tLS0tLSs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tKzwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfDwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAw MTUiPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICArLS0tLS0tLS0tLS0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tKzwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTYiPjx0ZD48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xh c3M9ImRlbGV0ZSI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfDwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICstLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSs8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0t LS0rLS0tLS0tLS0tLS0tLSs8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICBIeXBlcnZpc29yIFZURVAgKElQMikg fDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfCAgICBIeXBlcnZpc29yIFZURVAgKElQMikgfDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8ICstLS0tKy0tLS0rICArLS0tLSstLS0tKyB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICstLS0tKy0t LS0rICArLS0tLSstLS0tKyB8PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgfFZNMi0xICAgIHwgIHxWTTItMiAgICB8 IHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgfFZNMi0xICAgIHwgIHxWTTItMiAgICB8IHw8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCB8Vk5JIDEwMCAgfCAgfFZOSSAyMDAgIHwgfDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmlnaHQiPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCB8Vk5JIDEw MCAgfCAgfFZOSSAyMDAgIHwgfDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHwgICAgICAgICB8ICB8ICAgICAgICAg fCB8PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8IHwgICAgICAgICB8ICB8ICAgICAgICAgfCB8PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgKy0tLS0tLS0tLSsgICstLS0tLS0tLS0rIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgKy0tLS0t LS0tLSsgICstLS0tLS0tLS0rIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgIFNlcnZlciAyICAgICAgICAg ICAgfDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCAgICAgIFNlcnZlciAyICAgICAgICAgICAgfDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAg ICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxOiBSZWZlcmVuY2UgVlhMQU4gRG9tYWluPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgICAgICAgICAgICAgRmlndXJlIDE6 IFJlZmVyZW5jZSBWWExBTiBEb21haW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+ CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ NC4gIEJGRCBQYWNrZXQgVHJhbnNtaXNzaW9uIG92ZXIgVlhMQU4gVHVubmVsPC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+NC4gIEJGRCBQYWNrZXQgVHJhbnNtaXNzaW9uIG92ZXIgVlhM QU4gVHVubmVsPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEJGRCBwYWNrZXQg TVVTVCBiZSBlbmNhcHN1bGF0ZWQgYW5kIHNlbnQgdG8gYSByZW1vdGUgVlRFUCBhczwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIEJGRCBwYWNrZXQgTVVTVCBiZSBlbmNhcHN1bGF0 ZWQgYW5kIHNlbnQgdG8gYSByZW1vdGUgVlRFUCBhczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxNyI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRy Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBleHBsYWluZWQg aW4gPHNwYW4gY2xhc3M9ImRlbGV0ZSI+U2VjdGlvbiA0LjEuPC9zcGFuPiAgSW1wbGVtZW50YXRp b25zIFNIT1VMRCBlbnN1cmUgdGhhdCB0aGUgQkZEPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgIGV4cGxhaW5lZCBpbiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij50aGlzIHNlY3Rpb24u PC9zcGFuPiAgSW1wbGVtZW50YXRpb25zIFNIT1VMRCBlbnN1cmUgdGhhdCB0aGU8L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxibG9jayI+ICAgcGFja2V0cyBmb2xsb3cgdGhlIHNhbWUgbG9va3VwIHBh dGggYXMgVlhMQU4gZGF0YSBwYWNrZXRzIHdpdGhpbiB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJibG9jayI+ICAgQkZEIHBhY2tldHMgZm9sbG93IHRoZSBzYW1lIGxvb2t1cCBwYXRoIGFz IFZYTEFOIGRhdGEgcGFja2V0cyB3aXRoaW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwv dHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+ ICAgc2VuZGVyIHN5c3RlbS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgdGhl IHNlbmRlciBzeXN0ZW0uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPjQuMS4gIEJGRCBQYWNrZXQgRW5jYXBz dWxhdGlvbiBpbiBWWExBTjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIEJGRCBwYWNrZXRzIGFyZSBlbmNh cHN1bGF0ZWQgaW4gVlhMQU4gYXMgZGVzY3JpYmVkIGJlbG93LiAgVGhlIFZYTEFOPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgQkZEIHBhY2tldHMgYXJlIGVuY2Fwc3VsYXRlZCBp biBWWExBTiBhcyBkZXNjcmliZWQgYmVsb3cuICBUaGUgVlhMQU48L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPiAgIHBhY2tldCBmb3JtYXQgaXMgZGVmaW5lZCBpbiBTZWN0aW9uIDUgb2YgW1JG QzczNDhdLiAgVGhlIE91dGVyIElQL1VEUDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQi PiAgIHBhY2tldCBmb3JtYXQgaXMgZGVmaW5lZCBpbiBTZWN0aW9uIDUgb2YgW1JGQzczNDhdLiAg VGhlIE91dGVyIElQL1VEUDwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYW5kIFZYTEFO IGhlYWRlcnMgTVVTVCBiZSBlbmNvZGVkIGJ5IHRoZSBzZW5kZXIgYXMgZGVmaW5lZCBpbjwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGFuZCBWWExBTiBoZWFkZXJzIE1VU1QgYmUg ZW5jb2RlZCBieSB0aGUgc2VuZGVyIGFzIGRlZmluZWQgaW48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIFtSRkM3MzQ4XS48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBb UkZDNzM0OF0uPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQg Y2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgMCAgICAgICAg ICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMzwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgMCAgICAgICAgICAgICAgICAgICAxICAg ICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMzwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDE8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcg OCA5IDAgMTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij4gICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHw8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRy IGlkPSJwYXJ0LTUiIGNsYXNzPSJjaGFuZ2UiPjx0ZD48L3RkPjx0aD48c21hbGw+c2tpcHBpbmcg dG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVmPSJodHRwczovL3d3dzYuaWV0Zi5vcmcvcmZjZGlm Zi9yZmNkaWZmLnB5aHQjcGFydC01Ij48ZW0+IHBhZ2UgNywgbGluZSAxMTxzcGFuIGNsYXNzPSJo aWRlIj4gwrY8L3NwYW4+PC9lbT48L2E+PC90aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGlu ZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhyZWY9Imh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9yZmNk aWZmL3JmY2RpZmYucHlodCNwYXJ0LTUiPjxlbT4gcGFnZSA2LCBsaW5lIDUxPHNwYW4gY2xhc3M9 ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICArLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+ PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICAgIEZpZ3VyZSAyOiBWWExBTiBFbmNhcHN1bGF0aW9u IG9mIEJGRCBDb250cm9sIE1lc3NhZ2U8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4g ICAgICAgICAgIEZpZ3VyZSAyOiBWWExBTiBFbmNhcHN1bGF0aW9uIG9mIEJGRCBDb250cm9sIE1l c3NhZ2U8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgVGhlIEJGRCBwYWNrZXQg TVVTVCBiZSBjYXJyaWVkIGluc2lkZSB0aGUgaW5uZXIgTUFDIGZyYW1lIG9mIHRoZTwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIFRoZSBCRkQgcGFja2V0IE1VU1QgYmUgY2Fycmll ZCBpbnNpZGUgdGhlIGlubmVyIE1BQyBmcmFtZSBvZiB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIFZYTEFOIHBhY2tldC4gIFRoZSBpbm5lciBNQUMgZnJhbWUgY2FycnlpbmcgdGhl IEJGRCBwYXlsb2FkIGhhcyB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBW WExBTiBwYWNrZXQuICBUaGUgaW5uZXIgTUFDIGZyYW1lIGNhcnJ5aW5nIHRoZSBCRkQgcGF5bG9h ZCBoYXMgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBmb2xsb3dpbmcgZm9ybWF0 OjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGZvbGxvd2luZyBmb3JtYXQ6PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIEV0aGVybmV0IEhlYWRlcjo8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBFdGhlcm5ldCBIZWFkZXI6PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0ciBpZD0iZGlmZjAwMTgi Pjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+ICAgICAgICAgRGVzdGluYXRpb24gTUFDOiBUaGlzIE1VU1QgYmUgdGhlIDxz cGFuIGNsYXNzPSJkZWxldGUiPmRlZGljYXRlZCBNQUMgVEJBIChTZWN0aW9uIDgpPC9zcGFuPjwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICAgICAgICBEZXN0aW5hdGlvbiBNQUM6 IFRoaXMgTVVTVCBiZSB0aGUgTUFDIGFkZHJlc3Mgb2YgdGhlPC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsYmxvY2siPjxzcGFuIGNsYXNzPSJkZWxldGUiPiAgICAgICAgIG9yIHRoZTwvc3Bhbj4gTUFD IGFkZHJlc3Mgb2YgdGhlIGRlc3RpbmF0aW9uIFZURVAuICBUaGUgZGV0YWlscyBvZiBob3c8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAgICAgICAgZGVzdGluYXRpb24gVlRFUC4g IDxzcGFuIGNsYXNzPSJpbnNlcnQiPlRoZSBNQUMgYWRkcmVzcyBNQVkgYmUgY29uZmlndXJlZCBv ciBpdCBNQVk8L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICAgICAgICBiZSBs ZWFybmVkIHZpYSBhIGNvbnRyb2wgcGxhbmUgcHJvdG9jb2wuPC9zcGFuPiAgVGhlIGRldGFpbHMg b2YgaG93PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICB0aGUgTUFDIGFkZHJl c3Mgb2YgdGhlIGRlc3RpbmF0aW9uIFZURVAgaXMgb2J0YWluZWQgYXJlIG91dHNpZGU8L3RkPjx0 ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICB0aGUgTUFDIGFkZHJlc3Mgb2YgdGhl IGRlc3RpbmF0aW9uIFZURVAgaXMgb2J0YWluZWQgYXJlIG91dHNpZGU8L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgICAgICAgIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50LjwvdGQ+PHRk PiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgIHRoZSBzY29wZSBvZiB0aGlzIGRvY3Vt ZW50LjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNz PSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICAgICBTb3VyY2UgTUFD OiBNQUMgYWRkcmVzcyBvZiB0aGUgb3JpZ2luYXRpbmcgVlRFUDwvdGQ+PHRkPiA8L3RkPjx0ZCBj bGFzcz0icmlnaHQiPiAgICAgICAgIFNvdXJjZSBNQUM6IE1BQyBhZGRyZXNzIG9mIHRoZSBvcmln aW5hdGluZyBWVEVQPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgIElQIGhl YWRlcjo8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICBJUCBoZWFkZXI6PC90 ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0 Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgIFNvdXJjZSBJUDogSVAgYWRk cmVzcyBvZiB0aGUgb3JpZ2luYXRpbmcgVlRFUC48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICAgICAgICBTb3VyY2UgSVA6IElQIGFkZHJlc3Mgb2YgdGhlIG9yaWdpbmF0aW5nIFZU RVAuPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgICAgICAgIERlc3RpbmF0aW9u IElQOiBJUCBhZGRyZXNzIG9mIHRoZSB0ZXJtaW5hdGluZyBWVEVQLjwvdGQ+PHRkPiA8L3RkPjx0 ZCBjbGFzcz0icmlnaHQiPiAgICAgICAgIERlc3RpbmF0aW9uIElQOiBJUCBhZGRyZXNzIG9mIHRo ZSB0ZXJtaW5hdGluZyBWVEVQLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAg ICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3Ry PgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAg ICAgICBUVEw6IE1VU1QgYmUgc2V0IHRvIDEgdG8gZW5zdXJlIHRoYXQgdGhlIEJGRCBwYWNrZXQg aXMgbm90PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgICAgVFRMOiBNVVNU IGJlIHNldCB0byAxIHRvIGVuc3VyZSB0aGF0IHRoZSBCRkQgcGFja2V0IGlzIG5vdDwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgICAgICAgcm91dGVkIHdpdGhpbiB0aGUgTDMgdW5kZXJs YXkgbmV0d29yay48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICAgICAgICByb3V0 ZWQgd2l0aGluIHRoZSBMMyB1bmRlcmxheSBuZXR3b3JrLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNs YXNzPSJsZWZ0Ij4gICAgICBUaGUgZmllbGRzIG9mIHRoZSBVRFAgaGVhZGVyIGFuZCB0aGUgQkZE IGNvbnRyb2wgcGFja2V0IGFyZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgICAg IFRoZSBmaWVsZHMgb2YgdGhlIFVEUCBoZWFkZXIgYW5kIHRoZSBCRkQgY29udHJvbCBwYWNrZXQg YXJlPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICAgICBlbmNvZGVkIGFzIHNwZWNpZmll ZCBpbiBbUkZDNTg4MV0uPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgICAgZW5j b2RlZCBhcyBzcGVjaWZpZWQgaW4gW1JGQzU4ODFdLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNz PSJsZWZ0Ij41LiAgUmVjZXB0aW9uIG9mIEJGRCBQYWNrZXQgZnJvbSBWWExBTiBUdW5uZWw8L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij41LiAgUmVjZXB0aW9uIG9mIEJGRCBQYWNrZXQg ZnJvbSBWWExBTiBUdW5uZWw8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgT25j ZSBhIHBhY2tldCBpcyByZWNlaXZlZCwgVlRFUCBNVVNUIHZhbGlkYXRlIHRoZSBwYWNrZXQuICBJ ZiB0aGU8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBPbmNlIGEgcGFja2V0IGlz IHJlY2VpdmVkLCBWVEVQIE1VU1QgdmFsaWRhdGUgdGhlIHBhY2tldC4gIElmIHRoZTwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAxOSI+PHRkPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj4gICBEZXN0aW5hdGlvbiBNQUMgb2YgdGhlIGlubmVyIE1BQyBmcmFtZSBtYXRjaGVzIHRo ZSA8c3BhbiBjbGFzcz0iZGVsZXRlIj5kZWRpY2F0ZWQgTUFDIG9yPC9zcGFuPjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBEZXN0aW5hdGlvbiBNQUMgb2YgdGhlIGlubmVyIE1B QyBmcmFtZSBtYXRjaGVzIHRoZSBNQUMgYWRkcmVzcyBvZiB0aGU8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgdGhlPC9zcGFuPiBNQUMgYWRkcmVz cyBvZiB0aGUgVlRFUCB0aGUgcGFja2V0IE1VU1QgYmUgcHJvY2Vzc2VkIGZ1cnRoZXIuPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIFZURVAgdGhlIHBhY2tldCBNVVNUIGJlIHBy b2Nlc3NlZCBmdXJ0aGVyLjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAg PHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgog ICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUg VURQIGRlc3RpbmF0aW9uIHBvcnQgYW5kIHRoZSBUVEwgb2YgdGhlIGlubmVyIElQIHBhY2tldCBN VVNUIGJlPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIFVEUCBkZXN0aW5h dGlvbiBwb3J0IGFuZCB0aGUgVFRMIG9mIHRoZSBpbm5lciBJUCBwYWNrZXQgTVVTVCBiZTwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgdmFsaWRhdGVkIHRvIGRldGVybWluZSBpZiB0aGUg cmVjZWl2ZWQgcGFja2V0IGNhbiBiZSBwcm9jZXNzZWQgYnk8L3RkPjx0ZD4gPC90ZD48dGQgY2xh c3M9InJpZ2h0Ij4gICB2YWxpZGF0ZWQgdG8gZGV0ZXJtaW5lIGlmIHRoZSByZWNlaXZlZCBwYWNr ZXQgY2FuIGJlIHByb2Nlc3NlZCBieTwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4K ICAgICAgPHRyIGlkPSJkaWZmMDAyMCI+PHRkPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICBCRkQuICBCRkQgcGFja2V0IHdp dGggaW5uZXIgTUFDIHNldCB0byA8c3BhbiBjbGFzcz0iZGVsZXRlIj5WVEVQIG9yIGRlZGljYXRl ZDwvc3Bhbj4gTUFDIGFkZHJlc3M8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+ICAg QkZELiAgQkZEIHBhY2tldCB3aXRoIGlubmVyIE1BQyBzZXQgdG8gPHNwYW4gY2xhc3M9Imluc2Vy dCI+VlRFUCdzPC9zcGFuPiBNQUMgYWRkcmVzcyBNVVNUIE5PVCBiZTwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGJsb2NrIj4gICBNVVNUIE5PVCBiZSBmb3J3YXJkZWQgdG8gVk1zLjwvdGQ+PHRkPiA8 L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj4gICBmb3J3YXJkZWQgdG8gVk1zLjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0 ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsZWZ0Ij41LjEuICBEZW11bHRpcGxleGluZyBvZiB0aGUgQkZEIFBhY2tl dDwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjUuMS4gIERlbXVsdGlwbGV4aW5nIG9m IHRoZSBCRkQgUGFja2V0PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8 dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIERlbXVs dGlwbGV4aW5nIG9mIElQIEJGRCBwYWNrZXQgaGFzIGJlZW4gZGVmaW5lZCBpbiBTZWN0aW9uIDMg b2Y8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBEZW11bHRpcGxleGluZyBvZiBJ UCBCRkQgcGFja2V0IGhhcyBiZWVuIGRlZmluZWQgaW4gU2VjdGlvbiAzIG9mPC90ZD48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+ PHRkIGNsYXNzPSJsZWZ0Ij4gICBbUkZDNTg4MV0uICBTaW5jZSBtdWx0aXBsZSBCRkQgc2Vzc2lv bnMgbWF5IGJlIHJ1bm5pbmcgYmV0d2VlbiB0d288L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJp Z2h0Ij4gICBbUkZDNTg4MV0uICBTaW5jZSBtdWx0aXBsZSBCRkQgc2Vzc2lvbnMgbWF5IGJlIHJ1 bm5pbmcgYmV0d2VlbiB0d288L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFZURVBzLCB0 aGVyZSBuZWVkcyB0byBiZSBhIG1lY2hhbmlzbSBmb3IgZGVtdWx0aXBsZXhpbmcgcmVjZWl2ZWQg QkZEPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVlRFUHMsIHRoZXJlIG5lZWRz IHRvIGJlIGEgbWVjaGFuaXNtIGZvciBkZW11bHRpcGxleGluZyByZWNlaXZlZCBCRkQ8L3RkPjx0 ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+ PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHBhY2tldHMgdG8gdGhlIHByb3BlciBzZXNzaW9uLiAg VGhlIHByb2NlZHVyZSBmb3IgZGVtdWx0aXBsZXhpbmc8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij4gICBwYWNrZXRzIHRvIHRoZSBwcm9wZXIgc2Vzc2lvbi4gIFRoZSBwcm9jZWR1cmUg Zm9yIGRlbXVsdGlwbGV4aW5nPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBwYWNrZXRz IHdpdGggWW91ciBEaXNjcmltaW5hdG9yIGVxdWFsIHRvIDAgaXMgZGlmZmVyZW50IGZyb208L3Rk Pjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBwYWNrZXRzIHdpdGggWW91ciBEaXNjcmlt aW5hdG9yIGVxdWFsIHRvIDAgaXMgZGlmZmVyZW50IGZyb208L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPiAgIFtSRkM1ODgwXS4gIEZvciBzdWNoIHBhY2tldHMsIHRoZSBCRkQgc2Vzc2lvbiBN VVNUIGJlIGlkZW50aWZpZWQ8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICBbUkZD NTg4MF0uICBGb3Igc3VjaCBwYWNrZXRzLCB0aGUgQkZEIHNlc3Npb24gTVVTVCBiZSBpZGVudGlm aWVkPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICB1c2luZyB0aGUgaW5uZXIgaGVhZGVy cywgaS5lLiwgdGhlIHNvdXJjZSBJUCwgdGhlIGRlc3RpbmF0aW9uIElQLCBhbmQ8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB1c2luZyB0aGUgaW5uZXIgaGVhZGVycywgaS5lLiwg dGhlIHNvdXJjZSBJUCwgdGhlIGRlc3RpbmF0aW9uIElQLCBhbmQ8L3RkPjx0ZCBjbGFzcz0ibGlu ZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xh c3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNz PSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJwYXJ0LTYiIGNsYXNzPSJjaGFuZ2Ui Pjx0ZD48L3RkPjx0aD48c21hbGw+c2tpcHBpbmcgdG8gY2hhbmdlIGF0PC9zbWFsbD48YSBocmVm PSJodHRwczovL3d3dzYuaWV0Zi5vcmcvcmZjZGlmZi9yZmNkaWZmLnB5aHQjcGFydC02Ij48ZW0+ IHBhZ2UgOCwgbGluZSAyMjxzcGFuIGNsYXNzPSJoaWRlIj4gwrY8L3NwYW4+PC9lbT48L2E+PC90 aD48dGg+IDwvdGg+PHRoPjxzbWFsbD5za2lwcGluZyB0byBjaGFuZ2UgYXQ8L3NtYWxsPjxhIGhy ZWY9Imh0dHBzOi8vd3d3Ni5pZXRmLm9yZy9yZmNkaWZmL3JmY2RpZmYucHlodCNwYXJ0LTYiPjxl bT4gcGFnZSA4LCBsaW5lIDE5PHNwYW4gY2xhc3M9ImhpZGUiPiDCtjwvc3Bhbj48L2VtPjwvYT48 L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPiAgIG51bWJlciBvZiBWTklzIGluIGNvbW1vbi4gIFdoZW4gdGhlIHNpbmds ZSBCRkQgc2Vzc2lvbiBpcyB1c2VkIHRvPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ ICAgbnVtYmVyIG9mIFZOSXMgaW4gY29tbW9uLiAgV2hlbiB0aGUgc2luZ2xlIEJGRCBzZXNzaW9u IGlzIHVzZWQgdG88L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIG1vbml0b3IgdGhlIHJl YWNoYWJpbGl0eSBvZiB0aGUgcmVtb3RlIFZURVAsIGFuIGltcGxlbWVudGF0aW9uIFNIT1VMRDwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIG1vbml0b3IgdGhlIHJlYWNoYWJpbGl0 eSBvZiB0aGUgcmVtb3RlIFZURVAsIGFuIGltcGxlbWVudGF0aW9uIFNIT1VMRDwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk Pjx0ZCBjbGFzcz0ibGVmdCI+ICAgY2hvb3NlIGFueSBvZiB0aGUgVk5JcyBidXQgTUFZIGNob29z ZSBWTkkgPSAwLjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIGNob29zZSBhbnkg b2YgdGhlIFZOSXMgYnV0IE1BWSBjaG9vc2UgVk5JID0gMC48L3RkPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9 ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBj bGFzcz0ibGVmdCI+Ny4gIEVjaG8gQkZEPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ Ny4gIEVjaG8gQkZEPC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIFN1cHBvcnQg Zm9yIGVjaG8gQkZEIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuPC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgU3VwcG9ydCBmb3IgZWNobyBCRkQgaXMgb3V0 c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudC48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9Imxl ZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+OC4gIElBTkEgQ29uc2lkZXJhdGlvbnM8L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJpZ2h0Ij44LiAgSUFOQSBDb25zaWRlcmF0aW9uczwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVm dCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDIxIj48dGQ+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIDxzcGFu IGNsYXNzPSJkZWxldGUiPklBTkE8L3NwYW4+IGhhcyA8c3BhbiBjbGFzcz0iZGVsZXRlIj5hc3Np Z25lZCBUQkEgYXMgYSBkZWRpY2F0ZWQgTUFDIGFkZHJlc3MgZnJvbSB0aGU8L3NwYW4+IElBTkEg PHNwYW4gY2xhc3M9ImRlbGV0ZSI+NDgtYml0PC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5UaGlzIHNwZWNpZmljYXRpb248L3Nw YW4+IGhhcyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5ubzwvc3Bhbj4gSUFOQSA8c3BhbiBjbGFzcz0i aW5zZXJ0Ij5hY3Rpb24gcmVxdWVzdGVkLiAgVGhpcyBzZWN0aW9uIG1heTwvc3Bhbj4gYmU8L3Rk Pjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgdW5pY2Fz dCBNQUMgYWRkcmVzcyByZWdpc3RyeSB0bzwvc3Bhbj4gYmUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+ dXNlZCBhcyB0aGUgRGVzdGluYXRpb24gTUFDPC9zcGFuPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFz cz0icmJsb2NrIj4gICA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5kZWxldGVkIGJlZm9yZTwvc3Bhbj4g dGhlIDxzcGFuIGNsYXNzPSJpbnNlcnQiPnB1YmxpY2F0aW9uLjwvc3Bhbj48L3RkPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48 dGQgY2xhc3M9ImxibG9jayI+PHNwYW4gY2xhc3M9ImRlbGV0ZSI+ICAgYWRkcmVzcyBvZjwvc3Bh bj4gdGhlIDxzcGFuIGNsYXNzPSJkZWxldGUiPmlubmVyIEV0aGVybmV0IG9mIFZYTEFOIHdoZW4g Y2FycnlpbmcgQkZEIGNvbnRyb2w8L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxv Y2siPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFz cz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48c3BhbiBjbGFzcz0iZGVsZXRlIj4g ICBwYWNrZXRzLjwvc3Bhbj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PC90ZD48 dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48 L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9Imxp bmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPjkuICBTZWN1cml0eSBDb25zaWRlcmF0aW9uczwv dGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjkuICBTZWN1cml0eSBDb25zaWRlcmF0aW9u czwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy aWdodCI+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij4gICBUaGUgZG9jdW1lbnQgcmVxdWly ZXMgc2V0dGluZyB0aGUgaW5uZXIgSVAgVFRMIHRvIDEsIHdoaWNoIGNvdWxkIGJlPC90ZD48dGQ+ IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgVGhlIGRvY3VtZW50IHJlcXVpcmVzIHNldHRpbmcg dGhlIGlubmVyIElQIFRUTCB0byAxLCB3aGljaCBjb3VsZCBiZTwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGVmdCI+ICAgdXNlZCBhcyBhIEREb1MgYXR0YWNrIHZlY3Rvci4gIFRodXMgdGhlIGltcGxl bWVudGF0aW9uIE1VU1QgaGF2ZTwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIHVz ZWQgYXMgYSBERG9TIGF0dGFjayB2ZWN0b3IuICBUaHVzIHRoZSBpbXBsZW1lbnRhdGlvbiBNVVNU IGhhdmU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xh c3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHRocm90dGxpbmcgaW4gcGxhY2Ug dG8gY29udHJvbCB0aGUgcmF0ZSBvZiBCRkQgY29udHJvbCBwYWNrZXRzIHNlbnQ8L3RkPjx0ZD4g PC90ZD48dGQgY2xhc3M9InJpZ2h0Ij4gICB0aHJvdHRsaW5nIGluIHBsYWNlIHRvIGNvbnRyb2wg dGhlIHJhdGUgb2YgQkZEIGNvbnRyb2wgcGFja2V0cyBzZW50PC90ZD48dGQgY2xhc3M9ImxpbmVu byI+PC90ZD48L3RyPgogICAgICA8dHIgaWQ9ImRpZmYwMDIyIj48dGQ+PC90ZD48L3RyPgogICAg ICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPiAgIHRvIHRo ZSBjb250cm9sIHBsYW5lLiAgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+VGhyb3R0bGluZyBNQVkgYmUg cmVsYXhlZCBmb3I8L3NwYW4+IEJGRCBwYWNrZXRzPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJy YmxvY2siPiAgIHRvIHRoZSBjb250cm9sIHBsYW5lLiAgPHNwYW4gY2xhc3M9Imluc2VydCI+T24g dGhlIG90aGVyIGhhbmQsIG92ZXIgYWdncmVzc2l2ZSB0aHJvdHRsaW5nPC9zcGFuPjwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5iYXNlZCBvbiBw b3J0IG51bWJlci48L3NwYW4+PC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFu IGNsYXNzPSJpbnNlcnQiPiAgIG9mIEJGRCBjb250cm9sIHBhY2tldHMgbWF5IGJlY29tZSB0aGUg Y2F1c2Ugb2YgdGhlIGluYWJpbGl0eSB0byBmb3JtPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5l bm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFz cz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJibG9jayI+PHNwYW4gY2xhc3M9 Imluc2VydCI+ICAgYW5kIG1haW50YWluPC9zcGFuPiBCRkQgPHNwYW4gY2xhc3M9Imluc2VydCI+ c2Vzc2lvbiBhdCBzY2FsZS4gIEhlbmNlLCB0aHJvdHRsaW5nIG9mIEJGRCBjb250cm9sPC9zcGFu PjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2NrIj48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9 InJibG9jayI+ICAgcGFja2V0cyA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5TSE9VTEQgYmUgYWRqdXN0 ZWQgdG8gcGVybWl0IEJGRCB0byB3b3JrIGFjY29yZGluZyB0byBpdHM8L3NwYW4+PC90ZD48dGQg Y2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmJsb2NrIj48 c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBwcm9jZWR1cmVzLjwvc3Bhbj48L3RkPjx0ZCBjbGFzcz0i bGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQg Y2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNs YXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyIGlkPSJkaWZmMDAyMyI+PHRkPjwvdGQ+ PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJsb2Nr Ij4gICA8c3BhbiBjbGFzcz0iZGVsZXRlIj5UaGU8L3NwYW4+IGltcGxlbWVudGF0aW9uIFNIT1VM RCA8c3BhbiBjbGFzcz0iZGVsZXRlIj5oYXZlPC9zcGFuPiBhIDxzcGFuIGNsYXNzPSJkZWxldGUi PnJlYXNvbmFibGUgdXBwZXIgYm91bmQgb248L3NwYW4+IHRoZSBudW1iZXI8L3RkPjx0ZD4gPC90 ZD48dGQgY2xhc3M9InJibG9jayI+ICAgPHNwYW4gY2xhc3M9Imluc2VydCI+SWYgdGhlPC9zcGFu PiBpbXBsZW1lbnRhdGlvbiA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5zdXBwb3J0cyBlc3RhYmxpc2hp bmcgbXVsdGlwbGUgQkZEIHNlc3Npb25zPC9zcGFuPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8iPjwv dGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0ibGJs b2NrIj4gICBvZiA8c3BhbiBjbGFzcz0iZGVsZXRlIj5CRkQgc2Vzc2lvbnM8L3NwYW4+IHRoYXQg Y2FuIGJlIDxzcGFuIGNsYXNzPSJkZWxldGUiPmNyZWF0ZWQgYmV0d2Vlbjwvc3Bhbj4gdGhlIHNh bWUgPHNwYW4gY2xhc3M9ImRlbGV0ZSI+cGFpciBvZiBWVEVQcy48L3NwYW4+PC90ZD48dGQ+IDwv dGQ+PHRkIGNsYXNzPSJyYmxvY2siPjxzcGFuIGNsYXNzPSJpbnNlcnQiPiAgIGJldHdlZW4gdGhl IHNhbWUgcGFpciBvZiBWVEVQcywgdGhlcmU8L3NwYW4+IFNIT1VMRCA8c3BhbiBjbGFzcz0iaW5z ZXJ0Ij5iZTwvc3Bhbj4gYSA8c3BhbiBjbGFzcz0iaW5zZXJ0Ij5tZWNoYW5pc20gdG88L3NwYW4+ PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJs aW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsYmxvY2siPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0i cmJsb2NrIj48c3BhbiBjbGFzcz0iaW5zZXJ0Ij4gICBjb250cm9sPC9zcGFuPiB0aGUgPHNwYW4g Y2xhc3M9Imluc2VydCI+bWF4aW11bTwvc3Bhbj4gbnVtYmVyIG9mIDxzcGFuIGNsYXNzPSJpbnNl cnQiPnN1Y2ggc2Vzc2lvbjwvc3Bhbj4gdGhhdCBjYW4gYmUgPHNwYW4gY2xhc3M9Imluc2VydCI+ YWN0aXZlIGF0PC9zcGFuPiB0aGU8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAg ICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxibG9jayI+PC90ZD48 dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyYmxvY2siPiAgIHNhbWUgPHNwYW4gY2xhc3M9Imluc2VydCI+ dGltZS48L3NwYW4+PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48 dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAg IDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIE90aGVyIHRo YW4gaW5uZXIgSVAgVFRMIHNldCB0byAxIGFuZCBsaW1pdCB0aGUgbnVtYmVyIG9mIEJGRCBzZXNz aW9uczwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAgIE90aGVyIHRoYW4gaW5uZXIg SVAgVFRMIHNldCB0byAxIGFuZCBsaW1pdCB0aGUgbnVtYmVyIG9mIEJGRCBzZXNzaW9uczwvdGQ+ PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5v Ij48L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgYmV0d2VlbiB0aGUgc2FtZSBwYWlyIG9mIFZURVBz LCB0aGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3QgcmFpc2UgYW55PC90ZD48dGQ+IDwvdGQ+PHRk IGNsYXNzPSJyaWdodCI+ICAgYmV0d2VlbiB0aGUgc2FtZSBwYWlyIG9mIFZURVBzLCB0aGlzIHNw ZWNpZmljYXRpb24gZG9lcyBub3QgcmFpc2UgYW55PC90ZD48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRkIGNsYXNzPSJsZWZ0 Ij4gICBhZGRpdGlvbmFsIHNlY3VyaXR5IGlzc3VlcyBiZXlvbmQgdGhvc2Ugb2YgdGhlIHNwZWNp ZmljYXRpb25zPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgYWRkaXRpb25hbCBz ZWN1cml0eSBpc3N1ZXMgYmV5b25kIHRob3NlIG9mIHRoZSBzcGVjaWZpY2F0aW9uczwvdGQ+PHRk IGNsYXNzPSJsaW5lbm8iPjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48 L3RkPjx0ZCBjbGFzcz0ibGVmdCI+ICAgcmVmZXJyZWQgdG8gaW4gdGhlIGxpc3Qgb2Ygbm9ybWF0 aXZlIHJlZmVyZW5jZXMuPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcmVmZXJy ZWQgdG8gaW4gdGhlIGxpc3Qgb2Ygbm9ybWF0aXZlIHJlZmVyZW5jZXMuPC90ZD48dGQgY2xhc3M9 ImxpbmVubyI+PC90ZD48L3RyPgogICAgICA8dHI+PHRkIGNsYXNzPSJsaW5lbm8iPjwvdGQ+PHRk IGNsYXNzPSJsZWZ0Ij48L3RkPjx0ZD4gPC90ZD48dGQgY2xhc3M9InJpZ2h0Ij48L3RkPjx0ZCBj bGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90 ZD48dGQgY2xhc3M9ImxlZnQiPjEwLiAgQ29udHJpYnV0b3JzPC90ZD48dGQ+IDwvdGQ+PHRkIGNs YXNzPSJyaWdodCI+MTAuICBDb250cmlidXRvcnM8L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3Rk PjwvdHI+CiAgICAgIDx0cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQi PjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRkIGNsYXNzPSJsaW5lbm8i PjwvdGQ+PC90cj4KICAgICAgPHRyPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjx0ZCBjbGFzcz0i bGVmdCI+ICAgUmVzaGFkIFJhaG1hbjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPiAg IFJlc2hhZCBSYWhtYW48L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CiAgICAgIDx0 cj48dGQgY2xhc3M9ImxpbmVubyI+PC90ZD48dGQgY2xhc3M9ImxlZnQiPiAgIHJyYWhtYW5AY2lz Y28uY29tPC90ZD48dGQ+IDwvdGQ+PHRkIGNsYXNzPSJyaWdodCI+ICAgcnJhaG1hbkBjaXNjby5j b208L3RkPjx0ZCBjbGFzcz0ibGluZW5vIj48L3RkPjwvdHI+CgogICAgIDx0cj48dGQ+PC90ZD48 dGQgY2xhc3M9ImxlZnQiPjwvdGQ+PHRkPiA8L3RkPjx0ZCBjbGFzcz0icmlnaHQiPjwvdGQ+PHRk PjwvdGQ+PC90cj4KICAgICA8dHIgaWQ9ImVuZCIgYmdjb2xvcj0iZ3JheSI+PHRoIGNvbHNwYW49 IjUiIGFsaWduPSJjZW50ZXIiPiZuYnNwO0VuZCBvZiBjaGFuZ2VzLiAyMyBjaGFuZ2UgYmxvY2tz LiZuYnNwOzwvdGg+PC90cj4KICAgICA8dHIgY2xhc3M9InN0YXRzIj48dGQ+PC90ZD48dGg+PGk+ NDUgbGluZXMgY2hhbmdlZCBvciBkZWxldGVkPC9pPjwvdGg+PHRoPjxpPiA8L2k+PC90aD48dGg+ PGk+NDYgbGluZXMgY2hhbmdlZCBvciBhZGRlZDwvaT48L3RoPjx0ZD48L3RkPjwvdHI+CiAgICAg PHRyPjx0ZCBjb2xzcGFuPSI1IiBhbGlnbj0iY2VudGVyIiBjbGFzcz0ic21hbGwiPjxicj5UaGlz IGh0bWwgZGlmZiB3YXMgcHJvZHVjZWQgYnkgcmZjZGlmZiAxLjQ3LiBUaGUgbGF0ZXN0IHZlcnNp b24gaXMgYXZhaWxhYmxlIGZyb20gPGEgaHJlZj0iaHR0cDovL3d3dy50b29scy5pZXRmLm9yZy90 b29scy9yZmNkaWZmLyI+aHR0cDovL3Rvb2xzLmlldGYub3JnL3Rvb2xzL3JmY2RpZmYvPC9hPiA8 L3RkPjwvdHI+CiAgIDwvdGJvZHk+PC90YWJsZT4KICAgCiAgIAo8L2JvZHk+PC9odG1sPg== --0000000000002bb946058b7ddcb6-- From nobody Mon Jun 17 05:34:57 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 575E6120112; Sun, 16 Jun 2019 22:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 L31X-PxlCP6s; Sun, 16 Jun 2019 22:55:43 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08C371200F1; Sun, 16 Jun 2019 22:55:43 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A9CEAB81C67; Sun, 16 Jun 2019 22:55:23 -0700 (PDT) To: anoop@alumni.duke.edu, manav.bhatia@alcatel-lucent.com, mach@huawei.com, sboutros@cisco.com, mbinderb@cisco.com, jhaas@juniper.net Subject: [Errata Held for Document Update] RFC7130 (5742) X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: martin.vigoureux@nokia.com, iesg@ietf.org, rtg-bfd@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190617055523.A9CEAB81C67@rfc-editor.org> Date: Sun, 16 Jun 2019 22:55:23 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Mon, 17 Jun 2019 05:34:48 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 05:55:44 -0000 The following errata report has been held for document update for RFC7130, "Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5742 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Anoop Ghanwani Date Reported: 2019-05-30 Held by: Martin Vigoureux (IESG) Section: 2.3 Original Text ------------- Micro-BFD packets SHOULD always be sent untagged. However, when the LAG is operating in the context of IEEE 802.1q or IEEE 802.qinq, Corrected Text -------------- Micro-BFD packets SHOULD always be sent untagged. However, when the LAG is operating in the context of IEEE 802.1Q or IEEE 802.1ad, Notes ----- q should be capitalized. The IEEE standard for QinQ is IEEE 802.1ad. -------------------------------------- RFC7130 (draft-ietf-bfd-on-lags-04) -------------------------------------- Title : Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces Publication Date : February 2014 Author(s) : M. Bhatia, Ed., M. Chen, Ed., S. Boutros, Ed., M. Binderberger, Ed., J. Haas, Ed. Category : PROPOSED STANDARD Source : Bidirectional Forwarding Detection Area : Routing Stream : IETF Verifying Party : IESG From nobody Mon Jun 17 05:35:06 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3D3120112; Sun, 16 Jun 2019 22:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 ZSWZYFPke8zY; Sun, 16 Jun 2019 22:57:13 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B19491200F1; Sun, 16 Jun 2019 22:57:13 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 99EB5B81C77; Sun, 16 Jun 2019 22:56:54 -0700 (PDT) To: anoop@alumni.duke.edu, manav.bhatia@alcatel-lucent.com, mach@huawei.com, sboutros@cisco.com, mbinderb@cisco.com, jhaas@juniper.net Subject: [Errata Held for Document Update] RFC7130 (5741) X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: martin.vigoureux@nokia.com, iesg@ietf.org, rtg-bfd@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20190617055654.99EB5B81C77@rfc-editor.org> Date: Sun, 16 Jun 2019 22:56:54 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Mon, 17 Jun 2019 05:34:48 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 05:57:15 -0000 The following errata report has been held for document update for RFC7130, "Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5741 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Anoop Ghanwani Date Reported: 2019-05-30 Held by: Martin Vigoureux (IESG) Section: 1 Original Text ------------- While there are native Ethernet mechanisms to detect failures (802.1ax, .3ah) Corrected Text -------------- While there are native Ethernet mechanisms to detect failures (802.1AX, 802.3ah) Notes ----- ax should be capitalized. -------------------------------------- RFC7130 (draft-ietf-bfd-on-lags-04) -------------------------------------- Title : Bidirectional Forwarding Detection (BFD) on Link Aggregation Group (LAG) Interfaces Publication Date : February 2014 Author(s) : M. Bhatia, Ed., M. Chen, Ed., S. Boutros, Ed., M. Binderberger, Ed., J. Haas, Ed. Category : PROPOSED STANDARD Source : Bidirectional Forwarding Detection Area : Routing Stream : IETF Verifying Party : IESG From nobody Mon Jun 17 09:10:04 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A631202F9 for ; Mon, 17 Jun 2019 09:09:51 -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, 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 header.b=NpM4OE8m; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=qdBDLE3W 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 z_bYo6vcNA6Q for ; Mon, 17 Jun 2019 09:09:49 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE03B120324 for ; Mon, 17 Jun 2019 09:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3413; q=dns/txt; s=iport; t=1560787788; x=1561997388; h=from:to:subject:date:message-id:mime-version; bh=ZyO//z74ShFGn7Pd/avGiPj1vyUO8PvLgRWyuFMu24Q=; b=NpM4OE8mGV1i4jtUjhmFrMInZK8E7VRJXOv/nqhXVngIA2dZTrxB6FKt CziEGJfaOgn68f9VzJjRFTCnZ4WdIh4F5PI0mzMNb0xHPxbstMk2km814 20Yuyb8xSNsuQsaTHHgtrEZ7A1LLY2zof2glu2zueGyCJ7w7QxoI3zj+/ k=; IronPort-PHdr: =?us-ascii?q?9a23=3AO5FmYBEfPCEaf96QkSryo51GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1A3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeTwZiw/FcJqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BBBgBjugdd/4UNJK1mgheBDy9QA2p?= =?us-ascii?q?VIAQLKIQWg0cDjmJKlHCEU4EugSQDVAkBAQEMAQEtAgEBhFmCNSM0CQ4BAwE?= =?us-ascii?q?BBAEBAgEEbRwBC4VjER0BATgRAQw+AgQwJwQ1gwABgR1NAx0BnXQCgTiIX3G?= =?us-ascii?q?BMYJ5AQEFgkeCMhiCEAmBNIteF4FAP4E4H4QOAYZJMoImjjuEdJYwCQKCEJN?= =?us-ascii?q?SG4InhwOOBoQJiRSWYwIEAgQFAg4BAQWBUDiBWHAVZQGCQYIng1iKU3KBKY8?= =?us-ascii?q?fAQE?= X-IronPort-AV: E=Sophos;i="5.63,385,1557187200"; d="scan'208,217";a="574087920" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Jun 2019 16:09:47 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x5HG9lef016879 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 17 Jun 2019 16:09:47 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 17 Jun 2019 11:09:46 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 17 Jun 2019 11:09:45 -0500 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 17 Jun 2019 11:09:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZyO//z74ShFGn7Pd/avGiPj1vyUO8PvLgRWyuFMu24Q=; b=qdBDLE3WCjWmTg7x+K1Q5YwiS2rUEwOrXZyIwkRnYcwmLEDjrmEh6HFoawa3iIaWD6DpQv2DmCNGRTpcKOku9r80+S8FYHIhZwTqI1k+PIg92tOe97C5eH5UVx03UYnK8sy2OK3TnhefvAQJEcKBB6c5+P01yXogNzkjFbxmcqU= Received: from DM5PR1101MB2105.namprd11.prod.outlook.com (10.174.104.151) by DM5PR1101MB2315.namprd11.prod.outlook.com (10.174.105.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.13; Mon, 17 Jun 2019 16:09:45 +0000 Received: from DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::b57b:a39a:5e67:16c6]) by DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::b57b:a39a:5e67:16c6%2]) with mapi id 15.20.1987.014; Mon, 17 Jun 2019 16:09:45 +0000 From: "Reshad Rahman (rrahman)" To: "rtg-bfd@ietf.org" Subject: BFD presentation requests @ IETF105 Montreal Thread-Topic: BFD presentation requests @ IETF105 Montreal Thread-Index: AQHVJScUJIWzFG72uEOPC6YLBnK9+A== Date: Mon, 17 Jun 2019 16:09:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.6.190114 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; x-originating-ip: [2001:420:2840:1250:2421:2f0a:1dbc:638e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ef39a904-a739-4498-7d4e-08d6f33e36b7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR1101MB2315; x-ms-traffictypediagnostic: DM5PR1101MB2315: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0071BFA85B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(346002)(376002)(39860400002)(366004)(199004)(189003)(86362001)(316002)(102836004)(76116006)(91956017)(73956011)(186003)(6506007)(6916009)(7736002)(71190400001)(36756003)(58126008)(71200400001)(5660300002)(99286004)(66946007)(66476007)(66556008)(64756008)(66446008)(14454004)(2616005)(476003)(486006)(46003)(256004)(478600001)(6436002)(53936002)(5640700003)(8936002)(81166006)(25786009)(2351001)(68736007)(81156014)(2906002)(8676002)(6512007)(54896002)(6306002)(33656002)(558084003)(6116002)(6486002)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1101MB2315; H:DM5PR1101MB2105.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: DekHYpALOcBFJTBWj/HFCz5LhmkrR4fRwC10UYwRjWX+75zyyJa37gsqN7ZAQw7EpPY1HapCz9ynmy2KtvGO8fxM9TZH+LRIPtaj+1nZjYImvZCe1+TaCrusb5ojmJ3U526ZO/J/Kmdm0H/w4BWu0BZWkRciEjL8rUUipS6Bt6k78lFJIYxQDRpzDGpKUAwGXXmguX6tR/LCRQaEtivWqG0WOvLWHbyNdJYJoO+DzljMvXQAhPDIAsiQem8Wsa4V2fDAAoslAbud/CuUnbzc8RnCVpXLAJt825lvOdVAvVYSlMnHeOLRMJS3nkeTQdu/RVmashulyt7sGplvw9kYrdjagu6Dt2FhHHKrWoPQvg04uE3yEwD2Bvij04DYpgL/V2Qqm1kcx/UrA/ch4foQ950dL+AaWCm1cJ6VhTsn+3o= Content-Type: multipart/alternative; boundary="_000_BEBE4676EF3A4A9A8C3895FD97092BE9ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ef39a904-a739-4498-7d4e-08d6f33e36b7 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jun 2019 16:09:44.9319 (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-CrossTenant-userprincipalname: rrahman@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2315 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 16:10:02 -0000 --_000_BEBE4676EF3A4A9A8C3895FD97092BE9ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QkZEIFdHLA0KDQpXZSB3aWxsIGJlIG1lZXRpbmcgYXQgSUVURiAxMDUgaW4gTW9udHJlYWwuIFBs ZWFzZSBzZW5kIHByZXNlbnRhdGlvbiByZXF1ZXN0cyB0byB0aGUgY2hhaXJzLg0KDQpSZWdhcmRz LA0KUmVzaGFkICYgSmVmZi4NCg== --_000_BEBE4676EF3A4A9A8C3895FD97092BE9ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <5918CB32FE08C44491F85EC1E9347E9A@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUNB IiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5CRkQgV0csPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPldlIHdpbGwgYmUgbWVldGluZyBhdCBJ RVRGIDEwNSBpbiBNb250cmVhbC4gUGxlYXNlIHNlbmQgcHJlc2VudGF0aW9uIHJlcXVlc3RzIHRv IHRoZSBjaGFpcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5SZXNoYWQgJmFtcDsgSmVmZi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BEBE4676EF3A4A9A8C3895FD97092BE9ciscocom_-- From nobody Wed Jun 19 18:09:40 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48737120052; Wed, 19 Jun 2019 18:09:38 -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_HELO_NONE=0.001, 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 wBGVG4jQHupB; Wed, 19 Jun 2019 18:09:34 -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 A35921200F7; Wed, 19 Jun 2019 18:09:33 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id v24so977178ljg.13; Wed, 19 Jun 2019 18:09:33 -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=UUURzktwcTMYd2DkXbUHEOXzutGT7XxmaaUYnXxRRrc=; b=rHz2Pt2Avr6EK41XmJPw4aFUpLebIUzJ6q4AbVARcB5RTKkR9BRwZii4qrym7HEhE1 6M2mZDs5IPdt9gRjrdULs2NPoz+1LBtmPUoWGmaxWYGsBWDgsQ6BImnvXMhtvryHCy2P nLT4Z8FB2yXl/edJpFdpPZfPXd1tcpB8GslLpTxhnp0LG2wPm0C9O6YHW+govR61fvVd jZ7TDCoWTm2CvQiyPreDZo0T+HZ3VtkfjGD1axNZwJvYNDKhJqp62HAgfguebNVmUhyq ceW/5GPwatu7n5UxbtsKQd2nXff9kftihb9IqNDNLCvsUxNeGFVsFIXnxTBmIFvgzctl GgVA== 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=UUURzktwcTMYd2DkXbUHEOXzutGT7XxmaaUYnXxRRrc=; b=i44SeGcQVx/ILSvi4ltxhx0YPCWB7Ws+hUnXfx48Zm1mEmcD+VS26hRLIgvNC+KS+5 AS2j5c06fk06eONfDIowvy8esFlsrMdKAJ++yf1ucS3MPaCMsxpiqas4zusHGGxC+XiX Zs7oYhd5VngTrjGSDLQ2w0tmo7D/W34q0eKzDChJJvwC2zKiTAMxNmsL2S4UGPBKWjdu MLIb+tnTQOr4r/NzYyszuYn+scwO9kGFtSDHxotkJICpP6m4z9q7LK8JYRL28rBRP+Nl n0k1V8gJw+AyU7VvjDz7cS/fBJL3EMr+5hnevuBzueV8Hg34c5gwAqdhQp7u1jV3d9qh +giQ== X-Gm-Message-State: APjAAAWrnntyynA4iq0r05z32nmW9KAUK//OheB++1YSiGPdyFZWFqL+ psVXSXFx8WDa+47WyOuAm/rpWRxvyV9xAJClbbJGoEWa+Eo= X-Google-Smtp-Source: APXvYqwslmi/NryDresVBDleREabpn5EB3OxVkfvDq82M42jkeZMsuMH7eCehKoPvSwqQWDwmLzn+gOxfmO/aKkL6xg= X-Received: by 2002:a2e:834f:: with SMTP id l15mr45197868ljh.56.1560992971679; Wed, 19 Jun 2019 18:09:31 -0700 (PDT) MIME-Version: 1.0 References: <155933149484.6565.7386019489022348116@ietfa.amsl.com> <14822B96-D3C6-495E-8661-198068F72ABA@cisco.com> In-Reply-To: <14822B96-D3C6-495E-8661-198068F72ABA@cisco.com> From: Greg Mirsky Date: Thu, 20 Jun 2019 10:09:20 +0900 Message-ID: Subject: Re: Tsvart last call review of draft-ietf-bfd-vxlan-07 To: "Carlos Pignataro (cpignata)" Cc: Olivier Bonaventure , "tsv-art@ietf.org" , rtg-bfd WG , "draft-ietf-bfd-vxlan.all@ietf.org" , IETF list Content-Type: multipart/alternative; boundary="00000000000092ec62058bb6ff85" Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 01:09:38 -0000 --00000000000092ec62058bb6ff85 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Carlos, thank you for reminding of our continued discussion with Joel. We are seeking comments from VXLAN experts and much appreciate if you have insights on VXLAN to share. I've got some clarifying questions before I can respond to you. To which stage of the three-way handshake you refer as "initial demultiplexing"? I couldn't find this term in RFC 5880. Regarding the applicability of the Echo mode, thank you for pointing to the need for stricter terminology, the Echo mode, as defined in RFC 5880, is underspecified and it will require additional standardization. Future drafts may explore and define how the Echo mode of BFD is used over VXLAN tunnels. Will review and respond to the remaining questions soon. Regards, Greg On Thu, Jun 20, 2019 at 9:14 AM Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Hi, > > I have not reviewed this draft before, but triggered by this email, and > briefly scanning through a couple of sections, it is unclear to me how so= me > of the mechanics work. > > There are some major issues with the Mac usage and association, as Joel > Halpern mentioned in his Rtg Dir review. > > And, additionally, please consider the following comments and questions: > > > 1. Underspecification for initialization and initial demultiplexing. > > This document allows multiple BFD sessions between a single pair of VTEPs= : > > An > implementation that supports this specification MUST be able to > control the number of BFD sessions that can be created between the > same pair of VTEPs. > > The implication of this is that BFD single-hop initialization procedures > will not work. Instead, there is a need to map the initial demultiplexing= . > > This issue is explained in RFCs 5882 and 5883: > https://tools.ietf.org/html/rfc5883#section-4 and > https://tools.ietf.org/html/rfc5882#section-6 > > Section 5.1 says: > > For such packets, the BFD session MUST be identified > using the inner headers, i.e., the source IP, the destination IP, and > the source UDP port number present in the IP header carried by the > payload of the VXLAN encapsulated packet. The VNI of the packet > SHOULD be used to derive interface-related information for > demultiplexing the packet. > > But this does not really explain how to do the initial demultiplexing. > Does each BFD session need to have a separate inner source IP address? Or > source UDP port? And how ofter are they recycled or kept as state? How ar= e > these mapped? > Equally importantly, which side is Active? > And what if there=E2=80=99s a race condition with both sides being Active= and > setting up redundant sessions? > > 1.b. By the way, based on this, using S-BFD [RFC 7880] might be easier to > demux. > > > 2. Security > > This document says that the TTL in the inner packet carrying BFD is set t= o > 1. However, RFC 5880 says to use GTSM [RFC 5082], i.e., a value of 255. > > Why is GTSM not used here? > > > 3. ECMP and fate-sharing under-specification: > > Section 4.1. says: > > The Outer IP/UDP > and VXLAN headers MUST be encoded by the sender as defined in > [RFC7348]. > > > And RFC 7348 says: > > - Source Port: It is recommended that the UDP source port number > be calculated using a hash of fields from the inner packet -- > one example being a hash of the inner Ethernet frame's headers. > This is to enable a level of entropy for the ECMP/load- > balancing of the VM-to-VM traffic across the VXLAN overlay. > When calculating the UDP source port number in this manner, it > is RECOMMENDED that the value be in the dynamic/private port > range 49152-65535 [RFC6335]. > > > Based on this, depending on the hashing calculation, the outer source UDP > port can be different leading to different ECMP treatment. Does something > else need to be specified here in regards to the outer UDP source port? > > > 4. Section 7 says that =E2=80=9C Support for echo BFD is outside the scop= e of this > document=E2=80=9D. > > Assuming this means =E2=80=9CBFD Echo mode=E2=80=9D, why is this out of s= cope? If this is > a single logical hop underneath VXLAN, what=E2=80=99s preventing the use = of Echo? > Echo=E2=80=99s benefits are huge. > > > 5. Terminology > > Implementations SHOULD ensure that the BFD > packets follow the same lookup path as VXLAN data packets within the > sender system. > > What is a =E2=80=9Clook up path within a sender system=E2=80=9D? > > > 6. Deployment scenarios > > S3 says: > Figure 1 illustrates the scenario with two servers, each of them > hosting two VMs. The servers host VTEPs that terminate two VXLAN > [=E2=80=A6] > Figure 1: Reference VXLAN Domain > > > However, RFC 7348 Figure 3 lists that as one deployment scenario, not as > =E2=80=9Cthe scenario=E2=80=9D and =E2=80=9CThe Reference VXLAN Domain=E2= =80=9D. > > Best, > > Carlos. > > On Jun 17, 2019, at 12:58 AM, Greg Mirsky wrote: > > Hi Oliver, > thank you for your thorough review, clear and detailed questions. My > apologies for the delay to respond. Please find my answers below in-line > tagged GIM>>. > > Regards, > Greg > > On Fri, May 31, 2019 at 12:38 PM Olivier Bonaventure via Datatracker < > noreply@ietf.org> wrote: > >> Reviewer: Olivier Bonaventure >> Review result: Ready with Issues >> >> This document has been reviewed as part of the transport area review >> team's >> ongoing effort to review key IETF documents. These comments were written >> primarily for the transport area directors, but are copied to the >> document's >> authors and WG to allow them to address any issues raised and also to th= e >> IETF >> discussion list for information. >> >> When done at the time of IETF Last Call, the authors should consider thi= s >> review as part of the last-call comments they receive. Please always CC >> tsv-art@ietf.org if you reply to or forward this review. >> >> I have only limited knowledge of VXLAN and do not know all subtleties of >> BFD. >> This review is thus more from a generalist than a specialist in this >> topic. >> >> Major issues >> >> Section 4 requires that " Implementations SHOULD ensure that the BFD >> packets follow the same lookup path as VXLAN data packets within the >> sender system." >> >> Why is this requirement only relevant for the lookup path on the sender >> system >> ? What does this sentence really implies ? >> > GIM>> RFC 5880 set the scope of the fault detection of BFD protocol as > ... the bidirectional path between two forwarding engines, including > interfaces, data link(s), and to the extent possible the forwarding > engines themselves ... > The requirement aimed to the forwarding engine of a BFD system that > transmits BFD control packets over VXLAN tunnel. > >> >> Is it a requirement that the BFD packets follow the same path as the dat= a >> packet for a given VXLAN ? I guess so. In this case, the document should >> discuss how Equal Cost Multipath could affect this. >> > GIM>> I think that ECMP environment is more likely to be experienced by a > transit node in the underlay. If the BFD session is used to monitor the > specific underlay path, then, I agree, we should explain that using the > VXLAN payload information to draw path entropy may cause data and BFD > packets following different underlay routes. But, on the other hand, that > is the case for OAM and fault detection in all overlay networks in genera= l. > >> >> Minor issues >> >> Section 1 >> >> You write "The asynchronous mode of BFD, as defined in [RFC5880], >> can be used to monitor a p2p VXLAN tunnel." >> >> Why do you use the word can ? It is a possibility or a requirement ? >> > GIM>> In principle, BFD Demand mode may be used to monitor p2p paths as > well, I agree, will re-word to more assertive: > The asynchronous mode of BFD, as defined in [RFC5880], > is used to monitor a p2p VXLAN tunnel. >> >> >> NVE has not been defined before and is not in the terminology. >> > GIM>> Will add to the Terminology and expand as: > NVE Network Virtualization Endpoint > >> >> This entire section is not easy to read for an outsider. >> >> Section 3 >> >> VNI has not been defined >> > GIM>> Will add to the Terminology section: > VNI VXLAN Network Identifier (or VXLAN Segment ID) > >> >> Figure 1 could take less space >> > GIM>> Yes, can make it bit denser. Would the following be an improvement? > > > +------------+-------------+ > | Server 1 | > | +----+----+ +----+----+ | > | |VM1-1 | |VM1-2 | | > | |VNI 100 | |VNI 200 | | > | | | | | | > | +---------+ +---------+ | > | Hypervisor VTEP (IP1) | > +--------------------------+ > | > | +-------------+ > | | Layer 3 | > +---| Network | > +-------------+ > | > +-----------+ > | > +------------+-------------+ > | Hypervisor VTEP (IP2) | > | +----+----+ +----+----+ | > | |VM2-1 | |VM2-2 | | > | |VNI 100 | |VNI 200 | | > | | | | | | > | +---------+ +---------+ | > | Server 2 | > +--------------------------+ > > >> Section 4 >> >> I do not see the benefits of having one paragraph in Section 4 followed >> by only >> Section 4.1 >> > GIM>> Will merge Section 4.1 into 4 with minor required re-wording: > 4. BFD Packet Transmission over VXLAN Tunnel > > BFD packet MUST be encapsulated and sent to a remote VTEP as > explained in this section. Implementations SHOULD ensure that the > BFD packets follow the same lookup path as VXLAN data packets within > the sender system. > > BFD packets are encapsulated in VXLAN as described below. The VXLAN > packet format is defined in Section 5 of [RFC7348]. The Outer IP/UDP > and VXLAN headers MUST be encoded by the sender as defined in > [RFC7348]. > >> >> Section 4.1 >> >> The document does not specify when a dedicated MAC address or the MAC >> address >> of the destination VTEP must be used. This could affect the >> interoperability of >> implementations. Should all implementations support both the dedicated M= AC >> address and the destination MAC address ? >> > GIM>> After further discussion, authors decided to remove the request for > the dedicated MAC address allocation. Only the MAC address of the remote > VTEP must be used as the destination MAC address in the inner Ethernet > frame. Please check the attached diff between the -07 and the working > versions or the working version of the draft. > >> >> It is unclear from this section whether IPv4 inside IPv6 and the opposit= e >> should be supported or not. >> > GIM>> Any combination of outer IPvX and inner IPvX is possible. > >> >> Section 5. >> >> If the received packet does not match the dedicated MAC address nor the >> MAC >> address of the VTEP, should the packet be silently discarded or treated >> differently ? >> > GIM>> As I've mentioned earlier, authors have decided to remove the use o= f > the dedicated MAC address for BFD over VXLAN. > >> >> Section 5.1 >> >> Is this a modification to section 6.3 of RFC5880 ? This is not clear >> > GIM>> I think that this section is not modification but the definition of > the application-specific procedure that is outside the scope of RFC 5880: > The method of demultiplexing the initial packets (in which Your > Discriminator is zero) is application dependent, and is thus outside > the scope of this specification. > >> >> Section 9 >> >> The sentence " Throttling MAY be relaxed for BFD packets >> based on port number." is unclear. >> > GIM>> Yes, thank you for pointing to this. The updated text, in the whole > paragraph, is as follows: > NEW TEXT: > The document requires setting the inner IP TTL to 1, which could be > used as a DDoS attack vector. Thus the implementation MUST have > throttling in place to control the rate of BFD control packets sent > to the control plane. On the other hand, over aggressive throttling > of BFD control packets may become the cause of the inability to form > and maintain BFD session at scale. Hence, throttling of BFD control > packets SHOULD be adjusted to permit BFD to work according to its > procedures. > draft-ietf-bfd-vxlan-08.txt.html> > > > --00000000000092ec62058bb6ff85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carlos,
thank you for reminding of= our continued discussion with Joel. We are seeking comments from VXLAN exp= erts and much appreciate if you have insights on VXLAN to share.
= I've got some clarifying questions before I can respond to you. To whic= h stage of the three-way handshake you refer as "initial demultiplexin= g"? I couldn't find this term in RFC 5880.
Regarding the= applicability of the Echo mode, thank you for pointing to the need for str= icter terminology, the Echo mode, as defined in RFC 5880, is underspecified= and it will require additional standardization. Future drafts may explore = and define how the Echo mode of BFD is used over VXLAN tunnels.
<= br>
Will review and respond to the remaining questions soon.

Regards,
Greg


=
On Thu, Ju= n 20, 2019 at 9:14 AM Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
Hi,

I have not reviewed this draft before, but triggered by this email, an= d briefly scanning through a couple of sections, it is unclear to me how so= me of the mechanics work.

There are some major issues with the Mac usage and association, as Joe= l Halpern mentioned in his Rtg Dir review.

And, additionally, please consider the following comments and question= s:


1. Underspecification for initialization and initial demultiplexing.

This document allows multiple BFD sessions between a single pair of VT= EPs:

=C2=A0 =C2=A0An
=C2=A0 =C2=A0implementation that supports this specification MUST be a= ble to
=C2=A0 =C2=A0control the number of BFD sessions that can be created be= tween the
=C2=A0 =C2=A0same pair of VTEPs.

The implication of this is that BFD single-hop initialization procedur= es will not work. Instead, there is a need to map the initial demultiplexin= g.

This issue is explained in RFCs 5882 and 5883:=C2=A0https://tools.iet= f.org/html/rfc5883#section-4=C2=A0and=C2=A0https://tools.ietf.org/html= /rfc5882#section-6

Section 5.1 says:

=C2=A0 =C2=A0For such packets, the BFD session MUST be identified
=C2=A0 =C2=A0using the inner headers, i.e., the source IP, the destina= tion IP, and
=C2=A0 =C2=A0the source UDP port number present in the IP header carri= ed by the
=C2=A0 =C2=A0payload of the VXLAN encapsulated packet.=C2=A0 The VNI o= f the packet
=C2=A0 =C2=A0SHOULD be used to derive interface-related information fo= r
=C2=A0 =C2=A0demultiplexing the packet.

But this does not really explain how to do the initial demultiplexing.= Does each BFD session need to have a separate inner source IP address? Or = source UDP port? And how ofter are they recycled or kept as state? How are = these mapped?
Equally importantly, which side is Active?
And what if there=E2=80=99s a race condition with both sides being Act= ive and setting up redundant sessions?

1.b. By the way, based on this, using S-BFD [RFC 7880] might be easier= to demux.


2. Security

This document says that the TTL in the inner packet carrying BFD is se= t to 1. However, RFC 5880 says to use GTSM [RFC 5082], i.e., a value of 255= .

Why is GTSM not used here?


3. ECMP and fate-sharing under-specification:

Section 4.1. says:

=C2=A0 =C2=A0The Outer IP/UDP
=C2=A0 =C2=A0and VXLAN headers MUST be encoded by the sender as define= d in
=C2=A0 =C2=A0[RFC7348].


And RFC 7348 says:

=C2=A0 =C2=A0 =C2=A0 - =C2=A0Source Port: =C2=A0It is recommended that= the UDP source port number
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0be calculated using a hash of fields= from the inner packet --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0one example being a hash of the inne= r Ethernet frame's headers.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0This is to enable a level of entropy= for the ECMP/load-
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0balancing of the VM-to-VM traffic ac= ross the VXLAN overlay.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0When calculating the UDP source port= number in this manner, it
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0is RECOMMENDED that the value be in = the dynamic/private port
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0range 49152-65535 [RFC6335].


Based on this, depending on the hashing calculation, the outer source UDP p= ort can be different leading to different ECMP treatment. Does something el= se need to be specified here in regards to the outer UDP source port?


4. Section 7 says that =E2=80=9C=C2=A0Support for echo BFD is outside = the scope of this document=E2=80=9D.=C2=A0

Assuming this means =E2=80=9CBFD Echo mode=E2=80=9D, why is this out o= f scope? If this is a single logical hop underneath VXLAN, what=E2=80=99s p= reventing the use of Echo? Echo=E2=80=99s benefits are huge.


5. Terminology

=C2=A0 =C2=A0Implementations SHOULD ensure that the BFD
=C2=A0 =C2=A0packets follow the same lookup path as VXLAN data packets= within the
=C2=A0 =C2=A0sender system.

What is a =E2=80=9Clook up path within a sender system=E2=80=9D?


6. Deployment scenarios

S3 says:
=C2=A0 =C2=A0Figure 1 illustrates the scenario with two servers, each = of them
=C2=A0 =C2=A0hosting two VMs.=C2=A0 The servers host VTEPs that termin= ate two VXLAN
[=E2=80=A6]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0Figure 1: Reference VXLAN Domain


However, RFC=C2=A07348 Figure 3 lists that as one deployment scenario, not = as =E2=80=9Cthe scenario=E2=80=9D and =E2=80=9CThe Reference VXLAN Domain= =E2=80=9D.

Best,

Carlos.

On Jun 17, 2019, at 12:58 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Oliver,
thank you for your thorough review, clear and detailed questions. My a= pologies for the delay to respond. Please find my answers below in-line tag= ged GIM>>.

Regards,
Greg

On Fri, May 31, 2019 at 12:38 PM Oliv= ier Bonaventure via Datatracker <noreply@ietf.org> wrote:
Reviewer: Olivier Bonaventure
Review result: Ready with Issues

This document has been reviewed as part of the transport area review team&#= 39;s
ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document&= #39;s
authors and WG to allow them to address any issues raised and also to the I= ETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org = if you reply to or forward this review.

I have only limited knowledge of VXLAN and do not know all subtleties of BF= D.
This review is thus more from a generalist than a specialist in this topic.=

Major issues

Section 4 requires that " Implementations SHOULD ensure that the BFD =C2=A0 =C2=A0packets follow the same lookup path as VXLAN data packets with= in the
=C2=A0 =C2=A0sender system."

Why is this requirement only relevant for the lookup path on the sender sys= tem
? What does this sentence really implies ?
GIM>> RFC 5880 set the scope of the fault detection of BFD proto= col as=C2=A0
=C2=A0 =C2=A0... the bidirectional path between two forwarding engines, inc= luding
=C2=A0 =C2=A0interfaces, data link(s), and to the extent possible the forwa= rding
=C2=A0 =C2=A0engines themselves ...
The requirement aimed to the forwarding engine of a BFD system that tr= ansmits BFD control packets over VXLAN tunnel.

Is it a requirement that the BFD packets follow the same path as the data packet for a given VXLAN ? I guess so. In this case, the document should discuss how Equal Cost Multipath could affect this.
GIM>> I think that ECMP environment is more likely to be experie= nced by a transit node in the underlay. If the BFD session is used to monit= or the specific underlay path, then, I agree, we should explain that using = the VXLAN payload information to draw path entropy may cause data and BFD packets following different un= derlay routes. But, on the other hand, that is the case for OAM and fault d= etection in all overlay networks in general.

Minor issues

Section 1

You write "The asynchronous mode of BFD, as defined in [RFC5880],
=C2=A0can be used to monitor a p2p VXLAN tunnel."

Why do you use the word can ? It is a possibility or a requirement ?
GIM>> In principle, BFD Demand mode may be used to monitor p2p p= aths as well, I agree, will re-word to more assertive:
=C2=A0The asynchronous mode of BFD, as defined in [RFC5880],
=C2=A0is used to monitor a p2p VXLAN tunnel.

NVE has not been defined before and is not in the terminology.
GIM>> Will add to the Terminology and expand as:
NVE =C2=A0 =C2=A0 =C2=A0 =C2=A0Network Virtualization Endpoint=C2=A0

This entire section is not easy to read for an outsider.

Section 3

VNI has not been defined
GIM>> Will add to the Terminology section:
VNI=C2=A0 =C2=A0 VXLAN Network Identifier (or VXLAN Segment ID)

Figure 1 could take less space
GIM>> Yes, can make it bit denser. Would the following be an imp= rovement?
=C2=A0
      +------------+-------------+
      |        Server 1          |
      | +----+----+  +----+----+ |
      | |VM1-1    |  |VM1-2    | |
      | |VNI 100  |  |VNI 200  | |
      | |         |  |         | |
      | +---------+  +---------+ |
      | Hypervisor VTEP (IP1)    |
      +--------------------------+
                            |
                            |   +-------------+
                            |   |   Layer 3   |
                            +---|   Network   |
                                +-------------+
                                    |
                                    +-----------+
                                                |
                                         +------------+-------------+
                                         |    Hypervisor VTEP (IP2) |
                                         | +----+----+  +----+----+ |
                                         | |VM2-1    |  |VM2-2    | |
                                         | |VNI 100  |  |VNI 200  | |
                                         | |         |  |         | |
                                         | +---------+  +---------+ |
                                         |      Server 2            |
                                         +--------------------------+

Section 4

I do not see the benefits of having one paragraph in Section 4 followed by = only
Section 4.1
GIM>> Will merge Section 4.1 into 4 with minor required re-wordi= ng:
4.=C2=A0 BFD Packet Transmission over VXLAN Tunnel

=C2=A0 =C2=A0BFD packet MUST be encapsulated and sent to a remote VTEP as =C2=A0 =C2=A0explained in this section.=C2=A0 Implementations SHOULD ensure= that the
=C2=A0 =C2=A0BFD packets follow the same lookup path as VXLAN data packets = within
=C2=A0 =C2=A0the sender system.

=C2=A0 =C2=A0BFD packets are encapsulated in VXLAN as described below.=C2= =A0 The VXLAN
=C2=A0 =C2=A0packet format is defined in Section 5 of [RFC7348].=C2=A0 The = Outer IP/UDP
=C2=A0 =C2=A0and VXLAN headers MUST be encoded by the sender as defined in<= br> =C2=A0 =C2=A0[RFC7348].

Section 4.1

The document does not specify when a dedicated MAC address or the MAC addre= ss
of the destination VTEP must be used. This could affect the interoperabilit= y of
implementations. Should all implementations support both the dedicated MAC<= br> address and the destination MAC address ?
GIM>> After further discussion, authors decided to remove the re= quest for the dedicated MAC address allocation. Only the MAC address of the= remote VTEP must be used as the destination MAC address in the inner Ether= net frame. Please check the attached diff between the -07 and the working versions or the working version of th= e draft.

It is unclear from this section whether IPv4 inside IPv6 and the opposite should be supported or not.
GIM>> Any combination of outer IPvX and inner IPvX is possible.<= /div>

Section 5.

If the received packet does not match the dedicated MAC address nor the MAC=
address of the VTEP, should the packet be silently discarded or treated
differently ?
GIM>> As I've mentioned earlier, authors have decided to rem= ove the use of the dedicated MAC address for BFD over VXLAN.

Section 5.1

Is this a modification to section 6.3 of RFC5880 ? This is not clear
GIM>> I think that this section is not modification but the defi= nition of the application-specific procedure that is outside the scope of R= FC 5880:
=C2=A0 =C2=A0The method of demultiplexing the initial packets (in whic= h Your
=C2=A0 =C2=A0Discriminator is zero) is application dependent, and is thus o= utside
=C2=A0 =C2=A0the scope of this specification.

Section 9

The sentence " Throttling MAY be relaxed for BFD packets
=C2=A0 =C2=A0based on port number." is unclear.
GIM>> Yes, thank you for pointing to this. The updated text, in = the whole paragraph, is as follows:
NEW TEXT:
=C2=A0 =C2=A0The document requires setting the inner IP TTL to 1, whic= h could be
=C2=A0 =C2=A0used as a DDoS attack vector.=C2=A0 Thus the implementation MU= ST have
=C2=A0 =C2=A0throttling in place to control the rate of BFD control packets= sent
=C2=A0 =C2=A0to the control plane.=C2=A0 On the other hand, over aggressive= throttling
=C2=A0 =C2=A0of BFD control packets may become the cause of the inability t= o form
=C2=A0 =C2=A0and maintain BFD session at scale.=C2=A0 Hence, throttling of = BFD control
=C2=A0 =C2=A0packets SHOULD be adjusted to permit BFD to work according to = its
=C2=A0 =C2=A0procedures.
<draft-ietf-bfd= -vxlan-08.txt><Diff_ draft-ietf-bfd-vxlan-07.txt - draft-ietf-bfd-vxlan-08.txt.h= tml>

--00000000000092ec62058bb6ff85-- From nobody Wed Jun 19 18:31:47 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3855E1201D8; Wed, 19 Jun 2019 18:31:45 -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=jG8+GZeC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=zcUcciob 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 KvTpPJJKiq_N; Wed, 19 Jun 2019 18:31:41 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D908120189; Wed, 19 Jun 2019 18:31:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20236; q=dns/txt; s=iport; t=1560994301; x=1562203901; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sdLI6nD+8M0uvuooqVIRuUcqRtyrUnsAdUpEsTrG0yI=; b=jG8+GZeC4uj53Tpd1C4kIBYLzmqSueqgTdnx/5bH4oqSsrm4/F5ZAs6o A0BdJuceQM2qoYI6czqo+1IAcsNsgQctYCO/NkL4QkDZ0ANl7U3qUHcrE OIEKsQ1y9DID22Ftal4s2oW81/AAuviERIauCMNmht1rwKTdFAKLZe8qs 0=; IronPort-PHdr: =?us-ascii?q?9a23=3ASWiG5x36X+8ihdpIsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQAlX6I/jjcyUSF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CjAAC94Apd/5JdJa1mHAEBAQQBAQc?= =?us-ascii?q?EAQGBVQUBAQsBgUNQA2pVIAQLKAqEDINHA45ggleJRY1xgS4UgRADVAkBAQE?= =?us-ascii?q?MAQEjCgIBAYRAAheCQSM2Bw4BAwEBBAEBAgEFbYo3DIVKAQEBAwESEREMAQE?= =?us-ascii?q?lBAkFAQQLAgEIGAICJgICAh8RFRACBA4FIoMAAYFqAw4PAQIMom0CgTiIX3G?= =?us-ascii?q?BMYJ5AQEFhQENC4IQAwaBDCgBhHCEJIEegSsXgUA/gRABJx+CTD6CGkcBAQI?= =?us-ascii?q?BgSoBAQsHAQkVGBUMAoJQMoImi3QtgXIujUCMfiw+CQKCEYZIiR8Eg2gbgie?= =?us-ascii?q?HBoQKhWCCUoFLlEGBaopRgwgCBAIEBQIOAQEFgVcELWdxcBU7KgGCQT6CAws?= =?us-ascii?q?Yg02FFIU+AXIBgSiLTA8XgQsBgSABAQ?= X-IronPort-AV: E=Sophos;i="5.63,394,1557187200"; d="scan'208";a="578066144" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Jun 2019 01:31:39 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x5K1VdD4032678 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Jun 2019 01:31:39 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 19 Jun 2019 20:31:39 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 19 Jun 2019 20:31:38 -0500 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 19 Jun 2019 21:31:38 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sdLI6nD+8M0uvuooqVIRuUcqRtyrUnsAdUpEsTrG0yI=; b=zcUcciobTsAsQ49XtVkbRwouOe5FRixX5eGXZPceqArf7r48hK9eD6io7jRfHPZiUX+zq2VrRVEizsjYzxW/c0IjghgEwlvfLIogDnngyq3Q6NpXHkloNriyxNFUz88tqKHHIfwdo+xvEp1hm62nCfvBvaBzWnqYu27dmyDtaV8= Received: from BL0PR11MB3028.namprd11.prod.outlook.com (20.177.204.138) by BL0PR11MB3489.namprd11.prod.outlook.com (20.177.206.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.13; Thu, 20 Jun 2019 01:31:32 +0000 Received: from BL0PR11MB3028.namprd11.prod.outlook.com ([fe80::ec33:f4c1:227a:fcb3]) by BL0PR11MB3028.namprd11.prod.outlook.com ([fe80::ec33:f4c1:227a:fcb3%5]) with mapi id 15.20.1987.014; Thu, 20 Jun 2019 01:31:32 +0000 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: "tsv-art@ietf.org" , rtg-bfd WG , "draft-ietf-bfd-vxlan.all@ietf.org" , Olivier Bonaventure , IETF list Subject: Re: Tsvart last call review of draft-ietf-bfd-vxlan-07 Thread-Topic: Tsvart last call review of draft-ietf-bfd-vxlan-07 Thread-Index: AQHVJMqh+O1Bih53oEC7haZ3x5KaoKajsLYAgAAPSACAAAYzgA== Date: Thu, 20 Jun 2019 01:31:32 +0000 Message-ID: <8237FE8D-937E-4BCB-B1A3-89C2B3CDC51C@cisco.com> References: <155933149484.6565.7386019489022348116@ietfa.amsl.com> <14822B96-D3C6-495E-8661-198068F72ABA@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.11) authentication-results: spf=none (sender IP is ) smtp.mailfrom=cpignata@cisco.com; x-originating-ip: [173.38.117.68] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1795be73-86b5-431c-d92d-08d6f51f06b7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BL0PR11MB3489; x-ms-traffictypediagnostic: BL0PR11MB3489: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0074BBE012 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(396003)(346002)(39860400002)(136003)(189003)(199004)(51444003)(86362001)(81156014)(6306002)(26005)(8676002)(229853002)(76116006)(73956011)(66946007)(6512007)(64756008)(6486002)(33656002)(186003)(66476007)(66556008)(76176011)(6436002)(305945005)(6916009)(99286004)(256004)(7736002)(53546011)(6506007)(4326008)(66446008)(102836004)(6246003)(14444005)(5024004)(53936002)(8936002)(66066001)(14454004)(6116002)(3846002)(30864003)(966005)(57306001)(81166006)(50226002)(1411001)(54906003)(68736007)(5660300002)(478600001)(316002)(71190400001)(71200400001)(446003)(25786009)(486006)(11346002)(2616005)(36756003)(476003)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR11MB3489; H:BL0PR11MB3028.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: z3EDCIQ9YxP5oCw5lqWMHU+64UIDCwhsI7lleyeuOUVaEWQbRqklIF6yHsYZL/ZfjP7VY/l7ESjf7BXAdzOKmtQkh/bYcYYetS40Cgpu/G2UsFTxGLqwVp7qMD4TDjtSgrWZieIgIw/LX+UazwVSBDpjdJXWwLBwZL9L/riMjNBfdW959QJ2kWUoL3YOw0S30EwMMdjZIVmJyH8WIlNOI0yxXsAbU2hrD8qze1l1TlsJNIXF3C/PcvLBdd2m4pebLlQYpWn0x5PWFtxhU71QOzXJHB5lWTc3X4cBeQAqqbMbJj3fN5D9+31y4Q4EETw7p1Vqzcimi0J69O5NPEGDy1g/aAUxr+IjDKkOMn3Xbi88cUme0JtFE1qAFUOdiSLMevdOs1Ey7+Qr1idYooqbofiozcn8CbJwj60nCaNMnQs= Content-Type: text/plain; charset="utf-8" Content-ID: <606C5F6132D3B14CB38CF26F3E019EDB@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1795be73-86b5-431c-d92d-08d6f51f06b7 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2019 01:31:32.3887 (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-CrossTenant-userprincipalname: cpignata@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3489 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.27, xch-aln-017.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 01:31:45 -0000 SGVsbG8sIEdyZWcsDQoNCj4gT24gSnVuIDE5LCAyMDE5LCBhdCA5OjA5IFBNLCBHcmVnIE1pcnNr eSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IEhpIENhcmxvcywNCj4gdGhh bmsgeW91IGZvciByZW1pbmRpbmcgb2Ygb3VyIGNvbnRpbnVlZCBkaXNjdXNzaW9uIHdpdGggSm9l bC4gV2UgYXJlIHNlZWtpbmcgY29tbWVudHMgZnJvbSBWWExBTiBleHBlcnRzIGFuZCBtdWNoIGFw cHJlY2lhdGUgaWYgeW91IGhhdmUgaW5zaWdodHMgb24gVlhMQU4gdG8gc2hhcmUuDQo+IEkndmUg Z290IHNvbWUgY2xhcmlmeWluZyBxdWVzdGlvbnMgYmVmb3JlIEkgY2FuIHJlc3BvbmQgdG8geW91 Lg0KDQpTdXJlLg0KDQo+IFRvIHdoaWNoIHN0YWdlIG9mIHRoZSB0aHJlZS13YXkgaGFuZHNoYWtl IHlvdSByZWZlciBhcyAiaW5pdGlhbCBkZW11bHRpcGxleGluZyI/IEkgY291bGRuJ3QgZmluZCB0 aGlzIHRlcm0gaW4gUkZDIDU4ODAuDQoNCuKAnEluaXRpYWwgZGVtdWx0aXBsZXhpbmciIGlzIGEg d2VsbC1rbm93biB0ZXJtIGluIEJGRCwgcmVmZXJyaW5nIHRvIHRoZSAiZGVtdWx0aXBsZXhpbmcg b2YgdGhlIGluaXRpYWwgcGFja2V0cyIsIEJGRCBDb250cm9sIHBhY2tldCB3aXRoIFlvdXJEaXNj IGJlaW5nIHplcm8uDQoNCkluIFJGQyA1ODgwLCBzZWUgU2VjdGlvbiA2LjMuDQpodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNTg4MCNzZWN0aW9uLTYuMw0KDQogICBUaGUgbWV0aG9kIG9m IGRlbXVsdGlwbGV4aW5nIHRoZSBpbml0aWFsIHBhY2tldHMgKGluIHdoaWNoIFlvdXINCiAgIERp c2NyaW1pbmF0b3IgaXMgemVybykgaXMgYXBwbGljYXRpb24gZGVwZW5kZW50LCBhbmQgaXMgdGh1 cyBvdXRzaWRlDQogICB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLg0KDQpTaW5jZSBp bml0aWFsIGRlbXVsdGlwbGV4aW5nIGlzIGluZGVlZCBhcHBsaWNhdGlvbiBzcGVjaWZpYywgZGlm ZmVyZW50IGZvciBvbmUtaG9wIHZlcnN1cyBtdWx0aS1ob3AgYW5kIGRlcGVuZGVudCB1cG9uIHdo ZXRoZXIgYSBzaW5nbGUgb3IgbXVsdGlwbGUgc2Vzc2lvbnMgYXJlIGFsbG93ZWQgYmV0d2VlbiBh IHBhaXIgb2YgZW5kcG9pbnRzLCBJIGFkZGVkIGJlbG93IHR3byBvdGhlciByZWxldmFudCBjaXRh dGlvbnMsIGZyb20gYXBwbGljYXRpb24gc3BlY2lmaWMgQkZEIHNwZWNzOg0KMS4gaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzU4ODMjc2VjdGlvbi00IA0KMi4gaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzU4ODIjc2VjdGlvbi02DQoNCg0KPiBSZWdhcmRpbmcgdGhlIGFwcGxp Y2FiaWxpdHkgb2YgdGhlIEVjaG8gbW9kZSwgdGhhbmsgeW91IGZvciBwb2ludGluZyB0byB0aGUg bmVlZCBmb3Igc3RyaWN0ZXIgdGVybWlub2xvZ3ksIHRoZSBFY2hvIG1vZGUsIGFzIGRlZmluZWQg aW4gUkZDIDU4ODAsIGlzIHVuZGVyc3BlY2lmaWVkIGFuZCBpdCB3aWxsIHJlcXVpcmUgYWRkaXRp b25hbCBzdGFuZGFyZGl6YXRpb24uDQoNCk5vLiBCRkQgRWNobyBpcyBub3QgdW5kZXJzcGVjaWZp ZWQgaW4gUkZDIDU4ODAuDQoNClBsZWFzZSByZWFkIFM1OiBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNTg4MCNzZWN0aW9uLTUNCg0KICAgQkZEIEVjaG8gcGFja2V0cyBhcmUgc2VudCBp biBhbiBlbmNhcHN1bGF0aW9uIGFwcHJvcHJpYXRlIHRvIHRoZQ0KICAgZW52aXJvbm1lbnQuICBT ZWUgdGhlIGFwcHJvcHJpYXRlIGFwcGxpY2F0aW9uIGRvY3VtZW50cyBmb3IgdGhlDQogICBzcGVj aWZpY3Mgb2YgcGFydGljdWxhciBlbnZpcm9ubWVudHMuDQoNCg0KQkZEIEVjaG8gaXMgYXBwbGlj YXRpb24gZGVwZW5kZW50LiANCg0KVGhlcmVmb3JlLCBmb3IgZXhhbXBsZSwgc2luZ2xlLWhvcCBC RkQgaW4gUkZDIDU4ODEgc3BlY2lmaWVzIEJGRCBFY2hvIGZvciB0aGF0IGFwcGxpY2F0aW9uLg0K DQpIZW5jZSwgbXkgcXVlc3Rpb24gc3RhbmRzOiB3aHkgaXMgdGhpcyBkcmFmdCBjbGFpbWluZyBC RkQgRWNobyBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgQkZEIGFwcGxpY2F0aW9uIGRvY3VtZW50 Pw0KDQoNCj4gRnV0dXJlIGRyYWZ0cyBtYXkgZXhwbG9yZSBhbmQgZGVmaW5lIGhvdyB0aGUgRWNo byBtb2RlIG9mIEJGRCBpcyB1c2VkIG92ZXIgVlhMQU4gdHVubmVscy4NCj4gDQoNClNlZSBhYm92 ZS4NCg0KPiBXaWxsIHJldmlldyBhbmQgcmVzcG9uZCB0byB0aGUgcmVtYWluaW5nIHF1ZXN0aW9u cyBzb29uLg0KDQpUaGFuayB5b3UuIA0KDQpUaGUgInJlbWFpbmluZyBxdWVzdGlvbnMiIGFyZSBz dGlsbCBhbGwgdGhlIHF1ZXN0aW9ucyBiZWxvdyA6LSkNCg0KQmVzdCwNCg0KQ2FybG9zLg0KDQo+ IA0KPiBSZWdhcmRzLA0KPiBHcmVnDQo+IA0KPiANCj4gT24gVGh1LCBKdW4gMjAsIDIwMTkgYXQg OToxNCBBTSBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgPGNwaWduYXRhQGNpc2NvLmNvbT4g d3JvdGU6DQo+IEhpLA0KPiANCj4gSSBoYXZlIG5vdCByZXZpZXdlZCB0aGlzIGRyYWZ0IGJlZm9y ZSwgYnV0IHRyaWdnZXJlZCBieSB0aGlzIGVtYWlsLCBhbmQgYnJpZWZseSBzY2FubmluZyB0aHJv dWdoIGEgY291cGxlIG9mIHNlY3Rpb25zLCBpdCBpcyB1bmNsZWFyIHRvIG1lIGhvdyBzb21lIG9m IHRoZSBtZWNoYW5pY3Mgd29yay4NCj4gDQo+IFRoZXJlIGFyZSBzb21lIG1ham9yIGlzc3VlcyB3 aXRoIHRoZSBNYWMgdXNhZ2UgYW5kIGFzc29jaWF0aW9uLCBhcyBKb2VsIEhhbHBlcm4gbWVudGlv bmVkIGluIGhpcyBSdGcgRGlyIHJldmlldy4NCj4gDQo+IEFuZCwgYWRkaXRpb25hbGx5LCBwbGVh c2UgY29uc2lkZXIgdGhlIGZvbGxvd2luZyBjb21tZW50cyBhbmQgcXVlc3Rpb25zOg0KPiANCj4g DQo+IDEuIFVuZGVyc3BlY2lmaWNhdGlvbiBmb3IgaW5pdGlhbGl6YXRpb24gYW5kIGluaXRpYWwg ZGVtdWx0aXBsZXhpbmcuDQo+IA0KPiBUaGlzIGRvY3VtZW50IGFsbG93cyBtdWx0aXBsZSBCRkQg c2Vzc2lvbnMgYmV0d2VlbiBhIHNpbmdsZSBwYWlyIG9mIFZURVBzOg0KPiANCj4gICAgQW4NCj4g ICAgaW1wbGVtZW50YXRpb24gdGhhdCBzdXBwb3J0cyB0aGlzIHNwZWNpZmljYXRpb24gTVVTVCBi ZSBhYmxlIHRvDQo+ICAgIGNvbnRyb2wgdGhlIG51bWJlciBvZiBCRkQgc2Vzc2lvbnMgdGhhdCBj YW4gYmUgY3JlYXRlZCBiZXR3ZWVuIHRoZQ0KPiAgICBzYW1lIHBhaXIgb2YgVlRFUHMuDQo+IA0K PiBUaGUgaW1wbGljYXRpb24gb2YgdGhpcyBpcyB0aGF0IEJGRCBzaW5nbGUtaG9wIGluaXRpYWxp emF0aW9uIHByb2NlZHVyZXMgd2lsbCBub3Qgd29yay4gSW5zdGVhZCwgdGhlcmUgaXMgYSBuZWVk IHRvIG1hcCB0aGUgaW5pdGlhbCBkZW11bHRpcGxleGluZy4NCj4gDQo+IFRoaXMgaXNzdWUgaXMg ZXhwbGFpbmVkIGluIFJGQ3MgNTg4MiBhbmQgNTg4MzogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzU4ODMjc2VjdGlvbi00IGFuZCBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NTg4MiNzZWN0aW9uLTYNCj4gDQo+IFNlY3Rpb24gNS4xIHNheXM6DQo+IA0KPiAgICBGb3Igc3Vj aCBwYWNrZXRzLCB0aGUgQkZEIHNlc3Npb24gTVVTVCBiZSBpZGVudGlmaWVkDQo+ICAgIHVzaW5n IHRoZSBpbm5lciBoZWFkZXJzLCBpLmUuLCB0aGUgc291cmNlIElQLCB0aGUgZGVzdGluYXRpb24g SVAsIGFuZA0KPiAgICB0aGUgc291cmNlIFVEUCBwb3J0IG51bWJlciBwcmVzZW50IGluIHRoZSBJ UCBoZWFkZXIgY2FycmllZCBieSB0aGUNCj4gICAgcGF5bG9hZCBvZiB0aGUgVlhMQU4gZW5jYXBz dWxhdGVkIHBhY2tldC4gIFRoZSBWTkkgb2YgdGhlIHBhY2tldA0KPiAgICBTSE9VTEQgYmUgdXNl ZCB0byBkZXJpdmUgaW50ZXJmYWNlLXJlbGF0ZWQgaW5mb3JtYXRpb24gZm9yDQo+ICAgIGRlbXVs dGlwbGV4aW5nIHRoZSBwYWNrZXQuDQo+IA0KPiBCdXQgdGhpcyBkb2VzIG5vdCByZWFsbHkgZXhw bGFpbiBob3cgdG8gZG8gdGhlIGluaXRpYWwgZGVtdWx0aXBsZXhpbmcuIERvZXMgZWFjaCBCRkQg c2Vzc2lvbiBuZWVkIHRvIGhhdmUgYSBzZXBhcmF0ZSBpbm5lciBzb3VyY2UgSVAgYWRkcmVzcz8g T3Igc291cmNlIFVEUCBwb3J0PyBBbmQgaG93IG9mdGVyIGFyZSB0aGV5IHJlY3ljbGVkIG9yIGtl cHQgYXMgc3RhdGU/IEhvdyBhcmUgdGhlc2UgbWFwcGVkPw0KPiBFcXVhbGx5IGltcG9ydGFudGx5 LCB3aGljaCBzaWRlIGlzIEFjdGl2ZT8NCj4gQW5kIHdoYXQgaWYgdGhlcmXigJlzIGEgcmFjZSBj b25kaXRpb24gd2l0aCBib3RoIHNpZGVzIGJlaW5nIEFjdGl2ZSBhbmQgc2V0dGluZyB1cCByZWR1 bmRhbnQgc2Vzc2lvbnM/DQo+IA0KPiAxLmIuIEJ5IHRoZSB3YXksIGJhc2VkIG9uIHRoaXMsIHVz aW5nIFMtQkZEIFtSRkMgNzg4MF0gbWlnaHQgYmUgZWFzaWVyIHRvIGRlbXV4Lg0KPiANCj4gDQo+ IDIuIFNlY3VyaXR5DQo+IA0KPiBUaGlzIGRvY3VtZW50IHNheXMgdGhhdCB0aGUgVFRMIGluIHRo ZSBpbm5lciBwYWNrZXQgY2FycnlpbmcgQkZEIGlzIHNldCB0byAxLiBIb3dldmVyLCBSRkMgNTg4 MCBzYXlzIHRvIHVzZSBHVFNNIFtSRkMgNTA4Ml0sIGkuZS4sIGEgdmFsdWUgb2YgMjU1Li4NCj4g DQo+IFdoeSBpcyBHVFNNIG5vdCB1c2VkIGhlcmU/DQo+IA0KPiANCj4gMy4gRUNNUCBhbmQgZmF0 ZS1zaGFyaW5nIHVuZGVyLXNwZWNpZmljYXRpb246DQo+IA0KPiBTZWN0aW9uIDQuMS4gc2F5czoN Cj4gDQo+ICAgIFRoZSBPdXRlciBJUC9VRFANCj4gICAgYW5kIFZYTEFOIGhlYWRlcnMgTVVTVCBi ZSBlbmNvZGVkIGJ5IHRoZSBzZW5kZXIgYXMgZGVmaW5lZCBpbg0KPiAgICBbUkZDNzM0OF0uDQo+ IA0KPiANCj4gQW5kIFJGQyA3MzQ4IHNheXM6DQo+IA0KPiAgICAgICAtICBTb3VyY2UgUG9ydDog IEl0IGlzIHJlY29tbWVuZGVkIHRoYXQgdGhlIFVEUCBzb3VyY2UgcG9ydCBudW1iZXINCj4gICAg ICAgICAgYmUgY2FsY3VsYXRlZCB1c2luZyBhIGhhc2ggb2YgZmllbGRzIGZyb20gdGhlIGlubmVy IHBhY2tldCAtLQ0KPiAgICAgICAgICBvbmUgZXhhbXBsZSBiZWluZyBhIGhhc2ggb2YgdGhlIGlu bmVyIEV0aGVybmV0IGZyYW1lJ3MgaGVhZGVycy4NCj4gICAgICAgICAgVGhpcyBpcyB0byBlbmFi bGUgYSBsZXZlbCBvZiBlbnRyb3B5IGZvciB0aGUgRUNNUC9sb2FkLQ0KPiAgICAgICAgICBiYWxh bmNpbmcgb2YgdGhlIFZNLXRvLVZNIHRyYWZmaWMgYWNyb3NzIHRoZSBWWExBTiBvdmVybGF5Lg0K PiAgICAgICAgICBXaGVuIGNhbGN1bGF0aW5nIHRoZSBVRFAgc291cmNlIHBvcnQgbnVtYmVyIGlu IHRoaXMgbWFubmVyLCBpdA0KPiAgICAgICAgICBpcyBSRUNPTU1FTkRFRCB0aGF0IHRoZSB2YWx1 ZSBiZSBpbiB0aGUgZHluYW1pYy9wcml2YXRlIHBvcnQNCj4gICAgICAgICAgcmFuZ2UgNDkxNTIt NjU1MzUgW1JGQzYzMzVdLg0KPiANCj4gDQo+IEJhc2VkIG9uIHRoaXMsIGRlcGVuZGluZyBvbiB0 aGUgaGFzaGluZyBjYWxjdWxhdGlvbiwgdGhlIG91dGVyIHNvdXJjZSBVRFAgcG9ydCBjYW4gYmUg ZGlmZmVyZW50IGxlYWRpbmcgdG8gZGlmZmVyZW50IEVDTVAgdHJlYXRtZW50LiBEb2VzIHNvbWV0 aGluZyBlbHNlIG5lZWQgdG8gYmUgc3BlY2lmaWVkIGhlcmUgaW4gcmVnYXJkcyB0byB0aGUgb3V0 ZXIgVURQIHNvdXJjZSBwb3J0Pw0KPiANCj4gDQo+IDQuIFNlY3Rpb24gNyBzYXlzIHRoYXQg4oCc IFN1cHBvcnQgZm9yIGVjaG8gQkZEIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1l bnTigJ0uIA0KPiANCj4gQXNzdW1pbmcgdGhpcyBtZWFucyDigJxCRkQgRWNobyBtb2Rl4oCdLCB3 aHkgaXMgdGhpcyBvdXQgb2Ygc2NvcGU/IElmIHRoaXMgaXMgYSBzaW5nbGUgbG9naWNhbCBob3Ag dW5kZXJuZWF0aCBWWExBTiwgd2hhdOKAmXMgcHJldmVudGluZyB0aGUgdXNlIG9mIEVjaG8/IEVj aG/igJlzIGJlbmVmaXRzIGFyZSBodWdlLg0KPiANCj4gDQo+IDUuIFRlcm1pbm9sb2d5DQo+IA0K PiAgICBJbXBsZW1lbnRhdGlvbnMgU0hPVUxEIGVuc3VyZSB0aGF0IHRoZSBCRkQNCj4gICAgcGFj a2V0cyBmb2xsb3cgdGhlIHNhbWUgbG9va3VwIHBhdGggYXMgVlhMQU4gZGF0YSBwYWNrZXRzIHdp dGhpbiB0aGUNCj4gICAgc2VuZGVyIHN5c3RlbS4NCj4gDQo+IFdoYXQgaXMgYSDigJxsb29rIHVw IHBhdGggd2l0aGluIGEgc2VuZGVyIHN5c3RlbeKAnT8NCj4gDQo+IA0KPiA2LiBEZXBsb3ltZW50 IHNjZW5hcmlvcw0KPiANCj4gUzMgc2F5czoNCj4gICAgRmlndXJlIDEgaWxsdXN0cmF0ZXMgdGhl IHNjZW5hcmlvIHdpdGggdHdvIHNlcnZlcnMsIGVhY2ggb2YgdGhlbQ0KPiAgICBob3N0aW5nIHR3 byBWTXMuICBUaGUgc2VydmVycyBob3N0IFZURVBzIHRoYXQgdGVybWluYXRlIHR3byBWWExBTg0K PiBb4oCmXQ0KPiAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMTogUmVmZXJlbmNlIFZYTEFO IERvbWFpbg0KPiANCj4gDQo+IEhvd2V2ZXIsIFJGQyA3MzQ4IEZpZ3VyZSAzIGxpc3RzIHRoYXQg YXMgb25lIGRlcGxveW1lbnQgc2NlbmFyaW8sIG5vdCBhcyDigJx0aGUgc2NlbmFyaW/igJ0gYW5k IOKAnFRoZSBSZWZlcmVuY2UgVlhMQU4gRG9tYWlu4oCdLg0KPiANCj4gQmVzdCwNCj4gDQo+IENh cmxvcy4NCj4gDQo+PiBPbiBKdW4gMTcsIDIwMTksIGF0IDEyOjU4IEFNLCBHcmVnIE1pcnNreSA8 Z3JlZ2ltaXJza3lAZ21haWwuY29tPiB3cm90ZToNCj4+IA0KPj4gSGkgT2xpdmVyLA0KPj4gdGhh bmsgeW91IGZvciB5b3VyIHRob3JvdWdoIHJldmlldywgY2xlYXIgYW5kIGRldGFpbGVkIHF1ZXN0 aW9ucy4gTXkgYXBvbG9naWVzIGZvciB0aGUgZGVsYXkgdG8gcmVzcG9uZC4gUGxlYXNlIGZpbmQg bXkgYW5zd2VycyBiZWxvdyBpbi1saW5lIHRhZ2dlZCBHSU0+Pi4NCj4+IA0KPj4gUmVnYXJkcywN Cj4+IEdyZWcNCj4+IA0KPj4gT24gRnJpLCBNYXkgMzEsIDIwMTkgYXQgMTI6MzggUE0gT2xpdmll ciBCb25hdmVudHVyZSB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0K Pj4gUmV2aWV3ZXI6IE9saXZpZXIgQm9uYXZlbnR1cmUNCj4+IFJldmlldyByZXN1bHQ6IFJlYWR5 IHdpdGggSXNzdWVzDQo+PiANCj4+IFRoaXMgZG9jdW1lbnQgaGFzIGJlZW4gcmV2aWV3ZWQgYXMg cGFydCBvZiB0aGUgdHJhbnNwb3J0IGFyZWEgcmV2aWV3IHRlYW0ncw0KPj4gb25nb2luZyBlZmZv cnQgdG8gcmV2aWV3IGtleSBJRVRGIGRvY3VtZW50cy4gVGhlc2UgY29tbWVudHMgd2VyZSB3cml0 dGVuDQo+PiBwcmltYXJpbHkgZm9yIHRoZSB0cmFuc3BvcnQgYXJlYSBkaXJlY3RvcnMsIGJ1dCBh cmUgY29waWVkIHRvIHRoZSBkb2N1bWVudCdzDQo+PiBhdXRob3JzIGFuZCBXRyB0byBhbGxvdyB0 aGVtIHRvIGFkZHJlc3MgYW55IGlzc3VlcyByYWlzZWQgYW5kIGFsc28gdG8gdGhlIElFVEYNCj4+ IGRpc2N1c3Npb24gbGlzdCBmb3IgaW5mb3JtYXRpb24uDQo+PiANCj4+IFdoZW4gZG9uZSBhdCB0 aGUgdGltZSBvZiBJRVRGIExhc3QgQ2FsbCwgdGhlIGF1dGhvcnMgc2hvdWxkIGNvbnNpZGVyIHRo aXMNCj4+IHJldmlldyBhcyBwYXJ0IG9mIHRoZSBsYXN0LWNhbGwgY29tbWVudHMgdGhleSByZWNl aXZlLiBQbGVhc2UgYWx3YXlzIENDDQo+PiB0c3YtYXJ0QGlldGYub3JnIGlmIHlvdSByZXBseSB0 byBvciBmb3J3YXJkIHRoaXMgcmV2aWV3Lg0KPj4gDQo+PiBJIGhhdmUgb25seSBsaW1pdGVkIGtu b3dsZWRnZSBvZiBWWExBTiBhbmQgZG8gbm90IGtub3cgYWxsIHN1YnRsZXRpZXMgb2YgQkZELg0K Pj4gVGhpcyByZXZpZXcgaXMgdGh1cyBtb3JlIGZyb20gYSBnZW5lcmFsaXN0IHRoYW4gYSBzcGVj aWFsaXN0IGluIHRoaXMgdG9waWMuDQo+PiANCj4+IE1ham9yIGlzc3Vlcw0KPj4gDQo+PiBTZWN0 aW9uIDQgcmVxdWlyZXMgdGhhdCAiIEltcGxlbWVudGF0aW9ucyBTSE9VTEQgZW5zdXJlIHRoYXQg dGhlIEJGRA0KPj4gICAgcGFja2V0cyBmb2xsb3cgdGhlIHNhbWUgbG9va3VwIHBhdGggYXMgVlhM QU4gZGF0YSBwYWNrZXRzIHdpdGhpbiB0aGUNCj4+ICAgIHNlbmRlciBzeXN0ZW0uIg0KPj4gDQo+ PiBXaHkgaXMgdGhpcyByZXF1aXJlbWVudCBvbmx5IHJlbGV2YW50IGZvciB0aGUgbG9va3VwIHBh dGggb24gdGhlIHNlbmRlciBzeXN0ZW0NCj4+ID8gV2hhdCBkb2VzIHRoaXMgc2VudGVuY2UgcmVh bGx5IGltcGxpZXMgPw0KPj4gR0lNPj4gUkZDIDU4ODAgc2V0IHRoZSBzY29wZSBvZiB0aGUgZmF1 bHQgZGV0ZWN0aW9uIG9mIEJGRCBwcm90b2NvbCBhcyANCj4+ICAgIC4uLiB0aGUgYmlkaXJlY3Rp b25hbCBwYXRoIGJldHdlZW4gdHdvIGZvcndhcmRpbmcgZW5naW5lcywgaW5jbHVkaW5nDQo+PiAg ICBpbnRlcmZhY2VzLCBkYXRhIGxpbmsocyksIGFuZCB0byB0aGUgZXh0ZW50IHBvc3NpYmxlIHRo ZSBmb3J3YXJkaW5nDQo+PiAgICBlbmdpbmVzIHRoZW1zZWx2ZXMgLi4uDQo+PiBUaGUgcmVxdWly ZW1lbnQgYWltZWQgdG8gdGhlIGZvcndhcmRpbmcgZW5naW5lIG9mIGEgQkZEIHN5c3RlbSB0aGF0 IHRyYW5zbWl0cyBCRkQgY29udHJvbCBwYWNrZXRzIG92ZXIgVlhMQU4gdHVubmVsLg0KPj4gDQo+ PiBJcyBpdCBhIHJlcXVpcmVtZW50IHRoYXQgdGhlIEJGRCBwYWNrZXRzIGZvbGxvdyB0aGUgc2Ft ZSBwYXRoIGFzIHRoZSBkYXRhDQo+PiBwYWNrZXQgZm9yIGEgZ2l2ZW4gVlhMQU4gPyBJIGd1ZXNz IHNvLiBJbiB0aGlzIGNhc2UsIHRoZSBkb2N1bWVudCBzaG91bGQNCj4+IGRpc2N1c3MgaG93IEVx dWFsIENvc3QgTXVsdGlwYXRoIGNvdWxkIGFmZmVjdCB0aGlzLg0KPj4gR0lNPj4gSSB0aGluayB0 aGF0IEVDTVAgZW52aXJvbm1lbnQgaXMgbW9yZSBsaWtlbHkgdG8gYmUgZXhwZXJpZW5jZWQgYnkg YSB0cmFuc2l0IG5vZGUgaW4gdGhlIHVuZGVybGF5LiBJZiB0aGUgQkZEIHNlc3Npb24gaXMgdXNl ZCB0byBtb25pdG9yIHRoZSBzcGVjaWZpYyB1bmRlcmxheSBwYXRoLCB0aGVuLCBJIGFncmVlLCB3 ZSBzaG91bGQgZXhwbGFpbiB0aGF0IHVzaW5nIHRoZSBWWExBTiBwYXlsb2FkIGluZm9ybWF0aW9u IHRvIGRyYXcgcGF0aCBlbnRyb3B5IG1heSBjYXVzZSBkYXRhIGFuZCBCRkQgcGFja2V0cyBmb2xs b3dpbmcgZGlmZmVyZW50IHVuZGVybGF5IHJvdXRlcy4gQnV0LCBvbiB0aGUgb3RoZXIgaGFuZCwg dGhhdCBpcyB0aGUgY2FzZSBmb3IgT0FNIGFuZCBmYXVsdCBkZXRlY3Rpb24gaW4gYWxsIG92ZXJs YXkgbmV0d29ya3MgaW4gZ2VuZXJhbC4NCj4+IA0KPj4gTWlub3IgaXNzdWVzDQo+PiANCj4+IFNl Y3Rpb24gMQ0KPj4gDQo+PiBZb3Ugd3JpdGUgIlRoZSBhc3luY2hyb25vdXMgbW9kZSBvZiBCRkQs IGFzIGRlZmluZWQgaW4gW1JGQzU4ODBdLA0KPj4gIGNhbiBiZSB1c2VkIHRvIG1vbml0b3IgYSBw MnAgVlhMQU4gdHVubmVsLiINCj4+IA0KPj4gV2h5IGRvIHlvdSB1c2UgdGhlIHdvcmQgY2FuID8g SXQgaXMgYSBwb3NzaWJpbGl0eSBvciBhIHJlcXVpcmVtZW50ID8NCj4+IEdJTT4+IEluIHByaW5j aXBsZSwgQkZEIERlbWFuZCBtb2RlIG1heSBiZSB1c2VkIHRvIG1vbml0b3IgcDJwIHBhdGhzIGFz IHdlbGwsIEkgYWdyZWUsIHdpbGwgcmUtd29yZCB0byBtb3JlIGFzc2VydGl2ZToNCj4+ICBUaGUg YXN5bmNocm9ub3VzIG1vZGUgb2YgQkZELCBhcyBkZWZpbmVkIGluIFtSRkM1ODgwXSwNCj4+ICBp cyB1c2VkIHRvIG1vbml0b3IgYSBwMnAgVlhMQU4gdHVubmVsLg0KPj4gDQo+PiBOVkUgaGFzIG5v dCBiZWVuIGRlZmluZWQgYmVmb3JlIGFuZCBpcyBub3QgaW4gdGhlIHRlcm1pbm9sb2d5Lg0KPj4g R0lNPj4gV2lsbCBhZGQgdG8gdGhlIFRlcm1pbm9sb2d5IGFuZCBleHBhbmQgYXM6DQo+PiBOVkUg ICAgICAgIE5ldHdvcmsgVmlydHVhbGl6YXRpb24gRW5kcG9pbnQgDQo+PiANCj4+IFRoaXMgZW50 aXJlIHNlY3Rpb24gaXMgbm90IGVhc3kgdG8gcmVhZCBmb3IgYW4gb3V0c2lkZXIuDQo+PiANCj4+ IFNlY3Rpb24gMw0KPj4gDQo+PiBWTkkgaGFzIG5vdCBiZWVuIGRlZmluZWQNCj4+IEdJTT4+IFdp bGwgYWRkIHRvIHRoZSBUZXJtaW5vbG9neSBzZWN0aW9uOg0KPj4gVk5JICAgIFZYTEFOIE5ldHdv cmsgSWRlbnRpZmllciAob3IgVlhMQU4gU2VnbWVudCBJRCkNCj4+IA0KPj4gRmlndXJlIDEgY291 bGQgdGFrZSBsZXNzIHNwYWNlDQo+PiBHSU0+PiBZZXMsIGNhbiBtYWtlIGl0IGJpdCBkZW5zZXIu IFdvdWxkIHRoZSBmb2xsb3dpbmcgYmUgYW4gaW1wcm92ZW1lbnQ/DQo+PiAgDQo+PiAgICAgICAr LS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rDQo+PiAgICAgICB8ICAgICAgICBTZXJ2ZXIgMSAg ICAgICAgICB8DQo+PiAgICAgICB8ICstLS0tKy0tLS0rICArLS0tLSstLS0tKyB8DQo+PiAgICAg ICB8IHxWTTEtMSAgICB8ICB8Vk0xLTIgICAgfCB8DQo+PiAgICAgICB8IHxWTkkgMTAwICB8ICB8 Vk5JIDIwMCAgfCB8DQo+PiAgICAgICB8IHwgICAgICAgICB8ICB8ICAgICAgICAgfCB8DQo+PiAg ICAgICB8ICstLS0tLS0tLS0rICArLS0tLS0tLS0tKyB8DQo+PiAgICAgICB8IEh5cGVydmlzb3Ig VlRFUCAoSVAxKSAgICB8DQo+PiAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgICArLS0tLS0tLS0tLS0tLSsNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8ICAgfCAgIExheWVyIDMgICB8DQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0t LXwgICBOZXR3b3JrICAgfA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0t LS0tLS0tLS0tLSsNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLSsNCj4+ICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tKw0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg IEh5cGVydmlzb3IgVlRFUCAoSVAyKSB8DQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgKy0tLS0rLS0tLSsgICstLS0tKy0tLS0rIHwNCj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCB8Vk0yLTEgICAgfCAgfFZNMi0yICAgIHwg fA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHxWTkkgMTAw ICB8ICB8Vk5JIDIwMCAgfCB8DQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwgfCAgICAgICAgIHwgIHwgICAgICAgICB8IHwNCj4+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCArLS0tLS0tLS0tKyAgKy0tLS0tLS0tLSsgfA0KPj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgU2VydmVyIDIg ICAgICAgICAgICB8DQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+IA0KPj4gDQo+PiBTZWN0aW9uIDQNCj4+ IA0KPj4gSSBkbyBub3Qgc2VlIHRoZSBiZW5lZml0cyBvZiBoYXZpbmcgb25lIHBhcmFncmFwaCBp biBTZWN0aW9uIDQgZm9sbG93ZWQgYnkgb25seQ0KPj4gU2VjdGlvbiA0LjENCj4+IEdJTT4+IFdp bGwgbWVyZ2UgU2VjdGlvbiA0LjEgaW50byA0IHdpdGggbWlub3IgcmVxdWlyZWQgcmUtd29yZGlu ZzoNCj4+IDQuICBCRkQgUGFja2V0IFRyYW5zbWlzc2lvbiBvdmVyIFZYTEFOIFR1bm5lbA0KPj4g DQo+PiAgICBCRkQgcGFja2V0IE1VU1QgYmUgZW5jYXBzdWxhdGVkIGFuZCBzZW50IHRvIGEgcmVt b3RlIFZURVAgYXMNCj4+ICAgIGV4cGxhaW5lZCBpbiB0aGlzIHNlY3Rpb24uICBJbXBsZW1lbnRh dGlvbnMgU0hPVUxEIGVuc3VyZSB0aGF0IHRoZQ0KPj4gICAgQkZEIHBhY2tldHMgZm9sbG93IHRo ZSBzYW1lIGxvb2t1cCBwYXRoIGFzIFZYTEFOIGRhdGEgcGFja2V0cyB3aXRoaW4NCj4+ICAgIHRo ZSBzZW5kZXIgc3lzdGVtLg0KPj4gDQo+PiAgICBCRkQgcGFja2V0cyBhcmUgZW5jYXBzdWxhdGVk IGluIFZYTEFOIGFzIGRlc2NyaWJlZCBiZWxvdy4gIFRoZSBWWExBTg0KPj4gICAgcGFja2V0IGZv cm1hdCBpcyBkZWZpbmVkIGluIFNlY3Rpb24gNSBvZiBbUkZDNzM0OF0uICBUaGUgT3V0ZXIgSVAv VURQDQo+PiAgICBhbmQgVlhMQU4gaGVhZGVycyBNVVNUIGJlIGVuY29kZWQgYnkgdGhlIHNlbmRl ciBhcyBkZWZpbmVkIGluDQo+PiAgICBbUkZDNzM0OF0uDQo+PiANCj4+IFNlY3Rpb24gNC4xDQo+ PiANCj4+IFRoZSBkb2N1bWVudCBkb2VzIG5vdCBzcGVjaWZ5IHdoZW4gYSBkZWRpY2F0ZWQgTUFD IGFkZHJlc3Mgb3IgdGhlIE1BQyBhZGRyZXNzDQo+PiBvZiB0aGUgZGVzdGluYXRpb24gVlRFUCBt dXN0IGJlIHVzZWQuIFRoaXMgY291bGQgYWZmZWN0IHRoZSBpbnRlcm9wZXJhYmlsaXR5IG9mDQo+ PiBpbXBsZW1lbnRhdGlvbnMuIFNob3VsZCBhbGwgaW1wbGVtZW50YXRpb25zIHN1cHBvcnQgYm90 aCB0aGUgZGVkaWNhdGVkIE1BQw0KPj4gYWRkcmVzcyBhbmQgdGhlIGRlc3RpbmF0aW9uIE1BQyBh ZGRyZXNzID8NCj4+IEdJTT4+IEFmdGVyIGZ1cnRoZXIgZGlzY3Vzc2lvbiwgYXV0aG9ycyBkZWNp ZGVkIHRvIHJlbW92ZSB0aGUgcmVxdWVzdCBmb3IgdGhlIGRlZGljYXRlZCBNQUMgYWRkcmVzcyBh bGxvY2F0aW9uLiBPbmx5IHRoZSBNQUMgYWRkcmVzcyBvZiB0aGUgcmVtb3RlIFZURVAgbXVzdCBi ZSB1c2VkIGFzIHRoZSBkZXN0aW5hdGlvbiBNQUMgYWRkcmVzcyBpbiB0aGUgaW5uZXIgRXRoZXJu ZXQgZnJhbWUuIFBsZWFzZSBjaGVjayB0aGUgYXR0YWNoZWQgZGlmZiBiZXR3ZWVuIHRoZSAtMDcg YW5kIHRoZSB3b3JraW5nIHZlcnNpb25zIG9yIHRoZSB3b3JraW5nIHZlcnNpb24gb2YgdGhlIGRy YWZ0Lg0KPj4gDQo+PiBJdCBpcyB1bmNsZWFyIGZyb20gdGhpcyBzZWN0aW9uIHdoZXRoZXIgSVB2 NCBpbnNpZGUgSVB2NiBhbmQgdGhlIG9wcG9zaXRlDQo+PiBzaG91bGQgYmUgc3VwcG9ydGVkIG9y IG5vdC4NCj4+IEdJTT4+IEFueSBjb21iaW5hdGlvbiBvZiBvdXRlciBJUHZYIGFuZCBpbm5lciBJ UHZYIGlzIHBvc3NpYmxlLg0KPj4gDQo+PiBTZWN0aW9uIDUuDQo+PiANCj4+IElmIHRoZSByZWNl aXZlZCBwYWNrZXQgZG9lcyBub3QgbWF0Y2ggdGhlIGRlZGljYXRlZCBNQUMgYWRkcmVzcyBub3Ig dGhlIE1BQw0KPj4gYWRkcmVzcyBvZiB0aGUgVlRFUCwgc2hvdWxkIHRoZSBwYWNrZXQgYmUgc2ls ZW50bHkgZGlzY2FyZGVkIG9yIHRyZWF0ZWQNCj4+IGRpZmZlcmVudGx5ID8NCj4+IEdJTT4+IEFz IEkndmUgbWVudGlvbmVkIGVhcmxpZXIsIGF1dGhvcnMgaGF2ZSBkZWNpZGVkIHRvIHJlbW92ZSB0 aGUgdXNlIG9mIHRoZSBkZWRpY2F0ZWQgTUFDIGFkZHJlc3MgZm9yIEJGRCBvdmVyIFZYTEFOLg0K Pj4gDQo+PiBTZWN0aW9uIDUuMQ0KPj4gDQo+PiBJcyB0aGlzIGEgbW9kaWZpY2F0aW9uIHRvIHNl Y3Rpb24gNi4zIG9mIFJGQzU4ODAgPyBUaGlzIGlzIG5vdCBjbGVhcg0KPj4gR0lNPj4gSSB0aGlu ayB0aGF0IHRoaXMgc2VjdGlvbiBpcyBub3QgbW9kaWZpY2F0aW9uIGJ1dCB0aGUgZGVmaW5pdGlv biBvZiB0aGUgYXBwbGljYXRpb24tc3BlY2lmaWMgcHJvY2VkdXJlIHRoYXQgaXMgb3V0c2lkZSB0 aGUgc2NvcGUgb2YgUkZDIDU4ODA6DQo+PiAgICBUaGUgbWV0aG9kIG9mIGRlbXVsdGlwbGV4aW5n IHRoZSBpbml0aWFsIHBhY2tldHMgKGluIHdoaWNoIFlvdXINCj4+ICAgIERpc2NyaW1pbmF0b3Ig aXMgemVybykgaXMgYXBwbGljYXRpb24gZGVwZW5kZW50LCBhbmQgaXMgdGh1cyBvdXRzaWRlDQo+ PiAgICB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLg0KPj4gDQo+PiBTZWN0aW9uIDkN Cj4+IA0KPj4gVGhlIHNlbnRlbmNlICIgVGhyb3R0bGluZyBNQVkgYmUgcmVsYXhlZCBmb3IgQkZE IHBhY2tldHMNCj4+ICAgIGJhc2VkIG9uIHBvcnQgbnVtYmVyLiIgaXMgdW5jbGVhci4NCj4+IEdJ TT4+IFllcywgdGhhbmsgeW91IGZvciBwb2ludGluZyB0byB0aGlzLiBUaGUgdXBkYXRlZCB0ZXh0 LCBpbiB0aGUgd2hvbGUgcGFyYWdyYXBoLCBpcyBhcyBmb2xsb3dzOg0KPj4gTkVXIFRFWFQ6DQo+ PiAgICBUaGUgZG9jdW1lbnQgcmVxdWlyZXMgc2V0dGluZyB0aGUgaW5uZXIgSVAgVFRMIHRvIDEs IHdoaWNoIGNvdWxkIGJlDQo+PiAgICB1c2VkIGFzIGEgRERvUyBhdHRhY2sgdmVjdG9yLiAgVGh1 cyB0aGUgaW1wbGVtZW50YXRpb24gTVVTVCBoYXZlDQo+PiAgICB0aHJvdHRsaW5nIGluIHBsYWNl IHRvIGNvbnRyb2wgdGhlIHJhdGUgb2YgQkZEIGNvbnRyb2wgcGFja2V0cyBzZW50DQo+PiAgICB0 byB0aGUgY29udHJvbCBwbGFuZS4gIE9uIHRoZSBvdGhlciBoYW5kLCBvdmVyIGFnZ3Jlc3NpdmUg dGhyb3R0bGluZw0KPj4gICAgb2YgQkZEIGNvbnRyb2wgcGFja2V0cyBtYXkgYmVjb21lIHRoZSBj YXVzZSBvZiB0aGUgaW5hYmlsaXR5IHRvIGZvcm0NCj4+ICAgIGFuZCBtYWludGFpbiBCRkQgc2Vz c2lvbiBhdCBzY2FsZS4gIEhlbmNlLCB0aHJvdHRsaW5nIG9mIEJGRCBjb250cm9sDQo+PiAgICBw YWNrZXRzIFNIT1VMRCBiZSBhZGp1c3RlZCB0byBwZXJtaXQgQkZEIHRvIHdvcmsgYWNjb3JkaW5n IHRvIGl0cw0KPj4gICAgcHJvY2VkdXJlcy4NCj4+IDxkcmFmdC1pZXRmLWJmZC12eGxhbi0wOC50 eHQ+PERpZmZfIGRyYWZ0LWlldGYtYmZkLXZ4bGFuLTA3LnR4dCAtIGRyYWZ0LWlldGYtYmZkLXZ4 bGFuLTA4LnR4dC5odG1sPg0KPiANCg0K From nobody Wed Jun 19 19:44:01 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4066112049B; Wed, 19 Jun 2019 17:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=M82fh4ye; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=NkK/DQY9 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 7mhMK4ZBHKMI; Wed, 19 Jun 2019 17:14:44 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 612961202D4; Wed, 19 Jun 2019 17:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43693; q=dns/txt; s=iport; t=1560989684; x=1562199284; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=lDKtzqL2RUGu5rQV6DiYsrwaim/igdTzkjvJv5cQi1o=; b=M82fh4ye5DbIbpGncgDfCNMOsQahlZRwsvsBmnivorVSdkZMMeHFC9qr HZB8G8YGttfPGO+6HkObcoq2wqdlzYYyPL/EfSmCid7jHQnkkYSiOXE5G uxU16UqXlQLucPYlCha91dWl54ldpgoWIt2bhM2c5di1neZIRJaoJqcW4 w=; IronPort-PHdr: =?us-ascii?q?9a23=3AuHmNRxIcXoNlhxOzLdmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXEbjLfHsZjAzNM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DxAAAZzwpd/5xdJa1mHQEBBQEHBQG?= =?us-ascii?q?BVQYBCwGBQ1ADalUgBAsoCoQMg0cDjmCCMolqjXGBLhSBEANUCQEBAQwBASM?= =?us-ascii?q?KAgEBhEACF4JBIzYHDgEDAQEEAQECAQVtijcMhUsCBBIICR0BASUSAQ8CAQg?= =?us-ascii?q?4BwMCAgIfERQRAgQOBSKDAAGBHU0DHQECDKJJAoE4iF9xgTGCeQEBBYUBDQu?= =?us-ascii?q?CEAMGgTQBiRSBHoErF4FAP4EQAScME4JMPoIaRwEBAgGBKgEBCwcBCRUYFQE?= =?us-ascii?q?LglIygiaLdC2Bci6EdIhMjSo+CQKCEYZIiR8Eg2gbgieHBoQKhWCCUoFLlEG?= =?us-ascii?q?BaopRgwgCBAIEBQIOAQEFgVcELSo9cXAVOyoBgkE+ggMLGINNhRSFPgFygSm?= =?us-ascii?q?LTA8XgQsBgSABAQ?= X-IronPort-AV: E=Sophos;i="5.63,394,1557187200"; d="scan'208,217";a="575917988" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Jun 2019 00:14:42 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x5K0Egvx015790 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Jun 2019 00:14:42 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 19 Jun 2019 19:14:42 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 19 Jun 2019 19:14:41 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 19 Jun 2019 20:14:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lDKtzqL2RUGu5rQV6DiYsrwaim/igdTzkjvJv5cQi1o=; b=NkK/DQY9vIwH/Z39j4bhQ9g+hlQXQ5/XwWiMVmBwxd0tslPmP7RgBrYDMuX4HXUTPAdn/nVNfstFPi5q64FaLI6r/maHmXWVHglAbp5plM0WR9YrJXmHKRq0PaX3hCP/NZK9IR6Ayi1Hk5XQkFvJWwYVjSQyzETFyBIzoGR7YDA= Received: from BL0PR11MB3028.namprd11.prod.outlook.com (20.177.204.138) by BL0PR11MB2994.namprd11.prod.outlook.com (20.177.204.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.13; Thu, 20 Jun 2019 00:14:39 +0000 Received: from BL0PR11MB3028.namprd11.prod.outlook.com ([fe80::ec33:f4c1:227a:fcb3]) by BL0PR11MB3028.namprd11.prod.outlook.com ([fe80::ec33:f4c1:227a:fcb3%5]) with mapi id 15.20.1987.014; Thu, 20 Jun 2019 00:14:39 +0000 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: Olivier Bonaventure , "tsv-art@ietf.org" , rtg-bfd WG , "draft-ietf-bfd-vxlan.all@ietf.org" , IETF list Subject: Re: Tsvart last call review of draft-ietf-bfd-vxlan-07 Thread-Topic: Tsvart last call review of draft-ietf-bfd-vxlan-07 Thread-Index: AQHVJMqh+O1Bih53oEC7haZ3x5KaoKajsLYA Date: Thu, 20 Jun 2019 00:14:39 +0000 Message-ID: <14822B96-D3C6-495E-8661-198068F72ABA@cisco.com> References: <155933149484.6565.7386019489022348116@ietfa.amsl.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.11) authentication-results: spf=none (sender IP is ) smtp.mailfrom=cpignata@cisco.com; x-originating-ip: [173.38.117.68] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e40af728-a24e-4adb-9549-08d6f514491a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BL0PR11MB2994; x-ms-traffictypediagnostic: BL0PR11MB2994: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0074BBE012 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(39860400002)(346002)(136003)(366004)(199004)(51444003)(189003)(71200400001)(8936002)(71190400001)(606006)(6116002)(36756003)(6916009)(3846002)(7736002)(6246003)(81156014)(66946007)(76116006)(81166006)(8676002)(53936002)(66446008)(33656002)(966005)(50226002)(64756008)(1411001)(229853002)(66476007)(66556008)(25786009)(478600001)(73956011)(4326008)(68736007)(14454004)(57306001)(26005)(486006)(6436002)(2906002)(76176011)(316002)(5660300002)(186003)(14444005)(86362001)(446003)(6486002)(30864003)(11346002)(476003)(6306002)(6512007)(2616005)(54896002)(5024004)(66066001)(256004)(102836004)(6506007)(54906003)(53546011)(99286004)(236005); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR11MB2994; H:BL0PR11MB3028.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: kupskbEelWQVWbpc4FxhqIGNKB318v/gjIlSNf1nddzMZj7LJnXuC6zgbPS1pjMyycxR7bSLqYVn98ovTRjW8vSFKmEsyy/knVWTTUXjcGrDSZeo8mmX5VwxsW/lrdp5O/PAMMcZeTjKXb4tBnuJzY9uQIfs5z+7PE68jQjWOST1BtHv2aYDzdarYt9PmDgD6KhX7Fh9ufchBPSd0z0OQH0CCtCDla8IH1yfHIncfqAvvo9YBAiorR9lMCYZq0EOw1hjsn8ljDm+Z60OvuUE+5bA7zMuNIwu5rcJ15HeOZdlUIH6KONcceeM1ZbyUo3n3W26VUEiKYiytY5APpYGWmRLE2+tGtfbdNeTl/KY0Vz2GI+nyC0Ek7KSLxNPFJFdUddh4SgjWGAy30i81r1jnC4Yvu7TwRixWEPRy4XzFyQ= Content-Type: multipart/alternative; boundary="_000_14822B96D3C6495E8661198068F72ABAciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e40af728-a24e-4adb-9549-08d6f514491a X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2019 00:14:39.1895 (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-CrossTenant-userprincipalname: cpignata@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB2994 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.21, xch-aln-011.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: X-Mailman-Approved-At: Wed, 19 Jun 2019 19:43:59 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 00:14:49 -0000 --_000_14822B96D3C6495E8661198068F72ABAciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgaGF2ZSBub3QgcmV2aWV3ZWQgdGhpcyBkcmFmdCBiZWZvcmUsIGJ1dCB0cmlnZ2Vy ZWQgYnkgdGhpcyBlbWFpbCwgYW5kIGJyaWVmbHkgc2Nhbm5pbmcgdGhyb3VnaCBhIGNvdXBsZSBv ZiBzZWN0aW9ucywgaXQgaXMgdW5jbGVhciB0byBtZSBob3cgc29tZSBvZiB0aGUgbWVjaGFuaWNz IHdvcmsuDQoNClRoZXJlIGFyZSBzb21lIG1ham9yIGlzc3VlcyB3aXRoIHRoZSBNYWMgdXNhZ2Ug YW5kIGFzc29jaWF0aW9uLCBhcyBKb2VsIEhhbHBlcm4gbWVudGlvbmVkIGluIGhpcyBSdGcgRGly IHJldmlldy4NCg0KQW5kLCBhZGRpdGlvbmFsbHksIHBsZWFzZSBjb25zaWRlciB0aGUgZm9sbG93 aW5nIGNvbW1lbnRzIGFuZCBxdWVzdGlvbnM6DQoNCg0KMS4gVW5kZXJzcGVjaWZpY2F0aW9uIGZv ciBpbml0aWFsaXphdGlvbiBhbmQgaW5pdGlhbCBkZW11bHRpcGxleGluZy4NCg0KVGhpcyBkb2N1 bWVudCBhbGxvd3MgbXVsdGlwbGUgQkZEIHNlc3Npb25zIGJldHdlZW4gYSBzaW5nbGUgcGFpciBv ZiBWVEVQczoNCg0KICAgQW4NCiAgIGltcGxlbWVudGF0aW9uIHRoYXQgc3VwcG9ydHMgdGhpcyBz cGVjaWZpY2F0aW9uIE1VU1QgYmUgYWJsZSB0bw0KICAgY29udHJvbCB0aGUgbnVtYmVyIG9mIEJG RCBzZXNzaW9ucyB0aGF0IGNhbiBiZSBjcmVhdGVkIGJldHdlZW4gdGhlDQogICBzYW1lIHBhaXIg b2YgVlRFUHMuDQoNClRoZSBpbXBsaWNhdGlvbiBvZiB0aGlzIGlzIHRoYXQgQkZEIHNpbmdsZS1o b3AgaW5pdGlhbGl6YXRpb24gcHJvY2VkdXJlcyB3aWxsIG5vdCB3b3JrLiBJbnN0ZWFkLCB0aGVy ZSBpcyBhIG5lZWQgdG8gbWFwIHRoZSBpbml0aWFsIGRlbXVsdGlwbGV4aW5nLg0KDQpUaGlzIGlz c3VlIGlzIGV4cGxhaW5lZCBpbiBSRkNzIDU4ODIgYW5kIDU4ODM6IGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM1ODgzI3NlY3Rpb24tNCBhbmQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzU4ODIjc2VjdGlvbi02DQoNClNlY3Rpb24gNS4xIHNheXM6DQoNCiAgIEZvciBzdWNo IHBhY2tldHMsIHRoZSBCRkQgc2Vzc2lvbiBNVVNUIGJlIGlkZW50aWZpZWQNCiAgIHVzaW5nIHRo ZSBpbm5lciBoZWFkZXJzLCBpLmUuLCB0aGUgc291cmNlIElQLCB0aGUgZGVzdGluYXRpb24gSVAs IGFuZA0KICAgdGhlIHNvdXJjZSBVRFAgcG9ydCBudW1iZXIgcHJlc2VudCBpbiB0aGUgSVAgaGVh ZGVyIGNhcnJpZWQgYnkgdGhlDQogICBwYXlsb2FkIG9mIHRoZSBWWExBTiBlbmNhcHN1bGF0ZWQg cGFja2V0LiAgVGhlIFZOSSBvZiB0aGUgcGFja2V0DQogICBTSE9VTEQgYmUgdXNlZCB0byBkZXJp dmUgaW50ZXJmYWNlLXJlbGF0ZWQgaW5mb3JtYXRpb24gZm9yDQogICBkZW11bHRpcGxleGluZyB0 aGUgcGFja2V0Lg0KDQpCdXQgdGhpcyBkb2VzIG5vdCByZWFsbHkgZXhwbGFpbiBob3cgdG8gZG8g dGhlIGluaXRpYWwgZGVtdWx0aXBsZXhpbmcuIERvZXMgZWFjaCBCRkQgc2Vzc2lvbiBuZWVkIHRv IGhhdmUgYSBzZXBhcmF0ZSBpbm5lciBzb3VyY2UgSVAgYWRkcmVzcz8gT3Igc291cmNlIFVEUCBw b3J0PyBBbmQgaG93IG9mdGVyIGFyZSB0aGV5IHJlY3ljbGVkIG9yIGtlcHQgYXMgc3RhdGU/IEhv dyBhcmUgdGhlc2UgbWFwcGVkPw0KRXF1YWxseSBpbXBvcnRhbnRseSwgd2hpY2ggc2lkZSBpcyBB Y3RpdmU/DQpBbmQgd2hhdCBpZiB0aGVyZeKAmXMgYSByYWNlIGNvbmRpdGlvbiB3aXRoIGJvdGgg c2lkZXMgYmVpbmcgQWN0aXZlIGFuZCBzZXR0aW5nIHVwIHJlZHVuZGFudCBzZXNzaW9ucz8NCg0K MS5iLiBCeSB0aGUgd2F5LCBiYXNlZCBvbiB0aGlzLCB1c2luZyBTLUJGRCBbUkZDIDc4ODBdIG1p Z2h0IGJlIGVhc2llciB0byBkZW11eC4NCg0KDQoyLiBTZWN1cml0eQ0KDQpUaGlzIGRvY3VtZW50 IHNheXMgdGhhdCB0aGUgVFRMIGluIHRoZSBpbm5lciBwYWNrZXQgY2FycnlpbmcgQkZEIGlzIHNl dCB0byAxLiBIb3dldmVyLCBSRkMgNTg4MCBzYXlzIHRvIHVzZSBHVFNNIFtSRkMgNTA4Ml0sIGku ZS4sIGEgdmFsdWUgb2YgMjU1Lg0KDQpXaHkgaXMgR1RTTSBub3QgdXNlZCBoZXJlPw0KDQoNCjMu IEVDTVAgYW5kIGZhdGUtc2hhcmluZyB1bmRlci1zcGVjaWZpY2F0aW9uOg0KDQpTZWN0aW9uIDQu MS4gc2F5czoNCg0KICAgVGhlIE91dGVyIElQL1VEUA0KICAgYW5kIFZYTEFOIGhlYWRlcnMgTVVT VCBiZSBlbmNvZGVkIGJ5IHRoZSBzZW5kZXIgYXMgZGVmaW5lZCBpbg0KICAgW1JGQzczNDhdLg0K DQoNCkFuZCBSRkMgNzM0OCBzYXlzOg0KDQogICAgICAtICBTb3VyY2UgUG9ydDogIEl0IGlzIHJl Y29tbWVuZGVkIHRoYXQgdGhlIFVEUCBzb3VyY2UgcG9ydCBudW1iZXINCiAgICAgICAgIGJlIGNh bGN1bGF0ZWQgdXNpbmcgYSBoYXNoIG9mIGZpZWxkcyBmcm9tIHRoZSBpbm5lciBwYWNrZXQgLS0N CiAgICAgICAgIG9uZSBleGFtcGxlIGJlaW5nIGEgaGFzaCBvZiB0aGUgaW5uZXIgRXRoZXJuZXQg ZnJhbWUncyBoZWFkZXJzLg0KICAgICAgICAgVGhpcyBpcyB0byBlbmFibGUgYSBsZXZlbCBvZiBl bnRyb3B5IGZvciB0aGUgRUNNUC9sb2FkLQ0KICAgICAgICAgYmFsYW5jaW5nIG9mIHRoZSBWTS10 by1WTSB0cmFmZmljIGFjcm9zcyB0aGUgVlhMQU4gb3ZlcmxheS4NCiAgICAgICAgIFdoZW4gY2Fs Y3VsYXRpbmcgdGhlIFVEUCBzb3VyY2UgcG9ydCBudW1iZXIgaW4gdGhpcyBtYW5uZXIsIGl0DQog ICAgICAgICBpcyBSRUNPTU1FTkRFRCB0aGF0IHRoZSB2YWx1ZSBiZSBpbiB0aGUgZHluYW1pYy9w cml2YXRlIHBvcnQNCiAgICAgICAgIHJhbmdlIDQ5MTUyLTY1NTM1IFtSRkM2MzM1XS4NCg0KDQpC YXNlZCBvbiB0aGlzLCBkZXBlbmRpbmcgb24gdGhlIGhhc2hpbmcgY2FsY3VsYXRpb24sIHRoZSBv dXRlciBzb3VyY2UgVURQIHBvcnQgY2FuIGJlIGRpZmZlcmVudCBsZWFkaW5nIHRvIGRpZmZlcmVu dCBFQ01QIHRyZWF0bWVudC4gRG9lcyBzb21ldGhpbmcgZWxzZSBuZWVkIHRvIGJlIHNwZWNpZmll ZCBoZXJlIGluIHJlZ2FyZHMgdG8gdGhlIG91dGVyIFVEUCBzb3VyY2UgcG9ydD8NCg0KDQo0LiBT ZWN0aW9uIDcgc2F5cyB0aGF0IOKAnCBTdXBwb3J0IGZvciBlY2hvIEJGRCBpcyBvdXRzaWRlIHRo ZSBzY29wZSBvZiB0aGlzIGRvY3VtZW504oCdLg0KDQpBc3N1bWluZyB0aGlzIG1lYW5zIOKAnEJG RCBFY2hvIG1vZGXigJ0sIHdoeSBpcyB0aGlzIG91dCBvZiBzY29wZT8gSWYgdGhpcyBpcyBhIHNp bmdsZSBsb2dpY2FsIGhvcCB1bmRlcm5lYXRoIFZYTEFOLCB3aGF04oCZcyBwcmV2ZW50aW5nIHRo ZSB1c2Ugb2YgRWNobz8gRWNob+KAmXMgYmVuZWZpdHMgYXJlIGh1Z2UuDQoNCg0KNS4gVGVybWlu b2xvZ3kNCg0KICAgSW1wbGVtZW50YXRpb25zIFNIT1VMRCBlbnN1cmUgdGhhdCB0aGUgQkZEDQog ICBwYWNrZXRzIGZvbGxvdyB0aGUgc2FtZSBsb29rdXAgcGF0aCBhcyBWWExBTiBkYXRhIHBhY2tl dHMgd2l0aGluIHRoZQ0KICAgc2VuZGVyIHN5c3RlbS4NCg0KV2hhdCBpcyBhIOKAnGxvb2sgdXAg cGF0aCB3aXRoaW4gYSBzZW5kZXIgc3lzdGVt4oCdPw0KDQoNCjYuIERlcGxveW1lbnQgc2NlbmFy aW9zDQoNClMzIHNheXM6DQogICBGaWd1cmUgMSBpbGx1c3RyYXRlcyB0aGUgc2NlbmFyaW8gd2l0 aCB0d28gc2VydmVycywgZWFjaCBvZiB0aGVtDQogICBob3N0aW5nIHR3byBWTXMuICBUaGUgc2Vy dmVycyBob3N0IFZURVBzIHRoYXQgdGVybWluYXRlIHR3byBWWExBTg0KW+KApl0NCiAgICAgICAg ICAgICAgICAgICAgIEZpZ3VyZSAxOiBSZWZlcmVuY2UgVlhMQU4gRG9tYWluDQoNCg0KSG93ZXZl ciwgUkZDIDczNDggRmlndXJlIDMgbGlzdHMgdGhhdCBhcyBvbmUgZGVwbG95bWVudCBzY2VuYXJp bywgbm90IGFzIOKAnHRoZSBzY2VuYXJpb+KAnSBhbmQg4oCcVGhlIFJlZmVyZW5jZSBWWExBTiBE b21haW7igJ0uDQoNCkJlc3QsDQoNCkNhcmxvcy4NCg0KT24gSnVuIDE3LCAyMDE5LCBhdCAxMjo1 OCBBTSwgR3JlZyBNaXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2ltaXJz a3lAZ21haWwuY29tPj4gd3JvdGU6DQoNCkhpIE9saXZlciwNCnRoYW5rIHlvdSBmb3IgeW91ciB0 aG9yb3VnaCByZXZpZXcsIGNsZWFyIGFuZCBkZXRhaWxlZCBxdWVzdGlvbnMuIE15IGFwb2xvZ2ll cyBmb3IgdGhlIGRlbGF5IHRvIHJlc3BvbmQuIFBsZWFzZSBmaW5kIG15IGFuc3dlcnMgYmVsb3cg aW4tbGluZSB0YWdnZWQgR0lNPj4uDQoNClJlZ2FyZHMsDQpHcmVnDQoNCk9uIEZyaSwgTWF5IDMx LCAyMDE5IGF0IDEyOjM4IFBNIE9saXZpZXIgQm9uYXZlbnR1cmUgdmlhIERhdGF0cmFja2VyIDxu b3JlcGx5QGlldGYub3JnPG1haWx0bzpub3JlcGx5QGlldGYub3JnPj4gd3JvdGU6DQpSZXZpZXdl cjogT2xpdmllciBCb25hdmVudHVyZQ0KUmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0aCBJc3N1ZXMN Cg0KVGhpcyBkb2N1bWVudCBoYXMgYmVlbiByZXZpZXdlZCBhcyBwYXJ0IG9mIHRoZSB0cmFuc3Bv cnQgYXJlYSByZXZpZXcgdGVhbSdzDQpvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcga2V5IElFVEYg ZG9jdW1lbnRzLiBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4NCnByaW1hcmlseSBmb3IgdGhl IHRyYW5zcG9ydCBhcmVhIGRpcmVjdG9ycywgYnV0IGFyZSBjb3BpZWQgdG8gdGhlIGRvY3VtZW50 J3MNCmF1dGhvcnMgYW5kIFdHIHRvIGFsbG93IHRoZW0gdG8gYWRkcmVzcyBhbnkgaXNzdWVzIHJh aXNlZCBhbmQgYWxzbyB0byB0aGUgSUVURg0KZGlzY3Vzc2lvbiBsaXN0IGZvciBpbmZvcm1hdGlv bi4NCg0KV2hlbiBkb25lIGF0IHRoZSB0aW1lIG9mIElFVEYgTGFzdCBDYWxsLCB0aGUgYXV0aG9y cyBzaG91bGQgY29uc2lkZXIgdGhpcw0KcmV2aWV3IGFzIHBhcnQgb2YgdGhlIGxhc3QtY2FsbCBj b21tZW50cyB0aGV5IHJlY2VpdmUuIFBsZWFzZSBhbHdheXMgQ0MNCnRzdi1hcnRAaWV0Zi5vcmc8 bWFpbHRvOnRzdi1hcnRAaWV0Zi5vcmc+IGlmIHlvdSByZXBseSB0byBvciBmb3J3YXJkIHRoaXMg cmV2aWV3Lg0KDQpJIGhhdmUgb25seSBsaW1pdGVkIGtub3dsZWRnZSBvZiBWWExBTiBhbmQgZG8g bm90IGtub3cgYWxsIHN1YnRsZXRpZXMgb2YgQkZELg0KVGhpcyByZXZpZXcgaXMgdGh1cyBtb3Jl IGZyb20gYSBnZW5lcmFsaXN0IHRoYW4gYSBzcGVjaWFsaXN0IGluIHRoaXMgdG9waWMuDQoNCk1h am9yIGlzc3Vlcw0KDQpTZWN0aW9uIDQgcmVxdWlyZXMgdGhhdCAiIEltcGxlbWVudGF0aW9ucyBT SE9VTEQgZW5zdXJlIHRoYXQgdGhlIEJGRA0KICAgcGFja2V0cyBmb2xsb3cgdGhlIHNhbWUgbG9v a3VwIHBhdGggYXMgVlhMQU4gZGF0YSBwYWNrZXRzIHdpdGhpbiB0aGUNCiAgIHNlbmRlciBzeXN0 ZW0uIg0KDQpXaHkgaXMgdGhpcyByZXF1aXJlbWVudCBvbmx5IHJlbGV2YW50IGZvciB0aGUgbG9v a3VwIHBhdGggb24gdGhlIHNlbmRlciBzeXN0ZW0NCj8gV2hhdCBkb2VzIHRoaXMgc2VudGVuY2Ug cmVhbGx5IGltcGxpZXMgPw0KR0lNPj4gUkZDIDU4ODAgc2V0IHRoZSBzY29wZSBvZiB0aGUgZmF1 bHQgZGV0ZWN0aW9uIG9mIEJGRCBwcm90b2NvbCBhcw0KICAgLi4uIHRoZSBiaWRpcmVjdGlvbmFs IHBhdGggYmV0d2VlbiB0d28gZm9yd2FyZGluZyBlbmdpbmVzLCBpbmNsdWRpbmcNCiAgIGludGVy ZmFjZXMsIGRhdGEgbGluayhzKSwgYW5kIHRvIHRoZSBleHRlbnQgcG9zc2libGUgdGhlIGZvcndh cmRpbmcNCiAgIGVuZ2luZXMgdGhlbXNlbHZlcyAuLi4NClRoZSByZXF1aXJlbWVudCBhaW1lZCB0 byB0aGUgZm9yd2FyZGluZyBlbmdpbmUgb2YgYSBCRkQgc3lzdGVtIHRoYXQgdHJhbnNtaXRzIEJG RCBjb250cm9sIHBhY2tldHMgb3ZlciBWWExBTiB0dW5uZWwuDQoNCklzIGl0IGEgcmVxdWlyZW1l bnQgdGhhdCB0aGUgQkZEIHBhY2tldHMgZm9sbG93IHRoZSBzYW1lIHBhdGggYXMgdGhlIGRhdGEN CnBhY2tldCBmb3IgYSBnaXZlbiBWWExBTiA/IEkgZ3Vlc3Mgc28uIEluIHRoaXMgY2FzZSwgdGhl IGRvY3VtZW50IHNob3VsZA0KZGlzY3VzcyBob3cgRXF1YWwgQ29zdCBNdWx0aXBhdGggY291bGQg YWZmZWN0IHRoaXMuDQpHSU0+PiBJIHRoaW5rIHRoYXQgRUNNUCBlbnZpcm9ubWVudCBpcyBtb3Jl IGxpa2VseSB0byBiZSBleHBlcmllbmNlZCBieSBhIHRyYW5zaXQgbm9kZSBpbiB0aGUgdW5kZXJs YXkuIElmIHRoZSBCRkQgc2Vzc2lvbiBpcyB1c2VkIHRvIG1vbml0b3IgdGhlIHNwZWNpZmljIHVu ZGVybGF5IHBhdGgsIHRoZW4sIEkgYWdyZWUsIHdlIHNob3VsZCBleHBsYWluIHRoYXQgdXNpbmcg dGhlIFZYTEFOIHBheWxvYWQgaW5mb3JtYXRpb24gdG8gZHJhdyBwYXRoIGVudHJvcHkgbWF5IGNh dXNlIGRhdGEgYW5kIEJGRCBwYWNrZXRzIGZvbGxvd2luZyBkaWZmZXJlbnQgdW5kZXJsYXkgcm91 dGVzLiBCdXQsIG9uIHRoZSBvdGhlciBoYW5kLCB0aGF0IGlzIHRoZSBjYXNlIGZvciBPQU0gYW5k IGZhdWx0IGRldGVjdGlvbiBpbiBhbGwgb3ZlcmxheSBuZXR3b3JrcyBpbiBnZW5lcmFsLg0KDQpN aW5vciBpc3N1ZXMNCg0KU2VjdGlvbiAxDQoNCllvdSB3cml0ZSAiVGhlIGFzeW5jaHJvbm91cyBt b2RlIG9mIEJGRCwgYXMgZGVmaW5lZCBpbiBbUkZDNTg4MF0sDQogY2FuIGJlIHVzZWQgdG8gbW9u aXRvciBhIHAycCBWWExBTiB0dW5uZWwuIg0KDQpXaHkgZG8geW91IHVzZSB0aGUgd29yZCBjYW4g PyBJdCBpcyBhIHBvc3NpYmlsaXR5IG9yIGEgcmVxdWlyZW1lbnQgPw0KR0lNPj4gSW4gcHJpbmNp cGxlLCBCRkQgRGVtYW5kIG1vZGUgbWF5IGJlIHVzZWQgdG8gbW9uaXRvciBwMnAgcGF0aHMgYXMg d2VsbCwgSSBhZ3JlZSwgd2lsbCByZS13b3JkIHRvIG1vcmUgYXNzZXJ0aXZlOg0KIFRoZSBhc3lu Y2hyb25vdXMgbW9kZSBvZiBCRkQsIGFzIGRlZmluZWQgaW4gW1JGQzU4ODBdLA0KIGlzIHVzZWQg dG8gbW9uaXRvciBhIHAycCBWWExBTiB0dW5uZWwuDQoNCk5WRSBoYXMgbm90IGJlZW4gZGVmaW5l ZCBiZWZvcmUgYW5kIGlzIG5vdCBpbiB0aGUgdGVybWlub2xvZ3kuDQpHSU0+PiBXaWxsIGFkZCB0 byB0aGUgVGVybWlub2xvZ3kgYW5kIGV4cGFuZCBhczoNCk5WRSAgICAgICAgTmV0d29yayBWaXJ0 dWFsaXphdGlvbiBFbmRwb2ludA0KDQpUaGlzIGVudGlyZSBzZWN0aW9uIGlzIG5vdCBlYXN5IHRv IHJlYWQgZm9yIGFuIG91dHNpZGVyLg0KDQpTZWN0aW9uIDMNCg0KVk5JIGhhcyBub3QgYmVlbiBk ZWZpbmVkDQpHSU0+PiBXaWxsIGFkZCB0byB0aGUgVGVybWlub2xvZ3kgc2VjdGlvbjoNClZOSSAg ICBWWExBTiBOZXR3b3JrIElkZW50aWZpZXIgKG9yIFZYTEFOIFNlZ21lbnQgSUQpDQoNCkZpZ3Vy ZSAxIGNvdWxkIHRha2UgbGVzcyBzcGFjZQ0KR0lNPj4gWWVzLCBjYW4gbWFrZSBpdCBiaXQgZGVu c2VyLiBXb3VsZCB0aGUgZm9sbG93aW5nIGJlIGFuIGltcHJvdmVtZW50Pw0KDQoNCiAgICAgICst LS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLSsNCiAgICAgIHwgICAgICAgIFNlcnZlciAxICAgICAg ICAgIHwNCiAgICAgIHwgKy0tLS0rLS0tLSsgICstLS0tKy0tLS0rIHwNCiAgICAgIHwgfFZNMS0x ICAgIHwgIHxWTTEtMiAgICB8IHwNCiAgICAgIHwgfFZOSSAxMDAgIHwgIHxWTkkgMjAwICB8IHwN CiAgICAgIHwgfCAgICAgICAgIHwgIHwgICAgICAgICB8IHwNCiAgICAgIHwgKy0tLS0tLS0tLSsg ICstLS0tLS0tLS0rIHwNCiAgICAgIHwgSHlwZXJ2aXNvciBWVEVQIChJUDEpICAgIHwNCiAgICAg ICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICstLS0tLS0tLS0tLS0tKw0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICB8ICAgTGF5ZXIgMyAgIHwNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICArLS0tfCAgIE5ldHdvcmsgICB8DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tKw0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0t LS0tKw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0rDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICAgSHlwZXJ2aXNvciBWVEVQIChJUDIpIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfCArLS0tLSstLS0tKyAgKy0tLS0rLS0tLSsgfA0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8IHxWTTItMSAgICB8ICB8Vk0yLTIgICAgfCB8DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgfFZOSSAxMDAgIHwgIHxW TkkgMjAwICB8IHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCB8 ICAgICAgICAgfCAgfCAgICAgICAgIHwgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8ICstLS0tLS0tLS0rICArLS0tLS0tLS0tKyB8DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICBTZXJ2ZXIgMiAgICAgICAgICAgIHwNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tKw0KDQpTZWN0aW9uIDQNCg0KSSBkbyBub3Qgc2VlIHRoZSBiZW5lZml0cyBvZiBo YXZpbmcgb25lIHBhcmFncmFwaCBpbiBTZWN0aW9uIDQgZm9sbG93ZWQgYnkgb25seQ0KU2VjdGlv biA0LjENCkdJTT4+IFdpbGwgbWVyZ2UgU2VjdGlvbiA0LjEgaW50byA0IHdpdGggbWlub3IgcmVx dWlyZWQgcmUtd29yZGluZzoNCjQuICBCRkQgUGFja2V0IFRyYW5zbWlzc2lvbiBvdmVyIFZYTEFO IFR1bm5lbA0KDQogICBCRkQgcGFja2V0IE1VU1QgYmUgZW5jYXBzdWxhdGVkIGFuZCBzZW50IHRv IGEgcmVtb3RlIFZURVAgYXMNCiAgIGV4cGxhaW5lZCBpbiB0aGlzIHNlY3Rpb24uICBJbXBsZW1l bnRhdGlvbnMgU0hPVUxEIGVuc3VyZSB0aGF0IHRoZQ0KICAgQkZEIHBhY2tldHMgZm9sbG93IHRo ZSBzYW1lIGxvb2t1cCBwYXRoIGFzIFZYTEFOIGRhdGEgcGFja2V0cyB3aXRoaW4NCiAgIHRoZSBz ZW5kZXIgc3lzdGVtLg0KDQogICBCRkQgcGFja2V0cyBhcmUgZW5jYXBzdWxhdGVkIGluIFZYTEFO IGFzIGRlc2NyaWJlZCBiZWxvdy4gIFRoZSBWWExBTg0KICAgcGFja2V0IGZvcm1hdCBpcyBkZWZp bmVkIGluIFNlY3Rpb24gNSBvZiBbUkZDNzM0OF0uICBUaGUgT3V0ZXIgSVAvVURQDQogICBhbmQg VlhMQU4gaGVhZGVycyBNVVNUIGJlIGVuY29kZWQgYnkgdGhlIHNlbmRlciBhcyBkZWZpbmVkIGlu DQogICBbUkZDNzM0OF0uDQoNClNlY3Rpb24gNC4xDQoNClRoZSBkb2N1bWVudCBkb2VzIG5vdCBz cGVjaWZ5IHdoZW4gYSBkZWRpY2F0ZWQgTUFDIGFkZHJlc3Mgb3IgdGhlIE1BQyBhZGRyZXNzDQpv ZiB0aGUgZGVzdGluYXRpb24gVlRFUCBtdXN0IGJlIHVzZWQuIFRoaXMgY291bGQgYWZmZWN0IHRo ZSBpbnRlcm9wZXJhYmlsaXR5IG9mDQppbXBsZW1lbnRhdGlvbnMuIFNob3VsZCBhbGwgaW1wbGVt ZW50YXRpb25zIHN1cHBvcnQgYm90aCB0aGUgZGVkaWNhdGVkIE1BQw0KYWRkcmVzcyBhbmQgdGhl IGRlc3RpbmF0aW9uIE1BQyBhZGRyZXNzID8NCkdJTT4+IEFmdGVyIGZ1cnRoZXIgZGlzY3Vzc2lv biwgYXV0aG9ycyBkZWNpZGVkIHRvIHJlbW92ZSB0aGUgcmVxdWVzdCBmb3IgdGhlIGRlZGljYXRl ZCBNQUMgYWRkcmVzcyBhbGxvY2F0aW9uLiBPbmx5IHRoZSBNQUMgYWRkcmVzcyBvZiB0aGUgcmVt b3RlIFZURVAgbXVzdCBiZSB1c2VkIGFzIHRoZSBkZXN0aW5hdGlvbiBNQUMgYWRkcmVzcyBpbiB0 aGUgaW5uZXIgRXRoZXJuZXQgZnJhbWUuIFBsZWFzZSBjaGVjayB0aGUgYXR0YWNoZWQgZGlmZiBi ZXR3ZWVuIHRoZSAtMDcgYW5kIHRoZSB3b3JraW5nIHZlcnNpb25zIG9yIHRoZSB3b3JraW5nIHZl cnNpb24gb2YgdGhlIGRyYWZ0Lg0KDQpJdCBpcyB1bmNsZWFyIGZyb20gdGhpcyBzZWN0aW9uIHdo ZXRoZXIgSVB2NCBpbnNpZGUgSVB2NiBhbmQgdGhlIG9wcG9zaXRlDQpzaG91bGQgYmUgc3VwcG9y dGVkIG9yIG5vdC4NCkdJTT4+IEFueSBjb21iaW5hdGlvbiBvZiBvdXRlciBJUHZYIGFuZCBpbm5l ciBJUHZYIGlzIHBvc3NpYmxlLg0KDQpTZWN0aW9uIDUuDQoNCklmIHRoZSByZWNlaXZlZCBwYWNr ZXQgZG9lcyBub3QgbWF0Y2ggdGhlIGRlZGljYXRlZCBNQUMgYWRkcmVzcyBub3IgdGhlIE1BQw0K YWRkcmVzcyBvZiB0aGUgVlRFUCwgc2hvdWxkIHRoZSBwYWNrZXQgYmUgc2lsZW50bHkgZGlzY2Fy ZGVkIG9yIHRyZWF0ZWQNCmRpZmZlcmVudGx5ID8NCkdJTT4+IEFzIEkndmUgbWVudGlvbmVkIGVh cmxpZXIsIGF1dGhvcnMgaGF2ZSBkZWNpZGVkIHRvIHJlbW92ZSB0aGUgdXNlIG9mIHRoZSBkZWRp Y2F0ZWQgTUFDIGFkZHJlc3MgZm9yIEJGRCBvdmVyIFZYTEFOLg0KDQpTZWN0aW9uIDUuMQ0KDQpJ cyB0aGlzIGEgbW9kaWZpY2F0aW9uIHRvIHNlY3Rpb24gNi4zIG9mIFJGQzU4ODAgPyBUaGlzIGlz IG5vdCBjbGVhcg0KR0lNPj4gSSB0aGluayB0aGF0IHRoaXMgc2VjdGlvbiBpcyBub3QgbW9kaWZp Y2F0aW9uIGJ1dCB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgYXBwbGljYXRpb24tc3BlY2lmaWMgcHJv Y2VkdXJlIHRoYXQgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgUkZDIDU4ODA6DQogICBUaGUgbWV0 aG9kIG9mIGRlbXVsdGlwbGV4aW5nIHRoZSBpbml0aWFsIHBhY2tldHMgKGluIHdoaWNoIFlvdXIN CiAgIERpc2NyaW1pbmF0b3IgaXMgemVybykgaXMgYXBwbGljYXRpb24gZGVwZW5kZW50LCBhbmQg aXMgdGh1cyBvdXRzaWRlDQogICB0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLg0KDQpT ZWN0aW9uIDkNCg0KVGhlIHNlbnRlbmNlICIgVGhyb3R0bGluZyBNQVkgYmUgcmVsYXhlZCBmb3Ig QkZEIHBhY2tldHMNCiAgIGJhc2VkIG9uIHBvcnQgbnVtYmVyLiIgaXMgdW5jbGVhci4NCkdJTT4+ IFllcywgdGhhbmsgeW91IGZvciBwb2ludGluZyB0byB0aGlzLiBUaGUgdXBkYXRlZCB0ZXh0LCBp biB0aGUgd2hvbGUgcGFyYWdyYXBoLCBpcyBhcyBmb2xsb3dzOg0KTkVXIFRFWFQ6DQogICBUaGUg ZG9jdW1lbnQgcmVxdWlyZXMgc2V0dGluZyB0aGUgaW5uZXIgSVAgVFRMIHRvIDEsIHdoaWNoIGNv dWxkIGJlDQogICB1c2VkIGFzIGEgRERvUyBhdHRhY2sgdmVjdG9yLiAgVGh1cyB0aGUgaW1wbGVt ZW50YXRpb24gTVVTVCBoYXZlDQogICB0aHJvdHRsaW5nIGluIHBsYWNlIHRvIGNvbnRyb2wgdGhl IHJhdGUgb2YgQkZEIGNvbnRyb2wgcGFja2V0cyBzZW50DQogICB0byB0aGUgY29udHJvbCBwbGFu ZS4gIE9uIHRoZSBvdGhlciBoYW5kLCBvdmVyIGFnZ3Jlc3NpdmUgdGhyb3R0bGluZw0KICAgb2Yg QkZEIGNvbnRyb2wgcGFja2V0cyBtYXkgYmVjb21lIHRoZSBjYXVzZSBvZiB0aGUgaW5hYmlsaXR5 IHRvIGZvcm0NCiAgIGFuZCBtYWludGFpbiBCRkQgc2Vzc2lvbiBhdCBzY2FsZS4gIEhlbmNlLCB0 aHJvdHRsaW5nIG9mIEJGRCBjb250cm9sDQogICBwYWNrZXRzIFNIT1VMRCBiZSBhZGp1c3RlZCB0 byBwZXJtaXQgQkZEIHRvIHdvcmsgYWNjb3JkaW5nIHRvIGl0cw0KICAgcHJvY2VkdXJlcy4NCjxk cmFmdC1pZXRmLWJmZC12eGxhbi0wOC50eHQ+PERpZmZfIGRyYWZ0LWlldGYtYmZkLXZ4bGFuLTA3 LnR4dCAtIGRyYWZ0LWlldGYtYmZkLXZ4bGFuLTA4LnR4dC5odG1sPg0KDQo= --_000_14822B96D3C6495E8661198068F72ABAciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <32E1E719179AF845948D3799EBB2534F@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpLA0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SSBoYXZlIG5vdCByZXZpZXdlZCB0aGlzIGRyYWZ0 IGJlZm9yZSwgYnV0IHRyaWdnZXJlZCBieSB0aGlzIGVtYWlsLCBhbmQgYnJpZWZseSBzY2Fubmlu ZyB0aHJvdWdoIGEgY291cGxlIG9mIHNlY3Rpb25zLCBpdCBpcyB1bmNsZWFyIHRvIG1lIGhvdyBz b21lIG9mIHRoZSBtZWNoYW5pY3Mgd29yay48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoZXJlIGFyZSBzb21lIG1ham9yIGlzc3VlcyB3 aXRoIHRoZSBNYWMgdXNhZ2UgYW5kIGFzc29jaWF0aW9uLCBhcyBKb2VsIEhhbHBlcm4gbWVudGlv bmVkIGluIGhpcyBSdGcgRGlyIHJldmlldy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkFuZCwgYWRkaXRpb25hbGx5LCBwbGVhc2UgY29u c2lkZXIgdGhlIGZvbGxvd2luZyBjb21tZW50cyBhbmQgcXVlc3Rpb25zOjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjEuIFVuZGVyc3BlY2lmaWNhdGlvbiBmb3IgaW5pdGlh bGl6YXRpb24gYW5kIGluaXRpYWwgZGVtdWx0aXBsZXhpbmcuPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGlzIGRvY3VtZW50IGFsbG93 cyBtdWx0aXBsZSBCRkQgc2Vzc2lvbnMgYmV0d2VlbiBhIHNpbmdsZSBwYWlyIG9mIFZURVBzOjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtBbjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJz cDsgJm5ic3A7aW1wbGVtZW50YXRpb24gdGhhdCBzdXBwb3J0cyB0aGlzIHNwZWNpZmljYXRpb24g TVVTVCBiZSBhYmxlIHRvPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtjb250cm9s IHRoZSBudW1iZXIgb2YgQkZEIHNlc3Npb25zIHRoYXQgY2FuIGJlIGNyZWF0ZWQgYmV0d2VlbiB0 aGU8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO3NhbWUgcGFpciBvZiBWVEVQcy48 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+VGhlIGltcGxpY2F0aW9uIG9mIHRoaXMgaXMgdGhhdCBCRkQgc2luZ2xlLWhvcCBp bml0aWFsaXphdGlvbiBwcm9jZWR1cmVzIHdpbGwgbm90IHdvcmsuIEluc3RlYWQsIHRoZXJlIGlz IGEgbmVlZCB0byBtYXAgdGhlIGluaXRpYWwgZGVtdWx0aXBsZXhpbmcuPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGlzIGlzc3VlIGlz IGV4cGxhaW5lZCBpbiBSRkNzIDU4ODIgYW5kIDU4ODM6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzU4ODMjc2VjdGlvbi00IiBjbGFzcz0iIj5odHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNTg4MyNzZWN0aW9uLTQ8L2E+Jm5ic3A7YW5kJm5ic3A7PGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU4ODIjc2VjdGlvbi02IiBjbGFz cz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTg4MiNzZWN0aW9uLTY8L2E+PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5T ZWN0aW9uIDUuMSBzYXlzOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtGb3Igc3VjaCBw YWNrZXRzLCB0aGUgQkZEIHNlc3Npb24gTVVTVCBiZSBpZGVudGlmaWVkPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPiZuYnNwOyAmbmJzcDt1c2luZyB0aGUgaW5uZXIgaGVhZGVycywgaS5lLiwgdGhlIHNv dXJjZSBJUCwgdGhlIGRlc3RpbmF0aW9uIElQLCBhbmQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5i c3A7ICZuYnNwO3RoZSBzb3VyY2UgVURQIHBvcnQgbnVtYmVyIHByZXNlbnQgaW4gdGhlIElQIGhl YWRlciBjYXJyaWVkIGJ5IHRoZTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7cGF5 bG9hZCBvZiB0aGUgVlhMQU4gZW5jYXBzdWxhdGVkIHBhY2tldC4gJm5ic3A7VGhlIFZOSSBvZiB0 aGUgcGFja2V0PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtTSE9VTEQgYmUgdXNl ZCB0byBkZXJpdmUgaW50ZXJmYWNlLXJlbGF0ZWQgaW5mb3JtYXRpb24gZm9yPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtkZW11bHRpcGxleGluZyB0aGUgcGFja2V0LjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5CdXQgdGhpcyBkb2VzIG5vdCByZWFsbHkgZXhwbGFpbiBob3cgdG8gZG8gdGhlIGluaXRpYWwg ZGVtdWx0aXBsZXhpbmcuIERvZXMgZWFjaCBCRkQgc2Vzc2lvbiBuZWVkIHRvIGhhdmUgYSBzZXBh cmF0ZSBpbm5lciBzb3VyY2UgSVAgYWRkcmVzcz8gT3Igc291cmNlIFVEUCBwb3J0PyBBbmQgaG93 IG9mdGVyIGFyZSB0aGV5IHJlY3ljbGVkIG9yIGtlcHQgYXMgc3RhdGU/IEhvdyBhcmUgdGhlc2Ug bWFwcGVkPzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5FcXVhbGx5IGltcG9ydGFudGx5LCB3aGljaCBz aWRlIGlzIEFjdGl2ZT88L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QW5kIHdoYXQgaWYgdGhlcmXigJlz IGEgcmFjZSBjb25kaXRpb24gd2l0aCBib3RoIHNpZGVzIGJlaW5nIEFjdGl2ZSBhbmQgc2V0dGlu ZyB1cCByZWR1bmRhbnQgc2Vzc2lvbnM/PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4xLmIuIEJ5IHRoZSB3YXksIGJhc2VkIG9uIHRoaXMs IHVzaW5nIFMtQkZEIFtSRkMgNzg4MF0gbWlnaHQgYmUgZWFzaWVyIHRvIGRlbXV4LjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjIuIFNlY3VyaXR5PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGlzIGRvY3VtZW50 IHNheXMgdGhhdCB0aGUgVFRMIGluIHRoZSBpbm5lciBwYWNrZXQgY2FycnlpbmcgQkZEIGlzIHNl dCB0byAxLiBIb3dldmVyLCBSRkMgNTg4MCBzYXlzIHRvIHVzZSBHVFNNIFtSRkMgNTA4Ml0sIGku ZS4sIGEgdmFsdWUgb2YgMjU1LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+V2h5IGlzIEdUU00gbm90IHVzZWQgaGVyZT88L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4zLiBFQ01QIGFuZCBmYXRlLXNoYXJpbmcgdW5k ZXItc3BlY2lmaWNhdGlvbjo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPlNlY3Rpb24gNC4xLiBzYXlzOjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPiZu YnNwOyAmbmJzcDtUaGUgT3V0ZXIgSVAvVURQPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAm bmJzcDthbmQgVlhMQU4gaGVhZGVycyBNVVNUIGJlIGVuY29kZWQgYnkgdGhlIHNlbmRlciBhcyBk ZWZpbmVkIGluPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDtbUkZDNzM0OF0uPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCkFuZCBSRkMgNzM0OCBzYXlzOjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi PiZuYnNwOyAmbmJzcDsgJm5ic3A7IC0gJm5ic3A7U291cmNlIFBvcnQ6ICZuYnNwO0l0IGlzIHJl Y29tbWVuZGVkIHRoYXQgdGhlIFVEUCBzb3VyY2UgcG9ydCBudW1iZXI8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2JlIGNhbGN1bGF0ZWQgdXNp bmcgYSBoYXNoIG9mIGZpZWxkcyBmcm9tIHRoZSBpbm5lciBwYWNrZXQgLS08L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO29uZSBleGFtcGxlIGJl aW5nIGEgaGFzaCBvZiB0aGUgaW5uZXIgRXRoZXJuZXQgZnJhbWUncyBoZWFkZXJzLjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7VGhpcyBpcyB0 byBlbmFibGUgYSBsZXZlbCBvZiBlbnRyb3B5IGZvciB0aGUgRUNNUC9sb2FkLTwvZGl2Pg0KPGRp diBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YmFsYW5jaW5nIG9m IHRoZSBWTS10by1WTSB0cmFmZmljIGFjcm9zcyB0aGUgVlhMQU4gb3ZlcmxheS48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1doZW4gY2FsY3Vs YXRpbmcgdGhlIFVEUCBzb3VyY2UgcG9ydCBudW1iZXIgaW4gdGhpcyBtYW5uZXIsIGl0PC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtpcyBSRUNP TU1FTkRFRCB0aGF0IHRoZSB2YWx1ZSBiZSBpbiB0aGUgZHluYW1pYy9wcml2YXRlIHBvcnQ8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Jhbmdl IDQ5MTUyLTY1NTM1IFtSRkM2MzM1XS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KQmFzZWQg b24gdGhpcywgZGVwZW5kaW5nIG9uIHRoZSBoYXNoaW5nIGNhbGN1bGF0aW9uLCB0aGUgb3V0ZXIg c291cmNlIFVEUCBwb3J0IGNhbiBiZSBkaWZmZXJlbnQgbGVhZGluZyB0byBkaWZmZXJlbnQgRUNN UCB0cmVhdG1lbnQuIERvZXMgc29tZXRoaW5nIGVsc2UgbmVlZCB0byBiZSBzcGVjaWZpZWQgaGVy ZSBpbiByZWdhcmRzIHRvIHRoZSBvdXRlciBVRFAgc291cmNlIHBvcnQ/PGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj40LiBTZWN0aW9uIDcgc2F5cyB0aGF0IOKAnCZuYnNwO1N1cHBvcnQg Zm9yIGVjaG8gQkZEIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnTigJ0uJm5i c3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5Bc3N1bWluZyB0aGlzIG1lYW5zIOKAnEJGRCBFY2hvIG1vZGXigJ0sIHdoeSBpcyB0aGlz IG91dCBvZiBzY29wZT8gSWYgdGhpcyBpcyBhIHNpbmdsZSBsb2dpY2FsIGhvcCB1bmRlcm5lYXRo IFZYTEFOLCB3aGF04oCZcyBwcmV2ZW50aW5nIHRoZSB1c2Ugb2YgRWNobz8gRWNob+KAmXMgYmVu ZWZpdHMgYXJlIGh1Z2UuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+NS4g VGVybWlub2xvZ3k8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7SW1wbGVtZW50YXRpb25z IFNIT1VMRCBlbnN1cmUgdGhhdCB0aGUgQkZEPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAm bmJzcDtwYWNrZXRzIGZvbGxvdyB0aGUgc2FtZSBsb29rdXAgcGF0aCBhcyBWWExBTiBkYXRhIHBh Y2tldHMgd2l0aGluIHRoZTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7c2VuZGVy IHN5c3RlbS48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPldoYXQgaXMgYSDigJxsb29rIHVwIHBh dGggd2l0aGluIGEgc2VuZGVyIHN5c3RlbeKAnT88L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjYuIERlcGxveW1lbnQgc2NlbmFyaW9zPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5TMyBzYXlzOjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO0ZpZ3VyZSAxIGls bHVzdHJhdGVzIHRoZSBzY2VuYXJpbyB3aXRoIHR3byBzZXJ2ZXJzLCBlYWNoIG9mIHRoZW08L2Rp dj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO2hvc3RpbmcgdHdvIFZNcy4gJm5ic3A7VGhl IHNlcnZlcnMgaG9zdCBWVEVQcyB0aGF0IHRlcm1pbmF0ZSB0d28gVlhMQU48L2Rpdj4NClvigKZd PGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO0ZpZ3VyZSAxOiBSZWZlcmVuY2UgVlhMQU4gRG9tYWluPC9kaXY+DQo8 YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGJyIGNsYXNzPSIiPg0KSG93 ZXZlciwgUkZDJm5ic3A7NzM0OCBGaWd1cmUgMyBsaXN0cyB0aGF0IGFzIG9uZSBkZXBsb3ltZW50 IHNjZW5hcmlvLCBub3QgYXMg4oCcdGhlIHNjZW5hcmlv4oCdIGFuZCDigJxUaGUgUmVmZXJlbmNl IFZYTEFOIERvbWFpbuKAnS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPkJlc3QsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5DYXJsb3MuPGJyIGNsYXNzPSIiPg0KPGRpdj48YnIg Y2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+T24gSnVuIDE3LCAyMDE5LCBhdCAxMjo1OCBBTSwgR3JlZyBNaXJza3kgJmx0OzxhIGhyZWY9 Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20iIGNsYXNzPSIiPmdyZWdpbWlyc2t5QGdtYWls LmNvbTwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1u ZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYg ZGlyPSJsdHIiIGNsYXNzPSIiPkhpIE9saXZlciwNCjxkaXYgY2xhc3M9IiI+dGhhbmsgeW91IGZv ciB5b3VyIHRob3JvdWdoIHJldmlldywgY2xlYXIgYW5kIGRldGFpbGVkIHF1ZXN0aW9ucy4gTXkg YXBvbG9naWVzIGZvciB0aGUgZGVsYXkgdG8gcmVzcG9uZC4gUGxlYXNlIGZpbmQgbXkgYW5zd2Vy cyBiZWxvdyBpbi1saW5lIHRhZ2dlZCBHSU0mZ3Q7Jmd0Oy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlJlZ2FyZHMsPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPkdyZWc8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Z21haWxfcXVvdGUiPg0KPGRpdiBjbGFzcz0iZ21haWxfYXR0ciIgZGlyPSJsdHIiPk9uIEZyaSwg TWF5IDMxLCAyMDE5IGF0IDEyOjM4IFBNIE9saXZpZXIgQm9uYXZlbnR1cmUgdmlhIERhdGF0cmFj a2VyICZsdDs8YSB0YXJnZXQ9Il9ibGFuayIgaHJlZj0ibWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmci IGNsYXNzPSIiPm5vcmVwbHlAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVy LWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCIgY2xhc3M9 ImdtYWlsX3F1b3RlIj4NClJldmlld2VyOiBPbGl2aWVyIEJvbmF2ZW50dXJlPGJyIGNsYXNzPSIi Pg0KUmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0aCBJc3N1ZXM8YnIgY2xhc3M9IiI+DQo8YnIgY2xh c3M9IiI+DQpUaGlzIGRvY3VtZW50IGhhcyBiZWVuIHJldmlld2VkIGFzIHBhcnQgb2YgdGhlIHRy YW5zcG9ydCBhcmVhIHJldmlldyB0ZWFtJ3M8YnIgY2xhc3M9IiI+DQpvbmdvaW5nIGVmZm9ydCB0 byByZXZpZXcga2V5IElFVEYgZG9jdW1lbnRzLiBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW48 YnIgY2xhc3M9IiI+DQpwcmltYXJpbHkgZm9yIHRoZSB0cmFuc3BvcnQgYXJlYSBkaXJlY3RvcnMs IGJ1dCBhcmUgY29waWVkIHRvIHRoZSBkb2N1bWVudCdzPGJyIGNsYXNzPSIiPg0KYXV0aG9ycyBh bmQgV0cgdG8gYWxsb3cgdGhlbSB0byBhZGRyZXNzIGFueSBpc3N1ZXMgcmFpc2VkIGFuZCBhbHNv IHRvIHRoZSBJRVRGPGJyIGNsYXNzPSIiPg0KZGlzY3Vzc2lvbiBsaXN0IGZvciBpbmZvcm1hdGlv bi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpXaGVuIGRvbmUgYXQgdGhlIHRpbWUgb2Yg SUVURiBMYXN0IENhbGwsIHRoZSBhdXRob3JzIHNob3VsZCBjb25zaWRlciB0aGlzPGJyIGNsYXNz PSIiPg0KcmV2aWV3IGFzIHBhcnQgb2YgdGhlIGxhc3QtY2FsbCBjb21tZW50cyB0aGV5IHJlY2Vp dmUuIFBsZWFzZSBhbHdheXMgQ0M8YnIgY2xhc3M9IiI+DQo8YSB0YXJnZXQ9Il9ibGFuayIgaHJl Zj0ibWFpbHRvOnRzdi1hcnRAaWV0Zi5vcmciIGNsYXNzPSIiPnRzdi1hcnRAaWV0Zi5vcmc8L2E+ IGlmIHlvdSByZXBseSB0byBvciBmb3J3YXJkIHRoaXMgcmV2aWV3LjxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCkkgaGF2ZSBvbmx5IGxpbWl0ZWQga25vd2xlZGdlIG9mIFZYTEFOIGFuZCBk byBub3Qga25vdyBhbGwgc3VidGxldGllcyBvZiBCRkQuPGJyIGNsYXNzPSIiPg0KVGhpcyByZXZp ZXcgaXMgdGh1cyBtb3JlIGZyb20gYSBnZW5lcmFsaXN0IHRoYW4gYSBzcGVjaWFsaXN0IGluIHRo aXMgdG9waWMuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTWFqb3IgaXNzdWVzPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU2VjdGlvbiA0IHJlcXVpcmVzIHRoYXQgJnF1b3Q7IElt cGxlbWVudGF0aW9ucyBTSE9VTEQgZW5zdXJlIHRoYXQgdGhlIEJGRDxiciBjbGFzcz0iIj4NCiZu YnNwOyAmbmJzcDtwYWNrZXRzIGZvbGxvdyB0aGUgc2FtZSBsb29rdXAgcGF0aCBhcyBWWExBTiBk YXRhIHBhY2tldHMgd2l0aGluIHRoZTxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtzZW5kZXIg c3lzdGVtLiZxdW90OzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCldoeSBpcyB0aGlzIHJl cXVpcmVtZW50IG9ubHkgcmVsZXZhbnQgZm9yIHRoZSBsb29rdXAgcGF0aCBvbiB0aGUgc2VuZGVy IHN5c3RlbTxiciBjbGFzcz0iIj4NCj8gV2hhdCBkb2VzIHRoaXMgc2VudGVuY2UgcmVhbGx5IGlt cGxpZXMgPzxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+R0lNJmd0 OyZndDsgUkZDIDU4ODAgc2V0IHRoZSBzY29wZSBvZiB0aGUgZmF1bHQgZGV0ZWN0aW9uIG9mIEJG RCBwcm90b2NvbCBhcyZuYnNwOzwvZGl2Pg0KJm5ic3A7ICZuYnNwOy4uLiB0aGUgYmlkaXJlY3Rp b25hbCBwYXRoIGJldHdlZW4gdHdvIGZvcndhcmRpbmcgZW5naW5lcywgaW5jbHVkaW5nPGJyIGNs YXNzPSIiPg0KJm5ic3A7ICZuYnNwO2ludGVyZmFjZXMsIGRhdGEgbGluayhzKSwgYW5kIHRvIHRo ZSBleHRlbnQgcG9zc2libGUgdGhlIGZvcndhcmRpbmc8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPiZuYnNwOyAmbmJzcDtlbmdpbmVzIHRoZW1zZWx2ZXMgLi4uPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPlRoZSByZXF1aXJlbWVudCBhaW1lZCB0byB0aGUgZm9yd2FyZGluZyBlbmdpbmUgb2YgYSBC RkQgc3lzdGVtIHRoYXQgdHJhbnNtaXRzIEJGRCBjb250cm9sIHBhY2tldHMgb3ZlciBWWExBTiB0 dW5uZWwuPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4 O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgi IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8YnIgY2xhc3M9IiI+DQpJcyBpdCBhIHJlcXVpcmVtZW50 IHRoYXQgdGhlIEJGRCBwYWNrZXRzIGZvbGxvdyB0aGUgc2FtZSBwYXRoIGFzIHRoZSBkYXRhPGJy IGNsYXNzPSIiPg0KcGFja2V0IGZvciBhIGdpdmVuIFZYTEFOID8gSSBndWVzcyBzby4gSW4gdGhp cyBjYXNlLCB0aGUgZG9jdW1lbnQgc2hvdWxkPGJyIGNsYXNzPSIiPg0KZGlzY3VzcyBob3cgRXF1 YWwgQ29zdCBNdWx0aXBhdGggY291bGQgYWZmZWN0IHRoaXMuPGJyIGNsYXNzPSIiPg0KPC9ibG9j a3F1b3RlPg0KPGRpdiBjbGFzcz0iIj5HSU0mZ3Q7Jmd0OyBJIHRoaW5rIHRoYXQgRUNNUCBlbnZp cm9ubWVudCBpcyBtb3JlIGxpa2VseSB0byBiZSBleHBlcmllbmNlZCBieSBhIHRyYW5zaXQgbm9k ZSBpbiB0aGUgdW5kZXJsYXkuIElmIHRoZSBCRkQgc2Vzc2lvbiBpcyB1c2VkIHRvIG1vbml0b3Ig dGhlIHNwZWNpZmljIHVuZGVybGF5IHBhdGgsIHRoZW4sIEkgYWdyZWUsIHdlIHNob3VsZCBleHBs YWluIHRoYXQgdXNpbmcgdGhlIFZYTEFOIHBheWxvYWQgaW5mb3JtYXRpb24NCiB0byBkcmF3IHBh dGggZW50cm9weSBtYXkgY2F1c2UgZGF0YSBhbmQgQkZEIHBhY2tldHMgZm9sbG93aW5nIGRpZmZl cmVudCB1bmRlcmxheSByb3V0ZXMuIEJ1dCwgb24gdGhlIG90aGVyIGhhbmQsIHRoYXQgaXMgdGhl IGNhc2UgZm9yIE9BTSBhbmQgZmF1bHQgZGV0ZWN0aW9uIGluIGFsbCBvdmVybGF5IG5ldHdvcmtz IGluIGdlbmVyYWwuDQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MHB4IDBweCAw cHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1s ZWZ0OjFleCIgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxiciBjbGFzcz0iIj4NCk1pbm9yIGlzc3Vl czxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClNlY3Rpb24gMTxiciBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCllvdSB3cml0ZSAmcXVvdDtUaGUgYXN5bmNocm9ub3VzIG1vZGUgb2YgQkZE LCBhcyBkZWZpbmVkIGluIFtSRkM1ODgwXSw8YnIgY2xhc3M9IiI+DQombmJzcDtjYW4gYmUgdXNl ZCB0byBtb25pdG9yIGEgcDJwIFZYTEFOIHR1bm5lbC4mcXVvdDs8YnIgY2xhc3M9IiI+DQo8YnIg Y2xhc3M9IiI+DQpXaHkgZG8geW91IHVzZSB0aGUgd29yZCBjYW4gPyBJdCBpcyBhIHBvc3NpYmls aXR5IG9yIGEgcmVxdWlyZW1lbnQgPzxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxkaXYg Y2xhc3M9IiI+R0lNJmd0OyZndDsgSW4gcHJpbmNpcGxlLCBCRkQgRGVtYW5kIG1vZGUgbWF5IGJl IHVzZWQgdG8gbW9uaXRvciBwMnAgcGF0aHMgYXMgd2VsbCwgSSBhZ3JlZSwgd2lsbCByZS13b3Jk IHRvIG1vcmUgYXNzZXJ0aXZlOjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDtUaGUgYXN5bmNo cm9ub3VzIG1vZGUgb2YgQkZELCBhcyBkZWZpbmVkIGluIFtSRkM1ODgwXSw8L2Rpdj4NCiZuYnNw O2lzIHVzZWQgdG8gbW9uaXRvciBhIHAycCBWWExBTiB0dW5uZWwuDQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0 LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiIGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8YnIgY2xh c3M9IiI+DQpOVkUgaGFzIG5vdCBiZWVuIGRlZmluZWQgYmVmb3JlIGFuZCBpcyBub3QgaW4gdGhl IHRlcm1pbm9sb2d5LjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+ R0lNJmd0OyZndDsgV2lsbCBhZGQgdG8gdGhlIFRlcm1pbm9sb2d5IGFuZCBleHBhbmQgYXM6PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPk5WRSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtOZXR3b3Jr IFZpcnR1YWxpemF0aW9uIEVuZHBvaW50Jm5ic3A7PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIw NCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiIGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8YnIgY2xhc3M9 IiI+DQpUaGlzIGVudGlyZSBzZWN0aW9uIGlzIG5vdCBlYXN5IHRvIHJlYWQgZm9yIGFuIG91dHNp ZGVyLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClNlY3Rpb24gMzxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NClZOSSBoYXMgbm90IGJlZW4gZGVmaW5lZDxiciBjbGFzcz0iIj4NCjwv YmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+R0lNJmd0OyZndDsgV2lsbCBhZGQgdG8gdGhlIFRl cm1pbm9sb2d5IHNlY3Rpb246PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlZOSSZuYnNwOyAmbmJzcDsg VlhMQU4gTmV0d29yayBJZGVudGlmaWVyIChvciBWWExBTiBTZWdtZW50IElEKTwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHgg c29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4IiBjbGFzcz0iZ21haWxfcXVv dGUiPg0KPGJyIGNsYXNzPSIiPg0KRmlndXJlIDEgY291bGQgdGFrZSBsZXNzIHNwYWNlPGJyIGNs YXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj5HSU0mZ3Q7Jmd0OyBZZXMsIGNh biBtYWtlIGl0IGJpdCBkZW5zZXIuIFdvdWxkIHRoZSBmb2xsb3dpbmcgYmUgYW4gaW1wcm92ZW1l bnQ/PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxw cmUgc3R5bGU9IndoaXRlLXNwYWNlOiBwcmUtd3JhcDsiIGNsYXNzPSIiPiAgICAgICYjNDM7LS0t LS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0tJiM0MzsNCiAgICAgIHwgICAgICAgIFNlcnZlciAx ICAgICAgICAgIHwNCiAgICAgIHwgJiM0MzstLS0tJiM0MzstLS0tJiM0MzsgICYjNDM7LS0tLSYj NDM7LS0tLSYjNDM7IHwNCiAgICAgIHwgfFZNMS0xICAgIHwgIHxWTTEtMiAgICB8IHwNCiAgICAg IHwgfFZOSSAxMDAgIHwgIHxWTkkgMjAwICB8IHwNCiAgICAgIHwgfCAgICAgICAgIHwgIHwgICAg ICAgICB8IHwNCiAgICAgIHwgJiM0MzstLS0tLS0tLS0mIzQzOyAgJiM0MzstLS0tLS0tLS0mIzQz OyB8DQogICAgICB8IEh5cGVydmlzb3IgVlRFUCAoSVAxKSAgICB8DQogICAgICAmIzQzOy0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0MzsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICYjNDM7LS0tLS0tLS0tLS0tLSYjNDM7 DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgIHwgICBMYXllciAzICAgfA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICYjNDM7LS0tfCAgIE5ldHdvcmsgICB8DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICYjNDM7LS0tLS0tLS0tLS0tLSYjNDM7DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAmIzQzOy0tLS0tLS0tLS0tJiM0MzsNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgJiM0MzstLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0mIzQzOw0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIEh5cGVydmlzb3IgVlRFUCAo SVAyKSB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgJiM0Mzst LS0tJiM0MzstLS0tJiM0MzsgICYjNDM7LS0tLSYjNDM7LS0tLSYjNDM7IHwNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCB8Vk0yLTEgICAgfCAgfFZNMi0yICAgIHwg fA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHxWTkkgMTAwICB8 ICB8Vk5JIDIwMCAgfCB8DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwgfCAgICAgICAgIHwgIHwgICAgICAgICB8IHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAmIzQzOy0tLS0tLS0tLSYjNDM7ICAmIzQzOy0tLS0tLS0tLSYjNDM7 IHwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgIFNlcnZl ciAyICAgICAgICAgICAgfA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0Mzs8L3ByZT4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHgg c29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4IiBjbGFzcz0iZ21haWxfcXVv dGUiPg0KPGJyIGNsYXNzPSIiPg0KU2VjdGlvbiA0PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KSSBkbyBub3Qgc2VlIHRoZSBiZW5lZml0cyBvZiBoYXZpbmcgb25lIHBhcmFncmFwaCBpbiBT ZWN0aW9uIDQgZm9sbG93ZWQgYnkgb25seTxiciBjbGFzcz0iIj4NClNlY3Rpb24gNC4xPGJyIGNs YXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj5HSU0mZ3Q7Jmd0OyBXaWxsIG1l cmdlIFNlY3Rpb24gNC4xIGludG8gNCB3aXRoIG1pbm9yIHJlcXVpcmVkIHJlLXdvcmRpbmc6PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjQuJm5ic3A7IEJGRCBQYWNrZXQgVHJhbnNtaXNzaW9uIG92ZXIg VlhMQU4gVHVubmVsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO0JG RCBwYWNrZXQgTVVTVCBiZSBlbmNhcHN1bGF0ZWQgYW5kIHNlbnQgdG8gYSByZW1vdGUgVlRFUCBh czxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtleHBsYWluZWQgaW4gdGhpcyBzZWN0aW9uLiZu YnNwOyBJbXBsZW1lbnRhdGlvbnMgU0hPVUxEIGVuc3VyZSB0aGF0IHRoZTxiciBjbGFzcz0iIj4N CiZuYnNwOyAmbmJzcDtCRkQgcGFja2V0cyBmb2xsb3cgdGhlIHNhbWUgbG9va3VwIHBhdGggYXMg VlhMQU4gZGF0YSBwYWNrZXRzIHdpdGhpbjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDt0aGUg c2VuZGVyIHN5c3RlbS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7 QkZEIHBhY2tldHMgYXJlIGVuY2Fwc3VsYXRlZCBpbiBWWExBTiBhcyBkZXNjcmliZWQgYmVsb3cu Jm5ic3A7IFRoZSBWWExBTjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtwYWNrZXQgZm9ybWF0 IGlzIGRlZmluZWQgaW4gU2VjdGlvbiA1IG9mIFtSRkM3MzQ4XS4mbmJzcDsgVGhlIE91dGVyIElQ L1VEUDxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDthbmQgVlhMQU4gaGVhZGVycyBNVVNUIGJl IGVuY29kZWQgYnkgdGhlIHNlbmRlciBhcyBkZWZpbmVkIGluPGJyIGNsYXNzPSIiPg0KJm5ic3A7 ICZuYnNwO1tSRkM3MzQ4XS48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW46MHB4IDBweCAwcHggMC44ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQs MjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFleCIgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxiciBjbGFz cz0iIj4NClNlY3Rpb24gNC4xPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KVGhlIGRvY3Vt ZW50IGRvZXMgbm90IHNwZWNpZnkgd2hlbiBhIGRlZGljYXRlZCBNQUMgYWRkcmVzcyBvciB0aGUg TUFDIGFkZHJlc3M8YnIgY2xhc3M9IiI+DQpvZiB0aGUgZGVzdGluYXRpb24gVlRFUCBtdXN0IGJl IHVzZWQuIFRoaXMgY291bGQgYWZmZWN0IHRoZSBpbnRlcm9wZXJhYmlsaXR5IG9mPGJyIGNsYXNz PSIiPg0KaW1wbGVtZW50YXRpb25zLiBTaG91bGQgYWxsIGltcGxlbWVudGF0aW9ucyBzdXBwb3J0 IGJvdGggdGhlIGRlZGljYXRlZCBNQUM8YnIgY2xhc3M9IiI+DQphZGRyZXNzIGFuZCB0aGUgZGVz dGluYXRpb24gTUFDIGFkZHJlc3MgPzxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxkaXYg Y2xhc3M9IiI+R0lNJmd0OyZndDsgQWZ0ZXIgZnVydGhlciBkaXNjdXNzaW9uLCBhdXRob3JzIGRl Y2lkZWQgdG8gcmVtb3ZlIHRoZSByZXF1ZXN0IGZvciB0aGUgZGVkaWNhdGVkIE1BQyBhZGRyZXNz IGFsbG9jYXRpb24uIE9ubHkgdGhlIE1BQyBhZGRyZXNzIG9mIHRoZSByZW1vdGUgVlRFUCBtdXN0 IGJlIHVzZWQgYXMgdGhlIGRlc3RpbmF0aW9uIE1BQyBhZGRyZXNzIGluIHRoZSBpbm5lciBFdGhl cm5ldCBmcmFtZS4gUGxlYXNlIGNoZWNrIHRoZSBhdHRhY2hlZA0KIGRpZmYgYmV0d2VlbiB0aGUg LTA3IGFuZCB0aGUgd29ya2luZyB2ZXJzaW9ucyBvciB0aGUgd29ya2luZyB2ZXJzaW9uIG9mIHRo ZSBkcmFmdC48L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggMC44 ZXg7Ym9yZGVyLWxlZnQ6MXB4IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZy1sZWZ0OjFl eCIgY2xhc3M9ImdtYWlsX3F1b3RlIj4NCjxiciBjbGFzcz0iIj4NCkl0IGlzIHVuY2xlYXIgZnJv bSB0aGlzIHNlY3Rpb24gd2hldGhlciBJUHY0IGluc2lkZSBJUHY2IGFuZCB0aGUgb3Bwb3NpdGU8 YnIgY2xhc3M9IiI+DQpzaG91bGQgYmUgc3VwcG9ydGVkIG9yIG5vdC48YnIgY2xhc3M9IiI+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPkdJTSZndDsmZ3Q7IEFueSBjb21iaW5hdGlvbiBv ZiBvdXRlciBJUHZYIGFuZCBpbm5lciBJUHZYIGlzIHBvc3NpYmxlLjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQg cmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4IiBjbGFzcz0iZ21haWxfcXVvdGUiPg0K PGJyIGNsYXNzPSIiPg0KU2VjdGlvbiA1LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCklm IHRoZSByZWNlaXZlZCBwYWNrZXQgZG9lcyBub3QgbWF0Y2ggdGhlIGRlZGljYXRlZCBNQUMgYWRk cmVzcyBub3IgdGhlIE1BQzxiciBjbGFzcz0iIj4NCmFkZHJlc3Mgb2YgdGhlIFZURVAsIHNob3Vs ZCB0aGUgcGFja2V0IGJlIHNpbGVudGx5IGRpc2NhcmRlZCBvciB0cmVhdGVkPGJyIGNsYXNzPSIi Pg0KZGlmZmVyZW50bHkgPzxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9 IiI+R0lNJmd0OyZndDsgQXMgSSd2ZSBtZW50aW9uZWQgZWFybGllciwgYXV0aG9ycyBoYXZlIGRl Y2lkZWQgdG8gcmVtb3ZlIHRoZSB1c2Ugb2YgdGhlIGRlZGljYXRlZCBNQUMgYWRkcmVzcyBmb3Ig QkZEIG92ZXIgVlhMQU4uPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOjBweCAwcHgg MHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmct bGVmdDoxZXgiIGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8YnIgY2xhc3M9IiI+DQpTZWN0aW9uIDUu MTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCklzIHRoaXMgYSBtb2RpZmljYXRpb24gdG8g c2VjdGlvbiA2LjMgb2YgUkZDNTg4MCA/IFRoaXMgaXMgbm90IGNsZWFyPGJyIGNsYXNzPSIiPg0K PC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj5HSU0mZ3Q7Jmd0OyBJIHRoaW5rIHRoYXQgdGhp cyBzZWN0aW9uIGlzIG5vdCBtb2RpZmljYXRpb24gYnV0IHRoZSBkZWZpbml0aW9uIG9mIHRoZSBh cHBsaWNhdGlvbi1zcGVjaWZpYyBwcm9jZWR1cmUgdGhhdCBpcyBvdXRzaWRlIHRoZSBzY29wZSBv ZiBSRkMgNTg4MDo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO1RoZSBtZXRob2Qg b2YgZGVtdWx0aXBsZXhpbmcgdGhlIGluaXRpYWwgcGFja2V0cyAoaW4gd2hpY2ggWW91cjxiciBj bGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtEaXNjcmltaW5hdG9yIGlzIHplcm8pIGlzIGFwcGxpY2F0 aW9uIGRlcGVuZGVudCwgYW5kIGlzIHRodXMgb3V0c2lkZTxiciBjbGFzcz0iIj4NCiZuYnNwOyAm bmJzcDt0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVm dDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4IiBjbGFzcz0iZ21h aWxfcXVvdGUiPg0KPGJyIGNsYXNzPSIiPg0KU2VjdGlvbiA5PGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KVGhlIHNlbnRlbmNlICZxdW90OyBUaHJvdHRsaW5nIE1BWSBiZSByZWxheGVkIGZv ciBCRkQgcGFja2V0czxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtiYXNlZCBvbiBwb3J0IG51 bWJlci4mcXVvdDsgaXMgdW5jbGVhci48YnIgY2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 IGNsYXNzPSIiPkdJTSZndDsmZ3Q7IFllcywgdGhhbmsgeW91IGZvciBwb2ludGluZyB0byB0aGlz LiBUaGUgdXBkYXRlZCB0ZXh0LCBpbiB0aGUgd2hvbGUgcGFyYWdyYXBoLCBpcyBhcyBmb2xsb3dz OjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5ORVcgVEVYVDo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5i c3A7ICZuYnNwO1RoZSBkb2N1bWVudCByZXF1aXJlcyBzZXR0aW5nIHRoZSBpbm5lciBJUCBUVEwg dG8gMSwgd2hpY2ggY291bGQgYmU8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7dXNlZCBhcyBh IEREb1MgYXR0YWNrIHZlY3Rvci4mbmJzcDsgVGh1cyB0aGUgaW1wbGVtZW50YXRpb24gTVVTVCBo YXZlPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO3Rocm90dGxpbmcgaW4gcGxhY2UgdG8gY29u dHJvbCB0aGUgcmF0ZSBvZiBCRkQgY29udHJvbCBwYWNrZXRzIHNlbnQ8YnIgY2xhc3M9IiI+DQom bmJzcDsgJm5ic3A7dG8gdGhlIGNvbnRyb2wgcGxhbmUuJm5ic3A7IE9uIHRoZSBvdGhlciBoYW5k LCBvdmVyIGFnZ3Jlc3NpdmUgdGhyb3R0bGluZzxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtv ZiBCRkQgY29udHJvbCBwYWNrZXRzIG1heSBiZWNvbWUgdGhlIGNhdXNlIG9mIHRoZSBpbmFiaWxp dHkgdG8gZm9ybTxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDthbmQgbWFpbnRhaW4gQkZEIHNl c3Npb24gYXQgc2NhbGUuJm5ic3A7IEhlbmNlLCB0aHJvdHRsaW5nIG9mIEJGRCBjb250cm9sPGJy IGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO3BhY2tldHMgU0hPVUxEIGJlIGFkanVzdGVkIHRvIHBl cm1pdCBCRkQgdG8gd29yayBhY2NvcmRpbmcgdG8gaXRzPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZu YnNwO3Byb2NlZHVyZXMuPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHNw YW4gaWQ9ImNpZDpmX2p3endyNDFwMSI+Jmx0O2RyYWZ0LWlldGYtYmZkLXZ4bGFuLTA4LnR4dCZn dDs8L3NwYW4+PHNwYW4gaWQ9ImNpZDpmX2p3endxeHBqMCI+Jmx0O0RpZmZfIGRyYWZ0LWlldGYt YmZkLXZ4bGFuLTA3LnR4dCAtIGRyYWZ0LWlldGYtYmZkLXZ4bGFuLTA4LnR4dC5odG1sJmd0Ozwv c3Bhbj48L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_14822B96D3C6495E8661198068F72ABAciscocom_-- From nobody Wed Jun 19 19:44:08 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43EFF1202E7; Wed, 19 Jun 2019 18:58:52 -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_HELO_NONE=0.001, 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 oYmNQ2Sa6jBt; Wed, 19 Jun 2019 18:58:46 -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 49C9D12008F; Wed, 19 Jun 2019 18:58:46 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id a25so1171513lfg.2; Wed, 19 Jun 2019 18:58:46 -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=ThgSABPZ1DsPtOrzuk+MTON1y+tkQptuSDc+ypGbNTA=; b=AoGdYJOKYlTS/w74CiC/j+obKiJxz3FfIHmJ+5zrxYN+q9GdDGug1Sdah/7aN0e8OK U3yNBjG4aaa/LOIGd3Jy7NiWhIkRwD8zZXKrJUkVCkYdFy13ZmfWZTDEUWDfUSV0DwDf 7B/7r3r8JqBI8IbryXoSpqS1YnkTqbukJH8B5zFG0O2LVjGMtI6m8z+5AeAOAqklQEBC bpUdDluA6EYixJVIV6EnCaT+RnE2F1Oj4z2My00ZBXCrYozQuiF0/zHXudG56Hmak8Gt WD2ZWof0Cmfol2Qm3oeXKEv9WGLwFHxv4SkRGIodqiRC/ZfvtKVxFfkMuMOh8GEgBJIk 6G4A== 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=ThgSABPZ1DsPtOrzuk+MTON1y+tkQptuSDc+ypGbNTA=; b=qeMpkNxQxNYaS/TedKfBUNzspaFRcyEtYGPQRaYCXcmclwMLkCgg6mJzIgnEfUGtjy w3Ki71FgSE9kWVG1nR8UOdFOcbHYpxnHSK8eoP09qSZIg6YGeSfd1+O+Ha8MsvdUJhwj R4T2ifW05xQZiI5rmrnqeTtXb401msuVD358vf7HLexSd4hiJ8e88eh3JmRNdYggsk8V BX+UPy7PGSmlxPISFwSKxdZbbp80SPNU7Z3MDAb71HTgG/sSptOMYCN6PsOvL2Y1ahfN 7FanijfG/MtFQQGtLGkCV2huMgpWaLtNv4oVIu4LQV+trY1dwAxC3+vQug6gnKYL2vx0 3qGQ== X-Gm-Message-State: APjAAAVCR5+Jk+VRbLZoYIChg0+qaQ55OrWmXKR8KRtWwFKCltgsKpxQ r0QDfZaL0tCjc6xSJ4aHsMEJ9WPn1yllI61wioc= X-Google-Smtp-Source: APXvYqxbX+ayXNkdP6k44md/pT8nrhFtHBSaEzkkCPH81mlmzZTRx6p6ahT0UpkDkaHlJ0dscus59yKSsnj6Jdbdq3k= X-Received: by 2002:ac2:4243:: with SMTP id m3mr10117473lfl.9.1560995924156; Wed, 19 Jun 2019 18:58:44 -0700 (PDT) MIME-Version: 1.0 References: <155933149484.6565.7386019489022348116@ietfa.amsl.com> <14822B96-D3C6-495E-8661-198068F72ABA@cisco.com> <8237FE8D-937E-4BCB-B1A3-89C2B3CDC51C@cisco.com> In-Reply-To: <8237FE8D-937E-4BCB-B1A3-89C2B3CDC51C@cisco.com> From: Greg Mirsky Date: Thu, 20 Jun 2019 10:58:32 +0900 Message-ID: Subject: Re: Tsvart last call review of draft-ietf-bfd-vxlan-07 To: "Carlos Pignataro (cpignata)" Cc: "tsv-art@ietf.org" , rtg-bfd WG , "draft-ietf-bfd-vxlan.all@ietf.org" , Olivier Bonaventure , IETF list Content-Type: multipart/alternative; boundary="0000000000008e2644058bb7af93" Archived-At: X-Mailman-Approved-At: Wed, 19 Jun 2019 19:43:59 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 01:58:52 -0000 --0000000000008e2644058bb7af93 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Carlos, thank you for the expedient clarification. To your questions on demultiplexing BFD control packets with the zero value of the Your Discriminator field: - only BFD control packets with the zero value of the Your Discriminator field are demultiplexed using the information of the inner IP header. I believe that the text is clear and requires that all fields of the inner= IP header must be used to demultiplex a received BFD control packet with th= e zero value in the Your Discriminator field. Which of the fields an implementation uses to create multiple BFD sessions between the pair of VTEPs is implementation specific. To your point on the level Echo mode of BFD is specified in RFC 5880 I'll quote the opinion of Jeffrey Haas from the discussion of comments from Shawn Emery on behalf of the SecDir. Shawn had commented: Echo BFD is out of scope for the document, but does not describe the reason for this or why state this at all? I've responded: GIM>> I think that the main reason is that the BFD Echo mode is underspecified. RFC 5880 defined some of the mechanisms related to the Echo mode, but more standardization work may be required. And Jeffrey Haas had added: Speaking as a BFD chair, this is the relevant observation. BFD Echo is underspecified to the point where claiming compliance is difficult at best. In general, it relies on single-hop and the ability to have the remote Echo client loop the packets. This packet loop may not be practical for several encapsulations and thus i= s out of scope for such encapsulations. Whether this is practical for vxlan today, or in the presence of future extensions to vxlan is left out of scop= e for the core proposal. Will respond to other questions in a separate mail. Regards, Greg On Thu, Jun 20, 2019 at 10:31 AM Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Hello, Greg, > > > On Jun 19, 2019, at 9:09 PM, Greg Mirsky wrote: > > > > Hi Carlos, > > thank you for reminding of our continued discussion with Joel. We are > seeking comments from VXLAN experts and much appreciate if you have > insights on VXLAN to share. > > I've got some clarifying questions before I can respond to you. > > Sure. > > > To which stage of the three-way handshake you refer as "initial > demultiplexing"? I couldn't find this term in RFC 5880. > > =E2=80=9CInitial demultiplexing" is a well-known term in BFD, referring t= o the > "demultiplexing of the initial packets", BFD Control packet with YourDisc > being zero. > > In RFC 5880, see Section 6.3. > https://tools.ietf.org/html/rfc5880#section-6.3 > > The method of demultiplexing the initial packets (in which Your > Discriminator is zero) is application dependent, and is thus outside > the scope of this specification. > > Since initial demultiplexing is indeed application specific, different fo= r > one-hop versus multi-hop and dependent upon whether a single or multiple > sessions are allowed between a pair of endpoints, I added below two other > relevant citations, from application specific BFD specs: > 1. https://tools.ietf.org/html/rfc5883#section-4 > 2. https://tools.ietf.org/html/rfc5882#section-6 > > > > Regarding the applicability of the Echo mode, thank you for pointing to > the need for stricter terminology, the Echo mode, as defined in RFC 5880, > is underspecified and it will require additional standardization. > > No. BFD Echo is not underspecified in RFC 5880. > > Please read S5: https://tools.ietf.org/html/rfc5880#section-5 > > BFD Echo packets are sent in an encapsulation appropriate to the > environment. See the appropriate application documents for the > specifics of particular environments. > > > BFD Echo is application dependent. > > Therefore, for example, single-hop BFD in RFC 5881 specifies BFD Echo for > that application. > > Hence, my question stands: why is this draft claiming BFD Echo is out of > scope for this BFD application document? > > > > Future drafts may explore and define how the Echo mode of BFD is used > over VXLAN tunnels. > > > > See above. > > > Will review and respond to the remaining questions soon. > > Thank you. > > The "remaining questions" are still all the questions below :-) > > Best, > > Carlos. > > > > > Regards, > > Greg > > > > > > On Thu, Jun 20, 2019 at 9:14 AM Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > > Hi, > > > > I have not reviewed this draft before, but triggered by this email, and > briefly scanning through a couple of sections, it is unclear to me how so= me > of the mechanics work. > > > > There are some major issues with the Mac usage and association, as Joel > Halpern mentioned in his Rtg Dir review. > > > > And, additionally, please consider the following comments and questions= : > > > > > > 1. Underspecification for initialization and initial demultiplexing. > > > > This document allows multiple BFD sessions between a single pair of > VTEPs: > > > > An > > implementation that supports this specification MUST be able to > > control the number of BFD sessions that can be created between the > > same pair of VTEPs. > > > > The implication of this is that BFD single-hop initialization procedure= s > will not work. Instead, there is a need to map the initial demultiplexing= . > > > > This issue is explained in RFCs 5882 and 5883: > https://tools.ietf.org/html/rfc5883#section-4 and > https://tools.ietf.org/html/rfc5882#section-6 > > > > Section 5.1 says: > > > > For such packets, the BFD session MUST be identified > > using the inner headers, i.e., the source IP, the destination IP, an= d > > the source UDP port number present in the IP header carried by the > > payload of the VXLAN encapsulated packet. The VNI of the packet > > SHOULD be used to derive interface-related information for > > demultiplexing the packet. > > > > But this does not really explain how to do the initial demultiplexing. > Does each BFD session need to have a separate inner source IP address? Or > source UDP port? And how ofter are they recycled or kept as state? How ar= e > these mapped? > > Equally importantly, which side is Active? > > And what if there=E2=80=99s a race condition with both sides being Acti= ve and > setting up redundant sessions? > > > > 1.b. By the way, based on this, using S-BFD [RFC 7880] might be easier > to demux. > > > > > > 2. Security > > > > This document says that the TTL in the inner packet carrying BFD is set > to 1. However, RFC 5880 says to use GTSM [RFC 5082], i.e., a value of 255= .. > > > > Why is GTSM not used here? > > > > > > 3. ECMP and fate-sharing under-specification: > > > > Section 4.1. says: > > > > The Outer IP/UDP > > and VXLAN headers MUST be encoded by the sender as defined in > > [RFC7348]. > > > > > > And RFC 7348 says: > > > > - Source Port: It is recommended that the UDP source port numbe= r > > be calculated using a hash of fields from the inner packet -- > > one example being a hash of the inner Ethernet frame's headers= . > > This is to enable a level of entropy for the ECMP/load- > > balancing of the VM-to-VM traffic across the VXLAN overlay. > > When calculating the UDP source port number in this manner, it > > is RECOMMENDED that the value be in the dynamic/private port > > range 49152-65535 [RFC6335]. > > > > > > Based on this, depending on the hashing calculation, the outer source > UDP port can be different leading to different ECMP treatment. Does > something else need to be specified here in regards to the outer UDP sour= ce > port? > > > > > > 4. Section 7 says that =E2=80=9C Support for echo BFD is outside the sc= ope of > this document=E2=80=9D. > > > > Assuming this means =E2=80=9CBFD Echo mode=E2=80=9D, why is this out of= scope? If this > is a single logical hop underneath VXLAN, what=E2=80=99s preventing the u= se of > Echo? Echo=E2=80=99s benefits are huge. > > > > > > 5. Terminology > > > > Implementations SHOULD ensure that the BFD > > packets follow the same lookup path as VXLAN data packets within the > > sender system. > > > > What is a =E2=80=9Clook up path within a sender system=E2=80=9D? > > > > > > 6. Deployment scenarios > > > > S3 says: > > Figure 1 illustrates the scenario with two servers, each of them > > hosting two VMs. The servers host VTEPs that terminate two VXLAN > > [=E2=80=A6] > > Figure 1: Reference VXLAN Domain > > > > > > However, RFC 7348 Figure 3 lists that as one deployment scenario, not a= s > =E2=80=9Cthe scenario=E2=80=9D and =E2=80=9CThe Reference VXLAN Domain=E2= =80=9D. > > > > Best, > > > > Carlos. > > > >> On Jun 17, 2019, at 12:58 AM, Greg Mirsky > wrote: > >> > >> Hi Oliver, > >> thank you for your thorough review, clear and detailed questions. My > apologies for the delay to respond. Please find my answers below in-line > tagged GIM>>. > >> > >> Regards, > >> Greg > >> > >> On Fri, May 31, 2019 at 12:38 PM Olivier Bonaventure via Datatracker < > noreply@ietf.org> wrote: > >> Reviewer: Olivier Bonaventure > >> Review result: Ready with Issues > >> > >> This document has been reviewed as part of the transport area review > team's > >> ongoing effort to review key IETF documents. These comments were writt= en > >> primarily for the transport area directors, but are copied to the > document's > >> authors and WG to allow them to address any issues raised and also to > the IETF > >> discussion list for information. > >> > >> When done at the time of IETF Last Call, the authors should consider > this > >> review as part of the last-call comments they receive. Please always C= C > >> tsv-art@ietf.org if you reply to or forward this review. > >> > >> I have only limited knowledge of VXLAN and do not know all subtleties > of BFD. > >> This review is thus more from a generalist than a specialist in this > topic. > >> > >> Major issues > >> > >> Section 4 requires that " Implementations SHOULD ensure that the BFD > >> packets follow the same lookup path as VXLAN data packets within th= e > >> sender system." > >> > >> Why is this requirement only relevant for the lookup path on the sende= r > system > >> ? What does this sentence really implies ? > >> GIM>> RFC 5880 set the scope of the fault detection of BFD protocol as > >> ... the bidirectional path between two forwarding engines, includin= g > >> interfaces, data link(s), and to the extent possible the forwarding > >> engines themselves ... > >> The requirement aimed to the forwarding engine of a BFD system that > transmits BFD control packets over VXLAN tunnel. > >> > >> Is it a requirement that the BFD packets follow the same path as the > data > >> packet for a given VXLAN ? I guess so. In this case, the document shou= ld > >> discuss how Equal Cost Multipath could affect this. > >> GIM>> I think that ECMP environment is more likely to be experienced b= y > a transit node in the underlay. If the BFD session is used to monitor the > specific underlay path, then, I agree, we should explain that using the > VXLAN payload information to draw path entropy may cause data and BFD > packets following different underlay routes. But, on the other hand, that > is the case for OAM and fault detection in all overlay networks in genera= l. > >> > >> Minor issues > >> > >> Section 1 > >> > >> You write "The asynchronous mode of BFD, as defined in [RFC5880], > >> can be used to monitor a p2p VXLAN tunnel." > >> > >> Why do you use the word can ? It is a possibility or a requirement ? > >> GIM>> In principle, BFD Demand mode may be used to monitor p2p paths a= s > well, I agree, will re-word to more assertive: > >> The asynchronous mode of BFD, as defined in [RFC5880], > >> is used to monitor a p2p VXLAN tunnel. > >> > >> NVE has not been defined before and is not in the terminology. > >> GIM>> Will add to the Terminology and expand as: > >> NVE Network Virtualization Endpoint > >> > >> This entire section is not easy to read for an outsider. > >> > >> Section 3 > >> > >> VNI has not been defined > >> GIM>> Will add to the Terminology section: > >> VNI VXLAN Network Identifier (or VXLAN Segment ID) > >> > >> Figure 1 could take less space > >> GIM>> Yes, can make it bit denser. Would the following be an > improvement? > >> > >> +------------+-------------+ > >> | Server 1 | > >> | +----+----+ +----+----+ | > >> | |VM1-1 | |VM1-2 | | > >> | |VNI 100 | |VNI 200 | | > >> | | | | | | > >> | +---------+ +---------+ | > >> | Hypervisor VTEP (IP1) | > >> +--------------------------+ > >> | > >> | +-------------+ > >> | | Layer 3 | > >> +---| Network | > >> +-------------+ > >> | > >> +-----------+ > >> | > >> +------------+-------------+ > >> | Hypervisor VTEP (IP2) | > >> | +----+----+ +----+----+ | > >> | |VM2-1 | |VM2-2 | | > >> | |VNI 100 | |VNI 200 | | > >> | | | | | | > >> | +---------+ +---------+ | > >> | Server 2 | > >> +--------------------------+ > >> > >> > >> Section 4 > >> > >> I do not see the benefits of having one paragraph in Section 4 followe= d > by only > >> Section 4.1 > >> GIM>> Will merge Section 4.1 into 4 with minor required re-wording: > >> 4. BFD Packet Transmission over VXLAN Tunnel > >> > >> BFD packet MUST be encapsulated and sent to a remote VTEP as > >> explained in this section. Implementations SHOULD ensure that the > >> BFD packets follow the same lookup path as VXLAN data packets withi= n > >> the sender system. > >> > >> BFD packets are encapsulated in VXLAN as described below. The VXLA= N > >> packet format is defined in Section 5 of [RFC7348]. The Outer IP/U= DP > >> and VXLAN headers MUST be encoded by the sender as defined in > >> [RFC7348]. > >> > >> Section 4.1 > >> > >> The document does not specify when a dedicated MAC address or the MAC > address > >> of the destination VTEP must be used. This could affect the > interoperability of > >> implementations. Should all implementations support both the dedicated > MAC > >> address and the destination MAC address ? > >> GIM>> After further discussion, authors decided to remove the request > for the dedicated MAC address allocation. Only the MAC address of the > remote VTEP must be used as the destination MAC address in the inner > Ethernet frame. Please check the attached diff between the -07 and the > working versions or the working version of the draft. > >> > >> It is unclear from this section whether IPv4 inside IPv6 and the > opposite > >> should be supported or not. > >> GIM>> Any combination of outer IPvX and inner IPvX is possible. > >> > >> Section 5. > >> > >> If the received packet does not match the dedicated MAC address nor th= e > MAC > >> address of the VTEP, should the packet be silently discarded or treate= d > >> differently ? > >> GIM>> As I've mentioned earlier, authors have decided to remove the us= e > of the dedicated MAC address for BFD over VXLAN. > >> > >> Section 5.1 > >> > >> Is this a modification to section 6.3 of RFC5880 ? This is not clear > >> GIM>> I think that this section is not modification but the definition > of the application-specific procedure that is outside the scope of RFC 58= 80: > >> The method of demultiplexing the initial packets (in which Your > >> Discriminator is zero) is application dependent, and is thus outsid= e > >> the scope of this specification. > >> > >> Section 9 > >> > >> The sentence " Throttling MAY be relaxed for BFD packets > >> based on port number." is unclear. > >> GIM>> Yes, thank you for pointing to this. The updated text, in the > whole paragraph, is as follows: > >> NEW TEXT: > >> The document requires setting the inner IP TTL to 1, which could be > >> used as a DDoS attack vector. Thus the implementation MUST have > >> throttling in place to control the rate of BFD control packets sent > >> to the control plane. On the other hand, over aggressive throttlin= g > >> of BFD control packets may become the cause of the inability to for= m > >> and maintain BFD session at scale. Hence, throttling of BFD contro= l > >> packets SHOULD be adjusted to permit BFD to work according to its > >> procedures. > >> draft-ietf-bfd-vxlan-08.txt.html> > > > > --0000000000008e2644058bb7af93 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Carlos,
thank you for the exped= ient clarification.
To your=C2=A0questions on demultiplexing BFD = control packets with the zero value of the Your Discriminator field:
<= div>
  • only BFD control packets with the zero value of the Your Discri= minator field are demultiplexed using the information of the inner IP heade= r. I believe that the text is clear and requires that all fields of the inn= er IP header must be used to demultiplex a received BFD control packet with= the zero value in the Your Discriminator field. Which of the fields an imp= lementation uses to create multiple BFD sessions between the pair of VTEPs = is implementation specific.
To your point on the level Echo mode o= f BFD is specified in RFC 5880 I'll quote the opinion of Jeffrey Haas f= rom the discussion of comments from Shawn Emery on behalf of the SecDir. Sh= awn had commented:
Echo BFD is out of scope for the document, bu= t does not describe the reason for this or why state
this at all?
I've r= esponded:
GIM>> I think that the main reason is that the BFD Echo mode is un= derspecified. RFC 5880 defined some of the mechanisms related to the Echo m= ode, but more standardization work may be required.=C2=A0=C2=A0
And Jeffrey Haas had added:
Speaking as a BFD chair, this is the relevant o= bservation.=C2=A0 BFD Echo is
underspecified to the point where c= laiming compliance is difficult at best.
In general, it relies on= single-hop and the ability to have the remote Echo
client loop t= he packets.=C2=A0

This packet loop may not be prac= tical for several encapsulations and thus is
out of scope for suc= h encapsulations.=C2=A0 Whether this is practical for vxlan
today= , or in the presence of future extensions to vxlan is left out of scope
for the core proposal.=C2=A0=C2=A0

= Will respond to other questions in a separate mail.

Rega= rds,
Greg


=
On Thu, Ju= n 20, 2019 at 10:31 AM Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
Hello, Greg,

> On Jun 19, 2019, at 9:09 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
>
> Hi Carlos,
> thank you for reminding of our continued discussion with Joel. We are = seeking comments from VXLAN experts and much appreciate if you have insight= s on VXLAN to share.
> I've got some clarifying questions before I can respond to you.
Sure.

> To which stage of the three-way handshake you refer as "initial d= emultiplexing"? I couldn't find this term in RFC 5880.

=E2=80=9CInitial demultiplexing" is a well-known term in BFD, referrin= g to the "demultiplexing of the initial packets", BFD Control pac= ket with YourDisc being zero.

In RFC 5880, see Section 6.3.
https://tools.ietf.org/html/rfc5880#section-6.3
=C2=A0 =C2=A0The method of demultiplexing the initial packets (in which You= r
=C2=A0 =C2=A0Discriminator is zero) is application dependent, and is thus o= utside
=C2=A0 =C2=A0the scope of this specification.

Since initial demultiplexing is indeed application specific, different for = one-hop versus multi-hop and dependent upon whether a single or multiple se= ssions are allowed between a pair of endpoints, I added below two other rel= evant citations, from application specific BFD specs:
1. https://tools.ietf.org/html/rfc5883#section-4 2. https://tools.ietf.org/html/rfc5882#section-6

> Regarding the applicability of the Echo mode, thank you for pointing t= o the need for stricter terminology, the Echo mode, as defined in RFC 5880,= is underspecified and it will require additional standardization.

No. BFD Echo is not underspecified in RFC 5880.

Please read S5: https://tools.ietf.org/html/rfc5880#sec= tion-5

=C2=A0 =C2=A0BFD Echo packets are sent in an encapsulation appropriate to t= he
=C2=A0 =C2=A0environment.=C2=A0 See the appropriate application documents f= or the
=C2=A0 =C2=A0specifics of particular environments.


BFD Echo is application dependent.

Therefore, for example, single-hop BFD in RFC 5881 specifies BFD Echo for t= hat application.

Hence, my question stands: why is this draft claiming BFD Echo is out of sc= ope for this BFD application document?


> Future drafts may explore and define how the Echo mode of BFD is used = over VXLAN tunnels.
>

See above.

> Will review and respond to the remaining questions soon.

Thank you.

The "remaining questions" are still all the questions below :-)
Best,

Carlos.

>
> Regards,
> Greg
>
>
> On Thu, Jun 20, 2019 at 9:14 AM Carlos Pignataro (cpignata) <cpignata@cisco.com>= ; wrote:
> Hi,
>
> I have not reviewed this draft before, but triggered by this email, an= d briefly scanning through a couple of sections, it is unclear to me how so= me of the mechanics work.
>
> There are some major issues with the Mac usage and association, as Joe= l Halpern mentioned in his Rtg Dir review.
>
> And, additionally, please consider the following comments and question= s:
>
>
> 1. Underspecification for initialization and initial demultiplexing. >
> This document allows multiple BFD sessions between a single pair of VT= EPs:
>
>=C2=A0 =C2=A0 An
>=C2=A0 =C2=A0 implementation that supports this specification MUST be a= ble to
>=C2=A0 =C2=A0 control the number of BFD sessions that can be created be= tween the
>=C2=A0 =C2=A0 same pair of VTEPs.
>
> The implication of this is that BFD single-hop initialization procedur= es will not work. Instead, there is a need to map the initial demultiplexin= g.
>
> This issue is explained in RFCs 5882 and 5883: htt= ps://tools.ietf.org/html/rfc5883#section-4 and http= s://tools.ietf.org/html/rfc5882#section-6
>
> Section 5.1 says:
>
>=C2=A0 =C2=A0 For such packets, the BFD session MUST be identified
>=C2=A0 =C2=A0 using the inner headers, i.e., the source IP, the destina= tion IP, and
>=C2=A0 =C2=A0 the source UDP port number present in the IP header carri= ed by the
>=C2=A0 =C2=A0 payload of the VXLAN encapsulated packet.=C2=A0 The VNI o= f the packet
>=C2=A0 =C2=A0 SHOULD be used to derive interface-related information fo= r
>=C2=A0 =C2=A0 demultiplexing the packet.
>
> But this does not really explain how to do the initial demultiplexing.= Does each BFD session need to have a separate inner source IP address? Or = source UDP port? And how ofter are they recycled or kept as state? How are = these mapped?
> Equally importantly, which side is Active?
> And what if there=E2=80=99s a race condition with both sides being Act= ive and setting up redundant sessions?
>
> 1.b. By the way, based on this, using S-BFD [RFC 7880] might be easier= to demux.
>
>
> 2. Security
>
> This document says that the TTL in the inner packet carrying BFD is se= t to 1. However, RFC 5880 says to use GTSM [RFC 5082], i.e., a value of 255= ..
>
> Why is GTSM not used here?
>
>
> 3. ECMP and fate-sharing under-specification:
>
> Section 4.1. says:
>
>=C2=A0 =C2=A0 The Outer IP/UDP
>=C2=A0 =C2=A0 and VXLAN headers MUST be encoded by the sender as define= d in
>=C2=A0 =C2=A0 [RFC7348].
>
>
> And RFC 7348 says:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0 Source Port:=C2=A0 It is recommended= that the UDP source port number
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be calculated using a hash of fields= from the inner packet --
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 one example being a hash of the inne= r Ethernet frame's headers.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This is to enable a level of entropy= for the ECMP/load-
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 balancing of the VM-to-VM traffic ac= ross the VXLAN overlay.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 When calculating the UDP source port= number in this manner, it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is RECOMMENDED that the value be in = the dynamic/private port
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 range 49152-65535 [RFC6335].
>
>
> Based on this, depending on the hashing calculation, the outer source = UDP port can be different leading to different ECMP treatment. Does somethi= ng else need to be specified here in regards to the outer UDP source port?<= br> >
>
> 4. Section 7 says that =E2=80=9C Support for echo BFD is outside the s= cope of this document=E2=80=9D.
>
> Assuming this means =E2=80=9CBFD Echo mode=E2=80=9D, why is this out o= f scope? If this is a single logical hop underneath VXLAN, what=E2=80=99s p= reventing the use of Echo? Echo=E2=80=99s benefits are huge.
>
>
> 5. Terminology
>
>=C2=A0 =C2=A0 Implementations SHOULD ensure that the BFD
>=C2=A0 =C2=A0 packets follow the same lookup path as VXLAN data packets= within the
>=C2=A0 =C2=A0 sender system.
>
> What is a =E2=80=9Clook up path within a sender system=E2=80=9D?
>
>
> 6. Deployment scenarios
>
> S3 says:
>=C2=A0 =C2=A0 Figure 1 illustrates the scenario with two servers, each = of them
>=C2=A0 =C2=A0 hosting two VMs.=C2=A0 The servers host VTEPs that termin= ate two VXLAN
> [=E2=80=A6]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Figure 1: Reference VXLAN Domain
>
>
> However, RFC 7348 Figure 3 lists that as one deployment scenario, not = as =E2=80=9Cthe scenario=E2=80=9D and =E2=80=9CThe Reference VXLAN Domain= =E2=80=9D.
>
> Best,
>
> Carlos.
>
>> On Jun 17, 2019, at 12:58 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:=
>>
>> Hi Oliver,
>> thank you for your thorough review, clear and detailed questions. = My apologies for the delay to respond. Please find my answers below in-line= tagged GIM>>.
>>
>> Regards,
>> Greg
>>
>> On Fri, May 31, 2019 at 12:38 PM Olivier Bonaventure via Datatrack= er <noreply@ietf.o= rg> wrote:
>> Reviewer: Olivier Bonaventure
>> Review result: Ready with Issues
>>
>> This document has been reviewed as part of the transport area revi= ew team's
>> ongoing effort to review key IETF documents. These comments were w= ritten
>> primarily for the transport area directors, but are copied to the = document's
>> authors and WG to allow them to address any issues raised and also= to the IETF
>> discussion list for information.
>>
>> When done at the time of IETF Last Call, the authors should consid= er this
>> review as part of the last-call comments they receive. Please alwa= ys CC
>> tsv-art@ietf= .org if you reply to or forward this review.
>>
>> I have only limited knowledge of VXLAN and do not know all subtlet= ies of BFD.
>> This review is thus more from a generalist than a specialist in th= is topic.
>>
>> Major issues
>>
>> Section 4 requires that " Implementations SHOULD ensure that = the BFD
>>=C2=A0 =C2=A0 packets follow the same lookup path as VXLAN data pac= kets within the
>>=C2=A0 =C2=A0 sender system."
>>
>> Why is this requirement only relevant for the lookup path on the s= ender system
>> ? What does this sentence really implies ?
>> GIM>> RFC 5880 set the scope of the fault detection of BFD p= rotocol as
>>=C2=A0 =C2=A0 ... the bidirectional path between two forwarding eng= ines, including
>>=C2=A0 =C2=A0 interfaces, data link(s), and to the extent possible = the forwarding
>>=C2=A0 =C2=A0 engines themselves ...
>> The requirement aimed to the forwarding engine of a BFD system tha= t transmits BFD control packets over VXLAN tunnel.
>>
>> Is it a requirement that the BFD packets follow the same path as t= he data
>> packet for a given VXLAN ? I guess so. In this case, the document = should
>> discuss how Equal Cost Multipath could affect this.
>> GIM>> I think that ECMP environment is more likely to be exp= erienced by a transit node in the underlay. If the BFD session is used to m= onitor the specific underlay path, then, I agree, we should explain that us= ing the VXLAN payload information to draw path entropy may cause data and B= FD packets following different underlay routes. But, on the other hand, tha= t is the case for OAM and fault detection in all overlay networks in genera= l.
>>
>> Minor issues
>>
>> Section 1
>>
>> You write "The asynchronous mode of BFD, as defined in [RFC58= 80],
>>=C2=A0 can be used to monitor a p2p VXLAN tunnel."
>>
>> Why do you use the word can ? It is a possibility or a requirement= ?
>> GIM>> In principle, BFD Demand mode may be used to monitor p= 2p paths as well, I agree, will re-word to more assertive:
>>=C2=A0 The asynchronous mode of BFD, as defined in [RFC5880],
>>=C2=A0 is used to monitor a p2p VXLAN tunnel.
>>
>> NVE has not been defined before and is not in the terminology.
>> GIM>> Will add to the Terminology and expand as:
>> NVE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Network Virtualization Endpoint >>
>> This entire section is not easy to read for an outsider.
>>
>> Section 3
>>
>> VNI has not been defined
>> GIM>> Will add to the Terminology section:
>> VNI=C2=A0 =C2=A0 VXLAN Network Identifier (or VXLAN Segment ID) >>
>> Figure 1 could take less space
>> GIM>> Yes, can make it bit denser. Would the following be an= improvement?
>>=C2=A0
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0+------------+-------------+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 Server 1=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0| +----+----+=C2=A0 +----+----+ |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0| |VM1-1=C2=A0 =C2=A0 |=C2=A0 |VM1-2=C2= =A0 =C2=A0 | |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0| |VNI 100=C2=A0 |=C2=A0 |VNI 200=C2=A0 = | |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0| |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0| +---------+=C2=A0 +---------+ |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0| Hypervisor VTEP (IP1)=C2=A0 =C2=A0 | >>=C2=A0 =C2=A0 =C2=A0 =C2=A0+--------------------------+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0+-------------+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0|=C2=A0 =C2=A0Layer 3= =C2=A0 =C2=A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---|=C2=A0 =C2=A0Network=C2=A0 =C2= =A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-------------+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------= ---+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 +------------+-------------+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 Hypervisor VTEP (IP2) |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | +----+----+=C2=A0 +----+----+ |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | |VM2-1=C2=A0 =C2=A0 |=C2=A0 |VM2-2=C2=A0 =C2=A0 | |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | |VNI 100=C2=A0 |=C2=A0 |VNI 200=C2=A0 | |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | +---------+=C2=A0 +---------+ |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 Server 2=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 +--------------------------+
>>
>>
>> Section 4
>>
>> I do not see the benefits of having one paragraph in Section 4 fol= lowed by only
>> Section 4.1
>> GIM>> Will merge Section 4.1 into 4 with minor required re-w= ording:
>> 4.=C2=A0 BFD Packet Transmission over VXLAN Tunnel
>>
>>=C2=A0 =C2=A0 BFD packet MUST be encapsulated and sent to a remote = VTEP as
>>=C2=A0 =C2=A0 explained in this section.=C2=A0 Implementations SHOU= LD ensure that the
>>=C2=A0 =C2=A0 BFD packets follow the same lookup path as VXLAN data= packets within
>>=C2=A0 =C2=A0 the sender system.
>>
>>=C2=A0 =C2=A0 BFD packets are encapsulated in VXLAN as described be= low.=C2=A0 The VXLAN
>>=C2=A0 =C2=A0 packet format is defined in Section 5 of [RFC7348].= =C2=A0 The Outer IP/UDP
>>=C2=A0 =C2=A0 and VXLAN headers MUST be encoded by the sender as de= fined in
>>=C2=A0 =C2=A0 [RFC7348].
>>
>> Section 4.1
>>
>> The document does not specify when a dedicated MAC address or the = MAC address
>> of the destination VTEP must be used. This could affect the intero= perability of
>> implementations. Should all implementations support both the dedic= ated MAC
>> address and the destination MAC address ?
>> GIM>> After further discussion, authors decided to remove th= e request for the dedicated MAC address allocation. Only the MAC address of= the remote VTEP must be used as the destination MAC address in the inner E= thernet frame. Please check the attached diff between the -07 and the worki= ng versions or the working version of the draft.
>>
>> It is unclear from this section whether IPv4 inside IPv6 and the o= pposite
>> should be supported or not.
>> GIM>> Any combination of outer IPvX and inner IPvX is possib= le.
>>
>> Section 5.
>>
>> If the received packet does not match the dedicated MAC address no= r the MAC
>> address of the VTEP, should the packet be silently discarded or tr= eated
>> differently ?
>> GIM>> As I've mentioned earlier, authors have decided to= remove the use of the dedicated MAC address for BFD over VXLAN.
>>
>> Section 5.1
>>
>> Is this a modification to section 6.3 of RFC5880 ? This is not cle= ar
>> GIM>> I think that this section is not modification but the = definition of the application-specific procedure that is outside the scope = of RFC 5880:
>>=C2=A0 =C2=A0 The method of demultiplexing the initial packets (in = which Your
>>=C2=A0 =C2=A0 Discriminator is zero) is application dependent, and = is thus outside
>>=C2=A0 =C2=A0 the scope of this specification.
>>
>> Section 9
>>
>> The sentence " Throttling MAY be relaxed for BFD packets
>>=C2=A0 =C2=A0 based on port number." is unclear.
>> GIM>> Yes, thank you for pointing to this. The updated text,= in the whole paragraph, is as follows:
>> NEW TEXT:
>>=C2=A0 =C2=A0 The document requires setting the inner IP TTL to 1, = which could be
>>=C2=A0 =C2=A0 used as a DDoS attack vector.=C2=A0 Thus the implemen= tation MUST have
>>=C2=A0 =C2=A0 throttling in place to control the rate of BFD contro= l packets sent
>>=C2=A0 =C2=A0 to the control plane.=C2=A0 On the other hand, over a= ggressive throttling
>>=C2=A0 =C2=A0 of BFD control packets may become the cause of the in= ability to form
>>=C2=A0 =C2=A0 and maintain BFD session at scale.=C2=A0 Hence, throt= tling of BFD control
>>=C2=A0 =C2=A0 packets SHOULD be adjusted to permit BFD to work acco= rding to its
>>=C2=A0 =C2=A0 procedures.
>> <draft-ietf-bfd-vxlan-08.txt><Diff_ draft-ietf-bfd-vxlan-= 07.txt - draft-ietf-bfd-vxlan-08.txt.html>
>

--0000000000008e2644058bb7af93-- From nobody Wed Jun 19 19:44:16 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EA5812041D; Wed, 19 Jun 2019 19:09:26 -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, 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 header.b=YbSjhwty; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=VEWLLFYp 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 kjQuGsObEeMm; Wed, 19 Jun 2019 19:09:21 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC051202E7; Wed, 19 Jun 2019 19:09:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=67003; q=dns/txt; s=iport; t=1560996560; x=1562206160; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZUFR2q9lW7QNb77LNv+vF0qDgocweJ4KGwFi4T14hAA=; b=YbSjhwtyMcJ+IrxvXpqUw7lQPczw5HtVEeIMzVi2pZ/gHokwIu+Uc1pv a52uLFgBtdpLGZHBRMzxmFfNn7ntAAPGkXYMygISJd1gVWlF6Jqcx+x4h qy2GKC3ACO54xR0VVKvsdPFe7ypLlhG4kwAZ8dMIlLIhHXMp0aCL1FvOs c=; IronPort-PHdr: =?us-ascii?q?9a23=3A6EbFrxb3NMRWWxjCJBY/7Xf/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8Kavhdy01Gs1eXXdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A1AAAS6gpd/5JdJa1mGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBVQQBAQELAYEULyQsA2pVIAQLKAqEDINHA45ggleJRY1xgS4UgRA?= =?us-ascii?q?DVAkBAQEMAQEjCgIBAYRAAheCQSM2Bw4BAwEBBAEBAgEFbYo3DIVKAQEBAwE?= =?us-ascii?q?SCAEIBBkBASUECQUBBAsCAQgYIAEGAwICAh8RFBECBA4FIoMAAYEdTQMODwE?= =?us-ascii?q?CDKJTAoE4iF9xfjOCeQEBBYUBDQuCEAMGgTQBhHCEJIEegSsXgUA/gRABJx+?= =?us-ascii?q?CTD6CGkcBAQIBgSoBAQsGAgEIFRgVAQuCUjKCJot0LQKBcC6EdIhMjH4sPgk?= =?us-ascii?q?CghGGSIkfBINoG4InhwaECoVgglKBS5RBgWqKUYMIAgQCBAUCDgEBBYFXByp?= =?us-ascii?q?ncXAVOyoBgkE+ggMLGINNhRSFPgFyAYEoi0yBMQGBIAEB?= X-IronPort-AV: E=Sophos;i="5.63,395,1557187200"; d="scan'208,217";a="575986672" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Jun 2019 02:09:17 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id x5K29FON014096 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Jun 2019 02:09:15 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 19 Jun 2019 21:09:15 -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; Wed, 19 Jun 2019 21:09:14 -0500 Received: from NAM05-CO1-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; Wed, 19 Jun 2019 22:09:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZUFR2q9lW7QNb77LNv+vF0qDgocweJ4KGwFi4T14hAA=; b=VEWLLFYpOIk/ZEidU3umkb10PRC7cy3bzX6fieyM95V0WWpPbJuzm8wp53pFnOtRrZlJEG5hkGsy6oN4p7xhjJ/fLLM1CfgTVa7dyIZdPonnuKWKKnibs2MbLhTn5MtOppQKPeftek1JtUlZk8gyrKVuvgGeQirwYFfC0MEpzMU= Received: from BL0PR11MB3028.namprd11.prod.outlook.com (20.177.204.138) by BL0PR11MB3380.namprd11.prod.outlook.com (10.167.240.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.11; Thu, 20 Jun 2019 02:09:12 +0000 Received: from BL0PR11MB3028.namprd11.prod.outlook.com ([fe80::ec33:f4c1:227a:fcb3]) by BL0PR11MB3028.namprd11.prod.outlook.com ([fe80::ec33:f4c1:227a:fcb3%5]) with mapi id 15.20.1987.014; Thu, 20 Jun 2019 02:09:12 +0000 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: "tsv-art@ietf.org" , rtg-bfd WG , "draft-ietf-bfd-vxlan.all@ietf.org" , Olivier Bonaventure , IETF list Subject: Re: Tsvart last call review of draft-ietf-bfd-vxlan-07 Thread-Topic: Tsvart last call review of draft-ietf-bfd-vxlan-07 Thread-Index: AQHVJMqh+O1Bih53oEC7haZ3x5KaoKajsLYAgAAPSACAAAYzgIAAB4wAgAAC+oA= Date: Thu, 20 Jun 2019 02:09:12 +0000 Message-ID: <0B9FDA17-7F13-4FEC-AE97-40BC9D72C87B@cisco.com> References: <155933149484.6565.7386019489022348116@ietfa.amsl.com> <14822B96-D3C6-495E-8661-198068F72ABA@cisco.com> <8237FE8D-937E-4BCB-B1A3-89C2B3CDC51C@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.11) authentication-results: spf=none (sender IP is ) smtp.mailfrom=cpignata@cisco.com; x-originating-ip: [173.38.117.68] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 317de923-1247-4573-cd67-08d6f5244999 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BL0PR11MB3380; x-ms-traffictypediagnostic: BL0PR11MB3380: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0074BBE012 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(346002)(39860400002)(136003)(366004)(189003)(199004)(51444003)(102836004)(2906002)(53936002)(99286004)(478600001)(66946007)(26005)(36756003)(6512007)(446003)(6306002)(54896002)(1411001)(6506007)(68736007)(53546011)(57306001)(53946003)(71190400001)(2616005)(256004)(486006)(71200400001)(6916009)(30864003)(66066001)(476003)(11346002)(14454004)(76176011)(236005)(66446008)(6436002)(8676002)(6246003)(3846002)(6116002)(81166006)(7736002)(561944003)(66556008)(6486002)(5024004)(64756008)(14444005)(966005)(25786009)(8936002)(66476007)(54906003)(4326008)(73956011)(606006)(316002)(229853002)(5660300002)(33656002)(50226002)(76116006)(86362001)(81156014)(186003); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR11MB3380; H:BL0PR11MB3028.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: qb9hspE11jSnaIrzmxGsGggVSC1Vlvalnz6bsIMOc64qhF1f/DXx5774Vba0FDjtZ+GEdWdVezm42lypdgcqOJXIYIyeiBBsQsUI7K9/1aHl3mHieaIvWb310BgVHIi6gUsFUWCp4XvRGD1BuiB+rpNQN2XvQPGvN8UiCRlTj5rxRRRFVyjtgWWtz06VGcOnU4DNeycFA1SmCeQhCXFzm4PyNl7sJUe9xM0aucIFtUeznVJBOxZm4OQJprUdu3WfqQfHtNSupqnkPzFce1R55ViLUWttVnJRdnsWfPzfbwtGiGYJOeP3mOaqcargshXXFovLXzQ0zuBbB8IEh70kZVWfGZnpdNF9WhluEn2xs9XIB5UExMKR2SL/FH+wmL06H8jwvDOe40E04IHvsOPY03NTOE2ewSfkfaG44i7jrHw= Content-Type: multipart/alternative; boundary="_000_0B9FDA177F134FECAE9740BC9D72C87Bciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 317de923-1247-4573-cd67-08d6f5244999 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2019 02:09:12.0668 (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-CrossTenant-userprincipalname: cpignata@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3380 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.29, xch-aln-019.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: X-Mailman-Approved-At: Wed, 19 Jun 2019 19:43:59 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 02:09:27 -0000 --_000_0B9FDA177F134FECAE9740BC9D72C87Bciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sIEdyZWcsDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQpPbiBKdW4gMTksIDIwMTksIGF0 IDk6NTggUE0sIEdyZWcgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFpbC5jb208bWFpbHRvOmdyZWdp bWlyc2t5QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQpIZWxsbyBDYXJsb3MsDQp0aGFuayB5b3UgZm9y IHRoZSBleHBlZGllbnQgY2xhcmlmaWNhdGlvbi4NClRvIHlvdXIgcXVlc3Rpb25zIG9uIGRlbXVs dGlwbGV4aW5nIEJGRCBjb250cm9sIHBhY2tldHMgd2l0aCB0aGUgemVybyB2YWx1ZSBvZiB0aGUg WW91ciBEaXNjcmltaW5hdG9yIGZpZWxkOg0KDQogICogICBvbmx5IEJGRCBjb250cm9sIHBhY2tl dHMgd2l0aCB0aGUgemVybyB2YWx1ZSBvZiB0aGUgWW91ciBEaXNjcmltaW5hdG9yIGZpZWxkIGFy ZSBkZW11bHRpcGxleGVkIHVzaW5nIHRoZSBpbmZvcm1hdGlvbiBvZiB0aGUgaW5uZXIgSVAgaGVh ZGVyLiBJIGJlbGlldmUgdGhhdCB0aGUgdGV4dCBpcyBjbGVhciBhbmQgcmVxdWlyZXMgdGhhdCBh bGwgZmllbGRzIG9mIHRoZSBpbm5lciBJUCBoZWFkZXIgbXVzdCBiZSB1c2VkIHRvIGRlbXVsdGlw bGV4IGEgcmVjZWl2ZWQgQkZEIGNvbnRyb2wgcGFja2V0IHdpdGggdGhlIHplcm8gdmFsdWUgaW4g dGhlIFlvdXIgRGlzY3JpbWluYXRvciBmaWVsZC4gV2hpY2ggb2YgdGhlIGZpZWxkcyBhbiBpbXBs ZW1lbnRhdGlvbiB1c2VzIHRvIGNyZWF0ZSBtdWx0aXBsZSBCRkQgc2Vzc2lvbnMgYmV0d2VlbiB0 aGUgcGFpciBvZiBWVEVQcyBpcyBpbXBsZW1lbnRhdGlvbiBzcGVjaWZpYy4NCg0KVGhpcyB0ZXh0 IGlzIHJlcGVhdGluZyB3YXMgaXMgaW4gdGhlIGRyYWZ0LCBidXQgZG9lcyBub3QgYW5zd2VyIGFu eSBvZiBteSBxdWVzdGlvbnMuDQoNCkZvciBleGFtcGxlOg0KMS4gInRoYXQgYWxsIGZpZWxkcyBv ZiB0aGUgaW5uZXIgSVAgaGVhZGVyIG11c3QgYmUgdXNlZCB0byBkZW11bHRpcGxleCBhIHJlY2Vp dmVkIEJGRCBjb250cm9sIHBhY2tldOKAnQ0KICAgIC0+IFRoZSB0ZXh0IGRvZXMgbm90IHNheSDi gJxhbGwgZmllbGRz4oCdLCBidXQgcmVnYXJkbGVzcywgZG8geW91IG1lYW4gdGhlIERTQ1AgYW5k IHRoZSBFdmlsIEJpdD8gSVB2NiBGbG93IExhYmVsPyBIb3cgKmV4YWN0bHkqPw0KMi4gSG93IGlz IHRoZSBtYXBwaW5nIG9mIElQIChub3QgVURQPykgZmllbGRzIHRvIEJGRCBzZXNzaW9uIGRvbmU/ DQozLiBIb3cgaXMgdGhpcyBzdGF0ZSBjcmVhdGVkIGFuZCBtYWludGFpbmVkPw0KNC4gU2luY2Ug dGhpcyBpcyBhIHNldCBvZiBmaWVsZHMgb24gd2hpY2ggdHdvIHN5c3RlbXMgbmVlZCB0byBhZ3Jl ZSAod2hpY2ggZmllbGRzIGZyb20gdGhlIGlubmVyIElQL1VEUCBhcmUgbWFwcGVkIG5lZWRzIHRv IGJlIHVuZGVyc3Rvb2QgYnkgYm90aCBzeXN0ZW1zKSwgaXQgY2Fubm90IGJlIOKAnGltcGxlbWVu dGF0aW9uIHNwZWNpZmlj4oCdLiBGdXJ0aGVyLCB0aGUgdGV4dCBkb2VzIG5vdCBzYXkgc28uDQoN ClRvIHlvdXIgcG9pbnQgb24gdGhlIGxldmVsIEVjaG8gbW9kZSBvZiBCRkQgaXMgc3BlY2lmaWVk IGluIFJGQyA1ODgwIEknbGwgcXVvdGUgdGhlIG9waW5pb24gb2YgSmVmZnJleSBIYWFzIGZyb20g dGhlIGRpc2N1c3Npb24gb2YgY29tbWVudHMgZnJvbSBTaGF3biBFbWVyeSBvbiBiZWhhbGYgb2Yg dGhlIFNlY0Rpci4gU2hhd24gaGFkIGNvbW1lbnRlZDoNCkVjaG8gQkZEIGlzIG91dCBvZiBzY29w ZSBmb3IgdGhlIGRvY3VtZW50LCBidXQgZG9lcyBub3QgZGVzY3JpYmUgdGhlIHJlYXNvbiBmb3Ig dGhpcyBvciB3aHkgc3RhdGUNCnRoaXMgYXQgYWxsPw0KSSd2ZSByZXNwb25kZWQ6DQpHSU0+PiBJ IHRoaW5rIHRoYXQgdGhlIG1haW4gcmVhc29uIGlzIHRoYXQgdGhlIEJGRCBFY2hvIG1vZGUgaXMg dW5kZXJzcGVjaWZpZWQuIFJGQyA1ODgwIGRlZmluZWQgc29tZSBvZiB0aGUgbWVjaGFuaXNtcyBy ZWxhdGVkIHRvIHRoZSBFY2hvIG1vZGUsIGJ1dCBtb3JlIHN0YW5kYXJkaXphdGlvbiB3b3JrIG1h eSBiZSByZXF1aXJlZC4NCkFuZCBKZWZmcmV5IEhhYXMgaGFkIGFkZGVkOg0KU3BlYWtpbmcgYXMg YSBCRkQgY2hhaXIsIHRoaXMgaXMgdGhlIHJlbGV2YW50IG9ic2VydmF0aW9uLiAgQkZEIEVjaG8g aXMNCnVuZGVyc3BlY2lmaWVkIHRvIHRoZSBwb2ludCB3aGVyZSBjbGFpbWluZyBjb21wbGlhbmNl IGlzIGRpZmZpY3VsdCBhdCBiZXN0Lg0KSW4gZ2VuZXJhbCwgaXQgcmVsaWVzIG9uIHNpbmdsZS1o b3AgYW5kIHRoZSBhYmlsaXR5IHRvIGhhdmUgdGhlIHJlbW90ZSBFY2hvDQpjbGllbnQgbG9vcCB0 aGUgcGFja2V0cy4NCg0KQkZEIEVjaG8gY2Fubm90IGJlIHNwZWNpZmllZCBpbiBSRkMgNTg4MCBi YXNlIHNwZWMgYmVjYXVzZSBpdCBpcyBhcHBsaWNhdGlvbiBzcGVjaWZpYy4NCg0KDQpUaGlzIHBh Y2tldCBsb29wIG1heSBub3QgYmUgcHJhY3RpY2FsIGZvciBzZXZlcmFsIGVuY2Fwc3VsYXRpb25z IGFuZCB0aHVzIGlzDQpvdXQgb2Ygc2NvcGUgZm9yIHN1Y2ggZW5jYXBzdWxhdGlvbnMuICBXaGV0 aGVyIHRoaXMgaXMgcHJhY3RpY2FsIGZvciB2eGxhbg0KdG9kYXksIG9yIGluIHRoZSBwcmVzZW5j ZSBvZiBmdXR1cmUgZXh0ZW5zaW9ucyB0byB2eGxhbiBpcyBsZWZ0IG91dCBvZiBzY29wZQ0KZm9y IHRoZSBjb3JlIHByb3Bvc2FsLg0KDQpUaGUgcXVlc3Rpb24gcmVtYWluczogZm9yIFZYTEFOIGVu Y2Fwc3VsYXRpb24sIHRoaXMgaXMgbGlrZSBhIHNpbmdsZSBob3AgYXMgZmFyIGFzIEJGRCBpcyBj b25jZXJuZWQgKHNpbmdsZSBob3AgVlhMQU4gdHVubmVsKS4NCg0KU2luY2UgUkZDIDU4ODEgZGVm aW5lcyBFY2hvIGZvciBzaW5nbGUgaG9wLCBjYW4geW91IHBsZWFzZSBlbGFib3JhdGUgKGluIHRo ZSBkb2N1bWVudCkgd2h5IGlzIG91dCBvZiBzY29wZSBvciBob3cgaXQgY2FuIHdvcms/DQoNCkJl c3QsDQoNCkNhcmxvcy4NCg0KDQpXaWxsIHJlc3BvbmQgdG8gb3RoZXIgcXVlc3Rpb25zIGluIGEg c2VwYXJhdGUgbWFpbC4NCg0KUmVnYXJkcywNCkdyZWcNCg0KDQpPbiBUaHUsIEp1biAyMCwgMjAx OSBhdCAxMDozMSBBTSBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgPGNwaWduYXRhQGNpc2Nv LmNvbTxtYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tPj4gd3JvdGU6DQpIZWxsbywgR3JlZywNCg0K PiBPbiBKdW4gMTksIDIwMTksIGF0IDk6MDkgUE0sIEdyZWcgTWlyc2t5IDxncmVnaW1pcnNreUBn bWFpbC5jb208bWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbT4+IHdyb3RlOg0KPg0KPiBIaSBD YXJsb3MsDQo+IHRoYW5rIHlvdSBmb3IgcmVtaW5kaW5nIG9mIG91ciBjb250aW51ZWQgZGlzY3Vz c2lvbiB3aXRoIEpvZWwuIFdlIGFyZSBzZWVraW5nIGNvbW1lbnRzIGZyb20gVlhMQU4gZXhwZXJ0 cyBhbmQgbXVjaCBhcHByZWNpYXRlIGlmIHlvdSBoYXZlIGluc2lnaHRzIG9uIFZYTEFOIHRvIHNo YXJlLg0KPiBJJ3ZlIGdvdCBzb21lIGNsYXJpZnlpbmcgcXVlc3Rpb25zIGJlZm9yZSBJIGNhbiBy ZXNwb25kIHRvIHlvdS4NCg0KU3VyZS4NCg0KPiBUbyB3aGljaCBzdGFnZSBvZiB0aGUgdGhyZWUt d2F5IGhhbmRzaGFrZSB5b3UgcmVmZXIgYXMgImluaXRpYWwgZGVtdWx0aXBsZXhpbmciPyBJIGNv dWxkbid0IGZpbmQgdGhpcyB0ZXJtIGluIFJGQyA1ODgwLg0KDQrigJxJbml0aWFsIGRlbXVsdGlw bGV4aW5nIiBpcyBhIHdlbGwta25vd24gdGVybSBpbiBCRkQsIHJlZmVycmluZyB0byB0aGUgImRl bXVsdGlwbGV4aW5nIG9mIHRoZSBpbml0aWFsIHBhY2tldHMiLCBCRkQgQ29udHJvbCBwYWNrZXQg d2l0aCBZb3VyRGlzYyBiZWluZyB6ZXJvLg0KDQpJbiBSRkMgNTg4MCwgc2VlIFNlY3Rpb24gNi4z Lg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU4ODAjc2VjdGlvbi02LjMNCg0KICAg VGhlIG1ldGhvZCBvZiBkZW11bHRpcGxleGluZyB0aGUgaW5pdGlhbCBwYWNrZXRzIChpbiB3aGlj aCBZb3VyDQogICBEaXNjcmltaW5hdG9yIGlzIHplcm8pIGlzIGFwcGxpY2F0aW9uIGRlcGVuZGVu dCwgYW5kIGlzIHRodXMgb3V0c2lkZQ0KICAgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlv bi4NCg0KU2luY2UgaW5pdGlhbCBkZW11bHRpcGxleGluZyBpcyBpbmRlZWQgYXBwbGljYXRpb24g c3BlY2lmaWMsIGRpZmZlcmVudCBmb3Igb25lLWhvcCB2ZXJzdXMgbXVsdGktaG9wIGFuZCBkZXBl bmRlbnQgdXBvbiB3aGV0aGVyIGEgc2luZ2xlIG9yIG11bHRpcGxlIHNlc3Npb25zIGFyZSBhbGxv d2VkIGJldHdlZW4gYSBwYWlyIG9mIGVuZHBvaW50cywgSSBhZGRlZCBiZWxvdyB0d28gb3RoZXIg cmVsZXZhbnQgY2l0YXRpb25zLCBmcm9tIGFwcGxpY2F0aW9uIHNwZWNpZmljIEJGRCBzcGVjczoN CjEuIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1ODgzI3NlY3Rpb24tNA0KMi4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU4ODIjc2VjdGlvbi02DQoNCg0KPiBSZWdhcmRp bmcgdGhlIGFwcGxpY2FiaWxpdHkgb2YgdGhlIEVjaG8gbW9kZSwgdGhhbmsgeW91IGZvciBwb2lu dGluZyB0byB0aGUgbmVlZCBmb3Igc3RyaWN0ZXIgdGVybWlub2xvZ3ksIHRoZSBFY2hvIG1vZGUs IGFzIGRlZmluZWQgaW4gUkZDIDU4ODAsIGlzIHVuZGVyc3BlY2lmaWVkIGFuZCBpdCB3aWxsIHJl cXVpcmUgYWRkaXRpb25hbCBzdGFuZGFyZGl6YXRpb24uDQoNCk5vLiBCRkQgRWNobyBpcyBub3Qg dW5kZXJzcGVjaWZpZWQgaW4gUkZDIDU4ODAuDQoNClBsZWFzZSByZWFkIFM1OiBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNTg4MCNzZWN0aW9uLTUNCg0KICAgQkZEIEVjaG8gcGFja2V0 cyBhcmUgc2VudCBpbiBhbiBlbmNhcHN1bGF0aW9uIGFwcHJvcHJpYXRlIHRvIHRoZQ0KICAgZW52 aXJvbm1lbnQuICBTZWUgdGhlIGFwcHJvcHJpYXRlIGFwcGxpY2F0aW9uIGRvY3VtZW50cyBmb3Ig dGhlDQogICBzcGVjaWZpY3Mgb2YgcGFydGljdWxhciBlbnZpcm9ubWVudHMuDQoNCg0KQkZEIEVj aG8gaXMgYXBwbGljYXRpb24gZGVwZW5kZW50Lg0KDQpUaGVyZWZvcmUsIGZvciBleGFtcGxlLCBz aW5nbGUtaG9wIEJGRCBpbiBSRkMgNTg4MSBzcGVjaWZpZXMgQkZEIEVjaG8gZm9yIHRoYXQgYXBw bGljYXRpb24uDQoNCkhlbmNlLCBteSBxdWVzdGlvbiBzdGFuZHM6IHdoeSBpcyB0aGlzIGRyYWZ0 IGNsYWltaW5nIEJGRCBFY2hvIGlzIG91dCBvZiBzY29wZSBmb3IgdGhpcyBCRkQgYXBwbGljYXRp b24gZG9jdW1lbnQ/DQoNCg0KPiBGdXR1cmUgZHJhZnRzIG1heSBleHBsb3JlIGFuZCBkZWZpbmUg aG93IHRoZSBFY2hvIG1vZGUgb2YgQkZEIGlzIHVzZWQgb3ZlciBWWExBTiB0dW5uZWxzLg0KPg0K DQpTZWUgYWJvdmUuDQoNCj4gV2lsbCByZXZpZXcgYW5kIHJlc3BvbmQgdG8gdGhlIHJlbWFpbmlu ZyBxdWVzdGlvbnMgc29vbi4NCg0KVGhhbmsgeW91Lg0KDQpUaGUgInJlbWFpbmluZyBxdWVzdGlv bnMiIGFyZSBzdGlsbCBhbGwgdGhlIHF1ZXN0aW9ucyBiZWxvdyA6LSkNCg0KQmVzdCwNCg0KQ2Fy bG9zLg0KDQo+DQo+IFJlZ2FyZHMsDQo+IEdyZWcNCj4NCj4NCj4gT24gVGh1LCBKdW4gMjAsIDIw MTkgYXQgOToxNCBBTSBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgPGNwaWduYXRhQGNpc2Nv LmNvbTxtYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tPj4gd3JvdGU6DQo+IEhpLA0KPg0KPiBJIGhh dmUgbm90IHJldmlld2VkIHRoaXMgZHJhZnQgYmVmb3JlLCBidXQgdHJpZ2dlcmVkIGJ5IHRoaXMg ZW1haWwsIGFuZCBicmllZmx5IHNjYW5uaW5nIHRocm91Z2ggYSBjb3VwbGUgb2Ygc2VjdGlvbnMs IGl0IGlzIHVuY2xlYXIgdG8gbWUgaG93IHNvbWUgb2YgdGhlIG1lY2hhbmljcyB3b3JrLg0KPg0K PiBUaGVyZSBhcmUgc29tZSBtYWpvciBpc3N1ZXMgd2l0aCB0aGUgTWFjIHVzYWdlIGFuZCBhc3Nv Y2lhdGlvbiwgYXMgSm9lbCBIYWxwZXJuIG1lbnRpb25lZCBpbiBoaXMgUnRnIERpciByZXZpZXcu DQo+DQo+IEFuZCwgYWRkaXRpb25hbGx5LCBwbGVhc2UgY29uc2lkZXIgdGhlIGZvbGxvd2luZyBj b21tZW50cyBhbmQgcXVlc3Rpb25zOg0KPg0KPg0KPiAxLiBVbmRlcnNwZWNpZmljYXRpb24gZm9y IGluaXRpYWxpemF0aW9uIGFuZCBpbml0aWFsIGRlbXVsdGlwbGV4aW5nLg0KPg0KPiBUaGlzIGRv Y3VtZW50IGFsbG93cyBtdWx0aXBsZSBCRkQgc2Vzc2lvbnMgYmV0d2VlbiBhIHNpbmdsZSBwYWly IG9mIFZURVBzOg0KPg0KPiAgICBBbg0KPiAgICBpbXBsZW1lbnRhdGlvbiB0aGF0IHN1cHBvcnRz IHRoaXMgc3BlY2lmaWNhdGlvbiBNVVNUIGJlIGFibGUgdG8NCj4gICAgY29udHJvbCB0aGUgbnVt YmVyIG9mIEJGRCBzZXNzaW9ucyB0aGF0IGNhbiBiZSBjcmVhdGVkIGJldHdlZW4gdGhlDQo+ICAg IHNhbWUgcGFpciBvZiBWVEVQcy4NCj4NCj4gVGhlIGltcGxpY2F0aW9uIG9mIHRoaXMgaXMgdGhh dCBCRkQgc2luZ2xlLWhvcCBpbml0aWFsaXphdGlvbiBwcm9jZWR1cmVzIHdpbGwgbm90IHdvcmsu IEluc3RlYWQsIHRoZXJlIGlzIGEgbmVlZCB0byBtYXAgdGhlIGluaXRpYWwgZGVtdWx0aXBsZXhp bmcuDQo+DQo+IFRoaXMgaXNzdWUgaXMgZXhwbGFpbmVkIGluIFJGQ3MgNTg4MiBhbmQgNTg4Mzog aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU4ODMjc2VjdGlvbi00IGFuZCBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTg4MiNzZWN0aW9uLTYNCj4NCj4gU2VjdGlvbiA1LjEg c2F5czoNCj4NCj4gICAgRm9yIHN1Y2ggcGFja2V0cywgdGhlIEJGRCBzZXNzaW9uIE1VU1QgYmUg aWRlbnRpZmllZA0KPiAgICB1c2luZyB0aGUgaW5uZXIgaGVhZGVycywgaS5lLiwgdGhlIHNvdXJj ZSBJUCwgdGhlIGRlc3RpbmF0aW9uIElQLCBhbmQNCj4gICAgdGhlIHNvdXJjZSBVRFAgcG9ydCBu dW1iZXIgcHJlc2VudCBpbiB0aGUgSVAgaGVhZGVyIGNhcnJpZWQgYnkgdGhlDQo+ICAgIHBheWxv YWQgb2YgdGhlIFZYTEFOIGVuY2Fwc3VsYXRlZCBwYWNrZXQuICBUaGUgVk5JIG9mIHRoZSBwYWNr ZXQNCj4gICAgU0hPVUxEIGJlIHVzZWQgdG8gZGVyaXZlIGludGVyZmFjZS1yZWxhdGVkIGluZm9y bWF0aW9uIGZvcg0KPiAgICBkZW11bHRpcGxleGluZyB0aGUgcGFja2V0Lg0KPg0KPiBCdXQgdGhp cyBkb2VzIG5vdCByZWFsbHkgZXhwbGFpbiBob3cgdG8gZG8gdGhlIGluaXRpYWwgZGVtdWx0aXBs ZXhpbmcuIERvZXMgZWFjaCBCRkQgc2Vzc2lvbiBuZWVkIHRvIGhhdmUgYSBzZXBhcmF0ZSBpbm5l ciBzb3VyY2UgSVAgYWRkcmVzcz8gT3Igc291cmNlIFVEUCBwb3J0PyBBbmQgaG93IG9mdGVyIGFy ZSB0aGV5IHJlY3ljbGVkIG9yIGtlcHQgYXMgc3RhdGU/IEhvdyBhcmUgdGhlc2UgbWFwcGVkPw0K PiBFcXVhbGx5IGltcG9ydGFudGx5LCB3aGljaCBzaWRlIGlzIEFjdGl2ZT8NCj4gQW5kIHdoYXQg aWYgdGhlcmXigJlzIGEgcmFjZSBjb25kaXRpb24gd2l0aCBib3RoIHNpZGVzIGJlaW5nIEFjdGl2 ZSBhbmQgc2V0dGluZyB1cCByZWR1bmRhbnQgc2Vzc2lvbnM/DQo+DQo+IDEuYi4gQnkgdGhlIHdh eSwgYmFzZWQgb24gdGhpcywgdXNpbmcgUy1CRkQgW1JGQyA3ODgwXSBtaWdodCBiZSBlYXNpZXIg dG8gZGVtdXguDQo+DQo+DQo+IDIuIFNlY3VyaXR5DQo+DQo+IFRoaXMgZG9jdW1lbnQgc2F5cyB0 aGF0IHRoZSBUVEwgaW4gdGhlIGlubmVyIHBhY2tldCBjYXJyeWluZyBCRkQgaXMgc2V0IHRvIDEu IEhvd2V2ZXIsIFJGQyA1ODgwIHNheXMgdG8gdXNlIEdUU00gW1JGQyA1MDgyXSwgaS5lLiwgYSB2 YWx1ZSBvZiAyNTUuLg0KPg0KPiBXaHkgaXMgR1RTTSBub3QgdXNlZCBoZXJlPw0KPg0KPg0KPiAz LiBFQ01QIGFuZCBmYXRlLXNoYXJpbmcgdW5kZXItc3BlY2lmaWNhdGlvbjoNCj4NCj4gU2VjdGlv biA0LjEuIHNheXM6DQo+DQo+ICAgIFRoZSBPdXRlciBJUC9VRFANCj4gICAgYW5kIFZYTEFOIGhl YWRlcnMgTVVTVCBiZSBlbmNvZGVkIGJ5IHRoZSBzZW5kZXIgYXMgZGVmaW5lZCBpbg0KPiAgICBb UkZDNzM0OF0uDQo+DQo+DQo+IEFuZCBSRkMgNzM0OCBzYXlzOg0KPg0KPiAgICAgICAtICBTb3Vy Y2UgUG9ydDogIEl0IGlzIHJlY29tbWVuZGVkIHRoYXQgdGhlIFVEUCBzb3VyY2UgcG9ydCBudW1i ZXINCj4gICAgICAgICAgYmUgY2FsY3VsYXRlZCB1c2luZyBhIGhhc2ggb2YgZmllbGRzIGZyb20g dGhlIGlubmVyIHBhY2tldCAtLQ0KPiAgICAgICAgICBvbmUgZXhhbXBsZSBiZWluZyBhIGhhc2gg b2YgdGhlIGlubmVyIEV0aGVybmV0IGZyYW1lJ3MgaGVhZGVycy4NCj4gICAgICAgICAgVGhpcyBp cyB0byBlbmFibGUgYSBsZXZlbCBvZiBlbnRyb3B5IGZvciB0aGUgRUNNUC9sb2FkLQ0KPiAgICAg ICAgICBiYWxhbmNpbmcgb2YgdGhlIFZNLXRvLVZNIHRyYWZmaWMgYWNyb3NzIHRoZSBWWExBTiBv dmVybGF5Lg0KPiAgICAgICAgICBXaGVuIGNhbGN1bGF0aW5nIHRoZSBVRFAgc291cmNlIHBvcnQg bnVtYmVyIGluIHRoaXMgbWFubmVyLCBpdA0KPiAgICAgICAgICBpcyBSRUNPTU1FTkRFRCB0aGF0 IHRoZSB2YWx1ZSBiZSBpbiB0aGUgZHluYW1pYy9wcml2YXRlIHBvcnQNCj4gICAgICAgICAgcmFu Z2UgNDkxNTItNjU1MzUgW1JGQzYzMzVdLg0KPg0KPg0KPiBCYXNlZCBvbiB0aGlzLCBkZXBlbmRp bmcgb24gdGhlIGhhc2hpbmcgY2FsY3VsYXRpb24sIHRoZSBvdXRlciBzb3VyY2UgVURQIHBvcnQg Y2FuIGJlIGRpZmZlcmVudCBsZWFkaW5nIHRvIGRpZmZlcmVudCBFQ01QIHRyZWF0bWVudC4gRG9l cyBzb21ldGhpbmcgZWxzZSBuZWVkIHRvIGJlIHNwZWNpZmllZCBoZXJlIGluIHJlZ2FyZHMgdG8g dGhlIG91dGVyIFVEUCBzb3VyY2UgcG9ydD8NCj4NCj4NCj4gNC4gU2VjdGlvbiA3IHNheXMgdGhh dCDigJwgU3VwcG9ydCBmb3IgZWNobyBCRkQgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBk b2N1bWVudOKAnS4NCj4NCj4gQXNzdW1pbmcgdGhpcyBtZWFucyDigJxCRkQgRWNobyBtb2Rl4oCd LCB3aHkgaXMgdGhpcyBvdXQgb2Ygc2NvcGU/IElmIHRoaXMgaXMgYSBzaW5nbGUgbG9naWNhbCBo b3AgdW5kZXJuZWF0aCBWWExBTiwgd2hhdOKAmXMgcHJldmVudGluZyB0aGUgdXNlIG9mIEVjaG8/ IEVjaG/igJlzIGJlbmVmaXRzIGFyZSBodWdlLg0KPg0KPg0KPiA1LiBUZXJtaW5vbG9neQ0KPg0K PiAgICBJbXBsZW1lbnRhdGlvbnMgU0hPVUxEIGVuc3VyZSB0aGF0IHRoZSBCRkQNCj4gICAgcGFj a2V0cyBmb2xsb3cgdGhlIHNhbWUgbG9va3VwIHBhdGggYXMgVlhMQU4gZGF0YSBwYWNrZXRzIHdp dGhpbiB0aGUNCj4gICAgc2VuZGVyIHN5c3RlbS4NCj4NCj4gV2hhdCBpcyBhIOKAnGxvb2sgdXAg cGF0aCB3aXRoaW4gYSBzZW5kZXIgc3lzdGVt4oCdPw0KPg0KPg0KPiA2LiBEZXBsb3ltZW50IHNj ZW5hcmlvcw0KPg0KPiBTMyBzYXlzOg0KPiAgICBGaWd1cmUgMSBpbGx1c3RyYXRlcyB0aGUgc2Nl bmFyaW8gd2l0aCB0d28gc2VydmVycywgZWFjaCBvZiB0aGVtDQo+ICAgIGhvc3RpbmcgdHdvIFZN cy4gIFRoZSBzZXJ2ZXJzIGhvc3QgVlRFUHMgdGhhdCB0ZXJtaW5hdGUgdHdvIFZYTEFODQo+IFvi gKZdDQo+ICAgICAgICAgICAgICAgICAgICAgIEZpZ3VyZSAxOiBSZWZlcmVuY2UgVlhMQU4gRG9t YWluDQo+DQo+DQo+IEhvd2V2ZXIsIFJGQyA3MzQ4IEZpZ3VyZSAzIGxpc3RzIHRoYXQgYXMgb25l IGRlcGxveW1lbnQgc2NlbmFyaW8sIG5vdCBhcyDigJx0aGUgc2NlbmFyaW/igJ0gYW5kIOKAnFRo ZSBSZWZlcmVuY2UgVlhMQU4gRG9tYWlu4oCdLg0KPg0KPiBCZXN0LA0KPg0KPiBDYXJsb3MuDQo+ DQo+PiBPbiBKdW4gMTcsIDIwMTksIGF0IDEyOjU4IEFNLCBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJz a3lAZ21haWwuY29tPG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+PiB3cm90ZToNCj4+DQo+ PiBIaSBPbGl2ZXIsDQo+PiB0aGFuayB5b3UgZm9yIHlvdXIgdGhvcm91Z2ggcmV2aWV3LCBjbGVh ciBhbmQgZGV0YWlsZWQgcXVlc3Rpb25zLiBNeSBhcG9sb2dpZXMgZm9yIHRoZSBkZWxheSB0byBy ZXNwb25kLiBQbGVhc2UgZmluZCBteSBhbnN3ZXJzIGJlbG93IGluLWxpbmUgdGFnZ2VkIEdJTT4+ Lg0KPj4NCj4+IFJlZ2FyZHMsDQo+PiBHcmVnDQo+Pg0KPj4gT24gRnJpLCBNYXkgMzEsIDIwMTkg YXQgMTI6MzggUE0gT2xpdmllciBCb25hdmVudHVyZSB2aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlA aWV0Zi5vcmc8bWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmc+PiB3cm90ZToNCj4+IFJldmlld2VyOiBP bGl2aWVyIEJvbmF2ZW50dXJlDQo+PiBSZXZpZXcgcmVzdWx0OiBSZWFkeSB3aXRoIElzc3Vlcw0K Pj4NCj4+IFRoaXMgZG9jdW1lbnQgaGFzIGJlZW4gcmV2aWV3ZWQgYXMgcGFydCBvZiB0aGUgdHJh bnNwb3J0IGFyZWEgcmV2aWV3IHRlYW0ncw0KPj4gb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGtl eSBJRVRGIGRvY3VtZW50cy4gVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuDQo+PiBwcmltYXJp bHkgZm9yIHRoZSB0cmFuc3BvcnQgYXJlYSBkaXJlY3RvcnMsIGJ1dCBhcmUgY29waWVkIHRvIHRo ZSBkb2N1bWVudCdzDQo+PiBhdXRob3JzIGFuZCBXRyB0byBhbGxvdyB0aGVtIHRvIGFkZHJlc3Mg YW55IGlzc3VlcyByYWlzZWQgYW5kIGFsc28gdG8gdGhlIElFVEYNCj4+IGRpc2N1c3Npb24gbGlz dCBmb3IgaW5mb3JtYXRpb24uDQo+Pg0KPj4gV2hlbiBkb25lIGF0IHRoZSB0aW1lIG9mIElFVEYg TGFzdCBDYWxsLCB0aGUgYXV0aG9ycyBzaG91bGQgY29uc2lkZXIgdGhpcw0KPj4gcmV2aWV3IGFz IHBhcnQgb2YgdGhlIGxhc3QtY2FsbCBjb21tZW50cyB0aGV5IHJlY2VpdmUuIFBsZWFzZSBhbHdh eXMgQ0MNCj4+IHRzdi1hcnRAaWV0Zi5vcmc8bWFpbHRvOnRzdi1hcnRAaWV0Zi5vcmc+IGlmIHlv dSByZXBseSB0byBvciBmb3J3YXJkIHRoaXMgcmV2aWV3Lg0KPj4NCj4+IEkgaGF2ZSBvbmx5IGxp bWl0ZWQga25vd2xlZGdlIG9mIFZYTEFOIGFuZCBkbyBub3Qga25vdyBhbGwgc3VidGxldGllcyBv ZiBCRkQuDQo+PiBUaGlzIHJldmlldyBpcyB0aHVzIG1vcmUgZnJvbSBhIGdlbmVyYWxpc3QgdGhh biBhIHNwZWNpYWxpc3QgaW4gdGhpcyB0b3BpYy4NCj4+DQo+PiBNYWpvciBpc3N1ZXMNCj4+DQo+ PiBTZWN0aW9uIDQgcmVxdWlyZXMgdGhhdCAiIEltcGxlbWVudGF0aW9ucyBTSE9VTEQgZW5zdXJl IHRoYXQgdGhlIEJGRA0KPj4gICAgcGFja2V0cyBmb2xsb3cgdGhlIHNhbWUgbG9va3VwIHBhdGgg YXMgVlhMQU4gZGF0YSBwYWNrZXRzIHdpdGhpbiB0aGUNCj4+ICAgIHNlbmRlciBzeXN0ZW0uIg0K Pj4NCj4+IFdoeSBpcyB0aGlzIHJlcXVpcmVtZW50IG9ubHkgcmVsZXZhbnQgZm9yIHRoZSBsb29r dXAgcGF0aCBvbiB0aGUgc2VuZGVyIHN5c3RlbQ0KPj4gPyBXaGF0IGRvZXMgdGhpcyBzZW50ZW5j ZSByZWFsbHkgaW1wbGllcyA/DQo+PiBHSU0+PiBSRkMgNTg4MCBzZXQgdGhlIHNjb3BlIG9mIHRo ZSBmYXVsdCBkZXRlY3Rpb24gb2YgQkZEIHByb3RvY29sIGFzDQo+PiAgICAuLi4gdGhlIGJpZGly ZWN0aW9uYWwgcGF0aCBiZXR3ZWVuIHR3byBmb3J3YXJkaW5nIGVuZ2luZXMsIGluY2x1ZGluZw0K Pj4gICAgaW50ZXJmYWNlcywgZGF0YSBsaW5rKHMpLCBhbmQgdG8gdGhlIGV4dGVudCBwb3NzaWJs ZSB0aGUgZm9yd2FyZGluZw0KPj4gICAgZW5naW5lcyB0aGVtc2VsdmVzIC4uLg0KPj4gVGhlIHJl cXVpcmVtZW50IGFpbWVkIHRvIHRoZSBmb3J3YXJkaW5nIGVuZ2luZSBvZiBhIEJGRCBzeXN0ZW0g dGhhdCB0cmFuc21pdHMgQkZEIGNvbnRyb2wgcGFja2V0cyBvdmVyIFZYTEFOIHR1bm5lbC4NCj4+ DQo+PiBJcyBpdCBhIHJlcXVpcmVtZW50IHRoYXQgdGhlIEJGRCBwYWNrZXRzIGZvbGxvdyB0aGUg c2FtZSBwYXRoIGFzIHRoZSBkYXRhDQo+PiBwYWNrZXQgZm9yIGEgZ2l2ZW4gVlhMQU4gPyBJIGd1 ZXNzIHNvLiBJbiB0aGlzIGNhc2UsIHRoZSBkb2N1bWVudCBzaG91bGQNCj4+IGRpc2N1c3MgaG93 IEVxdWFsIENvc3QgTXVsdGlwYXRoIGNvdWxkIGFmZmVjdCB0aGlzLg0KPj4gR0lNPj4gSSB0aGlu ayB0aGF0IEVDTVAgZW52aXJvbm1lbnQgaXMgbW9yZSBsaWtlbHkgdG8gYmUgZXhwZXJpZW5jZWQg YnkgYSB0cmFuc2l0IG5vZGUgaW4gdGhlIHVuZGVybGF5LiBJZiB0aGUgQkZEIHNlc3Npb24gaXMg dXNlZCB0byBtb25pdG9yIHRoZSBzcGVjaWZpYyB1bmRlcmxheSBwYXRoLCB0aGVuLCBJIGFncmVl LCB3ZSBzaG91bGQgZXhwbGFpbiB0aGF0IHVzaW5nIHRoZSBWWExBTiBwYXlsb2FkIGluZm9ybWF0 aW9uIHRvIGRyYXcgcGF0aCBlbnRyb3B5IG1heSBjYXVzZSBkYXRhIGFuZCBCRkQgcGFja2V0cyBm b2xsb3dpbmcgZGlmZmVyZW50IHVuZGVybGF5IHJvdXRlcy4gQnV0LCBvbiB0aGUgb3RoZXIgaGFu ZCwgdGhhdCBpcyB0aGUgY2FzZSBmb3IgT0FNIGFuZCBmYXVsdCBkZXRlY3Rpb24gaW4gYWxsIG92 ZXJsYXkgbmV0d29ya3MgaW4gZ2VuZXJhbC4NCj4+DQo+PiBNaW5vciBpc3N1ZXMNCj4+DQo+PiBT ZWN0aW9uIDENCj4+DQo+PiBZb3Ugd3JpdGUgIlRoZSBhc3luY2hyb25vdXMgbW9kZSBvZiBCRkQs IGFzIGRlZmluZWQgaW4gW1JGQzU4ODBdLA0KPj4gIGNhbiBiZSB1c2VkIHRvIG1vbml0b3IgYSBw MnAgVlhMQU4gdHVubmVsLiINCj4+DQo+PiBXaHkgZG8geW91IHVzZSB0aGUgd29yZCBjYW4gPyBJ dCBpcyBhIHBvc3NpYmlsaXR5IG9yIGEgcmVxdWlyZW1lbnQgPw0KPj4gR0lNPj4gSW4gcHJpbmNp cGxlLCBCRkQgRGVtYW5kIG1vZGUgbWF5IGJlIHVzZWQgdG8gbW9uaXRvciBwMnAgcGF0aHMgYXMg d2VsbCwgSSBhZ3JlZSwgd2lsbCByZS13b3JkIHRvIG1vcmUgYXNzZXJ0aXZlOg0KPj4gIFRoZSBh c3luY2hyb25vdXMgbW9kZSBvZiBCRkQsIGFzIGRlZmluZWQgaW4gW1JGQzU4ODBdLA0KPj4gIGlz IHVzZWQgdG8gbW9uaXRvciBhIHAycCBWWExBTiB0dW5uZWwuDQo+Pg0KPj4gTlZFIGhhcyBub3Qg YmVlbiBkZWZpbmVkIGJlZm9yZSBhbmQgaXMgbm90IGluIHRoZSB0ZXJtaW5vbG9neS4NCj4+IEdJ TT4+IFdpbGwgYWRkIHRvIHRoZSBUZXJtaW5vbG9neSBhbmQgZXhwYW5kIGFzOg0KPj4gTlZFICAg ICAgICBOZXR3b3JrIFZpcnR1YWxpemF0aW9uIEVuZHBvaW50DQo+Pg0KPj4gVGhpcyBlbnRpcmUg c2VjdGlvbiBpcyBub3QgZWFzeSB0byByZWFkIGZvciBhbiBvdXRzaWRlci4NCj4+DQo+PiBTZWN0 aW9uIDMNCj4+DQo+PiBWTkkgaGFzIG5vdCBiZWVuIGRlZmluZWQNCj4+IEdJTT4+IFdpbGwgYWRk IHRvIHRoZSBUZXJtaW5vbG9neSBzZWN0aW9uOg0KPj4gVk5JICAgIFZYTEFOIE5ldHdvcmsgSWRl bnRpZmllciAob3IgVlhMQU4gU2VnbWVudCBJRCkNCj4+DQo+PiBGaWd1cmUgMSBjb3VsZCB0YWtl IGxlc3Mgc3BhY2UNCj4+IEdJTT4+IFllcywgY2FuIG1ha2UgaXQgYml0IGRlbnNlci4gV291bGQg dGhlIGZvbGxvd2luZyBiZSBhbiBpbXByb3ZlbWVudD8NCj4+DQo+PiAgICAgICArLS0tLS0tLS0t LS0tKy0tLS0tLS0tLS0tLS0rDQo+PiAgICAgICB8ICAgICAgICBTZXJ2ZXIgMSAgICAgICAgICB8 DQo+PiAgICAgICB8ICstLS0tKy0tLS0rICArLS0tLSstLS0tKyB8DQo+PiAgICAgICB8IHxWTTEt MSAgICB8ICB8Vk0xLTIgICAgfCB8DQo+PiAgICAgICB8IHxWTkkgMTAwICB8ICB8Vk5JIDIwMCAg fCB8DQo+PiAgICAgICB8IHwgICAgICAgICB8ICB8ICAgICAgICAgfCB8DQo+PiAgICAgICB8ICst LS0tLS0tLS0rICArLS0tLS0tLS0tKyB8DQo+PiAgICAgICB8IEh5cGVydmlzb3IgVlRFUCAoSVAx KSAgICB8DQo+PiAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+PiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg ICArLS0tLS0tLS0tLS0tLSsNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgfCAg IExheWVyIDMgICB8DQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLXwgICBOZXR3 b3JrICAgfA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0t LSsNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4+ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLSsNCj4+ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKw0K Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIEh5cGVydmlz b3IgVlRFUCAoSVAyKSB8DQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwgKy0tLS0rLS0tLSsgICstLS0tKy0tLS0rIHwNCj4+ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCB8Vk0yLTEgICAgfCAgfFZNMi0yICAgIHwgfA0KPj4gICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHxWTkkgMTAwICB8ICB8Vk5J IDIwMCAgfCB8DQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg fCAgICAgICAgIHwgIHwgICAgICAgICB8IHwNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgfCArLS0tLS0tLS0tKyAgKy0tLS0tLS0tLSsgfA0KPj4gICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgU2VydmVyIDIgICAgICAgICAg ICB8DQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+DQo+Pg0KPj4gU2VjdGlvbiA0DQo+Pg0KPj4gSSBkbyBu b3Qgc2VlIHRoZSBiZW5lZml0cyBvZiBoYXZpbmcgb25lIHBhcmFncmFwaCBpbiBTZWN0aW9uIDQg Zm9sbG93ZWQgYnkgb25seQ0KPj4gU2VjdGlvbiA0LjENCj4+IEdJTT4+IFdpbGwgbWVyZ2UgU2Vj dGlvbiA0LjEgaW50byA0IHdpdGggbWlub3IgcmVxdWlyZWQgcmUtd29yZGluZzoNCj4+IDQuICBC RkQgUGFja2V0IFRyYW5zbWlzc2lvbiBvdmVyIFZYTEFOIFR1bm5lbA0KPj4NCj4+ICAgIEJGRCBw YWNrZXQgTVVTVCBiZSBlbmNhcHN1bGF0ZWQgYW5kIHNlbnQgdG8gYSByZW1vdGUgVlRFUCBhcw0K Pj4gICAgZXhwbGFpbmVkIGluIHRoaXMgc2VjdGlvbi4gIEltcGxlbWVudGF0aW9ucyBTSE9VTEQg ZW5zdXJlIHRoYXQgdGhlDQo+PiAgICBCRkQgcGFja2V0cyBmb2xsb3cgdGhlIHNhbWUgbG9va3Vw IHBhdGggYXMgVlhMQU4gZGF0YSBwYWNrZXRzIHdpdGhpbg0KPj4gICAgdGhlIHNlbmRlciBzeXN0 ZW0uDQo+Pg0KPj4gICAgQkZEIHBhY2tldHMgYXJlIGVuY2Fwc3VsYXRlZCBpbiBWWExBTiBhcyBk ZXNjcmliZWQgYmVsb3cuICBUaGUgVlhMQU4NCj4+ICAgIHBhY2tldCBmb3JtYXQgaXMgZGVmaW5l ZCBpbiBTZWN0aW9uIDUgb2YgW1JGQzczNDhdLiAgVGhlIE91dGVyIElQL1VEUA0KPj4gICAgYW5k IFZYTEFOIGhlYWRlcnMgTVVTVCBiZSBlbmNvZGVkIGJ5IHRoZSBzZW5kZXIgYXMgZGVmaW5lZCBp bg0KPj4gICAgW1JGQzczNDhdLg0KPj4NCj4+IFNlY3Rpb24gNC4xDQo+Pg0KPj4gVGhlIGRvY3Vt ZW50IGRvZXMgbm90IHNwZWNpZnkgd2hlbiBhIGRlZGljYXRlZCBNQUMgYWRkcmVzcyBvciB0aGUg TUFDIGFkZHJlc3MNCj4+IG9mIHRoZSBkZXN0aW5hdGlvbiBWVEVQIG11c3QgYmUgdXNlZC4gVGhp cyBjb3VsZCBhZmZlY3QgdGhlIGludGVyb3BlcmFiaWxpdHkgb2YNCj4+IGltcGxlbWVudGF0aW9u cy4gU2hvdWxkIGFsbCBpbXBsZW1lbnRhdGlvbnMgc3VwcG9ydCBib3RoIHRoZSBkZWRpY2F0ZWQg TUFDDQo+PiBhZGRyZXNzIGFuZCB0aGUgZGVzdGluYXRpb24gTUFDIGFkZHJlc3MgPw0KPj4gR0lN Pj4gQWZ0ZXIgZnVydGhlciBkaXNjdXNzaW9uLCBhdXRob3JzIGRlY2lkZWQgdG8gcmVtb3ZlIHRo ZSByZXF1ZXN0IGZvciB0aGUgZGVkaWNhdGVkIE1BQyBhZGRyZXNzIGFsbG9jYXRpb24uIE9ubHkg dGhlIE1BQyBhZGRyZXNzIG9mIHRoZSByZW1vdGUgVlRFUCBtdXN0IGJlIHVzZWQgYXMgdGhlIGRl c3RpbmF0aW9uIE1BQyBhZGRyZXNzIGluIHRoZSBpbm5lciBFdGhlcm5ldCBmcmFtZS4gUGxlYXNl IGNoZWNrIHRoZSBhdHRhY2hlZCBkaWZmIGJldHdlZW4gdGhlIC0wNyBhbmQgdGhlIHdvcmtpbmcg dmVyc2lvbnMgb3IgdGhlIHdvcmtpbmcgdmVyc2lvbiBvZiB0aGUgZHJhZnQuDQo+Pg0KPj4gSXQg aXMgdW5jbGVhciBmcm9tIHRoaXMgc2VjdGlvbiB3aGV0aGVyIElQdjQgaW5zaWRlIElQdjYgYW5k IHRoZSBvcHBvc2l0ZQ0KPj4gc2hvdWxkIGJlIHN1cHBvcnRlZCBvciBub3QuDQo+PiBHSU0+PiBB bnkgY29tYmluYXRpb24gb2Ygb3V0ZXIgSVB2WCBhbmQgaW5uZXIgSVB2WCBpcyBwb3NzaWJsZS4N Cj4+DQo+PiBTZWN0aW9uIDUuDQo+Pg0KPj4gSWYgdGhlIHJlY2VpdmVkIHBhY2tldCBkb2VzIG5v dCBtYXRjaCB0aGUgZGVkaWNhdGVkIE1BQyBhZGRyZXNzIG5vciB0aGUgTUFDDQo+PiBhZGRyZXNz IG9mIHRoZSBWVEVQLCBzaG91bGQgdGhlIHBhY2tldCBiZSBzaWxlbnRseSBkaXNjYXJkZWQgb3Ig dHJlYXRlZA0KPj4gZGlmZmVyZW50bHkgPw0KPj4gR0lNPj4gQXMgSSd2ZSBtZW50aW9uZWQgZWFy bGllciwgYXV0aG9ycyBoYXZlIGRlY2lkZWQgdG8gcmVtb3ZlIHRoZSB1c2Ugb2YgdGhlIGRlZGlj YXRlZCBNQUMgYWRkcmVzcyBmb3IgQkZEIG92ZXIgVlhMQU4uDQo+Pg0KPj4gU2VjdGlvbiA1LjEN Cj4+DQo+PiBJcyB0aGlzIGEgbW9kaWZpY2F0aW9uIHRvIHNlY3Rpb24gNi4zIG9mIFJGQzU4ODAg PyBUaGlzIGlzIG5vdCBjbGVhcg0KPj4gR0lNPj4gSSB0aGluayB0aGF0IHRoaXMgc2VjdGlvbiBp cyBub3QgbW9kaWZpY2F0aW9uIGJ1dCB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgYXBwbGljYXRpb24t c3BlY2lmaWMgcHJvY2VkdXJlIHRoYXQgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgUkZDIDU4ODA6 DQo+PiAgICBUaGUgbWV0aG9kIG9mIGRlbXVsdGlwbGV4aW5nIHRoZSBpbml0aWFsIHBhY2tldHMg KGluIHdoaWNoIFlvdXINCj4+ICAgIERpc2NyaW1pbmF0b3IgaXMgemVybykgaXMgYXBwbGljYXRp b24gZGVwZW5kZW50LCBhbmQgaXMgdGh1cyBvdXRzaWRlDQo+PiAgICB0aGUgc2NvcGUgb2YgdGhp cyBzcGVjaWZpY2F0aW9uLg0KPj4NCj4+IFNlY3Rpb24gOQ0KPj4NCj4+IFRoZSBzZW50ZW5jZSAi IFRocm90dGxpbmcgTUFZIGJlIHJlbGF4ZWQgZm9yIEJGRCBwYWNrZXRzDQo+PiAgICBiYXNlZCBv biBwb3J0IG51bWJlci4iIGlzIHVuY2xlYXIuDQo+PiBHSU0+PiBZZXMsIHRoYW5rIHlvdSBmb3Ig cG9pbnRpbmcgdG8gdGhpcy4gVGhlIHVwZGF0ZWQgdGV4dCwgaW4gdGhlIHdob2xlIHBhcmFncmFw aCwgaXMgYXMgZm9sbG93czoNCj4+IE5FVyBURVhUOg0KPj4gICAgVGhlIGRvY3VtZW50IHJlcXVp cmVzIHNldHRpbmcgdGhlIGlubmVyIElQIFRUTCB0byAxLCB3aGljaCBjb3VsZCBiZQ0KPj4gICAg dXNlZCBhcyBhIEREb1MgYXR0YWNrIHZlY3Rvci4gIFRodXMgdGhlIGltcGxlbWVudGF0aW9uIE1V U1QgaGF2ZQ0KPj4gICAgdGhyb3R0bGluZyBpbiBwbGFjZSB0byBjb250cm9sIHRoZSByYXRlIG9m IEJGRCBjb250cm9sIHBhY2tldHMgc2VudA0KPj4gICAgdG8gdGhlIGNvbnRyb2wgcGxhbmUuICBP biB0aGUgb3RoZXIgaGFuZCwgb3ZlciBhZ2dyZXNzaXZlIHRocm90dGxpbmcNCj4+ICAgIG9mIEJG RCBjb250cm9sIHBhY2tldHMgbWF5IGJlY29tZSB0aGUgY2F1c2Ugb2YgdGhlIGluYWJpbGl0eSB0 byBmb3JtDQo+PiAgICBhbmQgbWFpbnRhaW4gQkZEIHNlc3Npb24gYXQgc2NhbGUuICBIZW5jZSwg dGhyb3R0bGluZyBvZiBCRkQgY29udHJvbA0KPj4gICAgcGFja2V0cyBTSE9VTEQgYmUgYWRqdXN0 ZWQgdG8gcGVybWl0IEJGRCB0byB3b3JrIGFjY29yZGluZyB0byBpdHMNCj4+ICAgIHByb2NlZHVy ZXMuDQo+PiA8ZHJhZnQtaWV0Zi1iZmQtdnhsYW4tMDgudHh0PjxEaWZmXyBkcmFmdC1pZXRmLWJm ZC12eGxhbi0wNy50eHQgLSBkcmFmdC1pZXRmLWJmZC12eGxhbi0wOC50eHQuaHRtbD4NCj4NCg0K DQo= --_000_0B9FDA177F134FECAE9740BC9D72C87Bciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <850BD10CCC9F854D968834FE68367276@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhlbGxvLCBHcmVnLA0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+UGxlYXNlIHNlZSBpbmxpbmUuPGJy IGNsYXNzPSIiPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gSnVuIDE5LCAyMDE5LCBhdCA5OjU4IFBNLCBHcmVn IE1pcnNreSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbSIgY2xhc3M9 IiI+Z3JlZ2ltaXJza3lAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9 IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJs dHIiIGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+SGVsbG8gQ2FybG9zLA0KPGRp diBjbGFzcz0iIj50aGFuayB5b3UgZm9yIHRoZSBleHBlZGllbnQgY2xhcmlmaWNhdGlvbi48L2Rp dj4NCjxkaXYgY2xhc3M9IiI+VG8geW91ciZuYnNwO3F1ZXN0aW9ucyBvbiBkZW11bHRpcGxleGlu ZyBCRkQgY29udHJvbCBwYWNrZXRzIHdpdGggdGhlIHplcm8gdmFsdWUgb2YgdGhlIFlvdXIgRGlz Y3JpbWluYXRvciBmaWVsZDo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8dWwgY2xhc3M9IiI+DQo8 bGkgY2xhc3M9IiI+b25seSBCRkQgY29udHJvbCBwYWNrZXRzIHdpdGggdGhlIHplcm8gdmFsdWUg b2YgdGhlIFlvdXIgRGlzY3JpbWluYXRvciBmaWVsZCBhcmUgZGVtdWx0aXBsZXhlZCB1c2luZyB0 aGUgaW5mb3JtYXRpb24gb2YgdGhlIGlubmVyIElQIGhlYWRlci4gSSBiZWxpZXZlIHRoYXQgdGhl IHRleHQgaXMgY2xlYXIgYW5kIHJlcXVpcmVzIHRoYXQgYWxsIGZpZWxkcyBvZiB0aGUgaW5uZXIg SVAgaGVhZGVyIG11c3QgYmUgdXNlZCB0byBkZW11bHRpcGxleA0KIGEgcmVjZWl2ZWQgQkZEIGNv bnRyb2wgcGFja2V0IHdpdGggdGhlIHplcm8gdmFsdWUgaW4gdGhlIFlvdXIgRGlzY3JpbWluYXRv ciBmaWVsZC4gV2hpY2ggb2YgdGhlIGZpZWxkcyBhbiBpbXBsZW1lbnRhdGlvbiB1c2VzIHRvIGNy ZWF0ZSBtdWx0aXBsZSBCRkQgc2Vzc2lvbnMgYmV0d2VlbiB0aGUgcGFpciBvZiBWVEVQcyBpcyBp bXBsZW1lbnRhdGlvbiBzcGVjaWZpYy48L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+VGhpcyB0ZXh0IGlzIHJlcGVhdGluZyB3YXMg aXMgaW4gdGhlIGRyYWZ0LCBidXQgZG9lcyBub3QgYW5zd2VyIGFueSBvZiBteSBxdWVzdGlvbnMu PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5Gb3IgZXhhbXBsZTo8L2Rp dj4NCjxkaXY+MS4gJnF1b3Q7dGhhdCBhbGwgZmllbGRzIG9mIHRoZSBpbm5lciBJUCBoZWFkZXIg bXVzdCBiZSB1c2VkIHRvIGRlbXVsdGlwbGV4IGEgcmVjZWl2ZWQgQkZEIGNvbnRyb2wgcGFja2V0 4oCdPC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDsgLSZndDsgVGhlIHRleHQgZG9lcyBub3Qgc2F5 IOKAnGFsbCBmaWVsZHPigJ0sIGJ1dCByZWdhcmRsZXNzLCBkbyB5b3UgbWVhbiB0aGUgRFNDUCBh bmQgdGhlIEV2aWwgQml0PyBJUHY2IEZsb3cgTGFiZWw/IEhvdyAqZXhhY3RseSo/PC9kaXY+DQo8 ZGl2PjIuIEhvdyBpcyB0aGUgbWFwcGluZyBvZiBJUCAobm90IFVEUD8pIGZpZWxkcyB0byBCRkQg c2Vzc2lvbiBkb25lPzwvZGl2Pg0KPGRpdj4zLiBIb3cgaXMgdGhpcyBzdGF0ZSBjcmVhdGVkIGFu ZCBtYWludGFpbmVkPyZuYnNwOzwvZGl2Pg0KPGRpdj40LiBTaW5jZSB0aGlzIGlzIGEgc2V0IG9m IGZpZWxkcyBvbiB3aGljaCB0d28gc3lzdGVtcyBuZWVkIHRvIGFncmVlICh3aGljaCBmaWVsZHMg ZnJvbSB0aGUgaW5uZXIgSVAvVURQIGFyZSBtYXBwZWQgbmVlZHMgdG8gYmUgdW5kZXJzdG9vZCBi eSBib3RoIHN5c3RlbXMpLCBpdCBjYW5ub3QgYmUg4oCcaW1wbGVtZW50YXRpb24gc3BlY2lmaWPi gJ0uIEZ1cnRoZXIsIHRoZSB0ZXh0IGRvZXMgbm90IHNheSBzby48L2Rpdj4NCjxiciBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPlRvIHlvdXIgcG9pbnQgb24gdGhlIGxldmVsIEVjaG8gbW9kZSBvZiBCRkQgaXMgc3Bl Y2lmaWVkIGluIFJGQyA1ODgwIEknbGwgcXVvdGUgdGhlIG9waW5pb24gb2YgSmVmZnJleSBIYWFz IGZyb20gdGhlIGRpc2N1c3Npb24gb2YgY29tbWVudHMgZnJvbSBTaGF3biBFbWVyeSBvbiBiZWhh bGYgb2YgdGhlIFNlY0Rpci4gU2hhd24gaGFkIGNvbW1lbnRlZDo8L2Rpdj4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowIDAgMCA0MHB4O2JvcmRlcjpub25lO3BhZGRpbmc6MHB4 IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6c21hbGwiIGNsYXNzPSIiPkVjaG8gQkZEIGlzIG91dCBvZiBzY29wZSBmb3IgdGhlIGRvY3Vt ZW50LCBidXQgZG9lcyBub3QgZGVzY3JpYmUgdGhlIHJlYXNvbiBmb3IgdGhpcyBvciB3aHkgc3Rh dGU8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbjowIDAgMCA0MHB4O2JvcmRlcjpub25lO3BhZGRpbmc6MHB4IiBjbGFz cz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5 bGU9ImZvbnQtc2l6ZToxMi44cHgiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6c21h bGwiIGNsYXNzPSIiPnRoaXMgYXQgYWxsPzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQpJJ3ZlIHJlc3BvbmRlZDoNCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW46 MCAwIDAgNDBweDtib3JkZXI6bm9uZTtwYWRkaW5nOjBweCIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNz PSIiPkdJTSZndDsmZ3Q7IEkgdGhpbmsgdGhhdCB0aGUgbWFpbiByZWFzb24gaXMgdGhhdCB0aGUg QkZEIEVjaG8gbW9kZSBpcyB1bmRlcnNwZWNpZmllZC4gUkZDIDU4ODAgZGVmaW5lZCBzb21lIG9m IHRoZSBtZWNoYW5pc21zIHJlbGF0ZWQgdG8gdGhlIEVjaG8gbW9kZSwgYnV0IG1vcmUgc3RhbmRh cmRpemF0aW9uIHdvcmsgbWF5IGJlIHJlcXVpcmVkLiZuYnNwOyZuYnNwOzwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KQW5kIEplZmZyZXkgSGFhcyBoYWQgYWRkZWQ6DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luOjAgMCAwIDQwcHg7Ym9yZGVyOm5vbmU7cGFkZGluZzowcHgiIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj5TcGVha2luZyBhcyBhIEJGRCBjaGFpciwgdGhpcyBpcyB0aGUgcmVsZXZhbnQg b2JzZXJ2YXRpb24uJm5ic3A7IEJGRCBFY2hvIGlzPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPnVuZGVy c3BlY2lmaWVkIHRvIHRoZSBwb2ludCB3aGVyZSBjbGFpbWluZyBjb21wbGlhbmNlIGlzIGRpZmZp Y3VsdCBhdCBiZXN0LjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5JbiBnZW5lcmFsLCBpdCByZWxpZXMg b24gc2luZ2xlLWhvcCBhbmQgdGhlIGFiaWxpdHkgdG8gaGF2ZSB0aGUgcmVtb3RlIEVjaG88L2Rp dj4NCjxkaXYgY2xhc3M9IiI+Y2xpZW50IGxvb3AgdGhlIHBhY2tldHMuJm5ic3A7PC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXY+QkZEIEVjaG8gY2Fubm90IGJlIHNwZWNpZmllZCBpbiBSRkMg NTg4MCBiYXNlIHNwZWMgYmVjYXVzZSBpdCBpcyBhcHBsaWNhdGlvbiBzcGVjaWZpYy48L2Rpdj4N CjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbjowIDAgMCA0MHB4O2JvcmRlcjpub25lO3BhZGRpbmc6MHB4IiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoaXMgcGFja2V0 IGxvb3AgbWF5IG5vdCBiZSBwcmFjdGljYWwgZm9yIHNldmVyYWwgZW5jYXBzdWxhdGlvbnMgYW5k IHRodXMgaXM8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+b3V0IG9mIHNjb3BlIGZvciBzdWNoIGVuY2Fw c3VsYXRpb25zLiZuYnNwOyBXaGV0aGVyIHRoaXMgaXMgcHJhY3RpY2FsIGZvciB2eGxhbjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj50b2RheSwgb3IgaW4gdGhlIHByZXNlbmNlIG9mIGZ1dHVyZSBleHRl bnNpb25zIHRvIHZ4bGFuIGlzIGxlZnQgb3V0IG9mIHNjb3BlPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PmZvciB0aGUgY29yZSBwcm9wb3NhbC4mbmJzcDsmbmJzcDs8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdj5UaGUgcXVlc3Rpb24gcmVtYWluczogZm9yIFZYTEFOIGVuY2Fwc3VsYXRpb24sIHRo aXMgaXMgbGlrZSBhIHNpbmdsZSBob3AgYXMgZmFyIGFzIEJGRCBpcyBjb25jZXJuZWQgKHNpbmds ZSBob3AgVlhMQU4gdHVubmVsKS48L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2PlNpbmNlIFJGQyA1ODgxIGRlZmluZXMgRWNobyBmb3Igc2luZ2xlIGhvcCwgY2FuIHlvdSBw bGVhc2UgZWxhYm9yYXRlIChpbiB0aGUgZG9jdW1lbnQpIHdoeSBpcyBvdXQgb2Ygc2NvcGUgb3Ig aG93IGl0IGNhbiB3b3JrPzwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+ QmVzdCw8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkNhcmxvcy48L2Rp dj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbjowIDAgMCA0MHB4O2JvcmRlcjpub25lO3BhZGRpbmc6MHB4IiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQpXaWxsIHJl c3BvbmQgdG8gb3RoZXIgcXVlc3Rpb25zIGluIGEgc2VwYXJhdGUgbWFpbC4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlJlZ2FyZHMsPC9kaXY+DQo8 ZGl2IGNsYXNzPSIiPkdyZWc8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVv dGUiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0dHIiPk9uIFRodSwgSnVuIDIwLCAy MDE5IGF0IDEwOjMxIEFNIENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbSIgY2xhc3M9IiI+Y3BpZ25hdGFAY2lzY28uY29tPC9h PiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwy MDQpO3BhZGRpbmctbGVmdDoxZXgiIGNsYXNzPSJnbWFpbF9xdW90ZSI+DQpIZWxsbywgR3JlZyw8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQomZ3Q7IE9uIEp1biAxOSwgMjAxOSwgYXQgOTow OSBQTSwgR3JlZyBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5j b20iIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+Jmd0 OyB3cm90ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsgSGkgQ2FybG9z LDxiciBjbGFzcz0iIj4NCiZndDsgdGhhbmsgeW91IGZvciByZW1pbmRpbmcgb2Ygb3VyIGNvbnRp bnVlZCBkaXNjdXNzaW9uIHdpdGggSm9lbC4gV2UgYXJlIHNlZWtpbmcgY29tbWVudHMgZnJvbSBW WExBTiBleHBlcnRzIGFuZCBtdWNoIGFwcHJlY2lhdGUgaWYgeW91IGhhdmUgaW5zaWdodHMgb24g VlhMQU4gdG8gc2hhcmUuPGJyIGNsYXNzPSIiPg0KJmd0OyBJJ3ZlIGdvdCBzb21lIGNsYXJpZnlp bmcgcXVlc3Rpb25zIGJlZm9yZSBJIGNhbiByZXNwb25kIHRvIHlvdS48YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQpTdXJlLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZndDsgVG8g d2hpY2ggc3RhZ2Ugb2YgdGhlIHRocmVlLXdheSBoYW5kc2hha2UgeW91IHJlZmVyIGFzICZxdW90 O2luaXRpYWwgZGVtdWx0aXBsZXhpbmcmcXVvdDs/IEkgY291bGRuJ3QgZmluZCB0aGlzIHRlcm0g aW4gUkZDIDU4ODAuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K4oCcSW5pdGlhbCBkZW11 bHRpcGxleGluZyZxdW90OyBpcyBhIHdlbGwta25vd24gdGVybSBpbiBCRkQsIHJlZmVycmluZyB0 byB0aGUgJnF1b3Q7ZGVtdWx0aXBsZXhpbmcgb2YgdGhlIGluaXRpYWwgcGFja2V0cyZxdW90Oywg QkZEIENvbnRyb2wgcGFja2V0IHdpdGggWW91ckRpc2MgYmVpbmcgemVyby48YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpJbiBSRkMgNTg4MCwgc2VlIFNlY3Rpb24gNi4zLjxiciBjbGFzcz0i Ij4NCjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1ODgwI3NlY3Rpb24t Ni4zIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj5odHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNTg4MCNzZWN0aW9uLTYuMzwvYT48YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7VGhlIG1ldGhvZCBvZiBkZW11bHRpcGxleGluZyB0 aGUgaW5pdGlhbCBwYWNrZXRzIChpbiB3aGljaCBZb3VyPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZu YnNwO0Rpc2NyaW1pbmF0b3IgaXMgemVybykgaXMgYXBwbGljYXRpb24gZGVwZW5kZW50LCBhbmQg aXMgdGh1cyBvdXRzaWRlPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwO3RoZSBzY29wZSBvZiB0 aGlzIHNwZWNpZmljYXRpb24uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU2luY2UgaW5p dGlhbCBkZW11bHRpcGxleGluZyBpcyBpbmRlZWQgYXBwbGljYXRpb24gc3BlY2lmaWMsIGRpZmZl cmVudCBmb3Igb25lLWhvcCB2ZXJzdXMgbXVsdGktaG9wIGFuZCBkZXBlbmRlbnQgdXBvbiB3aGV0 aGVyIGEgc2luZ2xlIG9yIG11bHRpcGxlIHNlc3Npb25zIGFyZSBhbGxvd2VkIGJldHdlZW4gYSBw YWlyIG9mIGVuZHBvaW50cywgSSBhZGRlZCBiZWxvdyB0d28gb3RoZXIgcmVsZXZhbnQgY2l0YXRp b25zLCBmcm9tIGFwcGxpY2F0aW9uDQogc3BlY2lmaWMgQkZEIHNwZWNzOjxiciBjbGFzcz0iIj4N CjEuIDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1ODgzI3NlY3Rpb24t NCIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+DQpodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNTg4MyNzZWN0aW9uLTQ8L2E+IDxiciBjbGFzcz0iIj4NCjIu IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1ODgyI3NlY3Rpb24tNiIg cmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+DQpodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNTg4MiNzZWN0aW9uLTY8L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNs YXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJmd0OyBSZWdhcmRpbmcgdGhlIGFwcGxpY2FiaWxpdHkg b2YgdGhlIEVjaG8gbW9kZSwgdGhhbmsgeW91IGZvciBwb2ludGluZyB0byB0aGUgbmVlZCBmb3Ig c3RyaWN0ZXIgdGVybWlub2xvZ3ksIHRoZSBFY2hvIG1vZGUsIGFzIGRlZmluZWQgaW4gUkZDIDU4 ODAsIGlzIHVuZGVyc3BlY2lmaWVkIGFuZCBpdCB3aWxsIHJlcXVpcmUgYWRkaXRpb25hbCBzdGFu ZGFyZGl6YXRpb24uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KTm8uIEJGRCBFY2hvIGlz IG5vdCB1bmRlcnNwZWNpZmllZCBpbiBSRkMgNTg4MC48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9 IiI+DQpQbGVhc2UgcmVhZCBTNTogPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzU4ODAjc2VjdGlvbi01IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFz cz0iIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1ODgwI3NlY3Rpb24tNTwvYT48 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7QkZEIEVjaG8gcGFja2V0 cyBhcmUgc2VudCBpbiBhbiBlbmNhcHN1bGF0aW9uIGFwcHJvcHJpYXRlIHRvIHRoZTxiciBjbGFz cz0iIj4NCiZuYnNwOyAmbmJzcDtlbnZpcm9ubWVudC4mbmJzcDsgU2VlIHRoZSBhcHByb3ByaWF0 ZSBhcHBsaWNhdGlvbiBkb2N1bWVudHMgZm9yIHRoZTxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJz cDtzcGVjaWZpY3Mgb2YgcGFydGljdWxhciBlbnZpcm9ubWVudHMuPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQkZEIEVjaG8gaXMgYXBwbGljYXRpb24gZGVwZW5k ZW50LiA8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGVyZWZvcmUsIGZvciBleGFtcGxl LCBzaW5nbGUtaG9wIEJGRCBpbiBSRkMgNTg4MSBzcGVjaWZpZXMgQkZEIEVjaG8gZm9yIHRoYXQg YXBwbGljYXRpb24uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSGVuY2UsIG15IHF1ZXN0 aW9uIHN0YW5kczogd2h5IGlzIHRoaXMgZHJhZnQgY2xhaW1pbmcgQkZEIEVjaG8gaXMgb3V0IG9m IHNjb3BlIGZvciB0aGlzIEJGRCBhcHBsaWNhdGlvbiBkb2N1bWVudD88YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQomZ3Q7IEZ1dHVyZSBkcmFmdHMgbWF5IGV4cGxv cmUgYW5kIGRlZmluZSBob3cgdGhlIEVjaG8gbW9kZSBvZiBCRkQgaXMgdXNlZCBvdmVyIFZYTEFO IHR1bm5lbHMuPGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpTZWUgYWJvdmUuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJmd0OyBXaWxsIHJldmll dyBhbmQgcmVzcG9uZCB0byB0aGUgcmVtYWluaW5nIHF1ZXN0aW9ucyBzb29uLjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NClRoYW5rIHlvdS4gPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIi Pg0KVGhlICZxdW90O3JlbWFpbmluZyBxdWVzdGlvbnMmcXVvdDsgYXJlIHN0aWxsIGFsbCB0aGUg cXVlc3Rpb25zIGJlbG93IDotKTxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkJlc3QsPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQ2FybG9zLjxiciBjbGFzcz0iIj4NCjxiciBjbGFz cz0iIj4NCiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyBSZWdhcmRzLDxiciBjbGFzcz0iIj4NCiZn dDsgR3JlZzxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9 IiI+DQomZ3Q7IE9uIFRodSwgSnVuIDIwLCAyMDE5IGF0IDk6MTQgQU0gQ2FybG9zIFBpZ25hdGFy byAoY3BpZ25hdGEpICZsdDs8YSBocmVmPSJtYWlsdG86Y3BpZ25hdGFAY2lzY28uY29tIiB0YXJn ZXQ9Il9ibGFuayIgY2xhc3M9IiI+Y3BpZ25hdGFAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PGJy IGNsYXNzPSIiPg0KJmd0OyBIaSw8YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZn dDsgSSBoYXZlIG5vdCByZXZpZXdlZCB0aGlzIGRyYWZ0IGJlZm9yZSwgYnV0IHRyaWdnZXJlZCBi eSB0aGlzIGVtYWlsLCBhbmQgYnJpZWZseSBzY2FubmluZyB0aHJvdWdoIGEgY291cGxlIG9mIHNl Y3Rpb25zLCBpdCBpcyB1bmNsZWFyIHRvIG1lIGhvdyBzb21lIG9mIHRoZSBtZWNoYW5pY3Mgd29y ay48YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsgVGhlcmUgYXJlIHNvbWUg bWFqb3IgaXNzdWVzIHdpdGggdGhlIE1hYyB1c2FnZSBhbmQgYXNzb2NpYXRpb24sIGFzIEpvZWwg SGFscGVybiBtZW50aW9uZWQgaW4gaGlzIFJ0ZyBEaXIgcmV2aWV3LjxiciBjbGFzcz0iIj4NCiZn dDsgPGJyIGNsYXNzPSIiPg0KJmd0OyBBbmQsIGFkZGl0aW9uYWxseSwgcGxlYXNlIGNvbnNpZGVy IHRoZSBmb2xsb3dpbmcgY29tbWVudHMgYW5kIHF1ZXN0aW9uczo8YnIgY2xhc3M9IiI+DQomZ3Q7 IDxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyAxLiBVbmRlcnNwZWNpZmlj YXRpb24gZm9yIGluaXRpYWxpemF0aW9uIGFuZCBpbml0aWFsIGRlbXVsdGlwbGV4aW5nLjxiciBj bGFzcz0iIj4NCiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyBUaGlzIGRvY3VtZW50IGFsbG93cyBt dWx0aXBsZSBCRkQgc2Vzc2lvbnMgYmV0d2VlbiBhIHNpbmdsZSBwYWlyIG9mIFZURVBzOjxiciBj bGFzcz0iIj4NCiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgQW48YnIgY2xh c3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBpbXBsZW1lbnRhdGlvbiB0aGF0IHN1cHBvcnRzIHRo aXMgc3BlY2lmaWNhdGlvbiBNVVNUIGJlIGFibGUgdG88YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyBjb250cm9sIHRoZSBudW1iZXIgb2YgQkZEIHNlc3Npb25zIHRoYXQgY2FuIGJlIGNy ZWF0ZWQgYmV0d2VlbiB0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBzYW1lIHBh aXIgb2YgVlRFUHMuPGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IFRoZSBp bXBsaWNhdGlvbiBvZiB0aGlzIGlzIHRoYXQgQkZEIHNpbmdsZS1ob3AgaW5pdGlhbGl6YXRpb24g cHJvY2VkdXJlcyB3aWxsIG5vdCB3b3JrLiBJbnN0ZWFkLCB0aGVyZSBpcyBhIG5lZWQgdG8gbWFw IHRoZSBpbml0aWFsIGRlbXVsdGlwbGV4aW5nLjxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNz PSIiPg0KJmd0OyBUaGlzIGlzc3VlIGlzIGV4cGxhaW5lZCBpbiBSRkNzIDU4ODIgYW5kIDU4ODM6 IDxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1ODgzI3NlY3Rpb24tNCIg cmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+DQpodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNTg4MyNzZWN0aW9uLTQ8L2E+IGFuZCA8YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTg4MiNzZWN0aW9uLTYiIHJlbD0ibm9yZWZlcnJlciIg dGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzU4ODIjc2VjdGlvbi02PC9hPjxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0 OyBTZWN0aW9uIDUuMSBzYXlzOjxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0 OyZuYnNwOyAmbmJzcDsgRm9yIHN1Y2ggcGFja2V0cywgdGhlIEJGRCBzZXNzaW9uIE1VU1QgYmUg aWRlbnRpZmllZDxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7IHVzaW5nIHRoZSBpbm5l ciBoZWFkZXJzLCBpLmUuLCB0aGUgc291cmNlIElQLCB0aGUgZGVzdGluYXRpb24gSVAsIGFuZDxi ciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7IHRoZSBzb3VyY2UgVURQIHBvcnQgbnVtYmVy IHByZXNlbnQgaW4gdGhlIElQIGhlYWRlciBjYXJyaWVkIGJ5IHRoZTxiciBjbGFzcz0iIj4NCiZn dDsmbmJzcDsgJm5ic3A7IHBheWxvYWQgb2YgdGhlIFZYTEFOIGVuY2Fwc3VsYXRlZCBwYWNrZXQu Jm5ic3A7IFRoZSBWTkkgb2YgdGhlIHBhY2tldDxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5i c3A7IFNIT1VMRCBiZSB1c2VkIHRvIGRlcml2ZSBpbnRlcmZhY2UtcmVsYXRlZCBpbmZvcm1hdGlv biBmb3I8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBkZW11bHRpcGxleGluZyB0aGUg cGFja2V0LjxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyBCdXQgdGhpcyBk b2VzIG5vdCByZWFsbHkgZXhwbGFpbiBob3cgdG8gZG8gdGhlIGluaXRpYWwgZGVtdWx0aXBsZXhp bmcuIERvZXMgZWFjaCBCRkQgc2Vzc2lvbiBuZWVkIHRvIGhhdmUgYSBzZXBhcmF0ZSBpbm5lciBz b3VyY2UgSVAgYWRkcmVzcz8gT3Igc291cmNlIFVEUCBwb3J0PyBBbmQgaG93IG9mdGVyIGFyZSB0 aGV5IHJlY3ljbGVkIG9yIGtlcHQgYXMgc3RhdGU/IEhvdyBhcmUgdGhlc2UgbWFwcGVkPzxiciBj bGFzcz0iIj4NCiZndDsgRXF1YWxseSBpbXBvcnRhbnRseSwgd2hpY2ggc2lkZSBpcyBBY3RpdmU/ PGJyIGNsYXNzPSIiPg0KJmd0OyBBbmQgd2hhdCBpZiB0aGVyZeKAmXMgYSByYWNlIGNvbmRpdGlv biB3aXRoIGJvdGggc2lkZXMgYmVpbmcgQWN0aXZlIGFuZCBzZXR0aW5nIHVwIHJlZHVuZGFudCBz ZXNzaW9ucz88YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsgMS5iLiBCeSB0 aGUgd2F5LCBiYXNlZCBvbiB0aGlzLCB1c2luZyBTLUJGRCBbUkZDIDc4ODBdIG1pZ2h0IGJlIGVh c2llciB0byBkZW11eC48YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsgPGJy IGNsYXNzPSIiPg0KJmd0OyAyLiBTZWN1cml0eTxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNz PSIiPg0KJmd0OyBUaGlzIGRvY3VtZW50IHNheXMgdGhhdCB0aGUgVFRMIGluIHRoZSBpbm5lciBw YWNrZXQgY2FycnlpbmcgQkZEIGlzIHNldCB0byAxLiBIb3dldmVyLCBSRkMgNTg4MCBzYXlzIHRv IHVzZSBHVFNNIFtSRkMgNTA4Ml0sIGkuZS4sIGEgdmFsdWUgb2YgMjU1Li48YnIgY2xhc3M9IiI+ DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsgV2h5IGlzIEdUU00gbm90IHVzZWQgaGVyZT88YnIg Y2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyAz LiBFQ01QIGFuZCBmYXRlLXNoYXJpbmcgdW5kZXItc3BlY2lmaWNhdGlvbjo8YnIgY2xhc3M9IiI+ DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsgU2VjdGlvbiA0LjEuIHNheXM6PGJyIGNsYXNzPSIi Pg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBUaGUgT3V0ZXIgSVAvVURQ PGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgYW5kIFZYTEFOIGhlYWRlcnMgTVVTVCBi ZSBlbmNvZGVkIGJ5IHRoZSBzZW5kZXIgYXMgZGVmaW5lZCBpbjxiciBjbGFzcz0iIj4NCiZndDsm bmJzcDsgJm5ic3A7IFtSRkM3MzQ4XS48YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4N CiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyBBbmQgUkZDIDczNDggc2F5czo8YnIgY2xhc3M9IiI+ DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDstJm5i c3A7IFNvdXJjZSBQb3J0OiZuYnNwOyBJdCBpcyByZWNvbW1lbmRlZCB0aGF0IHRoZSBVRFAgc291 cmNlIHBvcnQgbnVtYmVyPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgYmUgY2FsY3VsYXRlZCB1c2luZyBhIGhhc2ggb2YgZmllbGRzIGZyb20gdGhl IGlubmVyIHBhY2tldCAtLTxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IG9uZSBleGFtcGxlIGJlaW5nIGEgaGFzaCBvZiB0aGUgaW5uZXIgRXRoZXJu ZXQgZnJhbWUncyBoZWFkZXJzLjxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IFRoaXMgaXMgdG8gZW5hYmxlIGEgbGV2ZWwgb2YgZW50cm9weSBmb3Ig dGhlIEVDTVAvbG9hZC08YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBiYWxhbmNpbmcgb2YgdGhlIFZNLXRvLVZNIHRyYWZmaWMgYWNyb3NzIHRoZSBW WExBTiBvdmVybGF5LjxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IFdoZW4gY2FsY3VsYXRpbmcgdGhlIFVEUCBzb3VyY2UgcG9ydCBudW1iZXIgaW4g dGhpcyBtYW5uZXIsIGl0PGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgaXMgUkVDT01NRU5ERUQgdGhhdCB0aGUgdmFsdWUgYmUgaW4gdGhlIGR5bmFt aWMvcHJpdmF0ZSBwb3J0PGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgcmFuZ2UgNDkxNTItNjU1MzUgW1JGQzYzMzVdLjxiciBjbGFzcz0iIj4NCiZn dDsgPGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IEJhc2VkIG9uIHRoaXMs IGRlcGVuZGluZyBvbiB0aGUgaGFzaGluZyBjYWxjdWxhdGlvbiwgdGhlIG91dGVyIHNvdXJjZSBV RFAgcG9ydCBjYW4gYmUgZGlmZmVyZW50IGxlYWRpbmcgdG8gZGlmZmVyZW50IEVDTVAgdHJlYXRt ZW50LiBEb2VzIHNvbWV0aGluZyBlbHNlIG5lZWQgdG8gYmUgc3BlY2lmaWVkIGhlcmUgaW4gcmVn YXJkcyB0byB0aGUgb3V0ZXIgVURQIHNvdXJjZSBwb3J0PzxiciBjbGFzcz0iIj4NCiZndDsgPGJy IGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IDQuIFNlY3Rpb24gNyBzYXlzIHRo YXQg4oCcIFN1cHBvcnQgZm9yIGVjaG8gQkZEIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMg ZG9jdW1lbnTigJ0uDQo8YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsgQXNz dW1pbmcgdGhpcyBtZWFucyDigJxCRkQgRWNobyBtb2Rl4oCdLCB3aHkgaXMgdGhpcyBvdXQgb2Yg c2NvcGU/IElmIHRoaXMgaXMgYSBzaW5nbGUgbG9naWNhbCBob3AgdW5kZXJuZWF0aCBWWExBTiwg d2hhdOKAmXMgcHJldmVudGluZyB0aGUgdXNlIG9mIEVjaG8/IEVjaG/igJlzIGJlbmVmaXRzIGFy ZSBodWdlLjxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9 IiI+DQomZ3Q7IDUuIFRlcm1pbm9sb2d5PGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyBJbXBsZW1lbnRhdGlvbnMgU0hPVUxEIGVuc3VyZSB0aGF0IHRo ZSBCRkQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBwYWNrZXRzIGZvbGxvdyB0aGUg c2FtZSBsb29rdXAgcGF0aCBhcyBWWExBTiBkYXRhIHBhY2tldHMgd2l0aGluIHRoZTxiciBjbGFz cz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7IHNlbmRlciBzeXN0ZW0uPGJyIGNsYXNzPSIiPg0KJmd0 OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IFdoYXQgaXMgYSDigJxsb29rIHVwIHBhdGggd2l0aGluIGEg c2VuZGVyIHN5c3RlbeKAnT88YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsg PGJyIGNsYXNzPSIiPg0KJmd0OyA2LiBEZXBsb3ltZW50IHNjZW5hcmlvczxiciBjbGFzcz0iIj4N CiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyBTMyBzYXlzOjxiciBjbGFzcz0iIj4NCiZndDsmbmJz cDsgJm5ic3A7IEZpZ3VyZSAxIGlsbHVzdHJhdGVzIHRoZSBzY2VuYXJpbyB3aXRoIHR3byBzZXJ2 ZXJzLCBlYWNoIG9mIHRoZW08YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBob3N0aW5n IHR3byBWTXMuJm5ic3A7IFRoZSBzZXJ2ZXJzIGhvc3QgVlRFUHMgdGhhdCB0ZXJtaW5hdGUgdHdv IFZYTEFOPGJyIGNsYXNzPSIiPg0KJmd0OyBb4oCmXTxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IEZpZ3VyZSAxOiBSZWZlcmVuY2UgVlhMQU4gRG9tYWluPGJyIGNsYXNzPSIi Pg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsgSG93ZXZlciwg UkZDIDczNDggRmlndXJlIDMgbGlzdHMgdGhhdCBhcyBvbmUgZGVwbG95bWVudCBzY2VuYXJpbywg bm90IGFzIOKAnHRoZSBzY2VuYXJpb+KAnSBhbmQg4oCcVGhlIFJlZmVyZW5jZSBWWExBTiBEb21h aW7igJ0uPGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IEJlc3QsPGJyIGNs YXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IENhcmxvcy48YnIgY2xhc3M9IiI+DQom Z3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IE9uIEp1biAxNywgMjAxOSwgYXQgMTI6NTggQU0s IEdyZWcgTWlyc2t5ICZsdDs8YSBocmVmPSJtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+Z3JlZ2ltaXJza3lAZ21haWwuY29tPC9hPiZndDsgd3Jv dGU6PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgSGkgT2xp dmVyLDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IHRoYW5rIHlvdSBmb3IgeW91ciB0aG9yb3VnaCBy ZXZpZXcsIGNsZWFyIGFuZCBkZXRhaWxlZCBxdWVzdGlvbnMuIE15IGFwb2xvZ2llcyBmb3IgdGhl IGRlbGF5IHRvIHJlc3BvbmQuIFBsZWFzZSBmaW5kIG15IGFuc3dlcnMgYmVsb3cgaW4tbGluZSB0 YWdnZWQgR0lNJmd0OyZndDsuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgUmVnYXJkcyw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBHcmVnPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgT24gRnJpLCBNYXkgMzEsIDIwMTkg YXQgMTI6MzggUE0gT2xpdmllciBCb25hdmVudHVyZSB2aWEgRGF0YXRyYWNrZXIgJmx0OzxhIGhy ZWY9Im1haWx0bzpub3JlcGx5QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+bm9y ZXBseUBpZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IFJldmll d2VyOiBPbGl2aWVyIEJvbmF2ZW50dXJlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgUmV2aWV3IHJl c3VsdDogUmVhZHkgd2l0aCBJc3N1ZXM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyA8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyBUaGlzIGRvY3VtZW50IGhhcyBiZWVuIHJldmlld2VkIGFzIHBhcnQgb2Yg dGhlIHRyYW5zcG9ydCBhcmVhIHJldmlldyB0ZWFtJ3M8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBv bmdvaW5nIGVmZm9ydCB0byByZXZpZXcga2V5IElFVEYgZG9jdW1lbnRzLiBUaGVzZSBjb21tZW50 cyB3ZXJlIHdyaXR0ZW48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBwcmltYXJpbHkgZm9yIHRoZSB0 cmFuc3BvcnQgYXJlYSBkaXJlY3RvcnMsIGJ1dCBhcmUgY29waWVkIHRvIHRoZSBkb2N1bWVudCdz PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgYXV0aG9ycyBhbmQgV0cgdG8gYWxsb3cgdGhlbSB0byBh ZGRyZXNzIGFueSBpc3N1ZXMgcmFpc2VkIGFuZCBhbHNvIHRvIHRoZSBJRVRGPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgZGlzY3Vzc2lvbiBsaXN0IGZvciBpbmZvcm1hdGlvbi48YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBXaGVuIGRvbmUgYXQgdGhlIHRpbWUg b2YgSUVURiBMYXN0IENhbGwsIHRoZSBhdXRob3JzIHNob3VsZCBjb25zaWRlciB0aGlzPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgcmV2aWV3IGFzIHBhcnQgb2YgdGhlIGxhc3QtY2FsbCBjb21tZW50 cyB0aGV5IHJlY2VpdmUuIFBsZWFzZSBhbHdheXMgQ0M8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyA8 YSBocmVmPSJtYWlsdG86dHN2LWFydEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIi PnRzdi1hcnRAaWV0Zi5vcmc8L2E+IGlmIHlvdSByZXBseSB0byBvciBmb3J3YXJkIHRoaXMgcmV2 aWV3LjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IEkgaGF2 ZSBvbmx5IGxpbWl0ZWQga25vd2xlZGdlIG9mIFZYTEFOIGFuZCBkbyBub3Qga25vdyBhbGwgc3Vi dGxldGllcyBvZiBCRkQuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgVGhpcyByZXZpZXcgaXMgdGh1 cyBtb3JlIGZyb20gYSBnZW5lcmFsaXN0IHRoYW4gYSBzcGVjaWFsaXN0IGluIHRoaXMgdG9waWMu PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgTWFqb3IgaXNz dWVzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgU2VjdGlv biA0IHJlcXVpcmVzIHRoYXQgJnF1b3Q7IEltcGxlbWVudGF0aW9ucyBTSE9VTEQgZW5zdXJlIHRo YXQgdGhlIEJGRDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBwYWNrZXRzIGZv bGxvdyB0aGUgc2FtZSBsb29rdXAgcGF0aCBhcyBWWExBTiBkYXRhIHBhY2tldHMgd2l0aGluIHRo ZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBzZW5kZXIgc3lzdGVtLiZxdW90 OzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IFdoeSBpcyB0 aGlzIHJlcXVpcmVtZW50IG9ubHkgcmVsZXZhbnQgZm9yIHRoZSBsb29rdXAgcGF0aCBvbiB0aGUg c2VuZGVyIHN5c3RlbTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ID8gV2hhdCBkb2VzIHRoaXMgc2Vu dGVuY2UgcmVhbGx5IGltcGxpZXMgPzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IEdJTSZndDsmZ3Q7 IFJGQyA1ODgwIHNldCB0aGUgc2NvcGUgb2YgdGhlIGZhdWx0IGRldGVjdGlvbiBvZiBCRkQgcHJv dG9jb2wgYXMgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7IC4uLiB0aGUgYmlk aXJlY3Rpb25hbCBwYXRoIGJldHdlZW4gdHdvIGZvcndhcmRpbmcgZW5naW5lcywgaW5jbHVkaW5n PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7IGludGVyZmFjZXMsIGRhdGEgbGlu ayhzKSwgYW5kIHRvIHRoZSBleHRlbnQgcG9zc2libGUgdGhlIGZvcndhcmRpbmc8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgZW5naW5lcyB0aGVtc2VsdmVzIC4uLjxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7IFRoZSByZXF1aXJlbWVudCBhaW1lZCB0byB0aGUgZm9yd2FyZGluZyBl bmdpbmUgb2YgYSBCRkQgc3lzdGVtIHRoYXQgdHJhbnNtaXRzIEJGRCBjb250cm9sIHBhY2tldHMg b3ZlciBWWExBTiB0dW5uZWwuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgSXMgaXQgYSByZXF1aXJlbWVudCB0aGF0IHRoZSBCRkQgcGFja2V0cyBmb2xsb3cg dGhlIHNhbWUgcGF0aCBhcyB0aGUgZGF0YTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IHBhY2tldCBm b3IgYSBnaXZlbiBWWExBTiA/IEkgZ3Vlc3Mgc28uIEluIHRoaXMgY2FzZSwgdGhlIGRvY3VtZW50 IHNob3VsZDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IGRpc2N1c3MgaG93IEVxdWFsIENvc3QgTXVs dGlwYXRoIGNvdWxkIGFmZmVjdCB0aGlzLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IEdJTSZndDsm Z3Q7IEkgdGhpbmsgdGhhdCBFQ01QIGVudmlyb25tZW50IGlzIG1vcmUgbGlrZWx5IHRvIGJlIGV4 cGVyaWVuY2VkIGJ5IGEgdHJhbnNpdCBub2RlIGluIHRoZSB1bmRlcmxheS4gSWYgdGhlIEJGRCBz ZXNzaW9uIGlzIHVzZWQgdG8gbW9uaXRvciB0aGUgc3BlY2lmaWMgdW5kZXJsYXkgcGF0aCwgdGhl biwgSSBhZ3JlZSwgd2Ugc2hvdWxkIGV4cGxhaW4gdGhhdCB1c2luZyB0aGUgVlhMQU4gcGF5bG9h ZCBpbmZvcm1hdGlvbiB0byBkcmF3IHBhdGgNCiBlbnRyb3B5IG1heSBjYXVzZSBkYXRhIGFuZCBC RkQgcGFja2V0cyBmb2xsb3dpbmcgZGlmZmVyZW50IHVuZGVybGF5IHJvdXRlcy4gQnV0LCBvbiB0 aGUgb3RoZXIgaGFuZCwgdGhhdCBpcyB0aGUgY2FzZSBmb3IgT0FNIGFuZCBmYXVsdCBkZXRlY3Rp b24gaW4gYWxsIG92ZXJsYXkgbmV0d29ya3MgaW4gZ2VuZXJhbC48YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBNaW5vciBpc3N1ZXM8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBTZWN0aW9uIDE8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBZb3Ugd3JpdGUgJnF1b3Q7VGhlIGFzeW5j aHJvbm91cyBtb2RlIG9mIEJGRCwgYXMgZGVmaW5lZCBpbiBbUkZDNTg4MF0sPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsmbmJzcDsgY2FuIGJlIHVzZWQgdG8gbW9uaXRvciBhIHAycCBWWExBTiB0dW5u ZWwuJnF1b3Q7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg V2h5IGRvIHlvdSB1c2UgdGhlIHdvcmQgY2FuID8gSXQgaXMgYSBwb3NzaWJpbGl0eSBvciBhIHJl cXVpcmVtZW50ID88YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBHSU0mZ3Q7Jmd0OyBJbiBwcmluY2lw bGUsIEJGRCBEZW1hbmQgbW9kZSBtYXkgYmUgdXNlZCB0byBtb25pdG9yIHAycCBwYXRocyBhcyB3 ZWxsLCBJIGFncmVlLCB3aWxsIHJlLXdvcmQgdG8gbW9yZSBhc3NlcnRpdmU6PGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsmbmJzcDsgVGhlIGFzeW5jaHJvbm91cyBtb2RlIG9mIEJGRCwgYXMgZGVmaW5l ZCBpbiBbUkZDNTg4MF0sPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmbmJzcDsgaXMgdXNlZCB0byBt b25pdG9yIGEgcDJwIFZYTEFOIHR1bm5lbC48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyA8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyBOVkUgaGFzIG5vdCBiZWVuIGRlZmluZWQgYmVmb3JlIGFuZCBpcyBu b3QgaW4gdGhlIHRlcm1pbm9sb2d5LjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IEdJTSZndDsmZ3Q7 IFdpbGwgYWRkIHRvIHRoZSBUZXJtaW5vbG9neSBhbmQgZXhwYW5kIGFzOjxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7IE5WRSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBOZXR3b3JrIFZpcnR1YWxp emF0aW9uIEVuZHBvaW50IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7IFRoaXMgZW50aXJlIHNlY3Rpb24gaXMgbm90IGVhc3kgdG8gcmVhZCBmb3IgYW4gb3V0 c2lkZXIuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgU2Vj dGlvbiAzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgVk5J IGhhcyBub3QgYmVlbiBkZWZpbmVkPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgR0lNJmd0OyZndDsg V2lsbCBhZGQgdG8gdGhlIFRlcm1pbm9sb2d5IHNlY3Rpb246PGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsgVk5JJm5ic3A7ICZuYnNwOyBWWExBTiBOZXR3b3JrIElkZW50aWZpZXIgKG9yIFZYTEFOIFNl Z21lbnQgSUQpPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg RmlndXJlIDEgY291bGQgdGFrZSBsZXNzIHNwYWNlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgR0lN Jmd0OyZndDsgWWVzLCBjYW4gbWFrZSBpdCBiaXQgZGVuc2VyLiBXb3VsZCB0aGUgZm9sbG93aW5n IGJlIGFuIGltcHJvdmVtZW50PzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7IDxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLS0tLS0tLS0t LS0mIzQzOy0tLS0tLS0tLS0tLS0mIzQzOzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBTZXJ2ZXIgMSZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmIzQzOy0tLS0mIzQzOy0tLS0mIzQzOyZuYnNw OyAmIzQzOy0tLS0mIzQzOy0tLS0mIzQzOyB8PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDt8IHxWTTEtMSZuYnNwOyAmbmJzcDsgfCZuYnNwOyB8Vk0xLTIm bmJzcDsgJm5ic3A7IHwgfDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7fCB8Vk5JIDEwMCZuYnNwOyB8Jm5ic3A7IHxWTkkgMjAwJm5ic3A7IHwgfDxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCB8Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDt8IHw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3wgJiM0MzstLS0tLS0tLS0mIzQzOyZuYnNwOyAmIzQzOy0tLS0tLS0tLSYjNDM7IHw8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgSHlwZXJ2 aXNvciBWVEVQIChJUDEpJm5ic3A7ICZuYnNwOyB8PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0 Mzs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7fDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyYjNDM7LS0tLS0tLS0t LS0tLSYjNDM7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDtMYXllciAz Jm5ic3A7ICZuYnNwO3w8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7JiM0MzstLS18Jm5ic3A7ICZuYnNwO05ldHdvcmsm bmJzcDsgJm5ic3A7fDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS0tLS0tLS0tLS0t LSYjNDM7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyIGNsYXNz PSIiPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tLS0tLS0tLS0tJiM0Mzs8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0t JiM0Mzs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IHwmbmJzcDsgJm5ic3A7IEh5cGVydmlzb3IgVlRFUCAoSVAyKSB8PGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8ICYjNDM7LS0tLSYjNDM7 LS0tLSYjNDM7Jm5ic3A7ICYjNDM7LS0tLSYjNDM7LS0tLSYjNDM7IHw8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgfFZNMi0xJm5ic3A7ICZu YnNwOyB8Jm5ic3A7IHxWTTItMiZuYnNwOyAmbmJzcDsgfCB8PGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8IHxWTkkgMTAwJm5ic3A7IHwmbmJz cDsgfFZOSSAyMDAmbmJzcDsgfCB8PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyB8IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 fCZuYnNwOyB8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgfDxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCAmIzQzOy0tLS0t LS0tLSYjNDM7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tJiM0MzsgfDxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCZuYnNwOyAmbmJzcDsgJm5ic3A7 IFNlcnZlciAyJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJiM0Mzst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgU2VjdGlvbiA0PGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgSSBkbyBub3Qgc2Vl IHRoZSBiZW5lZml0cyBvZiBoYXZpbmcgb25lIHBhcmFncmFwaCBpbiBTZWN0aW9uIDQgZm9sbG93 ZWQgYnkgb25seTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IFNlY3Rpb24gNC4xPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgR0lNJmd0OyZndDsgV2lsbCBtZXJnZSBTZWN0aW9uIDQuMSBpbnRvIDQgd2l0 aCBtaW5vciByZXF1aXJlZCByZS13b3JkaW5nOjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IDQuJm5i c3A7IEJGRCBQYWNrZXQgVHJhbnNtaXNzaW9uIG92ZXIgVlhMQU4gVHVubmVsPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7IEJGRCBwYWNr ZXQgTVVTVCBiZSBlbmNhcHN1bGF0ZWQgYW5kIHNlbnQgdG8gYSByZW1vdGUgVlRFUCBhczxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBleHBsYWluZWQgaW4gdGhpcyBzZWN0aW9u LiZuYnNwOyBJbXBsZW1lbnRhdGlvbnMgU0hPVUxEIGVuc3VyZSB0aGF0IHRoZTxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBCRkQgcGFja2V0cyBmb2xsb3cgdGhlIHNhbWUgbG9v a3VwIHBhdGggYXMgVlhMQU4gZGF0YSBwYWNrZXRzIHdpdGhpbjxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyB0aGUgc2VuZGVyIHN5c3RlbS48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgQkZEIHBhY2tldHMgYXJlIGVu Y2Fwc3VsYXRlZCBpbiBWWExBTiBhcyBkZXNjcmliZWQgYmVsb3cuJm5ic3A7IFRoZSBWWExBTjxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBwYWNrZXQgZm9ybWF0IGlzIGRlZmlu ZWQgaW4gU2VjdGlvbiA1IG9mIFtSRkM3MzQ4XS4mbmJzcDsgVGhlIE91dGVyIElQL1VEUDxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBhbmQgVlhMQU4gaGVhZGVycyBNVVNUIGJl IGVuY29kZWQgYnkgdGhlIHNlbmRlciBhcyBkZWZpbmVkIGluPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsmbmJzcDsgJm5ic3A7IFtSRkM3MzQ4XS48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyA8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyBTZWN0aW9uIDQuMTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IDxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7IFRoZSBkb2N1bWVudCBkb2VzIG5vdCBzcGVjaWZ5IHdoZW4gYSBk ZWRpY2F0ZWQgTUFDIGFkZHJlc3Mgb3IgdGhlIE1BQyBhZGRyZXNzPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgb2YgdGhlIGRlc3RpbmF0aW9uIFZURVAgbXVzdCBiZSB1c2VkLiBUaGlzIGNvdWxkIGFm ZmVjdCB0aGUgaW50ZXJvcGVyYWJpbGl0eSBvZjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IGltcGxl bWVudGF0aW9ucy4gU2hvdWxkIGFsbCBpbXBsZW1lbnRhdGlvbnMgc3VwcG9ydCBib3RoIHRoZSBk ZWRpY2F0ZWQgTUFDPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgYWRkcmVzcyBhbmQgdGhlIGRlc3Rp bmF0aW9uIE1BQyBhZGRyZXNzID88YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBHSU0mZ3Q7Jmd0OyBB ZnRlciBmdXJ0aGVyIGRpc2N1c3Npb24sIGF1dGhvcnMgZGVjaWRlZCB0byByZW1vdmUgdGhlIHJl cXVlc3QgZm9yIHRoZSBkZWRpY2F0ZWQgTUFDIGFkZHJlc3MgYWxsb2NhdGlvbi4gT25seSB0aGUg TUFDIGFkZHJlc3Mgb2YgdGhlIHJlbW90ZSBWVEVQIG11c3QgYmUgdXNlZCBhcyB0aGUgZGVzdGlu YXRpb24gTUFDIGFkZHJlc3MgaW4gdGhlIGlubmVyIEV0aGVybmV0IGZyYW1lLiBQbGVhc2UgY2hl Y2sgdGhlIGF0dGFjaGVkIGRpZmYNCiBiZXR3ZWVuIHRoZSAtMDcgYW5kIHRoZSB3b3JraW5nIHZl cnNpb25zIG9yIHRoZSB3b3JraW5nIHZlcnNpb24gb2YgdGhlIGRyYWZ0LjxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IEl0IGlzIHVuY2xlYXIgZnJvbSB0aGlz IHNlY3Rpb24gd2hldGhlciBJUHY0IGluc2lkZSBJUHY2IGFuZCB0aGUgb3Bwb3NpdGU8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyBzaG91bGQgYmUgc3VwcG9ydGVkIG9yIG5vdC48YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyBHSU0mZ3Q7Jmd0OyBBbnkgY29tYmluYXRpb24gb2Ygb3V0ZXIgSVB2WCBhbmQg aW5uZXIgSVB2WCBpcyBwb3NzaWJsZS48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyA8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyBTZWN0aW9uIDUuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgSWYgdGhlIHJlY2VpdmVkIHBhY2tldCBkb2VzIG5vdCBtYXRjaCB0aGUg ZGVkaWNhdGVkIE1BQyBhZGRyZXNzIG5vciB0aGUgTUFDPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg YWRkcmVzcyBvZiB0aGUgVlRFUCwgc2hvdWxkIHRoZSBwYWNrZXQgYmUgc2lsZW50bHkgZGlzY2Fy ZGVkIG9yIHRyZWF0ZWQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBkaWZmZXJlbnRseSA/PGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgR0lNJmd0OyZndDsgQXMgSSd2ZSBtZW50aW9uZWQgZWFybGllciwg YXV0aG9ycyBoYXZlIGRlY2lkZWQgdG8gcmVtb3ZlIHRoZSB1c2Ugb2YgdGhlIGRlZGljYXRlZCBN QUMgYWRkcmVzcyBmb3IgQkZEIG92ZXIgVlhMQU4uPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgU2VjdGlvbiA1LjE8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyA8 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBJcyB0aGlzIGEgbW9kaWZpY2F0aW9uIHRvIHNlY3Rpb24g Ni4zIG9mIFJGQzU4ODAgPyBUaGlzIGlzIG5vdCBjbGVhcjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 IEdJTSZndDsmZ3Q7IEkgdGhpbmsgdGhhdCB0aGlzIHNlY3Rpb24gaXMgbm90IG1vZGlmaWNhdGlv biBidXQgdGhlIGRlZmluaXRpb24gb2YgdGhlIGFwcGxpY2F0aW9uLXNwZWNpZmljIHByb2NlZHVy ZSB0aGF0IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIFJGQyA1ODgwOjxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7Jm5ic3A7ICZuYnNwOyBUaGUgbWV0aG9kIG9mIGRlbXVsdGlwbGV4aW5nIHRoZSBpbml0 aWFsIHBhY2tldHMgKGluIHdoaWNoIFlvdXI8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAm bmJzcDsgRGlzY3JpbWluYXRvciBpcyB6ZXJvKSBpcyBhcHBsaWNhdGlvbiBkZXBlbmRlbnQsIGFu ZCBpcyB0aHVzIG91dHNpZGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgdGhl IHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyA8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyBTZWN0aW9uIDk8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyA8YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyBUaGUgc2VudGVuY2UgJnF1b3Q7IFRocm90dGxpbmcgTUFZIGJl IHJlbGF4ZWQgZm9yIEJGRCBwYWNrZXRzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmbmJzcDsgJm5i c3A7IGJhc2VkIG9uIHBvcnQgbnVtYmVyLiZxdW90OyBpcyB1bmNsZWFyLjxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7IEdJTSZndDsmZ3Q7IFllcywgdGhhbmsgeW91IGZvciBwb2ludGluZyB0byB0aGlz LiBUaGUgdXBkYXRlZCB0ZXh0LCBpbiB0aGUgd2hvbGUgcGFyYWdyYXBoLCBpcyBhcyBmb2xsb3dz OjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IE5FVyBURVhUOjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 Jm5ic3A7ICZuYnNwOyBUaGUgZG9jdW1lbnQgcmVxdWlyZXMgc2V0dGluZyB0aGUgaW5uZXIgSVAg VFRMIHRvIDEsIHdoaWNoIGNvdWxkIGJlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmbmJzcDsgJm5i c3A7IHVzZWQgYXMgYSBERG9TIGF0dGFjayB2ZWN0b3IuJm5ic3A7IFRodXMgdGhlIGltcGxlbWVu dGF0aW9uIE1VU1QgaGF2ZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyB0aHJv dHRsaW5nIGluIHBsYWNlIHRvIGNvbnRyb2wgdGhlIHJhdGUgb2YgQkZEIGNvbnRyb2wgcGFja2V0 cyBzZW50PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7IHRvIHRoZSBjb250cm9s IHBsYW5lLiZuYnNwOyBPbiB0aGUgb3RoZXIgaGFuZCwgb3ZlciBhZ2dyZXNzaXZlIHRocm90dGxp bmc8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgb2YgQkZEIGNvbnRyb2wgcGFj a2V0cyBtYXkgYmVjb21lIHRoZSBjYXVzZSBvZiB0aGUgaW5hYmlsaXR5IHRvIGZvcm08YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgYW5kIG1haW50YWluIEJGRCBzZXNzaW9uIGF0 IHNjYWxlLiZuYnNwOyBIZW5jZSwgdGhyb3R0bGluZyBvZiBCRkQgY29udHJvbDxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBwYWNrZXRzIFNIT1VMRCBiZSBhZGp1c3RlZCB0byBw ZXJtaXQgQkZEIHRvIHdvcmsgYWNjb3JkaW5nIHRvIGl0czxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 Jm5ic3A7ICZuYnNwOyBwcm9jZWR1cmVzLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7ICZsdDtkcmFm dC1pZXRmLWJmZC12eGxhbi0wOC50eHQmZ3Q7Jmx0O0RpZmZfIGRyYWZ0LWlldGYtYmZkLXZ4bGFu LTA3LnR4dCAtIGRyYWZ0LWlldGYtYmZkLXZ4bGFuLTA4LnR4dC5odG1sJmd0OzxiciBjbGFzcz0i Ij4NCiZndDsgPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_0B9FDA177F134FECAE9740BC9D72C87Bciscocom_-- From nobody Thu Jun 20 05:03:38 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160D8120440; Wed, 19 Jun 2019 21:50: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_HELO_NONE=0.001, 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 uZR8irusiESm; Wed, 19 Jun 2019 21:50:39 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (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 6F56F1205FF; Wed, 19 Jun 2019 21:50:38 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id y198so1403747lfa.1; Wed, 19 Jun 2019 21:50:38 -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=2cSBtIsmZHX+TPwWSUWQFlybf/UWdRKRODOZy5cSFko=; b=EYnNdD0iGSwMKfyV5TKGUPEx1oG00nmCGeTqE61l7SK6KQf53z51v2Nu/0749BjJ6l ktHXPTAo8dPuBTR2oXJmCi5xIM1ao/TKaeRh2WEywzdK082g8w4A8Zck59dQya0xifA1 xPT3BJ5FlLYIhbGl8RkG4UGPojD7rqBW1HUn+xpfOL4xdcKFLivsWM3ecnfnGWO2GAp6 4xObNeKGv3kPAJwNzkUVWzQJblfwb91jPY7xpUxCe+F8DsVILUYaPvvnU0AZQkONUWDi Bi3SL31D96VCH3xCZf69KzVTbwJGhLT/w4yHV0mu1++NgW8Cu2Dd2eci3hvf4nPyab4G 41Ww== 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=2cSBtIsmZHX+TPwWSUWQFlybf/UWdRKRODOZy5cSFko=; b=JIDO7WXhvkdrIJuG0PEcIgeCzo1mtVt1kQ1zSCEmQfFpl5+cnsX1nUVSjiQQkR9aHF oCh48qvrKqDTe3a5VxleSKC+omTsz86zK79mU9pt2CIjTww0lTuhfrx+nwL7fYhp5AbB UBPLGo2sk8VrCUnFGRRRPJjqn2mDlTTAZ19MsAR7xnaU1CTRNO0ByDBC2yavv5jbLOi2 G1mFrRb3YXb3IhiTNdhV95GIQpAXnv0y50QN86A0AO99gybfj/Y7OVovALqUCbT++/lA 05E3GG9RIfOF06D3AC9KhRpWJDU72cDDHIzZ48SPFtmcAM7YhjNwpMX43Yx/gRQE0b2s 80mA== X-Gm-Message-State: APjAAAUhUfxsSwq5J3aaGCX9+kTK8x0dslIPvW7UtqlLfkQF5Gg9dw2U 8zHzURG1GY1QE4h7e9tGHyp42CsXwlwSlB/IjjA= X-Google-Smtp-Source: APXvYqw/nU577doPDw+PIxuItKf+H2deQlcVv3hIlpgiDGqIY83WXv/oto9nIA5wPKK7NtzN+O0ORCh1f1kmqIMGwVo= X-Received: by 2002:ac2:569c:: with SMTP id 28mr4319395lfr.147.1561006236428; Wed, 19 Jun 2019 21:50:36 -0700 (PDT) MIME-Version: 1.0 References: <155933149484.6565.7386019489022348116@ietfa.amsl.com> <14822B96-D3C6-495E-8661-198068F72ABA@cisco.com> <8237FE8D-937E-4BCB-B1A3-89C2B3CDC51C@cisco.com> <0B9FDA17-7F13-4FEC-AE97-40BC9D72C87B@cisco.com> In-Reply-To: <0B9FDA17-7F13-4FEC-AE97-40BC9D72C87B@cisco.com> From: Greg Mirsky Date: Thu, 20 Jun 2019 13:50:24 +0900 Message-ID: Subject: Level of standardization of the Echo mode of BFD [Re: Tsvart last call review of draft-ietf-bfd-vxlan-07] To: "Carlos Pignataro (cpignata)" Cc: "tsv-art@ietf.org" , rtg-bfd WG , "draft-ietf-bfd-vxlan.all@ietf.org" , Olivier Bonaventure , IETF list Content-Type: multipart/alternative; boundary="00000000000036f10d058bba160b" Archived-At: X-Mailman-Approved-At: Thu, 20 Jun 2019 05:03:36 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 04:50:45 -0000 --00000000000036f10d058bba160b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Carlos, could you please refer me to the specification of BFD that defines the message format that is used in the Echo mode of BFD. Is it the BFD control packet? Something else? Regards, Greg On Thu, Jun 20, 2019 at 11:09 AM Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Hello, Greg, > > Please see inline. > > On Jun 19, 2019, at 9:58 PM, Greg Mirsky wrote: > > Hello Carlos, > thank you for the expedient clarification. > To your questions on demultiplexing BFD control packets with the zero > value of the Your Discriminator field: > > - only BFD control packets with the zero value of the Your > Discriminator field are demultiplexed using the information of the inn= er IP > header. I believe that the text is clear and requires that all fields = of > the inner IP header must be used to demultiplex a received BFD control > packet with the zero value in the Your Discriminator field. Which of t= he > fields an implementation uses to create multiple BFD sessions between = the > pair of VTEPs is implementation specific. > > This text is repeating was is in the draft, but does not answer any of my > questions. > > For example: > 1. "that all fields of the inner IP header must be used to demultiplex a > received BFD control packet=E2=80=9D > -> The text does not say =E2=80=9Call fields=E2=80=9D, but regardless= , do you mean the > DSCP and the Evil Bit? IPv6 Flow Label? How *exactly*? > 2. How is the mapping of IP (not UDP?) fields to BFD session done? > 3. How is this state created and maintained? > 4. Since this is a set of fields on which two systems need to agree (whic= h > fields from the inner IP/UDP are mapped needs to be understood by both > systems), it cannot be =E2=80=9Cimplementation specific=E2=80=9D. Further= , the text does > not say so. > > To your point on the level Echo mode of BFD is specified in RFC 5880 I'll > quote the opinion of Jeffrey Haas from the discussion of comments from > Shawn Emery on behalf of the SecDir. Shawn had commented: > > Echo BFD is out of scope for the document, but does not describe the > reason for this or why state > > this at all? > > I've responded: > > GIM>> I think that the main reason is that the BFD Echo mode is > underspecified. RFC 5880 defined some of the mechanisms related to the Ec= ho > mode, but more standardization work may be required. > > And Jeffrey Haas had added: > > Speaking as a BFD chair, this is the relevant observation. BFD Echo is > underspecified to the point where claiming compliance is difficult at bes= t. > In general, it relies on single-hop and the ability to have the remote Ec= ho > client loop the packets. > > > BFD Echo cannot be specified in RFC 5880 base spec because it is > application specific. > > > This packet loop may not be practical for several encapsulations and thus > is > out of scope for such encapsulations. Whether this is practical for vxla= n > today, or in the presence of future extensions to vxlan is left out of > scope > for the core proposal. > > > The question remains: for VXLAN encapsulation, this is like a single hop > as far as BFD is concerned (single hop VXLAN tunnel). > > Since RFC 5881 defines Echo for single hop, can you please elaborate (in > the document) why is out of scope or how it can work? > > Best, > > Carlos. > > > Will respond to other questions in a separate mail. > > Regards, > Greg > > > On Thu, Jun 20, 2019 at 10:31 AM Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > >> Hello, Greg, >> >> > On Jun 19, 2019, at 9:09 PM, Greg Mirsky wrote= : >> > >> > Hi Carlos, >> > thank you for reminding of our continued discussion with Joel. We are >> seeking comments from VXLAN experts and much appreciate if you have >> insights on VXLAN to share. >> > I've got some clarifying questions before I can respond to you. >> >> Sure. >> >> > To which stage of the three-way handshake you refer as "initial >> demultiplexing"? I couldn't find this term in RFC 5880. >> >> =E2=80=9CInitial demultiplexing" is a well-known term in BFD, referring = to the >> "demultiplexing of the initial packets", BFD Control packet with YourDis= c >> being zero. >> >> In RFC 5880, see Section 6.3. >> https://tools.ietf.org/html/rfc5880#section-6.3 >> >> The method of demultiplexing the initial packets (in which Your >> Discriminator is zero) is application dependent, and is thus outside >> the scope of this specification. >> >> Since initial demultiplexing is indeed application specific, different >> for one-hop versus multi-hop and dependent upon whether a single or >> multiple sessions are allowed between a pair of endpoints, I added below >> two other relevant citations, from application specific BFD specs: >> 1. https://tools.ietf.org/html/rfc5883#section-4 >> 2. https://tools.ietf.org/html/rfc5882#section-6 >> >> >> > Regarding the applicability of the Echo mode, thank you for pointing t= o >> the need for stricter terminology, the Echo mode, as defined in RFC 5880= , >> is underspecified and it will require additional standardization. >> >> No. BFD Echo is not underspecified in RFC 5880. >> >> Please read S5: https://tools.ietf.org/html/rfc5880#section-5 >> >> BFD Echo packets are sent in an encapsulation appropriate to the >> environment. See the appropriate application documents for the >> specifics of particular environments. >> >> >> BFD Echo is application dependent. >> >> Therefore, for example, single-hop BFD in RFC 5881 specifies BFD Echo fo= r >> that application. >> >> Hence, my question stands: why is this draft claiming BFD Echo is out of >> scope for this BFD application document? >> >> >> > Future drafts may explore and define how the Echo mode of BFD is used >> over VXLAN tunnels. >> > >> >> See above. >> >> > Will review and respond to the remaining questions soon. >> >> Thank you. >> >> The "remaining questions" are still all the questions below :-) >> >> Best, >> >> Carlos. >> >> > >> > Regards, >> > Greg >> > >> > >> > On Thu, Jun 20, 2019 at 9:14 AM Carlos Pignataro (cpignata) < >> cpignata@cisco.com> wrote: >> > Hi, >> > >> > I have not reviewed this draft before, but triggered by this email, an= d >> briefly scanning through a couple of sections, it is unclear to me how s= ome >> of the mechanics work. >> > >> > There are some major issues with the Mac usage and association, as Joe= l >> Halpern mentioned in his Rtg Dir review. >> > >> > And, additionally, please consider the following comments and question= s: >> > >> > >> > 1. Underspecification for initialization and initial demultiplexing. >> > >> > This document allows multiple BFD sessions between a single pair of >> VTEPs: >> > >> > An >> > implementation that supports this specification MUST be able to >> > control the number of BFD sessions that can be created between the >> > same pair of VTEPs. >> > >> > The implication of this is that BFD single-hop initialization >> procedures will not work. Instead, there is a need to map the initial >> demultiplexing. >> > >> > This issue is explained in RFCs 5882 and 5883: >> https://tools.ietf.org/html/rfc5883#section-4 and >> https://tools.ietf.org/html/rfc5882#section-6 >> > >> > Section 5.1 says: >> > >> > For such packets, the BFD session MUST be identified >> > using the inner headers, i.e., the source IP, the destination IP, a= nd >> > the source UDP port number present in the IP header carried by the >> > payload of the VXLAN encapsulated packet. The VNI of the packet >> > SHOULD be used to derive interface-related information for >> > demultiplexing the packet. >> > >> > But this does not really explain how to do the initial demultiplexing. >> Does each BFD session need to have a separate inner source IP address? O= r >> source UDP port? And how ofter are they recycled or kept as state? How a= re >> these mapped? >> > Equally importantly, which side is Active? >> > And what if there=E2=80=99s a race condition with both sides being Act= ive and >> setting up redundant sessions? >> > >> > 1.b. By the way, based on this, using S-BFD [RFC 7880] might be easier >> to demux. >> > >> > >> > 2. Security >> > >> > This document says that the TTL in the inner packet carrying BFD is se= t >> to 1. However, RFC 5880 says to use GTSM [RFC 5082], i.e., a value of 25= 5.. >> > >> > Why is GTSM not used here? >> > >> > >> > 3. ECMP and fate-sharing under-specification: >> > >> > Section 4.1. says: >> > >> > The Outer IP/UDP >> > and VXLAN headers MUST be encoded by the sender as defined in >> > [RFC7348]. >> > >> > >> > And RFC 7348 says: >> > >> > - Source Port: It is recommended that the UDP source port numb= er >> > be calculated using a hash of fields from the inner packet -- >> > one example being a hash of the inner Ethernet frame's header= s. >> > This is to enable a level of entropy for the ECMP/load- >> > balancing of the VM-to-VM traffic across the VXLAN overlay. >> > When calculating the UDP source port number in this manner, i= t >> > is RECOMMENDED that the value be in the dynamic/private port >> > range 49152-65535 [RFC6335]. >> > >> > >> > Based on this, depending on the hashing calculation, the outer source >> UDP port can be different leading to different ECMP treatment. Does >> something else need to be specified here in regards to the outer UDP sou= rce >> port? >> > >> > >> > 4. Section 7 says that =E2=80=9C Support for echo BFD is outside the s= cope of >> this document=E2=80=9D. >> > >> > Assuming this means =E2=80=9CBFD Echo mode=E2=80=9D, why is this out o= f scope? If this >> is a single logical hop underneath VXLAN, what=E2=80=99s preventing the = use of >> Echo? Echo=E2=80=99s benefits are huge. >> > >> > >> > 5. Terminology >> > >> > Implementations SHOULD ensure that the BFD >> > packets follow the same lookup path as VXLAN data packets within th= e >> > sender system. >> > >> > What is a =E2=80=9Clook up path within a sender system=E2=80=9D? >> > >> > >> > 6. Deployment scenarios >> > >> > S3 says: >> > Figure 1 illustrates the scenario with two servers, each of them >> > hosting two VMs. The servers host VTEPs that terminate two VXLAN >> > [=E2=80=A6] >> > Figure 1: Reference VXLAN Domain >> > >> > >> > However, RFC 7348 Figure 3 lists that as one deployment scenario, not >> as =E2=80=9Cthe scenario=E2=80=9D and =E2=80=9CThe Reference VXLAN Domai= n=E2=80=9D. >> > >> > Best, >> > >> > Carlos. >> > >> >> On Jun 17, 2019, at 12:58 AM, Greg Mirsky >> wrote: >> >> >> >> Hi Oliver, >> >> thank you for your thorough review, clear and detailed questions. My >> apologies for the delay to respond. Please find my answers below in-line >> tagged GIM>>. >> >> >> >> Regards, >> >> Greg >> >> >> >> On Fri, May 31, 2019 at 12:38 PM Olivier Bonaventure via Datatracker = < >> noreply@ietf.org> wrote: >> >> Reviewer: Olivier Bonaventure >> >> Review result: Ready with Issues >> >> >> >> This document has been reviewed as part of the transport area review >> team's >> >> ongoing effort to review key IETF documents. These comments were >> written >> >> primarily for the transport area directors, but are copied to the >> document's >> >> authors and WG to allow them to address any issues raised and also to >> the IETF >> >> discussion list for information. >> >> >> >> When done at the time of IETF Last Call, the authors should consider >> this >> >> review as part of the last-call comments they receive. Please always = CC >> >> tsv-art@ietf.org if you reply to or forward this review. >> >> >> >> I have only limited knowledge of VXLAN and do not know all subtleties >> of BFD. >> >> This review is thus more from a generalist than a specialist in this >> topic. >> >> >> >> Major issues >> >> >> >> Section 4 requires that " Implementations SHOULD ensure that the BFD >> >> packets follow the same lookup path as VXLAN data packets within t= he >> >> sender system." >> >> >> >> Why is this requirement only relevant for the lookup path on the >> sender system >> >> ? What does this sentence really implies ? >> >> GIM>> RFC 5880 set the scope of the fault detection of BFD protocol a= s >> >> ... the bidirectional path between two forwarding engines, includi= ng >> >> interfaces, data link(s), and to the extent possible the forwardin= g >> >> engines themselves ... >> >> The requirement aimed to the forwarding engine of a BFD system that >> transmits BFD control packets over VXLAN tunnel. >> >> >> >> Is it a requirement that the BFD packets follow the same path as the >> data >> >> packet for a given VXLAN ? I guess so. In this case, the document >> should >> >> discuss how Equal Cost Multipath could affect this. >> >> GIM>> I think that ECMP environment is more likely to be experienced >> by a transit node in the underlay. If the BFD session is used to monitor >> the specific underlay path, then, I agree, we should explain that using = the >> VXLAN payload information to draw path entropy may cause data and BFD >> packets following different underlay routes. But, on the other hand, tha= t >> is the case for OAM and fault detection in all overlay networks in gener= al. >> >> >> >> Minor issues >> >> >> >> Section 1 >> >> >> >> You write "The asynchronous mode of BFD, as defined in [RFC5880], >> >> can be used to monitor a p2p VXLAN tunnel." >> >> >> >> Why do you use the word can ? It is a possibility or a requirement ? >> >> GIM>> In principle, BFD Demand mode may be used to monitor p2p paths >> as well, I agree, will re-word to more assertive: >> >> The asynchronous mode of BFD, as defined in [RFC5880], >> >> is used to monitor a p2p VXLAN tunnel. >> >> >> >> NVE has not been defined before and is not in the terminology. >> >> GIM>> Will add to the Terminology and expand as: >> >> NVE Network Virtualization Endpoint >> >> >> >> This entire section is not easy to read for an outsider. >> >> >> >> Section 3 >> >> >> >> VNI has not been defined >> >> GIM>> Will add to the Terminology section: >> >> VNI VXLAN Network Identifier (or VXLAN Segment ID) >> >> >> >> Figure 1 could take less space >> >> GIM>> Yes, can make it bit denser. Would the following be an >> improvement? >> >> >> >> +------------+-------------+ >> >> | Server 1 | >> >> | +----+----+ +----+----+ | >> >> | |VM1-1 | |VM1-2 | | >> >> | |VNI 100 | |VNI 200 | | >> >> | | | | | | >> >> | +---------+ +---------+ | >> >> | Hypervisor VTEP (IP1) | >> >> +--------------------------+ >> >> | >> >> | +-------------+ >> >> | | Layer 3 | >> >> +---| Network | >> >> +-------------+ >> >> | >> >> +-----------+ >> >> | >> >> +------------+-------------+ >> >> | Hypervisor VTEP (IP2) | >> >> | +----+----+ +----+----+ | >> >> | |VM2-1 | |VM2-2 | | >> >> | |VNI 100 | |VNI 200 | | >> >> | | | | | | >> >> | +---------+ +---------+ | >> >> | Server 2 | >> >> +--------------------------+ >> >> >> >> >> >> Section 4 >> >> >> >> I do not see the benefits of having one paragraph in Section 4 >> followed by only >> >> Section 4.1 >> >> GIM>> Will merge Section 4.1 into 4 with minor required re-wording: >> >> 4. BFD Packet Transmission over VXLAN Tunnel >> >> >> >> BFD packet MUST be encapsulated and sent to a remote VTEP as >> >> explained in this section. Implementations SHOULD ensure that the >> >> BFD packets follow the same lookup path as VXLAN data packets with= in >> >> the sender system. >> >> >> >> BFD packets are encapsulated in VXLAN as described below. The VXL= AN >> >> packet format is defined in Section 5 of [RFC7348]. The Outer >> IP/UDP >> >> and VXLAN headers MUST be encoded by the sender as defined in >> >> [RFC7348]. >> >> >> >> Section 4.1 >> >> >> >> The document does not specify when a dedicated MAC address or the MAC >> address >> >> of the destination VTEP must be used. This could affect the >> interoperability of >> >> implementations. Should all implementations support both the dedicate= d >> MAC >> >> address and the destination MAC address ? >> >> GIM>> After further discussion, authors decided to remove the request >> for the dedicated MAC address allocation. Only the MAC address of the >> remote VTEP must be used as the destination MAC address in the inner >> Ethernet frame. Please check the attached diff between the -07 and the >> working versions or the working version of the draft. >> >> >> >> It is unclear from this section whether IPv4 inside IPv6 and the >> opposite >> >> should be supported or not. >> >> GIM>> Any combination of outer IPvX and inner IPvX is possible. >> >> >> >> Section 5. >> >> >> >> If the received packet does not match the dedicated MAC address nor >> the MAC >> >> address of the VTEP, should the packet be silently discarded or treat= ed >> >> differently ? >> >> GIM>> As I've mentioned earlier, authors have decided to remove the >> use of the dedicated MAC address for BFD over VXLAN. >> >> >> >> Section 5.1 >> >> >> >> Is this a modification to section 6.3 of RFC5880 ? This is not clear >> >> GIM>> I think that this section is not modification but the definitio= n >> of the application-specific procedure that is outside the scope of RFC 5= 880: >> >> The method of demultiplexing the initial packets (in which Your >> >> Discriminator is zero) is application dependent, and is thus outsi= de >> >> the scope of this specification. >> >> >> >> Section 9 >> >> >> >> The sentence " Throttling MAY be relaxed for BFD packets >> >> based on port number." is unclear. >> >> GIM>> Yes, thank you for pointing to this. The updated text, in the >> whole paragraph, is as follows: >> >> NEW TEXT: >> >> The document requires setting the inner IP TTL to 1, which could b= e >> >> used as a DDoS attack vector. Thus the implementation MUST have >> >> throttling in place to control the rate of BFD control packets sen= t >> >> to the control plane. On the other hand, over aggressive throttli= ng >> >> of BFD control packets may become the cause of the inability to fo= rm >> >> and maintain BFD session at scale. Hence, throttling of BFD contr= ol >> >> packets SHOULD be adjusted to permit BFD to work according to its >> >> procedures. >> >> > draft-ietf-bfd-vxlan-08.txt.html> >> > >> >> > --00000000000036f10d058bba160b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Carlos,
could= you please refer me to the specification of BFD that defines the message f= ormat that is used in the Echo mode of BFD. Is it the BFD control packet? S= omething else?

Regards,
Greg


On Thu, Jun 20, 2019 at 11:09 AM= Carlos Pignataro (cpignata) <cpig= nata@cisco.com> wrote:
Hello, Greg,

Please see inline.

On Jun 19, 2019, at 9:58 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Hello Carlos,
thank you for the expedient clarification.
To your=C2=A0questions on demultiplexing BFD control packets with the = zero value of the Your Discriminator field:
  • only BFD control packets with the zero value of the Your Discriminator = field are demultiplexed using the information of the inner IP header. I bel= ieve that the text is clear and requires that all fields of the inner IP he= ader must be used to demultiplex a received BFD control packet with the zero value in the Your Discriminato= r field. Which of the fields an implementation uses to create multiple BFD = sessions between the pair of VTEPs is implementation specific.
This text is repeating was is in the draft, but does not answer any of= my questions.

For example:
1. "that all fields of the inner IP header must be used to demult= iplex a received BFD control packet=E2=80=9D
=C2=A0 =C2=A0 -> The text does not say =E2=80=9Call fields=E2=80=9D= , but regardless, do you mean the DSCP and the Evil Bit? IPv6 Flow Label? H= ow *exactly*?
2. How is the mapping of IP (not UDP?) fields to BFD session done?
3. How is this state created and maintained?=C2=A0
4. Since this is a set of fields on which two systems need to agree (w= hich fields from the inner IP/UDP are mapped needs to be understood by both= systems), it cannot be =E2=80=9Cimplementation specific=E2=80=9D. Further,= the text does not say so.

To your point on the level Echo mode of BFD is specified in RFC 5880 I= 'll quote the opinion of Jeffrey Haas from the discussion of comments f= rom Shawn Emery on behalf of the SecDir. Shawn had commented:
Echo BFD is= out of scope for the document, but does not describe the reason for this o= r why state
this at all= ?
I've responded:
GIM>> I think that the main reason is that the BFD Echo mode is = underspecified. RFC 5880 defined some of the mechanisms related to the Echo= mode, but more standardization work may be required.=C2=A0=C2=A0
And Jeffrey Haas had added:
Speaking as a BFD chair, this is the relevant observation.=C2=A0 BFD E= cho is
underspecified to the point where claiming compliance is difficult at = best.
In general, it relies on single-hop and the ability to have the remote= Echo
client loop the packets.=C2=A0

BFD Echo cannot be specified in RFC 5880 base spec because it is appli= cation specific.


This packet loop may not be practical for several encapsulations and t= hus is
out of scope for such encapsulations.=C2=A0 Whether this is practical = for vxlan
today, or in the presence of future extensions to vxlan is left out of= scope
for the core proposal.=C2=A0=C2=A0

The question remains: for VXLAN encapsulation, this is like a single h= op as far as BFD is concerned (single hop VXLAN tunnel).

Since RFC 5881 defines Echo for single hop, can you please elaborate (= in the document) why is out of scope or how it can work?

Best,

Carlos.


Will respond to other questions in a separate mail.

Regards,
Greg


On Thu, Jun 20, 2019 at 10:31 AM Carl= os Pignataro (cpignata) <cpignata@cisco.com> wrote:
Hello, Greg,

> On Jun 19, 2019, at 9:09 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
>
> Hi Carlos,
> thank you for reminding of our continued discussion with Joel. We are = seeking comments from VXLAN experts and much appreciate if you have insight= s on VXLAN to share.
> I've got some clarifying questions before I can respond to you.
Sure.

> To which stage of the three-way handshake you refer as "initial d= emultiplexing"? I couldn't find this term in RFC 5880.

=E2=80=9CInitial demultiplexing" is a well-known term in BFD, referrin= g to the "demultiplexing of the initial packets", BFD Control pac= ket with YourDisc being zero.

In RFC 5880, see Section 6.3.
https://tools.ietf.org/html/rfc5880#section-6.3
=C2=A0 =C2=A0The method of demultiplexing the initial packets (in which You= r
=C2=A0 =C2=A0Discriminator is zero) is application dependent, and is thus o= utside
=C2=A0 =C2=A0the scope of this specification.

Since initial demultiplexing is indeed application specific, different for = one-hop versus multi-hop and dependent upon whether a single or multiple se= ssions are allowed between a pair of endpoints, I added below two other rel= evant citations, from application specific BFD specs:
1. https://tools.ietf.org/html/rfc5883#section-4
2. https://tools.ietf.org/html/rfc5882#section-6


> Regarding the applicability of the Echo mode, thank you for pointing t= o the need for stricter terminology, the Echo mode, as defined in RFC 5880,= is underspecified and it will require additional standardization.

No. BFD Echo is not underspecified in RFC 5880.

Please read S5: https://tools.ietf.org/html/rfc5880#section-5

=C2=A0 =C2=A0BFD Echo packets are sent in an encapsulation appropriate to t= he
=C2=A0 =C2=A0environment.=C2=A0 See the appropriate application documents f= or the
=C2=A0 =C2=A0specifics of particular environments.


BFD Echo is application dependent.

Therefore, for example, single-hop BFD in RFC 5881 specifies BFD Echo for t= hat application.

Hence, my question stands: why is this draft claiming BFD Echo is out of sc= ope for this BFD application document?


> Future drafts may explore and define how the Echo mode of BFD is used = over VXLAN tunnels.
>

See above.

> Will review and respond to the remaining questions soon.

Thank you.

The "remaining questions" are still all the questions below :-)
Best,

Carlos.

>
> Regards,
> Greg
>
>
> On Thu, Jun 20, 2019 at 9:14 AM Carlos Pignataro (cpignata) <cpignata@cisco.com>= ; wrote:
> Hi,
>
> I have not reviewed this draft before, but triggered by this email, an= d briefly scanning through a couple of sections, it is unclear to me how so= me of the mechanics work.
>
> There are some major issues with the Mac usage and association, as Joe= l Halpern mentioned in his Rtg Dir review.
>
> And, additionally, please consider the following comments and question= s:
>
>
> 1. Underspecification for initialization and initial demultiplexing. >
> This document allows multiple BFD sessions between a single pair of VT= EPs:
>
>=C2=A0 =C2=A0 An
>=C2=A0 =C2=A0 implementation that supports this specification MUST be a= ble to
>=C2=A0 =C2=A0 control the number of BFD sessions that can be created be= tween the
>=C2=A0 =C2=A0 same pair of VTEPs.
>
> The implication of this is that BFD single-hop initialization procedur= es will not work. Instead, there is a need to map the initial demultiplexin= g.
>
> This issue is explained in RFCs 5882 and 5883: https://tools.ietf.org/html/rfc5883#section-4 and https://tools.ietf.org/html/rfc5882#section-6
>
> Section 5.1 says:
>
>=C2=A0 =C2=A0 For such packets, the BFD session MUST be identified
>=C2=A0 =C2=A0 using the inner headers, i.e., the source IP, the destina= tion IP, and
>=C2=A0 =C2=A0 the source UDP port number present in the IP header carri= ed by the
>=C2=A0 =C2=A0 payload of the VXLAN encapsulated packet.=C2=A0 The VNI o= f the packet
>=C2=A0 =C2=A0 SHOULD be used to derive interface-related information fo= r
>=C2=A0 =C2=A0 demultiplexing the packet.
>
> But this does not really explain how to do the initial demultiplexing.= Does each BFD session need to have a separate inner source IP address? Or = source UDP port? And how ofter are they recycled or kept as state? How are = these mapped?
> Equally importantly, which side is Active?
> And what if there=E2=80=99s a race condition with both sides being Act= ive and setting up redundant sessions?
>
> 1.b. By the way, based on this, using S-BFD [RFC 7880] might be easier= to demux.
>
>
> 2. Security
>
> This document says that the TTL in the inner packet carrying BFD is se= t to 1. However, RFC 5880 says to use GTSM [RFC 5082], i.e., a value of 255= ..
>
> Why is GTSM not used here?
>
>
> 3. ECMP and fate-sharing under-specification:
>
> Section 4.1. says:
>
>=C2=A0 =C2=A0 The Outer IP/UDP
>=C2=A0 =C2=A0 and VXLAN headers MUST be encoded by the sender as define= d in
>=C2=A0 =C2=A0 [RFC7348].
>
>
> And RFC 7348 says:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0 Source Port:=C2=A0 It is recommended= that the UDP source port number
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be calculated using a hash of fields= from the inner packet --
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 one example being a hash of the inne= r Ethernet frame's headers.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This is to enable a level of entropy= for the ECMP/load-
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 balancing of the VM-to-VM traffic ac= ross the VXLAN overlay.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 When calculating the UDP source port= number in this manner, it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is RECOMMENDED that the value be in = the dynamic/private port
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 range 49152-65535 [RFC6335].
>
>
> Based on this, depending on the hashing calculation, the outer source = UDP port can be different leading to different ECMP treatment. Does somethi= ng else need to be specified here in regards to the outer UDP source port?<= br> >
>
> 4. Section 7 says that =E2=80=9C Support for echo BFD is outside the s= cope of this document=E2=80=9D.
>
> Assuming this means =E2=80=9CBFD Echo mode=E2=80=9D, why is this out o= f scope? If this is a single logical hop underneath VXLAN, what=E2=80=99s p= reventing the use of Echo? Echo=E2=80=99s benefits are huge.
>
>
> 5. Terminology
>
>=C2=A0 =C2=A0 Implementations SHOULD ensure that the BFD
>=C2=A0 =C2=A0 packets follow the same lookup path as VXLAN data packets= within the
>=C2=A0 =C2=A0 sender system.
>
> What is a =E2=80=9Clook up path within a sender system=E2=80=9D?
>
>
> 6. Deployment scenarios
>
> S3 says:
>=C2=A0 =C2=A0 Figure 1 illustrates the scenario with two servers, each = of them
>=C2=A0 =C2=A0 hosting two VMs.=C2=A0 The servers host VTEPs that termin= ate two VXLAN
> [=E2=80=A6]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Figure 1: Reference VXLAN Domain
>
>
> However, RFC 7348 Figure 3 lists that as one deployment scenario, not = as =E2=80=9Cthe scenario=E2=80=9D and =E2=80=9CThe Reference VXLAN Domain= =E2=80=9D.
>
> Best,
>
> Carlos.
>
>> On Jun 17, 2019, at 12:58 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:=
>>
>> Hi Oliver,
>> thank you for your thorough review, clear and detailed questions. = My apologies for the delay to respond. Please find my answers below in-line= tagged GIM>>.
>>
>> Regards,
>> Greg
>>
>> On Fri, May 31, 2019 at 12:38 PM Olivier Bonaventure via Datatrack= er <noreply@ietf.o= rg> wrote:
>> Reviewer: Olivier Bonaventure
>> Review result: Ready with Issues
>>
>> This document has been reviewed as part of the transport area revi= ew team's
>> ongoing effort to review key IETF documents. These comments were w= ritten
>> primarily for the transport area directors, but are copied to the = document's
>> authors and WG to allow them to address any issues raised and also= to the IETF
>> discussion list for information.
>>
>> When done at the time of IETF Last Call, the authors should consid= er this
>> review as part of the last-call comments they receive. Please alwa= ys CC
>> tsv-art@ietf= .org if you reply to or forward this review.
>>
>> I have only limited knowledge of VXLAN and do not know all subtlet= ies of BFD.
>> This review is thus more from a generalist than a specialist in th= is topic.
>>
>> Major issues
>>
>> Section 4 requires that " Implementations SHOULD ensure that = the BFD
>>=C2=A0 =C2=A0 packets follow the same lookup path as VXLAN data pac= kets within the
>>=C2=A0 =C2=A0 sender system."
>>
>> Why is this requirement only relevant for the lookup path on the s= ender system
>> ? What does this sentence really implies ?
>> GIM>> RFC 5880 set the scope of the fault detection of BFD p= rotocol as
>>=C2=A0 =C2=A0 ... the bidirectional path between two forwarding eng= ines, including
>>=C2=A0 =C2=A0 interfaces, data link(s), and to the extent possible = the forwarding
>>=C2=A0 =C2=A0 engines themselves ...
>> The requirement aimed to the forwarding engine of a BFD system tha= t transmits BFD control packets over VXLAN tunnel.
>>
>> Is it a requirement that the BFD packets follow the same path as t= he data
>> packet for a given VXLAN ? I guess so. In this case, the document = should
>> discuss how Equal Cost Multipath could affect this.
>> GIM>> I think that ECMP environment is more likely to be exp= erienced by a transit node in the underlay. If the BFD session is used to m= onitor the specific underlay path, then, I agree, we should explain that us= ing the VXLAN payload information to draw path entropy may cause data and BFD packets following different underlay routes= . But, on the other hand, that is the case for OAM and fault detection in a= ll overlay networks in general.
>>
>> Minor issues
>>
>> Section 1
>>
>> You write "The asynchronous mode of BFD, as defined in [RFC58= 80],
>>=C2=A0 can be used to monitor a p2p VXLAN tunnel."
>>
>> Why do you use the word can ? It is a possibility or a requirement= ?
>> GIM>> In principle, BFD Demand mode may be used to monitor p= 2p paths as well, I agree, will re-word to more assertive:
>>=C2=A0 The asynchronous mode of BFD, as defined in [RFC5880],
>>=C2=A0 is used to monitor a p2p VXLAN tunnel.
>>
>> NVE has not been defined before and is not in the terminology.
>> GIM>> Will add to the Terminology and expand as:
>> NVE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Network Virtualization Endpoint >>
>> This entire section is not easy to read for an outsider.
>>
>> Section 3
>>
>> VNI has not been defined
>> GIM>> Will add to the Terminology section:
>> VNI=C2=A0 =C2=A0 VXLAN Network Identifier (or VXLAN Segment ID) >>
>> Figure 1 could take less space
>> GIM>> Yes, can make it bit denser. Would the following be an= improvement?
>>=C2=A0
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0+------------+-------------+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 Server 1=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0| +----+----+=C2=A0 +----+----+ |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0| |VM1-1=C2=A0 =C2=A0 |=C2=A0 |VM1-2=C2= =A0 =C2=A0 | |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0| |VNI 100=C2=A0 |=C2=A0 |VNI 200=C2=A0 = | |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0| |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0| +---------+=C2=A0 +---------+ |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0| Hypervisor VTEP (IP1)=C2=A0 =C2=A0 | >>=C2=A0 =C2=A0 =C2=A0 =C2=A0+--------------------------+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0+-------------+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0|=C2=A0 =C2=A0Layer 3= =C2=A0 =C2=A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---|=C2=A0 =C2=A0Network=C2=A0 =C2= =A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-------------+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------= ---+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 +------------+-------------+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 Hypervisor VTEP (IP2) |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | +----+----+=C2=A0 +----+----+ |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | |VM2-1=C2=A0 =C2=A0 |=C2=A0 |VM2-2=C2=A0 =C2=A0 | |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | |VNI 100=C2=A0 |=C2=A0 |VNI 200=C2=A0 | |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | +---------+=C2=A0 +---------+ |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 Server 2=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 +--------------------------+
>>
>>
>> Section 4
>>
>> I do not see the benefits of having one paragraph in Section 4 fol= lowed by only
>> Section 4.1
>> GIM>> Will merge Section 4.1 into 4 with minor required re-w= ording:
>> 4.=C2=A0 BFD Packet Transmission over VXLAN Tunnel
>>
>>=C2=A0 =C2=A0 BFD packet MUST be encapsulated and sent to a remote = VTEP as
>>=C2=A0 =C2=A0 explained in this section.=C2=A0 Implementations SHOU= LD ensure that the
>>=C2=A0 =C2=A0 BFD packets follow the same lookup path as VXLAN data= packets within
>>=C2=A0 =C2=A0 the sender system.
>>
>>=C2=A0 =C2=A0 BFD packets are encapsulated in VXLAN as described be= low.=C2=A0 The VXLAN
>>=C2=A0 =C2=A0 packet format is defined in Section 5 of [RFC7348].= =C2=A0 The Outer IP/UDP
>>=C2=A0 =C2=A0 and VXLAN headers MUST be encoded by the sender as de= fined in
>>=C2=A0 =C2=A0 [RFC7348].
>>
>> Section 4.1
>>
>> The document does not specify when a dedicated MAC address or the = MAC address
>> of the destination VTEP must be used. This could affect the intero= perability of
>> implementations. Should all implementations support both the dedic= ated MAC
>> address and the destination MAC address ?
>> GIM>> After further discussion, authors decided to remove th= e request for the dedicated MAC address allocation. Only the MAC address of= the remote VTEP must be used as the destination MAC address in the inner E= thernet frame. Please check the attached diff between the -07 and the working versions or the working version of the dra= ft.
>>
>> It is unclear from this section whether IPv4 inside IPv6 and the o= pposite
>> should be supported or not.
>> GIM>> Any combination of outer IPvX and inner IPvX is possib= le.
>>
>> Section 5.
>>
>> If the received packet does not match the dedicated MAC address no= r the MAC
>> address of the VTEP, should the packet be silently discarded or tr= eated
>> differently ?
>> GIM>> As I've mentioned earlier, authors have decided to= remove the use of the dedicated MAC address for BFD over VXLAN.
>>
>> Section 5.1
>>
>> Is this a modification to section 6.3 of RFC5880 ? This is not cle= ar
>> GIM>> I think that this section is not modification but the = definition of the application-specific procedure that is outside the scope = of RFC 5880:
>>=C2=A0 =C2=A0 The method of demultiplexing the initial packets (in = which Your
>>=C2=A0 =C2=A0 Discriminator is zero) is application dependent, and = is thus outside
>>=C2=A0 =C2=A0 the scope of this specification.
>>
>> Section 9
>>
>> The sentence " Throttling MAY be relaxed for BFD packets
>>=C2=A0 =C2=A0 based on port number." is unclear.
>> GIM>> Yes, thank you for pointing to this. The updated text,= in the whole paragraph, is as follows:
>> NEW TEXT:
>>=C2=A0 =C2=A0 The document requires setting the inner IP TTL to 1, = which could be
>>=C2=A0 =C2=A0 used as a DDoS attack vector.=C2=A0 Thus the implemen= tation MUST have
>>=C2=A0 =C2=A0 throttling in place to control the rate of BFD contro= l packets sent
>>=C2=A0 =C2=A0 to the control plane.=C2=A0 On the other hand, over a= ggressive throttling
>>=C2=A0 =C2=A0 of BFD control packets may become the cause of the in= ability to form
>>=C2=A0 =C2=A0 and maintain BFD session at scale.=C2=A0 Hence, throt= tling of BFD control
>>=C2=A0 =C2=A0 packets SHOULD be adjusted to permit BFD to work acco= rding to its
>>=C2=A0 =C2=A0 procedures.
>> <draft-ietf-bfd-vxlan-08.txt><Diff_ draft-ietf-bfd-vxlan-= 07.txt - draft-ietf-bfd-vxlan-08.txt.html>
>


--00000000000036f10d058bba160b-- From nobody Thu Jun 20 05:03:46 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB632120440; Wed, 19 Jun 2019 22:09:04 -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, 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 header.b=Ly2K2Yf6; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=jX5D4Onr 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 72mntwOb-HrE; Wed, 19 Jun 2019 22:09:00 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF43E120436; Wed, 19 Jun 2019 22:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=75001; q=dns/txt; s=iport; t=1561007340; x=1562216940; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zV8nyJprdPef0Gi6mNSKb2vi5vcKHVyxSE90j+WD2Bs=; b=Ly2K2Yf66YvWe49k1ZPAW/J505hmT/5C7fxRPbB5CdoCOyWcn+FN3fD9 WOpiWoptsQAQa2SdMRrg9/MFX6REi8yBuC5aREvtKnSDBJDYsrASKjc/j 6wPHYgmp9t8zk7Da02brdaIQl/p2UsShL9jcpOwBCso3TOiyeF8FJVrZX Y=; IronPort-PHdr: =?us-ascii?q?9a23=3AO0ggEhEPJAsVOyToQaSRPp1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+efXybiM8FdhLfFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BOAQAuFAtd/5ldJa1mHAEBAQQBAQc?= =?us-ascii?q?EAQGBVgQBAQsBgRQvJAUnA2pVIAQLKAqEDINHA45ggleJRY1ygUKBEANUCQE?= =?us-ascii?q?BAQwBASMKAgEBhEACF4JBIzcGDgEDAQEEAQECAQVtijcMhUoBAQEDARIIAQg?= =?us-ascii?q?EGQEBJQQJBQEECwIBCBggAQIEAwICAh8RFBECBA4FIoMAAYEdTQMODwECDKF?= =?us-ascii?q?4AoE4iF9xfjOCeQEBBYUADQuCEAMGgTQBhHCEJIEegSsXgUA/gRABJx+CTD6?= =?us-ascii?q?CGkcBAQIBgSoBAQsGAgEIFQgQFQELglIygiaLdS0CgXAuhHeITox/LD4JAoI?= =?us-ascii?q?RhkiJIASDaRuCJ4cJhAqFYYJSgUyURoFrilSDCAIEAgQFAg4BAQWBZiJncXA?= =?us-ascii?q?VOyoBgkE+ggMLARcUbgEIgkKFFIU+AXIBgSiLW4ExAYEgAQE?= X-IronPort-AV: E=Sophos;i="5.63,395,1557187200"; d="scan'208,217";a="581116968" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Jun 2019 05:08:57 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x5K58vh0011178 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 20 Jun 2019 05:08:57 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 20 Jun 2019 00:08:56 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 20 Jun 2019 01:08:55 -0400 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 20 Jun 2019 00:08:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zV8nyJprdPef0Gi6mNSKb2vi5vcKHVyxSE90j+WD2Bs=; b=jX5D4OnrZRWzcO2biPt6rsENobohH3Bz2wSc4fzRcVDPRXe4dfk0RMOEIt7xr7M9rrRNhU21rXs70rKicOUcDHTMQRsIJk6qigVvO5YBVaWAUV7jnLKSkQAywB5oO9xL8pQhYWGUj43ZKX7KvvlZBzis5olmaBzIm1/KJ9NvlaM= Received: from SN6PR11MB3039.namprd11.prod.outlook.com (52.135.125.219) by SN6PR11MB2638.namprd11.prod.outlook.com (52.135.91.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.15; Thu, 20 Jun 2019 05:08:54 +0000 Received: from SN6PR11MB3039.namprd11.prod.outlook.com ([fe80::a911:c01b:d59:f15d]) by SN6PR11MB3039.namprd11.prod.outlook.com ([fe80::a911:c01b:d59:f15d%6]) with mapi id 15.20.1987.014; Thu, 20 Jun 2019 05:08:54 +0000 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: "tsv-art@ietf.org" , rtg-bfd WG , "draft-ietf-bfd-vxlan.all@ietf.org" , Olivier Bonaventure , IETF list Subject: Re: Level of standardization of the Echo mode of BFD [Re: Tsvart last call review of draft-ietf-bfd-vxlan-07] Thread-Topic: Level of standardization of the Echo mode of BFD [Re: Tsvart last call review of draft-ietf-bfd-vxlan-07] Thread-Index: AQHVJyO4ZUHeu4GAiUWD+HbCVzn3tKaj/jqA Date: Thu, 20 Jun 2019 05:08:54 +0000 Message-ID: References: <155933149484.6565.7386019489022348116@ietfa.amsl.com> <14822B96-D3C6-495E-8661-198068F72ABA@cisco.com> <8237FE8D-937E-4BCB-B1A3-89C2B3CDC51C@cisco.com> <0B9FDA17-7F13-4FEC-AE97-40BC9D72C87B@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.11) authentication-results: spf=none (sender IP is ) smtp.mailfrom=cpignata@cisco.com; x-originating-ip: [173.38.117.68] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 41d12be9-ac2b-4bb1-a36d-08d6f53d646a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:SN6PR11MB2638; x-ms-traffictypediagnostic: SN6PR11MB2638: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0074BBE012 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(136003)(39860400002)(396003)(189003)(199004)(51444003)(73956011)(54906003)(3846002)(99286004)(102836004)(68736007)(5660300002)(6116002)(14444005)(316002)(76176011)(2906002)(6506007)(30864003)(561944003)(5024004)(14454004)(8936002)(256004)(6436002)(478600001)(6512007)(33656002)(36756003)(966005)(81166006)(57306001)(53936002)(71200400001)(7736002)(8676002)(229853002)(6916009)(50226002)(64756008)(76116006)(53946003)(53546011)(1411001)(6306002)(54896002)(2616005)(606006)(236005)(6486002)(6246003)(446003)(66476007)(26005)(11346002)(476003)(5070765005)(486006)(66446008)(66946007)(4326008)(186003)(91956017)(66556008)(86362001)(25786009)(66066001)(71190400001)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR11MB2638; H:SN6PR11MB3039.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: Cm48rd4bVj16hUOQSCCobgTPPyz//FngN+2qNM2zkEzJS34nGMBQPP9r2Cvst+7DX2CIat1SvFaA6IBiSI1ZBhicQsuRSTFu6dC1fWH89h4DuRTMZLHPXz4cDvGA+kJUe9a9/0jLgrfdasFA3hNM8Z8/ikSLGHoI/s/3JpNzpF25rt2vEy1yES659A4GPwM70Npne+xbRSDYQkxkubkQzdy7+sirJ3XC0KZXlud7D98BRui5xqTd7wDUo6/oaAmI+TLZT+IZZ5JgkCpq3dAsMX7y4iW9/QgdlV5q8htSEjvl8JlLVlJ9LdnggZQpN+U/g+rhFMFpEWsHvZ4Rj7/0qU9vRSzaNW5Uy3F7f4wk2/ghE7tMou+aDh/eZqybiqIVL6mpIZNrYEgspxgq7IrhhLAo4TYZDZBU6/4UF0DI3Ao= Content-Type: multipart/alternative; boundary="_000_BADB8CA6FCAC47A38B06F82E98A89549ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 41d12be9-ac2b-4bb1-a36d-08d6f53d646a X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jun 2019 05:08:54.5224 (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-CrossTenant-userprincipalname: cpignata@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2638 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.24, xch-aln-014.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: X-Mailman-Approved-At: Thu, 20 Jun 2019 05:03:36 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 05:09:05 -0000 --_000_BADB8CA6FCAC47A38B06F82E98A89549ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sIEdyZWcsDQoNClllcywgaGFwcHkgdG9vIGFuc3dlciB5b3VyIHF1ZXN0aW9uLg0KDQpG aXJzdCwgaG93ZXZlciwgbGV0IG1lIG1ha2UgdHdvIHF1aWNrIG9ic2VydmF0aW9ucyBvbiB0aGUg ZXhjaGFuZ2U6DQoNCiAgMS4gIFlvdSBzZWVtIHRvIGJlIHBpY2tpbmcgdmVyeSBzcGVjaWZpYyBm cmFnbWVudHMgb3Igc3ViLXRvcGljcyBmcm9tIG15IGNvbW1lbnRzLCBhbmQgZm9sbG93aW5nIHVw IG9uIHRob3NlIG9ubHkuDQogIDIuICBJ4oCZbSBoYXBweSB0byBjb250aW51ZSBhbnN3ZXJpbmcg dGhlc2UgcXVlc3Rpb25zLCBidXQgdGhleSBhcmUgb3J0aG9nb25hbCB0byAoYW5kIGNvbnNlcXVl bnRseSBhIGRpc3RyYWN0aW9uIGZyb20pIHRoZSBpbml0aWFsIGNvbW1lbnRzIEkgcmFpc2VkLg0K DQpOb3csIHlvdXIgcXVlc3Rpb246IHRoZSBCRkQgRWNobyBwYWNrZXQgZm9ybWF0IGlzIGdlbmVy aWNhbGx5IHNwZWPigJllZCBhbmQgZGVmaW5lZCBpbiBTZWN0aW9uIDUgb2YgUkZDIDU4ODA6DQpo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTg4MCNzZWN0aW9uLTUNCg0KVGhlIG1vc3Qg cmVsZXZhbnQgcGFydCBpcyB0aGlzOg0KDQogICBUaGUgcGF5bG9hZCBvZiBhIEJGRCBFY2hvIHBh Y2tldCBpcyBhIGxvY2FsIG1hdHRlciwgc2luY2Ugb25seSB0aGUNCiAgIHNlbmRpbmcgc3lzdGVt IGV2ZXIgcHJvY2Vzc2VzIHRoZSBjb250ZW50LiAgVGhlIG9ubHkgcmVxdWlyZW1lbnQgaXMNCiAg IHRoYXQgc3VmZmljaWVudCBpbmZvcm1hdGlvbiBpcyBpbmNsdWRlZCB0byBkZW11bHRpcGxleCB0 aGUgcmVjZWl2ZWQNCiAgIHBhY2tldCB0byB0aGUgY29ycmVjdCBCRkQgc2Vzc2lvbiBhZnRlciBp dCBpcyBsb29wZWQgYmFjayB0byB0aGUNCiAgIHNlbmRlci4NCg0KU2luY2UgdGhlIHJlbW90ZSBz eXN0ZW0gZG9lcyBub3QgcHJvY2VzcyB0aGUgZWNobyBwYWNrZXQgY29udGVudCwgaXQgaXMgYSBs b2NhbCBtYXR0ZXIgb25seS4gQW5kIGdpdmVuIHRoZSBmYWN0IHRoYXQsIGFzIHN1Y2gsIHRoZXJl IGlzIG5vIGludGVyb3BlcmFiaWxpdHkgaW1wbGljYXRpb25zLCB0aGVyZSBpcyBubyBuZWVkIHRv IG92ZXItc3BlY2lmeSB0aGUgcGFja2V0IGZvcm1hdC4gVGhlIG9ubHkgcmVxdWlyZW1lbnQgaXMg dGhhdCB0aGUgc2VuZGluZyBzeXN0ZW0gbmVlZHMgdG8gYmUgYWJsZSB0byBtYXAgaXQgdG8gYSBz ZXNzaW9uIHdoZW4gaXQgYm9vbWVyYW5ncyBiYWNrLg0KDQpObywgaXQgaXMgZ2VuZXJhbGx5IG5v dCAoaS5lLiwgZG9lcyBub3QgbmVlZCB0byBiZSwgYnV0IHRoZXJl4oCZcyBmcmVlZG9tIHRvIHBv dGVudGlhbGx5IGJlKSBhIEJGRCBjb250cm9sIHBhY2tldC4NClllcywgaXQgY2FuIGJlIHNvbWV0 aGluZyBlbHNlLg0KDQpUaGF0IHNhaWQsIHRoZSBwYWNrZXQgZm9ybWF0IGZvciBCRkQgRWNobyBo YXMsIHRvIG15IGFuYWx5c2lzIGFuZCB1bmRlcnN0YW5kaW5nLCBubyByZWxldmFuY3kgb24gdGhl IHF1ZXN0aW9ucyBiZWxvdy4NCg0KQmVzdCwNCg0KQ2FybG9zLg0KDQpPbiBKdW4gMjAsIDIwMTks IGF0IDEyOjUwIEFNLCBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPG1haWx0bzpn cmVnaW1pcnNreUBnbWFpbC5jb20+PiB3cm90ZToNCg0KSGVsbG8gQ2FybG9zLA0KY291bGQgeW91 IHBsZWFzZSByZWZlciBtZSB0byB0aGUgc3BlY2lmaWNhdGlvbiBvZiBCRkQgdGhhdCBkZWZpbmVz IHRoZSBtZXNzYWdlIGZvcm1hdCB0aGF0IGlzIHVzZWQgaW4gdGhlIEVjaG8gbW9kZSBvZiBCRkQu IElzIGl0IHRoZSBCRkQgY29udHJvbCBwYWNrZXQ/IFNvbWV0aGluZyBlbHNlPw0KDQpSZWdhcmRz LA0KR3JlZw0KDQoNCk9uIFRodSwgSnVuIDIwLCAyMDE5IGF0IDExOjA5IEFNIENhcmxvcyBQaWdu YXRhcm8gKGNwaWduYXRhKSA8Y3BpZ25hdGFAY2lzY28uY29tPG1haWx0bzpjcGlnbmF0YUBjaXNj by5jb20+PiB3cm90ZToNCkhlbGxvLCBHcmVnLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KT24g SnVuIDE5LCAyMDE5LCBhdCA5OjU4IFBNLCBHcmVnIE1pcnNreSA8Z3JlZ2ltaXJza3lAZ21haWwu Y29tPG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+PiB3cm90ZToNCg0KSGVsbG8gQ2FybG9z LA0KdGhhbmsgeW91IGZvciB0aGUgZXhwZWRpZW50IGNsYXJpZmljYXRpb24uDQpUbyB5b3VyIHF1 ZXN0aW9ucyBvbiBkZW11bHRpcGxleGluZyBCRkQgY29udHJvbCBwYWNrZXRzIHdpdGggdGhlIHpl cm8gdmFsdWUgb2YgdGhlIFlvdXIgRGlzY3JpbWluYXRvciBmaWVsZDoNCg0KICAqICAgb25seSBC RkQgY29udHJvbCBwYWNrZXRzIHdpdGggdGhlIHplcm8gdmFsdWUgb2YgdGhlIFlvdXIgRGlzY3Jp bWluYXRvciBmaWVsZCBhcmUgZGVtdWx0aXBsZXhlZCB1c2luZyB0aGUgaW5mb3JtYXRpb24gb2Yg dGhlIGlubmVyIElQIGhlYWRlci4gSSBiZWxpZXZlIHRoYXQgdGhlIHRleHQgaXMgY2xlYXIgYW5k IHJlcXVpcmVzIHRoYXQgYWxsIGZpZWxkcyBvZiB0aGUgaW5uZXIgSVAgaGVhZGVyIG11c3QgYmUg dXNlZCB0byBkZW11bHRpcGxleCBhIHJlY2VpdmVkIEJGRCBjb250cm9sIHBhY2tldCB3aXRoIHRo ZSB6ZXJvIHZhbHVlIGluIHRoZSBZb3VyIERpc2NyaW1pbmF0b3IgZmllbGQuIFdoaWNoIG9mIHRo ZSBmaWVsZHMgYW4gaW1wbGVtZW50YXRpb24gdXNlcyB0byBjcmVhdGUgbXVsdGlwbGUgQkZEIHNl c3Npb25zIGJldHdlZW4gdGhlIHBhaXIgb2YgVlRFUHMgaXMgaW1wbGVtZW50YXRpb24gc3BlY2lm aWMuDQoNClRoaXMgdGV4dCBpcyByZXBlYXRpbmcgd2FzIGlzIGluIHRoZSBkcmFmdCwgYnV0IGRv ZXMgbm90IGFuc3dlciBhbnkgb2YgbXkgcXVlc3Rpb25zLg0KDQpGb3IgZXhhbXBsZToNCjEuICJ0 aGF0IGFsbCBmaWVsZHMgb2YgdGhlIGlubmVyIElQIGhlYWRlciBtdXN0IGJlIHVzZWQgdG8gZGVt dWx0aXBsZXggYSByZWNlaXZlZCBCRkQgY29udHJvbCBwYWNrZXTigJ0NCiAgICAtPiBUaGUgdGV4 dCBkb2VzIG5vdCBzYXkg4oCcYWxsIGZpZWxkc+KAnSwgYnV0IHJlZ2FyZGxlc3MsIGRvIHlvdSBt ZWFuIHRoZSBEU0NQIGFuZCB0aGUgRXZpbCBCaXQ/IElQdjYgRmxvdyBMYWJlbD8gSG93ICpleGFj dGx5Kj8NCjIuIEhvdyBpcyB0aGUgbWFwcGluZyBvZiBJUCAobm90IFVEUD8pIGZpZWxkcyB0byBC RkQgc2Vzc2lvbiBkb25lPw0KMy4gSG93IGlzIHRoaXMgc3RhdGUgY3JlYXRlZCBhbmQgbWFpbnRh aW5lZD8NCjQuIFNpbmNlIHRoaXMgaXMgYSBzZXQgb2YgZmllbGRzIG9uIHdoaWNoIHR3byBzeXN0 ZW1zIG5lZWQgdG8gYWdyZWUgKHdoaWNoIGZpZWxkcyBmcm9tIHRoZSBpbm5lciBJUC9VRFAgYXJl IG1hcHBlZCBuZWVkcyB0byBiZSB1bmRlcnN0b29kIGJ5IGJvdGggc3lzdGVtcyksIGl0IGNhbm5v dCBiZSDigJxpbXBsZW1lbnRhdGlvbiBzcGVjaWZpY+KAnS4gRnVydGhlciwgdGhlIHRleHQgZG9l cyBub3Qgc2F5IHNvLg0KDQpUbyB5b3VyIHBvaW50IG9uIHRoZSBsZXZlbCBFY2hvIG1vZGUgb2Yg QkZEIGlzIHNwZWNpZmllZCBpbiBSRkMgNTg4MCBJJ2xsIHF1b3RlIHRoZSBvcGluaW9uIG9mIEpl ZmZyZXkgSGFhcyBmcm9tIHRoZSBkaXNjdXNzaW9uIG9mIGNvbW1lbnRzIGZyb20gU2hhd24gRW1l cnkgb24gYmVoYWxmIG9mIHRoZSBTZWNEaXIuIFNoYXduIGhhZCBjb21tZW50ZWQ6DQpFY2hvIEJG RCBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRoZSBkb2N1bWVudCwgYnV0IGRvZXMgbm90IGRlc2NyaWJl IHRoZSByZWFzb24gZm9yIHRoaXMgb3Igd2h5IHN0YXRlDQp0aGlzIGF0IGFsbD8NCkkndmUgcmVz cG9uZGVkOg0KR0lNPj4gSSB0aGluayB0aGF0IHRoZSBtYWluIHJlYXNvbiBpcyB0aGF0IHRoZSBC RkQgRWNobyBtb2RlIGlzIHVuZGVyc3BlY2lmaWVkLiBSRkMgNTg4MCBkZWZpbmVkIHNvbWUgb2Yg dGhlIG1lY2hhbmlzbXMgcmVsYXRlZCB0byB0aGUgRWNobyBtb2RlLCBidXQgbW9yZSBzdGFuZGFy ZGl6YXRpb24gd29yayBtYXkgYmUgcmVxdWlyZWQuDQpBbmQgSmVmZnJleSBIYWFzIGhhZCBhZGRl ZDoNClNwZWFraW5nIGFzIGEgQkZEIGNoYWlyLCB0aGlzIGlzIHRoZSByZWxldmFudCBvYnNlcnZh dGlvbi4gIEJGRCBFY2hvIGlzDQp1bmRlcnNwZWNpZmllZCB0byB0aGUgcG9pbnQgd2hlcmUgY2xh aW1pbmcgY29tcGxpYW5jZSBpcyBkaWZmaWN1bHQgYXQgYmVzdC4NCkluIGdlbmVyYWwsIGl0IHJl bGllcyBvbiBzaW5nbGUtaG9wIGFuZCB0aGUgYWJpbGl0eSB0byBoYXZlIHRoZSByZW1vdGUgRWNo bw0KY2xpZW50IGxvb3AgdGhlIHBhY2tldHMuDQoNCkJGRCBFY2hvIGNhbm5vdCBiZSBzcGVjaWZp ZWQgaW4gUkZDIDU4ODAgYmFzZSBzcGVjIGJlY2F1c2UgaXQgaXMgYXBwbGljYXRpb24gc3BlY2lm aWMuDQoNCg0KVGhpcyBwYWNrZXQgbG9vcCBtYXkgbm90IGJlIHByYWN0aWNhbCBmb3Igc2V2ZXJh bCBlbmNhcHN1bGF0aW9ucyBhbmQgdGh1cyBpcw0Kb3V0IG9mIHNjb3BlIGZvciBzdWNoIGVuY2Fw c3VsYXRpb25zLiAgV2hldGhlciB0aGlzIGlzIHByYWN0aWNhbCBmb3IgdnhsYW4NCnRvZGF5LCBv ciBpbiB0aGUgcHJlc2VuY2Ugb2YgZnV0dXJlIGV4dGVuc2lvbnMgdG8gdnhsYW4gaXMgbGVmdCBv dXQgb2Ygc2NvcGUNCmZvciB0aGUgY29yZSBwcm9wb3NhbC4NCg0KVGhlIHF1ZXN0aW9uIHJlbWFp bnM6IGZvciBWWExBTiBlbmNhcHN1bGF0aW9uLCB0aGlzIGlzIGxpa2UgYSBzaW5nbGUgaG9wIGFz IGZhciBhcyBCRkQgaXMgY29uY2VybmVkIChzaW5nbGUgaG9wIFZYTEFOIHR1bm5lbCkuDQoNClNp bmNlIFJGQyA1ODgxIGRlZmluZXMgRWNobyBmb3Igc2luZ2xlIGhvcCwgY2FuIHlvdSBwbGVhc2Ug ZWxhYm9yYXRlIChpbiB0aGUgZG9jdW1lbnQpIHdoeSBpcyBvdXQgb2Ygc2NvcGUgb3IgaG93IGl0 IGNhbiB3b3JrPw0KDQpCZXN0LA0KDQpDYXJsb3MuDQoNCg0KV2lsbCByZXNwb25kIHRvIG90aGVy IHF1ZXN0aW9ucyBpbiBhIHNlcGFyYXRlIG1haWwuDQoNClJlZ2FyZHMsDQpHcmVnDQoNCg0KT24g VGh1LCBKdW4gMjAsIDIwMTkgYXQgMTA6MzEgQU0gQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEp IDxjcGlnbmF0YUBjaXNjby5jb208bWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbT4+IHdyb3RlOg0K SGVsbG8sIEdyZWcsDQoNCj4gT24gSnVuIDE5LCAyMDE5LCBhdCA5OjA5IFBNLCBHcmVnIE1pcnNr eSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPG1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20+PiB3 cm90ZToNCj4NCj4gSGkgQ2FybG9zLA0KPiB0aGFuayB5b3UgZm9yIHJlbWluZGluZyBvZiBvdXIg Y29udGludWVkIGRpc2N1c3Npb24gd2l0aCBKb2VsLiBXZSBhcmUgc2Vla2luZyBjb21tZW50cyBm cm9tIFZYTEFOIGV4cGVydHMgYW5kIG11Y2ggYXBwcmVjaWF0ZSBpZiB5b3UgaGF2ZSBpbnNpZ2h0 cyBvbiBWWExBTiB0byBzaGFyZS4NCj4gSSd2ZSBnb3Qgc29tZSBjbGFyaWZ5aW5nIHF1ZXN0aW9u cyBiZWZvcmUgSSBjYW4gcmVzcG9uZCB0byB5b3UuDQoNClN1cmUuDQoNCj4gVG8gd2hpY2ggc3Rh Z2Ugb2YgdGhlIHRocmVlLXdheSBoYW5kc2hha2UgeW91IHJlZmVyIGFzICJpbml0aWFsIGRlbXVs dGlwbGV4aW5nIj8gSSBjb3VsZG4ndCBmaW5kIHRoaXMgdGVybSBpbiBSRkMgNTg4MC4NCg0K4oCc SW5pdGlhbCBkZW11bHRpcGxleGluZyIgaXMgYSB3ZWxsLWtub3duIHRlcm0gaW4gQkZELCByZWZl cnJpbmcgdG8gdGhlICJkZW11bHRpcGxleGluZyBvZiB0aGUgaW5pdGlhbCBwYWNrZXRzIiwgQkZE IENvbnRyb2wgcGFja2V0IHdpdGggWW91ckRpc2MgYmVpbmcgemVyby4NCg0KSW4gUkZDIDU4ODAs IHNlZSBTZWN0aW9uIDYuMy4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1ODgwI3Nl Y3Rpb24tNi4zDQoNCiAgIFRoZSBtZXRob2Qgb2YgZGVtdWx0aXBsZXhpbmcgdGhlIGluaXRpYWwg cGFja2V0cyAoaW4gd2hpY2ggWW91cg0KICAgRGlzY3JpbWluYXRvciBpcyB6ZXJvKSBpcyBhcHBs aWNhdGlvbiBkZXBlbmRlbnQsIGFuZCBpcyB0aHVzIG91dHNpZGUNCiAgIHRoZSBzY29wZSBvZiB0 aGlzIHNwZWNpZmljYXRpb24uDQoNClNpbmNlIGluaXRpYWwgZGVtdWx0aXBsZXhpbmcgaXMgaW5k ZWVkIGFwcGxpY2F0aW9uIHNwZWNpZmljLCBkaWZmZXJlbnQgZm9yIG9uZS1ob3AgdmVyc3VzIG11 bHRpLWhvcCBhbmQgZGVwZW5kZW50IHVwb24gd2hldGhlciBhIHNpbmdsZSBvciBtdWx0aXBsZSBz ZXNzaW9ucyBhcmUgYWxsb3dlZCBiZXR3ZWVuIGEgcGFpciBvZiBlbmRwb2ludHMsIEkgYWRkZWQg YmVsb3cgdHdvIG90aGVyIHJlbGV2YW50IGNpdGF0aW9ucywgZnJvbSBhcHBsaWNhdGlvbiBzcGVj aWZpYyBCRkQgc3BlY3M6DQoxLiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTg4MyNz ZWN0aW9uLTQNCjIuIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1ODgyI3NlY3Rpb24t Ng0KDQoNCj4gUmVnYXJkaW5nIHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoZSBFY2hvIG1vZGUsIHRo YW5rIHlvdSBmb3IgcG9pbnRpbmcgdG8gdGhlIG5lZWQgZm9yIHN0cmljdGVyIHRlcm1pbm9sb2d5 LCB0aGUgRWNobyBtb2RlLCBhcyBkZWZpbmVkIGluIFJGQyA1ODgwLCBpcyB1bmRlcnNwZWNpZmll ZCBhbmQgaXQgd2lsbCByZXF1aXJlIGFkZGl0aW9uYWwgc3RhbmRhcmRpemF0aW9uLg0KDQpOby4g QkZEIEVjaG8gaXMgbm90IHVuZGVyc3BlY2lmaWVkIGluIFJGQyA1ODgwLg0KDQpQbGVhc2UgcmVh ZCBTNTogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU4ODAjc2VjdGlvbi01DQoNCiAg IEJGRCBFY2hvIHBhY2tldHMgYXJlIHNlbnQgaW4gYW4gZW5jYXBzdWxhdGlvbiBhcHByb3ByaWF0 ZSB0byB0aGUNCiAgIGVudmlyb25tZW50LiAgU2VlIHRoZSBhcHByb3ByaWF0ZSBhcHBsaWNhdGlv biBkb2N1bWVudHMgZm9yIHRoZQ0KICAgc3BlY2lmaWNzIG9mIHBhcnRpY3VsYXIgZW52aXJvbm1l bnRzLg0KDQoNCkJGRCBFY2hvIGlzIGFwcGxpY2F0aW9uIGRlcGVuZGVudC4NCg0KVGhlcmVmb3Jl LCBmb3IgZXhhbXBsZSwgc2luZ2xlLWhvcCBCRkQgaW4gUkZDIDU4ODEgc3BlY2lmaWVzIEJGRCBF Y2hvIGZvciB0aGF0IGFwcGxpY2F0aW9uLg0KDQpIZW5jZSwgbXkgcXVlc3Rpb24gc3RhbmRzOiB3 aHkgaXMgdGhpcyBkcmFmdCBjbGFpbWluZyBCRkQgRWNobyBpcyBvdXQgb2Ygc2NvcGUgZm9yIHRo aXMgQkZEIGFwcGxpY2F0aW9uIGRvY3VtZW50Pw0KDQoNCj4gRnV0dXJlIGRyYWZ0cyBtYXkgZXhw bG9yZSBhbmQgZGVmaW5lIGhvdyB0aGUgRWNobyBtb2RlIG9mIEJGRCBpcyB1c2VkIG92ZXIgVlhM QU4gdHVubmVscy4NCj4NCg0KU2VlIGFib3ZlLg0KDQo+IFdpbGwgcmV2aWV3IGFuZCByZXNwb25k IHRvIHRoZSByZW1haW5pbmcgcXVlc3Rpb25zIHNvb24uDQoNClRoYW5rIHlvdS4NCg0KVGhlICJy ZW1haW5pbmcgcXVlc3Rpb25zIiBhcmUgc3RpbGwgYWxsIHRoZSBxdWVzdGlvbnMgYmVsb3cgOi0p DQoNCkJlc3QsDQoNCkNhcmxvcy4NCg0KPg0KPiBSZWdhcmRzLA0KPiBHcmVnDQo+DQo+DQo+IE9u IFRodSwgSnVuIDIwLCAyMDE5IGF0IDk6MTQgQU0gQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEp IDxjcGlnbmF0YUBjaXNjby5jb208bWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbT4+IHdyb3RlOg0K PiBIaSwNCj4NCj4gSSBoYXZlIG5vdCByZXZpZXdlZCB0aGlzIGRyYWZ0IGJlZm9yZSwgYnV0IHRy aWdnZXJlZCBieSB0aGlzIGVtYWlsLCBhbmQgYnJpZWZseSBzY2FubmluZyB0aHJvdWdoIGEgY291 cGxlIG9mIHNlY3Rpb25zLCBpdCBpcyB1bmNsZWFyIHRvIG1lIGhvdyBzb21lIG9mIHRoZSBtZWNo YW5pY3Mgd29yay4NCj4NCj4gVGhlcmUgYXJlIHNvbWUgbWFqb3IgaXNzdWVzIHdpdGggdGhlIE1h YyB1c2FnZSBhbmQgYXNzb2NpYXRpb24sIGFzIEpvZWwgSGFscGVybiBtZW50aW9uZWQgaW4gaGlz IFJ0ZyBEaXIgcmV2aWV3Lg0KPg0KPiBBbmQsIGFkZGl0aW9uYWxseSwgcGxlYXNlIGNvbnNpZGVy IHRoZSBmb2xsb3dpbmcgY29tbWVudHMgYW5kIHF1ZXN0aW9uczoNCj4NCj4NCj4gMS4gVW5kZXJz cGVjaWZpY2F0aW9uIGZvciBpbml0aWFsaXphdGlvbiBhbmQgaW5pdGlhbCBkZW11bHRpcGxleGlu Zy4NCj4NCj4gVGhpcyBkb2N1bWVudCBhbGxvd3MgbXVsdGlwbGUgQkZEIHNlc3Npb25zIGJldHdl ZW4gYSBzaW5nbGUgcGFpciBvZiBWVEVQczoNCj4NCj4gICAgQW4NCj4gICAgaW1wbGVtZW50YXRp b24gdGhhdCBzdXBwb3J0cyB0aGlzIHNwZWNpZmljYXRpb24gTVVTVCBiZSBhYmxlIHRvDQo+ICAg IGNvbnRyb2wgdGhlIG51bWJlciBvZiBCRkQgc2Vzc2lvbnMgdGhhdCBjYW4gYmUgY3JlYXRlZCBi ZXR3ZWVuIHRoZQ0KPiAgICBzYW1lIHBhaXIgb2YgVlRFUHMuDQo+DQo+IFRoZSBpbXBsaWNhdGlv biBvZiB0aGlzIGlzIHRoYXQgQkZEIHNpbmdsZS1ob3AgaW5pdGlhbGl6YXRpb24gcHJvY2VkdXJl cyB3aWxsIG5vdCB3b3JrLiBJbnN0ZWFkLCB0aGVyZSBpcyBhIG5lZWQgdG8gbWFwIHRoZSBpbml0 aWFsIGRlbXVsdGlwbGV4aW5nLg0KPg0KPiBUaGlzIGlzc3VlIGlzIGV4cGxhaW5lZCBpbiBSRkNz IDU4ODIgYW5kIDU4ODM6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1ODgzI3NlY3Rp b24tNCBhbmQgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU4ODIjc2VjdGlvbi02DQo+ DQo+IFNlY3Rpb24gNS4xIHNheXM6DQo+DQo+ICAgIEZvciBzdWNoIHBhY2tldHMsIHRoZSBCRkQg c2Vzc2lvbiBNVVNUIGJlIGlkZW50aWZpZWQNCj4gICAgdXNpbmcgdGhlIGlubmVyIGhlYWRlcnMs IGkuZS4sIHRoZSBzb3VyY2UgSVAsIHRoZSBkZXN0aW5hdGlvbiBJUCwgYW5kDQo+ICAgIHRoZSBz b3VyY2UgVURQIHBvcnQgbnVtYmVyIHByZXNlbnQgaW4gdGhlIElQIGhlYWRlciBjYXJyaWVkIGJ5 IHRoZQ0KPiAgICBwYXlsb2FkIG9mIHRoZSBWWExBTiBlbmNhcHN1bGF0ZWQgcGFja2V0LiAgVGhl IFZOSSBvZiB0aGUgcGFja2V0DQo+ICAgIFNIT1VMRCBiZSB1c2VkIHRvIGRlcml2ZSBpbnRlcmZh Y2UtcmVsYXRlZCBpbmZvcm1hdGlvbiBmb3INCj4gICAgZGVtdWx0aXBsZXhpbmcgdGhlIHBhY2tl dC4NCj4NCj4gQnV0IHRoaXMgZG9lcyBub3QgcmVhbGx5IGV4cGxhaW4gaG93IHRvIGRvIHRoZSBp bml0aWFsIGRlbXVsdGlwbGV4aW5nLiBEb2VzIGVhY2ggQkZEIHNlc3Npb24gbmVlZCB0byBoYXZl IGEgc2VwYXJhdGUgaW5uZXIgc291cmNlIElQIGFkZHJlc3M/IE9yIHNvdXJjZSBVRFAgcG9ydD8g QW5kIGhvdyBvZnRlciBhcmUgdGhleSByZWN5Y2xlZCBvciBrZXB0IGFzIHN0YXRlPyBIb3cgYXJl IHRoZXNlIG1hcHBlZD8NCj4gRXF1YWxseSBpbXBvcnRhbnRseSwgd2hpY2ggc2lkZSBpcyBBY3Rp dmU/DQo+IEFuZCB3aGF0IGlmIHRoZXJl4oCZcyBhIHJhY2UgY29uZGl0aW9uIHdpdGggYm90aCBz aWRlcyBiZWluZyBBY3RpdmUgYW5kIHNldHRpbmcgdXAgcmVkdW5kYW50IHNlc3Npb25zPw0KPg0K PiAxLmIuIEJ5IHRoZSB3YXksIGJhc2VkIG9uIHRoaXMsIHVzaW5nIFMtQkZEIFtSRkMgNzg4MF0g bWlnaHQgYmUgZWFzaWVyIHRvIGRlbXV4Lg0KPg0KPg0KPiAyLiBTZWN1cml0eQ0KPg0KPiBUaGlz IGRvY3VtZW50IHNheXMgdGhhdCB0aGUgVFRMIGluIHRoZSBpbm5lciBwYWNrZXQgY2Fycnlpbmcg QkZEIGlzIHNldCB0byAxLiBIb3dldmVyLCBSRkMgNTg4MCBzYXlzIHRvIHVzZSBHVFNNIFtSRkMg NTA4Ml0sIGkuZS4sIGEgdmFsdWUgb2YgMjU1Li4NCj4NCj4gV2h5IGlzIEdUU00gbm90IHVzZWQg aGVyZT8NCj4NCj4NCj4gMy4gRUNNUCBhbmQgZmF0ZS1zaGFyaW5nIHVuZGVyLXNwZWNpZmljYXRp b246DQo+DQo+IFNlY3Rpb24gNC4xLiBzYXlzOg0KPg0KPiAgICBUaGUgT3V0ZXIgSVAvVURQDQo+ ICAgIGFuZCBWWExBTiBoZWFkZXJzIE1VU1QgYmUgZW5jb2RlZCBieSB0aGUgc2VuZGVyIGFzIGRl ZmluZWQgaW4NCj4gICAgW1JGQzczNDhdLg0KPg0KPg0KPiBBbmQgUkZDIDczNDggc2F5czoNCj4N Cj4gICAgICAgLSAgU291cmNlIFBvcnQ6ICBJdCBpcyByZWNvbW1lbmRlZCB0aGF0IHRoZSBVRFAg c291cmNlIHBvcnQgbnVtYmVyDQo+ICAgICAgICAgIGJlIGNhbGN1bGF0ZWQgdXNpbmcgYSBoYXNo IG9mIGZpZWxkcyBmcm9tIHRoZSBpbm5lciBwYWNrZXQgLS0NCj4gICAgICAgICAgb25lIGV4YW1w bGUgYmVpbmcgYSBoYXNoIG9mIHRoZSBpbm5lciBFdGhlcm5ldCBmcmFtZSdzIGhlYWRlcnMuDQo+ ICAgICAgICAgIFRoaXMgaXMgdG8gZW5hYmxlIGEgbGV2ZWwgb2YgZW50cm9weSBmb3IgdGhlIEVD TVAvbG9hZC0NCj4gICAgICAgICAgYmFsYW5jaW5nIG9mIHRoZSBWTS10by1WTSB0cmFmZmljIGFj cm9zcyB0aGUgVlhMQU4gb3ZlcmxheS4NCj4gICAgICAgICAgV2hlbiBjYWxjdWxhdGluZyB0aGUg VURQIHNvdXJjZSBwb3J0IG51bWJlciBpbiB0aGlzIG1hbm5lciwgaXQNCj4gICAgICAgICAgaXMg UkVDT01NRU5ERUQgdGhhdCB0aGUgdmFsdWUgYmUgaW4gdGhlIGR5bmFtaWMvcHJpdmF0ZSBwb3J0 DQo+ICAgICAgICAgIHJhbmdlIDQ5MTUyLTY1NTM1IFtSRkM2MzM1XS4NCj4NCj4NCj4gQmFzZWQg b24gdGhpcywgZGVwZW5kaW5nIG9uIHRoZSBoYXNoaW5nIGNhbGN1bGF0aW9uLCB0aGUgb3V0ZXIg c291cmNlIFVEUCBwb3J0IGNhbiBiZSBkaWZmZXJlbnQgbGVhZGluZyB0byBkaWZmZXJlbnQgRUNN UCB0cmVhdG1lbnQuIERvZXMgc29tZXRoaW5nIGVsc2UgbmVlZCB0byBiZSBzcGVjaWZpZWQgaGVy ZSBpbiByZWdhcmRzIHRvIHRoZSBvdXRlciBVRFAgc291cmNlIHBvcnQ/DQo+DQo+DQo+IDQuIFNl Y3Rpb24gNyBzYXlzIHRoYXQg4oCcIFN1cHBvcnQgZm9yIGVjaG8gQkZEIGlzIG91dHNpZGUgdGhl IHNjb3BlIG9mIHRoaXMgZG9jdW1lbnTigJ0uDQo+DQo+IEFzc3VtaW5nIHRoaXMgbWVhbnMg4oCc QkZEIEVjaG8gbW9kZeKAnSwgd2h5IGlzIHRoaXMgb3V0IG9mIHNjb3BlPyBJZiB0aGlzIGlzIGEg c2luZ2xlIGxvZ2ljYWwgaG9wIHVuZGVybmVhdGggVlhMQU4sIHdoYXTigJlzIHByZXZlbnRpbmcg dGhlIHVzZSBvZiBFY2hvPyBFY2hv4oCZcyBiZW5lZml0cyBhcmUgaHVnZS4NCj4NCj4NCj4gNS4g VGVybWlub2xvZ3kNCj4NCj4gICAgSW1wbGVtZW50YXRpb25zIFNIT1VMRCBlbnN1cmUgdGhhdCB0 aGUgQkZEDQo+ICAgIHBhY2tldHMgZm9sbG93IHRoZSBzYW1lIGxvb2t1cCBwYXRoIGFzIFZYTEFO IGRhdGEgcGFja2V0cyB3aXRoaW4gdGhlDQo+ICAgIHNlbmRlciBzeXN0ZW0uDQo+DQo+IFdoYXQg aXMgYSDigJxsb29rIHVwIHBhdGggd2l0aGluIGEgc2VuZGVyIHN5c3RlbeKAnT8NCj4NCj4NCj4g Ni4gRGVwbG95bWVudCBzY2VuYXJpb3MNCj4NCj4gUzMgc2F5czoNCj4gICAgRmlndXJlIDEgaWxs dXN0cmF0ZXMgdGhlIHNjZW5hcmlvIHdpdGggdHdvIHNlcnZlcnMsIGVhY2ggb2YgdGhlbQ0KPiAg ICBob3N0aW5nIHR3byBWTXMuICBUaGUgc2VydmVycyBob3N0IFZURVBzIHRoYXQgdGVybWluYXRl IHR3byBWWExBTg0KPiBb4oCmXQ0KPiAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMTogUmVm ZXJlbmNlIFZYTEFOIERvbWFpbg0KPg0KPg0KPiBIb3dldmVyLCBSRkMgNzM0OCBGaWd1cmUgMyBs aXN0cyB0aGF0IGFzIG9uZSBkZXBsb3ltZW50IHNjZW5hcmlvLCBub3QgYXMg4oCcdGhlIHNjZW5h cmlv4oCdIGFuZCDigJxUaGUgUmVmZXJlbmNlIFZYTEFOIERvbWFpbuKAnS4NCj4NCj4gQmVzdCwN Cj4NCj4gQ2FybG9zLg0KPg0KPj4gT24gSnVuIDE3LCAyMDE5LCBhdCAxMjo1OCBBTSwgR3JlZyBN aXJza3kgPGdyZWdpbWlyc2t5QGdtYWlsLmNvbTxtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29t Pj4gd3JvdGU6DQo+Pg0KPj4gSGkgT2xpdmVyLA0KPj4gdGhhbmsgeW91IGZvciB5b3VyIHRob3Jv dWdoIHJldmlldywgY2xlYXIgYW5kIGRldGFpbGVkIHF1ZXN0aW9ucy4gTXkgYXBvbG9naWVzIGZv ciB0aGUgZGVsYXkgdG8gcmVzcG9uZC4gUGxlYXNlIGZpbmQgbXkgYW5zd2VycyBiZWxvdyBpbi1s aW5lIHRhZ2dlZCBHSU0+Pi4NCj4+DQo+PiBSZWdhcmRzLA0KPj4gR3JlZw0KPj4NCj4+IE9uIEZy aSwgTWF5IDMxLCAyMDE5IGF0IDEyOjM4IFBNIE9saXZpZXIgQm9uYXZlbnR1cmUgdmlhIERhdGF0 cmFja2VyIDxub3JlcGx5QGlldGYub3JnPG1haWx0bzpub3JlcGx5QGlldGYub3JnPj4gd3JvdGU6 DQo+PiBSZXZpZXdlcjogT2xpdmllciBCb25hdmVudHVyZQ0KPj4gUmV2aWV3IHJlc3VsdDogUmVh ZHkgd2l0aCBJc3N1ZXMNCj4+DQo+PiBUaGlzIGRvY3VtZW50IGhhcyBiZWVuIHJldmlld2VkIGFz IHBhcnQgb2YgdGhlIHRyYW5zcG9ydCBhcmVhIHJldmlldyB0ZWFtJ3MNCj4+IG9uZ29pbmcgZWZm b3J0IHRvIHJldmlldyBrZXkgSUVURiBkb2N1bWVudHMuIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3Jp dHRlbg0KPj4gcHJpbWFyaWx5IGZvciB0aGUgdHJhbnNwb3J0IGFyZWEgZGlyZWN0b3JzLCBidXQg YXJlIGNvcGllZCB0byB0aGUgZG9jdW1lbnQncw0KPj4gYXV0aG9ycyBhbmQgV0cgdG8gYWxsb3cg dGhlbSB0byBhZGRyZXNzIGFueSBpc3N1ZXMgcmFpc2VkIGFuZCBhbHNvIHRvIHRoZSBJRVRGDQo+ PiBkaXNjdXNzaW9uIGxpc3QgZm9yIGluZm9ybWF0aW9uLg0KPj4NCj4+IFdoZW4gZG9uZSBhdCB0 aGUgdGltZSBvZiBJRVRGIExhc3QgQ2FsbCwgdGhlIGF1dGhvcnMgc2hvdWxkIGNvbnNpZGVyIHRo aXMNCj4+IHJldmlldyBhcyBwYXJ0IG9mIHRoZSBsYXN0LWNhbGwgY29tbWVudHMgdGhleSByZWNl aXZlLiBQbGVhc2UgYWx3YXlzIENDDQo+PiB0c3YtYXJ0QGlldGYub3JnPG1haWx0bzp0c3YtYXJ0 QGlldGYub3JnPiBpZiB5b3UgcmVwbHkgdG8gb3IgZm9yd2FyZCB0aGlzIHJldmlldy4NCj4+DQo+ PiBJIGhhdmUgb25seSBsaW1pdGVkIGtub3dsZWRnZSBvZiBWWExBTiBhbmQgZG8gbm90IGtub3cg YWxsIHN1YnRsZXRpZXMgb2YgQkZELg0KPj4gVGhpcyByZXZpZXcgaXMgdGh1cyBtb3JlIGZyb20g YSBnZW5lcmFsaXN0IHRoYW4gYSBzcGVjaWFsaXN0IGluIHRoaXMgdG9waWMuDQo+Pg0KPj4gTWFq b3IgaXNzdWVzDQo+Pg0KPj4gU2VjdGlvbiA0IHJlcXVpcmVzIHRoYXQgIiBJbXBsZW1lbnRhdGlv bnMgU0hPVUxEIGVuc3VyZSB0aGF0IHRoZSBCRkQNCj4+ICAgIHBhY2tldHMgZm9sbG93IHRoZSBz YW1lIGxvb2t1cCBwYXRoIGFzIFZYTEFOIGRhdGEgcGFja2V0cyB3aXRoaW4gdGhlDQo+PiAgICBz ZW5kZXIgc3lzdGVtLiINCj4+DQo+PiBXaHkgaXMgdGhpcyByZXF1aXJlbWVudCBvbmx5IHJlbGV2 YW50IGZvciB0aGUgbG9va3VwIHBhdGggb24gdGhlIHNlbmRlciBzeXN0ZW0NCj4+ID8gV2hhdCBk b2VzIHRoaXMgc2VudGVuY2UgcmVhbGx5IGltcGxpZXMgPw0KPj4gR0lNPj4gUkZDIDU4ODAgc2V0 IHRoZSBzY29wZSBvZiB0aGUgZmF1bHQgZGV0ZWN0aW9uIG9mIEJGRCBwcm90b2NvbCBhcw0KPj4g ICAgLi4uIHRoZSBiaWRpcmVjdGlvbmFsIHBhdGggYmV0d2VlbiB0d28gZm9yd2FyZGluZyBlbmdp bmVzLCBpbmNsdWRpbmcNCj4+ICAgIGludGVyZmFjZXMsIGRhdGEgbGluayhzKSwgYW5kIHRvIHRo ZSBleHRlbnQgcG9zc2libGUgdGhlIGZvcndhcmRpbmcNCj4+ICAgIGVuZ2luZXMgdGhlbXNlbHZl cyAuLi4NCj4+IFRoZSByZXF1aXJlbWVudCBhaW1lZCB0byB0aGUgZm9yd2FyZGluZyBlbmdpbmUg b2YgYSBCRkQgc3lzdGVtIHRoYXQgdHJhbnNtaXRzIEJGRCBjb250cm9sIHBhY2tldHMgb3ZlciBW WExBTiB0dW5uZWwuDQo+Pg0KPj4gSXMgaXQgYSByZXF1aXJlbWVudCB0aGF0IHRoZSBCRkQgcGFj a2V0cyBmb2xsb3cgdGhlIHNhbWUgcGF0aCBhcyB0aGUgZGF0YQ0KPj4gcGFja2V0IGZvciBhIGdp dmVuIFZYTEFOID8gSSBndWVzcyBzby4gSW4gdGhpcyBjYXNlLCB0aGUgZG9jdW1lbnQgc2hvdWxk DQo+PiBkaXNjdXNzIGhvdyBFcXVhbCBDb3N0IE11bHRpcGF0aCBjb3VsZCBhZmZlY3QgdGhpcy4N Cj4+IEdJTT4+IEkgdGhpbmsgdGhhdCBFQ01QIGVudmlyb25tZW50IGlzIG1vcmUgbGlrZWx5IHRv IGJlIGV4cGVyaWVuY2VkIGJ5IGEgdHJhbnNpdCBub2RlIGluIHRoZSB1bmRlcmxheS4gSWYgdGhl IEJGRCBzZXNzaW9uIGlzIHVzZWQgdG8gbW9uaXRvciB0aGUgc3BlY2lmaWMgdW5kZXJsYXkgcGF0 aCwgdGhlbiwgSSBhZ3JlZSwgd2Ugc2hvdWxkIGV4cGxhaW4gdGhhdCB1c2luZyB0aGUgVlhMQU4g cGF5bG9hZCBpbmZvcm1hdGlvbiB0byBkcmF3IHBhdGggZW50cm9weSBtYXkgY2F1c2UgZGF0YSBh bmQgQkZEIHBhY2tldHMgZm9sbG93aW5nIGRpZmZlcmVudCB1bmRlcmxheSByb3V0ZXMuIEJ1dCwg b24gdGhlIG90aGVyIGhhbmQsIHRoYXQgaXMgdGhlIGNhc2UgZm9yIE9BTSBhbmQgZmF1bHQgZGV0 ZWN0aW9uIGluIGFsbCBvdmVybGF5IG5ldHdvcmtzIGluIGdlbmVyYWwuDQo+Pg0KPj4gTWlub3Ig aXNzdWVzDQo+Pg0KPj4gU2VjdGlvbiAxDQo+Pg0KPj4gWW91IHdyaXRlICJUaGUgYXN5bmNocm9u b3VzIG1vZGUgb2YgQkZELCBhcyBkZWZpbmVkIGluIFtSRkM1ODgwXSwNCj4+ICBjYW4gYmUgdXNl ZCB0byBtb25pdG9yIGEgcDJwIFZYTEFOIHR1bm5lbC4iDQo+Pg0KPj4gV2h5IGRvIHlvdSB1c2Ug dGhlIHdvcmQgY2FuID8gSXQgaXMgYSBwb3NzaWJpbGl0eSBvciBhIHJlcXVpcmVtZW50ID8NCj4+ IEdJTT4+IEluIHByaW5jaXBsZSwgQkZEIERlbWFuZCBtb2RlIG1heSBiZSB1c2VkIHRvIG1vbml0 b3IgcDJwIHBhdGhzIGFzIHdlbGwsIEkgYWdyZWUsIHdpbGwgcmUtd29yZCB0byBtb3JlIGFzc2Vy dGl2ZToNCj4+ICBUaGUgYXN5bmNocm9ub3VzIG1vZGUgb2YgQkZELCBhcyBkZWZpbmVkIGluIFtS RkM1ODgwXSwNCj4+ICBpcyB1c2VkIHRvIG1vbml0b3IgYSBwMnAgVlhMQU4gdHVubmVsLg0KPj4N Cj4+IE5WRSBoYXMgbm90IGJlZW4gZGVmaW5lZCBiZWZvcmUgYW5kIGlzIG5vdCBpbiB0aGUgdGVy bWlub2xvZ3kuDQo+PiBHSU0+PiBXaWxsIGFkZCB0byB0aGUgVGVybWlub2xvZ3kgYW5kIGV4cGFu ZCBhczoNCj4+IE5WRSAgICAgICAgTmV0d29yayBWaXJ0dWFsaXphdGlvbiBFbmRwb2ludA0KPj4N Cj4+IFRoaXMgZW50aXJlIHNlY3Rpb24gaXMgbm90IGVhc3kgdG8gcmVhZCBmb3IgYW4gb3V0c2lk ZXIuDQo+Pg0KPj4gU2VjdGlvbiAzDQo+Pg0KPj4gVk5JIGhhcyBub3QgYmVlbiBkZWZpbmVkDQo+ PiBHSU0+PiBXaWxsIGFkZCB0byB0aGUgVGVybWlub2xvZ3kgc2VjdGlvbjoNCj4+IFZOSSAgICBW WExBTiBOZXR3b3JrIElkZW50aWZpZXIgKG9yIFZYTEFOIFNlZ21lbnQgSUQpDQo+Pg0KPj4gRmln dXJlIDEgY291bGQgdGFrZSBsZXNzIHNwYWNlDQo+PiBHSU0+PiBZZXMsIGNhbiBtYWtlIGl0IGJp dCBkZW5zZXIuIFdvdWxkIHRoZSBmb2xsb3dpbmcgYmUgYW4gaW1wcm92ZW1lbnQ/DQo+Pg0KPj4g ICAgICAgKy0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tKw0KPj4gICAgICAgfCAgICAgICAgU2Vy dmVyIDEgICAgICAgICAgfA0KPj4gICAgICAgfCArLS0tLSstLS0tKyAgKy0tLS0rLS0tLSsgfA0K Pj4gICAgICAgfCB8Vk0xLTEgICAgfCAgfFZNMS0yICAgIHwgfA0KPj4gICAgICAgfCB8Vk5JIDEw MCAgfCAgfFZOSSAyMDAgIHwgfA0KPj4gICAgICAgfCB8ICAgICAgICAgfCAgfCAgICAgICAgIHwg fA0KPj4gICAgICAgfCArLS0tLS0tLS0tKyAgKy0tLS0tLS0tLSsgfA0KPj4gICAgICAgfCBIeXBl cnZpc29yIFZURVAgKElQMSkgICAgfA0KPj4gICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tKw0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4+ICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8ICAgKy0tLS0tLS0tLS0tLS0rDQo+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCAgIHwgICBMYXllciAzICAgfA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICstLS18ICAgTmV0d29yayAgIHwNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKy0tLS0tLS0tLS0tLS0rDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8DQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0r DQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0r LS0tLS0tLS0tLS0tLSsNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgfCAgICBIeXBlcnZpc29yIFZURVAgKElQMikgfA0KPj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICstLS0tKy0tLS0rICArLS0tLSstLS0tKyB8DQo+PiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgfFZNMi0xICAgIHwgIHxWTTIt MiAgICB8IHwNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCB8 Vk5JIDEwMCAgfCAgfFZOSSAyMDAgIHwgfA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8IHwgICAgICAgICB8ICB8ICAgICAgICAgfCB8DQo+PiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgKy0tLS0tLS0tLSsgICstLS0tLS0tLS0r IHwNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgIFNl cnZlciAyICAgICAgICAgICAgfA0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQo+Pg0KPj4NCj4+IFNlY3Rpb24g NA0KPj4NCj4+IEkgZG8gbm90IHNlZSB0aGUgYmVuZWZpdHMgb2YgaGF2aW5nIG9uZSBwYXJhZ3Jh cGggaW4gU2VjdGlvbiA0IGZvbGxvd2VkIGJ5IG9ubHkNCj4+IFNlY3Rpb24gNC4xDQo+PiBHSU0+ PiBXaWxsIG1lcmdlIFNlY3Rpb24gNC4xIGludG8gNCB3aXRoIG1pbm9yIHJlcXVpcmVkIHJlLXdv cmRpbmc6DQo+PiA0LiAgQkZEIFBhY2tldCBUcmFuc21pc3Npb24gb3ZlciBWWExBTiBUdW5uZWwN Cj4+DQo+PiAgICBCRkQgcGFja2V0IE1VU1QgYmUgZW5jYXBzdWxhdGVkIGFuZCBzZW50IHRvIGEg cmVtb3RlIFZURVAgYXMNCj4+ICAgIGV4cGxhaW5lZCBpbiB0aGlzIHNlY3Rpb24uICBJbXBsZW1l bnRhdGlvbnMgU0hPVUxEIGVuc3VyZSB0aGF0IHRoZQ0KPj4gICAgQkZEIHBhY2tldHMgZm9sbG93 IHRoZSBzYW1lIGxvb2t1cCBwYXRoIGFzIFZYTEFOIGRhdGEgcGFja2V0cyB3aXRoaW4NCj4+ICAg IHRoZSBzZW5kZXIgc3lzdGVtLg0KPj4NCj4+ICAgIEJGRCBwYWNrZXRzIGFyZSBlbmNhcHN1bGF0 ZWQgaW4gVlhMQU4gYXMgZGVzY3JpYmVkIGJlbG93LiAgVGhlIFZYTEFODQo+PiAgICBwYWNrZXQg Zm9ybWF0IGlzIGRlZmluZWQgaW4gU2VjdGlvbiA1IG9mIFtSRkM3MzQ4XS4gIFRoZSBPdXRlciBJ UC9VRFANCj4+ICAgIGFuZCBWWExBTiBoZWFkZXJzIE1VU1QgYmUgZW5jb2RlZCBieSB0aGUgc2Vu ZGVyIGFzIGRlZmluZWQgaW4NCj4+ICAgIFtSRkM3MzQ4XS4NCj4+DQo+PiBTZWN0aW9uIDQuMQ0K Pj4NCj4+IFRoZSBkb2N1bWVudCBkb2VzIG5vdCBzcGVjaWZ5IHdoZW4gYSBkZWRpY2F0ZWQgTUFD IGFkZHJlc3Mgb3IgdGhlIE1BQyBhZGRyZXNzDQo+PiBvZiB0aGUgZGVzdGluYXRpb24gVlRFUCBt dXN0IGJlIHVzZWQuIFRoaXMgY291bGQgYWZmZWN0IHRoZSBpbnRlcm9wZXJhYmlsaXR5IG9mDQo+ PiBpbXBsZW1lbnRhdGlvbnMuIFNob3VsZCBhbGwgaW1wbGVtZW50YXRpb25zIHN1cHBvcnQgYm90 aCB0aGUgZGVkaWNhdGVkIE1BQw0KPj4gYWRkcmVzcyBhbmQgdGhlIGRlc3RpbmF0aW9uIE1BQyBh ZGRyZXNzID8NCj4+IEdJTT4+IEFmdGVyIGZ1cnRoZXIgZGlzY3Vzc2lvbiwgYXV0aG9ycyBkZWNp ZGVkIHRvIHJlbW92ZSB0aGUgcmVxdWVzdCBmb3IgdGhlIGRlZGljYXRlZCBNQUMgYWRkcmVzcyBh bGxvY2F0aW9uLiBPbmx5IHRoZSBNQUMgYWRkcmVzcyBvZiB0aGUgcmVtb3RlIFZURVAgbXVzdCBi ZSB1c2VkIGFzIHRoZSBkZXN0aW5hdGlvbiBNQUMgYWRkcmVzcyBpbiB0aGUgaW5uZXIgRXRoZXJu ZXQgZnJhbWUuIFBsZWFzZSBjaGVjayB0aGUgYXR0YWNoZWQgZGlmZiBiZXR3ZWVuIHRoZSAtMDcg YW5kIHRoZSB3b3JraW5nIHZlcnNpb25zIG9yIHRoZSB3b3JraW5nIHZlcnNpb24gb2YgdGhlIGRy YWZ0Lg0KPj4NCj4+IEl0IGlzIHVuY2xlYXIgZnJvbSB0aGlzIHNlY3Rpb24gd2hldGhlciBJUHY0 IGluc2lkZSBJUHY2IGFuZCB0aGUgb3Bwb3NpdGUNCj4+IHNob3VsZCBiZSBzdXBwb3J0ZWQgb3Ig bm90Lg0KPj4gR0lNPj4gQW55IGNvbWJpbmF0aW9uIG9mIG91dGVyIElQdlggYW5kIGlubmVyIElQ dlggaXMgcG9zc2libGUuDQo+Pg0KPj4gU2VjdGlvbiA1Lg0KPj4NCj4+IElmIHRoZSByZWNlaXZl ZCBwYWNrZXQgZG9lcyBub3QgbWF0Y2ggdGhlIGRlZGljYXRlZCBNQUMgYWRkcmVzcyBub3IgdGhl IE1BQw0KPj4gYWRkcmVzcyBvZiB0aGUgVlRFUCwgc2hvdWxkIHRoZSBwYWNrZXQgYmUgc2lsZW50 bHkgZGlzY2FyZGVkIG9yIHRyZWF0ZWQNCj4+IGRpZmZlcmVudGx5ID8NCj4+IEdJTT4+IEFzIEkn dmUgbWVudGlvbmVkIGVhcmxpZXIsIGF1dGhvcnMgaGF2ZSBkZWNpZGVkIHRvIHJlbW92ZSB0aGUg dXNlIG9mIHRoZSBkZWRpY2F0ZWQgTUFDIGFkZHJlc3MgZm9yIEJGRCBvdmVyIFZYTEFOLg0KPj4N Cj4+IFNlY3Rpb24gNS4xDQo+Pg0KPj4gSXMgdGhpcyBhIG1vZGlmaWNhdGlvbiB0byBzZWN0aW9u IDYuMyBvZiBSRkM1ODgwID8gVGhpcyBpcyBub3QgY2xlYXINCj4+IEdJTT4+IEkgdGhpbmsgdGhh dCB0aGlzIHNlY3Rpb24gaXMgbm90IG1vZGlmaWNhdGlvbiBidXQgdGhlIGRlZmluaXRpb24gb2Yg dGhlIGFwcGxpY2F0aW9uLXNwZWNpZmljIHByb2NlZHVyZSB0aGF0IGlzIG91dHNpZGUgdGhlIHNj b3BlIG9mIFJGQyA1ODgwOg0KPj4gICAgVGhlIG1ldGhvZCBvZiBkZW11bHRpcGxleGluZyB0aGUg aW5pdGlhbCBwYWNrZXRzIChpbiB3aGljaCBZb3VyDQo+PiAgICBEaXNjcmltaW5hdG9yIGlzIHpl cm8pIGlzIGFwcGxpY2F0aW9uIGRlcGVuZGVudCwgYW5kIGlzIHRodXMgb3V0c2lkZQ0KPj4gICAg dGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4NCj4+DQo+PiBTZWN0aW9uIDkNCj4+DQo+ PiBUaGUgc2VudGVuY2UgIiBUaHJvdHRsaW5nIE1BWSBiZSByZWxheGVkIGZvciBCRkQgcGFja2V0 cw0KPj4gICAgYmFzZWQgb24gcG9ydCBudW1iZXIuIiBpcyB1bmNsZWFyLg0KPj4gR0lNPj4gWWVz LCB0aGFuayB5b3UgZm9yIHBvaW50aW5nIHRvIHRoaXMuIFRoZSB1cGRhdGVkIHRleHQsIGluIHRo ZSB3aG9sZSBwYXJhZ3JhcGgsIGlzIGFzIGZvbGxvd3M6DQo+PiBORVcgVEVYVDoNCj4+ICAgIFRo ZSBkb2N1bWVudCByZXF1aXJlcyBzZXR0aW5nIHRoZSBpbm5lciBJUCBUVEwgdG8gMSwgd2hpY2gg Y291bGQgYmUNCj4+ICAgIHVzZWQgYXMgYSBERG9TIGF0dGFjayB2ZWN0b3IuICBUaHVzIHRoZSBp bXBsZW1lbnRhdGlvbiBNVVNUIGhhdmUNCj4+ICAgIHRocm90dGxpbmcgaW4gcGxhY2UgdG8gY29u dHJvbCB0aGUgcmF0ZSBvZiBCRkQgY29udHJvbCBwYWNrZXRzIHNlbnQNCj4+ICAgIHRvIHRoZSBj b250cm9sIHBsYW5lLiAgT24gdGhlIG90aGVyIGhhbmQsIG92ZXIgYWdncmVzc2l2ZSB0aHJvdHRs aW5nDQo+PiAgICBvZiBCRkQgY29udHJvbCBwYWNrZXRzIG1heSBiZWNvbWUgdGhlIGNhdXNlIG9m IHRoZSBpbmFiaWxpdHkgdG8gZm9ybQ0KPj4gICAgYW5kIG1haW50YWluIEJGRCBzZXNzaW9uIGF0 IHNjYWxlLiAgSGVuY2UsIHRocm90dGxpbmcgb2YgQkZEIGNvbnRyb2wNCj4+ICAgIHBhY2tldHMg U0hPVUxEIGJlIGFkanVzdGVkIHRvIHBlcm1pdCBCRkQgdG8gd29yayBhY2NvcmRpbmcgdG8gaXRz DQo+PiAgICBwcm9jZWR1cmVzLg0KPj4gPGRyYWZ0LWlldGYtYmZkLXZ4bGFuLTA4LnR4dD48RGlm Zl8gZHJhZnQtaWV0Zi1iZmQtdnhsYW4tMDcudHh0IC0gZHJhZnQtaWV0Zi1iZmQtdnhsYW4tMDgu dHh0Lmh0bWw+DQo+DQoNCg0KDQo= --_000_BADB8CA6FCAC47A38B06F82E98A89549ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <252326B5CAC1C2459C200EC55D666BB7@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhlbGxvLCBHcmVnLA0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+WWVzLCBoYXBweSB0b28gYW5zd2Vy IHlvdXIgcXVlc3Rpb24uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5GaXJzdCwgaG93ZXZlciwgbGV0IG1lIG1ha2UgdHdvIHF1aWNrIG9i c2VydmF0aW9ucyBvbiB0aGUgZXhjaGFuZ2U6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPG9sIGNs YXNzPSIiPg0KPGxpIGNsYXNzPSIiPllvdSBzZWVtIHRvIGJlIHBpY2tpbmcgdmVyeSBzcGVjaWZp YyBmcmFnbWVudHMgb3Igc3ViLXRvcGljcyBmcm9tIG15IGNvbW1lbnRzLCBhbmQgZm9sbG93aW5n IHVwIG9uIHRob3NlIG9ubHkuPC9saT48bGkgY2xhc3M9IiI+SeKAmW0gaGFwcHkgdG8gY29udGlu dWUgYW5zd2VyaW5nIHRoZXNlIHF1ZXN0aW9ucywgYnV0IHRoZXkgYXJlIG9ydGhvZ29uYWwgdG8g KGFuZCBjb25zZXF1ZW50bHkgYSBkaXN0cmFjdGlvbiBmcm9tKSB0aGUgaW5pdGlhbCBjb21tZW50 cyBJIHJhaXNlZC48L2xpPjwvb2w+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPk5vdywgeW91ciBxdWVzdGlvbjogdGhlIEJGRCBFY2hv IHBhY2tldCBmb3JtYXQgaXMgZ2VuZXJpY2FsbHkgc3BlY+KAmWVkIGFuZCBkZWZpbmVkIGluIFNl Y3Rpb24gNSBvZiBSRkMgNTg4MDo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU4ODAjc2VjdGlvbi01IiBjbGFzcz0iIj5odHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTg4MCNzZWN0aW9uLTU8L2E+PC9kaXY+DQo8ZGl2IGNs YXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGUgbW9zdCByZWxl dmFudCBwYXJ0IGlzIHRoaXM6PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO1RoZSBwYXls b2FkIG9mIGEgQkZEIEVjaG8gcGFja2V0IGlzIGEgbG9jYWwgbWF0dGVyLCBzaW5jZSBvbmx5IHRo ZTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7c2VuZGluZyBzeXN0ZW0gZXZlciBw cm9jZXNzZXMgdGhlIGNvbnRlbnQuICZuYnNwO1RoZSBvbmx5IHJlcXVpcmVtZW50IGlzPC9kaXY+ DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJzcDt0aGF0IHN1ZmZpY2llbnQgaW5mb3JtYXRpb24g aXMgaW5jbHVkZWQgdG8gZGVtdWx0aXBsZXggdGhlIHJlY2VpdmVkPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPiZuYnNwOyAmbmJzcDtwYWNrZXQgdG8gdGhlIGNvcnJlY3QgQkZEIHNlc3Npb24gYWZ0ZXIg aXQgaXMgbG9vcGVkIGJhY2sgdG8gdGhlPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNwOyAmbmJz cDtzZW5kZXIuJm5ic3A7PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xp bmUiPg0KU2luY2UgdGhlIHJlbW90ZSBzeXN0ZW0gZG9lcyBub3QgcHJvY2VzcyB0aGUgZWNobyBw YWNrZXQgY29udGVudCwgaXQgaXMgYSBsb2NhbCBtYXR0ZXIgb25seS4gQW5kIGdpdmVuIHRoZSBm YWN0IHRoYXQsIGFzIHN1Y2gsIHRoZXJlIGlzIG5vIGludGVyb3BlcmFiaWxpdHkgaW1wbGljYXRp b25zLCB0aGVyZSBpcyBubyBuZWVkIHRvIG92ZXItc3BlY2lmeSB0aGUgcGFja2V0IGZvcm1hdC4g VGhlIG9ubHkgcmVxdWlyZW1lbnQgaXMgdGhhdCB0aGUgc2VuZGluZw0KIHN5c3RlbSBuZWVkcyB0 byBiZSBhYmxlIHRvIG1hcCBpdCB0byBhIHNlc3Npb24gd2hlbiBpdCBib29tZXJhbmdzIGJhY2su PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5ObywgaXQgaXMgZ2VuZXJhbGx5IG5vdCAoaS5lLiwgZG9lcyBub3QgbmVlZCB0byBiZSwgYnV0 IHRoZXJl4oCZcyBmcmVlZG9tIHRvIHBvdGVudGlhbGx5IGJlKSBhIEJGRCBjb250cm9sIHBhY2tl dC4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+WWVzLCBpdCBjYW4gYmUgc29tZXRoaW5nIGVs c2UuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iIj5UaGF0IHNhaWQsIHRoZSBwYWNrZXQgZm9ybWF0IGZvciBCRkQgRWNobyBoYXMsIHRvIG15 IGFuYWx5c2lzIGFuZCB1bmRlcnN0YW5kaW5nLCBubyByZWxldmFuY3kgb24gdGhlIHF1ZXN0aW9u cyBiZWxvdy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPkJlc3QsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5DYXJsb3MuPGJyIGNsYXNzPSIiPg0KPGRpdj48YnIgY2xhc3M9IiI+ DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gSnVu IDIwLCAyMDE5LCBhdCAxMjo1MCBBTSwgR3JlZyBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpn cmVnaW1pcnNreUBnbWFpbC5jb20iIGNsYXNzPSIiPmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvYT4m Z3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIi IGNsYXNzPSIiPkhlbGxvIENhcmxvcyw8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPmNv dWxkIHlvdSBwbGVhc2UgcmVmZXIgbWUgdG8gdGhlIHNwZWNpZmljYXRpb24gb2YgQkZEIHRoYXQg ZGVmaW5lcyB0aGUgbWVzc2FnZSBmb3JtYXQgdGhhdCBpcyB1c2VkIGluIHRoZSBFY2hvIG1vZGUg b2YgQkZELiBJcyBpdCB0aGUgQkZEIGNvbnRyb2wgcGFja2V0PyBTb21ldGhpbmcgZWxzZT88L2Rp dj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBk aXI9Imx0ciIgY2xhc3M9IiI+UmVnYXJkcyw8L2Rpdj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIi PkdyZWc8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGRp cj0ibHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+T24gVGh1LCBKdW4gMjAsIDIwMTkgYXQgMTE6MDkg QU0gQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpICZsdDs8YSBocmVmPSJtYWlsdG86Y3BpZ25h dGFAY2lzY28uY29tIiBjbGFzcz0iIj5jcGlnbmF0YUBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5 bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIw NCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9Im92ZXJmbG93LXdyYXA6 IGJyZWFrLXdvcmQ7IiBjbGFzcz0iIj5IZWxsbywgR3JlZywNCjxkaXYgY2xhc3M9IiI+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlBsZWFzZSBzZWUgaW5saW5lLjxiciBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEp1biAxOSwgMjAxOSwgYXQgOTo1OCBQTSwg R3JlZyBNaXJza3kgJmx0OzxhIGhyZWY9Im1haWx0bzpncmVnaW1pcnNreUBnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIiBjbGFzcz0iIj5ncmVnaW1pcnNreUBnbWFpbC5jb208L2E+Jmd0OyB3cm90 ZTo8L2Rpdj4NCjxiciBjbGFzcz0iZ21haWwtbV8tMTc3OTM5MDA3NTc2NTUzNDg4MUFwcGxlLWlu dGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNz PSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+SGVsbG8gQ2FybG9zLA0KPGRpdiBjbGFzcz0i Ij50aGFuayB5b3UgZm9yIHRoZSBleHBlZGllbnQgY2xhcmlmaWNhdGlvbi48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+VG8geW91ciZuYnNwO3F1ZXN0aW9ucyBvbiBkZW11bHRpcGxleGluZyBCRkQgY29u dHJvbCBwYWNrZXRzIHdpdGggdGhlIHplcm8gdmFsdWUgb2YgdGhlIFlvdXIgRGlzY3JpbWluYXRv ciBmaWVsZDo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8dWwgY2xhc3M9IiI+DQo8bGkgY2xhc3M9 IiI+b25seSBCRkQgY29udHJvbCBwYWNrZXRzIHdpdGggdGhlIHplcm8gdmFsdWUgb2YgdGhlIFlv dXIgRGlzY3JpbWluYXRvciBmaWVsZCBhcmUgZGVtdWx0aXBsZXhlZCB1c2luZyB0aGUgaW5mb3Jt YXRpb24gb2YgdGhlIGlubmVyIElQIGhlYWRlci4gSSBiZWxpZXZlIHRoYXQgdGhlIHRleHQgaXMg Y2xlYXIgYW5kIHJlcXVpcmVzIHRoYXQgYWxsIGZpZWxkcyBvZiB0aGUgaW5uZXIgSVAgaGVhZGVy IG11c3QgYmUgdXNlZCB0byBkZW11bHRpcGxleA0KIGEgcmVjZWl2ZWQgQkZEIGNvbnRyb2wgcGFj a2V0IHdpdGggdGhlIHplcm8gdmFsdWUgaW4gdGhlIFlvdXIgRGlzY3JpbWluYXRvciBmaWVsZC4g V2hpY2ggb2YgdGhlIGZpZWxkcyBhbiBpbXBsZW1lbnRhdGlvbiB1c2VzIHRvIGNyZWF0ZSBtdWx0 aXBsZSBCRkQgc2Vzc2lvbnMgYmV0d2VlbiB0aGUgcGFpciBvZiBWVEVQcyBpcyBpbXBsZW1lbnRh dGlvbiBzcGVjaWZpYy48L2xpPjwvdWw+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXYgY2xhc3M9IiI+VGhpcyB0ZXh0IGlzIHJlcGVhdGluZyB3YXMg aXMgaW4gdGhlIGRyYWZ0LCBidXQgZG9lcyBub3QgYW5zd2VyIGFueSBvZiBteSBxdWVzdGlvbnMu PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij5Gb3IgZXhhbXBsZTo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+MS4gJnF1b3Q7dGhhdCBhbGwgZmll bGRzIG9mIHRoZSBpbm5lciBJUCBoZWFkZXIgbXVzdCBiZSB1c2VkIHRvIGRlbXVsdGlwbGV4IGEg cmVjZWl2ZWQgQkZEIGNvbnRyb2wgcGFja2V04oCdPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPiZuYnNw OyAmbmJzcDsgLSZndDsgVGhlIHRleHQgZG9lcyBub3Qgc2F5IOKAnGFsbCBmaWVsZHPigJ0sIGJ1 dCByZWdhcmRsZXNzLCBkbyB5b3UgbWVhbiB0aGUgRFNDUCBhbmQgdGhlIEV2aWwgQml0PyBJUHY2 IEZsb3cgTGFiZWw/IEhvdyAqZXhhY3RseSo/PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjIuIEhvdyBp cyB0aGUgbWFwcGluZyBvZiBJUCAobm90IFVEUD8pIGZpZWxkcyB0byBCRkQgc2Vzc2lvbiBkb25l PzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4zLiBIb3cgaXMgdGhpcyBzdGF0ZSBjcmVhdGVkIGFuZCBt YWludGFpbmVkPyZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj40LiBTaW5jZSB0aGlzIGlzIGEg c2V0IG9mIGZpZWxkcyBvbiB3aGljaCB0d28gc3lzdGVtcyBuZWVkIHRvIGFncmVlICh3aGljaCBm aWVsZHMgZnJvbSB0aGUgaW5uZXIgSVAvVURQIGFyZSBtYXBwZWQgbmVlZHMgdG8gYmUgdW5kZXJz dG9vZCBieSBib3RoIHN5c3RlbXMpLCBpdCBjYW5ub3QgYmUg4oCcaW1wbGVtZW50YXRpb24gc3Bl Y2lmaWPigJ0uIEZ1cnRoZXIsIHRoZSB0ZXh0IGRvZXMgbm90IHNheSBzby48L2Rpdj4NCjxiciBj bGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPlRvIHlvdXIgcG9pbnQgb24gdGhlIGxldmVsIEVjaG8gbW9kZSBvZiBCRkQg aXMgc3BlY2lmaWVkIGluIFJGQyA1ODgwIEknbGwgcXVvdGUgdGhlIG9waW5pb24gb2YgSmVmZnJl eSBIYWFzIGZyb20gdGhlIGRpc2N1c3Npb24gb2YgY29tbWVudHMgZnJvbSBTaGF3biBFbWVyeSBv biBiZWhhbGYgb2YgdGhlIFNlY0Rpci4gU2hhd24gaGFkIGNvbW1lbnRlZDo8L2Rpdj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCA0MHB4O2JvcmRlcjpub25l O3BhZGRpbmc6MHB4IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiIGNsYXNzPSIiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6c21hbGwiIGNsYXNzPSIiPkVjaG8gQkZEIGlzIG91dCBvZiBzY29wZSBm b3IgdGhlIGRvY3VtZW50LCBidXQgZG9lcyBub3QgZGVzY3JpYmUgdGhlIHJlYXNvbiBmb3IgdGhp cyBvciB3aHkgc3RhdGU8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCA0MHB4O2JvcmRlcjpub25l O3BhZGRpbmc6MHB4IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9ImZvbnQtc2l6ZToxMi44cHgiIGNsYXNzPSIiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6c21hbGwiIGNsYXNzPSIiPnRoaXMgYXQgYWxsPzwvc3Bhbj48L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQpJJ3ZlIHJlc3BvbmRlZDoNCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW46MHB4IDBweCAwcHggNDBweDtib3JkZXI6bm9uZTtwYWRkaW5nOjBw eCIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkdJTSZndDsmZ3Q7IEkgdGhpbmsgdGhhdCB0aGUg bWFpbiByZWFzb24gaXMgdGhhdCB0aGUgQkZEIEVjaG8gbW9kZSBpcyB1bmRlcnNwZWNpZmllZC4g UkZDIDU4ODAgZGVmaW5lZCBzb21lIG9mIHRoZSBtZWNoYW5pc21zIHJlbGF0ZWQgdG8gdGhlIEVj aG8gbW9kZSwgYnV0IG1vcmUgc3RhbmRhcmRpemF0aW9uIHdvcmsgbWF5IGJlIHJlcXVpcmVkLiZu YnNwOyZuYnNwOzwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KQW5kIEplZmZyZXkgSGFhcyBoYWQgYWRk ZWQ6DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDQwcHg7Ym9yZGVyOm5v bmU7cGFkZGluZzowcHgiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5TcGVha2luZyBhcyBhIEJG RCBjaGFpciwgdGhpcyBpcyB0aGUgcmVsZXZhbnQgb2JzZXJ2YXRpb24uJm5ic3A7IEJGRCBFY2hv IGlzPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPnVuZGVyc3BlY2lmaWVkIHRvIHRoZSBwb2ludCB3aGVy ZSBjbGFpbWluZyBjb21wbGlhbmNlIGlzIGRpZmZpY3VsdCBhdCBiZXN0LjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5JbiBnZW5lcmFsLCBpdCByZWxpZXMgb24gc2luZ2xlLWhvcCBhbmQgdGhlIGFiaWxp dHkgdG8gaGF2ZSB0aGUgcmVtb3RlIEVjaG88L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Y2xpZW50IGxv b3AgdGhlIHBhY2tldHMuJm5ic3A7PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+QkZEIEVjaG8gY2Fubm90IGJlIHNwZWNpZmllZCBpbiBSRkMgNTg4MCBiYXNl IHNwZWMgYmVjYXVzZSBpdCBpcyBhcHBsaWNhdGlvbiBzcGVjaWZpYy48L2Rpdj4NCjxiciBjbGFz cz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowcHgg MHB4IDBweCA0MHB4O2JvcmRlcjpub25lO3BhZGRpbmc6MHB4IiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoaXMgcGFja2V0IGxv b3AgbWF5IG5vdCBiZSBwcmFjdGljYWwgZm9yIHNldmVyYWwgZW5jYXBzdWxhdGlvbnMgYW5kIHRo dXMgaXM8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+b3V0IG9mIHNjb3BlIGZvciBzdWNoIGVuY2Fwc3Vs YXRpb25zLiZuYnNwOyBXaGV0aGVyIHRoaXMgaXMgcHJhY3RpY2FsIGZvciB2eGxhbjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj50b2RheSwgb3IgaW4gdGhlIHByZXNlbmNlIG9mIGZ1dHVyZSBleHRlbnNp b25zIHRvIHZ4bGFuIGlzIGxlZnQgb3V0IG9mIHNjb3BlPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPmZv ciB0aGUgY29yZSBwcm9wb3NhbC4mbmJzcDsmbmJzcDs8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGUgcXVlc3Rpb24gcmVtYWluczogZm9yIFZYTEFOIGVu Y2Fwc3VsYXRpb24sIHRoaXMgaXMgbGlrZSBhIHNpbmdsZSBob3AgYXMgZmFyIGFzIEJGRCBpcyBj b25jZXJuZWQgKHNpbmdsZSBob3AgVlhMQU4gdHVubmVsKS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlNpbmNlIFJGQyA1ODgxIGRlZmlu ZXMgRWNobyBmb3Igc2luZ2xlIGhvcCwgY2FuIHlvdSBwbGVhc2UgZWxhYm9yYXRlIChpbiB0aGUg ZG9jdW1lbnQpIHdoeSBpcyBvdXQgb2Ygc2NvcGUgb3IgaG93IGl0IGNhbiB3b3JrPzwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QmVzdCw8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PkNhcmxvcy48L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCA0MHB4O2JvcmRlcjpub25lO3BhZGRpbmc6 MHB4IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQpXaWxsIHJlc3BvbmQgdG8gb3RoZXIgcXVlc3Rpb25zIGluIGEgc2VwYXJhdGUg bWFpbC4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PlJlZ2FyZHMsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkdyZWc8YnIgY2xhc3M9IiI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSIiPg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGRp diBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9ImdtYWlsX2F0dHIi Pk9uIFRodSwgSnVuIDIwLCAyMDE5IGF0IDEwOjMxIEFNIENhcmxvcyBQaWduYXRhcm8gKGNwaWdu YXRhKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxh bmsiIGNsYXNzPSIiPmNwaWduYXRhQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbjowcHggMHB4IDBweCAwLjhleDti b3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nLWxlZnQ6MWV4IiBj bGFzcz0iZ21haWxfcXVvdGUiPg0KSGVsbG8sIEdyZWcsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KJmd0OyBPbiBKdW4gMTksIDIwMTksIGF0IDk6MDkgUE0sIEdyZWcgTWlyc2t5ICZsdDs8 YSBocmVmPSJtYWlsdG86Z3JlZ2ltaXJza3lAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayIgY2xh c3M9IiI+Z3JlZ2ltaXJza3lAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0K Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IEhpIENhcmxvcyw8YnIgY2xhc3M9IiI+DQomZ3Q7IHRo YW5rIHlvdSBmb3IgcmVtaW5kaW5nIG9mIG91ciBjb250aW51ZWQgZGlzY3Vzc2lvbiB3aXRoIEpv ZWwuIFdlIGFyZSBzZWVraW5nIGNvbW1lbnRzIGZyb20gVlhMQU4gZXhwZXJ0cyBhbmQgbXVjaCBh cHByZWNpYXRlIGlmIHlvdSBoYXZlIGluc2lnaHRzIG9uIFZYTEFOIHRvIHNoYXJlLjxiciBjbGFz cz0iIj4NCiZndDsgSSd2ZSBnb3Qgc29tZSBjbGFyaWZ5aW5nIHF1ZXN0aW9ucyBiZWZvcmUgSSBj YW4gcmVzcG9uZCB0byB5b3UuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU3VyZS48YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQomZ3Q7IFRvIHdoaWNoIHN0YWdlIG9mIHRoZSB0aHJl ZS13YXkgaGFuZHNoYWtlIHlvdSByZWZlciBhcyAmcXVvdDtpbml0aWFsIGRlbXVsdGlwbGV4aW5n JnF1b3Q7PyBJIGNvdWxkbid0IGZpbmQgdGhpcyB0ZXJtIGluIFJGQyA1ODgwLjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCuKAnEluaXRpYWwgZGVtdWx0aXBsZXhpbmcmcXVvdDsgaXMgYSB3 ZWxsLWtub3duIHRlcm0gaW4gQkZELCByZWZlcnJpbmcgdG8gdGhlICZxdW90O2RlbXVsdGlwbGV4 aW5nIG9mIHRoZSBpbml0aWFsIHBhY2tldHMmcXVvdDssIEJGRCBDb250cm9sIHBhY2tldCB3aXRo IFlvdXJEaXNjIGJlaW5nIHplcm8uPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSW4gUkZD IDU4ODAsIHNlZSBTZWN0aW9uIDYuMy48YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNTg4MCNzZWN0aW9uLTYuMyIgcmVsPSJub3JlZmVycmVyIiB0 YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU4 ODAjc2VjdGlvbi02LjM8L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZu YnNwO1RoZSBtZXRob2Qgb2YgZGVtdWx0aXBsZXhpbmcgdGhlIGluaXRpYWwgcGFja2V0cyAoaW4g d2hpY2ggWW91cjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDtEaXNjcmltaW5hdG9yIGlzIHpl cm8pIGlzIGFwcGxpY2F0aW9uIGRlcGVuZGVudCwgYW5kIGlzIHRodXMgb3V0c2lkZTxiciBjbGFz cz0iIj4NCiZuYnNwOyAmbmJzcDt0aGUgc2NvcGUgb2YgdGhpcyBzcGVjaWZpY2F0aW9uLjxiciBj bGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClNpbmNlIGluaXRpYWwgZGVtdWx0aXBsZXhpbmcgaXMg aW5kZWVkIGFwcGxpY2F0aW9uIHNwZWNpZmljLCBkaWZmZXJlbnQgZm9yIG9uZS1ob3AgdmVyc3Vz IG11bHRpLWhvcCBhbmQgZGVwZW5kZW50IHVwb24gd2hldGhlciBhIHNpbmdsZSBvciBtdWx0aXBs ZSBzZXNzaW9ucyBhcmUgYWxsb3dlZCBiZXR3ZWVuIGEgcGFpciBvZiBlbmRwb2ludHMsIEkgYWRk ZWQgYmVsb3cgdHdvIG90aGVyIHJlbGV2YW50IGNpdGF0aW9ucywgZnJvbSBhcHBsaWNhdGlvbg0K IHNwZWNpZmljIEJGRCBzcGVjczo8YnIgY2xhc3M9IiI+DQoxLiA8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjNTg4MyNzZWN0aW9uLTQiIHJlbD0ibm9yZWZlcnJlciIgdGFy Z2V0PSJfYmxhbmsiIGNsYXNzPSIiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU4 ODMjc2VjdGlvbi00PC9hPiA8YnIgY2xhc3M9IiI+DQoyLiA8YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNTg4MiNzZWN0aW9uLTYiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0 PSJfYmxhbmsiIGNsYXNzPSIiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU4ODIj c2VjdGlvbi02PC9hPjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4N CiZndDsgUmVnYXJkaW5nIHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoZSBFY2hvIG1vZGUsIHRoYW5r IHlvdSBmb3IgcG9pbnRpbmcgdG8gdGhlIG5lZWQgZm9yIHN0cmljdGVyIHRlcm1pbm9sb2d5LCB0 aGUgRWNobyBtb2RlLCBhcyBkZWZpbmVkIGluIFJGQyA1ODgwLCBpcyB1bmRlcnNwZWNpZmllZCBh bmQgaXQgd2lsbCByZXF1aXJlIGFkZGl0aW9uYWwgc3RhbmRhcmRpemF0aW9uLjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCk5vLiBCRkQgRWNobyBpcyBub3QgdW5kZXJzcGVjaWZpZWQgaW4g UkZDIDU4ODAuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KUGxlYXNlIHJlYWQgUzU6IDxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1ODgwI3NlY3Rpb24tNSIgcmVs PSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayIgY2xhc3M9IiI+DQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNTg4MCNzZWN0aW9uLTU8L2E+PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KJm5ic3A7ICZuYnNwO0JGRCBFY2hvIHBhY2tldHMgYXJlIHNlbnQgaW4gYW4gZW5jYXBz dWxhdGlvbiBhcHByb3ByaWF0ZSB0byB0aGU8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ZW52 aXJvbm1lbnQuJm5ic3A7IFNlZSB0aGUgYXBwcm9wcmlhdGUgYXBwbGljYXRpb24gZG9jdW1lbnRz IGZvciB0aGU8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7c3BlY2lmaWNzIG9mIHBhcnRpY3Vs YXIgZW52aXJvbm1lbnRzLjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCkJGRCBFY2hvIGlzIGFwcGxpY2F0aW9uIGRlcGVuZGVudC4gPGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KVGhlcmVmb3JlLCBmb3IgZXhhbXBsZSwgc2luZ2xlLWhvcCBCRkQgaW4gUkZD IDU4ODEgc3BlY2lmaWVzIEJGRCBFY2hvIGZvciB0aGF0IGFwcGxpY2F0aW9uLjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCkhlbmNlLCBteSBxdWVzdGlvbiBzdGFuZHM6IHdoeSBpcyB0aGlz IGRyYWZ0IGNsYWltaW5nIEJGRCBFY2hvIGlzIG91dCBvZiBzY29wZSBmb3IgdGhpcyBCRkQgYXBw bGljYXRpb24gZG9jdW1lbnQ/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0KJmd0OyBGdXR1cmUgZHJhZnRzIG1heSBleHBsb3JlIGFuZCBkZWZpbmUgaG93IHRoZSBF Y2hvIG1vZGUgb2YgQkZEIGlzIHVzZWQgb3ZlciBWWExBTiB0dW5uZWxzLjxiciBjbGFzcz0iIj4N CiZndDsgPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KU2VlIGFib3ZlLjxiciBjbGFzcz0i Ij4NCjxiciBjbGFzcz0iIj4NCiZndDsgV2lsbCByZXZpZXcgYW5kIHJlc3BvbmQgdG8gdGhlIHJl bWFpbmluZyBxdWVzdGlvbnMgc29vbi48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGFu ayB5b3UuIDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NClRoZSAmcXVvdDtyZW1haW5pbmcg cXVlc3Rpb25zJnF1b3Q7IGFyZSBzdGlsbCBhbGwgdGhlIHF1ZXN0aW9ucyBiZWxvdyA6LSk8YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpCZXN0LDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCkNhcmxvcy48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0i Ij4NCiZndDsgUmVnYXJkcyw8YnIgY2xhc3M9IiI+DQomZ3Q7IEdyZWc8YnIgY2xhc3M9IiI+DQom Z3Q7IDxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyBPbiBUaHUsIEp1biAy MCwgMjAxOSBhdCA5OjE0IEFNIENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRhKSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmNwaWduYXRhQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPmNw aWduYXRhQGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCiZndDsgSGksPGJy IGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IEkgaGF2ZSBub3QgcmV2aWV3ZWQg dGhpcyBkcmFmdCBiZWZvcmUsIGJ1dCB0cmlnZ2VyZWQgYnkgdGhpcyBlbWFpbCwgYW5kIGJyaWVm bHkgc2Nhbm5pbmcgdGhyb3VnaCBhIGNvdXBsZSBvZiBzZWN0aW9ucywgaXQgaXMgdW5jbGVhciB0 byBtZSBob3cgc29tZSBvZiB0aGUgbWVjaGFuaWNzIHdvcmsuPGJyIGNsYXNzPSIiPg0KJmd0OyA8 YnIgY2xhc3M9IiI+DQomZ3Q7IFRoZXJlIGFyZSBzb21lIG1ham9yIGlzc3VlcyB3aXRoIHRoZSBN YWMgdXNhZ2UgYW5kIGFzc29jaWF0aW9uLCBhcyBKb2VsIEhhbHBlcm4gbWVudGlvbmVkIGluIGhp cyBSdGcgRGlyIHJldmlldy48YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsg QW5kLCBhZGRpdGlvbmFsbHksIHBsZWFzZSBjb25zaWRlciB0aGUgZm9sbG93aW5nIGNvbW1lbnRz IGFuZCBxdWVzdGlvbnM6PGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IDxi ciBjbGFzcz0iIj4NCiZndDsgMS4gVW5kZXJzcGVjaWZpY2F0aW9uIGZvciBpbml0aWFsaXphdGlv biBhbmQgaW5pdGlhbCBkZW11bHRpcGxleGluZy48YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFz cz0iIj4NCiZndDsgVGhpcyBkb2N1bWVudCBhbGxvd3MgbXVsdGlwbGUgQkZEIHNlc3Npb25zIGJl dHdlZW4gYSBzaW5nbGUgcGFpciBvZiBWVEVQczo8YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFz cz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7IEFuPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJz cDsgaW1wbGVtZW50YXRpb24gdGhhdCBzdXBwb3J0cyB0aGlzIHNwZWNpZmljYXRpb24gTVVTVCBi ZSBhYmxlIHRvPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgY29udHJvbCB0aGUgbnVt YmVyIG9mIEJGRCBzZXNzaW9ucyB0aGF0IGNhbiBiZSBjcmVhdGVkIGJldHdlZW4gdGhlPGJyIGNs YXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgc2FtZSBwYWlyIG9mIFZURVBzLjxiciBjbGFzcz0i Ij4NCiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyBUaGUgaW1wbGljYXRpb24gb2YgdGhpcyBpcyB0 aGF0IEJGRCBzaW5nbGUtaG9wIGluaXRpYWxpemF0aW9uIHByb2NlZHVyZXMgd2lsbCBub3Qgd29y ay4gSW5zdGVhZCwgdGhlcmUgaXMgYSBuZWVkIHRvIG1hcCB0aGUgaW5pdGlhbCBkZW11bHRpcGxl eGluZy48YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsgVGhpcyBpc3N1ZSBp cyBleHBsYWluZWQgaW4gUkZDcyA1ODgyIGFuZCA1ODgzOiA8YSBocmVmPSJodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjNTg4MyNzZWN0aW9uLTQiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0 PSJfYmxhbmsiIGNsYXNzPSIiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU4ODMj c2VjdGlvbi00PC9hPiBhbmQgPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzU4ODIjc2VjdGlvbi02IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0i Ij4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1ODgyI3NlY3Rpb24tNjwvYT48YnIg Y2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsgU2VjdGlvbiA1LjEgc2F5czo8YnIg Y2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7IEZvciBzdWNo IHBhY2tldHMsIHRoZSBCRkQgc2Vzc2lvbiBNVVNUIGJlIGlkZW50aWZpZWQ8YnIgY2xhc3M9IiI+ DQomZ3Q7Jm5ic3A7ICZuYnNwOyB1c2luZyB0aGUgaW5uZXIgaGVhZGVycywgaS5lLiwgdGhlIHNv dXJjZSBJUCwgdGhlIGRlc3RpbmF0aW9uIElQLCBhbmQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7 ICZuYnNwOyB0aGUgc291cmNlIFVEUCBwb3J0IG51bWJlciBwcmVzZW50IGluIHRoZSBJUCBoZWFk ZXIgY2FycmllZCBieSB0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBwYXlsb2Fk IG9mIHRoZSBWWExBTiBlbmNhcHN1bGF0ZWQgcGFja2V0LiZuYnNwOyBUaGUgVk5JIG9mIHRoZSBw YWNrZXQ8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBTSE9VTEQgYmUgdXNlZCB0byBk ZXJpdmUgaW50ZXJmYWNlLXJlbGF0ZWQgaW5mb3JtYXRpb24gZm9yPGJyIGNsYXNzPSIiPg0KJmd0 OyZuYnNwOyAmbmJzcDsgZGVtdWx0aXBsZXhpbmcgdGhlIHBhY2tldC48YnIgY2xhc3M9IiI+DQom Z3Q7IDxiciBjbGFzcz0iIj4NCiZndDsgQnV0IHRoaXMgZG9lcyBub3QgcmVhbGx5IGV4cGxhaW4g aG93IHRvIGRvIHRoZSBpbml0aWFsIGRlbXVsdGlwbGV4aW5nLiBEb2VzIGVhY2ggQkZEIHNlc3Np b24gbmVlZCB0byBoYXZlIGEgc2VwYXJhdGUgaW5uZXIgc291cmNlIElQIGFkZHJlc3M/IE9yIHNv dXJjZSBVRFAgcG9ydD8gQW5kIGhvdyBvZnRlciBhcmUgdGhleSByZWN5Y2xlZCBvciBrZXB0IGFz IHN0YXRlPyBIb3cgYXJlIHRoZXNlIG1hcHBlZD88YnIgY2xhc3M9IiI+DQomZ3Q7IEVxdWFsbHkg aW1wb3J0YW50bHksIHdoaWNoIHNpZGUgaXMgQWN0aXZlPzxiciBjbGFzcz0iIj4NCiZndDsgQW5k IHdoYXQgaWYgdGhlcmXigJlzIGEgcmFjZSBjb25kaXRpb24gd2l0aCBib3RoIHNpZGVzIGJlaW5n IEFjdGl2ZSBhbmQgc2V0dGluZyB1cCByZWR1bmRhbnQgc2Vzc2lvbnM/PGJyIGNsYXNzPSIiPg0K Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IDEuYi4gQnkgdGhlIHdheSwgYmFzZWQgb24gdGhpcywg dXNpbmcgUy1CRkQgW1JGQyA3ODgwXSBtaWdodCBiZSBlYXNpZXIgdG8gZGVtdXguPGJyIGNsYXNz PSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsgMi4gU2Vj dXJpdHk8YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsgVGhpcyBkb2N1bWVu dCBzYXlzIHRoYXQgdGhlIFRUTCBpbiB0aGUgaW5uZXIgcGFja2V0IGNhcnJ5aW5nIEJGRCBpcyBz ZXQgdG8gMS4gSG93ZXZlciwgUkZDIDU4ODAgc2F5cyB0byB1c2UgR1RTTSBbUkZDIDUwODJdLCBp LmUuLCBhIHZhbHVlIG9mIDI1NS4uPGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQom Z3Q7IFdoeSBpcyBHVFNNIG5vdCB1c2VkIGhlcmU/PGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xh c3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsgMy4gRUNNUCBhbmQgZmF0ZS1zaGFyaW5n IHVuZGVyLXNwZWNpZmljYXRpb246PGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQom Z3Q7IFNlY3Rpb24gNC4xLiBzYXlzOjxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNzPSIiPg0K Jmd0OyZuYnNwOyAmbmJzcDsgVGhlIE91dGVyIElQL1VEUDxiciBjbGFzcz0iIj4NCiZndDsmbmJz cDsgJm5ic3A7IGFuZCBWWExBTiBoZWFkZXJzIE1VU1QgYmUgZW5jb2RlZCBieSB0aGUgc2VuZGVy IGFzIGRlZmluZWQgaW48YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBbUkZDNzM0OF0u PGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZn dDsgQW5kIFJGQyA3MzQ4IHNheXM6PGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQom Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LSZuYnNwOyBTb3VyY2UgUG9ydDombmJzcDsg SXQgaXMgcmVjb21tZW5kZWQgdGhhdCB0aGUgVURQIHNvdXJjZSBwb3J0IG51bWJlcjxiciBjbGFz cz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGJlIGNhbGN1bGF0 ZWQgdXNpbmcgYSBoYXNoIG9mIGZpZWxkcyBmcm9tIHRoZSBpbm5lciBwYWNrZXQgLS08YnIgY2xh c3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBvbmUgZXhhbXBs ZSBiZWluZyBhIGhhc2ggb2YgdGhlIGlubmVyIEV0aGVybmV0IGZyYW1lJ3MgaGVhZGVycy48YnIg Y2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBUaGlzIGlz IHRvIGVuYWJsZSBhIGxldmVsIG9mIGVudHJvcHkgZm9yIHRoZSBFQ01QL2xvYWQtPGJyIGNsYXNz PSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYmFsYW5jaW5nIG9m IHRoZSBWTS10by1WTSB0cmFmZmljIGFjcm9zcyB0aGUgVlhMQU4gb3ZlcmxheS48YnIgY2xhc3M9 IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBXaGVuIGNhbGN1bGF0 aW5nIHRoZSBVRFAgc291cmNlIHBvcnQgbnVtYmVyIGluIHRoaXMgbWFubmVyLCBpdDxiciBjbGFz cz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGlzIFJFQ09NTUVO REVEIHRoYXQgdGhlIHZhbHVlIGJlIGluIHRoZSBkeW5hbWljL3ByaXZhdGUgcG9ydDxiciBjbGFz cz0iIj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHJhbmdlIDQ5MTUy LTY1NTM1IFtSRkM2MzM1XS48YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsg PGJyIGNsYXNzPSIiPg0KJmd0OyBCYXNlZCBvbiB0aGlzLCBkZXBlbmRpbmcgb24gdGhlIGhhc2hp bmcgY2FsY3VsYXRpb24sIHRoZSBvdXRlciBzb3VyY2UgVURQIHBvcnQgY2FuIGJlIGRpZmZlcmVu dCBsZWFkaW5nIHRvIGRpZmZlcmVudCBFQ01QIHRyZWF0bWVudC4gRG9lcyBzb21ldGhpbmcgZWxz ZSBuZWVkIHRvIGJlIHNwZWNpZmllZCBoZXJlIGluIHJlZ2FyZHMgdG8gdGhlIG91dGVyIFVEUCBz b3VyY2UgcG9ydD88YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNs YXNzPSIiPg0KJmd0OyA0LiBTZWN0aW9uIDcgc2F5cyB0aGF0IOKAnCBTdXBwb3J0IGZvciBlY2hv IEJGRCBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW504oCdLg0KPGJyIGNsYXNz PSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IEFzc3VtaW5nIHRoaXMgbWVhbnMg4oCcQkZE IEVjaG8gbW9kZeKAnSwgd2h5IGlzIHRoaXMgb3V0IG9mIHNjb3BlPyBJZiB0aGlzIGlzIGEgc2lu Z2xlIGxvZ2ljYWwgaG9wIHVuZGVybmVhdGggVlhMQU4sIHdoYXTigJlzIHByZXZlbnRpbmcgdGhl IHVzZSBvZiBFY2hvPyBFY2hv4oCZcyBiZW5lZml0cyBhcmUgaHVnZS48YnIgY2xhc3M9IiI+DQom Z3Q7IDxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyA1LiBUZXJtaW5vbG9n eTxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgSW1w bGVtZW50YXRpb25zIFNIT1VMRCBlbnN1cmUgdGhhdCB0aGUgQkZEPGJyIGNsYXNzPSIiPg0KJmd0 OyZuYnNwOyAmbmJzcDsgcGFja2V0cyBmb2xsb3cgdGhlIHNhbWUgbG9va3VwIHBhdGggYXMgVlhM QU4gZGF0YSBwYWNrZXRzIHdpdGhpbiB0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNw OyBzZW5kZXIgc3lzdGVtLjxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyBX aGF0IGlzIGEg4oCcbG9vayB1cCBwYXRoIHdpdGhpbiBhIHNlbmRlciBzeXN0ZW3igJ0/PGJyIGNs YXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsgNi4g RGVwbG95bWVudCBzY2VuYXJpb3M8YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4NCiZn dDsgUzMgc2F5czo8YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyBGaWd1cmUgMSBpbGx1 c3RyYXRlcyB0aGUgc2NlbmFyaW8gd2l0aCB0d28gc2VydmVycywgZWFjaCBvZiB0aGVtPGJyIGNs YXNzPSIiPg0KJmd0OyZuYnNwOyAmbmJzcDsgaG9zdGluZyB0d28gVk1zLiZuYnNwOyBUaGUgc2Vy dmVycyBob3N0IFZURVBzIHRoYXQgdGVybWluYXRlIHR3byBWWExBTjxiciBjbGFzcz0iIj4NCiZn dDsgW+KApl08YnIgY2xhc3M9IiI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGaWd1cmUgMTog UmVmZXJlbmNlIFZYTEFOIERvbWFpbjxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNzPSIiPg0K Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7IEhvd2V2ZXIsIFJGQyA3MzQ4IEZpZ3VyZSAzIGxpc3Rz IHRoYXQgYXMgb25lIGRlcGxveW1lbnQgc2NlbmFyaW8sIG5vdCBhcyDigJx0aGUgc2NlbmFyaW/i gJ0gYW5kIOKAnFRoZSBSZWZlcmVuY2UgVlhMQU4gRG9tYWlu4oCdLjxiciBjbGFzcz0iIj4NCiZn dDsgPGJyIGNsYXNzPSIiPg0KJmd0OyBCZXN0LDxiciBjbGFzcz0iIj4NCiZndDsgPGJyIGNsYXNz PSIiPg0KJmd0OyBDYXJsb3MuPGJyIGNsYXNzPSIiPg0KJmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyBPbiBKdW4gMTcsIDIwMTksIGF0IDEyOjU4IEFNLCBHcmVnIE1pcnNreSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmdyZWdpbWlyc2t5QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIi PmdyZWdpbWlyc2t5QGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IEhpIE9saXZlciw8YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyB0aGFuayB5b3UgZm9yIHlvdXIgdGhvcm91Z2ggcmV2aWV3LCBjbGVhciBhbmQgZGV0YWls ZWQgcXVlc3Rpb25zLiBNeSBhcG9sb2dpZXMgZm9yIHRoZSBkZWxheSB0byByZXNwb25kLiBQbGVh c2UgZmluZCBteSBhbnN3ZXJzIGJlbG93IGluLWxpbmUgdGFnZ2VkIEdJTSZndDsmZ3Q7LjxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IFJlZ2FyZHMsPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsgR3JlZzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IDxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7IE9uIEZyaSwgTWF5IDMxLCAyMDE5IGF0IDEyOjM4IFBNIE9saXZpZXIgQm9u YXZlbnR1cmUgdmlhIERhdGF0cmFja2VyICZsdDs8YSBocmVmPSJtYWlsdG86bm9yZXBseUBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiIGNsYXNzPSIiPm5vcmVwbHlAaWV0Zi5vcmc8L2E+Jmd0OyB3 cm90ZTo8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBSZXZpZXdlcjogT2xpdmllciBCb25hdmVudHVy ZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IFJldmlldyByZXN1bHQ6IFJlYWR5IHdpdGggSXNzdWVz PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgVGhpcyBkb2N1 bWVudCBoYXMgYmVlbiByZXZpZXdlZCBhcyBwYXJ0IG9mIHRoZSB0cmFuc3BvcnQgYXJlYSByZXZp ZXcgdGVhbSdzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3 IGtleSBJRVRGIGRvY3VtZW50cy4gVGhlc2UgY29tbWVudHMgd2VyZSB3cml0dGVuPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgcHJpbWFyaWx5IGZvciB0aGUgdHJhbnNwb3J0IGFyZWEgZGlyZWN0b3Jz LCBidXQgYXJlIGNvcGllZCB0byB0aGUgZG9jdW1lbnQnczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 IGF1dGhvcnMgYW5kIFdHIHRvIGFsbG93IHRoZW0gdG8gYWRkcmVzcyBhbnkgaXNzdWVzIHJhaXNl ZCBhbmQgYWxzbyB0byB0aGUgSUVURjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IGRpc2N1c3Npb24g bGlzdCBmb3IgaW5mb3JtYXRpb24uPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgV2hlbiBkb25lIGF0IHRoZSB0aW1lIG9mIElFVEYgTGFzdCBDYWxsLCB0aGUg YXV0aG9ycyBzaG91bGQgY29uc2lkZXIgdGhpczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IHJldmll dyBhcyBwYXJ0IG9mIHRoZSBsYXN0LWNhbGwgY29tbWVudHMgdGhleSByZWNlaXZlLiBQbGVhc2Ug YWx3YXlzIENDPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnRzdi1hcnRA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0iIj50c3YtYXJ0QGlldGYub3JnPC9hPiBp ZiB5b3UgcmVwbHkgdG8gb3IgZm9yd2FyZCB0aGlzIHJldmlldy48YnIgY2xhc3M9IiI+DQomZ3Q7 Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBJIGhhdmUgb25seSBsaW1pdGVkIGtub3dsZWRn ZSBvZiBWWExBTiBhbmQgZG8gbm90IGtub3cgYWxsIHN1YnRsZXRpZXMgb2YgQkZELjxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7IFRoaXMgcmV2aWV3IGlzIHRodXMgbW9yZSBmcm9tIGEgZ2VuZXJhbGlz dCB0aGFuIGEgc3BlY2lhbGlzdCBpbiB0aGlzIHRvcGljLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IE1ham9yIGlzc3VlczxiciBjbGFzcz0iIj4NCiZndDsm Z3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IFNlY3Rpb24gNCByZXF1aXJlcyB0aGF0ICZxdW90 OyBJbXBsZW1lbnRhdGlvbnMgU0hPVUxEIGVuc3VyZSB0aGF0IHRoZSBCRkQ8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgcGFja2V0cyBmb2xsb3cgdGhlIHNhbWUgbG9va3VwIHBh dGggYXMgVlhMQU4gZGF0YSBwYWNrZXRzIHdpdGhpbiB0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyZuYnNwOyAmbmJzcDsgc2VuZGVyIHN5c3RlbS4mcXVvdDs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBXaHkgaXMgdGhpcyByZXF1aXJlbWVudCBvbmx5IHJl bGV2YW50IGZvciB0aGUgbG9va3VwIHBhdGggb24gdGhlIHNlbmRlciBzeXN0ZW08YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyA/IFdoYXQgZG9lcyB0aGlzIHNlbnRlbmNlIHJlYWxseSBpbXBsaWVzID88 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBHSU0mZ3Q7Jmd0OyBSRkMgNTg4MCBzZXQgdGhlIHNjb3Bl IG9mIHRoZSBmYXVsdCBkZXRlY3Rpb24gb2YgQkZEIHByb3RvY29sIGFzIDxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAuLi4gdGhlIGJpZGlyZWN0aW9uYWwgcGF0aCBiZXR3ZWVu IHR3byBmb3J3YXJkaW5nIGVuZ2luZXMsIGluY2x1ZGluZzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7 Jm5ic3A7ICZuYnNwOyBpbnRlcmZhY2VzLCBkYXRhIGxpbmsocyksIGFuZCB0byB0aGUgZXh0ZW50 IHBvc3NpYmxlIHRoZSBmb3J3YXJkaW5nPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmbmJzcDsgJm5i c3A7IGVuZ2luZXMgdGhlbXNlbHZlcyAuLi48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBUaGUgcmVx dWlyZW1lbnQgYWltZWQgdG8gdGhlIGZvcndhcmRpbmcgZW5naW5lIG9mIGEgQkZEIHN5c3RlbSB0 aGF0IHRyYW5zbWl0cyBCRkQgY29udHJvbCBwYWNrZXRzIG92ZXIgVlhMQU4gdHVubmVsLjxiciBj bGFzcz0iIj4NCiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IElzIGl0IGEgcmVxdWly ZW1lbnQgdGhhdCB0aGUgQkZEIHBhY2tldHMgZm9sbG93IHRoZSBzYW1lIHBhdGggYXMgdGhlIGRh dGE8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBwYWNrZXQgZm9yIGEgZ2l2ZW4gVlhMQU4gPyBJIGd1 ZXNzIHNvLiBJbiB0aGlzIGNhc2UsIHRoZSBkb2N1bWVudCBzaG91bGQ8YnIgY2xhc3M9IiI+DQom Z3Q7Jmd0OyBkaXNjdXNzIGhvdyBFcXVhbCBDb3N0IE11bHRpcGF0aCBjb3VsZCBhZmZlY3QgdGhp cy48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBHSU0mZ3Q7Jmd0OyBJIHRoaW5rIHRoYXQgRUNNUCBl bnZpcm9ubWVudCBpcyBtb3JlIGxpa2VseSB0byBiZSBleHBlcmllbmNlZCBieSBhIHRyYW5zaXQg bm9kZSBpbiB0aGUgdW5kZXJsYXkuIElmIHRoZSBCRkQgc2Vzc2lvbiBpcyB1c2VkIHRvIG1vbml0 b3IgdGhlIHNwZWNpZmljIHVuZGVybGF5IHBhdGgsIHRoZW4sIEkgYWdyZWUsIHdlIHNob3VsZCBl eHBsYWluIHRoYXQgdXNpbmcgdGhlIFZYTEFOIHBheWxvYWQgaW5mb3JtYXRpb24gdG8gZHJhdyBw YXRoDQogZW50cm9weSBtYXkgY2F1c2UgZGF0YSBhbmQgQkZEIHBhY2tldHMgZm9sbG93aW5nIGRp ZmZlcmVudCB1bmRlcmxheSByb3V0ZXMuIEJ1dCwgb24gdGhlIG90aGVyIGhhbmQsIHRoYXQgaXMg dGhlIGNhc2UgZm9yIE9BTSBhbmQgZmF1bHQgZGV0ZWN0aW9uIGluIGFsbCBvdmVybGF5IG5ldHdv cmtzIGluIGdlbmVyYWwuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsgTWlub3IgaXNzdWVzPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgU2VjdGlvbiAxPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0K Jmd0OyZndDsgWW91IHdyaXRlICZxdW90O1RoZSBhc3luY2hyb25vdXMgbW9kZSBvZiBCRkQsIGFz IGRlZmluZWQgaW4gW1JGQzU4ODBdLDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7IGNhbiBi ZSB1c2VkIHRvIG1vbml0b3IgYSBwMnAgVlhMQU4gdHVubmVsLiZxdW90OzxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IFdoeSBkbyB5b3UgdXNlIHRoZSB3b3Jk IGNhbiA/IEl0IGlzIGEgcG9zc2liaWxpdHkgb3IgYSByZXF1aXJlbWVudCA/PGJyIGNsYXNzPSIi Pg0KJmd0OyZndDsgR0lNJmd0OyZndDsgSW4gcHJpbmNpcGxlLCBCRkQgRGVtYW5kIG1vZGUgbWF5 IGJlIHVzZWQgdG8gbW9uaXRvciBwMnAgcGF0aHMgYXMgd2VsbCwgSSBhZ3JlZSwgd2lsbCByZS13 b3JkIHRvIG1vcmUgYXNzZXJ0aXZlOjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7IFRoZSBh c3luY2hyb25vdXMgbW9kZSBvZiBCRkQsIGFzIGRlZmluZWQgaW4gW1JGQzU4ODBdLDxiciBjbGFz cz0iIj4NCiZndDsmZ3Q7Jm5ic3A7IGlzIHVzZWQgdG8gbW9uaXRvciBhIHAycCBWWExBTiB0dW5u ZWwuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgTlZFIGhh cyBub3QgYmVlbiBkZWZpbmVkIGJlZm9yZSBhbmQgaXMgbm90IGluIHRoZSB0ZXJtaW5vbG9neS48 YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBHSU0mZ3Q7Jmd0OyBXaWxsIGFkZCB0byB0aGUgVGVybWlu b2xvZ3kgYW5kIGV4cGFuZCBhczo8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBOVkUmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgTmV0d29yayBWaXJ0dWFsaXphdGlvbiBFbmRwb2ludCA8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBUaGlzIGVudGlyZSBzZWN0 aW9uIGlzIG5vdCBlYXN5IHRvIHJlYWQgZm9yIGFuIG91dHNpZGVyLjxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IFNlY3Rpb24gMzxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IFZOSSBoYXMgbm90IGJlZW4gZGVmaW5lZDxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7IEdJTSZndDsmZ3Q7IFdpbGwgYWRkIHRvIHRoZSBUZXJtaW5v bG9neSBzZWN0aW9uOjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IFZOSSZuYnNwOyAmbmJzcDsgVlhM QU4gTmV0d29yayBJZGVudGlmaWVyIChvciBWWExBTiBTZWdtZW50IElEKTxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IEZpZ3VyZSAxIGNvdWxkIHRha2UgbGVz cyBzcGFjZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IEdJTSZndDsmZ3Q7IFllcywgY2FuIG1ha2Ug aXQgYml0IGRlbnNlci4gV291bGQgdGhlIGZvbGxvd2luZyBiZSBhbiBpbXByb3ZlbWVudD88YnIg Y2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyYjNDM7LS0tLS0tLS0tLS0tJiM0MzstLS0tLS0tLS0tLS0tJiM0 Mzs8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU2VydmVyIDEmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IHw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO3wgJiM0MzstLS0tJiM0MzstLS0tJiM0MzsmbmJzcDsgJiM0MzstLS0tJiM0MzstLS0tJiM0 MzsgfDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCB8 Vk0xLTEmbmJzcDsgJm5ic3A7IHwmbmJzcDsgfFZNMS0yJm5ic3A7ICZuYnNwOyB8IHw8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgfFZOSSAxMDAmbmJz cDsgfCZuYnNwOyB8Vk5JIDIwMCZuYnNwOyB8IHw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgfCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDt8Jm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCB8PGJyIGNsYXNz PSIiPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICYjNDM7LS0tLS0tLS0t JiM0MzsmbmJzcDsgJiM0MzstLS0tLS0tLS0mIzQzOyB8PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8IEh5cGVydmlzb3IgVlRFUCAoSVAxKSZuYnNwOyAm bmJzcDsgfDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 JiM0MzstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7fCZuYnNwOyAmbmJzcDsmIzQzOy0tLS0tLS0tLS0tLS0mIzQzOzxiciBjbGFzcz0iIj4N CiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8 Jm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7TGF5ZXIgMyZuYnNwOyAmbmJzcDt8PGJyIGNsYXNz PSIiPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyYjNDM7LS0tfCZuYnNwOyAmbmJzcDtOZXR3b3JrJm5ic3A7ICZuYnNwO3w8YnIgY2xhc3M9 IiI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsmIzQzOy0tLS0tLS0tLS0tLS0mIzQzOzxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7JiM0MzstLS0tLS0tLS0tLSYjNDM7PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8 PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm IzQzOy0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLSYjNDM7PGJyIGNsYXNzPSIiPg0KJmd0 OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8Jm5ic3A7ICZuYnNwOyBIeXBl cnZpc29yIFZURVAgKElQMikgfDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgfCAmIzQzOy0tLS0mIzQzOy0tLS0mIzQzOyZuYnNwOyAmIzQzOy0t LS0mIzQzOy0tLS0mIzQzOyB8PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyB8IHxWTTItMSZuYnNwOyAmbmJzcDsgfCZuYnNwOyB8Vk0yLTImbmJz cDsgJm5ic3A7IHwgfDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgfCB8Vk5JIDEwMCZuYnNwOyB8Jm5ic3A7IHxWTkkgMjAwJm5ic3A7IHwgfDxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfCB8 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgfCZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDt8IHw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHwgJiM0MzstLS0tLS0tLS0mIzQzOyZuYnNwOyAmIzQzOy0t LS0tLS0tLSYjNDM7IHw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHwmbmJzcDsgJm5ic3A7ICZuYnNwOyBTZXJ2ZXIgMiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0mIzQzOzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IDxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7IFNlY3Rpb24gNDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IDxi ciBjbGFzcz0iIj4NCiZndDsmZ3Q7IEkgZG8gbm90IHNlZSB0aGUgYmVuZWZpdHMgb2YgaGF2aW5n IG9uZSBwYXJhZ3JhcGggaW4gU2VjdGlvbiA0IGZvbGxvd2VkIGJ5IG9ubHk8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyBTZWN0aW9uIDQuMTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IEdJTSZndDsmZ3Q7 IFdpbGwgbWVyZ2UgU2VjdGlvbiA0LjEgaW50byA0IHdpdGggbWlub3IgcmVxdWlyZWQgcmUtd29y ZGluZzo8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyA0LiZuYnNwOyBCRkQgUGFja2V0IFRyYW5zbWlz c2lvbiBvdmVyIFZYTEFOIFR1bm5lbDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IDxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBCRkQgcGFja2V0IE1VU1QgYmUgZW5jYXBzdWxhdGVk IGFuZCBzZW50IHRvIGEgcmVtb3RlIFZURVAgYXM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNw OyAmbmJzcDsgZXhwbGFpbmVkIGluIHRoaXMgc2VjdGlvbi4mbmJzcDsgSW1wbGVtZW50YXRpb25z IFNIT1VMRCBlbnN1cmUgdGhhdCB0aGU8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJz cDsgQkZEIHBhY2tldHMgZm9sbG93IHRoZSBzYW1lIGxvb2t1cCBwYXRoIGFzIFZYTEFOIGRhdGEg cGFja2V0cyB3aXRoaW48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgdGhlIHNl bmRlciBzeXN0ZW0uPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsmbmJzcDsgJm5ic3A7IEJGRCBwYWNrZXRzIGFyZSBlbmNhcHN1bGF0ZWQgaW4gVlhMQU4gYXMg ZGVzY3JpYmVkIGJlbG93LiZuYnNwOyBUaGUgVlhMQU48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZu YnNwOyAmbmJzcDsgcGFja2V0IGZvcm1hdCBpcyBkZWZpbmVkIGluIFNlY3Rpb24gNSBvZiBbUkZD NzM0OF0uJm5ic3A7IFRoZSBPdXRlciBJUC9VRFA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNw OyAmbmJzcDsgYW5kIFZYTEFOIGhlYWRlcnMgTVVTVCBiZSBlbmNvZGVkIGJ5IHRoZSBzZW5kZXIg YXMgZGVmaW5lZCBpbjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBbUkZDNzM0 OF0uPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgU2VjdGlv biA0LjE8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBUaGUg ZG9jdW1lbnQgZG9lcyBub3Qgc3BlY2lmeSB3aGVuIGEgZGVkaWNhdGVkIE1BQyBhZGRyZXNzIG9y IHRoZSBNQUMgYWRkcmVzczxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IG9mIHRoZSBkZXN0aW5hdGlv biBWVEVQIG11c3QgYmUgdXNlZC4gVGhpcyBjb3VsZCBhZmZlY3QgdGhlIGludGVyb3BlcmFiaWxp dHkgb2Y8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBpbXBsZW1lbnRhdGlvbnMuIFNob3VsZCBhbGwg aW1wbGVtZW50YXRpb25zIHN1cHBvcnQgYm90aCB0aGUgZGVkaWNhdGVkIE1BQzxiciBjbGFzcz0i Ij4NCiZndDsmZ3Q7IGFkZHJlc3MgYW5kIHRoZSBkZXN0aW5hdGlvbiBNQUMgYWRkcmVzcyA/PGJy IGNsYXNzPSIiPg0KJmd0OyZndDsgR0lNJmd0OyZndDsgQWZ0ZXIgZnVydGhlciBkaXNjdXNzaW9u LCBhdXRob3JzIGRlY2lkZWQgdG8gcmVtb3ZlIHRoZSByZXF1ZXN0IGZvciB0aGUgZGVkaWNhdGVk IE1BQyBhZGRyZXNzIGFsbG9jYXRpb24uIE9ubHkgdGhlIE1BQyBhZGRyZXNzIG9mIHRoZSByZW1v dGUgVlRFUCBtdXN0IGJlIHVzZWQgYXMgdGhlIGRlc3RpbmF0aW9uIE1BQyBhZGRyZXNzIGluIHRo ZSBpbm5lciBFdGhlcm5ldCBmcmFtZS4gUGxlYXNlIGNoZWNrIHRoZSBhdHRhY2hlZCBkaWZmDQog YmV0d2VlbiB0aGUgLTA3IGFuZCB0aGUgd29ya2luZyB2ZXJzaW9ucyBvciB0aGUgd29ya2luZyB2 ZXJzaW9uIG9mIHRoZSBkcmFmdC48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyA8YnIgY2xhc3M9IiI+ DQomZ3Q7Jmd0OyBJdCBpcyB1bmNsZWFyIGZyb20gdGhpcyBzZWN0aW9uIHdoZXRoZXIgSVB2NCBp bnNpZGUgSVB2NiBhbmQgdGhlIG9wcG9zaXRlPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgc2hvdWxk IGJlIHN1cHBvcnRlZCBvciBub3QuPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgR0lNJmd0OyZndDsg QW55IGNvbWJpbmF0aW9uIG9mIG91dGVyIElQdlggYW5kIGlubmVyIElQdlggaXMgcG9zc2libGUu PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgU2VjdGlvbiA1 LjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IElmIHRoZSBy ZWNlaXZlZCBwYWNrZXQgZG9lcyBub3QgbWF0Y2ggdGhlIGRlZGljYXRlZCBNQUMgYWRkcmVzcyBu b3IgdGhlIE1BQzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IGFkZHJlc3Mgb2YgdGhlIFZURVAsIHNo b3VsZCB0aGUgcGFja2V0IGJlIHNpbGVudGx5IGRpc2NhcmRlZCBvciB0cmVhdGVkPGJyIGNsYXNz PSIiPg0KJmd0OyZndDsgZGlmZmVyZW50bHkgPzxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IEdJTSZn dDsmZ3Q7IEFzIEkndmUgbWVudGlvbmVkIGVhcmxpZXIsIGF1dGhvcnMgaGF2ZSBkZWNpZGVkIHRv IHJlbW92ZSB0aGUgdXNlIG9mIHRoZSBkZWRpY2F0ZWQgTUFDIGFkZHJlc3MgZm9yIEJGRCBvdmVy IFZYTEFOLjxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IDxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7IFNl Y3Rpb24gNS4xPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsg SXMgdGhpcyBhIG1vZGlmaWNhdGlvbiB0byBzZWN0aW9uIDYuMyBvZiBSRkM1ODgwID8gVGhpcyBp cyBub3QgY2xlYXI8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBHSU0mZ3Q7Jmd0OyBJIHRoaW5rIHRo YXQgdGhpcyBzZWN0aW9uIGlzIG5vdCBtb2RpZmljYXRpb24gYnV0IHRoZSBkZWZpbml0aW9uIG9m IHRoZSBhcHBsaWNhdGlvbi1zcGVjaWZpYyBwcm9jZWR1cmUgdGhhdCBpcyBvdXRzaWRlIHRoZSBz Y29wZSBvZiBSRkMgNTg4MDo8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgVGhl IG1ldGhvZCBvZiBkZW11bHRpcGxleGluZyB0aGUgaW5pdGlhbCBwYWNrZXRzIChpbiB3aGljaCBZ b3VyPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7IERpc2NyaW1pbmF0b3IgaXMg emVybykgaXMgYXBwbGljYXRpb24gZGVwZW5kZW50LCBhbmQgaXMgdGh1cyBvdXRzaWRlPGJyIGNs YXNzPSIiPg0KJmd0OyZndDsmbmJzcDsgJm5ic3A7IHRoZSBzY29wZSBvZiB0aGlzIHNwZWNpZmlj YXRpb24uPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgU2Vj dGlvbiA5PGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsgVGhl IHNlbnRlbmNlICZxdW90OyBUaHJvdHRsaW5nIE1BWSBiZSByZWxheGVkIGZvciBCRkQgcGFja2V0 czxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBiYXNlZCBvbiBwb3J0IG51bWJl ci4mcXVvdDsgaXMgdW5jbGVhci48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyBHSU0mZ3Q7Jmd0OyBZ ZXMsIHRoYW5rIHlvdSBmb3IgcG9pbnRpbmcgdG8gdGhpcy4gVGhlIHVwZGF0ZWQgdGV4dCwgaW4g dGhlIHdob2xlIHBhcmFncmFwaCwgaXMgYXMgZm9sbG93czo8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0 OyBORVcgVEVYVDo8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgVGhlIGRvY3Vt ZW50IHJlcXVpcmVzIHNldHRpbmcgdGhlIGlubmVyIElQIFRUTCB0byAxLCB3aGljaCBjb3VsZCBi ZTxiciBjbGFzcz0iIj4NCiZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyB1c2VkIGFzIGEgRERvUyBhdHRh Y2sgdmVjdG9yLiZuYnNwOyBUaHVzIHRoZSBpbXBsZW1lbnRhdGlvbiBNVVNUIGhhdmU8YnIgY2xh c3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgdGhyb3R0bGluZyBpbiBwbGFjZSB0byBjb250 cm9sIHRoZSByYXRlIG9mIEJGRCBjb250cm9sIHBhY2tldHMgc2VudDxiciBjbGFzcz0iIj4NCiZn dDsmZ3Q7Jm5ic3A7ICZuYnNwOyB0byB0aGUgY29udHJvbCBwbGFuZS4mbmJzcDsgT24gdGhlIG90 aGVyIGhhbmQsIG92ZXIgYWdncmVzc2l2ZSB0aHJvdHRsaW5nPGJyIGNsYXNzPSIiPg0KJmd0OyZn dDsmbmJzcDsgJm5ic3A7IG9mIEJGRCBjb250cm9sIHBhY2tldHMgbWF5IGJlY29tZSB0aGUgY2F1 c2Ugb2YgdGhlIGluYWJpbGl0eSB0byBmb3JtPGJyIGNsYXNzPSIiPg0KJmd0OyZndDsmbmJzcDsg Jm5ic3A7IGFuZCBtYWludGFpbiBCRkQgc2Vzc2lvbiBhdCBzY2FsZS4mbmJzcDsgSGVuY2UsIHRo cm90dGxpbmcgb2YgQkZEIGNvbnRyb2w8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJz cDsgcGFja2V0cyBTSE9VTEQgYmUgYWRqdXN0ZWQgdG8gcGVybWl0IEJGRCB0byB3b3JrIGFjY29y ZGluZyB0byBpdHM8YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgcHJvY2VkdXJl cy48YnIgY2xhc3M9IiI+DQomZ3Q7Jmd0OyAmbHQ7ZHJhZnQtaWV0Zi1iZmQtdnhsYW4tMDgudHh0 Jmd0OyZsdDtEaWZmXyBkcmFmdC1pZXRmLWJmZC12eGxhbi0wNy50eHQgLSBkcmFmdC1pZXRmLWJm ZC12eGxhbi0wOC50eHQuaHRtbCZndDs8YnIgY2xhc3M9IiI+DQomZ3Q7IDxiciBjbGFzcz0iIj4N CjxiciBjbGFzcz0iIj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_BADB8CA6FCAC47A38B06F82E98A89549ciscocom_-- From nobody Thu Jun 20 05:03:53 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954C4120471; Wed, 19 Jun 2019 22:30:35 -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_HELO_NONE=0.001, 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 xeoUZ9NzHXJQ; Wed, 19 Jun 2019 22:30:31 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 61BC412008D; Wed, 19 Jun 2019 22:30:30 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id r9so1449799ljg.5; Wed, 19 Jun 2019 22:30: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; bh=Vz0AJQgd0YtYcJr4RKZ9RE2XVoDZhAVwCLlAnU3A/ys=; b=u8CFPhfgMbV+n1OVXdX96ydrSX+iSmt16AIB+5gMxcVReFFw68iFSoYSobrHjhhy8N 6c0HPh+8M1A3sRuAce5jtzjpMGv/TIBrnUqukibBtYdPKY6mPR88tUAkMpd5RHH2T8oZ ElwfGQ9mrVf37af4agp8JAmQOYnACmz43xJoqVaV438ymtOHvPJ0R44pv+gRwvhOtzzI 3qPQ66RhGYMDCal37DmgEF93wVXwnB4e5pNuYpbL1CtijrkhYrGFVjsQB10gsEO7JHgJ 970JrRmkuaEDuQDmh+qUTfUR7jziYgKQ7ugrqnQzP92NyDc3d/zXSmVvWNalr7ZMzLR/ KCSw== 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=Vz0AJQgd0YtYcJr4RKZ9RE2XVoDZhAVwCLlAnU3A/ys=; b=Ae2BpkMm4JWcI00PT6JeOf6V/5Hhh26TZ8R+8yoTFyLRprzvgzG5H7RhigWRzQQWGV 2k2RVvq8l2f/5bCFb5A+miSpYDip9EbnPuFvoRaymU2f9nxiY1TxfjcbSO31n8vf0jmu pjeszqaWvCXuoZVeiPdNpGQt/ZkJsvAwi1FIcriTjPjzmXptd0JbJN1KBRK2os8nGYk1 yFsGrB5WQyUtqjRnKxPqbnAjsGcph+Zl13gdalFso1mdPBzlgWbft68stUTlxAVgAFey kPbNOENX3//eLh66hgGODhZsAoIV4HpkBoRwufcv8YOxBEAg9HVQbSS+phdLkJhNNNhc kEqw== X-Gm-Message-State: APjAAAV7VHTcncUqQfnIcdr1BkViAPKVGO5Pk7jb56Miuo7aeuPJOaZ2 z4X0MozWIyTxPdvos7nR+E0IidQ+iIIhhzk1S5o= X-Google-Smtp-Source: APXvYqzl9/rrzbcl+8xGpKqzl73EfY0cDCpAN0rsmLJ9vYFc/BLWCymizL88w11WxI9vF8/9ub2uhX6gCoSMc937XBQ= X-Received: by 2002:a2e:9ac6:: with SMTP id p6mr40590861ljj.100.1561008628194; Wed, 19 Jun 2019 22:30:28 -0700 (PDT) MIME-Version: 1.0 References: <155933149484.6565.7386019489022348116@ietfa.amsl.com> <14822B96-D3C6-495E-8661-198068F72ABA@cisco.com> <8237FE8D-937E-4BCB-B1A3-89C2B3CDC51C@cisco.com> <0B9FDA17-7F13-4FEC-AE97-40BC9D72C87B@cisco.com> In-Reply-To: From: Greg Mirsky Date: Thu, 20 Jun 2019 14:30:15 +0900 Message-ID: Subject: Re: Level of standardization of the Echo mode of BFD [Re: Tsvart last call review of draft-ietf-bfd-vxlan-07] To: "Carlos Pignataro (cpignata)" Cc: "tsv-art@ietf.org" , rtg-bfd WG , "draft-ietf-bfd-vxlan.all@ietf.org" , Olivier Bonaventure , IETF list Content-Type: multipart/alternative; boundary="000000000000c6602e058bbaa424" Archived-At: X-Mailman-Approved-At: Thu, 20 Jun 2019 05:03:36 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2019 05:30:36 -0000 --000000000000c6602e058bbaa424 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Carlos, thank you for clarifying your opinion on the applicability of the BFD Echo mode. I've split this thread to help us and others to follow the discussion on this particular issue. I'll note that RFC 5880 does not prohibit the remote system to perform any kind of processing on the packet received in the BFD Echo mode. Even more, Section 6.8.8 explicitly points out that a received Echo packet is likely to be processed: A means of detecting missing Echo packets MUST be implemented, which most likely involves processing of the Echo packets that are received. The processing of received Echo packets is otherwise outside the scope of this specification. Thus, interoperability is one of the underspecified issues for BFD Echo. Secondly, the Echo BFD mode has been excluded from the scope of RFC 5884: Further, the use of the Echo function is outside the scope of this specification. Would you suggest that the scope of RFC 5884 must include the BFD Echo function? Regards, Greg On Thu, Jun 20, 2019 at 2:08 PM Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Hello, Greg, > > Yes, happy too answer your question. > > First, however, let me make two quick observations on the exchange: > > 1. You seem to be picking very specific fragments or sub-topics from > my comments, and following up on those only. > 2. I=E2=80=99m happy to continue answering these questions, but they a= re > orthogonal to (and consequently a distraction from) the initial commen= ts I > raised. > > > Now, your question: the BFD Echo packet format is generically spec=E2=80= =99ed and > defined in Section 5 of RFC 5880: > https://tools.ietf.org/html/rfc5880#section-5 > > The most relevant part is this: > > The payload of a BFD Echo packet is a local matter, since only the > sending system ever processes the content. The only requirement is > that sufficient information is included to demultiplex the received > packet to the correct BFD session after it is looped back to the > sender. > > Since the remote system does not process the echo packet content, it is a > local matter only. And given the fact that, as such, there is no > interoperability implications, there is no need to over-specify the packe= t > format. The only requirement is that the sending system needs to be able = to > map it to a session when it boomerangs back. > > No, it is generally not (i.e., does not need to be, but there=E2=80=99s f= reedom to > potentially be) a BFD control packet. > Yes, it can be something else. > > That said, the packet format for BFD Echo has, to my analysis and > understanding, no relevancy on the questions below. > > Best, > > Carlos. > > On Jun 20, 2019, at 12:50 AM, Greg Mirsky wrote: > > Hello Carlos, > could you please refer me to the specification of BFD that defines the > message format that is used in the Echo mode of BFD. Is it the BFD contro= l > packet? Something else? > > Regards, > Greg > > > On Thu, Jun 20, 2019 at 11:09 AM Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > >> Hello, Greg, >> >> Please see inline. >> >> On Jun 19, 2019, at 9:58 PM, Greg Mirsky wrote: >> >> Hello Carlos, >> thank you for the expedient clarification. >> To your questions on demultiplexing BFD control packets with the zero >> value of the Your Discriminator field: >> >> - only BFD control packets with the zero value of the Your >> Discriminator field are demultiplexed using the information of the in= ner IP >> header. I believe that the text is clear and requires that all fields= of >> the inner IP header must be used to demultiplex a received BFD contro= l >> packet with the zero value in the Your Discriminator field. Which of = the >> fields an implementation uses to create multiple BFD sessions between= the >> pair of VTEPs is implementation specific. >> >> This text is repeating was is in the draft, but does not answer any of m= y >> questions. >> >> For example: >> 1. "that all fields of the inner IP header must be used to demultiplex a >> received BFD control packet=E2=80=9D >> -> The text does not say =E2=80=9Call fields=E2=80=9D, but regardles= s, do you mean >> the DSCP and the Evil Bit? IPv6 Flow Label? How *exactly*? >> 2. How is the mapping of IP (not UDP?) fields to BFD session done? >> 3. How is this state created and maintained? >> 4. Since this is a set of fields on which two systems need to agree >> (which fields from the inner IP/UDP are mapped needs to be understood by >> both systems), it cannot be =E2=80=9Cimplementation specific=E2=80=9D. F= urther, the text >> does not say so. >> >> To your point on the level Echo mode of BFD is specified in RFC 5880 I'l= l >> quote the opinion of Jeffrey Haas from the discussion of comments from >> Shawn Emery on behalf of the SecDir. Shawn had commented: >> >> Echo BFD is out of scope for the document, but does not describe the >> reason for this or why state >> >> this at all? >> >> I've responded: >> >> GIM>> I think that the main reason is that the BFD Echo mode is >> underspecified. RFC 5880 defined some of the mechanisms related to the E= cho >> mode, but more standardization work may be required. >> >> And Jeffrey Haas had added: >> >> Speaking as a BFD chair, this is the relevant observation. BFD Echo is >> underspecified to the point where claiming compliance is difficult at >> best. >> In general, it relies on single-hop and the ability to have the remote >> Echo >> client loop the packets. >> >> >> BFD Echo cannot be specified in RFC 5880 base spec because it is >> application specific. >> >> >> This packet loop may not be practical for several encapsulations and thu= s >> is >> out of scope for such encapsulations. Whether this is practical for vxl= an >> today, or in the presence of future extensions to vxlan is left out of >> scope >> for the core proposal. >> >> >> The question remains: for VXLAN encapsulation, this is like a single hop >> as far as BFD is concerned (single hop VXLAN tunnel). >> >> Since RFC 5881 defines Echo for single hop, can you please elaborate (in >> the document) why is out of scope or how it can work? >> >> Best, >> >> Carlos. >> >> >> Will respond to other questions in a separate mail. >> >> Regards, >> Greg >> >> >> On Thu, Jun 20, 2019 at 10:31 AM Carlos Pignataro (cpignata) < >> cpignata@cisco.com> wrote: >> >>> Hello, Greg, >>> >>> > On Jun 19, 2019, at 9:09 PM, Greg Mirsky >>> wrote: >>> > >>> > Hi Carlos, >>> > thank you for reminding of our continued discussion with Joel. We are >>> seeking comments from VXLAN experts and much appreciate if you have >>> insights on VXLAN to share. >>> > I've got some clarifying questions before I can respond to you. >>> >>> Sure. >>> >>> > To which stage of the three-way handshake you refer as "initial >>> demultiplexing"? I couldn't find this term in RFC 5880. >>> >>> =E2=80=9CInitial demultiplexing" is a well-known term in BFD, referring= to the >>> "demultiplexing of the initial packets", BFD Control packet with YourDi= sc >>> being zero. >>> >>> In RFC 5880, see Section 6.3. >>> https://tools.ietf.org/html/rfc5880#section-6.3 >>> >>> The method of demultiplexing the initial packets (in which Your >>> Discriminator is zero) is application dependent, and is thus outside >>> the scope of this specification. >>> >>> Since initial demultiplexing is indeed application specific, different >>> for one-hop versus multi-hop and dependent upon whether a single or >>> multiple sessions are allowed between a pair of endpoints, I added belo= w >>> two other relevant citations, from application specific BFD specs: >>> 1. https://tools.ietf.org/html/rfc5883#section-4 >>> 2. https://tools.ietf.org/html/rfc5882#section-6 >>> >>> >>> > Regarding the applicability of the Echo mode, thank you for pointing >>> to the need for stricter terminology, the Echo mode, as defined in RFC >>> 5880, is underspecified and it will require additional standardization. >>> >>> No. BFD Echo is not underspecified in RFC 5880. >>> >>> Please read S5: https://tools.ietf.org/html/rfc5880#section-5 >>> >>> BFD Echo packets are sent in an encapsulation appropriate to the >>> environment. See the appropriate application documents for the >>> specifics of particular environments. >>> >>> >>> BFD Echo is application dependent. >>> >>> Therefore, for example, single-hop BFD in RFC 5881 specifies BFD Echo >>> for that application. >>> >>> Hence, my question stands: why is this draft claiming BFD Echo is out o= f >>> scope for this BFD application document? >>> >>> >>> > Future drafts may explore and define how the Echo mode of BFD is used >>> over VXLAN tunnels. >>> > >>> >>> See above. >>> >>> > Will review and respond to the remaining questions soon. >>> >>> Thank you. >>> >>> The "remaining questions" are still all the questions below :-) >>> >>> Best, >>> >>> Carlos. >>> >>> > >>> > Regards, >>> > Greg >>> > >>> > >>> > On Thu, Jun 20, 2019 at 9:14 AM Carlos Pignataro (cpignata) < >>> cpignata@cisco.com> wrote: >>> > Hi, >>> > >>> > I have not reviewed this draft before, but triggered by this email, >>> and briefly scanning through a couple of sections, it is unclear to me = how >>> some of the mechanics work. >>> > >>> > There are some major issues with the Mac usage and association, as >>> Joel Halpern mentioned in his Rtg Dir review. >>> > >>> > And, additionally, please consider the following comments and >>> questions: >>> > >>> > >>> > 1. Underspecification for initialization and initial demultiplexing. >>> > >>> > This document allows multiple BFD sessions between a single pair of >>> VTEPs: >>> > >>> > An >>> > implementation that supports this specification MUST be able to >>> > control the number of BFD sessions that can be created between the >>> > same pair of VTEPs. >>> > >>> > The implication of this is that BFD single-hop initialization >>> procedures will not work. Instead, there is a need to map the initial >>> demultiplexing. >>> > >>> > This issue is explained in RFCs 5882 and 5883: >>> https://tools.ietf.org/html/rfc5883#section-4 and >>> https://tools.ietf.org/html/rfc5882#section-6 >>> > >>> > Section 5.1 says: >>> > >>> > For such packets, the BFD session MUST be identified >>> > using the inner headers, i.e., the source IP, the destination IP, >>> and >>> > the source UDP port number present in the IP header carried by the >>> > payload of the VXLAN encapsulated packet. The VNI of the packet >>> > SHOULD be used to derive interface-related information for >>> > demultiplexing the packet. >>> > >>> > But this does not really explain how to do the initial demultiplexing= . >>> Does each BFD session need to have a separate inner source IP address? = Or >>> source UDP port? And how ofter are they recycled or kept as state? How = are >>> these mapped? >>> > Equally importantly, which side is Active? >>> > And what if there=E2=80=99s a race condition with both sides being Ac= tive and >>> setting up redundant sessions? >>> > >>> > 1.b. By the way, based on this, using S-BFD [RFC 7880] might be easie= r >>> to demux. >>> > >>> > >>> > 2. Security >>> > >>> > This document says that the TTL in the inner packet carrying BFD is >>> set to 1. However, RFC 5880 says to use GTSM [RFC 5082], i.e., a value = of >>> 255.. >>> > >>> > Why is GTSM not used here? >>> > >>> > >>> > 3. ECMP and fate-sharing under-specification: >>> > >>> > Section 4.1. says: >>> > >>> > The Outer IP/UDP >>> > and VXLAN headers MUST be encoded by the sender as defined in >>> > [RFC7348]. >>> > >>> > >>> > And RFC 7348 says: >>> > >>> > - Source Port: It is recommended that the UDP source port >>> number >>> > be calculated using a hash of fields from the inner packet -= - >>> > one example being a hash of the inner Ethernet frame's >>> headers. >>> > This is to enable a level of entropy for the ECMP/load- >>> > balancing of the VM-to-VM traffic across the VXLAN overlay. >>> > When calculating the UDP source port number in this manner, = it >>> > is RECOMMENDED that the value be in the dynamic/private port >>> > range 49152-65535 [RFC6335]. >>> > >>> > >>> > Based on this, depending on the hashing calculation, the outer source >>> UDP port can be different leading to different ECMP treatment. Does >>> something else need to be specified here in regards to the outer UDP so= urce >>> port? >>> > >>> > >>> > 4. Section 7 says that =E2=80=9C Support for echo BFD is outside the = scope of >>> this document=E2=80=9D. >>> > >>> > Assuming this means =E2=80=9CBFD Echo mode=E2=80=9D, why is this out = of scope? If this >>> is a single logical hop underneath VXLAN, what=E2=80=99s preventing the= use of >>> Echo? Echo=E2=80=99s benefits are huge. >>> > >>> > >>> > 5. Terminology >>> > >>> > Implementations SHOULD ensure that the BFD >>> > packets follow the same lookup path as VXLAN data packets within t= he >>> > sender system. >>> > >>> > What is a =E2=80=9Clook up path within a sender system=E2=80=9D? >>> > >>> > >>> > 6. Deployment scenarios >>> > >>> > S3 says: >>> > Figure 1 illustrates the scenario with two servers, each of them >>> > hosting two VMs. The servers host VTEPs that terminate two VXLAN >>> > [=E2=80=A6] >>> > Figure 1: Reference VXLAN Domain >>> > >>> > >>> > However, RFC 7348 Figure 3 lists that as one deployment scenario, not >>> as =E2=80=9Cthe scenario=E2=80=9D and =E2=80=9CThe Reference VXLAN Doma= in=E2=80=9D. >>> > >>> > Best, >>> > >>> > Carlos. >>> > >>> >> On Jun 17, 2019, at 12:58 AM, Greg Mirsky >>> wrote: >>> >> >>> >> Hi Oliver, >>> >> thank you for your thorough review, clear and detailed questions. My >>> apologies for the delay to respond. Please find my answers below in-lin= e >>> tagged GIM>>. >>> >> >>> >> Regards, >>> >> Greg >>> >> >>> >> On Fri, May 31, 2019 at 12:38 PM Olivier Bonaventure via Datatracker= < >>> noreply@ietf.org> wrote: >>> >> Reviewer: Olivier Bonaventure >>> >> Review result: Ready with Issues >>> >> >>> >> This document has been reviewed as part of the transport area review >>> team's >>> >> ongoing effort to review key IETF documents. These comments were >>> written >>> >> primarily for the transport area directors, but are copied to the >>> document's >>> >> authors and WG to allow them to address any issues raised and also t= o >>> the IETF >>> >> discussion list for information. >>> >> >>> >> When done at the time of IETF Last Call, the authors should consider >>> this >>> >> review as part of the last-call comments they receive. Please always >>> CC >>> >> tsv-art@ietf.org if you reply to or forward this review. >>> >> >>> >> I have only limited knowledge of VXLAN and do not know all subtletie= s >>> of BFD. >>> >> This review is thus more from a generalist than a specialist in this >>> topic. >>> >> >>> >> Major issues >>> >> >>> >> Section 4 requires that " Implementations SHOULD ensure that the BFD >>> >> packets follow the same lookup path as VXLAN data packets within >>> the >>> >> sender system." >>> >> >>> >> Why is this requirement only relevant for the lookup path on the >>> sender system >>> >> ? What does this sentence really implies ? >>> >> GIM>> RFC 5880 set the scope of the fault detection of BFD protocol >>> as >>> >> ... the bidirectional path between two forwarding engines, >>> including >>> >> interfaces, data link(s), and to the extent possible the forwardi= ng >>> >> engines themselves ... >>> >> The requirement aimed to the forwarding engine of a BFD system that >>> transmits BFD control packets over VXLAN tunnel. >>> >> >>> >> Is it a requirement that the BFD packets follow the same path as the >>> data >>> >> packet for a given VXLAN ? I guess so. In this case, the document >>> should >>> >> discuss how Equal Cost Multipath could affect this. >>> >> GIM>> I think that ECMP environment is more likely to be experienced >>> by a transit node in the underlay. If the BFD session is used to monito= r >>> the specific underlay path, then, I agree, we should explain that using= the >>> VXLAN payload information to draw path entropy may cause data and BFD >>> packets following different underlay routes. But, on the other hand, th= at >>> is the case for OAM and fault detection in all overlay networks in gene= ral. >>> >> >>> >> Minor issues >>> >> >>> >> Section 1 >>> >> >>> >> You write "The asynchronous mode of BFD, as defined in [RFC5880], >>> >> can be used to monitor a p2p VXLAN tunnel." >>> >> >>> >> Why do you use the word can ? It is a possibility or a requirement ? >>> >> GIM>> In principle, BFD Demand mode may be used to monitor p2p paths >>> as well, I agree, will re-word to more assertive: >>> >> The asynchronous mode of BFD, as defined in [RFC5880], >>> >> is used to monitor a p2p VXLAN tunnel. >>> >> >>> >> NVE has not been defined before and is not in the terminology. >>> >> GIM>> Will add to the Terminology and expand as: >>> >> NVE Network Virtualization Endpoint >>> >> >>> >> This entire section is not easy to read for an outsider. >>> >> >>> >> Section 3 >>> >> >>> >> VNI has not been defined >>> >> GIM>> Will add to the Terminology section: >>> >> VNI VXLAN Network Identifier (or VXLAN Segment ID) >>> >> >>> >> Figure 1 could take less space >>> >> GIM>> Yes, can make it bit denser. Would the following be an >>> improvement? >>> >> >>> >> +------------+-------------+ >>> >> | Server 1 | >>> >> | +----+----+ +----+----+ | >>> >> | |VM1-1 | |VM1-2 | | >>> >> | |VNI 100 | |VNI 200 | | >>> >> | | | | | | >>> >> | +---------+ +---------+ | >>> >> | Hypervisor VTEP (IP1) | >>> >> +--------------------------+ >>> >> | >>> >> | +-------------+ >>> >> | | Layer 3 | >>> >> +---| Network | >>> >> +-------------+ >>> >> | >>> >> +-----------+ >>> >> | >>> >> +------------+-------------= + >>> >> | Hypervisor VTEP (IP2) = | >>> >> | +----+----+ +----+----+ = | >>> >> | |VM2-1 | |VM2-2 | = | >>> >> | |VNI 100 | |VNI 200 | = | >>> >> | | | | | = | >>> >> | +---------+ +---------+ = | >>> >> | Server 2 = | >>> >> +--------------------------= + >>> >> >>> >> >>> >> Section 4 >>> >> >>> >> I do not see the benefits of having one paragraph in Section 4 >>> followed by only >>> >> Section 4.1 >>> >> GIM>> Will merge Section 4.1 into 4 with minor required re-wording: >>> >> 4. BFD Packet Transmission over VXLAN Tunnel >>> >> >>> >> BFD packet MUST be encapsulated and sent to a remote VTEP as >>> >> explained in this section. Implementations SHOULD ensure that th= e >>> >> BFD packets follow the same lookup path as VXLAN data packets >>> within >>> >> the sender system. >>> >> >>> >> BFD packets are encapsulated in VXLAN as described below. The >>> VXLAN >>> >> packet format is defined in Section 5 of [RFC7348]. The Outer >>> IP/UDP >>> >> and VXLAN headers MUST be encoded by the sender as defined in >>> >> [RFC7348]. >>> >> >>> >> Section 4.1 >>> >> >>> >> The document does not specify when a dedicated MAC address or the MA= C >>> address >>> >> of the destination VTEP must be used. This could affect the >>> interoperability of >>> >> implementations. Should all implementations support both the >>> dedicated MAC >>> >> address and the destination MAC address ? >>> >> GIM>> After further discussion, authors decided to remove the reques= t >>> for the dedicated MAC address allocation. Only the MAC address of the >>> remote VTEP must be used as the destination MAC address in the inner >>> Ethernet frame. Please check the attached diff between the -07 and the >>> working versions or the working version of the draft. >>> >> >>> >> It is unclear from this section whether IPv4 inside IPv6 and the >>> opposite >>> >> should be supported or not. >>> >> GIM>> Any combination of outer IPvX and inner IPvX is possible. >>> >> >>> >> Section 5. >>> >> >>> >> If the received packet does not match the dedicated MAC address nor >>> the MAC >>> >> address of the VTEP, should the packet be silently discarded or >>> treated >>> >> differently ? >>> >> GIM>> As I've mentioned earlier, authors have decided to remove the >>> use of the dedicated MAC address for BFD over VXLAN. >>> >> >>> >> Section 5.1 >>> >> >>> >> Is this a modification to section 6.3 of RFC5880 ? This is not clear >>> >> GIM>> I think that this section is not modification but the >>> definition of the application-specific procedure that is outside the sc= ope >>> of RFC 5880: >>> >> The method of demultiplexing the initial packets (in which Your >>> >> Discriminator is zero) is application dependent, and is thus >>> outside >>> >> the scope of this specification. >>> >> >>> >> Section 9 >>> >> >>> >> The sentence " Throttling MAY be relaxed for BFD packets >>> >> based on port number." is unclear. >>> >> GIM>> Yes, thank you for pointing to this. The updated text, in the >>> whole paragraph, is as follows: >>> >> NEW TEXT: >>> >> The document requires setting the inner IP TTL to 1, which could = be >>> >> used as a DDoS attack vector. Thus the implementation MUST have >>> >> throttling in place to control the rate of BFD control packets se= nt >>> >> to the control plane. On the other hand, over aggressive >>> throttling >>> >> of BFD control packets may become the cause of the inability to >>> form >>> >> and maintain BFD session at scale. Hence, throttling of BFD >>> control >>> >> packets SHOULD be adjusted to permit BFD to work according to its >>> >> procedures. >>> >> >> draft-ietf-bfd-vxlan-08.txt.html> >>> > >>> >>> >> > --000000000000c6602e058bbaa424 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carlos,
thank you for clarifying your opinion on th= e applicability of the BFD Echo mode. I've split this thread to help us= and others to follow the discussion on this particular issue. I'll not= e that RFC 5880 does not prohibit the remote system to perform any kind of = processing on the packet received in the BFD Echo mode. Even more, Section = 6.8.8 explicitly points out that a received Echo packet is likely to be pro= cessed:
=C2=A0 =C2=A0A means of detecting missing Echo packets=C2=A0 =C2=A0MUST be implemented, which most likely involves processing of= the
=C2=A0 =C2=A0Echo packets that are received.=C2=A0 The processing o= f received Echo
=C2=A0 =C2=A0packets is otherwise outside the scope of t= his specification.
Thus, interoperability is one of the under= specified issues for BFD Echo. Secondly, the Echo BFD mode has been exclude= d from the scope of RFC 5884:
Further, the use of the Echo function is outsi= de the scope of this specification.
Would you suggest tha= t the scope of RFC 5884 must include the BFD Echo function?

<= div>Regards,
Greg

On Thu, Jun 20, 2019 at 2:08 PM Carlos Pig= nataro (cpignata) <cpignata@cisco.= com> wrote:
Hello, Greg,

Yes, happy too answer your question.

First, however, let me make two quick observations on the exchange:
  1. You seem to be picking very specific fragments or sub-topics from my co= mments, and following up on those only.
  2. I=E2=80=99m happy to contin= ue answering these questions, but they are orthogonal to (and consequently = a distraction from) the initial comments I raised.

Now, your question: the BFD Echo packet format is generically spec=E2= =80=99ed and defined in Section 5 of RFC 5880:

The most relevant part is this:

=C2=A0 =C2=A0The payload of a BFD Echo packet is a local matter, since= only the
=C2=A0 =C2=A0sending system ever processes the content.=C2=A0 The only= requirement is
=C2=A0 =C2=A0that sufficient information is included to demultiplex th= e received
=C2=A0 =C2=A0packet to the correct BFD session after it is looped back= to the
=C2=A0 =C2=A0sender.=C2=A0

Since the remote system does not process the echo packet content, it is a l= ocal matter only. And given the fact that, as such, there is no interoperab= ility implications, there is no need to over-specify the packet format. The= only requirement is that the sending system needs to be able to map it to a session when it boomerangs back.

No, it is generally not (i.e., does not need to be, but there=E2=80=99= s freedom to potentially be) a BFD control packet.=C2=A0
Yes, it can be something else.

That said, the packet format for BFD Echo has, to my analysis and unde= rstanding, no relevancy on the questions below.

Best,

Carlos.

On Jun 20, 2019, at 12:50 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Hello Carlos,
could you please refer me to the specification of BFD that= defines the message format that is used in the Echo mode of BFD. Is it the= BFD control packet? Something else?

Regards,
Greg


On Thu, Jun 20, 2019 at 11:09 AM Carl= os Pignataro (cpignata) <cpignata@cisco.com> wrote:
Hello, Greg,

Please see inline.

On Jun 19, 2019, at 9:58 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
Hello Carlos,
thank you for the expedient clarification.
To your=C2=A0questions on demultiplexing BFD control packets with the = zero value of the Your Discriminator field:
  • only BFD control packets with the zero value of the Your Discriminator = field are demultiplexed using the information of the inner IP header. I bel= ieve that the text is clear and requires that all fields of the inner IP he= ader must be used to demultiplex a received BFD control packet with the zero value in the Your Discriminato= r field. Which of the fields an implementation uses to create multiple BFD = sessions between the pair of VTEPs is implementation specific.
This text is repeating was is in the draft, but does not answer any of= my questions.

For example:
1. "that all fields of the inner IP header must be used to demult= iplex a received BFD control packet=E2=80=9D
=C2=A0 =C2=A0 -> The text does not say =E2=80=9Call fields=E2=80=9D= , but regardless, do you mean the DSCP and the Evil Bit? IPv6 Flow Label? H= ow *exactly*?
2. How is the mapping of IP (not UDP?) fields to BFD session done?
3. How is this state created and maintained?=C2=A0
4. Since this is a set of fields on which two systems need to agree (w= hich fields from the inner IP/UDP are mapped needs to be understood by both= systems), it cannot be =E2=80=9Cimplementation specific=E2=80=9D. Further,= the text does not say so.

To your point on the level Echo mode of BFD is specified in RFC 5880 I= 'll quote the opinion of Jeffrey Haas from the discussion of comments f= rom Shawn Emery on behalf of the SecDir. Shawn had commented:
Echo BFD is= out of scope for the document, but does not describe the reason for this o= r why state
this at all= ?
I've responded:
GIM>> I think that the main reason is that the BFD Echo mode is = underspecified. RFC 5880 defined some of the mechanisms related to the Echo= mode, but more standardization work may be required.=C2=A0=C2=A0
And Jeffrey Haas had added:
Speaking as a BFD chair, this is the relevant observation.=C2=A0 BFD E= cho is
underspecified to the point where claiming compliance is difficult at = best.
In general, it relies on single-hop and the ability to have the remote= Echo
client loop the packets.=C2=A0

BFD Echo cannot be specified in RFC 5880 base spec because it is appli= cation specific.


This packet loop may not be practical for several encapsulations and t= hus is
out of scope for such encapsulations.=C2=A0 Whether this is practical = for vxlan
today, or in the presence of future extensions to vxlan is left out of= scope
for the core proposal.=C2=A0=C2=A0

The question remains: for VXLAN encapsulation, this is like a single h= op as far as BFD is concerned (single hop VXLAN tunnel).

Since RFC 5881 defines Echo for single hop, can you please elaborate (= in the document) why is out of scope or how it can work?

Best,

Carlos.


Will respond to other questions in a separate mail.

Regards,
Greg


On Thu, Jun 20, 2019 at 10:31 AM Carl= os Pignataro (cpignata) <cpignata@cisco.com> wrote:
Hello, Greg,

> On Jun 19, 2019, at 9:09 PM, Greg Mirsky <gregimirsky@gmail.com> wrote:
>
> Hi Carlos,
> thank you for reminding of our continued discussion with Joel. We are = seeking comments from VXLAN experts and much appreciate if you have insight= s on VXLAN to share.
> I've got some clarifying questions before I can respond to you.
Sure.

> To which stage of the three-way handshake you refer as "initial d= emultiplexing"? I couldn't find this term in RFC 5880.

=E2=80=9CInitial demultiplexing" is a well-known term in BFD, referrin= g to the "demultiplexing of the initial packets", BFD Control pac= ket with YourDisc being zero.

In RFC 5880, see Section 6.3.
https://tools.ietf.org/html/rfc5880#section-6.3
=C2=A0 =C2=A0The method of demultiplexing the initial packets (in which You= r
=C2=A0 =C2=A0Discriminator is zero) is application dependent, and is thus o= utside
=C2=A0 =C2=A0the scope of this specification.

Since initial demultiplexing is indeed application specific, different for = one-hop versus multi-hop and dependent upon whether a single or multiple se= ssions are allowed between a pair of endpoints, I added below two other rel= evant citations, from application specific BFD specs:
1. https://tools.ietf.org/html/rfc5883#section-4
2. https://tools.ietf.org/html/rfc5882#section-6


> Regarding the applicability of the Echo mode, thank you for pointing t= o the need for stricter terminology, the Echo mode, as defined in RFC 5880,= is underspecified and it will require additional standardization.

No. BFD Echo is not underspecified in RFC 5880.

Please read S5: https://tools.ietf.org/html/rfc5880#section-5

=C2=A0 =C2=A0BFD Echo packets are sent in an encapsulation appropriate to t= he
=C2=A0 =C2=A0environment.=C2=A0 See the appropriate application documents f= or the
=C2=A0 =C2=A0specifics of particular environments.


BFD Echo is application dependent.

Therefore, for example, single-hop BFD in RFC 5881 specifies BFD Echo for t= hat application.

Hence, my question stands: why is this draft claiming BFD Echo is out of sc= ope for this BFD application document?


> Future drafts may explore and define how the Echo mode of BFD is used = over VXLAN tunnels.
>

See above.

> Will review and respond to the remaining questions soon.

Thank you.

The "remaining questions" are still all the questions below :-)
Best,

Carlos.

>
> Regards,
> Greg
>
>
> On Thu, Jun 20, 2019 at 9:14 AM Carlos Pignataro (cpignata) <cpignata@cisco.com>= ; wrote:
> Hi,
>
> I have not reviewed this draft before, but triggered by this email, an= d briefly scanning through a couple of sections, it is unclear to me how so= me of the mechanics work.
>
> There are some major issues with the Mac usage and association, as Joe= l Halpern mentioned in his Rtg Dir review.
>
> And, additionally, please consider the following comments and question= s:
>
>
> 1. Underspecification for initialization and initial demultiplexing. >
> This document allows multiple BFD sessions between a single pair of VT= EPs:
>
>=C2=A0 =C2=A0 An
>=C2=A0 =C2=A0 implementation that supports this specification MUST be a= ble to
>=C2=A0 =C2=A0 control the number of BFD sessions that can be created be= tween the
>=C2=A0 =C2=A0 same pair of VTEPs.
>
> The implication of this is that BFD single-hop initialization procedur= es will not work. Instead, there is a need to map the initial demultiplexin= g.
>
> This issue is explained in RFCs 5882 and 5883: https://tools.ietf.org/html/rfc5883#section-4 and https://tools.ietf.org/html/rfc5882#section-6
>
> Section 5.1 says:
>
>=C2=A0 =C2=A0 For such packets, the BFD session MUST be identified
>=C2=A0 =C2=A0 using the inner headers, i.e., the source IP, the destina= tion IP, and
>=C2=A0 =C2=A0 the source UDP port number present in the IP header carri= ed by the
>=C2=A0 =C2=A0 payload of the VXLAN encapsulated packet.=C2=A0 The VNI o= f the packet
>=C2=A0 =C2=A0 SHOULD be used to derive interface-related information fo= r
>=C2=A0 =C2=A0 demultiplexing the packet.
>
> But this does not really explain how to do the initial demultiplexing.= Does each BFD session need to have a separate inner source IP address? Or = source UDP port? And how ofter are they recycled or kept as state? How are = these mapped?
> Equally importantly, which side is Active?
> And what if there=E2=80=99s a race condition with both sides being Act= ive and setting up redundant sessions?
>
> 1.b. By the way, based on this, using S-BFD [RFC 7880] might be easier= to demux.
>
>
> 2. Security
>
> This document says that the TTL in the inner packet carrying BFD is se= t to 1. However, RFC 5880 says to use GTSM [RFC 5082], i.e., a value of 255= ..
>
> Why is GTSM not used here?
>
>
> 3. ECMP and fate-sharing under-specification:
>
> Section 4.1. says:
>
>=C2=A0 =C2=A0 The Outer IP/UDP
>=C2=A0 =C2=A0 and VXLAN headers MUST be encoded by the sender as define= d in
>=C2=A0 =C2=A0 [RFC7348].
>
>
> And RFC 7348 says:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0 Source Port:=C2=A0 It is recommended= that the UDP source port number
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be calculated using a hash of fields= from the inner packet --
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 one example being a hash of the inne= r Ethernet frame's headers.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This is to enable a level of entropy= for the ECMP/load-
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 balancing of the VM-to-VM traffic ac= ross the VXLAN overlay.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 When calculating the UDP source port= number in this manner, it
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is RECOMMENDED that the value be in = the dynamic/private port
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 range 49152-65535 [RFC6335].
>
>
> Based on this, depending on the hashing calculation, the outer source = UDP port can be different leading to different ECMP treatment. Does somethi= ng else need to be specified here in regards to the outer UDP source port?<= br> >
>
> 4. Section 7 says that =E2=80=9C Support for echo BFD is outside the s= cope of this document=E2=80=9D.
>
> Assuming this means =E2=80=9CBFD Echo mode=E2=80=9D, why is this out o= f scope? If this is a single logical hop underneath VXLAN, what=E2=80=99s p= reventing the use of Echo? Echo=E2=80=99s benefits are huge.
>
>
> 5. Terminology
>
>=C2=A0 =C2=A0 Implementations SHOULD ensure that the BFD
>=C2=A0 =C2=A0 packets follow the same lookup path as VXLAN data packets= within the
>=C2=A0 =C2=A0 sender system.
>
> What is a =E2=80=9Clook up path within a sender system=E2=80=9D?
>
>
> 6. Deployment scenarios
>
> S3 says:
>=C2=A0 =C2=A0 Figure 1 illustrates the scenario with two servers, each = of them
>=C2=A0 =C2=A0 hosting two VMs.=C2=A0 The servers host VTEPs that termin= ate two VXLAN
> [=E2=80=A6]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Figure 1: Reference VXLAN Domain
>
>
> However, RFC 7348 Figure 3 lists that as one deployment scenario, not = as =E2=80=9Cthe scenario=E2=80=9D and =E2=80=9CThe Reference VXLAN Domain= =E2=80=9D.
>
> Best,
>
> Carlos.
>
>> On Jun 17, 2019, at 12:58 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:=
>>
>> Hi Oliver,
>> thank you for your thorough review, clear and detailed questions. = My apologies for the delay to respond. Please find my answers below in-line= tagged GIM>>.
>>
>> Regards,
>> Greg
>>
>> On Fri, May 31, 2019 at 12:38 PM Olivier Bonaventure via Datatrack= er <noreply@ietf.o= rg> wrote:
>> Reviewer: Olivier Bonaventure
>> Review result: Ready with Issues
>>
>> This document has been reviewed as part of the transport area revi= ew team's
>> ongoing effort to review key IETF documents. These comments were w= ritten
>> primarily for the transport area directors, but are copied to the = document's
>> authors and WG to allow them to address any issues raised and also= to the IETF
>> discussion list for information.
>>
>> When done at the time of IETF Last Call, the authors should consid= er this
>> review as part of the last-call comments they receive. Please alwa= ys CC
>> tsv-art@ietf= .org if you reply to or forward this review.
>>
>> I have only limited knowledge of VXLAN and do not know all subtlet= ies of BFD.
>> This review is thus more from a generalist than a specialist in th= is topic.
>>
>> Major issues
>>
>> Section 4 requires that " Implementations SHOULD ensure that = the BFD
>>=C2=A0 =C2=A0 packets follow the same lookup path as VXLAN data pac= kets within the
>>=C2=A0 =C2=A0 sender system."
>>
>> Why is this requirement only relevant for the lookup path on the s= ender system
>> ? What does this sentence really implies ?
>> GIM>> RFC 5880 set the scope of the fault detection of BFD p= rotocol as
>>=C2=A0 =C2=A0 ... the bidirectional path between two forwarding eng= ines, including
>>=C2=A0 =C2=A0 interfaces, data link(s), and to the extent possible = the forwarding
>>=C2=A0 =C2=A0 engines themselves ...
>> The requirement aimed to the forwarding engine of a BFD system tha= t transmits BFD control packets over VXLAN tunnel.
>>
>> Is it a requirement that the BFD packets follow the same path as t= he data
>> packet for a given VXLAN ? I guess so. In this case, the document = should
>> discuss how Equal Cost Multipath could affect this.
>> GIM>> I think that ECMP environment is more likely to be exp= erienced by a transit node in the underlay. If the BFD session is used to m= onitor the specific underlay path, then, I agree, we should explain that us= ing the VXLAN payload information to draw path entropy may cause data and BFD packets following different underlay routes= . But, on the other hand, that is the case for OAM and fault detection in a= ll overlay networks in general.
>>
>> Minor issues
>>
>> Section 1
>>
>> You write "The asynchronous mode of BFD, as defined in [RFC58= 80],
>>=C2=A0 can be used to monitor a p2p VXLAN tunnel."
>>
>> Why do you use the word can ? It is a possibility or a requirement= ?
>> GIM>> In principle, BFD Demand mode may be used to monitor p= 2p paths as well, I agree, will re-word to more assertive:
>>=C2=A0 The asynchronous mode of BFD, as defined in [RFC5880],
>>=C2=A0 is used to monitor a p2p VXLAN tunnel.
>>
>> NVE has not been defined before and is not in the terminology.
>> GIM>> Will add to the Terminology and expand as:
>> NVE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Network Virtualization Endpoint >>
>> This entire section is not easy to read for an outsider.
>>
>> Section 3
>>
>> VNI has not been defined
>> GIM>> Will add to the Terminology section:
>> VNI=C2=A0 =C2=A0 VXLAN Network Identifier (or VXLAN Segment ID) >>
>> Figure 1 could take less space
>> GIM>> Yes, can make it bit denser. Would the following be an= improvement?
>>=C2=A0
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0+------------+-------------+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 Server 1=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0| +----+----+=C2=A0 +----+----+ |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0| |VM1-1=C2=A0 =C2=A0 |=C2=A0 |VM1-2=C2= =A0 =C2=A0 | |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0| |VNI 100=C2=A0 |=C2=A0 |VNI 200=C2=A0 = | |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0| |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0| +---------+=C2=A0 +---------+ |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0| Hypervisor VTEP (IP1)=C2=A0 =C2=A0 | >>=C2=A0 =C2=A0 =C2=A0 =C2=A0+--------------------------+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0+-------------+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0|=C2=A0 =C2=A0Layer 3= =C2=A0 =C2=A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---|=C2=A0 =C2=A0Network=C2=A0 =C2= =A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+-------------+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------= ---+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 +------------+-------------+
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 Hypervisor VTEP (IP2) |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | +----+----+=C2=A0 +----+----+ |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | |VM2-1=C2=A0 =C2=A0 |=C2=A0 |VM2-2=C2=A0 =C2=A0 | |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | |VNI 100=C2=A0 |=C2=A0 |VNI 200=C2=A0 | |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | +---------+=C2=A0 +---------+ |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |=C2=A0 =C2=A0 =C2=A0 Server 2=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 +--------------------------+
>>
>>
>> Section 4
>>
>> I do not see the benefits of having one paragraph in Section 4 fol= lowed by only
>> Section 4.1
>> GIM>> Will merge Section 4.1 into 4 with minor required re-w= ording:
>> 4.=C2=A0 BFD Packet Transmission over VXLAN Tunnel
>>
>>=C2=A0 =C2=A0 BFD packet MUST be encapsulated and sent to a remote = VTEP as
>>=C2=A0 =C2=A0 explained in this section.=C2=A0 Implementations SHOU= LD ensure that the
>>=C2=A0 =C2=A0 BFD packets follow the same lookup path as VXLAN data= packets within
>>=C2=A0 =C2=A0 the sender system.
>>
>>=C2=A0 =C2=A0 BFD packets are encapsulated in VXLAN as described be= low.=C2=A0 The VXLAN
>>=C2=A0 =C2=A0 packet format is defined in Section 5 of [RFC7348].= =C2=A0 The Outer IP/UDP
>>=C2=A0 =C2=A0 and VXLAN headers MUST be encoded by the sender as de= fined in
>>=C2=A0 =C2=A0 [RFC7348].
>>
>> Section 4.1
>>
>> The document does not specify when a dedicated MAC address or the = MAC address
>> of the destination VTEP must be used. This could affect the intero= perability of
>> implementations. Should all implementations support both the dedic= ated MAC
>> address and the destination MAC address ?
>> GIM>> After further discussion, authors decided to remove th= e request for the dedicated MAC address allocation. Only the MAC address of= the remote VTEP must be used as the destination MAC address in the inner E= thernet frame. Please check the attached diff between the -07 and the working versions or the working version of the dra= ft.
>>
>> It is unclear from this section whether IPv4 inside IPv6 and the o= pposite
>> should be supported or not.
>> GIM>> Any combination of outer IPvX and inner IPvX is possib= le.
>>
>> Section 5.
>>
>> If the received packet does not match the dedicated MAC address no= r the MAC
>> address of the VTEP, should the packet be silently discarded or tr= eated
>> differently ?
>> GIM>> As I've mentioned earlier, authors have decided to= remove the use of the dedicated MAC address for BFD over VXLAN.
>>
>> Section 5.1
>>
>> Is this a modification to section 6.3 of RFC5880 ? This is not cle= ar
>> GIM>> I think that this section is not modification but the = definition of the application-specific procedure that is outside the scope = of RFC 5880:
>>=C2=A0 =C2=A0 The method of demultiplexing the initial packets (in = which Your
>>=C2=A0 =C2=A0 Discriminator is zero) is application dependent, and = is thus outside
>>=C2=A0 =C2=A0 the scope of this specification.
>>
>> Section 9
>>
>> The sentence " Throttling MAY be relaxed for BFD packets
>>=C2=A0 =C2=A0 based on port number." is unclear.
>> GIM>> Yes, thank you for pointing to this. The updated text,= in the whole paragraph, is as follows:
>> NEW TEXT:
>>=C2=A0 =C2=A0 The document requires setting the inner IP TTL to 1, = which could be
>>=C2=A0 =C2=A0 used as a DDoS attack vector.=C2=A0 Thus the implemen= tation MUST have
>>=C2=A0 =C2=A0 throttling in place to control the rate of BFD contro= l packets sent
>>=C2=A0 =C2=A0 to the control plane.=C2=A0 On the other hand, over a= ggressive throttling
>>=C2=A0 =C2=A0 of BFD control packets may become the cause of the in= ability to form
>>=C2=A0 =C2=A0 and maintain BFD session at scale.=C2=A0 Hence, throt= tling of BFD control
>>=C2=A0 =C2=A0 packets SHOULD be adjusted to permit BFD to work acco= rding to its
>>=C2=A0 =C2=A0 procedures.
>> <draft-ietf-bfd-vxlan-08.txt><Diff_ draft-ietf-bfd-vxlan-= 07.txt - draft-ietf-bfd-vxlan-08.txt.html>
>



--000000000000c6602e058bbaa424-- From nobody Fri Jun 21 06:35:25 2019 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B80E120265; Fri, 21 Jun 2019 06:35:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-mirsky-bfd-mpls-demand-05.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtg-bfd@ietf.org Message-ID: <156112412353.17679.1978206912846342221@ietfa.amsl.com> Date: Fri, 21 Jun 2019 06:35:23 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2019 13:35:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection WG of the IETF. Title : BFD in Demand Mode over Point-to-Point MPLS LSP Author : Greg Mirsky Filename : draft-mirsky-bfd-mpls-demand-05.txt Pages : 5 Date : 2019-06-21 Abstract: This document describes procedures for using Bidirectional Forwarding Detection (BFD) in Demand mode to detect data plane failures in Multiprotocol Label Switching (MPLS) point-to-point Label Switched Paths. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-mirsky-bfd-mpls-demand-05 https://datatracker.ietf.org/doc/html/draft-mirsky-bfd-mpls-demand-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-mirsky-bfd-mpls-demand-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 21 17:19:41 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A83EE120241; Fri, 21 Jun 2019 17:19:31 -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, 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=YoitXcDj; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=tW6Wlbx5 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 Te6x1QmIhrfn; Fri, 21 Jun 2019 17:19:27 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F513120136; Fri, 21 Jun 2019 17:19:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34222; q=dns/txt; s=iport; t=1561162767; x=1562372367; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=rK6MvevEZ45eFmSg27hi3Y553PRqnMfdsIgcVsi/F3Y=; b=YoitXcDjgduTNx6HkadsNqs1eIL30459uwAdeblkwXdpe2x+meYR74ex Z9Xre9KIVmAFYEcylH3v8d+JUTzMEe9HRhZyNMzQpEaNWcOKrUaojy10s b3vkwvmlwlRV+KnPREx4gATRujViDZq4Yg/ZSa1mjijVM71IjxpUb7nLF Y=; IronPort-PHdr: =?us-ascii?q?9a23=3AZiOrohCeRhTELvhlTM5wUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuJ+brYCozAM1qX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CsAACycg1d/4ENJK1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZ4FEJAUnA2pVIAQLKAqEDINHA45hgjYliUWNc4FCgRADVAk?= =?us-ascii?q?BAQEMAQEjCgIBAYRAAheCRSM4EwEDAQEEAQECAQVtijcMhUoBAQEBAgESCAk?= =?us-ascii?q?EDQwBASUECQUBBAsCAQgYAgIfBwICAh8RFRACBA4FIoMAAYFqAw4PAQIMm3I?= =?us-ascii?q?CgTiIX3F+M4J5AQEFhHsNC4IRAwaBDCiEcYQkgR6BKxeBQD+BEAEnDBOCTD6?= =?us-ascii?q?CGkcBAQIBgSoBAQsGAgEIFQgQFQwCglAygiaLWSQtAoFwLo1MjQMsPwkCghK?= =?us-ascii?q?GTYRhhEUEg2obgiiHDIQKhWeCVIFNlFKBbYpdVII0AgQCBAUCDgEBBYFnIWd?= =?us-ascii?q?xcBU7KgGCQT6CAwsBFxRuAQiCQoUUhT4BcgGBKIwpgTEBgSABAQ?= X-IronPort-AV: E=Sophos;i="5.63,402,1557187200"; d="scan'208";a="295315047" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Jun 2019 00:19:25 +0000 Received: from XCH-RCD-020.cisco.com (xch-rcd-020.cisco.com [173.37.102.30]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x5M0JPBP010765 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 22 Jun 2019 00:19:25 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-020.cisco.com (173.37.102.30) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 21 Jun 2019 19:19:24 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 21 Jun 2019 19:19:24 -0500 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 21 Jun 2019 19:19:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rK6MvevEZ45eFmSg27hi3Y553PRqnMfdsIgcVsi/F3Y=; b=tW6Wlbx57n9tYUV+WvSG321kTwi+0AxbPt9xWdLMtB/aA0pQg4tXbtgMIWOZZqGWjkL8FzZK0Wc0JlEhw8iiOfx2JbMEMo8N4qpDPzi1KCapxy2cFSN8WXg0vnxrJt56FjbSyQjQ0R/KTpJuhrOUvJfSUKFr+l4vMujfqUlcsQk= Received: from BL0PR11MB3028.namprd11.prod.outlook.com (20.177.204.138) by BL0PR11MB3426.namprd11.prod.outlook.com (20.177.206.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.12; Sat, 22 Jun 2019 00:19:22 +0000 Received: from BL0PR11MB3028.namprd11.prod.outlook.com ([fe80::ec33:f4c1:227a:fcb3]) by BL0PR11MB3028.namprd11.prod.outlook.com ([fe80::ec33:f4c1:227a:fcb3%5]) with mapi id 15.20.2008.014; Sat, 22 Jun 2019 00:19:22 +0000 From: "Carlos Pignataro (cpignata)" To: Greg Mirsky CC: "tsv-art@ietf.org" , rtg-bfd WG , "draft-ietf-bfd-vxlan.all@ietf.org" , Olivier Bonaventure , IETF list Subject: Re: Level of standardization of the Echo mode of BFD [Re: Tsvart last call review of draft-ietf-bfd-vxlan-07] Thread-Topic: Level of standardization of the Echo mode of BFD [Re: Tsvart last call review of draft-ietf-bfd-vxlan-07] Thread-Index: AQHVJyO4ZUHeu4GAiUWD+HbCVzn3tKaj/jqAgAAF+ICAAs3NgA== Date: Sat, 22 Jun 2019 00:19:22 +0000 Message-ID: References: <155933149484.6565.7386019489022348116@ietfa.amsl.com> <14822B96-D3C6-495E-8661-198068F72ABA@cisco.com> <8237FE8D-937E-4BCB-B1A3-89C2B3CDC51C@cisco.com> <0B9FDA17-7F13-4FEC-AE97-40BC9D72C87B@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.11) authentication-results: spf=none (sender IP is ) smtp.mailfrom=cpignata@cisco.com; x-originating-ip: [173.38.117.82] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 52b12fe5-3077-4e8c-106c-08d6f6a7469d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BL0PR11MB3426; x-ms-traffictypediagnostic: BL0PR11MB3426: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0076F48C8A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(396003)(366004)(376002)(39860400002)(51444003)(199004)(189003)(2616005)(476003)(66476007)(86362001)(6916009)(26005)(11346002)(2906002)(316002)(68736007)(446003)(229853002)(7736002)(73956011)(25786009)(14444005)(33656002)(8676002)(66946007)(5660300002)(5024004)(966005)(561944003)(66556008)(66446008)(30864003)(305945005)(64756008)(256004)(76116006)(6436002)(1411001)(478600001)(66066001)(81156014)(57306001)(6116002)(6486002)(8936002)(99286004)(4326008)(50226002)(3846002)(6246003)(186003)(54906003)(53936002)(102836004)(71200400001)(71190400001)(76176011)(53546011)(6306002)(6512007)(53946003)(6506007)(486006)(14454004)(36756003)(81166006)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:BL0PR11MB3426; H:BL0PR11MB3028.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: 8QDyp+oSFOTLEuFdwUl+vfbVCEE6wntJf8FZ5NZAZG4zEMjlgGnBnsbWPA6FPswfeXa3EY8NAXwo7JomihY/XdR8xHiaJQjpj+Y4vqEPoFyBqa4O/fTdO5h6oKkyzTpD1RAICm5kotkoJdEeWTFDJFH/o9NZkGWOFEurD65v78eAw9pisB2q7eqOEL3mNbsCfAUKSgL3Rr31/GdlBtD1RkThB4Tx7jbJlGgpm/Gf6Fns17Vc/R3yCmPSaoiInktwYh7BB/pPdwyd2mtJi3PGdvjEJGgP5dWBWdTtwPl9N3aAKGh6unZy7BrRfEbYSET9Hk9Hxxn5a7z2kTRhWNhBlRhLckq9lEzZwD7jAo22hEylP5+CbfPreg27S+8p3NSEIkFrLwJk9VAu9ASe7k+jIKbpLUrMgw6FuFIM11voXwQ= Content-Type: text/plain; charset="utf-8" Content-ID: <15EC1455019FB8498428E437E000C40B@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 52b12fe5-3077-4e8c-106c-08d6f6a7469d X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2019 00:19:22.1505 (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-CrossTenant-userprincipalname: cpignata@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3426 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.30, xch-rcd-020.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2019 00:19:32 -0000 SGVsbG8sIEdyZWcsDQoNClRoYW5rIHlvdSBmb3IgaGF2aW5nIHNwbGl0IHRoaXMgdGhyZWFkLiBJ 4oCZbGwgbm90ZSBmb3IgZWFzZSBvZiB0cmFja2luZyB0aGF0IHRoaXMgc3BlY2lmaWMgaXNzdWUg aXMgaXNzdWUgIzQgb3VyIG9mIHRoZSBzaXggcXVpY2sgY29tbWVudHMgSSBzZW50Lg0KDQpOb3cs IHF1ZXN0aW9ucyB5b3UgYXNrIGxpa2UgdGhpcyBvbmUgcXVvdGVkIGZyb20gYmVsb3c6DQo+IFdv dWxkIHlvdSBzdWdnZXN0IHRoYXQgdGhlIHNjb3BlIG9mIFJGQyA1ODg0IG11c3QgaW5jbHVkZSB0 aGUgQkZEIEVjaG8gZnVuY3Rpb24/DQoNCg0KQXJlIG5vdyBzZWNvbmQtb3JkZXIgcmVkIGhlcnJp bmdzIGFuZCwgb25jZSBhZ2Fpbiwgbm90IHJlbGV2YW50IHRvIHRoZSBpc3N1ZSDigJQgaW5zdGVh ZCB0aGV5IGF2b2lkIHJlc3BvbmRpbmcgYW5kIHByZXZlbnQgY29udmVyZ2VuY2UuIEluIG15IGNv bW1lbnQsIEnigJltIGp1c3QgYXNraW5nIGZvciBhIHRlY2huaWNhbCBleHBsYW5hdGlvbiBvZiB3 aHkgQkZEIEVjaG8gaXMgb3V0IG9mIHNjb3BlLg0KDQoNClBsZWFzZSBzZWUgaW5saW5lLCB5b3Vy IHJlc3BvbnNlIGlzIGluY29ycmVjdCBpbiAzIHRlY2huaWNhbCBhcmVhcyB0aGF0IEkgZW51bWVy YXRlLg0KDQoNCj4gT24gSnVuIDIwLCAyMDE5LCBhdCAxOjMwIEFNLCBHcmVnIE1pcnNreSA8Z3Jl Z2ltaXJza3lAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IEhpIENhcmxvcywNCj4gdGhhbmsgeW91 IGZvciBjbGFyaWZ5aW5nIHlvdXIgb3BpbmlvbiBvbiB0aGUgYXBwbGljYWJpbGl0eSBvZiB0aGUg QkZEIEVjaG8gbW9kZS4NCg0KRm9yIGNvcnJlY3RuZXNzLCBJIGhhdmUgbm90IGlzc3VlZCBhbiAi b3BpbmlvbiBvbiB0aGUgYXBwbGljYWJpbGl0eSBvZiB0aGUgQkZEIEVjaG8gbW9kZS7igJ0gKEFn YWluLCBwbGVhc2UgZG8gbm90IG1pc2NoYXJhY3Rlcml6ZSEpIA0KDQpNeSBpbml0aWFsIHF1ZXN0 aW9uIHdhcyDigJx3aHkgaXMgdGhpcyBvdXQgb2Ygc2NvcGU/4oCdIEkgYmVsaWV2ZSBzY29waW5n IHNob3VsZCBiZSBkZWxpYmVyYXRlIGFuZCBpbnRlbnRpb25hbCwgYW5kIGhlbmNlIHNlZWtpbmcg dG8gdW5kZXJzdGFuZC4NCg0KDQo+IEkndmUgc3BsaXQgdGhpcyB0aHJlYWQgdG8gaGVscCB1cyBh bmQgb3RoZXJzIHRvIGZvbGxvdyB0aGUgZGlzY3Vzc2lvbiBvbiB0aGlzIHBhcnRpY3VsYXIgaXNz dWUuIEknbGwgbm90ZSB0aGF0IFJGQyA1ODgwIGRvZXMgbm90IHByb2hpYml0IHRoZSByZW1vdGUg c3lzdGVtIHRvIHBlcmZvcm0gYW55IGtpbmQgb2YgcHJvY2Vzc2luZyBvbiB0aGUgcGFja2V0IHJl Y2VpdmVkIGluIHRoZSBCRkQgRWNobyBtb2RlLg0KDQpUaGlzIGlzIHRlY2huaWNhbCBtaXN0YWtl ICMxLiANCg0KUkZDIDU4ODAgc2F5czoNCg0KICAgVGhlIEVjaG8gZnVuY3Rpb24gaGFzIHRoZSBh ZHZhbnRhZ2Ugb2YgdHJ1bHkgdGVzdGluZyBvbmx5IHRoZQ0KICAgZm9yd2FyZGluZyBwYXRoIG9u IHRoZSByZW1vdGUgc3lzdGVtLiANCg0KDQpObyBvdGhlciBwcm9jZXNzaW5nIG9uIHRoZSByZW1v dGUgc3lzdGVtIOKAlCB0aGF0IGlzIHRoZSBiZW5lZml0IG9mIEVjaG8uDQoNCg0KPiBFdmVuIG1v cmUsIFNlY3Rpb24gNi44LjggZXhwbGljaXRseSBwb2ludHMgb3V0IHRoYXQgYSByZWNlaXZlZCBF Y2hvIHBhY2tldCBpcyBsaWtlbHkgdG8gYmUgcHJvY2Vzc2VkOg0KPiAgICBBIG1lYW5zIG9mIGRl dGVjdGluZyBtaXNzaW5nIEVjaG8gcGFja2V0cw0KPiAgICBNVVNUIGJlIGltcGxlbWVudGVkLCB3 aGljaCBtb3N0IGxpa2VseSBpbnZvbHZlcyBwcm9jZXNzaW5nIG9mIHRoZQ0KPiAgICBFY2hvIHBh Y2tldHMgdGhhdCBhcmUgcmVjZWl2ZWQuICBUaGUgcHJvY2Vzc2luZyBvZiByZWNlaXZlZCBFY2hv DQo+ICAgIHBhY2tldHMgaXMgb3RoZXJ3aXNlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgc3Bl Y2lmaWNhdGlvbi4NCg0KDQpUaGlzIGlzIHRlY2huaWNhbCBtaXN0YWtlICMyLg0KDQpXaGF0IHlv dSBhcmUgcXVvdGluZyBpcyByZWZlcnJpbmcgdG8gdGhlIHJlY2VwdGlvbiBvZiBFY2hvIHBhY2tl dCBieSB0aGUgRWNobyBwYWNrZXQgKnNlbmRlciouIFRoYXQgaXMsIHRoZSBsb2NhbCBzeXN0ZW0s IG5vdCB0aGUgcmVtb3RlIHN5c3RlbS4gVGhlIEVjaG8gcGFja2V0IGlzIHJlY2VpdmVkIGJ5IHRo ZSBzYW1lIHN5c3RlbSB0aGF0IHNlbnQgaXQgKGJ5IGRlZmluaXRpb24gb2YgRWNobyEpLCBhbmQg dGh1cyB0aGUgbm9kZSBpdHNlbGYgbmVlZHMgdG8gZGVtdWx0aXBsZXggaXRzIG93biBjb250ZXh0 Li4uDQoNCg0KPiBUaHVzLCBpbnRlcm9wZXJhYmlsaXR5IGlzIG9uZSBvZiB0aGUgdW5kZXJzcGVj aWZpZWQgaXNzdWVzIGZvciBCRkQgRWNoby4NCg0KTm8uIFRoaXMgaXMgdGVjaG5pY2FsIG1pc3Rh a2UgIzJiLg0KDQpUaGVyZSBpcyBubyBpbnRlcm9wZXJhYmlsaXR5IHNwZWMgY29uc2lkZXJhdGlv bnMgYmV0d2VlbiBhIHN5c3RlbSBhbmQgaXRzZWxmICh1bmxlc3MgdGhlIHNlbmRlciBvZiBCRkQg RWNobyBoYXMgc3BsaXQgcGVyc29uYWxpdHkgOi0pDQoNCg0KDQo+IFNlY29uZGx5LCB0aGUgRWNo byBCRkQgbW9kZSBoYXMgYmVlbiBleGNsdWRlZCBmcm9tIHRoZSBzY29wZSBvZiBSRkMgNTg4NDoN Cj4gRnVydGhlciwgdGhlIHVzZSBvZiB0aGUgRWNobyBmdW5jdGlvbiBpcyBvdXRzaWRlIHRoZSBz Y29wZSBvZiB0aGlzIHNwZWNpZmljYXRpb24uDQoNClRoaXMgaXMgdGVjaG5pY2FsIG1pc3Rha2Ug IzMuDQoNCkl0IGlzIHJlYWxseSBpcnJlbGV2YW50IHRvIHRoZSBxdWVzdGlvbiB3aGV0aGVyIFJG QyA1ODg0LCB3aGljaCB0YWxrcyBhYm91dCBCRkQgZm9yIHVuaWRpcmVjdGlvbmFsIE1QTFMgTFNQ cywgc2NvcGVzIG91dCBCRkQgRWNoby4NCg0KQXMgSSBtZW50aW9uZWQgaW4gbXkgaW5pdGlhbCBl bWFpbCwgIklmIHRoaXMgaXMgYSBzaW5nbGUgbG9naWNhbCBob3AgdW5kZXJuZWF0aCBWWExBTiwg d2hhdOKAmXMgcHJldmVudGluZyB0aGUgdXNlIG9mIEVjaG8/4oCdIFJGQyA1ODg0IGlzIGRpZmZl cmVudCB0aGFuIChhbmQgbm90IHVzZWZ1bCBmb3Igb3IgcmVsZXZhbnQgdG8pIHRoZSBzY2VuYXJp byBpbiBkcmFmdC1pZXRmLWJmZC12eGxhbi4NCg0KDQoNCj4gV291bGQgeW91IHN1Z2dlc3QgdGhh dCB0aGUgc2NvcGUgb2YgUkZDIDU4ODQgbXVzdCBpbmNsdWRlIHRoZSBCRkQgRWNobyBmdW5jdGlv bj8NCg0KDQpJIGRvIG5vdCB1bmRlcnN0YW5kIHRoZSBjb250ZXh0IG9mIHRoaXMgcXVlc3Rpb24u IEJ1dCBhcyBJIG1lbnRpb25lZCwgdGhlc2UgcXVlc3Rpb25zIHRha2UgdGhlIHRocmVhZCBpbiBh IGRpcmVjdGlvbiB0aGF0IGRpdmVyZ2VzIGZyb20gcmVzb2x1dGlvbi4NCg0KSSBoYXZlIG5vdCBz dWdnZXN0ZWQgdGhhdCBhbnkgZG9jdW1lbnQgaW5jbHVkZXMgYW55dGhpbmcuIE15IGNvbW1lbnQg aXM6IHdoYXQgaXMgdGhlIHJlYXNvbiB3aHkgQkZEIEVjaG8gaXMgb3V0IG9mIHNjb3BlPyBUZWNo bmljYWxseSwgdGhpcyBpcyBhIHNpbmdsZSBob3AgYXQgdGhlIFZYTEFOIGxldmVsIGZvciBCRkQu DQoNCg0KQmVzdCwNCg0KQ2FybG9zLg0KDQo+IA0KPiBSZWdhcmRzLA0KPiBHcmVnDQo+IA0KPiBP biBUaHUsIEp1biAyMCwgMjAxOSBhdCAyOjA4IFBNIENhcmxvcyBQaWduYXRhcm8gKGNwaWduYXRh KSA8Y3BpZ25hdGFAY2lzY28uY29tPiB3cm90ZToNCj4gSGVsbG8sIEdyZWcsDQo+IA0KPiBZZXMs IGhhcHB5IHRvbyBhbnN3ZXIgeW91ciBxdWVzdGlvbi4NCj4gDQo+IEZpcnN0LCBob3dldmVyLCBs ZXQgbWUgbWFrZSB0d28gcXVpY2sgb2JzZXJ2YXRpb25zIG9uIHRoZSBleGNoYW5nZToNCj4gCeKA oiBZb3Ugc2VlbSB0byBiZSBwaWNraW5nIHZlcnkgc3BlY2lmaWMgZnJhZ21lbnRzIG9yIHN1Yi10 b3BpY3MgZnJvbSBteSBjb21tZW50cywgYW5kIGZvbGxvd2luZyB1cCBvbiB0aG9zZSBvbmx5Lg0K PiAJ4oCiIEnigJltIGhhcHB5IHRvIGNvbnRpbnVlIGFuc3dlcmluZyB0aGVzZSBxdWVzdGlvbnMs IGJ1dCB0aGV5IGFyZSBvcnRob2dvbmFsIHRvIChhbmQgY29uc2VxdWVudGx5IGEgZGlzdHJhY3Rp b24gZnJvbSkgdGhlIGluaXRpYWwgY29tbWVudHMgSSByYWlzZWQuDQo+IA0KPiBOb3csIHlvdXIg cXVlc3Rpb246IHRoZSBCRkQgRWNobyBwYWNrZXQgZm9ybWF0IGlzIGdlbmVyaWNhbGx5IHNwZWPi gJllZCBhbmQgZGVmaW5lZCBpbiBTZWN0aW9uIDUgb2YgUkZDIDU4ODA6DQo+IGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9yZmM1ODgwI3NlY3Rpb24tNQ0KPiANCj4gVGhlIG1vc3QgcmVsZXZh bnQgcGFydCBpcyB0aGlzOg0KPiANCj4gICAgVGhlIHBheWxvYWQgb2YgYSBCRkQgRWNobyBwYWNr ZXQgaXMgYSBsb2NhbCBtYXR0ZXIsIHNpbmNlIG9ubHkgdGhlDQo+ICAgIHNlbmRpbmcgc3lzdGVt IGV2ZXIgcHJvY2Vzc2VzIHRoZSBjb250ZW50LiAgVGhlIG9ubHkgcmVxdWlyZW1lbnQgaXMNCj4g ICAgdGhhdCBzdWZmaWNpZW50IGluZm9ybWF0aW9uIGlzIGluY2x1ZGVkIHRvIGRlbXVsdGlwbGV4 IHRoZSByZWNlaXZlZA0KPiAgICBwYWNrZXQgdG8gdGhlIGNvcnJlY3QgQkZEIHNlc3Npb24gYWZ0 ZXIgaXQgaXMgbG9vcGVkIGJhY2sgdG8gdGhlDQo+ICAgIHNlbmRlci4gDQo+IA0KPiBTaW5jZSB0 aGUgcmVtb3RlIHN5c3RlbSBkb2VzIG5vdCBwcm9jZXNzIHRoZSBlY2hvIHBhY2tldCBjb250ZW50 LCBpdCBpcyBhIGxvY2FsIG1hdHRlciBvbmx5LiBBbmQgZ2l2ZW4gdGhlIGZhY3QgdGhhdCwgYXMg c3VjaCwgdGhlcmUgaXMgbm8gaW50ZXJvcGVyYWJpbGl0eSBpbXBsaWNhdGlvbnMsIHRoZXJlIGlz IG5vIG5lZWQgdG8gb3Zlci1zcGVjaWZ5IHRoZSBwYWNrZXQgZm9ybWF0LiBUaGUgb25seSByZXF1 aXJlbWVudCBpcyB0aGF0IHRoZSBzZW5kaW5nIHN5c3RlbSBuZWVkcyB0byBiZSBhYmxlIHRvIG1h cCBpdCB0byBhIHNlc3Npb24gd2hlbiBpdCBib29tZXJhbmdzIGJhY2suDQo+IA0KPiBObywgaXQg aXMgZ2VuZXJhbGx5IG5vdCAoaS5lLiwgZG9lcyBub3QgbmVlZCB0byBiZSwgYnV0IHRoZXJl4oCZ cyBmcmVlZG9tIHRvIHBvdGVudGlhbGx5IGJlKSBhIEJGRCBjb250cm9sIHBhY2tldC4gDQo+IFll cywgaXQgY2FuIGJlIHNvbWV0aGluZyBlbHNlLg0KPiANCj4gVGhhdCBzYWlkLCB0aGUgcGFja2V0 IGZvcm1hdCBmb3IgQkZEIEVjaG8gaGFzLCB0byBteSBhbmFseXNpcyBhbmQgdW5kZXJzdGFuZGlu Zywgbm8gcmVsZXZhbmN5IG9uIHRoZSBxdWVzdGlvbnMgYmVsb3cuDQo+IA0KPiBCZXN0LA0KPiAN Cj4gQ2FybG9zLg0KPiANCj4+IE9uIEp1biAyMCwgMjAxOSwgYXQgMTI6NTAgQU0sIEdyZWcgTWly c2t5IDxncmVnaW1pcnNreUBnbWFpbC5jb20+IHdyb3RlOg0KPj4gDQo+PiBIZWxsbyBDYXJsb3Ms DQo+PiBjb3VsZCB5b3UgcGxlYXNlIHJlZmVyIG1lIHRvIHRoZSBzcGVjaWZpY2F0aW9uIG9mIEJG RCB0aGF0IGRlZmluZXMgdGhlIG1lc3NhZ2UgZm9ybWF0IHRoYXQgaXMgdXNlZCBpbiB0aGUgRWNo byBtb2RlIG9mIEJGRC4gSXMgaXQgdGhlIEJGRCBjb250cm9sIHBhY2tldD8gU29tZXRoaW5nIGVs c2U/DQo+PiANCj4+IFJlZ2FyZHMsDQo+PiBHcmVnDQo+PiANCj4+IA0KPj4gT24gVGh1LCBKdW4g MjAsIDIwMTkgYXQgMTE6MDkgQU0gQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIDxjcGlnbmF0 YUBjaXNjby5jb20+IHdyb3RlOg0KPj4gSGVsbG8sIEdyZWcsDQo+PiANCj4+IFBsZWFzZSBzZWUg aW5saW5lLg0KPj4gDQo+Pj4gT24gSnVuIDE5LCAyMDE5LCBhdCA5OjU4IFBNLCBHcmVnIE1pcnNr eSA8Z3JlZ2ltaXJza3lAZ21haWwuY29tPiB3cm90ZToNCj4+PiANCj4+PiBIZWxsbyBDYXJsb3Ms DQo+Pj4gdGhhbmsgeW91IGZvciB0aGUgZXhwZWRpZW50IGNsYXJpZmljYXRpb24uDQo+Pj4gVG8g eW91ciBxdWVzdGlvbnMgb24gZGVtdWx0aXBsZXhpbmcgQkZEIGNvbnRyb2wgcGFja2V0cyB3aXRo IHRoZSB6ZXJvIHZhbHVlIG9mIHRoZSBZb3VyIERpc2NyaW1pbmF0b3IgZmllbGQ6DQo+Pj4gCeKA oiBvbmx5IEJGRCBjb250cm9sIHBhY2tldHMgd2l0aCB0aGUgemVybyB2YWx1ZSBvZiB0aGUgWW91 ciBEaXNjcmltaW5hdG9yIGZpZWxkIGFyZSBkZW11bHRpcGxleGVkIHVzaW5nIHRoZSBpbmZvcm1h dGlvbiBvZiB0aGUgaW5uZXIgSVAgaGVhZGVyLiBJIGJlbGlldmUgdGhhdCB0aGUgdGV4dCBpcyBj bGVhciBhbmQgcmVxdWlyZXMgdGhhdCBhbGwgZmllbGRzIG9mIHRoZSBpbm5lciBJUCBoZWFkZXIg bXVzdCBiZSB1c2VkIHRvIGRlbXVsdGlwbGV4IGEgcmVjZWl2ZWQgQkZEIGNvbnRyb2wgcGFja2V0 IHdpdGggdGhlIHplcm8gdmFsdWUgaW4gdGhlIFlvdXIgRGlzY3JpbWluYXRvciBmaWVsZC4gV2hp Y2ggb2YgdGhlIGZpZWxkcyBhbiBpbXBsZW1lbnRhdGlvbiB1c2VzIHRvIGNyZWF0ZSBtdWx0aXBs ZSBCRkQgc2Vzc2lvbnMgYmV0d2VlbiB0aGUgcGFpciBvZiBWVEVQcyBpcyBpbXBsZW1lbnRhdGlv biBzcGVjaWZpYy4NCj4+IFRoaXMgdGV4dCBpcyByZXBlYXRpbmcgd2FzIGlzIGluIHRoZSBkcmFm dCwgYnV0IGRvZXMgbm90IGFuc3dlciBhbnkgb2YgbXkgcXVlc3Rpb25zLg0KPj4gDQo+PiBGb3Ig ZXhhbXBsZToNCj4+IDEuICJ0aGF0IGFsbCBmaWVsZHMgb2YgdGhlIGlubmVyIElQIGhlYWRlciBt dXN0IGJlIHVzZWQgdG8gZGVtdWx0aXBsZXggYSByZWNlaXZlZCBCRkQgY29udHJvbCBwYWNrZXTi gJ0NCj4+ICAgICAtPiBUaGUgdGV4dCBkb2VzIG5vdCBzYXkg4oCcYWxsIGZpZWxkc+KAnSwgYnV0 IHJlZ2FyZGxlc3MsIGRvIHlvdSBtZWFuIHRoZSBEU0NQIGFuZCB0aGUgRXZpbCBCaXQ/IElQdjYg RmxvdyBMYWJlbD8gSG93ICpleGFjdGx5Kj8NCj4+IDIuIEhvdyBpcyB0aGUgbWFwcGluZyBvZiBJ UCAobm90IFVEUD8pIGZpZWxkcyB0byBCRkQgc2Vzc2lvbiBkb25lPw0KPj4gMy4gSG93IGlzIHRo aXMgc3RhdGUgY3JlYXRlZCBhbmQgbWFpbnRhaW5lZD8gDQo+PiA0LiBTaW5jZSB0aGlzIGlzIGEg c2V0IG9mIGZpZWxkcyBvbiB3aGljaCB0d28gc3lzdGVtcyBuZWVkIHRvIGFncmVlICh3aGljaCBm aWVsZHMgZnJvbSB0aGUgaW5uZXIgSVAvVURQIGFyZSBtYXBwZWQgbmVlZHMgdG8gYmUgdW5kZXJz dG9vZCBieSBib3RoIHN5c3RlbXMpLCBpdCBjYW5ub3QgYmUg4oCcaW1wbGVtZW50YXRpb24gc3Bl Y2lmaWPigJ0uIEZ1cnRoZXIsIHRoZSB0ZXh0IGRvZXMgbm90IHNheSBzby4NCj4+IA0KPj4+IFRv IHlvdXIgcG9pbnQgb24gdGhlIGxldmVsIEVjaG8gbW9kZSBvZiBCRkQgaXMgc3BlY2lmaWVkIGlu IFJGQyA1ODgwIEknbGwgcXVvdGUgdGhlIG9waW5pb24gb2YgSmVmZnJleSBIYWFzIGZyb20gdGhl IGRpc2N1c3Npb24gb2YgY29tbWVudHMgZnJvbSBTaGF3biBFbWVyeSBvbiBiZWhhbGYgb2YgdGhl IFNlY0Rpci4gU2hhd24gaGFkIGNvbW1lbnRlZDoNCj4+PiBFY2hvIEJGRCBpcyBvdXQgb2Ygc2Nv cGUgZm9yIHRoZSBkb2N1bWVudCwgYnV0IGRvZXMgbm90IGRlc2NyaWJlIHRoZSByZWFzb24gZm9y IHRoaXMgb3Igd2h5IHN0YXRlDQo+Pj4gdGhpcyBhdCBhbGw/DQo+Pj4gSSd2ZSByZXNwb25kZWQ6 DQo+Pj4gR0lNPj4gSSB0aGluayB0aGF0IHRoZSBtYWluIHJlYXNvbiBpcyB0aGF0IHRoZSBCRkQg RWNobyBtb2RlIGlzIHVuZGVyc3BlY2lmaWVkLiBSRkMgNTg4MCBkZWZpbmVkIHNvbWUgb2YgdGhl IG1lY2hhbmlzbXMgcmVsYXRlZCB0byB0aGUgRWNobyBtb2RlLCBidXQgbW9yZSBzdGFuZGFyZGl6 YXRpb24gd29yayBtYXkgYmUgcmVxdWlyZWQuICANCj4+PiBBbmQgSmVmZnJleSBIYWFzIGhhZCBh ZGRlZDoNCj4+PiBTcGVha2luZyBhcyBhIEJGRCBjaGFpciwgdGhpcyBpcyB0aGUgcmVsZXZhbnQg b2JzZXJ2YXRpb24uICBCRkQgRWNobyBpcw0KPj4+IHVuZGVyc3BlY2lmaWVkIHRvIHRoZSBwb2lu dCB3aGVyZSBjbGFpbWluZyBjb21wbGlhbmNlIGlzIGRpZmZpY3VsdCBhdCBiZXN0Lg0KPj4+IElu IGdlbmVyYWwsIGl0IHJlbGllcyBvbiBzaW5nbGUtaG9wIGFuZCB0aGUgYWJpbGl0eSB0byBoYXZl IHRoZSByZW1vdGUgRWNobw0KPj4+IGNsaWVudCBsb29wIHRoZSBwYWNrZXRzLiANCj4+IA0KPj4g QkZEIEVjaG8gY2Fubm90IGJlIHNwZWNpZmllZCBpbiBSRkMgNTg4MCBiYXNlIHNwZWMgYmVjYXVz ZSBpdCBpcyBhcHBsaWNhdGlvbiBzcGVjaWZpYy4NCj4+IA0KPj4+IA0KPj4+IFRoaXMgcGFja2V0 IGxvb3AgbWF5IG5vdCBiZSBwcmFjdGljYWwgZm9yIHNldmVyYWwgZW5jYXBzdWxhdGlvbnMgYW5k IHRodXMgaXMNCj4+PiBvdXQgb2Ygc2NvcGUgZm9yIHN1Y2ggZW5jYXBzdWxhdGlvbnMuICBXaGV0 aGVyIHRoaXMgaXMgcHJhY3RpY2FsIGZvciB2eGxhbg0KPj4+IHRvZGF5LCBvciBpbiB0aGUgcHJl c2VuY2Ugb2YgZnV0dXJlIGV4dGVuc2lvbnMgdG8gdnhsYW4gaXMgbGVmdCBvdXQgb2Ygc2NvcGUN Cj4+PiBmb3IgdGhlIGNvcmUgcHJvcG9zYWwuICANCj4+IA0KPj4gVGhlIHF1ZXN0aW9uIHJlbWFp bnM6IGZvciBWWExBTiBlbmNhcHN1bGF0aW9uLCB0aGlzIGlzIGxpa2UgYSBzaW5nbGUgaG9wIGFz IGZhciBhcyBCRkQgaXMgY29uY2VybmVkIChzaW5nbGUgaG9wIFZYTEFOIHR1bm5lbCkuDQo+PiAN Cj4+IFNpbmNlIFJGQyA1ODgxIGRlZmluZXMgRWNobyBmb3Igc2luZ2xlIGhvcCwgY2FuIHlvdSBw bGVhc2UgZWxhYm9yYXRlIChpbiB0aGUgZG9jdW1lbnQpIHdoeSBpcyBvdXQgb2Ygc2NvcGUgb3Ig aG93IGl0IGNhbiB3b3JrPw0KPj4gDQo+PiBCZXN0LA0KPj4gDQo+PiBDYXJsb3MuDQo+PiANCj4+ PiANCj4+PiBXaWxsIHJlc3BvbmQgdG8gb3RoZXIgcXVlc3Rpb25zIGluIGEgc2VwYXJhdGUgbWFp bC4NCj4+PiANCj4+PiBSZWdhcmRzLA0KPj4+IEdyZWcNCj4+PiANCj4+PiANCj4+PiBPbiBUaHUs IEp1biAyMCwgMjAxOSBhdCAxMDozMSBBTSBDYXJsb3MgUGlnbmF0YXJvIChjcGlnbmF0YSkgPGNw aWduYXRhQGNpc2NvLmNvbT4gd3JvdGU6DQo+Pj4gSGVsbG8sIEdyZWcsDQo+Pj4gDQo+Pj4gPiBP biBKdW4gMTksIDIwMTksIGF0IDk6MDkgUE0sIEdyZWcgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFp bC5jb20+IHdyb3RlOg0KPj4+ID4gDQo+Pj4gPiBIaSBDYXJsb3MsDQo+Pj4gPiB0aGFuayB5b3Ug Zm9yIHJlbWluZGluZyBvZiBvdXIgY29udGludWVkIGRpc2N1c3Npb24gd2l0aCBKb2VsLiBXZSBh cmUgc2Vla2luZyBjb21tZW50cyBmcm9tIFZYTEFOIGV4cGVydHMgYW5kIG11Y2ggYXBwcmVjaWF0 ZSBpZiB5b3UgaGF2ZSBpbnNpZ2h0cyBvbiBWWExBTiB0byBzaGFyZS4NCj4+PiA+IEkndmUgZ290 IHNvbWUgY2xhcmlmeWluZyBxdWVzdGlvbnMgYmVmb3JlIEkgY2FuIHJlc3BvbmQgdG8geW91Lg0K Pj4+IA0KPj4+IFN1cmUuDQo+Pj4gDQo+Pj4gPiBUbyB3aGljaCBzdGFnZSBvZiB0aGUgdGhyZWUt d2F5IGhhbmRzaGFrZSB5b3UgcmVmZXIgYXMgImluaXRpYWwgZGVtdWx0aXBsZXhpbmciPyBJIGNv dWxkbid0IGZpbmQgdGhpcyB0ZXJtIGluIFJGQyA1ODgwLg0KPj4+IA0KPj4+IOKAnEluaXRpYWwg ZGVtdWx0aXBsZXhpbmciIGlzIGEgd2VsbC1rbm93biB0ZXJtIGluIEJGRCwgcmVmZXJyaW5nIHRv IHRoZSAiZGVtdWx0aXBsZXhpbmcgb2YgdGhlIGluaXRpYWwgcGFja2V0cyIsIEJGRCBDb250cm9s IHBhY2tldCB3aXRoIFlvdXJEaXNjIGJlaW5nIHplcm8uDQo+Pj4gDQo+Pj4gSW4gUkZDIDU4ODAs IHNlZSBTZWN0aW9uIDYuMy4NCj4+PiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTg4 MCNzZWN0aW9uLTYuMw0KPj4+IA0KPj4+ICAgIFRoZSBtZXRob2Qgb2YgZGVtdWx0aXBsZXhpbmcg dGhlIGluaXRpYWwgcGFja2V0cyAoaW4gd2hpY2ggWW91cg0KPj4+ICAgIERpc2NyaW1pbmF0b3Ig aXMgemVybykgaXMgYXBwbGljYXRpb24gZGVwZW5kZW50LCBhbmQgaXMgdGh1cyBvdXRzaWRlDQo+ Pj4gICAgdGhlIHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4NCj4+PiANCj4+PiBTaW5jZSBp bml0aWFsIGRlbXVsdGlwbGV4aW5nIGlzIGluZGVlZCBhcHBsaWNhdGlvbiBzcGVjaWZpYywgZGlm ZmVyZW50IGZvciBvbmUtaG9wIHZlcnN1cyBtdWx0aS1ob3AgYW5kIGRlcGVuZGVudCB1cG9uIHdo ZXRoZXIgYSBzaW5nbGUgb3IgbXVsdGlwbGUgc2Vzc2lvbnMgYXJlIGFsbG93ZWQgYmV0d2VlbiBh IHBhaXIgb2YgZW5kcG9pbnRzLCBJIGFkZGVkIGJlbG93IHR3byBvdGhlciByZWxldmFudCBjaXRh dGlvbnMsIGZyb20gYXBwbGljYXRpb24gc3BlY2lmaWMgQkZEIHNwZWNzOg0KPj4+IDEuIGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1ODgzI3NlY3Rpb24tNCANCj4+PiAyLiBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTg4MiNzZWN0aW9uLTYNCj4+PiANCj4+PiANCj4+PiA+ IFJlZ2FyZGluZyB0aGUgYXBwbGljYWJpbGl0eSBvZiB0aGUgRWNobyBtb2RlLCB0aGFuayB5b3Ug Zm9yIHBvaW50aW5nIHRvIHRoZSBuZWVkIGZvciBzdHJpY3RlciB0ZXJtaW5vbG9neSwgdGhlIEVj aG8gbW9kZSwgYXMgZGVmaW5lZCBpbiBSRkMgNTg4MCwgaXMgdW5kZXJzcGVjaWZpZWQgYW5kIGl0 IHdpbGwgcmVxdWlyZSBhZGRpdGlvbmFsIHN0YW5kYXJkaXphdGlvbi4NCj4+PiANCj4+PiBOby4g QkZEIEVjaG8gaXMgbm90IHVuZGVyc3BlY2lmaWVkIGluIFJGQyA1ODgwLg0KPj4+IA0KPj4+IFBs ZWFzZSByZWFkIFM1OiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNTg4MCNzZWN0aW9u LTUNCj4+PiANCj4+PiAgICBCRkQgRWNobyBwYWNrZXRzIGFyZSBzZW50IGluIGFuIGVuY2Fwc3Vs YXRpb24gYXBwcm9wcmlhdGUgdG8gdGhlDQo+Pj4gICAgZW52aXJvbm1lbnQuICBTZWUgdGhlIGFw cHJvcHJpYXRlIGFwcGxpY2F0aW9uIGRvY3VtZW50cyBmb3IgdGhlDQo+Pj4gICAgc3BlY2lmaWNz IG9mIHBhcnRpY3VsYXIgZW52aXJvbm1lbnRzLg0KPj4+IA0KPj4+IA0KPj4+IEJGRCBFY2hvIGlz IGFwcGxpY2F0aW9uIGRlcGVuZGVudC4gDQo+Pj4gDQo+Pj4gVGhlcmVmb3JlLCBmb3IgZXhhbXBs ZSwgc2luZ2xlLWhvcCBCRkQgaW4gUkZDIDU4ODEgc3BlY2lmaWVzIEJGRCBFY2hvIGZvciB0aGF0 IGFwcGxpY2F0aW9uLg0KPj4+IA0KPj4+IEhlbmNlLCBteSBxdWVzdGlvbiBzdGFuZHM6IHdoeSBp cyB0aGlzIGRyYWZ0IGNsYWltaW5nIEJGRCBFY2hvIGlzIG91dCBvZiBzY29wZSBmb3IgdGhpcyBC RkQgYXBwbGljYXRpb24gZG9jdW1lbnQ/DQo+Pj4gDQo+Pj4gDQo+Pj4gPiBGdXR1cmUgZHJhZnRz IG1heSBleHBsb3JlIGFuZCBkZWZpbmUgaG93IHRoZSBFY2hvIG1vZGUgb2YgQkZEIGlzIHVzZWQg b3ZlciBWWExBTiB0dW5uZWxzLg0KPj4+ID4gDQo+Pj4gDQo+Pj4gU2VlIGFib3ZlLg0KPj4+IA0K Pj4+ID4gV2lsbCByZXZpZXcgYW5kIHJlc3BvbmQgdG8gdGhlIHJlbWFpbmluZyBxdWVzdGlvbnMg c29vbi4NCj4+PiANCj4+PiBUaGFuayB5b3UuIA0KPj4+IA0KPj4+IFRoZSAicmVtYWluaW5nIHF1 ZXN0aW9ucyIgYXJlIHN0aWxsIGFsbCB0aGUgcXVlc3Rpb25zIGJlbG93IDotKQ0KPj4+IA0KPj4+ IEJlc3QsDQo+Pj4gDQo+Pj4gQ2FybG9zLg0KPj4+IA0KPj4+ID4gDQo+Pj4gPiBSZWdhcmRzLA0K Pj4+ID4gR3JlZw0KPj4+ID4gDQo+Pj4gPiANCj4+PiA+IE9uIFRodSwgSnVuIDIwLCAyMDE5IGF0 IDk6MTQgQU0gQ2FybG9zIFBpZ25hdGFybyAoY3BpZ25hdGEpIDxjcGlnbmF0YUBjaXNjby5jb20+ IHdyb3RlOg0KPj4+ID4gSGksDQo+Pj4gPiANCj4+PiA+IEkgaGF2ZSBub3QgcmV2aWV3ZWQgdGhp cyBkcmFmdCBiZWZvcmUsIGJ1dCB0cmlnZ2VyZWQgYnkgdGhpcyBlbWFpbCwgYW5kIGJyaWVmbHkg c2Nhbm5pbmcgdGhyb3VnaCBhIGNvdXBsZSBvZiBzZWN0aW9ucywgaXQgaXMgdW5jbGVhciB0byBt ZSBob3cgc29tZSBvZiB0aGUgbWVjaGFuaWNzIHdvcmsuDQo+Pj4gPiANCj4+PiA+IFRoZXJlIGFy ZSBzb21lIG1ham9yIGlzc3VlcyB3aXRoIHRoZSBNYWMgdXNhZ2UgYW5kIGFzc29jaWF0aW9uLCBh cyBKb2VsIEhhbHBlcm4gbWVudGlvbmVkIGluIGhpcyBSdGcgRGlyIHJldmlldy4NCj4+PiA+IA0K Pj4+ID4gQW5kLCBhZGRpdGlvbmFsbHksIHBsZWFzZSBjb25zaWRlciB0aGUgZm9sbG93aW5nIGNv bW1lbnRzIGFuZCBxdWVzdGlvbnM6DQo+Pj4gPiANCj4+PiA+IA0KPj4+ID4gMS4gVW5kZXJzcGVj aWZpY2F0aW9uIGZvciBpbml0aWFsaXphdGlvbiBhbmQgaW5pdGlhbCBkZW11bHRpcGxleGluZy4N Cj4+PiA+IA0KPj4+ID4gVGhpcyBkb2N1bWVudCBhbGxvd3MgbXVsdGlwbGUgQkZEIHNlc3Npb25z IGJldHdlZW4gYSBzaW5nbGUgcGFpciBvZiBWVEVQczoNCj4+PiA+IA0KPj4+ID4gICAgQW4NCj4+ PiA+ICAgIGltcGxlbWVudGF0aW9uIHRoYXQgc3VwcG9ydHMgdGhpcyBzcGVjaWZpY2F0aW9uIE1V U1QgYmUgYWJsZSB0bw0KPj4+ID4gICAgY29udHJvbCB0aGUgbnVtYmVyIG9mIEJGRCBzZXNzaW9u cyB0aGF0IGNhbiBiZSBjcmVhdGVkIGJldHdlZW4gdGhlDQo+Pj4gPiAgICBzYW1lIHBhaXIgb2Yg VlRFUHMuDQo+Pj4gPiANCj4+PiA+IFRoZSBpbXBsaWNhdGlvbiBvZiB0aGlzIGlzIHRoYXQgQkZE IHNpbmdsZS1ob3AgaW5pdGlhbGl6YXRpb24gcHJvY2VkdXJlcyB3aWxsIG5vdCB3b3JrLiBJbnN0 ZWFkLCB0aGVyZSBpcyBhIG5lZWQgdG8gbWFwIHRoZSBpbml0aWFsIGRlbXVsdGlwbGV4aW5nLg0K Pj4+ID4gDQo+Pj4gPiBUaGlzIGlzc3VlIGlzIGV4cGxhaW5lZCBpbiBSRkNzIDU4ODIgYW5kIDU4 ODM6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM1ODgzI3NlY3Rpb24tNCBhbmQgaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzU4ODIjc2VjdGlvbi02DQo+Pj4gPiANCj4+PiA+ IFNlY3Rpb24gNS4xIHNheXM6DQo+Pj4gPiANCj4+PiA+ICAgIEZvciBzdWNoIHBhY2tldHMsIHRo ZSBCRkQgc2Vzc2lvbiBNVVNUIGJlIGlkZW50aWZpZWQNCj4+PiA+ICAgIHVzaW5nIHRoZSBpbm5l ciBoZWFkZXJzLCBpLmUuLCB0aGUgc291cmNlIElQLCB0aGUgZGVzdGluYXRpb24gSVAsIGFuZA0K Pj4+ID4gICAgdGhlIHNvdXJjZSBVRFAgcG9ydCBudW1iZXIgcHJlc2VudCBpbiB0aGUgSVAgaGVh ZGVyIGNhcnJpZWQgYnkgdGhlDQo+Pj4gPiAgICBwYXlsb2FkIG9mIHRoZSBWWExBTiBlbmNhcHN1 bGF0ZWQgcGFja2V0LiAgVGhlIFZOSSBvZiB0aGUgcGFja2V0DQo+Pj4gPiAgICBTSE9VTEQgYmUg dXNlZCB0byBkZXJpdmUgaW50ZXJmYWNlLXJlbGF0ZWQgaW5mb3JtYXRpb24gZm9yDQo+Pj4gPiAg ICBkZW11bHRpcGxleGluZyB0aGUgcGFja2V0Lg0KPj4+ID4gDQo+Pj4gPiBCdXQgdGhpcyBkb2Vz IG5vdCByZWFsbHkgZXhwbGFpbiBob3cgdG8gZG8gdGhlIGluaXRpYWwgZGVtdWx0aXBsZXhpbmcu IERvZXMgZWFjaCBCRkQgc2Vzc2lvbiBuZWVkIHRvIGhhdmUgYSBzZXBhcmF0ZSBpbm5lciBzb3Vy Y2UgSVAgYWRkcmVzcz8gT3Igc291cmNlIFVEUCBwb3J0PyBBbmQgaG93IG9mdGVyIGFyZSB0aGV5 IHJlY3ljbGVkIG9yIGtlcHQgYXMgc3RhdGU/IEhvdyBhcmUgdGhlc2UgbWFwcGVkPw0KPj4+ID4g RXF1YWxseSBpbXBvcnRhbnRseSwgd2hpY2ggc2lkZSBpcyBBY3RpdmU/DQo+Pj4gPiBBbmQgd2hh dCBpZiB0aGVyZeKAmXMgYSByYWNlIGNvbmRpdGlvbiB3aXRoIGJvdGggc2lkZXMgYmVpbmcgQWN0 aXZlIGFuZCBzZXR0aW5nIHVwIHJlZHVuZGFudCBzZXNzaW9ucz8NCj4+PiA+IA0KPj4+ID4gMS5i LiBCeSB0aGUgd2F5LCBiYXNlZCBvbiB0aGlzLCB1c2luZyBTLUJGRCBbUkZDIDc4ODBdIG1pZ2h0 IGJlIGVhc2llciB0byBkZW11eC4NCj4+PiA+IA0KPj4+ID4gDQo+Pj4gPiAyLiBTZWN1cml0eQ0K Pj4+ID4gDQo+Pj4gPiBUaGlzIGRvY3VtZW50IHNheXMgdGhhdCB0aGUgVFRMIGluIHRoZSBpbm5l ciBwYWNrZXQgY2FycnlpbmcgQkZEIGlzIHNldCB0byAxLiBIb3dldmVyLCBSRkMgNTg4MCBzYXlz IHRvIHVzZSBHVFNNIFtSRkMgNTA4Ml0sIGkuZS4sIGEgdmFsdWUgb2YgMjU1Li4NCj4+PiA+IA0K Pj4+ID4gV2h5IGlzIEdUU00gbm90IHVzZWQgaGVyZT8NCj4+PiA+IA0KPj4+ID4gDQo+Pj4gPiAz LiBFQ01QIGFuZCBmYXRlLXNoYXJpbmcgdW5kZXItc3BlY2lmaWNhdGlvbjoNCj4+PiA+IA0KPj4+ ID4gU2VjdGlvbiA0LjEuIHNheXM6DQo+Pj4gPiANCj4+PiA+ICAgIFRoZSBPdXRlciBJUC9VRFAN Cj4+PiA+ICAgIGFuZCBWWExBTiBoZWFkZXJzIE1VU1QgYmUgZW5jb2RlZCBieSB0aGUgc2VuZGVy IGFzIGRlZmluZWQgaW4NCj4+PiA+ICAgIFtSRkM3MzQ4XS4NCj4+PiA+IA0KPj4+ID4gDQo+Pj4g PiBBbmQgUkZDIDczNDggc2F5czoNCj4+PiA+IA0KPj4+ID4gICAgICAgLSAgU291cmNlIFBvcnQ6 ICBJdCBpcyByZWNvbW1lbmRlZCB0aGF0IHRoZSBVRFAgc291cmNlIHBvcnQgbnVtYmVyDQo+Pj4g PiAgICAgICAgICBiZSBjYWxjdWxhdGVkIHVzaW5nIGEgaGFzaCBvZiBmaWVsZHMgZnJvbSB0aGUg aW5uZXIgcGFja2V0IC0tDQo+Pj4gPiAgICAgICAgICBvbmUgZXhhbXBsZSBiZWluZyBhIGhhc2gg b2YgdGhlIGlubmVyIEV0aGVybmV0IGZyYW1lJ3MgaGVhZGVycy4NCj4+PiA+ICAgICAgICAgIFRo aXMgaXMgdG8gZW5hYmxlIGEgbGV2ZWwgb2YgZW50cm9weSBmb3IgdGhlIEVDTVAvbG9hZC0NCj4+ PiA+ICAgICAgICAgIGJhbGFuY2luZyBvZiB0aGUgVk0tdG8tVk0gdHJhZmZpYyBhY3Jvc3MgdGhl IFZYTEFOIG92ZXJsYXkuDQo+Pj4gPiAgICAgICAgICBXaGVuIGNhbGN1bGF0aW5nIHRoZSBVRFAg c291cmNlIHBvcnQgbnVtYmVyIGluIHRoaXMgbWFubmVyLCBpdA0KPj4+ID4gICAgICAgICAgaXMg UkVDT01NRU5ERUQgdGhhdCB0aGUgdmFsdWUgYmUgaW4gdGhlIGR5bmFtaWMvcHJpdmF0ZSBwb3J0 DQo+Pj4gPiAgICAgICAgICByYW5nZSA0OTE1Mi02NTUzNSBbUkZDNjMzNV0uDQo+Pj4gPiANCj4+ PiA+IA0KPj4+ID4gQmFzZWQgb24gdGhpcywgZGVwZW5kaW5nIG9uIHRoZSBoYXNoaW5nIGNhbGN1 bGF0aW9uLCB0aGUgb3V0ZXIgc291cmNlIFVEUCBwb3J0IGNhbiBiZSBkaWZmZXJlbnQgbGVhZGlu ZyB0byBkaWZmZXJlbnQgRUNNUCB0cmVhdG1lbnQuIERvZXMgc29tZXRoaW5nIGVsc2UgbmVlZCB0 byBiZSBzcGVjaWZpZWQgaGVyZSBpbiByZWdhcmRzIHRvIHRoZSBvdXRlciBVRFAgc291cmNlIHBv cnQ/DQo+Pj4gPiANCj4+PiA+IA0KPj4+ID4gNC4gU2VjdGlvbiA3IHNheXMgdGhhdCDigJwgU3Vw cG9ydCBmb3IgZWNobyBCRkQgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudOKA nS4gDQo+Pj4gPiANCj4+PiA+IEFzc3VtaW5nIHRoaXMgbWVhbnMg4oCcQkZEIEVjaG8gbW9kZeKA nSwgd2h5IGlzIHRoaXMgb3V0IG9mIHNjb3BlPyBJZiB0aGlzIGlzIGEgc2luZ2xlIGxvZ2ljYWwg aG9wIHVuZGVybmVhdGggVlhMQU4sIHdoYXTigJlzIHByZXZlbnRpbmcgdGhlIHVzZSBvZiBFY2hv PyBFY2hv4oCZcyBiZW5lZml0cyBhcmUgaHVnZS4NCj4+PiA+IA0KPj4+ID4gDQo+Pj4gPiA1LiBU ZXJtaW5vbG9neQ0KPj4+ID4gDQo+Pj4gPiAgICBJbXBsZW1lbnRhdGlvbnMgU0hPVUxEIGVuc3Vy ZSB0aGF0IHRoZSBCRkQNCj4+PiA+ICAgIHBhY2tldHMgZm9sbG93IHRoZSBzYW1lIGxvb2t1cCBw YXRoIGFzIFZYTEFOIGRhdGEgcGFja2V0cyB3aXRoaW4gdGhlDQo+Pj4gPiAgICBzZW5kZXIgc3lz dGVtLg0KPj4+ID4gDQo+Pj4gPiBXaGF0IGlzIGEg4oCcbG9vayB1cCBwYXRoIHdpdGhpbiBhIHNl bmRlciBzeXN0ZW3igJ0/DQo+Pj4gPiANCj4+PiA+IA0KPj4+ID4gNi4gRGVwbG95bWVudCBzY2Vu YXJpb3MNCj4+PiA+IA0KPj4+ID4gUzMgc2F5czoNCj4+PiA+ICAgIEZpZ3VyZSAxIGlsbHVzdHJh dGVzIHRoZSBzY2VuYXJpbyB3aXRoIHR3byBzZXJ2ZXJzLCBlYWNoIG9mIHRoZW0NCj4+PiA+ICAg IGhvc3RpbmcgdHdvIFZNcy4gIFRoZSBzZXJ2ZXJzIGhvc3QgVlRFUHMgdGhhdCB0ZXJtaW5hdGUg dHdvIFZYTEFODQo+Pj4gPiBb4oCmXQ0KPj4+ID4gICAgICAgICAgICAgICAgICAgICAgRmlndXJl IDE6IFJlZmVyZW5jZSBWWExBTiBEb21haW4NCj4+PiA+IA0KPj4+ID4gDQo+Pj4gPiBIb3dldmVy LCBSRkMgNzM0OCBGaWd1cmUgMyBsaXN0cyB0aGF0IGFzIG9uZSBkZXBsb3ltZW50IHNjZW5hcmlv LCBub3QgYXMg4oCcdGhlIHNjZW5hcmlv4oCdIGFuZCDigJxUaGUgUmVmZXJlbmNlIFZYTEFOIERv bWFpbuKAnS4NCj4+PiA+IA0KPj4+ID4gQmVzdCwNCj4+PiA+IA0KPj4+ID4gQ2FybG9zLg0KPj4+ ID4gDQo+Pj4gPj4gT24gSnVuIDE3LCAyMDE5LCBhdCAxMjo1OCBBTSwgR3JlZyBNaXJza3kgPGdy ZWdpbWlyc2t5QGdtYWlsLmNvbT4gd3JvdGU6DQo+Pj4gPj4gDQo+Pj4gPj4gSGkgT2xpdmVyLA0K Pj4+ID4+IHRoYW5rIHlvdSBmb3IgeW91ciB0aG9yb3VnaCByZXZpZXcsIGNsZWFyIGFuZCBkZXRh aWxlZCBxdWVzdGlvbnMuIE15IGFwb2xvZ2llcyBmb3IgdGhlIGRlbGF5IHRvIHJlc3BvbmQuIFBs ZWFzZSBmaW5kIG15IGFuc3dlcnMgYmVsb3cgaW4tbGluZSB0YWdnZWQgR0lNPj4uDQo+Pj4gPj4g DQo+Pj4gPj4gUmVnYXJkcywNCj4+PiA+PiBHcmVnDQo+Pj4gPj4gDQo+Pj4gPj4gT24gRnJpLCBN YXkgMzEsIDIwMTkgYXQgMTI6MzggUE0gT2xpdmllciBCb25hdmVudHVyZSB2aWEgRGF0YXRyYWNr ZXIgPG5vcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0KPj4+ID4+IFJldmlld2VyOiBPbGl2aWVyIEJv bmF2ZW50dXJlDQo+Pj4gPj4gUmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0aCBJc3N1ZXMNCj4+PiA+ PiANCj4+PiA+PiBUaGlzIGRvY3VtZW50IGhhcyBiZWVuIHJldmlld2VkIGFzIHBhcnQgb2YgdGhl IHRyYW5zcG9ydCBhcmVhIHJldmlldyB0ZWFtJ3MNCj4+PiA+PiBvbmdvaW5nIGVmZm9ydCB0byBy ZXZpZXcga2V5IElFVEYgZG9jdW1lbnRzLiBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4NCj4+ PiA+PiBwcmltYXJpbHkgZm9yIHRoZSB0cmFuc3BvcnQgYXJlYSBkaXJlY3RvcnMsIGJ1dCBhcmUg Y29waWVkIHRvIHRoZSBkb2N1bWVudCdzDQo+Pj4gPj4gYXV0aG9ycyBhbmQgV0cgdG8gYWxsb3cg dGhlbSB0byBhZGRyZXNzIGFueSBpc3N1ZXMgcmFpc2VkIGFuZCBhbHNvIHRvIHRoZSBJRVRGDQo+ Pj4gPj4gZGlzY3Vzc2lvbiBsaXN0IGZvciBpbmZvcm1hdGlvbi4NCj4+PiA+PiANCj4+PiA+PiBX aGVuIGRvbmUgYXQgdGhlIHRpbWUgb2YgSUVURiBMYXN0IENhbGwsIHRoZSBhdXRob3JzIHNob3Vs ZCBjb25zaWRlciB0aGlzDQo+Pj4gPj4gcmV2aWV3IGFzIHBhcnQgb2YgdGhlIGxhc3QtY2FsbCBj b21tZW50cyB0aGV5IHJlY2VpdmUuIFBsZWFzZSBhbHdheXMgQ0MNCj4+PiA+PiB0c3YtYXJ0QGll dGYub3JnIGlmIHlvdSByZXBseSB0byBvciBmb3J3YXJkIHRoaXMgcmV2aWV3Lg0KPj4+ID4+IA0K Pj4+ID4+IEkgaGF2ZSBvbmx5IGxpbWl0ZWQga25vd2xlZGdlIG9mIFZYTEFOIGFuZCBkbyBub3Qg a25vdyBhbGwgc3VidGxldGllcyBvZiBCRkQuDQo+Pj4gPj4gVGhpcyByZXZpZXcgaXMgdGh1cyBt b3JlIGZyb20gYSBnZW5lcmFsaXN0IHRoYW4gYSBzcGVjaWFsaXN0IGluIHRoaXMgdG9waWMuDQo+ Pj4gPj4gDQo+Pj4gPj4gTWFqb3IgaXNzdWVzDQo+Pj4gPj4gDQo+Pj4gPj4gU2VjdGlvbiA0IHJl cXVpcmVzIHRoYXQgIiBJbXBsZW1lbnRhdGlvbnMgU0hPVUxEIGVuc3VyZSB0aGF0IHRoZSBCRkQN Cj4+PiA+PiAgICBwYWNrZXRzIGZvbGxvdyB0aGUgc2FtZSBsb29rdXAgcGF0aCBhcyBWWExBTiBk YXRhIHBhY2tldHMgd2l0aGluIHRoZQ0KPj4+ID4+ICAgIHNlbmRlciBzeXN0ZW0uIg0KPj4+ID4+ IA0KPj4+ID4+IFdoeSBpcyB0aGlzIHJlcXVpcmVtZW50IG9ubHkgcmVsZXZhbnQgZm9yIHRoZSBs b29rdXAgcGF0aCBvbiB0aGUgc2VuZGVyIHN5c3RlbQ0KPj4+ID4+ID8gV2hhdCBkb2VzIHRoaXMg c2VudGVuY2UgcmVhbGx5IGltcGxpZXMgPw0KPj4+ID4+IEdJTT4+IFJGQyA1ODgwIHNldCB0aGUg c2NvcGUgb2YgdGhlIGZhdWx0IGRldGVjdGlvbiBvZiBCRkQgcHJvdG9jb2wgYXMgDQo+Pj4gPj4g ICAgLi4uIHRoZSBiaWRpcmVjdGlvbmFsIHBhdGggYmV0d2VlbiB0d28gZm9yd2FyZGluZyBlbmdp bmVzLCBpbmNsdWRpbmcNCj4+PiA+PiAgICBpbnRlcmZhY2VzLCBkYXRhIGxpbmsocyksIGFuZCB0 byB0aGUgZXh0ZW50IHBvc3NpYmxlIHRoZSBmb3J3YXJkaW5nDQo+Pj4gPj4gICAgZW5naW5lcyB0 aGVtc2VsdmVzIC4uLg0KPj4+ID4+IFRoZSByZXF1aXJlbWVudCBhaW1lZCB0byB0aGUgZm9yd2Fy ZGluZyBlbmdpbmUgb2YgYSBCRkQgc3lzdGVtIHRoYXQgdHJhbnNtaXRzIEJGRCBjb250cm9sIHBh Y2tldHMgb3ZlciBWWExBTiB0dW5uZWwuDQo+Pj4gPj4gDQo+Pj4gPj4gSXMgaXQgYSByZXF1aXJl bWVudCB0aGF0IHRoZSBCRkQgcGFja2V0cyBmb2xsb3cgdGhlIHNhbWUgcGF0aCBhcyB0aGUgZGF0 YQ0KPj4+ID4+IHBhY2tldCBmb3IgYSBnaXZlbiBWWExBTiA/IEkgZ3Vlc3Mgc28uIEluIHRoaXMg Y2FzZSwgdGhlIGRvY3VtZW50IHNob3VsZA0KPj4+ID4+IGRpc2N1c3MgaG93IEVxdWFsIENvc3Qg TXVsdGlwYXRoIGNvdWxkIGFmZmVjdCB0aGlzLg0KPj4+ID4+IEdJTT4+IEkgdGhpbmsgdGhhdCBF Q01QIGVudmlyb25tZW50IGlzIG1vcmUgbGlrZWx5IHRvIGJlIGV4cGVyaWVuY2VkIGJ5IGEgdHJh bnNpdCBub2RlIGluIHRoZSB1bmRlcmxheS4gSWYgdGhlIEJGRCBzZXNzaW9uIGlzIHVzZWQgdG8g bW9uaXRvciB0aGUgc3BlY2lmaWMgdW5kZXJsYXkgcGF0aCwgdGhlbiwgSSBhZ3JlZSwgd2Ugc2hv dWxkIGV4cGxhaW4gdGhhdCB1c2luZyB0aGUgVlhMQU4gcGF5bG9hZCBpbmZvcm1hdGlvbiB0byBk cmF3IHBhdGggZW50cm9weSBtYXkgY2F1c2UgZGF0YSBhbmQgQkZEIHBhY2tldHMgZm9sbG93aW5n IGRpZmZlcmVudCB1bmRlcmxheSByb3V0ZXMuIEJ1dCwgb24gdGhlIG90aGVyIGhhbmQsIHRoYXQg aXMgdGhlIGNhc2UgZm9yIE9BTSBhbmQgZmF1bHQgZGV0ZWN0aW9uIGluIGFsbCBvdmVybGF5IG5l dHdvcmtzIGluIGdlbmVyYWwuDQo+Pj4gPj4gDQo+Pj4gPj4gTWlub3IgaXNzdWVzDQo+Pj4gPj4g DQo+Pj4gPj4gU2VjdGlvbiAxDQo+Pj4gPj4gDQo+Pj4gPj4gWW91IHdyaXRlICJUaGUgYXN5bmNo cm9ub3VzIG1vZGUgb2YgQkZELCBhcyBkZWZpbmVkIGluIFtSRkM1ODgwXSwNCj4+PiA+PiAgY2Fu IGJlIHVzZWQgdG8gbW9uaXRvciBhIHAycCBWWExBTiB0dW5uZWwuIg0KPj4+ID4+IA0KPj4+ID4+ IFdoeSBkbyB5b3UgdXNlIHRoZSB3b3JkIGNhbiA/IEl0IGlzIGEgcG9zc2liaWxpdHkgb3IgYSBy ZXF1aXJlbWVudCA/DQo+Pj4gPj4gR0lNPj4gSW4gcHJpbmNpcGxlLCBCRkQgRGVtYW5kIG1vZGUg bWF5IGJlIHVzZWQgdG8gbW9uaXRvciBwMnAgcGF0aHMgYXMgd2VsbCwgSSBhZ3JlZSwgd2lsbCBy ZS13b3JkIHRvIG1vcmUgYXNzZXJ0aXZlOg0KPj4+ID4+ICBUaGUgYXN5bmNocm9ub3VzIG1vZGUg b2YgQkZELCBhcyBkZWZpbmVkIGluIFtSRkM1ODgwXSwNCj4+PiA+PiAgaXMgdXNlZCB0byBtb25p dG9yIGEgcDJwIFZYTEFOIHR1bm5lbC4NCj4+PiA+PiANCj4+PiA+PiBOVkUgaGFzIG5vdCBiZWVu IGRlZmluZWQgYmVmb3JlIGFuZCBpcyBub3QgaW4gdGhlIHRlcm1pbm9sb2d5Lg0KPj4+ID4+IEdJ TT4+IFdpbGwgYWRkIHRvIHRoZSBUZXJtaW5vbG9neSBhbmQgZXhwYW5kIGFzOg0KPj4+ID4+IE5W RSAgICAgICAgTmV0d29yayBWaXJ0dWFsaXphdGlvbiBFbmRwb2ludCANCj4+PiA+PiANCj4+PiA+ PiBUaGlzIGVudGlyZSBzZWN0aW9uIGlzIG5vdCBlYXN5IHRvIHJlYWQgZm9yIGFuIG91dHNpZGVy Lg0KPj4+ID4+IA0KPj4+ID4+IFNlY3Rpb24gMw0KPj4+ID4+IA0KPj4+ID4+IFZOSSBoYXMgbm90 IGJlZW4gZGVmaW5lZA0KPj4+ID4+IEdJTT4+IFdpbGwgYWRkIHRvIHRoZSBUZXJtaW5vbG9neSBz ZWN0aW9uOg0KPj4+ID4+IFZOSSAgICBWWExBTiBOZXR3b3JrIElkZW50aWZpZXIgKG9yIFZYTEFO IFNlZ21lbnQgSUQpDQo+Pj4gPj4gDQo+Pj4gPj4gRmlndXJlIDEgY291bGQgdGFrZSBsZXNzIHNw YWNlDQo+Pj4gPj4gR0lNPj4gWWVzLCBjYW4gbWFrZSBpdCBiaXQgZGVuc2VyLiBXb3VsZCB0aGUg Zm9sbG93aW5nIGJlIGFuIGltcHJvdmVtZW50Pw0KPj4+ID4+ICANCj4+PiA+PiAgICAgICArLS0t LS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0rDQo+Pj4gPj4gICAgICAgfCAgICAgICAgU2VydmVyIDEg ICAgICAgICAgfA0KPj4+ID4+ICAgICAgIHwgKy0tLS0rLS0tLSsgICstLS0tKy0tLS0rIHwNCj4+ PiA+PiAgICAgICB8IHxWTTEtMSAgICB8ICB8Vk0xLTIgICAgfCB8DQo+Pj4gPj4gICAgICAgfCB8 Vk5JIDEwMCAgfCAgfFZOSSAyMDAgIHwgfA0KPj4+ID4+ICAgICAgIHwgfCAgICAgICAgIHwgIHwg ICAgICAgICB8IHwNCj4+PiA+PiAgICAgICB8ICstLS0tLS0tLS0rICArLS0tLS0tLS0tKyB8DQo+ Pj4gPj4gICAgICAgfCBIeXBlcnZpc29yIFZURVAgKElQMSkgICAgfA0KPj4+ID4+ICAgICAgICst LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4+PiA+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgfA0KPj4+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgKy0tLS0tLS0t LS0tLS0rDQo+Pj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICB8ICAgTGF5ZXIg MyAgIHwNCj4+PiA+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLXwgICBOZXR3b3Jr ICAgfA0KPj4+ID4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0t LS0rDQo+Pj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPj4+ID4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLSsNCj4+PiA+ PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+Pj4g Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0t Ky0tLS0tLS0tLS0tLS0rDQo+Pj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8ICAgIEh5cGVydmlzb3IgVlRFUCAoSVAyKSB8DQo+Pj4gPj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICstLS0tKy0tLS0rICArLS0tLSstLS0tKyB8 DQo+Pj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHxWTTIt MSAgICB8ICB8Vk0yLTIgICAgfCB8DQo+Pj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8IHxWTkkgMTAwICB8ICB8Vk5JIDIwMCAgfCB8DQo+Pj4gPj4gICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHwgICAgICAgICB8ICB8ICAgICAg ICAgfCB8DQo+Pj4gPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8 ICstLS0tLS0tLS0rICArLS0tLS0tLS0tKyB8DQo+Pj4gPj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8ICAgICAgU2VydmVyIDIgICAgICAgICAgICB8DQo+Pj4gPj4g ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rDQo+Pj4gPj4gDQo+Pj4gPj4gDQo+Pj4gPj4gU2VjdGlvbiA0DQo+Pj4gPj4g DQo+Pj4gPj4gSSBkbyBub3Qgc2VlIHRoZSBiZW5lZml0cyBvZiBoYXZpbmcgb25lIHBhcmFncmFw aCBpbiBTZWN0aW9uIDQgZm9sbG93ZWQgYnkgb25seQ0KPj4+ID4+IFNlY3Rpb24gNC4xDQo+Pj4g Pj4gR0lNPj4gV2lsbCBtZXJnZSBTZWN0aW9uIDQuMSBpbnRvIDQgd2l0aCBtaW5vciByZXF1aXJl ZCByZS13b3JkaW5nOg0KPj4+ID4+IDQuICBCRkQgUGFja2V0IFRyYW5zbWlzc2lvbiBvdmVyIFZY TEFOIFR1bm5lbA0KPj4+ID4+IA0KPj4+ID4+ICAgIEJGRCBwYWNrZXQgTVVTVCBiZSBlbmNhcHN1 bGF0ZWQgYW5kIHNlbnQgdG8gYSByZW1vdGUgVlRFUCBhcw0KPj4+ID4+ICAgIGV4cGxhaW5lZCBp biB0aGlzIHNlY3Rpb24uICBJbXBsZW1lbnRhdGlvbnMgU0hPVUxEIGVuc3VyZSB0aGF0IHRoZQ0K Pj4+ID4+ICAgIEJGRCBwYWNrZXRzIGZvbGxvdyB0aGUgc2FtZSBsb29rdXAgcGF0aCBhcyBWWExB TiBkYXRhIHBhY2tldHMgd2l0aGluDQo+Pj4gPj4gICAgdGhlIHNlbmRlciBzeXN0ZW0uDQo+Pj4g Pj4gDQo+Pj4gPj4gICAgQkZEIHBhY2tldHMgYXJlIGVuY2Fwc3VsYXRlZCBpbiBWWExBTiBhcyBk ZXNjcmliZWQgYmVsb3cuICBUaGUgVlhMQU4NCj4+PiA+PiAgICBwYWNrZXQgZm9ybWF0IGlzIGRl ZmluZWQgaW4gU2VjdGlvbiA1IG9mIFtSRkM3MzQ4XS4gIFRoZSBPdXRlciBJUC9VRFANCj4+PiA+ PiAgICBhbmQgVlhMQU4gaGVhZGVycyBNVVNUIGJlIGVuY29kZWQgYnkgdGhlIHNlbmRlciBhcyBk ZWZpbmVkIGluDQo+Pj4gPj4gICAgW1JGQzczNDhdLg0KPj4+ID4+IA0KPj4+ID4+IFNlY3Rpb24g NC4xDQo+Pj4gPj4gDQo+Pj4gPj4gVGhlIGRvY3VtZW50IGRvZXMgbm90IHNwZWNpZnkgd2hlbiBh IGRlZGljYXRlZCBNQUMgYWRkcmVzcyBvciB0aGUgTUFDIGFkZHJlc3MNCj4+PiA+PiBvZiB0aGUg ZGVzdGluYXRpb24gVlRFUCBtdXN0IGJlIHVzZWQuIFRoaXMgY291bGQgYWZmZWN0IHRoZSBpbnRl cm9wZXJhYmlsaXR5IG9mDQo+Pj4gPj4gaW1wbGVtZW50YXRpb25zLiBTaG91bGQgYWxsIGltcGxl bWVudGF0aW9ucyBzdXBwb3J0IGJvdGggdGhlIGRlZGljYXRlZCBNQUMNCj4+PiA+PiBhZGRyZXNz IGFuZCB0aGUgZGVzdGluYXRpb24gTUFDIGFkZHJlc3MgPw0KPj4+ID4+IEdJTT4+IEFmdGVyIGZ1 cnRoZXIgZGlzY3Vzc2lvbiwgYXV0aG9ycyBkZWNpZGVkIHRvIHJlbW92ZSB0aGUgcmVxdWVzdCBm b3IgdGhlIGRlZGljYXRlZCBNQUMgYWRkcmVzcyBhbGxvY2F0aW9uLiBPbmx5IHRoZSBNQUMgYWRk cmVzcyBvZiB0aGUgcmVtb3RlIFZURVAgbXVzdCBiZSB1c2VkIGFzIHRoZSBkZXN0aW5hdGlvbiBN QUMgYWRkcmVzcyBpbiB0aGUgaW5uZXIgRXRoZXJuZXQgZnJhbWUuIFBsZWFzZSBjaGVjayB0aGUg YXR0YWNoZWQgZGlmZiBiZXR3ZWVuIHRoZSAtMDcgYW5kIHRoZSB3b3JraW5nIHZlcnNpb25zIG9y IHRoZSB3b3JraW5nIHZlcnNpb24gb2YgdGhlIGRyYWZ0Lg0KPj4+ID4+IA0KPj4+ID4+IEl0IGlz IHVuY2xlYXIgZnJvbSB0aGlzIHNlY3Rpb24gd2hldGhlciBJUHY0IGluc2lkZSBJUHY2IGFuZCB0 aGUgb3Bwb3NpdGUNCj4+PiA+PiBzaG91bGQgYmUgc3VwcG9ydGVkIG9yIG5vdC4NCj4+PiA+PiBH SU0+PiBBbnkgY29tYmluYXRpb24gb2Ygb3V0ZXIgSVB2WCBhbmQgaW5uZXIgSVB2WCBpcyBwb3Nz aWJsZS4NCj4+PiA+PiANCj4+PiA+PiBTZWN0aW9uIDUuDQo+Pj4gPj4gDQo+Pj4gPj4gSWYgdGhl IHJlY2VpdmVkIHBhY2tldCBkb2VzIG5vdCBtYXRjaCB0aGUgZGVkaWNhdGVkIE1BQyBhZGRyZXNz IG5vciB0aGUgTUFDDQo+Pj4gPj4gYWRkcmVzcyBvZiB0aGUgVlRFUCwgc2hvdWxkIHRoZSBwYWNr ZXQgYmUgc2lsZW50bHkgZGlzY2FyZGVkIG9yIHRyZWF0ZWQNCj4+PiA+PiBkaWZmZXJlbnRseSA/ DQo+Pj4gPj4gR0lNPj4gQXMgSSd2ZSBtZW50aW9uZWQgZWFybGllciwgYXV0aG9ycyBoYXZlIGRl Y2lkZWQgdG8gcmVtb3ZlIHRoZSB1c2Ugb2YgdGhlIGRlZGljYXRlZCBNQUMgYWRkcmVzcyBmb3Ig QkZEIG92ZXIgVlhMQU4uDQo+Pj4gPj4gDQo+Pj4gPj4gU2VjdGlvbiA1LjENCj4+PiA+PiANCj4+ PiA+PiBJcyB0aGlzIGEgbW9kaWZpY2F0aW9uIHRvIHNlY3Rpb24gNi4zIG9mIFJGQzU4ODAgPyBU aGlzIGlzIG5vdCBjbGVhcg0KPj4+ID4+IEdJTT4+IEkgdGhpbmsgdGhhdCB0aGlzIHNlY3Rpb24g aXMgbm90IG1vZGlmaWNhdGlvbiBidXQgdGhlIGRlZmluaXRpb24gb2YgdGhlIGFwcGxpY2F0aW9u LXNwZWNpZmljIHByb2NlZHVyZSB0aGF0IGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIFJGQyA1ODgw Og0KPj4+ID4+ICAgIFRoZSBtZXRob2Qgb2YgZGVtdWx0aXBsZXhpbmcgdGhlIGluaXRpYWwgcGFj a2V0cyAoaW4gd2hpY2ggWW91cg0KPj4+ID4+ICAgIERpc2NyaW1pbmF0b3IgaXMgemVybykgaXMg YXBwbGljYXRpb24gZGVwZW5kZW50LCBhbmQgaXMgdGh1cyBvdXRzaWRlDQo+Pj4gPj4gICAgdGhl IHNjb3BlIG9mIHRoaXMgc3BlY2lmaWNhdGlvbi4NCj4+PiA+PiANCj4+PiA+PiBTZWN0aW9uIDkN Cj4+PiA+PiANCj4+PiA+PiBUaGUgc2VudGVuY2UgIiBUaHJvdHRsaW5nIE1BWSBiZSByZWxheGVk IGZvciBCRkQgcGFja2V0cw0KPj4+ID4+ICAgIGJhc2VkIG9uIHBvcnQgbnVtYmVyLiIgaXMgdW5j bGVhci4NCj4+PiA+PiBHSU0+PiBZZXMsIHRoYW5rIHlvdSBmb3IgcG9pbnRpbmcgdG8gdGhpcy4g VGhlIHVwZGF0ZWQgdGV4dCwgaW4gdGhlIHdob2xlIHBhcmFncmFwaCwgaXMgYXMgZm9sbG93czoN Cj4+PiA+PiBORVcgVEVYVDoNCj4+PiA+PiAgICBUaGUgZG9jdW1lbnQgcmVxdWlyZXMgc2V0dGlu ZyB0aGUgaW5uZXIgSVAgVFRMIHRvIDEsIHdoaWNoIGNvdWxkIGJlDQo+Pj4gPj4gICAgdXNlZCBh cyBhIEREb1MgYXR0YWNrIHZlY3Rvci4gIFRodXMgdGhlIGltcGxlbWVudGF0aW9uIE1VU1QgaGF2 ZQ0KPj4+ID4+ICAgIHRocm90dGxpbmcgaW4gcGxhY2UgdG8gY29udHJvbCB0aGUgcmF0ZSBvZiBC RkQgY29udHJvbCBwYWNrZXRzIHNlbnQNCj4+PiA+PiAgICB0byB0aGUgY29udHJvbCBwbGFuZS4g IE9uIHRoZSBvdGhlciBoYW5kLCBvdmVyIGFnZ3Jlc3NpdmUgdGhyb3R0bGluZw0KPj4+ID4+ICAg IG9mIEJGRCBjb250cm9sIHBhY2tldHMgbWF5IGJlY29tZSB0aGUgY2F1c2Ugb2YgdGhlIGluYWJp bGl0eSB0byBmb3JtDQo+Pj4gPj4gICAgYW5kIG1haW50YWluIEJGRCBzZXNzaW9uIGF0IHNjYWxl LiAgSGVuY2UsIHRocm90dGxpbmcgb2YgQkZEIGNvbnRyb2wNCj4+PiA+PiAgICBwYWNrZXRzIFNI T1VMRCBiZSBhZGp1c3RlZCB0byBwZXJtaXQgQkZEIHRvIHdvcmsgYWNjb3JkaW5nIHRvIGl0cw0K Pj4+ID4+ICAgIHByb2NlZHVyZXMuDQo+Pj4gPj4gPGRyYWZ0LWlldGYtYmZkLXZ4bGFuLTA4LnR4 dD48RGlmZl8gZHJhZnQtaWV0Zi1iZmQtdnhsYW4tMDcudHh0IC0gZHJhZnQtaWV0Zi1iZmQtdnhs YW4tMDgudHh0Lmh0bWw+DQo+Pj4gPiANCj4+PiANCj4+IA0KPiANCg0K From nobody Wed Jun 26 19:48:23 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556181200B7; Wed, 26 Jun 2019 18:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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_HELO_NONE=0.001, 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 nzESbqdpWqMQ; Wed, 26 Jun 2019 18:22:56 -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 21FDC120094; Wed, 26 Jun 2019 18:22:56 -0700 (PDT) Received: by mail-lj1-x22b.google.com with SMTP id v24so491364ljg.13; Wed, 26 Jun 2019 18:22:56 -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=zd82tTVQANyYPhTsVnLu6fSqjtovGET2axUGvJizJnI=; b=ixNNEYEutRO+uc4AVbIq400SSqJ8eWcuTby8SDrOGwBPqb1n+4pkQqdG66XJZdhr5B CXyDXr6xu/yguiU2pTomq71F82kcPzT+NG7cEElh0U3Ub3ydAbKp7srdAyblwQarzciA h9JkWUkRNsa1PRg9PKsVEDoWe2b+AyR9R0uJ75yGX4ETFsXxPBAqHIJWNII+CI5LGWyC 6edLLCJT4eHUkHTE4fI+uNYYx6gIAze58QXDh9aIjgdePy3MIsWcsus5xGcAzI269sXd k2saJsMJVVIEF7YVP6ymYzQG+MwnUd7SjjXBfyPGp5srlNy6/DFvd7ByCKc2XzTDbBM2 //Nw== 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=zd82tTVQANyYPhTsVnLu6fSqjtovGET2axUGvJizJnI=; b=XHsp/wqPMfqDsbOptlHwPI7U5oh4CckHO7PwzjmV3X9T3DqG7SajZTXI0NVpchus3a Tp/vU9xEE/jbdxAFi6B5I8jzLz0Y7cfTStDSClp0FlT0HxsbvY8gixjYbihFhci2iHFW VFDy3JjdOCKb2UUShT706zq2Zz5FAfEIGn7WKAAzSsiKNvXNO/xzb5lnyE277+ClK7G1 IFPw4lXk8ipxYSjLFEGShxX5WlZBow8VEJ0O85r+kGdWomLl5WQVXIm65cYQ9QUh/X+y qomgfX6iFDXT/6SC7VDs33FZg/nDBLG3GwgA+mv2jLzYS/xdJ3X82nx7ajJDO07RqKux 30Kw== X-Gm-Message-State: APjAAAVgDawqvrXAQNHnG9h3ZxS1kXSQ94eNJ/9M4Abj+f4nzVnRzu29 u/3aYv2slJ7lDhE6i4Gh6BqPUSINXAUwTxrBHss= X-Google-Smtp-Source: APXvYqyyJKIFL20v4uid90i2+n0Ow1GipPjIgwyFXyf8gNgH9dY/5CTF8/1z+ybfS4AVe9cibjxko6W08lluMqi/CR8= X-Received: by 2002:a2e:7614:: with SMTP id r20mr783518ljc.42.1561598573847; Wed, 26 Jun 2019 18:22:53 -0700 (PDT) MIME-Version: 1.0 References: <155933149484.6565.7386019489022348116@ietfa.amsl.com> <14822B96-D3C6-495E-8661-198068F72ABA@cisco.com> <8237FE8D-937E-4BCB-B1A3-89C2B3CDC51C@cisco.com> <0B9FDA17-7F13-4FEC-AE97-40BC9D72C87B@cisco.com> In-Reply-To: From: Greg Mirsky Date: Wed, 26 Jun 2019 18:22:42 -0700 Message-ID: Subject: Re: Level of standardization of the Echo mode of BFD [Re: Tsvart last call review of draft-ietf-bfd-vxlan-07] To: "Carlos Pignataro (cpignata)" Cc: "tsv-art@ietf.org" , rtg-bfd WG , "draft-ietf-bfd-vxlan.all@ietf.org" , Olivier Bonaventure , IETF list Content-Type: multipart/alternative; boundary="00000000000046aab9058c440056" Archived-At: X-Mailman-Approved-At: Wed, 26 Jun 2019 19:48:21 -0700 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 01:23:02 -0000 --00000000000046aab9058c440056 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Carlos, I hope that you can help me to answer a question related to the scope of RFC 5885. In RFC 5885 is stated: This specification describes procedures only for BFD asynchronous mode. Neither demand mode, nor Echo function of BFD is explicitly mentioned in RFC 5885. Hence my question If BFD over VXLAN changes from explicitly excluding the Echo function from the scope of the document to the definition of the scope like used in RFC 5885, would that address your concern? Regards, Greg On Fri, Jun 21, 2019 at 5:19 PM Carlos Pignataro (cpignata) < cpignata@cisco.com> wrote: > Hello, Greg, > > Thank you for having split this thread. I=E2=80=99ll note for ease of tra= cking > that this specific issue is issue #4 our of the six quick comments I sent= . > > Now, questions you ask like this one quoted from below: > > Would you suggest that the scope of RFC 5884 must include the BFD Echo > function? > > > Are now second-order red herrings and, once again, not relevant to the > issue =E2=80=94 instead they avoid responding and prevent convergence. In= my > comment, I=E2=80=99m just asking for a technical explanation of why BFD E= cho is out > of scope. > > > Please see inline, your response is incorrect in 3 technical areas that I > enumerate. > > > > On Jun 20, 2019, at 1:30 AM, Greg Mirsky wrote: > > > > Hi Carlos, > > thank you for clarifying your opinion on the applicability of the BFD > Echo mode. > > For correctness, I have not issued an "opinion on the applicability of th= e > BFD Echo mode.=E2=80=9D (Again, please do not mischaracterize!) > > My initial question was =E2=80=9Cwhy is this out of scope?=E2=80=9D I bel= ieve scoping > should be deliberate and intentional, and hence seeking to understand. > > > > I've split this thread to help us and others to follow the discussion o= n > this particular issue. I'll note that RFC 5880 does not prohibit the remo= te > system to perform any kind of processing on the packet received in the BF= D > Echo mode. > > This is technical mistake #1. > > RFC 5880 says: > > The Echo function has the advantage of truly testing only the > forwarding path on the remote system. > > > No other processing on the remote system =E2=80=94 that is the benefit of= Echo. > > > > Even more, Section 6.8.8 explicitly points out that a received Echo > packet is likely to be processed: > > A means of detecting missing Echo packets > > MUST be implemented, which most likely involves processing of the > > Echo packets that are received. The processing of received Echo > > packets is otherwise outside the scope of this specification. > > > This is technical mistake #2. > > What you are quoting is referring to the reception of Echo packet by the > Echo packet *sender*. That is, the local system, not the remote system. T= he > Echo packet is received by the same system that sent it (by definition of > Echo!), and thus the node itself needs to demultiplex its own context... > > > > Thus, interoperability is one of the underspecified issues for BFD Echo= . > > No. This is technical mistake #2b. > > There is no interoperability spec considerations between a system and > itself (unless the sender of BFD Echo has split personality :-) > > > > > Secondly, the Echo BFD mode has been excluded from the scope of RFC 588= 4: > > Further, the use of the Echo function is outside the scope of this > specification. > > This is technical mistake #3. > > It is really irrelevant to the question whether RFC 5884, which talks > about BFD for unidirectional MPLS LSPs, scopes out BFD Echo. > > As I mentioned in my initial email, "If this is a single logical hop > underneath VXLAN, what=E2=80=99s preventing the use of Echo?=E2=80=9D RFC= 5884 is different > than (and not useful for or relevant to) the scenario in > draft-ietf-bfd-vxlan. > > > > > Would you suggest that the scope of RFC 5884 must include the BFD Echo > function? > > > I do not understand the context of this question. But as I mentioned, > these questions take the thread in a direction that diverges from > resolution. > > I have not suggested that any document includes anything. My comment is: > what is the reason why BFD Echo is out of scope? Technically, this is a > single hop at the VXLAN level for BFD. > > > Best, > > Carlos. > > > > > Regards, > > Greg > > > > On Thu, Jun 20, 2019 at 2:08 PM Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > > Hello, Greg, > > > > Yes, happy too answer your question. > > > > First, however, let me make two quick observations on the exchange: > > =E2=80=A2 You seem to be picking very specific fragments or sub-t= opics > from my comments, and following up on those only. > > =E2=80=A2 I=E2=80=99m happy to continue answering these questions= , but they are > orthogonal to (and consequently a distraction from) the initial comments = I > raised. > > > > Now, your question: the BFD Echo packet format is generically spec=E2= =80=99ed > and defined in Section 5 of RFC 5880: > > https://tools.ietf.org/html/rfc5880#section-5 > > > > The most relevant part is this: > > > > The payload of a BFD Echo packet is a local matter, since only the > > sending system ever processes the content. The only requirement is > > that sufficient information is included to demultiplex the received > > packet to the correct BFD session after it is looped back to the > > sender. > > > > Since the remote system does not process the echo packet content, it is > a local matter only. And given the fact that, as such, there is no > interoperability implications, there is no need to over-specify the packe= t > format. The only requirement is that the sending system needs to be able = to > map it to a session when it boomerangs back. > > > > No, it is generally not (i.e., does not need to be, but there=E2=80=99s= freedom > to potentially be) a BFD control packet. > > Yes, it can be something else. > > > > That said, the packet format for BFD Echo has, to my analysis and > understanding, no relevancy on the questions below. > > > > Best, > > > > Carlos. > > > >> On Jun 20, 2019, at 12:50 AM, Greg Mirsky > wrote: > >> > >> Hello Carlos, > >> could you please refer me to the specification of BFD that defines the > message format that is used in the Echo mode of BFD. Is it the BFD contro= l > packet? Something else? > >> > >> Regards, > >> Greg > >> > >> > >> On Thu, Jun 20, 2019 at 11:09 AM Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > >> Hello, Greg, > >> > >> Please see inline. > >> > >>> On Jun 19, 2019, at 9:58 PM, Greg Mirsky > wrote: > >>> > >>> Hello Carlos, > >>> thank you for the expedient clarification. > >>> To your questions on demultiplexing BFD control packets with the zero > value of the Your Discriminator field: > >>> =E2=80=A2 only BFD control packets with the zero value of the You= r > Discriminator field are demultiplexed using the information of the inner = IP > header. I believe that the text is clear and requires that all fields of > the inner IP header must be used to demultiplex a received BFD control > packet with the zero value in the Your Discriminator field. Which of the > fields an implementation uses to create multiple BFD sessions between the > pair of VTEPs is implementation specific. > >> This text is repeating was is in the draft, but does not answer any of > my questions. > >> > >> For example: > >> 1. "that all fields of the inner IP header must be used to demultiplex > a received BFD control packet=E2=80=9D > >> -> The text does not say =E2=80=9Call fields=E2=80=9D, but regardl= ess, do you mean > the DSCP and the Evil Bit? IPv6 Flow Label? How *exactly*? > >> 2. How is the mapping of IP (not UDP?) fields to BFD session done? > >> 3. How is this state created and maintained? > >> 4. Since this is a set of fields on which two systems need to agree > (which fields from the inner IP/UDP are mapped needs to be understood by > both systems), it cannot be =E2=80=9Cimplementation specific=E2=80=9D. Fu= rther, the text > does not say so. > >> > >>> To your point on the level Echo mode of BFD is specified in RFC 5880 > I'll quote the opinion of Jeffrey Haas from the discussion of comments fr= om > Shawn Emery on behalf of the SecDir. Shawn had commented: > >>> Echo BFD is out of scope for the document, but does not describe the > reason for this or why state > >>> this at all? > >>> I've responded: > >>> GIM>> I think that the main reason is that the BFD Echo mode is > underspecified. RFC 5880 defined some of the mechanisms related to the Ec= ho > mode, but more standardization work may be required. > >>> And Jeffrey Haas had added: > >>> Speaking as a BFD chair, this is the relevant observation. BFD Echo = is > >>> underspecified to the point where claiming compliance is difficult at > best. > >>> In general, it relies on single-hop and the ability to have the remot= e > Echo > >>> client loop the packets. > >> > >> BFD Echo cannot be specified in RFC 5880 base spec because it is > application specific. > >> > >>> > >>> This packet loop may not be practical for several encapsulations and > thus is > >>> out of scope for such encapsulations. Whether this is practical for > vxlan > >>> today, or in the presence of future extensions to vxlan is left out o= f > scope > >>> for the core proposal. > >> > >> The question remains: for VXLAN encapsulation, this is like a single > hop as far as BFD is concerned (single hop VXLAN tunnel). > >> > >> Since RFC 5881 defines Echo for single hop, can you please elaborate > (in the document) why is out of scope or how it can work? > >> > >> Best, > >> > >> Carlos. > >> > >>> > >>> Will respond to other questions in a separate mail. > >>> > >>> Regards, > >>> Greg > >>> > >>> > >>> On Thu, Jun 20, 2019 at 10:31 AM Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > >>> Hello, Greg, > >>> > >>> > On Jun 19, 2019, at 9:09 PM, Greg Mirsky > wrote: > >>> > > >>> > Hi Carlos, > >>> > thank you for reminding of our continued discussion with Joel. We > are seeking comments from VXLAN experts and much appreciate if you have > insights on VXLAN to share. > >>> > I've got some clarifying questions before I can respond to you. > >>> > >>> Sure. > >>> > >>> > To which stage of the three-way handshake you refer as "initial > demultiplexing"? I couldn't find this term in RFC 5880. > >>> > >>> =E2=80=9CInitial demultiplexing" is a well-known term in BFD, referri= ng to the > "demultiplexing of the initial packets", BFD Control packet with YourDisc > being zero. > >>> > >>> In RFC 5880, see Section 6.3. > >>> https://tools.ietf.org/html/rfc5880#section-6.3 > >>> > >>> The method of demultiplexing the initial packets (in which Your > >>> Discriminator is zero) is application dependent, and is thus outsi= de > >>> the scope of this specification. > >>> > >>> Since initial demultiplexing is indeed application specific, differen= t > for one-hop versus multi-hop and dependent upon whether a single or > multiple sessions are allowed between a pair of endpoints, I added below > two other relevant citations, from application specific BFD specs: > >>> 1. https://tools.ietf.org/html/rfc5883#section-4 > >>> 2. https://tools.ietf.org/html/rfc5882#section-6 > >>> > >>> > >>> > Regarding the applicability of the Echo mode, thank you for pointin= g > to the need for stricter terminology, the Echo mode, as defined in RFC > 5880, is underspecified and it will require additional standardization. > >>> > >>> No. BFD Echo is not underspecified in RFC 5880. > >>> > >>> Please read S5: https://tools.ietf.org/html/rfc5880#section-5 > >>> > >>> BFD Echo packets are sent in an encapsulation appropriate to the > >>> environment. See the appropriate application documents for the > >>> specifics of particular environments. > >>> > >>> > >>> BFD Echo is application dependent. > >>> > >>> Therefore, for example, single-hop BFD in RFC 5881 specifies BFD Echo > for that application. > >>> > >>> Hence, my question stands: why is this draft claiming BFD Echo is out > of scope for this BFD application document? > >>> > >>> > >>> > Future drafts may explore and define how the Echo mode of BFD is > used over VXLAN tunnels. > >>> > > >>> > >>> See above. > >>> > >>> > Will review and respond to the remaining questions soon. > >>> > >>> Thank you. > >>> > >>> The "remaining questions" are still all the questions below :-) > >>> > >>> Best, > >>> > >>> Carlos. > >>> > >>> > > >>> > Regards, > >>> > Greg > >>> > > >>> > > >>> > On Thu, Jun 20, 2019 at 9:14 AM Carlos Pignataro (cpignata) < > cpignata@cisco.com> wrote: > >>> > Hi, > >>> > > >>> > I have not reviewed this draft before, but triggered by this email, > and briefly scanning through a couple of sections, it is unclear to me ho= w > some of the mechanics work. > >>> > > >>> > There are some major issues with the Mac usage and association, as > Joel Halpern mentioned in his Rtg Dir review. > >>> > > >>> > And, additionally, please consider the following comments and > questions: > >>> > > >>> > > >>> > 1. Underspecification for initialization and initial demultiplexing= . > >>> > > >>> > This document allows multiple BFD sessions between a single pair of > VTEPs: > >>> > > >>> > An > >>> > implementation that supports this specification MUST be able to > >>> > control the number of BFD sessions that can be created between t= he > >>> > same pair of VTEPs. > >>> > > >>> > The implication of this is that BFD single-hop initialization > procedures will not work. Instead, there is a need to map the initial > demultiplexing. > >>> > > >>> > This issue is explained in RFCs 5882 and 5883: > https://tools.ietf.org/html/rfc5883#section-4 and > https://tools.ietf.org/html/rfc5882#section-6 > >>> > > >>> > Section 5.1 says: > >>> > > >>> > For such packets, the BFD session MUST be identified > >>> > using the inner headers, i.e., the source IP, the destination IP= , > and > >>> > the source UDP port number present in the IP header carried by t= he > >>> > payload of the VXLAN encapsulated packet. The VNI of the packet > >>> > SHOULD be used to derive interface-related information for > >>> > demultiplexing the packet. > >>> > > >>> > But this does not really explain how to do the initial > demultiplexing. Does each BFD session need to have a separate inner sourc= e > IP address? Or source UDP port? And how ofter are they recycled or kept a= s > state? How are these mapped? > >>> > Equally importantly, which side is Active? > >>> > And what if there=E2=80=99s a race condition with both sides being = Active > and setting up redundant sessions? > >>> > > >>> > 1.b. By the way, based on this, using S-BFD [RFC 7880] might be > easier to demux. > >>> > > >>> > > >>> > 2. Security > >>> > > >>> > This document says that the TTL in the inner packet carrying BFD is > set to 1. However, RFC 5880 says to use GTSM [RFC 5082], i.e., a value of > 255.. > >>> > > >>> > Why is GTSM not used here? > >>> > > >>> > > >>> > 3. ECMP and fate-sharing under-specification: > >>> > > >>> > Section 4.1. says: > >>> > > >>> > The Outer IP/UDP > >>> > and VXLAN headers MUST be encoded by the sender as defined in > >>> > [RFC7348]. > >>> > > >>> > > >>> > And RFC 7348 says: > >>> > > >>> > - Source Port: It is recommended that the UDP source port > number > >>> > be calculated using a hash of fields from the inner packet > -- > >>> > one example being a hash of the inner Ethernet frame's > headers. > >>> > This is to enable a level of entropy for the ECMP/load- > >>> > balancing of the VM-to-VM traffic across the VXLAN overlay= . > >>> > When calculating the UDP source port number in this manner= , > it > >>> > is RECOMMENDED that the value be in the dynamic/private po= rt > >>> > range 49152-65535 [RFC6335]. > >>> > > >>> > > >>> > Based on this, depending on the hashing calculation, the outer > source UDP port can be different leading to different ECMP treatment. Doe= s > something else need to be specified here in regards to the outer UDP sour= ce > port? > >>> > > >>> > > >>> > 4. Section 7 says that =E2=80=9C Support for echo BFD is outside th= e scope > of this document=E2=80=9D. > >>> > > >>> > Assuming this means =E2=80=9CBFD Echo mode=E2=80=9D, why is this ou= t of scope? If > this is a single logical hop underneath VXLAN, what=E2=80=99s preventing = the use of > Echo? Echo=E2=80=99s benefits are huge. > >>> > > >>> > > >>> > 5. Terminology > >>> > > >>> > Implementations SHOULD ensure that the BFD > >>> > packets follow the same lookup path as VXLAN data packets within > the > >>> > sender system. > >>> > > >>> > What is a =E2=80=9Clook up path within a sender system=E2=80=9D? > >>> > > >>> > > >>> > 6. Deployment scenarios > >>> > > >>> > S3 says: > >>> > Figure 1 illustrates the scenario with two servers, each of them > >>> > hosting two VMs. The servers host VTEPs that terminate two VXLA= N > >>> > [=E2=80=A6] > >>> > Figure 1: Reference VXLAN Domain > >>> > > >>> > > >>> > However, RFC 7348 Figure 3 lists that as one deployment scenario, > not as =E2=80=9Cthe scenario=E2=80=9D and =E2=80=9CThe Reference VXLAN Do= main=E2=80=9D. > >>> > > >>> > Best, > >>> > > >>> > Carlos. > >>> > > >>> >> On Jun 17, 2019, at 12:58 AM, Greg Mirsky > wrote: > >>> >> > >>> >> Hi Oliver, > >>> >> thank you for your thorough review, clear and detailed questions. > My apologies for the delay to respond. Please find my answers below in-li= ne > tagged GIM>>. > >>> >> > >>> >> Regards, > >>> >> Greg > >>> >> > >>> >> On Fri, May 31, 2019 at 12:38 PM Olivier Bonaventure via > Datatracker wrote: > >>> >> Reviewer: Olivier Bonaventure > >>> >> Review result: Ready with Issues > >>> >> > >>> >> This document has been reviewed as part of the transport area > review team's > >>> >> ongoing effort to review key IETF documents. These comments were > written > >>> >> primarily for the transport area directors, but are copied to the > document's > >>> >> authors and WG to allow them to address any issues raised and also > to the IETF > >>> >> discussion list for information. > >>> >> > >>> >> When done at the time of IETF Last Call, the authors should > consider this > >>> >> review as part of the last-call comments they receive. Please > always CC > >>> >> tsv-art@ietf.org if you reply to or forward this review. > >>> >> > >>> >> I have only limited knowledge of VXLAN and do not know all > subtleties of BFD. > >>> >> This review is thus more from a generalist than a specialist in > this topic. > >>> >> > >>> >> Major issues > >>> >> > >>> >> Section 4 requires that " Implementations SHOULD ensure that the B= FD > >>> >> packets follow the same lookup path as VXLAN data packets withi= n > the > >>> >> sender system." > >>> >> > >>> >> Why is this requirement only relevant for the lookup path on the > sender system > >>> >> ? What does this sentence really implies ? > >>> >> GIM>> RFC 5880 set the scope of the fault detection of BFD protoco= l > as > >>> >> ... the bidirectional path between two forwarding engines, > including > >>> >> interfaces, data link(s), and to the extent possible the > forwarding > >>> >> engines themselves ... > >>> >> The requirement aimed to the forwarding engine of a BFD system tha= t > transmits BFD control packets over VXLAN tunnel. > >>> >> > >>> >> Is it a requirement that the BFD packets follow the same path as > the data > >>> >> packet for a given VXLAN ? I guess so. In this case, the document > should > >>> >> discuss how Equal Cost Multipath could affect this. > >>> >> GIM>> I think that ECMP environment is more likely to be > experienced by a transit node in the underlay. If the BFD session is used > to monitor the specific underlay path, then, I agree, we should explain > that using the VXLAN payload information to draw path entropy may cause > data and BFD packets following different underlay routes. But, on the oth= er > hand, that is the case for OAM and fault detection in all overlay network= s > in general. > >>> >> > >>> >> Minor issues > >>> >> > >>> >> Section 1 > >>> >> > >>> >> You write "The asynchronous mode of BFD, as defined in [RFC5880], > >>> >> can be used to monitor a p2p VXLAN tunnel." > >>> >> > >>> >> Why do you use the word can ? It is a possibility or a requirement= ? > >>> >> GIM>> In principle, BFD Demand mode may be used to monitor p2p > paths as well, I agree, will re-word to more assertive: > >>> >> The asynchronous mode of BFD, as defined in [RFC5880], > >>> >> is used to monitor a p2p VXLAN tunnel. > >>> >> > >>> >> NVE has not been defined before and is not in the terminology. > >>> >> GIM>> Will add to the Terminology and expand as: > >>> >> NVE Network Virtualization Endpoint > >>> >> > >>> >> This entire section is not easy to read for an outsider. > >>> >> > >>> >> Section 3 > >>> >> > >>> >> VNI has not been defined > >>> >> GIM>> Will add to the Terminology section: > >>> >> VNI VXLAN Network Identifier (or VXLAN Segment ID) > >>> >> > >>> >> Figure 1 could take less space > >>> >> GIM>> Yes, can make it bit denser. Would the following be an > improvement? > >>> >> > >>> >> +------------+-------------+ > >>> >> | Server 1 | > >>> >> | +----+----+ +----+----+ | > >>> >> | |VM1-1 | |VM1-2 | | > >>> >> | |VNI 100 | |VNI 200 | | > >>> >> | | | | | | > >>> >> | +---------+ +---------+ | > >>> >> | Hypervisor VTEP (IP1) | > >>> >> +--------------------------+ > >>> >> | > >>> >> | +-------------+ > >>> >> | | Layer 3 | > >>> >> +---| Network | > >>> >> +-------------+ > >>> >> | > >>> >> +-----------+ > >>> >> | > >>> >> > +------------+-------------+ > >>> >> | Hypervisor VTEP (IP2= ) > | > >>> >> | +----+----+ +----+----= + > | > >>> >> | |VM2-1 | |VM2-2 = | > | > >>> >> | |VNI 100 | |VNI 200 = | > | > >>> >> | | | | = | > | > >>> >> | +---------+ +---------= + > | > >>> >> | Server 2 > | > >>> >> > +--------------------------+ > >>> >> > >>> >> > >>> >> Section 4 > >>> >> > >>> >> I do not see the benefits of having one paragraph in Section 4 > followed by only > >>> >> Section 4.1 > >>> >> GIM>> Will merge Section 4.1 into 4 with minor required re-wording= : > >>> >> 4. BFD Packet Transmission over VXLAN Tunnel > >>> >> > >>> >> BFD packet MUST be encapsulated and sent to a remote VTEP as > >>> >> explained in this section. Implementations SHOULD ensure that > the > >>> >> BFD packets follow the same lookup path as VXLAN data packets > within > >>> >> the sender system. > >>> >> > >>> >> BFD packets are encapsulated in VXLAN as described below. The > VXLAN > >>> >> packet format is defined in Section 5 of [RFC7348]. The Outer > IP/UDP > >>> >> and VXLAN headers MUST be encoded by the sender as defined in > >>> >> [RFC7348]. > >>> >> > >>> >> Section 4.1 > >>> >> > >>> >> The document does not specify when a dedicated MAC address or the > MAC address > >>> >> of the destination VTEP must be used. This could affect the > interoperability of > >>> >> implementations. Should all implementations support both the > dedicated MAC > >>> >> address and the destination MAC address ? > >>> >> GIM>> After further discussion, authors decided to remove the > request for the dedicated MAC address allocation. Only the MAC address of > the remote VTEP must be used as the destination MAC address in the inner > Ethernet frame. Please check the attached diff between the -07 and the > working versions or the working version of the draft. > >>> >> > >>> >> It is unclear from this section whether IPv4 inside IPv6 and the > opposite > >>> >> should be supported or not. > >>> >> GIM>> Any combination of outer IPvX and inner IPvX is possible. > >>> >> > >>> >> Section 5. > >>> >> > >>> >> If the received packet does not match the dedicated MAC address no= r > the MAC > >>> >> address of the VTEP, should the packet be silently discarded or > treated > >>> >> differently ? > >>> >> GIM>> As I've mentioned earlier, authors have decided to remove th= e > use of the dedicated MAC address for BFD over VXLAN. > >>> >> > >>> >> Section 5.1 > >>> >> > >>> >> Is this a modification to section 6.3 of RFC5880 ? This is not cle= ar > >>> >> GIM>> I think that this section is not modification but the > definition of the application-specific procedure that is outside the scop= e > of RFC 5880: > >>> >> The method of demultiplexing the initial packets (in which Your > >>> >> Discriminator is zero) is application dependent, and is thus > outside > >>> >> the scope of this specification. > >>> >> > >>> >> Section 9 > >>> >> > >>> >> The sentence " Throttling MAY be relaxed for BFD packets > >>> >> based on port number." is unclear. > >>> >> GIM>> Yes, thank you for pointing to this. The updated text, in th= e > whole paragraph, is as follows: > >>> >> NEW TEXT: > >>> >> The document requires setting the inner IP TTL to 1, which coul= d > be > >>> >> used as a DDoS attack vector. Thus the implementation MUST hav= e > >>> >> throttling in place to control the rate of BFD control packets > sent > >>> >> to the control plane. On the other hand, over aggressive > throttling > >>> >> of BFD control packets may become the cause of the inability to > form > >>> >> and maintain BFD session at scale. Hence, throttling of BFD > control > >>> >> packets SHOULD be adjusted to permit BFD to work according to i= ts > >>> >> procedures. > >>> >> draft-ietf-bfd-vxlan-08.txt.html> > >>> > > >>> > >> > > > > --00000000000046aab9058c440056 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Carlos,
I hope that you can help me to answer a = question related to the scope of RFC 5885. In RFC 5885 is stated:
=C2=A0 =C2=A0This specification describes procedures only for BFD asynchro= nous mode.
Neither demand mode, nor Echo function of BFD is e= xplicitly mentioned in RFC 5885. Hence my question If BFD over VXLAN change= s from explicitly excluding the Echo function from the scope of the documen= t to the definition of the scope like used in RFC 5885, would that address = your concern?

Regards,
Greg
<= br>
On Fri,= Jun 21, 2019 at 5:19 PM Carlos Pignataro (cpignata) <cpignata@cisco.com> wrote:
Hello, Greg,

Thank you for having split this thread. I=E2=80=99ll note for ease of track= ing that this specific issue is issue #4 our of the six quick comments I se= nt.

Now, questions you ask like this one quoted from below:
> Would you suggest that the scope of RFC 5884 must include the BFD Echo= function?


Are now second-order red herrings and, once again, not relevant to the issu= e =E2=80=94 instead they avoid responding and prevent convergence. In my co= mment, I=E2=80=99m just asking for a technical explanation of why BFD Echo = is out of scope.


Please see inline, your response is incorrect in 3 technical areas that I e= numerate.


> On Jun 20, 2019, at 1:30 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:
>
> Hi Carlos,
> thank you for clarifying your opinion on the applicability of the BFD = Echo mode.

For correctness, I have not issued an "opinion on the applicability of= the BFD Echo mode.=E2=80=9D (Again, please do not mischaracterize!)

My initial question was =E2=80=9Cwhy is this out of scope?=E2=80=9D I belie= ve scoping should be deliberate and intentional, and hence seeking to under= stand.


> I've split this thread to help us and others to follow the discuss= ion on this particular issue. I'll note that RFC 5880 does not prohibit= the remote system to perform any kind of processing on the packet received= in the BFD Echo mode.

This is technical mistake #1.

RFC 5880 says:

=C2=A0 =C2=A0The Echo function has the advantage of truly testing only the<= br> =C2=A0 =C2=A0forwarding path on the remote system.


No other processing on the remote system =E2=80=94 that is the benefit of E= cho.


> Even more, Section 6.8.8 explicitly points out that a received Echo pa= cket is likely to be processed:
>=C2=A0 =C2=A0 A means of detecting missing Echo packets
>=C2=A0 =C2=A0 MUST be implemented, which most likely involves processin= g of the
>=C2=A0 =C2=A0 Echo packets that are received.=C2=A0 The processing of r= eceived Echo
>=C2=A0 =C2=A0 packets is otherwise outside the scope of this specificat= ion.


This is technical mistake #2.

What you are quoting is referring to the reception of Echo packet by the Ec= ho packet *sender*. That is, the local system, not the remote system. The E= cho packet is received by the same system that sent it (by definition of Ec= ho!), and thus the node itself needs to demultiplex its own context...


> Thus, interoperability is one of the underspecified issues for BFD Ech= o.

No. This is technical mistake #2b.

There is no interoperability spec considerations between a system and itsel= f (unless the sender of BFD Echo has split personality :-)



> Secondly, the Echo BFD mode has been excluded from the scope of RFC 58= 84:
> Further, the use of the Echo function is outside the scope of this spe= cification.

This is technical mistake #3.

It is really irrelevant to the question whether RFC 5884, which talks about= BFD for unidirectional MPLS LSPs, scopes out BFD Echo.

As I mentioned in my initial email, "If this is a single logical hop u= nderneath VXLAN, what=E2=80=99s preventing the use of Echo?=E2=80=9D RFC 58= 84 is different than (and not useful for or relevant to) the scenario in dr= aft-ietf-bfd-vxlan.



> Would you suggest that the scope of RFC 5884 must include the BFD Echo= function?


I do not understand the context of this question. But as I mentioned, these= questions take the thread in a direction that diverges from resolution.
I have not suggested that any document includes anything. My comment is: wh= at is the reason why BFD Echo is out of scope? Technically, this is a singl= e hop at the VXLAN level for BFD.


Best,

Carlos.

>
> Regards,
> Greg
>
> On Thu, Jun 20, 2019 at 2:08 PM Carlos Pignataro (cpignata) <cpignata@cisco.com>= ; wrote:
> Hello, Greg,
>
> Yes, happy too answer your question.
>
> First, however, let me make two quick observations on the exchange: >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 You seem to be picking very specif= ic fragments or sub-topics from my comments, and following up on those only= .
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 I=E2=80=99m happy to continue answ= ering these questions, but they are orthogonal to (and consequently a distr= action from) the initial comments I raised.
>
> Now, your question: the BFD Echo packet format is generically spec=E2= =80=99ed and defined in Section 5 of RFC 5880:
> https://tools.ietf.org/html/rfc5880#section-5<= br> >
> The most relevant part is this:
>
>=C2=A0 =C2=A0 The payload of a BFD Echo packet is a local matter, since= only the
>=C2=A0 =C2=A0 sending system ever processes the content.=C2=A0 The only= requirement is
>=C2=A0 =C2=A0 that sufficient information is included to demultiplex th= e received
>=C2=A0 =C2=A0 packet to the correct BFD session after it is looped back= to the
>=C2=A0 =C2=A0 sender.
>
> Since the remote system does not process the echo packet content, it i= s a local matter only. And given the fact that, as such, there is no intero= perability implications, there is no need to over-specify the packet format= . The only requirement is that the sending system needs to be able to map i= t to a session when it boomerangs back.
>
> No, it is generally not (i.e., does not need to be, but there=E2=80=99= s freedom to potentially be) a BFD control packet.
> Yes, it can be something else.
>
> That said, the packet format for BFD Echo has, to my analysis and unde= rstanding, no relevancy on the questions below.
>
> Best,
>
> Carlos.
>
>> On Jun 20, 2019, at 12:50 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:=
>>
>> Hello Carlos,
>> could you please refer me to the specification of BFD that defines= the message format that is used in the Echo mode of BFD. Is it the BFD con= trol packet? Something else?
>>
>> Regards,
>> Greg
>>
>>
>> On Thu, Jun 20, 2019 at 11:09 AM Carlos Pignataro (cpignata) <<= a href=3D"mailto:cpignata@cisco.com" target=3D"_blank">cpignata@cisco.com> wrote:
>> Hello, Greg,
>>
>> Please see inline.
>>
>>> On Jun 19, 2019, at 9:58 PM, Greg Mirsky <gregimirsky@gmail.com> wro= te:
>>>
>>> Hello Carlos,
>>> thank you for the expedient clarification.
>>> To your questions on demultiplexing BFD control packets with t= he zero value of the Your Discriminator field:
>>>=C2=A0 =C2=A0 =C2=A0=E2=80=A2 only BFD control packets with the= zero value of the Your Discriminator field are demultiplexed using the inf= ormation of the inner IP header. I believe that the text is clear and requi= res that all fields of the inner IP header must be used to demultiplex a re= ceived BFD control packet with the zero value in the Your Discriminator fie= ld. Which of the fields an implementation uses to create multiple BFD sessi= ons between the pair of VTEPs is implementation specific.
>> This text is repeating was is in the draft, but does not answer an= y of my questions.
>>
>> For example:
>> 1. "that all fields of the inner IP header must be used to de= multiplex a received BFD control packet=E2=80=9D
>>=C2=A0 =C2=A0 =C2=A0-> The text does not say =E2=80=9Call fields= =E2=80=9D, but regardless, do you mean the DSCP and the Evil Bit? IPv6 Flow= Label? How *exactly*?
>> 2. How is the mapping of IP (not UDP?) fields to BFD session done?=
>> 3. How is this state created and maintained?
>> 4. Since this is a set of fields on which two systems need to agre= e (which fields from the inner IP/UDP are mapped needs to be understood by = both systems), it cannot be =E2=80=9Cimplementation specific=E2=80=9D. Furt= her, the text does not say so.
>>
>>> To your point on the level Echo mode of BFD is specified in RF= C 5880 I'll quote the opinion of Jeffrey Haas from the discussion of co= mments from Shawn Emery on behalf of the SecDir. Shawn had commented:
>>> Echo BFD is out of scope for the document, but does not descri= be the reason for this or why state
>>> this at all?
>>> I've responded:
>>> GIM>> I think that the main reason is that the BFD Echo = mode is underspecified. RFC 5880 defined some of the mechanisms related to = the Echo mode, but more standardization work may be required.=C2=A0
>>> And Jeffrey Haas had added:
>>> Speaking as a BFD chair, this is the relevant observation.=C2= =A0 BFD Echo is
>>> underspecified to the point where claiming compliance is diffi= cult at best.
>>> In general, it relies on single-hop and the ability to have th= e remote Echo
>>> client loop the packets.
>>
>> BFD Echo cannot be specified in RFC 5880 base spec because it is a= pplication specific.
>>
>>>
>>> This packet loop may not be practical for several encapsulatio= ns and thus is
>>> out of scope for such encapsulations.=C2=A0 Whether this is pr= actical for vxlan
>>> today, or in the presence of future extensions to vxlan is lef= t out of scope
>>> for the core proposal.=C2=A0
>>
>> The question remains: for VXLAN encapsulation, this is like a sing= le hop as far as BFD is concerned (single hop VXLAN tunnel).
>>
>> Since RFC 5881 defines Echo for single hop, can you please elabora= te (in the document) why is out of scope or how it can work?
>>
>> Best,
>>
>> Carlos.
>>
>>>
>>> Will respond to other questions in a separate mail.
>>>
>>> Regards,
>>> Greg
>>>
>>>
>>> On Thu, Jun 20, 2019 at 10:31 AM Carlos Pignataro (cpignata) &= lt;cpignata@cisco.c= om> wrote:
>>> Hello, Greg,
>>>
>>> > On Jun 19, 2019, at 9:09 PM, Greg Mirsky <gregimirsky@gmail.com>= ; wrote:
>>> >
>>> > Hi Carlos,
>>> > thank you for reminding of our continued discussion with = Joel. We are seeking comments from VXLAN experts and much appreciate if you= have insights on VXLAN to share.
>>> > I've got some clarifying questions before I can respo= nd to you.
>>>
>>> Sure.
>>>
>>> > To which stage of the three-way handshake you refer as &q= uot;initial demultiplexing"? I couldn't find this term in RFC 5880= .
>>>
>>> =E2=80=9CInitial demultiplexing" is a well-known term in = BFD, referring to the "demultiplexing of the initial packets", BF= D Control packet with YourDisc being zero.
>>>
>>> In RFC 5880, see Section 6.3.
>>> https://tools.ietf.org/html/rfc5880#sect= ion-6.3
>>>
>>>=C2=A0 =C2=A0 The method of demultiplexing the initial packets = (in which Your
>>>=C2=A0 =C2=A0 Discriminator is zero) is application dependent, = and is thus outside
>>>=C2=A0 =C2=A0 the scope of this specification.
>>>
>>> Since initial demultiplexing is indeed application specific, d= ifferent for one-hop versus multi-hop and dependent upon whether a single o= r multiple sessions are allowed between a pair of endpoints, I added below = two other relevant citations, from application specific BFD specs:
>>> 1. https://tools.ietf.org/html/rfc5883#sec= tion-4
>>> 2. https://tools.ietf.org/html/rfc5882#sec= tion-6
>>>
>>>
>>> > Regarding the applicability of the Echo mode, thank you f= or pointing to the need for stricter terminology, the Echo mode, as defined= in RFC 5880, is underspecified and it will require additional standardizat= ion.
>>>
>>> No. BFD Echo is not underspecified in RFC 5880.
>>>
>>> Please read S5: https://tools.ietf.org/htm= l/rfc5880#section-5
>>>
>>>=C2=A0 =C2=A0 BFD Echo packets are sent in an encapsulation app= ropriate to the
>>>=C2=A0 =C2=A0 environment.=C2=A0 See the appropriate applicatio= n documents for the
>>>=C2=A0 =C2=A0 specifics of particular environments.
>>>
>>>
>>> BFD Echo is application dependent.
>>>
>>> Therefore, for example, single-hop BFD in RFC 5881 specifies B= FD Echo for that application.
>>>
>>> Hence, my question stands: why is this draft claiming BFD Echo= is out of scope for this BFD application document?
>>>
>>>
>>> > Future drafts may explore and define how the Echo mode of= BFD is used over VXLAN tunnels.
>>> >
>>>
>>> See above.
>>>
>>> > Will review and respond to the remaining questions soon.<= br> >>>
>>> Thank you.
>>>
>>> The "remaining questions" are still all the question= s below :-)
>>>
>>> Best,
>>>
>>> Carlos.
>>>
>>> >
>>> > Regards,
>>> > Greg
>>> >
>>> >
>>> > On Thu, Jun 20, 2019 at 9:14 AM Carlos Pignataro (cpignat= a) <cpignata@cis= co.com> wrote:
>>> > Hi,
>>> >
>>> > I have not reviewed this draft before, but triggered by t= his email, and briefly scanning through a couple of sections, it is unclear= to me how some of the mechanics work.
>>> >
>>> > There are some major issues with the Mac usage and associ= ation, as Joel Halpern mentioned in his Rtg Dir review.
>>> >
>>> > And, additionally, please consider the following comments= and questions:
>>> >
>>> >
>>> > 1. Underspecification for initialization and initial demu= ltiplexing.
>>> >
>>> > This document allows multiple BFD sessions between a sing= le pair of VTEPs:
>>> >
>>> >=C2=A0 =C2=A0 An
>>> >=C2=A0 =C2=A0 implementation that supports this specificat= ion MUST be able to
>>> >=C2=A0 =C2=A0 control the number of BFD sessions that can = be created between the
>>> >=C2=A0 =C2=A0 same pair of VTEPs.
>>> >
>>> > The implication of this is that BFD single-hop initializa= tion procedures will not work. Instead, there is a need to map the initial = demultiplexing.
>>> >
>>> > This issue is explained in RFCs 5882 and 5883: https://tools.ietf.org/html/rfc5883#section-4 and https://tools.ietf.org/html/rfc5882#section-6
>>> >
>>> > Section 5.1 says:
>>> >
>>> >=C2=A0 =C2=A0 For such packets, the BFD session MUST be id= entified
>>> >=C2=A0 =C2=A0 using the inner headers, i.e., the source IP= , the destination IP, and
>>> >=C2=A0 =C2=A0 the source UDP port number present in the IP= header carried by the
>>> >=C2=A0 =C2=A0 payload of the VXLAN encapsulated packet.=C2= =A0 The VNI of the packet
>>> >=C2=A0 =C2=A0 SHOULD be used to derive interface-related i= nformation for
>>> >=C2=A0 =C2=A0 demultiplexing the packet.
>>> >
>>> > But this does not really explain how to do the initial de= multiplexing. Does each BFD session need to have a separate inner source IP= address? Or source UDP port? And how ofter are they recycled or kept as st= ate? How are these mapped?
>>> > Equally importantly, which side is Active?
>>> > And what if there=E2=80=99s a race condition with both si= des being Active and setting up redundant sessions?
>>> >
>>> > 1.b. By the way, based on this, using S-BFD [RFC 7880] mi= ght be easier to demux.
>>> >
>>> >
>>> > 2. Security
>>> >
>>> > This document says that the TTL in the inner packet carry= ing BFD is set to 1. However, RFC 5880 says to use GTSM [RFC 5082], i.e., a= value of 255..
>>> >
>>> > Why is GTSM not used here?
>>> >
>>> >
>>> > 3. ECMP and fate-sharing under-specification:
>>> >
>>> > Section 4.1. says:
>>> >
>>> >=C2=A0 =C2=A0 The Outer IP/UDP
>>> >=C2=A0 =C2=A0 and VXLAN headers MUST be encoded by the sen= der as defined in
>>> >=C2=A0 =C2=A0 [RFC7348].
>>> >
>>> >
>>> > And RFC 7348 says:
>>> >
>>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0 Source Port:=C2=A0 It i= s recommended that the UDP source port number
>>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 be calculated using a h= ash of fields from the inner packet --
>>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 one example being a has= h of the inner Ethernet frame's headers.
>>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This is to enable a lev= el of entropy for the ECMP/load-
>>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 balancing of the VM-to-= VM traffic across the VXLAN overlay.
>>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 When calculating the UD= P source port number in this manner, it
>>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is RECOMMENDED that the= value be in the dynamic/private port
>>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 range 49152-65535 [RFC6= 335].
>>> >
>>> >
>>> > Based on this, depending on the hashing calculation, the = outer source UDP port can be different leading to different ECMP treatment.= Does something else need to be specified here in regards to the outer UDP = source port?
>>> >
>>> >
>>> > 4. Section 7 says that =E2=80=9C Support for echo BFD is = outside the scope of this document=E2=80=9D.
>>> >
>>> > Assuming this means =E2=80=9CBFD Echo mode=E2=80=9D, why = is this out of scope? If this is a single logical hop underneath VXLAN, wha= t=E2=80=99s preventing the use of Echo? Echo=E2=80=99s benefits are huge. >>> >
>>> >
>>> > 5. Terminology
>>> >
>>> >=C2=A0 =C2=A0 Implementations SHOULD ensure that the BFD >>> >=C2=A0 =C2=A0 packets follow the same lookup path as VXLAN= data packets within the
>>> >=C2=A0 =C2=A0 sender system.
>>> >
>>> > What is a =E2=80=9Clook up path within a sender system=E2= =80=9D?
>>> >
>>> >
>>> > 6. Deployment scenarios
>>> >
>>> > S3 says:
>>> >=C2=A0 =C2=A0 Figure 1 illustrates the scenario with two s= ervers, each of them
>>> >=C2=A0 =C2=A0 hosting two VMs.=C2=A0 The servers host VTEP= s that terminate two VXLAN
>>> > [=E2=80=A6]
>>> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 Figure 1: Reference VXLAN Domain
>>> >
>>> >
>>> > However, RFC 7348 Figure 3 lists that as one deployment s= cenario, not as =E2=80=9Cthe scenario=E2=80=9D and =E2=80=9CThe Reference V= XLAN Domain=E2=80=9D.
>>> >
>>> > Best,
>>> >
>>> > Carlos.
>>> >
>>> >> On Jun 17, 2019, at 12:58 AM, Greg Mirsky <gregimirsky@gmail.com> wrote:
>>> >>
>>> >> Hi Oliver,
>>> >> thank you for your thorough review, clear and detaile= d questions. My apologies for the delay to respond. Please find my answers = below in-line tagged GIM>>.
>>> >>
>>> >> Regards,
>>> >> Greg
>>> >>
>>> >> On Fri, May 31, 2019 at 12:38 PM Olivier Bonaventure = via Datatracker <n= oreply@ietf.org> wrote:
>>> >> Reviewer: Olivier Bonaventure
>>> >> Review result: Ready with Issues
>>> >>
>>> >> This document has been reviewed as part of the transp= ort area review team's
>>> >> ongoing effort to review key IETF documents. These co= mments were written
>>> >> primarily for the transport area directors, but are c= opied to the document's
>>> >> authors and WG to allow them to address any issues ra= ised and also to the IETF
>>> >> discussion list for information.
>>> >>
>>> >> When done at the time of IETF Last Call, the authors = should consider this
>>> >> review as part of the last-call comments they receive= . Please always CC
>>> >> tsv-art@ietf.org if you reply to or forward this review.
>>> >>
>>> >> I have only limited knowledge of VXLAN and do not kno= w all subtleties of BFD.
>>> >> This review is thus more from a generalist than a spe= cialist in this topic.
>>> >>
>>> >> Major issues
>>> >>
>>> >> Section 4 requires that " Implementations SHOULD= ensure that the BFD
>>> >>=C2=A0 =C2=A0 packets follow the same lookup path as V= XLAN data packets within the
>>> >>=C2=A0 =C2=A0 sender system."
>>> >>
>>> >> Why is this requirement only relevant for the lookup = path on the sender system
>>> >> ? What does this sentence really implies ?
>>> >> GIM>> RFC 5880 set the scope of the fault detec= tion of BFD protocol as
>>> >>=C2=A0 =C2=A0 ... the bidirectional path between two f= orwarding engines, including
>>> >>=C2=A0 =C2=A0 interfaces, data link(s), and to the ext= ent possible the forwarding
>>> >>=C2=A0 =C2=A0 engines themselves ...
>>> >> The requirement aimed to the forwarding engine of a B= FD system that transmits BFD control packets over VXLAN tunnel.
>>> >>
>>> >> Is it a requirement that the BFD packets follow the s= ame path as the data
>>> >> packet for a given VXLAN ? I guess so. In this case, = the document should
>>> >> discuss how Equal Cost Multipath could affect this. >>> >> GIM>> I think that ECMP environment is more lik= ely to be experienced by a transit node in the underlay. If the BFD session= is used to monitor the specific underlay path, then, I agree, we should ex= plain that using the VXLAN payload information to draw path entropy may cau= se data and BFD packets following different underlay routes. But, on the ot= her hand, that is the case for OAM and fault detection in all overlay netwo= rks in general.
>>> >>
>>> >> Minor issues
>>> >>
>>> >> Section 1
>>> >>
>>> >> You write "The asynchronous mode of BFD, as defi= ned in [RFC5880],
>>> >>=C2=A0 can be used to monitor a p2p VXLAN tunnel."= ;
>>> >>
>>> >> Why do you use the word can ? It is a possibility or = a requirement ?
>>> >> GIM>> In principle, BFD Demand mode may be used= to monitor p2p paths as well, I agree, will re-word to more assertive:
>>> >>=C2=A0 The asynchronous mode of BFD, as defined in [RF= C5880],
>>> >>=C2=A0 is used to monitor a p2p VXLAN tunnel.
>>> >>
>>> >> NVE has not been defined before and is not in the ter= minology.
>>> >> GIM>> Will add to the Terminology and expand as= :
>>> >> NVE=C2=A0 =C2=A0 =C2=A0 =C2=A0 Network Virtualization= Endpoint
>>> >>
>>> >> This entire section is not easy to read for an outsid= er.
>>> >>
>>> >> Section 3
>>> >>
>>> >> VNI has not been defined
>>> >> GIM>> Will add to the Terminology section:
>>> >> VNI=C2=A0 =C2=A0 VXLAN Network Identifier (or VXLAN S= egment ID)
>>> >>
>>> >> Figure 1 could take less space
>>> >> GIM>> Yes, can make it bit denser. Would the fo= llowing be an improvement?
>>> >>=C2=A0
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0+------------+-------------= +
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 Server 1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0| +----+----+=C2=A0 +----+-= ---+ |
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0| |VM1-1=C2=A0 =C2=A0 |=C2= =A0 |VM1-2=C2=A0 =C2=A0 | |
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0| |VNI 100=C2=A0 |=C2=A0 |V= NI 200=C2=A0 | |
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0| |=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| |
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0| +---------+=C2=A0 +------= ---+ |
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0| Hypervisor VTEP (IP1)=C2= =A0 =C2=A0 |
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0+--------------------------= +
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0+--------= -----+
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0|=C2=A0 = =C2=A0Layer 3=C2=A0 =C2=A0|
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---|=C2=A0 =C2=A0Netwo= rk=C2=A0 =C2=A0|
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--------= -----+
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0+-----------+
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 +------------+-------------+
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 Hypervisor VTEP (IP2) |
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | +----+----+=C2=A0 +----+----+ |
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | |VM2-1=C2=A0 =C2=A0 |=C2=A0 |VM2-2=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 | |VNI 100=C2=A0 |=C2=A0 |VNI 200=C2=A0 | |
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 |=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| |
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | +---------+=C2=A0 +---------+ |
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 Server 2=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
>>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 +--------------------------+
>>> >>
>>> >>
>>> >> Section 4
>>> >>
>>> >> I do not see the benefits of having one paragraph in = Section 4 followed by only
>>> >> Section 4.1
>>> >> GIM>> Will merge Section 4.1 into 4 with minor = required re-wording:
>>> >> 4.=C2=A0 BFD Packet Transmission over VXLAN Tunnel >>> >>
>>> >>=C2=A0 =C2=A0 BFD packet MUST be encapsulated and sent= to a remote VTEP as
>>> >>=C2=A0 =C2=A0 explained in this section.=C2=A0 Impleme= ntations SHOULD ensure that the
>>> >>=C2=A0 =C2=A0 BFD packets follow the same lookup path = as VXLAN data packets within
>>> >>=C2=A0 =C2=A0 the sender system.
>>> >>
>>> >>=C2=A0 =C2=A0 BFD packets are encapsulated in VXLAN as= described below.=C2=A0 The VXLAN
>>> >>=C2=A0 =C2=A0 packet format is defined in Section 5 of= [RFC7348].=C2=A0 The Outer IP/UDP
>>> >>=C2=A0 =C2=A0 and VXLAN headers MUST be encoded by the= sender as defined in
>>> >>=C2=A0 =C2=A0 [RFC7348].
>>> >>
>>> >> Section 4.1
>>> >>
>>> >> The document does not specify when a dedicated MAC ad= dress or the MAC address
>>> >> of the destination VTEP must be used. This could affe= ct the interoperability of
>>> >> implementations. Should all implementations support b= oth the dedicated MAC
>>> >> address and the destination MAC address ?
>>> >> GIM>> After further discussion, authors decided= to remove the request for the dedicated MAC address allocation. Only the M= AC address of the remote VTEP must be used as the destination MAC address i= n the inner Ethernet frame. Please check the attached diff between the -07 = and the working versions or the working version of the draft.
>>> >>
>>> >> It is unclear from this section whether IPv4 inside I= Pv6 and the opposite
>>> >> should be supported or not.
>>> >> GIM>> Any combination of outer IPvX and inner I= PvX is possible.
>>> >>
>>> >> Section 5.
>>> >>
>>> >> If the received packet does not match the dedicated M= AC address nor the MAC
>>> >> address of the VTEP, should the packet be silently di= scarded or treated
>>> >> differently ?
>>> >> GIM>> As I've mentioned earlier, authors ha= ve decided to remove the use of the dedicated MAC address for BFD over VXLA= N.
>>> >>
>>> >> Section 5.1
>>> >>
>>> >> Is this a modification to section 6.3 of RFC5880 ? Th= is is not clear
>>> >> GIM>> I think that this section is not modifica= tion but the definition of the application-specific procedure that is outsi= de the scope of RFC 5880:
>>> >>=C2=A0 =C2=A0 The method of demultiplexing the initial= packets (in which Your
>>> >>=C2=A0 =C2=A0 Discriminator is zero) is application de= pendent, and is thus outside
>>> >>=C2=A0 =C2=A0 the scope of this specification.
>>> >>
>>> >> Section 9
>>> >>
>>> >> The sentence " Throttling MAY be relaxed for BFD= packets
>>> >>=C2=A0 =C2=A0 based on port number." is unclear.<= br> >>> >> GIM>> Yes, thank you for pointing to this. The = updated text, in the whole paragraph, is as follows:
>>> >> NEW TEXT:
>>> >>=C2=A0 =C2=A0 The document requires setting the inner = IP TTL to 1, which could be
>>> >>=C2=A0 =C2=A0 used as a DDoS attack vector.=C2=A0 Thus= the implementation MUST have
>>> >>=C2=A0 =C2=A0 throttling in place to control the rate = of BFD control packets sent
>>> >>=C2=A0 =C2=A0 to the control plane.=C2=A0 On the other= hand, over aggressive throttling
>>> >>=C2=A0 =C2=A0 of BFD control packets may become the ca= use of the inability to form
>>> >>=C2=A0 =C2=A0 and maintain BFD session at scale.=C2=A0= Hence, throttling of BFD control
>>> >>=C2=A0 =C2=A0 packets SHOULD be adjusted to permit BFD= to work according to its
>>> >>=C2=A0 =C2=A0 procedures.
>>> >> <draft-ietf-bfd-vxlan-08.txt><Diff_ draft-ie= tf-bfd-vxlan-07.txt - draft-ietf-bfd-vxlan-08.txt.html>
>>> >
>>>
>>
>

--00000000000046aab9058c440056-- From nobody Fri Jun 28 13:01:08 2019 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E47120915; Fri, 28 Jun 2019 13:00:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rtg-bfd@ietf.org Subject: I-D Action: draft-ietf-bfd-unsolicited-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rtg-bfd@ietf.org Message-ID: <156175205953.21969.12553083879824402462@ietfa.amsl.com> Date: Fri, 28 Jun 2019 13:00:59 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 20:01:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bidirectional Forwarding Detection WG of the IETF. Title : Unsolicited BFD for Sessionless Applications Authors : Enke Chen Naiming Shen Robert Raszuk Reshad Rahman Filename : draft-ietf-bfd-unsolicited-01.txt Pages : 13 Date : 2019-06-28 Abstract: For operational simplification of "sessionless" applications using BFD, in this document we present procedures for "unsolicited BFD" that allow a BFD session to be initiated by only one side, and be established without explicit per-session configuration or registration by the other side (subject to certain per-interface or per-router policies). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bfd-unsolicited/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bfd-unsolicited-01 https://datatracker.ietf.org/doc/html/draft-ietf-bfd-unsolicited-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-unsolicited-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 28 13:07:44 2019 Return-Path: X-Original-To: rtg-bfd@ietfa.amsl.com Delivered-To: rtg-bfd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC792120904 for ; Fri, 28 Jun 2019 13:07:43 -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, 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=RF+OzkaI; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=qwRxMG7q 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 UdXCWUx5gMnT for ; Fri, 28 Jun 2019 13:07:42 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD1F912018F for ; Fri, 28 Jun 2019 13:07:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2838; q=dns/txt; s=iport; t=1561752461; x=1562962061; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=WvkeZgjQtVN3i4V/mrDZjfDGY2u5glS+1e0/UPnDAAE=; b=RF+OzkaIbxjlOIXBGVonRM83wOgGeGpnhRtVIdO9avmXVITz5GEUSXCm VfWiq1s1tiG/Kj4cBMmRXnPasNM7EWI7z2afj3cUw086yMEW9lX1LCvgu KEc5e//dwbAtPq4u29Ow/QnqIka8wKIJAmlxxTXfBefOCNKqW1BG3O/h+ U=; IronPort-PHdr: =?us-ascii?q?9a23=3A5gRiDxbiGffu/vRu6r7hpd3/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gebRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavwdSU6Gc1EfFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApAQA/cxZd/5FdJa1lHgEGBwaBVQc?= =?us-ascii?q?LAYFDUANqVSAECygKhBKDRwOOXUyBapdpgS6BJANUCQEBAQwBASMKAgEBhEA?= =?us-ascii?q?CF4JpIzYHDgEDAQEEAQECAQVtijcBC4VLAgEDEhEEDQwBATgPAgEIGgImAgI?= =?us-ascii?q?CMBUQAgQTIoMAAYFqAx0BDpwiAoE4iGBxfzOCeQEBBYE2Ag5BQIJDGIIRCYE?= =?us-ascii?q?MKItfF4FAP4E4DBOCTD6CYQEBAgEBFoFHF4JzMoImjmCNVY17CQKCFoZTjSY?= =?us-ascii?q?bgitshi6OHo0tgTCGCI9pAgQCBAUCDgEBBYFXBSyBWHAVGksBgkEJgjiDcYU?= =?us-ascii?q?UhT9ygSmNeQGBIAEB?= X-IronPort-AV: E=Sophos;i="5.63,428,1557187200"; d="scan'208";a="579765049" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Jun 2019 20:07:24 +0000 Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x5SK7NAZ030624 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 28 Jun 2019 20:07:24 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 28 Jun 2019 15:07:23 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 28 Jun 2019 15:07:23 -0500 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 28 Jun 2019 15:07:23 -0500 ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=fXhPQklDt/K3s3D1NuiAmc+Hlr671VrozdX6Y43+fYufv5GwaiPAL6Qr84IX4n/UR7Mo0IzzSJZD8iWvnst+AsGBy4f6lDcpZMoO+vH/W9yD61lMo/X2Qi/H9jgF4lh0bceUPf8ileU/VklSYZvZvDBElFb3VplWYyb6tORCrhA= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WvkeZgjQtVN3i4V/mrDZjfDGY2u5glS+1e0/UPnDAAE=; b=aPfE4wVRCE9Hhm7U8lAxCJTS40dIGm83Ky3mEetGiUFwdd9wsmZePcpuue418x9ozAEpS/E8q7q7BJoUSTRYK/A5h2ad+IYcRhSoyGF5sGzArbpTdJ1mZCxv4s46v5O+E9+Yg3hv4okRr95z+eqUHVgdbLzhl/21sJn/Jn5wmIU= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WvkeZgjQtVN3i4V/mrDZjfDGY2u5glS+1e0/UPnDAAE=; b=qwRxMG7qYYpWg+ymNo2YYAkZ20yDRrnsrn98DkfpNov7hSCXa8ABBjWMYWNOJ44yI/542rlUN7+Yjq5jGO8yv3AKNj0q+aczjftXmJBDjprrG9L5HFKChCMZ6Wj+AAtzaCJ4kxxEO03zE59H8wi7q//5bF0GH7IxrtgZQJVSNmI= Received: from DM5PR1101MB2105.namprd11.prod.outlook.com (10.174.104.151) by DM5PR1101MB2203.namprd11.prod.outlook.com (10.174.105.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Fri, 28 Jun 2019 20:07:22 +0000 Received: from DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::b57b:a39a:5e67:16c6]) by DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::b57b:a39a:5e67:16c6%2]) with mapi id 15.20.2008.014; Fri, 28 Jun 2019 20:07:22 +0000 From: "Reshad Rahman (rrahman)" To: "rtg-bfd@ietf.org" Subject: Re: I-D Action: draft-ietf-bfd-unsolicited-01.txt Thread-Topic: I-D Action: draft-ietf-bfd-unsolicited-01.txt Thread-Index: AQHVLexTwmtiNhvc40+nu8nxch7TjqaxO0cA Date: Fri, 28 Jun 2019 20:07:22 +0000 Message-ID: References: <156175205953.21969.12553083879824402462@ietfa.amsl.com> In-Reply-To: <156175205953.21969.12553083879824402462@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.6.190114 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; x-originating-ip: [173.38.117.74] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4bec6b28-701d-4aab-1112-08d6fc043b39 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR1101MB2203; x-ms-traffictypediagnostic: DM5PR1101MB2203: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 00826B6158 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(376002)(396003)(346002)(366004)(199004)(189003)(66476007)(478600001)(476003)(6916009)(2616005)(966005)(36756003)(58126008)(446003)(66446008)(64756008)(11346002)(316002)(5660300002)(14454004)(256004)(71200400001)(486006)(99286004)(66574012)(66066001)(68736007)(2906002)(71190400001)(14444005)(86362001)(81156014)(81166006)(7736002)(8936002)(6506007)(102836004)(76176011)(186003)(305945005)(66556008)(6116002)(3846002)(25786009)(8676002)(26005)(6512007)(6306002)(2351001)(66946007)(91956017)(76116006)(2501003)(53936002)(229853002)(73956011)(33656002)(6246003)(5640700003)(6486002)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1101MB2203; H:DM5PR1101MB2105.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: 14yOV0g55FzyedxeUd37c2VGsF317DkJv4vpyJRiJDQ0t0Obm6Sr+RgIjfA3L4FGb/k6Ee77Q7ck+WSknMYw7nD7guP5ZXP5sMY3J4FG8rS96EGv1olVYJ4X5seJMMlVdQuqRd9/3MFDFrrZQa9Rm6TfHYASkAc//9D+zXSzQLov6hdTSJtVoNjDYcdp8/ubdoRWjGYc1MPjDv/694X48YUAKyzxBt+D8VOzmZp9Kg0x9U7p3WJXY+KJe2R7+JoePHZAOFgmof+poBmGe+X/w0lHN5M4/9ynhbfGuiM+jw0Z3QKRgt0zvUXiVVLp8cPqjRNJlWdhRZDa+wyV6rFsmKOEoa4QeqZpF2pyTH8F2BX5j1uPTdhICnvaBb7657Sh+r1aa715XOLhT3X/fLtiuVJRkEtrGAngPYzZkld3P58= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4bec6b28-701d-4aab-1112-08d6fc043b39 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2019 20:07:22.1486 (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-CrossTenant-userprincipalname: rrahman@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2203 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.21, xch-aln-011.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 20:07:44 -0000 LSBZQU5HIHVwZGF0ZSBhbGxvdy0+ZW5hYmxlIHdoaWNoIHdhcyBkaXNjdXNzZWQgYXQgSUVURjEw NA0KLSBBZGRlZCA4MTc0IG9uIHRvcCBvZiAyMTE5DQotIEFkZGVkIFlBTkctcmVsYXRlZCBjb25z aWRlcmF0aW9ucyBpbiBTZWN1cml0eSBzZWN0aW9uLg0KDQpDb21tZW50cyB3ZWxjb21lLg0KDQpS ZWdhcmRzLA0KUmVzaGFkLg0KDQoNCu+7v09uIDIwMTktMDYtMjgsIDQ6MDEgUE0sICJSdGctYmZk IG9uIGJlaGFsZiBvZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciIDxydGctYmZkLWJvdW5jZXNA aWV0Zi5vcmcgb24gYmVoYWxmIG9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gd3JvdGU6DQoN CiAgICANCiAgICBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24t bGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQogICAgVGhpcyBkcmFmdCBpcyBhIHdv cmsgaXRlbSBvZiB0aGUgQmlkaXJlY3Rpb25hbCBGb3J3YXJkaW5nIERldGVjdGlvbiBXRyBvZiB0 aGUgSUVURi4NCiAgICANCiAgICAgICAgICAgIFRpdGxlICAgICAgICAgICA6IFVuc29saWNpdGVk IEJGRCBmb3IgU2Vzc2lvbmxlc3MgQXBwbGljYXRpb25zDQogICAgICAgICAgICBBdXRob3JzICAg ICAgICAgOiBFbmtlIENoZW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIE5haW1pbmcg U2hlbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9iZXJ0IFJhc3p1aw0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgUmVzaGFkIFJhaG1hbg0KICAgIAlGaWxlbmFtZSAgICAg ICAgOiBkcmFmdC1pZXRmLWJmZC11bnNvbGljaXRlZC0wMS50eHQNCiAgICAJUGFnZXMgICAgICAg ICAgIDogMTMNCiAgICAJRGF0ZSAgICAgICAgICAgIDogMjAxOS0wNi0yOA0KICAgIA0KICAgIEFi c3RyYWN0Og0KICAgICAgIEZvciBvcGVyYXRpb25hbCBzaW1wbGlmaWNhdGlvbiBvZiAic2Vzc2lv bmxlc3MiIGFwcGxpY2F0aW9ucyB1c2luZw0KICAgICAgIEJGRCwgaW4gdGhpcyBkb2N1bWVudCB3 ZSBwcmVzZW50IHByb2NlZHVyZXMgZm9yICJ1bnNvbGljaXRlZCBCRkQiDQogICAgICAgdGhhdCBh bGxvdyBhIEJGRCBzZXNzaW9uIHRvIGJlIGluaXRpYXRlZCBieSBvbmx5IG9uZSBzaWRlLCBhbmQg YmUNCiAgICAgICBlc3RhYmxpc2hlZCB3aXRob3V0IGV4cGxpY2l0IHBlci1zZXNzaW9uIGNvbmZp Z3VyYXRpb24gb3INCiAgICAgICByZWdpc3RyYXRpb24gYnkgdGhlIG90aGVyIHNpZGUgKHN1Ympl Y3QgdG8gY2VydGFpbiBwZXItaW50ZXJmYWNlIG9yDQogICAgICAgcGVyLXJvdXRlciBwb2xpY2ll cykuDQogICAgDQogICAgDQogICAgDQogICAgVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBh Z2UgZm9yIHRoaXMgZHJhZnQgaXM6DQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1iZmQtdW5zb2xpY2l0ZWQvDQogICAgDQogICAgVGhlcmUgYXJlIGFsc28g aHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Og0KICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWJmZC11bnNvbGljaXRlZC0wMQ0KICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1iZmQtdW5zb2xpY2l0ZWQtMDENCiAg ICANCiAgICBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6 DQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtYmZkLXVu c29saWNpdGVkLTAxDQogICAgDQogICAgDQogICAgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KICAgIHVu dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMu aWV0Zi5vcmcuDQogICAgDQogICAgSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBi eSBhbm9ueW1vdXMgRlRQIGF0Og0KICAgIGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvDQogICAgDQogICAgDQoNCg== From nobody Fri Jun 28 15:59:04 2019 Return-Path: X-Original-To: rtg-bfd@ietf.org Delivered-To: rtg-bfd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C46F0120937; Fri, 28 Jun 2019 15:57:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: rtg-bfd@ietf.org, martin.vigoureux@nokia.com Subject: bfd - Requested session has been scheduled for IETF 105 X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156176267079.11015.11323681474435575909.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2019 15:57:50 -0700 Archived-At: X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.29 List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 22:57:53 -0000 Dear Reshad Rahman, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. bfd Session 1 (1:00 requested) Tuesday, 23 July 2019, Afternoon Session III 1710-1810 Room Name: Sainte-Catherine size: 100 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/105/sessions/bfd.ics Request Information: --------------------------------------------------------- Working Group Name: Bidirectional Forwarding Detection Area Name: Routing Area Session Requester: Reshad Rahman Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 25 Conflicts to Avoid: First Priority: idr grow rtgwg bess lisp netmod netconf Second Priority: bier spring mpls teas pals sfc Third Priority: ccamp People who must be present: Jeffrey Haas Reshad Rahman Martin Vigoureux Resources Requested: Special Requests: ---------------------------------------------------------