From nobody Mon Feb 3 20:42:08 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C18981200FE for ; Mon, 3 Feb 2020 20:42:04 -0800 (PST) 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 pT8oo1XsdUC0 for ; Mon, 3 Feb 2020 20:42:02 -0800 (PST) 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 9AC9912004D for ; Mon, 3 Feb 2020 20:41:11 -0800 (PST) Received: by mail-lj1-x236.google.com with SMTP id o15so11491528ljg.6 for ; Mon, 03 Feb 2020 20:41:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=xPm0/AifASyCMXJoSNknLQhF/6+YoKz28s/Aum106zY=; b=UJ0xNQ6Crc7T75xhQ5tCqe4cggDI+aY5PW3AJoLsW7bBgX9+e3Rc41vpGxH97/SxX+ jWSipO6cQ6QaGD4svB/o6bETKONfJrctFOR4Pq3BBgxfROtNDt3htYDEZiOxCTQEsc84 ibrG7f3C8hBsRJH0iiRx/JIJyibGXiehwjBcqjFms7iRRWwsIJiJmNkTnMfd7MZgbV30 Ej+pnmmkp2AxGj6dVNYrzlKGRCFd11f8r+4Af3g012rn0Dklp+r35nwRQFrnMcRdwrvm xj+VdnS4VnZtjNhlOx+OvUqmNTNFtfqhg3wI7NNaUDui5Ok4JHjjNapJrGjIm38EIdjo fHwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xPm0/AifASyCMXJoSNknLQhF/6+YoKz28s/Aum106zY=; b=DHhPVekmcI4T3cSK1/ItyWK1rFCCjxjWJ6PufBYz2Z9sW+OFzXB+yD4lvgju4wf8Wq QG99GIkQ8yNqUGyYXdrNSWdBBgoXrn1TZKaxvkfRvnIRFptMg/0ZUjWA83wJYIb7BShj V+oURRfsrA/3FOC/lD+8JPZCtpDXo4JMWdWVbLbzq1uPqeOCEQq3lxIJhQlqVugm8KiL QIfdG6ATwg/U0OpZuwa9NzKpxL9cVFNdCGftesnpcOgowPc6TwK2BUHJU4IloX1lqEXo mCBgjFroof7gRwQ2ksyXkg5ort6XeZSxIhT+REkswhwDL3iqfdo1TYek8mENnqX0f8AQ KMzA== X-Gm-Message-State: APjAAAVkGWKBgN2kc0W+k+az6BirYZjT8h6ddh0q8hALaC5GcGzQVRG4 ExvUOus0MTcRXFzr4t3Zk8lb6JuWNsy3j0XT6O62g2rGhZH4a8Eu X-Google-Smtp-Source: APXvYqx6OoBnQGPirA9Wh033Y885DqOYuqGa2MexC9sUZKAu0XZzGAEpqLb/o7yWZTOfQqg2HgqdDY87Y1BIBZ+QrXM= X-Received: by 2002:a2e:b68c:: with SMTP id l12mr15499186ljo.36.1580791269437; Mon, 03 Feb 2020 20:41:09 -0800 (PST) MIME-Version: 1.0 From: Suneesh Date: Tue, 4 Feb 2020 10:10:57 +0530 Message-ID: To: bier@ietf.org Content-Type: multipart/alternative; boundary="0000000000001433cd059db8a6a1" Archived-At: Subject: [Bier] draft-ietf-bier-use-cases - Shepherd Review X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 04:42:05 -0000 --0000000000001433cd059db8a6a1 Content-Type: text/plain; charset="UTF-8" Hi All, Please find the below review comments from the shepherd Draft Version Reviewd: https://www.ietf.org/id/draft-ietf-bier-use-cases-10.txt General Comments: ================== - The document is well written and informative. - Editorial Review is done by Anoop Ghanwani on Version-08 and comments got addrssed in Version-09 - Some of the comments are yet to be addressed PE's vs PEs receivers vs receiver's - The draft is having a good number of acronyms, good to have 'Terminology' Section - Section 3.2. BUM in EVPN - Please expand VPLS - Please provide reference of VPLS rfc in Section-8 - Please expand PIM, mLDP - Section 3.3. IPTV and OTT Services Please expand MBGP - Section 3.6. Data Center Virtualization/Overlay Please expand NVE - Section 3.8. 4K Broadcast Video Services Please expand BGP - Section 3.9. Distributed Storage Cluster - Prefer to see the reference captured in Section-8 for NexentaEdge. (What is the best practice to capture company specific details?) - Bullet Point 4, is starting with ">", looks like typo? - may be we can have more clarity by having the various messages in single quotes eg: Chunk Put Accept -> 'Chunk Put Accept' Chunk Put Ack -> 'Chunk Put Ack' Chunk Get Request -> 'Chunk Get Request' etc. - Please expand MLD - Please capture MLD rfc details in Section-8 - Section 3.10. HTTP-Level Multicast: - Please provide reference to the following draft https://tools.ietf.org/html/draft-ietf-bier-multicast-http-response-02 - Prefer to see the reference captured in Section-8 for InterDigital - Please expand HTTP - Please capture HTTP rfc detaisl in Section-8 - Please expand FQDN ID nits comments: ================== Please address the following ID nits Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (August 4, 2019) is 183 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-bier-mvpn has been published as RFC 8556 -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Regards, Suneesh --0000000000001433cd059db8a6a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

Please find the below review co= mments from the shepherd

Draft Version Reviewd:=C2= =A0https://www.ietf.org/id/draft-ietf-bier-use-cases-10.txt=

General Comments:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

- The document is well written and informative.
- Edito= rial Review is done by Anoop Ghanwani <anoop@alumni.duke.edu> on Version-08 and c= omments got addrssed in Version-09
=C2=A0 =C2=A0- Some of the comments a= re yet to be addressed
=C2=A0 =C2=A0 PE's vs PEs
=C2=A0 =C2=A0 re= ceivers vs receiver's

- The draft is having a good number of acr= onyms, good to have 'Terminology' Section

- Section 3.2.=C2= =A0 BUM in EVPN
=C2=A0 - Please expand VPLS
=C2=A0 - Please provide r= eference of VPLS rfc in Section-8
=C2=A0 - Please expand PIM, mLDP
- Section 3.3.=C2=A0 IPTV and OTT Services
=C2=A0 Please expand MBGP
- Section 3.6.=C2=A0 Data Center Virtualization/Overlay
=C2=A0 Ple= ase expand NVE

- Section 3.8. =C2=A04K Broadcast Video Services
= =C2=A0 Please expand BGP

- Section 3.9.=C2=A0 Distributed Storage Cl= uster
=C2=A0 - Prefer to see the reference captured in Section-8 for Nex= entaEdge. (What is the best practice to capture company specific details?)<= br>=C2=A0 - Bullet Point 4, is starting with ">", looks like t= ypo?
=C2=A0 - may be we can have more clarity by having the various mess= ages in single quotes
=C2=A0 eg: Chunk Put Accept -> 'Chunk Put A= ccept'
=C2=A0 =C2=A0 =C2=A0Chunk Put Ack -> 'Chunk Put Ack= 9;
=C2=A0 =C2=A0 =C2=A0Chunk Get Request -> 'Chunk Get Request= 9; etc.
=C2=A0 - Please expand MLD
=C2=A0 - Please capture MLD rfc de= tails in Section-8


- Section 3.10.=C2=A0 HTTP-Level Multicast:
=C2=A0 - Please provide reference to the following draft
https://tools.ietf.org/html/draft-ietf-bier-multicast-ht= tp-response-02
=C2=A0 - Prefer to see the reference captured in Sect= ion-8 for InterDigital
=C2=A0 - Please expand HTTP
=C2=A0 - Please ca= pture HTTP rfc detaisl in Section-8
=C2=A0 - Please expand FQDN

<= br>
ID nits comments:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D

Please address the following ID nits

Miscellaneous = warnings:
=C2=A0 -------------------------------------------------------= ---------------------

=C2=A0 =3D=3D The copyright year in the IETF T= rust and authors Copyright Line does not
=C2=A0 =C2=A0 =C2=A0match the c= urrent year

=C2=A0 =3D=3D The document doesn't use any RFC 2119 = keywords, yet seems to have RFC
=C2=A0 =C2=A0 =C2=A02119 boilerplate tex= t.

=C2=A0 -- The document date (August 4, 2019) is 183 days in the p= ast.=C2=A0 Is this
=C2=A0 =C2=A0 =C2=A0intentional?


=C2=A0 Ch= ecking references for intended status: Informational
=C2=A0 ------------= ----------------------------------------------------------------

=C2= =A0 =3D=3D Outdated reference: draft-ietf-bier-mvpn has been published as R= FC 8556

=C2=A0 -- Obsolete informational reference (is this intentio= nal?): RFC 4601
=C2=A0 =C2=A0 =C2=A0(Obsoleted by RFC 7761)


= =C2=A0 =C2=A0 =C2=A0Summary: 0 errors (**), 0 flaws (~~), 3 warnings (=3D= =3D), 2 comments (--).


Regards,
= Suneesh
--0000000000001433cd059db8a6a1-- From nobody Tue Feb 4 09:35:16 2020 Return-Path: X-Original-To: bier@ietf.org Delivered-To: bier@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA31120152; Tue, 4 Feb 2020 09:35:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: bier@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: bier@ietf.org Message-ID: <158083771100.15781.6458179949194779114@ietfa.amsl.com> Date: Tue, 04 Feb 2020 09:35:11 -0800 Archived-At: Subject: [Bier] I-D Action: draft-ietf-bier-multicast-http-response-03.txt X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 17:35:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bit Indexed Explicit Replication WG of the IETF. Title : Applicability of BIER Multicast Overlay for Adaptive Streaming Services Authors : Dirk Trossen Akbar Rahman Chonggang Wang Toerless Eckert Filename : draft-ietf-bier-multicast-http-response-03.txt Pages : 17 Date : 2020-02-04 Abstract: HTTP Level multicast, using BIER, is described as a use case in the BIER Use Cases document. HTTP Level Multicast is used in today's video streaming and delivery services such as HLS, AR/VR etc., generally realized over IP Multicast as well as other use cases such as software update delivery. A realization of "HTTP Multicast" over "IP Multicast" is described for the video delivery use case. IP multicast is commonly used for IPTV services. DVB and BBF is also developing a reference architecture for IP Multicast service. A few problems with IP Multicast, such as waste of transmission bandwidth, increase in signaling when there are few users are described. Realization over BIER, through a BIER Multicast Overlay Layer, is described as an alternative. How BIER Multicast Overlay operation improves over IP Multicast, such as reduction in signaling, dynamic creation of multicast groups to reduce signaling and bandwidth wastage is described. We conclude with few next steps. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bier-multicast-http-response/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bier-multicast-http-response-03 https://datatracker.ietf.org/doc/html/draft-ietf-bier-multicast-http-response-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bier-multicast-http-response-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 6 06:47:33 2020 Return-Path: X-Original-To: bier@ietf.org Delivered-To: bier@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E1D12006D; Thu, 6 Feb 2020 06:47:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: bier@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: bier@ietf.org Message-ID: <158100044927.12441.7481502521530651351@ietfa.amsl.com> Date: Thu, 06 Feb 2020 06:47:29 -0800 Archived-At: Subject: [Bier] I-D Action: draft-ietf-bier-bier-yang-06.txt X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 14:47:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bit Indexed Explicit Replication WG of the IETF. Title : YANG Data Model for BIER Protocol Authors : Ran Chen Fangwei Hu Zheng Zhang Xianxian Dai Mahesh Sivakumar Filename : draft-ietf-bier-bier-yang-06.txt Pages : 17 Date : 2020-02-06 Abstract: This document defines a YANG data model for BIER configuration and operation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bier-bier-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bier-bier-yang-06 https://datatracker.ietf.org/doc/html/draft-ietf-bier-bier-yang-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bier-bier-yang-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 6 17:43:29 2020 Return-Path: X-Original-To: bier@ietf.org Delivered-To: bier@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3617E12001E; Thu, 6 Feb 2020 17:43:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: bier@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: bier@ietf.org Message-ID: <158103980711.16016.15113295387914159931@ietfa.amsl.com> Date: Thu, 06 Feb 2020 17:43:27 -0800 Archived-At: Subject: [Bier] I-D Action: draft-ietf-bier-te-yang-01.txt X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Feb 2020 01:43:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bit Indexed Explicit Replication WG of the IETF. Title : A YANG data model for Traffic Engineering for Bit Index Explicit Replication (BIER-TE) Authors : Zheng(Sandy) Zhang Cui(Linda) Wang Ran Chen Fangwei Hu Mahesh Sivakumar Huanan Chen Filename : draft-ietf-bier-te-yang-01.txt Pages : 17 Date : 2020-02-06 Abstract: This document defines a YANG data model for Traffic Engineering for Bit Index Explicit Replication (BIER-TE) configuration and operation. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bier-te-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bier-te-yang-01 https://datatracker.ietf.org/doc/html/draft-ietf-bier-te-yang-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bier-te-yang-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 Tue Feb 18 07:34:08 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676E11208BC for ; Tue, 18 Feb 2020 07:34:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 QjW0JdT-Ivot for ; Tue, 18 Feb 2020 07:34:04 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF761208DE for ; Tue, 18 Feb 2020 07:34:00 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 1D75F548015; Tue, 18 Feb 2020 16:33:55 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 0F4B6440040; Tue, 18 Feb 2020 16:33:55 +0100 (CET) Date: Tue, 18 Feb 2020 16:33:55 +0100 From: Toerless Eckert To: Dirk Trossen Cc: "bier@ietf.org" Message-ID: <20200218153355.GA57006@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [Bier] Dirk/*: Re: WGLC - draft-ietf-bier-te-arch (was: Re: Comments on draft-ietf-bier-te-arch-03) X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 15:34:07 -0000 Btw: Don't think i have seen a comment from you re. the actual WGLC for bier-te, to progress the document to IESG. Anybody else on the list of course equally encouraged to... ;-) Cheers Toerless On Tue, Oct 29, 2019 at 11:56:40AM +0000, Dirk Trossen wrote: > Yep, started the work based on work published in SIGCOMM2009, using BF in general. But we practically didn't implement them but used the bitposition simple version ???? The text below does make sense, thanks! > > Dirk > > -----Original Message----- > From: Toerless Eckert > Sent: 28 October 2019 17:25 > To: Dirk Trossen > Cc: bier@ietf.org > Subject: Re: [Bier] Comments on draft-ietf-bier-te-arch-03 > > On Wed, Oct 23, 2019 at 03:10:16PM +0000, Dirk Trossen wrote: > > > > [DOT] Note that the ICC paper talks about utilizing simple bitpositions to avoid false positive altogether - in fact, in our utilization of this solution, we've never used BF for that reason and stuck with the bitposition, aligning this solution pretty much with the BIER-TE one - which is one of the reasons for us to look at BIER(-TE) as another possible transport mechanism. So maybe adding a sentence like "Both approaches foresee the use of unique bitpositions per link to avoid said false positive and loop avoidance issues, bringing the approaches more in line with the proposed BIER-TE solution."? > > Haha. Now i see. So basically one uses one bloom filter 1 hash function > L(e) = (1< 2^e-max, and e voila, BIER-TE can be called a Bloom Filter solution, and thats what the ICC paper describes. > > So, how about this rewrite of the paragraph (for rev -05): > > Note that related work, uses bloom filters to represent leaves or edges of the intended delivery tree. Bloom filters in general can support larger trees/topologies with fewer addressing bits than explicit bitstrings, but they introduce the heuristic risk of false positives and cannot reset bits in the bitstring during forwarding to avoid loops. For these reasons, BIER-TE uses explicit bitstrings like BIER. The explicit bitstrings of BIER-TE can also be seen as a special type of bloom filter, and this is how related work describes it. > > > > > * Section 8 compares SR and BIER-TE, which I like seeing in the draft. I would argue that the possibility for creating opportunistic multicast relations (through a simple binary OR of unicast relations) is a significant advantage over SR. Here, a possible link to the 'HTTP multicast overlay' draft (see link above) might be useful, which makes use of this capability. > > > > Added at end of section: > > > > Both BIER and BIER-TE allow BFIR to "opportunistically" copy > > packets to a set of desired BFER on a packet-by-packet basis. In BIER, > > this is done by or'ing the BP for the desired BFER. In BIER-TE this > > can be done by or'ing for each desired BFER a bitstring using the > > "independent branches" approach described in > > and therefore also indicating the engineered path towards each desired > > BFER. This is the approach that > > relies on. > > > > [DOT] Could also add the multicast response draft here for completeness. > > Yepp. had already fixed that -> s/roll-ccast/multicast-http/ > > > > 3. Nitpicks: > > > * P4p1l1: "adjacencies" change to "adjacencies" > > > * P5p1l2: "6 BFR..." to "6 BFRs..." (with my working assumptions that an acronym is singular) > > > * P5p1l2: "All BFR..." change to "All BFRs..." > > > * P6p1l4: "...BFR1 to to send..." change to "...BFR1 to send..." > > > * P6p3l3: "...in the prior casse." change to "...in the prior case." > > > * P7p3l1: "...consists of the BIFT of all the the" change to "...consists of the BIFT of all the" > > > * P9p3l1: "During 'bring-up..." change to "During set-up..." or "During initial configuration..." > > > * P13p2l4: "The can be used" change to "They can be used" > > > * P13p6l1: "...to the BIER BIFT and are are" change to "...to the BIER BIFT and are" > > > * P17p2l6: "This Basic BIER-TE requirements make..." change to "These basic BIER-TE requirements make..." > > > * P21p1l3: "example is not mean as a likely setup" change to "example is not meant as a likely setup" > > > * P29p1l1: "which lead to" change to "which leads to" > > > * P30p6l1: "For non-leaf BFER, ..." change to "For a non-leaf BFER, ...." > > > * P30p7l1: "As explained earlier in the document, leaf BFER do..." change to "As explained earlier in the document, leaf BFERs do..." > > > > Thank you so much. > > > Thanks for the detailled review and recommendations. > > Cheers > Toerless > > > > > > > I hope this is useful. > > > > Very much so. > > > > Cheers > > Toerless > > > > > Best, > > > > > > Dirk > > > > > > -- > --- > tte@cs.fau.de > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier -- --- tte@cs.fau.de From nobody Tue Feb 18 07:39:16 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1C55120894 for ; Tue, 18 Feb 2020 07:39:08 -0800 (PST) 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, 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 Kivnab_gXmEB for ; Tue, 18 Feb 2020 07:39:05 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4F85120180 for ; Tue, 18 Feb 2020 07:39:05 -0800 (PST) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id EB1B6EB4E1E6B47E3245; Tue, 18 Feb 2020 15:39:02 +0000 (GMT) Received: from LHREML501-MBS.china.huawei.com ([10.201.109.50]) by LHREML713-CAH.china.huawei.com ([10.201.108.36]) with mapi id 14.03.0415.000; Tue, 18 Feb 2020 15:38:57 +0000 From: Dirk Trossen To: Toerless Eckert , Dirk Trossen CC: "bier@ietf.org" Thread-Topic: [Bier] Dirk/*: Re: WGLC - draft-ietf-bier-te-arch (was: Re: Comments on draft-ietf-bier-te-arch-03) Thread-Index: AQHV5nEORH8goA5gnUWvIUimkRTtP6ghFWlQ Date: Tue, 18 Feb 2020 15:38:57 +0000 Message-ID: <91BA3A406CA139458B56D8C52EAB227D1274C3@lhreml501-mbs> References: <20200218153355.GA57006@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200218153355.GA57006@faui48f.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.220.96.241] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Bier] Dirk/*: Re: WGLC - draft-ietf-bier-te-arch (was: Re: Comments on draft-ietf-bier-te-arch-03) X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 15:39:15 -0000 Toerless, all, Apologies, my organizational change temporarily disconnected me from that d= iscussion. From my side, this is a +1 regarding progress of the draft to ne= xt stage!=20 Best, Dirk -----Original Message----- From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Toerless Eckert Sent: 18 February 2020 16:34 To: Dirk Trossen Cc: bier@ietf.org Subject: [Bier] Dirk/*: Re: WGLC - draft-ietf-bier-te-arch (was: Re: Commen= ts on draft-ietf-bier-te-arch-03) Btw: Don't think i have seen a comment from you re. the actual WGLC for bie= r-te, to progress the document to IESG. Anybody else on the list of course equally encouraged to... ;-) Cheers Toerless On Tue, Oct 29, 2019 at 11:56:40AM +0000, Dirk Trossen wrote: > Yep, started the work based on work published in SIGCOMM2009, using BF in= general. But we practically didn't implement them but used the bitposition= simple version ???? The text below does make sense, thanks! >=20 > Dirk >=20 > -----Original Message----- > From: Toerless Eckert > Sent: 28 October 2019 17:25 > To: Dirk Trossen > Cc: bier@ietf.org > Subject: Re: [Bier] Comments on draft-ietf-bier-te-arch-03 >=20 > On Wed, Oct 23, 2019 at 03:10:16PM +0000, Dirk Trossen wrote: > >=20 > > [DOT] Note that the ICC paper talks about utilizing simple bitpositions= to avoid false positive altogether - in fact, in our utilization of this s= olution, we've never used BF for that reason and stuck with the bitposition= , aligning this solution pretty much with the BIER-TE one - which is one of= the reasons for us to look at BIER(-TE) as another possible transport mech= anism. So maybe adding a sentence like "Both approaches foresee the use of = unique bitpositions per link to avoid said false positive and loop avoidanc= e issues, bringing the approaches more in line with the proposed BIER-TE so= lution."? >=20 > Haha. Now i see. So basically one uses one bloom filter 1 hash=20 > function > L(e) =3D (1< 2^e-max, and e voila, BIE= R-TE can be called a Bloom Filter solution, and thats what the ICC paper de= scribes. >=20 > So, how about this rewrite of the paragraph (for rev -05): >=20 > Note that related work, uses=20 > bloom filters to represent leaves or edges of the intended delivery=20 > tree. Bloom filters in general can support larger trees/topologies=20 > with fewer addressing bits than explicit bitstrings, but they=20 > introduce the heuristic risk of false positives and cannot reset bits=20 > in the bitstring during forwarding to avoid loops. For these reasons,=20 > BIER-TE uses explicit bitstrings like BIER. The explicit bitstrings=20 > of BIER-TE can also be seen as a special type of bloom filter, and=20 > this is how related work describes it. >=20 >=20 > > > * Section 8 compares SR and BIER-TE, which I like seeing in th= e draft. I would argue that the possibility for creating opportunistic mult= icast relations (through a simple binary OR of unicast relations) is a sign= ificant advantage over SR. Here, a possible link to the 'HTTP multicast ove= rlay' draft (see link above) might be useful, which makes use of this capab= ility. > >=20 > > Added at end of section: > >=20 > > Both BIER and BIER-TE allow BFIR to "opportunistically" copy=20 > > packets to a set of desired BFER on a packet-by-packet basis. In=20 > > BIER, this is done by or'ing the BP for the desired BFER. In=20 > > BIER-TE this can be done by or'ing for each desired BFER a bitstring=20 > > using the "independent branches" approach described in > target=3D"bfr-id"/> and therefore also indicating the engineered path=20 > > towards each desired BFER. This is the approach that > target=3D"I-D.ietf-roll-ccast"/> relies on. > >=20 > > [DOT] Could also add the multicast response draft here for completeness= . >=20 > Yepp. had already fixed that -> s/roll-ccast/multicast-http/ >=20 > > > 3. Nitpicks: > > > * P4p1l1: "adjacencies" change to "adjacencies" > > > * P5p1l2: "6 BFR..." to "6 BFRs..." (with my working assumptio= ns that an acronym is singular) > > > * P5p1l2: "All BFR..." change to "All BFRs..." > > > * P6p1l4: "...BFR1 to to send..." change to "...BFR1 to send..= ." > > > * P6p3l3: "...in the prior casse." change to "...in the prior = case." > > > * P7p3l1: "...consists of the BIFT of all the the" change to "= ...consists of the BIFT of all the" > > > * P9p3l1: "During 'bring-up..." change to "During set-up..." o= r "During initial configuration..." > > > * P13p2l4: "The can be used" change to "They can be used" > > > * P13p6l1: "...to the BIER BIFT and are are" change to "...to = the BIER BIFT and are" > > > * P17p2l6: "This Basic BIER-TE requirements make..." change to= "These basic BIER-TE requirements make..." > > > * P21p1l3: "example is not mean as a likely setup" change to "= example is not meant as a likely setup" > > > * P29p1l1: "which lead to" change to "which leads to" > > > * P30p6l1: "For non-leaf BFER, ..." change to "For a non-leaf = BFER, ...." > > > * P30p7l1: "As explained earlier in the document, leaf BFER do= ..." change to "As explained earlier in the document, leaf BFERs do..." > >=20 > > Thank you so much. >=20 >=20 > Thanks for the detailled review and recommendations.=20 >=20 > Cheers > Toerless >=20 >=20 > >=20 > > > I hope this is useful. > >=20 > > Very much so. > >=20 > > Cheers > > Toerless > >=20 > > > Best, > > >=20 > > > Dirk > >=20 > >=20 >=20 > -- > --- > tte@cs.fau.de > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier -- --- tte@cs.fau.de _______________________________________________ BIER mailing list BIER@ietf.org https://www.ietf.org/mailman/listinfo/bier From nobody Tue Feb 18 12:07:29 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD1DB120813 for ; Tue, 18 Feb 2020 12:07:26 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=juniper.net header.b=cRBXmrgb; dkim=pass (1024-bit key) header.d=juniper.net header.b=gCQiV29X 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 wMbUodrjbUck for ; Tue, 18 Feb 2020 12:07:22 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 7CDD3120145 for ; Tue, 18 Feb 2020 12:07:21 -0800 (PST) Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 01IK0Txv024635; Tue, 18 Feb 2020 12:07:07 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=dlfDuQefoB4F6AzkQCRuXkUXfcID5gMztKlLZQU1RZ0=; b=cRBXmrgbsPGTx34HJUB3mBBlDS9/obAzmEmUeUfRrXFajSVneebFGC9yCA6EYRBx+QVw uvCjTgrXpUN/DqLoUlGLucfhqkKzwRivG8BKyWfRbrNO9qw7qA7jv0jttMDWZaSNd+Ix 2WkWLpwCWP94KrWhX9SY/SjV19sPfx+8kIpmqGluD59xCdpdLVHCit7jQdvmfiwgXtvn IYEuVmKvkOOevLIjRy7yWJ9u+CVprpt7JqKouVBByq3Uxmh67NaTtZ8IcQFMfnCpkhE4 lamMgiKT2W0g8gACzmS7/6qvuyCqtu79O6l4yab4kpzhWAYbZmijcbLK/gF9Hd3aVqM9 Qw== Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2106.outbound.protection.outlook.com [104.47.55.106]) by mx0a-00273201.pphosted.com with ESMTP id 2y86r21n0g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 Feb 2020 12:07:07 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m7NomNLT57ggd2i/f47+36znZhMV2A311wCQoU8IFvCF/0N+O+rmsloBaRPJvNjcYMcVEdQVUdwjSUkude+YwHog5/BjpacEmSBce9CtCFHLtCWNalNAHkMkmm00c1gJt6e6echmlQpN+z/inUkGYj/PnTMg2NNKsyPnlKtyOIKhKOfaJAt+Y9yNU5hB2Y7IDIyX0B8wbuHCUfbHr2OijP9IX94Vz3T6J1Rtkk+sSMGqGLZ34N97wU3k+AVyz41OcquhesftZQnN4DrLmSMbvV/48NnL4XNt76yDCmIrcmrzbChiVd1UzY4LWfWSBcac8Vz1jox6873Gx3V+fiCvQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dlfDuQefoB4F6AzkQCRuXkUXfcID5gMztKlLZQU1RZ0=; b=AcPuiyVn6qLBq8CI86SwMRQq78PmHeKNDwp5nNdI+tW7uA4OlqglVu0Np/W84mUdPlfwRJwmq1xUcLFhBZ4rv3k5efH355OOKoWMPpHzOJJIHbPh7Ai+x8RdK+DZjgeioE99byleYVK1XVLUEuwun/zS2rgG30kkcGFqmMWOZS+bveQF50+NJnMQDSmR+c+LHLhdBhb2glUbh9vJx6SSROmysSc3SQBvk/9dSZW3SxTx6Ot2a1u+P8J6kF2dM3s4He3PdEebekbzaDt4VmtkX7FwnNLCoCD5m4hRqtMDHwICFc2j7k4g4Kgx5qGf0jXWUvIdmxys9SseEDHIVkgrfA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dlfDuQefoB4F6AzkQCRuXkUXfcID5gMztKlLZQU1RZ0=; b=gCQiV29XqCxWodEUXebFwZg2evGOBbEeBjHzJAXJiNZPVPnz7C/tK9N5mEeHq+NZHFRbZjVV+BI3Df+560C2SvXHlU/x11W69m93hXWuLE9HNQfgN2qQOshgPrT+OtjE8VmTWPiVEfNvOLtqjLvaWuoPxlKRq5qTrqkXnaLDsWk= Received: from MN2PR05MB5981.namprd05.prod.outlook.com (20.178.240.207) by MN2PR05MB6927.namprd05.prod.outlook.com (52.135.37.74) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.14; Tue, 18 Feb 2020 20:07:05 +0000 Received: from MN2PR05MB5981.namprd05.prod.outlook.com ([fe80::18ab:3d92:bdf8:322d]) by MN2PR05MB5981.namprd05.prod.outlook.com ([fe80::18ab:3d92:bdf8:322d%7]) with mapi id 15.20.2750.016; Tue, 18 Feb 2020 20:07:05 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Toerless Eckert , "bier@ietf.org" Thread-Topic: [Bier] WGLC - draft-ietf-bier-te-arch Thread-Index: AdXmltqazVMKFHRdSsy5t+yost06gQ== Date: Tue, 18 Feb 2020 20:07:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.2.8 dlp-reaction: no-action x-originating-ip: [71.248.165.31] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: dd632c15-19ed-486b-ac52-08d7b4ae2001 x-ms-traffictypediagnostic: MN2PR05MB6927: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3276; x-forefront-prvs: 031763BCAF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(366004)(376002)(136003)(346002)(39860400002)(189003)(199004)(5660300002)(81166006)(81156014)(8676002)(86362001)(478600001)(186003)(26005)(966005)(8936002)(52536014)(316002)(66946007)(110136005)(66556008)(66446008)(66476007)(64756008)(55016002)(6506007)(71200400001)(30864003)(76116006)(33656002)(7696005)(66574012)(2906002)(9686003)(53546011)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR05MB6927; H:MN2PR05MB5981.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ifgVj7ah/P0KmtOhifLjPf7nZ4zNn3fuEMUPEmYupksaqGceGS+3xqb142kSqe5OSsyKL1Yo6zY/mJgsAjkSuW7KE0D37l+7fLtojC4k/BAVcPEJ1PpJVsp9kxaFNGLDHk7SqBEKLZOzqRtJFYWMdES1tWgwBLc8FRr+3NtZx4kUPPbP6rSc9nLeMw2PBKUgMyLNYFcALqTx0QHCfvg4l0SKI4bRYXW7+LGlXmlHJhx1Iq8cs20Q0GABOy/CmxgAL0fWzRGg/EaY6B9sFmx88/iX6p9RYYBpts23P7Z7bFaZS+nWCT0eMWOZ1qqZ8s85PFYGOa9oHU+T+9I0bufEKM62HnfgR+uOviIzyHTFOdug4Ma9/5NucYncs4q+617bL36ZvVxaA232r8bvAJxCmmeb3MoLiFRA0Z5wIJ8jvtaVWkA1o7rbsiwgeQj1WiEgp68pgSJPIewXidNzeg+N1k9QcL92IGD8c2eZBlufRtgd0lbJbN8i4RC8SxJmBx3r4Kxx919e5QT8UY0ePRSZ2g== x-ms-exchange-antispam-messagedata: Tiw4njcO92HCJ3QojeNvrsrgiNDRoTXAYqNN8l2LZ+dkTGdl9vCmhYCAH9m086NvYnfEIo6/x7GH7SW+lifOYJ8UjUGoUrphytuC14dIqEvgFojJ4QrsWdQiw53Gbc1z7OaBnfQf4DWoxrG89MeZCg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: dd632c15-19ed-486b-ac52-08d7b4ae2001 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2020 20:07:04.8905 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6T8VWkuWhhR3m6xsoL0tcciL+p1fuMNIZmY74dyi3vj8x3vQTyk99blZbLZ9DOPCwrvw8tB5iJEp+Max9Ng9qg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6927 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-18_06:2020-02-18, 2020-02-18 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 spamscore=0 phishscore=0 mlxlogscore=999 priorityscore=1501 impostorscore=0 suspectscore=0 clxscore=1011 adultscore=0 bulkscore=0 mlxscore=0 malwarescore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002180134 Archived-At: Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 20:07:27 -0000 Hi Toerless, Thanks! I support moving this to the next stage. Jeffrey On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote: > Thanks Jeff >=20 > I have now pushed out -05 with the answers and hopefully resolution to=20 > your points in email below. Biggest addition was a section about=20 > reuse of BPs (without DNR) which came out of the confusion i think the=20 > reuse in the ECMP example raised. I was afraid so far to explan that=20 > as it may not be easy to absorb and ultimately is stuff only=20 > controller developers need to understand, but hopefully useful. > And then of course the summary of BP optimizatins you asked for >=20 > Diff from last version i sent you: >=20 > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=3Dhttps: > **Araw.githubusercontent.com*toerless*bier-te-arch*master*draft-ietf-b > ier-te-arch-05.1.txt&url2=3Dhttp:**Atools.ietf.org*id*draft-ietf-bier-te > -arch-05.txt__;Ly8vLy8vLy8vLy8!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzH > OCr0fZkLPbgg3CPNu0PyrWsrFx41_jWX2At8V-$ >=20 > full -04 -> 05 diff: >=20 > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=3Dhttp:* > *Atools.ietf.org*id*draft-ietf-bier-te-arch-04.txt&url2=3Dhttp:**Atools. > ietf.org*id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk > !VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx41_jWancpziv$ >=20 > Comments inline below. >=20 > Cheers > toerless >=20 > On Mon, Oct 28, 2019 at 07:52:59PM +0000, Jeffrey (Zhaohui) Zhang wrote: > > I Thought u-turn is the most simple comparison leaf vs. non-leaf BFR. > >=20 > > Zzh> The text in the email is seriously misaligned. Looking at the pict= ure in the diff link, while you gave a U-turn example, though even if BFER2= is not connected to BFR2 but only connected to BFER1 (hence no U-turn), t= hen BFER1 is still not a leaf BFER I suppose. That's why I said the first s= entence of the above paragraph is enough to define Leaf BFER while the exam= ple itself is actually not needed. >=20 > Argh... ok, had to fix two words, BFIR->BFER and left-hand -> right-hand: >=20 > Consider how redundant disjoint traffic can reach BFER1/BFER2 in above=20 > picture: When BFER1/BFER2 are Non-Leaf BFER as shown on the right hand=20 > side, one traffic copy would be forwarded to BFER1 from BFR1, but the=20 > other one could only reach BFER1 via BFER2, which makes BFER2 a=20 > non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forwarding=20 > traffic to BFER2 >=20 > > Zzh> Additionally, in left part of the picture you added, if some failu= re leads to BFR2 to be only reachable via BFER1, then BFER1 is no longer a = leaf BFER.=20 >=20 > Added sentence: >=20 > Note that the BFER in the left hand picture are only guaranteed to=20 > be leaf-BFR by fitting routing configuration that prohibits transit=20 > traffic to pass through a PE, which is commonly applied in these=20 > topologies. >=20 > > I assume you don't reassign BPs when links go up and down. >=20 > I didn't want to discuss that option in this document. Its obviously=20 > perfectly feasible, but be yet a big amount of text (especially the=20 > considerations how to do this make-before-break. Future doc. >=20 > > > but subsequent polarization example confuses me. It seems that BP 0:6= is assigned to the routed adjacency BFR10 (which is actually talked about = in Section 4.8). > >=20 > > Section 4.7 does not mention "routed" at all, so there are no routed ad= jacencies at all used in 4.7. So i am not sure what you are confused about. > >=20 > > Zzh> "The BIFT of each BFR are only populated with BPs that are adjacen= t to the BFR in the BIER-TE topology". >=20 > Correct text from the introduction. Ok. >=20 > > Zzh> Since the same 0:6 is in BIFTS of BFR1/BFR2/BFR3 (and I suppose in= BFR4~BFR9 as well even though not drawn), I assumed it's for the "MP2P" ro= uted adjacency to R10; though I then ruled that out - but I don't know what= 0:6 represent now on BFR1, BFR2, and BFR3. >=20 > Ah. Ok. I thought i could strip down the example to show only the=20 > adjacencies relevant to the following discusion, but seemingly this=20 > can introduce the confusion you have. >=20 > So i completed the example with the BP assignment acoss all nodes, but=20 > added text pointing to a new section further down to discuss the=20 > re-use of BP for which thi picture is also an example. >=20 > (check out the diff, new reuse text to long to copy inline). >=20 > > The whole purpose of the ECMP BPs is of course to save bits, otherwise = we'd give each link a separate BP, which would be 6 BP to reach to BFR4...B= FR7 from BFR1.=20 > >=20 > > Zzh> The trouble I am having is that the same 0:6 is assigned to differ= ent things and it's present on all BFR1/BFR2/BFR3. It is perhaps an intenti= onal smart design but I have not wrapped my mind around it. It's apparently= different from the link bundle case, so better separate it out and elabora= te it (including the DNR flag that might be needed here - If the packet arr= ives on BFR1 with 0:6, would the BP reset when it is sent to BFR2/3)? >=20 > Yes, there was the bug of reusing BP 0:6 across sequential BFR along=20 > the path, but now the example correctly reuses separate BP at=20 > different stages of the paths (BP 0:6 on BFR1, BP 0:7 on BFR2/BFR3) and s= o on. >=20 > Thanks! >=20 > > > 4.8. Routed adjacencies > > >=20 > > > If I understand it correctly, there is a BP assigned to L1/L2/L3=20 > > > respectively (p2p link), and then there are BPs assigned to MP2P tunn= els (routed adjacency from every BFR) to the L1/L2/L3 interface addresses a= nd loopback addresses on BFR2/3. > >=20 > > Ok that wasn't quite the read i expected. Let me clarify the text/pictu= re: > >=20 > > ............... =20 > > ...BFR1--... ...--L1-- BFR2... > > ... .Routers. ...--L2--/ =20 > > ...BFR4--... ...------ BFR3... > > ............... | > > LO > > Network Area 1 > >=20 > > Assume the requirement in the above picture is to explicitly steer traf= fic flows that have arrived at BFR1 or BFR4 via a shortest path in the rout= ing underlay "network area 1" to one of the following three next segments: = (1) BFR2 via link L1, (2) BFR2 via link L2, (3) via BFR3. > >=20 > > To achieve this, both BFR1 and BFR4 are set up with a forward_routed ad= jacency BitPosition towards an address of BFR2 on link L1, another forward_= routed BitPosition towards an address of BFR2 on link L2 and a third forwar= d_routed Bitposition towards a node address LO of BFR3. > >=20 > > Does this clear ip the confusion ? > >=20 > > Zzh> The picture is badly misaligned. I'll wait till 4.7 questions are = cleared. >=20 > Ok. >=20 > > > If BFR2/3 are also BFERs, then they additionally will have BFER BPs. > > > On BFR1/4, the BIFT entries for the MP2P BPs for the L1/L2/L3/loopbac= k interface addresses of BFR2/3 will use forward_routed(interface/loopback = address). For a packet to be decapsulated on a BFER, there is a need for bo= th the BFER BP and another BP (p2p/lan/hub-spoke/routed-adjacency) in the p= acket (the former is for decapsulation and the latter is for getting it the= re). > >=20 > > This is not discussed in this section, but you are right - unless > > BFR2 or BFR3 is a leaf BFR. In that case, it would just leverage the on= e shared "leaf-BFR" BP, so they do not need a per-BFER BP for local_decap()= .=20 > >=20 > > Zzh> Right - shared leaf-BFR BP but still need that BP (the key is that= we need a BP to get packet to a BFER and then a BP for decapsulation). >=20 > You got it. >=20 > > > If that???s the case, it???s worth point the above out. > >=20 > > Hmm... The logic of BFER BPs is totally independent of the logic of for= ward_routed adjacency, so i would worry that repeating the explanation of B= FER BPs would conflate the forward_routed explanation. > >=20 > > Zzh> It's just that this is a place where all kinds of BPs are used so = it's good to have a summary (could be a subsection 4.9). >=20 > Yes, added such a summary. Pls. check. >=20 > > > Actually, the reason that I thought this is MP2P is that 0:6 is prese= nt on R1, R2, and R3 (and more I assume) in Figure 12, but now I think it c= an???t be MP2P (so it is not correct to have 0:6 present on those routers ?= ?? only the p2p tunnel head/tail should have the BP present in the BIFT). T= he reason is that if it were MP2P, any router getting a copy will send it t= o the endpoint of the routed adjacency, causing lots of duplicates. > > >=20 > > > Am I getting this correct? > >=20 > > I think you are still explaining from the misunderstsanding that the EC= MP explanations where about routed adjacencies. > >=20 > > I have now expanded the somewhat terse text in the BIFT table pictures,= to make it clear that the ECMP is across multipe forward_connected adjacen= cies in the examples. For example, first BIFT picture: > >=20 > > BIFT entry in BFR1: > > ------------------------------------------------------------------ > > | Index | Adjacencies | > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > | 0:6 | ECMP({forward_connected(L1, BFR2), | > > | | forward_connected(L2, BFR2), | > > | | forward_connected(L3, BFR2)}, seed) | > > ------------------------------------------------------------------ > >=20 > > Of course, an ECMP adjacency can be across any type of adjacencies, but= all the text/explanations used forward_connected, and now the pictures sho= w that explicitly. > >=20 > > Zzh> I can understand the multi-link case, but the multi-hop ECMP case = (from BFR1 towards BFR10) is confusing me. It would help to give an example= how it can be used, WITHOUT worrying about polarization. >=20 > Please check -05 text that has the full set of BIFT listed now: >=20 > There is really nothing nothing unique in multi-hop ECMP for BIER-TE=20 > that we do not also have in any other ECMP, except the conclusion that=20 > we want to support fast HW hash mechanisms AND allow the controller to=20 > set up non-polarized multi-hop ECMP AND be able to precalculate paths.=20 > Hence the specification of ECMP adjacencies to have a controller=20 > configurable seed. >=20 > Btw: The picture is maybe unnecessarily large because i've used it for=20 > 20 years to explain the same polarization issue for unicast vs=20 > multicast, and for multicast only BFR10...BFR4 are relevant (ECMP of=20 > the PIM/mLDP joins), whereas for unicast/BIER only > BFR1...BFR7 are relevant. But being symmetric, the picture makes it=20 > clear its the same problem. >=20 > > > To inhibit looping in the face of such physical misconfiguration, > > > only forward_connected adjacencies are permitted to have DNR set, = and > > > the link layer destination address of the adjacency (e.g. MAC > > > address) protects against closing the loop. Link layers without p= ort > > > unique link layer addresses should not be used with the DNR flag s= et. > > > > > > It???s not clear how link layer address helps? > >=20 > > I have expanded this to > > "link layer port unique unicast destination address" > >=20 > > Aka: MPLS or ethernet have unique link layer destination destination ad= dresses (label or destination MAC). If you think about incorrectly plugged = HDLC links (such as old T1/T3/... links), they only have 2 generic addresse= s, if i remember 1 or 3 in the HDLC frame. So when you misplug one of those= p2p cables wrong, the packets would be incrrectly received by the wrong re= ceiver node and then DNR could cause persistent loops only solved by TTL. > >=20 > > Zzh> "Consider in the ring picture that link L4 from BFR3 is plugged in= to the L1 interface of BFRa" - still not sure how label/mac helps here. I s= uppose the ring topology is discovered/verified by the control plane and wh= en the miscalling happens then the ring will not include the BFR1/BFR2 part= and BFR3 will not have the DNR set? If ring discovery/varication is not do= ne then perhaps we should point out that RPF based on link layer address is= needed - the key is RPF (which needs unique link layer address)? >=20 > Forget RPF. BIER(-TE) has no RPF (issues). Its just like unicast. RPF=20 > is just a problem for receiver originated joins like in PIM/mLDP, but=20 > not unicast/bier(-te)/RSVP-TE. >=20 > Forward_connected is just like a unicast subnet adjacency to a direct=20 > neighbor: Interface and L2 addresss of the destination. >=20 > The controller (could be a human) "assumes" a particular physicial=20 > topology, from telemetry/knowledge/whatever. It then calculates the=20 > desired BIER-TE topology and pushes it down. This topology is meant to=20 > be loop free of course wrt to the configured adjacencies. > In this BIER-TE topology, BFR3 will have a BP with the=20 > forward_connected(L4, MAC-of-BFR2) adjacency. >=20 > If the cable connecting to L4 is miswired, then BFR3 would still send=20 > the packets to the MAC address of BFR2, but given how the cable=20 > connects to some other node, these packets will be discarded by that=20 > node. because they're just L2 unicast packets. >=20 > I think this is equally true when we have normal BIER/MPLS enacp. > Those packets too are addressed to the unicast MAC address of the=20 > neighbor. >=20 > Now, if/when he controller recognizes that the physical topology has=20 > changed, thats a completely different story and not addressed here.=20 > Given how we assumed this was a cabling mistake, the controller would=20 > probably only complain about the miswiring to operations but be happy=20 > that the forwarding plane just makes packets fail instead of loop. If=20 > this was a planned change process, then it will be similarily=20 > convoluted as it would today be with rewiring cables in an=20 > SR-MPLS/SRv6 topology and updating SIDs. >=20 > > > Because the forwarding is different from BIER forwarding (because of = [1] above), we might as well introduce an optimization here ??? for each BI= FT, calculate the F-BM of the BIFT itself (the logical ???or??? of all the = BPs presented in this BIFT) and then use (packet->bitstring & BIFT.F-BM) as= the input to GetFirst/NextBitPosition(). That should skip many bits. > >=20 > > Right. But i explicitly removed those optimizations (i had them in olde= r draft versions) because the whole idea of this picture is solely the comp= arison with figure 4 of RFC8279. > >=20 > > Zzh> I think it's worth point that optimization out; you can mark it op= tional if you want to emphasize the similarity to BIER forwarding, but sinc= e BIER forwarding does do the maskoff step, it is very efficient while BIER= -TE forwarding does not it the maskoff step so this optimization is importa= nt. >=20 > Ok. I simplified the text comparison BIER/BIER-TE wrt. to the FBM=20 > rules [1] and [2] and added following paragraph: >=20 > In BIER, the order of BPs impacts the result of forwarding because of = [1].=20 > In BIER-TE, forwarding is not impacted by the order of BPs. It is=20 > therefore possible to further optimize forwarding than in BIER. For=20 > example parallelizing forwarding across multiple FPE cores or=20 > distributed linecards does only need to examine an arbitrary subset of=20 > BP and not evaluate the dependency between BPs. >=20 > > > The following pseudocode is comprehensive: > > >=20 > > > The above sentence reads a bit strange (or lacks some segue). > >=20 > > I hope not, but maybe best left to a native english speaker (RFC-editor= ). > >=20 > > The first (RFC8279) pseudocode was simplified. The second one is compre= hensive. If not comprehensive, whats a good opposite of simplified ? > >=20 > > Zzh> Perhaps "The above simplified pseudocode is elaborated further as = following"? > > Zzh> Jeffrey >=20 > Done. >=20 > Thanks a lot.=20 >=20 >=20 > > =20 > > > ________________________________________ > > > From: BIER [bier-bounces@ietf.org]=20 > > > on behalf of Toerless Eckert [tte@cs.fau.de] > > > Sent: Tuesday, July 09, 2019 23:38 > > > To: Mike McBride > > > Cc: Greg Shepherd; BIER WG; Pascal Thubert (pthubert) > > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch > > >=20 > > > Thanks, Mike > > >=20 > > > The authors also reviewed the document and concluded that it was=20 > > > really hard to get into the document context because of too many=20 > > > forward dependencies. We tried to fix this by adding two hopefully=20 > > > good & basic examples into the Introduction section and using them=20 > > > to also add a better definition of the term "BIER-TE Topology" in the= Introduction. > > > Hopefully this makes readin the rest of te document smoother. > > >=20 > > > Also improved text of Abstract and refined text compariing BIER-TE wi= th SR. > > >=20 > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=3Dhtt= ps: > > > **Atools.ietf.org*id*draft-ietf-bier-te-arch-02.txt&url2=3Dhttps:**A > > > tool > > > s.ietf.org*id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R > > > jC81=20 > > > c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV_eTUEh > > > $ > > > > > **Atools.ietf.org*id*draft-ietf-bier-te-arch-02.txt&url2=3Dhttps:**A > > > tool > > > s.ietf.org*id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R > > > jC81=20 > > > c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sNd1njcX > > > $> > > >=20 > > > Cheers > > > Toerless > > >=20 > > > On Wed, Jun 26, 2019 at 10:39:36AM -0700, Mike McBride wrote: > > > > How about three? I support. > > > > mike > > > > > > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd > wrote: > > > > > > > > > > We cannot take two 'yes' votes and WG consensus. > > > > > Please, read and respond. If you don't support, then please vote = as much publicly right here. > > > > > > > > > > Thanks, > > > > > Greg > > > > > > > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert (pthubert) > wrote: > > > > >> > > > > >> Support: > > > > >> > > > > >> I see great value in deterministic networks as well as IOT (with= RPL). > > > > >> > > > > >> All the best, > > > > >> > > > > >> Pascal > > > > >> > > > > >> > -----Original Message----- > > > > >> > From: BIER > > > > >> > > On=20 > > > > >> > Behalf Of Toerless Eckert > > > > >> > Sent: mardi 4 juin 2019 02:03 > > > > >> > To: Greg Shepherd=20 > > > > >> > > > > > > >> > Cc: BIER WG > > > > > >> > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch > > > > >> > > > > > >> > +1 > > > > >> > Obviously support as co-author. > > > > >> > > > > > >> > On Wed, May 29, 2019 at 12:41:26PM -0700, Greg Shepherd wrote: > > > > >> > > Please read and respond to this thread w/ or w/o support. > > > > >> > > > > > > >> > > https://urldefense.com/v3/__https://datatracker..ietf.org > > > > >> > > /doc=20 > > > > >> > > /draft-ietf-bier-te-arch/__;!8WoA6RjC81c!XvH4AAxfrDjFoK_s > > > > >> > > ercw ZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV9eClBj$ > > > > >> > > > > > >> > > doc/=20 > > > > >> > > draft-ietf-bier-te-arch/__;!8WoA6RjC81c!UBTGvWWpMHyeiSanx > > > > >> > > s6vI b_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sD40kmtH$> > > > > >> > > > > > > >> > > Vote ends 5 June 2019. > > > > >> > > > > > > >> > > Thanks, > > > > >> > > Shep > > > > >> > > (chairs) > > > > >> > > > > > >> > > _______________________________________________ > > > > >> > > BIER mailing list > > > > >> > > BIER@ietf.org > > > > >> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/ > > > > >> > > list > > > > >> > > info/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eE > > > > >> > > NOs4 l_qdsXF0KwZD82cJLDFFNT2WVXWX$=20 > > > > >> > > > > > >> > > list=20 > > > > >> > > info/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6b > > > > >> > > oAAW 4nrqju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > >> > > > > > >> > _______________________________________________ > > > > >> > BIER mailing list > > > > >> > BIER@ietf.org > > > > >> > https://urldefense.com/v3/__https://www.ietf.org/mailman/li > > > > >> > stin=20 > > > > >> > fo/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4 > > > > >> > l_qd > > > > >> > sXF0KwZD82cJLDFFNT2WVXWX$ > > > > >> > > > > >> > stin=20 > > > > >> > fo/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW > > > > >> > 4nrq > > > > >> > ju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > > > > > > > _______________________________________________ > > > > > BIER mailing list > > > > > BIER@ietf.org > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listi > > > > > nfo/=20 > > > > > bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsX > > > > > F0Kw > > > > > ZD82cJLDFFNT2WVXWX$ > > > > > > > > > nfo/=20 > > > > > bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju > > > > > 8UCL > > > > > OgiuXc8Y_6sKn2KoAT$> > > >=20 > > > -- > > > --- > > > tte@cs.fau.de > > >=20 > > > _______________________________________________ > > > BIER mailing list > > > BIER@ietf.org > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ > > > bier=20 > > > __;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82 > > > cJLD > > > FFNT2WVXWX$ > > > > > bier=20 > > > __;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiu > > > Xc8Y > > > _6sKn2KoAT$> > >=20 > > -- > > --- > > tte@cs.fau.de >=20 > -- > --- > tte@cs.fau.de >=20 > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier > __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx4 > 1_jWV3YUA6D$ -- --- tte@cs.fau.de From nobody Tue Feb 18 12:46:14 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDAE612081A for ; Tue, 18 Feb 2020 12:46:11 -0800 (PST) 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 KmKC0P4jNNIA for ; Tue, 18 Feb 2020 12:46:06 -0800 (PST) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 79740120145 for ; Tue, 18 Feb 2020 12:46:06 -0800 (PST) Received: by mail-qk1-x735.google.com with SMTP id o28so19592497qkj.9 for ; Tue, 18 Feb 2020 12:46:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=lOppAFf3t/ACfftsPktwn3K94wc/26IUl+7YyGm0AOQ=; b=orSEgVM5/v1A2KlzeGy0g0uvrg5i6fPC0tzwvPQ61O0iinDXidjV9wAQPpGNlSH6Vf RuUMYyGEd4p53ouH1prl/Z6pP2zwKg5AY1KAKh385ZRDCMQZ6AMVR911nWW2Kii6DTkg Vxywz2MC8qtDiIgiWuFyAOSqCiqXJNATRvlWMb54dpr0G3kz6p8ep7ut0sgSlcAlgo9H WPz+Sq+9uzBzUn5mX/bU2oGcmrz62LQzXsc0OiI+wALJ3vIcozo31IGBxvWgyZ2JoWI3 Dvt8vClPcY0dImmsoLHbI/v58gQMZ3ogJ1NliLPtAKrN6EhRw/3SSyQzs6NEsjtNu72C qfRA== 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:reply-to :from:date:message-id:subject:to:cc; bh=lOppAFf3t/ACfftsPktwn3K94wc/26IUl+7YyGm0AOQ=; b=HjkXEpcXn4Ri5zaaALGSzHuvScwIlel2bPnXjiUUYJ1pams+jFlWqOQHD36WnhQmf2 kbkTuL5BFKiQy4ufI3HGSqwYNf3xE1kRQCZjQiTch2oCrvsc0CxB+4lvIG2DyL8u0LOQ RePf2aNygDsM4W8yVonRCfIZglNfCH//V8zFjePNudnMnOBJoWqfep9ZP6K5yHwqsWSn oXq5rFy+bCBnW4th9sF5lK0Fl208pwUwZrBlUBKKcNaEL94Hca1t/gK9QgpfLJPaCkS8 gC87di5Irq2Y1W0AdSGBppVBOPJVzLk7726tuYTIySQZCewy5mx/JQI8G9vQltrImFZK bnwg== X-Gm-Message-State: APjAAAWVEgYs/oSTOUSxXxB73+dPHuQ9o56QfNcE9EM6xyHvp97abf+I KPC0ejAaTQYdhSRvGpUhLE/9VFcAhEKH7jgnCV9Xd/wl X-Google-Smtp-Source: APXvYqyJ9VmO0SjP9VaJ5T9TDdlxwP3Hztg9LBpAcN8xUUrknbzjfYXKFJ1W6ANa+4OilPo+Do/IRYqh6dNPv3NUVqE= X-Received: by 2002:a37:b744:: with SMTP id h65mr21298681qkf.85.1582058765394; Tue, 18 Feb 2020 12:46:05 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Reply-To: gjshep@gmail.com From: Greg Shepherd Date: Tue, 18 Feb 2020 12:45:54 -0800 Message-ID: To: "Jeffrey (Zhaohui) Zhang" Cc: Toerless Eckert , "bier@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b9a8ab059edfc2e9" Archived-At: Subject: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 20:46:12 -0000 --000000000000b9a8ab059edfc2e9 Content-Type: text/plain; charset="UTF-8" Thanks Toerless and Jeffrey https://datatracker.ietf.org/doc/draft-ietf-bier-te-arch/ One more week of WGLC. Please read the latest rev and respond to this thread w/wo support. Chairs (Shep) On Tue, Feb 18, 2020 at 12:07 PM Jeffrey (Zhaohui) Zhang wrote: > Hi Toerless, > > Thanks! > I support moving this to the next stage. > > Jeffrey > > On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote: > > Thanks Jeff > > > > I have now pushed out -05 with the answers and hopefully resolution to > > your points in email below. Biggest addition was a section about > > reuse of BPs (without DNR) which came out of the confusion i think the > > reuse in the ECMP example raised. I was afraid so far to explan that > > as it may not be easy to absorb and ultimately is stuff only > > controller developers need to understand, but hopefully useful. > > And then of course the summary of BP optimizatins you asked for > > > > Diff from last version i sent you: > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: > > **Araw.githubusercontent.com*toerless*bier-te-arch*master*draft-ietf-b > > ier-te-arch-05.1.txt&url2=http:**Atools.ietf.org*id*draft-ietf-bier-te > > -arch-05.txt__;Ly8vLy8vLy8vLy8!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzH > > OCr0fZkLPbgg3CPNu0PyrWsrFx41_jWX2At8V-$ > > > > full -04 -> 05 diff: > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=http:* > > *Atools.ietf.org*id*draft-ietf-bier-te-arch-04.txt&url2=http:**Atools. > > ietf.org*id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk > > !VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx41_jWancpziv$ > > > > Comments inline below. > > > > Cheers > > toerless > > > > On Mon, Oct 28, 2019 at 07:52:59PM +0000, Jeffrey (Zhaohui) Zhang wrote: > > > I Thought u-turn is the most simple comparison leaf vs. non-leaf BFR. > > > > > > Zzh> The text in the email is seriously misaligned. Looking at the > picture in the diff link, while you gave a U-turn example, though even if > BFER2 is not connected to BFR2 but only connected to BFER1 (hence no > U-turn), then BFER1 is still not a leaf BFER I suppose. That's why I said > the first sentence of the above paragraph is enough to define Leaf BFER > while the example itself is actually not needed. > > > > Argh... ok, had to fix two words, BFIR->BFER and left-hand -> right-hand: > > > > Consider how redundant disjoint traffic can reach BFER1/BFER2 in above > > picture: When BFER1/BFER2 are Non-Leaf BFER as shown on the right hand > > side, one traffic copy would be forwarded to BFER1 from BFR1, but the > > other one could only reach BFER1 via BFER2, which makes BFER2 a > > non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forwarding > > traffic to BFER2 > > > > > Zzh> Additionally, in left part of the picture you added, if some > failure leads to BFR2 to be only reachable via BFER1, then BFER1 is no > longer a leaf BFER. > > > > Added sentence: > > > > Note that the BFER in the left hand picture are only guaranteed to > > be leaf-BFR by fitting routing configuration that prohibits transit > > traffic to pass through a PE, which is commonly applied in these > > topologies. > > > > > I assume you don't reassign BPs when links go up and down. > > > > I didn't want to discuss that option in this document. Its obviously > > perfectly feasible, but be yet a big amount of text (especially the > > considerations how to do this make-before-break. Future doc. > > > > > > but subsequent polarization example confuses me. It seems that BP > 0:6 is assigned to the routed adjacency BFR10 (which is actually talked > about in Section 4.8). > > > > > > Section 4.7 does not mention "routed" at all, so there are no routed > adjacencies at all used in 4.7. So i am not sure what you are confused > about. > > > > > > Zzh> "The BIFT of each BFR are only populated with BPs that are > adjacent to the BFR in the BIER-TE topology". > > > > Correct text from the introduction. Ok. > > > > > Zzh> Since the same 0:6 is in BIFTS of BFR1/BFR2/BFR3 (and I suppose > in BFR4~BFR9 as well even though not drawn), I assumed it's for the "MP2P" > routed adjacency to R10; though I then ruled that out - but I don't know > what 0:6 represent now on BFR1, BFR2, and BFR3. > > > > Ah. Ok. I thought i could strip down the example to show only the > > adjacencies relevant to the following discusion, but seemingly this > > can introduce the confusion you have. > > > > So i completed the example with the BP assignment acoss all nodes, but > > added text pointing to a new section further down to discuss the > > re-use of BP for which thi picture is also an example. > > > > (check out the diff, new reuse text to long to copy inline). > > > > > The whole purpose of the ECMP BPs is of course to save bits, otherwise > we'd give each link a separate BP, which would be 6 BP to reach to > BFR4...BFR7 from BFR1. > > > > > > Zzh> The trouble I am having is that the same 0:6 is assigned to > different things and it's present on all BFR1/BFR2/BFR3. It is perhaps an > intentional smart design but I have not wrapped my mind around it. It's > apparently different from the link bundle case, so better separate it out > and elaborate it (including the DNR flag that might be needed here - If the > packet arrives on BFR1 with 0:6, would the BP reset when it is sent to > BFR2/3)? > > > > Yes, there was the bug of reusing BP 0:6 across sequential BFR along > > the path, but now the example correctly reuses separate BP at > > different stages of the paths (BP 0:6 on BFR1, BP 0:7 on BFR2/BFR3) and > so on. > > > > Thanks! > > > > > > 4.8. Routed adjacencies > > > > > > > > If I understand it correctly, there is a BP assigned to L1/L2/L3 > > > > respectively (p2p link), and then there are BPs assigned to MP2P > tunnels (routed adjacency from every BFR) to the L1/L2/L3 interface > addresses and loopback addresses on BFR2/3. > > > > > > Ok that wasn't quite the read i expected. Let me clarify the > text/picture: > > > > > > ............... > > > ...BFR1--... ...--L1-- BFR2... > > > ... .Routers. ...--L2--/ > > > ...BFR4--... ...------ BFR3... > > > ............... | > > > LO > > > Network Area 1 > > > > > > Assume the requirement in the above picture is to explicitly steer > traffic flows that have arrived at BFR1 or BFR4 via a shortest path in the > routing underlay "network area 1" to one of the following three next > segments: (1) BFR2 via link L1, (2) BFR2 via link L2, (3) via BFR3. > > > > > > To achieve this, both BFR1 and BFR4 are set up with a forward_routed > adjacency BitPosition towards an address of BFR2 on link L1, another > forward_routed BitPosition towards an address of BFR2 on link L2 and a > third forward_routed Bitposition towards a node address LO of BFR3. > > > > > > Does this clear ip the confusion ? > > > > > > Zzh> The picture is badly misaligned. I'll wait till 4.7 questions are > cleared. > > > > Ok. > > > > > > If BFR2/3 are also BFERs, then they additionally will have BFER BPs. > > > > On BFR1/4, the BIFT entries for the MP2P BPs for the > L1/L2/L3/loopback interface addresses of BFR2/3 will use > forward_routed(interface/loopback address). For a packet to be decapsulated > on a BFER, there is a need for both the BFER BP and another BP > (p2p/lan/hub-spoke/routed-adjacency) in the packet (the former is for > decapsulation and the latter is for getting it there). > > > > > > This is not discussed in this section, but you are right - unless > > > BFR2 or BFR3 is a leaf BFR. In that case, it would just leverage the > one shared "leaf-BFR" BP, so they do not need a per-BFER BP for > local_decap(). > > > > > > Zzh> Right - shared leaf-BFR BP but still need that BP (the key is > that we need a BP to get packet to a BFER and then a BP for decapsulation). > > > > You got it. > > > > > > If that???s the case, it???s worth point the above out. > > > > > > Hmm... The logic of BFER BPs is totally independent of the logic of > forward_routed adjacency, so i would worry that repeating the explanation > of BFER BPs would conflate the forward_routed explanation. > > > > > > Zzh> It's just that this is a place where all kinds of BPs are used so > it's good to have a summary (could be a subsection 4.9). > > > > Yes, added such a summary. Pls. check. > > > > > > Actually, the reason that I thought this is MP2P is that 0:6 is > present on R1, R2, and R3 (and more I assume) in Figure 12, but now I think > it can???t be MP2P (so it is not correct to have 0:6 present on those > routers ??? only the p2p tunnel head/tail should have the BP present in the > BIFT). The reason is that if it were MP2P, any router getting a copy will > send it to the endpoint of the routed adjacency, causing lots of duplicates. > > > > > > > > Am I getting this correct? > > > > > > I think you are still explaining from the misunderstsanding that the > ECMP explanations where about routed adjacencies. > > > > > > I have now expanded the somewhat terse text in the BIFT table > pictures, to make it clear that the ECMP is across multipe > forward_connected adjacencies in the examples. For example, first BIFT > picture: > > > > > > BIFT entry in BFR1: > > > ------------------------------------------------------------------ > > > | Index | Adjacencies | > > > ================================================================== > > > | 0:6 | ECMP({forward_connected(L1, BFR2), | > > > | | forward_connected(L2, BFR2), | > > > | | forward_connected(L3, BFR2)}, seed) | > > > ------------------------------------------------------------------ > > > > > > Of course, an ECMP adjacency can be across any type of adjacencies, > but all the text/explanations used forward_connected, and now the pictures > show that explicitly. > > > > > > Zzh> I can understand the multi-link case, but the multi-hop ECMP case > (from BFR1 towards BFR10) is confusing me. It would help to give an example > how it can be used, WITHOUT worrying about polarization. > > > > Please check -05 text that has the full set of BIFT listed now: > > > > There is really nothing nothing unique in multi-hop ECMP for BIER-TE > > that we do not also have in any other ECMP, except the conclusion that > > we want to support fast HW hash mechanisms AND allow the controller to > > set up non-polarized multi-hop ECMP AND be able to precalculate paths. > > Hence the specification of ECMP adjacencies to have a controller > > configurable seed. > > > > Btw: The picture is maybe unnecessarily large because i've used it for > > 20 years to explain the same polarization issue for unicast vs > > multicast, and for multicast only BFR10...BFR4 are relevant (ECMP of > > the PIM/mLDP joins), whereas for unicast/BIER only > > BFR1...BFR7 are relevant. But being symmetric, the picture makes it > > clear its the same problem. > > > > > > To inhibit looping in the face of such physical misconfiguration, > > > > only forward_connected adjacencies are permitted to have DNR set, > and > > > > the link layer destination address of the adjacency (e.g. MAC > > > > address) protects against closing the loop. Link layers without > port > > > > unique link layer addresses should not be used with the DNR flag > set. > > > > > > > > It???s not clear how link layer address helps? > > > > > > I have expanded this to > > > "link layer port unique unicast destination address" > > > > > > Aka: MPLS or ethernet have unique link layer destination destination > addresses (label or destination MAC). If you think about incorrectly > plugged HDLC links (such as old T1/T3/... links), they only have 2 generic > addresses, if i remember 1 or 3 in the HDLC frame. So when you misplug one > of those p2p cables wrong, the packets would be incrrectly received by the > wrong receiver node and then DNR could cause persistent loops only solved > by TTL. > > > > > > Zzh> "Consider in the ring picture that link L4 from BFR3 is plugged > into the L1 interface of BFRa" - still not sure how label/mac helps here. I > suppose the ring topology is discovered/verified by the control plane and > when the miscalling happens then the ring will not include the BFR1/BFR2 > part and BFR3 will not have the DNR set? If ring discovery/varication is > not done then perhaps we should point out that RPF based on link layer > address is needed - the key is RPF (which needs unique link layer address)? > > > > Forget RPF. BIER(-TE) has no RPF (issues). Its just like unicast. RPF > > is just a problem for receiver originated joins like in PIM/mLDP, but > > not unicast/bier(-te)/RSVP-TE. > > > > Forward_connected is just like a unicast subnet adjacency to a direct > > neighbor: Interface and L2 addresss of the destination. > > > > The controller (could be a human) "assumes" a particular physicial > > topology, from telemetry/knowledge/whatever. It then calculates the > > desired BIER-TE topology and pushes it down. This topology is meant to > > be loop free of course wrt to the configured adjacencies. > > In this BIER-TE topology, BFR3 will have a BP with the > > forward_connected(L4, MAC-of-BFR2) adjacency. > > > > If the cable connecting to L4 is miswired, then BFR3 would still send > > the packets to the MAC address of BFR2, but given how the cable > > connects to some other node, these packets will be discarded by that > > node. because they're just L2 unicast packets. > > > > I think this is equally true when we have normal BIER/MPLS enacp. > > Those packets too are addressed to the unicast MAC address of the > > neighbor. > > > > Now, if/when he controller recognizes that the physical topology has > > changed, thats a completely different story and not addressed here. > > Given how we assumed this was a cabling mistake, the controller would > > probably only complain about the miswiring to operations but be happy > > that the forwarding plane just makes packets fail instead of loop. If > > this was a planned change process, then it will be similarily > > convoluted as it would today be with rewiring cables in an > > SR-MPLS/SRv6 topology and updating SIDs. > > > > > > Because the forwarding is different from BIER forwarding (because of > [1] above), we might as well introduce an optimization here ??? for each > BIFT, calculate the F-BM of the BIFT itself (the logical ???or??? of all > the BPs presented in this BIFT) and then use (packet->bitstring & > BIFT.F-BM) as the input to GetFirst/NextBitPosition(). That should skip > many bits. > > > > > > Right. But i explicitly removed those optimizations (i had them in > older draft versions) because the whole idea of this picture is solely the > comparison with figure 4 of RFC8279. > > > > > > Zzh> I think it's worth point that optimization out; you can mark it > optional if you want to emphasize the similarity to BIER forwarding, but > since BIER forwarding does do the maskoff step, it is very efficient while > BIER-TE forwarding does not it the maskoff step so this optimization is > important. > > > > Ok. I simplified the text comparison BIER/BIER-TE wrt. to the FBM > > rules [1] and [2] and added following paragraph: > > > > In BIER, the order of BPs impacts the result of forwarding because of > [1]. > > In BIER-TE, forwarding is not impacted by the order of BPs. It is > > therefore possible to further optimize forwarding than in BIER. For > > example parallelizing forwarding across multiple FPE cores or > > distributed linecards does only need to examine an arbitrary subset of > > BP and not evaluate the dependency between BPs. > > > > > > The following pseudocode is comprehensive: > > > > > > > > The above sentence reads a bit strange (or lacks some segue). > > > > > > I hope not, but maybe best left to a native english speaker > (RFC-editor). > > > > > > The first (RFC8279) pseudocode was simplified. The second one is > comprehensive. If not comprehensive, whats a good opposite of simplified ? > > > > > > Zzh> Perhaps "The above simplified pseudocode is elaborated further as > following"? > > > Zzh> Jeffrey > > > > Done. > > > > Thanks a lot. > > > > > > > > > > > ________________________________________ > > > > From: BIER [bier-bounces@ietf.org] > > > > on behalf of Toerless Eckert [tte@cs.fau.de] > > > > Sent: Tuesday, July 09, 2019 23:38 > > > > To: Mike McBride > > > > Cc: Greg Shepherd; BIER WG; Pascal Thubert (pthubert) > > > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch > > > > > > > > Thanks, Mike > > > > > > > > The authors also reviewed the document and concluded that it was > > > > really hard to get into the document context because of too many > > > > forward dependencies. We tried to fix this by adding two hopefully > > > > good & basic examples into the Introduction section and using them > > > > to also add a better definition of the term "BIER-TE Topology" in > the Introduction. > > > > Hopefully this makes readin the rest of te document smoother. > > > > > > > > Also improved text of Abstract and refined text compariing BIER-TE > with SR. > > > > > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: > > > > **Atools.ietf.org*id*draft-ietf-bier-te-arch-02.txt&url2=https:**A > > > > tool > > > > s.ietf.org*id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R > > > > jC81 > > > > c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV_eTUEh > > > > $ > > > > < > https://urldefense.com/v3/__http:/tools.ietf.org/*rfcdiff?url1=https: > > > > **Atools.ietf.org*id*draft-ietf-bier-te-arch-02.txt&url2=https:**A > > > > tool > > > > s.ietf.org*id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R > > > > jC81 > > > > c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sNd1njcX > > > > $> > > > > > > > > Cheers > > > > Toerless > > > > > > > > On Wed, Jun 26, 2019 at 10:39:36AM -0700, Mike McBride wrote: > > > > > How about three? I support. > > > > > mike > > > > > > > > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd > wrote: > > > > > > > > > > > > We cannot take two 'yes' votes and WG consensus. > > > > > > Please, read and respond. If you don't support, then please vote > as much publicly right here. > > > > > > > > > > > > Thanks, > > > > > > Greg > > > > > > > > > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert (pthubert) < > pthubert@cisco.com> wrote: > > > > > >> > > > > > >> Support: > > > > > >> > > > > > >> I see great value in deterministic networks as well as IOT > (with RPL). > > > > > >> > > > > > >> All the best, > > > > > >> > > > > > >> Pascal > > > > > >> > > > > > >> > -----Original Message----- > > > > > >> > From: BIER > > > > > >> > > On > > > > > >> > Behalf Of Toerless Eckert > > > > > >> > Sent: mardi 4 juin 2019 02:03 > > > > > >> > To: Greg Shepherd > > > > > >> > > > > > > > >> > Cc: BIER WG > > > > > > >> > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch > > > > > >> > > > > > > >> > +1 > > > > > >> > Obviously support as co-author. > > > > > >> > > > > > > >> > On Wed, May 29, 2019 at 12:41:26PM -0700, Greg Shepherd wrote: > > > > > >> > > Please read and respond to this thread w/ or w/o support. > > > > > >> > > > > > > > >> > > https://urldefense.com/v3/__https://datatracker..ietf.org > > > > > >> > > /doc > > > > > >> > > /draft-ietf-bier-te-arch/__;!8WoA6RjC81c!XvH4AAxfrDjFoK_s > > > > > >> > > ercw ZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV9eClBj$ > > > > > >> > > > > > > >> > > doc/ > > > > > >> > > draft-ietf-bier-te-arch/__;!8WoA6RjC81c!UBTGvWWpMHyeiSanx > > > > > >> > > s6vI b_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sD40kmtH$> > > > > > >> > > > > > > > >> > > Vote ends 5 June 2019. > > > > > >> > > > > > > > >> > > Thanks, > > > > > >> > > Shep > > > > > >> > > (chairs) > > > > > >> > > > > > > >> > > _______________________________________________ > > > > > >> > > BIER mailing list > > > > > >> > > BIER@ietf.org > > > > > >> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/ > > > > > >> > > list > > > > > >> > > info/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eE > > > > > >> > > NOs4 l_qdsXF0KwZD82cJLDFFNT2WVXWX$ > > > > > >> > > > > > > >> > > list > > > > > >> > > info/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6b > > > > > >> > > oAAW 4nrqju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > > >> > > > > > > >> > _______________________________________________ > > > > > >> > BIER mailing list > > > > > >> > BIER@ietf.org > > > > > >> > https://urldefense.com/v3/__https://www.ietf.org/mailman/li > > > > > >> > stin > > > > > >> > fo/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4 > > > > > >> > l_qd > > > > > >> > sXF0KwZD82cJLDFFNT2WVXWX$ > > > > > >> > > > > > >> > stin > > > > > >> > fo/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW > > > > > >> > 4nrq > > > > > >> > ju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > > > > > > > > > _______________________________________________ > > > > > > BIER mailing list > > > > > > BIER@ietf.org > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listi > > > > > > nfo/ > > > > > > bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsX > > > > > > F0Kw > > > > > > ZD82cJLDFFNT2WVXWX$ > > > > > > > > > > > nfo/ > > > > > > bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju > > > > > > 8UCL > > > > > > OgiuXc8Y_6sKn2KoAT$> > > > > > > > > -- > > > > --- > > > > tte@cs.fau.de > > > > > > > > _______________________________________________ > > > > BIER mailing list > > > > BIER@ietf.org > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ > > > > bier > > > > __;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82 > > > > cJLD > > > > FFNT2WVXWX$ > > > > > > > bier > > > > __;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiu > > > > Xc8Y > > > > _6sKn2KoAT$> > > > > > > -- > > > --- > > > tte@cs.fau.de > > > > -- > > --- > > tte@cs.fau.de > > > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier > > __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx4 > > 1_jWV3YUA6D$ > > -- > --- > tte@cs.fau.de > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > --000000000000b9a8ab059edfc2e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Toerless and Jeffrey


=
One more week of WGLC. Please read the latest rev and respond to= this thread w/wo support.

Chairs
(Shep)=


On Tue, Feb 18, 2020 at 12:07 PM Jeffrey (Zhaohui) Zhang &l= t;zzhang=3D40juniper.net@dm= arc.ietf.org> wrote:
Hi Toerless,

Thanks!
I support moving this to the next stage.

Jeffrey

On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote:
> Thanks Jeff
>
> I have now pushed out -05 with the answers and hopefully resolution to=
> your points in email below.=C2=A0 Biggest addition was a section about=
> reuse of BPs (without DNR) which came out of the confusion i think the=
> reuse in the ECMP example raised. I was afraid so far to explan that <= br> > as it may not be easy to absorb and ultimately is stuff only
> controller developers need to understand, but hopefully useful.
> And then of course the summary of BP optimizatins you asked for
>
> Diff from last version i sent you:
>
> https://urldefense.com/v= 3/__http://tools.ietf.org/*rfcdiff?url1=3Dhttps:
> **Araw.githubusercontent.com*toerless*bier-te-arch*master*= draft-ietf-b
> ier-te-arch-05.1.txt&url2=3Dhttp:**Atools.ietf.org*id*draft-ietf-= bier-te
> -arch-05.txt__;Ly8vLy8vLy8vLy8!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzH=
> OCr0fZkLPbgg3CPNu0PyrWsrFx41_jWX2At8V-$
>
> full -04 -> 05 diff:
>
> https://urldefense.com/= v3/__http://tools.ietf.org/*rfcdiff?url1=3Dhttp:*
> *Atools.ietf.org*id*draft-ietf-bier-te-arch-04.txt&url2=3Dhttp:**= Atools.
> ietf.= org*id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk
> !VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx41_jWancpziv$
>
> Comments inline below.
>
> Cheers
>=C2=A0 =C2=A0 =C2=A0toerless
>
> On Mon, Oct 28, 2019 at 07:52:59PM +0000, Jeffrey (Zhaohui) Zhang wrot= e:
> > I Thought u-turn is the most simple comparison leaf vs. non-leaf = BFR.
> >
> > Zzh> The text in the email is seriously misaligned. Looking at= the picture in the diff link, while you gave a U-turn example, though even= if BFER2 is not connected to BFR2=C2=A0 but only connected to BFER1 (hence= no U-turn), then BFER1 is still not a leaf BFER I suppose. That's why = I said the first sentence of the above paragraph is enough to define Leaf B= FER while the example itself is actually not needed.
>
> Argh... ok, had to fix two words, BFIR->BFER and left-hand -> ri= ght-hand:
>
> Consider how redundant disjoint traffic can reach BFER1/BFER2 in above=
> picture: When BFER1/BFER2 are Non-Leaf BFER as shown on the right hand=
> side, one traffic copy would be forwarded to BFER1 from BFR1, but the =
> other one could only reach BFER1 via BFER2, which makes BFER2 a
> non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forwarding
> traffic to BFER2
>
> > Zzh> Additionally, in left part of the picture you added, if s= ome failure leads to BFR2 to be only reachable via BFER1, then BFER1 is no = longer a leaf BFER.
>
> Added sentence:
>
> <t>Note that the BFER in the left hand picture are only guarante= ed to
> be leaf-BFR by fitting routing configuration that prohibits transit > traffic to pass through a PE, which is commonly applied in these
> topologies.</t>
>
> > I assume you don't reassign BPs when links go up and down. >
> I didn't want to discuss that option in this document. Its obvious= ly
> perfectly feasible, but be yet a big amount of text (especially the > considerations how to do this make-before-break. Future doc.
>
> > > but subsequent polarization example confuses me. It seems th= at BP 0:6 is assigned to the routed adjacency BFR10 (which is actually talk= ed about in Section 4.8).
> >
> > Section 4.7 does not mention "routed" at all, so there = are no routed adjacencies at all used in 4.7. So i am not sure what you are= confused about.
> >
> > Zzh> "The BIFT of each BFR are only populated with BPs th= at are adjacent to the BFR in the BIER-TE topology".
>
> Correct text from the introduction. Ok.
>
> > Zzh> Since the same 0:6 is in BIFTS of BFR1/BFR2/BFR3 (and I s= uppose in BFR4~BFR9 as well even though not drawn), I assumed it's for = the "MP2P" routed adjacency to R10; though I then ruled that out = - but I don't know what 0:6 represent now on BFR1, BFR2, and BFR3.
>
> Ah. Ok. I thought i could strip down the example to show only the
> adjacencies relevant to the following discusion, but seemingly this > can introduce the confusion you have.
>
> So i completed the example with the BP assignment acoss all nodes, but=
> added text pointing to a new section further down to discuss the
> re-use of BP for which thi picture is also an example.
>
> (check out the diff, new reuse text to long to copy inline).
>
> > The whole purpose of the ECMP BPs is of course to save bits, othe= rwise we'd give each link a separate BP, which would be 6 BP to reach t= o BFR4...BFR7 from BFR1.
> >
> > Zzh> The trouble I am having is that the same 0:6 is assigned = to different things and it's present on all BFR1/BFR2/BFR3. It is perha= ps an intentional smart design but I have not wrapped my mind around it. It= 's apparently different from the link bundle case, so better separate i= t out and elaborate it (including the DNR flag that might be needed here - = If the packet arrives on BFR1 with 0:6, would the BP reset when it is sent = to BFR2/3)?
>
> Yes, there was the bug of reusing BP 0:6 across sequential BFR along <= br> > the path, but now the example correctly reuses separate BP at
> different stages of the paths (BP 0:6 on BFR1, BP 0:7 on BFR2/BFR3) an= d so on.
>
> Thanks!
>
> > > 4.8.=C2=A0 Routed adjacencies
> > >
> > > If I understand it correctly, there is a BP assigned to L1/L= 2/L3
> > > respectively (p2p link), and then there are BPs assigned to = MP2P tunnels (routed adjacency from every BFR) to the L1/L2/L3 interface ad= dresses and loopback addresses on BFR2/3.
> >
> > Ok that wasn't quite the read i expected. Let me clarify the = text/picture:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ...............=C2=A0 =C2=A0 =C2=A0
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...BFR1--...=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0...--L1-- BFR2...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0... .Routers. ...--L2--/=C2=A0
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...BFR4--...=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0...------ BFR3...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ...............=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0LO
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Network Area 1
> >
> > Assume the requirement in the above picture is to explicitly stee= r traffic flows that have arrived at BFR1 or BFR4 via a shortest path in th= e routing underlay "network area 1" to one of the following three= next segments: (1) BFR2 via link L1, (2) BFR2 via link L2, (3) via BFR3. > >
> > To achieve this, both BFR1 and BFR4 are set up with a forward_rou= ted adjacency BitPosition towards an address of BFR2 on link L1, another fo= rward_routed BitPosition towards an address of BFR2 on link L2 and a third = forward_routed Bitposition towards a node address LO of BFR3.
> >
> > Does this clear ip the confusion ?
> >
> > Zzh> The picture is badly misaligned. I'll wait till 4.7 q= uestions are cleared.
>
> Ok.
>
> > > If BFR2/3 are also BFERs, then they additionally will have B= FER BPs.
> > > On BFR1/4, the BIFT entries for the MP2P BPs for the L1/L2/L= 3/loopback interface addresses of BFR2/3 will use forward_routed(interface/= loopback address). For a packet to be decapsulated on a BFER, there is a ne= ed for both the BFER BP and another BP (p2p/lan/hub-spoke/routed-adjacency)= in the packet (the former is for decapsulation and the latter is for getti= ng it there).
> >
> > This is not discussed in this section, but you are right - unless=
> > BFR2 or BFR3 is a leaf BFR. In that case, it would just leverage = the one shared "leaf-BFR" BP, so they do not need a per-BFER BP f= or local_decap().
> >
> > Zzh> Right - shared leaf-BFR BP but still need that BP (the ke= y is that we need a BP to get packet to a BFER and then a BP for decapsulat= ion).
>
> You got it.
>
> > > If that???s the case, it???s worth point the above out.
> >
> > Hmm... The logic of BFER BPs is totally independent of the logic = of forward_routed adjacency, so i would worry that repeating the explanatio= n of BFER BPs would conflate the forward_routed explanation.
> >
> > Zzh> It's just that this is a place where all kinds of BPs= are used so it's good to have a summary (could be a subsection 4.9). >
> Yes, added such a summary. Pls. check.
>
> > > Actually, the reason that I thought this is MP2P is that 0:6= is present on R1, R2, and R3 (and more I assume) in Figure 12, but now I t= hink it can???t be MP2P (so it is not correct to have 0:6 present on those = routers ??? only the p2p tunnel head/tail should have the BP present in the= BIFT). The reason is that if it were MP2P, any router getting a copy will = send it to the endpoint of the routed adjacency, causing lots of duplicates= .
> > >
> > > Am I getting this correct?
> >
> > I think you are still explaining from the misunderstsanding that = the ECMP explanations where about routed adjacencies.
> >
> > I have now expanded the somewhat terse text in the BIFT table pic= tures, to make it clear that the ECMP is across multipe forward_connected a= djacencies in the examples. For example, first BIFT picture:
> >
> >=C2=A0 =C2=A0BIFT entry in BFR1:
> >=C2=A0 =C2=A0-----------------------------------------------------= -------------
> >=C2=A0 =C2=A0| Index |=C2=A0 Adjacencies=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> >=C2=A0 =C2=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=C2=A0 =C2=A0| 0:6=C2=A0 =C2=A0|=C2=A0 ECMP({forward_connected(L1,= BFR2),=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
> >=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 forward_connected(L2, BFR2),=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> >=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 forward_connected(L3, BFR2)}, seed)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|
> >=C2=A0 =C2=A0-----------------------------------------------------= -------------
> >
> > Of course, an ECMP adjacency can be across any type of adjacencie= s, but all the text/explanations used forward_connected, and now the pictur= es show that explicitly.
> >
> > Zzh> I can understand the multi-link case, but the multi-hop E= CMP case (from BFR1 towards BFR10) is confusing me. It would help to give a= n example how it can be used, WITHOUT worrying about polarization.
>
> Please check -05 text that has the full set of BIFT listed now:
>
> There is=C2=A0 really nothing nothing unique in multi-hop ECMP for BIE= R-TE
> that we do not also have in any other ECMP, except the conclusion that=
> we want to support fast HW hash mechanisms AND allow the controller to=
> set up non-polarized multi-hop ECMP AND be able to precalculate paths.=
> Hence the specification of ECMP adjacencies to have a controller
> configurable seed.
>
> Btw: The picture is maybe unnecessarily large because i've used it= for
> 20 years to explain the same polarization issue for unicast vs
> multicast, and for multicast only BFR10...BFR4 are relevant (ECMP of <= br> > the PIM/mLDP joins), whereas for unicast/BIER only
> BFR1...BFR7 are relevant. But being symmetric, the picture makes it > clear its the same problem.
>
> > >=C2=A0 =C2=A0 To inhibit looping in the face of such physical= misconfiguration,
> > >=C2=A0 =C2=A0 only forward_connected adjacencies are permitte= d to have DNR set, and
> > >=C2=A0 =C2=A0 the link layer destination address of the adjac= ency (e.g.=C2=A0 MAC
> > >=C2=A0 =C2=A0 address) protects against closing the loop.=C2= =A0 Link layers without port
> > >=C2=A0 =C2=A0 unique link layer addresses should not be used = with the DNR flag set.
> > >
> > > It???s not clear how link layer address helps?
> >
> > I have expanded this to
> > "link layer port unique unicast destination address" > >
> > Aka: MPLS or ethernet have unique link layer destination destinat= ion addresses (label or destination MAC). If you think about incorrectly pl= ugged HDLC links (such as old T1/T3/... links), they only have 2 generic ad= dresses, if i remember 1 or 3 in the HDLC frame. So when you misplug one of= those p2p cables wrong, the packets would be incrrectly received by the wr= ong receiver node and then DNR could cause persistent loops only solved by = TTL.
> >
> > Zzh> "Consider in the ring picture that link L4 from BFR3= is plugged into the L1 interface of BFRa" - still not sure how label/= mac helps here. I suppose the ring topology is discovered/verified by the c= ontrol plane and when the miscalling happens then the ring will not include= the BFR1/BFR2 part and BFR3 will not have the DNR set? If ring discovery/v= arication is not done then perhaps we should point out that RPF based on li= nk layer address is needed - the key is RPF (which needs unique link layer = address)?
>
> Forget RPF. BIER(-TE) has no RPF (issues). Its just like unicast. RPF =
> is just a problem for receiver originated joins like in PIM/mLDP, but =
> not unicast/bier(-te)/RSVP-TE.
>
> Forward_connected is just like a unicast subnet adjacency to a direct =
> neighbor: Interface and L2 addresss of the destination.
>
> The controller (could be a human) "assumes" a particular phy= sicial
> topology, from telemetry/knowledge/whatever. It then calculates the > desired BIER-TE topology and pushes it down. This topology is meant to=
> be loop free of course wrt to the configured adjacencies.
> In this BIER-TE topology, BFR3 will have a BP with the
> forward_connected(L4, MAC-of-BFR2) adjacency.
>
> If the cable connecting to L4 is miswired, then BFR3 would still send =
> the packets to the MAC address of BFR2, but given how the cable
> connects to some other node, these packets will be discarded by that <= br> > node. because they're just L2 unicast packets.
>
> I think this is equally true when we have normal BIER/MPLS enacp.
> Those packets too are addressed to the unicast MAC address of the
> neighbor.
>
> Now, if/when he controller recognizes that the physical topology has <= br> > changed, thats a completely different story and not addressed here. > Given how we assumed this was a cabling mistake, the controller would =
> probably only complain about the miswiring to operations but be happy =
> that the forwarding plane just makes packets fail instead of loop. If =
> this was a planned change process, then it will be similarily
> convoluted as it would today be with rewiring cables in an
> SR-MPLS/SRv6 topology and updating SIDs.
>
> > > Because the forwarding is different from BIER forwarding (be= cause of [1] above), we might as well introduce an optimization here ??? fo= r each BIFT, calculate the F-BM of the BIFT itself (the logical ???or??? of= all the BPs presented in this BIFT) and then use (packet->bitstring &am= p; BIFT.F-BM) as the input to GetFirst/NextBitPosition(). That should skip = many bits.
> >
> > Right. But i explicitly removed those optimizations (i had them i= n older draft versions) because the whole idea of this picture is solely th= e comparison with figure 4 of RFC8279.
> >
> > Zzh> I think it's worth point that optimization out; you c= an mark it optional if you want to emphasize the similarity to BIER forward= ing, but since BIER forwarding does do the maskoff step, it is very efficie= nt while BIER-TE forwarding does not it the maskoff step so this optimizati= on is important.
>
> Ok. I simplified the text comparison BIER/BIER-TE wrt. to the FBM
> rules [1] and [2] and added following paragraph:
>
> <t>In BIER, the order of BPs impacts the result of forwarding be= cause of [1].
> In BIER-TE, forwarding is not impacted by the order of BPs. It is
> therefore possible to further optimize forwarding than in BIER. For > example parallelizing forwarding across multiple FPE cores or
> distributed linecards does only need to examine an arbitrary subset of=
> BP and not evaluate the dependency between BPs.</t>
>
> > >=C2=A0 =C2=A0 The following pseudocode is comprehensive:
> > >
> > > The above sentence reads a bit strange (or lacks some segue)= .
> >
> > I hope not, but maybe best left to a native english speaker (RFC-= editor).
> >
> > The first (RFC8279) pseudocode was simplified. The second one is = comprehensive. If not comprehensive, whats a good opposite of simplified ?<= br> > >
> > Zzh> Perhaps "The above simplified pseudocode is elaborat= ed further as following"?
> > Zzh> Jeffrey
>
> Done.
>
> Thanks a lot.
>
>
> >=C2=A0 =C2=A0
> > > ________________________________________
> > > From: BIER [bier-bounces@ietf.org<mailto:bier-bounces@ietf.org>]
> > > on behalf of Toerless Eckert [tte@cs.fau.de<mailto:tte@cs.fau.de>]
> > > Sent: Tuesday, July 09, 2019 23:38
> > > To: Mike McBride
> > > Cc: Greg Shepherd; BIER WG; Pascal Thubert (pthubert)
> > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch
> > >
> > > Thanks, Mike
> > >
> > > The authors also reviewed the document and concluded that it= was
> > > really hard to get into the document context because of too = many
> > > forward dependencies. We tried to fix this by adding two hop= efully
> > > good & basic examples into the Introduction section and = using them
> > > to also add a better definition of the term "BIER-TE To= pology" in the Introduction.
> > > Hopefully this makes readin the rest of te document smoother= .
> > >
> > > Also improved text of Abstract and refined text compariing B= IER-TE with SR.
> > >
> > > https://urldef= ense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=3Dhttps:
> > > **Atools.ietf.org*id*draft-ietf-bier-te-arch-02.txt&url= 2=3Dhttps:**A
> > > tool
> > > s.ietf.org*id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA= 6R
> > > jC81
> > > c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV= _eTUEh
> > > $
> > > <https://url= defense.com/v3/__http:/tools.ietf.org/*rfcdiff?url1=3Dhttps:
> > > **Atools.ietf.org*id*draft-ietf-bier-te-arch-02.txt&url= 2=3Dhttps:**A
> > > tool
> > > s.ietf.org*id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA= 6R
> > > jC81
> > > c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sN= d1njcX
> > > $>
> > >
> > > Cheers
> > >=C2=A0 =C2=A0 =C2=A0Toerless
> > >
> > > On Wed, Jun 26, 2019 at 10:39:36AM -0700, Mike McBride wrote= :
> > > > How about three? I support.
> > > > mike
> > > >
> > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd <gjshep@gmail.com<m= ailto:gjshep@gmail.co= m>> wrote:
> > > > >
> > > > > We cannot take two 'yes' votes and WG cons= ensus.
> > > > > Please, read and respond. If you don't support= , then please vote as much publicly right here.
> > > > >
> > > > > Thanks,
> > > > > Greg
> > > > >
> > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert (pt= hubert) <pthuber= t@cisco.com<mailto:pthubert@cisco.com>> wrote:
> > > > >>
> > > > >> Support:
> > > > >>
> > > > >> I see great value in deterministic networks as= well as IOT (with RPL).
> > > > >>
> > > > >> All the best,
> > > > >>
> > > > >> Pascal
> > > > >>
> > > > >> > -----Original Message-----
> > > > >> > From: BIER
> > > > >> > <bier-bounces@ietf.org<mailto:bier-bounces@ietf.org>>= On
> > > > >> > Behalf Of Toerless Eckert
> > > > >> > Sent: mardi 4 juin 2019 02:03
> > > > >> > To: Greg Shepherd
> > > > >> > <gjshep@gmail.com<mailto:gjshep@gmail.com>>
> > > > >> > Cc: BIER WG <bier@ietf.org<mailto:bier@ietf.org>>
> > > > >> > Subject: Re: [Bier] WGLC - draft-ietf-bie= r-te-arch
> > > > >> >
> > > > >> > +1
> > > > >> > Obviously support as co-author.
> > > > >> >
> > > > >> > On Wed, May 29, 2019 at 12:41:26PM -0700,= Greg Shepherd wrote:
> > > > >> > > Please read and respond to this thre= ad w/ or w/o support.
> > > > >> > >
> > > > >> > > http= s://urldefense.com/v3/__https://datatracker..ietf.org
> > > > >> > > /doc
> > > > >> > > /draft-ietf-bier-te-arch/__;!8WoA6Rj= C81c!XvH4AAxfrDjFoK_s
> > > > >> > > ercw ZMsc0O5N42eENOs4l_qdsXF0KwZD82c= JLDFFNV9eClBj$
> > > > >> > > <h= ttps://urldefense.com/v3/__https:/datatracker.ietf.org/
> > > > >> > > doc/
> > > > >> > > draft-ietf-bier-te-arch/__;!8WoA6RjC= 81c!UBTGvWWpMHyeiSanx
> > > > >> > > s6vI b_EnBVgyg6boAAW4nrqju8UCLOgiuXc= 8Y_6sD40kmtH$>
> > > > >> > >
> > > > >> > > Vote ends 5 June 2019.
> > > > >> > >
> > > > >> > > Thanks,
> > > > >> > > Shep
> > > > >> > > (chairs)
> > > > >> >
> > > > >> > > ____________________________________= ___________
> > > > >> > > BIER mailing list
> > > > >> > > BIER@ietf.org<mailto:BIER@ietf.org>
> > > > >> > > http= s://urldefense.com/v3/__https://www.ietf.org/mailman/
> > > > >> > > list
> > > > >> > > info/bier__;!8WoA6RjC81c!XvH4AAxfrDj= FoK_sercwZMsc0O5N42eE
> > > > >> > > NOs4 l_qdsXF0KwZD82cJLDFFNT2WVXWX$ <= br> > > > > >> > > <h= ttps://urldefense.com/v3/__https:/www.ietf.org/mailman/
> > > > >> > > list
> > > > >> > > info/bier__;!8WoA6RjC81c!UBTGvWWpMHy= eiSanxs6vIb_EnBVgyg6b
> > > > >> > > oAAW 4nrqju8UCLOgiuXc8Y_6sKn2KoAT$&g= t;
> > > > >> >
> > > > >> > _________________________________________= ______
> > > > >> > BIER mailing list
> > > > >> > BIER@ietf.org<mailto:BIER@ietf.org>
> > > > >> > https:/= /urldefense.com/v3/__https://www.ietf.org/mailman/li
> > > > >> > stin
> > > > >> > fo/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_ser= cwZMsc0O5N42eENOs4
> > > > >> > l_qd
> > > > >> > sXF0KwZD82cJLDFFNT2WVXWX$
> > > > >> > <http= s://urldefense.com/v3/__https:/www.ietf.org/mailman/li
> > > > >> > stin
> > > > >> > fo/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs= 6vIb_EnBVgyg6boAAW
> > > > >> > 4nrq
> > > > >> > ju8UCLOgiuXc8Y_6sKn2KoAT$>
> > > > >
> > > > > _______________________________________________ > > > > > BIER mailing list
> > > > > BIER@ietf.org<mailto:BIER@ietf.org>
> > > > > https://urlde= fense.com/v3/__https://www.ietf.org/mailman/listi
> > > > > nfo/
> > > > > bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42= eENOs4l_qdsX
> > > > > F0Kw
> > > > > ZD82cJLDFFNT2WVXWX$
> > > > > <https://ur= ldefense.com/v3/__https:/www.ietf.org/mailman/listi
> > > > > nfo/
> > > > > bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg= 6boAAW4nrqju
> > > > > 8UCL
> > > > > OgiuXc8Y_6sKn2KoAT$>
> > >
> > > --
> > > ---
> > > tte@cs.fa= u.de<mailto:tte@c= s.fau.de>
> > >
> > > _______________________________________________
> > > BIER mailing list
> > > BIER@ietf= .org<mailto:BIER@= ietf.org>
> > > https://urldefense.= com/v3/__https://www.ietf.org/mailman/listinfo/
> > > bier
> > > __;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0= KwZD82
> > > cJLD
> > > FFNT2WVXWX$
> > > <https://urldefen= se.com/v3/__https:/www.ietf.org/mailman/listinfo/
> > > bier
> > > __;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8U= CLOgiu
> > > Xc8Y
> > > _6sKn2KoAT$>
> >
> > --
> > ---
> > tte@cs.fau.de<= /a>
>
> --
> ---
> tte@cs.fau.de >
> _______________________________________________
> BIER mailing list
> BIER@ietf.org > https://urldefense.com/v3= /__https://www.ietf.org/mailman/listinfo/bier
> __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx4=
> 1_jWV3YUA6D$

--
---
tte@cs.fau.de

_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ietf.org/mailman/listinfo/bier
--000000000000b9a8ab059edfc2e9-- From nobody Tue Feb 18 13:13:24 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012AF12085A for ; Tue, 18 Feb 2020 13:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iHHSvTLLhhHp for ; Tue, 18 Feb 2020 13:13:12 -0800 (PST) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2096.outbound.protection.outlook.com [40.107.237.96]) (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 95B4F120848 for ; Tue, 18 Feb 2020 13:13:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QXoUXcxxnalpdagptyR5/6l65HST2Ryz5sSqaZDaYVmQOxwwFwcNiYt7hBxdzcFRzmMYUs6WSngsRurLnqhA+mzoDulgvCWBWvMWK8bMCs8+y99m7Xtt6sHDb6V6a4xbx86FBe+QAYzH1VYXKwWGO/d3Dyi83Z39OBcZygR4TRUzrNjqLnUJBlnT9znIgWAi59rBiGnH7DL6DwJ6MAowA4TAMi6QkrqZKb6musiMlZvQdlCFqatLFtGBQlmNqhaOf6citKwQePnscG0OGM2vPMKLzJiJotat5Qteh8ohF5AYhLqf070JBe2Z5hOw2m3y/NkYHyjXRjJYQOd2D1WR0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PeMdf6pKTjdjlDKUYx52y0mjKmfCC9oiEOKTLtwMhCo=; b=dVRHLCMTOmoztvJhO2hjD+qmlebztOQ2iLr07Nzk+TSNjjjBQK38SZB9q8tIUTBhVdv6zgdnfPzZZFBa5FWEwlKm+9o9xPAEq2WFc7JbAxRXl1ncMf/meM2FUWO9c/8yQaO9y5pX+U8XZKsRKljFIMfnaWpMwQwowRiKYzZt3LBoZMqKy7TsFxJ5w7sk1epRnmxzgwxCHElghVXKPX71umGD8V3i3Ad41OqepnNEn5bKOLc41mc4MP6eWfwQ/BHW0sRLtDgObdlYwDaGiKsNtd3RuOcAsfR6AAUScbzv7u0sjD7+leJkVFCBgZeuwS/S1I82UhQ6dowS/2qgzQXwgw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PeMdf6pKTjdjlDKUYx52y0mjKmfCC9oiEOKTLtwMhCo=; b=R+0hvQi1k8LOTZxFzPIEX0dLscB09bdjANKOC/Yq1Ahj1V0TPLmyPdR9rO6q429bey/B2tgFsmDYRGcrH+b93LREdbJoqgSIK+fqOhjhx2Dw6BxqLFubxtJA3qiKC5bqkU4OR+GLol6vGW5Yi/jDwasX5vghGmcXyq0RrL5O6Cs= Received: from DM6PR08MB3978.namprd08.prod.outlook.com (20.176.65.29) by DM6PR08MB4762.namprd08.prod.outlook.com (20.176.114.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.23; Tue, 18 Feb 2020 21:13:10 +0000 Received: from DM6PR08MB3978.namprd08.prod.outlook.com ([fe80::d198:b006:9d2b:e8ec]) by DM6PR08MB3978.namprd08.prod.outlook.com ([fe80::d198:b006:9d2b:e8ec%6]) with mapi id 15.20.2729.032; Tue, 18 Feb 2020 21:13:10 +0000 From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" To: "Jeffrey (Zhaohui) Zhang" , Toerless Eckert , "bier@ietf.org" Thread-Topic: [Bier] WGLC - draft-ietf-bier-te-arch Thread-Index: AdXmltqazVMKFHRdSsy5t+yost06gQACVHfg Date: Tue, 18 Feb 2020 21: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: authentication-results: spf=none (sender IP is ) smtp.mailfrom=hooman.bidgoli@nokia.com; x-originating-ip: [174.112.72.100] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 7c34eee4-bb56-457a-7a03-08d7b4b75b85 x-ms-traffictypediagnostic: DM6PR08MB4762: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3276; x-forefront-prvs: 031763BCAF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(366004)(39860400002)(396003)(376002)(136003)(199004)(189003)(33656002)(7696005)(966005)(66574012)(110136005)(5660300002)(2906002)(81166006)(81156014)(8676002)(478600001)(64756008)(6506007)(66556008)(66446008)(86362001)(52536014)(8936002)(316002)(76116006)(26005)(30864003)(9686003)(186003)(66476007)(53546011)(71200400001)(66946007)(55016002)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR08MB4762; H:DM6PR08MB3978.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sialVZnYH0axsjBxfxNwIZ11Umj/AfQOdAIzbk1HpIHqhdLEhLtX3IKNDRR/veqVtvoU+ea3i5fbiBHPW0vVXEr9c7Pr0wLgXHrKNaywggG6Z5r4FFvxvfw2LgL3JrHmYUVmU6ewGNXn/gI7pICCgXubRiKpTQh59OyaaV71ZYWi+A2/YDv3DrbMXR6Nq2yO4lmxWHgWoS7pYqewyKu8pC9vzu+oY/Zl50TYm10+wJpyoNo2LpAubeWJGrQiYnk1h48j7iTrr0IgVYACSopQWAKpFWfdMz4T/g5sEzQIPWuOCQO+n72w5ywT1SHBK2UScLcv+GA/OuqWj9SAvR/OBCJ6GOAZ3OkqQML+tCLIcUBu0gyFbX/Ev0ZNGXadYmg+z6vgOMFwzec9Te1FXXjbiw6f3Ayhtrl3FBwXfptWiJnStubcVRiIcGZwGVyJrKOlyJyNsHdAfR6vHHp6RS0hkivaUd57usRd/JWwwTQJhlqaPXQIQTIUiNiiXPKtHXMMeljCqntzplutbyboTDunbQ== x-ms-exchange-antispam-messagedata: sUOu9w8RQjncHdvSckROsocNL5LMUkhn/TniOI+QmQCa5ylyjZ0NmAnqd9Yq4su7V8YmIxeLFV8YrzS5Pme+eXcRczB5HUzXA+GpWyFaXaC237B25wmPWwFIHHvRgbxmSXGcpVUKJgQkZYNNmrIwKw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7c34eee4-bb56-457a-7a03-08d7b4b75b85 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2020 21:13:10.2794 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 9kFou921GRD2OcHwaTZc3IJgLmnmy0Gyj+DpfzzRVHslvH76WvBgrbVbe0XVbU/PhmPG+3F2M2sC6vLRkkNJgh25av9Yn8KFvwGKZpLAQuM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB4762 Archived-At: Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 21:13:23 -0000 Support Regards Hooman -----Original Message----- From: BIER On Behalf Of Jeffrey (Zhaohui) Zhang Sent: Tuesday, February 18, 2020 3:07 PM To: Toerless Eckert ; bier@ietf.org Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch Hi Toerless, Thanks! I support moving this to the next stage. Jeffrey On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote: > Thanks Jeff >=20 > I have now pushed out -05 with the answers and hopefully resolution to=20 > your points in email below. Biggest addition was a section about=20 > reuse of BPs (without DNR) which came out of the confusion i think the=20 > reuse in the ECMP example raised. I was afraid so far to explan that=20 > as it may not be easy to absorb and ultimately is stuff only=20 > controller developers need to understand, but hopefully useful. > And then of course the summary of BP optimizatins you asked for >=20 > Diff from last version i sent you: >=20 > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=3Dhttps: > **Araw.githubusercontent.com*toerless*bier-te-arch*master*draft-ietf-b > ier-te-arch-05.1.txt&url2=3Dhttp:**Atools.ietf.org*id*draft-ietf-bier-te > -arch-05.txt__;Ly8vLy8vLy8vLy8!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzH > OCr0fZkLPbgg3CPNu0PyrWsrFx41_jWX2At8V-$ >=20 > full -04 -> 05 diff: >=20 > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=3Dhttp:* > *Atools.ietf.org*id*draft-ietf-bier-te-arch-04.txt&url2=3Dhttp:**Atools. > ietf.org*id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk > !VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx41_jWancpziv$ >=20 > Comments inline below. >=20 > Cheers > toerless >=20 > On Mon, Oct 28, 2019 at 07:52:59PM +0000, Jeffrey (Zhaohui) Zhang wrote: > > I Thought u-turn is the most simple comparison leaf vs. non-leaf BFR. > >=20 > > Zzh> The text in the email is seriously misaligned. Looking at the pict= ure in the diff link, while you gave a U-turn example, though even if BFER2= is not connected to BFR2 but only connected to BFER1 (hence no U-turn), t= hen BFER1 is still not a leaf BFER I suppose. That's why I said the first s= entence of the above paragraph is enough to define Leaf BFER while the exam= ple itself is actually not needed. >=20 > Argh... ok, had to fix two words, BFIR->BFER and left-hand -> right-hand: >=20 > Consider how redundant disjoint traffic can reach BFER1/BFER2 in above > picture: When BFER1/BFER2 are Non-Leaf BFER as shown on the right hand=20 > side, one traffic copy would be forwarded to BFER1 from BFR1, but the=20 > other one could only reach BFER1 via BFER2, which makes BFER2 a=20 > non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forwarding=20 > traffic to BFER2 >=20 > > Zzh> Additionally, in left part of the picture you added, if some failu= re leads to BFR2 to be only reachable via BFER1, then BFER1 is no longer a = leaf BFER.=20 >=20 > Added sentence: >=20 > Note that the BFER in the left hand picture are only guaranteed to=20 > be leaf-BFR by fitting routing configuration that prohibits transit=20 > traffic to pass through a PE, which is commonly applied in these=20 > topologies. >=20 > > I assume you don't reassign BPs when links go up and down. >=20 > I didn't want to discuss that option in this document. Its obviously=20 > perfectly feasible, but be yet a big amount of text (especially the=20 > considerations how to do this make-before-break. Future doc. >=20 > > > but subsequent polarization example confuses me. It seems that BP 0:6= is assigned to the routed adjacency BFR10 (which is actually talked about = in Section 4.8). > >=20 > > Section 4.7 does not mention "routed" at all, so there are no routed ad= jacencies at all used in 4.7. So i am not sure what you are confused about. > >=20 > > Zzh> "The BIFT of each BFR are only populated with BPs that are adjacen= t to the BFR in the BIER-TE topology". >=20 > Correct text from the introduction. Ok. >=20 > > Zzh> Since the same 0:6 is in BIFTS of BFR1/BFR2/BFR3 (and I suppose in= BFR4~BFR9 as well even though not drawn), I assumed it's for the "MP2P" ro= uted adjacency to R10; though I then ruled that out - but I don't know what= 0:6 represent now on BFR1, BFR2, and BFR3. >=20 > Ah. Ok. I thought i could strip down the example to show only the=20 > adjacencies relevant to the following discusion, but seemingly this=20 > can introduce the confusion you have. >=20 > So i completed the example with the BP assignment acoss all nodes, but=20 > added text pointing to a new section further down to discuss the=20 > re-use of BP for which thi picture is also an example. >=20 > (check out the diff, new reuse text to long to copy inline). >=20 > > The whole purpose of the ECMP BPs is of course to save bits, otherwise = we'd give each link a separate BP, which would be 6 BP to reach to BFR4...B= FR7 from BFR1.=20 > >=20 > > Zzh> The trouble I am having is that the same 0:6 is assigned to differ= ent things and it's present on all BFR1/BFR2/BFR3. It is perhaps an intenti= onal smart design but I have not wrapped my mind around it. It's apparently= different from the link bundle case, so better separate it out and elabora= te it (including the DNR flag that might be needed here - If the packet arr= ives on BFR1 with 0:6, would the BP reset when it is sent to BFR2/3)? >=20 > Yes, there was the bug of reusing BP 0:6 across sequential BFR along=20 > the path, but now the example correctly reuses separate BP at=20 > different stages of the paths (BP 0:6 on BFR1, BP 0:7 on BFR2/BFR3) and s= o on. >=20 > Thanks! >=20 > > > 4.8. Routed adjacencies > > >=20 > > > If I understand it correctly, there is a BP assigned to L1/L2/L3=20 > > > respectively (p2p link), and then there are BPs assigned to MP2P tunn= els (routed adjacency from every BFR) to the L1/L2/L3 interface addresses a= nd loopback addresses on BFR2/3. > >=20 > > Ok that wasn't quite the read i expected. Let me clarify the text/pictu= re: > >=20 > > ............... =20 > > ...BFR1--... ...--L1-- BFR2... > > ... .Routers. ...--L2--/ =20 > > ...BFR4--... ...------ BFR3... > > ............... | > > LO > > Network Area 1 > >=20 > > Assume the requirement in the above picture is to explicitly steer traf= fic flows that have arrived at BFR1 or BFR4 via a shortest path in the rout= ing underlay "network area 1" to one of the following three next segments: = (1) BFR2 via link L1, (2) BFR2 via link L2, (3) via BFR3. > >=20 > > To achieve this, both BFR1 and BFR4 are set up with a forward_routed ad= jacency BitPosition towards an address of BFR2 on link L1, another forward_= routed BitPosition towards an address of BFR2 on link L2 and a third forwar= d_routed Bitposition towards a node address LO of BFR3. > >=20 > > Does this clear ip the confusion ? > >=20 > > Zzh> The picture is badly misaligned. I'll wait till 4.7 questions are = cleared. >=20 > Ok. >=20 > > > If BFR2/3 are also BFERs, then they additionally will have BFER BPs. > > > On BFR1/4, the BIFT entries for the MP2P BPs for the L1/L2/L3/loopbac= k interface addresses of BFR2/3 will use forward_routed(interface/loopback = address). For a packet to be decapsulated on a BFER, there is a need for bo= th the BFER BP and another BP (p2p/lan/hub-spoke/routed-adjacency) in the p= acket (the former is for decapsulation and the latter is for getting it the= re). > >=20 > > This is not discussed in this section, but you are right - unless > > BFR2 or BFR3 is a leaf BFR. In that case, it would just leverage the on= e shared "leaf-BFR" BP, so they do not need a per-BFER BP for local_decap()= .=20 > >=20 > > Zzh> Right - shared leaf-BFR BP but still need that BP (the key is that= we need a BP to get packet to a BFER and then a BP for decapsulation). >=20 > You got it. >=20 > > > If that???s the case, it???s worth point the above out. > >=20 > > Hmm... The logic of BFER BPs is totally independent of the logic of for= ward_routed adjacency, so i would worry that repeating the explanation of B= FER BPs would conflate the forward_routed explanation. > >=20 > > Zzh> It's just that this is a place where all kinds of BPs are used so = it's good to have a summary (could be a subsection 4.9). >=20 > Yes, added such a summary. Pls. check. >=20 > > > Actually, the reason that I thought this is MP2P is that 0:6 is prese= nt on R1, R2, and R3 (and more I assume) in Figure 12, but now I think it c= an???t be MP2P (so it is not correct to have 0:6 present on those routers ?= ?? only the p2p tunnel head/tail should have the BP present in the BIFT). T= he reason is that if it were MP2P, any router getting a copy will send it t= o the endpoint of the routed adjacency, causing lots of duplicates. > > >=20 > > > Am I getting this correct? > >=20 > > I think you are still explaining from the misunderstsanding that the EC= MP explanations where about routed adjacencies. > >=20 > > I have now expanded the somewhat terse text in the BIFT table pictures,= to make it clear that the ECMP is across multipe forward_connected adjacen= cies in the examples. For example, first BIFT picture: > >=20 > > BIFT entry in BFR1: > > ------------------------------------------------------------------ > > | Index | Adjacencies | > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > | 0:6 | ECMP({forward_connected(L1, BFR2), | > > | | forward_connected(L2, BFR2), | > > | | forward_connected(L3, BFR2)}, seed) | > > ------------------------------------------------------------------ > >=20 > > Of course, an ECMP adjacency can be across any type of adjacencies, but= all the text/explanations used forward_connected, and now the pictures sho= w that explicitly. > >=20 > > Zzh> I can understand the multi-link case, but the multi-hop ECMP case = (from BFR1 towards BFR10) is confusing me. It would help to give an example= how it can be used, WITHOUT worrying about polarization. >=20 > Please check -05 text that has the full set of BIFT listed now: >=20 > There is really nothing nothing unique in multi-hop ECMP for BIER-TE=20 > that we do not also have in any other ECMP, except the conclusion that=20 > we want to support fast HW hash mechanisms AND allow the controller to=20 > set up non-polarized multi-hop ECMP AND be able to precalculate paths. > Hence the specification of ECMP adjacencies to have a controller=20 > configurable seed. >=20 > Btw: The picture is maybe unnecessarily large because i've used it for > 20 years to explain the same polarization issue for unicast vs=20 > multicast, and for multicast only BFR10...BFR4 are relevant (ECMP of=20 > the PIM/mLDP joins), whereas for unicast/BIER only > BFR1...BFR7 are relevant. But being symmetric, the picture makes it=20 > clear its the same problem. >=20 > > > To inhibit looping in the face of such physical misconfiguration, > > > only forward_connected adjacencies are permitted to have DNR set, = and > > > the link layer destination address of the adjacency (e.g. MAC > > > address) protects against closing the loop. Link layers without p= ort > > > unique link layer addresses should not be used with the DNR flag s= et. > > > > > > It???s not clear how link layer address helps? > >=20 > > I have expanded this to > > "link layer port unique unicast destination address" > >=20 > > Aka: MPLS or ethernet have unique link layer destination destination ad= dresses (label or destination MAC). If you think about incorrectly plugged = HDLC links (such as old T1/T3/... links), they only have 2 generic addresse= s, if i remember 1 or 3 in the HDLC frame. So when you misplug one of those= p2p cables wrong, the packets would be incrrectly received by the wrong re= ceiver node and then DNR could cause persistent loops only solved by TTL. > >=20 > > Zzh> "Consider in the ring picture that link L4 from BFR3 is plugged in= to the L1 interface of BFRa" - still not sure how label/mac helps here. I s= uppose the ring topology is discovered/verified by the control plane and wh= en the miscalling happens then the ring will not include the BFR1/BFR2 part= and BFR3 will not have the DNR set? If ring discovery/varication is not do= ne then perhaps we should point out that RPF based on link layer address is= needed - the key is RPF (which needs unique link layer address)? >=20 > Forget RPF. BIER(-TE) has no RPF (issues). Its just like unicast. RPF=20 > is just a problem for receiver originated joins like in PIM/mLDP, but=20 > not unicast/bier(-te)/RSVP-TE. >=20 > Forward_connected is just like a unicast subnet adjacency to a direct > neighbor: Interface and L2 addresss of the destination. >=20 > The controller (could be a human) "assumes" a particular physicial=20 > topology, from telemetry/knowledge/whatever. It then calculates the=20 > desired BIER-TE topology and pushes it down. This topology is meant to=20 > be loop free of course wrt to the configured adjacencies. > In this BIER-TE topology, BFR3 will have a BP with the=20 > forward_connected(L4, MAC-of-BFR2) adjacency. >=20 > If the cable connecting to L4 is miswired, then BFR3 would still send=20 > the packets to the MAC address of BFR2, but given how the cable=20 > connects to some other node, these packets will be discarded by that=20 > node. because they're just L2 unicast packets. >=20 > I think this is equally true when we have normal BIER/MPLS enacp. > Those packets too are addressed to the unicast MAC address of the=20 > neighbor. >=20 > Now, if/when he controller recognizes that the physical topology has=20 > changed, thats a completely different story and not addressed here. > Given how we assumed this was a cabling mistake, the controller would=20 > probably only complain about the miswiring to operations but be happy=20 > that the forwarding plane just makes packets fail instead of loop. If=20 > this was a planned change process, then it will be similarily=20 > convoluted as it would today be with rewiring cables in an > SR-MPLS/SRv6 topology and updating SIDs. >=20 > > > Because the forwarding is different from BIER forwarding (because of = [1] above), we might as well introduce an optimization here ??? for each BI= FT, calculate the F-BM of the BIFT itself (the logical ???or??? of all the = BPs presented in this BIFT) and then use (packet->bitstring & BIFT.F-BM) as= the input to GetFirst/NextBitPosition(). That should skip many bits. > >=20 > > Right. But i explicitly removed those optimizations (i had them in olde= r draft versions) because the whole idea of this picture is solely the comp= arison with figure 4 of RFC8279. > >=20 > > Zzh> I think it's worth point that optimization out; you can mark it op= tional if you want to emphasize the similarity to BIER forwarding, but sinc= e BIER forwarding does do the maskoff step, it is very efficient while BIER= -TE forwarding does not it the maskoff step so this optimization is importa= nt. >=20 > Ok. I simplified the text comparison BIER/BIER-TE wrt. to the FBM=20 > rules [1] and [2] and added following paragraph: >=20 > In BIER, the order of BPs impacts the result of forwarding because of = [1].=20 > In BIER-TE, forwarding is not impacted by the order of BPs. It is=20 > therefore possible to further optimize forwarding than in BIER. For=20 > example parallelizing forwarding across multiple FPE cores or=20 > distributed linecards does only need to examine an arbitrary subset of=20 > BP and not evaluate the dependency between BPs. >=20 > > > The following pseudocode is comprehensive: > > >=20 > > > The above sentence reads a bit strange (or lacks some segue). > >=20 > > I hope not, but maybe best left to a native english speaker (RFC-editor= ). > >=20 > > The first (RFC8279) pseudocode was simplified. The second one is compre= hensive. If not comprehensive, whats a good opposite of simplified ? > >=20 > > Zzh> Perhaps "The above simplified pseudocode is elaborated further as = following"? > > Zzh> Jeffrey >=20 > Done. >=20 > Thanks a lot.=20 >=20 >=20 > > =20 > > > ________________________________________ > > > From: BIER [bier-bounces@ietf.org] > > > on behalf of Toerless Eckert [tte@cs.fau.de] > > > Sent: Tuesday, July 09, 2019 23:38 > > > To: Mike McBride > > > Cc: Greg Shepherd; BIER WG; Pascal Thubert (pthubert) > > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch > > >=20 > > > Thanks, Mike > > >=20 > > > The authors also reviewed the document and concluded that it was=20 > > > really hard to get into the document context because of too many=20 > > > forward dependencies. We tried to fix this by adding two hopefully=20 > > > good & basic examples into the Introduction section and using them=20 > > > to also add a better definition of the term "BIER-TE Topology" in the= Introduction. > > > Hopefully this makes readin the rest of te document smoother. > > >=20 > > > Also improved text of Abstract and refined text compariing BIER-TE wi= th SR. > > >=20 > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=3Dhtt= ps: > > > **Atools.ietf.org*id*draft-ietf-bier-te-arch-02.txt&url2=3Dhttps:**A > > > tool > > > s.ietf.org*id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R > > > jC81 > > > c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV_eTUEh > > > $ > > > > > **Atools.ietf.org*id*draft-ietf-bier-te-arch-02.txt&url2=3Dhttps:**A > > > tool > > > s.ietf.org*id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R > > > jC81 > > > c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sNd1njcX > > > $> > > >=20 > > > Cheers > > > Toerless > > >=20 > > > On Wed, Jun 26, 2019 at 10:39:36AM -0700, Mike McBride wrote: > > > > How about three? I support. > > > > mike > > > > > > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd > wrote: > > > > > > > > > > We cannot take two 'yes' votes and WG consensus. > > > > > Please, read and respond. If you don't support, then please vote = as much publicly right here. > > > > > > > > > > Thanks, > > > > > Greg > > > > > > > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert (pthubert) > wrote: > > > > >> > > > > >> Support: > > > > >> > > > > >> I see great value in deterministic networks as well as IOT (with= RPL). > > > > >> > > > > >> All the best, > > > > >> > > > > >> Pascal > > > > >> > > > > >> > -----Original Message----- > > > > >> > From: BIER > > > > >> > > On=20 > > > > >> > Behalf Of Toerless Eckert > > > > >> > Sent: mardi 4 juin 2019 02:03 > > > > >> > To: Greg Shepherd > > > > >> > > > > > > >> > Cc: BIER WG > > > > > >> > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch > > > > >> > > > > > >> > +1 > > > > >> > Obviously support as co-author. > > > > >> > > > > > >> > On Wed, May 29, 2019 at 12:41:26PM -0700, Greg Shepherd wrote: > > > > >> > > Please read and respond to this thread w/ or w/o support. > > > > >> > > > > > > >> > > https://urldefense.com/v3/__https://datatracker..ietf.org > > > > >> > > /doc > > > > >> > > /draft-ietf-bier-te-arch/__;!8WoA6RjC81c!XvH4AAxfrDjFoK_s > > > > >> > > ercw ZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV9eClBj$ > > > > >> > > > > > >> > > doc/ > > > > >> > > draft-ietf-bier-te-arch/__;!8WoA6RjC81c!UBTGvWWpMHyeiSanx > > > > >> > > s6vI b_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sD40kmtH$> > > > > >> > > > > > > >> > > Vote ends 5 June 2019. > > > > >> > > > > > > >> > > Thanks, > > > > >> > > Shep > > > > >> > > (chairs) > > > > >> > > > > > >> > > _______________________________________________ > > > > >> > > BIER mailing list > > > > >> > > BIER@ietf.org > > > > >> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/ > > > > >> > > list > > > > >> > > info/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eE > > > > >> > > NOs4 l_qdsXF0KwZD82cJLDFFNT2WVXWX$=20 > > > > >> > > > > > >> > > list > > > > >> > > info/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6b > > > > >> > > oAAW 4nrqju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > >> > > > > > >> > _______________________________________________ > > > > >> > BIER mailing list > > > > >> > BIER@ietf.org > > > > >> > https://urldefense.com/v3/__https://www.ietf.org/mailman/li > > > > >> > stin > > > > >> > fo/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4 > > > > >> > l_qd > > > > >> > sXF0KwZD82cJLDFFNT2WVXWX$ > > > > >> > > > > >> > stin > > > > >> > fo/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW > > > > >> > 4nrq > > > > >> > ju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > > > > > > > _______________________________________________ > > > > > BIER mailing list > > > > > BIER@ietf.org > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listi > > > > > nfo/ > > > > > bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsX > > > > > F0Kw > > > > > ZD82cJLDFFNT2WVXWX$ > > > > > > > > > nfo/ > > > > > bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju > > > > > 8UCL > > > > > OgiuXc8Y_6sKn2KoAT$> > > >=20 > > > -- > > > --- > > > tte@cs.fau.de > > >=20 > > > _______________________________________________ > > > BIER mailing list > > > BIER@ietf.org > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ > > > bier > > > __;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82 > > > cJLD > > > FFNT2WVXWX$ > > > > > bier > > > __;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiu > > > Xc8Y > > > _6sKn2KoAT$> > >=20 > > -- > > --- > > tte@cs.fau.de >=20 > -- > --- > tte@cs.fau.de >=20 > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier > __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx4 > 1_jWV3YUA6D$ -- --- tte@cs.fau.de _______________________________________________ BIER mailing list BIER@ietf.org https://www.ietf.org/mailman/listinfo/bier From nobody Tue Feb 18 14:29:58 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA02120830 for ; Tue, 18 Feb 2020 14:29:56 -0800 (PST) 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, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, 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 nXMHwJXxc6Ek for ; Tue, 18 Feb 2020 14:29:51 -0800 (PST) Received: from mx03.uni-tuebingen.de (mx03.uni-tuebingen.de [134.2.5.213]) (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 B0BF4120836 for ; Tue, 18 Feb 2020 14:29:49 -0800 (PST) Received: from [192.168.1.101] (unknown [149.172.226.226]) by mx03.uni-tuebingen.de (Postfix) with ESMTPSA id 2FDF390D30 for ; Tue, 18 Feb 2020 23:29:47 +0100 (CET) To: bier@ietf.org References: From: Michael Menth Autocrypt: addr=menth@uni-tuebingen.de; prefer-encrypt=mutual; keydata= mQENBFEwuvUBCAC0e0350KZ4gcyRT7ia8iJ/yaSopkvA14XFLnu9ooRFsw7FvYThSQa6mJ0a fZuAqxs4/ymD6pbLEjQWhuHcZyVOWHsuIYtHBGLOmmSCvoYURgJ1w1wJCwH2uA2I8xT/cV3e fwJym09f/Tl71gLopIIzaSZo6T9NG3jGF2D9cfzapp8IOq1iSiBq5Ry+Sq3IPHkUkpcg3Zk6 td6MtlvRQUnK9nIffxG0RKMF28PCAYFwzx4Nj7zsjfYgcTAIt/ld7Ptk1olb9B9l8xVTuojK /s8sk6yZn0LgE0wjABxUCVSB9wMSyZac4f3QHSl5//ZnstjaqDCM0lijrHHnBI8pmVyHABEB AAG0Jk1pY2hhZWwgTWVudGggPG1lbnRoQHVuaS10dWViaW5nZW4uZGU+iQE+BBMBAgAoBQJR MLr1AhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRDxmVdyt1FYm9hyCACz D7Q8imyW9G++j2N97jF9ybcQJ8eCUeiJ20DFy3gAGR/Ic/RB+Y1fsD/1DY2Ahe82iKphp1Fp UK8qhfz+zDVJgz0CyzESyIztOkc1RyhO5295iRG30ClGYaxHHw7/1EbQ8CKEKIAD2WEHIk6I pZkYlBey1uMQLT4LE+nWwrMdo7BDt74rmUpRyWqDHI4J96i/VWKJGbpky5laRwd5hZeVEWGA Blz3/CL7vZzOHLwZduVTs4upZyc2zJHEqQKuHb0+ixs4xaP5yWpQPvacq5+G6IOSawHyDI5T hkRp48yJV519jOWYc/daT0MLHCHK6bt3AK+CfvmBf/ACSS84ravp Message-ID: <9ac4f094-767e-6d2f-72ce-ef693913c253@uni-tuebingen.de> Date: Tue, 18 Feb 2020 23:37:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 22:29:57 -0000 support (as co-author) Michael Am 18.02.2020 um 21:45 schrieb Greg Shepherd: > Thanks Toerless and Jeffrey > > https://datatracker.ietf.org/doc/draft-ietf-bier-te-arch/ > > One more week of WGLC. Please read the latest rev and respond to this > thread w/wo support. > > Chairs > (Shep) > > > On Tue, Feb 18, 2020 at 12:07 PM Jeffrey (Zhaohui) Zhang > > wrote: > > Hi Toerless, > > Thanks! > I support moving this to the next stage. > > Jeffrey > > On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote: > > Thanks Jeff > > > > I have now pushed out -05 with the answers and hopefully > resolution to > > your points in email below.  Biggest addition was a section about > > reuse of BPs (without DNR) which came out of the confusion i think > the > > reuse in the ECMP example raised. I was afraid so far to explan that > > as it may not be easy to absorb and ultimately is stuff only > > controller developers need to understand, but hopefully useful. > > And then of course the summary of BP optimizatins you asked for > > > > Diff from last version i sent you: > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: > > **Araw.githubusercontent.com > *toerless*bier-te-arch*master*draft-ietf-b > > ier-te-arch-05.1.txt&url2=http:**Atools.ietf.org > *id*draft-ietf-bier-te > > -arch-05.txt__;Ly8vLy8vLy8vLy8!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzH > > OCr0fZkLPbgg3CPNu0PyrWsrFx41_jWX2At8V-$ > > > > full -04 -> 05 diff: > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=http:* > > *Atools.ietf.org > *id*draft-ietf-bier-te-arch-04.txt&url2=http:**Atools. > > ietf.org > *id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk > > !VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx41_jWancpziv$ > > > > Comments inline below. > > > > Cheers > >     toerless > > > > On Mon, Oct 28, 2019 at 07:52:59PM +0000, Jeffrey (Zhaohui) Zhang > wrote: > > > I Thought u-turn is the most simple comparison leaf vs. non-leaf > BFR. > > > > > > Zzh> The text in the email is seriously misaligned. Looking at > the picture in the diff link, while you gave a U-turn example, > though even if BFER2 is not connected to BFR2  but only connected to > BFER1 (hence no U-turn), then BFER1 is still not a leaf BFER I > suppose. That's why I said the first sentence of the above paragraph > is enough to define Leaf BFER while the example itself is actually > not needed. > > > > Argh... ok, had to fix two words, BFIR->BFER and left-hand -> > right-hand: > > > > Consider how redundant disjoint traffic can reach BFER1/BFER2 in > above > > picture: When BFER1/BFER2 are Non-Leaf BFER as shown on the right > hand > > side, one traffic copy would be forwarded to BFER1 from BFR1, but the > > other one could only reach BFER1 via BFER2, which makes BFER2 a > > non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forwarding > > traffic to BFER2 > > > > > Zzh> Additionally, in left part of the picture you added, if > some failure leads to BFR2 to be only reachable via BFER1, then > BFER1 is no longer a leaf BFER. > > > > Added sentence: > > > > Note that the BFER in the left hand picture are only guaranteed to > > be leaf-BFR by fitting routing configuration that prohibits transit > > traffic to pass through a PE, which is commonly applied in these > > topologies. > > > > > I assume you don't reassign BPs when links go up and down. > > > > I didn't want to discuss that option in this document. Its obviously > > perfectly feasible, but be yet a big amount of text (especially the > > considerations how to do this make-before-break. Future doc. > > > > > > but subsequent polarization example confuses me. It seems that > BP 0:6 is assigned to the routed adjacency BFR10 (which is actually > talked about in Section 4.8). > > > > > > Section 4.7 does not mention "routed" at all, so there are no > routed adjacencies at all used in 4.7. So i am not sure what you are > confused about. > > > > > > Zzh> "The BIFT of each BFR are only populated with BPs that are > adjacent to the BFR in the BIER-TE topology". > > > > Correct text from the introduction. Ok. > > > > > Zzh> Since the same 0:6 is in BIFTS of BFR1/BFR2/BFR3 (and I > suppose in BFR4~BFR9 as well even though not drawn), I assumed it's > for the "MP2P" routed adjacency to R10; though I then ruled that out > - but I don't know what 0:6 represent now on BFR1, BFR2, and BFR3. > > > > Ah. Ok. I thought i could strip down the example to show only the > > adjacencies relevant to the following discusion, but seemingly this > > can introduce the confusion you have. > > > > So i completed the example with the BP assignment acoss all nodes, > but > > added text pointing to a new section further down to discuss the > > re-use of BP for which thi picture is also an example. > > > > (check out the diff, new reuse text to long to copy inline). > > > > > The whole purpose of the ECMP BPs is of course to save bits, > otherwise we'd give each link a separate BP, which would be 6 BP to > reach to BFR4...BFR7 from BFR1. > > > > > > Zzh> The trouble I am having is that the same 0:6 is assigned to > different things and it's present on all BFR1/BFR2/BFR3. It is > perhaps an intentional smart design but I have not wrapped my mind > around it. It's apparently different from the link bundle case, so > better separate it out and elaborate it (including the DNR flag that > might be needed here - If the packet arrives on BFR1 with 0:6, would > the BP reset when it is sent to BFR2/3)? > > > > Yes, there was the bug of reusing BP 0:6 across sequential BFR along > > the path, but now the example correctly reuses separate BP at > > different stages of the paths (BP 0:6 on BFR1, BP 0:7 on > BFR2/BFR3) and so on. > > > > Thanks! > > > > > > 4.8.  Routed adjacencies > > > > > > > > If I understand it correctly, there is a BP assigned to L1/L2/L3 > > > > respectively (p2p link), and then there are BPs assigned to > MP2P tunnels (routed adjacency from every BFR) to the L1/L2/L3 > interface addresses and loopback addresses on BFR2/3. > > > > > > Ok that wasn't quite the read i expected. Let me clarify the > text/picture: > > > > > >                    ...............      > > >          ...BFR1--...           ...--L1-- BFR2... > > >                   ... .Routers. ...--L2--/  > > >          ...BFR4--...           ...------ BFR3... > > >                    ...............         | > > >                                           LO > > >                     Network Area 1 > > > > > > Assume the requirement in the above picture is to explicitly > steer traffic flows that have arrived at BFR1 or BFR4 via a shortest > path in the routing underlay "network area 1" to one of the > following three next segments: (1) BFR2 via link L1, (2) BFR2 via > link L2, (3) via BFR3. > > > > > > To achieve this, both BFR1 and BFR4 are set up with a > forward_routed adjacency BitPosition towards an address of BFR2 on > link L1, another forward_routed BitPosition towards an address of > BFR2 on link L2 and a third forward_routed Bitposition towards a > node address LO of BFR3. > > > > > > Does this clear ip the confusion ? > > > > > > Zzh> The picture is badly misaligned. I'll wait till 4.7 > questions are cleared. > > > > Ok. > > > > > > If BFR2/3 are also BFERs, then they additionally will have > BFER BPs. > > > > On BFR1/4, the BIFT entries for the MP2P BPs for the > L1/L2/L3/loopback interface addresses of BFR2/3 will use > forward_routed(interface/loopback address). For a packet to be > decapsulated on a BFER, there is a need for both the BFER BP and > another BP (p2p/lan/hub-spoke/routed-adjacency) in the packet (the > former is for decapsulation and the latter is for getting it there). > > > > > > This is not discussed in this section, but you are right - unless > > > BFR2 or BFR3 is a leaf BFR. In that case, it would just leverage > the one shared "leaf-BFR" BP, so they do not need a per-BFER BP for > local_decap(). > > > > > > Zzh> Right - shared leaf-BFR BP but still need that BP (the key > is that we need a BP to get packet to a BFER and then a BP for > decapsulation). > > > > You got it. > > > > > > If that???s the case, it???s worth point the above out. > > > > > > Hmm... The logic of BFER BPs is totally independent of the logic > of forward_routed adjacency, so i would worry that repeating the > explanation of BFER BPs would conflate the forward_routed explanation. > > > > > > Zzh> It's just that this is a place where all kinds of BPs are > used so it's good to have a summary (could be a subsection 4.9). > > > > Yes, added such a summary. Pls. check. > > > > > > Actually, the reason that I thought this is MP2P is that 0:6 > is present on R1, R2, and R3 (and more I assume) in Figure 12, but > now I think it can???t be MP2P (so it is not correct to have 0:6 > present on those routers ??? only the p2p tunnel head/tail should > have the BP present in the BIFT). The reason is that if it were > MP2P, any router getting a copy will send it to the endpoint of the > routed adjacency, causing lots of duplicates.. > > > > > > > > Am I getting this correct? > > > > > > I think you are still explaining from the misunderstsanding that > the ECMP explanations where about routed adjacencies. > > > > > > I have now expanded the somewhat terse text in the BIFT table > pictures, to make it clear that the ECMP is across multipe > forward_connected adjacencies in the examples. For example, first > BIFT picture: > > > > > >   BIFT entry in BFR1: > > >   ------------------------------------------------------------------ > > >   | Index |  Adjacencies                                           | > > >   ================================================================== > > >   | 0:6   |  ECMP({forward_connected(L1, BFR2),                    | > > >   |       |        forward_connected(L2, BFR2),                    | > > >   |       |        forward_connected(L3, BFR2)}, seed)             | > > >   ------------------------------------------------------------------ > > > > > > Of course, an ECMP adjacency can be across any type of > adjacencies, but all the text/explanations used forward_connected, > and now the pictures show that explicitly. > > > > > > Zzh> I can understand the multi-link case, but the multi-hop > ECMP case (from BFR1 towards BFR10) is confusing me. It would help > to give an example how it can be used, WITHOUT worrying about > polarization. > > > > Please check -05 text that has the full set of BIFT listed now: > > > > There is  really nothing nothing unique in multi-hop ECMP for BIER-TE > > that we do not also have in any other ECMP, except the conclusion > that > > we want to support fast HW hash mechanisms AND allow the > controller to > > set up non-polarized multi-hop ECMP AND be able to precalculate > paths. > > Hence the specification of ECMP adjacencies to have a controller > > configurable seed. > > > > Btw: The picture is maybe unnecessarily large because i've used it > for > > 20 years to explain the same polarization issue for unicast vs > > multicast, and for multicast only BFR10...BFR4 are relevant (ECMP of > > the PIM/mLDP joins), whereas for unicast/BIER only > > BFR1...BFR7 are relevant. But being symmetric, the picture makes it > > clear its the same problem. > > > > > >    To inhibit looping in the face of such physical > misconfiguration, > > > >    only forward_connected adjacencies are permitted to have > DNR set, and > > > >    the link layer destination address of the adjacency (e.g.  MAC > > > >    address) protects against closing the loop.  Link layers > without port > > > >    unique link layer addresses should not be used with the DNR > flag set. > > > > > > > > It???s not clear how link layer address helps? > > > > > > I have expanded this to > > > "link layer port unique unicast destination address" > > > > > > Aka: MPLS or ethernet have unique link layer destination > destination addresses (label or destination MAC). If you think about > incorrectly plugged HDLC links (such as old T1/T3/... links), they > only have 2 generic addresses, if i remember 1 or 3 in the HDLC > frame. So when you misplug one of those p2p cables wrong, the > packets would be incrrectly received by the wrong receiver node and > then DNR could cause persistent loops only solved by TTL. > > > > > > Zzh> "Consider in the ring picture that link L4 from BFR3 is > plugged into the L1 interface of BFRa" - still not sure how > label/mac helps here. I suppose the ring topology is > discovered/verified by the control plane and when the miscalling > happens then the ring will not include the BFR1/BFR2 part and BFR3 > will not have the DNR set? If ring discovery/varication is not done > then perhaps we should point out that RPF based on link layer > address is needed - the key is RPF (which needs unique link layer > address)? > > > > Forget RPF. BIER(-TE) has no RPF (issues). Its just like unicast. RPF > > is just a problem for receiver originated joins like in PIM/mLDP, but > > not unicast/bier(-te)/RSVP-TE. > > > > Forward_connected is just like a unicast subnet adjacency to a direct > > neighbor: Interface and L2 addresss of the destination. > > > > The controller (could be a human) "assumes" a particular physicial > > topology, from telemetry/knowledge/whatever. It then calculates the > > desired BIER-TE topology and pushes it down. This topology is > meant to > > be loop free of course wrt to the configured adjacencies. > > In this BIER-TE topology, BFR3 will have a BP with the > > forward_connected(L4, MAC-of-BFR2) adjacency. > > > > If the cable connecting to L4 is miswired, then BFR3 would still send > > the packets to the MAC address of BFR2, but given how the cable > > connects to some other node, these packets will be discarded by that > > node. because they're just L2 unicast packets. > > > > I think this is equally true when we have normal BIER/MPLS enacp. > > Those packets too are addressed to the unicast MAC address of the > > neighbor. > > > > Now, if/when he controller recognizes that the physical topology has > > changed, thats a completely different story and not addressed here. > > Given how we assumed this was a cabling mistake, the controller would > > probably only complain about the miswiring to operations but be happy > > that the forwarding plane just makes packets fail instead of loop. If > > this was a planned change process, then it will be similarily > > convoluted as it would today be with rewiring cables in an > > SR-MPLS/SRv6 topology and updating SIDs. > > > > > > Because the forwarding is different from BIER forwarding > (because of [1] above), we might as well introduce an optimization > here ??? for each BIFT, calculate the F-BM of the BIFT itself (the > logical ???or??? of all the BPs presented in this BIFT) and then use > (packet->bitstring & BIFT.F-BM) as the input to > GetFirst/NextBitPosition(). That should skip many bits. > > > > > > Right. But i explicitly removed those optimizations (i had them > in older draft versions) because the whole idea of this picture is > solely the comparison with figure 4 of RFC8279. > > > > > > Zzh> I think it's worth point that optimization out; you can > mark it optional if you want to emphasize the similarity to BIER > forwarding, but since BIER forwarding does do the maskoff step, it > is very efficient while BIER-TE forwarding does not it the maskoff > step so this optimization is important. > > > > Ok. I simplified the text comparison BIER/BIER-TE wrt. to the FBM > > rules [1] and [2] and added following paragraph: > > > > In BIER, the order of BPs impacts the result of forwarding > because of [1]. > > In BIER-TE, forwarding is not impacted by the order of BPs. It is > > therefore possible to further optimize forwarding than in BIER. For > > example parallelizing forwarding across multiple FPE cores or > > distributed linecards does only need to examine an arbitrary > subset of > > BP and not evaluate the dependency between BPs. > > > > > >    The following pseudocode is comprehensive: > > > > > > > > The above sentence reads a bit strange (or lacks some segue).. > > > > > > I hope not, but maybe best left to a native english speaker > (RFC-editor). > > > > > > The first (RFC8279) pseudocode was simplified. The second one is > comprehensive. If not comprehensive, whats a good opposite of > simplified ? > > > > > > Zzh> Perhaps "The above simplified pseudocode is elaborated > further as following"? > > > Zzh> Jeffrey > > > > Done. > > > > Thanks a lot. > > > > > > >    > > > > ________________________________________ > > > > From: BIER [bier-bounces@ietf.org > >] > > > > on behalf of Toerless Eckert [tte@cs.fau.de > >] > > > > Sent: Tuesday, July 09, 2019 23:38 > > > > To: Mike McBride > > > > Cc: Greg Shepherd; BIER WG; Pascal Thubert (pthubert) > > > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch > > > > > > > > Thanks, Mike > > > > > > > > The authors also reviewed the document and concluded that it was > > > > really hard to get into the document context because of too many > > > > forward dependencies. We tried to fix this by adding two > hopefully > > > > good & basic examples into the Introduction section and using > them > > > > to also add a better definition of the term "BIER-TE Topology" > in the Introduction. > > > > Hopefully this makes readin the rest of te document smoother.. > > > > > > > > Also improved text of Abstract and refined text compariing > BIER-TE with SR. > > > > > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: > > > > **Atools.ietf.org > *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A > > > > tool > > > > s.ietf.org > *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R > > > > jC81 > > > > c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV_eTUEh > > > > $ > > > > > > > > **Atools.ietf.org > *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A > > > > tool > > > > s.ietf.org > *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R > > > > jC81 > > > > c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sNd1njcX > > > > $> > > > > > > > > Cheers > > > >     Toerless > > > > > > > > On Wed, Jun 26, 2019 at 10:39:36AM -0700, Mike McBride wrote: > > > > > How about three? I support. > > > > > mike > > > > > > > > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd > >> wrote: > > > > > > > > > > > > We cannot take two 'yes' votes and WG consensus. > > > > > > Please, read and respond. If you don't support, then > please vote as much publicly right here. > > > > > > > > > > > > Thanks, > > > > > > Greg > > > > > > > > > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert (pthubert) > >> wrote: > > > > > >> > > > > > >> Support: > > > > > >> > > > > > >> I see great value in deterministic networks as well as > IOT (with RPL). > > > > > >> > > > > > >> All the best, > > > > > >> > > > > > >> Pascal > > > > > >> > > > > > >> > -----Original Message----- > > > > > >> > From: BIER > > > > > >> > >> On > > > > > >> > Behalf Of Toerless Eckert > > > > > >> > Sent: mardi 4 juin 2019 02:03 > > > > > >> > To: Greg Shepherd > > > > > >> > >> > > > > > >> > Cc: BIER WG >> > > > > > >> > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch > > > > > >> > > > > > > >> > +1 > > > > > >> > Obviously support as co-author. > > > > > >> > > > > > > >> > On Wed, May 29, 2019 at 12:41:26PM -0700, Greg Shepherd > wrote: > > > > > >> > > Please read and respond to this thread w/ or w/o support. > > > > > >> > > > > > > > >> > > https://urldefense.com/v3/__https://datatracker..ietf.org > > > > > >> > > /doc > > > > > >> > > /draft-ietf-bier-te-arch/__;!8WoA6RjC81c!XvH4AAxfrDjFoK_s > > > > > >> > > ercw ZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV9eClBj$ > > > > > >> > > > > > > >> > > doc/ > > > > > >> > > draft-ietf-bier-te-arch/__;!8WoA6RjC81c!UBTGvWWpMHyeiSanx > > > > > >> > > s6vI b_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sD40kmtH$> > > > > > >> > > > > > > > >> > > Vote ends 5 June 2019. > > > > > >> > > > > > > > >> > > Thanks, > > > > > >> > > Shep > > > > > >> > > (chairs) > > > > > >> > > > > > > >> > > _______________________________________________ > > > > > >> > > BIER mailing list > > > > > >> > > BIER@ietf.org > > > > > > > >> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/ > > > > > >> > > list > > > > > >> > > info/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eE > > > > > >> > > NOs4 l_qdsXF0KwZD82cJLDFFNT2WVXWX$ > > > > > >> > > > > > > >> > > list > > > > > >> > > info/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6b > > > > > >> > > oAAW 4nrqju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > > >> > > > > > > >> > _______________________________________________ > > > > > >> > BIER mailing list > > > > > >> > BIER@ietf.org > > > > > > > >> > https://urldefense.com/v3/__https://www.ietf.org/mailman/li > > > > > >> > stin > > > > > >> > fo/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4 > > > > > >> > l_qd > > > > > >> > sXF0KwZD82cJLDFFNT2WVXWX$ > > > > > >> > > > > > >> > stin > > > > > >> > fo/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW > > > > > >> > 4nrq > > > > > >> > ju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > > > > > > > > > _______________________________________________ > > > > > > BIER mailing list > > > > > > BIER@ietf.org > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listi > > > > > > > nfo/ > > > > > > bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsX > > > > > > F0Kw > > > > > > ZD82cJLDFFNT2WVXWX$ > > > > > > > > > > > nfo/ > > > > > > bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju > > > > > > 8UCL > > > > > > OgiuXc8Y_6sKn2KoAT$> > > > > > > > > -- > > > > --- > > > > tte@cs.fau.de > > > > > > > > > _______________________________________________ > > > > BIER mailing list > > > > BIER@ietf..org > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ > > > > bier > > > > __;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82 > > > > cJLD > > > > FFNT2WVXWX$ > > > > > > > bier > > > > __;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiu > > > > Xc8Y > > > > _6sKn2KoAT$> > > > > > > -- > > > --- > > > tte@cs.fau.de > > > > -- > > --- > > tte@cs.fau.de > > > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier > > __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx4 > > 1_jWV3YUA6D$ > > -- > --- > tte@cs.fau.de > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://kn.inf.uni-tuebingen.de From nobody Tue Feb 18 16:50:06 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58207120861 for ; Tue, 18 Feb 2020 16:50:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_RED=0.001] autolearn=unavailable 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 6kjnsFL8HdzR for ; Tue, 18 Feb 2020 16:49:56 -0800 (PST) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15F4C120872 for ; Tue, 18 Feb 2020 16:49:54 -0800 (PST) Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id E3DD1FAB70F4228C7DFA; Wed, 19 Feb 2020 08:49:51 +0800 (CST) Received: from njxapp05.zte.com.cn ([10.41.132.204]) by mse-fl2.zte.com.cn with SMTP id 01J0nUMD064785; Wed, 19 Feb 2020 08:49:30 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn) Received: from mapi (njxapp05[null]) by mapi (Zmail) with MAPI id mid203; Wed, 19 Feb 2020 08:49:30 +0800 (CST) Date: Wed, 19 Feb 2020 08:49:30 +0800 (CST) X-Zmail-TransId: 2afd5e4c861ab046ccff X-Mailer: Zmail v1.0 Message-ID: <202002190849302862887@zte.com.cn> In-Reply-To: References: MN2PR05MB598175BB2DD63200BB91DF2CD4110@MN2PR05MB5981.namprd05.prod.outlook.com, CABFReBpXjpzdLTp9Ygnd9PjSSTKdWO664aVutgV-dgC3EJzZRA@mail.gmail.com Mime-Version: 1.0 From: To: Cc: , , Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-fl2.zte.com.cn 01J0nUMD064785 Archived-At: Subject: Re: [Bier] =?utf-8?q?WGLC_-_draft-ietf-bier-te-arch_1_WEEK?= X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 00:50:06 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 U3VwcG9ydC4NCg0KDQoNCg0KDQoNClRoYW5rcywNCg0KDQpTYW5keQ0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0K5Y6f5aeL6YKu5Lu2DQoNCg0KDQrlj5Hku7bkurrvvJpHcmVn U2hlcGhlcmQgPGdqc2hlcEBnbWFpbC5jb20+DQrmlLbku7bkurrvvJpKZWZmcmV5IChaaGFvaHVp KSBaaGFuZyA8enpoYW5nPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc+Ow0K5oqE6YCB5Lq6 77yaYmllckBpZXRmLm9yZyA8YmllckBpZXRmLm9yZz47VG9lcmxlc3MgRWNrZXJ0IDx0dGVAY3Mu ZmF1LmRlPjsNCuaXpSDmnJ8g77yaMjAyMOW5tDAy5pyIMTnml6UgMDQ6NDYNCuS4uyDpopgg77ya W0JpZXJdIFdHTEMgLSBkcmFmdC1pZXRmLWJpZXItdGUtYXJjaCAxIFdFRUsNCg0KDQoNCg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkJJRVIgbWFpbGlu ZyBsaXN0DQpCSUVSQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2JpZXINCg0KDQpUaGFua3MgVG9lcmxlc3MgYW5kIEplZmZyZXkNCg0KDQpodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWJpZXItdGUtYXJjaC8NCg0KDQoNCk9u ZSBtb3JlIHdlZWsgb2YgV0dMQy4gUGxlYXNlIHJlYWQgdGhlIGxhdGVzdCByZXYgYW5kIHJlc3Bv bmQgdG8gdGhpcyB0aHJlYWQgdy93byBzdXBwb3J0Lg0KDQoNCkNoYWlycw0KKFNoZXApDQoNCg0K DQoNCg0KT24gVHVlLCBGZWIgMTgsIDIwMjAgYXQgMTI6MDcgUE0gSmVmZnJleSAoWmhhb2h1aSkg WmhhbmcgPHp6aGFuZz00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPiB3cm90ZToNCg0KSGkg VG9lcmxlc3MsDQoNClRoYW5rcyENCkkgc3VwcG9ydCBtb3ZpbmcgdGhpcyB0byB0aGUgbmV4dCBz dGFnZS4NCg0KSmVmZnJleQ0KDQpPbiBGcmksIE5vdiAwMSwgMjAxOSBhdCAwNzo0MjozOFBNICsw MTAwLCBUb2VybGVzcyBFY2tlcnQgd3JvdGU6DQo+IFRoYW5rcyBKZWZmDQo+IA0KPiBJIGhhdmUg bm93IHB1c2hlZCBvdXQgLTA1IHdpdGggdGhlIGFuc3dlcnMgYW5kIGhvcGVmdWxseSByZXNvbHV0 aW9uIHRvIA0KPiB5b3VyIHBvaW50cyBpbiBlbWFpbCBiZWxvdy4gIEJpZ2dlc3QgYWRkaXRpb24g d2FzIGEgc2VjdGlvbiBhYm91dCANCj4gcmV1c2Ugb2YgQlBzICh3aXRob3V0IEROUikgd2hpY2gg Y2FtZSBvdXQgb2YgdGhlIGNvbmZ1c2lvbiBpIHRoaW5rIHRoZSANCj4gcmV1c2UgaW4gdGhlIEVD TVAgZXhhbXBsZSByYWlzZWQuIEkgd2FzIGFmcmFpZCBzbyBmYXIgdG8gZXhwbGFuIHRoYXQgDQo+ IGFzIGl0IG1heSBub3QgYmUgZWFzeSB0byBhYnNvcmIgYW5kIHVsdGltYXRlbHkgaXMgc3R1ZmYg b25seSANCj4gY29udHJvbGxlciBkZXZlbG9wZXJzIG5lZWQgdG8gdW5kZXJzdGFuZCwgYnV0IGhv cGVmdWxseSB1c2VmdWwuDQo+IEFuZCB0aGVuIG9mIGNvdXJzZSB0aGUgc3VtbWFyeSBvZiBCUCBv cHRpbWl6YXRpbnMgeW91IGFza2VkIGZvcg0KPiANCj4gRGlmZiBmcm9tIGxhc3QgdmVyc2lvbiBp IHNlbnQgeW91Og0KPiANCj4gaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHA6Ly90b29s cy5pZXRmLm9yZy8qcmZjZGlmZj91cmwxPWh0dHBzOg0KPiAqKkFyYXcuZ2l0aHVidXNlcmNvbnRl bnQuY29tKnRvZXJsZXNzKmJpZXItdGUtYXJjaCptYXN0ZXIqZHJhZnQtaWV0Zi1iDQo+IGllci10 ZS1hcmNoLTA1LjEudHh0JnVybDI9aHR0cDoqKkF0b29scy5pZXRmLm9yZyppZCpkcmFmdC1pZXRm LWJpZXItdGUNCj4gLWFyY2gtMDUudHh0X187THk4dkx5OHZMeTh2THk4ISFORXQ2eU1hTy1nayFW dVFDVkhucUp5X2FZSS1GTnQ5QTFhNUV6SA0KPiBPQ3IwZlprTFBiZ2czQ1BOdTBQeXJXc3JGeDQx X2pXWDJBdDhWLSQNCj4gDQo+IGZ1bGwgLTA0IC0+IDA1IGRpZmY6DQo+IA0KPiBodHRwczovL3Vy bGRlZmVuc2UuY29tL3YzL19faHR0cDovL3Rvb2xzLmlldGYub3JnLypyZmNkaWZmP3VybDE9aHR0 cDoqDQo+ICpBdG9vbHMuaWV0Zi5vcmcqaWQqZHJhZnQtaWV0Zi1iaWVyLXRlLWFyY2gtMDQudHh0 JnVybDI9aHR0cDoqKkF0b29scy4NCj4gaWV0Zi5vcmcqaWQqZHJhZnQtaWV0Zi1iaWVyLXRlLWFy Y2gtMDUudHh0X187THk4dkx5OHZMeTh2ISFORXQ2eU1hTy1naw0KPiAhVnVRQ1ZIbnFKeV9hWUkt Rk50OUExYTVFekhPQ3IwZlprTFBiZ2czQ1BOdTBQeXJXc3JGeDQxX2pXYW5jcHppdiQNCj4gDQo+ IENvbW1lbnRzIGlubGluZSBiZWxvdy4NCj4gDQo+IENoZWVycw0KPiAgICAgdG9lcmxlc3MNCj4g DQo+IE9uIE1vbiwgT2N0IDI4LCAyMDE5IGF0IDA3OjUyOjU5UE0gKzAwMDAsIEplZmZyZXkgKFpo YW9odWkpIFpoYW5nIHdyb3RlOg0KPiA+IEkgVGhvdWdodCB1LXR1cm4gaXMgdGhlIG1vc3Qgc2lt cGxlIGNvbXBhcmlzb24gbGVhZiB2cy4gbm9uLWxlYWYgQkZSLg0KPiA+IA0KPiA+IFp6aD4gVGhl IHRleHQgaW4gdGhlIGVtYWlsIGlzIHNlcmlvdXNseSBtaXNhbGlnbmVkLiBMb29raW5nIGF0IHRo ZSBwaWN0dXJlIGluIHRoZSBkaWZmIGxpbmssIHdoaWxlIHlvdSBnYXZlIGEgVS10dXJuIGV4YW1w bGUsIHRob3VnaCBldmVuIGlmIEJGRVIyIGlzIG5vdCBjb25uZWN0ZWQgdG8gQkZSMiAgYnV0IG9u bHkgY29ubmVjdGVkIHRvIEJGRVIxIChoZW5jZSBubyBVLXR1cm4pLCB0aGVuIEJGRVIxIGlzIHN0 aWxsIG5vdCBhIGxlYWYgQkZFUiBJIHN1cHBvc2UuIFRoYXQncyB3aHkgSSBzYWlkIHRoZSBmaXJz dCBzZW50ZW5jZSBvZiB0aGUgYWJvdmUgcGFyYWdyYXBoIGlzIGVub3VnaCB0byBkZWZpbmUgTGVh ZiBCRkVSIHdoaWxlIHRoZSBleGFtcGxlIGl0c2VsZiBpcyBhY3R1YWxseSBub3QgbmVlZGVkLg0K PiANCj4gQXJnaC4uLiBvaywgaGFkIHRvIGZpeCB0d28gd29yZHMsIEJGSVItPkJGRVIgYW5kIGxl ZnQtaGFuZCAtPiByaWdodC1oYW5kOg0KPiANCj4gQ29uc2lkZXIgaG93IHJlZHVuZGFudCBkaXNq b2ludCB0cmFmZmljIGNhbiByZWFjaCBCRkVSMS9CRkVSMiBpbiBhYm92ZSANCj4gcGljdHVyZTog V2hlbiBCRkVSMS9CRkVSMiBhcmUgTm9uLUxlYWYgQkZFUiBhcyBzaG93biBvbiB0aGUgcmlnaHQg aGFuZCANCj4gc2lkZSwgb25lIHRyYWZmaWMgY29weSB3b3VsZCBiZSBmb3J3YXJkZWQgdG8gQkZF UjEgZnJvbSBCRlIxLCBidXQgdGhlIA0KPiBvdGhlciBvbmUgY291bGQgb25seSByZWFjaCBCRkVS MSB2aWEgQkZFUjIsIHdoaWNoIG1ha2VzIEJGRVIyIGEgDQo+IG5vbi1MZWFmIEJGRVIuIExpa2V3 aXNlIEJGRVIxIGlzIGEgbm9uLUxlYWYgQkZFUiB3aGVuIGZvcndhcmRpbmcgDQo+IHRyYWZmaWMg dG8gQkZFUjINCj4gDQo+ID4gWnpoPiBBZGRpdGlvbmFsbHksIGluIGxlZnQgcGFydCBvZiB0aGUg cGljdHVyZSB5b3UgYWRkZWQsIGlmIHNvbWUgZmFpbHVyZSBsZWFkcyB0byBCRlIyIHRvIGJlIG9u bHkgcmVhY2hhYmxlIHZpYSBCRkVSMSwgdGhlbiBCRkVSMSBpcyBubyBsb25nZXIgYSBsZWFmIEJG RVIuIA0KPiANCj4gQWRkZWQgc2VudGVuY2U6DQo+IA0KPiA8dD5Ob3RlIHRoYXQgdGhlIEJGRVIg aW4gdGhlIGxlZnQgaGFuZCBwaWN0dXJlIGFyZSBvbmx5IGd1YXJhbnRlZWQgdG8gDQo+IGJlIGxl YWYtQkZSIGJ5IGZpdHRpbmcgcm91dGluZyBjb25maWd1cmF0aW9uIHRoYXQgcHJvaGliaXRzIHRy YW5zaXQgDQo+IHRyYWZmaWMgdG8gcGFzcyB0aHJvdWdoIGEgUEUsIHdoaWNoIGlzIGNvbW1vbmx5 IGFwcGxpZWQgaW4gdGhlc2UgDQo+IHRvcG9sb2dpZXMuPC90Pg0KPiANCj4gPiBJIGFzc3VtZSB5 b3UgZG9uJ3QgcmVhc3NpZ24gQlBzIHdoZW4gbGlua3MgZ28gdXAgYW5kIGRvd24uDQo+IA0KPiBJ IGRpZG4ndCB3YW50IHRvIGRpc2N1c3MgdGhhdCBvcHRpb24gaW4gdGhpcyBkb2N1bWVudC4gSXRz IG9idmlvdXNseSANCj4gcGVyZmVjdGx5IGZlYXNpYmxlLCBidXQgYmUgeWV0IGEgYmlnIGFtb3Vu dCBvZiB0ZXh0IChlc3BlY2lhbGx5IHRoZSANCj4gY29uc2lkZXJhdGlvbnMgaG93IHRvIGRvIHRo aXMgbWFrZS1iZWZvcmUtYnJlYWsuIEZ1dHVyZSBkb2MuDQo+IA0KPiA+ID4gYnV0IHN1YnNlcXVl bnQgcG9sYXJpemF0aW9uIGV4YW1wbGUgY29uZnVzZXMgbWUuIEl0IHNlZW1zIHRoYXQgQlAgMDo2 IGlzIGFzc2lnbmVkIHRvIHRoZSByb3V0ZWQgYWRqYWNlbmN5IEJGUjEwICh3aGljaCBpcyBhY3R1 YWxseSB0YWxrZWQgYWJvdXQgaW4gU2VjdGlvbiA0LjgpLg0KPiA+IA0KPiA+IFNlY3Rpb24gNC43 IGRvZXMgbm90IG1lbnRpb24gInJvdXRlZCIgYXQgYWxsLCBzbyB0aGVyZSBhcmUgbm8gcm91dGVk IGFkamFjZW5jaWVzIGF0IGFsbCB1c2VkIGluIDQuNy4gU28gaSBhbSBub3Qgc3VyZSB3aGF0IHlv dSBhcmUgY29uZnVzZWQgYWJvdXQuDQo+ID4gDQo+ID4gWnpoPiAiVGhlIEJJRlQgb2YgZWFjaCBC RlIgYXJlIG9ubHkgcG9wdWxhdGVkIHdpdGggQlBzIHRoYXQgYXJlIGFkamFjZW50IHRvIHRoZSBC RlIgaW4gdGhlIEJJRVItVEUgdG9wb2xvZ3kiLg0KPiANCj4gQ29ycmVjdCB0ZXh0IGZyb20gdGhl IGludHJvZHVjdGlvbi4gT2suDQo+IA0KPiA+IFp6aD4gU2luY2UgdGhlIHNhbWUgMDo2IGlzIGlu IEJJRlRTIG9mIEJGUjEvQkZSMi9CRlIzIChhbmQgSSBzdXBwb3NlIGluIEJGUjR+QkZSOSBhcyB3 ZWxsIGV2ZW4gdGhvdWdoIG5vdCBkcmF3biksIEkgYXNzdW1lZCBpdCdzIGZvciB0aGUgIk1QMlAi IHJvdXRlZCBhZGphY2VuY3kgdG8gUjEwOyB0aG91Z2ggSSB0aGVuIHJ1bGVkIHRoYXQgb3V0IC0g YnV0IEkgZG9uJ3Qga25vdyB3aGF0IDA6NiByZXByZXNlbnQgbm93IG9uIEJGUjEsIEJGUjIsIGFu ZCBCRlIzLg0KPiANCj4gQWguIE9rLiBJIHRob3VnaHQgaSBjb3VsZCBzdHJpcCBkb3duIHRoZSBl eGFtcGxlIHRvIHNob3cgb25seSB0aGUgDQo+IGFkamFjZW5jaWVzIHJlbGV2YW50IHRvIHRoZSBm b2xsb3dpbmcgZGlzY3VzaW9uLCBidXQgc2VlbWluZ2x5IHRoaXMgDQo+IGNhbiBpbnRyb2R1Y2Ug dGhlIGNvbmZ1c2lvbiB5b3UgaGF2ZS4NCj4gDQo+IFNvIGkgY29tcGxldGVkIHRoZSBleGFtcGxl IHdpdGggdGhlIEJQIGFzc2lnbm1lbnQgYWNvc3MgYWxsIG5vZGVzLCBidXQgDQo+IGFkZGVkIHRl eHQgcG9pbnRpbmcgdG8gYSBuZXcgc2VjdGlvbiBmdXJ0aGVyIGRvd24gdG8gZGlzY3VzcyB0aGUg DQo+IHJlLXVzZSBvZiBCUCBmb3Igd2hpY2ggdGhpIHBpY3R1cmUgaXMgYWxzbyBhbiBleGFtcGxl Lg0KPiANCj4gKGNoZWNrIG91dCB0aGUgZGlmZiwgbmV3IHJldXNlIHRleHQgdG8gbG9uZyB0byBj b3B5IGlubGluZSkuDQo+IA0KPiA+IFRoZSB3aG9sZSBwdXJwb3NlIG9mIHRoZSBFQ01QIEJQcyBp cyBvZiBjb3Vyc2UgdG8gc2F2ZSBiaXRzLCBvdGhlcndpc2Ugd2UnZCBnaXZlIGVhY2ggbGluayBh IHNlcGFyYXRlIEJQLCB3aGljaCB3b3VsZCBiZSA2IEJQIHRvIHJlYWNoIHRvIEJGUjQuLi5CRlI3 IGZyb20gQkZSMS4gDQo+ID4gDQo+ID4gWnpoPiBUaGUgdHJvdWJsZSBJIGFtIGhhdmluZyBpcyB0 aGF0IHRoZSBzYW1lIDA6NiBpcyBhc3NpZ25lZCB0byBkaWZmZXJlbnQgdGhpbmdzIGFuZCBpdCdz IHByZXNlbnQgb24gYWxsIEJGUjEvQkZSMi9CRlIzLiBJdCBpcyBwZXJoYXBzIGFuIGludGVudGlv bmFsIHNtYXJ0IGRlc2lnbiBidXQgSSBoYXZlIG5vdCB3cmFwcGVkIG15IG1pbmQgYXJvdW5kIGl0 LiBJdCdzIGFwcGFyZW50bHkgZGlmZmVyZW50IGZyb20gdGhlIGxpbmsgYnVuZGxlIGNhc2UsIHNv IGJldHRlciBzZXBhcmF0ZSBpdCBvdXQgYW5kIGVsYWJvcmF0ZSBpdCAoaW5jbHVkaW5nIHRoZSBE TlIgZmxhZyB0aGF0IG1pZ2h0IGJlIG5lZWRlZCBoZXJlIC0gSWYgdGhlIHBhY2tldCBhcnJpdmVz IG9uIEJGUjEgd2l0aCAwOjYsIHdvdWxkIHRoZSBCUCByZXNldCB3aGVuIGl0IGlzIHNlbnQgdG8g QkZSMi8zKT8NCj4gDQo+IFllcywgdGhlcmUgd2FzIHRoZSBidWcgb2YgcmV1c2luZyBCUCAwOjYg YWNyb3NzIHNlcXVlbnRpYWwgQkZSIGFsb25nIA0KPiB0aGUgcGF0aCwgYnV0IG5vdyB0aGUgZXhh bXBsZSBjb3JyZWN0bHkgcmV1c2VzIHNlcGFyYXRlIEJQIGF0IA0KPiBkaWZmZXJlbnQgc3RhZ2Vz IG9mIHRoZSBwYXRocyAoQlAgMDo2IG9uIEJGUjEsIEJQIDA6NyBvbiBCRlIyL0JGUjMpIGFuZCBz byBvbi4NCj4gDQo+IFRoYW5rcyENCj4gDQo+ID4gPiA0LjguICBSb3V0ZWQgYWRqYWNlbmNpZXMN Cj4gPiA+IA0KPiA+ID4gSWYgSSB1bmRlcnN0YW5kIGl0IGNvcnJlY3RseSwgdGhlcmUgaXMgYSBC UCBhc3NpZ25lZCB0byBMMS9MMi9MMyANCj4gPiA+IHJlc3BlY3RpdmVseSAocDJwIGxpbmspLCBh bmQgdGhlbiB0aGVyZSBhcmUgQlBzIGFzc2lnbmVkIHRvIE1QMlAgdHVubmVscyAocm91dGVkIGFk amFjZW5jeSBmcm9tIGV2ZXJ5IEJGUikgdG8gdGhlIEwxL0wyL0wzIGludGVyZmFjZSBhZGRyZXNz ZXMgYW5kIGxvb3BiYWNrIGFkZHJlc3NlcyBvbiBCRlIyLzMuDQo+ID4gDQo+ID4gT2sgdGhhdCB3 YXNuJ3QgcXVpdGUgdGhlIHJlYWQgaSBleHBlY3RlZC4gTGV0IG1lIGNsYXJpZnkgdGhlIHRleHQv cGljdHVyZToNCj4gPiANCj4gPiAgICAgICAgICAgICAgICAgICAgLi4uLi4uLi4uLi4uLi4uICAg ICANCj4gPiAgICAgICAgICAuLi5CRlIxLS0uLi4gICAgICAgICAgIC4uLi0tTDEtLSBCRlIyLi4u DQo+ID4gICAgICAgICAgICAgICAgICAgLi4uIC5Sb3V0ZXJzLiAuLi4tLUwyLS0vICANCj4gPiAg ICAgICAgICAuLi5CRlI0LS0uLi4gICAgICAgICAgIC4uLi0tLS0tLSBCRlIzLi4uDQo+ID4gICAg ICAgICAgICAgICAgICAgIC4uLi4uLi4uLi4uLi4uLiAgICAgICAgIHwNCj4gPiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBMTw0KPiA+ICAgICAgICAgICAgICAgICAg ICAgTmV0d29yayBBcmVhIDENCj4gPiANCj4gPiBBc3N1bWUgdGhlIHJlcXVpcmVtZW50IGluIHRo ZSBhYm92ZSBwaWN0dXJlIGlzIHRvIGV4cGxpY2l0bHkgc3RlZXIgdHJhZmZpYyBmbG93cyB0aGF0 IGhhdmUgYXJyaXZlZCBhdCBCRlIxIG9yIEJGUjQgdmlhIGEgc2hvcnRlc3QgcGF0aCBpbiB0aGUg cm91dGluZyB1bmRlcmxheSAibmV0d29yayBhcmVhIDEiIHRvIG9uZSBvZiB0aGUgZm9sbG93aW5n IHRocmVlIG5leHQgc2VnbWVudHM6ICgxKSBCRlIyIHZpYSBsaW5rIEwxLCAoMikgQkZSMiB2aWEg bGluayBMMiwgKDMpIHZpYSBCRlIzLg0KPiA+IA0KPiA+IFRvIGFjaGlldmUgdGhpcywgYm90aCBC RlIxIGFuZCBCRlI0IGFyZSBzZXQgdXAgd2l0aCBhIGZvcndhcmRfcm91dGVkIGFkamFjZW5jeSBC aXRQb3NpdGlvbiB0b3dhcmRzIGFuIGFkZHJlc3Mgb2YgQkZSMiBvbiBsaW5rIEwxLCBhbm90aGVy IGZvcndhcmRfcm91dGVkIEJpdFBvc2l0aW9uIHRvd2FyZHMgYW4gYWRkcmVzcyBvZiBCRlIyIG9u IGxpbmsgTDIgYW5kIGEgdGhpcmQgZm9yd2FyZF9yb3V0ZWQgQml0cG9zaXRpb24gdG93YXJkcyBh IG5vZGUgYWRkcmVzcyBMTyBvZiBCRlIzLg0KPiA+IA0KPiA+IERvZXMgdGhpcyBjbGVhciBpcCB0 aGUgY29uZnVzaW9uID8NCj4gPiANCj4gPiBaemg+IFRoZSBwaWN0dXJlIGlzIGJhZGx5IG1pc2Fs aWduZWQuIEknbGwgd2FpdCB0aWxsIDQuNyBxdWVzdGlvbnMgYXJlIGNsZWFyZWQuDQo+IA0KPiBP ay4NCj4gDQo+ID4gPiBJZiBCRlIyLzMgYXJlIGFsc28gQkZFUnMsIHRoZW4gdGhleSBhZGRpdGlv bmFsbHkgd2lsbCBoYXZlIEJGRVIgQlBzLg0KPiA+ID4gT24gQkZSMS80LCB0aGUgQklGVCBlbnRy aWVzIGZvciB0aGUgTVAyUCBCUHMgZm9yIHRoZSBMMS9MMi9MMy9sb29wYmFjayBpbnRlcmZhY2Ug YWRkcmVzc2VzIG9mIEJGUjIvMyB3aWxsIHVzZSBmb3J3YXJkX3JvdXRlZChpbnRlcmZhY2UvbG9v cGJhY2sgYWRkcmVzcykuIEZvciBhIHBhY2tldCB0byBiZSBkZWNhcHN1bGF0ZWQgb24gYSBCRkVS LCB0aGVyZSBpcyBhIG5lZWQgZm9yIGJvdGggdGhlIEJGRVIgQlAgYW5kIGFub3RoZXIgQlAgKHAy cC9sYW4vaHViLXNwb2tlL3JvdXRlZC1hZGphY2VuY3kpIGluIHRoZSBwYWNrZXQgKHRoZSBmb3Jt ZXIgaXMgZm9yIGRlY2Fwc3VsYXRpb24gYW5kIHRoZSBsYXR0ZXIgaXMgZm9yIGdldHRpbmcgaXQg dGhlcmUpLg0KPiA+IA0KPiA+IFRoaXMgaXMgbm90IGRpc2N1c3NlZCBpbiB0aGlzIHNlY3Rpb24s IGJ1dCB5b3UgYXJlIHJpZ2h0IC0gdW5sZXNzDQo+ID4gQkZSMiBvciBCRlIzIGlzIGEgbGVhZiBC RlIuIEluIHRoYXQgY2FzZSwgaXQgd291bGQganVzdCBsZXZlcmFnZSB0aGUgb25lIHNoYXJlZCAi bGVhZi1CRlIiIEJQLCBzbyB0aGV5IGRvIG5vdCBuZWVkIGEgcGVyLUJGRVIgQlAgZm9yIGxvY2Fs X2RlY2FwKCkuIA0KPiA+IA0KPiA+IFp6aD4gUmlnaHQgLSBzaGFyZWQgbGVhZi1CRlIgQlAgYnV0 IHN0aWxsIG5lZWQgdGhhdCBCUCAodGhlIGtleSBpcyB0aGF0IHdlIG5lZWQgYSBCUCB0byBnZXQg cGFja2V0IHRvIGEgQkZFUiBhbmQgdGhlbiBhIEJQIGZvciBkZWNhcHN1bGF0aW9uKS4NCj4gDQo+ IFlvdSBnb3QgaXQuDQo+IA0KPiA+ID4gSWYgdGhhdD8/P3MgdGhlIGNhc2UsIGl0Pz8/cyB3b3J0 aCBwb2ludCB0aGUgYWJvdmUgb3V0Lg0KPiA+IA0KPiA+IEhtbS4uLiBUaGUgbG9naWMgb2YgQkZF UiBCUHMgaXMgdG90YWxseSBpbmRlcGVuZGVudCBvZiB0aGUgbG9naWMgb2YgZm9yd2FyZF9yb3V0 ZWQgYWRqYWNlbmN5LCBzbyBpIHdvdWxkIHdvcnJ5IHRoYXQgcmVwZWF0aW5nIHRoZSBleHBsYW5h dGlvbiBvZiBCRkVSIEJQcyB3b3VsZCBjb25mbGF0ZSB0aGUgZm9yd2FyZF9yb3V0ZWQgZXhwbGFu YXRpb24uDQo+ID4gDQo+ID4gWnpoPiBJdCdzIGp1c3QgdGhhdCB0aGlzIGlzIGEgcGxhY2Ugd2hl cmUgYWxsIGtpbmRzIG9mIEJQcyBhcmUgdXNlZCBzbyBpdCdzIGdvb2QgdG8gaGF2ZSBhIHN1bW1h cnkgKGNvdWxkIGJlIGEgc3Vic2VjdGlvbiA0LjkpLg0KPiANCj4gWWVzLCBhZGRlZCBzdWNoIGEg c3VtbWFyeS4gUGxzLiBjaGVjay4NCj4gDQo+ID4gPiBBY3R1YWxseSwgdGhlIHJlYXNvbiB0aGF0 IEkgdGhvdWdodCB0aGlzIGlzIE1QMlAgaXMgdGhhdCAwOjYgaXMgcHJlc2VudCBvbiBSMSwgUjIs IGFuZCBSMyAoYW5kIG1vcmUgSSBhc3N1bWUpIGluIEZpZ3VyZSAxMiwgYnV0IG5vdyBJIHRoaW5r IGl0IGNhbj8/P3QgYmUgTVAyUCAoc28gaXQgaXMgbm90IGNvcnJlY3QgdG8gaGF2ZSAwOjYgcHJl c2VudCBvbiB0aG9zZSByb3V0ZXJzID8/PyBvbmx5IHRoZSBwMnAgdHVubmVsIGhlYWQvdGFpbCBz aG91bGQgaGF2ZSB0aGUgQlAgcHJlc2VudCBpbiB0aGUgQklGVCkuIFRoZSByZWFzb24gaXMgdGhh dCBpZiBpdCB3ZXJlIE1QMlAsIGFueSByb3V0ZXIgZ2V0dGluZyBhIGNvcHkgd2lsbCBzZW5kIGl0 IHRvIHRoZSBlbmRwb2ludCBvZiB0aGUgcm91dGVkIGFkamFjZW5jeSwgY2F1c2luZyBsb3RzIG9m IGR1cGxpY2F0ZXMuLi4NCj4gPiA+IA0KPiA+ID4gQW0gSSBnZXR0aW5nIHRoaXMgY29ycmVjdD8N Cj4gPiANCj4gPiBJIHRoaW5rIHlvdSBhcmUgc3RpbGwgZXhwbGFpbmluZyBmcm9tIHRoZSBtaXN1 bmRlcnN0c2FuZGluZyB0aGF0IHRoZSBFQ01QIGV4cGxhbmF0aW9ucyB3aGVyZSBhYm91dCByb3V0 ZWQgYWRqYWNlbmNpZXMuDQo+ID4gDQo+ID4gSSBoYXZlIG5vdyBleHBhbmRlZCB0aGUgc29tZXdo YXQgdGVyc2UgdGV4dCBpbiB0aGUgQklGVCB0YWJsZSBwaWN0dXJlcywgdG8gbWFrZSBpdCBjbGVh ciB0aGF0IHRoZSBFQ01QIGlzIGFjcm9zcyBtdWx0aXBlIGZvcndhcmRfY29ubmVjdGVkIGFkamFj ZW5jaWVzIGluIHRoZSBleGFtcGxlcy4gRm9yIGV4YW1wbGUsIGZpcnN0IEJJRlQgcGljdHVyZToN Cj4gPiANCj4gPiAgIEJJRlQgZW50cnkgaW4gQkZSMToNCj4gPiAgIC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+ICAg fCBJbmRleCB8ICBBZGphY2VuY2llcyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8DQo+ID4gICA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gPiAgIHwgMDo2ICAgfCAgRUNNUCh7Zm9yd2Fy ZF9jb25uZWN0ZWQoTDEsIEJGUjIpLCAgICAgICAgICAgICAgICAgICAgfA0KPiA+ICAgfCAgICAg ICB8ICAgICAgICBmb3J3YXJkX2Nvbm5lY3RlZChMMiwgQkZSMiksICAgICAgICAgICAgICAgICAg ICB8DQo+ID4gICB8ICAgICAgIHwgICAgICAgIGZvcndhcmRfY29ubmVjdGVkKEwzLCBCRlIyKX0s IHNlZWQpICAgICAgICAgICAgIHwNCj4gPiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IA0KPiA+IE9mIGNvdXJz ZSwgYW4gRUNNUCBhZGphY2VuY3kgY2FuIGJlIGFjcm9zcyBhbnkgdHlwZSBvZiBhZGphY2VuY2ll cywgYnV0IGFsbCB0aGUgdGV4dC9leHBsYW5hdGlvbnMgdXNlZCBmb3J3YXJkX2Nvbm5lY3RlZCwg YW5kIG5vdyB0aGUgcGljdHVyZXMgc2hvdyB0aGF0IGV4cGxpY2l0bHkuDQo+ID4gDQo+ID4gWnpo PiBJIGNhbiB1bmRlcnN0YW5kIHRoZSBtdWx0aS1saW5rIGNhc2UsIGJ1dCB0aGUgbXVsdGktaG9w IEVDTVAgY2FzZSAoZnJvbSBCRlIxIHRvd2FyZHMgQkZSMTApIGlzIGNvbmZ1c2luZyBtZS4gSXQg d291bGQgaGVscCB0byBnaXZlIGFuIGV4YW1wbGUgaG93IGl0IGNhbiBiZSB1c2VkLCBXSVRIT1VU IHdvcnJ5aW5nIGFib3V0IHBvbGFyaXphdGlvbi4NCj4gDQo+IFBsZWFzZSBjaGVjayAtMDUgdGV4 dCB0aGF0IGhhcyB0aGUgZnVsbCBzZXQgb2YgQklGVCBsaXN0ZWQgbm93Og0KPiANCj4gVGhlcmUg aXMgIHJlYWxseSBub3RoaW5nIG5vdGhpbmcgdW5pcXVlIGluIG11bHRpLWhvcCBFQ01QIGZvciBC SUVSLVRFIA0KPiB0aGF0IHdlIGRvIG5vdCBhbHNvIGhhdmUgaW4gYW55IG90aGVyIEVDTVAsIGV4 Y2VwdCB0aGUgY29uY2x1c2lvbiB0aGF0IA0KPiB3ZSB3YW50IHRvIHN1cHBvcnQgZmFzdCBIVyBo YXNoIG1lY2hhbmlzbXMgQU5EIGFsbG93IHRoZSBjb250cm9sbGVyIHRvIA0KPiBzZXQgdXAgbm9u LXBvbGFyaXplZCBtdWx0aS1ob3AgRUNNUCBBTkQgYmUgYWJsZSB0byBwcmVjYWxjdWxhdGUgcGF0 aHMuIA0KPiBIZW5jZSB0aGUgc3BlY2lmaWNhdGlvbiBvZiBFQ01QIGFkamFjZW5jaWVzIHRvIGhh dmUgYSBjb250cm9sbGVyIA0KPiBjb25maWd1cmFibGUgc2VlZC4NCj4gDQo+IEJ0dzogVGhlIHBp Y3R1cmUgaXMgbWF5YmUgdW5uZWNlc3NhcmlseSBsYXJnZSBiZWNhdXNlIGkndmUgdXNlZCBpdCBm b3IgDQo+IDIwIHllYXJzIHRvIGV4cGxhaW4gdGhlIHNhbWUgcG9sYXJpemF0aW9uIGlzc3VlIGZv ciB1bmljYXN0IHZzIA0KPiBtdWx0aWNhc3QsIGFuZCBmb3IgbXVsdGljYXN0IG9ubHkgQkZSMTAu Li5CRlI0IGFyZSByZWxldmFudCAoRUNNUCBvZiANCj4gdGhlIFBJTS9tTERQIGpvaW5zKSwgd2hl cmVhcyBmb3IgdW5pY2FzdC9CSUVSIG9ubHkNCj4gQkZSMS4uLkJGUjcgYXJlIHJlbGV2YW50LiBC dXQgYmVpbmcgc3ltbWV0cmljLCB0aGUgcGljdHVyZSBtYWtlcyBpdCANCj4gY2xlYXIgaXRzIHRo ZSBzYW1lIHByb2JsZW0uDQo+IA0KPiA+ID4gICAgVG8gaW5oaWJpdCBsb29waW5nIGluIHRoZSBm YWNlIG9mIHN1Y2ggcGh5c2ljYWwgbWlzY29uZmlndXJhdGlvbiwNCj4gPiA+ICAgIG9ubHkgZm9y d2FyZF9jb25uZWN0ZWQgYWRqYWNlbmNpZXMgYXJlIHBlcm1pdHRlZCB0byBoYXZlIEROUiBzZXQs IGFuZA0KPiA+ID4gICAgdGhlIGxpbmsgbGF5ZXIgZGVzdGluYXRpb24gYWRkcmVzcyBvZiB0aGUg YWRqYWNlbmN5IChlLmcuICBNQUMNCj4gPiA+ICAgIGFkZHJlc3MpIHByb3RlY3RzIGFnYWluc3Qg Y2xvc2luZyB0aGUgbG9vcC4gIExpbmsgbGF5ZXJzIHdpdGhvdXQgcG9ydA0KPiA+ID4gICAgdW5p cXVlIGxpbmsgbGF5ZXIgYWRkcmVzc2VzIHNob3VsZCBub3QgYmUgdXNlZCB3aXRoIHRoZSBETlIg ZmxhZyBzZXQuDQo+ID4gPg0KPiA+ID4gSXQ/Pz9zIG5vdCBjbGVhciBob3cgbGluayBsYXllciBh ZGRyZXNzIGhlbHBzPw0KPiA+IA0KPiA+IEkgaGF2ZSBleHBhbmRlZCB0aGlzIHRvDQo+ID4gImxp bmsgbGF5ZXIgcG9ydCB1bmlxdWUgdW5pY2FzdCBkZXN0aW5hdGlvbiBhZGRyZXNzIg0KPiA+IA0K PiA+IEFrYTogTVBMUyBvciBldGhlcm5ldCBoYXZlIHVuaXF1ZSBsaW5rIGxheWVyIGRlc3RpbmF0 aW9uIGRlc3RpbmF0aW9uIGFkZHJlc3NlcyAobGFiZWwgb3IgZGVzdGluYXRpb24gTUFDKS4gSWYg eW91IHRoaW5rIGFib3V0IGluY29ycmVjdGx5IHBsdWdnZWQgSERMQyBsaW5rcyAoc3VjaCBhcyBv bGQgVDEvVDMvLi4uIGxpbmtzKSwgdGhleSBvbmx5IGhhdmUgMiBnZW5lcmljIGFkZHJlc3Nlcywg aWYgaSByZW1lbWJlciAxIG9yIDMgaW4gdGhlIEhETEMgZnJhbWUuIFNvIHdoZW4geW91IG1pc3Bs dWcgb25lIG9mIHRob3NlIHAycCBjYWJsZXMgd3JvbmcsIHRoZSBwYWNrZXRzIHdvdWxkIGJlIGlu Y3JyZWN0bHkgcmVjZWl2ZWQgYnkgdGhlIHdyb25nIHJlY2VpdmVyIG5vZGUgYW5kIHRoZW4gRE5S IGNvdWxkIGNhdXNlIHBlcnNpc3RlbnQgbG9vcHMgb25seSBzb2x2ZWQgYnkgVFRMLg0KPiA+IA0K PiA+IFp6aD4gIkNvbnNpZGVyIGluIHRoZSByaW5nIHBpY3R1cmUgdGhhdCBsaW5rIEw0IGZyb20g QkZSMyBpcyBwbHVnZ2VkIGludG8gdGhlIEwxIGludGVyZmFjZSBvZiBCRlJhIiAtIHN0aWxsIG5v dCBzdXJlIGhvdyBsYWJlbC9tYWMgaGVscHMgaGVyZS4gSSBzdXBwb3NlIHRoZSByaW5nIHRvcG9s b2d5IGlzIGRpc2NvdmVyZWQvdmVyaWZpZWQgYnkgdGhlIGNvbnRyb2wgcGxhbmUgYW5kIHdoZW4g dGhlIG1pc2NhbGxpbmcgaGFwcGVucyB0aGVuIHRoZSByaW5nIHdpbGwgbm90IGluY2x1ZGUgdGhl IEJGUjEvQkZSMiBwYXJ0IGFuZCBCRlIzIHdpbGwgbm90IGhhdmUgdGhlIEROUiBzZXQ/IElmIHJp bmcgZGlzY292ZXJ5L3ZhcmljYXRpb24gaXMgbm90IGRvbmUgdGhlbiBwZXJoYXBzIHdlIHNob3Vs ZCBwb2ludCBvdXQgdGhhdCBSUEYgYmFzZWQgb24gbGluayBsYXllciBhZGRyZXNzIGlzIG5lZWRl ZCAtIHRoZSBrZXkgaXMgUlBGICh3aGljaCBuZWVkcyB1bmlxdWUgbGluayBsYXllciBhZGRyZXNz KT8NCj4gDQo+IEZvcmdldCBSUEYuIEJJRVIoLVRFKSBoYXMgbm8gUlBGIChpc3N1ZXMpLiBJdHMg anVzdCBsaWtlIHVuaWNhc3QuIFJQRiANCj4gaXMganVzdCBhIHByb2JsZW0gZm9yIHJlY2VpdmVy IG9yaWdpbmF0ZWQgam9pbnMgbGlrZSBpbiBQSU0vbUxEUCwgYnV0IA0KPiBub3QgdW5pY2FzdC9i aWVyKC10ZSkvUlNWUC1URS4NCj4gDQo+IEZvcndhcmRfY29ubmVjdGVkIGlzIGp1c3QgbGlrZSBh IHVuaWNhc3Qgc3VibmV0IGFkamFjZW5jeSB0byBhIGRpcmVjdCANCj4gbmVpZ2hib3I6IEludGVy ZmFjZSBhbmQgTDIgYWRkcmVzc3Mgb2YgdGhlIGRlc3RpbmF0aW9uLg0KPiANCj4gVGhlIGNvbnRy b2xsZXIgKGNvdWxkIGJlIGEgaHVtYW4pICJhc3N1bWVzIiBhIHBhcnRpY3VsYXIgcGh5c2ljaWFs IA0KPiB0b3BvbG9neSwgZnJvbSB0ZWxlbWV0cnkva25vd2xlZGdlL3doYXRldmVyLiBJdCB0aGVu IGNhbGN1bGF0ZXMgdGhlIA0KPiBkZXNpcmVkIEJJRVItVEUgdG9wb2xvZ3kgYW5kIHB1c2hlcyBp dCBkb3duLiBUaGlzIHRvcG9sb2d5IGlzIG1lYW50IHRvIA0KPiBiZSBsb29wIGZyZWUgb2YgY291 cnNlIHdydCB0byB0aGUgY29uZmlndXJlZCBhZGphY2VuY2llcy4NCj4gSW4gdGhpcyBCSUVSLVRF IHRvcG9sb2d5LCBCRlIzIHdpbGwgaGF2ZSBhIEJQIHdpdGggdGhlIA0KPiBmb3J3YXJkX2Nvbm5l Y3RlZChMNCwgTUFDLW9mLUJGUjIpIGFkamFjZW5jeS4NCj4gDQo+IElmIHRoZSBjYWJsZSBjb25u ZWN0aW5nIHRvIEw0IGlzIG1pc3dpcmVkLCB0aGVuIEJGUjMgd291bGQgc3RpbGwgc2VuZCANCj4g dGhlIHBhY2tldHMgdG8gdGhlIE1BQyBhZGRyZXNzIG9mIEJGUjIsIGJ1dCBnaXZlbiBob3cgdGhl IGNhYmxlIA0KPiBjb25uZWN0cyB0byBzb21lIG90aGVyIG5vZGUsIHRoZXNlIHBhY2tldHMgd2ls bCBiZSBkaXNjYXJkZWQgYnkgdGhhdCANCj4gbm9kZS4gYmVjYXVzZSB0aGV5J3JlIGp1c3QgTDIg dW5pY2FzdCBwYWNrZXRzLg0KPiANCj4gSSB0aGluayB0aGlzIGlzIGVxdWFsbHkgdHJ1ZSB3aGVu IHdlIGhhdmUgbm9ybWFsIEJJRVIvTVBMUyBlbmFjcC4NCj4gVGhvc2UgcGFja2V0cyB0b28gYXJl IGFkZHJlc3NlZCB0byB0aGUgdW5pY2FzdCBNQUMgYWRkcmVzcyBvZiB0aGUgDQo+IG5laWdoYm9y Lg0KPiANCj4gTm93LCBpZi93aGVuIGhlIGNvbnRyb2xsZXIgcmVjb2duaXplcyB0aGF0IHRoZSBw aHlzaWNhbCB0b3BvbG9neSBoYXMgDQo+IGNoYW5nZWQsIHRoYXRzIGEgY29tcGxldGVseSBkaWZm ZXJlbnQgc3RvcnkgYW5kIG5vdCBhZGRyZXNzZWQgaGVyZS4gDQo+IEdpdmVuIGhvdyB3ZSBhc3N1 bWVkIHRoaXMgd2FzIGEgY2FibGluZyBtaXN0YWtlLCB0aGUgY29udHJvbGxlciB3b3VsZCANCj4g cHJvYmFibHkgb25seSBjb21wbGFpbiBhYm91dCB0aGUgbWlzd2lyaW5nIHRvIG9wZXJhdGlvbnMg YnV0IGJlIGhhcHB5IA0KPiB0aGF0IHRoZSBmb3J3YXJkaW5nIHBsYW5lIGp1c3QgbWFrZXMgcGFj a2V0cyBmYWlsIGluc3RlYWQgb2YgbG9vcC4gSWYgDQo+IHRoaXMgd2FzIGEgcGxhbm5lZCBjaGFu Z2UgcHJvY2VzcywgdGhlbiBpdCB3aWxsIGJlIHNpbWlsYXJpbHkgDQo+IGNvbnZvbHV0ZWQgYXMg aXQgd291bGQgdG9kYXkgYmUgd2l0aCByZXdpcmluZyBjYWJsZXMgaW4gYW4gDQo+IFNSLU1QTFMv U1J2NiB0b3BvbG9neSBhbmQgdXBkYXRpbmcgU0lEcy4NCj4gDQo+ID4gPiBCZWNhdXNlIHRoZSBm b3J3YXJkaW5nIGlzIGRpZmZlcmVudCBmcm9tIEJJRVIgZm9yd2FyZGluZyAoYmVjYXVzZSBvZiBb MV0gYWJvdmUpLCB3ZSBtaWdodCBhcyB3ZWxsIGludHJvZHVjZSBhbiBvcHRpbWl6YXRpb24gaGVy ZSA/Pz8gZm9yIGVhY2ggQklGVCwgY2FsY3VsYXRlIHRoZSBGLUJNIG9mIHRoZSBCSUZUIGl0c2Vs ZiAodGhlIGxvZ2ljYWwgPz8/b3I/Pz8gb2YgYWxsIHRoZSBCUHMgcHJlc2VudGVkIGluIHRoaXMg QklGVCkgYW5kIHRoZW4gdXNlIChwYWNrZXQtPmJpdHN0cmluZyAmIEJJRlQuRi1CTSkgYXMgdGhl IGlucHV0IHRvIEdldEZpcnN0L05leHRCaXRQb3NpdGlvbigpLiBUaGF0IHNob3VsZCBza2lwIG1h bnkgYml0cy4NCj4gPiANCj4gPiBSaWdodC4gQnV0IGkgZXhwbGljaXRseSByZW1vdmVkIHRob3Nl IG9wdGltaXphdGlvbnMgKGkgaGFkIHRoZW0gaW4gb2xkZXIgZHJhZnQgdmVyc2lvbnMpIGJlY2F1 c2UgdGhlIHdob2xlIGlkZWEgb2YgdGhpcyBwaWN0dXJlIGlzIHNvbGVseSB0aGUgY29tcGFyaXNv biB3aXRoIGZpZ3VyZSA0IG9mIFJGQzgyNzkuDQo+ID4gDQo+ID4gWnpoPiBJIHRoaW5rIGl0J3Mg d29ydGggcG9pbnQgdGhhdCBvcHRpbWl6YXRpb24gb3V0OyB5b3UgY2FuIG1hcmsgaXQgb3B0aW9u YWwgaWYgeW91IHdhbnQgdG8gZW1waGFzaXplIHRoZSBzaW1pbGFyaXR5IHRvIEJJRVIgZm9yd2Fy ZGluZywgYnV0IHNpbmNlIEJJRVIgZm9yd2FyZGluZyBkb2VzIGRvIHRoZSBtYXNrb2ZmIHN0ZXAs IGl0IGlzIHZlcnkgZWZmaWNpZW50IHdoaWxlIEJJRVItVEUgZm9yd2FyZGluZyBkb2VzIG5vdCBp dCB0aGUgbWFza29mZiBzdGVwIHNvIHRoaXMgb3B0aW1pemF0aW9uIGlzIGltcG9ydGFudC4NCj4g DQo+IE9rLiBJIHNpbXBsaWZpZWQgdGhlIHRleHQgY29tcGFyaXNvbiBCSUVSL0JJRVItVEUgd3J0 LiB0byB0aGUgRkJNIA0KPiBydWxlcyBbMV0gYW5kIFsyXSBhbmQgYWRkZWQgZm9sbG93aW5nIHBh cmFncmFwaDoNCj4gDQo+IDx0PkluIEJJRVIsIHRoZSBvcmRlciBvZiBCUHMgaW1wYWN0cyB0aGUg cmVzdWx0IG9mIGZvcndhcmRpbmcgYmVjYXVzZSBvZiBbMV0uIA0KPiBJbiBCSUVSLVRFLCBmb3J3 YXJkaW5nIGlzIG5vdCBpbXBhY3RlZCBieSB0aGUgb3JkZXIgb2YgQlBzLiBJdCBpcyANCj4gdGhl cmVmb3JlIHBvc3NpYmxlIHRvIGZ1cnRoZXIgb3B0aW1pemUgZm9yd2FyZGluZyB0aGFuIGluIEJJ RVIuIEZvciANCj4gZXhhbXBsZSBwYXJhbGxlbGl6aW5nIGZvcndhcmRpbmcgYWNyb3NzIG11bHRp cGxlIEZQRSBjb3JlcyBvciANCj4gZGlzdHJpYnV0ZWQgbGluZWNhcmRzIGRvZXMgb25seSBuZWVk IHRvIGV4YW1pbmUgYW4gYXJiaXRyYXJ5IHN1YnNldCBvZiANCj4gQlAgYW5kIG5vdCBldmFsdWF0 ZSB0aGUgZGVwZW5kZW5jeSBiZXR3ZWVuIEJQcy48L3Q+DQo+IA0KPiA+ID4gICAgVGhlIGZvbGxv d2luZyBwc2V1ZG9jb2RlIGlzIGNvbXByZWhlbnNpdmU6DQo+ID4gPiANCj4gPiA+IFRoZSBhYm92 ZSBzZW50ZW5jZSByZWFkcyBhIGJpdCBzdHJhbmdlIChvciBsYWNrcyBzb21lIHNlZ3VlKS4uLg0K PiA+IA0KPiA+IEkgaG9wZSBub3QsIGJ1dCBtYXliZSBiZXN0IGxlZnQgdG8gYSBuYXRpdmUgZW5n bGlzaCBzcGVha2VyIChSRkMtZWRpdG9yKS4NCj4gPiANCj4gPiBUaGUgZmlyc3QgKFJGQzgyNzkp IHBzZXVkb2NvZGUgd2FzIHNpbXBsaWZpZWQuIFRoZSBzZWNvbmQgb25lIGlzIGNvbXByZWhlbnNp dmUuIElmIG5vdCBjb21wcmVoZW5zaXZlLCB3aGF0cyBhIGdvb2Qgb3Bwb3NpdGUgb2Ygc2ltcGxp ZmllZCA/DQo+ID4gDQo+ID4gWnpoPiBQZXJoYXBzICJUaGUgYWJvdmUgc2ltcGxpZmllZCBwc2V1 ZG9jb2RlIGlzIGVsYWJvcmF0ZWQgZnVydGhlciBhcyBmb2xsb3dpbmciPw0KPiA+IFp6aD4gSmVm ZnJleQ0KPiANCj4gRG9uZS4NCj4gDQo+IFRoYW5rcyBhIGxvdC4gDQo+IA0KPiANCj4gPiAgICAN Cj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IEZy b206IEJJRVIgW2JpZXItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86Ymllci1ib3VuY2VzQGlldGYu b3JnPl0gDQo+ID4gPiBvbiBiZWhhbGYgb2YgVG9lcmxlc3MgRWNrZXJ0IFt0dGVAY3MuZmF1LmRl PG1haWx0bzp0dGVAY3MuZmF1LmRlPl0NCj4gPiA+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMDksIDIw MTkgMjM6MzgNCj4gPiA+IFRvOiBNaWtlIE1jQnJpZGUNCj4gPiA+IENjOiBHcmVnIFNoZXBoZXJk OyBCSUVSIFdHOyBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpDQo+ID4gPiBTdWJqZWN0OiBSZTog W0JpZXJdIFdHTEMgLSBkcmFmdC1pZXRmLWJpZXItdGUtYXJjaA0KPiA+ID4gDQo+ID4gPiBUaGFu a3MsIE1pa2UNCj4gPiA+IA0KPiA+ID4gVGhlIGF1dGhvcnMgYWxzbyByZXZpZXdlZCB0aGUgZG9j dW1lbnQgYW5kIGNvbmNsdWRlZCB0aGF0IGl0IHdhcyANCj4gPiA+IHJlYWxseSBoYXJkIHRvIGdl dCBpbnRvIHRoZSBkb2N1bWVudCBjb250ZXh0IGJlY2F1c2Ugb2YgdG9vIG1hbnkgDQo+ID4gPiBm b3J3YXJkIGRlcGVuZGVuY2llcy4gV2UgdHJpZWQgdG8gZml4IHRoaXMgYnkgYWRkaW5nIHR3byBo b3BlZnVsbHkgDQo+ID4gPiBnb29kICYgYmFzaWMgZXhhbXBsZXMgaW50byB0aGUgSW50cm9kdWN0 aW9uIHNlY3Rpb24gYW5kIHVzaW5nIHRoZW0gDQo+ID4gPiB0byBhbHNvIGFkZCBhIGJldHRlciBk ZWZpbml0aW9uIG9mIHRoZSB0ZXJtICJCSUVSLVRFIFRvcG9sb2d5IiBpbiB0aGUgSW50cm9kdWN0 aW9uLg0KPiA+ID4gSG9wZWZ1bGx5IHRoaXMgbWFrZXMgcmVhZGluIHRoZSByZXN0IG9mIHRlIGRv Y3VtZW50IHNtb290aGVyLi4uDQo+ID4gPiANCj4gPiA+IEFsc28gaW1wcm92ZWQgdGV4dCBvZiBB YnN0cmFjdCBhbmQgcmVmaW5lZCB0ZXh0IGNvbXBhcmlpbmcgQklFUi1URSB3aXRoIFNSLg0KPiA+ ID4gDQo+ID4gPiBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cDovL3Rvb2xzLmlldGYu b3JnLypyZmNkaWZmP3VybDE9aHR0cHM6DQo+ID4gPiAqKkF0b29scy5pZXRmLm9yZyppZCpkcmFm dC1pZXRmLWJpZXItdGUtYXJjaC0wMi50eHQmdXJsMj1odHRwczoqKkENCj4gPiA+IHRvb2wNCj4g PiA+IHMuaWV0Zi5vcmcqaWQqZHJhZnQtaWV0Zi1iaWVyLXRlLWFyY2gtMDMudHh0X187THk4dkx5 OHZMeTh2IThXb0E2Ug0KPiA+ID4gakM4MSANCj4gPiA+IGMhWHZINEFBeGZyRGpGb0tfc2VyY3da TXNjME81TjQyZUVOT3M0bF9xZHNYRjBLd1pEODJjSkxERkZOVl9lVFVFaA0KPiA+ID4gJA0KPiA+ ID4gPGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwOi90b29scy5pZXRmLm9yZy8qcmZj ZGlmZj91cmwxPWh0dHBzOg0KPiA+ID4gKipBdG9vbHMuaWV0Zi5vcmcqaWQqZHJhZnQtaWV0Zi1i aWVyLXRlLWFyY2gtMDIudHh0JnVybDI9aHR0cHM6KipBDQo+ID4gPiB0b29sDQo+ID4gPiBzLmll dGYub3JnKmlkKmRyYWZ0LWlldGYtYmllci10ZS1hcmNoLTAzLnR4dF9fO0x5OHZMeTh2THk4diE4 V29BNlINCj4gPiA+IGpDODEgDQo+ID4gPiBjIVVCVEd2V1dwTUh5ZWlTYW54czZ2SWJfRW5CVmd5 ZzZib0FBVzRucnFqdThVQ0xPZ2l1WGM4WV82c05kMW5qY1gNCj4gPiA+ICQ+DQo+ID4gPiANCj4g PiA+IENoZWVycw0KPiA+ID4gICAgIFRvZXJsZXNzDQo+ID4gPiANCj4gPiA+IE9uIFdlZCwgSnVu IDI2LCAyMDE5IGF0IDEwOjM5OjM2QU0gLTA3MDAsIE1pa2UgTWNCcmlkZSB3cm90ZToNCj4gPiA+ ID4gSG93IGFib3V0IHRocmVlPyBJIHN1cHBvcnQuDQo+ID4gPiA+IG1pa2UNCj4gPiA+ID4NCj4g PiA+ID4gT24gVHVlLCBKdW4gMjUsIDIwMTkgYXQgMTA6NDIgQU0gR3JlZyBTaGVwaGVyZCA8Z2pz aGVwQGdtYWlsLmNvbTxtYWlsdG86Z2pzaGVwQGdtYWlsLmNvbT4+IHdyb3RlOg0KPiA+ID4gPiA+ DQo+ID4gPiA+ID4gV2UgY2Fubm90IHRha2UgdHdvICd5ZXMnIHZvdGVzIGFuZCBXRyBjb25zZW5z dXMuDQo+ID4gPiA+ID4gUGxlYXNlLCByZWFkIGFuZCByZXNwb25kLiBJZiB5b3UgZG9uJ3Qgc3Vw cG9ydCwgdGhlbiBwbGVhc2Ugdm90ZSBhcyBtdWNoIHB1YmxpY2x5IHJpZ2h0IGhlcmUuDQo+ID4g PiA+ID4NCj4gPiA+ID4gPiBUaGFua3MsDQo+ID4gPiA+ID4gR3JlZw0KPiA+ID4gPiA+DQo+ID4g PiA+ID4gT24gTW9uLCBKdW4gMywgMjAxOSBhdCAxMDowNSBQTSBQYXNjYWwgVGh1YmVydCAocHRo dWJlcnQpIDxwdGh1YmVydEBjaXNjby5jb208bWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbT4+IHdy b3RlOg0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+PiBTdXBwb3J0Og0KPiA+ID4gPiA+Pg0KPiA+ID4g PiA+PiBJIHNlZSBncmVhdCB2YWx1ZSBpbiBkZXRlcm1pbmlzdGljIG5ldHdvcmtzIGFzIHdlbGwg YXMgSU9UICh3aXRoIFJQTCkuDQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+IEFsbCB0aGUgYmVzdCwN Cj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4gUGFzY2FsDQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+ID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPj4gPiBGcm9tOiBCSUVSDQo+ID4g PiA+ID4+ID4gPGJpZXItYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86Ymllci1ib3VuY2VzQGlldGYu b3JnPj4gT24gDQo+ID4gPiA+ID4+ID4gQmVoYWxmIE9mIFRvZXJsZXNzIEVja2VydA0KPiA+ID4g PiA+PiA+IFNlbnQ6IG1hcmRpIDQganVpbiAyMDE5IDAyOjAzDQo+ID4gPiA+ID4+ID4gVG86IEdy ZWcgU2hlcGhlcmQgDQo+ID4gPiA+ID4+ID4gPGdqc2hlcEBnbWFpbC5jb208bWFpbHRvOmdqc2hl cEBnbWFpbC5jb20+Pg0KPiA+ID4gPiA+PiA+IENjOiBCSUVSIFdHIDxiaWVyQGlldGYub3JnPG1h aWx0bzpiaWVyQGlldGYub3JnPj4NCj4gPiA+ID4gPj4gPiBTdWJqZWN0OiBSZTogW0JpZXJdIFdH TEMgLSBkcmFmdC1pZXRmLWJpZXItdGUtYXJjaA0KPiA+ID4gPiA+PiA+DQo+ID4gPiA+ID4+ID4g KzENCj4gPiA+ID4gPj4gPiBPYnZpb3VzbHkgc3VwcG9ydCBhcyBjby1hdXRob3IuDQo+ID4gPiA+ ID4+ID4NCj4gPiA+ID4gPj4gPiBPbiBXZWQsIE1heSAyOSwgMjAxOSBhdCAxMjo0MToyNlBNIC0w NzAwLCBHcmVnIFNoZXBoZXJkIHdyb3RlOg0KPiA+ID4gPiA+PiA+ID4gUGxlYXNlIHJlYWQgYW5k IHJlc3BvbmQgdG8gdGhpcyB0aHJlYWQgdy8gb3Igdy9vIHN1cHBvcnQuDQo+ID4gPiA+ID4+ID4g Pg0KPiA+ID4gPiA+PiA+ID4gaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcNCj4gPiA+ID4gPj4gPiA+IC9kb2MgDQo+ID4gPiA+ID4+ID4gPiAv ZHJhZnQtaWV0Zi1iaWVyLXRlLWFyY2gvX187IThXb0E2UmpDODFjIVh2SDRBQXhmckRqRm9LX3MN Cj4gPiA+ID4gPj4gPiA+IGVyY3cgWk1zYzBPNU40MmVFTk9zNGxfcWRzWEYwS3daRDgyY0pMREZG TlY5ZUNsQmokDQo+ID4gPiA+ID4+ID4gPiA8aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0 dHBzOi9kYXRhdHJhY2tlci5pZXRmLm9yZy8NCj4gPiA+ID4gPj4gPiA+IGRvYy8gDQo+ID4gPiA+ ID4+ID4gPiBkcmFmdC1pZXRmLWJpZXItdGUtYXJjaC9fXzshOFdvQTZSakM4MWMhVUJUR3ZXV3BN SHllaVNhbngNCj4gPiA+ID4gPj4gPiA+IHM2dkkgYl9FbkJWZ3lnNmJvQUFXNG5ycWp1OFVDTE9n aXVYYzhZXzZzRDQwa210SCQ+DQo+ID4gPiA+ID4+ID4gPg0KPiA+ID4gPiA+PiA+ID4gVm90ZSBl bmRzIDUgSnVuZSAyMDE5Lg0KPiA+ID4gPiA+PiA+ID4NCj4gPiA+ID4gPj4gPiA+IFRoYW5rcywN Cj4gPiA+ID4gPj4gPiA+IFNoZXANCj4gPiA+ID4gPj4gPiA+IChjaGFpcnMpDQo+ID4gPiA+ID4+ ID4NCj4gPiA+ID4gPj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4gPiA+ID4+ID4gPiBCSUVSIG1haWxpbmcgbGlzdA0KPiA+ID4gPiA+PiA+ ID4gQklFUkBpZXRmLm9yZzxtYWlsdG86QklFUkBpZXRmLm9yZz4NCj4gPiA+ID4gPj4gPiA+IGh0 dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuLw0K PiA+ID4gPiA+PiA+ID4gbGlzdA0KPiA+ID4gPiA+PiA+ID4gaW5mby9iaWVyX187IThXb0E2UmpD ODFjIVh2SDRBQXhmckRqRm9LX3NlcmN3Wk1zYzBPNU40MmVFDQo+ID4gPiA+ID4+ID4gPiBOT3M0 IGxfcWRzWEYwS3daRDgyY0pMREZGTlQyV1ZYV1gkIA0KPiA+ID4gPiA+PiA+ID4gPGh0dHBzOi8v dXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovd3d3LmlldGYub3JnL21haWxtYW4vDQo+ID4gPiA+ ID4+ID4gPiBsaXN0IA0KPiA+ID4gPiA+PiA+ID4gaW5mby9iaWVyX187IThXb0E2UmpDODFjIVVC VEd2V1dwTUh5ZWlTYW54czZ2SWJfRW5CVmd5ZzZiDQo+ID4gPiA+ID4+ID4gPiBvQUFXIDRucnFq dThVQ0xPZ2l1WGM4WV82c0tuMktvQVQkPg0KPiA+ID4gPiA+PiA+DQo+ID4gPiA+ID4+ID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPj4g PiBCSUVSIG1haWxpbmcgbGlzdA0KPiA+ID4gPiA+PiA+IEJJRVJAaWV0Zi5vcmc8bWFpbHRvOkJJ RVJAaWV0Zi5vcmc+DQo+ID4gPiA+ID4+ID4gaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGkNCj4gPiA+ID4gPj4gPiBzdGluIA0KPiA+ID4g PiA+PiA+IGZvL2JpZXJfXzshOFdvQTZSakM4MWMhWHZINEFBeGZyRGpGb0tfc2VyY3daTXNjME81 TjQyZUVOT3M0DQo+ID4gPiA+ID4+ID4gbF9xZA0KPiA+ID4gPiA+PiA+IHNYRjBLd1pEODJjSkxE RkZOVDJXVlhXWCQNCj4gPiA+ID4gPj4gPiA8aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0 dHBzOi93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saQ0KPiA+ID4gPiA+PiA+IHN0aW4gDQo+ID4gPiA+ ID4+ID4gZm8vYmllcl9fOyE4V29BNlJqQzgxYyFVQlRHdldXcE1IeWVpU2FueHM2dkliX0VuQlZn eWc2Ym9BQVcNCj4gPiA+ID4gPj4gPiA0bnJxDQo+ID4gPiA+ID4+ID4ganU4VUNMT2dpdVhjOFlf NnNLbjJLb0FUJD4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ID4gQklFUiBtYWlsaW5nIGxpc3QNCj4g PiA+ID4gPiBCSUVSQGlldGYub3JnPG1haWx0bzpCSUVSQGlldGYub3JnPg0KPiA+ID4gPiA+IGh0 dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpDQo+ID4gPiA+ID4gbmZvLyANCj4gPiA+ID4gPiBiaWVyX187IThXb0E2UmpDODFjIVh2SDRB QXhmckRqRm9LX3NlcmN3Wk1zYzBPNU40MmVFTk9zNGxfcWRzWA0KPiA+ID4gPiA+IEYwS3cNCj4g PiA+ID4gPiBaRDgyY0pMREZGTlQyV1ZYV1gkDQo+ID4gPiA+ID4gPGh0dHBzOi8vdXJsZGVmZW5z ZS5jb20vdjMvX19odHRwczovd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGkNCj4gPiA+ID4gPiBu Zm8vIA0KPiA+ID4gPiA+IGJpZXJfXzshOFdvQTZSakM4MWMhVUJUR3ZXV3BNSHllaVNhbnhzNnZJ Yl9FbkJWZ3lnNmJvQUFXNG5ycWp1DQo+ID4gPiA+ID4gOFVDTA0KPiA+ID4gPiA+IE9naXVYYzhZ XzZzS24yS29BVCQ+DQo+ID4gPiANCj4gPiA+IC0tDQo+ID4gPiAtLS0NCj4gPiA+IHR0ZUBjcy5m YXUuZGU8bWFpbHRvOnR0ZUBjcy5mYXUuZGU+DQo+ID4gPiANCj4gPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBCSUVSIG1haWxpbmcgbGlz dA0KPiA+ID4gQklFUkBpZXRmLi4ub3JnPG1haWx0bzpCSUVSQGlldGYub3JnPg0KPiA+ID4gaHR0 cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vDQo+ID4gPiBiaWVyIA0KPiA+ID4gX187IThXb0E2UmpDODFjIVh2SDRBQXhmckRqRm9L X3NlcmN3Wk1zYzBPNU40MmVFTk9zNGxfcWRzWEYwS3daRDgyDQo+ID4gPiBjSkxEDQo+ID4gPiBG Rk5UMldWWFdYJA0KPiA+ID4gPGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vDQo+ID4gPiBiaWVyIA0KPiA+ID4gX187IThXb0E2 UmpDODFjIVVCVEd2V1dwTUh5ZWlTYW54czZ2SWJfRW5CVmd5ZzZib0FBVzRucnFqdThVQ0xPZ2l1 DQo+ID4gPiBYYzhZDQo+ID4gPiBfNnNLbjJLb0FUJD4NCj4gPiANCj4gPiAtLQ0KPiA+IC0tLQ0K PiA+IHR0ZUBjcy5mYXUuZGUNCj4gDQo+IC0tDQo+IC0tLQ0KPiB0dGVAY3MuZmF1LmRlDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBCSUVS IG1haWxpbmcgbGlzdA0KPiBCSUVSQGlldGYub3JnDQo+IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20v djMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JpZXINCj4gX187ISFO RXQ2eU1hTy1nayFWdVFDVkhucUp5X2FZSS1GTnQ5QTFhNUV6SE9DcjBmWmtMUGJnZzNDUE51MFB5 cldzckZ4NA0KPiAxX2pXVjNZVUE2RCQNCg0KLS0NCi0tLQ0KdHRlQGNzLmZhdS5kZQ0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQklFUiBtYWlsaW5n IGxpc3QNCkJJRVJAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vYmllcg== --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZh bWlseTphcmlhbDsiPlN1cHBvcnQuPC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZh bWlseTphcmlhbDsiPjxicj48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5 OmFyaWFsOyI+VGhhbmtzLDwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6 YXJpYWw7Ij5TYW5keTwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6YXJp YWw7Ij48YnI+PC9wPjxkaXYgY2xhc3M9InpNYWlsU2lnbiIgdW5vbmFtZWNoPSLlvKDlvoEwMDAw Nzk0MCIgdW5vbmFtZWVuPSJ6aGFuZyB6aGVuZzAwMDA3OTQwIj48ZGl2IGNsYXNzPSJ6TWFpbFNp Z25Db250ZW50Ij48ZGl2PjxwIHN0eWxlPSJtYXJnaW46MDtsaW5lLWhlaWdodDoyMHB4OyI+PGEg aHJlZj0iaHR0cDovL3d3dy56dGUuY29tLmNuLyIgdGFyZ2V0PSJfYmxhbmsiPjxicj48L2E+PC9w PjwvZGl2PjwvZGl2PjwvZGl2PjxkaXYgY2xhc3M9InpNYWlsRnJvbSI+PC9kaXY+PGRpdj48ZGl2 IGNsYXNzPSJ6aGlzdG9yeVJvdyIgc3R5bGU9ImRpc3BsYXk6YmxvY2siPjxkaXYgY2xhc3M9Inpo aXN0b3J5RGVzIiBzdHlsZT0id2lkdGg6IDEwMCU7IGhlaWdodDogMjhweDsgbGluZS1oZWlnaHQ6 IDI4cHg7IGJhY2tncm91bmQtY29sb3I6ICNFMEU1RTk7IGNvbG9yOiAjMTM4OEZGOyB0ZXh0LWFs aWduOiBjZW50ZXI7IiBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5T3JnVHh0Ij7ljp/lp4vpgq7ku7Y8 L2Rpdj48ZGl2IGlkPSJ6d3JpdGVIaXN0b3J5Q29udGFpbmVyIj48ZGl2IGNsYXNzPSJjb250cm9s LWdyb3VwIHpoaXN0b3J5UGFuZWwiPjxkaXYgY2xhc3M9InpoaXN0b3J5SGVhZGVyIiBzdHlsZT0i cGFkZGluZzogOHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiAjRjVGNkY4OyI+PGRpdj48c3Ryb25nIGxh bmd1YWdlLWRhdGE9Ikhpc3RvcnlTZW5kZXJUeHQiPuWPkeS7tuS6uu+8mjwvc3Ryb25nPjxzcGFu IGNsYXNzPSJ6cmVhZFVzZXJOYW1lIj5HcmVnU2hlcGhlcmQgJmx0O2dqc2hlcEBnbWFpbC5jb20m Z3Q7PC9zcGFuPjwvZGl2PjxkaXY+PHN0cm9uZyBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5VE9UeHQi PuaUtuS7tuS6uu+8mjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJ6cmVhZFVzZXJOYW1lIiBzdHlsZT0i ZGlzcGxheTogaW5saW5lOyI+SmVmZnJleSAoWmhhb2h1aSkgWmhhbmcgJmx0O3p6aGFuZz00MGp1 bmlwZXIubmV0QGRtYXJjLmlldGYub3JnJmd0Ozs8L3NwYW4+PC9kaXY+PGRpdj48c3Ryb25nIGxh bmd1YWdlLWRhdGE9Ikhpc3RvcnlDQ1R4dCI+5oqE6YCB5Lq677yaPC9zdHJvbmc+PHNwYW4gY2xh c3M9InpyZWFkVXNlck5hbWUiIHN0eWxlPSJkaXNwbGF5OiBpbmxpbmU7Ij5iaWVyQGlldGYub3Jn ICZsdDtiaWVyQGlldGYub3JnJmd0Ozs8L3NwYW4+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUi IHN0eWxlPSJkaXNwbGF5OiBpbmxpbmU7Ij5Ub2VybGVzcyBFY2tlcnQgJmx0O3R0ZUBjcy5mYXUu ZGUmZ3Q7Ozwvc3Bhbj48L2Rpdj48ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeURh dGVUeHQiPuaXpSDmnJ8g77yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9IiI+MjAyMOW5tDAy5pyIMTnm l6UgMDQ6NDY8L3NwYW4+PC9kaXY+PGRpdj48c3Ryb25nIGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlT dWJqZWN0VHh0Ij7kuLsg6aKYIO+8mjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJ6cmVhZFRpdGxlIj48 c3Ryb25nPltCaWVyXSBXR0xDIC0gZHJhZnQtaWV0Zi1iaWVyLXRlLWFyY2ggMSBXRUVLPC9zdHJv bmc+PC9zcGFuPjwvZGl2PjwvZGl2PjxkaXYgem1haWxidXNpbmVzcz0iYnVzaW5lc3NFeHRlcm5h bCI+PC9kaXY+PGRpdiBjbGFzcz0iemhpc3RvcnlDb250ZW50Ij48ZGl2Pl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPkJJRVImbmJzcDttYWlsaW5nJm5i c3A7bGlzdDxicj5CSUVSQGlldGYub3JnPGJyPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vYmllcjxicj48YnI+PGRpdiBkaXI9Imx0ciI+PGRpdj5UaGFua3MgVG9lcmxlc3Mg YW5kIEplZmZyZXk8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYmllci10ZS1hcmNoLyIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYmllci10 ZS1hcmNoLzwvYT48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5PbmUgbW9yZSB3ZWVrIG9m IFdHTEMuIFBsZWFzZSByZWFkIHRoZSBsYXRlc3QgcmV2IGFuZCByZXNwb25kIHRvIHRoaXMgdGhy ZWFkIHcvd28gc3VwcG9ydC48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkNoYWlyczwvZGl2Pjxk aXY+KFNoZXApPC9kaXY+PGRpdj48YnI+PC9kaXY+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3Rl Ij48ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+T24gVHVlLCBGZWIgMTgsIDIwMjAg YXQgMTI6MDcgUE0gSmVmZnJleSAoWmhhb2h1aSkgWmhhbmcgJmx0O3p6aGFuZz08YSBocmVmPSJt YWlsdG86NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwanVu aXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+PC9kaXY+PGJsb2NrcXVv dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2Jv cmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPkhp IFRvZXJsZXNzLDxicj48YnI+VGhhbmtzITxicj5JIHN1cHBvcnQgbW92aW5nIHRoaXMgdG8gdGhl IG5leHQgc3RhZ2UuPGJyPjxicj5KZWZmcmV5PGJyPjxicj5PbiBGcmksIE5vdiAwMSwgMjAxOSBh dCAwNzo0MjozOFBNICswMTAwLCBUb2VybGVzcyBFY2tlcnQgd3JvdGU6PGJyPiZndDsgVGhhbmtz IEplZmY8YnI+Jmd0OyA8YnI+Jmd0OyBJIGhhdmUgbm93IHB1c2hlZCBvdXQgLTA1IHdpdGggdGhl IGFuc3dlcnMgYW5kIGhvcGVmdWxseSByZXNvbHV0aW9uIHRvIDxicj4mZ3Q7IHlvdXIgcG9pbnRz IGluIGVtYWlsIGJlbG93LiZuYnNwOyBCaWdnZXN0IGFkZGl0aW9uIHdhcyBhIHNlY3Rpb24gYWJv dXQgPGJyPiZndDsgcmV1c2Ugb2YgQlBzICh3aXRob3V0IEROUikgd2hpY2ggY2FtZSBvdXQgb2Yg dGhlIGNvbmZ1c2lvbiBpIHRoaW5rIHRoZSA8YnI+Jmd0OyByZXVzZSBpbiB0aGUgRUNNUCBleGFt cGxlIHJhaXNlZC4gSSB3YXMgYWZyYWlkIHNvIGZhciB0byBleHBsYW4gdGhhdCA8YnI+Jmd0OyBh cyBpdCBtYXkgbm90IGJlIGVhc3kgdG8gYWJzb3JiIGFuZCB1bHRpbWF0ZWx5IGlzIHN0dWZmIG9u bHkgPGJyPiZndDsgY29udHJvbGxlciBkZXZlbG9wZXJzIG5lZWQgdG8gdW5kZXJzdGFuZCwgYnV0 IGhvcGVmdWxseSB1c2VmdWwuPGJyPiZndDsgQW5kIHRoZW4gb2YgY291cnNlIHRoZSBzdW1tYXJ5 IG9mIEJQIG9wdGltaXphdGlucyB5b3UgYXNrZWQgZm9yPGJyPiZndDsgPGJyPiZndDsgRGlmZiBm cm9tIGxhc3QgdmVyc2lvbiBpIHNlbnQgeW91Ojxicj4mZ3Q7IDxicj4mZ3Q7IDxhIGhyZWY9Imh0 dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwOi8vdG9vbHMuaWV0Zi5vcmcvKnJmY2RpZmY/ dXJsMT1odHRwcyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly91cmxk ZWZlbnNlLmNvbS92My9fX2h0dHA6Ly90b29scy5pZXRmLm9yZy8qcmZjZGlmZj91cmwxPWh0dHBz PC9hPjo8YnI+Jmd0OyAqKjxhIGhyZWY9Imh0dHA6Ly9BcmF3LmdpdGh1YnVzZXJjb250ZW50LmNv bSIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+QXJhdy5naXRodWJ1c2VyY29udGVu dC5jb208L2E+KnRvZXJsZXNzKmJpZXItdGUtYXJjaCptYXN0ZXIqZHJhZnQtaWV0Zi1iPGJyPiZn dDsgaWVyLXRlLWFyY2gtMDUuMS50eHQmYW1wO3VybDI9aHR0cDoqKjxhIGhyZWY9Imh0dHA6Ly9B dG9vbHMuaWV0Zi5vcmciIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPkF0b29scy5p ZXRmLm9yZzwvYT4qaWQqZHJhZnQtaWV0Zi1iaWVyLXRlPGJyPiZndDsgLWFyY2gtMDUudHh0X187 THk4dkx5OHZMeTh2THk4ISFORXQ2eU1hTy1nayFWdVFDVkhucUp5X2FZSS1GTnQ5QTFhNUV6SDxi cj4mZ3Q7IE9DcjBmWmtMUGJnZzNDUE51MFB5cldzckZ4NDFfaldYMkF0OFYtJDxicj4mZ3Q7IDxi cj4mZ3Q7IGZ1bGwgLTA0IC0mZ3Q7IDA1IGRpZmY6PGJyPiZndDsgPGJyPiZndDsgPGEgaHJlZj0i aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHA6Ly90b29scy5pZXRmLm9yZy8qcmZjZGlm Zj91cmwxPWh0dHA6KiIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly91 cmxkZWZlbnNlLmNvbS92My9fX2h0dHA6Ly90b29scy5pZXRmLm9yZy8qcmZjZGlmZj91cmwxPWh0 dHA6KjwvYT48YnI+Jmd0OyAqPGEgaHJlZj0iaHR0cDovL0F0b29scy5pZXRmLm9yZyIgcmVsPSJu b3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+QXRvb2xzLmlldGYub3JnPC9hPippZCpkcmFmdC1p ZXRmLWJpZXItdGUtYXJjaC0wNC50eHQmYW1wO3VybDI9aHR0cDoqKkF0b29scy48YnI+Jmd0OyA8 YSBocmVmPSJodHRwOi8vaWV0Zi5vcmciIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsi PmlldGYub3JnPC9hPippZCpkcmFmdC1pZXRmLWJpZXItdGUtYXJjaC0wNS50eHRfXztMeTh2THk4 dkx5OHYhIU5FdDZ5TWFPLWdrPGJyPiZndDsgIVZ1UUNWSG5xSnlfYVlJLUZOdDlBMWE1RXpIT0Ny MGZaa0xQYmdnM0NQTnUwUHlyV3NyRng0MV9qV2FuY3B6aXYkPGJyPiZndDsgPGJyPiZndDsgQ29t bWVudHMgaW5saW5lIGJlbG93Ljxicj4mZ3Q7IDxicj4mZ3Q7IENoZWVyczxicj4mZ3Q7Jm5ic3A7 ICZuYnNwOyAmbmJzcDt0b2VybGVzczxicj4mZ3Q7IDxicj4mZ3Q7IE9uIE1vbiwgT2N0IDI4LCAy MDE5IGF0IDA3OjUyOjU5UE0gKzAwMDAsIEplZmZyZXkgKFpoYW9odWkpIFpoYW5nIHdyb3RlOjxi cj4mZ3Q7ICZndDsgSSBUaG91Z2h0IHUtdHVybiBpcyB0aGUgbW9zdCBzaW1wbGUgY29tcGFyaXNv biBsZWFmIHZzLiBub24tbGVhZiBCRlIuPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IFp6aCZn dDsgVGhlIHRleHQgaW4gdGhlIGVtYWlsIGlzIHNlcmlvdXNseSBtaXNhbGlnbmVkLiBMb29raW5n IGF0IHRoZSBwaWN0dXJlIGluIHRoZSBkaWZmIGxpbmssIHdoaWxlIHlvdSBnYXZlIGEgVS10dXJu IGV4YW1wbGUsIHRob3VnaCBldmVuIGlmIEJGRVIyIGlzIG5vdCBjb25uZWN0ZWQgdG8gQkZSMiZu YnNwOyBidXQgb25seSBjb25uZWN0ZWQgdG8gQkZFUjEgKGhlbmNlIG5vIFUtdHVybiksIHRoZW4g QkZFUjEgaXMgc3RpbGwgbm90IGEgbGVhZiBCRkVSIEkgc3VwcG9zZS4gVGhhdCdzIHdoeSBJIHNh aWQgdGhlIGZpcnN0IHNlbnRlbmNlIG9mIHRoZSBhYm92ZSBwYXJhZ3JhcGggaXMgZW5vdWdoIHRv IGRlZmluZSBMZWFmIEJGRVIgd2hpbGUgdGhlIGV4YW1wbGUgaXRzZWxmIGlzIGFjdHVhbGx5IG5v dCBuZWVkZWQuPGJyPiZndDsgPGJyPiZndDsgQXJnaC4uLiBvaywgaGFkIHRvIGZpeCB0d28gd29y ZHMsIEJGSVItJmd0O0JGRVIgYW5kIGxlZnQtaGFuZCAtJmd0OyByaWdodC1oYW5kOjxicj4mZ3Q7 IDxicj4mZ3Q7IENvbnNpZGVyIGhvdyByZWR1bmRhbnQgZGlzam9pbnQgdHJhZmZpYyBjYW4gcmVh Y2ggQkZFUjEvQkZFUjIgaW4gYWJvdmUgPGJyPiZndDsgcGljdHVyZTogV2hlbiBCRkVSMS9CRkVS MiBhcmUgTm9uLUxlYWYgQkZFUiBhcyBzaG93biBvbiB0aGUgcmlnaHQgaGFuZCA8YnI+Jmd0OyBz aWRlLCBvbmUgdHJhZmZpYyBjb3B5IHdvdWxkIGJlIGZvcndhcmRlZCB0byBCRkVSMSBmcm9tIEJG UjEsIGJ1dCB0aGUgPGJyPiZndDsgb3RoZXIgb25lIGNvdWxkIG9ubHkgcmVhY2ggQkZFUjEgdmlh IEJGRVIyLCB3aGljaCBtYWtlcyBCRkVSMiBhIDxicj4mZ3Q7IG5vbi1MZWFmIEJGRVIuIExpa2V3 aXNlIEJGRVIxIGlzIGEgbm9uLUxlYWYgQkZFUiB3aGVuIGZvcndhcmRpbmcgPGJyPiZndDsgdHJh ZmZpYyB0byBCRkVSMjxicj4mZ3Q7IDxicj4mZ3Q7ICZndDsgWnpoJmd0OyBBZGRpdGlvbmFsbHks IGluIGxlZnQgcGFydCBvZiB0aGUgcGljdHVyZSB5b3UgYWRkZWQsIGlmIHNvbWUgZmFpbHVyZSBs ZWFkcyB0byBCRlIyIHRvIGJlIG9ubHkgcmVhY2hhYmxlIHZpYSBCRkVSMSwgdGhlbiBCRkVSMSBp cyBubyBsb25nZXIgYSBsZWFmIEJGRVIuIDxicj4mZ3Q7IDxicj4mZ3Q7IEFkZGVkIHNlbnRlbmNl Ojxicj4mZ3Q7IDxicj4mZ3Q7ICZsdDt0Jmd0O05vdGUgdGhhdCB0aGUgQkZFUiBpbiB0aGUgbGVm dCBoYW5kIHBpY3R1cmUgYXJlIG9ubHkgZ3VhcmFudGVlZCB0byA8YnI+Jmd0OyBiZSBsZWFmLUJG UiBieSBmaXR0aW5nIHJvdXRpbmcgY29uZmlndXJhdGlvbiB0aGF0IHByb2hpYml0cyB0cmFuc2l0 IDxicj4mZ3Q7IHRyYWZmaWMgdG8gcGFzcyB0aHJvdWdoIGEgUEUsIHdoaWNoIGlzIGNvbW1vbmx5 IGFwcGxpZWQgaW4gdGhlc2UgPGJyPiZndDsgdG9wb2xvZ2llcy4mbHQ7L3QmZ3Q7PGJyPiZndDsg PGJyPiZndDsgJmd0OyBJIGFzc3VtZSB5b3UgZG9uJ3QgcmVhc3NpZ24gQlBzIHdoZW4gbGlua3Mg Z28gdXAgYW5kIGRvd24uPGJyPiZndDsgPGJyPiZndDsgSSBkaWRuJ3Qgd2FudCB0byBkaXNjdXNz IHRoYXQgb3B0aW9uIGluIHRoaXMgZG9jdW1lbnQuIEl0cyBvYnZpb3VzbHkgPGJyPiZndDsgcGVy ZmVjdGx5IGZlYXNpYmxlLCBidXQgYmUgeWV0IGEgYmlnIGFtb3VudCBvZiB0ZXh0IChlc3BlY2lh bGx5IHRoZSA8YnI+Jmd0OyBjb25zaWRlcmF0aW9ucyBob3cgdG8gZG8gdGhpcyBtYWtlLWJlZm9y ZS1icmVhay4gRnV0dXJlIGRvYy48YnI+Jmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsgYnV0IHN1YnNl cXVlbnQgcG9sYXJpemF0aW9uIGV4YW1wbGUgY29uZnVzZXMgbWUuIEl0IHNlZW1zIHRoYXQgQlAg MDo2IGlzIGFzc2lnbmVkIHRvIHRoZSByb3V0ZWQgYWRqYWNlbmN5IEJGUjEwICh3aGljaCBpcyBh Y3R1YWxseSB0YWxrZWQgYWJvdXQgaW4gU2VjdGlvbiA0LjgpLjxicj4mZ3Q7ICZndDsgPGJyPiZn dDsgJmd0OyBTZWN0aW9uIDQuNyBkb2VzIG5vdCBtZW50aW9uICJyb3V0ZWQiIGF0IGFsbCwgc28g dGhlcmUgYXJlIG5vIHJvdXRlZCBhZGphY2VuY2llcyBhdCBhbGwgdXNlZCBpbiA0LjcuIFNvIGkg YW0gbm90IHN1cmUgd2hhdCB5b3UgYXJlIGNvbmZ1c2VkIGFib3V0Ljxicj4mZ3Q7ICZndDsgPGJy PiZndDsgJmd0OyBaemgmZ3Q7ICJUaGUgQklGVCBvZiBlYWNoIEJGUiBhcmUgb25seSBwb3B1bGF0 ZWQgd2l0aCBCUHMgdGhhdCBhcmUgYWRqYWNlbnQgdG8gdGhlIEJGUiBpbiB0aGUgQklFUi1URSB0 b3BvbG9neSIuPGJyPiZndDsgPGJyPiZndDsgQ29ycmVjdCB0ZXh0IGZyb20gdGhlIGludHJvZHVj dGlvbi4gT2suPGJyPiZndDsgPGJyPiZndDsgJmd0OyBaemgmZ3Q7IFNpbmNlIHRoZSBzYW1lIDA6 NiBpcyBpbiBCSUZUUyBvZiBCRlIxL0JGUjIvQkZSMyAoYW5kIEkgc3VwcG9zZSBpbiBCRlI0fkJG UjkgYXMgd2VsbCBldmVuIHRob3VnaCBub3QgZHJhd24pLCBJIGFzc3VtZWQgaXQncyBmb3IgdGhl ICJNUDJQIiByb3V0ZWQgYWRqYWNlbmN5IHRvIFIxMDsgdGhvdWdoIEkgdGhlbiBydWxlZCB0aGF0 IG91dCAtIGJ1dCBJIGRvbid0IGtub3cgd2hhdCAwOjYgcmVwcmVzZW50IG5vdyBvbiBCRlIxLCBC RlIyLCBhbmQgQkZSMy48YnI+Jmd0OyA8YnI+Jmd0OyBBaC4gT2suIEkgdGhvdWdodCBpIGNvdWxk IHN0cmlwIGRvd24gdGhlIGV4YW1wbGUgdG8gc2hvdyBvbmx5IHRoZSA8YnI+Jmd0OyBhZGphY2Vu Y2llcyByZWxldmFudCB0byB0aGUgZm9sbG93aW5nIGRpc2N1c2lvbiwgYnV0IHNlZW1pbmdseSB0 aGlzIDxicj4mZ3Q7IGNhbiBpbnRyb2R1Y2UgdGhlIGNvbmZ1c2lvbiB5b3UgaGF2ZS48YnI+Jmd0 OyA8YnI+Jmd0OyBTbyBpIGNvbXBsZXRlZCB0aGUgZXhhbXBsZSB3aXRoIHRoZSBCUCBhc3NpZ25t ZW50IGFjb3NzIGFsbCBub2RlcywgYnV0IDxicj4mZ3Q7IGFkZGVkIHRleHQgcG9pbnRpbmcgdG8g YSBuZXcgc2VjdGlvbiBmdXJ0aGVyIGRvd24gdG8gZGlzY3VzcyB0aGUgPGJyPiZndDsgcmUtdXNl IG9mIEJQIGZvciB3aGljaCB0aGkgcGljdHVyZSBpcyBhbHNvIGFuIGV4YW1wbGUuPGJyPiZndDsg PGJyPiZndDsgKGNoZWNrIG91dCB0aGUgZGlmZiwgbmV3IHJldXNlIHRleHQgdG8gbG9uZyB0byBj b3B5IGlubGluZSkuPGJyPiZndDsgPGJyPiZndDsgJmd0OyBUaGUgd2hvbGUgcHVycG9zZSBvZiB0 aGUgRUNNUCBCUHMgaXMgb2YgY291cnNlIHRvIHNhdmUgYml0cywgb3RoZXJ3aXNlIHdlJ2QgZ2l2 ZSBlYWNoIGxpbmsgYSBzZXBhcmF0ZSBCUCwgd2hpY2ggd291bGQgYmUgNiBCUCB0byByZWFjaCB0 byBCRlI0Li4uQkZSNyBmcm9tIEJGUjEuIDxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBaemgm Z3Q7IFRoZSB0cm91YmxlIEkgYW0gaGF2aW5nIGlzIHRoYXQgdGhlIHNhbWUgMDo2IGlzIGFzc2ln bmVkIHRvIGRpZmZlcmVudCB0aGluZ3MgYW5kIGl0J3MgcHJlc2VudCBvbiBhbGwgQkZSMS9CRlIy L0JGUjMuIEl0IGlzIHBlcmhhcHMgYW4gaW50ZW50aW9uYWwgc21hcnQgZGVzaWduIGJ1dCBJIGhh dmUgbm90IHdyYXBwZWQgbXkgbWluZCBhcm91bmQgaXQuIEl0J3MgYXBwYXJlbnRseSBkaWZmZXJl bnQgZnJvbSB0aGUgbGluayBidW5kbGUgY2FzZSwgc28gYmV0dGVyIHNlcGFyYXRlIGl0IG91dCBh bmQgZWxhYm9yYXRlIGl0IChpbmNsdWRpbmcgdGhlIEROUiBmbGFnIHRoYXQgbWlnaHQgYmUgbmVl ZGVkIGhlcmUgLSBJZiB0aGUgcGFja2V0IGFycml2ZXMgb24gQkZSMSB3aXRoIDA6Niwgd291bGQg dGhlIEJQIHJlc2V0IHdoZW4gaXQgaXMgc2VudCB0byBCRlIyLzMpPzxicj4mZ3Q7IDxicj4mZ3Q7 IFllcywgdGhlcmUgd2FzIHRoZSBidWcgb2YgcmV1c2luZyBCUCAwOjYgYWNyb3NzIHNlcXVlbnRp YWwgQkZSIGFsb25nIDxicj4mZ3Q7IHRoZSBwYXRoLCBidXQgbm93IHRoZSBleGFtcGxlIGNvcnJl Y3RseSByZXVzZXMgc2VwYXJhdGUgQlAgYXQgPGJyPiZndDsgZGlmZmVyZW50IHN0YWdlcyBvZiB0 aGUgcGF0aHMgKEJQIDA6NiBvbiBCRlIxLCBCUCAwOjcgb24gQkZSMi9CRlIzKSBhbmQgc28gb24u PGJyPiZndDsgPGJyPiZndDsgVGhhbmtzITxicj4mZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyA0Ljgu Jm5ic3A7IFJvdXRlZCBhZGphY2VuY2llczxicj4mZ3Q7ICZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7 ICZndDsgSWYgSSB1bmRlcnN0YW5kIGl0IGNvcnJlY3RseSwgdGhlcmUgaXMgYSBCUCBhc3NpZ25l ZCB0byBMMS9MMi9MMyA8YnI+Jmd0OyAmZ3Q7ICZndDsgcmVzcGVjdGl2ZWx5IChwMnAgbGluayks IGFuZCB0aGVuIHRoZXJlIGFyZSBCUHMgYXNzaWduZWQgdG8gTVAyUCB0dW5uZWxzIChyb3V0ZWQg YWRqYWNlbmN5IGZyb20gZXZlcnkgQkZSKSB0byB0aGUgTDEvTDIvTDMgaW50ZXJmYWNlIGFkZHJl c3NlcyBhbmQgbG9vcGJhY2sgYWRkcmVzc2VzIG9uIEJGUjIvMy48YnI+Jmd0OyAmZ3Q7IDxicj4m Z3Q7ICZndDsgT2sgdGhhdCB3YXNuJ3QgcXVpdGUgdGhlIHJlYWQgaSBleHBlY3RlZC4gTGV0IG1l IGNsYXJpZnkgdGhlIHRleHQvcGljdHVyZTo8YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgLi4uLi4uLi4uLi4uLi4uJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+Jmd0OyAmZ3Q7 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAuLi5CRlIxLS0uLi4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy4uLi0tTDEtLSBCRlIyLi4uPGJyPiZndDsg Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOy4uLiAuUm91dGVycy4gLi4uLS1MMi0tLyZuYnNwOyA8YnI+Jmd0OyAm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAuLi5CRlI0LS0uLi4mbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy4uLi0tLS0tLSBCRlIzLi4uPGJyPiZn dDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAuLi4uLi4uLi4uLi4uLi4mbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7fDxicj4mZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtMTzxicj4mZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TmV0d29yayBBcmVhIDE8 YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgQXNzdW1lIHRoZSByZXF1aXJlbWVudCBpbiB0aGUg YWJvdmUgcGljdHVyZSBpcyB0byBleHBsaWNpdGx5IHN0ZWVyIHRyYWZmaWMgZmxvd3MgdGhhdCBo YXZlIGFycml2ZWQgYXQgQkZSMSBvciBCRlI0IHZpYSBhIHNob3J0ZXN0IHBhdGggaW4gdGhlIHJv dXRpbmcgdW5kZXJsYXkgIm5ldHdvcmsgYXJlYSAxIiB0byBvbmUgb2YgdGhlIGZvbGxvd2luZyB0 aHJlZSBuZXh0IHNlZ21lbnRzOiAoMSkgQkZSMiB2aWEgbGluayBMMSwgKDIpIEJGUjIgdmlhIGxp bmsgTDIsICgzKSB2aWEgQkZSMy48YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgVG8gYWNoaWV2 ZSB0aGlzLCBib3RoIEJGUjEgYW5kIEJGUjQgYXJlIHNldCB1cCB3aXRoIGEgZm9yd2FyZF9yb3V0 ZWQgYWRqYWNlbmN5IEJpdFBvc2l0aW9uIHRvd2FyZHMgYW4gYWRkcmVzcyBvZiBCRlIyIG9uIGxp bmsgTDEsIGFub3RoZXIgZm9yd2FyZF9yb3V0ZWQgQml0UG9zaXRpb24gdG93YXJkcyBhbiBhZGRy ZXNzIG9mIEJGUjIgb24gbGluayBMMiBhbmQgYSB0aGlyZCBmb3J3YXJkX3JvdXRlZCBCaXRwb3Np dGlvbiB0b3dhcmRzIGEgbm9kZSBhZGRyZXNzIExPIG9mIEJGUjMuPGJyPiZndDsgJmd0OyA8YnI+ Jmd0OyAmZ3Q7IERvZXMgdGhpcyBjbGVhciBpcCB0aGUgY29uZnVzaW9uID88YnI+Jmd0OyAmZ3Q7 IDxicj4mZ3Q7ICZndDsgWnpoJmd0OyBUaGUgcGljdHVyZSBpcyBiYWRseSBtaXNhbGlnbmVkLiBJ J2xsIHdhaXQgdGlsbCA0LjcgcXVlc3Rpb25zIGFyZSBjbGVhcmVkLjxicj4mZ3Q7IDxicj4mZ3Q7 IE9rLjxicj4mZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyBJZiBCRlIyLzMgYXJlIGFsc28gQkZFUnMs IHRoZW4gdGhleSBhZGRpdGlvbmFsbHkgd2lsbCBoYXZlIEJGRVIgQlBzLjxicj4mZ3Q7ICZndDsg Jmd0OyBPbiBCRlIxLzQsIHRoZSBCSUZUIGVudHJpZXMgZm9yIHRoZSBNUDJQIEJQcyBmb3IgdGhl IEwxL0wyL0wzL2xvb3BiYWNrIGludGVyZmFjZSBhZGRyZXNzZXMgb2YgQkZSMi8zIHdpbGwgdXNl IGZvcndhcmRfcm91dGVkKGludGVyZmFjZS9sb29wYmFjayBhZGRyZXNzKS4gRm9yIGEgcGFja2V0 IHRvIGJlIGRlY2Fwc3VsYXRlZCBvbiBhIEJGRVIsIHRoZXJlIGlzIGEgbmVlZCBmb3IgYm90aCB0 aGUgQkZFUiBCUCBhbmQgYW5vdGhlciBCUCAocDJwL2xhbi9odWItc3Bva2Uvcm91dGVkLWFkamFj ZW5jeSkgaW4gdGhlIHBhY2tldCAodGhlIGZvcm1lciBpcyBmb3IgZGVjYXBzdWxhdGlvbiBhbmQg dGhlIGxhdHRlciBpcyBmb3IgZ2V0dGluZyBpdCB0aGVyZSkuPGJyPiZndDsgJmd0OyA8YnI+Jmd0 OyAmZ3Q7IFRoaXMgaXMgbm90IGRpc2N1c3NlZCBpbiB0aGlzIHNlY3Rpb24sIGJ1dCB5b3UgYXJl IHJpZ2h0IC0gdW5sZXNzPGJyPiZndDsgJmd0OyBCRlIyIG9yIEJGUjMgaXMgYSBsZWFmIEJGUi4g SW4gdGhhdCBjYXNlLCBpdCB3b3VsZCBqdXN0IGxldmVyYWdlIHRoZSBvbmUgc2hhcmVkICJsZWFm LUJGUiIgQlAsIHNvIHRoZXkgZG8gbm90IG5lZWQgYSBwZXItQkZFUiBCUCBmb3IgbG9jYWxfZGVj YXAoKS4gPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IFp6aCZndDsgUmlnaHQgLSBzaGFyZWQg bGVhZi1CRlIgQlAgYnV0IHN0aWxsIG5lZWQgdGhhdCBCUCAodGhlIGtleSBpcyB0aGF0IHdlIG5l ZWQgYSBCUCB0byBnZXQgcGFja2V0IHRvIGEgQkZFUiBhbmQgdGhlbiBhIEJQIGZvciBkZWNhcHN1 bGF0aW9uKS48YnI+Jmd0OyA8YnI+Jmd0OyBZb3UgZ290IGl0Ljxicj4mZ3Q7IDxicj4mZ3Q7ICZn dDsgJmd0OyBJZiB0aGF0Pz8/cyB0aGUgY2FzZSwgaXQ/Pz9zIHdvcnRoIHBvaW50IHRoZSBhYm92 ZSBvdXQuPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IEhtbS4uLiBUaGUgbG9naWMgb2YgQkZF UiBCUHMgaXMgdG90YWxseSBpbmRlcGVuZGVudCBvZiB0aGUgbG9naWMgb2YgZm9yd2FyZF9yb3V0 ZWQgYWRqYWNlbmN5LCBzbyBpIHdvdWxkIHdvcnJ5IHRoYXQgcmVwZWF0aW5nIHRoZSBleHBsYW5h dGlvbiBvZiBCRkVSIEJQcyB3b3VsZCBjb25mbGF0ZSB0aGUgZm9yd2FyZF9yb3V0ZWQgZXhwbGFu YXRpb24uPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IFp6aCZndDsgSXQncyBqdXN0IHRoYXQg dGhpcyBpcyBhIHBsYWNlIHdoZXJlIGFsbCBraW5kcyBvZiBCUHMgYXJlIHVzZWQgc28gaXQncyBn b29kIHRvIGhhdmUgYSBzdW1tYXJ5IChjb3VsZCBiZSBhIHN1YnNlY3Rpb24gNC45KS48YnI+Jmd0 OyA8YnI+Jmd0OyBZZXMsIGFkZGVkIHN1Y2ggYSBzdW1tYXJ5LiBQbHMuIGNoZWNrLjxicj4mZ3Q7 IDxicj4mZ3Q7ICZndDsgJmd0OyBBY3R1YWxseSwgdGhlIHJlYXNvbiB0aGF0IEkgdGhvdWdodCB0 aGlzIGlzIE1QMlAgaXMgdGhhdCAwOjYgaXMgcHJlc2VudCBvbiBSMSwgUjIsIGFuZCBSMyAoYW5k IG1vcmUgSSBhc3N1bWUpIGluIEZpZ3VyZSAxMiwgYnV0IG5vdyBJIHRoaW5rIGl0IGNhbj8/P3Qg YmUgTVAyUCAoc28gaXQgaXMgbm90IGNvcnJlY3QgdG8gaGF2ZSAwOjYgcHJlc2VudCBvbiB0aG9z ZSByb3V0ZXJzID8/PyBvbmx5IHRoZSBwMnAgdHVubmVsIGhlYWQvdGFpbCBzaG91bGQgaGF2ZSB0 aGUgQlAgcHJlc2VudCBpbiB0aGUgQklGVCkuIFRoZSByZWFzb24gaXMgdGhhdCBpZiBpdCB3ZXJl IE1QMlAsIGFueSByb3V0ZXIgZ2V0dGluZyBhIGNvcHkgd2lsbCBzZW5kIGl0IHRvIHRoZSBlbmRw b2ludCBvZiB0aGUgcm91dGVkIGFkamFjZW5jeSwgY2F1c2luZyBsb3RzIG9mIGR1cGxpY2F0ZXMu Li48YnI+Jmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IEFtIEkgZ2V0dGluZyB0aGlz IGNvcnJlY3Q/PGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IEkgdGhpbmsgeW91IGFyZSBzdGls bCBleHBsYWluaW5nIGZyb20gdGhlIG1pc3VuZGVyc3RzYW5kaW5nIHRoYXQgdGhlIEVDTVAgZXhw bGFuYXRpb25zIHdoZXJlIGFib3V0IHJvdXRlZCBhZGphY2VuY2llcy48YnI+Jmd0OyAmZ3Q7IDxi cj4mZ3Q7ICZndDsgSSBoYXZlIG5vdyBleHBhbmRlZCB0aGUgc29tZXdoYXQgdGVyc2UgdGV4dCBp biB0aGUgQklGVCB0YWJsZSBwaWN0dXJlcywgdG8gbWFrZSBpdCBjbGVhciB0aGF0IHRoZSBFQ01Q IGlzIGFjcm9zcyBtdWx0aXBlIGZvcndhcmRfY29ubmVjdGVkIGFkamFjZW5jaWVzIGluIHRoZSBl eGFtcGxlcy4gRm9yIGV4YW1wbGUsIGZpcnN0IEJJRlQgcGljdHVyZTo8YnI+Jmd0OyAmZ3Q7IDxi cj4mZ3Q7ICZndDsmbmJzcDsgJm5ic3A7QklGVCBlbnRyeSBpbiBCRlIxOjxicj4mZ3Q7ICZndDsm bmJzcDsgJm5ic3A7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPiZndDsgJmd0OyZuYnNwOyAmbmJzcDt8IEluZGV4IHwm bmJzcDsgQWRqYWNlbmNpZXMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8 PGJyPiZndDsgJmd0OyZuYnNwOyAmbmJzcDs9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+Jmd0OyAmZ3Q7Jm5ic3A7ICZu YnNwO3wgMDo2Jm5ic3A7ICZuYnNwO3wmbmJzcDsgRUNNUCh7Zm9yd2FyZF9jb25uZWN0ZWQoTDEs IEJGUjIpLCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyB8PGJyPiZndDsgJmd0OyZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBmb3J3YXJkX2Nv bm5lY3RlZChMMiwgQkZSMiksJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNw O3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IGZvcndhcmRfY29ubmVjdGVkKEwzLCBCRlIyKX0sIHNlZWQpJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxicj4mZ3Q7ICZndDsmbmJzcDsgJm5ic3A7LS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IE9mIGNvdXJzZSwgYW4gRUNNUCBhZGph Y2VuY3kgY2FuIGJlIGFjcm9zcyBhbnkgdHlwZSBvZiBhZGphY2VuY2llcywgYnV0IGFsbCB0aGUg dGV4dC9leHBsYW5hdGlvbnMgdXNlZCBmb3J3YXJkX2Nvbm5lY3RlZCwgYW5kIG5vdyB0aGUgcGlj dHVyZXMgc2hvdyB0aGF0IGV4cGxpY2l0bHkuPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IFp6 aCZndDsgSSBjYW4gdW5kZXJzdGFuZCB0aGUgbXVsdGktbGluayBjYXNlLCBidXQgdGhlIG11bHRp LWhvcCBFQ01QIGNhc2UgKGZyb20gQkZSMSB0b3dhcmRzIEJGUjEwKSBpcyBjb25mdXNpbmcgbWUu IEl0IHdvdWxkIGhlbHAgdG8gZ2l2ZSBhbiBleGFtcGxlIGhvdyBpdCBjYW4gYmUgdXNlZCwgV0lU SE9VVCB3b3JyeWluZyBhYm91dCBwb2xhcml6YXRpb24uPGJyPiZndDsgPGJyPiZndDsgUGxlYXNl IGNoZWNrIC0wNSB0ZXh0IHRoYXQgaGFzIHRoZSBmdWxsIHNldCBvZiBCSUZUIGxpc3RlZCBub3c6 PGJyPiZndDsgPGJyPiZndDsgVGhlcmUgaXMmbmJzcDsgcmVhbGx5IG5vdGhpbmcgbm90aGluZyB1 bmlxdWUgaW4gbXVsdGktaG9wIEVDTVAgZm9yIEJJRVItVEUgPGJyPiZndDsgdGhhdCB3ZSBkbyBu b3QgYWxzbyBoYXZlIGluIGFueSBvdGhlciBFQ01QLCBleGNlcHQgdGhlIGNvbmNsdXNpb24gdGhh dCA8YnI+Jmd0OyB3ZSB3YW50IHRvIHN1cHBvcnQgZmFzdCBIVyBoYXNoIG1lY2hhbmlzbXMgQU5E IGFsbG93IHRoZSBjb250cm9sbGVyIHRvIDxicj4mZ3Q7IHNldCB1cCBub24tcG9sYXJpemVkIG11 bHRpLWhvcCBFQ01QIEFORCBiZSBhYmxlIHRvIHByZWNhbGN1bGF0ZSBwYXRocy4gPGJyPiZndDsg SGVuY2UgdGhlIHNwZWNpZmljYXRpb24gb2YgRUNNUCBhZGphY2VuY2llcyB0byBoYXZlIGEgY29u dHJvbGxlciA8YnI+Jmd0OyBjb25maWd1cmFibGUgc2VlZC48YnI+Jmd0OyA8YnI+Jmd0OyBCdHc6 IFRoZSBwaWN0dXJlIGlzIG1heWJlIHVubmVjZXNzYXJpbHkgbGFyZ2UgYmVjYXVzZSBpJ3ZlIHVz ZWQgaXQgZm9yIDxicj4mZ3Q7IDIwIHllYXJzIHRvIGV4cGxhaW4gdGhlIHNhbWUgcG9sYXJpemF0 aW9uIGlzc3VlIGZvciB1bmljYXN0IHZzIDxicj4mZ3Q7IG11bHRpY2FzdCwgYW5kIGZvciBtdWx0 aWNhc3Qgb25seSBCRlIxMC4uLkJGUjQgYXJlIHJlbGV2YW50IChFQ01QIG9mIDxicj4mZ3Q7IHRo ZSBQSU0vbUxEUCBqb2lucyksIHdoZXJlYXMgZm9yIHVuaWNhc3QvQklFUiBvbmx5PGJyPiZndDsg QkZSMS4uLkJGUjcgYXJlIHJlbGV2YW50LiBCdXQgYmVpbmcgc3ltbWV0cmljLCB0aGUgcGljdHVy ZSBtYWtlcyBpdCA8YnI+Jmd0OyBjbGVhciBpdHMgdGhlIHNhbWUgcHJvYmxlbS48YnI+Jmd0OyA8 YnI+Jmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7IFRvIGluaGliaXQgbG9vcGluZyBpbiB0aGUg ZmFjZSBvZiBzdWNoIHBoeXNpY2FsIG1pc2NvbmZpZ3VyYXRpb24sPGJyPiZndDsgJmd0OyAmZ3Q7 Jm5ic3A7ICZuYnNwOyBvbmx5IGZvcndhcmRfY29ubmVjdGVkIGFkamFjZW5jaWVzIGFyZSBwZXJt aXR0ZWQgdG8gaGF2ZSBETlIgc2V0LCBhbmQ8YnI+Jmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7 IHRoZSBsaW5rIGxheWVyIGRlc3RpbmF0aW9uIGFkZHJlc3Mgb2YgdGhlIGFkamFjZW5jeSAoZS5n LiZuYnNwOyBNQUM8YnI+Jmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7IGFkZHJlc3MpIHByb3Rl Y3RzIGFnYWluc3QgY2xvc2luZyB0aGUgbG9vcC4mbmJzcDsgTGluayBsYXllcnMgd2l0aG91dCBw b3J0PGJyPiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyB1bmlxdWUgbGluayBsYXllciBhZGRy ZXNzZXMgc2hvdWxkIG5vdCBiZSB1c2VkIHdpdGggdGhlIEROUiBmbGFnIHNldC48YnI+Jmd0OyAm Z3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7ICZndDsgSXQ/Pz9zIG5vdCBjbGVhciBob3cgbGluayBsYXll ciBhZGRyZXNzIGhlbHBzPzxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBJIGhhdmUgZXhwYW5k ZWQgdGhpcyB0bzxicj4mZ3Q7ICZndDsgImxpbmsgbGF5ZXIgcG9ydCB1bmlxdWUgdW5pY2FzdCBk ZXN0aW5hdGlvbiBhZGRyZXNzIjxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBBa2E6IE1QTFMg b3IgZXRoZXJuZXQgaGF2ZSB1bmlxdWUgbGluayBsYXllciBkZXN0aW5hdGlvbiBkZXN0aW5hdGlv biBhZGRyZXNzZXMgKGxhYmVsIG9yIGRlc3RpbmF0aW9uIE1BQykuIElmIHlvdSB0aGluayBhYm91 dCBpbmNvcnJlY3RseSBwbHVnZ2VkIEhETEMgbGlua3MgKHN1Y2ggYXMgb2xkIFQxL1QzLy4uLiBs aW5rcyksIHRoZXkgb25seSBoYXZlIDIgZ2VuZXJpYyBhZGRyZXNzZXMsIGlmIGkgcmVtZW1iZXIg MSBvciAzIGluIHRoZSBIRExDIGZyYW1lLiBTbyB3aGVuIHlvdSBtaXNwbHVnIG9uZSBvZiB0aG9z ZSBwMnAgY2FibGVzIHdyb25nLCB0aGUgcGFja2V0cyB3b3VsZCBiZSBpbmNycmVjdGx5IHJlY2Vp dmVkIGJ5IHRoZSB3cm9uZyByZWNlaXZlciBub2RlIGFuZCB0aGVuIEROUiBjb3VsZCBjYXVzZSBw ZXJzaXN0ZW50IGxvb3BzIG9ubHkgc29sdmVkIGJ5IFRUTC48YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7 ICZndDsgWnpoJmd0OyAiQ29uc2lkZXIgaW4gdGhlIHJpbmcgcGljdHVyZSB0aGF0IGxpbmsgTDQg ZnJvbSBCRlIzIGlzIHBsdWdnZWQgaW50byB0aGUgTDEgaW50ZXJmYWNlIG9mIEJGUmEiIC0gc3Rp bGwgbm90IHN1cmUgaG93IGxhYmVsL21hYyBoZWxwcyBoZXJlLiBJIHN1cHBvc2UgdGhlIHJpbmcg dG9wb2xvZ3kgaXMgZGlzY292ZXJlZC92ZXJpZmllZCBieSB0aGUgY29udHJvbCBwbGFuZSBhbmQg d2hlbiB0aGUgbWlzY2FsbGluZyBoYXBwZW5zIHRoZW4gdGhlIHJpbmcgd2lsbCBub3QgaW5jbHVk ZSB0aGUgQkZSMS9CRlIyIHBhcnQgYW5kIEJGUjMgd2lsbCBub3QgaGF2ZSB0aGUgRE5SIHNldD8g SWYgcmluZyBkaXNjb3ZlcnkvdmFyaWNhdGlvbiBpcyBub3QgZG9uZSB0aGVuIHBlcmhhcHMgd2Ug c2hvdWxkIHBvaW50IG91dCB0aGF0IFJQRiBiYXNlZCBvbiBsaW5rIGxheWVyIGFkZHJlc3MgaXMg bmVlZGVkIC0gdGhlIGtleSBpcyBSUEYgKHdoaWNoIG5lZWRzIHVuaXF1ZSBsaW5rIGxheWVyIGFk ZHJlc3MpPzxicj4mZ3Q7IDxicj4mZ3Q7IEZvcmdldCBSUEYuIEJJRVIoLVRFKSBoYXMgbm8gUlBG IChpc3N1ZXMpLiBJdHMganVzdCBsaWtlIHVuaWNhc3QuIFJQRiA8YnI+Jmd0OyBpcyBqdXN0IGEg cHJvYmxlbSBmb3IgcmVjZWl2ZXIgb3JpZ2luYXRlZCBqb2lucyBsaWtlIGluIFBJTS9tTERQLCBi dXQgPGJyPiZndDsgbm90IHVuaWNhc3QvYmllcigtdGUpL1JTVlAtVEUuPGJyPiZndDsgPGJyPiZn dDsgRm9yd2FyZF9jb25uZWN0ZWQgaXMganVzdCBsaWtlIGEgdW5pY2FzdCBzdWJuZXQgYWRqYWNl bmN5IHRvIGEgZGlyZWN0IDxicj4mZ3Q7IG5laWdoYm9yOiBJbnRlcmZhY2UgYW5kIEwyIGFkZHJl c3NzIG9mIHRoZSBkZXN0aW5hdGlvbi48YnI+Jmd0OyA8YnI+Jmd0OyBUaGUgY29udHJvbGxlciAo Y291bGQgYmUgYSBodW1hbikgImFzc3VtZXMiIGEgcGFydGljdWxhciBwaHlzaWNpYWwgPGJyPiZn dDsgdG9wb2xvZ3ksIGZyb20gdGVsZW1ldHJ5L2tub3dsZWRnZS93aGF0ZXZlci4gSXQgdGhlbiBj YWxjdWxhdGVzIHRoZSA8YnI+Jmd0OyBkZXNpcmVkIEJJRVItVEUgdG9wb2xvZ3kgYW5kIHB1c2hl cyBpdCBkb3duLiBUaGlzIHRvcG9sb2d5IGlzIG1lYW50IHRvIDxicj4mZ3Q7IGJlIGxvb3AgZnJl ZSBvZiBjb3Vyc2Ugd3J0IHRvIHRoZSBjb25maWd1cmVkIGFkamFjZW5jaWVzLjxicj4mZ3Q7IElu IHRoaXMgQklFUi1URSB0b3BvbG9neSwgQkZSMyB3aWxsIGhhdmUgYSBCUCB3aXRoIHRoZSA8YnI+ Jmd0OyBmb3J3YXJkX2Nvbm5lY3RlZChMNCwgTUFDLW9mLUJGUjIpIGFkamFjZW5jeS48YnI+Jmd0 OyA8YnI+Jmd0OyBJZiB0aGUgY2FibGUgY29ubmVjdGluZyB0byBMNCBpcyBtaXN3aXJlZCwgdGhl biBCRlIzIHdvdWxkIHN0aWxsIHNlbmQgPGJyPiZndDsgdGhlIHBhY2tldHMgdG8gdGhlIE1BQyBh ZGRyZXNzIG9mIEJGUjIsIGJ1dCBnaXZlbiBob3cgdGhlIGNhYmxlIDxicj4mZ3Q7IGNvbm5lY3Rz IHRvIHNvbWUgb3RoZXIgbm9kZSwgdGhlc2UgcGFja2V0cyB3aWxsIGJlIGRpc2NhcmRlZCBieSB0 aGF0IDxicj4mZ3Q7IG5vZGUuIGJlY2F1c2UgdGhleSdyZSBqdXN0IEwyIHVuaWNhc3QgcGFja2V0 cy48YnI+Jmd0OyA8YnI+Jmd0OyBJIHRoaW5rIHRoaXMgaXMgZXF1YWxseSB0cnVlIHdoZW4gd2Ug aGF2ZSBub3JtYWwgQklFUi9NUExTIGVuYWNwLjxicj4mZ3Q7IFRob3NlIHBhY2tldHMgdG9vIGFy ZSBhZGRyZXNzZWQgdG8gdGhlIHVuaWNhc3QgTUFDIGFkZHJlc3Mgb2YgdGhlIDxicj4mZ3Q7IG5l aWdoYm9yLjxicj4mZ3Q7IDxicj4mZ3Q7IE5vdywgaWYvd2hlbiBoZSBjb250cm9sbGVyIHJlY29n bml6ZXMgdGhhdCB0aGUgcGh5c2ljYWwgdG9wb2xvZ3kgaGFzIDxicj4mZ3Q7IGNoYW5nZWQsIHRo YXRzIGEgY29tcGxldGVseSBkaWZmZXJlbnQgc3RvcnkgYW5kIG5vdCBhZGRyZXNzZWQgaGVyZS4g PGJyPiZndDsgR2l2ZW4gaG93IHdlIGFzc3VtZWQgdGhpcyB3YXMgYSBjYWJsaW5nIG1pc3Rha2Us IHRoZSBjb250cm9sbGVyIHdvdWxkIDxicj4mZ3Q7IHByb2JhYmx5IG9ubHkgY29tcGxhaW4gYWJv dXQgdGhlIG1pc3dpcmluZyB0byBvcGVyYXRpb25zIGJ1dCBiZSBoYXBweSA8YnI+Jmd0OyB0aGF0 IHRoZSBmb3J3YXJkaW5nIHBsYW5lIGp1c3QgbWFrZXMgcGFja2V0cyBmYWlsIGluc3RlYWQgb2Yg bG9vcC4gSWYgPGJyPiZndDsgdGhpcyB3YXMgYSBwbGFubmVkIGNoYW5nZSBwcm9jZXNzLCB0aGVu IGl0IHdpbGwgYmUgc2ltaWxhcmlseSA8YnI+Jmd0OyBjb252b2x1dGVkIGFzIGl0IHdvdWxkIHRv ZGF5IGJlIHdpdGggcmV3aXJpbmcgY2FibGVzIGluIGFuIDxicj4mZ3Q7IFNSLU1QTFMvU1J2NiB0 b3BvbG9neSBhbmQgdXBkYXRpbmcgU0lEcy48YnI+Jmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsgQmVj YXVzZSB0aGUgZm9yd2FyZGluZyBpcyBkaWZmZXJlbnQgZnJvbSBCSUVSIGZvcndhcmRpbmcgKGJl Y2F1c2Ugb2YgWzFdIGFib3ZlKSwgd2UgbWlnaHQgYXMgd2VsbCBpbnRyb2R1Y2UgYW4gb3B0aW1p emF0aW9uIGhlcmUgPz8/IGZvciBlYWNoIEJJRlQsIGNhbGN1bGF0ZSB0aGUgRi1CTSBvZiB0aGUg QklGVCBpdHNlbGYgKHRoZSBsb2dpY2FsID8/P29yPz8/IG9mIGFsbCB0aGUgQlBzIHByZXNlbnRl ZCBpbiB0aGlzIEJJRlQpIGFuZCB0aGVuIHVzZSAocGFja2V0LSZndDtiaXRzdHJpbmcgJmFtcDsg QklGVC5GLUJNKSBhcyB0aGUgaW5wdXQgdG8gR2V0Rmlyc3QvTmV4dEJpdFBvc2l0aW9uKCkuIFRo YXQgc2hvdWxkIHNraXAgbWFueSBiaXRzLjxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBSaWdo dC4gQnV0IGkgZXhwbGljaXRseSByZW1vdmVkIHRob3NlIG9wdGltaXphdGlvbnMgKGkgaGFkIHRo ZW0gaW4gb2xkZXIgZHJhZnQgdmVyc2lvbnMpIGJlY2F1c2UgdGhlIHdob2xlIGlkZWEgb2YgdGhp cyBwaWN0dXJlIGlzIHNvbGVseSB0aGUgY29tcGFyaXNvbiB3aXRoIGZpZ3VyZSA0IG9mIFJGQzgy NzkuPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IFp6aCZndDsgSSB0aGluayBpdCdzIHdvcnRo IHBvaW50IHRoYXQgb3B0aW1pemF0aW9uIG91dDsgeW91IGNhbiBtYXJrIGl0IG9wdGlvbmFsIGlm IHlvdSB3YW50IHRvIGVtcGhhc2l6ZSB0aGUgc2ltaWxhcml0eSB0byBCSUVSIGZvcndhcmRpbmcs IGJ1dCBzaW5jZSBCSUVSIGZvcndhcmRpbmcgZG9lcyBkbyB0aGUgbWFza29mZiBzdGVwLCBpdCBp cyB2ZXJ5IGVmZmljaWVudCB3aGlsZSBCSUVSLVRFIGZvcndhcmRpbmcgZG9lcyBub3QgaXQgdGhl IG1hc2tvZmYgc3RlcCBzbyB0aGlzIG9wdGltaXphdGlvbiBpcyBpbXBvcnRhbnQuPGJyPiZndDsg PGJyPiZndDsgT2suIEkgc2ltcGxpZmllZCB0aGUgdGV4dCBjb21wYXJpc29uIEJJRVIvQklFUi1U RSB3cnQuIHRvIHRoZSBGQk0gPGJyPiZndDsgcnVsZXMgWzFdIGFuZCBbMl0gYW5kIGFkZGVkIGZv bGxvd2luZyBwYXJhZ3JhcGg6PGJyPiZndDsgPGJyPiZndDsgJmx0O3QmZ3Q7SW4gQklFUiwgdGhl IG9yZGVyIG9mIEJQcyBpbXBhY3RzIHRoZSByZXN1bHQgb2YgZm9yd2FyZGluZyBiZWNhdXNlIG9m IFsxXS4gPGJyPiZndDsgSW4gQklFUi1URSwgZm9yd2FyZGluZyBpcyBub3QgaW1wYWN0ZWQgYnkg dGhlIG9yZGVyIG9mIEJQcy4gSXQgaXMgPGJyPiZndDsgdGhlcmVmb3JlIHBvc3NpYmxlIHRvIGZ1 cnRoZXIgb3B0aW1pemUgZm9yd2FyZGluZyB0aGFuIGluIEJJRVIuIEZvciA8YnI+Jmd0OyBleGFt cGxlIHBhcmFsbGVsaXppbmcgZm9yd2FyZGluZyBhY3Jvc3MgbXVsdGlwbGUgRlBFIGNvcmVzIG9y IDxicj4mZ3Q7IGRpc3RyaWJ1dGVkIGxpbmVjYXJkcyBkb2VzIG9ubHkgbmVlZCB0byBleGFtaW5l IGFuIGFyYml0cmFyeSBzdWJzZXQgb2YgPGJyPiZndDsgQlAgYW5kIG5vdCBldmFsdWF0ZSB0aGUg ZGVwZW5kZW5jeSBiZXR3ZWVuIEJQcy4mbHQ7L3QmZ3Q7PGJyPiZndDsgPGJyPiZndDsgJmd0OyAm Z3Q7Jm5ic3A7ICZuYnNwOyBUaGUgZm9sbG93aW5nIHBzZXVkb2NvZGUgaXMgY29tcHJlaGVuc2l2 ZTo8YnI+Jmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IFRoZSBhYm92ZSBzZW50ZW5j ZSByZWFkcyBhIGJpdCBzdHJhbmdlIChvciBsYWNrcyBzb21lIHNlZ3VlKS4uLjxicj4mZ3Q7ICZn dDsgPGJyPiZndDsgJmd0OyBJIGhvcGUgbm90LCBidXQgbWF5YmUgYmVzdCBsZWZ0IHRvIGEgbmF0 aXZlIGVuZ2xpc2ggc3BlYWtlciAoUkZDLWVkaXRvcikuPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAm Z3Q7IFRoZSBmaXJzdCAoUkZDODI3OSkgcHNldWRvY29kZSB3YXMgc2ltcGxpZmllZC4gVGhlIHNl Y29uZCBvbmUgaXMgY29tcHJlaGVuc2l2ZS4gSWYgbm90IGNvbXByZWhlbnNpdmUsIHdoYXRzIGEg Z29vZCBvcHBvc2l0ZSBvZiBzaW1wbGlmaWVkID88YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsg WnpoJmd0OyBQZXJoYXBzICJUaGUgYWJvdmUgc2ltcGxpZmllZCBwc2V1ZG9jb2RlIGlzIGVsYWJv cmF0ZWQgZnVydGhlciBhcyBmb2xsb3dpbmciPzxicj4mZ3Q7ICZndDsgWnpoJmd0OyBKZWZmcmV5 PGJyPiZndDsgPGJyPiZndDsgRG9uZS48YnI+Jmd0OyA8YnI+Jmd0OyBUaGFua3MgYSBsb3QuIDxi cj4mZ3Q7IDxicj4mZ3Q7IDxicj4mZ3Q7ICZndDsmbmJzcDsgJm5ic3A7IDxicj4mZ3Q7ICZndDsg Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsgJmd0 OyAmZ3Q7IEZyb206IEJJRVIgWzxhIGhyZWY9Im1haWx0bzpiaWVyLWJvdW5jZXNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5iaWVyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmx0O21haWx0bzo8YSBo cmVmPSJtYWlsdG86Ymllci1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Ymllci1i b3VuY2VzQGlldGYub3JnPC9hPiZndDtdIDxicj4mZ3Q7ICZndDsgJmd0OyBvbiBiZWhhbGYgb2Yg VG9lcmxlc3MgRWNrZXJ0IFs8YSBocmVmPSJtYWlsdG86dHRlQGNzLmZhdS5kZSIgdGFyZ2V0PSJf YmxhbmsiPnR0ZUBjcy5mYXUuZGU8L2E+Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dHRlQGNz LmZhdS5kZSIgdGFyZ2V0PSJfYmxhbmsiPnR0ZUBjcy5mYXUuZGU8L2E+Jmd0O108YnI+Jmd0OyAm Z3Q7ICZndDsgU2VudDogVHVlc2RheSwgSnVseSAwOSwgMjAxOSAyMzozODxicj4mZ3Q7ICZndDsg Jmd0OyBUbzogTWlrZSBNY0JyaWRlPGJyPiZndDsgJmd0OyAmZ3Q7IENjOiBHcmVnIFNoZXBoZXJk OyBCSUVSIFdHOyBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpPGJyPiZndDsgJmd0OyAmZ3Q7IFN1 YmplY3Q6IFJlOiBbQmllcl0gV0dMQyAtIGRyYWZ0LWlldGYtYmllci10ZS1hcmNoPGJyPiZndDsg Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyBUaGFua3MsIE1pa2U8YnI+Jmd0OyAmZ3Q7ICZn dDsgPGJyPiZndDsgJmd0OyAmZ3Q7IFRoZSBhdXRob3JzIGFsc28gcmV2aWV3ZWQgdGhlIGRvY3Vt ZW50IGFuZCBjb25jbHVkZWQgdGhhdCBpdCB3YXMgPGJyPiZndDsgJmd0OyAmZ3Q7IHJlYWxseSBo YXJkIHRvIGdldCBpbnRvIHRoZSBkb2N1bWVudCBjb250ZXh0IGJlY2F1c2Ugb2YgdG9vIG1hbnkg PGJyPiZndDsgJmd0OyAmZ3Q7IGZvcndhcmQgZGVwZW5kZW5jaWVzLiBXZSB0cmllZCB0byBmaXgg dGhpcyBieSBhZGRpbmcgdHdvIGhvcGVmdWxseSA8YnI+Jmd0OyAmZ3Q7ICZndDsgZ29vZCAmYW1w OyBiYXNpYyBleGFtcGxlcyBpbnRvIHRoZSBJbnRyb2R1Y3Rpb24gc2VjdGlvbiBhbmQgdXNpbmcg dGhlbSA8YnI+Jmd0OyAmZ3Q7ICZndDsgdG8gYWxzbyBhZGQgYSBiZXR0ZXIgZGVmaW5pdGlvbiBv ZiB0aGUgdGVybSAiQklFUi1URSBUb3BvbG9neSIgaW4gdGhlIEludHJvZHVjdGlvbi48YnI+Jmd0 OyAmZ3Q7ICZndDsgSG9wZWZ1bGx5IHRoaXMgbWFrZXMgcmVhZGluIHRoZSByZXN0IG9mIHRlIGRv Y3VtZW50IHNtb290aGVyLi4uPGJyPiZndDsgJmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyBB bHNvIGltcHJvdmVkIHRleHQgb2YgQWJzdHJhY3QgYW5kIHJlZmluZWQgdGV4dCBjb21wYXJpaW5n IEJJRVItVEUgd2l0aCBTUi48YnI+Jmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IDxh IGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwOi8vdG9vbHMuaWV0Zi5vcmcv KnJmY2RpZmY/dXJsMT1odHRwcyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHA6Ly90b29scy5pZXRmLm9yZy8qcmZjZGlmZj91 cmwxPWh0dHBzPC9hPjo8YnI+Jmd0OyAmZ3Q7ICZndDsgKio8YSBocmVmPSJodHRwOi8vQXRvb2xz LmlldGYub3JnIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5BdG9vbHMuaWV0Zi5v cmc8L2E+KmlkKmRyYWZ0LWlldGYtYmllci10ZS1hcmNoLTAyLnR4dCZhbXA7dXJsMj1odHRwczoq KkE8YnI+Jmd0OyAmZ3Q7ICZndDsgdG9vbDxicj4mZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJodHRw Oi8vcy5pZXRmLm9yZyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+cy5pZXRmLm9y ZzwvYT4qaWQqZHJhZnQtaWV0Zi1iaWVyLXRlLWFyY2gtMDMudHh0X187THk4dkx5OHZMeTh2IThX b0E2Ujxicj4mZ3Q7ICZndDsgJmd0OyBqQzgxIDxicj4mZ3Q7ICZndDsgJmd0OyBjIVh2SDRBQXhm ckRqRm9LX3NlcmN3Wk1zYzBPNU40MmVFTk9zNGxfcWRzWEYwS3daRDgyY0pMREZGTlZfZVRVRWg8 YnI+Jmd0OyAmZ3Q7ICZndDsgJDxicj4mZ3Q7ICZndDsgJmd0OyAmbHQ7PGEgaHJlZj0iaHR0cHM6 Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHA6L3Rvb2xzLmlldGYub3JnLypyZmNkaWZmP3VybDE9 aHR0cHMiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdXJsZGVmZW5z ZS5jb20vdjMvX19odHRwOi90b29scy5pZXRmLm9yZy8qcmZjZGlmZj91cmwxPWh0dHBzPC9hPjo8 YnI+Jmd0OyAmZ3Q7ICZndDsgKio8YSBocmVmPSJodHRwOi8vQXRvb2xzLmlldGYub3JnIiByZWw9 Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5BdG9vbHMuaWV0Zi5vcmc8L2E+KmlkKmRyYWZ0 LWlldGYtYmllci10ZS1hcmNoLTAyLnR4dCZhbXA7dXJsMj1odHRwczoqKkE8YnI+Jmd0OyAmZ3Q7 ICZndDsgdG9vbDxicj4mZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJodHRwOi8vcy5pZXRmLm9yZyIg cmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+cy5pZXRmLm9yZzwvYT4qaWQqZHJhZnQt aWV0Zi1iaWVyLXRlLWFyY2gtMDMudHh0X187THk4dkx5OHZMeTh2IThXb0E2Ujxicj4mZ3Q7ICZn dDsgJmd0OyBqQzgxIDxicj4mZ3Q7ICZndDsgJmd0OyBjIVVCVEd2V1dwTUh5ZWlTYW54czZ2SWJf RW5CVmd5ZzZib0FBVzRucnFqdThVQ0xPZ2l1WGM4WV82c05kMW5qY1g8YnI+Jmd0OyAmZ3Q7ICZn dDsgJCZndDs8YnI+Jmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IENoZWVyczxicj4m Z3Q7ICZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7VG9lcmxlc3M8YnI+Jmd0OyAmZ3Q7ICZn dDsgPGJyPiZndDsgJmd0OyAmZ3Q7IE9uIFdlZCwgSnVuIDI2LCAyMDE5IGF0IDEwOjM5OjM2QU0g LTA3MDAsIE1pa2UgTWNCcmlkZSB3cm90ZTo8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBIb3cgYWJv dXQgdGhyZWU/IEkgc3VwcG9ydC48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBtaWtlPGJyPiZndDsg Jmd0OyAmZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBPbiBUdWUsIEp1biAyNSwgMjAx OSBhdCAxMDo0MiBBTSBHcmVnIFNoZXBoZXJkICZsdDs8YSBocmVmPSJtYWlsdG86Z2pzaGVwQGdt YWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdqc2hlcEBnbWFpbC5jb208L2E+Jmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86Z2pzaGVwQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdqc2hlcEBn bWFpbC5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0Ozxi cj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgV2UgY2Fubm90IHRha2UgdHdvICd5ZXMnIHZvdGVz IGFuZCBXRyBjb25zZW5zdXMuPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBQbGVhc2UsIHJl YWQgYW5kIHJlc3BvbmQuIElmIHlvdSBkb24ndCBzdXBwb3J0LCB0aGVuIHBsZWFzZSB2b3RlIGFz IG11Y2ggcHVibGljbHkgcmlnaHQgaGVyZS48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJy PiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBUaGFua3MsPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyBHcmVnPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsgT24gTW9uLCBKdW4gMywgMjAxOSBhdCAxMDowNSBQTSBQYXNjYWwgVGh1YmVydCAo cHRodWJlcnQpICZsdDs8YSBocmVmPSJtYWlsdG86cHRodWJlcnRAY2lzY28uY29tIiB0YXJnZXQ9 Il9ibGFuayI+cHRodWJlcnRAY2lzY28uY29tPC9hPiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRv OnB0aHViZXJ0QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnB0aHViZXJ0QGNpc2NvLmNvbTwv YT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7IFN1cHBvcnQ6PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBJIHNlZSBncmVhdCB2YWx1 ZSBpbiBkZXRlcm1pbmlzdGljIG5ldHdvcmtzIGFzIHdlbGwgYXMgSU9UICh3aXRoIFJQTCkuPGJy PiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 Jmd0OyBBbGwgdGhlIGJlc3QsPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDs8YnI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBQYXNjYWw8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7Jmd0Ozxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS08YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IEZyb206 IEJJRVI8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86Ymllci1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Ymllci1ib3VuY2Vz QGlldGYub3JnPC9hPiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmJpZXItYm91bmNlc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJpZXItYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7Jmd0OyBP biA8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IEJlaGFsZiBPZiBUb2VybGVz cyBFY2tlcnQ8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IFNlbnQ6IG1hcmRp IDQganVpbiAyMDE5IDAyOjAzPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyBU bzogR3JlZyBTaGVwaGVyZCA8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZs dDs8YSBocmVmPSJtYWlsdG86Z2pzaGVwQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdqc2hl cEBnbWFpbC5jb208L2E+Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86Z2pzaGVwQGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmdqc2hlcEBnbWFpbC5jb208L2E+Jmd0OyZndDs8YnI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IENjOiBCSUVSIFdHICZsdDs8YSBocmVmPSJtYWls dG86YmllckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJpZXJAaWV0Zi5vcmc8L2E+Jmx0O21h aWx0bzo8YSBocmVmPSJtYWlsdG86YmllckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJpZXJA aWV0Zi5vcmc8L2E+Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7 IFN1YmplY3Q6IFJlOiBbQmllcl0gV0dMQyAtIGRyYWZ0LWlldGYtYmllci10ZS1hcmNoPGJyPiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsmZ3Q7ICZndDsgKzE8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IE9idmlv dXNseSBzdXBwb3J0IGFzIGNvLWF1dGhvci48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0 OyAmZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyBPbiBXZWQsIE1heSAy OSwgMjAxOSBhdCAxMjo0MToyNlBNIC0wNzAwLCBHcmVnIFNoZXBoZXJkIHdyb3RlOjxicj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyBQbGVhc2UgcmVhZCBhbmQgcmVzcG9u ZCB0byB0aGlzIHRocmVhZCB3LyBvciB3L28gc3VwcG9ydC48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7 ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmciIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v dXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnPC9hPjxicj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyAvZG9jIDxicj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyAvZHJhZnQtaWV0Zi1iaWVyLXRlLWFyY2gvX187 IThXb0E2UmpDODFjIVh2SDRBQXhmckRqRm9LX3M8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 Jmd0OyAmZ3Q7ICZndDsgZXJjdyBaTXNjME81TjQyZUVOT3M0bF9xZHNYRjBLd1pEODJjSkxERkZO VjllQ2xCaiQ8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgJmx0Ozxh IGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3VybGRlZmVu c2UuY29tL3YzL19faHR0cHM6L2RhdGF0cmFja2VyLmlldGYub3JnLzwvYT48YnI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgZG9jLyA8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgZHJhZnQtaWV0Zi1iaWVyLXRlLWFyY2gvX187IThXb0E2UmpD ODFjIVVCVEd2V1dwTUh5ZWlTYW54PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0 OyAmZ3Q7IHM2dkkgYl9FbkJWZ3lnNmJvQUFXNG5ycWp1OFVDTE9naXVYYzhZXzZzRDQwa210SCQm Z3Q7PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAmZ3Q7PGJyPiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAmZ3Q7IFZvdGUgZW5kcyA1IEp1bmUgMjAxOS48YnI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgVGhhbmtzLDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsmZ3Q7ICZndDsgJmd0OyBTaGVwPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0 OyAmZ3Q7IChjaGFpcnMpPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0Ozxicj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsm Z3Q7ICZndDsgJmd0OyBCSUVSIG1haWxpbmcgbGlzdDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsmZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86QklFUkBpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPkJJRVJAaWV0Zi5vcmc8L2E+Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86QklFUkBp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkJJRVJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4mZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3VybGRlZmVu c2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi8iIHJlbD0ibm9yZWZlcnJl ciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuLzwvYT48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAm Z3Q7ICZndDsgbGlzdDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyBp bmZvL2JpZXJfXzshOFdvQTZSakM4MWMhWHZINEFBeGZyRGpGb0tfc2VyY3daTXNjME81TjQyZUU8 YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgTk9zNCBsX3Fkc1hGMEt3 WkQ4MmNKTERGRk5UMldWWFdYJCA8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7 ICZndDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovd3d3 LmlldGYub3JnL21haWxtYW4vIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3d3dy5pZXRmLm9yZy9tYWlsbWFuLzwvYT48 YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgbGlzdCA8YnI+Jmd0OyAm Z3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgaW5mby9iaWVyX187IThXb0E2UmpDODFj IVVCVEd2V1dwTUh5ZWlTYW54czZ2SWJfRW5CVmd5ZzZiPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyZndDsgJmd0OyAmZ3Q7IG9BQVcgNG5ycWp1OFVDTE9naXVYYzhZXzZzS24yS29BVCQmZ3Q7 PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IEJJRVIgbWFpbGlu ZyBsaXN0PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyA8YSBocmVmPSJtYWls dG86QklFUkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkJJRVJAaWV0Zi5vcmc8L2E+Jmx0O21h aWx0bzo8YSBocmVmPSJtYWlsdG86QklFUkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkJJRVJA aWV0Zi5vcmc8L2E+Jmd0Ozxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgPGEg aHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGkiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdXJsZGVm ZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpPC9hPjxicj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgc3RpbiA8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7Jmd0OyAmZ3Q7IGZvL2JpZXJfXzshOFdvQTZSakM4MWMhWHZINEFBeGZyRGpGb0tfc2Vy Y3daTXNjME81TjQyZUVOT3M0PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyBs X3FkPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyBzWEYwS3daRDgyY0pMREZG TlQyV1ZYV1gkPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAmbHQ7PGEgaHJl Zj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saSIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly91cmxkZWZlbnNl LmNvbS92My9fX2h0dHBzOi93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saTwvYT48YnI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IHN0aW4gPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyZndDsgJmd0OyBmby9iaWVyX187IThXb0E2UmpDODFjIVVCVEd2V1dwTUh5ZWlTYW54czZ2SWJf RW5CVmd5ZzZib0FBVzxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgNG5ycTxi cj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsganU4VUNMT2dpdVhjOFlfNnNLbjJL b0FUJCZndDs8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgQklFUiBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpCSUVSQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+QklFUkBpZXRmLm9yZzwvYT4mbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpCSUVSQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+QklFUkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0 cHM6Ly93d3cuLi5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aTwvYT48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IG5mby8gPGJy PiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBiaWVyX187IThXb0E2UmpDODFjIVh2SDRBQXhmckRq Rm9LX3NlcmN3Wk1zYzBPNU40MmVFTk9zNGxfcWRzWDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsgRjBLdzxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgWkQ4MmNKTERGRk5UMldWWFdYJDxi cj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5z ZS5jb20vdjMvX19odHRwczovd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGkiIHJlbD0ibm9yZWZl cnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczov d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGk8L2E+PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyBuZm8vIDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgYmllcl9fOyE4V29BNlJqQzgxYyFV QlRHdldXcE1IeWVpU2FueHM2dkliX0VuQlZneWc2Ym9BQVc0bnJxanU8YnI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7IDhVQ0w8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IE9naXVYYzhZXzZz S24yS29BVCQmZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyAtLTxicj4m Z3Q7ICZndDsgJmd0OyAtLS08YnI+Jmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOnR0ZUBj cy5mYXUuZGUiIHRhcmdldD0iX2JsYW5rIj50dGVAY3MuZmF1LmRlPC9hPiZsdDttYWlsdG86PGEg aHJlZj0ibWFpbHRvOnR0ZUBjcy5mYXUuZGUiIHRhcmdldD0iX2JsYW5rIj50dGVAY3MuZmF1LmRl PC9hPiZndDs8YnI+Jmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsgJmd0OyAmZ3Q7IEJJ RVIgbWFpbGluZyBsaXN0PGJyPiZndDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpCSUVSQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+QklFUkBpZXRmLi4ub3JnPC9hPiZsdDttYWlsdG86PGEg aHJlZj0ibWFpbHRvOkJJRVJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5CSUVSQGlldGYub3Jn PC9hPiZndDs8YnI+Jmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNv bS92My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vIiByZWw9Im5vcmVm ZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby88L2E+PGJyPiZndDsgJmd0OyAmZ3Q7IGJp ZXIgPGJyPiZndDsgJmd0OyAmZ3Q7IF9fOyE4V29BNlJqQzgxYyFYdkg0QUF4ZnJEakZvS19zZXJj d1pNc2MwTzVONDJlRU5PczRsX3Fkc1hGMEt3WkQ4Mjxicj4mZ3Q7ICZndDsgJmd0OyBjSkxEPGJy PiZndDsgJmd0OyAmZ3Q7IEZGTlQyV1ZYV1gkPGJyPiZndDsgJmd0OyAmZ3Q7ICZsdDs8YSBocmVm PSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvLyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly91cmxk ZWZlbnNlLmNvbS92My9fX2h0dHBzOi93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby88L2E+ PGJyPiZndDsgJmd0OyAmZ3Q7IGJpZXIgPGJyPiZndDsgJmd0OyAmZ3Q7IF9fOyE4V29BNlJqQzgx YyFVQlRHdldXcE1IeWVpU2FueHM2dkliX0VuQlZneWc2Ym9BQVc0bnJxanU4VUNMT2dpdTxicj4m Z3Q7ICZndDsgJmd0OyBYYzhZPGJyPiZndDsgJmd0OyAmZ3Q7IF82c0tuMktvQVQkJmd0Ozxicj4m Z3Q7ICZndDsgPGJyPiZndDsgJmd0OyAtLTxicj4mZ3Q7ICZndDsgLS0tPGJyPiZndDsgJmd0OyA8 YSBocmVmPSJtYWlsdG86dHRlQGNzLmZhdS5kZSIgdGFyZ2V0PSJfYmxhbmsiPnR0ZUBjcy5mYXUu ZGU8L2E+PGJyPiZndDsgPGJyPiZndDsgLS08YnI+Jmd0OyAtLS08YnI+Jmd0OyA8YSBocmVmPSJt YWlsdG86dHRlQGNzLmZhdS5kZSIgdGFyZ2V0PSJfYmxhbmsiPnR0ZUBjcy5mYXUuZGU8L2E+PGJy PiZndDsgPGJyPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+Jmd0OyBCSUVSIG1haWxpbmcgbGlzdDxicj4mZ3Q7IDxhIGhyZWY9Im1haWx0bzpC SUVSQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+QklFUkBpZXRmLm9yZzwvYT48YnI+Jmd0OyA8 YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9iaWVyIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5o dHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9iaWVyPC9hPjxicj4mZ3Q7IF9fOyEhTkV0NnlNYU8tZ2shVnVRQ1ZIbnFKeV9hWUkt Rk50OUExYTVFekhPQ3IwZlprTFBiZ2czQ1BOdTBQeXJXc3JGeDQ8YnI+Jmd0OyAxX2pXVjNZVUE2 RCQ8YnI+PGJyPi0tPGJyPi0tLTxicj48YSBocmVmPSJtYWlsdG86dHRlQGNzLmZhdS5kZSIgdGFy Z2V0PSJfYmxhbmsiPnR0ZUBjcy5mYXUuZGU8L2E+PGJyPjxicj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj5CSUVSIG1haWxpbmcgbGlzdDxicj48YSBo cmVmPSJtYWlsdG86QklFUkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkJJRVJAaWV0Zi5vcmc8 L2E+PGJyPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmll ciIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9iaWVyPC9hPjxicj48L2Jsb2NrcXVvdGU+PC9kaXY+PC9kaXY+PC9k aXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PHA+PGJyPjwvcD48L2Rpdj4= --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Tue Feb 18 17:12:58 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15307120867 for ; Tue, 18 Feb 2020 17:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable 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 PPVRChIz-N0E for ; Tue, 18 Feb 2020 17:12:50 -0800 (PST) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CB03120869 for ; Tue, 18 Feb 2020 17:12:50 -0800 (PST) Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id 72C0469D495A836F04D0; Wed, 19 Feb 2020 09:12:48 +0800 (CST) Received: from njxapp05.zte.com.cn ([10.41.132.204]) by mse-fl1.zte.com.cn with SMTP id 01J1CAtb044990; Wed, 19 Feb 2020 09:12:10 +0800 (GMT-8) (envelope-from chen.ran@zte.com.cn) Received: from mapi (njxapp03[null]) by mapi (Zmail) with MAPI id mid203; Wed, 19 Feb 2020 09:12:10 +0800 (CST) Date: Wed, 19 Feb 2020 09:12:10 +0800 (CST) X-Zmail-TransId: 2afb5e4c8b6a80fea79d X-Mailer: Zmail v1.0 Message-ID: <202002190912101512108@zte.com.cn> In-Reply-To: References: MN2PR05MB598175BB2DD63200BB91DF2CD4110@MN2PR05MB5981.namprd05.prod.outlook.com, CABFReBpXjpzdLTp9Ygnd9PjSSTKdWO664aVutgV-dgC3EJzZRA@mail.gmail.com Mime-Version: 1.0 From: To: Cc: , , Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-fl1.zte.com.cn 01J1CAtb044990 Archived-At: Subject: Re: [Bier] =?utf-8?q?WGLC_-_draft-ietf-bier-te-arch_1_WEEK?= X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 01:12:57 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 U3VwcG9ydC5SZWdhcmRzDQoNCg0KUmFuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KDQoNCuWOn+Wni+mCruS7tg0KDQoNCg0K5Y+R5Lu25Lq677yaR3JlZ1NoZXBoZXJkIDxnanNo ZXBAZ21haWwuY29tPg0K5pS25Lu25Lq677yaSmVmZnJleSAoWmhhb2h1aSkgWmhhbmcgPHp6aGFu Zz00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPjsNCuaKhOmAgeS6uu+8mmJpZXJAaWV0Zi5v cmcgPGJpZXJAaWV0Zi5vcmc+O1RvZXJsZXNzIEVja2VydCA8dHRlQGNzLmZhdS5kZT47DQrml6Ug 5pyfIO+8mjIwMjDlubQwMuaciDE55pelIDA0OjQ2DQrkuLsg6aKYIO+8mltCaWVyXSBXR0xDIC0g ZHJhZnQtaWV0Zi1iaWVyLXRlLWFyY2ggMSBXRUVLDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCkJJRVIgbWFpbGluZyBsaXN0DQpCSUVSQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JpZXINCg0KDQpUaGFu a3MgVG9lcmxlc3MgYW5kIEplZmZyZXkNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtaWV0Zi1iaWVyLXRlLWFyY2gvDQoNCg0KT25lIG1vcmUgd2VlayBvZiBXR0xDLiBQ bGVhc2UgcmVhZCB0aGUgbGF0ZXN0IHJldiBhbmQgcmVzcG9uZCB0byB0aGlzIHRocmVhZCB3L3dv IHN1cHBvcnQuDQoNCkNoYWlycw0KKFNoZXApDQoNCg0KDQoNCk9uIFR1ZSwgRmViIDE4LCAyMDIw IGF0IDEyOjA3IFBNIEplZmZyZXkgKFpoYW9odWkpIFpoYW5nIDx6emhhbmc9NDBqdW5pcGVyLm5l dEBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQoNCkhpIFRvZXJsZXNzLA0KDQpUaGFua3MhDQpJIHN1 cHBvcnQgbW92aW5nIHRoaXMgdG8gdGhlIG5leHQgc3RhZ2UuDQoNCkplZmZyZXkNCg0KT24gRnJp LCBOb3YgMDEsIDIwMTkgYXQgMDc6NDI6MzhQTSArMDEwMCwgVG9lcmxlc3MgRWNrZXJ0IHdyb3Rl Og0KPiBUaGFua3MgSmVmZg0KPiANCj4gSSBoYXZlIG5vdyBwdXNoZWQgb3V0IC0wNSB3aXRoIHRo ZSBhbnN3ZXJzIGFuZCBob3BlZnVsbHkgcmVzb2x1dGlvbiB0byANCj4geW91ciBwb2ludHMgaW4g ZW1haWwgYmVsb3cuICBCaWdnZXN0IGFkZGl0aW9uIHdhcyBhIHNlY3Rpb24gYWJvdXQgDQo+IHJl dXNlIG9mIEJQcyAod2l0aG91dCBETlIpIHdoaWNoIGNhbWUgb3V0IG9mIHRoZSBjb25mdXNpb24g aSB0aGluayB0aGUgDQo+IHJldXNlIGluIHRoZSBFQ01QIGV4YW1wbGUgcmFpc2VkLiBJIHdhcyBh ZnJhaWQgc28gZmFyIHRvIGV4cGxhbiB0aGF0IA0KPiBhcyBpdCBtYXkgbm90IGJlIGVhc3kgdG8g YWJzb3JiIGFuZCB1bHRpbWF0ZWx5IGlzIHN0dWZmIG9ubHkgDQo+IGNvbnRyb2xsZXIgZGV2ZWxv cGVycyBuZWVkIHRvIHVuZGVyc3RhbmQsIGJ1dCBob3BlZnVsbHkgdXNlZnVsLg0KPiBBbmQgdGhl biBvZiBjb3Vyc2UgdGhlIHN1bW1hcnkgb2YgQlAgb3B0aW1pemF0aW5zIHlvdSBhc2tlZCBmb3IN Cj4gDQo+IERpZmYgZnJvbSBsYXN0IHZlcnNpb24gaSBzZW50IHlvdToNCj4gDQo+IGh0dHBzOi8v dXJsZGVmZW5zZS5jb20vdjMvX19odHRwOi8vdG9vbHMuaWV0Zi5vcmcvKnJmY2RpZmY/dXJsMT1o dHRwczoNCj4gKipBcmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSp0b2VybGVzcypiaWVyLXRlLWFy Y2gqbWFzdGVyKmRyYWZ0LWlldGYtYg0KPiBpZXItdGUtYXJjaC0wNS4xLnR4dCZ1cmwyPWh0dHA6 KipBdG9vbHMuaWV0Zi5vcmcqaWQqZHJhZnQtaWV0Zi1iaWVyLXRlDQo+IC1hcmNoLTA1LnR4dF9f O0x5OHZMeTh2THk4dkx5OCEhTkV0NnlNYU8tZ2shVnVRQ1ZIbnFKeV9hWUktRk50OUExYTVFekgN Cj4gT0NyMGZaa0xQYmdnM0NQTnUwUHlyV3NyRng0MV9qV1gyQXQ4Vi0kDQo+IA0KPiBmdWxsIC0w NCAtPiAwNSBkaWZmOg0KPiANCj4gaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHA6Ly90 b29scy5pZXRmLm9yZy8qcmZjZGlmZj91cmwxPWh0dHA6Kg0KPiAqQXRvb2xzLmlldGYub3JnKmlk KmRyYWZ0LWlldGYtYmllci10ZS1hcmNoLTA0LnR4dCZ1cmwyPWh0dHA6KipBdG9vbHMuDQo+IGll dGYub3JnKmlkKmRyYWZ0LWlldGYtYmllci10ZS1hcmNoLTA1LnR4dF9fO0x5OHZMeTh2THk4diEh TkV0NnlNYU8tZ2sNCj4gIVZ1UUNWSG5xSnlfYVlJLUZOdDlBMWE1RXpIT0NyMGZaa0xQYmdnM0NQ TnUwUHlyV3NyRng0MV9qV2FuY3B6aXYkDQo+IA0KPiBDb21tZW50cyBpbmxpbmUgYmVsb3cuDQo+ IA0KPiBDaGVlcnMNCj4gICAgIHRvZXJsZXNzDQo+IA0KPiBPbiBNb24sIE9jdCAyOCwgMjAxOSBh dCAwNzo1Mjo1OVBNICswMDAwLCBKZWZmcmV5IChaaGFvaHVpKSBaaGFuZyB3cm90ZToNCj4gPiBJ IFRob3VnaHQgdS10dXJuIGlzIHRoZSBtb3N0IHNpbXBsZSBjb21wYXJpc29uIGxlYWYgdnMuIG5v bi1sZWFmIEJGUi4NCj4gPiANCj4gPiBaemg+IFRoZSB0ZXh0IGluIHRoZSBlbWFpbCBpcyBzZXJp b3VzbHkgbWlzYWxpZ25lZC4gTG9va2luZyBhdCB0aGUgcGljdHVyZSBpbiB0aGUgZGlmZiBsaW5r LCB3aGlsZSB5b3UgZ2F2ZSBhIFUtdHVybiBleGFtcGxlLCB0aG91Z2ggZXZlbiBpZiBCRkVSMiBp cyBub3QgY29ubmVjdGVkIHRvIEJGUjIgIGJ1dCBvbmx5IGNvbm5lY3RlZCB0byBCRkVSMSAoaGVu Y2Ugbm8gVS10dXJuKSwgdGhlbiBCRkVSMSBpcyBzdGlsbCBub3QgYSBsZWFmIEJGRVIgSSBzdXBw b3NlLiBUaGF0J3Mgd2h5IEkgc2FpZCB0aGUgZmlyc3Qgc2VudGVuY2Ugb2YgdGhlIGFib3ZlIHBh cmFncmFwaCBpcyBlbm91Z2ggdG8gZGVmaW5lIExlYWYgQkZFUiB3aGlsZSB0aGUgZXhhbXBsZSBp dHNlbGYgaXMgYWN0dWFsbHkgbm90IG5lZWRlZC4NCj4gDQo+IEFyZ2guLi4gb2ssIGhhZCB0byBm aXggdHdvIHdvcmRzLCBCRklSLT5CRkVSIGFuZCBsZWZ0LWhhbmQgLT4gcmlnaHQtaGFuZDoNCj4g DQo+IENvbnNpZGVyIGhvdyByZWR1bmRhbnQgZGlzam9pbnQgdHJhZmZpYyBjYW4gcmVhY2ggQkZF UjEvQkZFUjIgaW4gYWJvdmUgDQo+IHBpY3R1cmU6IFdoZW4gQkZFUjEvQkZFUjIgYXJlIE5vbi1M ZWFmIEJGRVIgYXMgc2hvd24gb24gdGhlIHJpZ2h0IGhhbmQgDQo+IHNpZGUsIG9uZSB0cmFmZmlj IGNvcHkgd291bGQgYmUgZm9yd2FyZGVkIHRvIEJGRVIxIGZyb20gQkZSMSwgYnV0IHRoZSANCj4g b3RoZXIgb25lIGNvdWxkIG9ubHkgcmVhY2ggQkZFUjEgdmlhIEJGRVIyLCB3aGljaCBtYWtlcyBC RkVSMiBhIA0KPiBub24tTGVhZiBCRkVSLiBMaWtld2lzZSBCRkVSMSBpcyBhIG5vbi1MZWFmIEJG RVIgd2hlbiBmb3J3YXJkaW5nIA0KPiB0cmFmZmljIHRvIEJGRVIyDQo+IA0KPiA+IFp6aD4gQWRk aXRpb25hbGx5LCBpbiBsZWZ0IHBhcnQgb2YgdGhlIHBpY3R1cmUgeW91IGFkZGVkLCBpZiBzb21l IGZhaWx1cmUgbGVhZHMgdG8gQkZSMiB0byBiZSBvbmx5IHJlYWNoYWJsZSB2aWEgQkZFUjEsIHRo ZW4gQkZFUjEgaXMgbm8gbG9uZ2VyIGEgbGVhZiBCRkVSLiANCj4gDQo+IEFkZGVkIHNlbnRlbmNl Og0KPiANCj4gPHQ+Tm90ZSB0aGF0IHRoZSBCRkVSIGluIHRoZSBsZWZ0IGhhbmQgcGljdHVyZSBh cmUgb25seSBndWFyYW50ZWVkIHRvIA0KPiBiZSBsZWFmLUJGUiBieSBmaXR0aW5nIHJvdXRpbmcg Y29uZmlndXJhdGlvbiB0aGF0IHByb2hpYml0cyB0cmFuc2l0IA0KPiB0cmFmZmljIHRvIHBhc3Mg dGhyb3VnaCBhIFBFLCB3aGljaCBpcyBjb21tb25seSBhcHBsaWVkIGluIHRoZXNlIA0KPiB0b3Bv bG9naWVzLjwvdD4NCj4gDQo+ID4gSSBhc3N1bWUgeW91IGRvbid0IHJlYXNzaWduIEJQcyB3aGVu IGxpbmtzIGdvIHVwIGFuZCBkb3duLg0KPiANCj4gSSBkaWRuJ3Qgd2FudCB0byBkaXNjdXNzIHRo YXQgb3B0aW9uIGluIHRoaXMgZG9jdW1lbnQuIEl0cyBvYnZpb3VzbHkgDQo+IHBlcmZlY3RseSBm ZWFzaWJsZSwgYnV0IGJlIHlldCBhIGJpZyBhbW91bnQgb2YgdGV4dCAoZXNwZWNpYWxseSB0aGUg DQo+IGNvbnNpZGVyYXRpb25zIGhvdyB0byBkbyB0aGlzIG1ha2UtYmVmb3JlLWJyZWFrLiBGdXR1 cmUgZG9jLg0KPiANCj4gPiA+IGJ1dCBzdWJzZXF1ZW50IHBvbGFyaXphdGlvbiBleGFtcGxlIGNv bmZ1c2VzIG1lLiBJdCBzZWVtcyB0aGF0IEJQIDA6NiBpcyBhc3NpZ25lZCB0byB0aGUgcm91dGVk IGFkamFjZW5jeSBCRlIxMCAod2hpY2ggaXMgYWN0dWFsbHkgdGFsa2VkIGFib3V0IGluIFNlY3Rp b24gNC44KS4NCj4gPiANCj4gPiBTZWN0aW9uIDQuNyBkb2VzIG5vdCBtZW50aW9uICJyb3V0ZWQi IGF0IGFsbCwgc28gdGhlcmUgYXJlIG5vIHJvdXRlZCBhZGphY2VuY2llcyBhdCBhbGwgdXNlZCBp biA0LjcuIFNvIGkgYW0gbm90IHN1cmUgd2hhdCB5b3UgYXJlIGNvbmZ1c2VkIGFib3V0Lg0KPiA+ IA0KPiA+IFp6aD4gIlRoZSBCSUZUIG9mIGVhY2ggQkZSIGFyZSBvbmx5IHBvcHVsYXRlZCB3aXRo IEJQcyB0aGF0IGFyZSBhZGphY2VudCB0byB0aGUgQkZSIGluIHRoZSBCSUVSLVRFIHRvcG9sb2d5 Ii4NCj4gDQo+IENvcnJlY3QgdGV4dCBmcm9tIHRoZSBpbnRyb2R1Y3Rpb24uIE9rLg0KPiANCj4g PiBaemg+IFNpbmNlIHRoZSBzYW1lIDA6NiBpcyBpbiBCSUZUUyBvZiBCRlIxL0JGUjIvQkZSMyAo YW5kIEkgc3VwcG9zZSBpbiBCRlI0fkJGUjkgYXMgd2VsbCBldmVuIHRob3VnaCBub3QgZHJhd24p LCBJIGFzc3VtZWQgaXQncyBmb3IgdGhlICJNUDJQIiByb3V0ZWQgYWRqYWNlbmN5IHRvIFIxMDsg dGhvdWdoIEkgdGhlbiBydWxlZCB0aGF0IG91dCAtIGJ1dCBJIGRvbid0IGtub3cgd2hhdCAwOjYg cmVwcmVzZW50IG5vdyBvbiBCRlIxLCBCRlIyLCBhbmQgQkZSMy4NCj4gDQo+IEFoLiBPay4gSSB0 aG91Z2h0IGkgY291bGQgc3RyaXAgZG93biB0aGUgZXhhbXBsZSB0byBzaG93IG9ubHkgdGhlIA0K PiBhZGphY2VuY2llcyByZWxldmFudCB0byB0aGUgZm9sbG93aW5nIGRpc2N1c2lvbiwgYnV0IHNl ZW1pbmdseSB0aGlzIA0KPiBjYW4gaW50cm9kdWNlIHRoZSBjb25mdXNpb24geW91IGhhdmUuDQo+ IA0KPiBTbyBpIGNvbXBsZXRlZCB0aGUgZXhhbXBsZSB3aXRoIHRoZSBCUCBhc3NpZ25tZW50IGFj b3NzIGFsbCBub2RlcywgYnV0IA0KPiBhZGRlZCB0ZXh0IHBvaW50aW5nIHRvIGEgbmV3IHNlY3Rp b24gZnVydGhlciBkb3duIHRvIGRpc2N1c3MgdGhlIA0KPiByZS11c2Ugb2YgQlAgZm9yIHdoaWNo IHRoaSBwaWN0dXJlIGlzIGFsc28gYW4gZXhhbXBsZS4NCj4gDQo+IChjaGVjayBvdXQgdGhlIGRp ZmYsIG5ldyByZXVzZSB0ZXh0IHRvIGxvbmcgdG8gY29weSBpbmxpbmUpLg0KPiANCj4gPiBUaGUg d2hvbGUgcHVycG9zZSBvZiB0aGUgRUNNUCBCUHMgaXMgb2YgY291cnNlIHRvIHNhdmUgYml0cywg b3RoZXJ3aXNlIHdlJ2QgZ2l2ZSBlYWNoIGxpbmsgYSBzZXBhcmF0ZSBCUCwgd2hpY2ggd291bGQg YmUgNiBCUCB0byByZWFjaCB0byBCRlI0Li4uQkZSNyBmcm9tIEJGUjEuIA0KPiA+IA0KPiA+IFp6 aD4gVGhlIHRyb3VibGUgSSBhbSBoYXZpbmcgaXMgdGhhdCB0aGUgc2FtZSAwOjYgaXMgYXNzaWdu ZWQgdG8gZGlmZmVyZW50IHRoaW5ncyBhbmQgaXQncyBwcmVzZW50IG9uIGFsbCBCRlIxL0JGUjIv QkZSMy4gSXQgaXMgcGVyaGFwcyBhbiBpbnRlbnRpb25hbCBzbWFydCBkZXNpZ24gYnV0IEkgaGF2 ZSBub3Qgd3JhcHBlZCBteSBtaW5kIGFyb3VuZCBpdC4gSXQncyBhcHBhcmVudGx5IGRpZmZlcmVu dCBmcm9tIHRoZSBsaW5rIGJ1bmRsZSBjYXNlLCBzbyBiZXR0ZXIgc2VwYXJhdGUgaXQgb3V0IGFu ZCBlbGFib3JhdGUgaXQgKGluY2x1ZGluZyB0aGUgRE5SIGZsYWcgdGhhdCBtaWdodCBiZSBuZWVk ZWQgaGVyZSAtIElmIHRoZSBwYWNrZXQgYXJyaXZlcyBvbiBCRlIxIHdpdGggMDo2LCB3b3VsZCB0 aGUgQlAgcmVzZXQgd2hlbiBpdCBpcyBzZW50IHRvIEJGUjIvMyk/DQo+IA0KPiBZZXMsIHRoZXJl IHdhcyB0aGUgYnVnIG9mIHJldXNpbmcgQlAgMDo2IGFjcm9zcyBzZXF1ZW50aWFsIEJGUiBhbG9u ZyANCj4gdGhlIHBhdGgsIGJ1dCBub3cgdGhlIGV4YW1wbGUgY29ycmVjdGx5IHJldXNlcyBzZXBh cmF0ZSBCUCBhdCANCj4gZGlmZmVyZW50IHN0YWdlcyBvZiB0aGUgcGF0aHMgKEJQIDA6NiBvbiBC RlIxLCBCUCAwOjcgb24gQkZSMi9CRlIzKSBhbmQgc28gb24uDQo+IA0KPiBUaGFua3MhDQo+IA0K PiA+ID4gNC44LiAgUm91dGVkIGFkamFjZW5jaWVzDQo+ID4gPiANCj4gPiA+IElmIEkgdW5kZXJz dGFuZCBpdCBjb3JyZWN0bHksIHRoZXJlIGlzIGEgQlAgYXNzaWduZWQgdG8gTDEvTDIvTDMgDQo+ ID4gPiByZXNwZWN0aXZlbHkgKHAycCBsaW5rKSwgYW5kIHRoZW4gdGhlcmUgYXJlIEJQcyBhc3Np Z25lZCB0byBNUDJQIHR1bm5lbHMgKHJvdXRlZCBhZGphY2VuY3kgZnJvbSBldmVyeSBCRlIpIHRv IHRoZSBMMS9MMi9MMyBpbnRlcmZhY2UgYWRkcmVzc2VzIGFuZCBsb29wYmFjayBhZGRyZXNzZXMg b24gQkZSMi8zLg0KPiA+IA0KPiA+IE9rIHRoYXQgd2Fzbid0IHF1aXRlIHRoZSByZWFkIGkgZXhw ZWN0ZWQuIExldCBtZSBjbGFyaWZ5IHRoZSB0ZXh0L3BpY3R1cmU6DQo+ID4gDQo+ID4gICAgICAg ICAgICAgICAgICAgIC4uLi4uLi4uLi4uLi4uLiAgICAgDQo+ID4gICAgICAgICAgLi4uQkZSMS0t Li4uICAgICAgICAgICAuLi4tLUwxLS0gQkZSMi4uLg0KPiA+ICAgICAgICAgICAgICAgICAgIC4u LiAuUm91dGVycy4gLi4uLS1MMi0tLyAgDQo+ID4gICAgICAgICAgLi4uQkZSNC0tLi4uICAgICAg ICAgICAuLi4tLS0tLS0gQkZSMy4uLg0KPiA+ICAgICAgICAgICAgICAgICAgICAuLi4uLi4uLi4u Li4uLi4gICAgICAgICB8DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgTE8NCj4gPiAgICAgICAgICAgICAgICAgICAgIE5ldHdvcmsgQXJlYSAxDQo+ID4gDQo+ ID4gQXNzdW1lIHRoZSByZXF1aXJlbWVudCBpbiB0aGUgYWJvdmUgcGljdHVyZSBpcyB0byBleHBs aWNpdGx5IHN0ZWVyIHRyYWZmaWMgZmxvd3MgdGhhdCBoYXZlIGFycml2ZWQgYXQgQkZSMSBvciBC RlI0IHZpYSBhIHNob3J0ZXN0IHBhdGggaW4gdGhlIHJvdXRpbmcgdW5kZXJsYXkgIm5ldHdvcmsg YXJlYSAxIiB0byBvbmUgb2YgdGhlIGZvbGxvd2luZyB0aHJlZSBuZXh0IHNlZ21lbnRzOiAoMSkg QkZSMiB2aWEgbGluayBMMSwgKDIpIEJGUjIgdmlhIGxpbmsgTDIsICgzKSB2aWEgQkZSMy4NCj4g PiANCj4gPiBUbyBhY2hpZXZlIHRoaXMsIGJvdGggQkZSMSBhbmQgQkZSNCBhcmUgc2V0IHVwIHdp dGggYSBmb3J3YXJkX3JvdXRlZCBhZGphY2VuY3kgQml0UG9zaXRpb24gdG93YXJkcyBhbiBhZGRy ZXNzIG9mIEJGUjIgb24gbGluayBMMSwgYW5vdGhlciBmb3J3YXJkX3JvdXRlZCBCaXRQb3NpdGlv biB0b3dhcmRzIGFuIGFkZHJlc3Mgb2YgQkZSMiBvbiBsaW5rIEwyIGFuZCBhIHRoaXJkIGZvcndh cmRfcm91dGVkIEJpdHBvc2l0aW9uIHRvd2FyZHMgYSBub2RlIGFkZHJlc3MgTE8gb2YgQkZSMy4N Cj4gPiANCj4gPiBEb2VzIHRoaXMgY2xlYXIgaXAgdGhlIGNvbmZ1c2lvbiA/DQo+ID4gDQo+ID4g WnpoPiBUaGUgcGljdHVyZSBpcyBiYWRseSBtaXNhbGlnbmVkLiBJJ2xsIHdhaXQgdGlsbCA0Ljcg cXVlc3Rpb25zIGFyZSBjbGVhcmVkLg0KPiANCj4gT2suDQo+IA0KPiA+ID4gSWYgQkZSMi8zIGFy ZSBhbHNvIEJGRVJzLCB0aGVuIHRoZXkgYWRkaXRpb25hbGx5IHdpbGwgaGF2ZSBCRkVSIEJQcy4N Cj4gPiA+IE9uIEJGUjEvNCwgdGhlIEJJRlQgZW50cmllcyBmb3IgdGhlIE1QMlAgQlBzIGZvciB0 aGUgTDEvTDIvTDMvbG9vcGJhY2sgaW50ZXJmYWNlIGFkZHJlc3NlcyBvZiBCRlIyLzMgd2lsbCB1 c2UgZm9yd2FyZF9yb3V0ZWQoaW50ZXJmYWNlL2xvb3BiYWNrIGFkZHJlc3MpLiBGb3IgYSBwYWNr ZXQgdG8gYmUgZGVjYXBzdWxhdGVkIG9uIGEgQkZFUiwgdGhlcmUgaXMgYSBuZWVkIGZvciBib3Ro IHRoZSBCRkVSIEJQIGFuZCBhbm90aGVyIEJQIChwMnAvbGFuL2h1Yi1zcG9rZS9yb3V0ZWQtYWRq YWNlbmN5KSBpbiB0aGUgcGFja2V0ICh0aGUgZm9ybWVyIGlzIGZvciBkZWNhcHN1bGF0aW9uIGFu ZCB0aGUgbGF0dGVyIGlzIGZvciBnZXR0aW5nIGl0IHRoZXJlKS4NCj4gPiANCj4gPiBUaGlzIGlz IG5vdCBkaXNjdXNzZWQgaW4gdGhpcyBzZWN0aW9uLCBidXQgeW91IGFyZSByaWdodCAtIHVubGVz cw0KPiA+IEJGUjIgb3IgQkZSMyBpcyBhIGxlYWYgQkZSLiBJbiB0aGF0IGNhc2UsIGl0IHdvdWxk IGp1c3QgbGV2ZXJhZ2UgdGhlIG9uZSBzaGFyZWQgImxlYWYtQkZSIiBCUCwgc28gdGhleSBkbyBu b3QgbmVlZCBhIHBlci1CRkVSIEJQIGZvciBsb2NhbF9kZWNhcCgpLiANCj4gPiANCj4gPiBaemg+ IFJpZ2h0IC0gc2hhcmVkIGxlYWYtQkZSIEJQIGJ1dCBzdGlsbCBuZWVkIHRoYXQgQlAgKHRoZSBr ZXkgaXMgdGhhdCB3ZSBuZWVkIGEgQlAgdG8gZ2V0IHBhY2tldCB0byBhIEJGRVIgYW5kIHRoZW4g YSBCUCBmb3IgZGVjYXBzdWxhdGlvbikuDQo+IA0KPiBZb3UgZ290IGl0Lg0KPiANCj4gPiA+IElm IHRoYXQ/Pz9zIHRoZSBjYXNlLCBpdD8/P3Mgd29ydGggcG9pbnQgdGhlIGFib3ZlIG91dC4NCj4g PiANCj4gPiBIbW0uLi4gVGhlIGxvZ2ljIG9mIEJGRVIgQlBzIGlzIHRvdGFsbHkgaW5kZXBlbmRl bnQgb2YgdGhlIGxvZ2ljIG9mIGZvcndhcmRfcm91dGVkIGFkamFjZW5jeSwgc28gaSB3b3VsZCB3 b3JyeSB0aGF0IHJlcGVhdGluZyB0aGUgZXhwbGFuYXRpb24gb2YgQkZFUiBCUHMgd291bGQgY29u ZmxhdGUgdGhlIGZvcndhcmRfcm91dGVkIGV4cGxhbmF0aW9uLg0KPiA+IA0KPiA+IFp6aD4gSXQn cyBqdXN0IHRoYXQgdGhpcyBpcyBhIHBsYWNlIHdoZXJlIGFsbCBraW5kcyBvZiBCUHMgYXJlIHVz ZWQgc28gaXQncyBnb29kIHRvIGhhdmUgYSBzdW1tYXJ5IChjb3VsZCBiZSBhIHN1YnNlY3Rpb24g NC45KS4NCj4gDQo+IFllcywgYWRkZWQgc3VjaCBhIHN1bW1hcnkuIFBscy4gY2hlY2suDQo+IA0K PiA+ID4gQWN0dWFsbHksIHRoZSByZWFzb24gdGhhdCBJIHRob3VnaHQgdGhpcyBpcyBNUDJQIGlz IHRoYXQgMDo2IGlzIHByZXNlbnQgb24gUjEsIFIyLCBhbmQgUjMgKGFuZCBtb3JlIEkgYXNzdW1l KSBpbiBGaWd1cmUgMTIsIGJ1dCBub3cgSSB0aGluayBpdCBjYW4/Pz90IGJlIE1QMlAgKHNvIGl0 IGlzIG5vdCBjb3JyZWN0IHRvIGhhdmUgMDo2IHByZXNlbnQgb24gdGhvc2Ugcm91dGVycyA/Pz8g b25seSB0aGUgcDJwIHR1bm5lbCBoZWFkL3RhaWwgc2hvdWxkIGhhdmUgdGhlIEJQIHByZXNlbnQg aW4gdGhlIEJJRlQpLiBUaGUgcmVhc29uIGlzIHRoYXQgaWYgaXQgd2VyZSBNUDJQLCBhbnkgcm91 dGVyIGdldHRpbmcgYSBjb3B5IHdpbGwgc2VuZCBpdCB0byB0aGUgZW5kcG9pbnQgb2YgdGhlIHJv dXRlZCBhZGphY2VuY3ksIGNhdXNpbmcgbG90cyBvZiBkdXBsaWNhdGVzLi4uDQo+ID4gPiANCj4g PiA+IEFtIEkgZ2V0dGluZyB0aGlzIGNvcnJlY3Q/DQo+ID4gDQo+ID4gSSB0aGluayB5b3UgYXJl IHN0aWxsIGV4cGxhaW5pbmcgZnJvbSB0aGUgbWlzdW5kZXJzdHNhbmRpbmcgdGhhdCB0aGUgRUNN UCBleHBsYW5hdGlvbnMgd2hlcmUgYWJvdXQgcm91dGVkIGFkamFjZW5jaWVzLg0KPiA+IA0KPiA+ IEkgaGF2ZSBub3cgZXhwYW5kZWQgdGhlIHNvbWV3aGF0IHRlcnNlIHRleHQgaW4gdGhlIEJJRlQg dGFibGUgcGljdHVyZXMsIHRvIG1ha2UgaXQgY2xlYXIgdGhhdCB0aGUgRUNNUCBpcyBhY3Jvc3Mg bXVsdGlwZSBmb3J3YXJkX2Nvbm5lY3RlZCBhZGphY2VuY2llcyBpbiB0aGUgZXhhbXBsZXMuIEZv ciBleGFtcGxlLCBmaXJzdCBCSUZUIHBpY3R1cmU6DQo+ID4gDQo+ID4gICBCSUZUIGVudHJ5IGlu IEJGUjE6DQo+ID4gICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiAgIHwgSW5kZXggfCAgQWRqYWNlbmNpZXMgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiA+ICAgPT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 DQo+ID4gICB8IDA6NiAgIHwgIEVDTVAoe2ZvcndhcmRfY29ubmVjdGVkKEwxLCBCRlIyKSwgICAg ICAgICAgICAgICAgICAgIHwNCj4gPiAgIHwgICAgICAgfCAgICAgICAgZm9yd2FyZF9jb25uZWN0 ZWQoTDIsIEJGUjIpLCAgICAgICAgICAgICAgICAgICAgfA0KPiA+ICAgfCAgICAgICB8ICAgICAg ICBmb3J3YXJkX2Nvbm5lY3RlZChMMywgQkZSMil9LCBzZWVkKSAgICAgICAgICAgICB8DQo+ID4g ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gPiANCj4gPiBPZiBjb3Vyc2UsIGFuIEVDTVAgYWRqYWNlbmN5IGNhbiBi ZSBhY3Jvc3MgYW55IHR5cGUgb2YgYWRqYWNlbmNpZXMsIGJ1dCBhbGwgdGhlIHRleHQvZXhwbGFu YXRpb25zIHVzZWQgZm9yd2FyZF9jb25uZWN0ZWQsIGFuZCBub3cgdGhlIHBpY3R1cmVzIHNob3cg dGhhdCBleHBsaWNpdGx5Lg0KPiA+IA0KPiA+IFp6aD4gSSBjYW4gdW5kZXJzdGFuZCB0aGUgbXVs dGktbGluayBjYXNlLCBidXQgdGhlIG11bHRpLWhvcCBFQ01QIGNhc2UgKGZyb20gQkZSMSB0b3dh cmRzIEJGUjEwKSBpcyBjb25mdXNpbmcgbWUuIEl0IHdvdWxkIGhlbHAgdG8gZ2l2ZSBhbiBleGFt cGxlIGhvdyBpdCBjYW4gYmUgdXNlZCwgV0lUSE9VVCB3b3JyeWluZyBhYm91dCBwb2xhcml6YXRp b24uDQo+IA0KPiBQbGVhc2UgY2hlY2sgLTA1IHRleHQgdGhhdCBoYXMgdGhlIGZ1bGwgc2V0IG9m IEJJRlQgbGlzdGVkIG5vdzoNCj4gDQo+IFRoZXJlIGlzICByZWFsbHkgbm90aGluZyBub3RoaW5n IHVuaXF1ZSBpbiBtdWx0aS1ob3AgRUNNUCBmb3IgQklFUi1URSANCj4gdGhhdCB3ZSBkbyBub3Qg YWxzbyBoYXZlIGluIGFueSBvdGhlciBFQ01QLCBleGNlcHQgdGhlIGNvbmNsdXNpb24gdGhhdCAN Cj4gd2Ugd2FudCB0byBzdXBwb3J0IGZhc3QgSFcgaGFzaCBtZWNoYW5pc21zIEFORCBhbGxvdyB0 aGUgY29udHJvbGxlciB0byANCj4gc2V0IHVwIG5vbi1wb2xhcml6ZWQgbXVsdGktaG9wIEVDTVAg QU5EIGJlIGFibGUgdG8gcHJlY2FsY3VsYXRlIHBhdGhzLiANCj4gSGVuY2UgdGhlIHNwZWNpZmlj YXRpb24gb2YgRUNNUCBhZGphY2VuY2llcyB0byBoYXZlIGEgY29udHJvbGxlciANCj4gY29uZmln dXJhYmxlIHNlZWQuDQo+IA0KPiBCdHc6IFRoZSBwaWN0dXJlIGlzIG1heWJlIHVubmVjZXNzYXJp bHkgbGFyZ2UgYmVjYXVzZSBpJ3ZlIHVzZWQgaXQgZm9yIA0KPiAyMCB5ZWFycyB0byBleHBsYWlu IHRoZSBzYW1lIHBvbGFyaXphdGlvbiBpc3N1ZSBmb3IgdW5pY2FzdCB2cyANCj4gbXVsdGljYXN0 LCBhbmQgZm9yIG11bHRpY2FzdCBvbmx5IEJGUjEwLi4uQkZSNCBhcmUgcmVsZXZhbnQgKEVDTVAg b2YgDQo+IHRoZSBQSU0vbUxEUCBqb2lucyksIHdoZXJlYXMgZm9yIHVuaWNhc3QvQklFUiBvbmx5 DQo+IEJGUjEuLi5CRlI3IGFyZSByZWxldmFudC4gQnV0IGJlaW5nIHN5bW1ldHJpYywgdGhlIHBp Y3R1cmUgbWFrZXMgaXQgDQo+IGNsZWFyIGl0cyB0aGUgc2FtZSBwcm9ibGVtLg0KPiANCj4gPiA+ ICAgIFRvIGluaGliaXQgbG9vcGluZyBpbiB0aGUgZmFjZSBvZiBzdWNoIHBoeXNpY2FsIG1pc2Nv bmZpZ3VyYXRpb24sDQo+ID4gPiAgICBvbmx5IGZvcndhcmRfY29ubmVjdGVkIGFkamFjZW5jaWVz IGFyZSBwZXJtaXR0ZWQgdG8gaGF2ZSBETlIgc2V0LCBhbmQNCj4gPiA+ICAgIHRoZSBsaW5rIGxh eWVyIGRlc3RpbmF0aW9uIGFkZHJlc3Mgb2YgdGhlIGFkamFjZW5jeSAoZS5nLiAgTUFDDQo+ID4g PiAgICBhZGRyZXNzKSBwcm90ZWN0cyBhZ2FpbnN0IGNsb3NpbmcgdGhlIGxvb3AuICBMaW5rIGxh eWVycyB3aXRob3V0IHBvcnQNCj4gPiA+ICAgIHVuaXF1ZSBsaW5rIGxheWVyIGFkZHJlc3NlcyBz aG91bGQgbm90IGJlIHVzZWQgd2l0aCB0aGUgRE5SIGZsYWcgc2V0Lg0KPiA+ID4NCj4gPiA+IEl0 Pz8/cyBub3QgY2xlYXIgaG93IGxpbmsgbGF5ZXIgYWRkcmVzcyBoZWxwcz8NCj4gPiANCj4gPiBJ IGhhdmUgZXhwYW5kZWQgdGhpcyB0bw0KPiA+ICJsaW5rIGxheWVyIHBvcnQgdW5pcXVlIHVuaWNh c3QgZGVzdGluYXRpb24gYWRkcmVzcyINCj4gPiANCj4gPiBBa2E6IE1QTFMgb3IgZXRoZXJuZXQg aGF2ZSB1bmlxdWUgbGluayBsYXllciBkZXN0aW5hdGlvbiBkZXN0aW5hdGlvbiBhZGRyZXNzZXMg KGxhYmVsIG9yIGRlc3RpbmF0aW9uIE1BQykuIElmIHlvdSB0aGluayBhYm91dCBpbmNvcnJlY3Rs eSBwbHVnZ2VkIEhETEMgbGlua3MgKHN1Y2ggYXMgb2xkIFQxL1QzLy4uLiBsaW5rcyksIHRoZXkg b25seSBoYXZlIDIgZ2VuZXJpYyBhZGRyZXNzZXMsIGlmIGkgcmVtZW1iZXIgMSBvciAzIGluIHRo ZSBIRExDIGZyYW1lLiBTbyB3aGVuIHlvdSBtaXNwbHVnIG9uZSBvZiB0aG9zZSBwMnAgY2FibGVz IHdyb25nLCB0aGUgcGFja2V0cyB3b3VsZCBiZSBpbmNycmVjdGx5IHJlY2VpdmVkIGJ5IHRoZSB3 cm9uZyByZWNlaXZlciBub2RlIGFuZCB0aGVuIEROUiBjb3VsZCBjYXVzZSBwZXJzaXN0ZW50IGxv b3BzIG9ubHkgc29sdmVkIGJ5IFRUTC4NCj4gPiANCj4gPiBaemg+ICJDb25zaWRlciBpbiB0aGUg cmluZyBwaWN0dXJlIHRoYXQgbGluayBMNCBmcm9tIEJGUjMgaXMgcGx1Z2dlZCBpbnRvIHRoZSBM MSBpbnRlcmZhY2Ugb2YgQkZSYSIgLSBzdGlsbCBub3Qgc3VyZSBob3cgbGFiZWwvbWFjIGhlbHBz IGhlcmUuIEkgc3VwcG9zZSB0aGUgcmluZyB0b3BvbG9neSBpcyBkaXNjb3ZlcmVkL3ZlcmlmaWVk IGJ5IHRoZSBjb250cm9sIHBsYW5lIGFuZCB3aGVuIHRoZSBtaXNjYWxsaW5nIGhhcHBlbnMgdGhl biB0aGUgcmluZyB3aWxsIG5vdCBpbmNsdWRlIHRoZSBCRlIxL0JGUjIgcGFydCBhbmQgQkZSMyB3 aWxsIG5vdCBoYXZlIHRoZSBETlIgc2V0PyBJZiByaW5nIGRpc2NvdmVyeS92YXJpY2F0aW9uIGlz IG5vdCBkb25lIHRoZW4gcGVyaGFwcyB3ZSBzaG91bGQgcG9pbnQgb3V0IHRoYXQgUlBGIGJhc2Vk IG9uIGxpbmsgbGF5ZXIgYWRkcmVzcyBpcyBuZWVkZWQgLSB0aGUga2V5IGlzIFJQRiAod2hpY2gg bmVlZHMgdW5pcXVlIGxpbmsgbGF5ZXIgYWRkcmVzcyk/DQo+IA0KPiBGb3JnZXQgUlBGLiBCSUVS KC1URSkgaGFzIG5vIFJQRiAoaXNzdWVzKS4gSXRzIGp1c3QgbGlrZSB1bmljYXN0LiBSUEYgDQo+ IGlzIGp1c3QgYSBwcm9ibGVtIGZvciByZWNlaXZlciBvcmlnaW5hdGVkIGpvaW5zIGxpa2UgaW4g UElNL21MRFAsIGJ1dCANCj4gbm90IHVuaWNhc3QvYmllcigtdGUpL1JTVlAtVEUuDQo+IA0KPiBG b3J3YXJkX2Nvbm5lY3RlZCBpcyBqdXN0IGxpa2UgYSB1bmljYXN0IHN1Ym5ldCBhZGphY2VuY3kg dG8gYSBkaXJlY3QgDQo+IG5laWdoYm9yOiBJbnRlcmZhY2UgYW5kIEwyIGFkZHJlc3NzIG9mIHRo ZSBkZXN0aW5hdGlvbi4NCj4gDQo+IFRoZSBjb250cm9sbGVyIChjb3VsZCBiZSBhIGh1bWFuKSAi YXNzdW1lcyIgYSBwYXJ0aWN1bGFyIHBoeXNpY2lhbCANCj4gdG9wb2xvZ3ksIGZyb20gdGVsZW1l dHJ5L2tub3dsZWRnZS93aGF0ZXZlci4gSXQgdGhlbiBjYWxjdWxhdGVzIHRoZSANCj4gZGVzaXJl ZCBCSUVSLVRFIHRvcG9sb2d5IGFuZCBwdXNoZXMgaXQgZG93bi4gVGhpcyB0b3BvbG9neSBpcyBt ZWFudCB0byANCj4gYmUgbG9vcCBmcmVlIG9mIGNvdXJzZSB3cnQgdG8gdGhlIGNvbmZpZ3VyZWQg YWRqYWNlbmNpZXMuDQo+IEluIHRoaXMgQklFUi1URSB0b3BvbG9neSwgQkZSMyB3aWxsIGhhdmUg YSBCUCB3aXRoIHRoZSANCj4gZm9yd2FyZF9jb25uZWN0ZWQoTDQsIE1BQy1vZi1CRlIyKSBhZGph Y2VuY3kuDQo+IA0KPiBJZiB0aGUgY2FibGUgY29ubmVjdGluZyB0byBMNCBpcyBtaXN3aXJlZCwg dGhlbiBCRlIzIHdvdWxkIHN0aWxsIHNlbmQgDQo+IHRoZSBwYWNrZXRzIHRvIHRoZSBNQUMgYWRk cmVzcyBvZiBCRlIyLCBidXQgZ2l2ZW4gaG93IHRoZSBjYWJsZSANCj4gY29ubmVjdHMgdG8gc29t ZSBvdGhlciBub2RlLCB0aGVzZSBwYWNrZXRzIHdpbGwgYmUgZGlzY2FyZGVkIGJ5IHRoYXQgDQo+ IG5vZGUuIGJlY2F1c2UgdGhleSdyZSBqdXN0IEwyIHVuaWNhc3QgcGFja2V0cy4NCj4gDQo+IEkg dGhpbmsgdGhpcyBpcyBlcXVhbGx5IHRydWUgd2hlbiB3ZSBoYXZlIG5vcm1hbCBCSUVSL01QTFMg ZW5hY3AuDQo+IFRob3NlIHBhY2tldHMgdG9vIGFyZSBhZGRyZXNzZWQgdG8gdGhlIHVuaWNhc3Qg TUFDIGFkZHJlc3Mgb2YgdGhlIA0KPiBuZWlnaGJvci4NCj4gDQo+IE5vdywgaWYvd2hlbiBoZSBj b250cm9sbGVyIHJlY29nbml6ZXMgdGhhdCB0aGUgcGh5c2ljYWwgdG9wb2xvZ3kgaGFzIA0KPiBj aGFuZ2VkLCB0aGF0cyBhIGNvbXBsZXRlbHkgZGlmZmVyZW50IHN0b3J5IGFuZCBub3QgYWRkcmVz c2VkIGhlcmUuIA0KPiBHaXZlbiBob3cgd2UgYXNzdW1lZCB0aGlzIHdhcyBhIGNhYmxpbmcgbWlz dGFrZSwgdGhlIGNvbnRyb2xsZXIgd291bGQgDQo+IHByb2JhYmx5IG9ubHkgY29tcGxhaW4gYWJv dXQgdGhlIG1pc3dpcmluZyB0byBvcGVyYXRpb25zIGJ1dCBiZSBoYXBweSANCj4gdGhhdCB0aGUg Zm9yd2FyZGluZyBwbGFuZSBqdXN0IG1ha2VzIHBhY2tldHMgZmFpbCBpbnN0ZWFkIG9mIGxvb3Au IElmIA0KPiB0aGlzIHdhcyBhIHBsYW5uZWQgY2hhbmdlIHByb2Nlc3MsIHRoZW4gaXQgd2lsbCBi ZSBzaW1pbGFyaWx5IA0KPiBjb252b2x1dGVkIGFzIGl0IHdvdWxkIHRvZGF5IGJlIHdpdGggcmV3 aXJpbmcgY2FibGVzIGluIGFuIA0KPiBTUi1NUExTL1NSdjYgdG9wb2xvZ3kgYW5kIHVwZGF0aW5n IFNJRHMuDQo+IA0KPiA+ID4gQmVjYXVzZSB0aGUgZm9yd2FyZGluZyBpcyBkaWZmZXJlbnQgZnJv bSBCSUVSIGZvcndhcmRpbmcgKGJlY2F1c2Ugb2YgWzFdIGFib3ZlKSwgd2UgbWlnaHQgYXMgd2Vs bCBpbnRyb2R1Y2UgYW4gb3B0aW1pemF0aW9uIGhlcmUgPz8/IGZvciBlYWNoIEJJRlQsIGNhbGN1 bGF0ZSB0aGUgRi1CTSBvZiB0aGUgQklGVCBpdHNlbGYgKHRoZSBsb2dpY2FsID8/P29yPz8/IG9m IGFsbCB0aGUgQlBzIHByZXNlbnRlZCBpbiB0aGlzIEJJRlQpIGFuZCB0aGVuIHVzZSAocGFja2V0 LT5iaXRzdHJpbmcgJiBCSUZULkYtQk0pIGFzIHRoZSBpbnB1dCB0byBHZXRGaXJzdC9OZXh0Qml0 UG9zaXRpb24oKS4gVGhhdCBzaG91bGQgc2tpcCBtYW55IGJpdHMuDQo+ID4gDQo+ID4gUmlnaHQu IEJ1dCBpIGV4cGxpY2l0bHkgcmVtb3ZlZCB0aG9zZSBvcHRpbWl6YXRpb25zIChpIGhhZCB0aGVt IGluIG9sZGVyIGRyYWZ0IHZlcnNpb25zKSBiZWNhdXNlIHRoZSB3aG9sZSBpZGVhIG9mIHRoaXMg cGljdHVyZSBpcyBzb2xlbHkgdGhlIGNvbXBhcmlzb24gd2l0aCBmaWd1cmUgNCBvZiBSRkM4Mjc5 Lg0KPiA+IA0KPiA+IFp6aD4gSSB0aGluayBpdCdzIHdvcnRoIHBvaW50IHRoYXQgb3B0aW1pemF0 aW9uIG91dDsgeW91IGNhbiBtYXJrIGl0IG9wdGlvbmFsIGlmIHlvdSB3YW50IHRvIGVtcGhhc2l6 ZSB0aGUgc2ltaWxhcml0eSB0byBCSUVSIGZvcndhcmRpbmcsIGJ1dCBzaW5jZSBCSUVSIGZvcndh cmRpbmcgZG9lcyBkbyB0aGUgbWFza29mZiBzdGVwLCBpdCBpcyB2ZXJ5IGVmZmljaWVudCB3aGls ZSBCSUVSLVRFIGZvcndhcmRpbmcgZG9lcyBub3QgaXQgdGhlIG1hc2tvZmYgc3RlcCBzbyB0aGlz IG9wdGltaXphdGlvbiBpcyBpbXBvcnRhbnQuDQo+IA0KPiBPay4gSSBzaW1wbGlmaWVkIHRoZSB0 ZXh0IGNvbXBhcmlzb24gQklFUi9CSUVSLVRFIHdydC4gdG8gdGhlIEZCTSANCj4gcnVsZXMgWzFd IGFuZCBbMl0gYW5kIGFkZGVkIGZvbGxvd2luZyBwYXJhZ3JhcGg6DQo+IA0KPiA8dD5JbiBCSUVS LCB0aGUgb3JkZXIgb2YgQlBzIGltcGFjdHMgdGhlIHJlc3VsdCBvZiBmb3J3YXJkaW5nIGJlY2F1 c2Ugb2YgWzFdLiANCj4gSW4gQklFUi1URSwgZm9yd2FyZGluZyBpcyBub3QgaW1wYWN0ZWQgYnkg dGhlIG9yZGVyIG9mIEJQcy4gSXQgaXMgDQo+IHRoZXJlZm9yZSBwb3NzaWJsZSB0byBmdXJ0aGVy IG9wdGltaXplIGZvcndhcmRpbmcgdGhhbiBpbiBCSUVSLiBGb3IgDQo+IGV4YW1wbGUgcGFyYWxs ZWxpemluZyBmb3J3YXJkaW5nIGFjcm9zcyBtdWx0aXBsZSBGUEUgY29yZXMgb3IgDQo+IGRpc3Ry aWJ1dGVkIGxpbmVjYXJkcyBkb2VzIG9ubHkgbmVlZCB0byBleGFtaW5lIGFuIGFyYml0cmFyeSBz dWJzZXQgb2YgDQo+IEJQIGFuZCBub3QgZXZhbHVhdGUgdGhlIGRlcGVuZGVuY3kgYmV0d2VlbiBC UHMuPC90Pg0KPiANCj4gPiA+ICAgIFRoZSBmb2xsb3dpbmcgcHNldWRvY29kZSBpcyBjb21wcmVo ZW5zaXZlOg0KPiA+ID4gDQo+ID4gPiBUaGUgYWJvdmUgc2VudGVuY2UgcmVhZHMgYSBiaXQgc3Ry YW5nZSAob3IgbGFja3Mgc29tZSBzZWd1ZSkuLi4NCj4gPiANCj4gPiBJIGhvcGUgbm90LCBidXQg bWF5YmUgYmVzdCBsZWZ0IHRvIGEgbmF0aXZlIGVuZ2xpc2ggc3BlYWtlciAoUkZDLWVkaXRvciku DQo+ID4gDQo+ID4gVGhlIGZpcnN0IChSRkM4Mjc5KSBwc2V1ZG9jb2RlIHdhcyBzaW1wbGlmaWVk LiBUaGUgc2Vjb25kIG9uZSBpcyBjb21wcmVoZW5zaXZlLiBJZiBub3QgY29tcHJlaGVuc2l2ZSwg d2hhdHMgYSBnb29kIG9wcG9zaXRlIG9mIHNpbXBsaWZpZWQgPw0KPiA+IA0KPiA+IFp6aD4gUGVy aGFwcyAiVGhlIGFib3ZlIHNpbXBsaWZpZWQgcHNldWRvY29kZSBpcyBlbGFib3JhdGVkIGZ1cnRo ZXIgYXMgZm9sbG93aW5nIj8NCj4gPiBaemg+IEplZmZyZXkNCj4gDQo+IERvbmUuDQo+IA0KPiBU aGFua3MgYSBsb3QuIA0KPiANCj4gDQo+ID4gICAgDQo+ID4gPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiBGcm9tOiBCSUVSIFtiaWVyLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOmJpZXItYm91bmNlc0BpZXRmLm9yZz5dIA0KPiA+ID4gb24gYmVoYWxmIG9m IFRvZXJsZXNzIEVja2VydCBbdHRlQGNzLmZhdS5kZTxtYWlsdG86dHRlQGNzLmZhdS5kZT5dDQo+ ID4gPiBTZW50OiBUdWVzZGF5LCBKdWx5IDA5LCAyMDE5IDIzOjM4DQo+ID4gPiBUbzogTWlrZSBN Y0JyaWRlDQo+ID4gPiBDYzogR3JlZyBTaGVwaGVyZDsgQklFUiBXRzsgUGFzY2FsIFRodWJlcnQg KHB0aHViZXJ0KQ0KPiA+ID4gU3ViamVjdDogUmU6IFtCaWVyXSBXR0xDIC0gZHJhZnQtaWV0Zi1i aWVyLXRlLWFyY2gNCj4gPiA+IA0KPiA+ID4gVGhhbmtzLCBNaWtlDQo+ID4gPiANCj4gPiA+IFRo ZSBhdXRob3JzIGFsc28gcmV2aWV3ZWQgdGhlIGRvY3VtZW50IGFuZCBjb25jbHVkZWQgdGhhdCBp dCB3YXMgDQo+ID4gPiByZWFsbHkgaGFyZCB0byBnZXQgaW50byB0aGUgZG9jdW1lbnQgY29udGV4 dCBiZWNhdXNlIG9mIHRvbyBtYW55IA0KPiA+ID4gZm9yd2FyZCBkZXBlbmRlbmNpZXMuIFdlIHRy aWVkIHRvIGZpeCB0aGlzIGJ5IGFkZGluZyB0d28gaG9wZWZ1bGx5IA0KPiA+ID4gZ29vZCAmIGJh c2ljIGV4YW1wbGVzIGludG8gdGhlIEludHJvZHVjdGlvbiBzZWN0aW9uIGFuZCB1c2luZyB0aGVt IA0KPiA+ID4gdG8gYWxzbyBhZGQgYSBiZXR0ZXIgZGVmaW5pdGlvbiBvZiB0aGUgdGVybSAiQklF Ui1URSBUb3BvbG9neSIgaW4gdGhlIEludHJvZHVjdGlvbi4NCj4gPiA+IEhvcGVmdWxseSB0aGlz IG1ha2VzIHJlYWRpbiB0aGUgcmVzdCBvZiB0ZSBkb2N1bWVudCBzbW9vdGhlci4uLg0KPiA+ID4g DQo+ID4gPiBBbHNvIGltcHJvdmVkIHRleHQgb2YgQWJzdHJhY3QgYW5kIHJlZmluZWQgdGV4dCBj b21wYXJpaW5nIEJJRVItVEUgd2l0aCBTUi4NCj4gPiA+IA0KPiA+ID4gaHR0cHM6Ly91cmxkZWZl bnNlLmNvbS92My9fX2h0dHA6Ly90b29scy5pZXRmLm9yZy8qcmZjZGlmZj91cmwxPWh0dHBzOg0K PiA+ID4gKipBdG9vbHMuaWV0Zi5vcmcqaWQqZHJhZnQtaWV0Zi1iaWVyLXRlLWFyY2gtMDIudHh0 JnVybDI9aHR0cHM6KipBDQo+ID4gPiB0b29sDQo+ID4gPiBzLmlldGYub3JnKmlkKmRyYWZ0LWll dGYtYmllci10ZS1hcmNoLTAzLnR4dF9fO0x5OHZMeTh2THk4diE4V29BNlINCj4gPiA+IGpDODEg DQo+ID4gPiBjIVh2SDRBQXhmckRqRm9LX3NlcmN3Wk1zYzBPNU40MmVFTk9zNGxfcWRzWEYwS3da RDgyY0pMREZGTlZfZVRVRWgNCj4gPiA+ICQNCj4gPiA+IDxodHRwczovL3VybGRlZmVuc2UuY29t L3YzL19faHR0cDovdG9vbHMuaWV0Zi5vcmcvKnJmY2RpZmY/dXJsMT1odHRwczoNCj4gPiA+ICoq QXRvb2xzLmlldGYub3JnKmlkKmRyYWZ0LWlldGYtYmllci10ZS1hcmNoLTAyLnR4dCZ1cmwyPWh0 dHBzOioqQQ0KPiA+ID4gdG9vbA0KPiA+ID4gcy5pZXRmLm9yZyppZCpkcmFmdC1pZXRmLWJpZXIt dGUtYXJjaC0wMy50eHRfXztMeTh2THk4dkx5OHYhOFdvQTZSDQo+ID4gPiBqQzgxIA0KPiA+ID4g YyFVQlRHdldXcE1IeWVpU2FueHM2dkliX0VuQlZneWc2Ym9BQVc0bnJxanU4VUNMT2dpdVhjOFlf NnNOZDFuamNYDQo+ID4gPiAkPg0KPiA+ID4gDQo+ID4gPiBDaGVlcnMNCj4gPiA+ICAgICBUb2Vy bGVzcw0KPiA+ID4gDQo+ID4gPiBPbiBXZWQsIEp1biAyNiwgMjAxOSBhdCAxMDozOTozNkFNIC0w NzAwLCBNaWtlIE1jQnJpZGUgd3JvdGU6DQo+ID4gPiA+IEhvdyBhYm91dCB0aHJlZT8gSSBzdXBw b3J0Lg0KPiA+ID4gPiBtaWtlDQo+ID4gPiA+DQo+ID4gPiA+IE9uIFR1ZSwgSnVuIDI1LCAyMDE5 IGF0IDEwOjQyIEFNIEdyZWcgU2hlcGhlcmQgPGdqc2hlcEBnbWFpbC5jb208bWFpbHRvOmdqc2hl cEBnbWFpbC5jb20+PiB3cm90ZToNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFdlIGNhbm5vdCB0YWtl IHR3byAneWVzJyB2b3RlcyBhbmQgV0cgY29uc2Vuc3VzLg0KPiA+ID4gPiA+IFBsZWFzZSwgcmVh ZCBhbmQgcmVzcG9uZC4gSWYgeW91IGRvbid0IHN1cHBvcnQsIHRoZW4gcGxlYXNlIHZvdGUgYXMg bXVjaCBwdWJsaWNseSByaWdodCBoZXJlLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhhbmtzLA0K PiA+ID4gPiA+IEdyZWcNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IE9uIE1vbiwgSnVuIDMsIDIwMTkg YXQgMTA6MDUgUE0gUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSA8cHRodWJlcnRAY2lzY28uY29t PG1haWx0bzpwdGh1YmVydEBjaXNjby5jb20+PiB3cm90ZToNCj4gPiA+ID4gPj4NCj4gPiA+ID4g Pj4gU3VwcG9ydDoNCj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4gSSBzZWUgZ3JlYXQgdmFsdWUgaW4g ZGV0ZXJtaW5pc3RpYyBuZXR3b3JrcyBhcyB3ZWxsIGFzIElPVCAod2l0aCBSUEwpLg0KPiA+ID4g PiA+Pg0KPiA+ID4gPiA+PiBBbGwgdGhlIGJlc3QsDQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+IFBh c2NhbA0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4gPiA+ID4+ID4gRnJvbTogQklFUg0KPiA+ID4gPiA+PiA+IDxiaWVyLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOmJpZXItYm91bmNlc0BpZXRmLm9yZz4+IE9uIA0KPiA+ID4gPiA+PiA+IEJl aGFsZiBPZiBUb2VybGVzcyBFY2tlcnQNCj4gPiA+ID4gPj4gPiBTZW50OiBtYXJkaSA0IGp1aW4g MjAxOSAwMjowMw0KPiA+ID4gPiA+PiA+IFRvOiBHcmVnIFNoZXBoZXJkIA0KPiA+ID4gPiA+PiA+ IDxnanNoZXBAZ21haWwuY29tPG1haWx0bzpnanNoZXBAZ21haWwuY29tPj4NCj4gPiA+ID4gPj4g PiBDYzogQklFUiBXRyA8YmllckBpZXRmLm9yZzxtYWlsdG86YmllckBpZXRmLm9yZz4+DQo+ID4g PiA+ID4+ID4gU3ViamVjdDogUmU6IFtCaWVyXSBXR0xDIC0gZHJhZnQtaWV0Zi1iaWVyLXRlLWFy Y2gNCj4gPiA+ID4gPj4gPg0KPiA+ID4gPiA+PiA+ICsxDQo+ID4gPiA+ID4+ID4gT2J2aW91c2x5 IHN1cHBvcnQgYXMgY28tYXV0aG9yLg0KPiA+ID4gPiA+PiA+DQo+ID4gPiA+ID4+ID4gT24gV2Vk LCBNYXkgMjksIDIwMTkgYXQgMTI6NDE6MjZQTSAtMDcwMCwgR3JlZyBTaGVwaGVyZCB3cm90ZToN Cj4gPiA+ID4gPj4gPiA+IFBsZWFzZSByZWFkIGFuZCByZXNwb25kIHRvIHRoaXMgdGhyZWFkIHcv IG9yIHcvbyBzdXBwb3J0Lg0KPiA+ID4gPiA+PiA+ID4NCj4gPiA+ID4gPj4gPiA+IGh0dHBzOi8v dXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnDQo+ID4gPiA+ ID4+ID4gPiAvZG9jIA0KPiA+ID4gPiA+PiA+ID4gL2RyYWZ0LWlldGYtYmllci10ZS1hcmNoL19f OyE4V29BNlJqQzgxYyFYdkg0QUF4ZnJEakZvS19zDQo+ID4gPiA+ID4+ID4gPiBlcmN3IFpNc2Mw TzVONDJlRU5PczRsX3Fkc1hGMEt3WkQ4MmNKTERGRk5WOWVDbEJqJA0KPiA+ID4gPiA+PiA+ID4g PGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovZGF0YXRyYWNrZXIuaWV0Zi5vcmcv DQo+ID4gPiA+ID4+ID4gPiBkb2MvIA0KPiA+ID4gPiA+PiA+ID4gZHJhZnQtaWV0Zi1iaWVyLXRl LWFyY2gvX187IThXb0E2UmpDODFjIVVCVEd2V1dwTUh5ZWlTYW54DQo+ID4gPiA+ID4+ID4gPiBz NnZJIGJfRW5CVmd5ZzZib0FBVzRucnFqdThVQ0xPZ2l1WGM4WV82c0Q0MGttdEgkPg0KPiA+ID4g PiA+PiA+ID4NCj4gPiA+ID4gPj4gPiA+IFZvdGUgZW5kcyA1IEp1bmUgMjAxOS4NCj4gPiA+ID4g Pj4gPiA+DQo+ID4gPiA+ID4+ID4gPiBUaGFua3MsDQo+ID4gPiA+ID4+ID4gPiBTaGVwDQo+ID4g PiA+ID4+ID4gPiAoY2hhaXJzKQ0KPiA+ID4gPiA+PiA+DQo+ID4gPiA+ID4+ID4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+PiA+ID4g QklFUiBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPj4gPiA+IEJJRVJAaWV0Zi5vcmc8bWFpbHRvOkJJ RVJAaWV0Zi5vcmc+DQo+ID4gPiA+ID4+ID4gPiBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19f aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi8NCj4gPiA+ID4gPj4gPiA+IGxpc3QNCj4gPiA+ ID4gPj4gPiA+IGluZm8vYmllcl9fOyE4V29BNlJqQzgxYyFYdkg0QUF4ZnJEakZvS19zZXJjd1pN c2MwTzVONDJlRQ0KPiA+ID4gPiA+PiA+ID4gTk9zNCBsX3Fkc1hGMEt3WkQ4MmNKTERGRk5UMldW WFdYJCANCj4gPiA+ID4gPj4gPiA+IDxodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6 L3d3dy5pZXRmLm9yZy9tYWlsbWFuLw0KPiA+ID4gPiA+PiA+ID4gbGlzdCANCj4gPiA+ID4gPj4g PiA+IGluZm8vYmllcl9fOyE4V29BNlJqQzgxYyFVQlRHdldXcE1IeWVpU2FueHM2dkliX0VuQlZn eWc2Yg0KPiA+ID4gPiA+PiA+ID4gb0FBVyA0bnJxanU4VUNMT2dpdVhjOFlfNnNLbjJLb0FUJD4N Cj4gPiA+ID4gPj4gPg0KPiA+ID4gPiA+PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ID4+ID4gQklFUiBtYWlsaW5nIGxpc3QNCj4gPiA+ ID4gPj4gPiBCSUVSQGlldGYub3JnPG1haWx0bzpCSUVSQGlldGYub3JnPg0KPiA+ID4gPiA+PiA+ IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpDQo+ID4gPiA+ID4+ID4gc3RpbiANCj4gPiA+ID4gPj4gPiBmby9iaWVyX187IThXb0E2UmpD ODFjIVh2SDRBQXhmckRqRm9LX3NlcmN3Wk1zYzBPNU40MmVFTk9zNA0KPiA+ID4gPiA+PiA+IGxf cWQNCj4gPiA+ID4gPj4gPiBzWEYwS3daRDgyY0pMREZGTlQyV1ZYV1gkDQo+ID4gPiA+ID4+ID4g PGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovd3d3LmlldGYub3JnL21haWxtYW4v bGkNCj4gPiA+ID4gPj4gPiBzdGluIA0KPiA+ID4gPiA+PiA+IGZvL2JpZXJfXzshOFdvQTZSakM4 MWMhVUJUR3ZXV3BNSHllaVNhbnhzNnZJYl9FbkJWZ3lnNmJvQUFXDQo+ID4gPiA+ID4+ID4gNG5y cQ0KPiA+ID4gPiA+PiA+IGp1OFVDTE9naXVYYzhZXzZzS24yS29BVCQ+DQo+ID4gPiA+ID4NCj4g PiA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+ID4gPiA+IEJJRVIgbWFpbGluZyBsaXN0DQo+ID4gPiA+ID4gQklFUkBpZXRmLm9yZzxtYWls dG86QklFUkBpZXRmLm9yZz4NCj4gPiA+ID4gPiBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19f aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aQ0KPiA+ID4gPiA+IG5mby8gDQo+ID4g PiA+ID4gYmllcl9fOyE4V29BNlJqQzgxYyFYdkg0QUF4ZnJEakZvS19zZXJjd1pNc2MwTzVONDJl RU5PczRsX3Fkc1gNCj4gPiA+ID4gPiBGMEt3DQo+ID4gPiA+ID4gWkQ4MmNKTERGRk5UMldWWFdY JA0KPiA+ID4gPiA+IDxodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpDQo+ID4gPiA+ID4gbmZvLyANCj4gPiA+ID4gPiBiaWVyX187IThX b0E2UmpDODFjIVVCVEd2V1dwTUh5ZWlTYW54czZ2SWJfRW5CVmd5ZzZib0FBVzRucnFqdQ0KPiA+ ID4gPiA+IDhVQ0wNCj4gPiA+ID4gPiBPZ2l1WGM4WV82c0tuMktvQVQkPg0KPiA+ID4gDQo+ID4g PiAtLQ0KPiA+ID4gLS0tDQo+ID4gPiB0dGVAY3MuZmF1LmRlPG1haWx0bzp0dGVAY3MuZmF1LmRl Pg0KPiA+ID4gDQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+ID4gQklFUiBtYWlsaW5nIGxpc3QNCj4gPiA+IEJJRVJAaWV0Zi4uLm9yZzxt YWlsdG86QklFUkBpZXRmLm9yZz4NCj4gPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLw0KPiA+ID4gYmllciANCj4gPiA+ IF9fOyE4V29BNlJqQzgxYyFYdkg0QUF4ZnJEakZvS19zZXJjd1pNc2MwTzVONDJlRU5PczRsX3Fk c1hGMEt3WkQ4Mg0KPiA+ID4gY0pMRA0KPiA+ID4gRkZOVDJXVlhXWCQNCj4gPiA+IDxodHRwczov L3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv Lw0KPiA+ID4gYmllciANCj4gPiA+IF9fOyE4V29BNlJqQzgxYyFVQlRHdldXcE1IeWVpU2FueHM2 dkliX0VuQlZneWc2Ym9BQVc0bnJxanU4VUNMT2dpdQ0KPiA+ID4gWGM4WQ0KPiA+ID4gXzZzS24y S29BVCQ+DQo+ID4gDQo+ID4gLS0NCj4gPiAtLS0NCj4gPiB0dGVAY3MuZmF1LmRlDQo+IA0KPiAt LQ0KPiAtLS0NCj4gdHRlQGNzLmZhdS5kZQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gQklFUiBtYWlsaW5nIGxpc3QNCj4gQklFUkBpZXRm Lm9yZw0KPiBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9iaWVyDQo+IF9fOyEhTkV0NnlNYU8tZ2shVnVRQ1ZIbnFKeV9hWUkt Rk50OUExYTVFekhPQ3IwZlprTFBiZ2czQ1BOdTBQeXJXc3JGeDQNCj4gMV9qV1YzWVVBNkQkDQoN Ci0tDQotLS0NCnR0ZUBjcy5mYXUuZGUNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkJJRVIgbWFpbGluZyBsaXN0DQpCSUVSQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JpZXI= --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZh bWlseTphcmlhbDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIOWui+S9kywgJ01p Y3Jvc29mdCBZYWhlaScsICdMdWNpZGEgR3JhbmRlJywgVmVyZGFuYSwgTHVjaWRhLCBIZWx2ZXRp Y2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTZweDsgbGluZS1oZWlnaHQ6IDIyLjg1NzE0MzQw MjA5OTZweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+U3VwcG9ydC48 L3NwYW4+PGJyIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94OyBmb250LWZhbWlseTogQXJp YWwsIOWui+S9kywgJ01pY3Jvc29mdCBZYWhlaScsICdMdWNpZGEgR3JhbmRlJywgVmVyZGFuYSwg THVjaWRhLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTZweDsgbGluZS1oZWln aHQ6IDIyLjg1NzE0MzQwMjA5OTZweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgb3V0bGluZTogMHB4 ICFpbXBvcnRhbnQ7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPjxiciBz dHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsgZm9udC1mYW1pbHk6IEFyaWFsLCDlrovkvZMs ICdNaWNyb3NvZnQgWWFoZWknLCAnTHVjaWRhIEdyYW5kZScsIFZlcmRhbmEsIEx1Y2lkYSwgSGVs dmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE2cHg7IGxpbmUtaGVpZ2h0OiAyMi44NTcx NDM0MDIwOTk2cHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7IG91dGxpbmU6IDBweCAhaW1wb3J0YW50 OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6IEFyaWFsLCDlrovkvZMsICdNaWNyb3NvZnQgWWFoZWknLCAnTHVjaWRhIEdyYW5k ZScsIFZlcmRhbmEsIEx1Y2lkYSwgSGVsdmV0aWNhLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDE2 cHg7IGxpbmUtaGVpZ2h0OiAyMi44NTcxNDM0MDIwOTk2cHg7IGJhY2tncm91bmQtY29sb3I6IHJn YigyNTUsIDI1NSwgMjU1KTsiPlJlZ2FyZHM8L3NwYW4+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6 MTRweDtmb250LWZhbWlseTphcmlhbDsiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWws IOWui+S9kywgJ01pY3Jvc29mdCBZYWhlaScsICdMdWNpZGEgR3JhbmRlJywgVmVyZGFuYSwgTHVj aWRhLCBIZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTZweDsgbGluZS1oZWlnaHQ6 IDIyLjg1NzE0MzQwMjA5OTZweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUp OyI+UmFuPC9zcGFuPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6YXJp YWw7Ij48YnI+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZhbWlseTphcmlhbDsi Pjxicj48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5OmFyaWFsOyI+PGJy PjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij48YnI+PC9w PjxkaXY+PGRpdiBjbGFzcz0iemhpc3RvcnlSb3ciIHN0eWxlPSJkaXNwbGF5OmJsb2NrIj48ZGl2 IGNsYXNzPSJ6aGlzdG9yeURlcyIgc3R5bGU9IndpZHRoOiAxMDAlOyBoZWlnaHQ6IDI4cHg7IGxp bmUtaGVpZ2h0OiAyOHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiAjRTBFNUU5OyBjb2xvcjogIzEzODhG RjsgdGV4dC1hbGlnbjogY2VudGVyOyIgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeU9yZ1R4dCI+5Y6f 5aeL6YKu5Lu2PC9kaXY+PGRpdiBpZD0iendyaXRlSGlzdG9yeUNvbnRhaW5lciI+PGRpdiBjbGFz cz0iY29udHJvbC1ncm91cCB6aGlzdG9yeVBhbmVsIj48ZGl2IGNsYXNzPSJ6aGlzdG9yeUhlYWRl ciIgc3R5bGU9InBhZGRpbmc6IDhweDsgYmFja2dyb3VuZC1jb2xvcjogI0Y1RjZGODsiPjxkaXY+ PHN0cm9uZyBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5U2VuZGVyVHh0Ij7lj5Hku7bkurrvvJo8L3N0 cm9uZz48c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFtZSI+R3JlZ1NoZXBoZXJkICZsdDtnanNoZXBA Z21haWwuY29tJmd0Ozwvc3Bhbj48L2Rpdj48ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlz dG9yeVRPVHh0Ij7mlLbku7bkurrvvJo8L3N0cm9uZz48c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFt ZSIgc3R5bGU9ImRpc3BsYXk6IGlubGluZTsiPkplZmZyZXkgKFpoYW9odWkpIFpoYW5nICZsdDt6 emhhbmc9NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZyZndDs7PC9zcGFuPjwvZGl2PjxkaXY+ PHN0cm9uZyBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5Q0NUeHQiPuaKhOmAgeS6uu+8mjwvc3Ryb25n PjxzcGFuIGNsYXNzPSJ6cmVhZFVzZXJOYW1lIiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyI+Ymll ckBpZXRmLm9yZyAmbHQ7YmllckBpZXRmLm9yZyZndDs7PC9zcGFuPjxzcGFuIGNsYXNzPSJ6cmVh ZFVzZXJOYW1lIiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyI+VG9lcmxlc3MgRWNrZXJ0ICZsdDt0 dGVAY3MuZmF1LmRlJmd0Ozs8L3NwYW4+PC9kaXY+PGRpdj48c3Ryb25nIGxhbmd1YWdlLWRhdGE9 Ikhpc3RvcnlEYXRlVHh0Ij7ml6Ug5pyfIO+8mjwvc3Ryb25nPjxzcGFuIGNsYXNzPSIiPjIwMjDl ubQwMuaciDE55pelIDA0OjQ2PC9zcGFuPjwvZGl2PjxkaXY+PHN0cm9uZyBsYW5ndWFnZS1kYXRh PSJIaXN0b3J5U3ViamVjdFR4dCI+5Li7IOmimCDvvJo8L3N0cm9uZz48c3BhbiBjbGFzcz0ienJl YWRUaXRsZSI+PHN0cm9uZz5bQmllcl0gV0dMQyAtIGRyYWZ0LWlldGYtYmllci10ZS1hcmNoIDEg V0VFSzwvc3Ryb25nPjwvc3Bhbj48L2Rpdj48L2Rpdj48ZGl2IGNsYXNzPSJ6aGlzdG9yeUNvbnRl bnQiPjxkaXY+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+QklFUiZuYnNwO21haWxpbmcmbmJzcDtsaXN0PGJyPkJJRVJAaWV0Zi5vcmc8YnI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iaWVyPGJyPjxicj48ZGl2IGRpcj0ibHRy Ij48ZGl2PlRoYW5rcyBUb2VybGVzcyBhbmQgSmVmZnJleTwvZGl2Pjxicj48ZGl2PjxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtYmllci10ZS1hcmNo LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtYmllci10ZS1hcmNoLzwvYT48YnI+PC9kaXY+PGJyPjxkaXY+T25lIG1vcmUgd2VlayBv ZiBXR0xDLiBQbGVhc2UgcmVhZCB0aGUgbGF0ZXN0IHJldiBhbmQgcmVzcG9uZCB0byB0aGlzIHRo cmVhZCB3L3dvIHN1cHBvcnQuPC9kaXY+PGJyPjxkaXY+Q2hhaXJzPC9kaXY+PGRpdj4oU2hlcCk8 L2Rpdj48YnI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48ZGl2IGRpcj0ibHRyIiBjbGFz cz0iZ21haWxfYXR0ciI+T24gVHVlLCBGZWIgMTgsIDIwMjAgYXQgMTI6MDcgUE0gSmVmZnJleSAo Wmhhb2h1aSkgWmhhbmcgJmx0O3p6aGFuZz08YSBocmVmPSJtYWlsdG86NDBqdW5pcGVyLm5ldEBk bWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5v cmc8L2E+Jmd0OyB3cm90ZTo8YnI+PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3Rl IiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCBy Z2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPkhpIFRvZXJsZXNzLDxicj48YnI+VGhh bmtzITxicj5JIHN1cHBvcnQgbW92aW5nIHRoaXMgdG8gdGhlIG5leHQgc3RhZ2UuPGJyPjxicj5K ZWZmcmV5PGJyPjxicj5PbiBGcmksIE5vdiAwMSwgMjAxOSBhdCAwNzo0MjozOFBNICswMTAwLCBU b2VybGVzcyBFY2tlcnQgd3JvdGU6PGJyPiZndDsgVGhhbmtzIEplZmY8YnI+Jmd0OyA8YnI+Jmd0 OyBJIGhhdmUgbm93IHB1c2hlZCBvdXQgLTA1IHdpdGggdGhlIGFuc3dlcnMgYW5kIGhvcGVmdWxs eSByZXNvbHV0aW9uIHRvIDxicj4mZ3Q7IHlvdXIgcG9pbnRzIGluIGVtYWlsIGJlbG93LiZuYnNw OyBCaWdnZXN0IGFkZGl0aW9uIHdhcyBhIHNlY3Rpb24gYWJvdXQgPGJyPiZndDsgcmV1c2Ugb2Yg QlBzICh3aXRob3V0IEROUikgd2hpY2ggY2FtZSBvdXQgb2YgdGhlIGNvbmZ1c2lvbiBpIHRoaW5r IHRoZSA8YnI+Jmd0OyByZXVzZSBpbiB0aGUgRUNNUCBleGFtcGxlIHJhaXNlZC4gSSB3YXMgYWZy YWlkIHNvIGZhciB0byBleHBsYW4gdGhhdCA8YnI+Jmd0OyBhcyBpdCBtYXkgbm90IGJlIGVhc3kg dG8gYWJzb3JiIGFuZCB1bHRpbWF0ZWx5IGlzIHN0dWZmIG9ubHkgPGJyPiZndDsgY29udHJvbGxl ciBkZXZlbG9wZXJzIG5lZWQgdG8gdW5kZXJzdGFuZCwgYnV0IGhvcGVmdWxseSB1c2VmdWwuPGJy PiZndDsgQW5kIHRoZW4gb2YgY291cnNlIHRoZSBzdW1tYXJ5IG9mIEJQIG9wdGltaXphdGlucyB5 b3UgYXNrZWQgZm9yPGJyPiZndDsgPGJyPiZndDsgRGlmZiBmcm9tIGxhc3QgdmVyc2lvbiBpIHNl bnQgeW91Ojxicj4mZ3Q7IDxicj4mZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20v djMvX19odHRwOi8vdG9vbHMuaWV0Zi5vcmcvKnJmY2RpZmY/dXJsMT1odHRwcyIgcmVsPSJub3Jl ZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHA6 Ly90b29scy5pZXRmLm9yZy8qcmZjZGlmZj91cmwxPWh0dHBzPC9hPjo8YnI+Jmd0OyAqKjxhIGhy ZWY9Imh0dHA6Ly9BcmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIgcmVsPSJub3JlZmVycmVyIiB0 YXJnZXQ9Il9ibGFuayI+QXJhdy5naXRodWJ1c2VyY29udGVudC5jb208L2E+KnRvZXJsZXNzKmJp ZXItdGUtYXJjaCptYXN0ZXIqZHJhZnQtaWV0Zi1iPGJyPiZndDsgaWVyLXRlLWFyY2gtMDUuMS50 eHQmYW1wO3VybDI9aHR0cDoqKjxhIGhyZWY9Imh0dHA6Ly9BdG9vbHMuaWV0Zi5vcmciIHJlbD0i bm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPkF0b29scy5pZXRmLm9yZzwvYT4qaWQqZHJhZnQt aWV0Zi1iaWVyLXRlPGJyPiZndDsgLWFyY2gtMDUudHh0X187THk4dkx5OHZMeTh2THk4ISFORXQ2 eU1hTy1nayFWdVFDVkhucUp5X2FZSS1GTnQ5QTFhNUV6SDxicj4mZ3Q7IE9DcjBmWmtMUGJnZzND UE51MFB5cldzckZ4NDFfaldYMkF0OFYtJDxicj4mZ3Q7IDxicj4mZ3Q7IGZ1bGwgLTA0IC0mZ3Q7 IDA1IGRpZmY6PGJyPiZndDsgPGJyPiZndDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNv bS92My9fX2h0dHA6Ly90b29scy5pZXRmLm9yZy8qcmZjZGlmZj91cmwxPWh0dHA6KiIgcmVsPSJu b3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0 dHA6Ly90b29scy5pZXRmLm9yZy8qcmZjZGlmZj91cmwxPWh0dHA6KjwvYT48YnI+Jmd0OyAqPGEg aHJlZj0iaHR0cDovL0F0b29scy5pZXRmLm9yZyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9i bGFuayI+QXRvb2xzLmlldGYub3JnPC9hPippZCpkcmFmdC1pZXRmLWJpZXItdGUtYXJjaC0wNC50 eHQmYW1wO3VybDI9aHR0cDoqKkF0b29scy48YnI+Jmd0OyA8YSBocmVmPSJodHRwOi8vaWV0Zi5v cmciIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmlldGYub3JnPC9hPippZCpkcmFm dC1pZXRmLWJpZXItdGUtYXJjaC0wNS50eHRfXztMeTh2THk4dkx5OHYhIU5FdDZ5TWFPLWdrPGJy PiZndDsgIVZ1UUNWSG5xSnlfYVlJLUZOdDlBMWE1RXpIT0NyMGZaa0xQYmdnM0NQTnUwUHlyV3Ny Rng0MV9qV2FuY3B6aXYkPGJyPiZndDsgPGJyPiZndDsgQ29tbWVudHMgaW5saW5lIGJlbG93Ljxi cj4mZ3Q7IDxicj4mZ3Q7IENoZWVyczxicj4mZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDt0b2VybGVz czxicj4mZ3Q7IDxicj4mZ3Q7IE9uIE1vbiwgT2N0IDI4LCAyMDE5IGF0IDA3OjUyOjU5UE0gKzAw MDAsIEplZmZyZXkgKFpoYW9odWkpIFpoYW5nIHdyb3RlOjxicj4mZ3Q7ICZndDsgSSBUaG91Z2h0 IHUtdHVybiBpcyB0aGUgbW9zdCBzaW1wbGUgY29tcGFyaXNvbiBsZWFmIHZzLiBub24tbGVhZiBC RlIuPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IFp6aCZndDsgVGhlIHRleHQgaW4gdGhlIGVt YWlsIGlzIHNlcmlvdXNseSBtaXNhbGlnbmVkLiBMb29raW5nIGF0IHRoZSBwaWN0dXJlIGluIHRo ZSBkaWZmIGxpbmssIHdoaWxlIHlvdSBnYXZlIGEgVS10dXJuIGV4YW1wbGUsIHRob3VnaCBldmVu IGlmIEJGRVIyIGlzIG5vdCBjb25uZWN0ZWQgdG8gQkZSMiZuYnNwOyBidXQgb25seSBjb25uZWN0 ZWQgdG8gQkZFUjEgKGhlbmNlIG5vIFUtdHVybiksIHRoZW4gQkZFUjEgaXMgc3RpbGwgbm90IGEg bGVhZiBCRkVSIEkgc3VwcG9zZS4gVGhhdCdzIHdoeSBJIHNhaWQgdGhlIGZpcnN0IHNlbnRlbmNl IG9mIHRoZSBhYm92ZSBwYXJhZ3JhcGggaXMgZW5vdWdoIHRvIGRlZmluZSBMZWFmIEJGRVIgd2hp bGUgdGhlIGV4YW1wbGUgaXRzZWxmIGlzIGFjdHVhbGx5IG5vdCBuZWVkZWQuPGJyPiZndDsgPGJy PiZndDsgQXJnaC4uLiBvaywgaGFkIHRvIGZpeCB0d28gd29yZHMsIEJGSVItJmd0O0JGRVIgYW5k IGxlZnQtaGFuZCAtJmd0OyByaWdodC1oYW5kOjxicj4mZ3Q7IDxicj4mZ3Q7IENvbnNpZGVyIGhv dyByZWR1bmRhbnQgZGlzam9pbnQgdHJhZmZpYyBjYW4gcmVhY2ggQkZFUjEvQkZFUjIgaW4gYWJv dmUgPGJyPiZndDsgcGljdHVyZTogV2hlbiBCRkVSMS9CRkVSMiBhcmUgTm9uLUxlYWYgQkZFUiBh cyBzaG93biBvbiB0aGUgcmlnaHQgaGFuZCA8YnI+Jmd0OyBzaWRlLCBvbmUgdHJhZmZpYyBjb3B5 IHdvdWxkIGJlIGZvcndhcmRlZCB0byBCRkVSMSBmcm9tIEJGUjEsIGJ1dCB0aGUgPGJyPiZndDsg b3RoZXIgb25lIGNvdWxkIG9ubHkgcmVhY2ggQkZFUjEgdmlhIEJGRVIyLCB3aGljaCBtYWtlcyBC RkVSMiBhIDxicj4mZ3Q7IG5vbi1MZWFmIEJGRVIuIExpa2V3aXNlIEJGRVIxIGlzIGEgbm9uLUxl YWYgQkZFUiB3aGVuIGZvcndhcmRpbmcgPGJyPiZndDsgdHJhZmZpYyB0byBCRkVSMjxicj4mZ3Q7 IDxicj4mZ3Q7ICZndDsgWnpoJmd0OyBBZGRpdGlvbmFsbHksIGluIGxlZnQgcGFydCBvZiB0aGUg cGljdHVyZSB5b3UgYWRkZWQsIGlmIHNvbWUgZmFpbHVyZSBsZWFkcyB0byBCRlIyIHRvIGJlIG9u bHkgcmVhY2hhYmxlIHZpYSBCRkVSMSwgdGhlbiBCRkVSMSBpcyBubyBsb25nZXIgYSBsZWFmIEJG RVIuIDxicj4mZ3Q7IDxicj4mZ3Q7IEFkZGVkIHNlbnRlbmNlOjxicj4mZ3Q7IDxicj4mZ3Q7ICZs dDt0Jmd0O05vdGUgdGhhdCB0aGUgQkZFUiBpbiB0aGUgbGVmdCBoYW5kIHBpY3R1cmUgYXJlIG9u bHkgZ3VhcmFudGVlZCB0byA8YnI+Jmd0OyBiZSBsZWFmLUJGUiBieSBmaXR0aW5nIHJvdXRpbmcg Y29uZmlndXJhdGlvbiB0aGF0IHByb2hpYml0cyB0cmFuc2l0IDxicj4mZ3Q7IHRyYWZmaWMgdG8g cGFzcyB0aHJvdWdoIGEgUEUsIHdoaWNoIGlzIGNvbW1vbmx5IGFwcGxpZWQgaW4gdGhlc2UgPGJy PiZndDsgdG9wb2xvZ2llcy4mbHQ7L3QmZ3Q7PGJyPiZndDsgPGJyPiZndDsgJmd0OyBJIGFzc3Vt ZSB5b3UgZG9uJ3QgcmVhc3NpZ24gQlBzIHdoZW4gbGlua3MgZ28gdXAgYW5kIGRvd24uPGJyPiZn dDsgPGJyPiZndDsgSSBkaWRuJ3Qgd2FudCB0byBkaXNjdXNzIHRoYXQgb3B0aW9uIGluIHRoaXMg ZG9jdW1lbnQuIEl0cyBvYnZpb3VzbHkgPGJyPiZndDsgcGVyZmVjdGx5IGZlYXNpYmxlLCBidXQg YmUgeWV0IGEgYmlnIGFtb3VudCBvZiB0ZXh0IChlc3BlY2lhbGx5IHRoZSA8YnI+Jmd0OyBjb25z aWRlcmF0aW9ucyBob3cgdG8gZG8gdGhpcyBtYWtlLWJlZm9yZS1icmVhay4gRnV0dXJlIGRvYy48 YnI+Jmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsgYnV0IHN1YnNlcXVlbnQgcG9sYXJpemF0aW9uIGV4 YW1wbGUgY29uZnVzZXMgbWUuIEl0IHNlZW1zIHRoYXQgQlAgMDo2IGlzIGFzc2lnbmVkIHRvIHRo ZSByb3V0ZWQgYWRqYWNlbmN5IEJGUjEwICh3aGljaCBpcyBhY3R1YWxseSB0YWxrZWQgYWJvdXQg aW4gU2VjdGlvbiA0LjgpLjxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBTZWN0aW9uIDQuNyBk b2VzIG5vdCBtZW50aW9uICJyb3V0ZWQiIGF0IGFsbCwgc28gdGhlcmUgYXJlIG5vIHJvdXRlZCBh ZGphY2VuY2llcyBhdCBhbGwgdXNlZCBpbiA0LjcuIFNvIGkgYW0gbm90IHN1cmUgd2hhdCB5b3Ug YXJlIGNvbmZ1c2VkIGFib3V0Ljxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBaemgmZ3Q7ICJU aGUgQklGVCBvZiBlYWNoIEJGUiBhcmUgb25seSBwb3B1bGF0ZWQgd2l0aCBCUHMgdGhhdCBhcmUg YWRqYWNlbnQgdG8gdGhlIEJGUiBpbiB0aGUgQklFUi1URSB0b3BvbG9neSIuPGJyPiZndDsgPGJy PiZndDsgQ29ycmVjdCB0ZXh0IGZyb20gdGhlIGludHJvZHVjdGlvbi4gT2suPGJyPiZndDsgPGJy PiZndDsgJmd0OyBaemgmZ3Q7IFNpbmNlIHRoZSBzYW1lIDA6NiBpcyBpbiBCSUZUUyBvZiBCRlIx L0JGUjIvQkZSMyAoYW5kIEkgc3VwcG9zZSBpbiBCRlI0fkJGUjkgYXMgd2VsbCBldmVuIHRob3Vn aCBub3QgZHJhd24pLCBJIGFzc3VtZWQgaXQncyBmb3IgdGhlICJNUDJQIiByb3V0ZWQgYWRqYWNl bmN5IHRvIFIxMDsgdGhvdWdoIEkgdGhlbiBydWxlZCB0aGF0IG91dCAtIGJ1dCBJIGRvbid0IGtu b3cgd2hhdCAwOjYgcmVwcmVzZW50IG5vdyBvbiBCRlIxLCBCRlIyLCBhbmQgQkZSMy48YnI+Jmd0 OyA8YnI+Jmd0OyBBaC4gT2suIEkgdGhvdWdodCBpIGNvdWxkIHN0cmlwIGRvd24gdGhlIGV4YW1w bGUgdG8gc2hvdyBvbmx5IHRoZSA8YnI+Jmd0OyBhZGphY2VuY2llcyByZWxldmFudCB0byB0aGUg Zm9sbG93aW5nIGRpc2N1c2lvbiwgYnV0IHNlZW1pbmdseSB0aGlzIDxicj4mZ3Q7IGNhbiBpbnRy b2R1Y2UgdGhlIGNvbmZ1c2lvbiB5b3UgaGF2ZS48YnI+Jmd0OyA8YnI+Jmd0OyBTbyBpIGNvbXBs ZXRlZCB0aGUgZXhhbXBsZSB3aXRoIHRoZSBCUCBhc3NpZ25tZW50IGFjb3NzIGFsbCBub2Rlcywg YnV0IDxicj4mZ3Q7IGFkZGVkIHRleHQgcG9pbnRpbmcgdG8gYSBuZXcgc2VjdGlvbiBmdXJ0aGVy IGRvd24gdG8gZGlzY3VzcyB0aGUgPGJyPiZndDsgcmUtdXNlIG9mIEJQIGZvciB3aGljaCB0aGkg cGljdHVyZSBpcyBhbHNvIGFuIGV4YW1wbGUuPGJyPiZndDsgPGJyPiZndDsgKGNoZWNrIG91dCB0 aGUgZGlmZiwgbmV3IHJldXNlIHRleHQgdG8gbG9uZyB0byBjb3B5IGlubGluZSkuPGJyPiZndDsg PGJyPiZndDsgJmd0OyBUaGUgd2hvbGUgcHVycG9zZSBvZiB0aGUgRUNNUCBCUHMgaXMgb2YgY291 cnNlIHRvIHNhdmUgYml0cywgb3RoZXJ3aXNlIHdlJ2QgZ2l2ZSBlYWNoIGxpbmsgYSBzZXBhcmF0 ZSBCUCwgd2hpY2ggd291bGQgYmUgNiBCUCB0byByZWFjaCB0byBCRlI0Li4uQkZSNyBmcm9tIEJG UjEuIDxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBaemgmZ3Q7IFRoZSB0cm91YmxlIEkgYW0g aGF2aW5nIGlzIHRoYXQgdGhlIHNhbWUgMDo2IGlzIGFzc2lnbmVkIHRvIGRpZmZlcmVudCB0aGlu Z3MgYW5kIGl0J3MgcHJlc2VudCBvbiBhbGwgQkZSMS9CRlIyL0JGUjMuIEl0IGlzIHBlcmhhcHMg YW4gaW50ZW50aW9uYWwgc21hcnQgZGVzaWduIGJ1dCBJIGhhdmUgbm90IHdyYXBwZWQgbXkgbWlu ZCBhcm91bmQgaXQuIEl0J3MgYXBwYXJlbnRseSBkaWZmZXJlbnQgZnJvbSB0aGUgbGluayBidW5k bGUgY2FzZSwgc28gYmV0dGVyIHNlcGFyYXRlIGl0IG91dCBhbmQgZWxhYm9yYXRlIGl0IChpbmNs dWRpbmcgdGhlIEROUiBmbGFnIHRoYXQgbWlnaHQgYmUgbmVlZGVkIGhlcmUgLSBJZiB0aGUgcGFj a2V0IGFycml2ZXMgb24gQkZSMSB3aXRoIDA6Niwgd291bGQgdGhlIEJQIHJlc2V0IHdoZW4gaXQg aXMgc2VudCB0byBCRlIyLzMpPzxicj4mZ3Q7IDxicj4mZ3Q7IFllcywgdGhlcmUgd2FzIHRoZSBi dWcgb2YgcmV1c2luZyBCUCAwOjYgYWNyb3NzIHNlcXVlbnRpYWwgQkZSIGFsb25nIDxicj4mZ3Q7 IHRoZSBwYXRoLCBidXQgbm93IHRoZSBleGFtcGxlIGNvcnJlY3RseSByZXVzZXMgc2VwYXJhdGUg QlAgYXQgPGJyPiZndDsgZGlmZmVyZW50IHN0YWdlcyBvZiB0aGUgcGF0aHMgKEJQIDA6NiBvbiBC RlIxLCBCUCAwOjcgb24gQkZSMi9CRlIzKSBhbmQgc28gb24uPGJyPiZndDsgPGJyPiZndDsgVGhh bmtzITxicj4mZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyA0LjguJm5ic3A7IFJvdXRlZCBhZGphY2Vu Y2llczxicj4mZ3Q7ICZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsgSWYgSSB1bmRlcnN0YW5k IGl0IGNvcnJlY3RseSwgdGhlcmUgaXMgYSBCUCBhc3NpZ25lZCB0byBMMS9MMi9MMyA8YnI+Jmd0 OyAmZ3Q7ICZndDsgcmVzcGVjdGl2ZWx5IChwMnAgbGluayksIGFuZCB0aGVuIHRoZXJlIGFyZSBC UHMgYXNzaWduZWQgdG8gTVAyUCB0dW5uZWxzIChyb3V0ZWQgYWRqYWNlbmN5IGZyb20gZXZlcnkg QkZSKSB0byB0aGUgTDEvTDIvTDMgaW50ZXJmYWNlIGFkZHJlc3NlcyBhbmQgbG9vcGJhY2sgYWRk cmVzc2VzIG9uIEJGUjIvMy48YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgT2sgdGhhdCB3YXNu J3QgcXVpdGUgdGhlIHJlYWQgaSBleHBlY3RlZC4gTGV0IG1lIGNsYXJpZnkgdGhlIHRleHQvcGlj dHVyZTo8YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLi4uLi4uLi4uLi4u Li4uJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAuLi5CRlIxLS0uLi4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOy4uLi0tTDEtLSBCRlIyLi4uPGJyPiZndDsgJmd0OyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy4uLiAu Um91dGVycy4gLi4uLS1MMi0tLyZuYnNwOyA8YnI+Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAuLi5CRlI0LS0uLi4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOy4uLi0tLS0tLSBCRlIzLi4uPGJyPiZndDsgJmd0OyZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAu Li4uLi4uLi4uLi4uLi4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxicj4mZ3Q7 ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtMTzxicj4mZ3Q7ICZn dDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7TmV0d29yayBBcmVhIDE8YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7 ICZndDsgQXNzdW1lIHRoZSByZXF1aXJlbWVudCBpbiB0aGUgYWJvdmUgcGljdHVyZSBpcyB0byBl eHBsaWNpdGx5IHN0ZWVyIHRyYWZmaWMgZmxvd3MgdGhhdCBoYXZlIGFycml2ZWQgYXQgQkZSMSBv ciBCRlI0IHZpYSBhIHNob3J0ZXN0IHBhdGggaW4gdGhlIHJvdXRpbmcgdW5kZXJsYXkgIm5ldHdv cmsgYXJlYSAxIiB0byBvbmUgb2YgdGhlIGZvbGxvd2luZyB0aHJlZSBuZXh0IHNlZ21lbnRzOiAo MSkgQkZSMiB2aWEgbGluayBMMSwgKDIpIEJGUjIgdmlhIGxpbmsgTDIsICgzKSB2aWEgQkZSMy48 YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgVG8gYWNoaWV2ZSB0aGlzLCBib3RoIEJGUjEgYW5k IEJGUjQgYXJlIHNldCB1cCB3aXRoIGEgZm9yd2FyZF9yb3V0ZWQgYWRqYWNlbmN5IEJpdFBvc2l0 aW9uIHRvd2FyZHMgYW4gYWRkcmVzcyBvZiBCRlIyIG9uIGxpbmsgTDEsIGFub3RoZXIgZm9yd2Fy ZF9yb3V0ZWQgQml0UG9zaXRpb24gdG93YXJkcyBhbiBhZGRyZXNzIG9mIEJGUjIgb24gbGluayBM MiBhbmQgYSB0aGlyZCBmb3J3YXJkX3JvdXRlZCBCaXRwb3NpdGlvbiB0b3dhcmRzIGEgbm9kZSBh ZGRyZXNzIExPIG9mIEJGUjMuPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IERvZXMgdGhpcyBj bGVhciBpcCB0aGUgY29uZnVzaW9uID88YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgWnpoJmd0 OyBUaGUgcGljdHVyZSBpcyBiYWRseSBtaXNhbGlnbmVkLiBJJ2xsIHdhaXQgdGlsbCA0LjcgcXVl c3Rpb25zIGFyZSBjbGVhcmVkLjxicj4mZ3Q7IDxicj4mZ3Q7IE9rLjxicj4mZ3Q7IDxicj4mZ3Q7 ICZndDsgJmd0OyBJZiBCRlIyLzMgYXJlIGFsc28gQkZFUnMsIHRoZW4gdGhleSBhZGRpdGlvbmFs bHkgd2lsbCBoYXZlIEJGRVIgQlBzLjxicj4mZ3Q7ICZndDsgJmd0OyBPbiBCRlIxLzQsIHRoZSBC SUZUIGVudHJpZXMgZm9yIHRoZSBNUDJQIEJQcyBmb3IgdGhlIEwxL0wyL0wzL2xvb3BiYWNrIGlu dGVyZmFjZSBhZGRyZXNzZXMgb2YgQkZSMi8zIHdpbGwgdXNlIGZvcndhcmRfcm91dGVkKGludGVy ZmFjZS9sb29wYmFjayBhZGRyZXNzKS4gRm9yIGEgcGFja2V0IHRvIGJlIGRlY2Fwc3VsYXRlZCBv biBhIEJGRVIsIHRoZXJlIGlzIGEgbmVlZCBmb3IgYm90aCB0aGUgQkZFUiBCUCBhbmQgYW5vdGhl ciBCUCAocDJwL2xhbi9odWItc3Bva2Uvcm91dGVkLWFkamFjZW5jeSkgaW4gdGhlIHBhY2tldCAo dGhlIGZvcm1lciBpcyBmb3IgZGVjYXBzdWxhdGlvbiBhbmQgdGhlIGxhdHRlciBpcyBmb3IgZ2V0 dGluZyBpdCB0aGVyZSkuPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IFRoaXMgaXMgbm90IGRp c2N1c3NlZCBpbiB0aGlzIHNlY3Rpb24sIGJ1dCB5b3UgYXJlIHJpZ2h0IC0gdW5sZXNzPGJyPiZn dDsgJmd0OyBCRlIyIG9yIEJGUjMgaXMgYSBsZWFmIEJGUi4gSW4gdGhhdCBjYXNlLCBpdCB3b3Vs ZCBqdXN0IGxldmVyYWdlIHRoZSBvbmUgc2hhcmVkICJsZWFmLUJGUiIgQlAsIHNvIHRoZXkgZG8g bm90IG5lZWQgYSBwZXItQkZFUiBCUCBmb3IgbG9jYWxfZGVjYXAoKS4gPGJyPiZndDsgJmd0OyA8 YnI+Jmd0OyAmZ3Q7IFp6aCZndDsgUmlnaHQgLSBzaGFyZWQgbGVhZi1CRlIgQlAgYnV0IHN0aWxs IG5lZWQgdGhhdCBCUCAodGhlIGtleSBpcyB0aGF0IHdlIG5lZWQgYSBCUCB0byBnZXQgcGFja2V0 IHRvIGEgQkZFUiBhbmQgdGhlbiBhIEJQIGZvciBkZWNhcHN1bGF0aW9uKS48YnI+Jmd0OyA8YnI+ Jmd0OyBZb3UgZ290IGl0Ljxicj4mZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyBJZiB0aGF0Pz8/cyB0 aGUgY2FzZSwgaXQ/Pz9zIHdvcnRoIHBvaW50IHRoZSBhYm92ZSBvdXQuPGJyPiZndDsgJmd0OyA8 YnI+Jmd0OyAmZ3Q7IEhtbS4uLiBUaGUgbG9naWMgb2YgQkZFUiBCUHMgaXMgdG90YWxseSBpbmRl cGVuZGVudCBvZiB0aGUgbG9naWMgb2YgZm9yd2FyZF9yb3V0ZWQgYWRqYWNlbmN5LCBzbyBpIHdv dWxkIHdvcnJ5IHRoYXQgcmVwZWF0aW5nIHRoZSBleHBsYW5hdGlvbiBvZiBCRkVSIEJQcyB3b3Vs ZCBjb25mbGF0ZSB0aGUgZm9yd2FyZF9yb3V0ZWQgZXhwbGFuYXRpb24uPGJyPiZndDsgJmd0OyA8 YnI+Jmd0OyAmZ3Q7IFp6aCZndDsgSXQncyBqdXN0IHRoYXQgdGhpcyBpcyBhIHBsYWNlIHdoZXJl IGFsbCBraW5kcyBvZiBCUHMgYXJlIHVzZWQgc28gaXQncyBnb29kIHRvIGhhdmUgYSBzdW1tYXJ5 IChjb3VsZCBiZSBhIHN1YnNlY3Rpb24gNC45KS48YnI+Jmd0OyA8YnI+Jmd0OyBZZXMsIGFkZGVk IHN1Y2ggYSBzdW1tYXJ5LiBQbHMuIGNoZWNrLjxicj4mZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyBB Y3R1YWxseSwgdGhlIHJlYXNvbiB0aGF0IEkgdGhvdWdodCB0aGlzIGlzIE1QMlAgaXMgdGhhdCAw OjYgaXMgcHJlc2VudCBvbiBSMSwgUjIsIGFuZCBSMyAoYW5kIG1vcmUgSSBhc3N1bWUpIGluIEZp Z3VyZSAxMiwgYnV0IG5vdyBJIHRoaW5rIGl0IGNhbj8/P3QgYmUgTVAyUCAoc28gaXQgaXMgbm90 IGNvcnJlY3QgdG8gaGF2ZSAwOjYgcHJlc2VudCBvbiB0aG9zZSByb3V0ZXJzID8/PyBvbmx5IHRo ZSBwMnAgdHVubmVsIGhlYWQvdGFpbCBzaG91bGQgaGF2ZSB0aGUgQlAgcHJlc2VudCBpbiB0aGUg QklGVCkuIFRoZSByZWFzb24gaXMgdGhhdCBpZiBpdCB3ZXJlIE1QMlAsIGFueSByb3V0ZXIgZ2V0 dGluZyBhIGNvcHkgd2lsbCBzZW5kIGl0IHRvIHRoZSBlbmRwb2ludCBvZiB0aGUgcm91dGVkIGFk amFjZW5jeSwgY2F1c2luZyBsb3RzIG9mIGR1cGxpY2F0ZXMuLi48YnI+Jmd0OyAmZ3Q7ICZndDsg PGJyPiZndDsgJmd0OyAmZ3Q7IEFtIEkgZ2V0dGluZyB0aGlzIGNvcnJlY3Q/PGJyPiZndDsgJmd0 OyA8YnI+Jmd0OyAmZ3Q7IEkgdGhpbmsgeW91IGFyZSBzdGlsbCBleHBsYWluaW5nIGZyb20gdGhl IG1pc3VuZGVyc3RzYW5kaW5nIHRoYXQgdGhlIEVDTVAgZXhwbGFuYXRpb25zIHdoZXJlIGFib3V0 IHJvdXRlZCBhZGphY2VuY2llcy48YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgSSBoYXZlIG5v dyBleHBhbmRlZCB0aGUgc29tZXdoYXQgdGVyc2UgdGV4dCBpbiB0aGUgQklGVCB0YWJsZSBwaWN0 dXJlcywgdG8gbWFrZSBpdCBjbGVhciB0aGF0IHRoZSBFQ01QIGlzIGFjcm9zcyBtdWx0aXBlIGZv cndhcmRfY29ubmVjdGVkIGFkamFjZW5jaWVzIGluIHRoZSBleGFtcGxlcy4gRm9yIGV4YW1wbGUs IGZpcnN0IEJJRlQgcGljdHVyZTo8YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsmbmJzcDsgJm5i c3A7QklGVCBlbnRyeSBpbiBCRlIxOjxicj4mZ3Q7ICZndDsmbmJzcDsgJm5ic3A7LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PGJyPiZndDsgJmd0OyZuYnNwOyAmbmJzcDt8IEluZGV4IHwmbmJzcDsgQWRqYWNlbmNpZXMmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPiZndDsgJmd0OyZuYnNwOyAm bmJzcDs9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT08YnI+Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwO3wgMDo2Jm5ic3A7ICZuYnNw O3wmbmJzcDsgRUNNUCh7Zm9yd2FyZF9jb25uZWN0ZWQoTDEsIEJGUjIpLCZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8 PGJyPiZndDsgJmd0OyZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBmb3J3YXJkX2Nvbm5lY3RlZChMMiwgQkZSMiksJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IHw8YnI+Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGZvcndhcmRfY29ubmVjdGVkKEwz LCBCRlIyKX0sIHNlZWQpJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7fDxicj4mZ3Q7ICZndDsmbmJzcDsgJm5ic3A7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPiZndDsgJmd0OyA8 YnI+Jmd0OyAmZ3Q7IE9mIGNvdXJzZSwgYW4gRUNNUCBhZGphY2VuY3kgY2FuIGJlIGFjcm9zcyBh bnkgdHlwZSBvZiBhZGphY2VuY2llcywgYnV0IGFsbCB0aGUgdGV4dC9leHBsYW5hdGlvbnMgdXNl ZCBmb3J3YXJkX2Nvbm5lY3RlZCwgYW5kIG5vdyB0aGUgcGljdHVyZXMgc2hvdyB0aGF0IGV4cGxp Y2l0bHkuPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IFp6aCZndDsgSSBjYW4gdW5kZXJzdGFu ZCB0aGUgbXVsdGktbGluayBjYXNlLCBidXQgdGhlIG11bHRpLWhvcCBFQ01QIGNhc2UgKGZyb20g QkZSMSB0b3dhcmRzIEJGUjEwKSBpcyBjb25mdXNpbmcgbWUuIEl0IHdvdWxkIGhlbHAgdG8gZ2l2 ZSBhbiBleGFtcGxlIGhvdyBpdCBjYW4gYmUgdXNlZCwgV0lUSE9VVCB3b3JyeWluZyBhYm91dCBw b2xhcml6YXRpb24uPGJyPiZndDsgPGJyPiZndDsgUGxlYXNlIGNoZWNrIC0wNSB0ZXh0IHRoYXQg aGFzIHRoZSBmdWxsIHNldCBvZiBCSUZUIGxpc3RlZCBub3c6PGJyPiZndDsgPGJyPiZndDsgVGhl cmUgaXMmbmJzcDsgcmVhbGx5IG5vdGhpbmcgbm90aGluZyB1bmlxdWUgaW4gbXVsdGktaG9wIEVD TVAgZm9yIEJJRVItVEUgPGJyPiZndDsgdGhhdCB3ZSBkbyBub3QgYWxzbyBoYXZlIGluIGFueSBv dGhlciBFQ01QLCBleGNlcHQgdGhlIGNvbmNsdXNpb24gdGhhdCA8YnI+Jmd0OyB3ZSB3YW50IHRv IHN1cHBvcnQgZmFzdCBIVyBoYXNoIG1lY2hhbmlzbXMgQU5EIGFsbG93IHRoZSBjb250cm9sbGVy IHRvIDxicj4mZ3Q7IHNldCB1cCBub24tcG9sYXJpemVkIG11bHRpLWhvcCBFQ01QIEFORCBiZSBh YmxlIHRvIHByZWNhbGN1bGF0ZSBwYXRocy4gPGJyPiZndDsgSGVuY2UgdGhlIHNwZWNpZmljYXRp b24gb2YgRUNNUCBhZGphY2VuY2llcyB0byBoYXZlIGEgY29udHJvbGxlciA8YnI+Jmd0OyBjb25m aWd1cmFibGUgc2VlZC48YnI+Jmd0OyA8YnI+Jmd0OyBCdHc6IFRoZSBwaWN0dXJlIGlzIG1heWJl IHVubmVjZXNzYXJpbHkgbGFyZ2UgYmVjYXVzZSBpJ3ZlIHVzZWQgaXQgZm9yIDxicj4mZ3Q7IDIw IHllYXJzIHRvIGV4cGxhaW4gdGhlIHNhbWUgcG9sYXJpemF0aW9uIGlzc3VlIGZvciB1bmljYXN0 IHZzIDxicj4mZ3Q7IG11bHRpY2FzdCwgYW5kIGZvciBtdWx0aWNhc3Qgb25seSBCRlIxMC4uLkJG UjQgYXJlIHJlbGV2YW50IChFQ01QIG9mIDxicj4mZ3Q7IHRoZSBQSU0vbUxEUCBqb2lucyksIHdo ZXJlYXMgZm9yIHVuaWNhc3QvQklFUiBvbmx5PGJyPiZndDsgQkZSMS4uLkJGUjcgYXJlIHJlbGV2 YW50LiBCdXQgYmVpbmcgc3ltbWV0cmljLCB0aGUgcGljdHVyZSBtYWtlcyBpdCA8YnI+Jmd0OyBj bGVhciBpdHMgdGhlIHNhbWUgcHJvYmxlbS48YnI+Jmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsmbmJz cDsgJm5ic3A7IFRvIGluaGliaXQgbG9vcGluZyBpbiB0aGUgZmFjZSBvZiBzdWNoIHBoeXNpY2Fs IG1pc2NvbmZpZ3VyYXRpb24sPGJyPiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyBvbmx5IGZv cndhcmRfY29ubmVjdGVkIGFkamFjZW5jaWVzIGFyZSBwZXJtaXR0ZWQgdG8gaGF2ZSBETlIgc2V0 LCBhbmQ8YnI+Jmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7IHRoZSBsaW5rIGxheWVyIGRlc3Rp bmF0aW9uIGFkZHJlc3Mgb2YgdGhlIGFkamFjZW5jeSAoZS5nLiZuYnNwOyBNQUM8YnI+Jmd0OyAm Z3Q7ICZndDsmbmJzcDsgJm5ic3A7IGFkZHJlc3MpIHByb3RlY3RzIGFnYWluc3QgY2xvc2luZyB0 aGUgbG9vcC4mbmJzcDsgTGluayBsYXllcnMgd2l0aG91dCBwb3J0PGJyPiZndDsgJmd0OyAmZ3Q7 Jm5ic3A7ICZuYnNwOyB1bmlxdWUgbGluayBsYXllciBhZGRyZXNzZXMgc2hvdWxkIG5vdCBiZSB1 c2VkIHdpdGggdGhlIEROUiBmbGFnIHNldC48YnI+Jmd0OyAmZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7 ICZndDsgSXQ/Pz9zIG5vdCBjbGVhciBob3cgbGluayBsYXllciBhZGRyZXNzIGhlbHBzPzxicj4m Z3Q7ICZndDsgPGJyPiZndDsgJmd0OyBJIGhhdmUgZXhwYW5kZWQgdGhpcyB0bzxicj4mZ3Q7ICZn dDsgImxpbmsgbGF5ZXIgcG9ydCB1bmlxdWUgdW5pY2FzdCBkZXN0aW5hdGlvbiBhZGRyZXNzIjxi cj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBBa2E6IE1QTFMgb3IgZXRoZXJuZXQgaGF2ZSB1bmlx dWUgbGluayBsYXllciBkZXN0aW5hdGlvbiBkZXN0aW5hdGlvbiBhZGRyZXNzZXMgKGxhYmVsIG9y IGRlc3RpbmF0aW9uIE1BQykuIElmIHlvdSB0aGluayBhYm91dCBpbmNvcnJlY3RseSBwbHVnZ2Vk IEhETEMgbGlua3MgKHN1Y2ggYXMgb2xkIFQxL1QzLy4uLiBsaW5rcyksIHRoZXkgb25seSBoYXZl IDIgZ2VuZXJpYyBhZGRyZXNzZXMsIGlmIGkgcmVtZW1iZXIgMSBvciAzIGluIHRoZSBIRExDIGZy YW1lLiBTbyB3aGVuIHlvdSBtaXNwbHVnIG9uZSBvZiB0aG9zZSBwMnAgY2FibGVzIHdyb25nLCB0 aGUgcGFja2V0cyB3b3VsZCBiZSBpbmNycmVjdGx5IHJlY2VpdmVkIGJ5IHRoZSB3cm9uZyByZWNl aXZlciBub2RlIGFuZCB0aGVuIEROUiBjb3VsZCBjYXVzZSBwZXJzaXN0ZW50IGxvb3BzIG9ubHkg c29sdmVkIGJ5IFRUTC48YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgWnpoJmd0OyAiQ29uc2lk ZXIgaW4gdGhlIHJpbmcgcGljdHVyZSB0aGF0IGxpbmsgTDQgZnJvbSBCRlIzIGlzIHBsdWdnZWQg aW50byB0aGUgTDEgaW50ZXJmYWNlIG9mIEJGUmEiIC0gc3RpbGwgbm90IHN1cmUgaG93IGxhYmVs L21hYyBoZWxwcyBoZXJlLiBJIHN1cHBvc2UgdGhlIHJpbmcgdG9wb2xvZ3kgaXMgZGlzY292ZXJl ZC92ZXJpZmllZCBieSB0aGUgY29udHJvbCBwbGFuZSBhbmQgd2hlbiB0aGUgbWlzY2FsbGluZyBo YXBwZW5zIHRoZW4gdGhlIHJpbmcgd2lsbCBub3QgaW5jbHVkZSB0aGUgQkZSMS9CRlIyIHBhcnQg YW5kIEJGUjMgd2lsbCBub3QgaGF2ZSB0aGUgRE5SIHNldD8gSWYgcmluZyBkaXNjb3ZlcnkvdmFy aWNhdGlvbiBpcyBub3QgZG9uZSB0aGVuIHBlcmhhcHMgd2Ugc2hvdWxkIHBvaW50IG91dCB0aGF0 IFJQRiBiYXNlZCBvbiBsaW5rIGxheWVyIGFkZHJlc3MgaXMgbmVlZGVkIC0gdGhlIGtleSBpcyBS UEYgKHdoaWNoIG5lZWRzIHVuaXF1ZSBsaW5rIGxheWVyIGFkZHJlc3MpPzxicj4mZ3Q7IDxicj4m Z3Q7IEZvcmdldCBSUEYuIEJJRVIoLVRFKSBoYXMgbm8gUlBGIChpc3N1ZXMpLiBJdHMganVzdCBs aWtlIHVuaWNhc3QuIFJQRiA8YnI+Jmd0OyBpcyBqdXN0IGEgcHJvYmxlbSBmb3IgcmVjZWl2ZXIg b3JpZ2luYXRlZCBqb2lucyBsaWtlIGluIFBJTS9tTERQLCBidXQgPGJyPiZndDsgbm90IHVuaWNh c3QvYmllcigtdGUpL1JTVlAtVEUuPGJyPiZndDsgPGJyPiZndDsgRm9yd2FyZF9jb25uZWN0ZWQg aXMganVzdCBsaWtlIGEgdW5pY2FzdCBzdWJuZXQgYWRqYWNlbmN5IHRvIGEgZGlyZWN0IDxicj4m Z3Q7IG5laWdoYm9yOiBJbnRlcmZhY2UgYW5kIEwyIGFkZHJlc3NzIG9mIHRoZSBkZXN0aW5hdGlv bi48YnI+Jmd0OyA8YnI+Jmd0OyBUaGUgY29udHJvbGxlciAoY291bGQgYmUgYSBodW1hbikgImFz c3VtZXMiIGEgcGFydGljdWxhciBwaHlzaWNpYWwgPGJyPiZndDsgdG9wb2xvZ3ksIGZyb20gdGVs ZW1ldHJ5L2tub3dsZWRnZS93aGF0ZXZlci4gSXQgdGhlbiBjYWxjdWxhdGVzIHRoZSA8YnI+Jmd0 OyBkZXNpcmVkIEJJRVItVEUgdG9wb2xvZ3kgYW5kIHB1c2hlcyBpdCBkb3duLiBUaGlzIHRvcG9s b2d5IGlzIG1lYW50IHRvIDxicj4mZ3Q7IGJlIGxvb3AgZnJlZSBvZiBjb3Vyc2Ugd3J0IHRvIHRo ZSBjb25maWd1cmVkIGFkamFjZW5jaWVzLjxicj4mZ3Q7IEluIHRoaXMgQklFUi1URSB0b3BvbG9n eSwgQkZSMyB3aWxsIGhhdmUgYSBCUCB3aXRoIHRoZSA8YnI+Jmd0OyBmb3J3YXJkX2Nvbm5lY3Rl ZChMNCwgTUFDLW9mLUJGUjIpIGFkamFjZW5jeS48YnI+Jmd0OyA8YnI+Jmd0OyBJZiB0aGUgY2Fi bGUgY29ubmVjdGluZyB0byBMNCBpcyBtaXN3aXJlZCwgdGhlbiBCRlIzIHdvdWxkIHN0aWxsIHNl bmQgPGJyPiZndDsgdGhlIHBhY2tldHMgdG8gdGhlIE1BQyBhZGRyZXNzIG9mIEJGUjIsIGJ1dCBn aXZlbiBob3cgdGhlIGNhYmxlIDxicj4mZ3Q7IGNvbm5lY3RzIHRvIHNvbWUgb3RoZXIgbm9kZSwg dGhlc2UgcGFja2V0cyB3aWxsIGJlIGRpc2NhcmRlZCBieSB0aGF0IDxicj4mZ3Q7IG5vZGUuIGJl Y2F1c2UgdGhleSdyZSBqdXN0IEwyIHVuaWNhc3QgcGFja2V0cy48YnI+Jmd0OyA8YnI+Jmd0OyBJ IHRoaW5rIHRoaXMgaXMgZXF1YWxseSB0cnVlIHdoZW4gd2UgaGF2ZSBub3JtYWwgQklFUi9NUExT IGVuYWNwLjxicj4mZ3Q7IFRob3NlIHBhY2tldHMgdG9vIGFyZSBhZGRyZXNzZWQgdG8gdGhlIHVu aWNhc3QgTUFDIGFkZHJlc3Mgb2YgdGhlIDxicj4mZ3Q7IG5laWdoYm9yLjxicj4mZ3Q7IDxicj4m Z3Q7IE5vdywgaWYvd2hlbiBoZSBjb250cm9sbGVyIHJlY29nbml6ZXMgdGhhdCB0aGUgcGh5c2lj YWwgdG9wb2xvZ3kgaGFzIDxicj4mZ3Q7IGNoYW5nZWQsIHRoYXRzIGEgY29tcGxldGVseSBkaWZm ZXJlbnQgc3RvcnkgYW5kIG5vdCBhZGRyZXNzZWQgaGVyZS4gPGJyPiZndDsgR2l2ZW4gaG93IHdl IGFzc3VtZWQgdGhpcyB3YXMgYSBjYWJsaW5nIG1pc3Rha2UsIHRoZSBjb250cm9sbGVyIHdvdWxk IDxicj4mZ3Q7IHByb2JhYmx5IG9ubHkgY29tcGxhaW4gYWJvdXQgdGhlIG1pc3dpcmluZyB0byBv cGVyYXRpb25zIGJ1dCBiZSBoYXBweSA8YnI+Jmd0OyB0aGF0IHRoZSBmb3J3YXJkaW5nIHBsYW5l IGp1c3QgbWFrZXMgcGFja2V0cyBmYWlsIGluc3RlYWQgb2YgbG9vcC4gSWYgPGJyPiZndDsgdGhp cyB3YXMgYSBwbGFubmVkIGNoYW5nZSBwcm9jZXNzLCB0aGVuIGl0IHdpbGwgYmUgc2ltaWxhcmls eSA8YnI+Jmd0OyBjb252b2x1dGVkIGFzIGl0IHdvdWxkIHRvZGF5IGJlIHdpdGggcmV3aXJpbmcg Y2FibGVzIGluIGFuIDxicj4mZ3Q7IFNSLU1QTFMvU1J2NiB0b3BvbG9neSBhbmQgdXBkYXRpbmcg U0lEcy48YnI+Jmd0OyA8YnI+Jmd0OyAmZ3Q7ICZndDsgQmVjYXVzZSB0aGUgZm9yd2FyZGluZyBp cyBkaWZmZXJlbnQgZnJvbSBCSUVSIGZvcndhcmRpbmcgKGJlY2F1c2Ugb2YgWzFdIGFib3ZlKSwg d2UgbWlnaHQgYXMgd2VsbCBpbnRyb2R1Y2UgYW4gb3B0aW1pemF0aW9uIGhlcmUgPz8/IGZvciBl YWNoIEJJRlQsIGNhbGN1bGF0ZSB0aGUgRi1CTSBvZiB0aGUgQklGVCBpdHNlbGYgKHRoZSBsb2dp Y2FsID8/P29yPz8/IG9mIGFsbCB0aGUgQlBzIHByZXNlbnRlZCBpbiB0aGlzIEJJRlQpIGFuZCB0 aGVuIHVzZSAocGFja2V0LSZndDtiaXRzdHJpbmcgJmFtcDsgQklGVC5GLUJNKSBhcyB0aGUgaW5w dXQgdG8gR2V0Rmlyc3QvTmV4dEJpdFBvc2l0aW9uKCkuIFRoYXQgc2hvdWxkIHNraXAgbWFueSBi aXRzLjxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBSaWdodC4gQnV0IGkgZXhwbGljaXRseSBy ZW1vdmVkIHRob3NlIG9wdGltaXphdGlvbnMgKGkgaGFkIHRoZW0gaW4gb2xkZXIgZHJhZnQgdmVy c2lvbnMpIGJlY2F1c2UgdGhlIHdob2xlIGlkZWEgb2YgdGhpcyBwaWN0dXJlIGlzIHNvbGVseSB0 aGUgY29tcGFyaXNvbiB3aXRoIGZpZ3VyZSA0IG9mIFJGQzgyNzkuPGJyPiZndDsgJmd0OyA8YnI+ Jmd0OyAmZ3Q7IFp6aCZndDsgSSB0aGluayBpdCdzIHdvcnRoIHBvaW50IHRoYXQgb3B0aW1pemF0 aW9uIG91dDsgeW91IGNhbiBtYXJrIGl0IG9wdGlvbmFsIGlmIHlvdSB3YW50IHRvIGVtcGhhc2l6 ZSB0aGUgc2ltaWxhcml0eSB0byBCSUVSIGZvcndhcmRpbmcsIGJ1dCBzaW5jZSBCSUVSIGZvcndh cmRpbmcgZG9lcyBkbyB0aGUgbWFza29mZiBzdGVwLCBpdCBpcyB2ZXJ5IGVmZmljaWVudCB3aGls ZSBCSUVSLVRFIGZvcndhcmRpbmcgZG9lcyBub3QgaXQgdGhlIG1hc2tvZmYgc3RlcCBzbyB0aGlz IG9wdGltaXphdGlvbiBpcyBpbXBvcnRhbnQuPGJyPiZndDsgPGJyPiZndDsgT2suIEkgc2ltcGxp ZmllZCB0aGUgdGV4dCBjb21wYXJpc29uIEJJRVIvQklFUi1URSB3cnQuIHRvIHRoZSBGQk0gPGJy PiZndDsgcnVsZXMgWzFdIGFuZCBbMl0gYW5kIGFkZGVkIGZvbGxvd2luZyBwYXJhZ3JhcGg6PGJy PiZndDsgPGJyPiZndDsgJmx0O3QmZ3Q7SW4gQklFUiwgdGhlIG9yZGVyIG9mIEJQcyBpbXBhY3Rz IHRoZSByZXN1bHQgb2YgZm9yd2FyZGluZyBiZWNhdXNlIG9mIFsxXS4gPGJyPiZndDsgSW4gQklF Ui1URSwgZm9yd2FyZGluZyBpcyBub3QgaW1wYWN0ZWQgYnkgdGhlIG9yZGVyIG9mIEJQcy4gSXQg aXMgPGJyPiZndDsgdGhlcmVmb3JlIHBvc3NpYmxlIHRvIGZ1cnRoZXIgb3B0aW1pemUgZm9yd2Fy ZGluZyB0aGFuIGluIEJJRVIuIEZvciA8YnI+Jmd0OyBleGFtcGxlIHBhcmFsbGVsaXppbmcgZm9y d2FyZGluZyBhY3Jvc3MgbXVsdGlwbGUgRlBFIGNvcmVzIG9yIDxicj4mZ3Q7IGRpc3RyaWJ1dGVk IGxpbmVjYXJkcyBkb2VzIG9ubHkgbmVlZCB0byBleGFtaW5lIGFuIGFyYml0cmFyeSBzdWJzZXQg b2YgPGJyPiZndDsgQlAgYW5kIG5vdCBldmFsdWF0ZSB0aGUgZGVwZW5kZW5jeSBiZXR3ZWVuIEJQ cy4mbHQ7L3QmZ3Q7PGJyPiZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyBUaGUg Zm9sbG93aW5nIHBzZXVkb2NvZGUgaXMgY29tcHJlaGVuc2l2ZTo8YnI+Jmd0OyAmZ3Q7ICZndDsg PGJyPiZndDsgJmd0OyAmZ3Q7IFRoZSBhYm92ZSBzZW50ZW5jZSByZWFkcyBhIGJpdCBzdHJhbmdl IChvciBsYWNrcyBzb21lIHNlZ3VlKS4uLjxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyBJIGhv cGUgbm90LCBidXQgbWF5YmUgYmVzdCBsZWZ0IHRvIGEgbmF0aXZlIGVuZ2xpc2ggc3BlYWtlciAo UkZDLWVkaXRvcikuPGJyPiZndDsgJmd0OyA8YnI+Jmd0OyAmZ3Q7IFRoZSBmaXJzdCAoUkZDODI3 OSkgcHNldWRvY29kZSB3YXMgc2ltcGxpZmllZC4gVGhlIHNlY29uZCBvbmUgaXMgY29tcHJlaGVu c2l2ZS4gSWYgbm90IGNvbXByZWhlbnNpdmUsIHdoYXRzIGEgZ29vZCBvcHBvc2l0ZSBvZiBzaW1w bGlmaWVkID88YnI+Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgWnpoJmd0OyBQZXJoYXBzICJUaGUg YWJvdmUgc2ltcGxpZmllZCBwc2V1ZG9jb2RlIGlzIGVsYWJvcmF0ZWQgZnVydGhlciBhcyBmb2xs b3dpbmciPzxicj4mZ3Q7ICZndDsgWnpoJmd0OyBKZWZmcmV5PGJyPiZndDsgPGJyPiZndDsgRG9u ZS48YnI+Jmd0OyA8YnI+Jmd0OyBUaGFua3MgYSBsb3QuIDxicj4mZ3Q7IDxicj4mZ3Q7IDxicj4m Z3Q7ICZndDsmbmJzcDsgJm5ic3A7IDxicj4mZ3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsgJmd0OyAmZ3Q7IEZyb206IEJJRVIgWzxh IGhyZWY9Im1haWx0bzpiaWVyLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5iaWVy LWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86Ymllci1ib3Vu Y2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Ymllci1ib3VuY2VzQGlldGYub3JnPC9hPiZn dDtdIDxicj4mZ3Q7ICZndDsgJmd0OyBvbiBiZWhhbGYgb2YgVG9lcmxlc3MgRWNrZXJ0IFs8YSBo cmVmPSJtYWlsdG86dHRlQGNzLmZhdS5kZSIgdGFyZ2V0PSJfYmxhbmsiPnR0ZUBjcy5mYXUuZGU8 L2E+Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86dHRlQGNzLmZhdS5kZSIgdGFyZ2V0PSJfYmxh bmsiPnR0ZUBjcy5mYXUuZGU8L2E+Jmd0O108YnI+Jmd0OyAmZ3Q7ICZndDsgU2VudDogVHVlc2Rh eSwgSnVseSAwOSwgMjAxOSAyMzozODxicj4mZ3Q7ICZndDsgJmd0OyBUbzogTWlrZSBNY0JyaWRl PGJyPiZndDsgJmd0OyAmZ3Q7IENjOiBHcmVnIFNoZXBoZXJkOyBCSUVSIFdHOyBQYXNjYWwgVGh1 YmVydCAocHRodWJlcnQpPGJyPiZndDsgJmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbQmllcl0gV0dM QyAtIGRyYWZ0LWlldGYtYmllci10ZS1hcmNoPGJyPiZndDsgJmd0OyAmZ3Q7IDxicj4mZ3Q7ICZn dDsgJmd0OyBUaGFua3MsIE1pa2U8YnI+Jmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7 IFRoZSBhdXRob3JzIGFsc28gcmV2aWV3ZWQgdGhlIGRvY3VtZW50IGFuZCBjb25jbHVkZWQgdGhh dCBpdCB3YXMgPGJyPiZndDsgJmd0OyAmZ3Q7IHJlYWxseSBoYXJkIHRvIGdldCBpbnRvIHRoZSBk b2N1bWVudCBjb250ZXh0IGJlY2F1c2Ugb2YgdG9vIG1hbnkgPGJyPiZndDsgJmd0OyAmZ3Q7IGZv cndhcmQgZGVwZW5kZW5jaWVzLiBXZSB0cmllZCB0byBmaXggdGhpcyBieSBhZGRpbmcgdHdvIGhv cGVmdWxseSA8YnI+Jmd0OyAmZ3Q7ICZndDsgZ29vZCAmYW1wOyBiYXNpYyBleGFtcGxlcyBpbnRv IHRoZSBJbnRyb2R1Y3Rpb24gc2VjdGlvbiBhbmQgdXNpbmcgdGhlbSA8YnI+Jmd0OyAmZ3Q7ICZn dDsgdG8gYWxzbyBhZGQgYSBiZXR0ZXIgZGVmaW5pdGlvbiBvZiB0aGUgdGVybSAiQklFUi1URSBU b3BvbG9neSIgaW4gdGhlIEludHJvZHVjdGlvbi48YnI+Jmd0OyAmZ3Q7ICZndDsgSG9wZWZ1bGx5 IHRoaXMgbWFrZXMgcmVhZGluIHRoZSByZXN0IG9mIHRlIGRvY3VtZW50IHNtb290aGVyLi4uPGJy PiZndDsgJmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyBBbHNvIGltcHJvdmVkIHRleHQgb2Yg QWJzdHJhY3QgYW5kIHJlZmluZWQgdGV4dCBjb21wYXJpaW5nIEJJRVItVEUgd2l0aCBTUi48YnI+ Jmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVm ZW5zZS5jb20vdjMvX19odHRwOi8vdG9vbHMuaWV0Zi5vcmcvKnJmY2RpZmY/dXJsMT1odHRwcyIg cmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92 My9fX2h0dHA6Ly90b29scy5pZXRmLm9yZy8qcmZjZGlmZj91cmwxPWh0dHBzPC9hPjo8YnI+Jmd0 OyAmZ3Q7ICZndDsgKio8YSBocmVmPSJodHRwOi8vQXRvb2xzLmlldGYub3JnIiByZWw9Im5vcmVm ZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5BdG9vbHMuaWV0Zi5vcmc8L2E+KmlkKmRyYWZ0LWlldGYt Ymllci10ZS1hcmNoLTAyLnR4dCZhbXA7dXJsMj1odHRwczoqKkE8YnI+Jmd0OyAmZ3Q7ICZndDsg dG9vbDxicj4mZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJodHRwOi8vcy5pZXRmLm9yZyIgcmVsPSJu b3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+cy5pZXRmLm9yZzwvYT4qaWQqZHJhZnQtaWV0Zi1i aWVyLXRlLWFyY2gtMDMudHh0X187THk4dkx5OHZMeTh2IThXb0E2Ujxicj4mZ3Q7ICZndDsgJmd0 OyBqQzgxIDxicj4mZ3Q7ICZndDsgJmd0OyBjIVh2SDRBQXhmckRqRm9LX3NlcmN3Wk1zYzBPNU40 MmVFTk9zNGxfcWRzWEYwS3daRDgyY0pMREZGTlZfZVRVRWg8YnI+Jmd0OyAmZ3Q7ICZndDsgJDxi cj4mZ3Q7ICZndDsgJmd0OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9f X2h0dHA6L3Rvb2xzLmlldGYub3JnLypyZmNkaWZmP3VybDE9aHR0cHMiIHJlbD0ibm9yZWZlcnJl ciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwOi90b29s cy5pZXRmLm9yZy8qcmZjZGlmZj91cmwxPWh0dHBzPC9hPjo8YnI+Jmd0OyAmZ3Q7ICZndDsgKio8 YSBocmVmPSJodHRwOi8vQXRvb2xzLmlldGYub3JnIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0i X2JsYW5rIj5BdG9vbHMuaWV0Zi5vcmc8L2E+KmlkKmRyYWZ0LWlldGYtYmllci10ZS1hcmNoLTAy LnR4dCZhbXA7dXJsMj1odHRwczoqKkE8YnI+Jmd0OyAmZ3Q7ICZndDsgdG9vbDxicj4mZ3Q7ICZn dDsgJmd0OyA8YSBocmVmPSJodHRwOi8vcy5pZXRmLm9yZyIgcmVsPSJub3JlZmVycmVyIiB0YXJn ZXQ9Il9ibGFuayI+cy5pZXRmLm9yZzwvYT4qaWQqZHJhZnQtaWV0Zi1iaWVyLXRlLWFyY2gtMDMu dHh0X187THk4dkx5OHZMeTh2IThXb0E2Ujxicj4mZ3Q7ICZndDsgJmd0OyBqQzgxIDxicj4mZ3Q7 ICZndDsgJmd0OyBjIVVCVEd2V1dwTUh5ZWlTYW54czZ2SWJfRW5CVmd5ZzZib0FBVzRucnFqdThV Q0xPZ2l1WGM4WV82c05kMW5qY1g8YnI+Jmd0OyAmZ3Q7ICZndDsgJCZndDs8YnI+Jmd0OyAmZ3Q7 ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IENoZWVyczxicj4mZ3Q7ICZndDsgJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7VG9lcmxlc3M8YnI+Jmd0OyAmZ3Q7ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7 IE9uIFdlZCwgSnVuIDI2LCAyMDE5IGF0IDEwOjM5OjM2QU0gLTA3MDAsIE1pa2UgTWNCcmlkZSB3 cm90ZTo8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBIb3cgYWJvdXQgdGhyZWU/IEkgc3VwcG9ydC48 YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyBtaWtlPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OyBPbiBUdWUsIEp1biAyNSwgMjAxOSBhdCAxMDo0MiBBTSBHcmVnIFNo ZXBoZXJkICZsdDs8YSBocmVmPSJtYWlsdG86Z2pzaGVwQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPmdqc2hlcEBnbWFpbC5jb208L2E+Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86Z2pzaGVw QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdqc2hlcEBnbWFpbC5jb208L2E+Jmd0OyZndDsg d3JvdGU6PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgV2UgY2Fubm90IHRha2UgdHdvICd5ZXMnIHZvdGVzIGFuZCBXRyBjb25zZW5zdXMuPGJy PiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBQbGVhc2UsIHJlYWQgYW5kIHJlc3BvbmQuIElmIHlv dSBkb24ndCBzdXBwb3J0LCB0aGVuIHBsZWFzZSB2b3RlIGFzIG11Y2ggcHVibGljbHkgcmlnaHQg aGVyZS48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyBUaGFua3MsPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBHcmVnPGJyPiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgT24gTW9uLCBKdW4g MywgMjAxOSBhdCAxMDowNSBQTSBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpICZsdDs8YSBocmVm PSJtYWlsdG86cHRodWJlcnRAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+cHRodWJlcnRAY2lz Y28uY29tPC9hPiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPnB0aHViZXJ0QGNpc2NvLmNvbTwvYT4mZ3Q7Jmd0OyB3cm90ZTo8YnI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsm Z3Q7IFN1cHBvcnQ6PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7Jmd0OyBJIHNlZSBncmVhdCB2YWx1ZSBpbiBkZXRlcm1pbmlzdGljIG5l dHdvcmtzIGFzIHdlbGwgYXMgSU9UICh3aXRoIFJQTCkuPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyBBbGwgdGhlIGJlc3QsPGJy PiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDs8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7 Jmd0OyBQYXNjYWw8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0Ozxicj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IEZyb206IEJJRVI8YnI+Jmd0OyAmZ3Q7ICZn dDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Ymllci1ib3VuY2VzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Ymllci1ib3VuY2VzQGlldGYub3JnPC9hPiZsdDttYWls dG86PGEgaHJlZj0ibWFpbHRvOmJpZXItYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PmJpZXItYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7Jmd0OyBPbiA8YnI+Jmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7IEJlaGFsZiBPZiBUb2VybGVzcyBFY2tlcnQ8YnI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IFNlbnQ6IG1hcmRpIDQganVpbiAyMDE5IDAyOjAzPGJy PiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyBUbzogR3JlZyBTaGVwaGVyZCA8YnI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Z2pz aGVwQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdqc2hlcEBnbWFpbC5jb208L2E+Jmx0O21h aWx0bzo8YSBocmVmPSJtYWlsdG86Z2pzaGVwQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdq c2hlcEBnbWFpbC5jb208L2E+Jmd0OyZndDs8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0 OyAmZ3Q7IENjOiBCSUVSIFdHICZsdDs8YSBocmVmPSJtYWlsdG86YmllckBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPmJpZXJAaWV0Zi5vcmc8L2E+Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 YmllckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJpZXJAaWV0Zi5vcmc8L2E+Jmd0OyZndDs8 YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IFN1YmplY3Q6IFJlOiBbQmllcl0g V0dMQyAtIGRyYWZ0LWlldGYtYmllci10ZS1hcmNoPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgKzE8YnI+Jmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IE9idmlvdXNseSBzdXBwb3J0IGFzIGNvLWF1 dGhvci48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyZndDsgJmd0OyBPbiBXZWQsIE1heSAyOSwgMjAxOSBhdCAxMjo0MToyNlBN IC0wNzAwLCBHcmVnIFNoZXBoZXJkIHdyb3RlOjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsm Z3Q7ICZndDsgJmd0OyBQbGVhc2UgcmVhZCBhbmQgcmVzcG9uZCB0byB0aGlzIHRocmVhZCB3LyBv ciB3L28gc3VwcG9ydC48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDs8 YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6 Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmciIHJlbD0i bm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19o dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnPC9hPjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsmZ3Q7ICZndDsgJmd0OyAvZG9jIDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZn dDsgJmd0OyAvZHJhZnQtaWV0Zi1iaWVyLXRlLWFyY2gvX187IThXb0E2UmpDODFjIVh2SDRBQXhm ckRqRm9LX3M8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgZXJjdyBa TXNjME81TjQyZUVOT3M0bF9xZHNYRjBLd1pEODJjSkxERkZOVjllQ2xCaiQ8YnI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVm ZW5zZS5jb20vdjMvX19odHRwczovZGF0YXRyYWNrZXIuaWV0Zi5vcmcvIiByZWw9Im5vcmVmZXJy ZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L2Rh dGF0cmFja2VyLmlldGYub3JnLzwvYT48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAm Z3Q7ICZndDsgZG9jLyA8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsg ZHJhZnQtaWV0Zi1iaWVyLXRlLWFyY2gvX187IThXb0E2UmpDODFjIVVCVEd2V1dwTUh5ZWlTYW54 PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAmZ3Q7IHM2dkkgYl9FbkJWZ3ln NmJvQUFXNG5ycWp1OFVDTE9naXVYYzhZXzZzRDQwa210SCQmZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OyZndDsgJmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsg Jmd0OyAmZ3Q7IFZvdGUgZW5kcyA1IEp1bmUgMjAxOS48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7Jmd0OyAmZ3Q7ICZndDs8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZn dDsgVGhhbmtzLDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyBTaGVw PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAmZ3Q7IChjaGFpcnMpPGJyPiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsmZ3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyBCSUVSIG1h aWxpbmcgbGlzdDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyA8YSBo cmVmPSJtYWlsdG86QklFUkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkJJRVJAaWV0Zi5vcmc8 L2E+Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86QklFUkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPkJJRVJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7 ICZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi8iIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuLzwv YT48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgbGlzdDxicj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyBpbmZvL2JpZXJfXzshOFdvQTZSakM4 MWMhWHZINEFBeGZyRGpGb0tfc2VyY3daTXNjME81TjQyZUU8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgTk9zNCBsX3Fkc1hGMEt3WkQ4MmNKTERGRk5UMldWWFdYJCA8 YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgJmx0OzxhIGhyZWY9Imh0 dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovd3d3LmlldGYub3JnL21haWxtYW4vIiBy ZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3VybGRlZmVuc2UuY29tL3Yz L19faHR0cHM6L3d3dy5pZXRmLm9yZy9tYWlsbWFuLzwvYT48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgbGlzdCA8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0 OyAmZ3Q7ICZndDsgaW5mby9iaWVyX187IThXb0E2UmpDODFjIVVCVEd2V1dwTUh5ZWlTYW54czZ2 SWJfRW5CVmd5ZzZiPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAmZ3Q7IG9B QVcgNG5ycWp1OFVDTE9naXVYYzhZXzZzS24yS29BVCQmZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyZndDsgJmd0Ozxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IEJJRVIgbWFpbGluZyBsaXN0PGJyPiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86QklFUkBpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPkJJRVJAaWV0Zi5vcmc8L2E+Jmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86 QklFUkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkJJRVJAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4m Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZl bnNlLmNvbS92My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGkiIHJlbD0ibm9yZWZl cnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpPC9hPjxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsm Z3Q7ICZndDsgc3RpbiA8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IGZvL2Jp ZXJfXzshOFdvQTZSakM4MWMhWHZINEFBeGZyRGpGb0tfc2VyY3daTXNjME81TjQyZUVOT3M0PGJy PiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyBsX3FkPGJyPiZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OyZndDsgJmd0OyBzWEYwS3daRDgyY0pMREZGTlQyV1ZYV1gkPGJyPiZndDsgJmd0 OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl LmNvbS92My9fX2h0dHBzOi93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saSIgcmVsPSJub3JlZmVycmVy IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saTwvYT48YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAm Z3Q7IHN0aW4gPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyBmby9iaWVyX187 IThXb0E2UmpDODFjIVVCVEd2V1dwTUh5ZWlTYW54czZ2SWJfRW5CVmd5ZzZib0FBVzxicj4mZ3Q7 ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgNG5ycTxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsmZ3Q7ICZndDsganU4VUNMT2dpdVhjOFlfNnNLbjJLb0FUJCZndDs8YnI+Jmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgQklFUiBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDxhIGhy ZWY9Im1haWx0bzpCSUVSQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+QklFUkBpZXRmLm9yZzwv YT4mbHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpCSUVSQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+QklFUkBpZXRmLm9yZzwvYT4mZ3Q7PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyA8YSBo cmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuLi5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Vy bGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aTwvYT48 YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IG5mby8gPGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyBiaWVyX187IThXb0E2UmpDODFjIVh2SDRBQXhmckRqRm9LX3NlcmN3Wk1zYzBPNU40MmVF Tk9zNGxfcWRzWDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgRjBLdzxicj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgWkQ4MmNKTERGRk5UMldWWFdYJDxicj4mZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGkiIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGk8L2E+PGJyPiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBuZm8vIDxicj4mZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsgYmllcl9fOyE4V29BNlJqQzgxYyFVQlRHdldXcE1IeWVpU2FueHM2dkli X0VuQlZneWc2Ym9BQVc0bnJxanU8YnI+Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IDhVQ0w8YnI+ Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IE9naXVYYzhZXzZzS24yS29BVCQmZ3Q7PGJyPiZndDsg Jmd0OyAmZ3Q7IDxicj4mZ3Q7ICZndDsgJmd0OyAtLTxicj4mZ3Q7ICZndDsgJmd0OyAtLS08YnI+ Jmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOnR0ZUBjcy5mYXUuZGUiIHRhcmdldD0iX2Js YW5rIj50dGVAY3MuZmF1LmRlPC9hPiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnR0ZUBjcy5m YXUuZGUiIHRhcmdldD0iX2JsYW5rIj50dGVAY3MuZmF1LmRlPC9hPiZndDs8YnI+Jmd0OyAmZ3Q7 ICZndDsgPGJyPiZndDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPiZndDsgJmd0OyAmZ3Q7IEJJRVIgbWFpbGluZyBsaXN0PGJyPiZn dDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpCSUVSQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+QklFUkBpZXRmLi4ub3JnPC9hPiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOkJJRVJAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5CSUVSQGlldGYub3JnPC9hPiZndDs8YnI+Jmd0OyAmZ3Q7 ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby88L2E+PGJyPiZndDsgJmd0OyAmZ3Q7IGJpZXIgPGJyPiZndDsgJmd0OyAmZ3Q7 IF9fOyE4V29BNlJqQzgxYyFYdkg0QUF4ZnJEakZvS19zZXJjd1pNc2MwTzVONDJlRU5PczRsX3Fk c1hGMEt3WkQ4Mjxicj4mZ3Q7ICZndDsgJmd0OyBjSkxEPGJyPiZndDsgJmd0OyAmZ3Q7IEZGTlQy V1ZYV1gkPGJyPiZndDsgJmd0OyAmZ3Q7ICZsdDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2Uu Y29tL3YzL19faHR0cHM6L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLyIgcmVsPSJub3Jl ZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBz Oi93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby88L2E+PGJyPiZndDsgJmd0OyAmZ3Q7IGJp ZXIgPGJyPiZndDsgJmd0OyAmZ3Q7IF9fOyE4V29BNlJqQzgxYyFVQlRHdldXcE1IeWVpU2FueHM2 dkliX0VuQlZneWc2Ym9BQVc0bnJxanU4VUNMT2dpdTxicj4mZ3Q7ICZndDsgJmd0OyBYYzhZPGJy PiZndDsgJmd0OyAmZ3Q7IF82c0tuMktvQVQkJmd0Ozxicj4mZ3Q7ICZndDsgPGJyPiZndDsgJmd0 OyAtLTxicj4mZ3Q7ICZndDsgLS0tPGJyPiZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86dHRlQGNz LmZhdS5kZSIgdGFyZ2V0PSJfYmxhbmsiPnR0ZUBjcy5mYXUuZGU8L2E+PGJyPiZndDsgPGJyPiZn dDsgLS08YnI+Jmd0OyAtLS08YnI+Jmd0OyA8YSBocmVmPSJtYWlsdG86dHRlQGNzLmZhdS5kZSIg dGFyZ2V0PSJfYmxhbmsiPnR0ZUBjcy5mYXUuZGU8L2E+PGJyPiZndDsgPGJyPiZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Jmd0OyBCSUVSIG1h aWxpbmcgbGlzdDxicj4mZ3Q7IDxhIGhyZWY9Im1haWx0bzpCSUVSQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+QklFUkBpZXRmLm9yZzwvYT48YnI+Jmd0OyA8YSBocmVmPSJodHRwczovL3VybGRl ZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iaWVy IiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3VybGRlZmVuc2UuY29t L3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iaWVyPC9hPjxicj4m Z3Q7IF9fOyEhTkV0NnlNYU8tZ2shVnVRQ1ZIbnFKeV9hWUktRk50OUExYTVFekhPQ3IwZlprTFBi Z2czQ1BOdTBQeXJXc3JGeDQ8YnI+Jmd0OyAxX2pXVjNZVUE2RCQ8YnI+PGJyPi0tPGJyPi0tLTxi cj48YSBocmVmPSJtYWlsdG86dHRlQGNzLmZhdS5kZSIgdGFyZ2V0PSJfYmxhbmsiPnR0ZUBjcy5m YXUuZGU8L2E+PGJyPjxicj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzxicj5CSUVSIG1haWxpbmcgbGlzdDxicj48YSBocmVmPSJtYWlsdG86QklFUkBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkJJRVJAaWV0Zi5vcmc8L2E+PGJyPjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmllciIgcmVsPSJub3JlZmVycmVyIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iaWVy PC9hPjxicj48L2Jsb2NrcXVvdGU+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+ PC9kaXY+PC9kaXY+PHA+PGJyPjwvcD48L2Rpdj4= --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Tue Feb 18 23:51:44 2020 Return-Path: X-Original-To: bier@ietf.org Delivered-To: bier@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A9D1200D8; Tue, 18 Feb 2020 23:51:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: bier@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: bier@ietf.org Message-ID: <158209870216.19201.8088693167855623153@ietfa.amsl.com> Date: Tue, 18 Feb 2020 23:51:42 -0800 Archived-At: Subject: [Bier] I-D Action: draft-ietf-bier-oam-requirements-09.txt X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 07:51:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bit Indexed Explicit Replication WG of the IETF. Title : Operations, Administration and Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer Authors : Greg Mirsky Carlos Pignataro Nagendra Kumar Mach Chen Santosh Pallagatti Filename : draft-ietf-bier-oam-requirements-09.txt Pages : 6 Date : 2020-02-18 Abstract: This document describes a list of functional requirement toward Operations, Administration and Maintenance (OAM) toolset in Bit Index Explicit Replication (BIER) layer of a network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bier-oam-requirements/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bier-oam-requirements-09 https://datatracker.ietf.org/doc/html/draft-ietf-bier-oam-requirements-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bier-oam-requirements-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 19 00:10:14 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEEDF1200E3; Wed, 19 Feb 2020 00:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 4t2KBOzFLvtT; Wed, 19 Feb 2020 00:10:09 -0800 (PST) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03E9D1200D8; Wed, 19 Feb 2020 00:10:08 -0800 (PST) Received: from mxct.zte.com.cn (unknown [192.168.164.215]) by Forcepoint Email with ESMTPS id 3728BD243CAAF01C35A4; Wed, 19 Feb 2020 16:10:06 +0800 (CST) Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id 0D4FD2B9EA744C3E3AB8; Wed, 19 Feb 2020 16:10:06 +0800 (CST) Received: from njxapp03.zte.com.cn ([10.41.132.202]) by mse-fl2.zte.com.cn with SMTP id 01J89Rr7094686; Wed, 19 Feb 2020 16:09:27 +0800 (GMT-8) (envelope-from xiong.quan@zte.com.cn) Received: from mapi (njxapp05[null]) by mapi (Zmail) with MAPI id mid201; Wed, 19 Feb 2020 16:09:26 +0800 (CST) Date: Wed, 19 Feb 2020 16:09:26 +0800 (CST) X-Zmail-TransId: 2afd5e4ced3695a0c8b8 X-Mailer: Zmail v1.0 Message-ID: <202002191609264128704@zte.com.cn> Mime-Version: 1.0 From: To: , Cc: , , Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-fl2.zte.com.cn 01J89Rr7094686 Archived-At: Subject: [Bier] =?utf-8?q?=5BBIER=5D_New_Version_Notification_for_draft-h?= =?utf-8?q?u-bier-bfd-05=2Etxt?= X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 08:10:12 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 RGVhciBDaGFpcnMgYW5kIGFsbCwNCg0KDQoNCg0KDQoNClRoZSBuZXcgdmVyc2lvbiBvZiBkcmFm dC1odS1iaWVyLWJmZC0wNSBoYXMgYmVlbiB1cGxvYWRlZC4gVGhpcyBkcmFmdCBoYXMgYmVlbiBk aXNjdXNzZWQgbWFueSB0aW1lcyBpbiBJRVRGIG1lZXRpbmcgYW5kICBtYWlsaW5nIGxpc3QuIFRo ZSBhdXRob3JzIGFwcHJlY2lhdGUgbW9yZSBmZWVkYmFja3MuIFlvdXIgY29tbWVudHMgYW5kIHN1 Z2dlc3Rpb25zIGFyZSB2ZXJ5IHdlbGNvbWUhDQoNCg0KDQoNCg0KDQpCZXN0IFJlZ2FyZHMsDQoN Cg0KUXVhbg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt aHUtYmllci1iZmQtMDUudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFF1 YW4gWGlvbmcgYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAg ICAgIGRyYWZ0LWh1LWJpZXItYmZkDQpSZXZpc2lvbjogICAgMDUNClRpdGxlOiAgICAgICAgQklF UiBCRkQNCkRvY3VtZW50IGRhdGU6ICAgIDIwMjAtMDItMTcNCkdyb3VwOiAgICAgICAgSW5kaXZp ZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgIDEwDQpVUkw6ICAgICAgICAgICAgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWh1LWJpZXItYmZkLTA1LnR4dA0K U3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1 LWJpZXItYmZkLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1odS1iaWVyLWJmZC0wNQ0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaHUtYmllci1iZmQNCkRpZmY6ICAgICAgICAgICBodHRw czovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaHUtYmllci1iZmQtMDUNCg0KQWJz dHJhY3Q6DQogICBQb2ludCB0byBtdWx0aXBvaW50IChQMk1QKSBCRkQgaXMgZGVzaWduZWQgdG8g dmVyaWZ5IG11bHRpcG9pbnQNCiAgIGNvbm5lY3Rpdml0eS4gIFRoaXMgZG9jdW1lbnQgc3BlY2lm aWVzIHRoZSBhcHBsaWNhdGlvbiBvZiBQMk1QIEJGRCBpbg0KICAgQklFUiBuZXR3b3JrLg0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwg dGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRm Lm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ= --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxkaXY+PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxw IHN0eWxlPSJmb250LXNpemU6MjBweDtmb250LWZhbWlseTphcmlhbDsiPkRlYXIgQ2hhaXJzIGFu ZCBhbGwsPC9wPjxwIHN0eWxlPSJmb250LXNpemU6MjBweDtmb250LWZhbWlseTphcmlhbDsiPjxi cj48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToyMHB4O2ZvbnQtZmFtaWx5OmFyaWFsOyI+VGhlIG5l dyB2ZXJzaW9uIG9mJm5ic3A7PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMXB4OyI+ZHJhZnQt aHUtYmllci1iZmQtMDUgaGFzIGJlZW4gdXBsb2FkZWQuIFRoaXMgZHJhZnQgaGFzIGJlZW4gZGlz Y3Vzc2VkIG1hbnkgdGltZXMgaW4gSUVURiBtZWV0aW5nIGFuZCAmbmJzcDttYWlsaW5nIGxpc3Qu IFRoZSBhdXRob3JzIGFwcHJlY2lhdGUgbW9yZSBmZWVkYmFja3MuIFlvdXIgY29tbWVudHMgYW5k IHN1Z2dlc3Rpb25zIGFyZSB2ZXJ5IHdlbGNvbWUhPC9zcGFuPjwvcD48cCBzdHlsZT0iZm9udC1z aXplOjIwcHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IDIx cHg7Ij48YnI+PC9zcGFuPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjIwcHg7Zm9udC1mYW1pbHk6 YXJpYWw7Ij48c3BhbiBzdHlsZT0ibGluZS1oZWlnaHQ6IDIxcHg7Ij5CZXN0IFJlZ2FyZHMsPC9z cGFuPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjIwcHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij48c3Bh biBzdHlsZT0ibGluZS1oZWlnaHQ6IDIxcHg7Ij5RdWFuPC9zcGFuPjwvcD48cCBzdHlsZT0iZm9u dC1zaXplOjIwcHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij48YnI+PC9wPjxkaXY+PGRpdiBjbGFzcz0i emhpc3RvcnlSb3ciIHN0eWxlPSJkaXNwbGF5OmJsb2NrIj48ZGl2IGlkPSJ6d3JpdGVIaXN0b3J5 Q29udGFpbmVyIj48ZGl2IGNsYXNzPSJjb250cm9sLWdyb3VwIHpoaXN0b3J5UGFuZWwiPjxkaXYg Y2xhc3M9InpoaXN0b3J5Q29udGVudCI+PGRpdj48YnI+QSZuYnNwO25ldyZuYnNwO3ZlcnNpb24m bmJzcDtvZiZuYnNwO0ktRCwmbmJzcDtkcmFmdC1odS1iaWVyLWJmZC0wNS50eHQ8YnI+aGFzJm5i c3A7YmVlbiZuYnNwO3N1Y2Nlc3NmdWxseSZuYnNwO3N1Ym1pdHRlZCZuYnNwO2J5Jm5ic3A7UXVh biZuYnNwO1hpb25nJm5ic3A7YW5kJm5ic3A7cG9zdGVkJm5ic3A7dG8mbmJzcDt0aGU8YnI+SUVU RiZuYnNwO3JlcG9zaXRvcnkuPGJyPjxicj5OYW1lOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO2RyYWZ0LWh1LWJpZXItYmZkPGJyPlJldmlzaW9uOiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzA1PGJyPlRpdGxlOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO0JJRVImbmJzcDtCRkQ8YnI+RG9jdW1lbnQmbmJzcDtkYXRl OiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzIwMjAtMDItMTc8YnI+R3JvdXA6Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SW5kaXZpZHVhbCZuYnNwO1N1Ym1p c3Npb248YnI+UGFnZXM6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7MTA8YnI+VVJMOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2h0dHBzOi8vd3d3LmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1odS1iaWVyLWJmZC0wNS50eHQ8YnI+U3RhdHVzOiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2h0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1LWJpZXItYmZkLzxicj5IdG1saXplZDombmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaHUtYmllci1iZmQtMDU8YnI+SHRtbGl6ZWQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv aHRtbC9kcmFmdC1odS1iaWVyLWJmZDxicj5EaWZmOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2h0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1odS1iaWVyLWJmZC0wNTxicj48YnI+QWJzdHJhY3Q6PGJy PiZuYnNwOyZuYnNwOyZuYnNwO1BvaW50Jm5ic3A7dG8mbmJzcDttdWx0aXBvaW50Jm5ic3A7KFAy TVApJm5ic3A7QkZEJm5ic3A7aXMmbmJzcDtkZXNpZ25lZCZuYnNwO3RvJm5ic3A7dmVyaWZ5Jm5i c3A7bXVsdGlwb2ludDxicj4mbmJzcDsmbmJzcDsmbmJzcDtjb25uZWN0aXZpdHkuJm5ic3A7Jm5i c3A7VGhpcyZuYnNwO2RvY3VtZW50Jm5ic3A7c3BlY2lmaWVzJm5ic3A7dGhlJm5ic3A7YXBwbGlj YXRpb24mbmJzcDtvZiZuYnNwO1AyTVAmbmJzcDtCRkQmbmJzcDtpbjxicj4mbmJzcDsmbmJzcDsm bmJzcDtCSUVSJm5ic3A7bmV0d29yay48YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOzxicj48YnI+PGJyPlBsZWFzZSZuYnNwO25vdGUmbmJzcDt0aGF0Jm5ic3A7aXQm bmJzcDttYXkmbmJzcDt0YWtlJm5ic3A7YSZuYnNwO2NvdXBsZSZuYnNwO29mJm5ic3A7bWludXRl cyZuYnNwO2Zyb20mbmJzcDt0aGUmbmJzcDt0aW1lJm5ic3A7b2YmbmJzcDtzdWJtaXNzaW9uPGJy PnVudGlsJm5ic3A7dGhlJm5ic3A7aHRtbGl6ZWQmbmJzcDt2ZXJzaW9uJm5ic3A7YW5kJm5ic3A7 ZGlmZiZuYnNwO2FyZSZuYnNwO2F2YWlsYWJsZSZuYnNwO2F0Jm5ic3A7dG9vbHMuaWV0Zi5vcmcu PGJyPjxicj5UaGUmbmJzcDtJRVRGJm5ic3A7U2VjcmV0YXJpYXQ8YnI+PC9kaXY+PC9kaXY+PC9k aXY+PC9kaXY+PC9kaXY+PC9kaXY+PHA+PGJyPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj4= --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Wed Feb 19 00:17:06 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA301200CD for ; Wed, 19 Feb 2020 00:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.298 X-Spam-Level: X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 EdrUDFjI1Dle for ; Wed, 19 Feb 2020 00:17:00 -0800 (PST) Received: from mailout31.telekom.de (mailout31.telekom.de [194.25.225.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1244E1200D8 for ; Wed, 19 Feb 2020 00:16:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1582100219; x=1613636219; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=zNT+NqVv6M8Jbtc+5MMcR4QHny0CCeUp1sQ10DRiZSs=; b=ZgawF4EgL+0r4umBhEDsal08oQW1tny0cot7y5HfYBvXRgeGxG6uiadb QAIHWEE8yoCoQ5HgGfmiCD4FfUYCYEDkMqgo+Xeg8hwDb8Nw5YJJU75Oi N6gH9R48wXO3WcDHlhQUnZoGuG+IAESJIe6ZEhW0358O1Dwy34eCTXlWR vl5srW3cYjgx5atJpcUpt+HLzXoVo+ZyOrCzdkXwPYsSN+UlcKv9xBqhu cY2vO6Iu5yO1efKgL1thWYdeD3EkKHwZQ+3vA9MgXPXk7JEFA1zgep3Lu 1HHTHXixfkR8UPiJc9yHeSAbOuuj+gic+Fs1eChsTOHYSm6kKF8SYdfeZ w==; IronPort-SDR: GPJEhGa0ufd7fTnk0mM4M92YHfAtHss5vTeuvZ5wiH8GQNeC5U6ec2umFaRVk0vDm1ZskeBYMF x5OtaAYKWTOA== Received: from qdefcs.de.t-internal.com ([10.171.254.41]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 19 Feb 2020 09:16:52 +0100 IronPort-SDR: 1sC32WpwFeOybr6M3ErbaFBL04UuSf3LWTXQov5JXuzZ6LI1RgsewwFb4JCdkKMJw3clkRwZS2 fc/T98ojGR1g== X-IronPort-AV: E=Sophos; i="5.69,256,1571695200"; d="scan'208,217"; a="51619908" X-MGA-submission: =?us-ascii?q?MDE8yiU/ruabHL+8FN3Gj/v4cqAp9BKH+zFA8O?= =?us-ascii?q?gLZc7+1w7OEJ8Ul25lAyhQ7HrzThUGzVrLCuVSGCLN5MgHDj+aGzHpVf?= =?us-ascii?q?L6A+wazv3jlvCatjWf3LFNrP7jc7phGQ4xWhCYNC3o11sBt1HOSXNRei?= =?us-ascii?q?iFTNnpAGxc2z1y6Tn5Gdr4Qw=3D=3D?= Received: from he105864.emea1.cds.t-internal.com ([10.169.119.41]) by QDEFCV.de.t-internal.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA384; 19 Feb 2020 09:16:53 +0100 Received: from HE199744.EMEA1.cds.t-internal.com (10.169.119.52) by HE105864.emea1.cds.t-internal.com (10.169.119.41) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 19 Feb 2020 09:16:51 +0100 Received: from HE100181.emea1.cds.t-internal.com (10.171.40.15) by HE199744.EMEA1.cds.t-internal.com (10.169.119.52) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 19 Feb 2020 09:16:51 +0100 Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.17) by O365mail02.telekom.de (172.30.0.235) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 19 Feb 2020 09:16:53 +0100 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dG+095dPZXnmiu4I20J7rqqZVUHGIdjSuKwUURe4j/gEkJUHTRWblw8cFp4ZKc+dJBnEyyTp+2wKdFK7hr0i2DapJslXjNTI257hyAZHs0k0yv/2OCSkswk/6q/9ChaIWQa7R32QR99zlvUmdHfrbpuUdGYPpmlBal8i3K2F5cZnetmoPag2ezYcsYomf0qsmX4dI7MPAw0CSBA9N91Le/JhWrZFT1eI1sxkimzxCax/aHas8dLK/CdJc301XfT9bDmIa2DXiOwaGvvRvndbpOApXSMqgbj1KqUiy2yWackP+Kq10P9FIHlLLu+81o/gFGFgfw29gjiqpuSEl0ULhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zNT+NqVv6M8Jbtc+5MMcR4QHny0CCeUp1sQ10DRiZSs=; b=ZQLhK2EiJt+N6luSZTT9xoclFyIg/E5zLDv7l1SwRlK4BGe9g9q6etef0M/1o9eZwxubvKCoCSNMRNjtzzr4YhncjEe3NmglCdY/99LZXGldIpMmVH3rcUrFmnYZxFuk/buCw7geN0i/DzWxg7brUjPSzWcuJ3THBjcqJE/e8EkO9CX2b4YAyoPerdCdoQzolPMnZlO/H+XY8JR7NUTESd59OHulmKk4UOdbrvPpRO0M8koXFwOgbfAfoAO30DKd2q32rvsRpVhZazmKlsImTyKlggPp7djafLll0UxvPam5NXQ6lQfsPc3CwkASWf5rIHm7+4QOMDCUumPfhu5yxw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telekom.de; dmarc=pass action=none header.from=telekom.de; dkim=pass header.d=telekom.de; arc=none Received: from LEXPR01MB0495.DEUPRD01.PROD.OUTLOOK.DE (10.158.168.141) by LEXPR01MB0351.DEUPRD01.PROD.OUTLOOK.DE (10.158.169.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.29; Wed, 19 Feb 2020 08:16:50 +0000 Received: from LEXPR01MB0495.DEUPRD01.PROD.OUTLOOK.DE ([fe80::31a8:c1dd:fafe:8aa2]) by LEXPR01MB0495.DEUPRD01.PROD.OUTLOOK.DE ([fe80::31a8:c1dd:fafe:8aa2%4]) with mapi id 15.20.2729.032; Wed, 19 Feb 2020 08:16:50 +0000 From: To: , CC: , Thread-Topic: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK Thread-Index: AQHV5px94tB0yxbFVU+M+K4OafMO26giLGmg Date: Wed, 19 Feb 2020 08:16:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Nils.Warnke@telekom.de; x-originating-ip: [164.19.3.111] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 93bed820-2718-481b-477e-08d7b5141245 x-ms-traffictypediagnostic: LEXPR01MB0351: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3276; x-forefront-prvs: 0318501FAE x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(366004)(396003)(136003)(346002)(189003)(199004)(66574012)(186003)(26005)(76116006)(19627235002)(53546011)(4326008)(5660300002)(86362001)(316002)(7696005)(54906003)(81166006)(8676002)(66476007)(71200400001)(66556008)(64756008)(9686003)(66446008)(66946007)(8936002)(81156014)(55016002)(966005)(30864003)(2906002)(478600001)(33656002)(110136005); DIR:OUT; SFP:1101; SCL:1; SRVR:LEXPR01MB0351; H:LEXPR01MB0495.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gSVatCmrWaU4YCz5aO+aVD/5OYP4zODiwbsE1N/tlndQDhJoZ5mXEfypKMtbGB855jaZyHmzhADnyPMqb+BqBRyniHuiwWWRtgUtY8arVNVPD+HAlFXzY8P5yOaBm8W1xPUepljbRr1SZTlUAFe7inzJ0iPerPzWPV46qkGHt21VUPwQyD9Ct4HVPXqF9mYXR9qJh2WJ+/dLYWFZN1Fqk8ienrTq+tmB7wayncMQTjVecqfYJwxVexptLinQdOofniZovJf9DMFCH0OiTHfRlvtsw1BUFbeYqIBnld9xLmlWjzUcGJ8tE07c++TwwXtFh6exuOUbd+UtcG7qvIj3cRiwrvavfAy4OZXhBPTozjzy4ZN8BnfhURTCYrZgdlOO2bHmVFWl2zxLYvEKiSAlh1XR1Pxnsox8B0ZIQRcoh8KUIc67QGs7njt/KUIl3w1gfYQYult4bDIrc7VoXvBeqPOrI66jOKLlYvq1oamSAHHiB0O7Sys6VdcGKoKVzhZ5 x-ms-exchange-antispam-messagedata: cFKNXlRWdWTzdncXjZzqo4+ZwMyKG2HQhcTLwT8tfBa3KdX2zluMBg4ur/lzSZfSh90apgwi7bRza2y1XyhmD7/ld/ezzsdYGgeEwE1MOHU23k+redKfivAFMN/Rb0wcM7vh1VIh0cB+W+Ur7w/Q3w== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LEXPR01MB0495CB59CD2034FF8453A56996100LEXPR01MB0495DEUP_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 93bed820-2718-481b-477e-08d7b5141245 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Feb 2020 08:16:50.5758 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qJ0XNdMGgUTkcrcn9Cow2EDPhe3913yMC2y1ikbMpE2QocvgNnYnQc2iTiytP88/mKQRYtUrfEWSEhUm9StSAw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LEXPR01MB0351 X-TM-SNTS-SMTP: 03D2416888438601F558053A0F43AAFA9A090FE18C5DCCA5F558574C5CFA661B2000:8 X-OriginatorOrg: telekom.de Archived-At: Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 08:17:04 -0000 --_000_LEXPR01MB0495CB59CD2034FF8453A56996100LEXPR01MB0495DEUP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydC4NCktpbmQgcmVnYXJkcywgTmlscyBXYXJua2UNCg0KVm9uOiBCSUVSIDxiaWVyLWJv dW5jZXNAaWV0Zi5vcmc+IEltIEF1ZnRyYWcgdm9uIEdyZWcgU2hlcGhlcmQNCkdlc2VuZGV0OiBE aWVuc3RhZywgMTguIEZlYnJ1YXIgMjAyMCAyMTo0Ng0KQW46IEplZmZyZXkgKFpoYW9odWkpIFpo YW5nIDx6emhhbmc9NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZz4NCkNjOiBiaWVyQGlldGYu b3JnOyBUb2VybGVzcyBFY2tlcnQgPHR0ZUBjcy5mYXUuZGU+DQpCZXRyZWZmOiBbQmllcl0gV0dM QyAtIGRyYWZ0LWlldGYtYmllci10ZS1hcmNoIDEgV0VFSw0KDQpUaGFua3MgVG9lcmxlc3MgYW5k IEplZmZyZXkNCg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1i aWVyLXRlLWFyY2gvDQoNCk9uZSBtb3JlIHdlZWsgb2YgV0dMQy4gUGxlYXNlIHJlYWQgdGhlIGxh dGVzdCByZXYgYW5kIHJlc3BvbmQgdG8gdGhpcyB0aHJlYWQgdy93byBzdXBwb3J0Lg0KDQpDaGFp cnMNCihTaGVwKQ0KDQoNCk9uIFR1ZSwgRmViIDE4LCAyMDIwIGF0IDEyOjA3IFBNIEplZmZyZXkg KFpoYW9odWkpIFpoYW5nIDx6emhhbmc9NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZzxtYWls dG86NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KSGkgVG9lcmxlc3MsDQoN ClRoYW5rcyENCkkgc3VwcG9ydCBtb3ZpbmcgdGhpcyB0byB0aGUgbmV4dCBzdGFnZS4NCg0KSmVm ZnJleQ0KDQpPbiBGcmksIE5vdiAwMSwgMjAxOSBhdCAwNzo0MjozOFBNICswMTAwLCBUb2VybGVz cyBFY2tlcnQgd3JvdGU6DQo+IFRoYW5rcyBKZWZmDQo+DQo+IEkgaGF2ZSBub3cgcHVzaGVkIG91 dCAtMDUgd2l0aCB0aGUgYW5zd2VycyBhbmQgaG9wZWZ1bGx5IHJlc29sdXRpb24gdG8NCj4geW91 ciBwb2ludHMgaW4gZW1haWwgYmVsb3cuICBCaWdnZXN0IGFkZGl0aW9uIHdhcyBhIHNlY3Rpb24g YWJvdXQNCj4gcmV1c2Ugb2YgQlBzICh3aXRob3V0IEROUikgd2hpY2ggY2FtZSBvdXQgb2YgdGhl IGNvbmZ1c2lvbiBpIHRoaW5rIHRoZQ0KPiByZXVzZSBpbiB0aGUgRUNNUCBleGFtcGxlIHJhaXNl ZC4gSSB3YXMgYWZyYWlkIHNvIGZhciB0byBleHBsYW4gdGhhdA0KPiBhcyBpdCBtYXkgbm90IGJl IGVhc3kgdG8gYWJzb3JiIGFuZCB1bHRpbWF0ZWx5IGlzIHN0dWZmIG9ubHkNCj4gY29udHJvbGxl ciBkZXZlbG9wZXJzIG5lZWQgdG8gdW5kZXJzdGFuZCwgYnV0IGhvcGVmdWxseSB1c2VmdWwuDQo+ IEFuZCB0aGVuIG9mIGNvdXJzZSB0aGUgc3VtbWFyeSBvZiBCUCBvcHRpbWl6YXRpbnMgeW91IGFz a2VkIGZvcg0KPg0KPiBEaWZmIGZyb20gbGFzdCB2ZXJzaW9uIGkgc2VudCB5b3U6DQo+DQo+IGh0 dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwOi8vdG9vbHMuaWV0Zi5vcmcvKnJmY2RpZmY/ dXJsMT1odHRwczxodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cDovdG9vbHMuaWV0Zi5v cmcvKnJmY2RpZmY/dXJsMT1odHRwcz46DQo+ICoqQXJhdy5naXRodWJ1c2VyY29udGVudC5jb208 aHR0cDovL0FyYXcuZ2l0aHVidXNlcmNvbnRlbnQuY29tPip0b2VybGVzcypiaWVyLXRlLWFyY2gq bWFzdGVyKmRyYWZ0LWlldGYtYg0KPiBpZXItdGUtYXJjaC0wNS4xLnR4dCZ1cmwyPWh0dHA6KipB dG9vbHMuaWV0Zi5vcmc8aHR0cDovL0F0b29scy5pZXRmLm9yZz4qaWQqZHJhZnQtaWV0Zi1iaWVy LXRlDQo+IC1hcmNoLTA1LnR4dF9fO0x5OHZMeTh2THk4dkx5OCEhTkV0NnlNYU8tZ2shVnVRQ1ZI bnFKeV9hWUktRk50OUExYTVFekgNCj4gT0NyMGZaa0xQYmdnM0NQTnUwUHlyV3NyRng0MV9qV1gy QXQ4Vi0kDQo+DQo+IGZ1bGwgLTA0IC0+IDA1IGRpZmY6DQo+DQo+IGh0dHBzOi8vdXJsZGVmZW5z ZS5jb20vdjMvX19odHRwOi8vdG9vbHMuaWV0Zi5vcmcvKnJmY2RpZmY/dXJsMT1odHRwOio8aHR0 cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHA6L3Rvb2xzLmlldGYub3JnLypyZmNkaWZmP3Vy bDE9aHR0cDoqPg0KPiAqQXRvb2xzLmlldGYub3JnPGh0dHA6Ly9BdG9vbHMuaWV0Zi5vcmc+Kmlk KmRyYWZ0LWlldGYtYmllci10ZS1hcmNoLTA0LnR4dCZ1cmwyPWh0dHA6KipBdG9vbHMuDQo+IGll dGYub3JnPGh0dHA6Ly9pZXRmLm9yZz4qaWQqZHJhZnQtaWV0Zi1iaWVyLXRlLWFyY2gtMDUudHh0 X187THk4dkx5OHZMeTh2ISFORXQ2eU1hTy1naw0KPiAhVnVRQ1ZIbnFKeV9hWUktRk50OUExYTVF ekhPQ3IwZlprTFBiZ2czQ1BOdTBQeXJXc3JGeDQxX2pXYW5jcHppdiQNCj4NCj4gQ29tbWVudHMg aW5saW5lIGJlbG93Lg0KPg0KPiBDaGVlcnMNCj4gICAgIHRvZXJsZXNzDQo+DQo+IE9uIE1vbiwg T2N0IDI4LCAyMDE5IGF0IDA3OjUyOjU5UE0gKzAwMDAsIEplZmZyZXkgKFpoYW9odWkpIFpoYW5n IHdyb3RlOg0KPiA+IEkgVGhvdWdodCB1LXR1cm4gaXMgdGhlIG1vc3Qgc2ltcGxlIGNvbXBhcmlz b24gbGVhZiB2cy4gbm9uLWxlYWYgQkZSLg0KPiA+DQo+ID4gWnpoPiBUaGUgdGV4dCBpbiB0aGUg ZW1haWwgaXMgc2VyaW91c2x5IG1pc2FsaWduZWQuIExvb2tpbmcgYXQgdGhlIHBpY3R1cmUgaW4g dGhlIGRpZmYgbGluaywgd2hpbGUgeW91IGdhdmUgYSBVLXR1cm4gZXhhbXBsZSwgdGhvdWdoIGV2 ZW4gaWYgQkZFUjIgaXMgbm90IGNvbm5lY3RlZCB0byBCRlIyICBidXQgb25seSBjb25uZWN0ZWQg dG8gQkZFUjEgKGhlbmNlIG5vIFUtdHVybiksIHRoZW4gQkZFUjEgaXMgc3RpbGwgbm90IGEgbGVh ZiBCRkVSIEkgc3VwcG9zZS4gVGhhdCdzIHdoeSBJIHNhaWQgdGhlIGZpcnN0IHNlbnRlbmNlIG9m IHRoZSBhYm92ZSBwYXJhZ3JhcGggaXMgZW5vdWdoIHRvIGRlZmluZSBMZWFmIEJGRVIgd2hpbGUg dGhlIGV4YW1wbGUgaXRzZWxmIGlzIGFjdHVhbGx5IG5vdCBuZWVkZWQuDQo+DQo+IEFyZ2guLi4g b2ssIGhhZCB0byBmaXggdHdvIHdvcmRzLCBCRklSLT5CRkVSIGFuZCBsZWZ0LWhhbmQgLT4gcmln aHQtaGFuZDoNCj4NCj4gQ29uc2lkZXIgaG93IHJlZHVuZGFudCBkaXNqb2ludCB0cmFmZmljIGNh biByZWFjaCBCRkVSMS9CRkVSMiBpbiBhYm92ZQ0KPiBwaWN0dXJlOiBXaGVuIEJGRVIxL0JGRVIy IGFyZSBOb24tTGVhZiBCRkVSIGFzIHNob3duIG9uIHRoZSByaWdodCBoYW5kDQo+IHNpZGUsIG9u ZSB0cmFmZmljIGNvcHkgd291bGQgYmUgZm9yd2FyZGVkIHRvIEJGRVIxIGZyb20gQkZSMSwgYnV0 IHRoZQ0KPiBvdGhlciBvbmUgY291bGQgb25seSByZWFjaCBCRkVSMSB2aWEgQkZFUjIsIHdoaWNo IG1ha2VzIEJGRVIyIGENCj4gbm9uLUxlYWYgQkZFUi4gTGlrZXdpc2UgQkZFUjEgaXMgYSBub24t TGVhZiBCRkVSIHdoZW4gZm9yd2FyZGluZw0KPiB0cmFmZmljIHRvIEJGRVIyDQo+DQo+ID4gWnpo PiBBZGRpdGlvbmFsbHksIGluIGxlZnQgcGFydCBvZiB0aGUgcGljdHVyZSB5b3UgYWRkZWQsIGlm IHNvbWUgZmFpbHVyZSBsZWFkcyB0byBCRlIyIHRvIGJlIG9ubHkgcmVhY2hhYmxlIHZpYSBCRkVS MSwgdGhlbiBCRkVSMSBpcyBubyBsb25nZXIgYSBsZWFmIEJGRVIuDQo+DQo+IEFkZGVkIHNlbnRl bmNlOg0KPg0KPiA8dD5Ob3RlIHRoYXQgdGhlIEJGRVIgaW4gdGhlIGxlZnQgaGFuZCBwaWN0dXJl IGFyZSBvbmx5IGd1YXJhbnRlZWQgdG8NCj4gYmUgbGVhZi1CRlIgYnkgZml0dGluZyByb3V0aW5n IGNvbmZpZ3VyYXRpb24gdGhhdCBwcm9oaWJpdHMgdHJhbnNpdA0KPiB0cmFmZmljIHRvIHBhc3Mg dGhyb3VnaCBhIFBFLCB3aGljaCBpcyBjb21tb25seSBhcHBsaWVkIGluIHRoZXNlDQo+IHRvcG9s b2dpZXMuPC90Pg0KPg0KPiA+IEkgYXNzdW1lIHlvdSBkb24ndCByZWFzc2lnbiBCUHMgd2hlbiBs aW5rcyBnbyB1cCBhbmQgZG93bi4NCj4NCj4gSSBkaWRuJ3Qgd2FudCB0byBkaXNjdXNzIHRoYXQg b3B0aW9uIGluIHRoaXMgZG9jdW1lbnQuIEl0cyBvYnZpb3VzbHkNCj4gcGVyZmVjdGx5IGZlYXNp YmxlLCBidXQgYmUgeWV0IGEgYmlnIGFtb3VudCBvZiB0ZXh0IChlc3BlY2lhbGx5IHRoZQ0KPiBj b25zaWRlcmF0aW9ucyBob3cgdG8gZG8gdGhpcyBtYWtlLWJlZm9yZS1icmVhay4gRnV0dXJlIGRv Yy4NCj4NCj4gPiA+IGJ1dCBzdWJzZXF1ZW50IHBvbGFyaXphdGlvbiBleGFtcGxlIGNvbmZ1c2Vz IG1lLiBJdCBzZWVtcyB0aGF0IEJQIDA6NiBpcyBhc3NpZ25lZCB0byB0aGUgcm91dGVkIGFkamFj ZW5jeSBCRlIxMCAod2hpY2ggaXMgYWN0dWFsbHkgdGFsa2VkIGFib3V0IGluIFNlY3Rpb24gNC44 KS4NCj4gPg0KPiA+IFNlY3Rpb24gNC43IGRvZXMgbm90IG1lbnRpb24gInJvdXRlZCIgYXQgYWxs LCBzbyB0aGVyZSBhcmUgbm8gcm91dGVkIGFkamFjZW5jaWVzIGF0IGFsbCB1c2VkIGluIDQuNy4g U28gaSBhbSBub3Qgc3VyZSB3aGF0IHlvdSBhcmUgY29uZnVzZWQgYWJvdXQuDQo+ID4NCj4gPiBa emg+ICJUaGUgQklGVCBvZiBlYWNoIEJGUiBhcmUgb25seSBwb3B1bGF0ZWQgd2l0aCBCUHMgdGhh dCBhcmUgYWRqYWNlbnQgdG8gdGhlIEJGUiBpbiB0aGUgQklFUi1URSB0b3BvbG9neSIuDQo+DQo+ IENvcnJlY3QgdGV4dCBmcm9tIHRoZSBpbnRyb2R1Y3Rpb24uIE9rLg0KPg0KPiA+IFp6aD4gU2lu Y2UgdGhlIHNhbWUgMDo2IGlzIGluIEJJRlRTIG9mIEJGUjEvQkZSMi9CRlIzIChhbmQgSSBzdXBw b3NlIGluIEJGUjR+QkZSOSBhcyB3ZWxsIGV2ZW4gdGhvdWdoIG5vdCBkcmF3biksIEkgYXNzdW1l ZCBpdCdzIGZvciB0aGUgIk1QMlAiIHJvdXRlZCBhZGphY2VuY3kgdG8gUjEwOyB0aG91Z2ggSSB0 aGVuIHJ1bGVkIHRoYXQgb3V0IC0gYnV0IEkgZG9uJ3Qga25vdyB3aGF0IDA6NiByZXByZXNlbnQg bm93IG9uIEJGUjEsIEJGUjIsIGFuZCBCRlIzLg0KPg0KPiBBaC4gT2suIEkgdGhvdWdodCBpIGNv dWxkIHN0cmlwIGRvd24gdGhlIGV4YW1wbGUgdG8gc2hvdyBvbmx5IHRoZQ0KPiBhZGphY2VuY2ll cyByZWxldmFudCB0byB0aGUgZm9sbG93aW5nIGRpc2N1c2lvbiwgYnV0IHNlZW1pbmdseSB0aGlz DQo+IGNhbiBpbnRyb2R1Y2UgdGhlIGNvbmZ1c2lvbiB5b3UgaGF2ZS4NCj4NCj4gU28gaSBjb21w bGV0ZWQgdGhlIGV4YW1wbGUgd2l0aCB0aGUgQlAgYXNzaWdubWVudCBhY29zcyBhbGwgbm9kZXMs IGJ1dA0KPiBhZGRlZCB0ZXh0IHBvaW50aW5nIHRvIGEgbmV3IHNlY3Rpb24gZnVydGhlciBkb3du IHRvIGRpc2N1c3MgdGhlDQo+IHJlLXVzZSBvZiBCUCBmb3Igd2hpY2ggdGhpIHBpY3R1cmUgaXMg YWxzbyBhbiBleGFtcGxlLg0KPg0KPiAoY2hlY2sgb3V0IHRoZSBkaWZmLCBuZXcgcmV1c2UgdGV4 dCB0byBsb25nIHRvIGNvcHkgaW5saW5lKS4NCj4NCj4gPiBUaGUgd2hvbGUgcHVycG9zZSBvZiB0 aGUgRUNNUCBCUHMgaXMgb2YgY291cnNlIHRvIHNhdmUgYml0cywgb3RoZXJ3aXNlIHdlJ2QgZ2l2 ZSBlYWNoIGxpbmsgYSBzZXBhcmF0ZSBCUCwgd2hpY2ggd291bGQgYmUgNiBCUCB0byByZWFjaCB0 byBCRlI0Li4uQkZSNyBmcm9tIEJGUjEuDQo+ID4NCj4gPiBaemg+IFRoZSB0cm91YmxlIEkgYW0g aGF2aW5nIGlzIHRoYXQgdGhlIHNhbWUgMDo2IGlzIGFzc2lnbmVkIHRvIGRpZmZlcmVudCB0aGlu Z3MgYW5kIGl0J3MgcHJlc2VudCBvbiBhbGwgQkZSMS9CRlIyL0JGUjMuIEl0IGlzIHBlcmhhcHMg YW4gaW50ZW50aW9uYWwgc21hcnQgZGVzaWduIGJ1dCBJIGhhdmUgbm90IHdyYXBwZWQgbXkgbWlu ZCBhcm91bmQgaXQuIEl0J3MgYXBwYXJlbnRseSBkaWZmZXJlbnQgZnJvbSB0aGUgbGluayBidW5k bGUgY2FzZSwgc28gYmV0dGVyIHNlcGFyYXRlIGl0IG91dCBhbmQgZWxhYm9yYXRlIGl0IChpbmNs dWRpbmcgdGhlIEROUiBmbGFnIHRoYXQgbWlnaHQgYmUgbmVlZGVkIGhlcmUgLSBJZiB0aGUgcGFj a2V0IGFycml2ZXMgb24gQkZSMSB3aXRoIDA6Niwgd291bGQgdGhlIEJQIHJlc2V0IHdoZW4gaXQg aXMgc2VudCB0byBCRlIyLzMpPw0KPg0KPiBZZXMsIHRoZXJlIHdhcyB0aGUgYnVnIG9mIHJldXNp bmcgQlAgMDo2IGFjcm9zcyBzZXF1ZW50aWFsIEJGUiBhbG9uZw0KPiB0aGUgcGF0aCwgYnV0IG5v dyB0aGUgZXhhbXBsZSBjb3JyZWN0bHkgcmV1c2VzIHNlcGFyYXRlIEJQIGF0DQo+IGRpZmZlcmVu dCBzdGFnZXMgb2YgdGhlIHBhdGhzIChCUCAwOjYgb24gQkZSMSwgQlAgMDo3IG9uIEJGUjIvQkZS MykgYW5kIHNvIG9uLg0KPg0KPiBUaGFua3MhDQo+DQo+ID4gPiA0LjguICBSb3V0ZWQgYWRqYWNl bmNpZXMNCj4gPiA+DQo+ID4gPiBJZiBJIHVuZGVyc3RhbmQgaXQgY29ycmVjdGx5LCB0aGVyZSBp cyBhIEJQIGFzc2lnbmVkIHRvIEwxL0wyL0wzDQo+ID4gPiByZXNwZWN0aXZlbHkgKHAycCBsaW5r KSwgYW5kIHRoZW4gdGhlcmUgYXJlIEJQcyBhc3NpZ25lZCB0byBNUDJQIHR1bm5lbHMgKHJvdXRl ZCBhZGphY2VuY3kgZnJvbSBldmVyeSBCRlIpIHRvIHRoZSBMMS9MMi9MMyBpbnRlcmZhY2UgYWRk cmVzc2VzIGFuZCBsb29wYmFjayBhZGRyZXNzZXMgb24gQkZSMi8zLg0KPiA+DQo+ID4gT2sgdGhh dCB3YXNuJ3QgcXVpdGUgdGhlIHJlYWQgaSBleHBlY3RlZC4gTGV0IG1lIGNsYXJpZnkgdGhlIHRl eHQvcGljdHVyZToNCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAgICAuLi4uLi4uLi4uLi4uLi4N Cj4gPiAgICAgICAgICAuLi5CRlIxLS0uLi4gICAgICAgICAgIC4uLi0tTDEtLSBCRlIyLi4uDQo+ ID4gICAgICAgICAgICAgICAgICAgLi4uIC5Sb3V0ZXJzLiAuLi4tLUwyLS0vDQo+ID4gICAgICAg ICAgLi4uQkZSNC0tLi4uICAgICAgICAgICAuLi4tLS0tLS0gQkZSMy4uLg0KPiA+ICAgICAgICAg ICAgICAgICAgICAuLi4uLi4uLi4uLi4uLi4gICAgICAgICB8DQo+ID4gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgTE8NCj4gPiAgICAgICAgICAgICAgICAgICAgIE5l dHdvcmsgQXJlYSAxDQo+ID4NCj4gPiBBc3N1bWUgdGhlIHJlcXVpcmVtZW50IGluIHRoZSBhYm92 ZSBwaWN0dXJlIGlzIHRvIGV4cGxpY2l0bHkgc3RlZXIgdHJhZmZpYyBmbG93cyB0aGF0IGhhdmUg YXJyaXZlZCBhdCBCRlIxIG9yIEJGUjQgdmlhIGEgc2hvcnRlc3QgcGF0aCBpbiB0aGUgcm91dGlu ZyB1bmRlcmxheSAibmV0d29yayBhcmVhIDEiIHRvIG9uZSBvZiB0aGUgZm9sbG93aW5nIHRocmVl IG5leHQgc2VnbWVudHM6ICgxKSBCRlIyIHZpYSBsaW5rIEwxLCAoMikgQkZSMiB2aWEgbGluayBM MiwgKDMpIHZpYSBCRlIzLg0KPiA+DQo+ID4gVG8gYWNoaWV2ZSB0aGlzLCBib3RoIEJGUjEgYW5k IEJGUjQgYXJlIHNldCB1cCB3aXRoIGEgZm9yd2FyZF9yb3V0ZWQgYWRqYWNlbmN5IEJpdFBvc2l0 aW9uIHRvd2FyZHMgYW4gYWRkcmVzcyBvZiBCRlIyIG9uIGxpbmsgTDEsIGFub3RoZXIgZm9yd2Fy ZF9yb3V0ZWQgQml0UG9zaXRpb24gdG93YXJkcyBhbiBhZGRyZXNzIG9mIEJGUjIgb24gbGluayBM MiBhbmQgYSB0aGlyZCBmb3J3YXJkX3JvdXRlZCBCaXRwb3NpdGlvbiB0b3dhcmRzIGEgbm9kZSBh ZGRyZXNzIExPIG9mIEJGUjMuDQo+ID4NCj4gPiBEb2VzIHRoaXMgY2xlYXIgaXAgdGhlIGNvbmZ1 c2lvbiA/DQo+ID4NCj4gPiBaemg+IFRoZSBwaWN0dXJlIGlzIGJhZGx5IG1pc2FsaWduZWQuIEkn bGwgd2FpdCB0aWxsIDQuNyBxdWVzdGlvbnMgYXJlIGNsZWFyZWQuDQo+DQo+IE9rLg0KPg0KPiA+ ID4gSWYgQkZSMi8zIGFyZSBhbHNvIEJGRVJzLCB0aGVuIHRoZXkgYWRkaXRpb25hbGx5IHdpbGwg aGF2ZSBCRkVSIEJQcy4NCj4gPiA+IE9uIEJGUjEvNCwgdGhlIEJJRlQgZW50cmllcyBmb3IgdGhl IE1QMlAgQlBzIGZvciB0aGUgTDEvTDIvTDMvbG9vcGJhY2sgaW50ZXJmYWNlIGFkZHJlc3NlcyBv ZiBCRlIyLzMgd2lsbCB1c2UgZm9yd2FyZF9yb3V0ZWQoaW50ZXJmYWNlL2xvb3BiYWNrIGFkZHJl c3MpLiBGb3IgYSBwYWNrZXQgdG8gYmUgZGVjYXBzdWxhdGVkIG9uIGEgQkZFUiwgdGhlcmUgaXMg YSBuZWVkIGZvciBib3RoIHRoZSBCRkVSIEJQIGFuZCBhbm90aGVyIEJQIChwMnAvbGFuL2h1Yi1z cG9rZS9yb3V0ZWQtYWRqYWNlbmN5KSBpbiB0aGUgcGFja2V0ICh0aGUgZm9ybWVyIGlzIGZvciBk ZWNhcHN1bGF0aW9uIGFuZCB0aGUgbGF0dGVyIGlzIGZvciBnZXR0aW5nIGl0IHRoZXJlKS4NCj4g Pg0KPiA+IFRoaXMgaXMgbm90IGRpc2N1c3NlZCBpbiB0aGlzIHNlY3Rpb24sIGJ1dCB5b3UgYXJl IHJpZ2h0IC0gdW5sZXNzDQo+ID4gQkZSMiBvciBCRlIzIGlzIGEgbGVhZiBCRlIuIEluIHRoYXQg Y2FzZSwgaXQgd291bGQganVzdCBsZXZlcmFnZSB0aGUgb25lIHNoYXJlZCAibGVhZi1CRlIiIEJQ LCBzbyB0aGV5IGRvIG5vdCBuZWVkIGEgcGVyLUJGRVIgQlAgZm9yIGxvY2FsX2RlY2FwKCkuDQo+ ID4NCj4gPiBaemg+IFJpZ2h0IC0gc2hhcmVkIGxlYWYtQkZSIEJQIGJ1dCBzdGlsbCBuZWVkIHRo YXQgQlAgKHRoZSBrZXkgaXMgdGhhdCB3ZSBuZWVkIGEgQlAgdG8gZ2V0IHBhY2tldCB0byBhIEJG RVIgYW5kIHRoZW4gYSBCUCBmb3IgZGVjYXBzdWxhdGlvbikuDQo+DQo+IFlvdSBnb3QgaXQuDQo+ DQo+ID4gPiBJZiB0aGF0Pz8/cyB0aGUgY2FzZSwgaXQ/Pz9zIHdvcnRoIHBvaW50IHRoZSBhYm92 ZSBvdXQuDQo+ID4NCj4gPiBIbW0uLi4gVGhlIGxvZ2ljIG9mIEJGRVIgQlBzIGlzIHRvdGFsbHkg aW5kZXBlbmRlbnQgb2YgdGhlIGxvZ2ljIG9mIGZvcndhcmRfcm91dGVkIGFkamFjZW5jeSwgc28g aSB3b3VsZCB3b3JyeSB0aGF0IHJlcGVhdGluZyB0aGUgZXhwbGFuYXRpb24gb2YgQkZFUiBCUHMg d291bGQgY29uZmxhdGUgdGhlIGZvcndhcmRfcm91dGVkIGV4cGxhbmF0aW9uLg0KPiA+DQo+ID4g WnpoPiBJdCdzIGp1c3QgdGhhdCB0aGlzIGlzIGEgcGxhY2Ugd2hlcmUgYWxsIGtpbmRzIG9mIEJQ cyBhcmUgdXNlZCBzbyBpdCdzIGdvb2QgdG8gaGF2ZSBhIHN1bW1hcnkgKGNvdWxkIGJlIGEgc3Vi c2VjdGlvbiA0LjkpLg0KPg0KPiBZZXMsIGFkZGVkIHN1Y2ggYSBzdW1tYXJ5LiBQbHMuIGNoZWNr Lg0KPg0KPiA+ID4gQWN0dWFsbHksIHRoZSByZWFzb24gdGhhdCBJIHRob3VnaHQgdGhpcyBpcyBN UDJQIGlzIHRoYXQgMDo2IGlzIHByZXNlbnQgb24gUjEsIFIyLCBhbmQgUjMgKGFuZCBtb3JlIEkg YXNzdW1lKSBpbiBGaWd1cmUgMTIsIGJ1dCBub3cgSSB0aGluayBpdCBjYW4/Pz90IGJlIE1QMlAg KHNvIGl0IGlzIG5vdCBjb3JyZWN0IHRvIGhhdmUgMDo2IHByZXNlbnQgb24gdGhvc2Ugcm91dGVy cyA/Pz8gb25seSB0aGUgcDJwIHR1bm5lbCBoZWFkL3RhaWwgc2hvdWxkIGhhdmUgdGhlIEJQIHBy ZXNlbnQgaW4gdGhlIEJJRlQpLiBUaGUgcmVhc29uIGlzIHRoYXQgaWYgaXQgd2VyZSBNUDJQLCBh bnkgcm91dGVyIGdldHRpbmcgYSBjb3B5IHdpbGwgc2VuZCBpdCB0byB0aGUgZW5kcG9pbnQgb2Yg dGhlIHJvdXRlZCBhZGphY2VuY3ksIGNhdXNpbmcgbG90cyBvZiBkdXBsaWNhdGVzLi4NCj4gPiA+ DQo+ID4gPiBBbSBJIGdldHRpbmcgdGhpcyBjb3JyZWN0Pw0KPiA+DQo+ID4gSSB0aGluayB5b3Ug YXJlIHN0aWxsIGV4cGxhaW5pbmcgZnJvbSB0aGUgbWlzdW5kZXJzdHNhbmRpbmcgdGhhdCB0aGUg RUNNUCBleHBsYW5hdGlvbnMgd2hlcmUgYWJvdXQgcm91dGVkIGFkamFjZW5jaWVzLg0KPiA+DQo+ ID4gSSBoYXZlIG5vdyBleHBhbmRlZCB0aGUgc29tZXdoYXQgdGVyc2UgdGV4dCBpbiB0aGUgQklG VCB0YWJsZSBwaWN0dXJlcywgdG8gbWFrZSBpdCBjbGVhciB0aGF0IHRoZSBFQ01QIGlzIGFjcm9z cyBtdWx0aXBlIGZvcndhcmRfY29ubmVjdGVkIGFkamFjZW5jaWVzIGluIHRoZSBleGFtcGxlcy4g Rm9yIGV4YW1wbGUsIGZpcnN0IEJJRlQgcGljdHVyZToNCj4gPg0KPiA+ICAgQklGVCBlbnRyeSBp biBCRlIxOg0KPiA+ICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gICB8IEluZGV4IHwgIEFkamFjZW5jaWVzICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gPiAgID09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQ0KPiA+ICAgfCAwOjYgICB8ICBFQ01QKHtmb3J3YXJkX2Nvbm5lY3RlZChMMSwgQkZSMiksICAg ICAgICAgICAgICAgICAgICB8DQo+ID4gICB8ICAgICAgIHwgICAgICAgIGZvcndhcmRfY29ubmVj dGVkKEwyLCBCRlIyKSwgICAgICAgICAgICAgICAgICAgIHwNCj4gPiAgIHwgICAgICAgfCAgICAg ICAgZm9yd2FyZF9jb25uZWN0ZWQoTDMsIEJGUjIpfSwgc2VlZCkgICAgICAgICAgICAgfA0KPiA+ ICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+ID4NCj4gPiBPZiBjb3Vyc2UsIGFuIEVDTVAgYWRqYWNlbmN5IGNhbiBi ZSBhY3Jvc3MgYW55IHR5cGUgb2YgYWRqYWNlbmNpZXMsIGJ1dCBhbGwgdGhlIHRleHQvZXhwbGFu YXRpb25zIHVzZWQgZm9yd2FyZF9jb25uZWN0ZWQsIGFuZCBub3cgdGhlIHBpY3R1cmVzIHNob3cg dGhhdCBleHBsaWNpdGx5Lg0KPiA+DQo+ID4gWnpoPiBJIGNhbiB1bmRlcnN0YW5kIHRoZSBtdWx0 aS1saW5rIGNhc2UsIGJ1dCB0aGUgbXVsdGktaG9wIEVDTVAgY2FzZSAoZnJvbSBCRlIxIHRvd2Fy ZHMgQkZSMTApIGlzIGNvbmZ1c2luZyBtZS4gSXQgd291bGQgaGVscCB0byBnaXZlIGFuIGV4YW1w bGUgaG93IGl0IGNhbiBiZSB1c2VkLCBXSVRIT1VUIHdvcnJ5aW5nIGFib3V0IHBvbGFyaXphdGlv bi4NCj4NCj4gUGxlYXNlIGNoZWNrIC0wNSB0ZXh0IHRoYXQgaGFzIHRoZSBmdWxsIHNldCBvZiBC SUZUIGxpc3RlZCBub3c6DQo+DQo+IFRoZXJlIGlzICByZWFsbHkgbm90aGluZyBub3RoaW5nIHVu aXF1ZSBpbiBtdWx0aS1ob3AgRUNNUCBmb3IgQklFUi1URQ0KPiB0aGF0IHdlIGRvIG5vdCBhbHNv IGhhdmUgaW4gYW55IG90aGVyIEVDTVAsIGV4Y2VwdCB0aGUgY29uY2x1c2lvbiB0aGF0DQo+IHdl IHdhbnQgdG8gc3VwcG9ydCBmYXN0IEhXIGhhc2ggbWVjaGFuaXNtcyBBTkQgYWxsb3cgdGhlIGNv bnRyb2xsZXIgdG8NCj4gc2V0IHVwIG5vbi1wb2xhcml6ZWQgbXVsdGktaG9wIEVDTVAgQU5EIGJl IGFibGUgdG8gcHJlY2FsY3VsYXRlIHBhdGhzLg0KPiBIZW5jZSB0aGUgc3BlY2lmaWNhdGlvbiBv ZiBFQ01QIGFkamFjZW5jaWVzIHRvIGhhdmUgYSBjb250cm9sbGVyDQo+IGNvbmZpZ3VyYWJsZSBz ZWVkLg0KPg0KPiBCdHc6IFRoZSBwaWN0dXJlIGlzIG1heWJlIHVubmVjZXNzYXJpbHkgbGFyZ2Ug YmVjYXVzZSBpJ3ZlIHVzZWQgaXQgZm9yDQo+IDIwIHllYXJzIHRvIGV4cGxhaW4gdGhlIHNhbWUg cG9sYXJpemF0aW9uIGlzc3VlIGZvciB1bmljYXN0IHZzDQo+IG11bHRpY2FzdCwgYW5kIGZvciBt dWx0aWNhc3Qgb25seSBCRlIxMC4uLkJGUjQgYXJlIHJlbGV2YW50IChFQ01QIG9mDQo+IHRoZSBQ SU0vbUxEUCBqb2lucyksIHdoZXJlYXMgZm9yIHVuaWNhc3QvQklFUiBvbmx5DQo+IEJGUjEuLi5C RlI3IGFyZSByZWxldmFudC4gQnV0IGJlaW5nIHN5bW1ldHJpYywgdGhlIHBpY3R1cmUgbWFrZXMg aXQNCj4gY2xlYXIgaXRzIHRoZSBzYW1lIHByb2JsZW0uDQo+DQo+ID4gPiAgICBUbyBpbmhpYml0 IGxvb3BpbmcgaW4gdGhlIGZhY2Ugb2Ygc3VjaCBwaHlzaWNhbCBtaXNjb25maWd1cmF0aW9uLA0K PiA+ID4gICAgb25seSBmb3J3YXJkX2Nvbm5lY3RlZCBhZGphY2VuY2llcyBhcmUgcGVybWl0dGVk IHRvIGhhdmUgRE5SIHNldCwgYW5kDQo+ID4gPiAgICB0aGUgbGluayBsYXllciBkZXN0aW5hdGlv biBhZGRyZXNzIG9mIHRoZSBhZGphY2VuY3kgKGUuZy4gIE1BQw0KPiA+ID4gICAgYWRkcmVzcykg cHJvdGVjdHMgYWdhaW5zdCBjbG9zaW5nIHRoZSBsb29wLiAgTGluayBsYXllcnMgd2l0aG91dCBw b3J0DQo+ID4gPiAgICB1bmlxdWUgbGluayBsYXllciBhZGRyZXNzZXMgc2hvdWxkIG5vdCBiZSB1 c2VkIHdpdGggdGhlIEROUiBmbGFnIHNldC4NCj4gPiA+DQo+ID4gPiBJdD8/P3Mgbm90IGNsZWFy IGhvdyBsaW5rIGxheWVyIGFkZHJlc3MgaGVscHM/DQo+ID4NCj4gPiBJIGhhdmUgZXhwYW5kZWQg dGhpcyB0bw0KPiA+ICJsaW5rIGxheWVyIHBvcnQgdW5pcXVlIHVuaWNhc3QgZGVzdGluYXRpb24g YWRkcmVzcyINCj4gPg0KPiA+IEFrYTogTVBMUyBvciBldGhlcm5ldCBoYXZlIHVuaXF1ZSBsaW5r IGxheWVyIGRlc3RpbmF0aW9uIGRlc3RpbmF0aW9uIGFkZHJlc3NlcyAobGFiZWwgb3IgZGVzdGlu YXRpb24gTUFDKS4gSWYgeW91IHRoaW5rIGFib3V0IGluY29ycmVjdGx5IHBsdWdnZWQgSERMQyBs aW5rcyAoc3VjaCBhcyBvbGQgVDEvVDMvLi4uIGxpbmtzKSwgdGhleSBvbmx5IGhhdmUgMiBnZW5l cmljIGFkZHJlc3NlcywgaWYgaSByZW1lbWJlciAxIG9yIDMgaW4gdGhlIEhETEMgZnJhbWUuIFNv IHdoZW4geW91IG1pc3BsdWcgb25lIG9mIHRob3NlIHAycCBjYWJsZXMgd3JvbmcsIHRoZSBwYWNr ZXRzIHdvdWxkIGJlIGluY3JyZWN0bHkgcmVjZWl2ZWQgYnkgdGhlIHdyb25nIHJlY2VpdmVyIG5v ZGUgYW5kIHRoZW4gRE5SIGNvdWxkIGNhdXNlIHBlcnNpc3RlbnQgbG9vcHMgb25seSBzb2x2ZWQg YnkgVFRMLg0KPiA+DQo+ID4gWnpoPiAiQ29uc2lkZXIgaW4gdGhlIHJpbmcgcGljdHVyZSB0aGF0 IGxpbmsgTDQgZnJvbSBCRlIzIGlzIHBsdWdnZWQgaW50byB0aGUgTDEgaW50ZXJmYWNlIG9mIEJG UmEiIC0gc3RpbGwgbm90IHN1cmUgaG93IGxhYmVsL21hYyBoZWxwcyBoZXJlLiBJIHN1cHBvc2Ug dGhlIHJpbmcgdG9wb2xvZ3kgaXMgZGlzY292ZXJlZC92ZXJpZmllZCBieSB0aGUgY29udHJvbCBw bGFuZSBhbmQgd2hlbiB0aGUgbWlzY2FsbGluZyBoYXBwZW5zIHRoZW4gdGhlIHJpbmcgd2lsbCBu b3QgaW5jbHVkZSB0aGUgQkZSMS9CRlIyIHBhcnQgYW5kIEJGUjMgd2lsbCBub3QgaGF2ZSB0aGUg RE5SIHNldD8gSWYgcmluZyBkaXNjb3ZlcnkvdmFyaWNhdGlvbiBpcyBub3QgZG9uZSB0aGVuIHBl cmhhcHMgd2Ugc2hvdWxkIHBvaW50IG91dCB0aGF0IFJQRiBiYXNlZCBvbiBsaW5rIGxheWVyIGFk ZHJlc3MgaXMgbmVlZGVkIC0gdGhlIGtleSBpcyBSUEYgKHdoaWNoIG5lZWRzIHVuaXF1ZSBsaW5r IGxheWVyIGFkZHJlc3MpPw0KPg0KPiBGb3JnZXQgUlBGLiBCSUVSKC1URSkgaGFzIG5vIFJQRiAo aXNzdWVzKS4gSXRzIGp1c3QgbGlrZSB1bmljYXN0LiBSUEYNCj4gaXMganVzdCBhIHByb2JsZW0g Zm9yIHJlY2VpdmVyIG9yaWdpbmF0ZWQgam9pbnMgbGlrZSBpbiBQSU0vbUxEUCwgYnV0DQo+IG5v dCB1bmljYXN0L2JpZXIoLXRlKS9SU1ZQLVRFLg0KPg0KPiBGb3J3YXJkX2Nvbm5lY3RlZCBpcyBq dXN0IGxpa2UgYSB1bmljYXN0IHN1Ym5ldCBhZGphY2VuY3kgdG8gYSBkaXJlY3QNCj4gbmVpZ2hi b3I6IEludGVyZmFjZSBhbmQgTDIgYWRkcmVzc3Mgb2YgdGhlIGRlc3RpbmF0aW9uLg0KPg0KPiBU aGUgY29udHJvbGxlciAoY291bGQgYmUgYSBodW1hbikgImFzc3VtZXMiIGEgcGFydGljdWxhciBw aHlzaWNpYWwNCj4gdG9wb2xvZ3ksIGZyb20gdGVsZW1ldHJ5L2tub3dsZWRnZS93aGF0ZXZlci4g SXQgdGhlbiBjYWxjdWxhdGVzIHRoZQ0KPiBkZXNpcmVkIEJJRVItVEUgdG9wb2xvZ3kgYW5kIHB1 c2hlcyBpdCBkb3duLiBUaGlzIHRvcG9sb2d5IGlzIG1lYW50IHRvDQo+IGJlIGxvb3AgZnJlZSBv ZiBjb3Vyc2Ugd3J0IHRvIHRoZSBjb25maWd1cmVkIGFkamFjZW5jaWVzLg0KPiBJbiB0aGlzIEJJ RVItVEUgdG9wb2xvZ3ksIEJGUjMgd2lsbCBoYXZlIGEgQlAgd2l0aCB0aGUNCj4gZm9yd2FyZF9j b25uZWN0ZWQoTDQsIE1BQy1vZi1CRlIyKSBhZGphY2VuY3kuDQo+DQo+IElmIHRoZSBjYWJsZSBj b25uZWN0aW5nIHRvIEw0IGlzIG1pc3dpcmVkLCB0aGVuIEJGUjMgd291bGQgc3RpbGwgc2VuZA0K PiB0aGUgcGFja2V0cyB0byB0aGUgTUFDIGFkZHJlc3Mgb2YgQkZSMiwgYnV0IGdpdmVuIGhvdyB0 aGUgY2FibGUNCj4gY29ubmVjdHMgdG8gc29tZSBvdGhlciBub2RlLCB0aGVzZSBwYWNrZXRzIHdp bGwgYmUgZGlzY2FyZGVkIGJ5IHRoYXQNCj4gbm9kZS4gYmVjYXVzZSB0aGV5J3JlIGp1c3QgTDIg dW5pY2FzdCBwYWNrZXRzLg0KPg0KPiBJIHRoaW5rIHRoaXMgaXMgZXF1YWxseSB0cnVlIHdoZW4g d2UgaGF2ZSBub3JtYWwgQklFUi9NUExTIGVuYWNwLg0KPiBUaG9zZSBwYWNrZXRzIHRvbyBhcmUg YWRkcmVzc2VkIHRvIHRoZSB1bmljYXN0IE1BQyBhZGRyZXNzIG9mIHRoZQ0KPiBuZWlnaGJvci4N Cj4NCj4gTm93LCBpZi93aGVuIGhlIGNvbnRyb2xsZXIgcmVjb2duaXplcyB0aGF0IHRoZSBwaHlz aWNhbCB0b3BvbG9neSBoYXMNCj4gY2hhbmdlZCwgdGhhdHMgYSBjb21wbGV0ZWx5IGRpZmZlcmVu dCBzdG9yeSBhbmQgbm90IGFkZHJlc3NlZCBoZXJlLg0KPiBHaXZlbiBob3cgd2UgYXNzdW1lZCB0 aGlzIHdhcyBhIGNhYmxpbmcgbWlzdGFrZSwgdGhlIGNvbnRyb2xsZXIgd291bGQNCj4gcHJvYmFi bHkgb25seSBjb21wbGFpbiBhYm91dCB0aGUgbWlzd2lyaW5nIHRvIG9wZXJhdGlvbnMgYnV0IGJl IGhhcHB5DQo+IHRoYXQgdGhlIGZvcndhcmRpbmcgcGxhbmUganVzdCBtYWtlcyBwYWNrZXRzIGZh aWwgaW5zdGVhZCBvZiBsb29wLiBJZg0KPiB0aGlzIHdhcyBhIHBsYW5uZWQgY2hhbmdlIHByb2Nl c3MsIHRoZW4gaXQgd2lsbCBiZSBzaW1pbGFyaWx5DQo+IGNvbnZvbHV0ZWQgYXMgaXQgd291bGQg dG9kYXkgYmUgd2l0aCByZXdpcmluZyBjYWJsZXMgaW4gYW4NCj4gU1ItTVBMUy9TUnY2IHRvcG9s b2d5IGFuZCB1cGRhdGluZyBTSURzLg0KPg0KPiA+ID4gQmVjYXVzZSB0aGUgZm9yd2FyZGluZyBp cyBkaWZmZXJlbnQgZnJvbSBCSUVSIGZvcndhcmRpbmcgKGJlY2F1c2Ugb2YgWzFdIGFib3ZlKSwg d2UgbWlnaHQgYXMgd2VsbCBpbnRyb2R1Y2UgYW4gb3B0aW1pemF0aW9uIGhlcmUgPz8/IGZvciBl YWNoIEJJRlQsIGNhbGN1bGF0ZSB0aGUgRi1CTSBvZiB0aGUgQklGVCBpdHNlbGYgKHRoZSBsb2dp Y2FsID8/P29yPz8/IG9mIGFsbCB0aGUgQlBzIHByZXNlbnRlZCBpbiB0aGlzIEJJRlQpIGFuZCB0 aGVuIHVzZSAocGFja2V0LT5iaXRzdHJpbmcgJiBCSUZULkYtQk0pIGFzIHRoZSBpbnB1dCB0byBH ZXRGaXJzdC9OZXh0Qml0UG9zaXRpb24oKS4gVGhhdCBzaG91bGQgc2tpcCBtYW55IGJpdHMuDQo+ ID4NCj4gPiBSaWdodC4gQnV0IGkgZXhwbGljaXRseSByZW1vdmVkIHRob3NlIG9wdGltaXphdGlv bnMgKGkgaGFkIHRoZW0gaW4gb2xkZXIgZHJhZnQgdmVyc2lvbnMpIGJlY2F1c2UgdGhlIHdob2xl IGlkZWEgb2YgdGhpcyBwaWN0dXJlIGlzIHNvbGVseSB0aGUgY29tcGFyaXNvbiB3aXRoIGZpZ3Vy ZSA0IG9mIFJGQzgyNzkuDQo+ID4NCj4gPiBaemg+IEkgdGhpbmsgaXQncyB3b3J0aCBwb2ludCB0 aGF0IG9wdGltaXphdGlvbiBvdXQ7IHlvdSBjYW4gbWFyayBpdCBvcHRpb25hbCBpZiB5b3Ugd2Fu dCB0byBlbXBoYXNpemUgdGhlIHNpbWlsYXJpdHkgdG8gQklFUiBmb3J3YXJkaW5nLCBidXQgc2lu Y2UgQklFUiBmb3J3YXJkaW5nIGRvZXMgZG8gdGhlIG1hc2tvZmYgc3RlcCwgaXQgaXMgdmVyeSBl ZmZpY2llbnQgd2hpbGUgQklFUi1URSBmb3J3YXJkaW5nIGRvZXMgbm90IGl0IHRoZSBtYXNrb2Zm IHN0ZXAgc28gdGhpcyBvcHRpbWl6YXRpb24gaXMgaW1wb3J0YW50Lg0KPg0KPiBPay4gSSBzaW1w bGlmaWVkIHRoZSB0ZXh0IGNvbXBhcmlzb24gQklFUi9CSUVSLVRFIHdydC4gdG8gdGhlIEZCTQ0K PiBydWxlcyBbMV0gYW5kIFsyXSBhbmQgYWRkZWQgZm9sbG93aW5nIHBhcmFncmFwaDoNCj4NCj4g PHQ+SW4gQklFUiwgdGhlIG9yZGVyIG9mIEJQcyBpbXBhY3RzIHRoZSByZXN1bHQgb2YgZm9yd2Fy ZGluZyBiZWNhdXNlIG9mIFsxXS4NCj4gSW4gQklFUi1URSwgZm9yd2FyZGluZyBpcyBub3QgaW1w YWN0ZWQgYnkgdGhlIG9yZGVyIG9mIEJQcy4gSXQgaXMNCj4gdGhlcmVmb3JlIHBvc3NpYmxlIHRv IGZ1cnRoZXIgb3B0aW1pemUgZm9yd2FyZGluZyB0aGFuIGluIEJJRVIuIEZvcg0KPiBleGFtcGxl IHBhcmFsbGVsaXppbmcgZm9yd2FyZGluZyBhY3Jvc3MgbXVsdGlwbGUgRlBFIGNvcmVzIG9yDQo+ IGRpc3RyaWJ1dGVkIGxpbmVjYXJkcyBkb2VzIG9ubHkgbmVlZCB0byBleGFtaW5lIGFuIGFyYml0 cmFyeSBzdWJzZXQgb2YNCj4gQlAgYW5kIG5vdCBldmFsdWF0ZSB0aGUgZGVwZW5kZW5jeSBiZXR3 ZWVuIEJQcy48L3Q+DQo+DQo+ID4gPiAgICBUaGUgZm9sbG93aW5nIHBzZXVkb2NvZGUgaXMgY29t cHJlaGVuc2l2ZToNCj4gPiA+DQo+ID4gPiBUaGUgYWJvdmUgc2VudGVuY2UgcmVhZHMgYSBiaXQg c3RyYW5nZSAob3IgbGFja3Mgc29tZSBzZWd1ZSkuLg0KPiA+DQo+ID4gSSBob3BlIG5vdCwgYnV0 IG1heWJlIGJlc3QgbGVmdCB0byBhIG5hdGl2ZSBlbmdsaXNoIHNwZWFrZXIgKFJGQy1lZGl0b3Ip Lg0KPiA+DQo+ID4gVGhlIGZpcnN0IChSRkM4Mjc5KSBwc2V1ZG9jb2RlIHdhcyBzaW1wbGlmaWVk LiBUaGUgc2Vjb25kIG9uZSBpcyBjb21wcmVoZW5zaXZlLiBJZiBub3QgY29tcHJlaGVuc2l2ZSwg d2hhdHMgYSBnb29kIG9wcG9zaXRlIG9mIHNpbXBsaWZpZWQgPw0KPiA+DQo+ID4gWnpoPiBQZXJo YXBzICJUaGUgYWJvdmUgc2ltcGxpZmllZCBwc2V1ZG9jb2RlIGlzIGVsYWJvcmF0ZWQgZnVydGhl ciBhcyBmb2xsb3dpbmciPw0KPiA+IFp6aD4gSmVmZnJleQ0KPg0KPiBEb25lLg0KPg0KPiBUaGFu a3MgYSBsb3QuDQo+DQo+DQo+ID4NCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiA+IEZyb206IEJJRVIgW2JpZXItYm91bmNlc0BpZXRmLm9yZzxtYWls dG86Ymllci1ib3VuY2VzQGlldGYub3JnPjxtYWlsdG86Ymllci1ib3VuY2VzQGlldGYub3JnPG1h aWx0bzpiaWVyLWJvdW5jZXNAaWV0Zi5vcmc+Pl0NCj4gPiA+IG9uIGJlaGFsZiBvZiBUb2VybGVz cyBFY2tlcnQgW3R0ZUBjcy5mYXUuZGU8bWFpbHRvOnR0ZUBjcy5mYXUuZGU+PG1haWx0bzp0dGVA Y3MuZmF1LmRlPG1haWx0bzp0dGVAY3MuZmF1LmRlPj5dDQo+ID4gPiBTZW50OiBUdWVzZGF5LCBK dWx5IDA5LCAyMDE5IDIzOjM4DQo+ID4gPiBUbzogTWlrZSBNY0JyaWRlDQo+ID4gPiBDYzogR3Jl ZyBTaGVwaGVyZDsgQklFUiBXRzsgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KQ0KPiA+ID4gU3Vi amVjdDogUmU6IFtCaWVyXSBXR0xDIC0gZHJhZnQtaWV0Zi1iaWVyLXRlLWFyY2gNCj4gPiA+DQo+ ID4gPiBUaGFua3MsIE1pa2UNCj4gPiA+DQo+ID4gPiBUaGUgYXV0aG9ycyBhbHNvIHJldmlld2Vk IHRoZSBkb2N1bWVudCBhbmQgY29uY2x1ZGVkIHRoYXQgaXQgd2FzDQo+ID4gPiByZWFsbHkgaGFy ZCB0byBnZXQgaW50byB0aGUgZG9jdW1lbnQgY29udGV4dCBiZWNhdXNlIG9mIHRvbyBtYW55DQo+ ID4gPiBmb3J3YXJkIGRlcGVuZGVuY2llcy4gV2UgdHJpZWQgdG8gZml4IHRoaXMgYnkgYWRkaW5n IHR3byBob3BlZnVsbHkNCj4gPiA+IGdvb2QgJiBiYXNpYyBleGFtcGxlcyBpbnRvIHRoZSBJbnRy b2R1Y3Rpb24gc2VjdGlvbiBhbmQgdXNpbmcgdGhlbQ0KPiA+ID4gdG8gYWxzbyBhZGQgYSBiZXR0 ZXIgZGVmaW5pdGlvbiBvZiB0aGUgdGVybSAiQklFUi1URSBUb3BvbG9neSIgaW4gdGhlIEludHJv ZHVjdGlvbi4NCj4gPiA+IEhvcGVmdWxseSB0aGlzIG1ha2VzIHJlYWRpbiB0aGUgcmVzdCBvZiB0 ZSBkb2N1bWVudCBzbW9vdGhlci4uDQo+ID4gPg0KPiA+ID4gQWxzbyBpbXByb3ZlZCB0ZXh0IG9m IEFic3RyYWN0IGFuZCByZWZpbmVkIHRleHQgY29tcGFyaWluZyBCSUVSLVRFIHdpdGggU1IuDQo+ ID4gPg0KPiA+ID4gaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHA6Ly90b29scy5pZXRm Lm9yZy8qcmZjZGlmZj91cmwxPWh0dHBzPGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRw Oi90b29scy5pZXRmLm9yZy8qcmZjZGlmZj91cmwxPWh0dHBzPjoNCj4gPiA+ICoqQXRvb2xzLmll dGYub3JnPGh0dHA6Ly9BdG9vbHMuaWV0Zi5vcmc+KmlkKmRyYWZ0LWlldGYtYmllci10ZS1hcmNo LTAyLnR4dCZ1cmwyPWh0dHBzOioqQQ0KPiA+ID4gdG9vbA0KPiA+ID4gcy5pZXRmLm9yZzxodHRw Oi8vcy5pZXRmLm9yZz4qaWQqZHJhZnQtaWV0Zi1iaWVyLXRlLWFyY2gtMDMudHh0X187THk4dkx5 OHZMeTh2IThXb0E2Ug0KPiA+ID4gakM4MQ0KPiA+ID4gYyFYdkg0QUF4ZnJEakZvS19zZXJjd1pN c2MwTzVONDJlRU5PczRsX3Fkc1hGMEt3WkQ4MmNKTERGRk5WX2VUVUVoDQo+ID4gPiAkDQo+ID4g PiA8aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHA6L3Rvb2xzLmlldGYub3JnLypyZmNk aWZmP3VybDE9aHR0cHM6DQo+ID4gPiAqKkF0b29scy5pZXRmLm9yZzxodHRwOi8vQXRvb2xzLmll dGYub3JnPippZCpkcmFmdC1pZXRmLWJpZXItdGUtYXJjaC0wMi50eHQmdXJsMj1odHRwczoqKkEN Cj4gPiA+IHRvb2wNCj4gPiA+IHMuaWV0Zi5vcmc8aHR0cDovL3MuaWV0Zi5vcmc+KmlkKmRyYWZ0 LWlldGYtYmllci10ZS1hcmNoLTAzLnR4dF9fO0x5OHZMeTh2THk4diE4V29BNlINCj4gPiA+IGpD ODENCj4gPiA+IGMhVUJUR3ZXV3BNSHllaVNhbnhzNnZJYl9FbkJWZ3lnNmJvQUFXNG5ycWp1OFVD TE9naXVYYzhZXzZzTmQxbmpjWA0KPiA+ID4gJD4NCj4gPiA+DQo+ID4gPiBDaGVlcnMNCj4gPiA+ ICAgICBUb2VybGVzcw0KPiA+ID4NCj4gPiA+IE9uIFdlZCwgSnVuIDI2LCAyMDE5IGF0IDEwOjM5 OjM2QU0gLTA3MDAsIE1pa2UgTWNCcmlkZSB3cm90ZToNCj4gPiA+ID4gSG93IGFib3V0IHRocmVl PyBJIHN1cHBvcnQuDQo+ID4gPiA+IG1pa2UNCj4gPiA+ID4NCj4gPiA+ID4gT24gVHVlLCBKdW4g MjUsIDIwMTkgYXQgMTA6NDIgQU0gR3JlZyBTaGVwaGVyZCA8Z2pzaGVwQGdtYWlsLmNvbTxtYWls dG86Z2pzaGVwQGdtYWlsLmNvbT48bWFpbHRvOmdqc2hlcEBnbWFpbC5jb208bWFpbHRvOmdqc2hl cEBnbWFpbC5jb20+Pj4gd3JvdGU6DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBXZSBjYW5ub3QgdGFr ZSB0d28gJ3llcycgdm90ZXMgYW5kIFdHIGNvbnNlbnN1cy4NCj4gPiA+ID4gPiBQbGVhc2UsIHJl YWQgYW5kIHJlc3BvbmQuIElmIHlvdSBkb24ndCBzdXBwb3J0LCB0aGVuIHBsZWFzZSB2b3RlIGFz IG11Y2ggcHVibGljbHkgcmlnaHQgaGVyZS4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFRoYW5rcywN Cj4gPiA+ID4gPiBHcmVnDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBPbiBNb24sIEp1biAzLCAyMDE5 IGF0IDEwOjA1IFBNIFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgPHB0aHViZXJ0QGNpc2NvLmNv bTxtYWlsdG86cHRodWJlcnRAY2lzY28uY29tPjxtYWlsdG86cHRodWJlcnRAY2lzY28uY29tPG1h aWx0bzpwdGh1YmVydEBjaXNjby5jb20+Pj4gd3JvdGU6DQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+ IFN1cHBvcnQ6DQo+ID4gPiA+ID4+DQo+ID4gPiA+ID4+IEkgc2VlIGdyZWF0IHZhbHVlIGluIGRl dGVybWluaXN0aWMgbmV0d29ya3MgYXMgd2VsbCBhcyBJT1QgKHdpdGggUlBMKS4NCj4gPiA+ID4g Pj4NCj4gPiA+ID4gPj4gQWxsIHRoZSBiZXN0LA0KPiA+ID4gPiA+Pg0KPiA+ID4gPiA+PiBQYXNj YWwNCj4gPiA+ID4gPj4NCj4gPiA+ID4gPj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiA+ID4gPiA+PiA+IEZyb206IEJJRVINCj4gPiA+ID4gPj4gPiA8Ymllci1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzpiaWVyLWJvdW5jZXNAaWV0Zi5vcmc+PG1haWx0bzpiaWVyLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOmJpZXItYm91bmNlc0BpZXRmLm9yZz4+PiBPbg0KPiA+ID4gPiA+PiA+IEJl aGFsZiBPZiBUb2VybGVzcyBFY2tlcnQNCj4gPiA+ID4gPj4gPiBTZW50OiBtYXJkaSA0IGp1aW4g MjAxOSAwMjowMw0KPiA+ID4gPiA+PiA+IFRvOiBHcmVnIFNoZXBoZXJkDQo+ID4gPiA+ID4+ID4g PGdqc2hlcEBnbWFpbC5jb208bWFpbHRvOmdqc2hlcEBnbWFpbC5jb20+PG1haWx0bzpnanNoZXBA Z21haWwuY29tPG1haWx0bzpnanNoZXBAZ21haWwuY29tPj4+DQo+ID4gPiA+ID4+ID4gQ2M6IEJJ RVIgV0cgPGJpZXJAaWV0Zi5vcmc8bWFpbHRvOmJpZXJAaWV0Zi5vcmc+PG1haWx0bzpiaWVyQGll dGYub3JnPG1haWx0bzpiaWVyQGlldGYub3JnPj4+DQo+ID4gPiA+ID4+ID4gU3ViamVjdDogUmU6 IFtCaWVyXSBXR0xDIC0gZHJhZnQtaWV0Zi1iaWVyLXRlLWFyY2gNCj4gPiA+ID4gPj4gPg0KPiA+ ID4gPiA+PiA+ICsxDQo+ID4gPiA+ID4+ID4gT2J2aW91c2x5IHN1cHBvcnQgYXMgY28tYXV0aG9y Lg0KPiA+ID4gPiA+PiA+DQo+ID4gPiA+ID4+ID4gT24gV2VkLCBNYXkgMjksIDIwMTkgYXQgMTI6 NDE6MjZQTSAtMDcwMCwgR3JlZyBTaGVwaGVyZCB3cm90ZToNCj4gPiA+ID4gPj4gPiA+IFBsZWFz ZSByZWFkIGFuZCByZXNwb25kIHRvIHRoaXMgdGhyZWFkIHcvIG9yIHcvbyBzdXBwb3J0Lg0KPiA+ ID4gPiA+PiA+ID4NCj4gPiA+ID4gPj4gPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19o dHRwczovL2RhdGF0cmFja2VyLi5pZXRmLm9yZzxodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19f aHR0cHM6L2RhdGF0cmFja2VyLi5pZXRmLm9yZz4NCj4gPiA+ID4gPj4gPiA+IC9kb2MNCj4gPiA+ ID4gPj4gPiA+IC9kcmFmdC1pZXRmLWJpZXItdGUtYXJjaC9fXzshOFdvQTZSakM4MWMhWHZINEFB eGZyRGpGb0tfcw0KPiA+ID4gPiA+PiA+ID4gZXJjdyBaTXNjME81TjQyZUVOT3M0bF9xZHNYRjBL d1pEODJjSkxERkZOVjllQ2xCaiQNCj4gPiA+ID4gPj4gPiA+IDxodHRwczovL3VybGRlZmVuc2Uu Y29tL3YzL19faHR0cHM6L2RhdGF0cmFja2VyLmlldGYub3JnLw0KPiA+ID4gPiA+PiA+ID4gZG9j Lw0KPiA+ID4gPiA+PiA+ID4gZHJhZnQtaWV0Zi1iaWVyLXRlLWFyY2gvX187IThXb0E2UmpDODFj IVVCVEd2V1dwTUh5ZWlTYW54DQo+ID4gPiA+ID4+ID4gPiBzNnZJIGJfRW5CVmd5ZzZib0FBVzRu cnFqdThVQ0xPZ2l1WGM4WV82c0Q0MGttdEgkPg0KPiA+ID4gPiA+PiA+ID4NCj4gPiA+ID4gPj4g PiA+IFZvdGUgZW5kcyA1IEp1bmUgMjAxOS4NCj4gPiA+ID4gPj4gPiA+DQo+ID4gPiA+ID4+ID4g PiBUaGFua3MsDQo+ID4gPiA+ID4+ID4gPiBTaGVwDQo+ID4gPiA+ID4+ID4gPiAoY2hhaXJzKQ0K PiA+ID4gPiA+PiA+DQo+ID4gPiA+ID4+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+PiA+ID4gQklFUiBtYWlsaW5nIGxpc3QNCj4g PiA+ID4gPj4gPiA+IEJJRVJAaWV0Zi5vcmc8bWFpbHRvOkJJRVJAaWV0Zi5vcmc+PG1haWx0bzpC SUVSQGlldGYub3JnPG1haWx0bzpCSUVSQGlldGYub3JnPj4NCj4gPiA+ID4gPj4gPiA+IGh0dHBz Oi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuLzxodHRw czovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3d3dy5pZXRmLm9yZy9tYWlsbWFuLz4NCj4g PiA+ID4gPj4gPiA+IGxpc3QNCj4gPiA+ID4gPj4gPiA+IGluZm8vYmllcl9fOyE4V29BNlJqQzgx YyFYdkg0QUF4ZnJEakZvS19zZXJjd1pNc2MwTzVONDJlRQ0KPiA+ID4gPiA+PiA+ID4gTk9zNCBs X3Fkc1hGMEt3WkQ4MmNKTERGRk5UMldWWFdYJA0KPiA+ID4gPiA+PiA+ID4gPGh0dHBzOi8vdXJs ZGVmZW5zZS5jb20vdjMvX19odHRwczovd3d3LmlldGYub3JnL21haWxtYW4vDQo+ID4gPiA+ID4+ ID4gPiBsaXN0DQo+ID4gPiA+ID4+ID4gPiBpbmZvL2JpZXJfXzshOFdvQTZSakM4MWMhVUJUR3ZX V3BNSHllaVNhbnhzNnZJYl9FbkJWZ3lnNmINCj4gPiA+ID4gPj4gPiA+IG9BQVcgNG5ycWp1OFVD TE9naXVYYzhZXzZzS24yS29BVCQ+DQo+ID4gPiA+ID4+ID4NCj4gPiA+ID4gPj4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+PiA+IEJJ RVIgbWFpbGluZyBsaXN0DQo+ID4gPiA+ID4+ID4gQklFUkBpZXRmLm9yZzxtYWlsdG86QklFUkBp ZXRmLm9yZz48bWFpbHRvOkJJRVJAaWV0Zi5vcmc8bWFpbHRvOkJJRVJAaWV0Zi5vcmc+Pg0KPiA+ ID4gPiA+PiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpPGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovd3d3LmlldGYu b3JnL21haWxtYW4vbGk+DQo+ID4gPiA+ID4+ID4gc3Rpbg0KPiA+ID4gPiA+PiA+IGZvL2JpZXJf XzshOFdvQTZSakM4MWMhWHZINEFBeGZyRGpGb0tfc2VyY3daTXNjME81TjQyZUVOT3M0DQo+ID4g PiA+ID4+ID4gbF9xZA0KPiA+ID4gPiA+PiA+IHNYRjBLd1pEODJjSkxERkZOVDJXVlhXWCQNCj4g PiA+ID4gPj4gPiA8aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saQ0KPiA+ID4gPiA+PiA+IHN0aW4NCj4gPiA+ID4gPj4gPiBmby9iaWVyX187 IThXb0E2UmpDODFjIVVCVEd2V1dwTUh5ZWlTYW54czZ2SWJfRW5CVmd5ZzZib0FBVw0KPiA+ID4g PiA+PiA+IDRucnENCj4gPiA+ID4gPj4gPiBqdThVQ0xPZ2l1WGM4WV82c0tuMktvQVQkPg0KPiA+ ID4gPiA+DQo+ID4gPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPiA+ID4gPiBCSUVSIG1haWxpbmcgbGlzdA0KPiA+ID4gPiA+IEJJRVJAaWV0 Zi5vcmc8bWFpbHRvOkJJRVJAaWV0Zi5vcmc+PG1haWx0bzpCSUVSQGlldGYub3JnPG1haWx0bzpC SUVSQGlldGYub3JnPj4NCj4gPiA+ID4gPiBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aTxodHRwczovL3VybGRlZmVuc2UuY29tL3Yz L19faHR0cHM6L3d3dy4uaWV0Zi5vcmcvbWFpbG1hbi9saXN0aT4NCj4gPiA+ID4gPiBuZm8vDQo+ ID4gPiA+ID4gYmllcl9fOyE4V29BNlJqQzgxYyFYdkg0QUF4ZnJEakZvS19zZXJjd1pNc2MwTzVO NDJlRU5PczRsX3Fkc1gNCj4gPiA+ID4gPiBGMEt3DQo+ID4gPiA+ID4gWkQ4MmNKTERGRk5UMldW WFdYJA0KPiA+ID4gPiA+IDxodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpDQo+ID4gPiA+ID4gbmZvLw0KPiA+ID4gPiA+IGJpZXJfXzsh OFdvQTZSakM4MWMhVUJUR3ZXV3BNSHllaVNhbnhzNnZJYl9FbkJWZ3lnNmJvQUFXNG5ycWp1DQo+ ID4gPiA+ID4gOFVDTA0KPiA+ID4gPiA+IE9naXVYYzhZXzZzS24yS29BVCQ+DQo+ID4gPg0KPiA+ ID4gLS0NCj4gPiA+IC0tLQ0KPiA+ID4gdHRlQGNzLmZhdS5kZTxtYWlsdG86dHRlQGNzLmZhdS5k ZT48bWFpbHRvOnR0ZUBjcy5mYXUuZGU8bWFpbHRvOnR0ZUBjcy5mYXUuZGU+Pg0KPiA+ID4NCj4g PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4g PiBCSUVSIG1haWxpbmcgbGlzdA0KPiA+ID4gQklFUkBpZXRmLi5vcmc8bWFpbHRvOkJJRVJAaWV0 Zi5vcmc+PG1haWx0bzpCSUVSQGlldGYub3JnPG1haWx0bzpCSUVSQGlldGYub3JnPj4NCj4gPiA+ IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvLzxodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvLz4NCj4gPiA+IGJpZXINCj4gPiA+IF9fOyE4V29BNlJqQzgxYyFY dkg0QUF4ZnJEakZvS19zZXJjd1pNc2MwTzVONDJlRU5PczRsX3Fkc1hGMEt3WkQ4Mg0KPiA+ID4g Y0pMRA0KPiA+ID4gRkZOVDJXVlhXWCQNCj4gPiA+IDxodHRwczovL3VybGRlZmVuc2UuY29tL3Yz L19faHR0cHM6L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLw0KPiA+ID4gYmllcg0KPiA+ ID4gX187IThXb0E2UmpDODFjIVVCVEd2V1dwTUh5ZWlTYW54czZ2SWJfRW5CVmd5ZzZib0FBVzRu cnFqdThVQ0xPZ2l1DQo+ID4gPiBYYzhZDQo+ID4gPiBfNnNLbjJLb0FUJD4NCj4gPg0KPiA+IC0t DQo+ID4gLS0tDQo+ID4gdHRlQGNzLmZhdS5kZTxtYWlsdG86dHRlQGNzLmZhdS5kZT4NCj4NCj4g LS0NCj4gLS0tDQo+IHR0ZUBjcy5mYXUuZGU8bWFpbHRvOnR0ZUBjcy5mYXUuZGU+DQo+DQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEJJRVIgbWFp bGluZyBsaXN0DQo+IEJJRVJAaWV0Zi5vcmc8bWFpbHRvOkJJRVJAaWV0Zi5vcmc+DQo+IGh0dHBz Oi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2JpZXI8aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9iaWVyPg0KPiBfXzshIU5FdDZ5TWFPLWdrIVZ1UUNWSG5xSnlfYVlJ LUZOdDlBMWE1RXpIT0NyMGZaa0xQYmdnM0NQTnUwUHlyV3NyRng0DQo+IDFfaldWM1lVQTZEJA0K DQotLQ0KLS0tDQp0dGVAY3MuZmF1LmRlPG1haWx0bzp0dGVAY3MuZmF1LmRlPg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQklFUiBtYWlsaW5nIGxp c3QNCkJJRVJAaWV0Zi5vcmc8bWFpbHRvOkJJRVJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JpZXINCg== --_000_LEXPR01MB0495CB59CD2034FF8453A56996100LEXPR01MB0495DEUP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8q IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBk aXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkUtTWFpbEZvcm1hdHZvcmxhZ2UxOA0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRS1NYWlsRm9ybWF0dm9ybGFnZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCAyLjBjbSA3MC44NXB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iREUiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+U3VwcG9ydC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPktpbmQgcmVnYXJkcywgTmlscyBXYXJu a2U8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Wb246PC9i PiBCSUVSICZsdDtiaWVyLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPkltIEF1ZnRyYWcgdm9uIDwv Yj4NCkdyZWcgU2hlcGhlcmQ8YnI+DQo8Yj5HZXNlbmRldDo8L2I+IERpZW5zdGFnLCAxOC4gRmVi cnVhciAyMDIwIDIxOjQ2PGJyPg0KPGI+QW46PC9iPiBKZWZmcmV5IChaaGFvaHVpKSBaaGFuZyAm bHQ7enpoYW5nPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBiaWVyQGlldGYub3JnOyBUb2VybGVzcyBFY2tlcnQgJmx0O3R0ZUBjcy5mYXUuZGUmZ3Q7PGJy Pg0KPGI+QmV0cmVmZjo8L2I+IFtCaWVyXSBXR0xDIC0gZHJhZnQtaWV0Zi1iaWVyLXRlLWFyY2gg MSBXRUVLPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIFRvZXJs ZXNzIGFuZCBKZWZmcmV5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtYmllci10ZS1hcmNoLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1iaWVyLXRlLWFyY2gvPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUgbW9yZSB3ZWVrIG9mIFdHTEMuIFBsZWFzZSBy ZWFkIHRoZSBsYXRlc3QgcmV2IGFuZCByZXNwb25kIHRvIHRoaXMgdGhyZWFkIHcvd28gc3VwcG9y dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Q2hhaXJzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4oU2hlcCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ T24gVHVlLCBGZWIgMTgsIDIwMjAgYXQgMTI6MDcgUE0gSmVmZnJleSAoWmhhb2h1aSkgWmhhbmcg Jmx0O3p6aGFuZz08YSBocmVmPSJtYWlsdG86NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZyI+ NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgVG9lcmxlc3Ms PGJyPg0KPGJyPg0KVGhhbmtzITxicj4NCkkgc3VwcG9ydCBtb3ZpbmcgdGhpcyB0byB0aGUgbmV4 dCBzdGFnZS48YnI+DQo8YnI+DQpKZWZmcmV5PGJyPg0KPGJyPg0KT24gRnJpLCBOb3YgMDEsIDIw MTkgYXQgMDc6NDI6MzhQTSAmIzQzOzAxMDAsIFRvZXJsZXNzIEVja2VydCB3cm90ZTo8YnI+DQom Z3Q7IFRoYW5rcyBKZWZmPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgaGF2ZSBub3cgcHVzaGVkIG91 dCAtMDUgd2l0aCB0aGUgYW5zd2VycyBhbmQgaG9wZWZ1bGx5IHJlc29sdXRpb24gdG8gPGJyPg0K Jmd0OyB5b3VyIHBvaW50cyBpbiBlbWFpbCBiZWxvdy4mbmJzcDsgQmlnZ2VzdCBhZGRpdGlvbiB3 YXMgYSBzZWN0aW9uIGFib3V0IDxicj4NCiZndDsgcmV1c2Ugb2YgQlBzICh3aXRob3V0IEROUikg d2hpY2ggY2FtZSBvdXQgb2YgdGhlIGNvbmZ1c2lvbiBpIHRoaW5rIHRoZSA8YnI+DQomZ3Q7IHJl dXNlIGluIHRoZSBFQ01QIGV4YW1wbGUgcmFpc2VkLiBJIHdhcyBhZnJhaWQgc28gZmFyIHRvIGV4 cGxhbiB0aGF0IDxicj4NCiZndDsgYXMgaXQgbWF5IG5vdCBiZSBlYXN5IHRvIGFic29yYiBhbmQg dWx0aW1hdGVseSBpcyBzdHVmZiBvbmx5IDxicj4NCiZndDsgY29udHJvbGxlciBkZXZlbG9wZXJz IG5lZWQgdG8gdW5kZXJzdGFuZCwgYnV0IGhvcGVmdWxseSB1c2VmdWwuPGJyPg0KJmd0OyBBbmQg dGhlbiBvZiBjb3Vyc2UgdGhlIHN1bW1hcnkgb2YgQlAgb3B0aW1pemF0aW5zIHlvdSBhc2tlZCBm b3I8YnI+DQomZ3Q7IDxicj4NCiZndDsgRGlmZiBmcm9tIGxhc3QgdmVyc2lvbiBpIHNlbnQgeW91 Ojxicj4NCiZndDsgPGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3Yz L19faHR0cDovdG9vbHMuaWV0Zi5vcmcvKnJmY2RpZmY/dXJsMT1odHRwcyIgdGFyZ2V0PSJfYmxh bmsiPg0KaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHA6Ly90b29scy5pZXRmLm9yZy8q cmZjZGlmZj91cmwxPWh0dHBzPC9hPjo8YnI+DQomZ3Q7ICoqPGEgaHJlZj0iaHR0cDovL0FyYXcu Z2l0aHVidXNlcmNvbnRlbnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+QXJhdy5naXRodWJ1c2VyY29u dGVudC5jb208L2E+KnRvZXJsZXNzKmJpZXItdGUtYXJjaCptYXN0ZXIqZHJhZnQtaWV0Zi1iPGJy Pg0KJmd0OyBpZXItdGUtYXJjaC0wNS4xLnR4dCZhbXA7dXJsMj1odHRwOioqPGEgaHJlZj0iaHR0 cDovL0F0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkF0b29scy5pZXRmLm9yZzwvYT4q aWQqZHJhZnQtaWV0Zi1iaWVyLXRlPGJyPg0KJmd0OyAtYXJjaC0wNS50eHRfXztMeTh2THk4dkx5 OHZMeTghIU5FdDZ5TWFPLWdrIVZ1UUNWSG5xSnlfYVlJLUZOdDlBMWE1RXpIPGJyPg0KJmd0OyBP Q3IwZlprTFBiZ2czQ1BOdTBQeXJXc3JGeDQxX2pXWDJBdDhWLSQ8YnI+DQomZ3Q7IDxicj4NCiZn dDsgZnVsbCAtMDQgLSZndDsgMDUgZGlmZjo8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGEgaHJlZj0i aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHA6L3Rvb2xzLmlldGYub3JnLypyZmNkaWZm P3VybDE9aHR0cDoqIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3VybGRlZmVuc2UuY29tL3Yz L19faHR0cDovL3Rvb2xzLmlldGYub3JnLypyZmNkaWZmP3VybDE9aHR0cDoqPC9hPjxicj4NCiZn dDsgKjxhIGhyZWY9Imh0dHA6Ly9BdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5BdG9v bHMuaWV0Zi5vcmc8L2E+KmlkKmRyYWZ0LWlldGYtYmllci10ZS1hcmNoLTA0LnR4dCZhbXA7dXJs Mj1odHRwOioqQXRvb2xzLjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cDovL2lldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+aWV0Zi5vcmc8L2E+KmlkKmRyYWZ0LWlldGYtYmllci10ZS1hcmNoLTA1LnR4 dF9fO0x5OHZMeTh2THk4diEhTkV0NnlNYU8tZ2s8YnI+DQomZ3Q7ICFWdVFDVkhucUp5X2FZSS1G TnQ5QTFhNUV6SE9DcjBmWmtMUGJnZzNDUE51MFB5cldzckZ4NDFfaldhbmNweml2JDxicj4NCiZn dDsgPGJyPg0KJmd0OyBDb21tZW50cyBpbmxpbmUgYmVsb3cuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IENoZWVyczxicj4NCiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwO3RvZXJsZXNzPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IE9uIE1vbiwgT2N0IDI4LCAyMDE5IGF0IDA3OjUyOjU5UE0gJiM0MzswMDAwLCBK ZWZmcmV5IChaaGFvaHVpKSBaaGFuZyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsgSSBUaG91Z2h0IHUt dHVybiBpcyB0aGUgbW9zdCBzaW1wbGUgY29tcGFyaXNvbiBsZWFmIHZzLiBub24tbGVhZiBCRlIu PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBaemgmZ3Q7IFRoZSB0ZXh0IGluIHRoZSBl bWFpbCBpcyBzZXJpb3VzbHkgbWlzYWxpZ25lZC4gTG9va2luZyBhdCB0aGUgcGljdHVyZSBpbiB0 aGUgZGlmZiBsaW5rLCB3aGlsZSB5b3UgZ2F2ZSBhIFUtdHVybiBleGFtcGxlLCB0aG91Z2ggZXZl biBpZiBCRkVSMiBpcyBub3QgY29ubmVjdGVkIHRvIEJGUjImbmJzcDsgYnV0IG9ubHkgY29ubmVj dGVkIHRvIEJGRVIxIChoZW5jZSBubyBVLXR1cm4pLCB0aGVuIEJGRVIxIGlzIHN0aWxsIG5vdCBh IGxlYWYgQkZFUg0KIEkgc3VwcG9zZS4gVGhhdCdzIHdoeSBJIHNhaWQgdGhlIGZpcnN0IHNlbnRl bmNlIG9mIHRoZSBhYm92ZSBwYXJhZ3JhcGggaXMgZW5vdWdoIHRvIGRlZmluZSBMZWFmIEJGRVIg d2hpbGUgdGhlIGV4YW1wbGUgaXRzZWxmIGlzIGFjdHVhbGx5IG5vdCBuZWVkZWQuPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IEFyZ2guLi4gb2ssIGhhZCB0byBmaXggdHdvIHdvcmRzLCBCRklSLSZndDtC RkVSIGFuZCBsZWZ0LWhhbmQgLSZndDsgcmlnaHQtaGFuZDo8YnI+DQomZ3Q7IDxicj4NCiZndDsg Q29uc2lkZXIgaG93IHJlZHVuZGFudCBkaXNqb2ludCB0cmFmZmljIGNhbiByZWFjaCBCRkVSMS9C RkVSMiBpbiBhYm92ZSA8YnI+DQomZ3Q7IHBpY3R1cmU6IFdoZW4gQkZFUjEvQkZFUjIgYXJlIE5v bi1MZWFmIEJGRVIgYXMgc2hvd24gb24gdGhlIHJpZ2h0IGhhbmQgPGJyPg0KJmd0OyBzaWRlLCBv bmUgdHJhZmZpYyBjb3B5IHdvdWxkIGJlIGZvcndhcmRlZCB0byBCRkVSMSBmcm9tIEJGUjEsIGJ1 dCB0aGUgPGJyPg0KJmd0OyBvdGhlciBvbmUgY291bGQgb25seSByZWFjaCBCRkVSMSB2aWEgQkZF UjIsIHdoaWNoIG1ha2VzIEJGRVIyIGEgPGJyPg0KJmd0OyBub24tTGVhZiBCRkVSLiBMaWtld2lz ZSBCRkVSMSBpcyBhIG5vbi1MZWFmIEJGRVIgd2hlbiBmb3J3YXJkaW5nIDxicj4NCiZndDsgdHJh ZmZpYyB0byBCRkVSMjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IFp6aCZndDsgQWRkaXRpb25h bGx5LCBpbiBsZWZ0IHBhcnQgb2YgdGhlIHBpY3R1cmUgeW91IGFkZGVkLCBpZiBzb21lIGZhaWx1 cmUgbGVhZHMgdG8gQkZSMiB0byBiZSBvbmx5IHJlYWNoYWJsZSB2aWEgQkZFUjEsIHRoZW4gQkZF UjEgaXMgbm8gbG9uZ2VyIGEgbGVhZiBCRkVSLg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFkZGVk IHNlbnRlbmNlOjxicj4NCiZndDsgPGJyPg0KJmd0OyAmbHQ7dCZndDtOb3RlIHRoYXQgdGhlIEJG RVIgaW4gdGhlIGxlZnQgaGFuZCBwaWN0dXJlIGFyZSBvbmx5IGd1YXJhbnRlZWQgdG8gPGJyPg0K Jmd0OyBiZSBsZWFmLUJGUiBieSBmaXR0aW5nIHJvdXRpbmcgY29uZmlndXJhdGlvbiB0aGF0IHBy b2hpYml0cyB0cmFuc2l0IDxicj4NCiZndDsgdHJhZmZpYyB0byBwYXNzIHRocm91Z2ggYSBQRSwg d2hpY2ggaXMgY29tbW9ubHkgYXBwbGllZCBpbiB0aGVzZSA8YnI+DQomZ3Q7IHRvcG9sb2dpZXMu Jmx0Oy90Jmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IEkgYXNzdW1lIHlvdSBkb24ndCBy ZWFzc2lnbiBCUHMgd2hlbiBsaW5rcyBnbyB1cCBhbmQgZG93bi48YnI+DQomZ3Q7IDxicj4NCiZn dDsgSSBkaWRuJ3Qgd2FudCB0byBkaXNjdXNzIHRoYXQgb3B0aW9uIGluIHRoaXMgZG9jdW1lbnQu IEl0cyBvYnZpb3VzbHkgPGJyPg0KJmd0OyBwZXJmZWN0bHkgZmVhc2libGUsIGJ1dCBiZSB5ZXQg YSBiaWcgYW1vdW50IG9mIHRleHQgKGVzcGVjaWFsbHkgdGhlIDxicj4NCiZndDsgY29uc2lkZXJh dGlvbnMgaG93IHRvIGRvIHRoaXMgbWFrZS1iZWZvcmUtYnJlYWsuIEZ1dHVyZSBkb2MuPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBidXQgc3Vic2VxdWVudCBwb2xhcml6YXRpb24gZXhh bXBsZSBjb25mdXNlcyBtZS4gSXQgc2VlbXMgdGhhdCBCUCAwOjYgaXMgYXNzaWduZWQgdG8gdGhl IHJvdXRlZCBhZGphY2VuY3kgQkZSMTAgKHdoaWNoIGlzIGFjdHVhbGx5IHRhbGtlZCBhYm91dCBp biBTZWN0aW9uIDQuOCkuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBTZWN0aW9uIDQu NyBkb2VzIG5vdCBtZW50aW9uICZxdW90O3JvdXRlZCZxdW90OyBhdCBhbGwsIHNvIHRoZXJlIGFy ZSBubyByb3V0ZWQgYWRqYWNlbmNpZXMgYXQgYWxsIHVzZWQgaW4gNC43LiBTbyBpIGFtIG5vdCBz dXJlIHdoYXQgeW91IGFyZSBjb25mdXNlZCBhYm91dC48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7IFp6aCZndDsgJnF1b3Q7VGhlIEJJRlQgb2YgZWFjaCBCRlIgYXJlIG9ubHkgcG9wdWxh dGVkIHdpdGggQlBzIHRoYXQgYXJlIGFkamFjZW50IHRvIHRoZSBCRlIgaW4gdGhlIEJJRVItVEUg dG9wb2xvZ3kmcXVvdDsuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IENvcnJlY3QgdGV4dCBmcm9tIHRo ZSBpbnRyb2R1Y3Rpb24uIE9rLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IFp6aCZndDsgU2lu Y2UgdGhlIHNhbWUgMDo2IGlzIGluIEJJRlRTIG9mIEJGUjEvQkZSMi9CRlIzIChhbmQgSSBzdXBw b3NlIGluIEJGUjR+QkZSOSBhcyB3ZWxsIGV2ZW4gdGhvdWdoIG5vdCBkcmF3biksIEkgYXNzdW1l ZCBpdCdzIGZvciB0aGUgJnF1b3Q7TVAyUCZxdW90OyByb3V0ZWQgYWRqYWNlbmN5IHRvIFIxMDsg dGhvdWdoIEkgdGhlbiBydWxlZCB0aGF0IG91dCAtIGJ1dCBJIGRvbid0IGtub3cgd2hhdCAwOjYg cmVwcmVzZW50IG5vdyBvbiBCRlIxLCBCRlIyLA0KIGFuZCBCRlIzLjxicj4NCiZndDsgPGJyPg0K Jmd0OyBBaC4gT2suIEkgdGhvdWdodCBpIGNvdWxkIHN0cmlwIGRvd24gdGhlIGV4YW1wbGUgdG8g c2hvdyBvbmx5IHRoZSA8YnI+DQomZ3Q7IGFkamFjZW5jaWVzIHJlbGV2YW50IHRvIHRoZSBmb2xs b3dpbmcgZGlzY3VzaW9uLCBidXQgc2VlbWluZ2x5IHRoaXMgPGJyPg0KJmd0OyBjYW4gaW50cm9k dWNlIHRoZSBjb25mdXNpb24geW91IGhhdmUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFNvIGkgY29t cGxldGVkIHRoZSBleGFtcGxlIHdpdGggdGhlIEJQIGFzc2lnbm1lbnQgYWNvc3MgYWxsIG5vZGVz LCBidXQgPGJyPg0KJmd0OyBhZGRlZCB0ZXh0IHBvaW50aW5nIHRvIGEgbmV3IHNlY3Rpb24gZnVy dGhlciBkb3duIHRvIGRpc2N1c3MgdGhlIDxicj4NCiZndDsgcmUtdXNlIG9mIEJQIGZvciB3aGlj aCB0aGkgcGljdHVyZSBpcyBhbHNvIGFuIGV4YW1wbGUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IChj aGVjayBvdXQgdGhlIGRpZmYsIG5ldyByZXVzZSB0ZXh0IHRvIGxvbmcgdG8gY29weSBpbmxpbmUp Ljxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoZSB3aG9sZSBwdXJwb3NlIG9mIHRoZSBFQ01Q IEJQcyBpcyBvZiBjb3Vyc2UgdG8gc2F2ZSBiaXRzLCBvdGhlcndpc2Ugd2UnZCBnaXZlIGVhY2gg bGluayBhIHNlcGFyYXRlIEJQLCB3aGljaCB3b3VsZCBiZSA2IEJQIHRvIHJlYWNoIHRvIEJGUjQu Li5CRlI3IGZyb20gQkZSMS4NCjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgWnpoJmd0 OyBUaGUgdHJvdWJsZSBJIGFtIGhhdmluZyBpcyB0aGF0IHRoZSBzYW1lIDA6NiBpcyBhc3NpZ25l ZCB0byBkaWZmZXJlbnQgdGhpbmdzIGFuZCBpdCdzIHByZXNlbnQgb24gYWxsIEJGUjEvQkZSMi9C RlIzLiBJdCBpcyBwZXJoYXBzIGFuIGludGVudGlvbmFsIHNtYXJ0IGRlc2lnbiBidXQgSSBoYXZl IG5vdCB3cmFwcGVkIG15IG1pbmQgYXJvdW5kIGl0LiBJdCdzIGFwcGFyZW50bHkgZGlmZmVyZW50 IGZyb20gdGhlIGxpbmsgYnVuZGxlDQogY2FzZSwgc28gYmV0dGVyIHNlcGFyYXRlIGl0IG91dCBh bmQgZWxhYm9yYXRlIGl0IChpbmNsdWRpbmcgdGhlIEROUiBmbGFnIHRoYXQgbWlnaHQgYmUgbmVl ZGVkIGhlcmUgLSBJZiB0aGUgcGFja2V0IGFycml2ZXMgb24gQkZSMSB3aXRoIDA6Niwgd291bGQg dGhlIEJQIHJlc2V0IHdoZW4gaXQgaXMgc2VudCB0byBCRlIyLzMpPzxicj4NCiZndDsgPGJyPg0K Jmd0OyBZZXMsIHRoZXJlIHdhcyB0aGUgYnVnIG9mIHJldXNpbmcgQlAgMDo2IGFjcm9zcyBzZXF1 ZW50aWFsIEJGUiBhbG9uZyA8YnI+DQomZ3Q7IHRoZSBwYXRoLCBidXQgbm93IHRoZSBleGFtcGxl IGNvcnJlY3RseSByZXVzZXMgc2VwYXJhdGUgQlAgYXQgPGJyPg0KJmd0OyBkaWZmZXJlbnQgc3Rh Z2VzIG9mIHRoZSBwYXRocyAoQlAgMDo2IG9uIEJGUjEsIEJQIDA6NyBvbiBCRlIyL0JGUjMpIGFu ZCBzbyBvbi48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmtzITxicj4NCiZndDsgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgNC44LiZuYnNwOyBSb3V0ZWQgYWRqYWNlbmNpZXM8YnI+DQomZ3Q7ICZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBJZiBJIHVuZGVyc3RhbmQgaXQgY29ycmVjdGx5LCB0 aGVyZSBpcyBhIEJQIGFzc2lnbmVkIHRvIEwxL0wyL0wzIDxicj4NCiZndDsgJmd0OyAmZ3Q7IHJl c3BlY3RpdmVseSAocDJwIGxpbmspLCBhbmQgdGhlbiB0aGVyZSBhcmUgQlBzIGFzc2lnbmVkIHRv IE1QMlAgdHVubmVscyAocm91dGVkIGFkamFjZW5jeSBmcm9tIGV2ZXJ5IEJGUikgdG8gdGhlIEwx L0wyL0wzIGludGVyZmFjZSBhZGRyZXNzZXMgYW5kIGxvb3BiYWNrIGFkZHJlc3NlcyBvbiBCRlIy LzMuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBPayB0aGF0IHdhc24ndCBxdWl0ZSB0 aGUgcmVhZCBpIGV4cGVjdGVkLiBMZXQgbWUgY2xhcmlmeSB0aGUgdGV4dC9waWN0dXJlOjxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLi4uLi4uLi4uLi4uLi4uJm5i c3A7ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IC4uLkJGUjEtLS4uLiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Li4uLS1MMS0tIEJGUjIuLi48YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsuLi4gLlJv dXRlcnMuIC4uLi0tTDItLS8mbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAuLi5CRlI0LS0uLi4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOy4uLi0tLS0tLSBCRlIzLi4uPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IC4uLi4uLi4uLi4uLi4uLiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0K Jmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TE88YnI+DQom Z3Q7ICZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7TmV0d29yayBBcmVhIDE8YnI+DQomZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7IEFzc3VtZSB0aGUgcmVxdWlyZW1lbnQgaW4gdGhlIGFib3ZlIHBpY3R1 cmUgaXMgdG8gZXhwbGljaXRseSBzdGVlciB0cmFmZmljIGZsb3dzIHRoYXQgaGF2ZSBhcnJpdmVk IGF0IEJGUjEgb3IgQkZSNCB2aWEgYSBzaG9ydGVzdCBwYXRoIGluIHRoZSByb3V0aW5nIHVuZGVy bGF5ICZxdW90O25ldHdvcmsgYXJlYSAxJnF1b3Q7IHRvIG9uZSBvZiB0aGUgZm9sbG93aW5nIHRo cmVlIG5leHQgc2VnbWVudHM6ICgxKSBCRlIyIHZpYSBsaW5rIEwxLCAoMikgQkZSMiB2aWENCiBs aW5rIEwyLCAoMykgdmlhIEJGUjMuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBUbyBh Y2hpZXZlIHRoaXMsIGJvdGggQkZSMSBhbmQgQkZSNCBhcmUgc2V0IHVwIHdpdGggYSBmb3J3YXJk X3JvdXRlZCBhZGphY2VuY3kgQml0UG9zaXRpb24gdG93YXJkcyBhbiBhZGRyZXNzIG9mIEJGUjIg b24gbGluayBMMSwgYW5vdGhlciBmb3J3YXJkX3JvdXRlZCBCaXRQb3NpdGlvbiB0b3dhcmRzIGFu IGFkZHJlc3Mgb2YgQkZSMiBvbiBsaW5rIEwyIGFuZCBhIHRoaXJkIGZvcndhcmRfcm91dGVkIEJp dHBvc2l0aW9uIHRvd2FyZHMgYSBub2RlDQogYWRkcmVzcyBMTyBvZiBCRlIzLjxicj4NCiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgRG9lcyB0aGlzIGNsZWFyIGlwIHRoZSBjb25mdXNpb24gPzxi cj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgWnpoJmd0OyBUaGUgcGljdHVyZSBpcyBiYWRs eSBtaXNhbGlnbmVkLiBJJ2xsIHdhaXQgdGlsbCA0LjcgcXVlc3Rpb25zIGFyZSBjbGVhcmVkLjxi cj4NCiZndDsgPGJyPg0KJmd0OyBPay48YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IElm IEJGUjIvMyBhcmUgYWxzbyBCRkVScywgdGhlbiB0aGV5IGFkZGl0aW9uYWxseSB3aWxsIGhhdmUg QkZFUiBCUHMuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgT24gQkZSMS80LCB0aGUgQklGVCBlbnRyaWVz IGZvciB0aGUgTVAyUCBCUHMgZm9yIHRoZSBMMS9MMi9MMy9sb29wYmFjayBpbnRlcmZhY2UgYWRk cmVzc2VzIG9mIEJGUjIvMyB3aWxsIHVzZSBmb3J3YXJkX3JvdXRlZChpbnRlcmZhY2UvbG9vcGJh Y2sgYWRkcmVzcykuIEZvciBhIHBhY2tldCB0byBiZSBkZWNhcHN1bGF0ZWQgb24gYSBCRkVSLCB0 aGVyZSBpcyBhIG5lZWQgZm9yIGJvdGggdGhlIEJGRVIgQlAgYW5kIGFub3RoZXIgQlAgKHAycC9s YW4vaHViLXNwb2tlL3JvdXRlZC1hZGphY2VuY3kpDQogaW4gdGhlIHBhY2tldCAodGhlIGZvcm1l ciBpcyBmb3IgZGVjYXBzdWxhdGlvbiBhbmQgdGhlIGxhdHRlciBpcyBmb3IgZ2V0dGluZyBpdCB0 aGVyZSkuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBUaGlzIGlzIG5vdCBkaXNjdXNz ZWQgaW4gdGhpcyBzZWN0aW9uLCBidXQgeW91IGFyZSByaWdodCAtIHVubGVzczxicj4NCiZndDsg Jmd0OyBCRlIyIG9yIEJGUjMgaXMgYSBsZWFmIEJGUi4gSW4gdGhhdCBjYXNlLCBpdCB3b3VsZCBq dXN0IGxldmVyYWdlIHRoZSBvbmUgc2hhcmVkICZxdW90O2xlYWYtQkZSJnF1b3Q7IEJQLCBzbyB0 aGV5IGRvIG5vdCBuZWVkIGEgcGVyLUJGRVIgQlAgZm9yIGxvY2FsX2RlY2FwKCkuDQo8YnI+DQom Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFp6aCZndDsgUmlnaHQgLSBzaGFyZWQgbGVhZi1CRlIg QlAgYnV0IHN0aWxsIG5lZWQgdGhhdCBCUCAodGhlIGtleSBpcyB0aGF0IHdlIG5lZWQgYSBCUCB0 byBnZXQgcGFja2V0IHRvIGEgQkZFUiBhbmQgdGhlbiBhIEJQIGZvciBkZWNhcHN1bGF0aW9uKS48 YnI+DQomZ3Q7IDxicj4NCiZndDsgWW91IGdvdCBpdC48YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0 OyAmZ3Q7IElmIHRoYXQ/Pz9zIHRoZSBjYXNlLCBpdD8/P3Mgd29ydGggcG9pbnQgdGhlIGFib3Zl IG91dC48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEhtbS4uLiBUaGUgbG9naWMgb2Yg QkZFUiBCUHMgaXMgdG90YWxseSBpbmRlcGVuZGVudCBvZiB0aGUgbG9naWMgb2YgZm9yd2FyZF9y b3V0ZWQgYWRqYWNlbmN5LCBzbyBpIHdvdWxkIHdvcnJ5IHRoYXQgcmVwZWF0aW5nIHRoZSBleHBs YW5hdGlvbiBvZiBCRkVSIEJQcyB3b3VsZCBjb25mbGF0ZSB0aGUgZm9yd2FyZF9yb3V0ZWQgZXhw bGFuYXRpb24uPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBaemgmZ3Q7IEl0J3MganVz dCB0aGF0IHRoaXMgaXMgYSBwbGFjZSB3aGVyZSBhbGwga2luZHMgb2YgQlBzIGFyZSB1c2VkIHNv IGl0J3MgZ29vZCB0byBoYXZlIGEgc3VtbWFyeSAoY291bGQgYmUgYSBzdWJzZWN0aW9uIDQuOSku PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFllcywgYWRkZWQgc3VjaCBhIHN1bW1hcnkuIFBscy4gY2hl Y2suPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBBY3R1YWxseSwgdGhlIHJlYXNvbiB0 aGF0IEkgdGhvdWdodCB0aGlzIGlzIE1QMlAgaXMgdGhhdCAwOjYgaXMgcHJlc2VudCBvbiBSMSwg UjIsIGFuZCBSMyAoYW5kIG1vcmUgSSBhc3N1bWUpIGluIEZpZ3VyZSAxMiwgYnV0IG5vdyBJIHRo aW5rIGl0IGNhbj8/P3QgYmUgTVAyUCAoc28gaXQgaXMgbm90IGNvcnJlY3QgdG8gaGF2ZSAwOjYg cHJlc2VudCBvbiB0aG9zZSByb3V0ZXJzID8/PyBvbmx5IHRoZSBwMnAgdHVubmVsIGhlYWQvdGFp bA0KIHNob3VsZCBoYXZlIHRoZSBCUCBwcmVzZW50IGluIHRoZSBCSUZUKS4gVGhlIHJlYXNvbiBp cyB0aGF0IGlmIGl0IHdlcmUgTVAyUCwgYW55IHJvdXRlciBnZXR0aW5nIGEgY29weSB3aWxsIHNl bmQgaXQgdG8gdGhlIGVuZHBvaW50IG9mIHRoZSByb3V0ZWQgYWRqYWNlbmN5LCBjYXVzaW5nIGxv dHMgb2YgZHVwbGljYXRlcy4uPGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZn dDsgQW0gSSBnZXR0aW5nIHRoaXMgY29ycmVjdD88YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7IEkgdGhpbmsgeW91IGFyZSBzdGlsbCBleHBsYWluaW5nIGZyb20gdGhlIG1pc3VuZGVyc3Rz YW5kaW5nIHRoYXQgdGhlIEVDTVAgZXhwbGFuYXRpb25zIHdoZXJlIGFib3V0IHJvdXRlZCBhZGph Y2VuY2llcy48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEkgaGF2ZSBub3cgZXhwYW5k ZWQgdGhlIHNvbWV3aGF0IHRlcnNlIHRleHQgaW4gdGhlIEJJRlQgdGFibGUgcGljdHVyZXMsIHRv IG1ha2UgaXQgY2xlYXIgdGhhdCB0aGUgRUNNUCBpcyBhY3Jvc3MgbXVsdGlwZSBmb3J3YXJkX2Nv bm5lY3RlZCBhZGphY2VuY2llcyBpbiB0aGUgZXhhbXBsZXMuIEZvciBleGFtcGxlLCBmaXJzdCBC SUZUIHBpY3R1cmU6PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDtC SUZUIGVudHJ5IGluIEJGUjE6PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxi cj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDt8IEluZGV4IHwmbmJzcDsgQWRqYWNlbmNpZXMmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 ICZuYnNwOz09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PTxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDt8IDA6NiZuYnNwOyAm bmJzcDt8Jm5ic3A7IEVDTVAoe2ZvcndhcmRfY29ubmVjdGVkKEwxLCBCRlIyKSwmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgfDxicj4NCiZndDsgJmd0OyZuYnNwOyAmbmJzcDt8Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7fCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBmb3J3YXJkX2Nvbm5lY3RlZChMMiwgQkZS MiksJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IHw8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJm5ic3A7fCZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgZm9yd2FyZF9jb25u ZWN0ZWQoTDMsIEJGUjIpfSwgc2VlZCkmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDt8PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgT2YgY291cnNlLCBhbiBFQ01QIGFkamFjZW5jeSBj YW4gYmUgYWNyb3NzIGFueSB0eXBlIG9mIGFkamFjZW5jaWVzLCBidXQgYWxsIHRoZSB0ZXh0L2V4 cGxhbmF0aW9ucyB1c2VkIGZvcndhcmRfY29ubmVjdGVkLCBhbmQgbm93IHRoZSBwaWN0dXJlcyBz aG93IHRoYXQgZXhwbGljaXRseS48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFp6aCZn dDsgSSBjYW4gdW5kZXJzdGFuZCB0aGUgbXVsdGktbGluayBjYXNlLCBidXQgdGhlIG11bHRpLWhv cCBFQ01QIGNhc2UgKGZyb20gQkZSMSB0b3dhcmRzIEJGUjEwKSBpcyBjb25mdXNpbmcgbWUuIEl0 IHdvdWxkIGhlbHAgdG8gZ2l2ZSBhbiBleGFtcGxlIGhvdyBpdCBjYW4gYmUgdXNlZCwgV0lUSE9V VCB3b3JyeWluZyBhYm91dCBwb2xhcml6YXRpb24uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFBsZWFz ZSBjaGVjayAtMDUgdGV4dCB0aGF0IGhhcyB0aGUgZnVsbCBzZXQgb2YgQklGVCBsaXN0ZWQgbm93 Ojxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGVyZSBpcyZuYnNwOyByZWFsbHkgbm90aGluZyBub3Ro aW5nIHVuaXF1ZSBpbiBtdWx0aS1ob3AgRUNNUCBmb3IgQklFUi1URSA8YnI+DQomZ3Q7IHRoYXQg d2UgZG8gbm90IGFsc28gaGF2ZSBpbiBhbnkgb3RoZXIgRUNNUCwgZXhjZXB0IHRoZSBjb25jbHVz aW9uIHRoYXQgPGJyPg0KJmd0OyB3ZSB3YW50IHRvIHN1cHBvcnQgZmFzdCBIVyBoYXNoIG1lY2hh bmlzbXMgQU5EIGFsbG93IHRoZSBjb250cm9sbGVyIHRvIDxicj4NCiZndDsgc2V0IHVwIG5vbi1w b2xhcml6ZWQgbXVsdGktaG9wIEVDTVAgQU5EIGJlIGFibGUgdG8gcHJlY2FsY3VsYXRlIHBhdGhz LiA8YnI+DQomZ3Q7IEhlbmNlIHRoZSBzcGVjaWZpY2F0aW9uIG9mIEVDTVAgYWRqYWNlbmNpZXMg dG8gaGF2ZSBhIGNvbnRyb2xsZXIgPGJyPg0KJmd0OyBjb25maWd1cmFibGUgc2VlZC48YnI+DQom Z3Q7IDxicj4NCiZndDsgQnR3OiBUaGUgcGljdHVyZSBpcyBtYXliZSB1bm5lY2Vzc2FyaWx5IGxh cmdlIGJlY2F1c2UgaSd2ZSB1c2VkIGl0IGZvciA8YnI+DQomZ3Q7IDIwIHllYXJzIHRvIGV4cGxh aW4gdGhlIHNhbWUgcG9sYXJpemF0aW9uIGlzc3VlIGZvciB1bmljYXN0IHZzIDxicj4NCiZndDsg bXVsdGljYXN0LCBhbmQgZm9yIG11bHRpY2FzdCBvbmx5IEJGUjEwLi4uQkZSNCBhcmUgcmVsZXZh bnQgKEVDTVAgb2YgPGJyPg0KJmd0OyB0aGUgUElNL21MRFAgam9pbnMpLCB3aGVyZWFzIGZvciB1 bmljYXN0L0JJRVIgb25seTxicj4NCiZndDsgQkZSMS4uLkJGUjcgYXJlIHJlbGV2YW50LiBCdXQg YmVpbmcgc3ltbWV0cmljLCB0aGUgcGljdHVyZSBtYWtlcyBpdCA8YnI+DQomZ3Q7IGNsZWFyIGl0 cyB0aGUgc2FtZSBwcm9ibGVtLjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsg Jm5ic3A7IFRvIGluaGliaXQgbG9vcGluZyBpbiB0aGUgZmFjZSBvZiBzdWNoIHBoeXNpY2FsIG1p c2NvbmZpZ3VyYXRpb24sPGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7IG9ubHkgZm9y d2FyZF9jb25uZWN0ZWQgYWRqYWNlbmNpZXMgYXJlIHBlcm1pdHRlZCB0byBoYXZlIEROUiBzZXQs IGFuZDxicj4NCiZndDsgJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyB0aGUgbGluayBsYXllciBkZXN0 aW5hdGlvbiBhZGRyZXNzIG9mIHRoZSBhZGphY2VuY3kgKGUuZy4mbmJzcDsgTUFDPGJyPg0KJmd0 OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7IGFkZHJlc3MpIHByb3RlY3RzIGFnYWluc3QgY2xvc2lu ZyB0aGUgbG9vcC4mbmJzcDsgTGluayBsYXllcnMgd2l0aG91dCBwb3J0PGJyPg0KJmd0OyAmZ3Q7 ICZndDsmbmJzcDsgJm5ic3A7IHVuaXF1ZSBsaW5rIGxheWVyIGFkZHJlc3NlcyBzaG91bGQgbm90 IGJlIHVzZWQgd2l0aCB0aGUgRE5SIGZsYWcgc2V0Ljxicj4NCiZndDsgJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgSXQ/Pz9zIG5vdCBjbGVhciBob3cgbGluayBsYXllciBhZGRyZXNzIGhl bHBzPzxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgSSBoYXZlIGV4cGFuZGVkIHRoaXMg dG88YnI+DQomZ3Q7ICZndDsgJnF1b3Q7bGluayBsYXllciBwb3J0IHVuaXF1ZSB1bmljYXN0IGRl c3RpbmF0aW9uIGFkZHJlc3MmcXVvdDs8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEFr YTogTVBMUyBvciBldGhlcm5ldCBoYXZlIHVuaXF1ZSBsaW5rIGxheWVyIGRlc3RpbmF0aW9uIGRl c3RpbmF0aW9uIGFkZHJlc3NlcyAobGFiZWwgb3IgZGVzdGluYXRpb24gTUFDKS4gSWYgeW91IHRo aW5rIGFib3V0IGluY29ycmVjdGx5IHBsdWdnZWQgSERMQyBsaW5rcyAoc3VjaCBhcyBvbGQgVDEv VDMvLi4uIGxpbmtzKSwgdGhleSBvbmx5IGhhdmUgMiBnZW5lcmljIGFkZHJlc3NlcywgaWYgaSBy ZW1lbWJlciAxIG9yIDMgaW4gdGhlIEhETEMNCiBmcmFtZS4gU28gd2hlbiB5b3UgbWlzcGx1ZyBv bmUgb2YgdGhvc2UgcDJwIGNhYmxlcyB3cm9uZywgdGhlIHBhY2tldHMgd291bGQgYmUgaW5jcnJl Y3RseSByZWNlaXZlZCBieSB0aGUgd3JvbmcgcmVjZWl2ZXIgbm9kZSBhbmQgdGhlbiBETlIgY291 bGQgY2F1c2UgcGVyc2lzdGVudCBsb29wcyBvbmx5IHNvbHZlZCBieSBUVEwuPGJyPg0KJmd0OyAm Z3Q7IDxicj4NCiZndDsgJmd0OyBaemgmZ3Q7ICZxdW90O0NvbnNpZGVyIGluIHRoZSByaW5nIHBp Y3R1cmUgdGhhdCBsaW5rIEw0IGZyb20gQkZSMyBpcyBwbHVnZ2VkIGludG8gdGhlIEwxIGludGVy ZmFjZSBvZiBCRlJhJnF1b3Q7IC0gc3RpbGwgbm90IHN1cmUgaG93IGxhYmVsL21hYyBoZWxwcyBo ZXJlLiBJIHN1cHBvc2UgdGhlIHJpbmcgdG9wb2xvZ3kgaXMgZGlzY292ZXJlZC92ZXJpZmllZCBi eSB0aGUgY29udHJvbCBwbGFuZSBhbmQgd2hlbiB0aGUgbWlzY2FsbGluZyBoYXBwZW5zIHRoZW4g dGhlDQogcmluZyB3aWxsIG5vdCBpbmNsdWRlIHRoZSBCRlIxL0JGUjIgcGFydCBhbmQgQkZSMyB3 aWxsIG5vdCBoYXZlIHRoZSBETlIgc2V0PyBJZiByaW5nIGRpc2NvdmVyeS92YXJpY2F0aW9uIGlz IG5vdCBkb25lIHRoZW4gcGVyaGFwcyB3ZSBzaG91bGQgcG9pbnQgb3V0IHRoYXQgUlBGIGJhc2Vk IG9uIGxpbmsgbGF5ZXIgYWRkcmVzcyBpcyBuZWVkZWQgLSB0aGUga2V5IGlzIFJQRiAod2hpY2gg bmVlZHMgdW5pcXVlIGxpbmsgbGF5ZXIgYWRkcmVzcyk/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEZv cmdldCBSUEYuIEJJRVIoLVRFKSBoYXMgbm8gUlBGIChpc3N1ZXMpLiBJdHMganVzdCBsaWtlIHVu aWNhc3QuIFJQRiA8YnI+DQomZ3Q7IGlzIGp1c3QgYSBwcm9ibGVtIGZvciByZWNlaXZlciBvcmln aW5hdGVkIGpvaW5zIGxpa2UgaW4gUElNL21MRFAsIGJ1dCA8YnI+DQomZ3Q7IG5vdCB1bmljYXN0 L2JpZXIoLXRlKS9SU1ZQLVRFLjxicj4NCiZndDsgPGJyPg0KJmd0OyBGb3J3YXJkX2Nvbm5lY3Rl ZCBpcyBqdXN0IGxpa2UgYSB1bmljYXN0IHN1Ym5ldCBhZGphY2VuY3kgdG8gYSBkaXJlY3QgPGJy Pg0KJmd0OyBuZWlnaGJvcjogSW50ZXJmYWNlIGFuZCBMMiBhZGRyZXNzcyBvZiB0aGUgZGVzdGlu YXRpb24uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBjb250cm9sbGVyIChjb3VsZCBiZSBhIGh1 bWFuKSAmcXVvdDthc3N1bWVzJnF1b3Q7IGEgcGFydGljdWxhciBwaHlzaWNpYWwgPGJyPg0KJmd0 OyB0b3BvbG9neSwgZnJvbSB0ZWxlbWV0cnkva25vd2xlZGdlL3doYXRldmVyLiBJdCB0aGVuIGNh bGN1bGF0ZXMgdGhlIDxicj4NCiZndDsgZGVzaXJlZCBCSUVSLVRFIHRvcG9sb2d5IGFuZCBwdXNo ZXMgaXQgZG93bi4gVGhpcyB0b3BvbG9neSBpcyBtZWFudCB0byA8YnI+DQomZ3Q7IGJlIGxvb3Ag ZnJlZSBvZiBjb3Vyc2Ugd3J0IHRvIHRoZSBjb25maWd1cmVkIGFkamFjZW5jaWVzLjxicj4NCiZn dDsgSW4gdGhpcyBCSUVSLVRFIHRvcG9sb2d5LCBCRlIzIHdpbGwgaGF2ZSBhIEJQIHdpdGggdGhl IDxicj4NCiZndDsgZm9yd2FyZF9jb25uZWN0ZWQoTDQsIE1BQy1vZi1CRlIyKSBhZGphY2VuY3ku PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElmIHRoZSBjYWJsZSBjb25uZWN0aW5nIHRvIEw0IGlzIG1p c3dpcmVkLCB0aGVuIEJGUjMgd291bGQgc3RpbGwgc2VuZCA8YnI+DQomZ3Q7IHRoZSBwYWNrZXRz IHRvIHRoZSBNQUMgYWRkcmVzcyBvZiBCRlIyLCBidXQgZ2l2ZW4gaG93IHRoZSBjYWJsZSA8YnI+ DQomZ3Q7IGNvbm5lY3RzIHRvIHNvbWUgb3RoZXIgbm9kZSwgdGhlc2UgcGFja2V0cyB3aWxsIGJl IGRpc2NhcmRlZCBieSB0aGF0IDxicj4NCiZndDsgbm9kZS4gYmVjYXVzZSB0aGV5J3JlIGp1c3Qg TDIgdW5pY2FzdCBwYWNrZXRzLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJIHRoaW5rIHRoaXMgaXMg ZXF1YWxseSB0cnVlIHdoZW4gd2UgaGF2ZSBub3JtYWwgQklFUi9NUExTIGVuYWNwLjxicj4NCiZn dDsgVGhvc2UgcGFja2V0cyB0b28gYXJlIGFkZHJlc3NlZCB0byB0aGUgdW5pY2FzdCBNQUMgYWRk cmVzcyBvZiB0aGUgPGJyPg0KJmd0OyBuZWlnaGJvci48YnI+DQomZ3Q7IDxicj4NCiZndDsgTm93 LCBpZi93aGVuIGhlIGNvbnRyb2xsZXIgcmVjb2duaXplcyB0aGF0IHRoZSBwaHlzaWNhbCB0b3Bv bG9neSBoYXMgPGJyPg0KJmd0OyBjaGFuZ2VkLCB0aGF0cyBhIGNvbXBsZXRlbHkgZGlmZmVyZW50 IHN0b3J5IGFuZCBub3QgYWRkcmVzc2VkIGhlcmUuIDxicj4NCiZndDsgR2l2ZW4gaG93IHdlIGFz c3VtZWQgdGhpcyB3YXMgYSBjYWJsaW5nIG1pc3Rha2UsIHRoZSBjb250cm9sbGVyIHdvdWxkIDxi cj4NCiZndDsgcHJvYmFibHkgb25seSBjb21wbGFpbiBhYm91dCB0aGUgbWlzd2lyaW5nIHRvIG9w ZXJhdGlvbnMgYnV0IGJlIGhhcHB5IDxicj4NCiZndDsgdGhhdCB0aGUgZm9yd2FyZGluZyBwbGFu ZSBqdXN0IG1ha2VzIHBhY2tldHMgZmFpbCBpbnN0ZWFkIG9mIGxvb3AuIElmIDxicj4NCiZndDsg dGhpcyB3YXMgYSBwbGFubmVkIGNoYW5nZSBwcm9jZXNzLCB0aGVuIGl0IHdpbGwgYmUgc2ltaWxh cmlseSA8YnI+DQomZ3Q7IGNvbnZvbHV0ZWQgYXMgaXQgd291bGQgdG9kYXkgYmUgd2l0aCByZXdp cmluZyBjYWJsZXMgaW4gYW4gPGJyPg0KJmd0OyBTUi1NUExTL1NSdjYgdG9wb2xvZ3kgYW5kIHVw ZGF0aW5nIFNJRHMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBCZWNhdXNlIHRoZSBm b3J3YXJkaW5nIGlzIGRpZmZlcmVudCBmcm9tIEJJRVIgZm9yd2FyZGluZyAoYmVjYXVzZSBvZiBb MV0gYWJvdmUpLCB3ZSBtaWdodCBhcyB3ZWxsIGludHJvZHVjZSBhbiBvcHRpbWl6YXRpb24gaGVy ZSA/Pz8gZm9yIGVhY2ggQklGVCwgY2FsY3VsYXRlIHRoZSBGLUJNIG9mIHRoZSBCSUZUIGl0c2Vs ZiAodGhlIGxvZ2ljYWwgPz8/b3I/Pz8gb2YgYWxsIHRoZSBCUHMgcHJlc2VudGVkIGluIHRoaXMg QklGVCkgYW5kDQogdGhlbiB1c2UgKHBhY2tldC0mZ3Q7Yml0c3RyaW5nICZhbXA7IEJJRlQuRi1C TSkgYXMgdGhlIGlucHV0IHRvIEdldEZpcnN0L05leHRCaXRQb3NpdGlvbigpLiBUaGF0IHNob3Vs ZCBza2lwIG1hbnkgYml0cy48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFJpZ2h0LiBC dXQgaSBleHBsaWNpdGx5IHJlbW92ZWQgdGhvc2Ugb3B0aW1pemF0aW9ucyAoaSBoYWQgdGhlbSBp biBvbGRlciBkcmFmdCB2ZXJzaW9ucykgYmVjYXVzZSB0aGUgd2hvbGUgaWRlYSBvZiB0aGlzIHBp Y3R1cmUgaXMgc29sZWx5IHRoZSBjb21wYXJpc29uIHdpdGggZmlndXJlIDQgb2YgUkZDODI3OS48 YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFp6aCZndDsgSSB0aGluayBpdCdzIHdvcnRo IHBvaW50IHRoYXQgb3B0aW1pemF0aW9uIG91dDsgeW91IGNhbiBtYXJrIGl0IG9wdGlvbmFsIGlm IHlvdSB3YW50IHRvIGVtcGhhc2l6ZSB0aGUgc2ltaWxhcml0eSB0byBCSUVSIGZvcndhcmRpbmcs IGJ1dCBzaW5jZSBCSUVSIGZvcndhcmRpbmcgZG9lcyBkbyB0aGUgbWFza29mZiBzdGVwLCBpdCBp cyB2ZXJ5IGVmZmljaWVudCB3aGlsZSBCSUVSLVRFIGZvcndhcmRpbmcgZG9lcyBub3QgaXQgdGhl IG1hc2tvZmYNCiBzdGVwIHNvIHRoaXMgb3B0aW1pemF0aW9uIGlzIGltcG9ydGFudC48YnI+DQom Z3Q7IDxicj4NCiZndDsgT2suIEkgc2ltcGxpZmllZCB0aGUgdGV4dCBjb21wYXJpc29uIEJJRVIv QklFUi1URSB3cnQuIHRvIHRoZSBGQk0gPGJyPg0KJmd0OyBydWxlcyBbMV0gYW5kIFsyXSBhbmQg YWRkZWQgZm9sbG93aW5nIHBhcmFncmFwaDo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmx0O3QmZ3Q7 SW4gQklFUiwgdGhlIG9yZGVyIG9mIEJQcyBpbXBhY3RzIHRoZSByZXN1bHQgb2YgZm9yd2FyZGlu ZyBiZWNhdXNlIG9mIFsxXS4gPGJyPg0KJmd0OyBJbiBCSUVSLVRFLCBmb3J3YXJkaW5nIGlzIG5v dCBpbXBhY3RlZCBieSB0aGUgb3JkZXIgb2YgQlBzLiBJdCBpcyA8YnI+DQomZ3Q7IHRoZXJlZm9y ZSBwb3NzaWJsZSB0byBmdXJ0aGVyIG9wdGltaXplIGZvcndhcmRpbmcgdGhhbiBpbiBCSUVSLiBG b3IgPGJyPg0KJmd0OyBleGFtcGxlIHBhcmFsbGVsaXppbmcgZm9yd2FyZGluZyBhY3Jvc3MgbXVs dGlwbGUgRlBFIGNvcmVzIG9yIDxicj4NCiZndDsgZGlzdHJpYnV0ZWQgbGluZWNhcmRzIGRvZXMg b25seSBuZWVkIHRvIGV4YW1pbmUgYW4gYXJiaXRyYXJ5IHN1YnNldCBvZiA8YnI+DQomZ3Q7IEJQ IGFuZCBub3QgZXZhbHVhdGUgdGhlIGRlcGVuZGVuY3kgYmV0d2VlbiBCUHMuJmx0Oy90Jmd0Ozxi cj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsmbmJzcDsgJm5ic3A7IFRoZSBmb2xsb3dpbmcg cHNldWRvY29kZSBpcyBjb21wcmVoZW5zaXZlOjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyAmZ3Q7IFRoZSBhYm92ZSBzZW50ZW5jZSByZWFkcyBhIGJpdCBzdHJhbmdlIChvciBs YWNrcyBzb21lIHNlZ3VlKS4uPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJIGhvcGUg bm90LCBidXQgbWF5YmUgYmVzdCBsZWZ0IHRvIGEgbmF0aXZlIGVuZ2xpc2ggc3BlYWtlciAoUkZD LWVkaXRvcikuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBUaGUgZmlyc3QgKFJGQzgy NzkpIHBzZXVkb2NvZGUgd2FzIHNpbXBsaWZpZWQuIFRoZSBzZWNvbmQgb25lIGlzIGNvbXByZWhl bnNpdmUuIElmIG5vdCBjb21wcmVoZW5zaXZlLCB3aGF0cyBhIGdvb2Qgb3Bwb3NpdGUgb2Ygc2lt cGxpZmllZCA/PGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBaemgmZ3Q7IFBlcmhhcHMg JnF1b3Q7VGhlIGFib3ZlIHNpbXBsaWZpZWQgcHNldWRvY29kZSBpcyBlbGFib3JhdGVkIGZ1cnRo ZXIgYXMgZm9sbG93aW5nJnF1b3Q7Pzxicj4NCiZndDsgJmd0OyBaemgmZ3Q7IEplZmZyZXk8YnI+ DQomZ3Q7IDxicj4NCiZndDsgRG9uZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmtzIGEgbG90 LiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZuYnNwOyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KJmd0OyAmZ3Q7ICZndDsgRnJvbTogQklFUiBbPGEgaHJlZj0ibWFpbHRvOmJpZXItYm91 bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJpZXItYm91bmNlc0BpZXRmLm9yZzwvYT4m bHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpiaWVyLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5iaWVyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0O10NCjxicj4NCiZndDsgJmd0OyAm Z3Q7IG9uIGJlaGFsZiBvZiBUb2VybGVzcyBFY2tlcnQgWzxhIGhyZWY9Im1haWx0bzp0dGVAY3Mu ZmF1LmRlIiB0YXJnZXQ9Il9ibGFuayI+dHRlQGNzLmZhdS5kZTwvYT4mbHQ7bWFpbHRvOjxhIGhy ZWY9Im1haWx0bzp0dGVAY3MuZmF1LmRlIiB0YXJnZXQ9Il9ibGFuayI+dHRlQGNzLmZhdS5kZTwv YT4mZ3Q7XTxicj4NCiZndDsgJmd0OyAmZ3Q7IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMDksIDIwMTkg MjM6Mzg8YnI+DQomZ3Q7ICZndDsgJmd0OyBUbzogTWlrZSBNY0JyaWRlPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgQ2M6IEdyZWcgU2hlcGhlcmQ7IEJJRVIgV0c7IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVy dCk8YnI+DQomZ3Q7ICZndDsgJmd0OyBTdWJqZWN0OiBSZTogW0JpZXJdIFdHTEMgLSBkcmFmdC1p ZXRmLWJpZXItdGUtYXJjaDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7 IFRoYW5rcywgTWlrZTxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IFRo ZSBhdXRob3JzIGFsc28gcmV2aWV3ZWQgdGhlIGRvY3VtZW50IGFuZCBjb25jbHVkZWQgdGhhdCBp dCB3YXMgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgcmVhbGx5IGhhcmQgdG8gZ2V0IGludG8gdGhlIGRv Y3VtZW50IGNvbnRleHQgYmVjYXVzZSBvZiB0b28gbWFueSA8YnI+DQomZ3Q7ICZndDsgJmd0OyBm b3J3YXJkIGRlcGVuZGVuY2llcy4gV2UgdHJpZWQgdG8gZml4IHRoaXMgYnkgYWRkaW5nIHR3byBo b3BlZnVsbHkgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZ29vZCAmYW1wOyBiYXNpYyBleGFtcGxlcyBp bnRvIHRoZSBJbnRyb2R1Y3Rpb24gc2VjdGlvbiBhbmQgdXNpbmcgdGhlbSA8YnI+DQomZ3Q7ICZn dDsgJmd0OyB0byBhbHNvIGFkZCBhIGJldHRlciBkZWZpbml0aW9uIG9mIHRoZSB0ZXJtICZxdW90 O0JJRVItVEUgVG9wb2xvZ3kmcXVvdDsgaW4gdGhlIEludHJvZHVjdGlvbi48YnI+DQomZ3Q7ICZn dDsgJmd0OyBIb3BlZnVsbHkgdGhpcyBtYWtlcyByZWFkaW4gdGhlIHJlc3Qgb2YgdGUgZG9jdW1l bnQgc21vb3RoZXIuLjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IEFs c28gaW1wcm92ZWQgdGV4dCBvZiBBYnN0cmFjdCBhbmQgcmVmaW5lZCB0ZXh0IGNvbXBhcmlpbmcg QklFUi1URSB3aXRoIFNSLjxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7 IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwOi90b29scy5pZXRmLm9y Zy8qcmZjZGlmZj91cmwxPWh0dHBzIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3VybGRlZmVu c2UuY29tL3YzL19faHR0cDovL3Rvb2xzLmlldGYub3JnLypyZmNkaWZmP3VybDE9aHR0cHM8L2E+ Ojxicj4NCiZndDsgJmd0OyAmZ3Q7ICoqPGEgaHJlZj0iaHR0cDovL0F0b29scy5pZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPkF0b29scy5pZXRmLm9yZzwvYT4qaWQqZHJhZnQtaWV0Zi1iaWVyLXRl LWFyY2gtMDIudHh0JmFtcDt1cmwyPWh0dHBzOioqQTxicj4NCiZndDsgJmd0OyAmZ3Q7IHRvb2w8 YnI+DQomZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJodHRwOi8vcy5pZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnMuaWV0Zi5vcmc8L2E+KmlkKmRyYWZ0LWlldGYtYmllci10ZS1hcmNoLTAzLnR4dF9f O0x5OHZMeTh2THk4diE4V29BNlI8YnI+DQomZ3Q7ICZndDsgJmd0OyBqQzgxIDxicj4NCiZndDsg Jmd0OyAmZ3Q7IGMhWHZINEFBeGZyRGpGb0tfc2VyY3daTXNjME81TjQyZUVOT3M0bF9xZHNYRjBL d1pEODJjSkxERkZOVl9lVFVFaDxicj4NCiZndDsgJmd0OyAmZ3Q7ICQ8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHA6L3Rvb2xz LmlldGYub3JnLypyZmNkaWZmP3VybDE9aHR0cHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Vy bGRlZmVuc2UuY29tL3YzL19faHR0cDovdG9vbHMuaWV0Zi5vcmcvKnJmY2RpZmY/dXJsMT1odHRw czwvYT46PGJyPg0KJmd0OyAmZ3Q7ICZndDsgKio8YSBocmVmPSJodHRwOi8vQXRvb2xzLmlldGYu b3JnIiB0YXJnZXQ9Il9ibGFuayI+QXRvb2xzLmlldGYub3JnPC9hPippZCpkcmFmdC1pZXRmLWJp ZXItdGUtYXJjaC0wMi50eHQmYW1wO3VybDI9aHR0cHM6KipBPGJyPg0KJmd0OyAmZ3Q7ICZndDsg dG9vbDxicj4NCiZndDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHA6Ly9zLmlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+cy5pZXRmLm9yZzwvYT4qaWQqZHJhZnQtaWV0Zi1iaWVyLXRlLWFyY2gtMDMu dHh0X187THk4dkx5OHZMeTh2IThXb0E2Ujxicj4NCiZndDsgJmd0OyAmZ3Q7IGpDODEgPGJyPg0K Jmd0OyAmZ3Q7ICZndDsgYyFVQlRHdldXcE1IeWVpU2FueHM2dkliX0VuQlZneWc2Ym9BQVc0bnJx anU4VUNMT2dpdVhjOFlfNnNOZDFuamNYPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJCZndDs8YnI+DQom Z3Q7ICZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJmd0OyBDaGVlcnM8YnI+DQomZ3Q7ICZndDsg Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7VG9lcmxlc3M8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YnI+ DQomZ3Q7ICZndDsgJmd0OyBPbiBXZWQsIEp1biAyNiwgMjAxOSBhdCAxMDozOTozNkFNIC0wNzAw LCBNaWtlIE1jQnJpZGUgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBIb3cgYWJvdXQg dGhyZWU/IEkgc3VwcG9ydC48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7IG1pa2U8YnI+DQomZ3Q7 ICZndDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyBPbiBUdWUsIEp1biAyNSwg MjAxOSBhdCAxMDo0MiBBTSBHcmVnIFNoZXBoZXJkICZsdDs8YSBocmVmPSJtYWlsdG86Z2pzaGVw QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdqc2hlcEBnbWFpbC5jb208L2E+Jmx0O21haWx0 bzo8YSBocmVmPSJtYWlsdG86Z2pzaGVwQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdqc2hl cEBnbWFpbC5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFdlIGNhbm5vdCB0YWtlIHR3byAneWVz JyB2b3RlcyBhbmQgV0cgY29uc2Vuc3VzLjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBQ bGVhc2UsIHJlYWQgYW5kIHJlc3BvbmQuIElmIHlvdSBkb24ndCBzdXBwb3J0LCB0aGVuIHBsZWFz ZSB2b3RlIGFzIG11Y2ggcHVibGljbHkgcmlnaHQgaGVyZS48YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgVGhhbmtzLDxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyBHcmVnPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IE9uIE1vbiwgSnVuIDMsIDIwMTkgYXQgMTA6MDUg UE0gUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnB0aHViZXJ0 QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnB0aHViZXJ0QGNpc2NvLmNvbTwvYT4mbHQ7bWFp bHRvOjxhIGhyZWY9Im1haWx0bzpwdGh1YmVydEBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5w dGh1YmVydEBjaXNjby5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgU3VwcG9ydDo8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7Jmd0OyBJIHNlZSBncmVhdCB2YWx1ZSBpbiBkZXRlcm1pbmlzdGljIG5ldHdvcmtzIGFz IHdlbGwgYXMgSU9UICh3aXRoIFJQTCkuPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0 Ozxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgQWxsIHRoZSBiZXN0LDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsm Z3Q7IFBhc2NhbDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgRnJvbTogQklFUjxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJpZXItYm91 bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJpZXItYm91bmNlc0BpZXRmLm9yZzwvYT4m bHQ7bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpiaWVyLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5iaWVyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyZndDsgT24NCjxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyBCZWhhbGYgT2YgVG9lcmxlc3MgRWNrZXJ0PGJy Pg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IFNlbnQ6IG1hcmRpIDQganVpbiAy MDE5IDAyOjAzPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IFRvOiBHcmVn IFNoZXBoZXJkIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmdqc2hlcEBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5nanNoZXBAZ21h aWwuY29tPC9hPiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmdqc2hlcEBnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj5nanNoZXBAZ21haWwuY29tPC9hPiZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IENjOiBCSUVSIFdHICZsdDs8YSBocmVmPSJtYWlsdG86 YmllckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJpZXJAaWV0Zi5vcmc8L2E+Jmx0O21haWx0 bzo8YSBocmVmPSJtYWlsdG86YmllckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmJpZXJAaWV0 Zi5vcmc8L2E+Jmd0OyZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsg U3ViamVjdDogUmU6IFtCaWVyXSBXR0xDIC0gZHJhZnQtaWV0Zi1iaWVyLXRlLWFyY2g8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7 ICZndDsmZ3Q7ICZndDsgJiM0MzsxPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAm Z3Q7IE9idmlvdXNseSBzdXBwb3J0IGFzIGNvLWF1dGhvci48YnI+DQomZ3Q7ICZndDsgJmd0OyAm Z3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsg T24gV2VkLCBNYXkgMjksIDIwMTkgYXQgMTI6NDE6MjZQTSAtMDcwMCwgR3JlZyBTaGVwaGVyZCB3 cm90ZTo8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyBQbGVhc2Ug cmVhZCBhbmQgcmVzcG9uZCB0byB0aGlzIHRocmVhZCB3LyBvciB3L28gc3VwcG9ydC48YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7 ICZndDsgJmd0OyZndDsgJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20v djMvX19odHRwczovZGF0YXRyYWNrZXIuLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw czovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9kYXRhdHJhY2tlci4uaWV0Zi5vcmc8L2E+ PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgL2RvYyA8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyAvZHJhZnQtaWV0Zi1iaWVyLXRl LWFyY2gvX187IThXb0E2UmpDODFjIVh2SDRBQXhmckRqRm9LX3M8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyBlcmN3IFpNc2MwTzVONDJlRU5PczRsX3Fkc1hGMEt3 WkQ4MmNKTERGRk5WOWVDbEJqJDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0 OyAmZ3Q7ICZsdDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L2Rh dGF0cmFja2VyLmlldGYub3JnLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdXJsZGVmZW5zZS5j b20vdjMvX19odHRwczovZGF0YXRyYWNrZXIuaWV0Zi5vcmcvPC9hPjxicj4NCiZndDsgJmd0OyAm Z3Q7ICZndDsgJmd0OyZndDsgJmd0OyAmZ3Q7IGRvYy8gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgZHJhZnQtaWV0Zi1iaWVyLXRlLWFyY2gvX187IThXb0E2UmpD ODFjIVVCVEd2V1dwTUh5ZWlTYW54PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAm Z3Q7ICZndDsgczZ2SSBiX0VuQlZneWc2Ym9BQVc0bnJxanU4VUNMT2dpdVhjOFlfNnNENDBrbXRI JCZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAmZ3Q7IFZvdGUgZW5kcyA1IEp1bmUgMjAx OS48YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7ICZndDsg Jmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyBTaGVwPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0 OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgKGNoYWlycyk8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsg Jmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAmZ3Q7IEJJRVIgbWFpbGluZyBsaXN0PGJyPg0K Jmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOkJJ RVJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5CSUVSQGlldGYub3JnPC9hPiZsdDttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOkJJRVJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5CSUVSQGlldGYu b3JnPC9hPiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyA8 YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3d3dy5pZXRmLm9yZy9t YWlsbWFuLyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vPC9hPjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyZndDsgJmd0OyAmZ3Q7IGxpc3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7 ICZndDsgJmd0OyBpbmZvL2JpZXJfXzshOFdvQTZSakM4MWMhWHZINEFBeGZyRGpGb0tfc2VyY3da TXNjME81TjQyZUU8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgJmd0OyBO T3M0IGxfcWRzWEYwS3daRDgyY0pMREZGTlQyV1ZYV1gkIDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZn dDsgJmd0OyZndDsgJmd0OyAmZ3Q7ICZsdDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29t L3YzL19faHR0cHM6L3d3dy5pZXRmLm9yZy9tYWlsbWFuLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovd3d3LmlldGYub3JnL21haWxtYW4vPC9hPjxi cj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAmZ3Q7IGxpc3QgPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgaW5mby9iaWVyX187IThXb0E2UmpD ODFjIVVCVEd2V1dwTUh5ZWlTYW54czZ2SWJfRW5CVmd5ZzZiPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7ICZndDsgb0FBVyA0bnJxanU4VUNMT2dpdVhjOFlfNnNLbjJLb0FU JCZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsg QklFUiBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsg PGEgaHJlZj0ibWFpbHRvOkJJRVJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5CSUVSQGlldGYu b3JnPC9hPiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOkJJRVJAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5CSUVSQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZn dDsmZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly91cmxkZWZl bnNlLmNvbS92My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGk8L2E+PGJyPg0KJmd0 OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IHN0aW4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7IGZvL2JpZXJfXzshOFdvQTZSakM4MWMhWHZINEFBeGZyRGpGb0tf c2VyY3daTXNjME81TjQyZUVOT3M0PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAm Z3Q7IGxfcWQ8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsgc1hGMEt3WkQ4 MmNKTERGRk5UMldWWFdYJDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyZndDsgJmd0OyAm bHQ7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMv X19odHRwczovd3d3LmlldGYub3JnL21haWxtYW4vbGk8L2E+PGJyPg0KJmd0OyAmZ3Q7ICZndDsg Jmd0OyAmZ3Q7Jmd0OyAmZ3Q7IHN0aW4gPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0 OyAmZ3Q7IGZvL2JpZXJfXzshOFdvQTZSakM4MWMhVUJUR3ZXV3BNSHllaVNhbnhzNnZJYl9FbkJW Z3lnNmJvQUFXPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IDRucnE8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsmZ3Q7ICZndDsganU4VUNMT2dpdVhjOFlfNnNLbjJL b0FUJCZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0 OyAmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgQklFUiBtYWlsaW5nIGxpc3Q8YnI+DQom Z3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOkJJRVJAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5CSUVSQGlldGYub3JnPC9hPiZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRv OkJJRVJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5CSUVSQGlldGYub3JnPC9hPiZndDs8YnI+ DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNv bS92My9fX2h0dHBzOi93d3cuLmlldGYub3JnL21haWxtYW4vbGlzdGkiIHRhcmdldD0iX2JsYW5r Ij4NCmh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpPC9hPjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBuZm8vIDxicj4NCiZn dDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBiaWVyX187IThXb0E2UmpDODFjIVh2SDRBQXhmckRqRm9L X3NlcmN3Wk1zYzBPNU40MmVFTk9zNGxfcWRzWDxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0 OyBGMEt3PGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IFpEODJjSkxERkZOVDJXVlhXWCQ8 YnI+DQomZ3Q7ICZndDsgJmd0OyAmZ3Q7ICZndDsgJmx0OzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVm ZW5zZS5jb20vdjMvX19odHRwczovd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGkiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpPC9hPjxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBuZm8vIDxicj4N CiZndDsgJmd0OyAmZ3Q7ICZndDsgJmd0OyBiaWVyX187IThXb0E2UmpDODFjIVVCVEd2V1dwTUh5 ZWlTYW54czZ2SWJfRW5CVmd5ZzZib0FBVzRucnFqdTxicj4NCiZndDsgJmd0OyAmZ3Q7ICZndDsg Jmd0OyA4VUNMPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmd0OyAmZ3Q7IE9naXVYYzhZXzZzS24yS29B VCQmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgLS08YnI+DQom Z3Q7ICZndDsgJmd0OyAtLS08YnI+DQomZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJtYWlsdG86dHRl QGNzLmZhdS5kZSIgdGFyZ2V0PSJfYmxhbmsiPnR0ZUBjcy5mYXUuZGU8L2E+Jmx0O21haWx0bzo8 YSBocmVmPSJtYWlsdG86dHRlQGNzLmZhdS5kZSIgdGFyZ2V0PSJfYmxhbmsiPnR0ZUBjcy5mYXUu ZGU8L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAmZ3Q7IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7 ICZndDsgQklFUiBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJtYWls dG86QklFUkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkJJRVJAaWV0Zi4ub3JnPC9hPiZsdDtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOkJJRVJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5CSUVS QGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7ICZndDsgJmd0OyA8YSBocmVmPSJodHRwczovL3Vy bGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvLyIg dGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vPC9hPjxicj4NCiZndDsgJmd0OyAmZ3Q7IGJpZXIg PGJyPg0KJmd0OyAmZ3Q7ICZndDsgX187IThXb0E2UmpDODFjIVh2SDRBQXhmckRqRm9LX3NlcmN3 Wk1zYzBPNU40MmVFTk9zNGxfcWRzWEYwS3daRDgyPGJyPg0KJmd0OyAmZ3Q7ICZndDsgY0pMRDxi cj4NCiZndDsgJmd0OyAmZ3Q7IEZGTlQyV1ZYV1gkPGJyPg0KJmd0OyAmZ3Q7ICZndDsgJmx0Ozxh IGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92 My9fX2h0dHBzOi93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby88L2E+PGJyPg0KJmd0OyAm Z3Q7ICZndDsgYmllciA8YnI+DQomZ3Q7ICZndDsgJmd0OyBfXzshOFdvQTZSakM4MWMhVUJUR3ZX V3BNSHllaVNhbnhzNnZJYl9FbkJWZ3lnNmJvQUFXNG5ycWp1OFVDTE9naXU8YnI+DQomZ3Q7ICZn dDsgJmd0OyBYYzhZPGJyPg0KJmd0OyAmZ3Q7ICZndDsgXzZzS24yS29BVCQmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyAtLTxicj4NCiZndDsgJmd0OyAtLS08YnI+DQomZ3Q7ICZn dDsgPGEgaHJlZj0ibWFpbHRvOnR0ZUBjcy5mYXUuZGUiIHRhcmdldD0iX2JsYW5rIj50dGVAY3Mu ZmF1LmRlPC9hPjxicj4NCiZndDsgPGJyPg0KJmd0OyAtLTxicj4NCiZndDsgLS0tPGJyPg0KJmd0 OyA8YSBocmVmPSJtYWlsdG86dHRlQGNzLmZhdS5kZSIgdGFyZ2V0PSJfYmxhbmsiPnR0ZUBjcy5m YXUuZGU8L2E+PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBCSUVSIG1haWxpbmcgbGlzdDxicj4NCiZn dDsgPGEgaHJlZj0ibWFpbHRvOkJJRVJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5CSUVSQGll dGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9f X2h0dHBzOi93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iaWVyIiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9iaWVyPC9hPjxicj4NCiZndDsgX187ISFORXQ2eU1hTy1nayFWdVFDVkhu cUp5X2FZSS1GTnQ5QTFhNUV6SE9DcjBmWmtMUGJnZzNDUE51MFB5cldzckZ4NDxicj4NCiZndDsg MV9qV1YzWVVBNkQkPGJyPg0KPGJyPg0KLS08YnI+DQotLS08YnI+DQo8YSBocmVmPSJtYWlsdG86 dHRlQGNzLmZhdS5kZSIgdGFyZ2V0PSJfYmxhbmsiPnR0ZUBjcy5mYXUuZGU8L2E+PGJyPg0KPGJy Pg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpC SUVSIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpCSUVSQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+QklFUkBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JpZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JpZXI8L2E+PG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_LEXPR01MB0495CB59CD2034FF8453A56996100LEXPR01MB0495DEUP_-- From nobody Wed Feb 19 07:54:00 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000AF120169 for ; Wed, 19 Feb 2020 07:53:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.749 X-Spam-Level: X-Spam-Status: No, score=-0.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lAtuto4St3yb for ; Wed, 19 Feb 2020 07:53:55 -0800 (PST) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 54B6E120168 for ; Wed, 19 Feb 2020 07:53:55 -0800 (PST) Received: by mail-wr1-x42c.google.com with SMTP id m16so1089971wrx.11 for ; Wed, 19 Feb 2020 07:53:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=p6mGoeGX6F0mrq/m3CqOqh5t5CHZqT1EBQ+f3hnjvvs=; b=H3QsEH5C+bRLTX7kePdGZBdgC8k16/7OPID3EJKm9sDIUZy3fjjW4ogAOi6jJIJ78b vsnCRNgLaMdR5SZ11pB/oTog+Kalt3eaauUjFxMbKp0jO1azL7l+MVKhuJEm56PQwK5M krD43JSl+xG0anr691tNyJEyZhk2QHuY7v6S5aTBTEK/sFica2EL9Oao622yIWxO0W+L T6BCa+EvA5FkBVt3otfha2ViFUYjkMbVuLMcVABWK26+21ANEbna9pzEH/zdPlgJyF0g 2M1/qfqxe5X54d8w6zWTrH7xWX9VUo/jiB+04I/Yn8O7QOB4+7BjPSHIUgZJlxeptlPp YbKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=p6mGoeGX6F0mrq/m3CqOqh5t5CHZqT1EBQ+f3hnjvvs=; b=c8w6YomeL2mXFN1NcTBsqq7HnsgSBx7jUYPsyqIGEgoc/3a8gyPmw4EvcgQmSfUbch TP1LcY7l44onrxGRnOB20/BFvZ8MGgRppuqGWLatJxQ8bDmEHJMPM/thevzVSNBvXvga Wt01PTzKcD/wWx1wFijNnxzGj77dLQy7vYpazUDTToiCQDka0lgitzwhLbjIxNAqx4kD uTwlO2iJUf0s4zdrJhXicbqSF78a6rFXOGCn9kXErZ5eqPa+u6RB6NtVhgHk89hHML0b 1nebHzGdOPt4y23K2k8EhVhbAtKr+ayHZZZ0P5Db36vVjicskSpb+2K1QWv17Jcc8Uqa tvtQ== X-Gm-Message-State: APjAAAXV0adH8SBSa4Bx1DXa9gt5l7SIvsf9LNQWkidJ6juC0S2T1Gdh OXn67L0dX4iLpcfjhlylw0WPtU5+xhWAMYfn1zM= X-Google-Smtp-Source: APXvYqwxgGqlQhP7nwRYUd7zgrGWpcox+Cmywj8YsbvLYJgKft/Y/mbAch+498hoH+noNdLD1ogg8ogpD1bzcU+QrO0= X-Received: by 2002:adf:f7c6:: with SMTP id a6mr38430353wrq.164.1582127633418; Wed, 19 Feb 2020 07:53:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Mike McBride Date: Wed, 19 Feb 2020 07:54:10 -0800 Message-ID: To: Greg Shepherd Cc: "Jeffrey (Zhaohui) Zhang" , "bier@ietf.org" , Toerless Eckert Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 15:53:59 -0000 Support. mike On Tue, Feb 18, 2020 at 12:46 PM Greg Shepherd wrote: > > Thanks Toerless and Jeffrey > > https://datatracker.ietf.org/doc/draft-ietf-bier-te-arch/ > > One more week of WGLC. Please read the latest rev and respond to this thr= ead w/wo support. > > Chairs > (Shep) > > > On Tue, Feb 18, 2020 at 12:07 PM Jeffrey (Zhaohui) Zhang wrote: >> >> Hi Toerless, >> >> Thanks! >> I support moving this to the next stage. >> >> Jeffrey >> >> On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote: >> > Thanks Jeff >> > >> > I have now pushed out -05 with the answers and hopefully resolution to >> > your points in email below. Biggest addition was a section about >> > reuse of BPs (without DNR) which came out of the confusion i think the >> > reuse in the ECMP example raised. I was afraid so far to explan that >> > as it may not be easy to absorb and ultimately is stuff only >> > controller developers need to understand, but hopefully useful. >> > And then of course the summary of BP optimizatins you asked for >> > >> > Diff from last version i sent you: >> > >> > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=3Dhttp= s: >> > **Araw.githubusercontent.com*toerless*bier-te-arch*master*draft-ietf-b >> > ier-te-arch-05.1.txt&url2=3Dhttp:**Atools.ietf.org*id*draft-ietf-bier-= te >> > -arch-05.txt__;Ly8vLy8vLy8vLy8!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzH >> > OCr0fZkLPbgg3CPNu0PyrWsrFx41_jWX2At8V-$ >> > >> > full -04 -> 05 diff: >> > >> > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=3Dhttp= :* >> > *Atools.ietf.org*id*draft-ietf-bier-te-arch-04.txt&url2=3Dhttp:**Atool= s. >> > ietf.org*id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk >> > !VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx41_jWancpziv$ >> > >> > Comments inline below. >> > >> > Cheers >> > toerless >> > >> > On Mon, Oct 28, 2019 at 07:52:59PM +0000, Jeffrey (Zhaohui) Zhang wrot= e: >> > > I Thought u-turn is the most simple comparison leaf vs. non-leaf BFR= . >> > > >> > > Zzh> The text in the email is seriously misaligned. Looking at the p= icture in the diff link, while you gave a U-turn example, though even if BF= ER2 is not connected to BFR2 but only connected to BFER1 (hence no U-turn)= , then BFER1 is still not a leaf BFER I suppose. That's why I said the firs= t sentence of the above paragraph is enough to define Leaf BFER while the e= xample itself is actually not needed. >> > >> > Argh... ok, had to fix two words, BFIR->BFER and left-hand -> right-ha= nd: >> > >> > Consider how redundant disjoint traffic can reach BFER1/BFER2 in above >> > picture: When BFER1/BFER2 are Non-Leaf BFER as shown on the right hand >> > side, one traffic copy would be forwarded to BFER1 from BFR1, but the >> > other one could only reach BFER1 via BFER2, which makes BFER2 a >> > non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forwarding >> > traffic to BFER2 >> > >> > > Zzh> Additionally, in left part of the picture you added, if some fa= ilure leads to BFR2 to be only reachable via BFER1, then BFER1 is no longer= a leaf BFER. >> > >> > Added sentence: >> > >> > Note that the BFER in the left hand picture are only guaranteed to >> > be leaf-BFR by fitting routing configuration that prohibits transit >> > traffic to pass through a PE, which is commonly applied in these >> > topologies. >> > >> > > I assume you don't reassign BPs when links go up and down. >> > >> > I didn't want to discuss that option in this document. Its obviously >> > perfectly feasible, but be yet a big amount of text (especially the >> > considerations how to do this make-before-break. Future doc. >> > >> > > > but subsequent polarization example confuses me. It seems that BP = 0:6 is assigned to the routed adjacency BFR10 (which is actually talked abo= ut in Section 4.8). >> > > >> > > Section 4.7 does not mention "routed" at all, so there are no routed= adjacencies at all used in 4.7. So i am not sure what you are confused abo= ut. >> > > >> > > Zzh> "The BIFT of each BFR are only populated with BPs that are adja= cent to the BFR in the BIER-TE topology". >> > >> > Correct text from the introduction. Ok. >> > >> > > Zzh> Since the same 0:6 is in BIFTS of BFR1/BFR2/BFR3 (and I suppose= in BFR4~BFR9 as well even though not drawn), I assumed it's for the "MP2P"= routed adjacency to R10; though I then ruled that out - but I don't know w= hat 0:6 represent now on BFR1, BFR2, and BFR3. >> > >> > Ah. Ok. I thought i could strip down the example to show only the >> > adjacencies relevant to the following discusion, but seemingly this >> > can introduce the confusion you have. >> > >> > So i completed the example with the BP assignment acoss all nodes, but >> > added text pointing to a new section further down to discuss the >> > re-use of BP for which thi picture is also an example. >> > >> > (check out the diff, new reuse text to long to copy inline). >> > >> > > The whole purpose of the ECMP BPs is of course to save bits, otherwi= se we'd give each link a separate BP, which would be 6 BP to reach to BFR4.= ..BFR7 from BFR1. >> > > >> > > Zzh> The trouble I am having is that the same 0:6 is assigned to dif= ferent things and it's present on all BFR1/BFR2/BFR3. It is perhaps an inte= ntional smart design but I have not wrapped my mind around it. It's apparen= tly different from the link bundle case, so better separate it out and elab= orate it (including the DNR flag that might be needed here - If the packet = arrives on BFR1 with 0:6, would the BP reset when it is sent to BFR2/3)? >> > >> > Yes, there was the bug of reusing BP 0:6 across sequential BFR along >> > the path, but now the example correctly reuses separate BP at >> > different stages of the paths (BP 0:6 on BFR1, BP 0:7 on BFR2/BFR3) an= d so on. >> > >> > Thanks! >> > >> > > > 4.8. Routed adjacencies >> > > > >> > > > If I understand it correctly, there is a BP assigned to L1/L2/L3 >> > > > respectively (p2p link), and then there are BPs assigned to MP2P t= unnels (routed adjacency from every BFR) to the L1/L2/L3 interface addresse= s and loopback addresses on BFR2/3. >> > > >> > > Ok that wasn't quite the read i expected. Let me clarify the text/pi= cture: >> > > >> > > ............... >> > > ...BFR1--... ...--L1-- BFR2... >> > > ... .Routers. ...--L2--/ >> > > ...BFR4--... ...------ BFR3... >> > > ............... | >> > > LO >> > > Network Area 1 >> > > >> > > Assume the requirement in the above picture is to explicitly steer t= raffic flows that have arrived at BFR1 or BFR4 via a shortest path in the r= outing underlay "network area 1" to one of the following three next segment= s: (1) BFR2 via link L1, (2) BFR2 via link L2, (3) via BFR3. >> > > >> > > To achieve this, both BFR1 and BFR4 are set up with a forward_routed= adjacency BitPosition towards an address of BFR2 on link L1, another forwa= rd_routed BitPosition towards an address of BFR2 on link L2 and a third for= ward_routed Bitposition towards a node address LO of BFR3. >> > > >> > > Does this clear ip the confusion ? >> > > >> > > Zzh> The picture is badly misaligned. I'll wait till 4.7 questions a= re cleared. >> > >> > Ok. >> > >> > > > If BFR2/3 are also BFERs, then they additionally will have BFER BP= s. >> > > > On BFR1/4, the BIFT entries for the MP2P BPs for the L1/L2/L3/loop= back interface addresses of BFR2/3 will use forward_routed(interface/loopba= ck address). For a packet to be decapsulated on a BFER, there is a need for= both the BFER BP and another BP (p2p/lan/hub-spoke/routed-adjacency) in th= e packet (the former is for decapsulation and the latter is for getting it = there). >> > > >> > > This is not discussed in this section, but you are right - unless >> > > BFR2 or BFR3 is a leaf BFR. In that case, it would just leverage the= one shared "leaf-BFR" BP, so they do not need a per-BFER BP for local_deca= p(). >> > > >> > > Zzh> Right - shared leaf-BFR BP but still need that BP (the key is t= hat we need a BP to get packet to a BFER and then a BP for decapsulation). >> > >> > You got it. >> > >> > > > If that???s the case, it???s worth point the above out. >> > > >> > > Hmm... The logic of BFER BPs is totally independent of the logic of = forward_routed adjacency, so i would worry that repeating the explanation o= f BFER BPs would conflate the forward_routed explanation. >> > > >> > > Zzh> It's just that this is a place where all kinds of BPs are used = so it's good to have a summary (could be a subsection 4.9). >> > >> > Yes, added such a summary. Pls. check. >> > >> > > > Actually, the reason that I thought this is MP2P is that 0:6 is pr= esent on R1, R2, and R3 (and more I assume) in Figure 12, but now I think i= t can???t be MP2P (so it is not correct to have 0:6 present on those router= s ??? only the p2p tunnel head/tail should have the BP present in the BIFT)= . The reason is that if it were MP2P, any router getting a copy will send i= t to the endpoint of the routed adjacency, causing lots of duplicates.. >> > > > >> > > > Am I getting this correct? >> > > >> > > I think you are still explaining from the misunderstsanding that the= ECMP explanations where about routed adjacencies. >> > > >> > > I have now expanded the somewhat terse text in the BIFT table pictur= es, to make it clear that the ECMP is across multipe forward_connected adja= cencies in the examples. For example, first BIFT picture: >> > > >> > > BIFT entry in BFR1: >> > > ------------------------------------------------------------------ >> > > | Index | Adjacencies | >> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >> > > | 0:6 | ECMP({forward_connected(L1, BFR2), | >> > > | | forward_connected(L2, BFR2), | >> > > | | forward_connected(L3, BFR2)}, seed) | >> > > ------------------------------------------------------------------ >> > > >> > > Of course, an ECMP adjacency can be across any type of adjacencies, = but all the text/explanations used forward_connected, and now the pictures = show that explicitly. >> > > >> > > Zzh> I can understand the multi-link case, but the multi-hop ECMP ca= se (from BFR1 towards BFR10) is confusing me. It would help to give an exam= ple how it can be used, WITHOUT worrying about polarization. >> > >> > Please check -05 text that has the full set of BIFT listed now: >> > >> > There is really nothing nothing unique in multi-hop ECMP for BIER-TE >> > that we do not also have in any other ECMP, except the conclusion that >> > we want to support fast HW hash mechanisms AND allow the controller to >> > set up non-polarized multi-hop ECMP AND be able to precalculate paths. >> > Hence the specification of ECMP adjacencies to have a controller >> > configurable seed. >> > >> > Btw: The picture is maybe unnecessarily large because i've used it for >> > 20 years to explain the same polarization issue for unicast vs >> > multicast, and for multicast only BFR10...BFR4 are relevant (ECMP of >> > the PIM/mLDP joins), whereas for unicast/BIER only >> > BFR1...BFR7 are relevant. But being symmetric, the picture makes it >> > clear its the same problem. >> > >> > > > To inhibit looping in the face of such physical misconfiguratio= n, >> > > > only forward_connected adjacencies are permitted to have DNR se= t, and >> > > > the link layer destination address of the adjacency (e.g. MAC >> > > > address) protects against closing the loop. Link layers withou= t port >> > > > unique link layer addresses should not be used with the DNR fla= g set. >> > > > >> > > > It???s not clear how link layer address helps? >> > > >> > > I have expanded this to >> > > "link layer port unique unicast destination address" >> > > >> > > Aka: MPLS or ethernet have unique link layer destination destination= addresses (label or destination MAC). If you think about incorrectly plugg= ed HDLC links (such as old T1/T3/... links), they only have 2 generic addre= sses, if i remember 1 or 3 in the HDLC frame. So when you misplug one of th= ose p2p cables wrong, the packets would be incrrectly received by the wrong= receiver node and then DNR could cause persistent loops only solved by TTL= . >> > > >> > > Zzh> "Consider in the ring picture that link L4 from BFR3 is plugged= into the L1 interface of BFRa" - still not sure how label/mac helps here. = I suppose the ring topology is discovered/verified by the control plane and= when the miscalling happens then the ring will not include the BFR1/BFR2 p= art and BFR3 will not have the DNR set? If ring discovery/varication is not= done then perhaps we should point out that RPF based on link layer address= is needed - the key is RPF (which needs unique link layer address)? >> > >> > Forget RPF. BIER(-TE) has no RPF (issues). Its just like unicast. RPF >> > is just a problem for receiver originated joins like in PIM/mLDP, but >> > not unicast/bier(-te)/RSVP-TE. >> > >> > Forward_connected is just like a unicast subnet adjacency to a direct >> > neighbor: Interface and L2 addresss of the destination. >> > >> > The controller (could be a human) "assumes" a particular physicial >> > topology, from telemetry/knowledge/whatever. It then calculates the >> > desired BIER-TE topology and pushes it down. This topology is meant to >> > be loop free of course wrt to the configured adjacencies. >> > In this BIER-TE topology, BFR3 will have a BP with the >> > forward_connected(L4, MAC-of-BFR2) adjacency. >> > >> > If the cable connecting to L4 is miswired, then BFR3 would still send >> > the packets to the MAC address of BFR2, but given how the cable >> > connects to some other node, these packets will be discarded by that >> > node. because they're just L2 unicast packets. >> > >> > I think this is equally true when we have normal BIER/MPLS enacp. >> > Those packets too are addressed to the unicast MAC address of the >> > neighbor. >> > >> > Now, if/when he controller recognizes that the physical topology has >> > changed, thats a completely different story and not addressed here. >> > Given how we assumed this was a cabling mistake, the controller would >> > probably only complain about the miswiring to operations but be happy >> > that the forwarding plane just makes packets fail instead of loop. If >> > this was a planned change process, then it will be similarily >> > convoluted as it would today be with rewiring cables in an >> > SR-MPLS/SRv6 topology and updating SIDs. >> > >> > > > Because the forwarding is different from BIER forwarding (because = of [1] above), we might as well introduce an optimization here ??? for each= BIFT, calculate the F-BM of the BIFT itself (the logical ???or??? of all t= he BPs presented in this BIFT) and then use (packet->bitstring & BIFT.F-BM)= as the input to GetFirst/NextBitPosition(). That should skip many bits. >> > > >> > > Right. But i explicitly removed those optimizations (i had them in o= lder draft versions) because the whole idea of this picture is solely the c= omparison with figure 4 of RFC8279. >> > > >> > > Zzh> I think it's worth point that optimization out; you can mark it= optional if you want to emphasize the similarity to BIER forwarding, but s= ince BIER forwarding does do the maskoff step, it is very efficient while B= IER-TE forwarding does not it the maskoff step so this optimization is impo= rtant. >> > >> > Ok. I simplified the text comparison BIER/BIER-TE wrt. to the FBM >> > rules [1] and [2] and added following paragraph: >> > >> > In BIER, the order of BPs impacts the result of forwarding because = of [1]. >> > In BIER-TE, forwarding is not impacted by the order of BPs. It is >> > therefore possible to further optimize forwarding than in BIER. For >> > example parallelizing forwarding across multiple FPE cores or >> > distributed linecards does only need to examine an arbitrary subset of >> > BP and not evaluate the dependency between BPs. >> > >> > > > The following pseudocode is comprehensive: >> > > > >> > > > The above sentence reads a bit strange (or lacks some segue).. >> > > >> > > I hope not, but maybe best left to a native english speaker (RFC-edi= tor). >> > > >> > > The first (RFC8279) pseudocode was simplified. The second one is com= prehensive. If not comprehensive, whats a good opposite of simplified ? >> > > >> > > Zzh> Perhaps "The above simplified pseudocode is elaborated further = as following"? >> > > Zzh> Jeffrey >> > >> > Done. >> > >> > Thanks a lot. >> > >> > >> > > >> > > > ________________________________________ >> > > > From: BIER [bier-bounces@ietf.org] >> > > > on behalf of Toerless Eckert [tte@cs.fau.de] >> > > > Sent: Tuesday, July 09, 2019 23:38 >> > > > To: Mike McBride >> > > > Cc: Greg Shepherd; BIER WG; Pascal Thubert (pthubert) >> > > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch >> > > > >> > > > Thanks, Mike >> > > > >> > > > The authors also reviewed the document and concluded that it was >> > > > really hard to get into the document context because of too many >> > > > forward dependencies. We tried to fix this by adding two hopefully >> > > > good & basic examples into the Introduction section and using them >> > > > to also add a better definition of the term "BIER-TE Topology" in = the Introduction. >> > > > Hopefully this makes readin the rest of te document smoother.. >> > > > >> > > > Also improved text of Abstract and refined text compariing BIER-TE= with SR. >> > > > >> > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=3D= https: >> > > > **Atools.ietf.org*id*draft-ietf-bier-te-arch-02.txt&url2=3Dhttps:*= *A >> > > > tool >> > > > s.ietf.org*id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R >> > > > jC81 >> > > > c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV_eTUEh >> > > > $ >> > > > > > > > **Atools.ietf.org*id*draft-ietf-bier-te-arch-02.txt&url2=3Dhttps:*= *A >> > > > tool >> > > > s.ietf.org*id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R >> > > > jC81 >> > > > c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sNd1njcX >> > > > $> >> > > > >> > > > Cheers >> > > > Toerless >> > > > >> > > > On Wed, Jun 26, 2019 at 10:39:36AM -0700, Mike McBride wrote: >> > > > > How about three? I support. >> > > > > mike >> > > > > >> > > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd > wrote: >> > > > > > >> > > > > > We cannot take two 'yes' votes and WG consensus. >> > > > > > Please, read and respond. If you don't support, then please vo= te as much publicly right here. >> > > > > > >> > > > > > Thanks, >> > > > > > Greg >> > > > > > >> > > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert (pthubert) > wrote: >> > > > > >> >> > > > > >> Support: >> > > > > >> >> > > > > >> I see great value in deterministic networks as well as IOT (w= ith RPL). >> > > > > >> >> > > > > >> All the best, >> > > > > >> >> > > > > >> Pascal >> > > > > >> >> > > > > >> > -----Original Message----- >> > > > > >> > From: BIER >> > > > > >> > > On >> > > > > >> > Behalf Of Toerless Eckert >> > > > > >> > Sent: mardi 4 juin 2019 02:03 >> > > > > >> > To: Greg Shepherd >> > > > > >> > > >> > > > > >> > Cc: BIER WG > >> > > > > >> > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch >> > > > > >> > >> > > > > >> > +1 >> > > > > >> > Obviously support as co-author. >> > > > > >> > >> > > > > >> > On Wed, May 29, 2019 at 12:41:26PM -0700, Greg Shepherd wro= te: >> > > > > >> > > Please read and respond to this thread w/ or w/o support. >> > > > > >> > > >> > > > > >> > > https://urldefense.com/v3/__https://datatracker..ietf.org >> > > > > >> > > /doc >> > > > > >> > > /draft-ietf-bier-te-arch/__;!8WoA6RjC81c!XvH4AAxfrDjFoK_s >> > > > > >> > > ercw ZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV9eClBj$ >> > > > > >> > > > > > > > >> > > doc/ >> > > > > >> > > draft-ietf-bier-te-arch/__;!8WoA6RjC81c!UBTGvWWpMHyeiSanx >> > > > > >> > > s6vI b_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sD40kmtH$> >> > > > > >> > > >> > > > > >> > > Vote ends 5 June 2019. >> > > > > >> > > >> > > > > >> > > Thanks, >> > > > > >> > > Shep >> > > > > >> > > (chairs) >> > > > > >> > >> > > > > >> > > _______________________________________________ >> > > > > >> > > BIER mailing list >> > > > > >> > > BIER@ietf.org >> > > > > >> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/ >> > > > > >> > > list >> > > > > >> > > info/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eE >> > > > > >> > > NOs4 l_qdsXF0KwZD82cJLDFFNT2WVXWX$ >> > > > > >> > > > > > > > >> > > list >> > > > > >> > > info/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6b >> > > > > >> > > oAAW 4nrqju8UCLOgiuXc8Y_6sKn2KoAT$> >> > > > > >> > >> > > > > >> > _______________________________________________ >> > > > > >> > BIER mailing list >> > > > > >> > BIER@ietf.org >> > > > > >> > https://urldefense.com/v3/__https://www.ietf.org/mailman/li >> > > > > >> > stin >> > > > > >> > fo/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4 >> > > > > >> > l_qd >> > > > > >> > sXF0KwZD82cJLDFFNT2WVXWX$ >> > > > > >> > > > > > > >> > stin >> > > > > >> > fo/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW >> > > > > >> > 4nrq >> > > > > >> > ju8UCLOgiuXc8Y_6sKn2KoAT$> >> > > > > > >> > > > > > _______________________________________________ >> > > > > > BIER mailing list >> > > > > > BIER@ietf.org >> > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listi >> > > > > > nfo/ >> > > > > > bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsX >> > > > > > F0Kw >> > > > > > ZD82cJLDFFNT2WVXWX$ >> > > > > > > > > > > > nfo/ >> > > > > > bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju >> > > > > > 8UCL >> > > > > > OgiuXc8Y_6sKn2KoAT$> >> > > > >> > > > -- >> > > > --- >> > > > tte@cs.fau.de >> > > > >> > > > _______________________________________________ >> > > > BIER mailing list >> > > > BIER@ietf..org >> > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ >> > > > bier >> > > > __;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82 >> > > > cJLD >> > > > FFNT2WVXWX$ >> > > > > > > > bier >> > > > __;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiu >> > > > Xc8Y >> > > > _6sKn2KoAT$> >> > > >> > > -- >> > > --- >> > > tte@cs.fau.de >> > >> > -- >> > --- >> > tte@cs.fau.de >> > >> > _______________________________________________ >> > BIER mailing list >> > BIER@ietf.org >> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier >> > __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx4 >> > 1_jWV3YUA6D$ >> >> -- >> --- >> tte@cs.fau.de >> >> _______________________________________________ >> BIER mailing list >> BIER@ietf.org >> https://www.ietf.org/mailman/listinfo/bier > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier From nobody Wed Feb 19 15:38:51 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E4C120819 for ; Wed, 19 Feb 2020 15:38:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 3kSpR2NIMTlj for ; Wed, 19 Feb 2020 15:38:42 -0800 (PST) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) (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 9A285120802 for ; Wed, 19 Feb 2020 15:38:42 -0800 (PST) Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id 4FA224011E for ; Wed, 19 Feb 2020 16:38:41 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id 4YvRjgHV6DbTf4YvRjAUr8; Wed, 19 Feb 2020 16:38:41 -0700 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.3 cv=IPIs9DnG c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=l697ptgUJYAA:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=uherdBYGAAAA:8 a=bt8Zh30PAAAA:8 a=pGLkceISAAAA:8 a=AUd_NHdVAAAA:8 a=Csye_UTfkrvBZwCUVKsA:9 a=qI4i0PTGz7MyOhgc:21 a=UwHqqnWCzft31z6e:21 a=7tK4qQerbkCMhLv0:21 a=QEXdDO2ut3YA:10:nop_charset_2 a=SVmHTikTonYNA9-IrbYA:9 a=IrRbKCkPa0rUP_Bt:21 a=07mmDmIcmaXSXpeY:21 a=dnEAPAky9ajSh10W:21 a=_W_S_7VecoQA:10:nop_html a=w1C3t2QeGrPiZgrLijVG:22 a=Ef4yma5cpRUEJWN9UqBm:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Sender:Reply-To:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=1b1zvJuWnWZIv+ZG1F+pcjRit6812/uj2Q08KZzyM5M=; b=MdactAVStuOxFmoYKdlwLkk/28 FTLwu44iLIXeXP0bbmJgR9KXztNQoh4bFJS7odD0QFm9LI3TNBC5gSX7uAVhCKtXcb6UYk5BR+6uj 12E4UGKa2FGv9MXPWTq+9Inb9; Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:60024 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1j4YvQ-004Oa8-Mk; Wed, 19 Feb 2020 16:38:40 -0700 To: gjshep@gmail.com, "Jeffrey (Zhaohui) Zhang" Cc: Toerless Eckert , "bier@ietf.org" References: From: Lou Berger Message-ID: <11ab30da-8701-b491-6162-5a69aa9d6965@labn.net> Date: Wed, 19 Feb 2020 18:38:38 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6F80FBDB24E277E1005287E5" Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 72.66.11.201 X-Source-L: No X-Exim-ID: 1j4YvQ-004Oa8-Mk X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net (fs2.dc.labn.net) [72.66.11.201]:60024 X-Source-Auth: lberger@labn.net X-Email-Count: 9 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Org: HG=bhcustomer;ORG=bluehost; X-Local-Domain: yes Archived-At: Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2020 23:38:49 -0000 This is a multi-part message in MIME format. --------------6F80FBDB24E277E1005287E5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi,     I have no issue or objection to the mechanisms being defined in this document as much as they go, but I was quite disappointed that despite the name of the document and use of 'bier-te'  to see that the document doesn't define any traffic engineering support, at least as far as the term has been used in IETF RFCs.  In particular it totally lacks any discussion of resources usage and/or allocation.  What it currently describes certainly provides good and useful path/traffic steering that can be used to support policy-based routing.  Basically it does the same as what is defined by draft-ietf-spring-segment-routing-policy. I personally (not speaking for the related WGs that I chair) would prefer to see this document be revised  to include resource allocation that would allow BIER-TE to support TE usage such as DetNet.  Barring such an addition, I'm against publication of this document as is and I think the document should be recast and renamed to be aligned with the SR example, i.e., BIER routing policy (or path steering). Lou On 2/18/20 3:45 PM, Greg Shepherd wrote: > Thanks Toerless and Jeffrey > > https://datatracker.ietf.org/doc/draft-ietf-bier-te-arch/ > > One more week of WGLC. Please read the latest rev and respond to this > thread w/wo support. > > Chairs > (Shep) > > > On Tue, Feb 18, 2020 at 12:07 PM Jeffrey (Zhaohui) Zhang > > wrote: > > Hi Toerless, > > Thanks! > I support moving this to the next stage. > > Jeffrey > > On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote: > > Thanks Jeff > > > > I have now pushed out -05 with the answers and hopefully > resolution to > > your points in email below.  Biggest addition was a section about > > reuse of BPs (without DNR) which came out of the confusion i > think the > > reuse in the ECMP example raised. I was afraid so far to explan > that > > as it may not be easy to absorb and ultimately is stuff only > > controller developers need to understand, but hopefully useful. > > And then of course the summary of BP optimizatins you asked for > > > > Diff from last version i sent you: > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: > > **Araw.githubusercontent.com > *toerless*bier-te-arch*master*draft-ietf-b > > ier-te-arch-05.1.txt&url2=http:**Atools.ietf.org > *id*draft-ietf-bier-te > > > -arch-05.txt__;Ly8vLy8vLy8vLy8!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzH > > OCr0fZkLPbgg3CPNu0PyrWsrFx41_jWX2At8V-$ > > > > full -04 -> 05 diff: > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=http:* > > *Atools.ietf.org > *id*draft-ietf-bier-te-arch-04.txt&url2=http:**Atools. > > ietf.org > *id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk > > !VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx41_jWancpziv$ > > > > Comments inline below. > > > > Cheers > >     toerless > > > > On Mon, Oct 28, 2019 at 07:52:59PM +0000, Jeffrey (Zhaohui) > Zhang wrote: > > > I Thought u-turn is the most simple comparison leaf vs. > non-leaf BFR. > > > > > > Zzh> The text in the email is seriously misaligned. Looking at > the picture in the diff link, while you gave a U-turn example, > though even if BFER2 is not connected to BFR2  but only connected > to BFER1 (hence no U-turn), then BFER1 is still not a leaf BFER I > suppose. That's why I said the first sentence of the above > paragraph is enough to define Leaf BFER while the example itself > is actually not needed. > > > > Argh... ok, had to fix two words, BFIR->BFER and left-hand -> > right-hand: > > > > Consider how redundant disjoint traffic can reach BFER1/BFER2 in > above > > picture: When BFER1/BFER2 are Non-Leaf BFER as shown on the > right hand > > side, one traffic copy would be forwarded to BFER1 from BFR1, > but the > > other one could only reach BFER1 via BFER2, which makes BFER2 a > > non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forwarding > > traffic to BFER2 > > > > > Zzh> Additionally, in left part of the picture you added, if > some failure leads to BFR2 to be only reachable via BFER1, then > BFER1 is no longer a leaf BFER. > > > > Added sentence: > > > > Note that the BFER in the left hand picture are only > guaranteed to > > be leaf-BFR by fitting routing configuration that prohibits transit > > traffic to pass through a PE, which is commonly applied in these > > topologies. > > > > > I assume you don't reassign BPs when links go up and down. > > > > I didn't want to discuss that option in this document. Its > obviously > > perfectly feasible, but be yet a big amount of text (especially the > > considerations how to do this make-before-break. Future doc. > > > > > > but subsequent polarization example confuses me. It seems > that BP 0:6 is assigned to the routed adjacency BFR10 (which is > actually talked about in Section 4.8). > > > > > > Section 4.7 does not mention "routed" at all, so there are no > routed adjacencies at all used in 4.7. So i am not sure what you > are confused about. > > > > > > Zzh> "The BIFT of each BFR are only populated with BPs that > are adjacent to the BFR in the BIER-TE topology". > > > > Correct text from the introduction. Ok. > > > > > Zzh> Since the same 0:6 is in BIFTS of BFR1/BFR2/BFR3 (and I > suppose in BFR4~BFR9 as well even though not drawn), I assumed > it's for the "MP2P" routed adjacency to R10; though I then ruled > that out - but I don't know what 0:6 represent now on BFR1, BFR2, > and BFR3. > > > > Ah. Ok. I thought i could strip down the example to show only the > > adjacencies relevant to the following discusion, but seemingly this > > can introduce the confusion you have. > > > > So i completed the example with the BP assignment acoss all > nodes, but > > added text pointing to a new section further down to discuss the > > re-use of BP for which thi picture is also an example. > > > > (check out the diff, new reuse text to long to copy inline). > > > > > The whole purpose of the ECMP BPs is of course to save bits, > otherwise we'd give each link a separate BP, which would be 6 BP > to reach to BFR4...BFR7 from BFR1. > > > > > > Zzh> The trouble I am having is that the same 0:6 is assigned > to different things and it's present on all BFR1/BFR2/BFR3. It is > perhaps an intentional smart design but I have not wrapped my mind > around it. It's apparently different from the link bundle case, so > better separate it out and elaborate it (including the DNR flag > that might be needed here - If the packet arrives on BFR1 with > 0:6, would the BP reset when it is sent to BFR2/3)? > > > > Yes, there was the bug of reusing BP 0:6 across sequential BFR > along > > the path, but now the example correctly reuses separate BP at > > different stages of the paths (BP 0:6 on BFR1, BP 0:7 on > BFR2/BFR3) and so on. > > > > Thanks! > > > > > > 4.8.  Routed adjacencies > > > > > > > > If I understand it correctly, there is a BP assigned to > L1/L2/L3 > > > > respectively (p2p link), and then there are BPs assigned to > MP2P tunnels (routed adjacency from every BFR) to the L1/L2/L3 > interface addresses and loopback addresses on BFR2/3. > > > > > > Ok that wasn't quite the read i expected. Let me clarify the > text/picture: > > > > > >                    ............... > > >          ...BFR1--...           ...--L1-- BFR2... > > >                   ... .Routers. ...--L2--/ > > >          ...BFR4--...           ...------ BFR3... > > >                    ...............         | > > >                                           LO > > >                     Network Area 1 > > > > > > Assume the requirement in the above picture is to explicitly > steer traffic flows that have arrived at BFR1 or BFR4 via a > shortest path in the routing underlay "network area 1" to one of > the following three next segments: (1) BFR2 via link L1, (2) BFR2 > via link L2, (3) via BFR3. > > > > > > To achieve this, both BFR1 and BFR4 are set up with a > forward_routed adjacency BitPosition towards an address of BFR2 on > link L1, another forward_routed BitPosition towards an address of > BFR2 on link L2 and a third forward_routed Bitposition towards a > node address LO of BFR3. > > > > > > Does this clear ip the confusion ? > > > > > > Zzh> The picture is badly misaligned. I'll wait till 4.7 > questions are cleared. > > > > Ok. > > > > > > If BFR2/3 are also BFERs, then they additionally will have > BFER BPs. > > > > On BFR1/4, the BIFT entries for the MP2P BPs for the > L1/L2/L3/loopback interface addresses of BFR2/3 will use > forward_routed(interface/loopback address). For a packet to be > decapsulated on a BFER, there is a need for both the BFER BP and > another BP (p2p/lan/hub-spoke/routed-adjacency) in the packet (the > former is for decapsulation and the latter is for getting it there). > > > > > > This is not discussed in this section, but you are right - unless > > > BFR2 or BFR3 is a leaf BFR. In that case, it would just > leverage the one shared "leaf-BFR" BP, so they do not need a > per-BFER BP for local_decap(). > > > > > > Zzh> Right - shared leaf-BFR BP but still need that BP (the > key is that we need a BP to get packet to a BFER and then a BP for > decapsulation). > > > > You got it. > > > > > > If that???s the case, it???s worth point the above out. > > > > > > Hmm... The logic of BFER BPs is totally independent of the > logic of forward_routed adjacency, so i would worry that repeating > the explanation of BFER BPs would conflate the forward_routed > explanation. > > > > > > Zzh> It's just that this is a place where all kinds of BPs are > used so it's good to have a summary (could be a subsection 4.9). > > > > Yes, added such a summary. Pls. check. > > > > > > Actually, the reason that I thought this is MP2P is that 0:6 > is present on R1, R2, and R3 (and more I assume) in Figure 12, but > now I think it can???t be MP2P (so it is not correct to have 0:6 > present on those routers ??? only the p2p tunnel head/tail should > have the BP present in the BIFT). The reason is that if it were > MP2P, any router getting a copy will send it to the endpoint of > the routed adjacency, causing lots of duplicates. > > > > > > > > Am I getting this correct? > > > > > > I think you are still explaining from the misunderstsanding > that the ECMP explanations where about routed adjacencies. > > > > > > I have now expanded the somewhat terse text in the BIFT table > pictures, to make it clear that the ECMP is across multipe > forward_connected adjacencies in the examples. For example, first > BIFT picture: > > > > > >   BIFT entry in BFR1: > > > >  ------------------------------------------------------------------ > > >   | Index |  Adjacencies                  | > > > >  ================================================================== > > >   | 0:6   |  ECMP({forward_connected(L1, BFR2),                 | > > >   |       |        forward_connected(L2, BFR2),                 | > > >   |       |        forward_connected(L3, BFR2)}, seed)        >      | > > > >  ------------------------------------------------------------------ > > > > > > Of course, an ECMP adjacency can be across any type of > adjacencies, but all the text/explanations used forward_connected, > and now the pictures show that explicitly. > > > > > > Zzh> I can understand the multi-link case, but the multi-hop > ECMP case (from BFR1 towards BFR10) is confusing me. It would help > to give an example how it can be used, WITHOUT worrying about > polarization. > > > > Please check -05 text that has the full set of BIFT listed now: > > > > There is  really nothing nothing unique in multi-hop ECMP for > BIER-TE > > that we do not also have in any other ECMP, except the > conclusion that > > we want to support fast HW hash mechanisms AND allow the > controller to > > set up non-polarized multi-hop ECMP AND be able to precalculate > paths. > > Hence the specification of ECMP adjacencies to have a controller > > configurable seed. > > > > Btw: The picture is maybe unnecessarily large because i've used > it for > > 20 years to explain the same polarization issue for unicast vs > > multicast, and for multicast only BFR10...BFR4 are relevant > (ECMP of > > the PIM/mLDP joins), whereas for unicast/BIER only > > BFR1...BFR7 are relevant. But being symmetric, the picture makes it > > clear its the same problem. > > > > > >    To inhibit looping in the face of such physical > misconfiguration, > > > >    only forward_connected adjacencies are permitted to have > DNR set, and > > > >    the link layer destination address of the adjacency > (e.g.  MAC > > > >    address) protects against closing the loop.  Link layers > without port > > > >    unique link layer addresses should not be used with the > DNR flag set. > > > > > > > > It???s not clear how link layer address helps? > > > > > > I have expanded this to > > > "link layer port unique unicast destination address" > > > > > > Aka: MPLS or ethernet have unique link layer destination > destination addresses (label or destination MAC). If you think > about incorrectly plugged HDLC links (such as old T1/T3/... > links), they only have 2 generic addresses, if i remember 1 or 3 > in the HDLC frame. So when you misplug one of those p2p cables > wrong, the packets would be incrrectly received by the wrong > receiver node and then DNR could cause persistent loops only > solved by TTL. > > > > > > Zzh> "Consider in the ring picture that link L4 from BFR3 is > plugged into the L1 interface of BFRa" - still not sure how > label/mac helps here. I suppose the ring topology is > discovered/verified by the control plane and when the miscalling > happens then the ring will not include the BFR1/BFR2 part and BFR3 > will not have the DNR set? If ring discovery/varication is not > done then perhaps we should point out that RPF based on link layer > address is needed - the key is RPF (which needs unique link layer > address)? > > > > Forget RPF. BIER(-TE) has no RPF (issues). Its just like > unicast. RPF > > is just a problem for receiver originated joins like in > PIM/mLDP, but > > not unicast/bier(-te)/RSVP-TE. > > > > Forward_connected is just like a unicast subnet adjacency to a > direct > > neighbor: Interface and L2 addresss of the destination. > > > > The controller (could be a human) "assumes" a particular physicial > > topology, from telemetry/knowledge/whatever. It then calculates the > > desired BIER-TE topology and pushes it down. This topology is > meant to > > be loop free of course wrt to the configured adjacencies. > > In this BIER-TE topology, BFR3 will have a BP with the > > forward_connected(L4, MAC-of-BFR2) adjacency. > > > > If the cable connecting to L4 is miswired, then BFR3 would still > send > > the packets to the MAC address of BFR2, but given how the cable > > connects to some other node, these packets will be discarded by > that > > node. because they're just L2 unicast packets. > > > > I think this is equally true when we have normal BIER/MPLS enacp. > > Those packets too are addressed to the unicast MAC address of the > > neighbor. > > > > Now, if/when he controller recognizes that the physical topology > has > > changed, thats a completely different story and not addressed here. > > Given how we assumed this was a cabling mistake, the controller > would > > probably only complain about the miswiring to operations but be > happy > > that the forwarding plane just makes packets fail instead of > loop. If > > this was a planned change process, then it will be similarily > > convoluted as it would today be with rewiring cables in an > > SR-MPLS/SRv6 topology and updating SIDs. > > > > > > Because the forwarding is different from BIER forwarding > (because of [1] above), we might as well introduce an optimization > here ??? for each BIFT, calculate the F-BM of the BIFT itself (the > logical ???or??? of all the BPs presented in this BIFT) and then > use (packet->bitstring & BIFT.F-BM) as the input to > GetFirst/NextBitPosition(). That should skip many bits. > > > > > > Right. But i explicitly removed those optimizations (i had > them in older draft versions) because the whole idea of this > picture is solely the comparison with figure 4 of RFC8279. > > > > > > Zzh> I think it's worth point that optimization out; you can > mark it optional if you want to emphasize the similarity to BIER > forwarding, but since BIER forwarding does do the maskoff step, it > is very efficient while BIER-TE forwarding does not it the maskoff > step so this optimization is important. > > > > Ok. I simplified the text comparison BIER/BIER-TE wrt. to the FBM > > rules [1] and [2] and added following paragraph: > > > > In BIER, the order of BPs impacts the result of forwarding > because of [1]. > > In BIER-TE, forwarding is not impacted by the order of BPs. It is > > therefore possible to further optimize forwarding than in BIER. For > > example parallelizing forwarding across multiple FPE cores or > > distributed linecards does only need to examine an arbitrary > subset of > > BP and not evaluate the dependency between BPs. > > > > > >    The following pseudocode is comprehensive: > > > > > > > > The above sentence reads a bit strange (or lacks some segue). > > > > > > I hope not, but maybe best left to a native english speaker > (RFC-editor). > > > > > > The first (RFC8279) pseudocode was simplified. The second one > is comprehensive. If not comprehensive, whats a good opposite of > simplified ? > > > > > > Zzh> Perhaps "The above simplified pseudocode is elaborated > further as following"? > > > Zzh> Jeffrey > > > > Done. > > > > Thanks a lot. > > > > > > > > > > > ________________________________________ > > > > From: BIER [bier-bounces@ietf.org > >] > > > > on behalf of Toerless Eckert [tte@cs.fau.de > >] > > > > Sent: Tuesday, July 09, 2019 23:38 > > > > To: Mike McBride > > > > Cc: Greg Shepherd; BIER WG; Pascal Thubert (pthubert) > > > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch > > > > > > > > Thanks, Mike > > > > > > > > The authors also reviewed the document and concluded that it > was > > > > really hard to get into the document context because of too > many > > > > forward dependencies. We tried to fix this by adding two > hopefully > > > > good & basic examples into the Introduction section and > using them > > > > to also add a better definition of the term "BIER-TE > Topology" in the Introduction. > > > > Hopefully this makes readin the rest of te document smoother. > > > > > > > > Also improved text of Abstract and refined text compariing > BIER-TE with SR. > > > > > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: > > > > **Atools.ietf.org > *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A > > > > tool > > > > s.ietf.org > *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R > > > > jC81 > > > > > c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV_eTUEh > > > > $ > > > > > > > > **Atools.ietf.org > *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A > > > > tool > > > > s.ietf.org > *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R > > > > jC81 > > > > > c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sNd1njcX > > > > $> > > > > > > > > Cheers > > > >     Toerless > > > > > > > > On Wed, Jun 26, 2019 at 10:39:36AM -0700, Mike McBride wrote: > > > > > How about three? I support. > > > > > mike > > > > > > > > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd > >> wrote: > > > > > > > > > > > > We cannot take two 'yes' votes and WG consensus. > > > > > > Please, read and respond. If you don't support, then > please vote as much publicly right here. > > > > > > > > > > > > Thanks, > > > > > > Greg > > > > > > > > > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert > (pthubert) >> wrote: > > > > > >> > > > > > >> Support: > > > > > >> > > > > > >> I see great value in deterministic networks as well as > IOT (with RPL). > > > > > >> > > > > > >> All the best, > > > > > >> > > > > > >> Pascal > > > > > >> > > > > > >> > -----Original Message----- > > > > > >> > From: BIER > > > > > >> > >> On > > > > > >> > Behalf Of Toerless Eckert > > > > > >> > Sent: mardi 4 juin 2019 02:03 > > > > > >> > To: Greg Shepherd > > > > > >> > >> > > > > > >> > Cc: BIER WG >> > > > > > >> > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch > > > > > >> > > > > > > >> > +1 > > > > > >> > Obviously support as co-author. > > > > > >> > > > > > > >> > On Wed, May 29, 2019 at 12:41:26PM -0700, Greg > Shepherd wrote: > > > > > >> > > Please read and respond to this thread w/ or w/o > support. > > > > > >> > > > > > > > >> > > > https://urldefense.com/v3/__https://datatracker..ietf.org > > > > > >> > > /doc > > > > > >> > > > /draft-ietf-bier-te-arch/__;!8WoA6RjC81c!XvH4AAxfrDjFoK_s > > > > > >> > > ercw ZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV9eClBj$ > > > > > >> > > > > > > > >> > > doc/ > > > > > >> > > > draft-ietf-bier-te-arch/__;!8WoA6RjC81c!UBTGvWWpMHyeiSanx > > > > > >> > > s6vI b_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sD40kmtH$> > > > > > >> > > > > > > > >> > > Vote ends 5 June 2019. > > > > > >> > > > > > > > >> > > Thanks, > > > > > >> > > Shep > > > > > >> > > (chairs) > > > > > >> > > > > > > >> > > _______________________________________________ > > > > > >> > > BIER mailing list > > > > > >> > > BIER@ietf.org > > > > > > > >> > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/ > > > > > >> > > list > > > > > >> > > > info/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eE > > > > > >> > > NOs4 l_qdsXF0KwZD82cJLDFFNT2WVXWX$ > > > > > >> > > > > > > > >> > > list > > > > > >> > > > info/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6b > > > > > >> > > oAAW 4nrqju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > > >> > > > > > > >> > _______________________________________________ > > > > > >> > BIER mailing list > > > > > >> > BIER@ietf.org > > > > > > > >> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/li > > > > > >> > stin > > > > > >> > > fo/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4 > > > > > >> > l_qd > > > > > >> > sXF0KwZD82cJLDFFNT2WVXWX$ > > > > > >> > > > > > > >> > stin > > > > > >> > > fo/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW > > > > > >> > 4nrq > > > > > >> > ju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > > > > > > > > > _______________________________________________ > > > > > > BIER mailing list > > > > > > BIER@ietf.org > > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listi > > > > > > nfo/ > > > > > > > bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsX > > > > > > F0Kw > > > > > > ZD82cJLDFFNT2WVXWX$ > > > > > > > > > > > > nfo/ > > > > > > > bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju > > > > > > 8UCL > > > > > > OgiuXc8Y_6sKn2KoAT$> > > > > > > > > -- > > > > --- > > > > tte@cs.fau.de > > > > > > > > > _______________________________________________ > > > > BIER mailing list > > > > BIER@ietf.org > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ > > > > bier > > > > > __;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82 > > > > cJLD > > > > FFNT2WVXWX$ > > > > > > > > bier > > > > > __;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiu > > > > Xc8Y > > > > _6sKn2KoAT$> > > > > > > -- > > > --- > > > tte@cs.fau.de > > > > -- > > --- > > tte@cs.fau.de > > > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier > > > __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx4 > > 1_jWV3YUA6D$ > > -- > --- > tte@cs.fau.de > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > --------------6F80FBDB24E277E1005287E5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

    I have no issue or objection to the mechanisms being defined in this document as much as they go, but I was quite disappointed that despite the name of the document and use of 'bier-te'  to see that the document doesn't define any traffic engineering support, at least as far as the term has been used in IETF RFCs.  In particular it totally lacks any discussion of resources usage and/or allocation.  What it currently describes certainly provides good and useful path/traffic steering that can be used to support policy-based routing.  Basically it does the same as what is defined by draft-ietf-spring-segment-routing-policy. 

I personally (not speaking for the related WGs that I chair) would prefer to see this document be revised  to include resource allocation that would allow BIER-TE to support TE usage such as DetNet.  Barring such an addition, I'm against publication of this document as is and I think the document should be recast and renamed to be aligned with the SR example, i.e., BIER routing policy (or path steering).

Lou

On 2/18/20 3:45 PM, Greg Shepherd wrote:
Thanks Toerless and Jeffrey


One more week of WGLC. Please read the latest rev and respond to this thread w/wo support.

Chairs
(Shep)


On Tue, Feb 18, 2020 at 12:07 PM Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org> wrote:
Hi Toerless,

Thanks!
I support moving this to the next stage.

Jeffrey

On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote:
> Thanks Jeff
>
> I have now pushed out -05 with the answers and hopefully resolution to
> your points in email below.  Biggest addition was a section about
> reuse of BPs (without DNR) which came out of the confusion i think the
> reuse in the ECMP example raised. I was afraid so far to explan that
> as it may not be easy to absorb and ultimately is stuff only
> controller developers need to understand, but hopefully useful.
> And then of course the summary of BP optimizatins you asked for
>
> Diff from last version i sent you:
>
> https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https:
> **Araw.githubusercontent.com*toerless*bier-te-arch*master*draft-ietf-b
> ier-te-arch-05.1.txt&url2=http:**Atools.ietf.org*id*draft-ietf-bier-te
> -arch-05.txt__;Ly8vLy8vLy8vLy8!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzH
> OCr0fZkLPbgg3CPNu0PyrWsrFx41_jWX2At8V-$
>
> full -04 -> 05 diff:
>
> https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=http:*
> *Atools.ietf.org*id*draft-ietf-bier-te-arch-04.txt&url2=http:**Atools.
> ietf.org*id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk
> !VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx41_jWancpziv$
>
> Comments inline below.
>
> Cheers
>     toerless
>
> On Mon, Oct 28, 2019 at 07:52:59PM +0000, Jeffrey (Zhaohui) Zhang wrote:
> > I Thought u-turn is the most simple comparison leaf vs. non-leaf BFR.
> >
> > Zzh> The text in the email is seriously misaligned. Looking at the picture in the diff link, while you gave a U-turn example, though even if BFER2 is not connected to BFR2  but only connected to BFER1 (hence no U-turn), then BFER1 is still not a leaf BFER I suppose. That's why I said the first sentence of the above paragraph is enough to define Leaf BFER while the example itself is actually not needed.
>
> Argh... ok, had to fix two words, BFIR->BFER and left-hand -> right-hand:
>
> Consider how redundant disjoint traffic can reach BFER1/BFER2 in above
> picture: When BFER1/BFER2 are Non-Leaf BFER as shown on the right hand
> side, one traffic copy would be forwarded to BFER1 from BFR1, but the
> other one could only reach BFER1 via BFER2, which makes BFER2 a
> non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forwarding
> traffic to BFER2
>
> > Zzh> Additionally, in left part of the picture you added, if some failure leads to BFR2 to be only reachable via BFER1, then BFER1 is no longer a leaf BFER.
>
> Added sentence:
>
> <t>Note that the BFER in the left hand picture are only guaranteed to
> be leaf-BFR by fitting routing configuration that prohibits transit
> traffic to pass through a PE, which is commonly applied in these
> topologies.</t>
>
> > I assume you don't reassign BPs when links go up and down.
>
> I didn't want to discuss that option in this document. Its obviously
> perfectly feasible, but be yet a big amount of text (especially the
> considerations how to do this make-before-break. Future doc.
>
> > > but subsequent polarization example confuses me. It seems that BP 0:6 is assigned to the routed adjacency BFR10 (which is actually talked about in Section 4.8).
> >
> > Section 4.7 does not mention "routed" at all, so there are no routed adjacencies at all used in 4.7. So i am not sure what you are confused about.
> >
> > Zzh> "The BIFT of each BFR are only populated with BPs that are adjacent to the BFR in the BIER-TE topology".
>
> Correct text from the introduction. Ok.
>
> > Zzh> Since the same 0:6 is in BIFTS of BFR1/BFR2/BFR3 (and I suppose in BFR4~BFR9 as well even though not drawn), I assumed it's for the "MP2P" routed adjacency to R10; though I then ruled that out - but I don't know what 0:6 represent now on BFR1, BFR2, and BFR3.
>
> Ah. Ok. I thought i could strip down the example to show only the
> adjacencies relevant to the following discusion, but seemingly this
> can introduce the confusion you have.
>
> So i completed the example with the BP assignment acoss all nodes, but
> added text pointing to a new section further down to discuss the
> re-use of BP for which thi picture is also an example.
>
> (check out the diff, new reuse text to long to copy inline).
>
> > The whole purpose of the ECMP BPs is of course to save bits, otherwise we'd give each link a separate BP, which would be 6 BP to reach to BFR4...BFR7 from BFR1.
> >
> > Zzh> The trouble I am having is that the same 0:6 is assigned to different things and it's present on all BFR1/BFR2/BFR3. It is perhaps an intentional smart design but I have not wrapped my mind around it. It's apparently different from the link bundle case, so better separate it out and elaborate it (including the DNR flag that might be needed here - If the packet arrives on BFR1 with 0:6, would the BP reset when it is sent to BFR2/3)?
>
> Yes, there was the bug of reusing BP 0:6 across sequential BFR along
> the path, but now the example correctly reuses separate BP at
> different stages of the paths (BP 0:6 on BFR1, BP 0:7 on BFR2/BFR3) and so on.
>
> Thanks!
>
> > > 4.8.  Routed adjacencies
> > >
> > > If I understand it correctly, there is a BP assigned to L1/L2/L3
> > > respectively (p2p link), and then there are BPs assigned to MP2P tunnels (routed adjacency from every BFR) to the L1/L2/L3 interface addresses and loopback addresses on BFR2/3.
> >
> > Ok that wasn't quite the read i expected. Let me clarify the text/picture:
> >
> >                    ...............     
> >          ...BFR1--...           ...--L1-- BFR2...
> >                   ... .Routers. ...--L2--/ 
> >          ...BFR4--...           ...------ BFR3...
> >                    ...............         |
> >                                           LO
> >                     Network Area 1
> >
> > Assume the requirement in the above picture is to explicitly steer traffic flows that have arrived at BFR1 or BFR4 via a shortest path in the routing underlay "network area 1" to one of the following three next segments: (1) BFR2 via link L1, (2) BFR2 via link L2, (3) via BFR3.
> >
> > To achieve this, both BFR1 and BFR4 are set up with a forward_routed adjacency BitPosition towards an address of BFR2 on link L1, another forward_routed BitPosition towards an address of BFR2 on link L2 and a third forward_routed Bitposition towards a node address LO of BFR3.
> >
> > Does this clear ip the confusion ?
> >
> > Zzh> The picture is badly misaligned. I'll wait till 4.7 questions are cleared.
>
> Ok.
>
> > > If BFR2/3 are also BFERs, then they additionally will have BFER BPs.
> > > On BFR1/4, the BIFT entries for the MP2P BPs for the L1/L2/L3/loopback interface addresses of BFR2/3 will use forward_routed(interface/loopback address). For a packet to be decapsulated on a BFER, there is a need for both the BFER BP and another BP (p2p/lan/hub-spoke/routed-adjacency) in the packet (the former is for decapsulation and the latter is for getting it there).
> >
> > This is not discussed in this section, but you are right - unless
> > BFR2 or BFR3 is a leaf BFR. In that case, it would just leverage the one shared "leaf-BFR" BP, so they do not need a per-BFER BP for local_decap().
> >
> > Zzh> Right - shared leaf-BFR BP but still need that BP (the key is that we need a BP to get packet to a BFER and then a BP for decapsulation).
>
> You got it.
>
> > > If that???s the case, it???s worth point the above out.
> >
> > Hmm... The logic of BFER BPs is totally independent of the logic of forward_routed adjacency, so i would worry that repeating the explanation of BFER BPs would conflate the forward_routed explanation.
> >
> > Zzh> It's just that this is a place where all kinds of BPs are used so it's good to have a summary (could be a subsection 4.9).
>
> Yes, added such a summary. Pls. check.
>
> > > Actually, the reason that I thought this is MP2P is that 0:6 is present on R1, R2, and R3 (and more I assume) in Figure 12, but now I think it can???t be MP2P (so it is not correct to have 0:6 present on those routers ??? only the p2p tunnel head/tail should have the BP present in the BIFT). The reason is that if it were MP2P, any router getting a copy will send it to the endpoint of the routed adjacency, causing lots of duplicates.
> > >
> > > Am I getting this correct?
> >
> > I think you are still explaining from the misunderstsanding that the ECMP explanations where about routed adjacencies.
> >
> > I have now expanded the somewhat terse text in the BIFT table pictures, to make it clear that the ECMP is across multipe forward_connected adjacencies in the examples. For example, first BIFT picture:
> >
> >   BIFT entry in BFR1:
> >   ------------------------------------------------------------------
> >   | Index |  Adjacencies                                           |
> >   ==================================================================
> >   | 0:6   |  ECMP({forward_connected(L1, BFR2),                    |
> >   |       |        forward_connected(L2, BFR2),                    |
> >   |       |        forward_connected(L3, BFR2)}, seed)             |
> >   ------------------------------------------------------------------
> >
> > Of course, an ECMP adjacency can be across any type of adjacencies, but all the text/explanations used forward_connected, and now the pictures show that explicitly.
> >
> > Zzh> I can understand the multi-link case, but the multi-hop ECMP case (from BFR1 towards BFR10) is confusing me. It would help to give an example how it can be used, WITHOUT worrying about polarization.
>
> Please check -05 text that has the full set of BIFT listed now:
>
> There is  really nothing nothing unique in multi-hop ECMP for BIER-TE
> that we do not also have in any other ECMP, except the conclusion that
> we want to support fast HW hash mechanisms AND allow the controller to
> set up non-polarized multi-hop ECMP AND be able to precalculate paths.
> Hence the specification of ECMP adjacencies to have a controller
> configurable seed.
>
> Btw: The picture is maybe unnecessarily large because i've used it for
> 20 years to explain the same polarization issue for unicast vs
> multicast, and for multicast only BFR10...BFR4 are relevant (ECMP of
> the PIM/mLDP joins), whereas for unicast/BIER only
> BFR1...BFR7 are relevant. But being symmetric, the picture makes it
> clear its the same problem.
>
> > >    To inhibit looping in the face of such physical misconfiguration,
> > >    only forward_connected adjacencies are permitted to have DNR set, and
> > >    the link layer destination address of the adjacency (e.g.  MAC
> > >    address) protects against closing the loop.  Link layers without port
> > >    unique link layer addresses should not be used with the DNR flag set.
> > >
> > > It???s not clear how link layer address helps?
> >
> > I have expanded this to
> > "link layer port unique unicast destination address"
> >
> > Aka: MPLS or ethernet have unique link layer destination destination addresses (label or destination MAC). If you think about incorrectly plugged HDLC links (such as old T1/T3/... links), they only have 2 generic addresses, if i remember 1 or 3 in the HDLC frame. So when you misplug one of those p2p cables wrong, the packets would be incrrectly received by the wrong receiver node and then DNR could cause persistent loops only solved by TTL.
> >
> > Zzh> "Consider in the ring picture that link L4 from BFR3 is plugged into the L1 interface of BFRa" - still not sure how label/mac helps here. I suppose the ring topology is discovered/verified by the control plane and when the miscalling happens then the ring will not include the BFR1/BFR2 part and BFR3 will not have the DNR set? If ring discovery/varication is not done then perhaps we should point out that RPF based on link layer address is needed - the key is RPF (which needs unique link layer address)?
>
> Forget RPF. BIER(-TE) has no RPF (issues). Its just like unicast. RPF
> is just a problem for receiver originated joins like in PIM/mLDP, but
> not unicast/bier(-te)/RSVP-TE.
>
> Forward_connected is just like a unicast subnet adjacency to a direct
> neighbor: Interface and L2 addresss of the destination.
>
> The controller (could be a human) "assumes" a particular physicial
> topology, from telemetry/knowledge/whatever. It then calculates the
> desired BIER-TE topology and pushes it down. This topology is meant to
> be loop free of course wrt to the configured adjacencies.
> In this BIER-TE topology, BFR3 will have a BP with the
> forward_connected(L4, MAC-of-BFR2) adjacency.
>
> If the cable connecting to L4 is miswired, then BFR3 would still send
> the packets to the MAC address of BFR2, but given how the cable
> connects to some other node, these packets will be discarded by that
> node. because they're just L2 unicast packets.
>
> I think this is equally true when we have normal BIER/MPLS enacp.
> Those packets too are addressed to the unicast MAC address of the
> neighbor.
>
> Now, if/when he controller recognizes that the physical topology has
> changed, thats a completely different story and not addressed here.
> Given how we assumed this was a cabling mistake, the controller would
> probably only complain about the miswiring to operations but be happy
> that the forwarding plane just makes packets fail instead of loop. If
> this was a planned change process, then it will be similarily
> convoluted as it would today be with rewiring cables in an
> SR-MPLS/SRv6 topology and updating SIDs.
>
> > > Because the forwarding is different from BIER forwarding (because of [1] above), we might as well introduce an optimization here ??? for each BIFT, calculate the F-BM of the BIFT itself (the logical ???or??? of all the BPs presented in this BIFT) and then use (packet->bitstring & BIFT.F-BM) as the input to GetFirst/NextBitPosition(). That should skip many bits.
> >
> > Right. But i explicitly removed those optimizations (i had them in older draft versions) because the whole idea of this picture is solely the comparison with figure 4 of RFC8279.
> >
> > Zzh> I think it's worth point that optimization out; you can mark it optional if you want to emphasize the similarity to BIER forwarding, but since BIER forwarding does do the maskoff step, it is very efficient while BIER-TE forwarding does not it the maskoff step so this optimization is important.
>
> Ok. I simplified the text comparison BIER/BIER-TE wrt. to the FBM
> rules [1] and [2] and added following paragraph:
>
> <t>In BIER, the order of BPs impacts the result of forwarding because of [1].
> In BIER-TE, forwarding is not impacted by the order of BPs. It is
> therefore possible to further optimize forwarding than in BIER. For
> example parallelizing forwarding across multiple FPE cores or
> distributed linecards does only need to examine an arbitrary subset of
> BP and not evaluate the dependency between BPs.</t>
>
> > >    The following pseudocode is comprehensive:
> > >
> > > The above sentence reads a bit strange (or lacks some segue).
> >
> > I hope not, but maybe best left to a native english speaker (RFC-editor).
> >
> > The first (RFC8279) pseudocode was simplified. The second one is comprehensive. If not comprehensive, whats a good opposite of simplified ?
> >
> > Zzh> Perhaps "The above simplified pseudocode is elaborated further as following"?
> > Zzh> Jeffrey
>
> Done.
>
> Thanks a lot.
>
>
> >   
> > > ________________________________________
> > > From: BIER [bier-bounces@ietf.org<mailto:bier-bounces@ietf.org>]
> > > on behalf of Toerless Eckert [tte@cs.fau.de<mailto:tte@cs.fau.de>]
> > > Sent: Tuesday, July 09, 2019 23:38
> > > To: Mike McBride
> > > Cc: Greg Shepherd; BIER WG; Pascal Thubert (pthubert)
> > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch
> > >
> > > Thanks, Mike
> > >
> > > The authors also reviewed the document and concluded that it was
> > > really hard to get into the document context because of too many
> > > forward dependencies. We tried to fix this by adding two hopefully
> > > good & basic examples into the Introduction section and using them
> > > to also add a better definition of the term "BIER-TE Topology" in the Introduction.
> > > Hopefully this makes readin the rest of te document smoother.
> > >
> > > Also improved text of Abstract and refined text compariing BIER-TE with SR.
> > >
> > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https:
> > > **Atools.ietf.org*id*draft-ietf-bier-te-arch-02.txt&url2=https:**A
> > > tool
> > > s.ietf.org*id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R
> > > jC81
> > > c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV_eTUEh
> > > $
> > > <https://urldefense.com/v3/__http:/tools.ietf.org/*rfcdiff?url1=https:
> > > **Atools.ietf.org*id*draft-ietf-bier-te-arch-02.txt&url2=https:**A
> > > tool
> > > s.ietf.org*id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R
> > > jC81
> > > c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sNd1njcX
> > > $>
> > >
> > > Cheers
> > >     Toerless
> > >
> > > On Wed, Jun 26, 2019 at 10:39:36AM -0700, Mike McBride wrote:
> > > > How about three? I support.
> > > > mike
> > > >
> > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd <gjshep@gmail.com<mailto:gjshep@gmail.com>> wrote:
> > > > >
> > > > > We cannot take two 'yes' votes and WG consensus.
> > > > > Please, read and respond. If you don't support, then please vote as much publicly right here.
> > > > >
> > > > > Thanks,
> > > > > Greg
> > > > >
> > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert (pthubert) <pthubert@cisco.com<mailto:pthubert@cisco.com>> wrote:
> > > > >>
> > > > >> Support:
> > > > >>
> > > > >> I see great value in deterministic networks as well as IOT (with RPL).
> > > > >>
> > > > >> All the best,
> > > > >>
> > > > >> Pascal
> > > > >>
> > > > >> > -----Original Message-----
> > > > >> > From: BIER
> > > > >> > <bier-bounces@ietf.org<mailto:bier-bounces@ietf.org>> On
> > > > >> > Behalf Of Toerless Eckert
> > > > >> > Sent: mardi 4 juin 2019 02:03
> > > > >> > To: Greg Shepherd
> > > > >> > <gjshep@gmail.com<mailto:gjshep@gmail.com>>
> > > > >> > Cc: BIER WG <bier@ietf.org<mailto:bier@ietf.org>>
> > > > >> > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch
> > > > >> >
> > > > >> > +1
> > > > >> > Obviously support as co-author.
> > > > >> >
> > > > >> > On Wed, May 29, 2019 at 12:41:26PM -0700, Greg Shepherd wrote:
> > > > >> > > Please read and respond to this thread w/ or w/o support.
> > > > >> > >
> > > > >> > > https://urldefense.com/v3/__https://datatracker..ietf.org
> > > > >> > > /doc
> > > > >> > > /draft-ietf-bier-te-arch/__;!8WoA6RjC81c!XvH4AAxfrDjFoK_s
> > > > >> > > ercw ZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV9eClBj$
> > > > >> > > <https://urldefense.com/v3/__https:/datatracker.ietf.org/
> > > > >> > > doc/
> > > > >> > > draft-ietf-bier-te-arch/__;!8WoA6RjC81c!UBTGvWWpMHyeiSanx
> > > > >> > > s6vI b_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sD40kmtH$>
> > > > >> > >
> > > > >> > > Vote ends 5 June 2019.
> > > > >> > >
> > > > >> > > Thanks,
> > > > >> > > Shep
> > > > >> > > (chairs)
> > > > >> >
> > > > >> > > _______________________________________________
> > > > >> > > BIER mailing list
> > > > >> > > BIER@ietf.org<mailto:BIER@ietf.org>
> > > > >> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/
> > > > >> > > list
> > > > >> > > info/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eE
> > > > >> > > NOs4 l_qdsXF0KwZD82cJLDFFNT2WVXWX$
> > > > >> > > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/
> > > > >> > > list
> > > > >> > > info/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6b
> > > > >> > > oAAW 4nrqju8UCLOgiuXc8Y_6sKn2KoAT$>
> > > > >> >
> > > > >> > _______________________________________________
> > > > >> > BIER mailing list
> > > > >> > BIER@ietf.org<mailto:BIER@ietf.org>
> > > > >> > https://urldefense.com/v3/__https://www.ietf.org/mailman/li
> > > > >> > stin
> > > > >> > fo/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4
> > > > >> > l_qd
> > > > >> > sXF0KwZD82cJLDFFNT2WVXWX$
> > > > >> > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/li
> > > > >> > stin
> > > > >> > fo/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW
> > > > >> > 4nrq
> > > > >> > ju8UCLOgiuXc8Y_6sKn2KoAT$>
> > > > >
> > > > > _______________________________________________
> > > > > BIER mailing list
> > > > > BIER@ietf.org<mailto:BIER@ietf.org>
> > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listi
> > > > > nfo/
> > > > > bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsX
> > > > > F0Kw
> > > > > ZD82cJLDFFNT2WVXWX$
> > > > > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listi
> > > > > nfo/
> > > > > bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju
> > > > > 8UCL
> > > > > OgiuXc8Y_6sKn2KoAT$>
> > >
> > > --
> > > ---
> > > tte@cs.fau.de<mailto:tte@cs.fau.de>
> > >
> > > _______________________________________________
> > > BIER mailing list
> > > BIER@ietf.org<mailto:BIER@ietf.org>
> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/
> > > bier
> > > __;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82
> > > cJLD
> > > FFNT2WVXWX$
> > > <https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/
> > > bier
> > > __;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiu
> > > Xc8Y
> > > _6sKn2KoAT$>
> >
> > --
> > ---
> > tte@cs.fau.de
>
> --
> ---
> tte@cs.fau.de
>
> _______________________________________________
> BIER mailing list
> BIER@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier
> __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx4
> 1_jWV3YUA6D$

--
---
tte@cs.fau.de

_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ietf.org/mailman/listinfo/bier
--------------6F80FBDB24E277E1005287E5-- From nobody Wed Feb 19 19:43:14 2020 Return-Path: X-Original-To: bier@ietf.org Delivered-To: bier@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DDCE312002E; Wed, 19 Feb 2020 19:43:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: bier@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: bier@ietf.org Message-ID: <158217019178.17754.1404390064455419097@ietfa.amsl.com> Date: Wed, 19 Feb 2020 19:43:11 -0800 Archived-At: Subject: [Bier] I-D Action: draft-ietf-bier-te-arch-06.txt X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 03:43:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Bit Indexed Explicit Replication WG of the IETF. Title : Path Engineering for Bit Index Explicit Replication (BIER-TE) Authors : Toerless Eckert Gregory Cauchie Michael Menth Filename : draft-ietf-bier-te-arch-06.txt Pages : 45 Date : 2020-02-19 Abstract: This memo introduces per-packet stateless strict and loose path engineered replication and forwarding for Bit Index Explicit Replication packets (RFC8279). This is called BIER-TE. BIER-TE leverages RFC8279 and extends it with a new semantic for bits in the bitstring. BIER-TE can leverage BIER forwarding engines with little or no changes. In BIER, the BitPositions (BP) of the packets bitstring indicate BIER Forwarding Egress Routers (BFER), and hop-by-hop forwarding uses a Routing Underlay such as an IGP. In BIER-TE, BitPositions indicate adjacencies. The BIFT of each BFR are only populated with BPs that are adjacent to the BFR in the BIER- TE topology. The BIER-TE topology can consist of layer 2 or remote (route) adjacencies. The BFR then replicates and forwards BIER packets to those adjacencies. This results in the aforementioned strict and loose path forwarding. BIER-TE can co-exist with BIER forwarding in the same domain, for example by using separate sub-domains. In the absence of routed adjacencies, BIER-TE does not require a BIER routing underlay, and can then be operated without requiring an IGP routing protocol. BIER-TE operates without explicit in-network tree-building and carries the multicast distribution tree in the packet header. It can therefore be a good fit to support multicast path steering in Segment Routing (SR) networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-bier-te-arch/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-bier-te-arch-06 https://datatracker.ietf.org/doc/html/draft-ietf-bier-te-arch-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-bier-te-arch-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 19 19:56:44 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 594411201DB for ; Wed, 19 Feb 2020 19:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 Oa-rbOkSPICK for ; Wed, 19 Feb 2020 19:56:27 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E00E12084B for ; Wed, 19 Feb 2020 19:56:27 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 52CB3548048; Thu, 20 Feb 2020 04:56:20 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 48F91440040; Thu, 20 Feb 2020 04:56:20 +0100 (CET) Date: Thu, 20 Feb 2020 04:56:20 +0100 From: Toerless Eckert To: Lou Berger Cc: gjshep@gmail.com, "Jeffrey (Zhaohui) Zhang" , "bier@ietf.org" Message-ID: <20200220035620.GA42520@faui48f.informatik.uni-erlangen.de> References: <11ab30da-8701-b491-6162-5a69aa9d6965@labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <11ab30da-8701-b491-6162-5a69aa9d6965@labn.net> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 03:56:41 -0000 Thanks a lot, Lou [ Would have been nice if you could have commented a bit earlier. But i can understand how a few years is not enough time ;-P (actually no kidding, i really can.) ] Originally i had planned to address the explanations you are missing in this doc in the BIER-TE traffic engineering framework document, for which i had written the -00 version and presented at TEAS WG, IETF101, but given how we first wanted to get BIER-TE out as RFC, i let that expire, and in hindsight it's certainly useful to have a short section summarizing this in the BIER-TE RFC itself: So, I just pushed -06 of the draft to address your concerns with additional explanations. Summary below, diff here: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-bier-te-arch-05.txt&url2=https://tools.ietf.org/id/draft-ietf-bier-te-arch-06.txt - Title changed from "Traffic Engineering for..." to "Path Engineering for...", but kept name BIER-TE (see below). - Added section 1.1 explaining how BIER-TE relates to traffic engineering, naming use-cases where its for example beneficial standalone and and what it could be combined with for more comprehensive TE solutions, but also stating that those integrations are outside the scope of this document. - changed "traffic engineering" term in the whole doc to "path engineering", where appropriate. - Unrelated to you, there was one leftover fix from ietf106 review to rename BIER-TE Controller Host to just BIER-TE Controller Wrt to naming: The mayority of customers i talked to only used RSVP-TE for path engineering, and not for anything more. Several didn't even know it can do bandwidth reservation. Nobody knew it could do latency guarantees, because nobody knows an implementation that supports that. [All reasons btw. why replacing RSVP-TE with SR happened in the industry.] In any case, the name BIER-TE was selected to reduce confusion with customers, not to maximize naming correctness in IETF. Something like "BIER-PE" (Path Engineering) would have probably confused more than it would have helped. Think of the justification for the name BIER-TE not as "all you need to do TE", but "the variation of BIER to support TE". Wrt to SR: SR can actually NOT do the same as BIER-TE. It has no stateless multicast. All the SR options do really require that you set up multicast trees with e.g.: replication-SIDs that together form the equivalent of a multicast tree, like you would have built with RSVP-TE. Except that the signaling how to build the tree is left for someone else, like PCECC. (AFAIK, i may not be on top of all details). In BIER-TE, there is no such per-tree state on transit nodes. Instead of a 256 bit bitstring in BIER-TE think of a header with up to 256 SIDs (e.g.: 128 bit per SID in SRv6). That would be the SR equivalent of BIER-TE. Just a bit less ( ;-) ) less efficient on the wire than BIER-TE and extremely harder to parse. Cheers Toerless On Wed, Feb 19, 2020 at 06:38:38PM -0500, Lou Berger wrote: > Hi, > >     I have no issue or objection to the mechanisms being defined in this > document as much as they go, but I was quite disappointed that despite the > name of the document and use of 'bier-te'  to see that the document doesn't > define any traffic engineering support, at least as far as the term has been > used in IETF RFCs.  In particular it totally lacks any discussion of > resources usage and/or allocation.  What it currently describes certainly > provides good and useful path/traffic steering that can be used to support > policy-based routing.  Basically it does the same as what is defined by > draft-ietf-spring-segment-routing-policy. > > I personally (not speaking for the related WGs that I chair) would prefer to > see this document be revised  to include resource allocation that would > allow BIER-TE to support TE usage such as DetNet.  Barring such an addition, > I'm against publication of this document as is and I think the document > should be recast and renamed to be aligned with the SR example, i.e., BIER > routing policy (or path steering). > > Lou > > On 2/18/20 3:45 PM, Greg Shepherd wrote: > > Thanks Toerless and Jeffrey > > > > https://datatracker.ietf.org/doc/draft-ietf-bier-te-arch/ > > > > One more week of WGLC. Please read the latest rev and respond to this > > thread w/wo support. > > > > Chairs > > (Shep) > > > > > > On Tue, Feb 18, 2020 at 12:07 PM Jeffrey (Zhaohui) Zhang > > > > wrote: > > > > Hi Toerless, > > > > Thanks! > > I support moving this to the next stage. > > > > Jeffrey > > > > On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote: > > > Thanks Jeff > > > > > > I have now pushed out -05 with the answers and hopefully > > resolution to > > > your points in email below.  Biggest addition was a section about > > > reuse of BPs (without DNR) which came out of the confusion i > > think the > > > reuse in the ECMP example raised. I was afraid so far to explan > > that > > > as it may not be easy to absorb and ultimately is stuff only > > > controller developers need to understand, but hopefully useful. > > > And then of course the summary of BP optimizatins you asked for > > > > > > Diff from last version i sent you: > > > > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: > > > **Araw.githubusercontent.com > > *toerless*bier-te-arch*master*draft-ietf-b > > > ier-te-arch-05.1.txt&url2=http:**Atools.ietf.org > > *id*draft-ietf-bier-te > > > > > -arch-05.txt__;Ly8vLy8vLy8vLy8!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzH > > > OCr0fZkLPbgg3CPNu0PyrWsrFx41_jWX2At8V-$ > > > > > > full -04 -> 05 diff: > > > > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=http:* > > > *Atools.ietf.org > > *id*draft-ietf-bier-te-arch-04.txt&url2=http:**Atools. > > > ietf.org > > *id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk > > > !VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx41_jWancpziv$ > > > > > > Comments inline below. > > > > > > Cheers > > >     toerless > > > > > > On Mon, Oct 28, 2019 at 07:52:59PM +0000, Jeffrey (Zhaohui) > > Zhang wrote: > > > > I Thought u-turn is the most simple comparison leaf vs. > > non-leaf BFR. > > > > > > > > Zzh> The text in the email is seriously misaligned. Looking at > > the picture in the diff link, while you gave a U-turn example, > > though even if BFER2 is not connected to BFR2  but only connected > > to BFER1 (hence no U-turn), then BFER1 is still not a leaf BFER I > > suppose. That's why I said the first sentence of the above > > paragraph is enough to define Leaf BFER while the example itself > > is actually not needed. > > > > > > Argh... ok, had to fix two words, BFIR->BFER and left-hand -> > > right-hand: > > > > > > Consider how redundant disjoint traffic can reach BFER1/BFER2 in > > above > > > picture: When BFER1/BFER2 are Non-Leaf BFER as shown on the > > right hand > > > side, one traffic copy would be forwarded to BFER1 from BFR1, > > but the > > > other one could only reach BFER1 via BFER2, which makes BFER2 a > > > non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forwarding > > > traffic to BFER2 > > > > > > > Zzh> Additionally, in left part of the picture you added, if > > some failure leads to BFR2 to be only reachable via BFER1, then > > BFER1 is no longer a leaf BFER. > > > > > > Added sentence: > > > > > > Note that the BFER in the left hand picture are only > > guaranteed to > > > be leaf-BFR by fitting routing configuration that prohibits transit > > > traffic to pass through a PE, which is commonly applied in these > > > topologies. > > > > > > > I assume you don't reassign BPs when links go up and down. > > > > > > I didn't want to discuss that option in this document. Its > > obviously > > > perfectly feasible, but be yet a big amount of text (especially the > > > considerations how to do this make-before-break. Future doc. > > > > > > > > but subsequent polarization example confuses me. It seems > > that BP 0:6 is assigned to the routed adjacency BFR10 (which is > > actually talked about in Section 4.8). > > > > > > > > Section 4.7 does not mention "routed" at all, so there are no > > routed adjacencies at all used in 4.7. So i am not sure what you > > are confused about. > > > > > > > > Zzh> "The BIFT of each BFR are only populated with BPs that > > are adjacent to the BFR in the BIER-TE topology". > > > > > > Correct text from the introduction. Ok. > > > > > > > Zzh> Since the same 0:6 is in BIFTS of BFR1/BFR2/BFR3 (and I > > suppose in BFR4~BFR9 as well even though not drawn), I assumed > > it's for the "MP2P" routed adjacency to R10; though I then ruled > > that out - but I don't know what 0:6 represent now on BFR1, BFR2, > > and BFR3. > > > > > > Ah. Ok. I thought i could strip down the example to show only the > > > adjacencies relevant to the following discusion, but seemingly this > > > can introduce the confusion you have. > > > > > > So i completed the example with the BP assignment acoss all > > nodes, but > > > added text pointing to a new section further down to discuss the > > > re-use of BP for which thi picture is also an example. > > > > > > (check out the diff, new reuse text to long to copy inline). > > > > > > > The whole purpose of the ECMP BPs is of course to save bits, > > otherwise we'd give each link a separate BP, which would be 6 BP > > to reach to BFR4...BFR7 from BFR1. > > > > > > > > Zzh> The trouble I am having is that the same 0:6 is assigned > > to different things and it's present on all BFR1/BFR2/BFR3. It is > > perhaps an intentional smart design but I have not wrapped my mind > > around it. It's apparently different from the link bundle case, so > > better separate it out and elaborate it (including the DNR flag > > that might be needed here - If the packet arrives on BFR1 with > > 0:6, would the BP reset when it is sent to BFR2/3)? > > > > > > Yes, there was the bug of reusing BP 0:6 across sequential BFR > > along > > > the path, but now the example correctly reuses separate BP at > > > different stages of the paths (BP 0:6 on BFR1, BP 0:7 on > > BFR2/BFR3) and so on. > > > > > > Thanks! > > > > > > > > 4.8.  Routed adjacencies > > > > > > > > > > If I understand it correctly, there is a BP assigned to > > L1/L2/L3 > > > > > respectively (p2p link), and then there are BPs assigned to > > MP2P tunnels (routed adjacency from every BFR) to the L1/L2/L3 > > interface addresses and loopback addresses on BFR2/3. > > > > > > > > Ok that wasn't quite the read i expected. Let me clarify the > > text/picture: > > > > > > > >                    ............... > > > >          ...BFR1--...           ...--L1-- BFR2... > > > >                   ... .Routers. ...--L2--/ > > > >          ...BFR4--...           ...------ BFR3... > > > >                    ...............         | > > > >                                           LO > > > >                     Network Area 1 > > > > > > > > Assume the requirement in the above picture is to explicitly > > steer traffic flows that have arrived at BFR1 or BFR4 via a > > shortest path in the routing underlay "network area 1" to one of > > the following three next segments: (1) BFR2 via link L1, (2) BFR2 > > via link L2, (3) via BFR3. > > > > > > > > To achieve this, both BFR1 and BFR4 are set up with a > > forward_routed adjacency BitPosition towards an address of BFR2 on > > link L1, another forward_routed BitPosition towards an address of > > BFR2 on link L2 and a third forward_routed Bitposition towards a > > node address LO of BFR3. > > > > > > > > Does this clear ip the confusion ? > > > > > > > > Zzh> The picture is badly misaligned. I'll wait till 4.7 > > questions are cleared. > > > > > > Ok. > > > > > > > > If BFR2/3 are also BFERs, then they additionally will have > > BFER BPs. > > > > > On BFR1/4, the BIFT entries for the MP2P BPs for the > > L1/L2/L3/loopback interface addresses of BFR2/3 will use > > forward_routed(interface/loopback address). For a packet to be > > decapsulated on a BFER, there is a need for both the BFER BP and > > another BP (p2p/lan/hub-spoke/routed-adjacency) in the packet (the > > former is for decapsulation and the latter is for getting it there). > > > > > > > > This is not discussed in this section, but you are right - unless > > > > BFR2 or BFR3 is a leaf BFR. In that case, it would just > > leverage the one shared "leaf-BFR" BP, so they do not need a > > per-BFER BP for local_decap(). > > > > > > > > Zzh> Right - shared leaf-BFR BP but still need that BP (the > > key is that we need a BP to get packet to a BFER and then a BP for > > decapsulation). > > > > > > You got it. > > > > > > > > If that???s the case, it???s worth point the above out. > > > > > > > > Hmm... The logic of BFER BPs is totally independent of the > > logic of forward_routed adjacency, so i would worry that repeating > > the explanation of BFER BPs would conflate the forward_routed > > explanation. > > > > > > > > Zzh> It's just that this is a place where all kinds of BPs are > > used so it's good to have a summary (could be a subsection 4.9). > > > > > > Yes, added such a summary. Pls. check. > > > > > > > > Actually, the reason that I thought this is MP2P is that 0:6 > > is present on R1, R2, and R3 (and more I assume) in Figure 12, but > > now I think it can???t be MP2P (so it is not correct to have 0:6 > > present on those routers ??? only the p2p tunnel head/tail should > > have the BP present in the BIFT). The reason is that if it were > > MP2P, any router getting a copy will send it to the endpoint of > > the routed adjacency, causing lots of duplicates. > > > > > > > > > > Am I getting this correct? > > > > > > > > I think you are still explaining from the misunderstsanding > > that the ECMP explanations where about routed adjacencies. > > > > > > > > I have now expanded the somewhat terse text in the BIFT table > > pictures, to make it clear that the ECMP is across multipe > > forward_connected adjacencies in the examples. For example, first > > BIFT picture: > > > > > > > >   BIFT entry in BFR1: > > > > > >  ------------------------------------------------------------------ > > > >   | Index |  Adjacencies                  | > > > > > >  ================================================================== > > > >   | 0:6   |  ECMP({forward_connected(L1, BFR2),                 | > > > >   |       |        forward_connected(L2, BFR2),                 | > > > >   |       |        forward_connected(L3, BFR2)}, seed)        > >      | > > > > > >  ------------------------------------------------------------------ > > > > > > > > Of course, an ECMP adjacency can be across any type of > > adjacencies, but all the text/explanations used forward_connected, > > and now the pictures show that explicitly. > > > > > > > > Zzh> I can understand the multi-link case, but the multi-hop > > ECMP case (from BFR1 towards BFR10) is confusing me. It would help > > to give an example how it can be used, WITHOUT worrying about > > polarization. > > > > > > Please check -05 text that has the full set of BIFT listed now: > > > > > > There is  really nothing nothing unique in multi-hop ECMP for > > BIER-TE > > > that we do not also have in any other ECMP, except the > > conclusion that > > > we want to support fast HW hash mechanisms AND allow the > > controller to > > > set up non-polarized multi-hop ECMP AND be able to precalculate > > paths. > > > Hence the specification of ECMP adjacencies to have a controller > > > configurable seed. > > > > > > Btw: The picture is maybe unnecessarily large because i've used > > it for > > > 20 years to explain the same polarization issue for unicast vs > > > multicast, and for multicast only BFR10...BFR4 are relevant > > (ECMP of > > > the PIM/mLDP joins), whereas for unicast/BIER only > > > BFR1...BFR7 are relevant. But being symmetric, the picture makes it > > > clear its the same problem. > > > > > > > >    To inhibit looping in the face of such physical > > misconfiguration, > > > > >    only forward_connected adjacencies are permitted to have > > DNR set, and > > > > >    the link layer destination address of the adjacency > > (e.g.  MAC > > > > >    address) protects against closing the loop.  Link layers > > without port > > > > >    unique link layer addresses should not be used with the > > DNR flag set. > > > > > > > > > > It???s not clear how link layer address helps? > > > > > > > > I have expanded this to > > > > "link layer port unique unicast destination address" > > > > > > > > Aka: MPLS or ethernet have unique link layer destination > > destination addresses (label or destination MAC). If you think > > about incorrectly plugged HDLC links (such as old T1/T3/... > > links), they only have 2 generic addresses, if i remember 1 or 3 > > in the HDLC frame. So when you misplug one of those p2p cables > > wrong, the packets would be incrrectly received by the wrong > > receiver node and then DNR could cause persistent loops only > > solved by TTL. > > > > > > > > Zzh> "Consider in the ring picture that link L4 from BFR3 is > > plugged into the L1 interface of BFRa" - still not sure how > > label/mac helps here. I suppose the ring topology is > > discovered/verified by the control plane and when the miscalling > > happens then the ring will not include the BFR1/BFR2 part and BFR3 > > will not have the DNR set? If ring discovery/varication is not > > done then perhaps we should point out that RPF based on link layer > > address is needed - the key is RPF (which needs unique link layer > > address)? > > > > > > Forget RPF. BIER(-TE) has no RPF (issues). Its just like > > unicast. RPF > > > is just a problem for receiver originated joins like in > > PIM/mLDP, but > > > not unicast/bier(-te)/RSVP-TE. > > > > > > Forward_connected is just like a unicast subnet adjacency to a > > direct > > > neighbor: Interface and L2 addresss of the destination. > > > > > > The controller (could be a human) "assumes" a particular physicial > > > topology, from telemetry/knowledge/whatever. It then calculates the > > > desired BIER-TE topology and pushes it down. This topology is > > meant to > > > be loop free of course wrt to the configured adjacencies. > > > In this BIER-TE topology, BFR3 will have a BP with the > > > forward_connected(L4, MAC-of-BFR2) adjacency. > > > > > > If the cable connecting to L4 is miswired, then BFR3 would still > > send > > > the packets to the MAC address of BFR2, but given how the cable > > > connects to some other node, these packets will be discarded by > > that > > > node. because they're just L2 unicast packets. > > > > > > I think this is equally true when we have normal BIER/MPLS enacp. > > > Those packets too are addressed to the unicast MAC address of the > > > neighbor. > > > > > > Now, if/when he controller recognizes that the physical topology > > has > > > changed, thats a completely different story and not addressed here. > > > Given how we assumed this was a cabling mistake, the controller > > would > > > probably only complain about the miswiring to operations but be > > happy > > > that the forwarding plane just makes packets fail instead of > > loop. If > > > this was a planned change process, then it will be similarily > > > convoluted as it would today be with rewiring cables in an > > > SR-MPLS/SRv6 topology and updating SIDs. > > > > > > > > Because the forwarding is different from BIER forwarding > > (because of [1] above), we might as well introduce an optimization > > here ??? for each BIFT, calculate the F-BM of the BIFT itself (the > > logical ???or??? of all the BPs presented in this BIFT) and then > > use (packet->bitstring & BIFT.F-BM) as the input to > > GetFirst/NextBitPosition(). That should skip many bits. > > > > > > > > Right. But i explicitly removed those optimizations (i had > > them in older draft versions) because the whole idea of this > > picture is solely the comparison with figure 4 of RFC8279. > > > > > > > > Zzh> I think it's worth point that optimization out; you can > > mark it optional if you want to emphasize the similarity to BIER > > forwarding, but since BIER forwarding does do the maskoff step, it > > is very efficient while BIER-TE forwarding does not it the maskoff > > step so this optimization is important. > > > > > > Ok. I simplified the text comparison BIER/BIER-TE wrt. to the FBM > > > rules [1] and [2] and added following paragraph: > > > > > > In BIER, the order of BPs impacts the result of forwarding > > because of [1]. > > > In BIER-TE, forwarding is not impacted by the order of BPs. It is > > > therefore possible to further optimize forwarding than in BIER. For > > > example parallelizing forwarding across multiple FPE cores or > > > distributed linecards does only need to examine an arbitrary > > subset of > > > BP and not evaluate the dependency between BPs. > > > > > > > >    The following pseudocode is comprehensive: > > > > > > > > > > The above sentence reads a bit strange (or lacks some segue). > > > > > > > > I hope not, but maybe best left to a native english speaker > > (RFC-editor). > > > > > > > > The first (RFC8279) pseudocode was simplified. The second one > > is comprehensive. If not comprehensive, whats a good opposite of > > simplified ? > > > > > > > > Zzh> Perhaps "The above simplified pseudocode is elaborated > > further as following"? > > > > Zzh> Jeffrey > > > > > > Done. > > > > > > Thanks a lot. > > > > > > > > > > > > > > > ________________________________________ > > > > > From: BIER [bier-bounces@ietf.org > > > >] > > > > > on behalf of Toerless Eckert [tte@cs.fau.de > > >] > > > > > Sent: Tuesday, July 09, 2019 23:38 > > > > > To: Mike McBride > > > > > Cc: Greg Shepherd; BIER WG; Pascal Thubert (pthubert) > > > > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch > > > > > > > > > > Thanks, Mike > > > > > > > > > > The authors also reviewed the document and concluded that it > > was > > > > > really hard to get into the document context because of too > > many > > > > > forward dependencies. We tried to fix this by adding two > > hopefully > > > > > good & basic examples into the Introduction section and > > using them > > > > > to also add a better definition of the term "BIER-TE > > Topology" in the Introduction. > > > > > Hopefully this makes readin the rest of te document smoother. > > > > > > > > > > Also improved text of Abstract and refined text compariing > > BIER-TE with SR. > > > > > > > > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: > > > > > **Atools.ietf.org > > *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A > > > > > tool > > > > > s.ietf.org > > *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R > > > > > jC81 > > > > > > > c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV_eTUEh > > > > > $ > > > > > > > > > > > **Atools.ietf.org > > *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A > > > > > tool > > > > > s.ietf.org > > *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R > > > > > jC81 > > > > > > > c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sNd1njcX > > > > > $> > > > > > > > > > > Cheers > > > > >     Toerless > > > > > > > > > > On Wed, Jun 26, 2019 at 10:39:36AM -0700, Mike McBride wrote: > > > > > > How about three? I support. > > > > > > mike > > > > > > > > > > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd > > > > >> wrote: > > > > > > > > > > > > > > We cannot take two 'yes' votes and WG consensus. > > > > > > > Please, read and respond. If you don't support, then > > please vote as much publicly right here. > > > > > > > > > > > > > > Thanks, > > > > > > > Greg > > > > > > > > > > > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert > > (pthubert) > > >> wrote: > > > > > > >> > > > > > > >> Support: > > > > > > >> > > > > > > >> I see great value in deterministic networks as well as > > IOT (with RPL). > > > > > > >> > > > > > > >> All the best, > > > > > > >> > > > > > > >> Pascal > > > > > > >> > > > > > > >> > -----Original Message----- > > > > > > >> > From: BIER > > > > > > >> > > > >> On > > > > > > >> > Behalf Of Toerless Eckert > > > > > > >> > Sent: mardi 4 juin 2019 02:03 > > > > > > >> > To: Greg Shepherd > > > > > > >> > > > >> > > > > > > >> > Cc: BIER WG > >> > > > > > > >> > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch > > > > > > >> > > > > > > > >> > +1 > > > > > > >> > Obviously support as co-author. > > > > > > >> > > > > > > > >> > On Wed, May 29, 2019 at 12:41:26PM -0700, Greg > > Shepherd wrote: > > > > > > >> > > Please read and respond to this thread w/ or w/o > > support. > > > > > > >> > > > > > > > > >> > > > > https://urldefense.com/v3/__https://datatracker..ietf.org > > > > > > >> > > /doc > > > > > > >> > > > > /draft-ietf-bier-te-arch/__;!8WoA6RjC81c!XvH4AAxfrDjFoK_s > > > > > > >> > > ercw ZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV9eClBj$ > > > > > > >> > > > > > > > > > >> > > doc/ > > > > > > >> > > > > draft-ietf-bier-te-arch/__;!8WoA6RjC81c!UBTGvWWpMHyeiSanx > > > > > > >> > > s6vI b_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sD40kmtH$> > > > > > > >> > > > > > > > > >> > > Vote ends 5 June 2019. > > > > > > >> > > > > > > > > >> > > Thanks, > > > > > > >> > > Shep > > > > > > >> > > (chairs) > > > > > > >> > > > > > > > >> > > _______________________________________________ > > > > > > >> > > BIER mailing list > > > > > > >> > > BIER@ietf.org > > > > > > > > > >> > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/ > > > > > > >> > > list > > > > > > >> > > > > info/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eE > > > > > > >> > > NOs4 l_qdsXF0KwZD82cJLDFFNT2WVXWX$ > > > > > > >> > > > > > > > > > >> > > list > > > > > > >> > > > > info/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6b > > > > > > >> > > oAAW 4nrqju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > > > >> > > > > > > > >> > _______________________________________________ > > > > > > >> > BIER mailing list > > > > > > >> > BIER@ietf.org > > > > > > > > > >> > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/li > > > > > > >> > stin > > > > > > >> > > > fo/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4 > > > > > > >> > l_qd > > > > > > >> > sXF0KwZD82cJLDFFNT2WVXWX$ > > > > > > >> > > > > > > > > >> > stin > > > > > > >> > > > fo/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW > > > > > > >> > 4nrq > > > > > > >> > ju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > > > > > > > > > > > _______________________________________________ > > > > > > > BIER mailing list > > > > > > > BIER@ietf.org > > > > > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listi > > > > > > > nfo/ > > > > > > > > > bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsX > > > > > > > F0Kw > > > > > > > ZD82cJLDFFNT2WVXWX$ > > > > > > > > > > > > > > > nfo/ > > > > > > > > > bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju > > > > > > > 8UCL > > > > > > > OgiuXc8Y_6sKn2KoAT$> > > > > > > > > > > -- > > > > > --- > > > > > tte@cs.fau.de > > > > > > > > > > > > _______________________________________________ > > > > > BIER mailing list > > > > > BIER@ietf.org > > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ > > > > > bier > > > > > > > __;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82 > > > > > cJLD > > > > > FFNT2WVXWX$ > > > > > > > > > > > bier > > > > > > > __;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiu > > > > > Xc8Y > > > > > _6sKn2KoAT$> > > > > > > > > -- > > > > --- > > > > tte@cs.fau.de > > > > > > -- > > > --- > > > tte@cs.fau.de > > > > > > _______________________________________________ > > > BIER mailing list > > > BIER@ietf.org > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier > > > > > __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx4 > > > 1_jWV3YUA6D$ > > > > -- > > --- > > tte@cs.fau.de > > > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org > > https://www.ietf.org/mailman/listinfo/bier > > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier -- --- tte@cs.fau.de From nobody Thu Feb 20 20:26:35 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C0C1207FD for ; Thu, 20 Feb 2020 20:26:34 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 RwWSA8PAlfTV for ; Thu, 20 Feb 2020 20:26:30 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C630120639 for ; Thu, 20 Feb 2020 20:26:29 -0800 (PST) Received: from [192.168.1.6] (unknown [119.94.165.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 091E7364520; Fri, 21 Feb 2020 05:26:24 +0100 (CET) To: Lou Berger , gjshep@gmail.com, "Jeffrey (Zhaohui) Zhang" Cc: "bier@ietf.org" , Toerless Eckert References: <11ab30da-8701-b491-6162-5a69aa9d6965@labn.net> From: Loa Andersson Message-ID: Date: Fri, 21 Feb 2020 12:25:46 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.4.2 MIME-Version: 1.0 In-Reply-To: <11ab30da-8701-b491-6162-5a69aa9d6965@labn.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 04:26:34 -0000 Authors, working group, Inline plz. On 20/02/2020 07:38, Lou Berger wrote: > Hi, > >     I have no issue or objection to the mechanisms being defined in > this document as much as they go, but I was quite disappointed that > despite the name of the document and use of 'bier-te'  to see that the > document doesn't define any traffic engineering support, at least as far > as the term has been used in IETF RFCs.  In particular it totally lacks > any discussion of resources usage and/or allocation.  What it currently > describes certainly provides good and useful path/traffic steering that > can be used to support policy-based routing.  Basically it does the same > as what is defined by draft-ietf-spring-segment-routing-policy. > > I personally (not speaking for the related WGs that I chair) would > prefer to see this document be revised  to include resource allocation > that would allow BIER-TE to support TE usage such as DetNet.  Barring > such an addition, I'm against publication of this document as is and I > think the document should be recast and renamed to be aligned with the > SR example, i.e., BIER routing policy (or path steering). chair hat off Personally I agree with Lou, plz add the resource allocation. chair hat on mpls wg chairs discussed this, and it is our opinion that this document should have been at lest flagged in mpls and teas, preferably a cross wg review should have been organized. /Loa > > Lou > > On 2/18/20 3:45 PM, Greg Shepherd wrote: >> Thanks Toerless and Jeffrey >> >> https://datatracker.ietf.org/doc/draft-ietf-bier-te-arch/ >> >> One more week of WGLC. Please read the latest rev and respond to this >> thread w/wo support. >> >> Chairs >> (Shep) >> >> >> On Tue, Feb 18, 2020 at 12:07 PM Jeffrey (Zhaohui) Zhang >> > > wrote: >> >> Hi Toerless, >> >> Thanks! >> I support moving this to the next stage. >> >> Jeffrey >> >> On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote: >> > Thanks Jeff >> > >> > I have now pushed out -05 with the answers and hopefully >> resolution to >> > your points in email below.  Biggest addition was a section about >> > reuse of BPs (without DNR) which came out of the confusion i >> think the >> > reuse in the ECMP example raised. I was afraid so far to explan >> that >> > as it may not be easy to absorb and ultimately is stuff only >> > controller developers need to understand, but hopefully useful. >> > And then of course the summary of BP optimizatins you asked for >> > >> > Diff from last version i sent you: >> > >> > >> https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: >> > **Araw.githubusercontent.com >> *toerless*bier-te-arch*master*draft-ietf-b >> > ier-te-arch-05.1.txt&url2=http:**Atools.ietf.org >> *id*draft-ietf-bier-te >> > >> -arch-05.txt__;Ly8vLy8vLy8vLy8!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzH >> > OCr0fZkLPbgg3CPNu0PyrWsrFx41_jWX2At8V-$ >> > >> > full -04 -> 05 diff: >> > >> > >> https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=http:* >> > *Atools.ietf.org >> *id*draft-ietf-bier-te-arch-04.txt&url2=http:**Atools. >> > ietf.org >> *id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk >> > !VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx41_jWancpziv$ >> > >> > Comments inline below. >> > >> > Cheers >> >     toerless >> > >> > On Mon, Oct 28, 2019 at 07:52:59PM +0000, Jeffrey (Zhaohui) >> Zhang wrote: >> > > I Thought u-turn is the most simple comparison leaf vs. >> non-leaf BFR. >> > > >> > > Zzh> The text in the email is seriously misaligned. Looking at >> the picture in the diff link, while you gave a U-turn example, >> though even if BFER2 is not connected to BFR2  but only connected >> to BFER1 (hence no U-turn), then BFER1 is still not a leaf BFER I >> suppose. That's why I said the first sentence of the above >> paragraph is enough to define Leaf BFER while the example itself >> is actually not needed. >> > >> > Argh... ok, had to fix two words, BFIR->BFER and left-hand -> >> right-hand: >> > >> > Consider how redundant disjoint traffic can reach BFER1/BFER2 in >> above >> > picture: When BFER1/BFER2 are Non-Leaf BFER as shown on the >> right hand >> > side, one traffic copy would be forwarded to BFER1 from BFR1, >> but the >> > other one could only reach BFER1 via BFER2, which makes BFER2 a >> > non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forwarding >> > traffic to BFER2 >> > >> > > Zzh> Additionally, in left part of the picture you added, if >> some failure leads to BFR2 to be only reachable via BFER1, then >> BFER1 is no longer a leaf BFER. >> > >> > Added sentence: >> > >> > Note that the BFER in the left hand picture are only >> guaranteed to >> > be leaf-BFR by fitting routing configuration that prohibits transit >> > traffic to pass through a PE, which is commonly applied in these >> > topologies. >> > >> > > I assume you don't reassign BPs when links go up and down. >> > >> > I didn't want to discuss that option in this document. Its >> obviously >> > perfectly feasible, but be yet a big amount of text (especially the >> > considerations how to do this make-before-break. Future doc. >> > >> > > > but subsequent polarization example confuses me. It seems >> that BP 0:6 is assigned to the routed adjacency BFR10 (which is >> actually talked about in Section 4.8). >> > > >> > > Section 4.7 does not mention "routed" at all, so there are no >> routed adjacencies at all used in 4.7. So i am not sure what you >> are confused about. >> > > >> > > Zzh> "The BIFT of each BFR are only populated with BPs that >> are adjacent to the BFR in the BIER-TE topology". >> > >> > Correct text from the introduction. Ok. >> > >> > > Zzh> Since the same 0:6 is in BIFTS of BFR1/BFR2/BFR3 (and I >> suppose in BFR4~BFR9 as well even though not drawn), I assumed >> it's for the "MP2P" routed adjacency to R10; though I then ruled >> that out - but I don't know what 0:6 represent now on BFR1, BFR2, >> and BFR3. >> > >> > Ah. Ok. I thought i could strip down the example to show only the >> > adjacencies relevant to the following discusion, but seemingly this >> > can introduce the confusion you have. >> > >> > So i completed the example with the BP assignment acoss all >> nodes, but >> > added text pointing to a new section further down to discuss the >> > re-use of BP for which thi picture is also an example. >> > >> > (check out the diff, new reuse text to long to copy inline). >> > >> > > The whole purpose of the ECMP BPs is of course to save bits, >> otherwise we'd give each link a separate BP, which would be 6 BP >> to reach to BFR4...BFR7 from BFR1. >> > > >> > > Zzh> The trouble I am having is that the same 0:6 is assigned >> to different things and it's present on all BFR1/BFR2/BFR3. It is >> perhaps an intentional smart design but I have not wrapped my mind >> around it. It's apparently different from the link bundle case, so >> better separate it out and elaborate it (including the DNR flag >> that might be needed here - If the packet arrives on BFR1 with >> 0:6, would the BP reset when it is sent to BFR2/3)? >> > >> > Yes, there was the bug of reusing BP 0:6 across sequential BFR >> along >> > the path, but now the example correctly reuses separate BP at >> > different stages of the paths (BP 0:6 on BFR1, BP 0:7 on >> BFR2/BFR3) and so on. >> > >> > Thanks! >> > >> > > > 4.8.  Routed adjacencies >> > > > >> > > > If I understand it correctly, there is a BP assigned to >> L1/L2/L3 >> > > > respectively (p2p link), and then there are BPs assigned to >> MP2P tunnels (routed adjacency from every BFR) to the L1/L2/L3 >> interface addresses and loopback addresses on BFR2/3. >> > > >> > > Ok that wasn't quite the read i expected. Let me clarify the >> text/picture: >> > > >> > >                    ............... >> > >          ...BFR1--...           ...--L1-- BFR2... >> > >                   ... .Routers. ...--L2--/ >> > >          ...BFR4--...           ...------ BFR3... >> > >                    ...............         | >> > >                                           LO >> > >                     Network Area 1 >> > > >> > > Assume the requirement in the above picture is to explicitly >> steer traffic flows that have arrived at BFR1 or BFR4 via a >> shortest path in the routing underlay "network area 1" to one of >> the following three next segments: (1) BFR2 via link L1, (2) BFR2 >> via link L2, (3) via BFR3. >> > > >> > > To achieve this, both BFR1 and BFR4 are set up with a >> forward_routed adjacency BitPosition towards an address of BFR2 on >> link L1, another forward_routed BitPosition towards an address of >> BFR2 on link L2 and a third forward_routed Bitposition towards a >> node address LO of BFR3. >> > > >> > > Does this clear ip the confusion ? >> > > >> > > Zzh> The picture is badly misaligned. I'll wait till 4.7 >> questions are cleared. >> > >> > Ok. >> > >> > > > If BFR2/3 are also BFERs, then they additionally will have >> BFER BPs. >> > > > On BFR1/4, the BIFT entries for the MP2P BPs for the >> L1/L2/L3/loopback interface addresses of BFR2/3 will use >> forward_routed(interface/loopback address). For a packet to be >> decapsulated on a BFER, there is a need for both the BFER BP and >> another BP (p2p/lan/hub-spoke/routed-adjacency) in the packet (the >> former is for decapsulation and the latter is for getting it there). >> > > >> > > This is not discussed in this section, but you are right - unless >> > > BFR2 or BFR3 is a leaf BFR. In that case, it would just >> leverage the one shared "leaf-BFR" BP, so they do not need a >> per-BFER BP for local_decap(). >> > > >> > > Zzh> Right - shared leaf-BFR BP but still need that BP (the >> key is that we need a BP to get packet to a BFER and then a BP for >> decapsulation). >> > >> > You got it. >> > >> > > > If that???s the case, it???s worth point the above out. >> > > >> > > Hmm... The logic of BFER BPs is totally independent of the >> logic of forward_routed adjacency, so i would worry that repeating >> the explanation of BFER BPs would conflate the forward_routed >> explanation. >> > > >> > > Zzh> It's just that this is a place where all kinds of BPs are >> used so it's good to have a summary (could be a subsection 4.9). >> > >> > Yes, added such a summary. Pls. check. >> > >> > > > Actually, the reason that I thought this is MP2P is that 0:6 >> is present on R1, R2, and R3 (and more I assume) in Figure 12, but >> now I think it can???t be MP2P (so it is not correct to have 0:6 >> present on those routers ??? only the p2p tunnel head/tail should >> have the BP present in the BIFT). The reason is that if it were >> MP2P, any router getting a copy will send it to the endpoint of >> the routed adjacency, causing lots of duplicates. >> > > > >> > > > Am I getting this correct? >> > > >> > > I think you are still explaining from the misunderstsanding >> that the ECMP explanations where about routed adjacencies. >> > > >> > > I have now expanded the somewhat terse text in the BIFT table >> pictures, to make it clear that the ECMP is across multipe >> forward_connected adjacencies in the examples. For example, first >> BIFT picture: >> > > >> > >   BIFT entry in BFR1: >> > > >>  ------------------------------------------------------------------ >> > >   | Index |  Adjacencies                  | >> > > >>  ================================================================== >> > >   | 0:6   |  ECMP({forward_connected(L1, BFR2),                 | >> > >   |       |        forward_connected(L2, BFR2),                 | >> > >   |       |        forward_connected(L3, BFR2)}, seed) >>      | >> > > >>  ------------------------------------------------------------------ >> > > >> > > Of course, an ECMP adjacency can be across any type of >> adjacencies, but all the text/explanations used forward_connected, >> and now the pictures show that explicitly. >> > > >> > > Zzh> I can understand the multi-link case, but the multi-hop >> ECMP case (from BFR1 towards BFR10) is confusing me. It would help >> to give an example how it can be used, WITHOUT worrying about >> polarization. >> > >> > Please check -05 text that has the full set of BIFT listed now: >> > >> > There is  really nothing nothing unique in multi-hop ECMP for >> BIER-TE >> > that we do not also have in any other ECMP, except the >> conclusion that >> > we want to support fast HW hash mechanisms AND allow the >> controller to >> > set up non-polarized multi-hop ECMP AND be able to precalculate >> paths. >> > Hence the specification of ECMP adjacencies to have a controller >> > configurable seed. >> > >> > Btw: The picture is maybe unnecessarily large because i've used >> it for >> > 20 years to explain the same polarization issue for unicast vs >> > multicast, and for multicast only BFR10...BFR4 are relevant >> (ECMP of >> > the PIM/mLDP joins), whereas for unicast/BIER only >> > BFR1...BFR7 are relevant. But being symmetric, the picture makes it >> > clear its the same problem. >> > >> > > >    To inhibit looping in the face of such physical >> misconfiguration, >> > > >    only forward_connected adjacencies are permitted to have >> DNR set, and >> > > >    the link layer destination address of the adjacency >> (e.g.  MAC >> > > >    address) protects against closing the loop.  Link layers >> without port >> > > >    unique link layer addresses should not be used with the >> DNR flag set. >> > > > >> > > > It???s not clear how link layer address helps? >> > > >> > > I have expanded this to >> > > "link layer port unique unicast destination address" >> > > >> > > Aka: MPLS or ethernet have unique link layer destination >> destination addresses (label or destination MAC). If you think >> about incorrectly plugged HDLC links (such as old T1/T3/... >> links), they only have 2 generic addresses, if i remember 1 or 3 >> in the HDLC frame. So when you misplug one of those p2p cables >> wrong, the packets would be incrrectly received by the wrong >> receiver node and then DNR could cause persistent loops only >> solved by TTL. >> > > >> > > Zzh> "Consider in the ring picture that link L4 from BFR3 is >> plugged into the L1 interface of BFRa" - still not sure how >> label/mac helps here. I suppose the ring topology is >> discovered/verified by the control plane and when the miscalling >> happens then the ring will not include the BFR1/BFR2 part and BFR3 >> will not have the DNR set? If ring discovery/varication is not >> done then perhaps we should point out that RPF based on link layer >> address is needed - the key is RPF (which needs unique link layer >> address)? >> > >> > Forget RPF. BIER(-TE) has no RPF (issues). Its just like >> unicast. RPF >> > is just a problem for receiver originated joins like in >> PIM/mLDP, but >> > not unicast/bier(-te)/RSVP-TE. >> > >> > Forward_connected is just like a unicast subnet adjacency to a >> direct >> > neighbor: Interface and L2 addresss of the destination. >> > >> > The controller (could be a human) "assumes" a particular physicial >> > topology, from telemetry/knowledge/whatever. It then calculates the >> > desired BIER-TE topology and pushes it down. This topology is >> meant to >> > be loop free of course wrt to the configured adjacencies. >> > In this BIER-TE topology, BFR3 will have a BP with the >> > forward_connected(L4, MAC-of-BFR2) adjacency. >> > >> > If the cable connecting to L4 is miswired, then BFR3 would still >> send >> > the packets to the MAC address of BFR2, but given how the cable >> > connects to some other node, these packets will be discarded by >> that >> > node. because they're just L2 unicast packets. >> > >> > I think this is equally true when we have normal BIER/MPLS enacp. >> > Those packets too are addressed to the unicast MAC address of the >> > neighbor. >> > >> > Now, if/when he controller recognizes that the physical topology >> has >> > changed, thats a completely different story and not addressed here. >> > Given how we assumed this was a cabling mistake, the controller >> would >> > probably only complain about the miswiring to operations but be >> happy >> > that the forwarding plane just makes packets fail instead of >> loop. If >> > this was a planned change process, then it will be similarily >> > convoluted as it would today be with rewiring cables in an >> > SR-MPLS/SRv6 topology and updating SIDs. >> > >> > > > Because the forwarding is different from BIER forwarding >> (because of [1] above), we might as well introduce an optimization >> here ??? for each BIFT, calculate the F-BM of the BIFT itself (the >> logical ???or??? of all the BPs presented in this BIFT) and then >> use (packet->bitstring & BIFT.F-BM) as the input to >> GetFirst/NextBitPosition(). That should skip many bits. >> > > >> > > Right. But i explicitly removed those optimizations (i had >> them in older draft versions) because the whole idea of this >> picture is solely the comparison with figure 4 of RFC8279. >> > > >> > > Zzh> I think it's worth point that optimization out; you can >> mark it optional if you want to emphasize the similarity to BIER >> forwarding, but since BIER forwarding does do the maskoff step, it >> is very efficient while BIER-TE forwarding does not it the maskoff >> step so this optimization is important. >> > >> > Ok. I simplified the text comparison BIER/BIER-TE wrt. to the FBM >> > rules [1] and [2] and added following paragraph: >> > >> > In BIER, the order of BPs impacts the result of forwarding >> because of [1]. >> > In BIER-TE, forwarding is not impacted by the order of BPs. It is >> > therefore possible to further optimize forwarding than in BIER. For >> > example parallelizing forwarding across multiple FPE cores or >> > distributed linecards does only need to examine an arbitrary >> subset of >> > BP and not evaluate the dependency between BPs. >> > >> > > >    The following pseudocode is comprehensive: >> > > > >> > > > The above sentence reads a bit strange (or lacks some segue). >> > > >> > > I hope not, but maybe best left to a native english speaker >> (RFC-editor). >> > > >> > > The first (RFC8279) pseudocode was simplified. The second one >> is comprehensive. If not comprehensive, whats a good opposite of >> simplified ? >> > > >> > > Zzh> Perhaps "The above simplified pseudocode is elaborated >> further as following"? >> > > Zzh> Jeffrey >> > >> > Done. >> > >> > Thanks a lot. >> > >> > >> > > >> > > > ________________________________________ >> > > > From: BIER [bier-bounces@ietf.org >> > >] >> > > > on behalf of Toerless Eckert [tte@cs.fau.de >> >] >> > > > Sent: Tuesday, July 09, 2019 23:38 >> > > > To: Mike McBride >> > > > Cc: Greg Shepherd; BIER WG; Pascal Thubert (pthubert) >> > > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch >> > > > >> > > > Thanks, Mike >> > > > >> > > > The authors also reviewed the document and concluded that it >> was >> > > > really hard to get into the document context because of too >> many >> > > > forward dependencies. We tried to fix this by adding two >> hopefully >> > > > good & basic examples into the Introduction section and >> using them >> > > > to also add a better definition of the term "BIER-TE >> Topology" in the Introduction. >> > > > Hopefully this makes readin the rest of te document smoother. >> > > > >> > > > Also improved text of Abstract and refined text compariing >> BIER-TE with SR. >> > > > >> > > > >> https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: >> > > > **Atools.ietf.org >> *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A >> > > > tool >> > > > s.ietf.org >> *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R >> > > > jC81 >> > > > >> c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV_eTUEh >> > > > $ >> > > > >> > > > > **Atools.ietf.org >> *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A >> > > > tool >> > > > s.ietf.org >> *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R >> > > > jC81 >> > > > >> c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sNd1njcX >> > > > $> >> > > > >> > > > Cheers >> > > >     Toerless >> > > > >> > > > On Wed, Jun 26, 2019 at 10:39:36AM -0700, Mike McBride wrote: >> > > > > How about three? I support. >> > > > > mike >> > > > > >> > > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd >> > > >> wrote: >> > > > > > >> > > > > > We cannot take two 'yes' votes and WG consensus. >> > > > > > Please, read and respond. If you don't support, then >> please vote as much publicly right here. >> > > > > > >> > > > > > Thanks, >> > > > > > Greg >> > > > > > >> > > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert >> (pthubert) > > >> wrote: >> > > > > >> >> > > > > >> Support: >> > > > > >> >> > > > > >> I see great value in deterministic networks as well as >> IOT (with RPL). >> > > > > >> >> > > > > >> All the best, >> > > > > >> >> > > > > >> Pascal >> > > > > >> >> > > > > >> > -----Original Message----- >> > > > > >> > From: BIER >> > > > > >> > > > >> On >> > > > > >> > Behalf Of Toerless Eckert >> > > > > >> > Sent: mardi 4 juin 2019 02:03 >> > > > > >> > To: Greg Shepherd >> > > > > >> > > > >> >> > > > > >> > Cc: BIER WG > >> >> > > > > >> > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch >> > > > > >> > >> > > > > >> > +1 >> > > > > >> > Obviously support as co-author. >> > > > > >> > >> > > > > >> > On Wed, May 29, 2019 at 12:41:26PM -0700, Greg >> Shepherd wrote: >> > > > > >> > > Please read and respond to this thread w/ or w/o >> support. >> > > > > >> > > >> > > > > >> > > >> https://urldefense.com/v3/__https://datatracker..ietf.org >> > > > > >> > > /doc >> > > > > >> > > >> /draft-ietf-bier-te-arch/__;!8WoA6RjC81c!XvH4AAxfrDjFoK_s >> > > > > >> > > ercw ZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV9eClBj$ >> > > > > >> > > >> > > > > > >> > > doc/ >> > > > > >> > > >> draft-ietf-bier-te-arch/__;!8WoA6RjC81c!UBTGvWWpMHyeiSanx >> > > > > >> > > s6vI b_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sD40kmtH$> >> > > > > >> > > >> > > > > >> > > Vote ends 5 June 2019. >> > > > > >> > > >> > > > > >> > > Thanks, >> > > > > >> > > Shep >> > > > > >> > > (chairs) >> > > > > >> > >> > > > > >> > > _______________________________________________ >> > > > > >> > > BIER mailing list >> > > > > >> > > BIER@ietf.org >> > >> > > > > >> > > >> https://urldefense.com/v3/__https://www.ietf.org/mailman/ >> > > > > >> > > list >> > > > > >> > > >> info/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eE >> > > > > >> > > NOs4 l_qdsXF0KwZD82cJLDFFNT2WVXWX$ >> > > > > >> > > >> > > > > > >> > > list >> > > > > >> > > >> info/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6b >> > > > > >> > > oAAW 4nrqju8UCLOgiuXc8Y_6sKn2KoAT$> >> > > > > >> > >> > > > > >> > _______________________________________________ >> > > > > >> > BIER mailing list >> > > > > >> > BIER@ietf.org >> > >> > > > > >> > >> https://urldefense.com/v3/__https://www.ietf.org/mailman/li >> > > > > >> > stin >> > > > > >> > >> fo/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4 >> > > > > >> > l_qd >> > > > > >> > sXF0KwZD82cJLDFFNT2WVXWX$ >> > > > > >> > >> > > > > > >> > stin >> > > > > >> > >> fo/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW >> > > > > >> > 4nrq >> > > > > >> > ju8UCLOgiuXc8Y_6sKn2KoAT$> >> > > > > > >> > > > > > _______________________________________________ >> > > > > > BIER mailing list >> > > > > > BIER@ietf.org >> > >> > > > > > >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listi >> > > > > > nfo/ >> > > > > > >> bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsX >> > > > > > F0Kw >> > > > > > ZD82cJLDFFNT2WVXWX$ >> > > > > > >> > > > > > > nfo/ >> > > > > > >> bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju >> > > > > > 8UCL >> > > > > > OgiuXc8Y_6sKn2KoAT$> >> > > > >> > > > -- >> > > > --- >> > > > tte@cs.fau.de > > >> > > > >> > > > _______________________________________________ >> > > > BIER mailing list >> > > > BIER@ietf.org > > >> > > > >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ >> > > > bier >> > > > >> __;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82 >> > > > cJLD >> > > > FFNT2WVXWX$ >> > > > >> > > > > bier >> > > > >> __;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiu >> > > > Xc8Y >> > > > _6sKn2KoAT$> >> > > >> > > -- >> > > --- >> > > tte@cs.fau.de >> > >> > -- >> > --- >> > tte@cs.fau.de >> > >> > _______________________________________________ >> > BIER mailing list >> > BIER@ietf.org >> > >> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier >> > >> __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx4 >> > 1_jWV3YUA6D$ >> >> -- >> --- >> tte@cs.fau.de >> >> _______________________________________________ >> BIER mailing list >> BIER@ietf.org >> https://www.ietf.org/mailman/listinfo/bier >> > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Fri Feb 21 06:37:44 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA4712086C for ; Fri, 21 Feb 2020 06:37:28 -0800 (PST) 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=unavailable 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 VYtCffNWUIG6 for ; Fri, 21 Feb 2020 06:37:20 -0800 (PST) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450: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 1834E120800 for ; Fri, 21 Feb 2020 06:37:20 -0800 (PST) Received: by mail-lj1-x22d.google.com with SMTP id x7so2440914ljc.1 for ; Fri, 21 Feb 2020 06:37:19 -0800 (PST) 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=k8Sqz/N+b8S0Faz/mUp8sSyi/z63FQMvwZ/jpmtzyxc=; b=cztGGYr6srRF4+RS9nS5uBjTmT9WwH7KQQ27VdSsH/x/URUa0MWsZCa0d6TDy8bWFI lDOLSZq43b1xp8r1ZsWdYs7qGYS+hUw3YjxKDYyy7oaphZjMwtFksQwc/eksbJp9PpSK ulsu5o293XCVJlxOhIKLhkxX6lWbBYyUiC8knA1bF7tq3l+zr0ZmEJbR1lSd8vQrOpwW yRTCpI34gHtn/Br6GXOWzjng2g0qe3yJvdoiUQNtk1tuWO9ikijfmfJ1tytMecaDocg6 /Bu8HU4CtEqSgYMKOI97FsO2OPa5l8W4fuR3Rl1ghmmLj3E8ibAtLlPYLz/wQg4BBkjT bUIw== 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=k8Sqz/N+b8S0Faz/mUp8sSyi/z63FQMvwZ/jpmtzyxc=; b=Z7wVHh9n6WjPUItkpMH2lxPbEPQ2AH8vHUO5MEt7cdayPj0RCW2lCWhBqu9DEVQKJu y2sbMDtDt0bTADjsP6D4ezOrV/Pm9AziX12pPuwF848Ww8CHF00hH1Y7foddvKSIetfl gNEmF9TKEEQ6DSAuXlvyTwJz8vN0K42R69BIdMOH7qJe9ruXZ82VJe4GMB7jRDMmWGWw utsS2Rsvyn2f/kx8yKtwWMm1fCRiNT0mMcgSKkNjrb6d1ow6XwbIPW8YK7XjRDZ3r2HU Hgope3zZuTx3GFm/QW0MQOCYvKVdAAjubrribqD3lct4rNc/XYhyJdr/0UM1oNtBRGex mzAw== X-Gm-Message-State: APjAAAW8hTr41cY/8lo7lmBc/BOtYTOAlTnv+5ZNetniCJdEhKoq2Bgc JM8JohLWIdYlYi2NTzsJi7ur6jeukonHs7za58I= X-Google-Smtp-Source: APXvYqxxpGmk1gMgnyw1F9+6sc2agsqN829v/Ds6hWyzt30PPpnWUhfPb3bjdgb38ntePGgzdemrf5te1kV4AWow+40= X-Received: by 2002:a2e:b0e3:: with SMTP id h3mr21620264ljl.56.1582295838043; Fri, 21 Feb 2020 06:37:18 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Fri, 21 Feb 2020 06:37:06 -0800 Message-ID: To: Greg Shepherd Cc: "Jeffrey (Zhaohui) Zhang" , "bier@ietf.org" , Toerless Eckert Content-Type: multipart/alternative; boundary="0000000000005b301a059f16f57b" Archived-At: Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 14:37:41 -0000 --0000000000005b301a059f16f57b Content-Type: text/plain; charset="UTF-8" (Hope I'm not too late) I support progressing this work. The document presents a technically sound solution for the important use case. Regards, Greg On Tue, Feb 18, 2020 at 12:46 PM Greg Shepherd wrote: > Thanks Toerless and Jeffrey > > https://datatracker.ietf.org/doc/draft-ietf-bier-te-arch/ > > One more week of WGLC. Please read the latest rev and respond to this > thread w/wo support. > > Chairs > (Shep) > > > On Tue, Feb 18, 2020 at 12:07 PM Jeffrey (Zhaohui) Zhang 40juniper.net@dmarc.ietf.org> wrote: > >> Hi Toerless, >> >> Thanks! >> I support moving this to the next stage. >> >> Jeffrey >> >> On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote: >> > Thanks Jeff >> > >> > I have now pushed out -05 with the answers and hopefully resolution to >> > your points in email below. Biggest addition was a section about >> > reuse of BPs (without DNR) which came out of the confusion i think the >> > reuse in the ECMP example raised. I was afraid so far to explan that >> > as it may not be easy to absorb and ultimately is stuff only >> > controller developers need to understand, but hopefully useful. >> > And then of course the summary of BP optimizatins you asked for >> > >> > Diff from last version i sent you: >> > >> > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: >> > **Araw.githubusercontent.com*toerless*bier-te-arch*master*draft-ietf-b >> > ier-te-arch-05.1.txt&url2=http:**Atools.ietf.org*id*draft-ietf-bier-te >> > -arch-05.txt__;Ly8vLy8vLy8vLy8!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzH >> > OCr0fZkLPbgg3CPNu0PyrWsrFx41_jWX2At8V-$ >> > >> > full -04 -> 05 diff: >> > >> > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=http:* >> > *Atools.ietf.org*id*draft-ietf-bier-te-arch-04.txt&url2=http:**Atools. >> > ietf.org*id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk >> > !VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx41_jWancpziv$ >> > >> > Comments inline below. >> > >> > Cheers >> > toerless >> > >> > On Mon, Oct 28, 2019 at 07:52:59PM +0000, Jeffrey (Zhaohui) Zhang wrote: >> > > I Thought u-turn is the most simple comparison leaf vs. non-leaf BFR. >> > > >> > > Zzh> The text in the email is seriously misaligned. Looking at the >> picture in the diff link, while you gave a U-turn example, though even if >> BFER2 is not connected to BFR2 but only connected to BFER1 (hence no >> U-turn), then BFER1 is still not a leaf BFER I suppose. That's why I said >> the first sentence of the above paragraph is enough to define Leaf BFER >> while the example itself is actually not needed. >> > >> > Argh... ok, had to fix two words, BFIR->BFER and left-hand -> >> right-hand: >> > >> > Consider how redundant disjoint traffic can reach BFER1/BFER2 in above >> > picture: When BFER1/BFER2 are Non-Leaf BFER as shown on the right hand >> > side, one traffic copy would be forwarded to BFER1 from BFR1, but the >> > other one could only reach BFER1 via BFER2, which makes BFER2 a >> > non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forwarding >> > traffic to BFER2 >> > >> > > Zzh> Additionally, in left part of the picture you added, if some >> failure leads to BFR2 to be only reachable via BFER1, then BFER1 is no >> longer a leaf BFER. >> > >> > Added sentence: >> > >> > Note that the BFER in the left hand picture are only guaranteed to >> > be leaf-BFR by fitting routing configuration that prohibits transit >> > traffic to pass through a PE, which is commonly applied in these >> > topologies. >> > >> > > I assume you don't reassign BPs when links go up and down. >> > >> > I didn't want to discuss that option in this document. Its obviously >> > perfectly feasible, but be yet a big amount of text (especially the >> > considerations how to do this make-before-break. Future doc. >> > >> > > > but subsequent polarization example confuses me. It seems that BP >> 0:6 is assigned to the routed adjacency BFR10 (which is actually talked >> about in Section 4.8). >> > > >> > > Section 4.7 does not mention "routed" at all, so there are no routed >> adjacencies at all used in 4.7. So i am not sure what you are confused >> about. >> > > >> > > Zzh> "The BIFT of each BFR are only populated with BPs that are >> adjacent to the BFR in the BIER-TE topology". >> > >> > Correct text from the introduction. Ok. >> > >> > > Zzh> Since the same 0:6 is in BIFTS of BFR1/BFR2/BFR3 (and I suppose >> in BFR4~BFR9 as well even though not drawn), I assumed it's for the "MP2P" >> routed adjacency to R10; though I then ruled that out - but I don't know >> what 0:6 represent now on BFR1, BFR2, and BFR3. >> > >> > Ah. Ok. I thought i could strip down the example to show only the >> > adjacencies relevant to the following discusion, but seemingly this >> > can introduce the confusion you have. >> > >> > So i completed the example with the BP assignment acoss all nodes, but >> > added text pointing to a new section further down to discuss the >> > re-use of BP for which thi picture is also an example. >> > >> > (check out the diff, new reuse text to long to copy inline). >> > >> > > The whole purpose of the ECMP BPs is of course to save bits, >> otherwise we'd give each link a separate BP, which would be 6 BP to reach >> to BFR4...BFR7 from BFR1. >> > > >> > > Zzh> The trouble I am having is that the same 0:6 is assigned to >> different things and it's present on all BFR1/BFR2/BFR3. It is perhaps an >> intentional smart design but I have not wrapped my mind around it. It's >> apparently different from the link bundle case, so better separate it out >> and elaborate it (including the DNR flag that might be needed here - If the >> packet arrives on BFR1 with 0:6, would the BP reset when it is sent to >> BFR2/3)? >> > >> > Yes, there was the bug of reusing BP 0:6 across sequential BFR along >> > the path, but now the example correctly reuses separate BP at >> > different stages of the paths (BP 0:6 on BFR1, BP 0:7 on BFR2/BFR3) and >> so on. >> > >> > Thanks! >> > >> > > > 4.8. Routed adjacencies >> > > > >> > > > If I understand it correctly, there is a BP assigned to L1/L2/L3 >> > > > respectively (p2p link), and then there are BPs assigned to MP2P >> tunnels (routed adjacency from every BFR) to the L1/L2/L3 interface >> addresses and loopback addresses on BFR2/3. >> > > >> > > Ok that wasn't quite the read i expected. Let me clarify the >> text/picture: >> > > >> > > ............... >> > > ...BFR1--... ...--L1-- BFR2... >> > > ... .Routers. ...--L2--/ >> > > ...BFR4--... ...------ BFR3... >> > > ............... | >> > > LO >> > > Network Area 1 >> > > >> > > Assume the requirement in the above picture is to explicitly steer >> traffic flows that have arrived at BFR1 or BFR4 via a shortest path in the >> routing underlay "network area 1" to one of the following three next >> segments: (1) BFR2 via link L1, (2) BFR2 via link L2, (3) via BFR3. >> > > >> > > To achieve this, both BFR1 and BFR4 are set up with a forward_routed >> adjacency BitPosition towards an address of BFR2 on link L1, another >> forward_routed BitPosition towards an address of BFR2 on link L2 and a >> third forward_routed Bitposition towards a node address LO of BFR3. >> > > >> > > Does this clear ip the confusion ? >> > > >> > > Zzh> The picture is badly misaligned. I'll wait till 4.7 questions >> are cleared. >> > >> > Ok. >> > >> > > > If BFR2/3 are also BFERs, then they additionally will have BFER BPs. >> > > > On BFR1/4, the BIFT entries for the MP2P BPs for the >> L1/L2/L3/loopback interface addresses of BFR2/3 will use >> forward_routed(interface/loopback address). For a packet to be decapsulated >> on a BFER, there is a need for both the BFER BP and another BP >> (p2p/lan/hub-spoke/routed-adjacency) in the packet (the former is for >> decapsulation and the latter is for getting it there). >> > > >> > > This is not discussed in this section, but you are right - unless >> > > BFR2 or BFR3 is a leaf BFR. In that case, it would just leverage the >> one shared "leaf-BFR" BP, so they do not need a per-BFER BP for >> local_decap(). >> > > >> > > Zzh> Right - shared leaf-BFR BP but still need that BP (the key is >> that we need a BP to get packet to a BFER and then a BP for decapsulation). >> > >> > You got it. >> > >> > > > If that???s the case, it???s worth point the above out. >> > > >> > > Hmm... The logic of BFER BPs is totally independent of the logic of >> forward_routed adjacency, so i would worry that repeating the explanation >> of BFER BPs would conflate the forward_routed explanation. >> > > >> > > Zzh> It's just that this is a place where all kinds of BPs are used >> so it's good to have a summary (could be a subsection 4.9). >> > >> > Yes, added such a summary. Pls. check. >> > >> > > > Actually, the reason that I thought this is MP2P is that 0:6 is >> present on R1, R2, and R3 (and more I assume) in Figure 12, but now I think >> it can???t be MP2P (so it is not correct to have 0:6 present on those >> routers ??? only the p2p tunnel head/tail should have the BP present in the >> BIFT). The reason is that if it were MP2P, any router getting a copy will >> send it to the endpoint of the routed adjacency, causing lots of >> duplicates.. >> > > > >> > > > Am I getting this correct? >> > > >> > > I think you are still explaining from the misunderstsanding that the >> ECMP explanations where about routed adjacencies. >> > > >> > > I have now expanded the somewhat terse text in the BIFT table >> pictures, to make it clear that the ECMP is across multipe >> forward_connected adjacencies in the examples. For example, first BIFT >> picture: >> > > >> > > BIFT entry in BFR1: >> > > ------------------------------------------------------------------ >> > > | Index | Adjacencies | >> > > ================================================================== >> > > | 0:6 | ECMP({forward_connected(L1, BFR2), | >> > > | | forward_connected(L2, BFR2), | >> > > | | forward_connected(L3, BFR2)}, seed) | >> > > ------------------------------------------------------------------ >> > > >> > > Of course, an ECMP adjacency can be across any type of adjacencies, >> but all the text/explanations used forward_connected, and now the pictures >> show that explicitly. >> > > >> > > Zzh> I can understand the multi-link case, but the multi-hop ECMP >> case (from BFR1 towards BFR10) is confusing me. It would help to give an >> example how it can be used, WITHOUT worrying about polarization. >> > >> > Please check -05 text that has the full set of BIFT listed now: >> > >> > There is really nothing nothing unique in multi-hop ECMP for BIER-TE >> > that we do not also have in any other ECMP, except the conclusion that >> > we want to support fast HW hash mechanisms AND allow the controller to >> > set up non-polarized multi-hop ECMP AND be able to precalculate paths. >> > Hence the specification of ECMP adjacencies to have a controller >> > configurable seed. >> > >> > Btw: The picture is maybe unnecessarily large because i've used it for >> > 20 years to explain the same polarization issue for unicast vs >> > multicast, and for multicast only BFR10...BFR4 are relevant (ECMP of >> > the PIM/mLDP joins), whereas for unicast/BIER only >> > BFR1...BFR7 are relevant. But being symmetric, the picture makes it >> > clear its the same problem. >> > >> > > > To inhibit looping in the face of such physical misconfiguration, >> > > > only forward_connected adjacencies are permitted to have DNR >> set, and >> > > > the link layer destination address of the adjacency (e.g. MAC >> > > > address) protects against closing the loop. Link layers without >> port >> > > > unique link layer addresses should not be used with the DNR flag >> set. >> > > > >> > > > It???s not clear how link layer address helps? >> > > >> > > I have expanded this to >> > > "link layer port unique unicast destination address" >> > > >> > > Aka: MPLS or ethernet have unique link layer destination destination >> addresses (label or destination MAC). If you think about incorrectly >> plugged HDLC links (such as old T1/T3/... links), they only have 2 generic >> addresses, if i remember 1 or 3 in the HDLC frame. So when you misplug one >> of those p2p cables wrong, the packets would be incrrectly received by the >> wrong receiver node and then DNR could cause persistent loops only solved >> by TTL. >> > > >> > > Zzh> "Consider in the ring picture that link L4 from BFR3 is plugged >> into the L1 interface of BFRa" - still not sure how label/mac helps here. I >> suppose the ring topology is discovered/verified by the control plane and >> when the miscalling happens then the ring will not include the BFR1/BFR2 >> part and BFR3 will not have the DNR set? If ring discovery/varication is >> not done then perhaps we should point out that RPF based on link layer >> address is needed - the key is RPF (which needs unique link layer address)? >> > >> > Forget RPF. BIER(-TE) has no RPF (issues). Its just like unicast. RPF >> > is just a problem for receiver originated joins like in PIM/mLDP, but >> > not unicast/bier(-te)/RSVP-TE. >> > >> > Forward_connected is just like a unicast subnet adjacency to a direct >> > neighbor: Interface and L2 addresss of the destination. >> > >> > The controller (could be a human) "assumes" a particular physicial >> > topology, from telemetry/knowledge/whatever. It then calculates the >> > desired BIER-TE topology and pushes it down. This topology is meant to >> > be loop free of course wrt to the configured adjacencies. >> > In this BIER-TE topology, BFR3 will have a BP with the >> > forward_connected(L4, MAC-of-BFR2) adjacency. >> > >> > If the cable connecting to L4 is miswired, then BFR3 would still send >> > the packets to the MAC address of BFR2, but given how the cable >> > connects to some other node, these packets will be discarded by that >> > node. because they're just L2 unicast packets. >> > >> > I think this is equally true when we have normal BIER/MPLS enacp. >> > Those packets too are addressed to the unicast MAC address of the >> > neighbor. >> > >> > Now, if/when he controller recognizes that the physical topology has >> > changed, thats a completely different story and not addressed here. >> > Given how we assumed this was a cabling mistake, the controller would >> > probably only complain about the miswiring to operations but be happy >> > that the forwarding plane just makes packets fail instead of loop. If >> > this was a planned change process, then it will be similarily >> > convoluted as it would today be with rewiring cables in an >> > SR-MPLS/SRv6 topology and updating SIDs. >> > >> > > > Because the forwarding is different from BIER forwarding (because >> of [1] above), we might as well introduce an optimization here ??? for each >> BIFT, calculate the F-BM of the BIFT itself (the logical ???or??? of all >> the BPs presented in this BIFT) and then use (packet->bitstring & >> BIFT.F-BM) as the input to GetFirst/NextBitPosition(). That should skip >> many bits. >> > > >> > > Right. But i explicitly removed those optimizations (i had them in >> older draft versions) because the whole idea of this picture is solely the >> comparison with figure 4 of RFC8279. >> > > >> > > Zzh> I think it's worth point that optimization out; you can mark it >> optional if you want to emphasize the similarity to BIER forwarding, but >> since BIER forwarding does do the maskoff step, it is very efficient while >> BIER-TE forwarding does not it the maskoff step so this optimization is >> important. >> > >> > Ok. I simplified the text comparison BIER/BIER-TE wrt. to the FBM >> > rules [1] and [2] and added following paragraph: >> > >> > In BIER, the order of BPs impacts the result of forwarding because >> of [1]. >> > In BIER-TE, forwarding is not impacted by the order of BPs. It is >> > therefore possible to further optimize forwarding than in BIER. For >> > example parallelizing forwarding across multiple FPE cores or >> > distributed linecards does only need to examine an arbitrary subset of >> > BP and not evaluate the dependency between BPs. >> > >> > > > The following pseudocode is comprehensive: >> > > > >> > > > The above sentence reads a bit strange (or lacks some segue).. >> > > >> > > I hope not, but maybe best left to a native english speaker >> (RFC-editor). >> > > >> > > The first (RFC8279) pseudocode was simplified. The second one is >> comprehensive. If not comprehensive, whats a good opposite of simplified ? >> > > >> > > Zzh> Perhaps "The above simplified pseudocode is elaborated further >> as following"? >> > > Zzh> Jeffrey >> > >> > Done. >> > >> > Thanks a lot. >> > >> > >> > > >> > > > ________________________________________ >> > > > From: BIER [bier-bounces@ietf.org] >> > > > on behalf of Toerless Eckert [tte@cs.fau.de] >> > > > Sent: Tuesday, July 09, 2019 23:38 >> > > > To: Mike McBride >> > > > Cc: Greg Shepherd; BIER WG; Pascal Thubert (pthubert) >> > > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch >> > > > >> > > > Thanks, Mike >> > > > >> > > > The authors also reviewed the document and concluded that it was >> > > > really hard to get into the document context because of too many >> > > > forward dependencies. We tried to fix this by adding two hopefully >> > > > good & basic examples into the Introduction section and using them >> > > > to also add a better definition of the term "BIER-TE Topology" in >> the Introduction. >> > > > Hopefully this makes readin the rest of te document smoother.. >> > > > >> > > > Also improved text of Abstract and refined text compariing BIER-TE >> with SR. >> > > > >> > > > >> https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: >> > > > **Atools.ietf.org*id*draft-ietf-bier-te-arch-02.txt&url2=https:**A >> > > > tool >> > > > s.ietf.org*id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R >> > > > jC81 >> > > > c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV_eTUEh >> > > > $ >> > > > < >> https://urldefense.com/v3/__http:/tools.ietf.org/*rfcdiff?url1=https: >> > > > **Atools.ietf.org*id*draft-ietf-bier-te-arch-02.txt&url2=https:**A >> > > > tool >> > > > s.ietf.org*id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R >> > > > jC81 >> > > > c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sNd1njcX >> > > > $> >> > > > >> > > > Cheers >> > > > Toerless >> > > > >> > > > On Wed, Jun 26, 2019 at 10:39:36AM -0700, Mike McBride wrote: >> > > > > How about three? I support. >> > > > > mike >> > > > > >> > > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd > > wrote: >> > > > > > >> > > > > > We cannot take two 'yes' votes and WG consensus. >> > > > > > Please, read and respond. If you don't support, then please >> vote as much publicly right here. >> > > > > > >> > > > > > Thanks, >> > > > > > Greg >> > > > > > >> > > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert (pthubert) < >> pthubert@cisco.com> wrote: >> > > > > >> >> > > > > >> Support: >> > > > > >> >> > > > > >> I see great value in deterministic networks as well as IOT >> (with RPL). >> > > > > >> >> > > > > >> All the best, >> > > > > >> >> > > > > >> Pascal >> > > > > >> >> > > > > >> > -----Original Message----- >> > > > > >> > From: BIER >> > > > > >> > > On >> > > > > >> > Behalf Of Toerless Eckert >> > > > > >> > Sent: mardi 4 juin 2019 02:03 >> > > > > >> > To: Greg Shepherd >> > > > > >> > > >> > > > > >> > Cc: BIER WG > >> > > > > >> > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch >> > > > > >> > >> > > > > >> > +1 >> > > > > >> > Obviously support as co-author. >> > > > > >> > >> > > > > >> > On Wed, May 29, 2019 at 12:41:26PM -0700, Greg Shepherd >> wrote: >> > > > > >> > > Please read and respond to this thread w/ or w/o support. >> > > > > >> > > >> > > > > >> > > https://urldefense.com/v3/__https://datatracker..ietf.org >> > > > > >> > > /doc >> > > > > >> > > /draft-ietf-bier-te-arch/__;!8WoA6RjC81c!XvH4AAxfrDjFoK_s >> > > > > >> > > ercw ZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV9eClBj$ >> > > > > >> > > > > > > > >> > > doc/ >> > > > > >> > > draft-ietf-bier-te-arch/__;!8WoA6RjC81c!UBTGvWWpMHyeiSanx >> > > > > >> > > s6vI b_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sD40kmtH$> >> > > > > >> > > >> > > > > >> > > Vote ends 5 June 2019. >> > > > > >> > > >> > > > > >> > > Thanks, >> > > > > >> > > Shep >> > > > > >> > > (chairs) >> > > > > >> > >> > > > > >> > > _______________________________________________ >> > > > > >> > > BIER mailing list >> > > > > >> > > BIER@ietf.org >> > > > > >> > > https://urldefense.com/v3/__https://www.ietf.org/mailman/ >> > > > > >> > > list >> > > > > >> > > info/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eE >> > > > > >> > > NOs4 l_qdsXF0KwZD82cJLDFFNT2WVXWX$ >> > > > > >> > > > > > > > >> > > list >> > > > > >> > > info/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6b >> > > > > >> > > oAAW 4nrqju8UCLOgiuXc8Y_6sKn2KoAT$> >> > > > > >> > >> > > > > >> > _______________________________________________ >> > > > > >> > BIER mailing list >> > > > > >> > BIER@ietf.org >> > > > > >> > https://urldefense.com/v3/__https://www.ietf.org/mailman/li >> > > > > >> > stin >> > > > > >> > fo/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4 >> > > > > >> > l_qd >> > > > > >> > sXF0KwZD82cJLDFFNT2WVXWX$ >> > > > > >> > > > > > > >> > stin >> > > > > >> > fo/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW >> > > > > >> > 4nrq >> > > > > >> > ju8UCLOgiuXc8Y_6sKn2KoAT$> >> > > > > > >> > > > > > _______________________________________________ >> > > > > > BIER mailing list >> > > > > > BIER@ietf.org >> > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listi >> >> > > > > > nfo/ >> > > > > > bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsX >> > > > > > F0Kw >> > > > > > ZD82cJLDFFNT2WVXWX$ >> > > > > > > > > > > > nfo/ >> > > > > > bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju >> > > > > > 8UCL >> > > > > > OgiuXc8Y_6sKn2KoAT$> >> > > > >> > > > -- >> > > > --- >> > > > tte@cs.fau.de >> > > > >> > > > _______________________________________________ >> > > > BIER mailing list >> > > > BIER@ietf..org >> > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ >> > > > bier >> > > > __;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82 >> > > > cJLD >> > > > FFNT2WVXWX$ >> > > > > > > > bier >> > > > __;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiu >> > > > Xc8Y >> > > > _6sKn2KoAT$> >> > > >> > > -- >> > > --- >> > > tte@cs.fau.de >> > >> > -- >> > --- >> > tte@cs.fau.de >> > >> > _______________________________________________ >> > BIER mailing list >> > BIER@ietf.org >> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier >> > __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx4 >> > 1_jWV3YUA6D$ >> >> -- >> --- >> tte@cs.fau.de >> >> _______________________________________________ >> BIER mailing list >> BIER@ietf.org >> https://www.ietf.org/mailman/listinfo/bier >> > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > --0000000000005b301a059f16f57b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
(Hope I'm not too late)

I support p= rogressing this work. The document presents a technically sound solution fo= r the important use case.

Regards,
Greg<= /div>
O= n Tue, Feb 18, 2020 at 12:46 PM Greg Shepherd <gjshep@gmail.com> wrote:
Thanks T= oerless and Jeffrey


O= ne more week of WGLC. Please read the latest rev and respond to this thread= w/wo support.

Chairs
(Shep)
<= br>

On Tue, Feb 18, 2020 at 12:07 PM Jeffrey (Zhaohui) Zhang <zzhang=3D40juniper.n= et@dmarc.ietf.org> wrote:
Hi Toerless,

Thanks!
I support moving this to the next stage.

Jeffrey

On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote:
> Thanks Jeff
>
> I have now pushed out -05 with the answers and hopefully resolution to=
> your points in email below.=C2=A0 Biggest addition was a section about=
> reuse of BPs (without DNR) which came out of the confusion i think the=
> reuse in the ECMP example raised. I was afraid so far to explan that <= br> > as it may not be easy to absorb and ultimately is stuff only
> controller developers need to understand, but hopefully useful.
> And then of course the summary of BP optimizatins you asked for
>
> Diff from last version i sent you:
>
> https://urldefense.com/v= 3/__http://tools.ietf.org/*rfcdiff?url1=3Dhttps:
> **Araw.githubusercontent.com*toerless*bier-te-arch*master*= draft-ietf-b
> ier-te-arch-05.1.txt&url2=3Dhttp:**Atools.ietf.org*id*draft-ietf-= bier-te
> -arch-05.txt__;Ly8vLy8vLy8vLy8!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzH=
> OCr0fZkLPbgg3CPNu0PyrWsrFx41_jWX2At8V-$
>
> full -04 -> 05 diff:
>
> https://urldefense.com/= v3/__http://tools.ietf.org/*rfcdiff?url1=3Dhttp:*
> *Atools.ietf.org*id*draft-ietf-bier-te-arch-04.txt&url2=3Dhttp:**= Atools.
> ietf.= org*id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk
> !VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx41_jWancpziv$
>
> Comments inline below.
>
> Cheers
>=C2=A0 =C2=A0 =C2=A0toerless
>
> On Mon, Oct 28, 2019 at 07:52:59PM +0000, Jeffrey (Zhaohui) Zhang wrot= e:
> > I Thought u-turn is the most simple comparison leaf vs. non-leaf = BFR.
> >
> > Zzh> The text in the email is seriously misaligned. Looking at= the picture in the diff link, while you gave a U-turn example, though even= if BFER2 is not connected to BFR2=C2=A0 but only connected to BFER1 (hence= no U-turn), then BFER1 is still not a leaf BFER I suppose. That's why = I said the first sentence of the above paragraph is enough to define Leaf B= FER while the example itself is actually not needed.
>
> Argh... ok, had to fix two words, BFIR->BFER and left-hand -> ri= ght-hand:
>
> Consider how redundant disjoint traffic can reach BFER1/BFER2 in above=
> picture: When BFER1/BFER2 are Non-Leaf BFER as shown on the right hand=
> side, one traffic copy would be forwarded to BFER1 from BFR1, but the =
> other one could only reach BFER1 via BFER2, which makes BFER2 a
> non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forwarding
> traffic to BFER2
>
> > Zzh> Additionally, in left part of the picture you added, if s= ome failure leads to BFR2 to be only reachable via BFER1, then BFER1 is no = longer a leaf BFER.
>
> Added sentence:
>
> <t>Note that the BFER in the left hand picture are only guarante= ed to
> be leaf-BFR by fitting routing configuration that prohibits transit > traffic to pass through a PE, which is commonly applied in these
> topologies.</t>
>
> > I assume you don't reassign BPs when links go up and down. >
> I didn't want to discuss that option in this document. Its obvious= ly
> perfectly feasible, but be yet a big amount of text (especially the > considerations how to do this make-before-break. Future doc.
>
> > > but subsequent polarization example confuses me. It seems th= at BP 0:6 is assigned to the routed adjacency BFR10 (which is actually talk= ed about in Section 4.8).
> >
> > Section 4.7 does not mention "routed" at all, so there = are no routed adjacencies at all used in 4.7. So i am not sure what you are= confused about.
> >
> > Zzh> "The BIFT of each BFR are only populated with BPs th= at are adjacent to the BFR in the BIER-TE topology".
>
> Correct text from the introduction. Ok.
>
> > Zzh> Since the same 0:6 is in BIFTS of BFR1/BFR2/BFR3 (and I s= uppose in BFR4~BFR9 as well even though not drawn), I assumed it's for = the "MP2P" routed adjacency to R10; though I then ruled that out = - but I don't know what 0:6 represent now on BFR1, BFR2, and BFR3.
>
> Ah. Ok. I thought i could strip down the example to show only the
> adjacencies relevant to the following discusion, but seemingly this > can introduce the confusion you have.
>
> So i completed the example with the BP assignment acoss all nodes, but=
> added text pointing to a new section further down to discuss the
> re-use of BP for which thi picture is also an example.
>
> (check out the diff, new reuse text to long to copy inline).
>
> > The whole purpose of the ECMP BPs is of course to save bits, othe= rwise we'd give each link a separate BP, which would be 6 BP to reach t= o BFR4...BFR7 from BFR1.
> >
> > Zzh> The trouble I am having is that the same 0:6 is assigned = to different things and it's present on all BFR1/BFR2/BFR3. It is perha= ps an intentional smart design but I have not wrapped my mind around it. It= 's apparently different from the link bundle case, so better separate i= t out and elaborate it (including the DNR flag that might be needed here - = If the packet arrives on BFR1 with 0:6, would the BP reset when it is sent = to BFR2/3)?
>
> Yes, there was the bug of reusing BP 0:6 across sequential BFR along <= br> > the path, but now the example correctly reuses separate BP at
> different stages of the paths (BP 0:6 on BFR1, BP 0:7 on BFR2/BFR3) an= d so on.
>
> Thanks!
>
> > > 4.8.=C2=A0 Routed adjacencies
> > >
> > > If I understand it correctly, there is a BP assigned to L1/L= 2/L3
> > > respectively (p2p link), and then there are BPs assigned to = MP2P tunnels (routed adjacency from every BFR) to the L1/L2/L3 interface ad= dresses and loopback addresses on BFR2/3.
> >
> > Ok that wasn't quite the read i expected. Let me clarify the = text/picture:
> >
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ...............=C2=A0 =C2=A0 =C2=A0
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...BFR1--...=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0...--L1-- BFR2...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0... .Routers. ...--L2--/=C2=A0
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ...BFR4--...=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0...------ BFR3...
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ...............=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0LO
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Network Area 1
> >
> > Assume the requirement in the above picture is to explicitly stee= r traffic flows that have arrived at BFR1 or BFR4 via a shortest path in th= e routing underlay "network area 1" to one of the following three= next segments: (1) BFR2 via link L1, (2) BFR2 via link L2, (3) via BFR3. > >
> > To achieve this, both BFR1 and BFR4 are set up with a forward_rou= ted adjacency BitPosition towards an address of BFR2 on link L1, another fo= rward_routed BitPosition towards an address of BFR2 on link L2 and a third = forward_routed Bitposition towards a node address LO of BFR3.
> >
> > Does this clear ip the confusion ?
> >
> > Zzh> The picture is badly misaligned. I'll wait till 4.7 q= uestions are cleared.
>
> Ok.
>
> > > If BFR2/3 are also BFERs, then they additionally will have B= FER BPs.
> > > On BFR1/4, the BIFT entries for the MP2P BPs for the L1/L2/L= 3/loopback interface addresses of BFR2/3 will use forward_routed(interface/= loopback address). For a packet to be decapsulated on a BFER, there is a ne= ed for both the BFER BP and another BP (p2p/lan/hub-spoke/routed-adjacency)= in the packet (the former is for decapsulation and the latter is for getti= ng it there).
> >
> > This is not discussed in this section, but you are right - unless=
> > BFR2 or BFR3 is a leaf BFR. In that case, it would just leverage = the one shared "leaf-BFR" BP, so they do not need a per-BFER BP f= or local_decap().
> >
> > Zzh> Right - shared leaf-BFR BP but still need that BP (the ke= y is that we need a BP to get packet to a BFER and then a BP for decapsulat= ion).
>
> You got it.
>
> > > If that???s the case, it???s worth point the above out.
> >
> > Hmm... The logic of BFER BPs is totally independent of the logic = of forward_routed adjacency, so i would worry that repeating the explanatio= n of BFER BPs would conflate the forward_routed explanation.
> >
> > Zzh> It's just that this is a place where all kinds of BPs= are used so it's good to have a summary (could be a subsection 4.9). >
> Yes, added such a summary. Pls. check.
>
> > > Actually, the reason that I thought this is MP2P is that 0:6= is present on R1, R2, and R3 (and more I assume) in Figure 12, but now I t= hink it can???t be MP2P (so it is not correct to have 0:6 present on those = routers ??? only the p2p tunnel head/tail should have the BP present in the= BIFT). The reason is that if it were MP2P, any router getting a copy will = send it to the endpoint of the routed adjacency, causing lots of duplicates= ..
> > >
> > > Am I getting this correct?
> >
> > I think you are still explaining from the misunderstsanding that = the ECMP explanations where about routed adjacencies.
> >
> > I have now expanded the somewhat terse text in the BIFT table pic= tures, to make it clear that the ECMP is across multipe forward_connected a= djacencies in the examples. For example, first BIFT picture:
> >
> >=C2=A0 =C2=A0BIFT entry in BFR1:
> >=C2=A0 =C2=A0-----------------------------------------------------= -------------
> >=C2=A0 =C2=A0| Index |=C2=A0 Adjacencies=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> >=C2=A0 =C2=A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=C2=A0 =C2=A0| 0:6=C2=A0 =C2=A0|=C2=A0 ECMP({forward_connected(L1,= BFR2),=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
> >=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 forward_connected(L2, BFR2),=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
> >=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2= =A0 forward_connected(L3, BFR2)}, seed)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|
> >=C2=A0 =C2=A0-----------------------------------------------------= -------------
> >
> > Of course, an ECMP adjacency can be across any type of adjacencie= s, but all the text/explanations used forward_connected, and now the pictur= es show that explicitly.
> >
> > Zzh> I can understand the multi-link case, but the multi-hop E= CMP case (from BFR1 towards BFR10) is confusing me. It would help to give a= n example how it can be used, WITHOUT worrying about polarization.
>
> Please check -05 text that has the full set of BIFT listed now:
>
> There is=C2=A0 really nothing nothing unique in multi-hop ECMP for BIE= R-TE
> that we do not also have in any other ECMP, except the conclusion that=
> we want to support fast HW hash mechanisms AND allow the controller to=
> set up non-polarized multi-hop ECMP AND be able to precalculate paths.=
> Hence the specification of ECMP adjacencies to have a controller
> configurable seed.
>
> Btw: The picture is maybe unnecessarily large because i've used it= for
> 20 years to explain the same polarization issue for unicast vs
> multicast, and for multicast only BFR10...BFR4 are relevant (ECMP of <= br> > the PIM/mLDP joins), whereas for unicast/BIER only
> BFR1...BFR7 are relevant. But being symmetric, the picture makes it > clear its the same problem.
>
> > >=C2=A0 =C2=A0 To inhibit looping in the face of such physical= misconfiguration,
> > >=C2=A0 =C2=A0 only forward_connected adjacencies are permitte= d to have DNR set, and
> > >=C2=A0 =C2=A0 the link layer destination address of the adjac= ency (e.g.=C2=A0 MAC
> > >=C2=A0 =C2=A0 address) protects against closing the loop.=C2= =A0 Link layers without port
> > >=C2=A0 =C2=A0 unique link layer addresses should not be used = with the DNR flag set.
> > >
> > > It???s not clear how link layer address helps?
> >
> > I have expanded this to
> > "link layer port unique unicast destination address" > >
> > Aka: MPLS or ethernet have unique link layer destination destinat= ion addresses (label or destination MAC). If you think about incorrectly pl= ugged HDLC links (such as old T1/T3/... links), they only have 2 generic ad= dresses, if i remember 1 or 3 in the HDLC frame. So when you misplug one of= those p2p cables wrong, the packets would be incrrectly received by the wr= ong receiver node and then DNR could cause persistent loops only solved by = TTL.
> >
> > Zzh> "Consider in the ring picture that link L4 from BFR3= is plugged into the L1 interface of BFRa" - still not sure how label/= mac helps here. I suppose the ring topology is discovered/verified by the c= ontrol plane and when the miscalling happens then the ring will not include= the BFR1/BFR2 part and BFR3 will not have the DNR set? If ring discovery/v= arication is not done then perhaps we should point out that RPF based on li= nk layer address is needed - the key is RPF (which needs unique link layer = address)?
>
> Forget RPF. BIER(-TE) has no RPF (issues). Its just like unicast. RPF =
> is just a problem for receiver originated joins like in PIM/mLDP, but =
> not unicast/bier(-te)/RSVP-TE.
>
> Forward_connected is just like a unicast subnet adjacency to a direct =
> neighbor: Interface and L2 addresss of the destination.
>
> The controller (could be a human) "assumes" a particular phy= sicial
> topology, from telemetry/knowledge/whatever. It then calculates the > desired BIER-TE topology and pushes it down. This topology is meant to=
> be loop free of course wrt to the configured adjacencies.
> In this BIER-TE topology, BFR3 will have a BP with the
> forward_connected(L4, MAC-of-BFR2) adjacency.
>
> If the cable connecting to L4 is miswired, then BFR3 would still send =
> the packets to the MAC address of BFR2, but given how the cable
> connects to some other node, these packets will be discarded by that <= br> > node. because they're just L2 unicast packets.
>
> I think this is equally true when we have normal BIER/MPLS enacp.
> Those packets too are addressed to the unicast MAC address of the
> neighbor.
>
> Now, if/when he controller recognizes that the physical topology has <= br> > changed, thats a completely different story and not addressed here. > Given how we assumed this was a cabling mistake, the controller would =
> probably only complain about the miswiring to operations but be happy =
> that the forwarding plane just makes packets fail instead of loop. If =
> this was a planned change process, then it will be similarily
> convoluted as it would today be with rewiring cables in an
> SR-MPLS/SRv6 topology and updating SIDs.
>
> > > Because the forwarding is different from BIER forwarding (be= cause of [1] above), we might as well introduce an optimization here ??? fo= r each BIFT, calculate the F-BM of the BIFT itself (the logical ???or??? of= all the BPs presented in this BIFT) and then use (packet->bitstring &am= p; BIFT.F-BM) as the input to GetFirst/NextBitPosition(). That should skip = many bits.
> >
> > Right. But i explicitly removed those optimizations (i had them i= n older draft versions) because the whole idea of this picture is solely th= e comparison with figure 4 of RFC8279.
> >
> > Zzh> I think it's worth point that optimization out; you c= an mark it optional if you want to emphasize the similarity to BIER forward= ing, but since BIER forwarding does do the maskoff step, it is very efficie= nt while BIER-TE forwarding does not it the maskoff step so this optimizati= on is important.
>
> Ok. I simplified the text comparison BIER/BIER-TE wrt. to the FBM
> rules [1] and [2] and added following paragraph:
>
> <t>In BIER, the order of BPs impacts the result of forwarding be= cause of [1].
> In BIER-TE, forwarding is not impacted by the order of BPs. It is
> therefore possible to further optimize forwarding than in BIER. For > example parallelizing forwarding across multiple FPE cores or
> distributed linecards does only need to examine an arbitrary subset of=
> BP and not evaluate the dependency between BPs.</t>
>
> > >=C2=A0 =C2=A0 The following pseudocode is comprehensive:
> > >
> > > The above sentence reads a bit strange (or lacks some segue)= ..
> >
> > I hope not, but maybe best left to a native english speaker (RFC-= editor).
> >
> > The first (RFC8279) pseudocode was simplified. The second one is = comprehensive. If not comprehensive, whats a good opposite of simplified ?<= br> > >
> > Zzh> Perhaps "The above simplified pseudocode is elaborat= ed further as following"?
> > Zzh> Jeffrey
>
> Done.
>
> Thanks a lot.
>
>
> >=C2=A0 =C2=A0
> > > ________________________________________
> > > From: BIER [bier-bounces@ietf.org<mailto:bier-bounces@ietf.org>]
> > > on behalf of Toerless Eckert [tte@cs.fau.de<mailto:tte@cs.fau.de>]
> > > Sent: Tuesday, July 09, 2019 23:38
> > > To: Mike McBride
> > > Cc: Greg Shepherd; BIER WG; Pascal Thubert (pthubert)
> > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch
> > >
> > > Thanks, Mike
> > >
> > > The authors also reviewed the document and concluded that it= was
> > > really hard to get into the document context because of too = many
> > > forward dependencies. We tried to fix this by adding two hop= efully
> > > good & basic examples into the Introduction section and = using them
> > > to also add a better definition of the term "BIER-TE To= pology" in the Introduction.
> > > Hopefully this makes readin the rest of te document smoother= ..
> > >
> > > Also improved text of Abstract and refined text compariing B= IER-TE with SR.
> > >
> > > https://urldef= ense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=3Dhttps:
> > > **Atools.ietf.org*id*draft-ietf-bier-te-arch-02.txt&url= 2=3Dhttps:**A
> > > tool
> > > s.ietf.org*id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA= 6R
> > > jC81
> > > c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV= _eTUEh
> > > $
> > > <https://url= defense.com/v3/__http:/tools.ietf.org/*rfcdiff?url1=3Dhttps:
> > > **Atools.ietf.org*id*draft-ietf-bier-te-arch-02.txt&url= 2=3Dhttps:**A
> > > tool
> > > s.ietf.org*id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA= 6R
> > > jC81
> > > c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sN= d1njcX
> > > $>
> > >
> > > Cheers
> > >=C2=A0 =C2=A0 =C2=A0Toerless
> > >
> > > On Wed, Jun 26, 2019 at 10:39:36AM -0700, Mike McBride wrote= :
> > > > How about three? I support.
> > > > mike
> > > >
> > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd <gjshep@gmail.com<m= ailto:gjshep@gmail.co= m>> wrote:
> > > > >
> > > > > We cannot take two 'yes' votes and WG cons= ensus.
> > > > > Please, read and respond. If you don't support= , then please vote as much publicly right here.
> > > > >
> > > > > Thanks,
> > > > > Greg
> > > > >
> > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert (pt= hubert) <pthuber= t@cisco.com<mailto:pthubert@cisco.com>> wrote:
> > > > >>
> > > > >> Support:
> > > > >>
> > > > >> I see great value in deterministic networks as= well as IOT (with RPL).
> > > > >>
> > > > >> All the best,
> > > > >>
> > > > >> Pascal
> > > > >>
> > > > >> > -----Original Message-----
> > > > >> > From: BIER
> > > > >> > <bier-bounces@ietf.org<mailto:bier-bounces@ietf.org>>= On
> > > > >> > Behalf Of Toerless Eckert
> > > > >> > Sent: mardi 4 juin 2019 02:03
> > > > >> > To: Greg Shepherd
> > > > >> > <gjshep@gmail.com<mailto:gjshep@gmail.com>>
> > > > >> > Cc: BIER WG <bier@ietf.org<mailto:bier@ietf.org>>
> > > > >> > Subject: Re: [Bier] WGLC - draft-ietf-bie= r-te-arch
> > > > >> >
> > > > >> > +1
> > > > >> > Obviously support as co-author.
> > > > >> >
> > > > >> > On Wed, May 29, 2019 at 12:41:26PM -0700,= Greg Shepherd wrote:
> > > > >> > > Please read and respond to this thre= ad w/ or w/o support.
> > > > >> > >
> > > > >> > > http= s://urldefense.com/v3/__https://datatracker..ietf.org
> > > > >> > > /doc
> > > > >> > > /draft-ietf-bier-te-arch/__;!8WoA6Rj= C81c!XvH4AAxfrDjFoK_s
> > > > >> > > ercw ZMsc0O5N42eENOs4l_qdsXF0KwZD82c= JLDFFNV9eClBj$
> > > > >> > > <h= ttps://urldefense.com/v3/__https:/datatracker.ietf.org/
> > > > >> > > doc/
> > > > >> > > draft-ietf-bier-te-arch/__;!8WoA6RjC= 81c!UBTGvWWpMHyeiSanx
> > > > >> > > s6vI b_EnBVgyg6boAAW4nrqju8UCLOgiuXc= 8Y_6sD40kmtH$>
> > > > >> > >
> > > > >> > > Vote ends 5 June 2019.
> > > > >> > >
> > > > >> > > Thanks,
> > > > >> > > Shep
> > > > >> > > (chairs)
> > > > >> >
> > > > >> > > ____________________________________= ___________
> > > > >> > > BIER mailing list
> > > > >> > > BIER@ietf.org<mailto:BIER@ietf.org>
> > > > >> > > http= s://urldefense.com/v3/__https://www.ietf.org/mailman/
> > > > >> > > list
> > > > >> > > info/bier__;!8WoA6RjC81c!XvH4AAxfrDj= FoK_sercwZMsc0O5N42eE
> > > > >> > > NOs4 l_qdsXF0KwZD82cJLDFFNT2WVXWX$ <= br> > > > > >> > > <h= ttps://urldefense.com/v3/__https:/www.ietf.org/mailman/
> > > > >> > > list
> > > > >> > > info/bier__;!8WoA6RjC81c!UBTGvWWpMHy= eiSanxs6vIb_EnBVgyg6b
> > > > >> > > oAAW 4nrqju8UCLOgiuXc8Y_6sKn2KoAT$&g= t;
> > > > >> >
> > > > >> > _________________________________________= ______
> > > > >> > BIER mailing list
> > > > >> > BIER@ietf.org<mailto:BIER@ietf.org>
> > > > >> > https:/= /urldefense.com/v3/__https://www.ietf.org/mailman/li
> > > > >> > stin
> > > > >> > fo/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_ser= cwZMsc0O5N42eENOs4
> > > > >> > l_qd
> > > > >> > sXF0KwZD82cJLDFFNT2WVXWX$
> > > > >> > <http= s://urldefense.com/v3/__https:/www.ietf.org/mailman/li
> > > > >> > stin
> > > > >> > fo/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs= 6vIb_EnBVgyg6boAAW
> > > > >> > 4nrq
> > > > >> > ju8UCLOgiuXc8Y_6sKn2KoAT$>
> > > > >
> > > > > _______________________________________________ > > > > > BIER mailing list
> > > > > BIER@ietf.org<mailto:BIER@ietf.org>
> > > > > https://urld= efense.com/v3/__https://www.ietf.org/mailman/listi
> > > > > nfo/
> > > > > bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42= eENOs4l_qdsX
> > > > > F0Kw
> > > > > ZD82cJLDFFNT2WVXWX$
> > > > > <https://ur= ldefense.com/v3/__https:/www.ietf.org/mailman/listi
> > > > > nfo/
> > > > > bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg= 6boAAW4nrqju
> > > > > 8UCL
> > > > > OgiuXc8Y_6sKn2KoAT$>
> > >
> > > --
> > > ---
> > > tte@cs.fa= u.de<mailto:tte@c= s.fau.de>
> > >
> > > _______________________________________________
> > > BIER mailing list
> > > BIER@ietf= ..org<mailto:BIER= @ietf.org>
> > > https://urldefense.= com/v3/__https://www.ietf.org/mailman/listinfo/
> > > bier
> > > __;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0= KwZD82
> > > cJLD
> > > FFNT2WVXWX$
> > > <https://urldefen= se.com/v3/__https:/www.ietf.org/mailman/listinfo/
> > > bier
> > > __;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8U= CLOgiu
> > > Xc8Y
> > > _6sKn2KoAT$>
> >
> > --
> > ---
> > tte@cs.fau.de<= /a>
>
> --
> ---
> tte@cs.fau.de >
> _______________________________________________
> BIER mailing list
> BIER@ietf.org > https://urldefense.com/v3= /__https://www.ietf.org/mailman/listinfo/bier
> __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx4=
> 1_jWV3YUA6D$

--
---
tte@cs.fau.de

_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ietf.org/mailman/listinfo/bier
_______________________________________________
BIER mailing list
BIER@ietf.org
https://www.ietf.org/mailman/listinfo/bier
--0000000000005b301a059f16f57b-- From nobody Fri Feb 21 10:45:56 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45508120026 for ; Fri, 21 Feb 2020 10:45:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 BY1xp8ZRn398 for ; Fri, 21 Feb 2020 10:45:51 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 137E912021C for ; Fri, 21 Feb 2020 10:45:51 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 6B5FA54804D; Fri, 21 Feb 2020 19:45:42 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5FAF2440040; Fri, 21 Feb 2020 19:45:42 +0100 (CET) Date: Fri, 21 Feb 2020 19:45:42 +0100 From: Toerless Eckert To: Loa Andersson Cc: Lou Berger , gjshep@gmail.com, "Jeffrey (Zhaohui) Zhang" , "bier@ietf.org" Message-ID: <20200221184542.GA20521@faui48f.informatik.uni-erlangen.de> References: <11ab30da-8701-b491-6162-5a69aa9d6965@labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 18:45:55 -0000 Hi Loa, On Fri, Feb 21, 2020 at 12:25:46PM +0800, Loa Andersson wrote: > Authors, working group, > > Inline plz. [lou's text...] > chair hat off > > Personally I agree with Lou, plz add the resource allocation. > > chair hat on > > mpls wg chairs discussed this, and it is our opinion that this document > should have been at lest flagged in mpls and teas, preferably a cross > wg review should have been organized. The BIER-TE architecture was broadly disseminated @IETF101 with presentations adjusted to the specific WG audience to both TEAS and DetNet. I also posted a draft about the bier-te framework architecture that ultimately was meant to go into TEAS and describe for example how bandwidth resource allocation would happen on a controller in the same way as it would for example for SR. I apologize for not having gone to MPLS, but before 101 i asked around and was told TEAS was the appropriate place. nobody brought up a suggestion to go to MPLS. Note that we did have other WGs/chairs interested in BIER-TE reach out to BIER-WG by themselves (e.g.: from Roll). I think the people working in SR and having an interest in multicast for example are well aware of BIER/BIER-TE too. This is just WG last call, not IETF last call, so i'd certainly be happy to come @107 to your WG and present on BIER-TE. Let me know. BIER-TE was from the beginning designed to be the variation of BIER to support TE, but not the same all-in-one signaling that e.g.: RSVP-TE is. If you understand the technology, i think it's clear why the path engineering and resource management are two orthogonal components of a modular solution. [ And we all know what happened to RSVP-TE (all-in-one) when the mayority of users didn't leverage it's resource allocation functionality. ] As you are probably not subscribed BIER mailing list, let me append at the bottom the reply i sent to Lou and the list. Pls. read the new section in the doc, and let me know if you have any further questions. Cheers Toerless --- Thanks a lot, Lou [ Would have been nice if you could have commented a bit earlier. But i can understand how a few years is not enough time ;-P (actually no kidding, i really can.) ] Originally i had planned to address the explanations you are missing in this doc in the BIER-TE traffic engineering framework document, for which i had written the -00 version and presented at TEAS WG, IETF101, but given how we first wanted to get BIER-TE out as RFC, i let that expire, and in hindsight it's certainly useful to have a short section summarizing this in the BIER-TE RFC itself: So, I just pushed -06 of the draft to address your concerns with additional explanations. Summary below, diff here: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-bier-te-arch-05.txt&url2=https://tools.ietf.org/id/draft-ietf-bier-te-arch-06.txt - Title changed from "Traffic Engineering for..." to "Path Engineering for...", but kept name BIER-TE (see below). - Added section 1.1 explaining how BIER-TE relates to traffic engineering, naming use-cases where its for example beneficial standalone and and what it could be combined with for more comprehensive TE solutions, but also stating that those integrations are outside the scope of this document. - changed "traffic engineering" term in the whole doc to "path engineering", where appropriate. - Unrelated to you, there was one leftover fix from ietf106 review to rename BIER-TE Controller Host to just BIER-TE Controller Wrt to naming: The mayority of customers i talked to only used RSVP-TE for path engineering, and not for anything more. Several didn't even know it can do bandwidth reservation. Nobody knew it could do latency guarantees, because nobody knows an implementation that supports that. [All reasons btw. why replacing RSVP-TE with SR happened in the industry.] In any case, the name BIER-TE was selected to reduce confusion with customers, not to maximize naming correctness in IETF. Something like "BIER-PE" (Path Engineering) would have probably confused more than it would have helped. Think of the justification for the name BIER-TE not as "all you need to do TE", but "the variation of BIER to support TE". Wrt to SR: SR can actually NOT do the same as BIER-TE. It has no stateless multicast. All the SR options do really require that you set up multicast trees with e.g.: replication-SIDs that together form the equivalent of a multicast tree, like you would have built with RSVP-TE. Except that the signaling how to build the tree is left for someone else, like PCECC. (AFAIK, i may not be on top of all details). In BIER-TE, there is no such per-tree state on transit nodes. Instead of a 256 bit bitstring in BIER-TE think of a header with up to 256 SIDs (e.g.: 128 bit per SID in SRv6). That would be the SR equivalent of BIER-TE. Just a bit less ( ;-) ) less efficient on the wire than BIER-TE and extremely harder to parse. Cheers Toerless On Wed, Feb 19, 2020 at 06:38:38PM -0500, Lou Berger wrote: > Hi, > >     I have no issue or objection to the mechanisms being defined in this > document as much as they go, but I was quite disappointed that despite the > name of the document and use of 'bier-te'  to see that the document doesn't > define any traffic engineering support, at least as far as the term has been > used in IETF RFCs.  In particular it totally lacks any discussion of > resources usage and/or allocation.  What it currently describes certainly > provides good and useful path/traffic steering that can be used to support > policy-based routing.  Basically it does the same as what is defined by > draft-ietf-spring-segment-routing-policy. > > I personally (not speaking for the related WGs that I chair) would prefer to > see this document be revised  to include resource allocation that would > allow BIER-TE to support TE usage such as DetNet.  Barring such an addition, > I'm against publication of this document as is and I think the document > should be recast and renamed to be aligned with the SR example, i.e., BIER > routing policy (or path steering). > > Lou > > On 2/18/20 3:45 PM, Greg Shepherd wrote: > > Thanks Toerless and Jeffrey > > > > https://datatracker.ietf.org/doc/draft-ietf-bier-te-arch/ > > > > One more week of WGLC. Please read the latest rev and respond to this > > thread w/wo support. > > > > Chairs > > (Shep) > > > > > > On Tue, Feb 18, 2020 at 12:07 PM Jeffrey (Zhaohui) Zhang > > > > wrote: > > > > Hi Toerless, > > > > Thanks! > > I support moving this to the next stage. > > > > Jeffrey > > > > On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote: > > > Thanks Jeff > > > > > > I have now pushed out -05 with the answers and hopefully > > resolution to > > > your points in email below.  Biggest addition was a section about > > > reuse of BPs (without DNR) which came out of the confusion i > > think the > > > reuse in the ECMP example raised. I was afraid so far to explan > > that > > > as it may not be easy to absorb and ultimately is stuff only > > > controller developers need to understand, but hopefully useful. > > > And then of course the summary of BP optimizatins you asked for > > > > > > Diff from last version i sent you: > > > > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: > > > **Araw.githubusercontent.com > > *toerless*bier-te-arch*master*draft-ietf-b > > > ier-te-arch-05.1.txt&url2=http:**Atools.ietf.org > > *id*draft-ietf-bier-te > > > > > -arch-05.txt__;Ly8vLy8vLy8vLy8!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzH > > > OCr0fZkLPbgg3CPNu0PyrWsrFx41_jWX2At8V-$ > > > > > > full -04 -> 05 diff: > > > > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=http:* > > > *Atools.ietf.org > > *id*draft-ietf-bier-te-arch-04.txt&url2=http:**Atools. > > > ietf.org > > *id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk > > > !VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx41_jWancpziv$ > > > > > > Comments inline below. > > > > > > Cheers > > >     toerless > > > > > > On Mon, Oct 28, 2019 at 07:52:59PM +0000, Jeffrey (Zhaohui) > > Zhang wrote: > > > > I Thought u-turn is the most simple comparison leaf vs. > > non-leaf BFR. > > > > > > > > Zzh> The text in the email is seriously misaligned. Looking at > > the picture in the diff link, while you gave a U-turn example, > > though even if BFER2 is not connected to BFR2  but only connected > > to BFER1 (hence no U-turn), then BFER1 is still not a leaf BFER I > > suppose. That's why I said the first sentence of the above > > paragraph is enough to define Leaf BFER while the example itself > > is actually not needed. > > > > > > Argh... ok, had to fix two words, BFIR->BFER and left-hand -> > > right-hand: > > > > > > Consider how redundant disjoint traffic can reach BFER1/BFER2 in > > above > > > picture: When BFER1/BFER2 are Non-Leaf BFER as shown on the > > right hand > > > side, one traffic copy would be forwarded to BFER1 from BFR1, > > but the > > > other one could only reach BFER1 via BFER2, which makes BFER2 a > > > non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forwarding > > > traffic to BFER2 > > > > > > > Zzh> Additionally, in left part of the picture you added, if > > some failure leads to BFR2 to be only reachable via BFER1, then > > BFER1 is no longer a leaf BFER. > > > > > > Added sentence: > > > > > > Note that the BFER in the left hand picture are only > > guaranteed to > > > be leaf-BFR by fitting routing configuration that prohibits transit > > > traffic to pass through a PE, which is commonly applied in these > > > topologies. > > > > > > > I assume you don't reassign BPs when links go up and down. > > > > > > I didn't want to discuss that option in this document. Its > > obviously > > > perfectly feasible, but be yet a big amount of text (especially the > > > considerations how to do this make-before-break. Future doc. > > > > > > > > but subsequent polarization example confuses me. It seems > > that BP 0:6 is assigned to the routed adjacency BFR10 (which is > > actually talked about in Section 4.8). > > > > > > > > Section 4.7 does not mention "routed" at all, so there are no > > routed adjacencies at all used in 4.7. So i am not sure what you > > are confused about. > > > > > > > > Zzh> "The BIFT of each BFR are only populated with BPs that > > are adjacent to the BFR in the BIER-TE topology". > > > > > > Correct text from the introduction. Ok. > > > > > > > Zzh> Since the same 0:6 is in BIFTS of BFR1/BFR2/BFR3 (and I > > suppose in BFR4~BFR9 as well even though not drawn), I assumed > > it's for the "MP2P" routed adjacency to R10; though I then ruled > > that out - but I don't know what 0:6 represent now on BFR1, BFR2, > > and BFR3. > > > > > > Ah. Ok. I thought i could strip down the example to show only the > > > adjacencies relevant to the following discusion, but seemingly this > > > can introduce the confusion you have. > > > > > > So i completed the example with the BP assignment acoss all > > nodes, but > > > added text pointing to a new section further down to discuss the > > > re-use of BP for which thi picture is also an example. > > > > > > (check out the diff, new reuse text to long to copy inline). > > > > > > > The whole purpose of the ECMP BPs is of course to save bits, > > otherwise we'd give each link a separate BP, which would be 6 BP > > to reach to BFR4...BFR7 from BFR1. > > > > > > > > Zzh> The trouble I am having is that the same 0:6 is assigned > > to different things and it's present on all BFR1/BFR2/BFR3. It is > > perhaps an intentional smart design but I have not wrapped my mind > > around it. It's apparently different from the link bundle case, so > > better separate it out and elaborate it (including the DNR flag > > that might be needed here - If the packet arrives on BFR1 with > > 0:6, would the BP reset when it is sent to BFR2/3)? > > > > > > Yes, there was the bug of reusing BP 0:6 across sequential BFR > > along > > > the path, but now the example correctly reuses separate BP at > > > different stages of the paths (BP 0:6 on BFR1, BP 0:7 on > > BFR2/BFR3) and so on. > > > > > > Thanks! > > > > > > > > 4.8.  Routed adjacencies > > > > > > > > > > If I understand it correctly, there is a BP assigned to > > L1/L2/L3 > > > > > respectively (p2p link), and then there are BPs assigned to > > MP2P tunnels (routed adjacency from every BFR) to the L1/L2/L3 > > interface addresses and loopback addresses on BFR2/3. > > > > > > > > Ok that wasn't quite the read i expected. Let me clarify the > > text/picture: > > > > > > > >                    ............... > > > >          ...BFR1--...           ...--L1-- BFR2... > > > >                   ... .Routers. ...--L2--/ > > > >          ...BFR4--...           ...------ BFR3... > > > >                    ...............         | > > > >                                           LO > > > >                     Network Area 1 > > > > > > > > Assume the requirement in the above picture is to explicitly > > steer traffic flows that have arrived at BFR1 or BFR4 via a > > shortest path in the routing underlay "network area 1" to one of > > the following three next segments: (1) BFR2 via link L1, (2) BFR2 > > via link L2, (3) via BFR3. > > > > > > > > To achieve this, both BFR1 and BFR4 are set up with a > > forward_routed adjacency BitPosition towards an address of BFR2 on > > link L1, another forward_routed BitPosition towards an address of > > BFR2 on link L2 and a third forward_routed Bitposition towards a > > node address LO of BFR3. > > > > > > > > Does this clear ip the confusion ? > > > > > > > > Zzh> The picture is badly misaligned. I'll wait till 4.7 > > questions are cleared. > > > > > > Ok. > > > > > > > > If BFR2/3 are also BFERs, then they additionally will have > > BFER BPs. > > > > > On BFR1/4, the BIFT entries for the MP2P BPs for the > > L1/L2/L3/loopback interface addresses of BFR2/3 will use > > forward_routed(interface/loopback address). For a packet to be > > decapsulated on a BFER, there is a need for both the BFER BP and > > another BP (p2p/lan/hub-spoke/routed-adjacency) in the packet (the > > former is for decapsulation and the latter is for getting it there). > > > > > > > > This is not discussed in this section, but you are right - unless > > > > BFR2 or BFR3 is a leaf BFR. In that case, it would just > > leverage the one shared "leaf-BFR" BP, so they do not need a > > per-BFER BP for local_decap(). > > > > > > > > Zzh> Right - shared leaf-BFR BP but still need that BP (the > > key is that we need a BP to get packet to a BFER and then a BP for > > decapsulation). > > > > > > You got it. > > > > > > > > If that???s the case, it???s worth point the above out. > > > > > > > > Hmm... The logic of BFER BPs is totally independent of the > > logic of forward_routed adjacency, so i would worry that repeating > > the explanation of BFER BPs would conflate the forward_routed > > explanation. > > > > > > > > Zzh> It's just that this is a place where all kinds of BPs are > > used so it's good to have a summary (could be a subsection 4.9). > > > > > > Yes, added such a summary. Pls. check. > > > > > > > > Actually, the reason that I thought this is MP2P is that 0:6 > > is present on R1, R2, and R3 (and more I assume) in Figure 12, but > > now I think it can???t be MP2P (so it is not correct to have 0:6 > > present on those routers ??? only the p2p tunnel head/tail should > > have the BP present in the BIFT). The reason is that if it were > > MP2P, any router getting a copy will send it to the endpoint of > > the routed adjacency, causing lots of duplicates. > > > > > > > > > > Am I getting this correct? > > > > > > > > I think you are still explaining from the misunderstsanding > > that the ECMP explanations where about routed adjacencies. > > > > > > > > I have now expanded the somewhat terse text in the BIFT table > > pictures, to make it clear that the ECMP is across multipe > > forward_connected adjacencies in the examples. For example, first > > BIFT picture: > > > > > > > >   BIFT entry in BFR1: > > > > > >  ------------------------------------------------------------------ > > > >   | Index |  Adjacencies                  | > > > > > >  ================================================================== > > > >   | 0:6   |  ECMP({forward_connected(L1, BFR2),                 | > > > >   |       |        forward_connected(L2, BFR2),                 | > > > >   |       |        forward_connected(L3, BFR2)}, seed)        > >      | > > > > > >  ------------------------------------------------------------------ > > > > > > > > Of course, an ECMP adjacency can be across any type of > > adjacencies, but all the text/explanations used forward_connected, > > and now the pictures show that explicitly. > > > > > > > > Zzh> I can understand the multi-link case, but the multi-hop > > ECMP case (from BFR1 towards BFR10) is confusing me. It would help > > to give an example how it can be used, WITHOUT worrying about > > polarization. > > > > > > Please check -05 text that has the full set of BIFT listed now: > > > > > > There is  really nothing nothing unique in multi-hop ECMP for > > BIER-TE > > > that we do not also have in any other ECMP, except the > > conclusion that > > > we want to support fast HW hash mechanisms AND allow the > > controller to > > > set up non-polarized multi-hop ECMP AND be able to precalculate > > paths. > > > Hence the specification of ECMP adjacencies to have a controller > > > configurable seed. > > > > > > Btw: The picture is maybe unnecessarily large because i've used > > it for > > > 20 years to explain the same polarization issue for unicast vs > > > multicast, and for multicast only BFR10...BFR4 are relevant > > (ECMP of > > > the PIM/mLDP joins), whereas for unicast/BIER only > > > BFR1...BFR7 are relevant. But being symmetric, the picture makes it > > > clear its the same problem. > > > > > > > >    To inhibit looping in the face of such physical > > misconfiguration, > > > > >    only forward_connected adjacencies are permitted to have > > DNR set, and > > > > >    the link layer destination address of the adjacency > > (e.g.  MAC > > > > >    address) protects against closing the loop.  Link layers > > without port > > > > >    unique link layer addresses should not be used with the > > DNR flag set. > > > > > > > > > > It???s not clear how link layer address helps? > > > > > > > > I have expanded this to > > > > "link layer port unique unicast destination address" > > > > > > > > Aka: MPLS or ethernet have unique link layer destination > > destination addresses (label or destination MAC). If you think > > about incorrectly plugged HDLC links (such as old T1/T3/... > > links), they only have 2 generic addresses, if i remember 1 or 3 > > in the HDLC frame. So when you misplug one of those p2p cables > > wrong, the packets would be incrrectly received by the wrong > > receiver node and then DNR could cause persistent loops only > > solved by TTL. > > > > > > > > Zzh> "Consider in the ring picture that link L4 from BFR3 is > > plugged into the L1 interface of BFRa" - still not sure how > > label/mac helps here. I suppose the ring topology is > > discovered/verified by the control plane and when the miscalling > > happens then the ring will not include the BFR1/BFR2 part and BFR3 > > will not have the DNR set? If ring discovery/varication is not > > done then perhaps we should point out that RPF based on link layer > > address is needed - the key is RPF (which needs unique link layer > > address)? > > > > > > Forget RPF. BIER(-TE) has no RPF (issues). Its just like > > unicast. RPF > > > is just a problem for receiver originated joins like in > > PIM/mLDP, but > > > not unicast/bier(-te)/RSVP-TE. > > > > > > Forward_connected is just like a unicast subnet adjacency to a > > direct > > > neighbor: Interface and L2 addresss of the destination. > > > > > > The controller (could be a human) "assumes" a particular physicial > > > topology, from telemetry/knowledge/whatever. It then calculates the > > > desired BIER-TE topology and pushes it down. This topology is > > meant to > > > be loop free of course wrt to the configured adjacencies. > > > In this BIER-TE topology, BFR3 will have a BP with the > > > forward_connected(L4, MAC-of-BFR2) adjacency. > > > > > > If the cable connecting to L4 is miswired, then BFR3 would still > > send > > > the packets to the MAC address of BFR2, but given how the cable > > > connects to some other node, these packets will be discarded by > > that > > > node. because they're just L2 unicast packets. > > > > > > I think this is equally true when we have normal BIER/MPLS enacp. > > > Those packets too are addressed to the unicast MAC address of the > > > neighbor. > > > > > > Now, if/when he controller recognizes that the physical topology > > has > > > changed, thats a completely different story and not addressed here. > > > Given how we assumed this was a cabling mistake, the controller > > would > > > probably only complain about the miswiring to operations but be > > happy > > > that the forwarding plane just makes packets fail instead of > > loop. If > > > this was a planned change process, then it will be similarily > > > convoluted as it would today be with rewiring cables in an > > > SR-MPLS/SRv6 topology and updating SIDs. > > > > > > > > Because the forwarding is different from BIER forwarding > > (because of [1] above), we might as well introduce an optimization > > here ??? for each BIFT, calculate the F-BM of the BIFT itself (the > > logical ???or??? of all the BPs presented in this BIFT) and then > > use (packet->bitstring & BIFT.F-BM) as the input to > > GetFirst/NextBitPosition(). That should skip many bits. > > > > > > > > Right. But i explicitly removed those optimizations (i had > > them in older draft versions) because the whole idea of this > > picture is solely the comparison with figure 4 of RFC8279. > > > > > > > > Zzh> I think it's worth point that optimization out; you can > > mark it optional if you want to emphasize the similarity to BIER > > forwarding, but since BIER forwarding does do the maskoff step, it > > is very efficient while BIER-TE forwarding does not it the maskoff > > step so this optimization is important. > > > > > > Ok. I simplified the text comparison BIER/BIER-TE wrt. to the FBM > > > rules [1] and [2] and added following paragraph: > > > > > > In BIER, the order of BPs impacts the result of forwarding > > because of [1]. > > > In BIER-TE, forwarding is not impacted by the order of BPs. It is > > > therefore possible to further optimize forwarding than in BIER. For > > > example parallelizing forwarding across multiple FPE cores or > > > distributed linecards does only need to examine an arbitrary > > subset of > > > BP and not evaluate the dependency between BPs. > > > > > > > >    The following pseudocode is comprehensive: > > > > > > > > > > The above sentence reads a bit strange (or lacks some segue). > > > > > > > > I hope not, but maybe best left to a native english speaker > > (RFC-editor). > > > > > > > > The first (RFC8279) pseudocode was simplified. The second one > > is comprehensive. If not comprehensive, whats a good opposite of > > simplified ? > > > > > > > > Zzh> Perhaps "The above simplified pseudocode is elaborated > > further as following"? > > > > Zzh> Jeffrey > > > > > > Done. > > > > > > Thanks a lot. > > > > > > > > > > > > > > > ________________________________________ > > > > > From: BIER [bier-bounces@ietf.org > > > >] > > > > > on behalf of Toerless Eckert [tte@cs.fau.de > > >] > > > > > Sent: Tuesday, July 09, 2019 23:38 > > > > > To: Mike McBride > > > > > Cc: Greg Shepherd; BIER WG; Pascal Thubert (pthubert) > > > > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch > > > > > > > > > > Thanks, Mike > > > > > > > > > > The authors also reviewed the document and concluded that it > > was > > > > > really hard to get into the document context because of too > > many > > > > > forward dependencies. We tried to fix this by adding two > > hopefully > > > > > good & basic examples into the Introduction section and > > using them > > > > > to also add a better definition of the term "BIER-TE > > Topology" in the Introduction. > > > > > Hopefully this makes readin the rest of te document smoother. > > > > > > > > > > Also improved text of Abstract and refined text compariing > > BIER-TE with SR. > > > > > > > > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: > > > > > **Atools.ietf.org > > *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A > > > > > tool > > > > > s.ietf.org > > *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R > > > > > jC81 > > > > > > > c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV_eTUEh > > > > > $ > > > > > > > > > > > **Atools.ietf.org > > *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A > > > > > tool > > > > > s.ietf.org > > *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R > > > > > jC81 > > > > > > > c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sNd1njcX > > > > > $> > > > > > > > > > > Cheers > > > > >     Toerless > > > > > > > > > > On Wed, Jun 26, 2019 at 10:39:36AM -0700, Mike McBride wrote: > > > > > > How about three? I support. > > > > > > mike > > > > > > > > > > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd > > > > >> wrote: > > > > > > > > > > > > > > We cannot take two 'yes' votes and WG consensus. > > > > > > > Please, read and respond. If you don't support, then > > please vote as much publicly right here. > > > > > > > > > > > > > > Thanks, > > > > > > > Greg > > > > > > > > > > > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert > > (pthubert) > > >> wrote: > > > > > > >> > > > > > > >> Support: > > > > > > >> > > > > > > >> I see great value in deterministic networks as well as > > IOT (with RPL). > > > > > > >> > > > > > > >> All the best, > > > > > > >> > > > > > > >> Pascal > > > > > > >> > > > > > > >> > -----Original Message----- > > > > > > >> > From: BIER > > > > > > >> > > > >> On > > > > > > >> > Behalf Of Toerless Eckert > > > > > > >> > Sent: mardi 4 juin 2019 02:03 > > > > > > >> > To: Greg Shepherd > > > > > > >> > > > >> > > > > > > >> > Cc: BIER WG > >> > > > > > > >> > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch > > > > > > >> > > > > > > > >> > +1 > > > > > > >> > Obviously support as co-author. > > > > > > >> > > > > > > > >> > On Wed, May 29, 2019 at 12:41:26PM -0700, Greg > > Shepherd wrote: > > > > > > >> > > Please read and respond to this thread w/ or w/o > > support. > > > > > > >> > > > > > > > > >> > > > > https://urldefense.com/v3/__https://datatracker..ietf.org > > > > > > >> > > /doc > > > > > > >> > > > > /draft-ietf-bier-te-arch/__;!8WoA6RjC81c!XvH4AAxfrDjFoK_s > > > > > > >> > > ercw ZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV9eClBj$ > > > > > > >> > > > > > > > > > >> > > doc/ > > > > > > >> > > > > draft-ietf-bier-te-arch/__;!8WoA6RjC81c!UBTGvWWpMHyeiSanx > > > > > > >> > > s6vI b_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sD40kmtH$> > > > > > > >> > > > > > > > > >> > > Vote ends 5 June 2019. > > > > > > >> > > > > > > > > >> > > Thanks, > > > > > > >> > > Shep > > > > > > >> > > (chairs) > > > > > > >> > > > > > > > >> > > _______________________________________________ > > > > > > >> > > BIER mailing list > > > > > > >> > > BIER@ietf.org > > > > > > > > > >> > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/ > > > > > > >> > > list > > > > > > >> > > > > info/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eE > > > > > > >> > > NOs4 l_qdsXF0KwZD82cJLDFFNT2WVXWX$ > > > > > > >> > > > > > > > > > >> > > list > > > > > > >> > > > > info/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6b > > > > > > >> > > oAAW 4nrqju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > > > >> > > > > > > > >> > _______________________________________________ > > > > > > >> > BIER mailing list > > > > > > >> > BIER@ietf.org > > > > > > > > > >> > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/li > > > > > > >> > stin > > > > > > >> > > > fo/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4 > > > > > > >> > l_qd > > > > > > >> > sXF0KwZD82cJLDFFNT2WVXWX$ > > > > > > >> > > > > > > > > >> > stin > > > > > > >> > > > fo/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW > > > > > > >> > 4nrq > > > > > > >> > ju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > > > > > > > > > > > _______________________________________________ > > > > > > > BIER mailing list > > > > > > > BIER@ietf.org > > > > > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listi > > > > > > > nfo/ > > > > > > > > > bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsX > > > > > > > F0Kw > > > > > > > ZD82cJLDFFNT2WVXWX$ > > > > > > > > > > > > > > > nfo/ > > > > > > > > > bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju > > > > > > > 8UCL > > > > > > > OgiuXc8Y_6sKn2KoAT$> > > > > > > > > > > -- > > > > > --- > > > > > tte@cs.fau.de > > > > > > > > > > > > _______________________________________________ > > > > > BIER mailing list > > > > > BIER@ietf.org > > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ > > > > > bier > > > > > > > __;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82 > > > > > cJLD > > > > > FFNT2WVXWX$ > > > > > > > > > > > bier > > > > > > > __;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiu > > > > > Xc8Y > > > > > _6sKn2KoAT$> > > > > > > > > -- > > > > --- > > > > tte@cs.fau.de > > > > > > -- > > > --- > > > tte@cs.fau.de > > > > > > _______________________________________________ > > > BIER mailing list > > > BIER@ietf.org > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier > > > > > __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx4 > > > 1_jWV3YUA6D$ > > > > -- > > --- > > tte@cs.fau.de > > > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org > > https://www.ietf.org/mailman/listinfo/bier > > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier -- --- tte@cs.fau.de From nobody Fri Feb 21 12:02:15 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3519B1200F3 for ; Fri, 21 Feb 2020 12:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 8TIllT-j3fZQ for ; Fri, 21 Feb 2020 12:01:55 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) (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 B6C8A12012D for ; Fri, 21 Feb 2020 12:01:55 -0800 (PST) Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id EB36B140626 for ; Fri, 21 Feb 2020 13:01:52 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id 5EUijA08uBs3j5EUijDSWZ; Fri, 21 Feb 2020 13:01:52 -0700 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.3 cv=dLqIZtRb c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=xqWC_Br6kY4A:10:nop_ipv6 a=IkcTkHD0fZMA:10:nop_charset_1 a=l697ptgUJYAA:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=48vgC7mUAAAA:8 a=uherdBYGAAAA:8 a=bt8Zh30PAAAA:8 a=pGLkceISAAAA:8 a=AUd_NHdVAAAA:8 a=QHQU03FHx2yEElXkFSAA:9 a=B5hBAgc58UlTHLSK:21 a=StsxXpeOni_gv66F:21 a=8fRrfuomfFB89nqZ:21 a=QEXdDO2ut3YA:10:nop_charset_2 a=w1C3t2QeGrPiZgrLijVG:22 a=Ef4yma5cpRUEJWN9UqBm:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=59OLCLSJ6T26bJoS/n/sCiMikro351r0zftP+M+dB8w=; b=iley2SEL9vcvJ6Z/Odys5yGAe1 FIKBoCTdRkWFmMzMndogGBdyi5xS+8P5iLXWZzpm414um0jno/oO2IeBm8+sAYhHL7ZUAkQmL+b5+ yAKW0C+Twjnm/qoUspVzRGATm; Received: from [127.0.0.1] (port=36229 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1j5EUi-000i6O-GI; Fri, 21 Feb 2020 13:01:52 -0700 To: Toerless Eckert Cc: gjshep@gmail.com, "Jeffrey (Zhaohui) Zhang" , "bier@ietf.org" References: <11ab30da-8701-b491-6162-5a69aa9d6965@labn.net> <20200220035620.GA42520@faui48f.informatik.uni-erlangen.de> From: Lou Berger Message-ID: Date: Fri, 21 Feb 2020 15:01:51 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <20200220035620.GA42520@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 127.0.0.1 X-Source-L: Yes X-Exim-ID: 1j5EUi-000i6O-GI X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:36229 X-Source-Auth: lberger@labn.net X-Email-Count: 4 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 20:02:14 -0000 Hi Toerless , Thanks for the super quick response On 2/19/2020 10:56 PM, Toerless Eckert wrote: > Thanks a lot, Lou > > [ Would have been nice if you could have commented a bit earlier. > But i can understand how a few years is not enough time ;-P > (actually no kidding, i really can.) ] I raised this as an issue last march - at both the Chair and AD level.  I thought I made the same point to you privately after one the presentations at IETF101, but if you don't remember it, I accept that I didn't. > Originally i had planned to address the explanations you are missing > in this doc in the BIER-TE traffic engineering framework document, > for which i had written the -00 version and presented at TEAS WG, IETF101, > but given how we first wanted to get BIER-TE out as RFC, i let that > expire, and in hindsight it's certainly useful to have a short > section summarizing this in the BIER-TE RFC itself: Well that document seems like a fine place to describe how BIER-RP (routing policy) can be used to deliver BIER-TE. > So, I just pushed -06 of the draft to address your concerns with > additional explanations. > Summary below, diff here: > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-bier-te-arch-05.txt&url2=https://tools.ietf.org/id/draft-ietf-bier-te-arch-06.txt > > - Title changed from "Traffic Engineering for..." to "Path Engineering > for...", Do we really need a new term to describe here?  I find zero (0) instances of Path Engineering in any RFC.  Routing policy (and policy-based routing) on the other hand are fairly well established terms in the industry.  I think this just sows seeds for future confusion on this topic. Why is "routing policy" not good enough for what is being defining here?  I again point out, this is the term being used in SPRING for basically the equivalent function/purpose. (Yes the forwarding mechanism is different, but the objective is not.) > but kept name BIER-TE (see below). > > - Added section 1.1 explaining how BIER-TE relates to traffic > engineering, naming use-cases where its for example beneficial standalone and > and what it could be combined with for more comprehensive TE solutions, > but also stating that those integrations are outside the scope of this > document. So this section seems to miss what has been going on in traffic engineering / TEAS for the last 5+ years (i.e., controller-based TE approaches)  and then goes on describe path steering  in a very brief way.  I read this as saying that BIER *could* do TE in the future and *can* support routing policy and path steering today. > - changed "traffic engineering" term in the whole doc to "path engineering", > where appropriate. While this is appreciated, I'm not sure it's helpful.  As stated above, I think the introduction of the new PE term is confusing as the continued use of BIER-TE. > - Unrelated to you, there was one leftover fix from ietf106 review to rename BIER-TE > Controller Host to just BIER-TE Controller > > Wrt to naming: > > The mayority of customers i talked to only used RSVP-TE for path > engineering, and not for anything more. Several didn't even know it > can do bandwidth reservation. Nobody knew it could do latency > guarantees, because nobody knows an implementation that supports that. > [All reasons btw. why replacing RSVP-TE with SR happened in the industry.] While I'm going to avoid getting into product differentiators and marketing, you're not mentioning that even those products and customers who didn't support/use per LSP queuing, did available resource bookkeeping and even admission control. > In any case, the name BIER-TE was selected to reduce confusion > with customers, not to maximize naming correctness in IETF. umm, the IETF is a standards body not an industry marketing forum, so I'm unclear how this point helps your argument.  It seems that you're saying that if we call it BIER-TE we can market it in place of existing IETF TE solutions - even though it doesn't yet have the TE capability covered in draft-eckert-teas-bier-te-framework. Assuming I'm reading it right, this just confirms to me that the current work needs to be renamed and that draft-eckert-teas-bier-te-framework will define BIER-TE. > Something like "BIER-PE" (Path Engineering) would have > probably confused more than it would have helped. Think > of the justification for the name BIER-TE not as > "all you need to do TE", but "the variation of BIER to support TE". I'm sorry to say, I'm left more confused by this response and doc update than I was before it. > Wrt to SR: > > SR can actually NOT do the same as BIER-TE. It has no stateless multicast. My point wasn't that BIER=SR, but rather both deliver support for path steering and policy based routing. Thanks for being responsive! Lou > All the SR options do really require that you set up multicast trees with > e.g.: replication-SIDs that together form the equivalent of a > multicast tree, like you would have built with RSVP-TE. Except that > the signaling how to build the tree is left for someone else, like > PCECC. (AFAIK, i may not be on top of all details). In BIER-TE, > there is no such per-tree state on transit nodes. > > Instead of a 256 bit bitstring in BIER-TE think of a header with up to 256 SIDs > (e.g.: 128 bit per SID in SRv6). That would be the SR equivalent of BIER-TE. > Just a bit less ( ;-) ) less efficient on the wire than BIER-TE and extremely > harder to parse. > > Cheers > Toerless > > > On Wed, Feb 19, 2020 at 06:38:38PM -0500, Lou Berger wrote: >> Hi, >> >>     I have no issue or objection to the mechanisms being defined in this >> document as much as they go, but I was quite disappointed that despite the >> name of the document and use of 'bier-te'  to see that the document doesn't >> define any traffic engineering support, at least as far as the term has been >> used in IETF RFCs.  In particular it totally lacks any discussion of >> resources usage and/or allocation.  What it currently describes certainly >> provides good and useful path/traffic steering that can be used to support >> policy-based routing.  Basically it does the same as what is defined by >> draft-ietf-spring-segment-routing-policy. >> >> I personally (not speaking for the related WGs that I chair) would prefer to >> see this document be revised  to include resource allocation that would >> allow BIER-TE to support TE usage such as DetNet.  Barring such an addition, >> I'm against publication of this document as is and I think the document >> should be recast and renamed to be aligned with the SR example, i.e., BIER >> routing policy (or path steering). >> >> Lou >> >> On 2/18/20 3:45 PM, Greg Shepherd wrote: >>> Thanks Toerless and Jeffrey >>> >>> https://datatracker.ietf.org/doc/draft-ietf-bier-te-arch/ >>> >>> One more week of WGLC. Please read the latest rev and respond to this >>> thread w/wo support. >>> >>> Chairs >>> (Shep) >>> >>> >>> On Tue, Feb 18, 2020 at 12:07 PM Jeffrey (Zhaohui) Zhang >>> >> > wrote: >>> >>> Hi Toerless, >>> >>> Thanks! >>> I support moving this to the next stage. >>> >>> Jeffrey >>> >>> On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote: >>> > Thanks Jeff >>> > >>> > I have now pushed out -05 with the answers and hopefully >>> resolution to >>> > your points in email below.  Biggest addition was a section about >>> > reuse of BPs (without DNR) which came out of the confusion i >>> think the >>> > reuse in the ECMP example raised. I was afraid so far to explan >>> that >>> > as it may not be easy to absorb and ultimately is stuff only >>> > controller developers need to understand, but hopefully useful. >>> > And then of course the summary of BP optimizatins you asked for >>> > >>> > Diff from last version i sent you: >>> > >>> > >>> https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: >>> > **Araw.githubusercontent.com >>> *toerless*bier-te-arch*master*draft-ietf-b >>> > ier-te-arch-05.1.txt&url2=http:**Atools.ietf.org >>> *id*draft-ietf-bier-te >>> > >>> -arch-05.txt__;Ly8vLy8vLy8vLy8!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzH >>> > OCr0fZkLPbgg3CPNu0PyrWsrFx41_jWX2At8V-$ >>> > >>> > full -04 -> 05 diff: >>> > >>> > >>> https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=http:* >>> > *Atools.ietf.org >>> *id*draft-ietf-bier-te-arch-04.txt&url2=http:**Atools. >>> > ietf.org >>> *id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk >>> > !VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx41_jWancpziv$ >>> > >>> > Comments inline below. >>> > >>> > Cheers >>> >     toerless >>> > >>> > On Mon, Oct 28, 2019 at 07:52:59PM +0000, Jeffrey (Zhaohui) >>> Zhang wrote: >>> > > I Thought u-turn is the most simple comparison leaf vs. >>> non-leaf BFR. >>> > > >>> > > Zzh> The text in the email is seriously misaligned. Looking at >>> the picture in the diff link, while you gave a U-turn example, >>> though even if BFER2 is not connected to BFR2  but only connected >>> to BFER1 (hence no U-turn), then BFER1 is still not a leaf BFER I >>> suppose. That's why I said the first sentence of the above >>> paragraph is enough to define Leaf BFER while the example itself >>> is actually not needed. >>> > >>> > Argh... ok, had to fix two words, BFIR->BFER and left-hand -> >>> right-hand: >>> > >>> > Consider how redundant disjoint traffic can reach BFER1/BFER2 in >>> above >>> > picture: When BFER1/BFER2 are Non-Leaf BFER as shown on the >>> right hand >>> > side, one traffic copy would be forwarded to BFER1 from BFR1, >>> but the >>> > other one could only reach BFER1 via BFER2, which makes BFER2 a >>> > non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forwarding >>> > traffic to BFER2 >>> > >>> > > Zzh> Additionally, in left part of the picture you added, if >>> some failure leads to BFR2 to be only reachable via BFER1, then >>> BFER1 is no longer a leaf BFER. >>> > >>> > Added sentence: >>> > >>> > Note that the BFER in the left hand picture are only >>> guaranteed to >>> > be leaf-BFR by fitting routing configuration that prohibits transit >>> > traffic to pass through a PE, which is commonly applied in these >>> > topologies. >>> > >>> > > I assume you don't reassign BPs when links go up and down. >>> > >>> > I didn't want to discuss that option in this document. Its >>> obviously >>> > perfectly feasible, but be yet a big amount of text (especially the >>> > considerations how to do this make-before-break. Future doc. >>> > >>> > > > but subsequent polarization example confuses me. It seems >>> that BP 0:6 is assigned to the routed adjacency BFR10 (which is >>> actually talked about in Section 4.8). >>> > > >>> > > Section 4.7 does not mention "routed" at all, so there are no >>> routed adjacencies at all used in 4.7. So i am not sure what you >>> are confused about. >>> > > >>> > > Zzh> "The BIFT of each BFR are only populated with BPs that >>> are adjacent to the BFR in the BIER-TE topology". >>> > >>> > Correct text from the introduction. Ok. >>> > >>> > > Zzh> Since the same 0:6 is in BIFTS of BFR1/BFR2/BFR3 (and I >>> suppose in BFR4~BFR9 as well even though not drawn), I assumed >>> it's for the "MP2P" routed adjacency to R10; though I then ruled >>> that out - but I don't know what 0:6 represent now on BFR1, BFR2, >>> and BFR3. >>> > >>> > Ah. Ok. I thought i could strip down the example to show only the >>> > adjacencies relevant to the following discusion, but seemingly this >>> > can introduce the confusion you have. >>> > >>> > So i completed the example with the BP assignment acoss all >>> nodes, but >>> > added text pointing to a new section further down to discuss the >>> > re-use of BP for which thi picture is also an example. >>> > >>> > (check out the diff, new reuse text to long to copy inline). >>> > >>> > > The whole purpose of the ECMP BPs is of course to save bits, >>> otherwise we'd give each link a separate BP, which would be 6 BP >>> to reach to BFR4...BFR7 from BFR1. >>> > > >>> > > Zzh> The trouble I am having is that the same 0:6 is assigned >>> to different things and it's present on all BFR1/BFR2/BFR3. It is >>> perhaps an intentional smart design but I have not wrapped my mind >>> around it. It's apparently different from the link bundle case, so >>> better separate it out and elaborate it (including the DNR flag >>> that might be needed here - If the packet arrives on BFR1 with >>> 0:6, would the BP reset when it is sent to BFR2/3)? >>> > >>> > Yes, there was the bug of reusing BP 0:6 across sequential BFR >>> along >>> > the path, but now the example correctly reuses separate BP at >>> > different stages of the paths (BP 0:6 on BFR1, BP 0:7 on >>> BFR2/BFR3) and so on. >>> > >>> > Thanks! >>> > >>> > > > 4.8.  Routed adjacencies >>> > > > >>> > > > If I understand it correctly, there is a BP assigned to >>> L1/L2/L3 >>> > > > respectively (p2p link), and then there are BPs assigned to >>> MP2P tunnels (routed adjacency from every BFR) to the L1/L2/L3 >>> interface addresses and loopback addresses on BFR2/3. >>> > > >>> > > Ok that wasn't quite the read i expected. Let me clarify the >>> text/picture: >>> > > >>> > >                    ............... >>> > >          ...BFR1--...           ...--L1-- BFR2... >>> > >                   ... .Routers. ...--L2--/ >>> > >          ...BFR4--...           ...------ BFR3... >>> > >                    ...............         | >>> > >                                           LO >>> > >                     Network Area 1 >>> > > >>> > > Assume the requirement in the above picture is to explicitly >>> steer traffic flows that have arrived at BFR1 or BFR4 via a >>> shortest path in the routing underlay "network area 1" to one of >>> the following three next segments: (1) BFR2 via link L1, (2) BFR2 >>> via link L2, (3) via BFR3. >>> > > >>> > > To achieve this, both BFR1 and BFR4 are set up with a >>> forward_routed adjacency BitPosition towards an address of BFR2 on >>> link L1, another forward_routed BitPosition towards an address of >>> BFR2 on link L2 and a third forward_routed Bitposition towards a >>> node address LO of BFR3. >>> > > >>> > > Does this clear ip the confusion ? >>> > > >>> > > Zzh> The picture is badly misaligned. I'll wait till 4.7 >>> questions are cleared. >>> > >>> > Ok. >>> > >>> > > > If BFR2/3 are also BFERs, then they additionally will have >>> BFER BPs. >>> > > > On BFR1/4, the BIFT entries for the MP2P BPs for the >>> L1/L2/L3/loopback interface addresses of BFR2/3 will use >>> forward_routed(interface/loopback address). For a packet to be >>> decapsulated on a BFER, there is a need for both the BFER BP and >>> another BP (p2p/lan/hub-spoke/routed-adjacency) in the packet (the >>> former is for decapsulation and the latter is for getting it there). >>> > > >>> > > This is not discussed in this section, but you are right - unless >>> > > BFR2 or BFR3 is a leaf BFR. In that case, it would just >>> leverage the one shared "leaf-BFR" BP, so they do not need a >>> per-BFER BP for local_decap(). >>> > > >>> > > Zzh> Right - shared leaf-BFR BP but still need that BP (the >>> key is that we need a BP to get packet to a BFER and then a BP for >>> decapsulation). >>> > >>> > You got it. >>> > >>> > > > If that???s the case, it???s worth point the above out. >>> > > >>> > > Hmm... The logic of BFER BPs is totally independent of the >>> logic of forward_routed adjacency, so i would worry that repeating >>> the explanation of BFER BPs would conflate the forward_routed >>> explanation. >>> > > >>> > > Zzh> It's just that this is a place where all kinds of BPs are >>> used so it's good to have a summary (could be a subsection 4.9). >>> > >>> > Yes, added such a summary. Pls. check. >>> > >>> > > > Actually, the reason that I thought this is MP2P is that 0:6 >>> is present on R1, R2, and R3 (and more I assume) in Figure 12, but >>> now I think it can???t be MP2P (so it is not correct to have 0:6 >>> present on those routers ??? only the p2p tunnel head/tail should >>> have the BP present in the BIFT). The reason is that if it were >>> MP2P, any router getting a copy will send it to the endpoint of >>> the routed adjacency, causing lots of duplicates. >>> > > > >>> > > > Am I getting this correct? >>> > > >>> > > I think you are still explaining from the misunderstsanding >>> that the ECMP explanations where about routed adjacencies. >>> > > >>> > > I have now expanded the somewhat terse text in the BIFT table >>> pictures, to make it clear that the ECMP is across multipe >>> forward_connected adjacencies in the examples. For example, first >>> BIFT picture: >>> > > >>> > >   BIFT entry in BFR1: >>> > > >>>  ------------------------------------------------------------------ >>> > >   | Index |  Adjacencies                  | >>> > > >>>  ================================================================== >>> > >   | 0:6   |  ECMP({forward_connected(L1, BFR2),                 | >>> > >   |       |        forward_connected(L2, BFR2),                 | >>> > >   |       |        forward_connected(L3, BFR2)}, seed) >>>      | >>> > > >>>  ------------------------------------------------------------------ >>> > > >>> > > Of course, an ECMP adjacency can be across any type of >>> adjacencies, but all the text/explanations used forward_connected, >>> and now the pictures show that explicitly. >>> > > >>> > > Zzh> I can understand the multi-link case, but the multi-hop >>> ECMP case (from BFR1 towards BFR10) is confusing me. It would help >>> to give an example how it can be used, WITHOUT worrying about >>> polarization. >>> > >>> > Please check -05 text that has the full set of BIFT listed now: >>> > >>> > There is  really nothing nothing unique in multi-hop ECMP for >>> BIER-TE >>> > that we do not also have in any other ECMP, except the >>> conclusion that >>> > we want to support fast HW hash mechanisms AND allow the >>> controller to >>> > set up non-polarized multi-hop ECMP AND be able to precalculate >>> paths. >>> > Hence the specification of ECMP adjacencies to have a controller >>> > configurable seed. >>> > >>> > Btw: The picture is maybe unnecessarily large because i've used >>> it for >>> > 20 years to explain the same polarization issue for unicast vs >>> > multicast, and for multicast only BFR10...BFR4 are relevant >>> (ECMP of >>> > the PIM/mLDP joins), whereas for unicast/BIER only >>> > BFR1...BFR7 are relevant. But being symmetric, the picture makes it >>> > clear its the same problem. >>> > >>> > > >    To inhibit looping in the face of such physical >>> misconfiguration, >>> > > >    only forward_connected adjacencies are permitted to have >>> DNR set, and >>> > > >    the link layer destination address of the adjacency >>> (e.g.  MAC >>> > > >    address) protects against closing the loop.  Link layers >>> without port >>> > > >    unique link layer addresses should not be used with the >>> DNR flag set. >>> > > > >>> > > > It???s not clear how link layer address helps? >>> > > >>> > > I have expanded this to >>> > > "link layer port unique unicast destination address" >>> > > >>> > > Aka: MPLS or ethernet have unique link layer destination >>> destination addresses (label or destination MAC). If you think >>> about incorrectly plugged HDLC links (such as old T1/T3/... >>> links), they only have 2 generic addresses, if i remember 1 or 3 >>> in the HDLC frame. So when you misplug one of those p2p cables >>> wrong, the packets would be incrrectly received by the wrong >>> receiver node and then DNR could cause persistent loops only >>> solved by TTL. >>> > > >>> > > Zzh> "Consider in the ring picture that link L4 from BFR3 is >>> plugged into the L1 interface of BFRa" - still not sure how >>> label/mac helps here. I suppose the ring topology is >>> discovered/verified by the control plane and when the miscalling >>> happens then the ring will not include the BFR1/BFR2 part and BFR3 >>> will not have the DNR set? If ring discovery/varication is not >>> done then perhaps we should point out that RPF based on link layer >>> address is needed - the key is RPF (which needs unique link layer >>> address)? >>> > >>> > Forget RPF. BIER(-TE) has no RPF (issues). Its just like >>> unicast. RPF >>> > is just a problem for receiver originated joins like in >>> PIM/mLDP, but >>> > not unicast/bier(-te)/RSVP-TE. >>> > >>> > Forward_connected is just like a unicast subnet adjacency to a >>> direct >>> > neighbor: Interface and L2 addresss of the destination. >>> > >>> > The controller (could be a human) "assumes" a particular physicial >>> > topology, from telemetry/knowledge/whatever. It then calculates the >>> > desired BIER-TE topology and pushes it down. This topology is >>> meant to >>> > be loop free of course wrt to the configured adjacencies. >>> > In this BIER-TE topology, BFR3 will have a BP with the >>> > forward_connected(L4, MAC-of-BFR2) adjacency. >>> > >>> > If the cable connecting to L4 is miswired, then BFR3 would still >>> send >>> > the packets to the MAC address of BFR2, but given how the cable >>> > connects to some other node, these packets will be discarded by >>> that >>> > node. because they're just L2 unicast packets. >>> > >>> > I think this is equally true when we have normal BIER/MPLS enacp. >>> > Those packets too are addressed to the unicast MAC address of the >>> > neighbor. >>> > >>> > Now, if/when he controller recognizes that the physical topology >>> has >>> > changed, thats a completely different story and not addressed here. >>> > Given how we assumed this was a cabling mistake, the controller >>> would >>> > probably only complain about the miswiring to operations but be >>> happy >>> > that the forwarding plane just makes packets fail instead of >>> loop. If >>> > this was a planned change process, then it will be similarily >>> > convoluted as it would today be with rewiring cables in an >>> > SR-MPLS/SRv6 topology and updating SIDs. >>> > >>> > > > Because the forwarding is different from BIER forwarding >>> (because of [1] above), we might as well introduce an optimization >>> here ??? for each BIFT, calculate the F-BM of the BIFT itself (the >>> logical ???or??? of all the BPs presented in this BIFT) and then >>> use (packet->bitstring & BIFT.F-BM) as the input to >>> GetFirst/NextBitPosition(). That should skip many bits. >>> > > >>> > > Right. But i explicitly removed those optimizations (i had >>> them in older draft versions) because the whole idea of this >>> picture is solely the comparison with figure 4 of RFC8279. >>> > > >>> > > Zzh> I think it's worth point that optimization out; you can >>> mark it optional if you want to emphasize the similarity to BIER >>> forwarding, but since BIER forwarding does do the maskoff step, it >>> is very efficient while BIER-TE forwarding does not it the maskoff >>> step so this optimization is important. >>> > >>> > Ok. I simplified the text comparison BIER/BIER-TE wrt. to the FBM >>> > rules [1] and [2] and added following paragraph: >>> > >>> > In BIER, the order of BPs impacts the result of forwarding >>> because of [1]. >>> > In BIER-TE, forwarding is not impacted by the order of BPs. It is >>> > therefore possible to further optimize forwarding than in BIER. For >>> > example parallelizing forwarding across multiple FPE cores or >>> > distributed linecards does only need to examine an arbitrary >>> subset of >>> > BP and not evaluate the dependency between BPs. >>> > >>> > > >    The following pseudocode is comprehensive: >>> > > > >>> > > > The above sentence reads a bit strange (or lacks some segue). >>> > > >>> > > I hope not, but maybe best left to a native english speaker >>> (RFC-editor). >>> > > >>> > > The first (RFC8279) pseudocode was simplified. The second one >>> is comprehensive. If not comprehensive, whats a good opposite of >>> simplified ? >>> > > >>> > > Zzh> Perhaps "The above simplified pseudocode is elaborated >>> further as following"? >>> > > Zzh> Jeffrey >>> > >>> > Done. >>> > >>> > Thanks a lot. >>> > >>> > >>> > > >>> > > > ________________________________________ >>> > > > From: BIER [bier-bounces@ietf.org >>> >> >] >>> > > > on behalf of Toerless Eckert [tte@cs.fau.de >>> >] >>> > > > Sent: Tuesday, July 09, 2019 23:38 >>> > > > To: Mike McBride >>> > > > Cc: Greg Shepherd; BIER WG; Pascal Thubert (pthubert) >>> > > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch >>> > > > >>> > > > Thanks, Mike >>> > > > >>> > > > The authors also reviewed the document and concluded that it >>> was >>> > > > really hard to get into the document context because of too >>> many >>> > > > forward dependencies. We tried to fix this by adding two >>> hopefully >>> > > > good & basic examples into the Introduction section and >>> using them >>> > > > to also add a better definition of the term "BIER-TE >>> Topology" in the Introduction. >>> > > > Hopefully this makes readin the rest of te document smoother. >>> > > > >>> > > > Also improved text of Abstract and refined text compariing >>> BIER-TE with SR. >>> > > > >>> > > > >>> https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: >>> > > > **Atools.ietf.org >>> *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A >>> > > > tool >>> > > > s.ietf.org >>> *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R >>> > > > jC81 >>> > > > >>> c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV_eTUEh >>> > > > $ >>> > > > >>> >> > > > **Atools.ietf.org >>> *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A >>> > > > tool >>> > > > s.ietf.org >>> *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R >>> > > > jC81 >>> > > > >>> c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sNd1njcX >>> > > > $> >>> > > > >>> > > > Cheers >>> > > >     Toerless >>> > > > >>> > > > On Wed, Jun 26, 2019 at 10:39:36AM -0700, Mike McBride wrote: >>> > > > > How about three? I support. >>> > > > > mike >>> > > > > >>> > > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd >>> >> >> >> wrote: >>> > > > > > >>> > > > > > We cannot take two 'yes' votes and WG consensus. >>> > > > > > Please, read and respond. If you don't support, then >>> please vote as much publicly right here. >>> > > > > > >>> > > > > > Thanks, >>> > > > > > Greg >>> > > > > > >>> > > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert >>> (pthubert) >> >> >> wrote: >>> > > > > >> >>> > > > > >> Support: >>> > > > > >> >>> > > > > >> I see great value in deterministic networks as well as >>> IOT (with RPL). >>> > > > > >> >>> > > > > >> All the best, >>> > > > > >> >>> > > > > >> Pascal >>> > > > > >> >>> > > > > >> > -----Original Message----- >>> > > > > >> > From: BIER >>> > > > > >> > >> >> >> On >>> > > > > >> > Behalf Of Toerless Eckert >>> > > > > >> > Sent: mardi 4 juin 2019 02:03 >>> > > > > >> > To: Greg Shepherd >>> > > > > >> > >> >> >> >>> > > > > >> > Cc: BIER WG >> >> >>> > > > > >> > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch >>> > > > > >> > >>> > > > > >> > +1 >>> > > > > >> > Obviously support as co-author. >>> > > > > >> > >>> > > > > >> > On Wed, May 29, 2019 at 12:41:26PM -0700, Greg >>> Shepherd wrote: >>> > > > > >> > > Please read and respond to this thread w/ or w/o >>> support. >>> > > > > >> > > >>> > > > > >> > > >>> https://urldefense.com/v3/__https://datatracker..ietf.org >>> > > > > >> > > /doc >>> > > > > >> > > >>> /draft-ietf-bier-te-arch/__;!8WoA6RjC81c!XvH4AAxfrDjFoK_s >>> > > > > >> > > ercw ZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV9eClBj$ >>> > > > > >> > > >>> >> > > > > >> > > doc/ >>> > > > > >> > > >>> draft-ietf-bier-te-arch/__;!8WoA6RjC81c!UBTGvWWpMHyeiSanx >>> > > > > >> > > s6vI b_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sD40kmtH$> >>> > > > > >> > > >>> > > > > >> > > Vote ends 5 June 2019. >>> > > > > >> > > >>> > > > > >> > > Thanks, >>> > > > > >> > > Shep >>> > > > > >> > > (chairs) >>> > > > > >> > >>> > > > > >> > > _______________________________________________ >>> > > > > >> > > BIER mailing list >>> > > > > >> > > BIER@ietf.org >>> > >>> > > > > >> > > >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/ >>> > > > > >> > > list >>> > > > > >> > > >>> info/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eE >>> > > > > >> > > NOs4 l_qdsXF0KwZD82cJLDFFNT2WVXWX$ >>> > > > > >> > > >>> >> > > > > >> > > list >>> > > > > >> > > >>> info/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6b >>> > > > > >> > > oAAW 4nrqju8UCLOgiuXc8Y_6sKn2KoAT$> >>> > > > > >> > >>> > > > > >> > _______________________________________________ >>> > > > > >> > BIER mailing list >>> > > > > >> > BIER@ietf.org >>> > >>> > > > > >> > >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/li >>> > > > > >> > stin >>> > > > > >> > >>> fo/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4 >>> > > > > >> > l_qd >>> > > > > >> > sXF0KwZD82cJLDFFNT2WVXWX$ >>> > > > > >> > >>> >> > > > > >> > stin >>> > > > > >> > >>> fo/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW >>> > > > > >> > 4nrq >>> > > > > >> > ju8UCLOgiuXc8Y_6sKn2KoAT$> >>> > > > > > >>> > > > > > _______________________________________________ >>> > > > > > BIER mailing list >>> > > > > > BIER@ietf.org >>> > >>> > > > > > >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listi >>> > > > > > nfo/ >>> > > > > > >>> bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsX >>> > > > > > F0Kw >>> > > > > > ZD82cJLDFFNT2WVXWX$ >>> > > > > > >>> >> > > > > > nfo/ >>> > > > > > >>> bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju >>> > > > > > 8UCL >>> > > > > > OgiuXc8Y_6sKn2KoAT$> >>> > > > >>> > > > -- >>> > > > --- >>> > > > tte@cs.fau.de >> > >>> > > > >>> > > > _______________________________________________ >>> > > > BIER mailing list >>> > > > BIER@ietf.org >> > >>> > > > >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ >>> > > > bier >>> > > > >>> __;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82 >>> > > > cJLD >>> > > > FFNT2WVXWX$ >>> > > > >>> >> > > > bier >>> > > > >>> __;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiu >>> > > > Xc8Y >>> > > > _6sKn2KoAT$> >>> > > >>> > > -- >>> > > --- >>> > > tte@cs.fau.de >>> > >>> > -- >>> > --- >>> > tte@cs.fau.de >>> > >>> > _______________________________________________ >>> > BIER mailing list >>> > BIER@ietf.org >>> > >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier >>> > >>> __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx4 >>> > 1_jWV3YUA6D$ >>> >>> -- >>> --- >>> tte@cs.fau.de >>> >>> _______________________________________________ >>> BIER mailing list >>> BIER@ietf.org >>> https://www.ietf.org/mailman/listinfo/bier >>> >> _______________________________________________ >> BIER mailing list >> BIER@ietf.org >> https://www.ietf.org/mailman/listinfo/bier > From nobody Fri Feb 21 18:17:10 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F6912006B; Fri, 21 Feb 2020 18:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 lTZTV8SmtE6n; Fri, 21 Feb 2020 18:17:05 -0800 (PST) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7007120048; Fri, 21 Feb 2020 18:17:04 -0800 (PST) Received: from mxct.zte.com.cn (unknown [192.168.164.217]) by Forcepoint Email with ESMTPS id 8FFBE6D5CCA105D660E7; Sat, 22 Feb 2020 10:17:02 +0800 (CST) Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id 7331EE42A72341DA63ED; Sat, 22 Feb 2020 10:17:02 +0800 (CST) Received: from njxapp01.zte.com.cn ([10.41.132.200]) by mse-fl2.zte.com.cn with SMTP id 01M2Gluj027204; Sat, 22 Feb 2020 10:16:48 +0800 (GMT-8) (envelope-from zhang.zheng@zte.com.cn) Received: from mapi (njxapp05[null]) by mapi (Zmail) with MAPI id mid203; Sat, 22 Feb 2020 10:16:47 +0800 (CST) Date: Sat, 22 Feb 2020 10:16:47 +0800 (CST) X-Zmail-TransId: 2afd5e508f0fb4494d26 X-Mailer: Zmail v1.0 Message-ID: <202002221016475538682@zte.com.cn> Mime-Version: 1.0 From: To: Cc: Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-fl2.zte.com.cn 01M2Gluj027204 Archived-At: Subject: [Bier] =?utf-8?q?Call_for_BIER_presentation_items_in_IETF107=23?= X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2020 02:17:08 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksDQoNCg0KDQoNCg0KDQpXZSBoYXZlIHJlcXVlc3RlZCBhIDIgaG91ciBCSUVSIFdHIG1lZXRp bmcgc2xvdCBhdCBJRVRGMTA3IyBpbiBWYW5jb3V2ZXIuIA0KDQoNCklmIHlvdSB3b3VsZCBsaWtl IHRvIHByZXNlbnQgYXQgdGhhdCBtZWV0aW5nLCBwbGVhc2Ugc2VuZCBhIHJlcXVlc3Qgd2l0aCAi UHJlc2VudGF0aW9uIGRyYWZ0LCB0aGUgYW1vdW50IG9mIHRpbWUsIHByZXNlbnRlciIuIA0KDQoN Ckl0IGlzIHBvc3NpYmxlIHRvIHByZXNlbnQgcmVtb3RlbHkgaWYgeW91IGFyZSBub3QgYXR0ZW5k aW5nIHRoZSBtZWV0aW5nLg0KDQoNCg0KDQoNCg0KVGhhbmtzLA0KDQoNClNhbmR5DQoNCg0KKFNl Y3JldGFyeSk= --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZh bWlseTphcmlhbDsiPkhpLDwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6 YXJpYWw7Ij48YnI+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZhbWlseTphcmlh bDsiPldlIGhhdmUgcmVxdWVzdGVkIGEgMiBob3VyIEJJRVIgV0cgbWVldGluZyBzbG90IGF0IElF VEYxMDcjIGluIFZhbmNvdXZlci4mbmJzcDs8L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToxNHB4O2Zv bnQtZmFtaWx5OmFyaWFsOyI+SWYgeW91IHdvdWxkIGxpa2UgdG8gcHJlc2VudCBhdCB0aGF0IG1l ZXRpbmcsIHBsZWFzZSBzZW5kIGEgcmVxdWVzdCB3aXRoICJQcmVzZW50YXRpb24gZHJhZnQsIHRo ZSBhbW91bnQgb2YgdGltZSwgcHJlc2VudGVyIi4mbmJzcDs8L3A+PHAgc3R5bGU9ImZvbnQtc2l6 ZToxNHB4O2ZvbnQtZmFtaWx5OmFyaWFsOyI+SXQgaXMgcG9zc2libGUgdG8gcHJlc2VudCByZW1v dGVseSBpZiB5b3UgYXJlIG5vdCBhdHRlbmRpbmcgdGhlIG1lZXRpbmcuPC9wPjxwIHN0eWxlPSJm b250LXNpemU6MTRweDtmb250LWZhbWlseTphcmlhbDsiPjxicj48L3A+PHAgc3R5bGU9ImZvbnQt c2l6ZToxNHB4O2ZvbnQtZmFtaWx5OmFyaWFsOyI+VGhhbmtzLDwvcD48cCBzdHlsZT0iZm9udC1z aXplOjE0cHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij5TYW5keTwvcD48cCBzdHlsZT0iZm9udC1zaXpl OjE0cHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij4oU2VjcmV0YXJ5KTwvcD48cCBzdHlsZT0iZm9udC1z aXplOjE0cHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij48YnI+PC9wPjwvZGl2Pg== --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Fri Feb 21 19:29:27 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1541200FE; Fri, 21 Feb 2020 19:29:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_RED=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 bQg3QvRsuERS; Fri, 21 Feb 2020 19:29:21 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FFFD12006B; Fri, 21 Feb 2020 19:29:21 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 6E7A9548052; Sat, 22 Feb 2020 04:29:14 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 66D1C440040; Sat, 22 Feb 2020 04:29:14 +0100 (CET) Date: Sat, 22 Feb 2020 04:29:14 +0100 From: Toerless Eckert To: zhang.zheng@zte.com.cn Cc: bier@ietf.org, bier-chairs@ietf.org Message-ID: <20200222032914.GA14025@faui48f.informatik.uni-erlangen.de> References: <202002221016475538682@zte.com.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202002221016475538682@zte.com.cn> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Bier] Call for BIER presentation items in IETF107# X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2020 03:29:26 -0000 bier-te-arch, toerless eckert, 10 min On Sat, Feb 22, 2020 at 10:16:47AM +0800, zhang.zheng@zte.com.cn wrote: > Hi, > > > > > > > We have requested a 2 hour BIER WG meeting slot at IETF107# in Vancouver. > > > If you would like to present at that meeting, please send a request with "Presentation draft, the amount of time, presenter". > > > It is possible to present remotely if you are not attending the meeting. > > > > > > > Thanks, > > > Sandy > > > (Secretary) > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier -- --- tte@cs.fau.de From nobody Sat Feb 22 09:52:59 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6959B3A046A; Sat, 22 Feb 2020 09:52:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 Z0zkfuTiyBvW; Sat, 22 Feb 2020 09:52:57 -0800 (PST) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 B788B3A0474; Sat, 22 Feb 2020 09:52:56 -0800 (PST) Received: by mail-il1-x134.google.com with SMTP id s85so4354285ill.11; Sat, 22 Feb 2020 09:52:56 -0800 (PST) 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=x07CgfN1SdVfSSE6mRXB4EovMeNZjNn9cAM7XJoDjrI=; b=t91STFOzejazvHUDPJxhciO5ZknmUXGDL9+IrFINZvNdAIeRsEUgRojGQMT8VkZDVE /dujOSBOL4UdlwlLmXsfWS+cpkOKh88pTxtjoUId8idcxrfJgyef+8A9xoDbOSuf+Xwz FIsZVrpM7xl3CeDS9NlZEZ2XOrr9J648HjI9Y3sQKW3yFaRVUCpuPZAibHMBHBuaIshU a1cVVibPL4gFOBVUiV4YVx1D0iTSPpJigxjr2idxS8uoY/SsuHsLQl7RVdXPLk+qviTr BMd/UPqXzB0RLghp1LP7Pf/6pDIwUDWAGZwZWLk2i7xqYJkrglXnlTCJUELqDJ9Lkp+a wLhg== 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=x07CgfN1SdVfSSE6mRXB4EovMeNZjNn9cAM7XJoDjrI=; b=P3S5LYA1TDhhXvt1seuOHDab/Cp1PkgMb6szutBcDqCLatfu1nnfWcfwQN+b6pugLe s+yo11tsTh5UElcC0qoySOlHFsKF/ZEIHmxWMqyuQUyvrMx6WehunNZK+VoMoSc4n220 auxEWU8bmr8flqpW9UxuQLe8D/oAvYd1CqUZ5HXS33dPvckDg5q5nLP4zUivJpgcKEW/ Kp9ONqDgvlXSgKom9rOO6bkHFgs/gyLV+XIcTZ1eZTA84NLyIzdiQRwrHN07mMg42ATt DS9g/dlXzLx516L1Q8XFx072CYKpLJvMzGQmeScoXeWcT6KVGd6xdRYsIBGtT8bIPkyF AzyA== X-Gm-Message-State: APjAAAX1T3Q3rBE/45YcRcxJ3kZPU8sBT156OJCJWZpL/EUp2KL3HNGa k+L1MMF5AnpSzYJeaz5xPfrURpH8cGrXyjujBKMrZQ== X-Google-Smtp-Source: APXvYqxhIvtTcPTj+i3hx7JM+4/YyG8xE8j/WCBWngh2F963JIKH4H/OeB8vvEbV3DBtJcW1NL4qtz7wwdvPO31rOtA= X-Received: by 2002:a92:4187:: with SMTP id o129mr44989388ila.239.1582392181889; Sat, 22 Feb 2020 09:23:01 -0800 (PST) MIME-Version: 1.0 References: <202002221016475538682@zte.com.cn> <20200222032914.GA14025@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200222032914.GA14025@faui48f.informatik.uni-erlangen.de> From: Tony Przygienda Date: Sat, 22 Feb 2020 09:22:03 -0800 Message-ID: To: Toerless Eckert Cc: "zhang.zheng" , BIER WG , BIER WG Chairs Content-Type: multipart/alternative; boundary="000000000000e5a43a059f2d6382" Archived-At: Subject: Re: [Bier] Call for BIER presentation items in IETF107# X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Feb 2020 17:52:58 -0000 --000000000000e5a43a059f2d6382 Content-Type: text/plain; charset="UTF-8" Sandy is converging agenda while Greg & me sip well-deserved pinacoladas ;-) On Fri, Feb 21, 2020 at 7:29 PM Toerless Eckert wrote: > bier-te-arch, toerless eckert, 10 min > > On Sat, Feb 22, 2020 at 10:16:47AM +0800, zhang.zheng@zte.com.cn wrote: > > Hi, > > > > > > > > > > > > > > We have requested a 2 hour BIER WG meeting slot at IETF107# in > Vancouver. > > > > > > If you would like to present at that meeting, please send a request with > "Presentation draft, the amount of time, presenter". > > > > > > It is possible to present remotely if you are not attending the meeting. > > > > > > > > > > > > > > Thanks, > > > > > > Sandy > > > > > > (Secretary) > > > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org > > https://www.ietf.org/mailman/listinfo/bier > > > -- > --- > tte@cs.fau.de > --000000000000e5a43a059f2d6382 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sandy is converging agenda while Greg & me sip well-de= served pinacoladas ;-)

On Fri, Feb 21, 2020 at 7:29 PM Toerless Eckert &= lt;tte@cs.fau.de> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">bier-te-arch, toerless eck= ert, 10 min

On Sat, Feb 22, 2020 at 10:16:47AM +0800, zhang.zheng@zte.com.cn wrote:
> Hi,
>
>
>
>
>
>
> We have requested a 2 hour BIER WG meeting slot at IETF107# in Vancouv= er.
>
>
> If you would like to present at that meeting, please send a request wi= th "Presentation draft, the amount of time, presenter".
>
>
> It is possible to present remotely if you are not attending the meetin= g.
>
>
>
>
>
>
> Thanks,
>
>
> Sandy
>
>
> (Secretary)


> _______________________________________________
> BIER mailing list
> BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier


--
---
tte@cs.fau.de
--000000000000e5a43a059f2d6382-- From nobody Mon Feb 24 09:54:24 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED1E3A0FEE for ; Mon, 24 Feb 2020 09:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 9tFGRauACO66 for ; Mon, 24 Feb 2020 09:54:19 -0800 (PST) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 AA3B03A0FBE for ; Mon, 24 Feb 2020 09:54:19 -0800 (PST) Received: by mail-ed1-x533.google.com with SMTP id c7so12943500edu.2 for ; Mon, 24 Feb 2020 09:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to; bh=rcJayVFxXcBBr9dObsg5KRT41ELSw79uFHZcqjkBhd4=; b=R4rWPzgBfWcxsE7jqdSId1yY4d0rzO0yekt41FJD8a5kfcN5b4wV0ks7D73IDtREpb Szjn6jzSGg++6ba3+NTDZhUZLQ9uO4uE4h+r04EeQ/sZcZeuWerTF66AI1Kb5R+X5XBE efxp6Yfjwx0J66biUDILat3N3ZBccL4eZbRRscIp3kq7x98WQxm2WnzBdXFExbPC+Caz JbLO9vfIA0psJhTLBi4PSpxjWolucYUY4YXZgZvgmM+YMc7yPRa+E0xYR/GT4Gj3q3Zv NSMwcm8zwwMA5vNAfdtJQTOVKoYqbyviK4w6KxBJIVF+xdlkMmSXu/ODsh0oli9P2AQr yKhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=rcJayVFxXcBBr9dObsg5KRT41ELSw79uFHZcqjkBhd4=; b=hVV+NlTB9hcowrlSaxPGRWypvthfrz8P6QZ3GYKf6q1DymLeEzs4hV2T/iW3uh9woZ 33WRIgiFpE9XcP3+TTLyyAOuDsZjcm1M0yF8vYMNv+NlJbGQ7c7Cc1TH6CpvnqyJazDM iXG0MiffKNF+y6ueWTyFqubf4AyGsP51LdD4ozr+Y5hJ6G/HrSh4JuXbzJP8FSdUXC1K zOpwE5LP65irldoS1F9tc3jxMXnP8XbupoH6yQGTZaHWNv4HZ4lQ5ke/KxCI/y44GdjT DA9OZqvkueu61VOiLYd1pLz0FhDVjkofkDnxDkyUVIYppmhHkS9iYUFHO8YODnFFj4u9 jLDw== X-Gm-Message-State: APjAAAXm/uaWsHI5XfrE/Up6HkpWkh40VPN1hAEMohkJ4c2TZ2Q8ZSAF Dy+TWH3p3rhR6VvqLwUCxGbtWbYG6PbMap55duFsowXO X-Google-Smtp-Source: APXvYqyfklS7VX+Sxs2rLx2nxHmfzB6BR2oHm4z2DxHki7IWEzDU25oQAsOlpODn1m1ULCT4eIOwLuW+/fzrWbbehh8= X-Received: by 2002:a17:906:9458:: with SMTP id z24mr48739411ejx.155.1582566857683; Mon, 24 Feb 2020 09:54:17 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 24 Feb 2020 09:54:17 -0800 From: Alvaro Retana MIME-Version: 1.0 Date: Mon, 24 Feb 2020 09:54:17 -0800 Message-ID: To: bier@ietf.org Content-Type: multipart/alternative; boundary="00000000000062b879059f560f0e" Archived-At: Subject: [Bier] Fwd: Last Call: (Multipoint Alternate Marking method for passive and hybrid performance monitoring) to Experimental RFC X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 17:54:23 -0000 --00000000000062b879059f560f0e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FYI=E2=80=A6 This document is related to draft-ietf-bier-pmmm-oam. If you have comments, please send them to the authors and cc last-call@ietf.org. Thanks! Alvaro. On February 21, 2020 at 3:45:59 PM, The IESG (iesg-secretary@ietf.org) wrote: The IESG has received a request from the IP Performance Measurement WG (ippm) to consider the following document: - 'Multipoint Alternate Marking method for passive and hybrid performance monitoring' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-03-06. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Alternate Marking method, as presented in RFC 8321 [RFC8321], can be applied only to point-to-point flows because it assumes that all the packets of the flow measured on one node are measured again by a single second node. This document aims to generalize and expand this methodology to measure any kind of unicast flows, whose packets can follow several different paths in the network, in wider terms a multipoint-to-multipoint network. For this reason the technique here described is called Multipoint Alternate Marking. Some definitions here introduced extend the scope of RFC 5644 [RFC5644] in the context of alternate marking schema. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ippm-multipoint-alt-mark/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ippm-multipoint-alt-mark/ballot= / The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/4010/ https://datatracker.ietf.org/ipr/3035/ https://datatracker.ietf.org/ipr/3110/ _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --00000000000062b879059f560f0e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
FYI=E2=80=A6

This document is related to=C2=A0draft-ietf-bier-pmmm-= oam.

If you have co= mments, please send them to the authors and cc last-call@ietf.org.

Thanks!

Alvaro.
=

On February 21, 2020 at 3:45:59 PM, = The IESG (iesg-secretary@ietf.or= g) wrote:

<= div>

The IESG has received a request from the IP Performance Measurement WG = (ippm)
to consider the following document: - 'Multipoint Alternate Marking= method
for passive and hybrid performance
monitoring'
<draft-ietf-ippm-multipoint-alt-mark-05.txt> as Experimental RF= C

The IESG plans to make a decision in the next few weeks, and solicits f= inal
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing li= sts by 2020-03-06. Exceptionally, comments may
be sent to iesg@ietf.org instead. = In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


The Alternate Marking method, as presented in RFC 8321 [RFC8321], ca= n
be applied only to point-to-point flows because it assumes that all
the packets of the flow measured on one node are measured again by a
single second node. This document aims to generalize and expand thi= s
methodology to measure any kind of unicast flows, whose packets can
follow several different paths in the network, in wider terms a
multipoint-to-multipoint network. For this reason the technique her= e
described is called Multipoint Alternate Marking. Some definitions
here introduced extend the scope of RFC 5644 [RFC5644] in the contex= t
of alternate marking schema.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ippm-multipoint-alt-= mark/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-ippm-multipoi= nt-alt-mark/ballot/

The following IPR Declarations may be related to this I-D:

https://datatrack= er.ietf.org/ipr/4010/
https://datatrack= er.ietf.org/ipr/3035/
https://datatrack= er.ietf.org/ipr/3110/





_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https:/= /www.ietf.org/mailman/listinfo/ietf-announce
<= /body> --00000000000062b879059f560f0e-- From nobody Mon Feb 24 17:57:33 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8301A3A17C4 for ; Mon, 24 Feb 2020 17:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 o4kfX14ivKEO for ; Mon, 24 Feb 2020 17:57:26 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C44A03A17BC for ; Mon, 24 Feb 2020 17:57:25 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B56E9548048; Tue, 25 Feb 2020 02:57:18 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id A7E29440040; Tue, 25 Feb 2020 02:57:18 +0100 (CET) Date: Tue, 25 Feb 2020 02:57:18 +0100 From: Toerless Eckert To: Lou Berger Cc: gjshep@gmail.com, "bier@ietf.org" , "Jeffrey (Zhaohui) Zhang" Message-ID: <20200225015718.GC20521@faui48f.informatik.uni-erlangen.de> References: <11ab30da-8701-b491-6162-5a69aa9d6965@labn.net> <20200220035620.GA42520@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 01:57:31 -0000 Hi Lou, round 2. Here is the github pre-version of -07 of the draft: https://raw.githubusercontent.com/toerless/bier-te-arch/62378f618299307349a934fc6ad78e1af9e16771/draft-ietf-bier-te-arch.txt Diff: http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-bier-te-arch-06.txt&url2=https://raw.githubusercontent.com/toerless/bier-te-arch/62378f618299307349a934fc6ad78e1af9e16771/draft-ietf-bier-te-arch.txt I would appreciate if you could try to partition your opinions into things you think MUST be solved before passing the document to IESG (for IETF/IESG review) and those issues that could then be solved when it is in IETF/IESG review. For example, i think a final choice of name could be something that shouldn't block the document to take this step. If this goes along into IETF107, it would be great if you could find the time to be at the BIER-WG meeting. Summary of changes: 1. Changed abbreviation BIER-TE to BIER-PE, otherwise we can not unconfuse readers of the difference between BIER-PE and BIER-TE. Relationship: BIER-TE = (BIER with steering: BIER-PE or othre) plus resource allocation mechanisms, and this document only describes BIER-PE. 2. Removed all use of the term "path engineering" from the (explanatory) text, replaced with path / tree steering or policy in the text (like RFC8402). 3. In result, "Path Engineering" is now solely a name for the mechanism. In the same way as SR introduced "Segment Routing" as a name, but explains what it does with the terms "steering" and "policy". 4. I think a unique new term not already used in before is helpful because what BIER-PE does is quite unique and new. And reusing an existing term always brings out more people wanting to argue about the accuracy of how their pre-existing term is applied. I hope we can have a deterministic, short latency decision mechanism for the term. After we've decided on the term, its easy to update the doc again with that new term (%s/PE/XXX/g). I'll throw "Tree Steering Bitstrings" (BIER-TSB) into the ring. [The main issue with name change now is that we've gotten some followup work such as YANG model that also refers to BIER-TE meaning BIER-PE, so that would also need to change name. See below for my reply to that naming change you said you suggested .] 5. I also refined the section 1.1 that was introduced in -06 to mention e.g.: PCE. Specific answers to the mail thread below. Cheers Toerless On Fri, Feb 21, 2020 at 03:01:51PM -0500, Lou Berger wrote: > > [ Would have been nice if you could have commented a bit earlier. > > But i can understand how a few years is not enough time ;-P > > (actually no kidding, i really can.) ] > > I raised this as an issue last march - at both the Chair and AD level.  I > thought I made the same point to you privately after one the presentations > at IETF101, but if you don't remember it, I accept that I didn't. Did you include the authors ? I could not find any email about this. Also no forwarded emails from AD/chairs i could find. If you still have a copy, pls. PM. This is annoying... I do not remember naming issue discussed after IETF101, but i am sure i was preoccupied with technical issues and might not have given it too much thought back then. Of course there was a lot of time since IETF101 to bring up the naming point again... > Well that document seems like a fine place to describe how BIER-RP (routing > policy) can be used to deliver BIER-TE. > [...] > > Do we really need a new term to describe here?  I find zero (0) instances of > Path Engineering in any RFC.  Routing policy (and policy-based routing) on > the other hand are fairly well established terms in the industry.  I think > this just sows seeds for future confusion on this topic. > > Why is "routing policy" not good enough for what is being defining here?  I > again point out, this is the term being used in SPRING for basically the > equivalent function/purpose. (Yes the forwarding mechanism is different, but > the objective is not.) SPRING did establish new unique name/terminologies, like "Segment". As said above, i think its best we do the samegiven how unique this is. Looking at rfc8402, "steering" and "policy" are used in verbal explanations, without providing specific terminology for them, so i did follow that example too. > > but kept name BIER-TE (see below). > > > > - Added section 1.1 explaining how BIER-TE relates to traffic > > engineering, naming use-cases where its for example beneficial standalone and > > and what it could be combined with for more comprehensive TE solutions, > > but also stating that those integrations are outside the scope of this > > document. > > So this section seems to miss what has been going on in traffic engineering > / TEAS for the last 5+ years (i.e., controller-based TE approaches) I don't think that is a correct assessment. BIER-PE itself requires a controller to calculate paths / trees. With or without other traffic engineering components. That component is called the BIER-PE controller and has been in the draft forever. The new section 1.1 added in response to your review relates that BIER-TE controller to an overall TE controller, using the PCE example and refrerence to it. There is really nothing more that a BIER-WG document could or should do. What this document intended to support is whats necessary and sufficient to get the forwarding plane implemented/standardized. Everything else is for independent followup work in TEAS IMHO, such as reviving the framwork draft. >  and then goes on describe path steering  in a very brief way.  I read this as > saying that BIER *could* do TE in the future and *can* support routing > policy and path steering today. Even stronger: BIER-PE is always meant to ONLY do that (steering), any additional TE functions wold come from independent other components. And simple examples for that are given in section 1.1. > > - changed "traffic engineering" term in the whole doc to "path engineering", > > where appropriate. > > While this is appreciated, I'm not sure it's helpful.  As stated above, I > think the introduction of the new PE term is confusing as the continued use > of BIER-TE. See above. We can certainly not use "BIER-TE" to mean two different things, so i hope that concern is resolved. > > The mayority of customers i talked to only used RSVP-TE for path > > engineering, and not for anything more. Several didn't even know it > > can do bandwidth reservation. Nobody knew it could do latency > > guarantees, because nobody knows an implementation that supports that. > > [All reasons btw. why replacing RSVP-TE with SR happened in the industry.] > > While I'm going to avoid getting into product differentiators and marketing, > you're not mentioning that even those products and customers who didn't > support/use per LSP queuing, did available resource bookkeeping and even > admission control. I think the point is mood now (given how we'll change the name BIER-TE to a better term). But maybe to better explain: We started calling this TE so customers would easier understand that this is intended to give them what they actually use RSVP-TE for (Traffic Steering), and not necessarily all that RSVP-TE could do beyond that. A central controller is assumed to exist in BIER-PE too. Given how SR also shows how you can be successful in deployment without betting on 'TE' name recognition, i have no quarrels in changing the name. As said above, its motly a question of finding the best term and changing the followup works names too. > > In any case, the name BIER-TE was selected to reduce confusion > > with customers, not to maximize naming correctness in IETF. > > umm, the IETF is a standards body not an industry marketing forum, so I'm > unclear how this point helps your argument. It's not am argument or justification, just an explanation. Not only to you, but also the WG. > It seems that you're saying > that if we call it BIER-TE we can market it in place of existing IETF TE > solutions - even though it doesn't yet have the TE capability covered in > draft-eckert-teas-bier-te-framework. ... > Assuming I'm reading it right, this just confirms to me that the current > work needs to be renamed and that draft-eckert-teas-bier-te-framework will > define BIER-TE. Yes. BIER-TE could btw. rely on BIER-PE or BIER + other path steering (e.g.: flex-algos), so BIER-PE is only one option for the path-steering options for BIER-TE. > My point wasn't that BIER=SR, but rather both deliver support for path > steering and policy based routing. Yepp, i hope we're in violent agreement. Cheers Toerless > Thanks for being responsive! > > Lou > > > All the SR options do really require that you set up multicast trees with > > e.g.: replication-SIDs that together form the equivalent of a > > multicast tree, like you would have built with RSVP-TE. Except that > > the signaling how to build the tree is left for someone else, like > > PCECC. (AFAIK, i may not be on top of all details). In BIER-TE, > > there is no such per-tree state on transit nodes. > > > > Instead of a 256 bit bitstring in BIER-TE think of a header with up to 256 SIDs > > (e.g.: 128 bit per SID in SRv6). That would be the SR equivalent of BIER-TE. > > Just a bit less ( ;-) ) less efficient on the wire than BIER-TE and extremely > > harder to parse. > > > > Cheers > > Toerless > > > > > > On Wed, Feb 19, 2020 at 06:38:38PM -0500, Lou Berger wrote: > > > Hi, > > > > > >     I have no issue or objection to the mechanisms being defined in this > > > document as much as they go, but I was quite disappointed that despite the > > > name of the document and use of 'bier-te'  to see that the document doesn't > > > define any traffic engineering support, at least as far as the term has been > > > used in IETF RFCs.  In particular it totally lacks any discussion of > > > resources usage and/or allocation.  What it currently describes certainly > > > provides good and useful path/traffic steering that can be used to support > > > policy-based routing.  Basically it does the same as what is defined by > > > draft-ietf-spring-segment-routing-policy. > > > > > > I personally (not speaking for the related WGs that I chair) would prefer to > > > see this document be revised  to include resource allocation that would > > > allow BIER-TE to support TE usage such as DetNet.  Barring such an addition, > > > I'm against publication of this document as is and I think the document > > > should be recast and renamed to be aligned with the SR example, i.e., BIER > > > routing policy (or path steering). > > > > > > Lou > > > > > > On 2/18/20 3:45 PM, Greg Shepherd wrote: > > > > Thanks Toerless and Jeffrey > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-bier-te-arch/ > > > > > > > > One more week of WGLC. Please read the latest rev and respond to this > > > > thread w/wo support. > > > > > > > > Chairs > > > > (Shep) > > > > > > > > > > > > On Tue, Feb 18, 2020 at 12:07 PM Jeffrey (Zhaohui) Zhang > > > > > > > > wrote: > > > > > > > > Hi Toerless, > > > > > > > > Thanks! > > > > I support moving this to the next stage. > > > > > > > > Jeffrey > > > > > > > > On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote: > > > > > Thanks Jeff > > > > > > > > > > I have now pushed out -05 with the answers and hopefully > > > > resolution to > > > > > your points in email below.  Biggest addition was a section about > > > > > reuse of BPs (without DNR) which came out of the confusion i > > > > think the > > > > > reuse in the ECMP example raised. I was afraid so far to explan > > > > that > > > > > as it may not be easy to absorb and ultimately is stuff only > > > > > controller developers need to understand, but hopefully useful. > > > > > And then of course the summary of BP optimizatins you asked for > > > > > > > > > > Diff from last version i sent you: > > > > > > > > > > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: > > > > > **Araw.githubusercontent.com > > > > *toerless*bier-te-arch*master*draft-ietf-b > > > > > ier-te-arch-05.1.txt&url2=http:**Atools.ietf.org > > > > *id*draft-ietf-bier-te > > > > > > > > > -arch-05.txt__;Ly8vLy8vLy8vLy8!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzH > > > > > OCr0fZkLPbgg3CPNu0PyrWsrFx41_jWX2At8V-$ > > > > > > > > > > full -04 -> 05 diff: > > > > > > > > > > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=http:* > > > > > *Atools.ietf.org > > > > *id*draft-ietf-bier-te-arch-04.txt&url2=http:**Atools. > > > > > ietf.org > > > > *id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk > > > > > !VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx41_jWancpziv$ > > > > > > > > > > Comments inline below. > > > > > > > > > > Cheers > > > > >     toerless > > > > > > > > > > On Mon, Oct 28, 2019 at 07:52:59PM +0000, Jeffrey (Zhaohui) > > > > Zhang wrote: > > > > > > I Thought u-turn is the most simple comparison leaf vs. > > > > non-leaf BFR. > > > > > > > > > > > > Zzh> The text in the email is seriously misaligned. Looking at > > > > the picture in the diff link, while you gave a U-turn example, > > > > though even if BFER2 is not connected to BFR2  but only connected > > > > to BFER1 (hence no U-turn), then BFER1 is still not a leaf BFER I > > > > suppose. That's why I said the first sentence of the above > > > > paragraph is enough to define Leaf BFER while the example itself > > > > is actually not needed. > > > > > > > > > > Argh... ok, had to fix two words, BFIR->BFER and left-hand -> > > > > right-hand: > > > > > > > > > > Consider how redundant disjoint traffic can reach BFER1/BFER2 in > > > > above > > > > > picture: When BFER1/BFER2 are Non-Leaf BFER as shown on the > > > > right hand > > > > > side, one traffic copy would be forwarded to BFER1 from BFR1, > > > > but the > > > > > other one could only reach BFER1 via BFER2, which makes BFER2 a > > > > > non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forwarding > > > > > traffic to BFER2 > > > > > > > > > > > Zzh> Additionally, in left part of the picture you added, if > > > > some failure leads to BFR2 to be only reachable via BFER1, then > > > > BFER1 is no longer a leaf BFER. > > > > > > > > > > Added sentence: > > > > > > > > > > Note that the BFER in the left hand picture are only > > > > guaranteed to > > > > > be leaf-BFR by fitting routing configuration that prohibits transit > > > > > traffic to pass through a PE, which is commonly applied in these > > > > > topologies. > > > > > > > > > > > I assume you don't reassign BPs when links go up and down. > > > > > > > > > > I didn't want to discuss that option in this document. Its > > > > obviously > > > > > perfectly feasible, but be yet a big amount of text (especially the > > > > > considerations how to do this make-before-break. Future doc. > > > > > > > > > > > > but subsequent polarization example confuses me. It seems > > > > that BP 0:6 is assigned to the routed adjacency BFR10 (which is > > > > actually talked about in Section 4.8). > > > > > > > > > > > > Section 4.7 does not mention "routed" at all, so there are no > > > > routed adjacencies at all used in 4.7. So i am not sure what you > > > > are confused about. > > > > > > > > > > > > Zzh> "The BIFT of each BFR are only populated with BPs that > > > > are adjacent to the BFR in the BIER-TE topology". > > > > > > > > > > Correct text from the introduction. Ok. > > > > > > > > > > > Zzh> Since the same 0:6 is in BIFTS of BFR1/BFR2/BFR3 (and I > > > > suppose in BFR4~BFR9 as well even though not drawn), I assumed > > > > it's for the "MP2P" routed adjacency to R10; though I then ruled > > > > that out - but I don't know what 0:6 represent now on BFR1, BFR2, > > > > and BFR3. > > > > > > > > > > Ah. Ok. I thought i could strip down the example to show only the > > > > > adjacencies relevant to the following discusion, but seemingly this > > > > > can introduce the confusion you have. > > > > > > > > > > So i completed the example with the BP assignment acoss all > > > > nodes, but > > > > > added text pointing to a new section further down to discuss the > > > > > re-use of BP for which thi picture is also an example. > > > > > > > > > > (check out the diff, new reuse text to long to copy inline). > > > > > > > > > > > The whole purpose of the ECMP BPs is of course to save bits, > > > > otherwise we'd give each link a separate BP, which would be 6 BP > > > > to reach to BFR4...BFR7 from BFR1. > > > > > > > > > > > > Zzh> The trouble I am having is that the same 0:6 is assigned > > > > to different things and it's present on all BFR1/BFR2/BFR3. It is > > > > perhaps an intentional smart design but I have not wrapped my mind > > > > around it. It's apparently different from the link bundle case, so > > > > better separate it out and elaborate it (including the DNR flag > > > > that might be needed here - If the packet arrives on BFR1 with > > > > 0:6, would the BP reset when it is sent to BFR2/3)? > > > > > > > > > > Yes, there was the bug of reusing BP 0:6 across sequential BFR > > > > along > > > > > the path, but now the example correctly reuses separate BP at > > > > > different stages of the paths (BP 0:6 on BFR1, BP 0:7 on > > > > BFR2/BFR3) and so on. > > > > > > > > > > Thanks! > > > > > > > > > > > > 4.8.  Routed adjacencies > > > > > > > > > > > > > > If I understand it correctly, there is a BP assigned to > > > > L1/L2/L3 > > > > > > > respectively (p2p link), and then there are BPs assigned to > > > > MP2P tunnels (routed adjacency from every BFR) to the L1/L2/L3 > > > > interface addresses and loopback addresses on BFR2/3. > > > > > > > > > > > > Ok that wasn't quite the read i expected. Let me clarify the > > > > text/picture: > > > > > > > > > > > >                    ............... > > > > > >          ...BFR1--...           ...--L1-- BFR2... > > > > > >                   ... .Routers. ...--L2--/ > > > > > >          ...BFR4--...           ...------ BFR3... > > > > > >                    ...............         | > > > > > >                                           LO > > > > > >                     Network Area 1 > > > > > > > > > > > > Assume the requirement in the above picture is to explicitly > > > > steer traffic flows that have arrived at BFR1 or BFR4 via a > > > > shortest path in the routing underlay "network area 1" to one of > > > > the following three next segments: (1) BFR2 via link L1, (2) BFR2 > > > > via link L2, (3) via BFR3. > > > > > > > > > > > > To achieve this, both BFR1 and BFR4 are set up with a > > > > forward_routed adjacency BitPosition towards an address of BFR2 on > > > > link L1, another forward_routed BitPosition towards an address of > > > > BFR2 on link L2 and a third forward_routed Bitposition towards a > > > > node address LO of BFR3. > > > > > > > > > > > > Does this clear ip the confusion ? > > > > > > > > > > > > Zzh> The picture is badly misaligned. I'll wait till 4.7 > > > > questions are cleared. > > > > > > > > > > Ok. > > > > > > > > > > > > If BFR2/3 are also BFERs, then they additionally will have > > > > BFER BPs. > > > > > > > On BFR1/4, the BIFT entries for the MP2P BPs for the > > > > L1/L2/L3/loopback interface addresses of BFR2/3 will use > > > > forward_routed(interface/loopback address). For a packet to be > > > > decapsulated on a BFER, there is a need for both the BFER BP and > > > > another BP (p2p/lan/hub-spoke/routed-adjacency) in the packet (the > > > > former is for decapsulation and the latter is for getting it there). > > > > > > > > > > > > This is not discussed in this section, but you are right - unless > > > > > > BFR2 or BFR3 is a leaf BFR. In that case, it would just > > > > leverage the one shared "leaf-BFR" BP, so they do not need a > > > > per-BFER BP for local_decap(). > > > > > > > > > > > > Zzh> Right - shared leaf-BFR BP but still need that BP (the > > > > key is that we need a BP to get packet to a BFER and then a BP for > > > > decapsulation). > > > > > > > > > > You got it. > > > > > > > > > > > > If that???s the case, it???s worth point the above out. > > > > > > > > > > > > Hmm... The logic of BFER BPs is totally independent of the > > > > logic of forward_routed adjacency, so i would worry that repeating > > > > the explanation of BFER BPs would conflate the forward_routed > > > > explanation. > > > > > > > > > > > > Zzh> It's just that this is a place where all kinds of BPs are > > > > used so it's good to have a summary (could be a subsection 4.9). > > > > > > > > > > Yes, added such a summary. Pls. check. > > > > > > > > > > > > Actually, the reason that I thought this is MP2P is that 0:6 > > > > is present on R1, R2, and R3 (and more I assume) in Figure 12, but > > > > now I think it can???t be MP2P (so it is not correct to have 0:6 > > > > present on those routers ??? only the p2p tunnel head/tail should > > > > have the BP present in the BIFT). The reason is that if it were > > > > MP2P, any router getting a copy will send it to the endpoint of > > > > the routed adjacency, causing lots of duplicates. > > > > > > > > > > > > > > Am I getting this correct? > > > > > > > > > > > > I think you are still explaining from the misunderstsanding > > > > that the ECMP explanations where about routed adjacencies. > > > > > > > > > > > > I have now expanded the somewhat terse text in the BIFT table > > > > pictures, to make it clear that the ECMP is across multipe > > > > forward_connected adjacencies in the examples. For example, first > > > > BIFT picture: > > > > > > > > > > > >   BIFT entry in BFR1: > > > > > > > > > >  ------------------------------------------------------------------ > > > > > >   | Index |  Adjacencies                  | > > > > > > > > > >  ================================================================== > > > > > >   | 0:6   |  ECMP({forward_connected(L1, BFR2),                 | > > > > > >   |       |        forward_connected(L2, BFR2),                 | > > > > > >   |       |        forward_connected(L3, BFR2)}, seed) > > > >      | > > > > > > > > > >  ------------------------------------------------------------------ > > > > > > > > > > > > Of course, an ECMP adjacency can be across any type of > > > > adjacencies, but all the text/explanations used forward_connected, > > > > and now the pictures show that explicitly. > > > > > > > > > > > > Zzh> I can understand the multi-link case, but the multi-hop > > > > ECMP case (from BFR1 towards BFR10) is confusing me. It would help > > > > to give an example how it can be used, WITHOUT worrying about > > > > polarization. > > > > > > > > > > Please check -05 text that has the full set of BIFT listed now: > > > > > > > > > > There is  really nothing nothing unique in multi-hop ECMP for > > > > BIER-TE > > > > > that we do not also have in any other ECMP, except the > > > > conclusion that > > > > > we want to support fast HW hash mechanisms AND allow the > > > > controller to > > > > > set up non-polarized multi-hop ECMP AND be able to precalculate > > > > paths. > > > > > Hence the specification of ECMP adjacencies to have a controller > > > > > configurable seed. > > > > > > > > > > Btw: The picture is maybe unnecessarily large because i've used > > > > it for > > > > > 20 years to explain the same polarization issue for unicast vs > > > > > multicast, and for multicast only BFR10...BFR4 are relevant > > > > (ECMP of > > > > > the PIM/mLDP joins), whereas for unicast/BIER only > > > > > BFR1...BFR7 are relevant. But being symmetric, the picture makes it > > > > > clear its the same problem. > > > > > > > > > > > >    To inhibit looping in the face of such physical > > > > misconfiguration, > > > > > > >    only forward_connected adjacencies are permitted to have > > > > DNR set, and > > > > > > >    the link layer destination address of the adjacency > > > > (e.g.  MAC > > > > > > >    address) protects against closing the loop.  Link layers > > > > without port > > > > > > >    unique link layer addresses should not be used with the > > > > DNR flag set. > > > > > > > > > > > > > > It???s not clear how link layer address helps? > > > > > > > > > > > > I have expanded this to > > > > > > "link layer port unique unicast destination address" > > > > > > > > > > > > Aka: MPLS or ethernet have unique link layer destination > > > > destination addresses (label or destination MAC). If you think > > > > about incorrectly plugged HDLC links (such as old T1/T3/... > > > > links), they only have 2 generic addresses, if i remember 1 or 3 > > > > in the HDLC frame. So when you misplug one of those p2p cables > > > > wrong, the packets would be incrrectly received by the wrong > > > > receiver node and then DNR could cause persistent loops only > > > > solved by TTL. > > > > > > > > > > > > Zzh> "Consider in the ring picture that link L4 from BFR3 is > > > > plugged into the L1 interface of BFRa" - still not sure how > > > > label/mac helps here. I suppose the ring topology is > > > > discovered/verified by the control plane and when the miscalling > > > > happens then the ring will not include the BFR1/BFR2 part and BFR3 > > > > will not have the DNR set? If ring discovery/varication is not > > > > done then perhaps we should point out that RPF based on link layer > > > > address is needed - the key is RPF (which needs unique link layer > > > > address)? > > > > > > > > > > Forget RPF. BIER(-TE) has no RPF (issues). Its just like > > > > unicast. RPF > > > > > is just a problem for receiver originated joins like in > > > > PIM/mLDP, but > > > > > not unicast/bier(-te)/RSVP-TE. > > > > > > > > > > Forward_connected is just like a unicast subnet adjacency to a > > > > direct > > > > > neighbor: Interface and L2 addresss of the destination. > > > > > > > > > > The controller (could be a human) "assumes" a particular physicial > > > > > topology, from telemetry/knowledge/whatever. It then calculates the > > > > > desired BIER-TE topology and pushes it down. This topology is > > > > meant to > > > > > be loop free of course wrt to the configured adjacencies. > > > > > In this BIER-TE topology, BFR3 will have a BP with the > > > > > forward_connected(L4, MAC-of-BFR2) adjacency. > > > > > > > > > > If the cable connecting to L4 is miswired, then BFR3 would still > > > > send > > > > > the packets to the MAC address of BFR2, but given how the cable > > > > > connects to some other node, these packets will be discarded by > > > > that > > > > > node. because they're just L2 unicast packets. > > > > > > > > > > I think this is equally true when we have normal BIER/MPLS enacp. > > > > > Those packets too are addressed to the unicast MAC address of the > > > > > neighbor. > > > > > > > > > > Now, if/when he controller recognizes that the physical topology > > > > has > > > > > changed, thats a completely different story and not addressed here. > > > > > Given how we assumed this was a cabling mistake, the controller > > > > would > > > > > probably only complain about the miswiring to operations but be > > > > happy > > > > > that the forwarding plane just makes packets fail instead of > > > > loop. If > > > > > this was a planned change process, then it will be similarily > > > > > convoluted as it would today be with rewiring cables in an > > > > > SR-MPLS/SRv6 topology and updating SIDs. > > > > > > > > > > > > Because the forwarding is different from BIER forwarding > > > > (because of [1] above), we might as well introduce an optimization > > > > here ??? for each BIFT, calculate the F-BM of the BIFT itself (the > > > > logical ???or??? of all the BPs presented in this BIFT) and then > > > > use (packet->bitstring & BIFT.F-BM) as the input to > > > > GetFirst/NextBitPosition(). That should skip many bits. > > > > > > > > > > > > Right. But i explicitly removed those optimizations (i had > > > > them in older draft versions) because the whole idea of this > > > > picture is solely the comparison with figure 4 of RFC8279. > > > > > > > > > > > > Zzh> I think it's worth point that optimization out; you can > > > > mark it optional if you want to emphasize the similarity to BIER > > > > forwarding, but since BIER forwarding does do the maskoff step, it > > > > is very efficient while BIER-TE forwarding does not it the maskoff > > > > step so this optimization is important. > > > > > > > > > > Ok. I simplified the text comparison BIER/BIER-TE wrt. to the FBM > > > > > rules [1] and [2] and added following paragraph: > > > > > > > > > > In BIER, the order of BPs impacts the result of forwarding > > > > because of [1]. > > > > > In BIER-TE, forwarding is not impacted by the order of BPs. It is > > > > > therefore possible to further optimize forwarding than in BIER. For > > > > > example parallelizing forwarding across multiple FPE cores or > > > > > distributed linecards does only need to examine an arbitrary > > > > subset of > > > > > BP and not evaluate the dependency between BPs. > > > > > > > > > > > >    The following pseudocode is comprehensive: > > > > > > > > > > > > > > The above sentence reads a bit strange (or lacks some segue). > > > > > > > > > > > > I hope not, but maybe best left to a native english speaker > > > > (RFC-editor). > > > > > > > > > > > > The first (RFC8279) pseudocode was simplified. The second one > > > > is comprehensive. If not comprehensive, whats a good opposite of > > > > simplified ? > > > > > > > > > > > > Zzh> Perhaps "The above simplified pseudocode is elaborated > > > > further as following"? > > > > > > Zzh> Jeffrey > > > > > > > > > > Done. > > > > > > > > > > Thanks a lot. > > > > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > > > > From: BIER [bier-bounces@ietf.org > > > > > > > >] > > > > > > > on behalf of Toerless Eckert [tte@cs.fau.de > > > > >] > > > > > > > Sent: Tuesday, July 09, 2019 23:38 > > > > > > > To: Mike McBride > > > > > > > Cc: Greg Shepherd; BIER WG; Pascal Thubert (pthubert) > > > > > > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch > > > > > > > > > > > > > > Thanks, Mike > > > > > > > > > > > > > > The authors also reviewed the document and concluded that it > > > > was > > > > > > > really hard to get into the document context because of too > > > > many > > > > > > > forward dependencies. We tried to fix this by adding two > > > > hopefully > > > > > > > good & basic examples into the Introduction section and > > > > using them > > > > > > > to also add a better definition of the term "BIER-TE > > > > Topology" in the Introduction. > > > > > > > Hopefully this makes readin the rest of te document smoother. > > > > > > > > > > > > > > Also improved text of Abstract and refined text compariing > > > > BIER-TE with SR. > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: > > > > > > > **Atools.ietf.org > > > > *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A > > > > > > > tool > > > > > > > s.ietf.org > > > > *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R > > > > > > > jC81 > > > > > > > > > > > c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV_eTUEh > > > > > > > $ > > > > > > > > > > > > > > > > > **Atools.ietf.org > > > > *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A > > > > > > > tool > > > > > > > s.ietf.org > > > > *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R > > > > > > > jC81 > > > > > > > > > > > c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sNd1njcX > > > > > > > $> > > > > > > > > > > > > > > Cheers > > > > > > >     Toerless > > > > > > > > > > > > > > On Wed, Jun 26, 2019 at 10:39:36AM -0700, Mike McBride wrote: > > > > > > > > How about three? I support. > > > > > > > > mike > > > > > > > > > > > > > > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd > > > > > > > > > > >> wrote: > > > > > > > > > > > > > > > > > > We cannot take two 'yes' votes and WG consensus. > > > > > > > > > Please, read and respond. If you don't support, then > > > > please vote as much publicly right here. > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > Greg > > > > > > > > > > > > > > > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert > > > > (pthubert) > > > > > > >> wrote: > > > > > > > > >> > > > > > > > > >> Support: > > > > > > > > >> > > > > > > > > >> I see great value in deterministic networks as well as > > > > IOT (with RPL). > > > > > > > > >> > > > > > > > > >> All the best, > > > > > > > > >> > > > > > > > > >> Pascal > > > > > > > > >> > > > > > > > > >> > -----Original Message----- > > > > > > > > >> > From: BIER > > > > > > > > >> > > > > > > > >> On > > > > > > > > >> > Behalf Of Toerless Eckert > > > > > > > > >> > Sent: mardi 4 juin 2019 02:03 > > > > > > > > >> > To: Greg Shepherd > > > > > > > > >> > > > > > > > >> > > > > > > > > >> > Cc: BIER WG > > > >> > > > > > > > > >> > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch > > > > > > > > >> > > > > > > > > > >> > +1 > > > > > > > > >> > Obviously support as co-author. > > > > > > > > >> > > > > > > > > > >> > On Wed, May 29, 2019 at 12:41:26PM -0700, Greg > > > > Shepherd wrote: > > > > > > > > >> > > Please read and respond to this thread w/ or w/o > > > > support. > > > > > > > > >> > > > > > > > > > > >> > > > > > > https://urldefense.com/v3/__https://datatracker..ietf.org > > > > > > > > >> > > /doc > > > > > > > > >> > > > > > > /draft-ietf-bier-te-arch/__;!8WoA6RjC81c!XvH4AAxfrDjFoK_s > > > > > > > > >> > > ercw ZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV9eClBj$ > > > > > > > > >> > > > > > > > > > > > > > >> > > doc/ > > > > > > > > >> > > > > > > draft-ietf-bier-te-arch/__;!8WoA6RjC81c!UBTGvWWpMHyeiSanx > > > > > > > > >> > > s6vI b_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sD40kmtH$> > > > > > > > > >> > > > > > > > > > > >> > > Vote ends 5 June 2019. > > > > > > > > >> > > > > > > > > > > >> > > Thanks, > > > > > > > > >> > > Shep > > > > > > > > >> > > (chairs) > > > > > > > > >> > > > > > > > > > >> > > _______________________________________________ > > > > > > > > >> > > BIER mailing list > > > > > > > > >> > > BIER@ietf.org > > > > > > > > > > > > > >> > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/ > > > > > > > > >> > > list > > > > > > > > >> > > > > > > info/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eE > > > > > > > > >> > > NOs4 l_qdsXF0KwZD82cJLDFFNT2WVXWX$ > > > > > > > > >> > > > > > > > > > > > > > >> > > list > > > > > > > > >> > > > > > > info/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6b > > > > > > > > >> > > oAAW 4nrqju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > > > > > >> > > > > > > > > > >> > _______________________________________________ > > > > > > > > >> > BIER mailing list > > > > > > > > >> > BIER@ietf.org > > > > > > > > > > > > > >> > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/li > > > > > > > > >> > stin > > > > > > > > >> > > > > > fo/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4 > > > > > > > > >> > l_qd > > > > > > > > >> > sXF0KwZD82cJLDFFNT2WVXWX$ > > > > > > > > >> > > > > > > > > > > > > >> > stin > > > > > > > > >> > > > > > fo/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW > > > > > > > > >> > 4nrq > > > > > > > > >> > ju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > BIER mailing list > > > > > > > > > BIER@ietf.org > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listi > > > > > > > > > nfo/ > > > > > > > > > > > > > bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsX > > > > > > > > > F0Kw > > > > > > > > > ZD82cJLDFFNT2WVXWX$ > > > > > > > > > > > > > > > > > > > > > nfo/ > > > > > > > > > > > > > bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju > > > > > > > > > 8UCL > > > > > > > > > OgiuXc8Y_6sKn2KoAT$> > > > > > > > > > > > > > > -- > > > > > > > --- > > > > > > > tte@cs.fau.de > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > BIER mailing list > > > > > > > BIER@ietf.org > > > > > > > > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ > > > > > > > bier > > > > > > > > > > > __;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82 > > > > > > > cJLD > > > > > > > FFNT2WVXWX$ > > > > > > > > > > > > > > > > > bier > > > > > > > > > > > __;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiu > > > > > > > Xc8Y > > > > > > > _6sKn2KoAT$> > > > > > > > > > > > > -- > > > > > > --- > > > > > > tte@cs.fau.de > > > > > > > > > > -- > > > > > --- > > > > > tte@cs.fau.de > > > > > > > > > > _______________________________________________ > > > > > BIER mailing list > > > > > BIER@ietf.org > > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier > > > > > > > > > __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx4 > > > > > 1_jWV3YUA6D$ > > > > > > > > -- > > > > --- > > > > tte@cs.fau.de > > > > > > > > _______________________________________________ > > > > BIER mailing list > > > > BIER@ietf.org > > > > https://www.ietf.org/mailman/listinfo/bier > > > > > > > _______________________________________________ > > > BIER mailing list > > > BIER@ietf.org > > > https://www.ietf.org/mailman/listinfo/bier > > > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier From nobody Tue Feb 25 08:31:35 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB843A104D for ; Tue, 25 Feb 2020 08:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 XoxutwjUJa4q for ; Tue, 25 Feb 2020 08:31:31 -0800 (PST) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 E530B3A104C for ; Tue, 25 Feb 2020 08:31:30 -0800 (PST) Received: by mail-ed1-x529.google.com with SMTP id r18so133801edl.1 for ; Tue, 25 Feb 2020 08:31:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to; bh=Jpk/mCf9IWDdLKYcgA1wCliX9S8h8csSSBcdblR4NXY=; b=WswGgQs+/j9U3DvdOr9+m3ChtRw3nzItRX0s6/js+cJllAQxolXv3LnYuF9a5HYK2+ oW42gltLZY2HPLekuxdfAkQBw2NMFZJmIg2VCTFuK7lsZE3eJ6Y4SZmFO0tm1y6a6ggo a6jb30qMgdClQRBlctblT/STA94p1zjR9qK9xZprtNM2P+qOMhuPJLr+WEwZXEIAOxVt IxTr9P9cZS9g8W/7/oBkRsOSj/XrRP9/bGgoCSZQYiemQYc8hd+ff2VPdXT3Ome7j9tb Si8thh1o98h9ZTvgbdV/It4uWvtd80cB3OG9doILWUHDvRNdOvirLrUKOxN+ui3G3RuQ 3CwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=Jpk/mCf9IWDdLKYcgA1wCliX9S8h8csSSBcdblR4NXY=; b=Xfg/h+DVXc2UFIL7zPUYBcEtWblxTWyohtOPr1umw/Rgeud79FsujPONtEZP4foZiN 5fa4CY1jjq0f0y+tKA3WOy6GkZDxXbQARkMs4Dqzen2Z+ytwckM2xrCxO86JFW0coMLQ LowW3Li6wzXSsvibqtv3rmc3kLYjOG/FnViWNFghZtCxLzvv8H0/dmQeCgMts0xADkn2 JSgu2MCV8CM77pzDjrpQB/9E5oHLFwHr5F4CeIVpF1p794q16sgznBp6heUXXiBiHFxU u5TsQbJwSmLVznA6NwGYRSGfLvAAQXWBXCnMnliA95G7Un6Oz/qnWoVYkRZp5KH4Ej+J HWog== X-Gm-Message-State: APjAAAXvk0RnWv93JK12Ok6a9q4KgaXkCHGwuInn/lhsqL5ub1u6iDk0 6mIHgn2DqFiB0FX3tCvygC9oO1NGBEQonRmedq/TN3lv X-Google-Smtp-Source: APXvYqz43BA0oSh79Okowa1UvjdmfXm5jXkNTTupaDn4v8SMsJ3zULwjhVDdtNFpGfKYL3Mr+dvA8BBrUOWweNaeyGk= X-Received: by 2002:a17:906:1cd0:: with SMTP id i16mr4994ejh.186.1582648289028; Tue, 25 Feb 2020 08:31:29 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 25 Feb 2020 08:31:28 -0800 From: Alvaro Retana MIME-Version: 1.0 Date: Tue, 25 Feb 2020 08:31:28 -0800 Message-ID: To: bier@ietf.org Content-Type: multipart/alternative; boundary="000000000000126f51059f690598" Archived-At: Subject: [Bier] Fwd: Last Call: (Packetization Layer Path MTU Discovery for Datagram Transports) to Proposed Standard X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 16:31:34 -0000 --000000000000126f51059f690598 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FYI=E2=80=A6 Forwarding to the WG because there are a couple of documents related to PMTUD have been discussed on the list. If you have comments, please send them to the authors and copy last-call@ietf.org. Thanks! Alvaro. On February 25, 2020 at 9:14:45 AM, The IESG (iesg-secretary@ietf.org) wrote: The IESG has received a request from the Transport Area Working Group WG (tsvwg) to consider the following document: - 'Packetization Layer Path MTU Discovery for Datagram Transports' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-03-10. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a robust method for Path MTU Discovery (PMTUD) for datagram Packetization Layers (PLs). It describes an extension to RFC 1191 and RFC 8201, which specifies ICMP-based Path MTU Discovery for IPv4 and IPv6. The method allows a PL, or a datagram application that uses a PL, to discover whether a network path can support the current size of datagram. This can be used to detect and reduce the message size when a sender encounters a packet black hole (where packets are discarded). The method can probe a network path with progressively larger packets to discover whether the maximum packet size can be increased. This allows a sender to determine an appropriate packet size, providing functionality for datagram transports that is equivalent to the Packetization Layer PMTUD specification for TCP, specified in RFC 4821. The document updates RFC 4821 to specify the method for datagram PLs, and updates RFC 8085 as the method to use in place of RFC 4821 with UDP datagrams. Section 7.3 of RFC4960 recommends an endpoint apply the techniques in RFC 4821 on a per-destination-address basis. RFC 4960, RFC 6951 and RFC 8261 are updated to recommend that SCTP, SCTP encapsulated in UDP and SCTP encapsulated in DTLS use the method specified in this document instead of the method in RFC 4821. The document also provides implementation notes for incorporating Datagram PMTUD into IETF datagram transports or applications that use datagram transports. When published, this specification updates RFC 4960, RFC 4821, RFC 8085 and RFC 8261. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud/ballot/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --000000000000126f51059f690598 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
FYI=E2=80=A6

Forwarding to the WG because there are a couple of doc= uments related to PMTUD have been discussed on the list.

If you have comments, please send the= m to the authors and copy last-call@i= etf.org.

Thanks= !

=
Alvaro.

On February 25, 2020 at 9:14:45 AM, The IESG (iesg-secretary@ietf.org) wrote:<= /p>


The IESG has received a request from the Transport Area Working Group W= G
(tsvwg) to consider the following document: - 'Packetization Layer = Path MTU
Discovery for Datagram Transports'
<draft-ietf-tsvwg-datagram-plpmtud-15.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits f= inal
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing li= sts by 2020-03-10. Exceptionally, comments may
be sent to iesg@ietf.org instead. = In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


This document describes a robust method for Path MTU Discovery
(PMTUD) for datagram Packetization Layers (PLs). It describes an
extension to RFC 1191 and RFC 8201, which specifies ICMP-based Path
MTU Discovery for IPv4 and IPv6. The method allows a PL, or a
datagram application that uses a PL, to discover whether a network
path can support the current size of datagram. This can be used to
detect and reduce the message size when a sender encounters a packet
black hole (where packets are discarded). The method can probe a
network path with progressively larger packets to discover whether
the maximum packet size can be increased. This allows a sender to
determine an appropriate packet size, providing functionality for
datagram transports that is equivalent to the Packetization Layer
PMTUD specification for TCP, specified in RFC 4821.

The document updates RFC 4821 to specify the method for datagram PLs= ,
and updates RFC 8085 as the method to use in place of RFC 4821 with
UDP datagrams. Section 7.3 of RFC4960 recommends an endpoint apply
the techniques in RFC 4821 on a per-destination-address basis. RFC
4960, RFC 6951 and RFC 8261 are updated to recommend that SCTP, SCTP
encapsulated in UDP and SCTP encapsulated in DTLS use the method
specified in this document instead of the method in RFC 4821.

The document also provides implementation notes for incorporating
Datagram PMTUD into IETF datagram transports or applications that us= e
datagram transports.

When published, this specification updates RFC 4960, RFC 4821, RFC
8085 and RFC 8261.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-plpmtud= /

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tsvwg-datagram-= plpmtud/ballot/


No IPR declarations have been submitted directly on this I-D.





_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https:/= /www.ietf.org/mailman/listinfo/ietf-announce
<= /body> --000000000000126f51059f690598-- From nobody Tue Feb 25 10:19:33 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04ABA3A125E for ; Tue, 25 Feb 2020 10:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 (768-bit key) header.d=labn.net 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 wh_eN9NKJbzJ for ; Tue, 25 Feb 2020 10:19:27 -0800 (PST) Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 BC1213A0F9C for ; Tue, 25 Feb 2020 10:19:27 -0800 (PST) Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 704BC1E061D for ; Tue, 25 Feb 2020 11:19:27 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id 6ennj7OG2kyVr6ennjpD4H; Tue, 25 Feb 2020 11:19:27 -0700 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.3 cv=dZKuI0fe c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=xqWC_Br6kY4A:10:nop_ipv6 a=IkcTkHD0fZMA:10:nop_charset_1 a=l697ptgUJYAA:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=7OBBZF0iAAAA:20 a=48vgC7mUAAAA:8 a=uherdBYGAAAA:8 a=bt8Zh30PAAAA:8 a=pGLkceISAAAA:8 a=AUd_NHdVAAAA:8 a=UVxT4ypLugPxXopVND4A:9 a=zLhUpgbnW97XhAxj:21 a=LrD6EttRRVP81QhY:21 a=7IV0nE4a4P3unY9a:21 a=QEXdDO2ut3YA:10:nop_charset_2 a=-RoEEKskQ1sA:10:nop_election2020_name_body a=w1C3t2QeGrPiZgrLijVG:22 a=Ef4yma5cpRUEJWN9UqBm:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=DzuiYxys1vem1KEvM6D+SvMyNgTYY7bxalNI5n66Dhw=; b=0aP8+mnlBIaY+NUq2IirP9auN0 b5Hbbz8s0RkcdmMHjblhQdljvLmMhuNwe56nQAAGkLsBPO7crShPG6SRFMBhL7Z+p8Ufq2vq+slak UrXMbVE2Q99rrscLdJi/Kdimp; Received: from [127.0.0.1] (port=13141 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1j6enm-003BsY-Sr; Tue, 25 Feb 2020 11:19:27 -0700 To: Toerless Eckert Cc: gjshep@gmail.com, "bier@ietf.org" , "Jeffrey (Zhaohui) Zhang" References: <11ab30da-8701-b491-6162-5a69aa9d6965@labn.net> <20200220035620.GA42520@faui48f.informatik.uni-erlangen.de> <20200225015718.GC20521@faui48f.informatik.uni-erlangen.de> From: Lou Berger Message-ID: Date: Tue, 25 Feb 2020 13:19:26 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <20200225015718.GC20521@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 127.0.0.1 X-Source-L: Yes X-Exim-ID: 1j6enm-003BsY-Sr X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPv6:::1]) [127.0.0.1]:13141 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 18:19:31 -0000 Hi Toerless,     This revision will mostly remove my objection related to the use of TE by the document.  I suspect in section 7.2 you have two instances where "traffic" needs to be replaced with "path".  More substantively, I think you should delete section 1.1 and leave its subject  matter  to eckert-teas-bier-te-framework to be covered/worked out.  If you want to keep it, I think there's a longer discussion need on its contents. FWIW I still think the introduction of the a new term "Path Engineering", rather than reusing one of the existing IETF terms for the same capability ("routing policy", "policy based routing", "path steering") seems  likely to lead to more confusion then if you stuck with an established term.  I'll leave this to others to argue. I think this covers all the detailed discussion points below. If not, can you extract the ones you'd like to keep discussing? Thanks again for the responsiveness to my comments! Lou On 2/24/2020 8:57 PM, Toerless Eckert wrote: > Hi Lou, round 2. > > Here is the github pre-version of -07 of the draft: > > https://raw.githubusercontent.com/toerless/bier-te-arch/62378f618299307349a934fc6ad78e1af9e16771/draft-ietf-bier-te-arch.txt > > Diff: > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-bier-te-arch-06.txt&url2=https://raw.githubusercontent.com/toerless/bier-te-arch/62378f618299307349a934fc6ad78e1af9e16771/draft-ietf-bier-te-arch.txt > > I would appreciate if you could try to partition your opinions into > things you think MUST be solved before passing the document to IESG (for > IETF/IESG review) and those issues that could then be solved when it is > in IETF/IESG review. For example, i think a final choice of name could > be something that shouldn't block the document to take this step. > > If this goes along into IETF107, it would be great if you could find the > time to be at the BIER-WG meeting. > > Summary of changes: > > 1. Changed abbreviation BIER-TE to BIER-PE, otherwise we can not unconfuse > readers of the difference between BIER-PE and BIER-TE. > > Relationship: BIER-TE = (BIER with steering: BIER-PE or othre) plus resource > allocation mechanisms, and this document only describes BIER-PE. > > 2. Removed all use of the term "path engineering" from the (explanatory) text, > replaced with path / tree steering or policy in the text (like RFC8402). > > 3. In result, "Path Engineering" is now solely a name for the mechanism. > In the same way as SR introduced "Segment Routing" as a name, but explains > what it does with the terms "steering" and "policy". > > 4. I think a unique new term not already used in before is helpful because > what BIER-PE does is quite unique and new. And reusing an existing term > always brings out more people wanting to argue about the accuracy of how > their pre-existing term is applied. > > I hope we can have a deterministic, short latency decision mechanism for > the term. After we've decided on the term, its easy to update the doc > again with that new term (%s/PE/XXX/g). > > I'll throw "Tree Steering Bitstrings" (BIER-TSB) into the ring. > > [The main issue with name change now is that we've gotten some followup > work such as YANG model that also refers to BIER-TE meaning BIER-PE, so > that would also need to change name. See below for my reply to that naming > change you said you suggested .] > > 5. I also refined the section 1.1 that was introduced in -06 to mention > e.g.: PCE. > > Specific answers to the mail thread below. > > Cheers > Toerless > > On Fri, Feb 21, 2020 at 03:01:51PM -0500, Lou Berger wrote: >>> [ Would have been nice if you could have commented a bit earlier. >>> But i can understand how a few years is not enough time ;-P >>> (actually no kidding, i really can.) ] >> I raised this as an issue last march - at both the Chair and AD level.  I >> thought I made the same point to you privately after one the presentations >> at IETF101, but if you don't remember it, I accept that I didn't. > Did you include the authors ? I could not find any email about this. > Also no forwarded emails from AD/chairs i could find. If you still have > a copy, pls. PM. This is annoying... > > I do not remember naming issue discussed after IETF101, but i am > sure i was preoccupied with technical issues and might not have > given it too much thought back then. Of course there was a lot of > time since IETF101 to bring up the naming point again... > >> Well that document seems like a fine place to describe how BIER-RP (routing >> policy) can be used to deliver BIER-TE. >> > [...] >> Do we really need a new term to describe here?  I find zero (0) instances of >> Path Engineering in any RFC.  Routing policy (and policy-based routing) on >> the other hand are fairly well established terms in the industry.  I think >> this just sows seeds for future confusion on this topic. >> >> Why is "routing policy" not good enough for what is being defining here?  I >> again point out, this is the term being used in SPRING for basically the >> equivalent function/purpose. (Yes the forwarding mechanism is different, but >> the objective is not.) > SPRING did establish new unique name/terminologies, like "Segment". > As said above, i think its best we do the samegiven how unique this is. > > Looking at rfc8402, "steering" and "policy" are used in verbal > explanations, without providing specific terminology for them, > so i did follow that example too. > >>> but kept name BIER-TE (see below). >>> >>> - Added section 1.1 explaining how BIER-TE relates to traffic >>> engineering, naming use-cases where its for example beneficial standalone and >>> and what it could be combined with for more comprehensive TE solutions, >>> but also stating that those integrations are outside the scope of this >>> document. >> So this section seems to miss what has been going on in traffic engineering >> / TEAS for the last 5+ years (i.e., controller-based TE approaches) > I don't think that is a correct assessment. BIER-PE itself requires a > controller to calculate paths / trees. With or without other traffic > engineering components. That component is called the BIER-PE controller and > has been in the draft forever. > > The new section 1.1 added in response to your review relates that > BIER-TE controller to an overall TE controller, using the PCE example > and refrerence to it. > > There is really nothing more that a BIER-WG document could or should > do. What this document intended to support is whats necessary and > sufficient to get the forwarding plane implemented/standardized. > Everything else is for independent followup work in TEAS IMHO, > such as reviving the framwork draft. > >>   and then goes on describe path steering  in a very brief way.  I read this as >> saying that BIER *could* do TE in the future and *can* support routing >> policy and path steering today. > Even stronger: BIER-PE is always meant to ONLY do that (steering), > any additional TE functions wold come from independent other components. > And simple examples for that are given in section 1.1. > >>> - changed "traffic engineering" term in the whole doc to "path engineering", >>> where appropriate. >> While this is appreciated, I'm not sure it's helpful.  As stated above, I >> think the introduction of the new PE term is confusing as the continued use >> of BIER-TE. > See above. We can certainly not use "BIER-TE" to mean two different > things, so i hope that concern is resolved. > >>> The mayority of customers i talked to only used RSVP-TE for path >>> engineering, and not for anything more. Several didn't even know it >>> can do bandwidth reservation. Nobody knew it could do latency >>> guarantees, because nobody knows an implementation that supports that. >>> [All reasons btw. why replacing RSVP-TE with SR happened in the industry.] >> While I'm going to avoid getting into product differentiators and marketing, >> you're not mentioning that even those products and customers who didn't >> support/use per LSP queuing, did available resource bookkeeping and even >> admission control. > I think the point is mood now (given how we'll change the name BIER-TE > to a better term). But maybe to better explain: We started calling this > TE so customers would easier understand that this is intended to give > them what they actually use RSVP-TE for (Traffic Steering), and not > necessarily all that RSVP-TE could do beyond that. A central controller > is assumed to exist in BIER-PE too. > > Given how SR also shows how you can be successful in deployment > without betting on 'TE' name recognition, i have no quarrels in > changing the name. As said above, its motly a question of finding > the best term and changing the followup works names too. > >>> In any case, the name BIER-TE was selected to reduce confusion >>> with customers, not to maximize naming correctness in IETF. >> umm, the IETF is a standards body not an industry marketing forum, so I'm >> unclear how this point helps your argument. > It's not am argument or justification, just an explanation. Not only to you, > but also the WG. > >>  It seems that you're saying >> that if we call it BIER-TE we can market it in place of existing IETF TE >> solutions - even though it doesn't yet have the TE capability covered in >> draft-eckert-teas-bier-te-framework. > .... > >> Assuming I'm reading it right, this just confirms to me that the current >> work needs to be renamed and that draft-eckert-teas-bier-te-framework will >> define BIER-TE. > Yes. BIER-TE could btw. rely on BIER-PE or BIER + other path steering > (e.g.: flex-algos), so BIER-PE is only one option for the path-steering > options for BIER-TE. > >> My point wasn't that BIER=SR, but rather both deliver support for path >> steering and policy based routing. > Yepp, i hope we're in violent agreement. > > Cheers > Toerless > >> Thanks for being responsive! >> >> Lou >> >>> All the SR options do really require that you set up multicast trees with >>> e.g.: replication-SIDs that together form the equivalent of a >>> multicast tree, like you would have built with RSVP-TE. Except that >>> the signaling how to build the tree is left for someone else, like >>> PCECC. (AFAIK, i may not be on top of all details). In BIER-TE, >>> there is no such per-tree state on transit nodes. >>> >>> Instead of a 256 bit bitstring in BIER-TE think of a header with up to 256 SIDs >>> (e.g.: 128 bit per SID in SRv6). That would be the SR equivalent of BIER-TE. >>> Just a bit less ( ;-) ) less efficient on the wire than BIER-TE and extremely >>> harder to parse. >>> >>> Cheers >>> Toerless >>> >>> >>> On Wed, Feb 19, 2020 at 06:38:38PM -0500, Lou Berger wrote: >>>> Hi, >>>> >>>>     I have no issue or objection to the mechanisms being defined in this >>>> document as much as they go, but I was quite disappointed that despite the >>>> name of the document and use of 'bier-te'  to see that the document doesn't >>>> define any traffic engineering support, at least as far as the term has been >>>> used in IETF RFCs.  In particular it totally lacks any discussion of >>>> resources usage and/or allocation.  What it currently describes certainly >>>> provides good and useful path/traffic steering that can be used to support >>>> policy-based routing.  Basically it does the same as what is defined by >>>> draft-ietf-spring-segment-routing-policy. >>>> >>>> I personally (not speaking for the related WGs that I chair) would prefer to >>>> see this document be revised  to include resource allocation that would >>>> allow BIER-TE to support TE usage such as DetNet.  Barring such an addition, >>>> I'm against publication of this document as is and I think the document >>>> should be recast and renamed to be aligned with the SR example, i.e., BIER >>>> routing policy (or path steering). >>>> >>>> Lou >>>> >>>> On 2/18/20 3:45 PM, Greg Shepherd wrote: >>>>> Thanks Toerless and Jeffrey >>>>> >>>>> https://datatracker.ietf.org/doc/draft-ietf-bier-te-arch/ >>>>> >>>>> One more week of WGLC. Please read the latest rev and respond to this >>>>> thread w/wo support. >>>>> >>>>> Chairs >>>>> (Shep) >>>>> >>>>> >>>>> On Tue, Feb 18, 2020 at 12:07 PM Jeffrey (Zhaohui) Zhang >>>>> >>>> > wrote: >>>>> >>>>> Hi Toerless, >>>>> >>>>> Thanks! >>>>> I support moving this to the next stage. >>>>> >>>>> Jeffrey >>>>> >>>>> On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote: >>>>> > Thanks Jeff >>>>> > >>>>> > I have now pushed out -05 with the answers and hopefully >>>>> resolution to >>>>> > your points in email below.  Biggest addition was a section about >>>>> > reuse of BPs (without DNR) which came out of the confusion i >>>>> think the >>>>> > reuse in the ECMP example raised. I was afraid so far to explan >>>>> that >>>>> > as it may not be easy to absorb and ultimately is stuff only >>>>> > controller developers need to understand, but hopefully useful. >>>>> > And then of course the summary of BP optimizatins you asked for >>>>> > >>>>> > Diff from last version i sent you: >>>>> > >>>>> > >>>>> https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: >>>>> > **Araw.githubusercontent.com >>>>> *toerless*bier-te-arch*master*draft-ietf-b >>>>> > ier-te-arch-05.1.txt&url2=http:**Atools.ietf.org >>>>> *id*draft-ietf-bier-te >>>>> > >>>>> -arch-05.txt__;Ly8vLy8vLy8vLy8!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzH >>>>> > OCr0fZkLPbgg3CPNu0PyrWsrFx41_jWX2At8V-$ >>>>> > >>>>> > full -04 -> 05 diff: >>>>> > >>>>> > >>>>> https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=http:* >>>>> > *Atools.ietf.org >>>>> *id*draft-ietf-bier-te-arch-04.txt&url2=http:**Atools. >>>>> > ietf.org >>>>> *id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk >>>>> > !VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx41_jWancpziv$ >>>>> > >>>>> > Comments inline below. >>>>> > >>>>> > Cheers >>>>> >     toerless >>>>> > >>>>> > On Mon, Oct 28, 2019 at 07:52:59PM +0000, Jeffrey (Zhaohui) >>>>> Zhang wrote: >>>>> > > I Thought u-turn is the most simple comparison leaf vs. >>>>> non-leaf BFR. >>>>> > > >>>>> > > Zzh> The text in the email is seriously misaligned. Looking at >>>>> the picture in the diff link, while you gave a U-turn example, >>>>> though even if BFER2 is not connected to BFR2  but only connected >>>>> to BFER1 (hence no U-turn), then BFER1 is still not a leaf BFER I >>>>> suppose. That's why I said the first sentence of the above >>>>> paragraph is enough to define Leaf BFER while the example itself >>>>> is actually not needed. >>>>> > >>>>> > Argh... ok, had to fix two words, BFIR->BFER and left-hand -> >>>>> right-hand: >>>>> > >>>>> > Consider how redundant disjoint traffic can reach BFER1/BFER2 in >>>>> above >>>>> > picture: When BFER1/BFER2 are Non-Leaf BFER as shown on the >>>>> right hand >>>>> > side, one traffic copy would be forwarded to BFER1 from BFR1, >>>>> but the >>>>> > other one could only reach BFER1 via BFER2, which makes BFER2 a >>>>> > non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forwarding >>>>> > traffic to BFER2 >>>>> > >>>>> > > Zzh> Additionally, in left part of the picture you added, if >>>>> some failure leads to BFR2 to be only reachable via BFER1, then >>>>> BFER1 is no longer a leaf BFER. >>>>> > >>>>> > Added sentence: >>>>> > >>>>> > Note that the BFER in the left hand picture are only >>>>> guaranteed to >>>>> > be leaf-BFR by fitting routing configuration that prohibits transit >>>>> > traffic to pass through a PE, which is commonly applied in these >>>>> > topologies. >>>>> > >>>>> > > I assume you don't reassign BPs when links go up and down. >>>>> > >>>>> > I didn't want to discuss that option in this document. Its >>>>> obviously >>>>> > perfectly feasible, but be yet a big amount of text (especially the >>>>> > considerations how to do this make-before-break. Future doc. >>>>> > >>>>> > > > but subsequent polarization example confuses me. It seems >>>>> that BP 0:6 is assigned to the routed adjacency BFR10 (which is >>>>> actually talked about in Section 4.8). >>>>> > > >>>>> > > Section 4.7 does not mention "routed" at all, so there are no >>>>> routed adjacencies at all used in 4.7. So i am not sure what you >>>>> are confused about. >>>>> > > >>>>> > > Zzh> "The BIFT of each BFR are only populated with BPs that >>>>> are adjacent to the BFR in the BIER-TE topology". >>>>> > >>>>> > Correct text from the introduction. Ok. >>>>> > >>>>> > > Zzh> Since the same 0:6 is in BIFTS of BFR1/BFR2/BFR3 (and I >>>>> suppose in BFR4~BFR9 as well even though not drawn), I assumed >>>>> it's for the "MP2P" routed adjacency to R10; though I then ruled >>>>> that out - but I don't know what 0:6 represent now on BFR1, BFR2, >>>>> and BFR3. >>>>> > >>>>> > Ah. Ok. I thought i could strip down the example to show only the >>>>> > adjacencies relevant to the following discusion, but seemingly this >>>>> > can introduce the confusion you have. >>>>> > >>>>> > So i completed the example with the BP assignment acoss all >>>>> nodes, but >>>>> > added text pointing to a new section further down to discuss the >>>>> > re-use of BP for which thi picture is also an example. >>>>> > >>>>> > (check out the diff, new reuse text to long to copy inline). >>>>> > >>>>> > > The whole purpose of the ECMP BPs is of course to save bits, >>>>> otherwise we'd give each link a separate BP, which would be 6 BP >>>>> to reach to BFR4...BFR7 from BFR1. >>>>> > > >>>>> > > Zzh> The trouble I am having is that the same 0:6 is assigned >>>>> to different things and it's present on all BFR1/BFR2/BFR3. It is >>>>> perhaps an intentional smart design but I have not wrapped my mind >>>>> around it. It's apparently different from the link bundle case, so >>>>> better separate it out and elaborate it (including the DNR flag >>>>> that might be needed here - If the packet arrives on BFR1 with >>>>> 0:6, would the BP reset when it is sent to BFR2/3)? >>>>> > >>>>> > Yes, there was the bug of reusing BP 0:6 across sequential BFR >>>>> along >>>>> > the path, but now the example correctly reuses separate BP at >>>>> > different stages of the paths (BP 0:6 on BFR1, BP 0:7 on >>>>> BFR2/BFR3) and so on. >>>>> > >>>>> > Thanks! >>>>> > >>>>> > > > 4.8.  Routed adjacencies >>>>> > > > >>>>> > > > If I understand it correctly, there is a BP assigned to >>>>> L1/L2/L3 >>>>> > > > respectively (p2p link), and then there are BPs assigned to >>>>> MP2P tunnels (routed adjacency from every BFR) to the L1/L2/L3 >>>>> interface addresses and loopback addresses on BFR2/3. >>>>> > > >>>>> > > Ok that wasn't quite the read i expected. Let me clarify the >>>>> text/picture: >>>>> > > >>>>> > >                    ............... >>>>> > >          ...BFR1--...           ...--L1-- BFR2... >>>>> > >                   ... .Routers. ...--L2--/ >>>>> > >          ...BFR4--...           ...------ BFR3... >>>>> > >                    ...............         | >>>>> > >                                           LO >>>>> > >                     Network Area 1 >>>>> > > >>>>> > > Assume the requirement in the above picture is to explicitly >>>>> steer traffic flows that have arrived at BFR1 or BFR4 via a >>>>> shortest path in the routing underlay "network area 1" to one of >>>>> the following three next segments: (1) BFR2 via link L1, (2) BFR2 >>>>> via link L2, (3) via BFR3. >>>>> > > >>>>> > > To achieve this, both BFR1 and BFR4 are set up with a >>>>> forward_routed adjacency BitPosition towards an address of BFR2 on >>>>> link L1, another forward_routed BitPosition towards an address of >>>>> BFR2 on link L2 and a third forward_routed Bitposition towards a >>>>> node address LO of BFR3. >>>>> > > >>>>> > > Does this clear ip the confusion ? >>>>> > > >>>>> > > Zzh> The picture is badly misaligned. I'll wait till 4.7 >>>>> questions are cleared. >>>>> > >>>>> > Ok. >>>>> > >>>>> > > > If BFR2/3 are also BFERs, then they additionally will have >>>>> BFER BPs. >>>>> > > > On BFR1/4, the BIFT entries for the MP2P BPs for the >>>>> L1/L2/L3/loopback interface addresses of BFR2/3 will use >>>>> forward_routed(interface/loopback address). For a packet to be >>>>> decapsulated on a BFER, there is a need for both the BFER BP and >>>>> another BP (p2p/lan/hub-spoke/routed-adjacency) in the packet (the >>>>> former is for decapsulation and the latter is for getting it there). >>>>> > > >>>>> > > This is not discussed in this section, but you are right - unless >>>>> > > BFR2 or BFR3 is a leaf BFR. In that case, it would just >>>>> leverage the one shared "leaf-BFR" BP, so they do not need a >>>>> per-BFER BP for local_decap(). >>>>> > > >>>>> > > Zzh> Right - shared leaf-BFR BP but still need that BP (the >>>>> key is that we need a BP to get packet to a BFER and then a BP for >>>>> decapsulation). >>>>> > >>>>> > You got it. >>>>> > >>>>> > > > If that???s the case, it???s worth point the above out. >>>>> > > >>>>> > > Hmm... The logic of BFER BPs is totally independent of the >>>>> logic of forward_routed adjacency, so i would worry that repeating >>>>> the explanation of BFER BPs would conflate the forward_routed >>>>> explanation. >>>>> > > >>>>> > > Zzh> It's just that this is a place where all kinds of BPs are >>>>> used so it's good to have a summary (could be a subsection 4.9). >>>>> > >>>>> > Yes, added such a summary. Pls. check. >>>>> > >>>>> > > > Actually, the reason that I thought this is MP2P is that 0:6 >>>>> is present on R1, R2, and R3 (and more I assume) in Figure 12, but >>>>> now I think it can???t be MP2P (so it is not correct to have 0:6 >>>>> present on those routers ??? only the p2p tunnel head/tail should >>>>> have the BP present in the BIFT). The reason is that if it were >>>>> MP2P, any router getting a copy will send it to the endpoint of >>>>> the routed adjacency, causing lots of duplicates. >>>>> > > > >>>>> > > > Am I getting this correct? >>>>> > > >>>>> > > I think you are still explaining from the misunderstsanding >>>>> that the ECMP explanations where about routed adjacencies. >>>>> > > >>>>> > > I have now expanded the somewhat terse text in the BIFT table >>>>> pictures, to make it clear that the ECMP is across multipe >>>>> forward_connected adjacencies in the examples. For example, first >>>>> BIFT picture: >>>>> > > >>>>> > >   BIFT entry in BFR1: >>>>> > > >>>>>  ------------------------------------------------------------------ >>>>> > >   | Index |  Adjacencies                  | >>>>> > > >>>>>  ================================================================== >>>>> > >   | 0:6   |  ECMP({forward_connected(L1, BFR2),                 | >>>>> > >   |       |        forward_connected(L2, BFR2),                 | >>>>> > >   |       |        forward_connected(L3, BFR2)}, seed) >>>>>      | >>>>> > > >>>>>  ------------------------------------------------------------------ >>>>> > > >>>>> > > Of course, an ECMP adjacency can be across any type of >>>>> adjacencies, but all the text/explanations used forward_connected, >>>>> and now the pictures show that explicitly. >>>>> > > >>>>> > > Zzh> I can understand the multi-link case, but the multi-hop >>>>> ECMP case (from BFR1 towards BFR10) is confusing me. It would help >>>>> to give an example how it can be used, WITHOUT worrying about >>>>> polarization. >>>>> > >>>>> > Please check -05 text that has the full set of BIFT listed now: >>>>> > >>>>> > There is  really nothing nothing unique in multi-hop ECMP for >>>>> BIER-TE >>>>> > that we do not also have in any other ECMP, except the >>>>> conclusion that >>>>> > we want to support fast HW hash mechanisms AND allow the >>>>> controller to >>>>> > set up non-polarized multi-hop ECMP AND be able to precalculate >>>>> paths. >>>>> > Hence the specification of ECMP adjacencies to have a controller >>>>> > configurable seed. >>>>> > >>>>> > Btw: The picture is maybe unnecessarily large because i've used >>>>> it for >>>>> > 20 years to explain the same polarization issue for unicast vs >>>>> > multicast, and for multicast only BFR10...BFR4 are relevant >>>>> (ECMP of >>>>> > the PIM/mLDP joins), whereas for unicast/BIER only >>>>> > BFR1...BFR7 are relevant. But being symmetric, the picture makes it >>>>> > clear its the same problem. >>>>> > >>>>> > > >    To inhibit looping in the face of such physical >>>>> misconfiguration, >>>>> > > >    only forward_connected adjacencies are permitted to have >>>>> DNR set, and >>>>> > > >    the link layer destination address of the adjacency >>>>> (e.g.  MAC >>>>> > > >    address) protects against closing the loop.  Link layers >>>>> without port >>>>> > > >    unique link layer addresses should not be used with the >>>>> DNR flag set. >>>>> > > > >>>>> > > > It???s not clear how link layer address helps? >>>>> > > >>>>> > > I have expanded this to >>>>> > > "link layer port unique unicast destination address" >>>>> > > >>>>> > > Aka: MPLS or ethernet have unique link layer destination >>>>> destination addresses (label or destination MAC). If you think >>>>> about incorrectly plugged HDLC links (such as old T1/T3/... >>>>> links), they only have 2 generic addresses, if i remember 1 or 3 >>>>> in the HDLC frame. So when you misplug one of those p2p cables >>>>> wrong, the packets would be incrrectly received by the wrong >>>>> receiver node and then DNR could cause persistent loops only >>>>> solved by TTL. >>>>> > > >>>>> > > Zzh> "Consider in the ring picture that link L4 from BFR3 is >>>>> plugged into the L1 interface of BFRa" - still not sure how >>>>> label/mac helps here. I suppose the ring topology is >>>>> discovered/verified by the control plane and when the miscalling >>>>> happens then the ring will not include the BFR1/BFR2 part and BFR3 >>>>> will not have the DNR set? If ring discovery/varication is not >>>>> done then perhaps we should point out that RPF based on link layer >>>>> address is needed - the key is RPF (which needs unique link layer >>>>> address)? >>>>> > >>>>> > Forget RPF. BIER(-TE) has no RPF (issues). Its just like >>>>> unicast. RPF >>>>> > is just a problem for receiver originated joins like in >>>>> PIM/mLDP, but >>>>> > not unicast/bier(-te)/RSVP-TE. >>>>> > >>>>> > Forward_connected is just like a unicast subnet adjacency to a >>>>> direct >>>>> > neighbor: Interface and L2 addresss of the destination. >>>>> > >>>>> > The controller (could be a human) "assumes" a particular physicial >>>>> > topology, from telemetry/knowledge/whatever. It then calculates the >>>>> > desired BIER-TE topology and pushes it down. This topology is >>>>> meant to >>>>> > be loop free of course wrt to the configured adjacencies. >>>>> > In this BIER-TE topology, BFR3 will have a BP with the >>>>> > forward_connected(L4, MAC-of-BFR2) adjacency. >>>>> > >>>>> > If the cable connecting to L4 is miswired, then BFR3 would still >>>>> send >>>>> > the packets to the MAC address of BFR2, but given how the cable >>>>> > connects to some other node, these packets will be discarded by >>>>> that >>>>> > node. because they're just L2 unicast packets. >>>>> > >>>>> > I think this is equally true when we have normal BIER/MPLS enacp. >>>>> > Those packets too are addressed to the unicast MAC address of the >>>>> > neighbor. >>>>> > >>>>> > Now, if/when he controller recognizes that the physical topology >>>>> has >>>>> > changed, thats a completely different story and not addressed here. >>>>> > Given how we assumed this was a cabling mistake, the controller >>>>> would >>>>> > probably only complain about the miswiring to operations but be >>>>> happy >>>>> > that the forwarding plane just makes packets fail instead of >>>>> loop. If >>>>> > this was a planned change process, then it will be similarily >>>>> > convoluted as it would today be with rewiring cables in an >>>>> > SR-MPLS/SRv6 topology and updating SIDs. >>>>> > >>>>> > > > Because the forwarding is different from BIER forwarding >>>>> (because of [1] above), we might as well introduce an optimization >>>>> here ??? for each BIFT, calculate the F-BM of the BIFT itself (the >>>>> logical ???or??? of all the BPs presented in this BIFT) and then >>>>> use (packet->bitstring & BIFT.F-BM) as the input to >>>>> GetFirst/NextBitPosition(). That should skip many bits. >>>>> > > >>>>> > > Right. But i explicitly removed those optimizations (i had >>>>> them in older draft versions) because the whole idea of this >>>>> picture is solely the comparison with figure 4 of RFC8279. >>>>> > > >>>>> > > Zzh> I think it's worth point that optimization out; you can >>>>> mark it optional if you want to emphasize the similarity to BIER >>>>> forwarding, but since BIER forwarding does do the maskoff step, it >>>>> is very efficient while BIER-TE forwarding does not it the maskoff >>>>> step so this optimization is important. >>>>> > >>>>> > Ok. I simplified the text comparison BIER/BIER-TE wrt. to the FBM >>>>> > rules [1] and [2] and added following paragraph: >>>>> > >>>>> > In BIER, the order of BPs impacts the result of forwarding >>>>> because of [1]. >>>>> > In BIER-TE, forwarding is not impacted by the order of BPs. It is >>>>> > therefore possible to further optimize forwarding than in BIER. For >>>>> > example parallelizing forwarding across multiple FPE cores or >>>>> > distributed linecards does only need to examine an arbitrary >>>>> subset of >>>>> > BP and not evaluate the dependency between BPs. >>>>> > >>>>> > > >    The following pseudocode is comprehensive: >>>>> > > > >>>>> > > > The above sentence reads a bit strange (or lacks some segue). >>>>> > > >>>>> > > I hope not, but maybe best left to a native english speaker >>>>> (RFC-editor). >>>>> > > >>>>> > > The first (RFC8279) pseudocode was simplified. The second one >>>>> is comprehensive. If not comprehensive, whats a good opposite of >>>>> simplified ? >>>>> > > >>>>> > > Zzh> Perhaps "The above simplified pseudocode is elaborated >>>>> further as following"? >>>>> > > Zzh> Jeffrey >>>>> > >>>>> > Done. >>>>> > >>>>> > Thanks a lot. >>>>> > >>>>> > >>>>> > > >>>>> > > > ________________________________________ >>>>> > > > From: BIER [bier-bounces@ietf.org >>>>> >>>> >] >>>>> > > > on behalf of Toerless Eckert [tte@cs.fau.de >>>>> >] >>>>> > > > Sent: Tuesday, July 09, 2019 23:38 >>>>> > > > To: Mike McBride >>>>> > > > Cc: Greg Shepherd; BIER WG; Pascal Thubert (pthubert) >>>>> > > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch >>>>> > > > >>>>> > > > Thanks, Mike >>>>> > > > >>>>> > > > The authors also reviewed the document and concluded that it >>>>> was >>>>> > > > really hard to get into the document context because of too >>>>> many >>>>> > > > forward dependencies. We tried to fix this by adding two >>>>> hopefully >>>>> > > > good & basic examples into the Introduction section and >>>>> using them >>>>> > > > to also add a better definition of the term "BIER-TE >>>>> Topology" in the Introduction. >>>>> > > > Hopefully this makes readin the rest of te document smoother. >>>>> > > > >>>>> > > > Also improved text of Abstract and refined text compariing >>>>> BIER-TE with SR. >>>>> > > > >>>>> > > > >>>>> https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: >>>>> > > > **Atools.ietf.org >>>>> *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A >>>>> > > > tool >>>>> > > > s.ietf.org >>>>> *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R >>>>> > > > jC81 >>>>> > > > >>>>> c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV_eTUEh >>>>> > > > $ >>>>> > > > >>>>> >>>> > > > **Atools.ietf.org >>>>> *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A >>>>> > > > tool >>>>> > > > s.ietf.org >>>>> *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R >>>>> > > > jC81 >>>>> > > > >>>>> c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sNd1njcX >>>>> > > > $> >>>>> > > > >>>>> > > > Cheers >>>>> > > >     Toerless >>>>> > > > >>>>> > > > On Wed, Jun 26, 2019 at 10:39:36AM -0700, Mike McBride wrote: >>>>> > > > > How about three? I support. >>>>> > > > > mike >>>>> > > > > >>>>> > > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd >>>>> >>>> >>>> >> wrote: >>>>> > > > > > >>>>> > > > > > We cannot take two 'yes' votes and WG consensus. >>>>> > > > > > Please, read and respond. If you don't support, then >>>>> please vote as much publicly right here. >>>>> > > > > > >>>>> > > > > > Thanks, >>>>> > > > > > Greg >>>>> > > > > > >>>>> > > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert >>>>> (pthubert) >>>> >>>> >> wrote: >>>>> > > > > >> >>>>> > > > > >> Support: >>>>> > > > > >> >>>>> > > > > >> I see great value in deterministic networks as well as >>>>> IOT (with RPL). >>>>> > > > > >> >>>>> > > > > >> All the best, >>>>> > > > > >> >>>>> > > > > >> Pascal >>>>> > > > > >> >>>>> > > > > >> > -----Original Message----- >>>>> > > > > >> > From: BIER >>>>> > > > > >> > >>>> >>>> >> On >>>>> > > > > >> > Behalf Of Toerless Eckert >>>>> > > > > >> > Sent: mardi 4 juin 2019 02:03 >>>>> > > > > >> > To: Greg Shepherd >>>>> > > > > >> > >>>> >>>> >> >>>>> > > > > >> > Cc: BIER WG >>>> >> >>>>> > > > > >> > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch >>>>> > > > > >> > >>>>> > > > > >> > +1 >>>>> > > > > >> > Obviously support as co-author. >>>>> > > > > >> > >>>>> > > > > >> > On Wed, May 29, 2019 at 12:41:26PM -0700, Greg >>>>> Shepherd wrote: >>>>> > > > > >> > > Please read and respond to this thread w/ or w/o >>>>> support. >>>>> > > > > >> > > >>>>> > > > > >> > > >>>>> https://urldefense.com/v3/__https://datatracker..ietf.org >>>>> > > > > >> > > /doc >>>>> > > > > >> > > >>>>> /draft-ietf-bier-te-arch/__;!8WoA6RjC81c!XvH4AAxfrDjFoK_s >>>>> > > > > >> > > ercw ZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV9eClBj$ >>>>> > > > > >> > > >>>>> >>>> > > > > >> > > doc/ >>>>> > > > > >> > > >>>>> draft-ietf-bier-te-arch/__;!8WoA6RjC81c!UBTGvWWpMHyeiSanx >>>>> > > > > >> > > s6vI b_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sD40kmtH$> >>>>> > > > > >> > > >>>>> > > > > >> > > Vote ends 5 June 2019. >>>>> > > > > >> > > >>>>> > > > > >> > > Thanks, >>>>> > > > > >> > > Shep >>>>> > > > > >> > > (chairs) >>>>> > > > > >> > >>>>> > > > > >> > > _______________________________________________ >>>>> > > > > >> > > BIER mailing list >>>>> > > > > >> > > BIER@ietf.org >>>>> > >>>>> > > > > >> > > >>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/ >>>>> > > > > >> > > list >>>>> > > > > >> > > >>>>> info/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eE >>>>> > > > > >> > > NOs4 l_qdsXF0KwZD82cJLDFFNT2WVXWX$ >>>>> > > > > >> > > >>>>> >>>> > > > > >> > > list >>>>> > > > > >> > > >>>>> info/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6b >>>>> > > > > >> > > oAAW 4nrqju8UCLOgiuXc8Y_6sKn2KoAT$> >>>>> > > > > >> > >>>>> > > > > >> > _______________________________________________ >>>>> > > > > >> > BIER mailing list >>>>> > > > > >> > BIER@ietf.org >>>>> > >>>>> > > > > >> > >>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/li >>>>> > > > > >> > stin >>>>> > > > > >> > >>>>> fo/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4 >>>>> > > > > >> > l_qd >>>>> > > > > >> > sXF0KwZD82cJLDFFNT2WVXWX$ >>>>> > > > > >> > >>>>> >>>> > > > > >> > stin >>>>> > > > > >> > >>>>> fo/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW >>>>> > > > > >> > 4nrq >>>>> > > > > >> > ju8UCLOgiuXc8Y_6sKn2KoAT$> >>>>> > > > > > >>>>> > > > > > _______________________________________________ >>>>> > > > > > BIER mailing list >>>>> > > > > > BIER@ietf.org >>>>> > >>>>> > > > > > >>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listi >>>>> > > > > > nfo/ >>>>> > > > > > >>>>> bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsX >>>>> > > > > > F0Kw >>>>> > > > > > ZD82cJLDFFNT2WVXWX$ >>>>> > > > > > >>>>> >>>> > > > > > nfo/ >>>>> > > > > > >>>>> bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju >>>>> > > > > > 8UCL >>>>> > > > > > OgiuXc8Y_6sKn2KoAT$> >>>>> > > > >>>>> > > > -- >>>>> > > > --- >>>>> > > > tte@cs.fau.de >>>> > >>>>> > > > >>>>> > > > _______________________________________________ >>>>> > > > BIER mailing list >>>>> > > > BIER@ietf.org >>>> > >>>>> > > > >>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ >>>>> > > > bier >>>>> > > > >>>>> __;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82 >>>>> > > > cJLD >>>>> > > > FFNT2WVXWX$ >>>>> > > > >>>>> >>>> > > > bier >>>>> > > > >>>>> __;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiu >>>>> > > > Xc8Y >>>>> > > > _6sKn2KoAT$> >>>>> > > >>>>> > > -- >>>>> > > --- >>>>> > > tte@cs.fau.de >>>>> > >>>>> > -- >>>>> > --- >>>>> > tte@cs.fau.de >>>>> > >>>>> > _______________________________________________ >>>>> > BIER mailing list >>>>> > BIER@ietf.org >>>>> > >>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier >>>>> > >>>>> __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx4 >>>>> > 1_jWV3YUA6D$ >>>>> >>>>> -- >>>>> --- >>>>> tte@cs.fau.de >>>>> >>>>> _______________________________________________ >>>>> BIER mailing list >>>>> BIER@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/bier >>>>> >>>> _______________________________________________ >>>> BIER mailing list >>>> BIER@ietf.org >>>> https://www.ietf.org/mailman/listinfo/bier >> _______________________________________________ >> BIER mailing list >> BIER@ietf.org >> https://www.ietf.org/mailman/listinfo/bier > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > From nobody Tue Feb 25 16:02:21 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D301E3A0902 for ; Tue, 25 Feb 2020 16:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 8c0dZla7_f7W for ; Tue, 25 Feb 2020 16:02:15 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46D493A0903 for ; Tue, 25 Feb 2020 16:02:15 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 06B66548005; Wed, 26 Feb 2020 01:02:07 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id EEA11440040; Wed, 26 Feb 2020 01:02:06 +0100 (CET) Date: Wed, 26 Feb 2020 01:02:06 +0100 From: Toerless Eckert To: Lou Berger Cc: gjshep@gmail.com, "bier@ietf.org" , "Jeffrey (Zhaohui) Zhang" Message-ID: <20200226000206.GA31874@faui48f.informatik.uni-erlangen.de> References: <11ab30da-8701-b491-6162-5a69aa9d6965@labn.net> <20200220035620.GA42520@faui48f.informatik.uni-erlangen.de> <20200225015718.GC20521@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 00:02:20 -0000 Lou, *: Here is the next and hopefully final github version for your review. If you can give a thumbsup i will upload to datatracker, and the WG chairs would also be able to finalize WG last-call. https://raw.githubusercontent.com/toerless/bier-te-arch/7e996deb1dcd18596d4864c750f6e7541d737e6f/draft-ietf-bier-te-arch.txt And here the diff to -05, last version before taking input from your review into account. Given how 1.1 was removed, this seems like the most logical comparison point. http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-bier-te-arch-05.txt&url2=https://raw.githubusercontent.com/toerless/bier-te-arch/7e996deb1dcd18596d4864c750f6e7541d737e6f/draft-ietf-bier-te-arch.txt Changes to -05 are now easily seen as limited textual: - Name change BIER-TE to BIER-PE - Explanations using steering/policy - [RFC-editor remove note] about name change. - BIER-TE controller host -> BIER-TE Controller (unrelated to Lou) Detailled answers, explanations below. Cheers Toerless On Tue, Feb 25, 2020 at 01:19:26PM -0500, Lou Berger wrote: > Hi Toerless, > >     This revision will mostly remove my objection related to the use of TE > by the document.  I suspect in section 7.2 you have two instances where > "traffic" needs to be replaced with "path". Fixed > More substantively, I think you > should delete section 1.1 and leave its subject  matter  to > eckert-teas-bier-te-framework to be covered/worked out.  If you want to keep > it, I think there's a longer discussion need on its contents. Removed section 1.1 from the text. I have added to the beginning of 1. an [RFC-editor: pls. remove ] section explaining the naming change so late in the process to further IETF/IESG reviewers (if i had just put it into the changelog i fear it will be overlooked by reviewers). For what is worth, i did like the idea of having explanations about relationship of BIER-PE to BIER-TE, especially because the framework is IMHO not yet in a state to serve as a good even draft reference (it was only pointed to in section 1.1, so also removed as reference). How about this: If IESG review wants to have that type of explanation back, i'll knock on your door to revive and help me fix up that text. > FWIW I still think the introduction of the a new term "Path Engineering", > rather than reusing one of the existing IETF terms for the same capability > ("routing policy", "policy based routing", "path steering") seems  likely to > lead to more confusion then if you stuck with an established term.  I'll > leave this to others to argue. Ok, second time around you're suggesting this, i now owe you an explanation why i think these terms are technically misleading: (its a bit long, that why i avoided the explanation in before). All the established terms you propose come from unicast and never had a re-definition/re-interpretation for IP multicast. Using any of these terms in the name would easily lead to people (especially when not reading the doc) think the BIER solution here works like in both IP multicast and BIER in before BIER-PE: By impacting the underlying unicast (forward) routing (BIER) or RPF (reverse path) routing (IP Multicast). Examples: You can use static muRIB routes to steer traffic for IP Multicast or BIER. You can also use separate IGP (Flex-)topologies to do the same dynamically. Thats all great stuff to describe in a BIER-TE framework document (in conjunction with BIER), but that is also the stuff i do not want BIER-PE to be confused with because there are technical limitations to those unicast routing policy/ steering approaches when its applied to trees: Try to use any of the pre-existing mechanisms for unicast routing policy or path steering with BIER or IP multicast to build steiner trees. Not generally possible. With BIER-PE, no problem. Same thing with disjoint trees (even MRT flex-algo's wouldn't achieve the same). IMHO, the term "Path Engineering" is free of this mis-name-recognition because it is a new. The name also hints at the fact that this could be in support of, or a component of traffic engineering. And wrt to minimizing the change to the long held name, the hamming distance is just one character/word. So it's the 'safest/most-conservative/logical' name change this late in the process. As i said, i would be happier with a more unique new descriptive name like "Tree Steering Bitstrings" (BIER-TSB), but i do not feel like making such a big naming change without more explicit support by more members of the WG this late in the process. > I think this covers all the detailed discussion points below. If not, can > you extract the ones you'd like to keep discussing? Still sad about the missed opportunity of fixing this naming problem earlier wrt. to the mail you sopposedly sent, and happy to beat myself up if that ended up being my fault, but i guess i shouldn't continue to dig into that issue if it would turn out to be someone else's fault. Otherwise i am fine. If you want to give the doc now a thumbs up in response to the last call, that would be great ;-) EOF > Thanks again for the responsiveness to my comments! > > Lou > > On 2/24/2020 8:57 PM, Toerless Eckert wrote: > > Hi Lou, round 2. > > > > Here is the github pre-version of -07 of the draft: > > > > https://raw.githubusercontent.com/toerless/bier-te-arch/62378f618299307349a934fc6ad78e1af9e16771/draft-ietf-bier-te-arch.txt > > > > Diff: > > > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-bier-te-arch-06.txt&url2=https://raw.githubusercontent.com/toerless/bier-te-arch/62378f618299307349a934fc6ad78e1af9e16771/draft-ietf-bier-te-arch.txt > > > > I would appreciate if you could try to partition your opinions into > > things you think MUST be solved before passing the document to IESG (for > > IETF/IESG review) and those issues that could then be solved when it is > > in IETF/IESG review. For example, i think a final choice of name could > > be something that shouldn't block the document to take this step. > > > > If this goes along into IETF107, it would be great if you could find the > > time to be at the BIER-WG meeting. > > > > Summary of changes: > > > > 1. Changed abbreviation BIER-TE to BIER-PE, otherwise we can not unconfuse > > readers of the difference between BIER-PE and BIER-TE. > > > > Relationship: BIER-TE = (BIER with steering: BIER-PE or othre) plus resource > > allocation mechanisms, and this document only describes BIER-PE. > > > > 2. Removed all use of the term "path engineering" from the (explanatory) text, > > replaced with path / tree steering or policy in the text (like RFC8402). > > > > 3. In result, "Path Engineering" is now solely a name for the mechanism. > > In the same way as SR introduced "Segment Routing" as a name, but explains > > what it does with the terms "steering" and "policy". > > > > 4. I think a unique new term not already used in before is helpful because > > what BIER-PE does is quite unique and new. And reusing an existing term > > always brings out more people wanting to argue about the accuracy of how > > their pre-existing term is applied. > > > > I hope we can have a deterministic, short latency decision mechanism for > > the term. After we've decided on the term, its easy to update the doc > > again with that new term (%s/PE/XXX/g). > > > > I'll throw "Tree Steering Bitstrings" (BIER-TSB) into the ring. > > > > [The main issue with name change now is that we've gotten some followup > > work such as YANG model that also refers to BIER-TE meaning BIER-PE, so > > that would also need to change name. See below for my reply to that naming > > change you said you suggested .] > > > > 5. I also refined the section 1.1 that was introduced in -06 to mention > > e.g.: PCE. > > > > Specific answers to the mail thread below. > > > > Cheers > > Toerless > > > > On Fri, Feb 21, 2020 at 03:01:51PM -0500, Lou Berger wrote: > > > > [ Would have been nice if you could have commented a bit earlier. > > > > But i can understand how a few years is not enough time ;-P > > > > (actually no kidding, i really can.) ] > > > I raised this as an issue last march - at both the Chair and AD level.  I > > > thought I made the same point to you privately after one the presentations > > > at IETF101, but if you don't remember it, I accept that I didn't. > > Did you include the authors ? I could not find any email about this. > > Also no forwarded emails from AD/chairs i could find. If you still have > > a copy, pls. PM. This is annoying... > > > > I do not remember naming issue discussed after IETF101, but i am > > sure i was preoccupied with technical issues and might not have > > given it too much thought back then. Of course there was a lot of > > time since IETF101 to bring up the naming point again... > > > > > Well that document seems like a fine place to describe how BIER-RP (routing > > > policy) can be used to deliver BIER-TE. > > > > > [...] > > > Do we really need a new term to describe here?  I find zero (0) instances of > > > Path Engineering in any RFC.  Routing policy (and policy-based routing) on > > > the other hand are fairly well established terms in the industry.  I think > > > this just sows seeds for future confusion on this topic. > > > > > > Why is "routing policy" not good enough for what is being defining here?  I > > > again point out, this is the term being used in SPRING for basically the > > > equivalent function/purpose. (Yes the forwarding mechanism is different, but > > > the objective is not.) > > SPRING did establish new unique name/terminologies, like "Segment". > > As said above, i think its best we do the samegiven how unique this is. > > > > Looking at rfc8402, "steering" and "policy" are used in verbal > > explanations, without providing specific terminology for them, > > so i did follow that example too. > > > > > > but kept name BIER-TE (see below). > > > > > > > > - Added section 1.1 explaining how BIER-TE relates to traffic > > > > engineering, naming use-cases where its for example beneficial standalone and > > > > and what it could be combined with for more comprehensive TE solutions, > > > > but also stating that those integrations are outside the scope of this > > > > document. > > > So this section seems to miss what has been going on in traffic engineering > > > / TEAS for the last 5+ years (i.e., controller-based TE approaches) > > I don't think that is a correct assessment. BIER-PE itself requires a > > controller to calculate paths / trees. With or without other traffic > > engineering components. That component is called the BIER-PE controller and > > has been in the draft forever. > > > > The new section 1.1 added in response to your review relates that > > BIER-TE controller to an overall TE controller, using the PCE example > > and refrerence to it. > > > > There is really nothing more that a BIER-WG document could or should > > do. What this document intended to support is whats necessary and > > sufficient to get the forwarding plane implemented/standardized. > > Everything else is for independent followup work in TEAS IMHO, > > such as reviving the framwork draft. > > > > >   and then goes on describe path steering  in a very brief way.  I read this as > > > saying that BIER *could* do TE in the future and *can* support routing > > > policy and path steering today. > > Even stronger: BIER-PE is always meant to ONLY do that (steering), > > any additional TE functions wold come from independent other components. > > And simple examples for that are given in section 1.1. > > > > > > - changed "traffic engineering" term in the whole doc to "path engineering", > > > > where appropriate. > > > While this is appreciated, I'm not sure it's helpful.  As stated above, I > > > think the introduction of the new PE term is confusing as the continued use > > > of BIER-TE. > > See above. We can certainly not use "BIER-TE" to mean two different > > things, so i hope that concern is resolved. > > > > > > The mayority of customers i talked to only used RSVP-TE for path > > > > engineering, and not for anything more. Several didn't even know it > > > > can do bandwidth reservation. Nobody knew it could do latency > > > > guarantees, because nobody knows an implementation that supports that. > > > > [All reasons btw. why replacing RSVP-TE with SR happened in the industry.] > > > While I'm going to avoid getting into product differentiators and marketing, > > > you're not mentioning that even those products and customers who didn't > > > support/use per LSP queuing, did available resource bookkeeping and even > > > admission control. > > I think the point is mood now (given how we'll change the name BIER-TE > > to a better term). But maybe to better explain: We started calling this > > TE so customers would easier understand that this is intended to give > > them what they actually use RSVP-TE for (Traffic Steering), and not > > necessarily all that RSVP-TE could do beyond that. A central controller > > is assumed to exist in BIER-PE too. > > > > Given how SR also shows how you can be successful in deployment > > without betting on 'TE' name recognition, i have no quarrels in > > changing the name. As said above, its motly a question of finding > > the best term and changing the followup works names too. > > > > > > In any case, the name BIER-TE was selected to reduce confusion > > > > with customers, not to maximize naming correctness in IETF. > > > umm, the IETF is a standards body not an industry marketing forum, so I'm > > > unclear how this point helps your argument. > > It's not am argument or justification, just an explanation. Not only to you, > > but also the WG. > > > > >  It seems that you're saying > > > that if we call it BIER-TE we can market it in place of existing IETF TE > > > solutions - even though it doesn't yet have the TE capability covered in > > > draft-eckert-teas-bier-te-framework. > > .... > > > > > Assuming I'm reading it right, this just confirms to me that the current > > > work needs to be renamed and that draft-eckert-teas-bier-te-framework will > > > define BIER-TE. > > Yes. BIER-TE could btw. rely on BIER-PE or BIER + other path steering > > (e.g.: flex-algos), so BIER-PE is only one option for the path-steering > > options for BIER-TE. > > > > > My point wasn't that BIER=SR, but rather both deliver support for path > > > steering and policy based routing. > > Yepp, i hope we're in violent agreement. > > > > Cheers > > Toerless > > > > > Thanks for being responsive! > > > > > > Lou > > > > > > > All the SR options do really require that you set up multicast trees with > > > > e.g.: replication-SIDs that together form the equivalent of a > > > > multicast tree, like you would have built with RSVP-TE. Except that > > > > the signaling how to build the tree is left for someone else, like > > > > PCECC. (AFAIK, i may not be on top of all details). In BIER-TE, > > > > there is no such per-tree state on transit nodes. > > > > > > > > Instead of a 256 bit bitstring in BIER-TE think of a header with up to 256 SIDs > > > > (e.g.: 128 bit per SID in SRv6). That would be the SR equivalent of BIER-TE. > > > > Just a bit less ( ;-) ) less efficient on the wire than BIER-TE and extremely > > > > harder to parse. > > > > > > > > Cheers > > > > Toerless > > > > > > > > > > > > On Wed, Feb 19, 2020 at 06:38:38PM -0500, Lou Berger wrote: > > > > > Hi, > > > > > > > > > >     I have no issue or objection to the mechanisms being defined in this > > > > > document as much as they go, but I was quite disappointed that despite the > > > > > name of the document and use of 'bier-te'  to see that the document doesn't > > > > > define any traffic engineering support, at least as far as the term has been > > > > > used in IETF RFCs.  In particular it totally lacks any discussion of > > > > > resources usage and/or allocation.  What it currently describes certainly > > > > > provides good and useful path/traffic steering that can be used to support > > > > > policy-based routing.  Basically it does the same as what is defined by > > > > > draft-ietf-spring-segment-routing-policy. > > > > > > > > > > I personally (not speaking for the related WGs that I chair) would prefer to > > > > > see this document be revised  to include resource allocation that would > > > > > allow BIER-TE to support TE usage such as DetNet.  Barring such an addition, > > > > > I'm against publication of this document as is and I think the document > > > > > should be recast and renamed to be aligned with the SR example, i.e., BIER > > > > > routing policy (or path steering). > > > > > > > > > > Lou > > > > > > > > > > On 2/18/20 3:45 PM, Greg Shepherd wrote: > > > > > > Thanks Toerless and Jeffrey > > > > > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-bier-te-arch/ > > > > > > > > > > > > One more week of WGLC. Please read the latest rev and respond to this > > > > > > thread w/wo support. > > > > > > > > > > > > Chairs > > > > > > (Shep) > > > > > > > > > > > > > > > > > > On Tue, Feb 18, 2020 at 12:07 PM Jeffrey (Zhaohui) Zhang > > > > > > > > > > > > wrote: > > > > > > > > > > > > Hi Toerless, > > > > > > > > > > > > Thanks! > > > > > > I support moving this to the next stage. > > > > > > > > > > > > Jeffrey > > > > > > > > > > > > On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote: > > > > > > > Thanks Jeff > > > > > > > > > > > > > > I have now pushed out -05 with the answers and hopefully > > > > > > resolution to > > > > > > > your points in email below.  Biggest addition was a section about > > > > > > > reuse of BPs (without DNR) which came out of the confusion i > > > > > > think the > > > > > > > reuse in the ECMP example raised. I was afraid so far to explan > > > > > > that > > > > > > > as it may not be easy to absorb and ultimately is stuff only > > > > > > > controller developers need to understand, but hopefully useful. > > > > > > > And then of course the summary of BP optimizatins you asked for > > > > > > > > > > > > > > Diff from last version i sent you: > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: > > > > > > > **Araw.githubusercontent.com > > > > > > *toerless*bier-te-arch*master*draft-ietf-b > > > > > > > ier-te-arch-05.1.txt&url2=http:**Atools.ietf.org > > > > > > *id*draft-ietf-bier-te > > > > > > > > > > > > > -arch-05.txt__;Ly8vLy8vLy8vLy8!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzH > > > > > > > OCr0fZkLPbgg3CPNu0PyrWsrFx41_jWX2At8V-$ > > > > > > > > > > > > > > full -04 -> 05 diff: > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=http:* > > > > > > > *Atools.ietf.org > > > > > > *id*draft-ietf-bier-te-arch-04.txt&url2=http:**Atools. > > > > > > > ietf.org > > > > > > *id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk > > > > > > > !VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx41_jWancpziv$ > > > > > > > > > > > > > > Comments inline below. > > > > > > > > > > > > > > Cheers > > > > > > >     toerless > > > > > > > > > > > > > > On Mon, Oct 28, 2019 at 07:52:59PM +0000, Jeffrey (Zhaohui) > > > > > > Zhang wrote: > > > > > > > > I Thought u-turn is the most simple comparison leaf vs. > > > > > > non-leaf BFR. > > > > > > > > > > > > > > > > Zzh> The text in the email is seriously misaligned. Looking at > > > > > > the picture in the diff link, while you gave a U-turn example, > > > > > > though even if BFER2 is not connected to BFR2  but only connected > > > > > > to BFER1 (hence no U-turn), then BFER1 is still not a leaf BFER I > > > > > > suppose. That's why I said the first sentence of the above > > > > > > paragraph is enough to define Leaf BFER while the example itself > > > > > > is actually not needed. > > > > > > > > > > > > > > Argh... ok, had to fix two words, BFIR->BFER and left-hand -> > > > > > > right-hand: > > > > > > > > > > > > > > Consider how redundant disjoint traffic can reach BFER1/BFER2 in > > > > > > above > > > > > > > picture: When BFER1/BFER2 are Non-Leaf BFER as shown on the > > > > > > right hand > > > > > > > side, one traffic copy would be forwarded to BFER1 from BFR1, > > > > > > but the > > > > > > > other one could only reach BFER1 via BFER2, which makes BFER2 a > > > > > > > non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forwarding > > > > > > > traffic to BFER2 > > > > > > > > > > > > > > > Zzh> Additionally, in left part of the picture you added, if > > > > > > some failure leads to BFR2 to be only reachable via BFER1, then > > > > > > BFER1 is no longer a leaf BFER. > > > > > > > > > > > > > > Added sentence: > > > > > > > > > > > > > > Note that the BFER in the left hand picture are only > > > > > > guaranteed to > > > > > > > be leaf-BFR by fitting routing configuration that prohibits transit > > > > > > > traffic to pass through a PE, which is commonly applied in these > > > > > > > topologies. > > > > > > > > > > > > > > > I assume you don't reassign BPs when links go up and down. > > > > > > > > > > > > > > I didn't want to discuss that option in this document. Its > > > > > > obviously > > > > > > > perfectly feasible, but be yet a big amount of text (especially the > > > > > > > considerations how to do this make-before-break. Future doc. > > > > > > > > > > > > > > > > but subsequent polarization example confuses me. It seems > > > > > > that BP 0:6 is assigned to the routed adjacency BFR10 (which is > > > > > > actually talked about in Section 4.8). > > > > > > > > > > > > > > > > Section 4.7 does not mention "routed" at all, so there are no > > > > > > routed adjacencies at all used in 4.7. So i am not sure what you > > > > > > are confused about. > > > > > > > > > > > > > > > > Zzh> "The BIFT of each BFR are only populated with BPs that > > > > > > are adjacent to the BFR in the BIER-TE topology". > > > > > > > > > > > > > > Correct text from the introduction. Ok. > > > > > > > > > > > > > > > Zzh> Since the same 0:6 is in BIFTS of BFR1/BFR2/BFR3 (and I > > > > > > suppose in BFR4~BFR9 as well even though not drawn), I assumed > > > > > > it's for the "MP2P" routed adjacency to R10; though I then ruled > > > > > > that out - but I don't know what 0:6 represent now on BFR1, BFR2, > > > > > > and BFR3. > > > > > > > > > > > > > > Ah. Ok. I thought i could strip down the example to show only the > > > > > > > adjacencies relevant to the following discusion, but seemingly this > > > > > > > can introduce the confusion you have. > > > > > > > > > > > > > > So i completed the example with the BP assignment acoss all > > > > > > nodes, but > > > > > > > added text pointing to a new section further down to discuss the > > > > > > > re-use of BP for which thi picture is also an example. > > > > > > > > > > > > > > (check out the diff, new reuse text to long to copy inline). > > > > > > > > > > > > > > > The whole purpose of the ECMP BPs is of course to save bits, > > > > > > otherwise we'd give each link a separate BP, which would be 6 BP > > > > > > to reach to BFR4...BFR7 from BFR1. > > > > > > > > > > > > > > > > Zzh> The trouble I am having is that the same 0:6 is assigned > > > > > > to different things and it's present on all BFR1/BFR2/BFR3. It is > > > > > > perhaps an intentional smart design but I have not wrapped my mind > > > > > > around it. It's apparently different from the link bundle case, so > > > > > > better separate it out and elaborate it (including the DNR flag > > > > > > that might be needed here - If the packet arrives on BFR1 with > > > > > > 0:6, would the BP reset when it is sent to BFR2/3)? > > > > > > > > > > > > > > Yes, there was the bug of reusing BP 0:6 across sequential BFR > > > > > > along > > > > > > > the path, but now the example correctly reuses separate BP at > > > > > > > different stages of the paths (BP 0:6 on BFR1, BP 0:7 on > > > > > > BFR2/BFR3) and so on. > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > 4.8.  Routed adjacencies > > > > > > > > > > > > > > > > > > If I understand it correctly, there is a BP assigned to > > > > > > L1/L2/L3 > > > > > > > > > respectively (p2p link), and then there are BPs assigned to > > > > > > MP2P tunnels (routed adjacency from every BFR) to the L1/L2/L3 > > > > > > interface addresses and loopback addresses on BFR2/3. > > > > > > > > > > > > > > > > Ok that wasn't quite the read i expected. Let me clarify the > > > > > > text/picture: > > > > > > > > > > > > > > > >                    ............... > > > > > > > >          ...BFR1--...           ...--L1-- BFR2... > > > > > > > >                   ... .Routers. ...--L2--/ > > > > > > > >          ...BFR4--...           ...------ BFR3... > > > > > > > >                    ...............         | > > > > > > > >                                           LO > > > > > > > >                     Network Area 1 > > > > > > > > > > > > > > > > Assume the requirement in the above picture is to explicitly > > > > > > steer traffic flows that have arrived at BFR1 or BFR4 via a > > > > > > shortest path in the routing underlay "network area 1" to one of > > > > > > the following three next segments: (1) BFR2 via link L1, (2) BFR2 > > > > > > via link L2, (3) via BFR3. > > > > > > > > > > > > > > > > To achieve this, both BFR1 and BFR4 are set up with a > > > > > > forward_routed adjacency BitPosition towards an address of BFR2 on > > > > > > link L1, another forward_routed BitPosition towards an address of > > > > > > BFR2 on link L2 and a third forward_routed Bitposition towards a > > > > > > node address LO of BFR3. > > > > > > > > > > > > > > > > Does this clear ip the confusion ? > > > > > > > > > > > > > > > > Zzh> The picture is badly misaligned. I'll wait till 4.7 > > > > > > questions are cleared. > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > If BFR2/3 are also BFERs, then they additionally will have > > > > > > BFER BPs. > > > > > > > > > On BFR1/4, the BIFT entries for the MP2P BPs for the > > > > > > L1/L2/L3/loopback interface addresses of BFR2/3 will use > > > > > > forward_routed(interface/loopback address). For a packet to be > > > > > > decapsulated on a BFER, there is a need for both the BFER BP and > > > > > > another BP (p2p/lan/hub-spoke/routed-adjacency) in the packet (the > > > > > > former is for decapsulation and the latter is for getting it there). > > > > > > > > > > > > > > > > This is not discussed in this section, but you are right - unless > > > > > > > > BFR2 or BFR3 is a leaf BFR. In that case, it would just > > > > > > leverage the one shared "leaf-BFR" BP, so they do not need a > > > > > > per-BFER BP for local_decap(). > > > > > > > > > > > > > > > > Zzh> Right - shared leaf-BFR BP but still need that BP (the > > > > > > key is that we need a BP to get packet to a BFER and then a BP for > > > > > > decapsulation). > > > > > > > > > > > > > > You got it. > > > > > > > > > > > > > > > > If that???s the case, it???s worth point the above out. > > > > > > > > > > > > > > > > Hmm... The logic of BFER BPs is totally independent of the > > > > > > logic of forward_routed adjacency, so i would worry that repeating > > > > > > the explanation of BFER BPs would conflate the forward_routed > > > > > > explanation. > > > > > > > > > > > > > > > > Zzh> It's just that this is a place where all kinds of BPs are > > > > > > used so it's good to have a summary (could be a subsection 4.9). > > > > > > > > > > > > > > Yes, added such a summary. Pls. check. > > > > > > > > > > > > > > > > Actually, the reason that I thought this is MP2P is that 0:6 > > > > > > is present on R1, R2, and R3 (and more I assume) in Figure 12, but > > > > > > now I think it can???t be MP2P (so it is not correct to have 0:6 > > > > > > present on those routers ??? only the p2p tunnel head/tail should > > > > > > have the BP present in the BIFT). The reason is that if it were > > > > > > MP2P, any router getting a copy will send it to the endpoint of > > > > > > the routed adjacency, causing lots of duplicates. > > > > > > > > > > > > > > > > > > Am I getting this correct? > > > > > > > > > > > > > > > > I think you are still explaining from the misunderstsanding > > > > > > that the ECMP explanations where about routed adjacencies. > > > > > > > > > > > > > > > > I have now expanded the somewhat terse text in the BIFT table > > > > > > pictures, to make it clear that the ECMP is across multipe > > > > > > forward_connected adjacencies in the examples. For example, first > > > > > > BIFT picture: > > > > > > > > > > > > > > > >   BIFT entry in BFR1: > > > > > > > > > > > > > >  ------------------------------------------------------------------ > > > > > > > >   | Index |  Adjacencies                  | > > > > > > > > > > > > > >  ================================================================== > > > > > > > >   | 0:6   |  ECMP({forward_connected(L1, BFR2),                 | > > > > > > > >   |       |        forward_connected(L2, BFR2),                 | > > > > > > > >   |       |        forward_connected(L3, BFR2)}, seed) > > > > > >      | > > > > > > > > > > > > > >  ------------------------------------------------------------------ > > > > > > > > > > > > > > > > Of course, an ECMP adjacency can be across any type of > > > > > > adjacencies, but all the text/explanations used forward_connected, > > > > > > and now the pictures show that explicitly. > > > > > > > > > > > > > > > > Zzh> I can understand the multi-link case, but the multi-hop > > > > > > ECMP case (from BFR1 towards BFR10) is confusing me. It would help > > > > > > to give an example how it can be used, WITHOUT worrying about > > > > > > polarization. > > > > > > > > > > > > > > Please check -05 text that has the full set of BIFT listed now: > > > > > > > > > > > > > > There is  really nothing nothing unique in multi-hop ECMP for > > > > > > BIER-TE > > > > > > > that we do not also have in any other ECMP, except the > > > > > > conclusion that > > > > > > > we want to support fast HW hash mechanisms AND allow the > > > > > > controller to > > > > > > > set up non-polarized multi-hop ECMP AND be able to precalculate > > > > > > paths. > > > > > > > Hence the specification of ECMP adjacencies to have a controller > > > > > > > configurable seed. > > > > > > > > > > > > > > Btw: The picture is maybe unnecessarily large because i've used > > > > > > it for > > > > > > > 20 years to explain the same polarization issue for unicast vs > > > > > > > multicast, and for multicast only BFR10...BFR4 are relevant > > > > > > (ECMP of > > > > > > > the PIM/mLDP joins), whereas for unicast/BIER only > > > > > > > BFR1...BFR7 are relevant. But being symmetric, the picture makes it > > > > > > > clear its the same problem. > > > > > > > > > > > > > > > >    To inhibit looping in the face of such physical > > > > > > misconfiguration, > > > > > > > > >    only forward_connected adjacencies are permitted to have > > > > > > DNR set, and > > > > > > > > >    the link layer destination address of the adjacency > > > > > > (e.g.  MAC > > > > > > > > >    address) protects against closing the loop.  Link layers > > > > > > without port > > > > > > > > >    unique link layer addresses should not be used with the > > > > > > DNR flag set. > > > > > > > > > > > > > > > > > > It???s not clear how link layer address helps? > > > > > > > > > > > > > > > > I have expanded this to > > > > > > > > "link layer port unique unicast destination address" > > > > > > > > > > > > > > > > Aka: MPLS or ethernet have unique link layer destination > > > > > > destination addresses (label or destination MAC). If you think > > > > > > about incorrectly plugged HDLC links (such as old T1/T3/... > > > > > > links), they only have 2 generic addresses, if i remember 1 or 3 > > > > > > in the HDLC frame. So when you misplug one of those p2p cables > > > > > > wrong, the packets would be incrrectly received by the wrong > > > > > > receiver node and then DNR could cause persistent loops only > > > > > > solved by TTL. > > > > > > > > > > > > > > > > Zzh> "Consider in the ring picture that link L4 from BFR3 is > > > > > > plugged into the L1 interface of BFRa" - still not sure how > > > > > > label/mac helps here. I suppose the ring topology is > > > > > > discovered/verified by the control plane and when the miscalling > > > > > > happens then the ring will not include the BFR1/BFR2 part and BFR3 > > > > > > will not have the DNR set? If ring discovery/varication is not > > > > > > done then perhaps we should point out that RPF based on link layer > > > > > > address is needed - the key is RPF (which needs unique link layer > > > > > > address)? > > > > > > > > > > > > > > Forget RPF. BIER(-TE) has no RPF (issues). Its just like > > > > > > unicast. RPF > > > > > > > is just a problem for receiver originated joins like in > > > > > > PIM/mLDP, but > > > > > > > not unicast/bier(-te)/RSVP-TE. > > > > > > > > > > > > > > Forward_connected is just like a unicast subnet adjacency to a > > > > > > direct > > > > > > > neighbor: Interface and L2 addresss of the destination. > > > > > > > > > > > > > > The controller (could be a human) "assumes" a particular physicial > > > > > > > topology, from telemetry/knowledge/whatever. It then calculates the > > > > > > > desired BIER-TE topology and pushes it down. This topology is > > > > > > meant to > > > > > > > be loop free of course wrt to the configured adjacencies. > > > > > > > In this BIER-TE topology, BFR3 will have a BP with the > > > > > > > forward_connected(L4, MAC-of-BFR2) adjacency. > > > > > > > > > > > > > > If the cable connecting to L4 is miswired, then BFR3 would still > > > > > > send > > > > > > > the packets to the MAC address of BFR2, but given how the cable > > > > > > > connects to some other node, these packets will be discarded by > > > > > > that > > > > > > > node. because they're just L2 unicast packets. > > > > > > > > > > > > > > I think this is equally true when we have normal BIER/MPLS enacp. > > > > > > > Those packets too are addressed to the unicast MAC address of the > > > > > > > neighbor. > > > > > > > > > > > > > > Now, if/when he controller recognizes that the physical topology > > > > > > has > > > > > > > changed, thats a completely different story and not addressed here. > > > > > > > Given how we assumed this was a cabling mistake, the controller > > > > > > would > > > > > > > probably only complain about the miswiring to operations but be > > > > > > happy > > > > > > > that the forwarding plane just makes packets fail instead of > > > > > > loop. If > > > > > > > this was a planned change process, then it will be similarily > > > > > > > convoluted as it would today be with rewiring cables in an > > > > > > > SR-MPLS/SRv6 topology and updating SIDs. > > > > > > > > > > > > > > > > Because the forwarding is different from BIER forwarding > > > > > > (because of [1] above), we might as well introduce an optimization > > > > > > here ??? for each BIFT, calculate the F-BM of the BIFT itself (the > > > > > > logical ???or??? of all the BPs presented in this BIFT) and then > > > > > > use (packet->bitstring & BIFT.F-BM) as the input to > > > > > > GetFirst/NextBitPosition(). That should skip many bits. > > > > > > > > > > > > > > > > Right. But i explicitly removed those optimizations (i had > > > > > > them in older draft versions) because the whole idea of this > > > > > > picture is solely the comparison with figure 4 of RFC8279. > > > > > > > > > > > > > > > > Zzh> I think it's worth point that optimization out; you can > > > > > > mark it optional if you want to emphasize the similarity to BIER > > > > > > forwarding, but since BIER forwarding does do the maskoff step, it > > > > > > is very efficient while BIER-TE forwarding does not it the maskoff > > > > > > step so this optimization is important. > > > > > > > > > > > > > > Ok. I simplified the text comparison BIER/BIER-TE wrt. to the FBM > > > > > > > rules [1] and [2] and added following paragraph: > > > > > > > > > > > > > > In BIER, the order of BPs impacts the result of forwarding > > > > > > because of [1]. > > > > > > > In BIER-TE, forwarding is not impacted by the order of BPs. It is > > > > > > > therefore possible to further optimize forwarding than in BIER. For > > > > > > > example parallelizing forwarding across multiple FPE cores or > > > > > > > distributed linecards does only need to examine an arbitrary > > > > > > subset of > > > > > > > BP and not evaluate the dependency between BPs. > > > > > > > > > > > > > > > >    The following pseudocode is comprehensive: > > > > > > > > > > > > > > > > > > The above sentence reads a bit strange (or lacks some segue). > > > > > > > > > > > > > > > > I hope not, but maybe best left to a native english speaker > > > > > > (RFC-editor). > > > > > > > > > > > > > > > > The first (RFC8279) pseudocode was simplified. The second one > > > > > > is comprehensive. If not comprehensive, whats a good opposite of > > > > > > simplified ? > > > > > > > > > > > > > > > > Zzh> Perhaps "The above simplified pseudocode is elaborated > > > > > > further as following"? > > > > > > > > Zzh> Jeffrey > > > > > > > > > > > > > > Done. > > > > > > > > > > > > > > Thanks a lot. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > > > > > > From: BIER [bier-bounces@ietf.org > > > > > > > > > > > >] > > > > > > > > > on behalf of Toerless Eckert [tte@cs.fau.de > > > > > > >] > > > > > > > > > Sent: Tuesday, July 09, 2019 23:38 > > > > > > > > > To: Mike McBride > > > > > > > > > Cc: Greg Shepherd; BIER WG; Pascal Thubert (pthubert) > > > > > > > > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch > > > > > > > > > > > > > > > > > > Thanks, Mike > > > > > > > > > > > > > > > > > > The authors also reviewed the document and concluded that it > > > > > > was > > > > > > > > > really hard to get into the document context because of too > > > > > > many > > > > > > > > > forward dependencies. We tried to fix this by adding two > > > > > > hopefully > > > > > > > > > good & basic examples into the Introduction section and > > > > > > using them > > > > > > > > > to also add a better definition of the term "BIER-TE > > > > > > Topology" in the Introduction. > > > > > > > > > Hopefully this makes readin the rest of te document smoother. > > > > > > > > > > > > > > > > > > Also improved text of Abstract and refined text compariing > > > > > > BIER-TE with SR. > > > > > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: > > > > > > > > > **Atools.ietf.org > > > > > > *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A > > > > > > > > > tool > > > > > > > > > s.ietf.org > > > > > > *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R > > > > > > > > > jC81 > > > > > > > > > > > > > > > c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV_eTUEh > > > > > > > > > $ > > > > > > > > > > > > > > > > > > > > > > > **Atools.ietf.org > > > > > > *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A > > > > > > > > > tool > > > > > > > > > s.ietf.org > > > > > > *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R > > > > > > > > > jC81 > > > > > > > > > > > > > > > c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sNd1njcX > > > > > > > > > $> > > > > > > > > > > > > > > > > > > Cheers > > > > > > > > >     Toerless > > > > > > > > > > > > > > > > > > On Wed, Jun 26, 2019 at 10:39:36AM -0700, Mike McBride wrote: > > > > > > > > > > How about three? I support. > > > > > > > > > > mike > > > > > > > > > > > > > > > > > > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd > > > > > > > > > > > > > > > > >> wrote: > > > > > > > > > > > > > > > > > > > > > > We cannot take two 'yes' votes and WG consensus. > > > > > > > > > > > Please, read and respond. If you don't support, then > > > > > > please vote as much publicly right here. > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > Greg > > > > > > > > > > > > > > > > > > > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert > > > > > > (pthubert) > > > > > > > > > > >> wrote: > > > > > > > > > > >> > > > > > > > > > > >> Support: > > > > > > > > > > >> > > > > > > > > > > >> I see great value in deterministic networks as well as > > > > > > IOT (with RPL). > > > > > > > > > > >> > > > > > > > > > > >> All the best, > > > > > > > > > > >> > > > > > > > > > > >> Pascal > > > > > > > > > > >> > > > > > > > > > > >> > -----Original Message----- > > > > > > > > > > >> > From: BIER > > > > > > > > > > >> > > > > > > > > > > > >> On > > > > > > > > > > >> > Behalf Of Toerless Eckert > > > > > > > > > > >> > Sent: mardi 4 juin 2019 02:03 > > > > > > > > > > >> > To: Greg Shepherd > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > >> > Cc: BIER WG > > > > > >> > > > > > > > > > > >> > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch > > > > > > > > > > >> > > > > > > > > > > > >> > +1 > > > > > > > > > > >> > Obviously support as co-author. > > > > > > > > > > >> > > > > > > > > > > > >> > On Wed, May 29, 2019 at 12:41:26PM -0700, Greg > > > > > > Shepherd wrote: > > > > > > > > > > >> > > Please read and respond to this thread w/ or w/o > > > > > > support. > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > https://urldefense.com/v3/__https://datatracker..ietf.org > > > > > > > > > > >> > > /doc > > > > > > > > > > >> > > > > > > > > /draft-ietf-bier-te-arch/__;!8WoA6RjC81c!XvH4AAxfrDjFoK_s > > > > > > > > > > >> > > ercw ZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV9eClBj$ > > > > > > > > > > >> > > > > > > > > > > > > > > > > > >> > > doc/ > > > > > > > > > > >> > > > > > > > > draft-ietf-bier-te-arch/__;!8WoA6RjC81c!UBTGvWWpMHyeiSanx > > > > > > > > > > >> > > s6vI b_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sD40kmtH$> > > > > > > > > > > >> > > > > > > > > > > > > >> > > Vote ends 5 June 2019. > > > > > > > > > > >> > > > > > > > > > > > > >> > > Thanks, > > > > > > > > > > >> > > Shep > > > > > > > > > > >> > > (chairs) > > > > > > > > > > >> > > > > > > > > > > > >> > > _______________________________________________ > > > > > > > > > > >> > > BIER mailing list > > > > > > > > > > >> > > BIER@ietf.org > > > > > > > > > > > > > > > > > >> > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/ > > > > > > > > > > >> > > list > > > > > > > > > > >> > > > > > > > > info/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eE > > > > > > > > > > >> > > NOs4 l_qdsXF0KwZD82cJLDFFNT2WVXWX$ > > > > > > > > > > >> > > > > > > > > > > > > > > > > > >> > > list > > > > > > > > > > >> > > > > > > > > info/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6b > > > > > > > > > > >> > > oAAW 4nrqju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > > > > > > > >> > > > > > > > > > > > >> > _______________________________________________ > > > > > > > > > > >> > BIER mailing list > > > > > > > > > > >> > BIER@ietf.org > > > > > > > > > > > > > > > > > >> > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/li > > > > > > > > > > >> > stin > > > > > > > > > > >> > > > > > > > fo/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4 > > > > > > > > > > >> > l_qd > > > > > > > > > > >> > sXF0KwZD82cJLDFFNT2WVXWX$ > > > > > > > > > > >> > > > > > > > > > > > > > > > > >> > stin > > > > > > > > > > >> > > > > > > > fo/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW > > > > > > > > > > >> > 4nrq > > > > > > > > > > >> > ju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > BIER mailing list > > > > > > > > > > > BIER@ietf.org > > > > > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listi > > > > > > > > > > > nfo/ > > > > > > > > > > > > > > > > > bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsX > > > > > > > > > > > F0Kw > > > > > > > > > > > ZD82cJLDFFNT2WVXWX$ > > > > > > > > > > > > > > > > > > > > > > > > > > > nfo/ > > > > > > > > > > > > > > > > > bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju > > > > > > > > > > > 8UCL > > > > > > > > > > > OgiuXc8Y_6sKn2KoAT$> > > > > > > > > > > > > > > > > > > -- > > > > > > > > > --- > > > > > > > > > tte@cs.fau.de > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > BIER mailing list > > > > > > > > > BIER@ietf.org > > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ > > > > > > > > > bier > > > > > > > > > > > > > > > __;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82 > > > > > > > > > cJLD > > > > > > > > > FFNT2WVXWX$ > > > > > > > > > > > > > > > > > > > > > > > bier > > > > > > > > > > > > > > > __;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiu > > > > > > > > > Xc8Y > > > > > > > > > _6sKn2KoAT$> > > > > > > > > > > > > > > > > -- > > > > > > > > --- > > > > > > > > tte@cs.fau.de > > > > > > > > > > > > > > -- > > > > > > > --- > > > > > > > tte@cs.fau.de > > > > > > > > > > > > > > _______________________________________________ > > > > > > > BIER mailing list > > > > > > > BIER@ietf.org > > > > > > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier > > > > > > > > > > > > > __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx4 > > > > > > > 1_jWV3YUA6D$ > > > > > > > > > > > > -- > > > > > > --- > > > > > > tte@cs.fau.de > > > > > > > > > > > > _______________________________________________ > > > > > > BIER mailing list > > > > > > BIER@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/bier > > > > > > > > > > > _______________________________________________ > > > > > BIER mailing list > > > > > BIER@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/bier > > > _______________________________________________ > > > BIER mailing list > > > BIER@ietf.org > > > https://www.ietf.org/mailman/listinfo/bier > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org > > https://www.ietf.org/mailman/listinfo/bier > > > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier -- --- tte@cs.fau.de From nobody Wed Feb 26 13:33:51 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 488503A0795 for ; Wed, 26 Feb 2020 13:33:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 vh6ZGXJQ25Bw for ; Wed, 26 Feb 2020 13:33:45 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 F1F663A078A for ; Wed, 26 Feb 2020 13:33:44 -0800 (PST) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 01QLLPbu026050; Wed, 26 Feb 2020 16:33:28 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049459.ppops.net-00191d01. with ESMTP id 2ydxh9kgv5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 26 Feb 2020 16:33:27 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 01QLXPVE004481; Wed, 26 Feb 2020 16:33:26 -0500 Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [135.66.87.47]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 01QLXJn1004344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 26 Feb 2020 16:33:20 -0500 Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [127.0.0.1]) by zlp27126.vci.att.com (Service) with ESMTP id 786B54030734; Wed, 26 Feb 2020 21:33:19 +0000 (GMT) Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (unknown [130.9.129.152]) by zlp27126.vci.att.com (Service) with ESMTPS id 107C14030733; Wed, 26 Feb 2020 21:33:19 +0000 (GMT) Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.48]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0468.000; Wed, 26 Feb 2020 16:33:18 -0500 From: "BRUNGARD, DEBORAH A" To: Toerless Eckert , Lou Berger CC: "gjshep@gmail.com" , "bier@ietf.org" , "Jeffrey (Zhaohui) Zhang" Thread-Topic: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK Thread-Index: AQHV53213EDGuluOYkqDU6m9Z5Dxz6gjyEEAgAKgGICABRpOAIABEmgAgABfvQCAAQP34A== Date: Wed, 26 Feb 2020 21:33:17 +0000 Message-ID: References: <11ab30da-8701-b491-6162-5a69aa9d6965@labn.net> <20200220035620.GA42520@faui48f.informatik.uni-erlangen.de> <20200225015718.GC20521@faui48f.informatik.uni-erlangen.de> <20200226000206.GA31874@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200226000206.GA31874@faui48f.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.239] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-26_07:2020-02-26, 2020-02-26 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 spamscore=0 phishscore=0 mlxscore=0 lowpriorityscore=0 mlxlogscore=999 priorityscore=1501 bulkscore=0 suspectscore=0 impostorscore=0 adultscore=0 malwarescore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002260126 Archived-At: Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 21:33:49 -0000 SGkgVG9lcmxlc3MsDQoNCllvdXIgY29tbWVudDoNCj4gPiBJIHdvdWxkIGFwcHJlY2lhdGUgaWYg eW91IGNvdWxkIHRyeSB0byBwYXJ0aXRpb24geW91ciBvcGluaW9ucyBpbnRvDQo+ID4gdGhpbmdz IHlvdSB0aGluayBNVVNUIGJlIHNvbHZlZCBiZWZvcmUgcGFzc2luZyB0aGUgZG9jdW1lbnQgdG8g SUVTRyAoZm9yDQo+ID4gSUVURi9JRVNHIHJldmlldykgYW5kIHRob3NlIGlzc3VlcyB0aGF0IGNv dWxkIHRoZW4gYmUgc29sdmVkIHdoZW4gaXQgaXMNCj4gPiBpbiBJRVRGL0lFU0cgcmV2aWV3LiBG b3IgZXhhbXBsZSwgaSB0aGluayBhIGZpbmFsIGNob2ljZSBvZiBuYW1lIGNvdWxkDQo+ID4gYmUg c29tZXRoaW5nIHRoYXQgc2hvdWxkbid0IGJsb2NrIHRoZSBkb2N1bWVudCB0byB0YWtlIHRoaXMg c3RlcC4NCj4gPg0KDQpXYWl0aW5nIGZvciB0aGUgSUVTRyB0byAibmFtZSIgeW91ciB0ZWNobm9s b2d5IHdpbGwgZGVmaW5pdGVseSByZXN1bHQgaW4gYSBtdWNoIGxvbmdlciBkZWxheSB0aGFuIHNv cnRpbmcgb3V0IGluIFdHIExhc3QgQ2FsbC4gWW91IG5vdGVkLCB5b3UgaGFkIHByZXNlbnRlZCBh biBlYXJsaWVyIHZlcnNpb24gb2YgdGhpcyBkb2N1bWVudCBpbiBURUFTLCBidXQgaXQgaXMgYXQg dGhlIHRpbWUgb2YgV0cgTGFzdCBDYWxsIChwZXIgdGhlIGNoYXJ0ZXIpLCB0aGUgVEVBUy9NUExT L2FuZCBwcm9iYWJseSBQQ0UsIHNob3VsZCBoYXZlIGJlZW4gbm90aWZpZWQgKEkgaW5jbHVkZWQg TVBMUyBhcyB5b3UgaGF2ZSBtdWx0aXBsZSBwcm9wb3NhbHMgb24gdXNlIG9mIE1QTFMgbGFiZWxz KS4gSSd2ZSBjb250YWN0ZWQgeW91ciBCSUVSIENoYWlycy9BRCB0byBleHRlbmQgYXQgbGVhc3Qg YSB3ZWVrIHRoZSBMYXN0IENhbGwuDQoNCk9uIG5hbWluZywgYXMgTG91IG5vdGVkLCBwcmVmZXJl bmNlIGlzIHRvIGFsaWduIHRlcm1pbm9sb2d5IHVzZWQgaW4gb3RoZXIgd29ya2luZyBncm91cHMg LSBlc3BlY2lhbGx5IHdpdGhpbiB0aGUgcm91dGluZyBhcmVhLiBUaGUgUkZDLWVkaXRvciBhbHNv IHJlY29tbWVuZHMgY2FyZWZ1bCB1c2Ugb2YgYWJicmV2aWF0aW9ucyAtIGl0IGlzIGV4cGVjdGVk IG5ldyBhYmJyZXZpYXRpb25zIGFyZSBhZGRlZCB0byBhIGxpc3Q6DQpodHRwczovL3d3dy5yZmMt ZWRpdG9yLm9yZy9tYXRlcmlhbHMvYWJicmV2LmV4cGFuc2lvbi50eHQNCg0KQXMgeW91IGNhbiBz ZWUsIFBFIGlzIGFscmVhZHkgdXNlZC4gQW5kIGluIHRoZSBSb3V0aW5nIEFyZWEsIGZvciBvdXIg UEUgYWJicmV2aWF0aW9uLCB3ZSBjb3VsZCBzYXkgaXQgc2hvdWxkIGhhdmUgYW4gYXN0ZXJpc2vw n5iKIFlvdXIganVzdGlmaWNhdGlvbiBpcyB0aGF0ICJQRSIgaXMgc2hvcnQgc2ltaWxhciB0byAi VEUiLCBidXQgZm9yIHRoZSBSb3V0aW5nIEFyZWEsIGl0IG5lZWRzIHRvIGJlIGVpdGhlciBkaWZm ZXJlbnQgb3IgbWF5YmUgYWRkIGEgbGV0dGVyICh0aHJlZSBsZXR0ZXJzKS4gSWYgeW91IGxvb2sg dGhydSB0aGUgbGlzdCwgdGhhdCdzIHdoYXQgb3RoZXJzIGhhdmUgZG9uZSBlLmcuIGluIFNQUklO RywgdGhleSBoYXZlIGEgbmV3IGRvY3VtZW50IGFsc28gdXNpbmcgIlBFIiBkaWZmZXJlbnRseSBi dXQgaXQncyBhYmJyZXZpYXRlZCAiRVBFIi4NCg0KQXMgd2UgYWxsIGVuam95IHRyeWluZyB0byBu YW1lICJzb21ldGhpbmciLCBJIGNoZWNrZWQgUENFIGRvY3VtZW50cyAoYXMgeW91IG5vdGVkIGlu IHRoZSBkb2N1bWVudCwgQklFUi1QRSByZXF1aXJlcyBTRE4vUENFIGNvbnRyb2xsZXIpLiBBcyBM b3Ugc2F5cyAtIHRoZXJlIGlzIG5vIG1lbnRpb24gb2YgInBhdGggZW5naW5lZXJpbmciIGVpdGhl ciBpbiBQQ0UgZG9jdW1lbnRzIG9yIGFueSBJRVRGIGRvY3VtZW50cy4gU28gbWF5YmUgIlBFIiBp biB0aGUgc3RyaW5nIGlzIG5vdCB0aGUgYmVzdC4gTXkgMi1jZW50cywgaG93IGFib3V0ICJTUkVQ LUJJRVIiIChTb3VyY2UgUm91dGVkIEVuZ2luZWVyZWQgUGF0aCk/IEhhdmUgZnVuIG5hbWluZyAt IGJ1dCBwbGVhc2Ugc3RhYmlsaXplIG9uIGEgbmFtZSBiZWZvcmUgaGFuZC1vZmYgdG8gdGhlIElF U0cgLSBvdGhlcndpc2UgdGhlIElFU0cgd2lsbCBoYXZlIGFsbCB0aGUgZnVuLg0KDQpBcyBCSUVS LVBFIHJlcXVpcmVzIHVzZSBvZiBhbiBTRE4vUENFIGNvbnRyb2xsZXIgLSBoZXJlJ3MgbXkgZWFy bHkgQUQgY29tbWVudHMgLSBwbGVhc2UgbWVudGlvbiB0aGlzIGVhcmxpZXIgaW4gdGhlIGRvY3Vt ZW50IC0gYWJzdHJhY3QsIGludHJvLiBlLmcuIHRoZSBTUFJJTkcgZG9jdW1lbnQgaGFzIGFzIHRo ZSB0aXRsZSAiY2VudHJhbGl6ZWQiIEVQRS4gVGhlIGNlbnRyYWxpemVkIGNvbnRyb2xsZXIgaXMg dGhlIGtleSBkaWZmZXJlbnRpYXRvciBmb3IgQklFUi1QRS4gQWxzbywgaW4gc2VjdGlvbiA4LCB0 aGVyZSBpcyBubyBuZWVkIHRvIGJlIGNyaXRpY2FsIG9mIFJTVlAtVEUsIHdlIGFyZSBub3QgdHJ5 aW5nIHRvIG1hcmtldCBvbmUgdnMuIHRoZSBvdGhlcjoNCiJTUiBhaW1zIHRvIGVuYWJsZSBsaWdo dHdlaWdodCBwYXRoIHN0ZWVyaW5nIHZpYSBsb29zZSBzb3VyY2Ugcm91dGluZy4gQ29tcGFyZWQg dG8gaXRzIG1vcmUgaGVhdnktd2VpZ2h0IHByZWRlY2Vzc29yIFJTVlAtVEUsIFNSIGRvZXMgZm9y IGV4YW1wbGUgbm90IHJlcXVpcmUgcGVyLXBhdGggc2lnbmFsaW5nIHRvIGVhY2ggb2YgdGhlc2Ug aG9wcy4iDQoNClJTVlAtVEUgcHJvdmlkZXMgdmVyeSBkaWZmZXJlbnQgY2FwYWJpbGl0aWVzIHRo YW4gU1IgYW5kIEJJRVIuIFdpdGggUlNWUC1URSBnbGFzc2VzIG9uLCBvbmUgY291bGQgc2F5IFNS IGFuZCBCSUVSIHByb3ZpZGUgdmVyeSBsaW1pdGVkIGNhcGFiaWxpdGllcy4gQW5kIGJvdGggU1Ig YW5kIEJJRVIgcmVxdWlyZSB2ZXJ5IGhlYXZ5LXdlaWdodCBTRE4gY29udHJvbGxlcnMuIFNvIGl0 IGp1c3QgZGVwZW5kcyB3aGVyZSB0aGUgb3BlcmF0b3IvdmVuZG9yIHdhbnRzIHRvIHB1dCB0aGVp ciAid2VpZ2h0Ii4gQnV0IGl0J3Mgbm90IGZvciBJRVRGIHRvIGRvIHRoZSBqdWRnZW1lbnQuIFNh bWUgZm9yIHNvbWUgb2YgeW91ciBwcm8gQklFUi1QRSBjb21tZW50cyB2cy4gU1IuIFNSIGhhcyBp dCdzIGFkdmFudGFnZXMgb3ZlciBCSUVSIHRvby4gQW4gUkZDIGlzIG5vdCBmb3IgbWFya2V0aW5n IG9uZSB0ZWNobm9sb2d5IHZzLiBhbm90aGVyLg0KDQpIb3BlZnVsbHkgbXkgd29ya2luZyBncm91 cHMgKFRFQVMsIE1QTFMsIFBDRSkgYXJlIGdpdmVuIHRoZSAiaGVhZHMtdXAiIHNvb24gLSBJJ2Qg cHJlZmVyIGRpc2N1c3Npb24gZHVyaW5nIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIHZzLiBJRVRG IExhc3QgQ2FsbCBvciBteSBuZWVkaW5nIHRvIGVudGVyIGEgIkRpc2N1c3MiIHdhaXRpbmcgZm9y IHRoZWlyIHJldmlldy4NCg0KVGhhbmtzIQ0KRGVib3JhaA0KKEFEIGhhdCBvbikNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEJJRVIgPGJpZXItYm91bmNlc0BpZXRmLm9yZz4g T24gQmVoYWxmIE9mIFRvZXJsZXNzIEVja2VydA0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMjUs IDIwMjAgNzowMiBQTQ0KVG86IExvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+DQpDYzogZ2pz aGVwQGdtYWlsLmNvbTsgYmllckBpZXRmLm9yZzsgSmVmZnJleSAoWmhhb2h1aSkgWmhhbmcgPHp6 aGFuZz00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPg0KU3ViamVjdDogUmU6IFtCaWVyXSBX R0xDIC0gZHJhZnQtaWV0Zi1iaWVyLXRlLWFyY2ggMSBXRUVLDQoNCkxvdSwgKjoNCg0KSGVyZSBp cyB0aGUgbmV4dCBhbmQgaG9wZWZ1bGx5IGZpbmFsIGdpdGh1YiB2ZXJzaW9uIGZvciB5b3VyIHJl dmlldy4NCklmIHlvdSBjYW4gZ2l2ZSBhIHRodW1ic3VwIGkgd2lsbCB1cGxvYWQgdG8gZGF0YXRy YWNrZXIsDQphbmQgdGhlIFdHIGNoYWlycyB3b3VsZCBhbHNvIGJlIGFibGUgdG8gZmluYWxpemUg V0cgbGFzdC1jYWxsLg0KDQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cHMtM0FfX3Jhdy5naXRodWJ1c2VyY29udGVudC5jb21fdG9lcmxlc3NfYmllci0yRHRl LTJEYXJjaF83ZTk5NmRlYjFkY2QxODU5NmQ0ODY0Yzc1MGY2ZTc1NDFkNzM3ZTZmX2RyYWZ0LTJE aWV0Zi0yRGJpZXItMkR0ZS0yRGFyY2gudHh0JmQ9RHdJRkF3JmM9TEZZWi1vOV9IVU1lTVRTUWlj dmpJZyZyPTZVaEdwVzlsd2k5ZE03allseFhEOHcmbT1NVzNTMG12aE5OOXVxNVZtalhkTlhHd3Np c1ZQNXd6ek84cjA0aDRhUDBvJnM9aGJWVW10Nm9iLUlsZ3QwMGtpT2x3QU9jQTY4a2xkbHh2TzBM cXEtZ0t4byZlPSANCg0KQW5kIGhlcmUgdGhlIGRpZmYgdG8gLTA1LCBsYXN0IHZlcnNpb24gYmVm b3JlIHRha2luZyBpbnB1dCBmcm9tIHlvdXIgcmV2aWV3IGludG8gYWNjb3VudC4NCkdpdmVuIGhv dyAxLjEgd2FzIHJlbW92ZWQsIHRoaXMgc2VlbXMgbGlrZSB0aGUgbW9zdCBsb2dpY2FsIGNvbXBh cmlzb24gcG9pbnQuDQoNCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwLTNBX190b29scy5pZXRmLm9yZ190b29sc19yZmNkaWZmX3JmY2RpZmYucHlodC0zRnVy bDEtM0RodHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaWRfZHJhZnQtMkRpZXRmLTJEYmllci0yRHRl LTJEYXJjaC0yRDA1LnR4dC0yNnVybDItM0RodHRwcy0zQV9fcmF3LmdpdGh1YnVzZXJjb250ZW50 LmNvbV90b2VybGVzc19iaWVyLTJEdGUtMkRhcmNoXzdlOTk2ZGViMWRjZDE4NTk2ZDQ4NjRjNzUw ZjZlNzU0MWQ3MzdlNmZfZHJhZnQtMkRpZXRmLTJEYmllci0yRHRlLTJEYXJjaC50eHQmZD1Ed0lG QXcmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9NlVoR3BXOWx3aTlkTTdqWWx4WEQ4dyZtPU1X M1MwbXZoTk45dXE1Vm1qWGROWEd3c2lzVlA1d3p6TzhyMDRoNGFQMG8mcz1qVHZyR2FncUhnUEtu ZVRVcE92TmtlWWNsN2N4RFNWMzJnTGstLXZ5emRRJmU9IA0KDQpDaGFuZ2VzIHRvIC0wNSBhcmUg bm93IGVhc2lseSBzZWVuIGFzIGxpbWl0ZWQgdGV4dHVhbDoNCi0gTmFtZSBjaGFuZ2UgQklFUi1U RSB0byBCSUVSLVBFDQotIEV4cGxhbmF0aW9ucyB1c2luZyBzdGVlcmluZy9wb2xpY3kNCi0gW1JG Qy1lZGl0b3IgcmVtb3ZlIG5vdGVdIGFib3V0IG5hbWUgY2hhbmdlLg0KLSBCSUVSLVRFIGNvbnRy b2xsZXIgaG9zdCAtPiBCSUVSLVRFIENvbnRyb2xsZXIgKHVucmVsYXRlZCB0byBMb3UpDQoNCkRl dGFpbGxlZCBhbnN3ZXJzLCBleHBsYW5hdGlvbnMgYmVsb3cuDQoNCkNoZWVycw0KICAgIFRvZXJs ZXNzDQoNCk9uIFR1ZSwgRmViIDI1LCAyMDIwIGF0IDAxOjE5OjI2UE0gLTA1MDAsIExvdSBCZXJn ZXIgd3JvdGU6DQo+IEhpIFRvZXJsZXNzLA0KPiANCj4gwqDCoMKgIFRoaXMgcmV2aXNpb24gd2ls bCBtb3N0bHkgcmVtb3ZlIG15IG9iamVjdGlvbiByZWxhdGVkIHRvIHRoZSB1c2Ugb2YgVEUNCj4g YnkgdGhlIGRvY3VtZW50LsKgIEkgc3VzcGVjdCBpbiBzZWN0aW9uIDcuMiB5b3UgaGF2ZSB0d28g aW5zdGFuY2VzIHdoZXJlDQo+ICJ0cmFmZmljIiBuZWVkcyB0byBiZSByZXBsYWNlZCB3aXRoICJw YXRoIi4NCg0KRml4ZWQNCg0KPsKgTW9yZSBzdWJzdGFudGl2ZWx5LCBJIHRoaW5rIHlvdQ0KPiBz aG91bGQgZGVsZXRlIHNlY3Rpb24gMS4xIGFuZCBsZWF2ZSBpdHMgc3ViamVjdMKgIG1hdHRlcsKg IHRvDQo+IGVja2VydC10ZWFzLWJpZXItdGUtZnJhbWV3b3JrIHRvIGJlIGNvdmVyZWQvd29ya2Vk IG91dC7CoCBJZiB5b3Ugd2FudCB0byBrZWVwDQo+IGl0LCBJIHRoaW5rIHRoZXJlJ3MgYSBsb25n ZXIgZGlzY3Vzc2lvbiBuZWVkIG9uIGl0cyBjb250ZW50cy4NCg0KUmVtb3ZlZCBzZWN0aW9uIDEu MSBmcm9tIHRoZSB0ZXh0Lg0KDQpJIGhhdmUgYWRkZWQgdG8gdGhlIGJlZ2lubmluZyBvZiAxLiBh biBbUkZDLWVkaXRvcjogcGxzLiByZW1vdmUgXSBzZWN0aW9uDQpleHBsYWluaW5nIHRoZSBuYW1p bmcgY2hhbmdlIHNvIGxhdGUgaW4gdGhlIHByb2Nlc3MgdG8gZnVydGhlciBJRVRGL0lFU0cNCnJl dmlld2VycyAoaWYgaSBoYWQganVzdCBwdXQgaXQgaW50byB0aGUgY2hhbmdlbG9nIGkgZmVhciBp dCB3aWxsIA0KYmUgb3Zlcmxvb2tlZCBieSByZXZpZXdlcnMpLg0KDQpGb3Igd2hhdCBpcyB3b3J0 aCwgaSBkaWQgbGlrZSB0aGUgaWRlYSBvZiBoYXZpbmcgZXhwbGFuYXRpb25zIA0KYWJvdXQgcmVs YXRpb25zaGlwIG9mIEJJRVItUEUgdG8gQklFUi1URSwgZXNwZWNpYWxseSBiZWNhdXNlIHRoZQ0K ZnJhbWV3b3JrIGlzIElNSE8gbm90IHlldCBpbiBhIHN0YXRlIHRvIHNlcnZlIGFzIGEgZ29vZCBl dmVuIGRyYWZ0DQpyZWZlcmVuY2UgKGl0IHdhcyBvbmx5IHBvaW50ZWQgdG8gaW4gc2VjdGlvbiAx LjEsIHNvIGFsc28gcmVtb3ZlZA0KYXMgcmVmZXJlbmNlKS4NCg0KSG93IGFib3V0IHRoaXM6IElm IElFU0cgcmV2aWV3IHdhbnRzIHRvIGhhdmUgdGhhdCB0eXBlIG9mIGV4cGxhbmF0aW9uIGJhY2ss DQppJ2xsIGtub2NrIG9uIHlvdXIgZG9vciB0byByZXZpdmUgYW5kIGhlbHAgbWUgZml4IHVwIHRo YXQgdGV4dC4NCg0KPiBGV0lXIEkgc3RpbGwgdGhpbmsgdGhlIGludHJvZHVjdGlvbiBvZiB0aGUg YSBuZXcgdGVybSAiUGF0aCBFbmdpbmVlcmluZyIsDQo+IHJhdGhlciB0aGFuIHJldXNpbmcgb25l IG9mIHRoZSBleGlzdGluZyBJRVRGIHRlcm1zIGZvciB0aGUgc2FtZSBjYXBhYmlsaXR5DQo+ICgi cm91dGluZyBwb2xpY3kiLCAicG9saWN5IGJhc2VkIHJvdXRpbmciLCAicGF0aCBzdGVlcmluZyIp IHNlZW1zwqAgbGlrZWx5IHRvDQo+IGxlYWQgdG8gbW9yZSBjb25mdXNpb24gdGhlbiBpZiB5b3Ug c3R1Y2sgd2l0aCBhbiBlc3RhYmxpc2hlZCB0ZXJtLsKgIEknbGwNCj4gbGVhdmUgdGhpcyB0byBv dGhlcnMgdG8gYXJndWUuDQoNCk9rLCBzZWNvbmQgdGltZSBhcm91bmQgeW91J3JlIHN1Z2dlc3Rp bmcgdGhpcywgaSBub3cgb3dlIHlvdSBhbiBleHBsYW5hdGlvbg0Kd2h5IGkgdGhpbmsgdGhlc2Ug dGVybXMgYXJlIHRlY2huaWNhbGx5IG1pc2xlYWRpbmc6DQooaXRzIGEgYml0IGxvbmcsIHRoYXQg d2h5IGkgYXZvaWRlZCB0aGUgZXhwbGFuYXRpb24gaW4gYmVmb3JlKS4NCg0KQWxsIHRoZSBlc3Rh Ymxpc2hlZCB0ZXJtcyB5b3UgcHJvcG9zZSBjb21lIGZyb20gdW5pY2FzdCBhbmQNCm5ldmVyIGhh ZCBhIHJlLWRlZmluaXRpb24vcmUtaW50ZXJwcmV0YXRpb24gZm9yIElQIG11bHRpY2FzdC4NCg0K VXNpbmcgYW55IG9mIHRoZXNlIHRlcm1zIGluIHRoZSBuYW1lIHdvdWxkIGVhc2lseSBsZWFkIHRv DQpwZW9wbGUgKGVzcGVjaWFsbHkgd2hlbiBub3QgcmVhZGluZyB0aGUgZG9jKSB0aGluayB0aGUN CkJJRVIgc29sdXRpb24gaGVyZSB3b3JrcyBsaWtlIGluIGJvdGggSVAgbXVsdGljYXN0IGFuZA0K QklFUiBpbiBiZWZvcmUgQklFUi1QRTogQnkgaW1wYWN0aW5nIHRoZSB1bmRlcmx5aW5nIHVuaWNh c3QNCihmb3J3YXJkKSByb3V0aW5nIChCSUVSKSBvciBSUEYgKHJldmVyc2UgcGF0aCkgcm91dGlu ZyAoSVAgTXVsdGljYXN0KS4gDQoNCkV4YW1wbGVzOiBZb3UgY2FuIHVzZSBzdGF0aWMgbXVSSUIg cm91dGVzIHRvIHN0ZWVyIHRyYWZmaWMgZm9yDQpJUCBNdWx0aWNhc3Qgb3IgQklFUi4gWW91IGNh biBhbHNvIHVzZSBzZXBhcmF0ZSBJR1AgKEZsZXgtKXRvcG9sb2dpZXMNCnRvIGRvIHRoZSBzYW1l IGR5bmFtaWNhbGx5LiBUaGF0cyBhbGwgZ3JlYXQgc3R1ZmYgdG8gZGVzY3JpYmUgaW4gYQ0KQklF Ui1URSBmcmFtZXdvcmsgZG9jdW1lbnQgKGluIGNvbmp1bmN0aW9uIHdpdGggQklFUiksIGJ1dCB0 aGF0DQppcyBhbHNvIHRoZSBzdHVmZiBpIGRvIG5vdCB3YW50IEJJRVItUEUgdG8gYmUgY29uZnVz ZWQgd2l0aA0KYmVjYXVzZSB0aGVyZSBhcmUgdGVjaG5pY2FsIGxpbWl0YXRpb25zIHRvIHRob3Nl IHVuaWNhc3Qgcm91dGluZyBwb2xpY3kvDQpzdGVlcmluZyBhcHByb2FjaGVzIHdoZW4gaXRzIGFw cGxpZWQgdG8gdHJlZXM6DQoNClRyeSB0byB1c2UgYW55IG9mIHRoZSBwcmUtZXhpc3RpbmcgbWVj aGFuaXNtcyBmb3IgdW5pY2FzdCByb3V0aW5nIHBvbGljeQ0Kb3IgcGF0aCBzdGVlcmluZyB3aXRo IEJJRVIgb3IgSVAgbXVsdGljYXN0IHRvIGJ1aWxkIHN0ZWluZXIgdHJlZXMuDQpOb3QgZ2VuZXJh bGx5IHBvc3NpYmxlLiBXaXRoIEJJRVItUEUsIG5vIHByb2JsZW0uIFNhbWUgdGhpbmcgd2l0aA0K ZGlzam9pbnQgdHJlZXMgKGV2ZW4gTVJUIGZsZXgtYWxnbydzIHdvdWxkbid0IGFjaGlldmUgdGhl IHNhbWUpLg0KDQpJTUhPLCB0aGUgdGVybSAiUGF0aCBFbmdpbmVlcmluZyIgaXMgZnJlZSBvZiB0 aGlzIG1pcy1uYW1lLXJlY29nbml0aW9uDQpiZWNhdXNlIGl0IGlzIGEgbmV3LiBUaGUgbmFtZSBh bHNvIGhpbnRzIGF0IHRoZSBmYWN0IHRoYXQgdGhpcyBjb3VsZCBiZQ0KaW4gc3VwcG9ydCBvZiwg b3IgYSBjb21wb25lbnQgb2YgdHJhZmZpYyBlbmdpbmVlcmluZy4gDQpBbmQgd3J0IHRvIG1pbmlt aXppbmcgdGhlIGNoYW5nZSB0byB0aGUgbG9uZyBoZWxkIG5hbWUsDQp0aGUgaGFtbWluZyBkaXN0 YW5jZSBpcyBqdXN0IG9uZSBjaGFyYWN0ZXIvd29yZC4gU28gaXQncyB0aGUNCidzYWZlc3QvbW9z dC1jb25zZXJ2YXRpdmUvbG9naWNhbCcgbmFtZSBjaGFuZ2UgdGhpcyBsYXRlIGluIHRoZQ0KcHJv Y2Vzcy4NCg0KQXMgaSBzYWlkLCBpIHdvdWxkIGJlIGhhcHBpZXIgd2l0aCBhIG1vcmUgdW5pcXVl IG5ldyBkZXNjcmlwdGl2ZQ0KbmFtZSBsaWtlICJUcmVlIFN0ZWVyaW5nIEJpdHN0cmluZ3MiIChC SUVSLVRTQiksIGJ1dCBpIGRvIG5vdCBmZWVsDQpsaWtlIG1ha2luZyBzdWNoIGEgYmlnIG5hbWlu ZyBjaGFuZ2Ugd2l0aG91dCBtb3JlIGV4cGxpY2l0IHN1cHBvcnQNCmJ5IG1vcmUgbWVtYmVycyBv ZiB0aGUgV0cgdGhpcyBsYXRlIGluIHRoZSBwcm9jZXNzLiANCg0KPiBJIHRoaW5rIHRoaXMgY292 ZXJzIGFsbCB0aGUgZGV0YWlsZWQgZGlzY3Vzc2lvbiBwb2ludHMgYmVsb3cuIElmIG5vdCwgY2Fu DQo+IHlvdSBleHRyYWN0IHRoZSBvbmVzIHlvdSdkIGxpa2UgdG8ga2VlcCBkaXNjdXNzaW5nPw0K DQpTdGlsbCBzYWQgYWJvdXQgdGhlIG1pc3NlZCBvcHBvcnR1bml0eSBvZiBmaXhpbmcgdGhpcyBu YW1pbmcgDQpwcm9ibGVtIGVhcmxpZXIgd3J0LiB0byB0aGUgbWFpbCB5b3Ugc29wcG9zZWRseSBz ZW50LCBhbmQNCmhhcHB5IHRvIGJlYXQgbXlzZWxmIHVwIGlmIHRoYXQgZW5kZWQgdXAgYmVpbmcg bXkgZmF1bHQsIGJ1dA0KaSBndWVzcyBpIHNob3VsZG4ndCBjb250aW51ZSB0byBkaWcgaW50byB0 aGF0IGlzc3VlIGlmIGl0IHdvdWxkDQp0dXJuIG91dCB0byBiZSBzb21lb25lIGVsc2UncyBmYXVs dC4NCg0KT3RoZXJ3aXNlIGkgYW0gZmluZS4NCg0KSWYgeW91IHdhbnQgdG8gZ2l2ZSB0aGUgZG9j IG5vdyBhIHRodW1icyB1cCBpbiByZXNwb25zZSB0byB0aGUgbGFzdA0KY2FsbCwgdGhhdCB3b3Vs ZCBiZSBncmVhdCA7LSkNCg0KRU9GDQoNCj4gVGhhbmtzIGFnYWluIGZvciB0aGUgcmVzcG9uc2l2 ZW5lc3MgdG8gbXkgY29tbWVudHMhDQo+IA0KPiBMb3UNCj4gDQo+IE9uIDIvMjQvMjAyMCA4OjU3 IFBNLCBUb2VybGVzcyBFY2tlcnQgd3JvdGU6DQo+ID4gSGkgTG91LCByb3VuZCAyLg0KPiA+IA0K PiA+IEhlcmUgaXMgdGhlIGdpdGh1YiBwcmUtdmVyc2lvbiBvZiAtMDcgb2YgdGhlIGRyYWZ0Og0K PiA+IA0KPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fcmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbV90b2VybGVzc19iaWVyLTJEdGUtMkRhcmNo XzYyMzc4ZjYxODI5OTMwNzM0OWE5MzRmYzZhZDc4ZTFhZjllMTY3NzFfZHJhZnQtMkRpZXRmLTJE Ymllci0yRHRlLTJEYXJjaC50eHQmZD1Ed0lGQXcmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9 NlVoR3BXOWx3aTlkTTdqWWx4WEQ4dyZtPU1XM1MwbXZoTk45dXE1Vm1qWGROWEd3c2lzVlA1d3p6 TzhyMDRoNGFQMG8mcz1pamJIYmVOb3dtOHVZaWdlRjN0UFFCT1NyRkw1Y2h5b3hmakJYeURPeFBn JmU9IA0KPiA+IA0KPiA+IERpZmY6DQo+ID4gDQo+ID4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m cG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3Rvb2xzLmlldGYub3JnX3Rvb2xzX3JmY2RpZmZf cmZjZGlmZi5weWh0LTNGdXJsMS0zRGh0dHBzLTNBX190b29scy5pZXRmLm9yZ19pZF9kcmFmdC0y RGlldGYtMkRiaWVyLTJEdGUtMkRhcmNoLTJEMDYudHh0LTI2dXJsMi0zRGh0dHBzLTNBX19yYXcu Z2l0aHVidXNlcmNvbnRlbnQuY29tX3RvZXJsZXNzX2JpZXItMkR0ZS0yRGFyY2hfNjIzNzhmNjE4 Mjk5MzA3MzQ5YTkzNGZjNmFkNzhlMWFmOWUxNjc3MV9kcmFmdC0yRGlldGYtMkRiaWVyLTJEdGUt MkRhcmNoLnR4dCZkPUR3SUZBdyZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj02VWhHcFc5bHdp OWRNN2pZbHhYRDh3Jm09TVczUzBtdmhOTjl1cTVWbWpYZE5YR3dzaXNWUDV3enpPOHIwNGg0YVAw byZzPVZNV3hDRTJJelQwMDdyY3pGWld3aDFDRUIzeEc0OHhPajVSaWZwakl0NXMmZT0gDQo+ID4g DQo+ID4gSSB3b3VsZCBhcHByZWNpYXRlIGlmIHlvdSBjb3VsZCB0cnkgdG8gcGFydGl0aW9uIHlv dXIgb3BpbmlvbnMgaW50bw0KPiA+IHRoaW5ncyB5b3UgdGhpbmsgTVVTVCBiZSBzb2x2ZWQgYmVm b3JlIHBhc3NpbmcgdGhlIGRvY3VtZW50IHRvIElFU0cgKGZvcg0KPiA+IElFVEYvSUVTRyByZXZp ZXcpIGFuZCB0aG9zZSBpc3N1ZXMgdGhhdCBjb3VsZCB0aGVuIGJlIHNvbHZlZCB3aGVuIGl0IGlz DQo+ID4gaW4gSUVURi9JRVNHIHJldmlldy4gRm9yIGV4YW1wbGUsIGkgdGhpbmsgYSBmaW5hbCBj aG9pY2Ugb2YgbmFtZSBjb3VsZA0KPiA+IGJlIHNvbWV0aGluZyB0aGF0IHNob3VsZG4ndCBibG9j ayB0aGUgZG9jdW1lbnQgdG8gdGFrZSB0aGlzIHN0ZXAuDQo+ID4gDQo+ID4gSWYgdGhpcyBnb2Vz IGFsb25nIGludG8gSUVURjEwNywgaXQgd291bGQgYmUgZ3JlYXQgaWYgeW91IGNvdWxkIGZpbmQg dGhlDQo+ID4gdGltZSB0byBiZSBhdCB0aGUgQklFUi1XRyBtZWV0aW5nLg0KPiA+IA0KPiA+IFN1 bW1hcnkgb2YgY2hhbmdlczoNCj4gPiANCj4gPiAxLiBDaGFuZ2VkIGFiYnJldmlhdGlvbiBCSUVS LVRFIHRvIEJJRVItUEUsIG90aGVyd2lzZSB3ZSBjYW4gbm90IHVuY29uZnVzZQ0KPiA+IHJlYWRl cnMgb2YgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBCSUVSLVBFIGFuZCBCSUVSLVRFLg0KPiA+IA0K PiA+IFJlbGF0aW9uc2hpcDogQklFUi1URSA9IChCSUVSIHdpdGggc3RlZXJpbmc6IEJJRVItUEUg b3Igb3RocmUpIHBsdXMgcmVzb3VyY2UNCj4gPiBhbGxvY2F0aW9uIG1lY2hhbmlzbXMsIGFuZCB0 aGlzIGRvY3VtZW50IG9ubHkgZGVzY3JpYmVzIEJJRVItUEUuDQo+ID4gDQo+ID4gMi4gUmVtb3Zl ZCBhbGwgdXNlIG9mIHRoZSB0ZXJtICJwYXRoIGVuZ2luZWVyaW5nIiBmcm9tIHRoZSAoZXhwbGFu YXRvcnkpIHRleHQsDQo+ID4gcmVwbGFjZWQgd2l0aCBwYXRoIC8gdHJlZSBzdGVlcmluZyBvciBw b2xpY3kgaW4gdGhlIHRleHQgKGxpa2UgUkZDODQwMikuDQo+ID4gDQo+ID4gMy4gSW4gcmVzdWx0 LCAiUGF0aCBFbmdpbmVlcmluZyIgaXMgbm93IHNvbGVseSBhIG5hbWUgIGZvciB0aGUgbWVjaGFu aXNtLg0KPiA+IEluIHRoZSBzYW1lIHdheSBhcyBTUiBpbnRyb2R1Y2VkICJTZWdtZW50IFJvdXRp bmciIGFzIGEgbmFtZSwgYnV0IGV4cGxhaW5zDQo+ID4gd2hhdCBpdCBkb2VzIHdpdGggdGhlIHRl cm1zICJzdGVlcmluZyIgYW5kICJwb2xpY3kiLg0KPiA+IA0KPiA+IDQuIEkgdGhpbmsgYSB1bmlx dWUgbmV3IHRlcm0gbm90IGFscmVhZHkgdXNlZCBpbiBiZWZvcmUgaXMgaGVscGZ1bCBiZWNhdXNl DQo+ID4gd2hhdCBCSUVSLVBFIGRvZXMgaXMgcXVpdGUgdW5pcXVlIGFuZCBuZXcuIEFuZCByZXVz aW5nIGFuIGV4aXN0aW5nIHRlcm0NCj4gPiBhbHdheXMgYnJpbmdzIG91dCBtb3JlIHBlb3BsZSB3 YW50aW5nIHRvIGFyZ3VlIGFib3V0IHRoZSBhY2N1cmFjeSBvZiBob3cNCj4gPiB0aGVpciBwcmUt ZXhpc3RpbmcgdGVybSBpcyBhcHBsaWVkLg0KPiA+IA0KPiA+IEkgaG9wZSB3ZSBjYW4gaGF2ZSBh IGRldGVybWluaXN0aWMsIHNob3J0IGxhdGVuY3kgZGVjaXNpb24gbWVjaGFuaXNtIGZvcg0KPiA+ IHRoZSB0ZXJtLiBBZnRlciB3ZSd2ZSBkZWNpZGVkIG9uIHRoZSB0ZXJtLCBpdHMgZWFzeSB0byB1 cGRhdGUgdGhlIGRvYw0KPiA+IGFnYWluIHdpdGggdGhhdCBuZXcgdGVybSAoJXMvUEUvWFhYL2cp Lg0KPiA+IA0KPiA+IEknbGwgdGhyb3cgIlRyZWUgU3RlZXJpbmcgQml0c3RyaW5ncyIgKEJJRVIt VFNCKSBpbnRvIHRoZSByaW5nLg0KPiA+IA0KPiA+IFtUaGUgbWFpbiBpc3N1ZSB3aXRoIG5hbWUg Y2hhbmdlIG5vdyBpcyB0aGF0IHdlJ3ZlIGdvdHRlbiBzb21lIGZvbGxvd3VwDQo+ID4gd29yayBz dWNoIGFzIFlBTkcgbW9kZWwgdGhhdCBhbHNvIHJlZmVycyB0byBCSUVSLVRFIG1lYW5pbmcgQklF Ui1QRSwgc28NCj4gPiB0aGF0IHdvdWxkIGFsc28gbmVlZCB0byBjaGFuZ2UgbmFtZS4gU2VlIGJl bG93IGZvciBteSByZXBseSB0byB0aGF0IG5hbWluZw0KPiA+IGNoYW5nZSB5b3Ugc2FpZCB5b3Ug c3VnZ2VzdGVkIC5dDQo+ID4gDQo+ID4gNS4gSSBhbHNvIHJlZmluZWQgdGhlIHNlY3Rpb24gMS4x IHRoYXQgd2FzIGludHJvZHVjZWQgaW4gLTA2IHRvIG1lbnRpb24NCj4gPiBlLmcuOiBQQ0UuDQo+ ID4gDQo+ID4gU3BlY2lmaWMgYW5zd2VycyB0byB0aGUgbWFpbCB0aHJlYWQgYmVsb3cuDQo+ID4g DQo+ID4gQ2hlZXJzDQo+ID4gICAgICBUb2VybGVzcw0KPiA+IA0KPiA+IE9uIEZyaSwgRmViIDIx LCAyMDIwIGF0IDAzOjAxOjUxUE0gLTA1MDAsIExvdSBCZXJnZXIgd3JvdGU6DQo+ID4gPiA+IFsg V291bGQgaGF2ZSBiZWVuIG5pY2UgaWYgeW91IGNvdWxkIGhhdmUgY29tbWVudGVkIGEgYml0IGVh cmxpZXIuDQo+ID4gPiA+ICAgICBCdXQgaSBjYW4gdW5kZXJzdGFuZCBob3cgYSBmZXcgeWVhcnMg aXMgbm90IGVub3VnaCB0aW1lIDstUA0KPiA+ID4gPiAgICAgKGFjdHVhbGx5IG5vIGtpZGRpbmcs IGkgcmVhbGx5IGNhbi4pIF0NCj4gPiA+IEkgcmFpc2VkIHRoaXMgYXMgYW4gaXNzdWUgbGFzdCBt YXJjaCAtIGF0IGJvdGggdGhlIENoYWlyIGFuZCBBRCBsZXZlbC4uwqAgSQ0KPiA+ID4gdGhvdWdo dCBJIG1hZGUgdGhlIHNhbWUgcG9pbnQgdG8geW91IHByaXZhdGVseSBhZnRlciBvbmUgdGhlIHBy ZXNlbnRhdGlvbnMNCj4gPiA+IGF0IElFVEYxMDEsIGJ1dCBpZiB5b3UgZG9uJ3QgcmVtZW1iZXIg aXQsIEkgYWNjZXB0IHRoYXQgSSBkaWRuJ3QuDQo+ID4gRGlkIHlvdSBpbmNsdWRlIHRoZSBhdXRo b3JzID8gSSBjb3VsZCBub3QgZmluZCBhbnkgZW1haWwgYWJvdXQgdGhpcy4NCj4gPiBBbHNvIG5v IGZvcndhcmRlZCBlbWFpbHMgZnJvbSBBRC9jaGFpcnMgaSBjb3VsZCBmaW5kLiBJZiB5b3Ugc3Rp bGwgaGF2ZQ0KPiA+IGEgY29weSwgcGxzLiBQTS4gVGhpcyBpcyBhbm5veWluZy4uLg0KPiA+IA0K PiA+IEkgZG8gbm90IHJlbWVtYmVyIG5hbWluZyBpc3N1ZSBkaXNjdXNzZWQgYWZ0ZXIgSUVURjEw MSwgYnV0IGkgYW0NCj4gPiBzdXJlIGkgd2FzIHByZW9jY3VwaWVkIHdpdGggdGVjaG5pY2FsIGlz c3VlcyBhbmQgbWlnaHQgbm90IGhhdmUNCj4gPiBnaXZlbiBpdCB0b28gbXVjaCB0aG91Z2h0IGJh Y2sgdGhlbi4gT2YgY291cnNlIHRoZXJlIHdhcyBhIGxvdCBvZg0KPiA+IHRpbWUgc2luY2UgSUVU RjEwMSB0byBicmluZyB1cCB0aGUgbmFtaW5nIHBvaW50IGFnYWluLi4uDQo+ID4gDQo+ID4gPiBX ZWxsIHRoYXQgZG9jdW1lbnQgc2VlbXMgbGlrZSBhIGZpbmUgcGxhY2UgdG8gZGVzY3JpYmUgaG93 IEJJRVItUlAgKHJvdXRpbmcNCj4gPiA+IHBvbGljeSkgY2FuIGJlIHVzZWQgdG8gZGVsaXZlciBC SUVSLVRFLg0KPiA+ID4gDQo+ID4gWy4uLl0NCj4gPiA+IERvIHdlIHJlYWxseSBuZWVkIGEgbmV3 IHRlcm0gdG8gZGVzY3JpYmUgaGVyZT/CoCBJIGZpbmQgemVybyAoMCkgaW5zdGFuY2VzIG9mDQo+ ID4gPiBQYXRoIEVuZ2luZWVyaW5nIGluIGFueSBSRkMuwqAgUm91dGluZyBwb2xpY3kgKGFuZCBw b2xpY3ktYmFzZWQgcm91dGluZykgb24NCj4gPiA+IHRoZSBvdGhlciBoYW5kIGFyZSBmYWlybHkg d2VsbCBlc3RhYmxpc2hlZCB0ZXJtcyBpbiB0aGUgaW5kdXN0cnkuwqAgSSB0aGluaw0KPiA+ID4g dGhpcyBqdXN0IHNvd3Mgc2VlZHMgZm9yIGZ1dHVyZSBjb25mdXNpb24gb24gdGhpcyB0b3BpYy4N Cj4gPiA+IA0KPiA+ID4gV2h5IGlzICJyb3V0aW5nIHBvbGljeSIgbm90IGdvb2QgZW5vdWdoIGZv ciB3aGF0IGlzIGJlaW5nIGRlZmluaW5nIGhlcmU/wqAgSQ0KPiA+ID4gYWdhaW4gcG9pbnQgb3V0 LCB0aGlzIGlzIHRoZSB0ZXJtIGJlaW5nIHVzZWQgaW4gU1BSSU5HIGZvciBiYXNpY2FsbHkgdGhl DQo+ID4gPiBlcXVpdmFsZW50IGZ1bmN0aW9uL3B1cnBvc2UuIChZZXMgdGhlIGZvcndhcmRpbmcg bWVjaGFuaXNtIGlzIGRpZmZlcmVudCwgYnV0DQo+ID4gPiB0aGUgb2JqZWN0aXZlIGlzIG5vdC4p DQo+ID4gU1BSSU5HIGRpZCBlc3RhYmxpc2ggbmV3IHVuaXF1ZSBuYW1lL3Rlcm1pbm9sb2dpZXMs IGxpa2UgIlNlZ21lbnQiLg0KPiA+IEFzIHNhaWQgYWJvdmUsIGkgdGhpbmsgaXRzIGJlc3Qgd2Ug ZG8gdGhlIHNhbWVnaXZlbiBob3cgdW5pcXVlIHRoaXMgaXMuDQo+ID4gDQo+ID4gTG9va2luZyBh dCByZmM4NDAyLCAic3RlZXJpbmciIGFuZCAicG9saWN5IiBhcmUgdXNlZCBpbiB2ZXJiYWwNCj4g PiBleHBsYW5hdGlvbnMsIHdpdGhvdXQgcHJvdmlkaW5nIHNwZWNpZmljIHRlcm1pbm9sb2d5IGZv ciB0aGVtLA0KPiA+IHNvIGkgZGlkIGZvbGxvdyB0aGF0IGV4YW1wbGUgdG9vLg0KPiA+IA0KPiA+ ID4gPiBidXQga2VwdCBuYW1lIEJJRVItVEUgKHNlZSBiZWxvdykuDQo+ID4gPiA+IA0KPiA+ID4g PiAtIEFkZGVkIHNlY3Rpb24gMS4xIGV4cGxhaW5pbmcgaG93IEJJRVItVEUgcmVsYXRlcyB0byB0 cmFmZmljDQo+ID4gPiA+ICAgICBlbmdpbmVlcmluZywgbmFtaW5nIHVzZS1jYXNlcyB3aGVyZSBp dHMgZm9yIGV4YW1wbGUgYmVuZWZpY2lhbCBzdGFuZGFsb25lIGFuZA0KPiA+ID4gPiAgICAgYW5k IHdoYXQgaXQgY291bGQgYmUgY29tYmluZWQgd2l0aCBmb3IgbW9yZSBjb21wcmVoZW5zaXZlIFRF IHNvbHV0aW9ucywNCj4gPiA+ID4gICAgIGJ1dCBhbHNvIHN0YXRpbmcgdGhhdCB0aG9zZSBpbnRl Z3JhdGlvbnMgYXJlIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMNCj4gPiA+ID4gICAgIGRvY3Vt ZW50Lg0KPiA+ID4gU28gdGhpcyBzZWN0aW9uIHNlZW1zIHRvIG1pc3Mgd2hhdCBoYXMgYmVlbiBn b2luZyBvbiBpbiB0cmFmZmljIGVuZ2luZWVyaW5nDQo+ID4gPiAvIFRFQVMgZm9yIHRoZSBsYXN0 IDUrIHllYXJzIChpLmUuLCBjb250cm9sbGVyLWJhc2VkIFRFIGFwcHJvYWNoZXMpDQo+ID4gSSBk b24ndCB0aGluayB0aGF0IGlzIGEgY29ycmVjdCBhc3Nlc3NtZW50LiBCSUVSLVBFIGl0c2VsZiBy ZXF1aXJlcyBhDQo+ID4gY29udHJvbGxlciB0byBjYWxjdWxhdGUgcGF0aHMgLyB0cmVlcy4gV2l0 aCBvciB3aXRob3V0IG90aGVyIHRyYWZmaWMNCj4gPiBlbmdpbmVlcmluZyBjb21wb25lbnRzLiBU aGF0IGNvbXBvbmVudCBpcyBjYWxsZWQgdGhlIEJJRVItUEUgY29udHJvbGxlciBhbmQNCj4gPiBo YXMgYmVlbiBpbiB0aGUgZHJhZnQgZm9yZXZlci4NCj4gPiANCj4gPiBUaGUgbmV3IHNlY3Rpb24g MS4xIGFkZGVkIGluIHJlc3BvbnNlIHRvIHlvdXIgcmV2aWV3IHJlbGF0ZXMgdGhhdA0KPiA+IEJJ RVItVEUgY29udHJvbGxlciB0byBhbiBvdmVyYWxsIFRFIGNvbnRyb2xsZXIsIHVzaW5nIHRoZSBQ Q0UgZXhhbXBsZQ0KPiA+IGFuZCByZWZyZXJlbmNlIHRvIGl0Lg0KPiA+IA0KPiA+IFRoZXJlIGlz IHJlYWxseSBub3RoaW5nIG1vcmUgdGhhdCBhIEJJRVItV0cgZG9jdW1lbnQgY291bGQgb3Igc2hv dWxkDQo+ID4gZG8uIFdoYXQgdGhpcyBkb2N1bWVudCBpbnRlbmRlZCB0byBzdXBwb3J0IGlzIHdo YXRzIG5lY2Vzc2FyeSBhbmQNCj4gPiBzdWZmaWNpZW50IHRvIGdldCB0aGUgZm9yd2FyZGluZyBw bGFuZSBpbXBsZW1lbnRlZC9zdGFuZGFyZGl6ZWQuDQo+ID4gRXZlcnl0aGluZyBlbHNlIGlzIGZv ciBpbmRlcGVuZGVudCBmb2xsb3d1cCB3b3JrIGluIFRFQVMgSU1ITywNCj4gPiBzdWNoIGFzIHJl dml2aW5nIHRoZSBmcmFtd29yayBkcmFmdC4NCj4gPiANCj4gPiA+ICDCoCBhbmQgdGhlbiBnb2Vz IG9uIGRlc2NyaWJlIHBhdGggc3RlZXJpbmfCoCBpbiBhIHZlcnkgYnJpZWYgd2F5LsKgIEkgcmVh ZCB0aGlzIGFzDQo+ID4gPiBzYXlpbmcgdGhhdCBCSUVSICpjb3VsZCogZG8gVEUgaW4gdGhlIGZ1 dHVyZSBhbmQgKmNhbiogc3VwcG9ydCByb3V0aW5nDQo+ID4gPiBwb2xpY3kgYW5kIHBhdGggc3Rl ZXJpbmcgdG9kYXkuDQo+ID4gRXZlbiBzdHJvbmdlcjogQklFUi1QRSBpcyBhbHdheXMgbWVhbnQg dG8gT05MWSBkbyB0aGF0IChzdGVlcmluZyksDQo+ID4gYW55IGFkZGl0aW9uYWwgVEUgZnVuY3Rp b25zIHdvbGQgY29tZSBmcm9tIGluZGVwZW5kZW50IG90aGVyIGNvbXBvbmVudHMuDQo+ID4gQW5k IHNpbXBsZSBleGFtcGxlcyBmb3IgdGhhdCBhcmUgZ2l2ZW4gaW4gc2VjdGlvbiAxLjEuDQo+ID4g DQo+ID4gPiA+IC0gY2hhbmdlZCAidHJhZmZpYyBlbmdpbmVlcmluZyIgdGVybSBpbiB0aGUgd2hv bGUgZG9jIHRvICJwYXRoIGVuZ2luZWVyaW5nIiwNCj4gPiA+ID4gICAgIHdoZXJlIGFwcHJvcHJp YXRlLg0KPiA+ID4gV2hpbGUgdGhpcyBpcyBhcHByZWNpYXRlZCwgSSdtIG5vdCBzdXJlIGl0J3Mg aGVscGZ1bC7CoCBBcyBzdGF0ZWQgYWJvdmUsIEkNCj4gPiA+IHRoaW5rIHRoZSBpbnRyb2R1Y3Rp b24gb2YgdGhlIG5ldyBQRSB0ZXJtIGlzIGNvbmZ1c2luZyBhcyB0aGUgY29udGludWVkIHVzZQ0K PiA+ID4gb2YgQklFUi1URS4NCj4gPiBTZWUgYWJvdmUuIFdlIGNhbiBjZXJ0YWlubHkgbm90IHVz ZSAiQklFUi1URSIgdG8gbWVhbiB0d28gZGlmZmVyZW50DQo+ID4gdGhpbmdzLCBzbyBpIGhvcGUg dGhhdCBjb25jZXJuIGlzIHJlc29sdmVkLg0KPiA+IA0KPiA+ID4gPiBUaGUgbWF5b3JpdHkgb2Yg Y3VzdG9tZXJzIGkgdGFsa2VkIHRvIG9ubHkgdXNlZCBSU1ZQLVRFIGZvciBwYXRoDQo+ID4gPiA+ IGVuZ2luZWVyaW5nLCBhbmQgbm90IGZvciBhbnl0aGluZyBtb3JlLiBTZXZlcmFsIGRpZG4ndCBl dmVuIGtub3cgaXQNCj4gPiA+ID4gY2FuIGRvIGJhbmR3aWR0aCByZXNlcnZhdGlvbi4gTm9ib2R5 IGtuZXcgaXQgY291bGQgZG8gbGF0ZW5jeQ0KPiA+ID4gPiBndWFyYW50ZWVzLCBiZWNhdXNlIG5v Ym9keSBrbm93cyBhbiBpbXBsZW1lbnRhdGlvbiB0aGF0IHN1cHBvcnRzIHRoYXQuDQo+ID4gPiA+ IFtBbGwgcmVhc29ucyBidHcuIHdoeSByZXBsYWNpbmcgUlNWUC1URSB3aXRoIFNSIGhhcHBlbmVk IGluIHRoZSBpbmR1c3RyeS5dDQo+ID4gPiBXaGlsZSBJJ20gZ29pbmcgdG8gYXZvaWQgZ2V0dGlu ZyBpbnRvIHByb2R1Y3QgZGlmZmVyZW50aWF0b3JzIGFuZCBtYXJrZXRpbmcsDQo+ID4gPiB5b3Un cmUgbm90IG1lbnRpb25pbmcgdGhhdCBldmVuIHRob3NlIHByb2R1Y3RzIGFuZCBjdXN0b21lcnMg d2hvIGRpZG4ndA0KPiA+ID4gc3VwcG9ydC91c2UgcGVyIExTUCBxdWV1aW5nLCBkaWQgYXZhaWxh YmxlIHJlc291cmNlIGJvb2trZWVwaW5nIGFuZCBldmVuDQo+ID4gPiBhZG1pc3Npb24gY29udHJv bC4NCj4gPiBJIHRoaW5rIHRoZSBwb2ludCBpcyBtb29kIG5vdyAoZ2l2ZW4gaG93IHdlJ2xsIGNo YW5nZSB0aGUgbmFtZSBCSUVSLVRFDQo+ID4gdG8gYSBiZXR0ZXIgdGVybSkuIEJ1dCBtYXliZSB0 byBiZXR0ZXIgZXhwbGFpbjogV2Ugc3RhcnRlZCBjYWxsaW5nIHRoaXMNCj4gPiBURSBzbyBjdXN0 b21lcnMgd291bGQgZWFzaWVyIHVuZGVyc3RhbmQgdGhhdCB0aGlzIGlzIGludGVuZGVkIHRvIGdp dmUNCj4gPiB0aGVtIHdoYXQgdGhleSBhY3R1YWxseSB1c2UgUlNWUC1URSBmb3IgKFRyYWZmaWMg U3RlZXJpbmcpLCBhbmQgbm90DQo+ID4gbmVjZXNzYXJpbHkgYWxsIHRoYXQgUlNWUC1URSBjb3Vs ZCBkbyBiZXlvbmQgdGhhdC4gQSBjZW50cmFsIGNvbnRyb2xsZXINCj4gPiBpcyBhc3N1bWVkIHRv IGV4aXN0IGluIEJJRVItUEUgdG9vLg0KPiA+IA0KPiA+IEdpdmVuIGhvdyBTUiBhbHNvIHNob3dz IGhvdyB5b3UgY2FuIGJlIHN1Y2Nlc3NmdWwgaW4gZGVwbG95bWVudA0KPiA+IHdpdGhvdXQgYmV0 dGluZyBvbiAnVEUnIG5hbWUgcmVjb2duaXRpb24sIGkgaGF2ZSBubyBxdWFycmVscyBpbg0KPiA+ IGNoYW5naW5nIHRoZSBuYW1lLiBBcyBzYWlkIGFib3ZlLCBpdHMgbW90bHkgYSBxdWVzdGlvbiBv ZiBmaW5kaW5nDQo+ID4gdGhlIGJlc3QgdGVybSBhbmQgY2hhbmdpbmcgdGhlIGZvbGxvd3VwIHdv cmtzIG5hbWVzIHRvby4NCj4gPiANCj4gPiA+ID4gSW4gYW55IGNhc2UsIHRoZSBuYW1lIEJJRVIt VEUgd2FzIHNlbGVjdGVkIHRvIHJlZHVjZSBjb25mdXNpb24NCj4gPiA+ID4gd2l0aCBjdXN0b21l cnMsIG5vdCB0byBtYXhpbWl6ZSBuYW1pbmcgY29ycmVjdG5lc3MgaW4gSUVURi4NCj4gPiA+IHVt bSwgdGhlIElFVEYgaXMgYSBzdGFuZGFyZHMgYm9keSBub3QgYW4gaW5kdXN0cnkgbWFya2V0aW5n IGZvcnVtLCBzbyBJJ20NCj4gPiA+IHVuY2xlYXIgaG93IHRoaXMgcG9pbnQgaGVscHMgeW91ciBh cmd1bWVudC4NCj4gPiBJdCdzIG5vdCBhbSBhcmd1bWVudCBvciBqdXN0aWZpY2F0aW9uLCBqdXN0 IGFuIGV4cGxhbmF0aW9uLiBOb3Qgb25seSB0byB5b3UsDQo+ID4gYnV0IGFsc28gdGhlIFdHLg0K PiA+IA0KPiA+ID4gIMKgSXQgc2VlbXMgdGhhdCB5b3UncmUgc2F5aW5nDQo+ID4gPiB0aGF0IGlm IHdlIGNhbGwgaXQgQklFUi1URSB3ZSBjYW4gbWFya2V0IGl0IGluIHBsYWNlIG9mIGV4aXN0aW5n IElFVEYgVEUNCj4gPiA+IHNvbHV0aW9ucyAtIGV2ZW4gdGhvdWdoIGl0IGRvZXNuJ3QgeWV0IGhh dmUgdGhlIFRFIGNhcGFiaWxpdHkgY292ZXJlZCBpbg0KPiA+ID4gZHJhZnQtZWNrZXJ0LXRlYXMt Ymllci10ZS1mcmFtZXdvcmsuDQo+ID4gLi4uLg0KPiA+IA0KPiA+ID4gQXNzdW1pbmcgSSdtIHJl YWRpbmcgaXQgcmlnaHQsIHRoaXMganVzdCBjb25maXJtcyB0byBtZSB0aGF0IHRoZSBjdXJyZW50 DQo+ID4gPiB3b3JrIG5lZWRzIHRvIGJlIHJlbmFtZWQgYW5kIHRoYXQgZHJhZnQtZWNrZXJ0LXRl YXMtYmllci10ZS1mcmFtZXdvcmsgd2lsbA0KPiA+ID4gZGVmaW5lIEJJRVItVEUuDQo+ID4gWWVz LiBCSUVSLVRFIGNvdWxkIGJ0dy4gcmVseSBvbiBCSUVSLVBFIG9yIEJJRVIgKyBvdGhlciBwYXRo IHN0ZWVyaW5nDQo+ID4gKGUuZy46IGZsZXgtYWxnb3MpLCBzbyBCSUVSLVBFIGlzIG9ubHkgb25l IG9wdGlvbiBmb3IgdGhlIHBhdGgtc3RlZXJpbmcNCj4gPiBvcHRpb25zIGZvciBCSUVSLVRFLg0K PiA+IA0KPiA+ID4gTXkgcG9pbnQgd2Fzbid0IHRoYXQgQklFUj1TUiwgYnV0IHJhdGhlciBib3Ro IGRlbGl2ZXIgc3VwcG9ydCBmb3IgcGF0aA0KPiA+ID4gc3RlZXJpbmcgYW5kIHBvbGljeSBiYXNl ZCByb3V0aW5nLg0KPiA+IFllcHAsIGkgaG9wZSB3ZSdyZSBpbiB2aW9sZW50IGFncmVlbWVudC4N Cj4gPiANCj4gPiBDaGVlcnMNCj4gPiAgICAgIFRvZXJsZXNzDQo+ID4gDQo+ID4gPiBUaGFua3Mg Zm9yIGJlaW5nIHJlc3BvbnNpdmUhDQo+ID4gPiANCj4gPiA+IExvdQ0KPiA+ID4gDQo+ID4gPiA+ IEFsbCB0aGUgU1Igb3B0aW9ucyBkbyByZWFsbHkgcmVxdWlyZSB0aGF0IHlvdSBzZXQgdXAgbXVs dGljYXN0IHRyZWVzIHdpdGgNCj4gPiA+ID4gZS5nLjogcmVwbGljYXRpb24tU0lEcyB0aGF0IHRv Z2V0aGVyIGZvcm0gdGhlIGVxdWl2YWxlbnQgb2YgYQ0KPiA+ID4gPiBtdWx0aWNhc3QgdHJlZSwg bGlrZSB5b3Ugd291bGQgaGF2ZSBidWlsdCB3aXRoIFJTVlAtVEUuIEV4Y2VwdCB0aGF0DQo+ID4g PiA+IHRoZSBzaWduYWxpbmcgaG93IHRvIGJ1aWxkIHRoZSB0cmVlIGlzIGxlZnQgZm9yIHNvbWVv bmUgZWxzZSwgbGlrZQ0KPiA+ID4gPiBQQ0VDQy4gKEFGQUlLLCBpIG1heSBub3QgYmUgb24gdG9w IG9mIGFsbCBkZXRhaWxzKS4gSW4gQklFUi1URSwNCj4gPiA+ID4gdGhlcmUgaXMgbm8gc3VjaCBw ZXItdHJlZSBzdGF0ZSBvbiB0cmFuc2l0IG5vZGVzLg0KPiA+ID4gPiANCj4gPiA+ID4gSW5zdGVh ZCBvZiBhIDI1NiBiaXQgYml0c3RyaW5nIGluIEJJRVItVEUgdGhpbmsgb2YgYSBoZWFkZXIgd2l0 aCB1cCB0byAyNTYgU0lEcw0KPiA+ID4gPiAoZS5nLjogMTI4IGJpdCBwZXIgU0lEIGluIFNSdjYp LiBUaGF0IHdvdWxkIGJlIHRoZSBTUiBlcXVpdmFsZW50IG9mIEJJRVItVEUuDQo+ID4gPiA+IEp1 c3QgYSBiaXQgbGVzcyAoIDstKSApIGxlc3MgZWZmaWNpZW50IG9uIHRoZSB3aXJlIHRoYW4gQklF Ui1URSBhbmQgZXh0cmVtZWx5DQo+ID4gPiA+IGhhcmRlciB0byBwYXJzZS4NCj4gPiA+ID4gDQo+ ID4gPiA+IENoZWVycw0KPiA+ID4gPiAgICAgICBUb2VybGVzcw0KPiA+ID4gPiANCj4gPiA+ID4g DQo+ID4gPiA+IE9uIFdlZCwgRmViIDE5LCAyMDIwIGF0IDA2OjM4OjM4UE0gLTA1MDAsIExvdSBC ZXJnZXIgd3JvdGU6DQo+ID4gPiA+ID4gSGksDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gICDCoMKg wqAgSSBoYXZlIG5vIGlzc3VlIG9yIG9iamVjdGlvbiB0byB0aGUgbWVjaGFuaXNtcyBiZWluZyBk ZWZpbmVkIGluIHRoaXMNCj4gPiA+ID4gPiBkb2N1bWVudCBhcyBtdWNoIGFzIHRoZXkgZ28sIGJ1 dCBJIHdhcyBxdWl0ZSBkaXNhcHBvaW50ZWQgdGhhdCBkZXNwaXRlIHRoZQ0KPiA+ID4gPiA+IG5h bWUgb2YgdGhlIGRvY3VtZW50IGFuZCB1c2Ugb2YgJ2JpZXItdGUnwqAgdG8gc2VlIHRoYXQgdGhl IGRvY3VtZW50IGRvZXNuJ3QNCj4gPiA+ID4gPiBkZWZpbmUgYW55IHRyYWZmaWMgZW5naW5lZXJp bmcgc3VwcG9ydCwgYXQgbGVhc3QgYXMgZmFyIGFzIHRoZSB0ZXJtIGhhcyBiZWVuDQo+ID4gPiA+ ID4gdXNlZCBpbiBJRVRGIFJGQ3MuwqAgSW4gcGFydGljdWxhciBpdCB0b3RhbGx5IGxhY2tzIGFu eSBkaXNjdXNzaW9uIG9mDQo+ID4gPiA+ID4gcmVzb3VyY2VzIHVzYWdlIGFuZC9vciBhbGxvY2F0 aW9uLsKgIFdoYXQgaXQgY3VycmVudGx5IGRlc2NyaWJlcyBjZXJ0YWlubHkNCj4gPiA+ID4gPiBw cm92aWRlcyBnb29kIGFuZCB1c2VmdWwgcGF0aC90cmFmZmljIHN0ZWVyaW5nIHRoYXQgY2FuIGJl IHVzZWQgdG8gc3VwcG9ydA0KPiA+ID4gPiA+IHBvbGljeS1iYXNlZCByb3V0aW5nLsKgIEJhc2lj YWxseSBpdCBkb2VzIHRoZSBzYW1lIGFzIHdoYXQgaXMgZGVmaW5lZCBieQ0KPiA+ID4gPiA+IGRy YWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1wb2xpY3kuDQo+ID4gPiA+ID4gDQo+ID4g PiA+ID4gSSBwZXJzb25hbGx5IChub3Qgc3BlYWtpbmcgZm9yIHRoZSByZWxhdGVkIFdHcyB0aGF0 IEkgY2hhaXIpIHdvdWxkIHByZWZlciB0bw0KPiA+ID4gPiA+IHNlZSB0aGlzIGRvY3VtZW50IGJl IHJldmlzZWTCoCB0byBpbmNsdWRlIHJlc291cmNlIGFsbG9jYXRpb24gdGhhdCB3b3VsZA0KPiA+ ID4gPiA+IGFsbG93IEJJRVItVEUgdG8gc3VwcG9ydCBURSB1c2FnZSBzdWNoIGFzIERldE5ldC7C oCBCYXJyaW5nIHN1Y2ggYW4gYWRkaXRpb24sDQo+ID4gPiA+ID4gSSdtIGFnYWluc3QgcHVibGlj YXRpb24gb2YgdGhpcyBkb2N1bWVudCBhcyBpcyBhbmQgSSB0aGluayB0aGUgZG9jdW1lbnQNCj4g PiA+ID4gPiBzaG91bGQgYmUgcmVjYXN0IGFuZCByZW5hbWVkIHRvIGJlIGFsaWduZWQgd2l0aCB0 aGUgU1IgZXhhbXBsZSwgaS4uZS4sIEJJRVINCj4gPiA+ID4gPiByb3V0aW5nIHBvbGljeSAob3Ig cGF0aCBzdGVlcmluZykuDQo+ID4gPiA+ID4gDQo+ID4gPiA+ID4gTG91DQo+ID4gPiA+ID4gDQo+ ID4gPiA+ID4gT24gMi8xOC8yMCAzOjQ1IFBNLCBHcmVnIFNoZXBoZXJkIHdyb3RlOg0KPiA+ID4g PiA+ID4gVGhhbmtzIFRvZXJsZXNzIGFuZCBKZWZmcmV5DQo+ID4gPiA+ID4gPiANCj4gPiA+ID4g PiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f ZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0LTJEaWV0Zi0yRGJpZXItMkR0ZS0yRGFyY2hf JmQ9RHdJRkF3JmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPTZVaEdwVzlsd2k5ZE03allseFhE OHcmbT1NVzNTMG12aE5OOXVxNVZtalhkTlhHd3Npc1ZQNXd6ek84cjA0aDRhUDBvJnM9akg5eDdn YWN2MzM1UWRjcV9idGdVTnRPMy1UUXh3THNwbWZWemJDQzlPbyZlPSANCj4gPiA+ID4gPiA+IA0K PiA+ID4gPiA+ID4gT25lIG1vcmUgd2VlayBvZiBXR0xDLiBQbGVhc2UgcmVhZCB0aGUgbGF0ZXN0 IHJldiBhbmQgcmVzcG9uZCB0byB0aGlzDQo+ID4gPiA+ID4gPiB0aHJlYWQgdy93byBzdXBwb3J0 Lg0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiBDaGFpcnMNCj4gPiA+ID4gPiA+IChTaGVwKQ0K PiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+IE9uIFR1ZSwgRmViIDE4LCAy MDIwIGF0IDEyOjA3IFBNIEplZmZyZXkgKFpoYW9odWkpIFpoYW5nDQo+ID4gPiA+ID4gPiA8enpo YW5nPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmcNCj4gPiA+ID4gPiA+IDxtYWlsdG86NDBq dW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ ID4gPiAgICAgICBIaSBUb2VybGVzcywNCj4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ID4gICAgICAg VGhhbmtzIQ0KPiA+ID4gPiA+ID4gICAgICAgSSBzdXBwb3J0IG1vdmluZyB0aGlzIHRvIHRoZSBu ZXh0IHN0YWdlLg0KPiA+ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiAgICAgICBKZWZmcmV5DQo+ID4g PiA+ID4gPiANCj4gPiA+ID4gPiA+ICAgICAgIE9uIEZyaSwgTm92IDAxLCAyMDE5IGF0IDA3OjQy OjM4UE0gKzAxMDAsIFRvZXJsZXNzIEVja2VydCB3cm90ZToNCj4gPiA+ID4gPiA+ICAgICAgID4g VGhhbmtzIEplZmYNCj4gPiA+ID4gPiA+ICAgICAgID4NCj4gPiA+ID4gPiA+ICAgICAgID4gSSBo YXZlIG5vdyBwdXNoZWQgb3V0IC0wNSB3aXRoIHRoZSBhbnN3ZXJzIGFuZCBob3BlZnVsbHkNCj4g PiA+ID4gPiA+ICAgICAgIHJlc29sdXRpb24gdG8NCj4gPiA+ID4gPiA+ICAgICAgID4geW91ciBw b2ludHMgaW4gZW1haWwgYmVsb3cuwqAgQmlnZ2VzdCBhZGRpdGlvbiB3YXMgYSBzZWN0aW9uIGFi b3V0DQo+ID4gPiA+ID4gPiAgICAgICA+IHJldXNlIG9mIEJQcyAod2l0aG91dCBETlIpIHdoaWNo IGNhbWUgb3V0IG9mIHRoZSBjb25mdXNpb24gaQ0KPiA+ID4gPiA+ID4gICAgICAgdGhpbmsgdGhl DQo+ID4gPiA+ID4gPiAgICAgICA+IHJldXNlIGluIHRoZSBFQ01QIGV4YW1wbGUgcmFpc2VkLiBJ IHdhcyBhZnJhaWQgc28gZmFyIHRvIGV4cGxhbg0KPiA+ID4gPiA+ID4gICAgICAgdGhhdA0KPiA+ ID4gPiA+ID4gICAgICAgPiBhcyBpdCBtYXkgbm90IGJlIGVhc3kgdG8gYWJzb3JiIGFuZCB1bHRp bWF0ZWx5IGlzIHN0dWZmIG9ubHkNCj4gPiA+ID4gPiA+ICAgICAgID4gY29udHJvbGxlciBkZXZl bG9wZXJzIG5lZWQgdG8gdW5kZXJzdGFuZCwgYnV0IGhvcGVmdWxseSB1c2VmdWwuDQo+ID4gPiA+ ID4gPiAgICAgICA+IEFuZCB0aGVuIG9mIGNvdXJzZSB0aGUgc3VtbWFyeSBvZiBCUCBvcHRpbWl6 YXRpbnMgeW91IGFza2VkIGZvcg0KPiA+ID4gPiA+ID4gICAgICAgPg0KPiA+ID4gPiA+ID4gICAg ICAgPiBEaWZmIGZyb20gbGFzdCB2ZXJzaW9uIGkgc2VudCB5b3U6DQo+ID4gPiA+ID4gPiAgICAg ICA+DQo+ID4gPiA+ID4gPiAgICAgICA+DQo+ID4gPiA+ID4gPiAgICAgICBodHRwczovL3VybGRl ZmVuc2UuY29tL3YzL19faHR0cDovL3Rvb2xzLmlldGYub3JnLypyZmNkaWZmP3VybDE9aHR0cHM6 DQo+ID4gPiA+ID4gPiAgICAgICA+ICoqQXJhdy5naXRodWJ1c2VyY29udGVudC5jb20NCj4gPiA+ ID4gPiA+ICAgICAgIDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cC0zQV9fQXJhdy5naXRodWJ1c2VyY29udGVudC5jb20mZD1Ed0lGQXcmYz1MRllaLW85X0hV TWVNVFNRaWN2aklnJnI9NlVoR3BXOWx3aTlkTTdqWWx4WEQ4dyZtPU1XM1MwbXZoTk45dXE1Vm1q WGROWEd3c2lzVlA1d3p6TzhyMDRoNGFQMG8mcz14VkFqcDcyMWdfRWw2MVg4eU15UnczZ2daaElR LVNHOVpiLVVGcFZ0T0h3JmU9ID4qdG9lcmxlc3MqYmllci10ZS1hcmNoKm1hc3RlcipkcmFmdC1p ZXRmLWINCj4gPiA+ID4gPiA+ICAgICAgID4gaWVyLXRlLWFyY2gtMDUuMS50eHQmdXJsMj1odHRw OioqQXRvb2xzLmlldGYub3JnDQo+ID4gPiA+ID4gPiAgICAgICA8aHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX0F0b29scy5pZXRmLm9yZyZkPUR3SUZB dyZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj02VWhHcFc5bHdpOWRNN2pZbHhYRDh3Jm09TVcz UzBtdmhOTjl1cTVWbWpYZE5YR3dzaXNWUDV3enpPOHIwNGg0YVAwbyZzPWdnUHJrU0J6aUJ4Y1VW NDhOS21za3J3NmZPelU5NG0zRGs1dTY3VU1jUmcmZT0gPippZCpkcmFmdC1pZXRmLWJpZXItdGUN Cj4gPiA+ID4gPiA+ICAgICAgID4NCj4gPiA+ID4gPiA+ICAgICAgIC1hcmNoLTA1LnR4dF9fO0x5 OHZMeTh2THk4dkx5OCEhTkV0NnlNYU8tZ2shVnVRQ1ZIbnFKeV9hWUktRk50OUExYTVFekgNCj4g PiA+ID4gPiA+ICAgICAgID4gT0NyMGZaa0xQYmdnM0NQTnUwUHlyV3NyRng0MV9qV1gyQXQ4Vi0k DQo+ID4gPiA+ID4gPiAgICAgICA+DQo+ID4gPiA+ID4gPiAgICAgICA+IGZ1bGwgLTA0IC0+IDA1 IGRpZmY6DQo+ID4gPiA+ID4gPiAgICAgICA+DQo+ID4gPiA+ID4gPiAgICAgICA+DQo+ID4gPiA+ ID4gPiAgICAgICBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cDovL3Rvb2xzLmlldGYu b3JnLypyZmNkaWZmP3VybDE9aHR0cDoqDQo+ID4gPiA+ID4gPiAgICAgICA+ICpBdG9vbHMuaWV0 Zi5vcmcNCj4gPiA+ID4gPiA+ICAgICAgIDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cC0zQV9fQXRvb2xzLmlldGYub3JnJmQ9RHdJRkF3JmM9TEZZWi1vOV9I VU1lTVRTUWljdmpJZyZyPTZVaEdwVzlsd2k5ZE03allseFhEOHcmbT1NVzNTMG12aE5OOXVxNVZt alhkTlhHd3Npc1ZQNXd6ek84cjA0aDRhUDBvJnM9Z2dQcmtTQnppQnhjVVY0OE5LbXNrcnc2Zk96 VTk0bTNEazV1NjdVTWNSZyZlPSA+KmlkKmRyYWZ0LWlldGYtYmllci10ZS1hcmNoLTA0LnR4dCZ1 cmwyPWh0dHA6KipBdG9vbHMuDQo+ID4gPiA+ID4gPiAgICAgICA+IGlldGYub3JnDQo+ID4gPiA+ ID4gPiAgICAgICA8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHAtM0FfX2lldGYub3JnJmQ9RHdJRkF3JmM9TEZZWi1vOV9IVU1lTVRTUWljdmpJZyZyPTZVaEdw Vzlsd2k5ZE03allseFhEOHcmbT1NVzNTMG12aE5OOXVxNVZtalhkTlhHd3Npc1ZQNXd6ek84cjA0 aDRhUDBvJnM9VVJSTXBYTTk0a0I0eFN3MjdvN2ZHX0RWMklPRDRrSlZFM2VzalBJX2I5ZyZlPSA+ KmlkKmRyYWZ0LWlldGYtYmllci10ZS1hcmNoLTA1LnR4dF9fO0x5OHZMeTh2THk4diEhTkV0NnlN YU8tZ2sNCj4gPiA+ID4gPiA+ICAgICAgID4gIVZ1UUNWSG5xSnlfYVlJLUZOdDlBMWE1RXpIT0Ny MGZaa0xQYmdnM0NQTnUwUHlyV3NyRng0MV9qV2FuY3B6aXYkDQo+ID4gPiA+ID4gPiAgICAgICA+ DQo+ID4gPiA+ID4gPiAgICAgICA+IENvbW1lbnRzIGlubGluZSBiZWxvdy4NCj4gPiA+ID4gPiA+ ICAgICAgID4NCj4gPiA+ID4gPiA+ICAgICAgID4gQ2hlZXJzDQo+ID4gPiA+ID4gPiAgICAgICA+ wqAgwqAgwqB0b2VybGVzcw0KPiA+ID4gPiA+ID4gICAgICAgPg0KPiA+ID4gPiA+ID4gICAgICAg PiBPbiBNb24sIE9jdCAyOCwgMjAxOSBhdCAwNzo1Mjo1OVBNICswMDAwLCBKZWZmcmV5IChaaGFv aHVpKQ0KPiA+ID4gPiA+ID4gICAgICAgWmhhbmcgd3JvdGU6DQo+ID4gPiA+ID4gPiAgICAgICA+ ID4gSSBUaG91Z2h0IHUtdHVybiBpcyB0aGUgbW9zdCBzaW1wbGUgY29tcGFyaXNvbiBsZWFmIHZz Lg0KPiA+ID4gPiA+ID4gICAgICAgbm9uLWxlYWYgQkZSLg0KPiA+ID4gPiA+ID4gICAgICAgPiA+ DQo+ID4gPiA+ID4gPiAgICAgICA+ID4gWnpoPiBUaGUgdGV4dCBpbiB0aGUgZW1haWwgaXMgc2Vy aW91c2x5IG1pc2FsaWduZWQuIExvb2tpbmcgYXQNCj4gPiA+ID4gPiA+ICAgICAgIHRoZSBwaWN0 dXJlIGluIHRoZSBkaWZmIGxpbmssIHdoaWxlIHlvdSBnYXZlIGEgVS10dXJuIGV4YW1wbGUsDQo+ ID4gPiA+ID4gPiAgICAgICB0aG91Z2ggZXZlbiBpZiBCRkVSMiBpcyBub3QgY29ubmVjdGVkIHRv IEJGUjLCoCBidXQgb25seSBjb25uZWN0ZWQNCj4gPiA+ID4gPiA+ICAgICAgIHRvIEJGRVIxICho ZW5jZSBubyBVLXR1cm4pLCB0aGVuIEJGRVIxIGlzIHN0aWxsIG5vdCBhIGxlYWYgQkZFUiBJDQo+ ID4gPiA+ID4gPiAgICAgICBzdXBwb3NlLiBUaGF0J3Mgd2h5IEkgc2FpZCB0aGUgZmlyc3Qgc2Vu dGVuY2Ugb2YgdGhlIGFib3ZlDQo+ID4gPiA+ID4gPiAgICAgICBwYXJhZ3JhcGggaXMgZW5vdWdo IHRvIGRlZmluZSBMZWFmIEJGRVIgd2hpbGUgdGhlIGV4YW1wbGUgaXRzZWxmDQo+ID4gPiA+ID4g PiAgICAgICBpcyBhY3R1YWxseSBub3QgbmVlZGVkLg0KPiA+ID4gPiA+ID4gICAgICAgPg0KPiA+ ID4gPiA+ID4gICAgICAgPiBBcmdoLi4uIG9rLCBoYWQgdG8gZml4IHR3byB3b3JkcywgQkZJUi0+ QkZFUiBhbmQgbGVmdC1oYW5kIC0+DQo+ID4gPiA+ID4gPiAgICAgICByaWdodC1oYW5kOg0KPiA+ ID4gPiA+ID4gICAgICAgPg0KPiA+ID4gPiA+ID4gICAgICAgPiBDb25zaWRlciBob3cgcmVkdW5k YW50IGRpc2pvaW50IHRyYWZmaWMgY2FuIHJlYWNoIEJGRVIxL0JGRVIyIGluDQo+ID4gPiA+ID4g PiAgICAgICBhYm92ZQ0KPiA+ID4gPiA+ID4gICAgICAgPiBwaWN0dXJlOiBXaGVuIEJGRVIxL0JG RVIyIGFyZSBOb24tTGVhZiBCRkVSIGFzIHNob3duIG9uIHRoZQ0KPiA+ID4gPiA+ID4gICAgICAg cmlnaHQgaGFuZA0KPiA+ID4gPiA+ID4gICAgICAgPiBzaWRlLCBvbmUgdHJhZmZpYyBjb3B5IHdv dWxkIGJlIGZvcndhcmRlZCB0byBCRkVSMSBmcm9tIEJGUjEsDQo+ID4gPiA+ID4gPiAgICAgICBi dXQgdGhlDQo+ID4gPiA+ID4gPiAgICAgICA+IG90aGVyIG9uZSBjb3VsZCBvbmx5IHJlYWNoIEJG RVIxIHZpYSBCRkVSMiwgd2hpY2ggbWFrZXMgQkZFUjIgYQ0KPiA+ID4gPiA+ID4gICAgICAgPiBu b24tTGVhZiBCRkVSLiBMaWtld2lzZSBCRkVSMSBpcyBhIG5vbi1MZWFmIEJGRVIgd2hlbiBmb3J3 YXJkaW5nDQo+ID4gPiA+ID4gPiAgICAgICA+IHRyYWZmaWMgdG8gQkZFUjINCj4gPiA+ID4gPiA+ ICAgICAgID4NCj4gPiA+ID4gPiA+ICAgICAgID4gPiBaemg+IEFkZGl0aW9uYWxseSwgaW4gbGVm dCBwYXJ0IG9mIHRoZSBwaWN0dXJlIHlvdSBhZGRlZCwgaWYNCj4gPiA+ID4gPiA+ICAgICAgIHNv bWUgZmFpbHVyZSBsZWFkcyB0byBCRlIyIHRvIGJlIG9ubHkgcmVhY2hhYmxlIHZpYSBCRkVSMSwg dGhlbg0KPiA+ID4gPiA+ID4gICAgICAgQkZFUjEgaXMgbm8gbG9uZ2VyIGEgbGVhZiBCRkVSLg0K PiA+ID4gPiA+ID4gICAgICAgPg0KPiA+ID4gPiA+ID4gICAgICAgPiBBZGRlZCBzZW50ZW5jZToN Cj4gPiA+ID4gPiA+ICAgICAgID4NCj4gPiA+ID4gPiA+ICAgICAgID4gPHQ+Tm90ZSB0aGF0IHRo ZSBCRkVSIGluIHRoZSBsZWZ0IGhhbmQgcGljdHVyZSBhcmUgb25seQ0KPiA+ID4gPiA+ID4gICAg ICAgZ3VhcmFudGVlZCB0bw0KPiA+ID4gPiA+ID4gICAgICAgPiBiZSBsZWFmLUJGUiBieSBmaXR0 aW5nIHJvdXRpbmcgY29uZmlndXJhdGlvbiB0aGF0IHByb2hpYml0cyB0cmFuc2l0DQo+ID4gPiA+ ID4gPiAgICAgICA+IHRyYWZmaWMgdG8gcGFzcyB0aHJvdWdoIGEgUEUsIHdoaWNoIGlzIGNvbW1v bmx5IGFwcGxpZWQgaW4gdGhlc2UNCj4gPiA+ID4gPiA+ICAgICAgID4gdG9wb2xvZ2llcy48L3Q+ DQo+ID4gPiA+ID4gPiAgICAgICA+DQo+ID4gPiA+ID4gPiAgICAgICA+ID4gSSBhc3N1bWUgeW91 IGRvbid0IHJlYXNzaWduIEJQcyB3aGVuIGxpbmtzIGdvIHVwIGFuZCBkb3duLg0KPiA+ID4gPiA+ ID4gICAgICAgPg0KPiA+ID4gPiA+ID4gICAgICAgPiBJIGRpZG4ndCB3YW50IHRvIGRpc2N1c3Mg dGhhdCBvcHRpb24gaW4gdGhpcyBkb2N1bWVudC4gSXRzDQo+ID4gPiA+ID4gPiAgICAgICBvYnZp b3VzbHkNCj4gPiA+ID4gPiA+ICAgICAgID4gcGVyZmVjdGx5IGZlYXNpYmxlLCBidXQgYmUgeWV0 IGEgYmlnIGFtb3VudCBvZiB0ZXh0IChlc3BlY2lhbGx5IHRoZQ0KPiA+ID4gPiA+ID4gICAgICAg PiBjb25zaWRlcmF0aW9ucyBob3cgdG8gZG8gdGhpcyBtYWtlLWJlZm9yZS1icmVhay4gRnV0dXJl IGRvYy4NCj4gPiA+ID4gPiA+ICAgICAgID4NCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+IGJ1dCBz dWJzZXF1ZW50IHBvbGFyaXphdGlvbiBleGFtcGxlIGNvbmZ1c2VzIG1lLiBJdCBzZWVtcw0KPiA+ ID4gPiA+ID4gICAgICAgdGhhdCBCUCAwOjYgaXMgYXNzaWduZWQgdG8gdGhlIHJvdXRlZCBhZGph Y2VuY3kgQkZSMTAgKHdoaWNoIGlzDQo+ID4gPiA+ID4gPiAgICAgICBhY3R1YWxseSB0YWxrZWQg YWJvdXQgaW4gU2VjdGlvbiA0LjgpLg0KPiA+ID4gPiA+ID4gICAgICAgPiA+DQo+ID4gPiA+ID4g PiAgICAgICA+ID4gU2VjdGlvbiA0LjcgZG9lcyBub3QgbWVudGlvbiAicm91dGVkIiBhdCBhbGws IHNvIHRoZXJlIGFyZSBubw0KPiA+ID4gPiA+ID4gICAgICAgcm91dGVkIGFkamFjZW5jaWVzIGF0 IGFsbCB1c2VkIGluIDQuNy4gU28gaSBhbSBub3Qgc3VyZSB3aGF0IHlvdQ0KPiA+ID4gPiA+ID4g ICAgICAgYXJlIGNvbmZ1c2VkIGFib3V0Lg0KPiA+ID4gPiA+ID4gICAgICAgPiA+DQo+ID4gPiA+ ID4gPiAgICAgICA+ID4gWnpoPiAiVGhlIEJJRlQgb2YgZWFjaCBCRlIgYXJlIG9ubHkgcG9wdWxh dGVkIHdpdGggQlBzIHRoYXQNCj4gPiA+ID4gPiA+ICAgICAgIGFyZSBhZGphY2VudCB0byB0aGUg QkZSIGluIHRoZSBCSUVSLVRFIHRvcG9sb2d5Ii4NCj4gPiA+ID4gPiA+ICAgICAgID4NCj4gPiA+ ID4gPiA+ICAgICAgID4gQ29ycmVjdCB0ZXh0IGZyb20gdGhlIGludHJvZHVjdGlvbi4gT2suDQo+ ID4gPiA+ID4gPiAgICAgICA+DQo+ID4gPiA+ID4gPiAgICAgICA+ID4gWnpoPiBTaW5jZSB0aGUg c2FtZSAwOjYgaXMgaW4gQklGVFMgb2YgQkZSMS9CRlIyL0JGUjMgKGFuZCBJDQo+ID4gPiA+ID4g PiAgICAgICBzdXBwb3NlIGluIEJGUjR+QkZSOSBhcyB3ZWxsIGV2ZW4gdGhvdWdoIG5vdCBkcmF3 biksIEkgYXNzdW1lZA0KPiA+ID4gPiA+ID4gICAgICAgaXQncyBmb3IgdGhlICJNUDJQIiByb3V0 ZWQgYWRqYWNlbmN5IHRvIFIxMDsgdGhvdWdoIEkgdGhlbiBydWxlZA0KPiA+ID4gPiA+ID4gICAg ICAgdGhhdCBvdXQgLSBidXQgSSBkb24ndCBrbm93IHdoYXQgMDo2IHJlcHJlc2VudCBub3cgb24g QkZSMSwgQkZSMiwNCj4gPiA+ID4gPiA+ICAgICAgIGFuZCBCRlIzLg0KPiA+ID4gPiA+ID4gICAg ICAgPg0KPiA+ID4gPiA+ID4gICAgICAgPiBBaC4gT2suIEkgdGhvdWdodCBpIGNvdWxkIHN0cmlw IGRvd24gdGhlIGV4YW1wbGUgdG8gc2hvdyBvbmx5IHRoZQ0KPiA+ID4gPiA+ID4gICAgICAgPiBh ZGphY2VuY2llcyByZWxldmFudCB0byB0aGUgZm9sbG93aW5nIGRpc2N1c2lvbiwgYnV0IHNlZW1p bmdseSB0aGlzDQo+ID4gPiA+ID4gPiAgICAgICA+IGNhbiBpbnRyb2R1Y2UgdGhlIGNvbmZ1c2lv biB5b3UgaGF2ZS4NCj4gPiA+ID4gPiA+ICAgICAgID4NCj4gPiA+ID4gPiA+ICAgICAgID4gU28g aSBjb21wbGV0ZWQgdGhlIGV4YW1wbGUgd2l0aCB0aGUgQlAgYXNzaWdubWVudCBhY29zcyBhbGwN Cj4gPiA+ID4gPiA+ICAgICAgIG5vZGVzLCBidXQNCj4gPiA+ID4gPiA+ICAgICAgID4gYWRkZWQg dGV4dCBwb2ludGluZyB0byBhIG5ldyBzZWN0aW9uIGZ1cnRoZXIgZG93biB0byBkaXNjdXNzIHRo ZQ0KPiA+ID4gPiA+ID4gICAgICAgPiByZS11c2Ugb2YgQlAgZm9yIHdoaWNoIHRoaSBwaWN0dXJl IGlzIGFsc28gYW4gZXhhbXBsZS4NCj4gPiA+ID4gPiA+ICAgICAgID4NCj4gPiA+ID4gPiA+ICAg ICAgID4gKGNoZWNrIG91dCB0aGUgZGlmZiwgbmV3IHJldXNlIHRleHQgdG8gbG9uZyB0byBjb3B5 IGlubGluZSkuDQo+ID4gPiA+ID4gPiAgICAgICA+DQo+ID4gPiA+ID4gPiAgICAgICA+ID4gVGhl IHdob2xlIHB1cnBvc2Ugb2YgdGhlIEVDTVAgQlBzIGlzIG9mIGNvdXJzZSB0byBzYXZlIGJpdHMs DQo+ID4gPiA+ID4gPiAgICAgICBvdGhlcndpc2Ugd2UnZCBnaXZlIGVhY2ggbGluayBhIHNlcGFy YXRlIEJQLCB3aGljaCB3b3VsZCBiZSA2IEJQDQo+ID4gPiA+ID4gPiAgICAgICB0byByZWFjaCB0 byBCRlI0Li4uQkZSNyBmcm9tIEJGUjEuDQo+ID4gPiA+ID4gPiAgICAgICA+ID4NCj4gPiA+ID4g PiA+ICAgICAgID4gPiBaemg+IFRoZSB0cm91YmxlIEkgYW0gaGF2aW5nIGlzIHRoYXQgdGhlIHNh bWUgMDo2IGlzIGFzc2lnbmVkDQo+ID4gPiA+ID4gPiAgICAgICB0byBkaWZmZXJlbnQgdGhpbmdz IGFuZCBpdCdzIHByZXNlbnQgb24gYWxsIEJGUjEvQkZSMi9CRlIzLiBJdCBpcw0KPiA+ID4gPiA+ ID4gICAgICAgcGVyaGFwcyBhbiBpbnRlbnRpb25hbCBzbWFydCBkZXNpZ24gYnV0IEkgaGF2ZSBu b3Qgd3JhcHBlZCBteSBtaW5kDQo+ID4gPiA+ID4gPiAgICAgICBhcm91bmQgaXQuIEl0J3MgYXBw YXJlbnRseSBkaWZmZXJlbnQgZnJvbSB0aGUgbGluayBidW5kbGUgY2FzZSwgc28NCj4gPiA+ID4g PiA+ICAgICAgIGJldHRlciBzZXBhcmF0ZSBpdCBvdXQgYW5kIGVsYWJvcmF0ZSBpdCAoaW5jbHVk aW5nIHRoZSBETlIgZmxhZw0KPiA+ID4gPiA+ID4gICAgICAgdGhhdCBtaWdodCBiZSBuZWVkZWQg aGVyZSAtIElmIHRoZSBwYWNrZXQgYXJyaXZlcyBvbiBCRlIxIHdpdGgNCj4gPiA+ID4gPiA+ICAg ICAgIDA6Niwgd291bGQgdGhlIEJQIHJlc2V0IHdoZW4gaXQgaXMgc2VudCB0byBCRlIyLzMpPw0K PiA+ID4gPiA+ID4gICAgICAgPg0KPiA+ID4gPiA+ID4gICAgICAgPiBZZXMsIHRoZXJlIHdhcyB0 aGUgYnVnIG9mIHJldXNpbmcgQlAgMDo2IGFjcm9zcyBzZXF1ZW50aWFsIEJGUg0KPiA+ID4gPiA+ ID4gICAgICAgYWxvbmcNCj4gPiA+ID4gPiA+ICAgICAgID4gdGhlIHBhdGgsIGJ1dCBub3cgdGhl IGV4YW1wbGUgY29ycmVjdGx5IHJldXNlcyBzZXBhcmF0ZSBCUCBhdA0KPiA+ID4gPiA+ID4gICAg ICAgPiBkaWZmZXJlbnQgc3RhZ2VzIG9mIHRoZSBwYXRocyAoQlAgMDo2IG9uIEJGUjEsIEJQIDA6 NyBvbg0KPiA+ID4gPiA+ID4gICAgICAgQkZSMi9CRlIzKSBhbmQgc28gb24uDQo+ID4gPiA+ID4g PiAgICAgICA+DQo+ID4gPiA+ID4gPiAgICAgICA+IFRoYW5rcyENCj4gPiA+ID4gPiA+ICAgICAg ID4NCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+IDQuOC7CoCBSb3V0ZWQgYWRqYWNlbmNpZXMNCj4g PiA+ID4gPiA+ICAgICAgID4gPiA+DQo+ID4gPiA+ID4gPiAgICAgICA+ID4gPiBJZiBJIHVuZGVy c3RhbmQgaXQgY29ycmVjdGx5LCB0aGVyZSBpcyBhIEJQIGFzc2lnbmVkIHRvDQo+ID4gPiA+ID4g PiAgICAgICBMMS9MMi9MMw0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gcmVzcGVjdGl2ZWx5IChw MnAgbGluayksIGFuZCB0aGVuIHRoZXJlIGFyZSBCUHMgYXNzaWduZWQgdG8NCj4gPiA+ID4gPiA+ ICAgICAgIE1QMlAgdHVubmVscyAocm91dGVkIGFkamFjZW5jeSBmcm9tIGV2ZXJ5IEJGUikgdG8g dGhlIEwxL0wyL0wzDQo+ID4gPiA+ID4gPiAgICAgICBpbnRlcmZhY2UgYWRkcmVzc2VzIGFuZCBs b29wYmFjayBhZGRyZXNzZXMgb24gQkZSMi8zLg0KPiA+ID4gPiA+ID4gICAgICAgPiA+DQo+ID4g PiA+ID4gPiAgICAgICA+ID4gT2sgdGhhdCB3YXNuJ3QgcXVpdGUgdGhlIHJlYWQgaSBleHBlY3Rl ZC4gTGV0IG1lIGNsYXJpZnkgdGhlDQo+ID4gPiA+ID4gPiAgICAgICB0ZXh0L3BpY3R1cmU6DQo+ ID4gPiA+ID4gPiAgICAgICA+ID4NCj4gPiA+ID4gPiA+ICAgICAgID4gPsKgIMKgIMKgIMKgIMKg IMKgIMKgIMKgIMKgIMKgIC4uLi4uLi4uLi4uLi4uLg0KPiA+ID4gPiA+ID4gICAgICAgPiA+wqAg wqAgwqAgwqAgwqAgLi4uQkZSMS0tLi4uwqAgwqAgwqAgwqAgwqAgwqAuLi4tLUwxLS0gQkZSMi4u Lg0KPiA+ID4gPiA+ID4gICAgICAgPiA+wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAuLi4g LlJvdXRlcnMuIC4uLi4tLUwyLS0vDQo+ID4gPiA+ID4gPiAgICAgICA+ID7CoCDCoCDCoCDCoCDC oCAuLi5CRlI0LS0uLi7CoCDCoCDCoCDCoCDCoCDCoC4uLi0tLS0tLSBCRlIzLi4uDQo+ID4gPiA+ ID4gPiAgICAgICA+ID7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCAuLi4uLi4uLi4uLi4u Li4uwqAgwqAgwqAgwqAgwqB8DQo+ID4gPiA+ID4gPiAgICAgICA+ID7CoCDCoCDCoCDCoCDCoCDC oCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoExPDQo+ID4g PiA+ID4gPiAgICAgICA+ID7CoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoCDCoE5ldHdvcmsg QXJlYSAxDQo+ID4gPiA+ID4gPiAgICAgICA+ID4NCj4gPiA+ID4gPiA+ICAgICAgID4gPiBBc3N1 bWUgdGhlIHJlcXVpcmVtZW50IGluIHRoZSBhYm92ZSBwaWN0dXJlIGlzIHRvIGV4cGxpY2l0bHkN Cj4gPiA+ID4gPiA+ICAgICAgIHN0ZWVyIHRyYWZmaWMgZmxvd3MgdGhhdCBoYXZlIGFycml2ZWQg YXQgQkZSMSBvciBCRlI0IHZpYSBhDQo+ID4gPiA+ID4gPiAgICAgICBzaG9ydGVzdCBwYXRoIGlu IHRoZSByb3V0aW5nIHVuZGVybGF5ICJuZXR3b3JrIGFyZWEgMSIgdG8gb25lIG9mDQo+ID4gPiA+ ID4gPiAgICAgICB0aGUgZm9sbG93aW5nIHRocmVlIG5leHQgc2VnbWVudHM6ICgxKSBCRlIyIHZp YSBsaW5rIEwxLCAoMikgQkZSMg0KPiA+ID4gPiA+ID4gICAgICAgdmlhIGxpbmsgTDIsICgzKSB2 aWEgQkZSMy4NCj4gPiA+ID4gPiA+ICAgICAgID4gPg0KPiA+ID4gPiA+ID4gICAgICAgPiA+IFRv IGFjaGlldmUgdGhpcywgYm90aCBCRlIxIGFuZCBCRlI0IGFyZSBzZXQgdXAgd2l0aCBhDQo+ID4g PiA+ID4gPiAgICAgICBmb3J3YXJkX3JvdXRlZCBhZGphY2VuY3kgQml0UG9zaXRpb24gdG93YXJk cyBhbiBhZGRyZXNzIG9mIEJGUjIgb24NCj4gPiA+ID4gPiA+ICAgICAgIGxpbmsgTDEsIGFub3Ro ZXIgZm9yd2FyZF9yb3V0ZWQgQml0UG9zaXRpb24gdG93YXJkcyBhbiBhZGRyZXNzIG9mDQo+ID4g PiA+ID4gPiAgICAgICBCRlIyIG9uIGxpbmsgTDIgYW5kIGEgdGhpcmQgZm9yd2FyZF9yb3V0ZWQg Qml0cG9zaXRpb24gdG93YXJkcyBhDQo+ID4gPiA+ID4gPiAgICAgICBub2RlIGFkZHJlc3MgTE8g b2YgQkZSMy4NCj4gPiA+ID4gPiA+ICAgICAgID4gPg0KPiA+ID4gPiA+ID4gICAgICAgPiA+IERv ZXMgdGhpcyBjbGVhciBpcCB0aGUgY29uZnVzaW9uID8NCj4gPiA+ID4gPiA+ICAgICAgID4gPg0K PiA+ID4gPiA+ID4gICAgICAgPiA+IFp6aD4gVGhlIHBpY3R1cmUgaXMgYmFkbHkgbWlzYWxpZ25l ZC4gSSdsbCB3YWl0IHRpbGwgNC43DQo+ID4gPiA+ID4gPiAgICAgICBxdWVzdGlvbnMgYXJlIGNs ZWFyZWQuDQo+ID4gPiA+ID4gPiAgICAgICA+DQo+ID4gPiA+ID4gPiAgICAgICA+IE9rLg0KPiA+ ID4gPiA+ID4gICAgICAgPg0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gSWYgQkZSMi8zIGFyZSBh bHNvIEJGRVJzLCB0aGVuIHRoZXkgYWRkaXRpb25hbGx5IHdpbGwgaGF2ZQ0KPiA+ID4gPiA+ID4g ICAgICAgQkZFUiBCUHMuDQo+ID4gPiA+ID4gPiAgICAgICA+ID4gPiBPbiBCRlIxLzQsIHRoZSBC SUZUIGVudHJpZXMgZm9yIHRoZSBNUDJQIEJQcyBmb3IgdGhlDQo+ID4gPiA+ID4gPiAgICAgICBM MS9MMi9MMy9sb29wYmFjayBpbnRlcmZhY2UgYWRkcmVzc2VzIG9mIEJGUjIvMyB3aWxsIHVzZQ0K PiA+ID4gPiA+ID4gICAgICAgZm9yd2FyZF9yb3V0ZWQoaW50ZXJmYWNlL2xvb3BiYWNrIGFkZHJl c3MpLiBGb3IgYSBwYWNrZXQgdG8gYmUNCj4gPiA+ID4gPiA+ICAgICAgIGRlY2Fwc3VsYXRlZCBv biBhIEJGRVIsIHRoZXJlIGlzIGEgbmVlZCBmb3IgYm90aCB0aGUgQkZFUiBCUCBhbmQNCj4gPiA+ ID4gPiA+ICAgICAgIGFub3RoZXIgQlAgKHAycC9sYW4vaHViLXNwb2tlL3JvdXRlZC1hZGphY2Vu Y3kpIGluIHRoZSBwYWNrZXQgKHRoZQ0KPiA+ID4gPiA+ID4gICAgICAgZm9ybWVyIGlzIGZvciBk ZWNhcHN1bGF0aW9uIGFuZCB0aGUgbGF0dGVyIGlzIGZvciBnZXR0aW5nIGl0IHRoZXJlKS4NCj4g PiA+ID4gPiA+ICAgICAgID4gPg0KPiA+ID4gPiA+ID4gICAgICAgPiA+IFRoaXMgaXMgbm90IGRp c2N1c3NlZCBpbiB0aGlzIHNlY3Rpb24sIGJ1dCB5b3UgYXJlIHJpZ2h0IC0gdW5sZXNzDQo+ID4g PiA+ID4gPiAgICAgICA+ID4gQkZSMiBvciBCRlIzIGlzIGEgbGVhZiBCRlIuIEluIHRoYXQgY2Fz ZSwgaXQgd291bGQganVzdA0KPiA+ID4gPiA+ID4gICAgICAgbGV2ZXJhZ2UgdGhlIG9uZSBzaGFy ZWQgImxlYWYtQkZSIiBCUCwgc28gdGhleSBkbyBub3QgbmVlZCBhDQo+ID4gPiA+ID4gPiAgICAg ICBwZXItQkZFUiBCUCBmb3IgbG9jYWxfZGVjYXAoKS4NCj4gPiA+ID4gPiA+ICAgICAgID4gPg0K PiA+ID4gPiA+ID4gICAgICAgPiA+IFp6aD4gUmlnaHQgLSBzaGFyZWQgbGVhZi1CRlIgQlAgYnV0 IHN0aWxsIG5lZWQgdGhhdCBCUCAodGhlDQo+ID4gPiA+ID4gPiAgICAgICBrZXkgaXMgdGhhdCB3 ZSBuZWVkIGEgQlAgdG8gZ2V0IHBhY2tldCB0byBhIEJGRVIgYW5kIHRoZW4gYSBCUCBmb3INCj4g PiA+ID4gPiA+ICAgICAgIGRlY2Fwc3VsYXRpb24pLg0KPiA+ID4gPiA+ID4gICAgICAgPg0KPiA+ ID4gPiA+ID4gICAgICAgPiBZb3UgZ290IGl0Lg0KPiA+ID4gPiA+ID4gICAgICAgPg0KPiA+ID4g PiA+ID4gICAgICAgPiA+ID4gSWYgdGhhdD8/P3MgdGhlIGNhc2UsIGl0Pz8/cyB3b3J0aCBwb2lu dCB0aGUgYWJvdmUgb3V0Lg0KPiA+ID4gPiA+ID4gICAgICAgPiA+DQo+ID4gPiA+ID4gPiAgICAg ICA+ID4gSG1tLi4uIFRoZSBsb2dpYyBvZiBCRkVSIEJQcyBpcyB0b3RhbGx5IGluZGVwZW5kZW50 IG9mIHRoZQ0KPiA+ID4gPiA+ID4gICAgICAgbG9naWMgb2YgZm9yd2FyZF9yb3V0ZWQgYWRqYWNl bmN5LCBzbyBpIHdvdWxkIHdvcnJ5IHRoYXQgcmVwZWF0aW5nDQo+ID4gPiA+ID4gPiAgICAgICB0 aGUgZXhwbGFuYXRpb24gb2YgQkZFUiBCUHMgd291bGQgY29uZmxhdGUgdGhlIGZvcndhcmRfcm91 dGVkDQo+ID4gPiA+ID4gPiAgICAgICBleHBsYW5hdGlvbi4NCj4gPiA+ID4gPiA+ICAgICAgID4g Pg0KPiA+ID4gPiA+ID4gICAgICAgPiA+IFp6aD4gSXQncyBqdXN0IHRoYXQgdGhpcyBpcyBhIHBs YWNlIHdoZXJlIGFsbCBraW5kcyBvZiBCUHMgYXJlDQo+ID4gPiA+ID4gPiAgICAgICB1c2VkIHNv IGl0J3MgZ29vZCB0byBoYXZlIGEgc3VtbWFyeSAoY291bGQgYmUgYSBzdWJzZWN0aW9uIDQuOSku DQo+ID4gPiA+ID4gPiAgICAgICA+DQo+ID4gPiA+ID4gPiAgICAgICA+IFllcywgYWRkZWQgc3Vj aCBhIHN1bW1hcnkuIFBscy4gY2hlY2suDQo+ID4gPiA+ID4gPiAgICAgICA+DQo+ID4gPiA+ID4g PiAgICAgICA+ID4gPiBBY3R1YWxseSwgdGhlIHJlYXNvbiB0aGF0IEkgdGhvdWdodCB0aGlzIGlz IE1QMlAgaXMgdGhhdCAwOjYNCj4gPiA+ID4gPiA+ICAgICAgIGlzIHByZXNlbnQgb24gUjEsIFIy LCBhbmQgUjMgKGFuZCBtb3JlIEkgYXNzdW1lKSBpbiBGaWd1cmUgMTIsIGJ1dA0KPiA+ID4gPiA+ ID4gICAgICAgbm93IEkgdGhpbmsgaXQgY2FuPz8/dCBiZSBNUDJQIChzbyBpdCBpcyBub3QgY29y cmVjdCB0byBoYXZlIDA6Ng0KPiA+ID4gPiA+ID4gICAgICAgcHJlc2VudCBvbiB0aG9zZSByb3V0 ZXJzID8/PyBvbmx5IHRoZSBwMnAgdHVubmVsIGhlYWQvdGFpbCBzaG91bGQNCj4gPiA+ID4gPiA+ ICAgICAgIGhhdmUgdGhlIEJQIHByZXNlbnQgaW4gdGhlIEJJRlQpLiBUaGUgcmVhc29uIGlzIHRo YXQgaWYgaXQgd2VyZQ0KPiA+ID4gPiA+ID4gICAgICAgTVAyUCwgYW55IHJvdXRlciBnZXR0aW5n IGEgY29weSB3aWxsIHNlbmQgaXQgdG8gdGhlIGVuZHBvaW50IG9mDQo+ID4gPiA+ID4gPiAgICAg ICB0aGUgcm91dGVkIGFkamFjZW5jeSwgY2F1c2luZyBsb3RzIG9mIGR1cGxpY2F0ZXMuDQo+ID4g PiA+ID4gPiAgICAgICA+ID4gPg0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gQW0gSSBnZXR0aW5n IHRoaXMgY29ycmVjdD8NCj4gPiA+ID4gPiA+ICAgICAgID4gPg0KPiA+ID4gPiA+ID4gICAgICAg PiA+IEkgdGhpbmsgeW91IGFyZSBzdGlsbCBleHBsYWluaW5nIGZyb20gdGhlIG1pc3VuZGVyc3Rz YW5kaW5nDQo+ID4gPiA+ID4gPiAgICAgICB0aGF0IHRoZSBFQ01QIGV4cGxhbmF0aW9ucyB3aGVy ZSBhYm91dCByb3V0ZWQgYWRqYWNlbmNpZXMuDQo+ID4gPiA+ID4gPiAgICAgICA+ID4NCj4gPiA+ ID4gPiA+ICAgICAgID4gPiBJIGhhdmUgbm93IGV4cGFuZGVkIHRoZSBzb21ld2hhdCB0ZXJzZSB0 ZXh0IGluIHRoZSBCSUZUIHRhYmxlDQo+ID4gPiA+ID4gPiAgICAgICBwaWN0dXJlcywgdG8gbWFr ZSBpdCBjbGVhciB0aGF0IHRoZSBFQ01QIGlzIGFjcm9zcyBtdWx0aXBlDQo+ID4gPiA+ID4gPiAg ICAgICBmb3J3YXJkX2Nvbm5lY3RlZCBhZGphY2VuY2llcyBpbiB0aGUgZXhhbXBsZXMuIEZvciBl eGFtcGxlLCBmaXJzdA0KPiA+ID4gPiA+ID4gICAgICAgQklGVCBwaWN0dXJlOg0KPiA+ID4gPiA+ ID4gICAgICAgPiA+DQo+ID4gPiA+ID4gPiAgICAgICA+ID7CoCDCoEJJRlQgZW50cnkgaW4gQkZS MToNCj4gPiA+ID4gPiA+ICAgICAgID4gPg0KPiA+ID4gPiA+ID4gICAgICAgwqAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gPiA+ID4gPiA+ICAgICAgID4gPsKgIMKgfCBJbmRleCB8wqAgQWRqYWNlbmNpZXMgwqAgwqAg wqAgwqAgwqAgwqAgwqAgwqAgwqB8DQo+ID4gPiA+ID4gPiAgICAgICA+ID4NCj4gPiA+ID4gPiA+ ICAgICAgIMKgPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09DQo+ID4gPiA+ID4gPiAgICAgICA+ID7CoCDCoHwgMDo2wqAgwqB8 wqAgRUNNUCh7Zm9yd2FyZF9jb25uZWN0ZWQoTDEsIEJGUjIpLCDCoCDCoCDCoCDCoCDCoCDCoCDC oCDCoCB8DQo+ID4gPiA+ID4gPiAgICAgICA+ID7CoCDCoHzCoCDCoCDCoCDCoHzCoCDCoCDCoCDC oCBmb3J3YXJkX2Nvbm5lY3RlZChMMiwgQkZSMiksIMKgIMKgIMKgIMKgIMKgIMKgIMKgIMKgIHwN Cj4gPiA+ID4gPiA+ICAgICAgID4gPsKgIMKgfMKgIMKgIMKgIMKgfMKgIMKgIMKgIMKgIGZvcndh cmRfY29ubmVjdGVkKEwzLCBCRlIyKX0sIHNlZWQpDQo+ID4gPiA+ID4gPiAgICAgICDCoCDCoCDC oHwNCj4gPiA+ID4gPiA+ICAgICAgID4gPg0KPiA+ID4gPiA+ID4gICAgICAgwqAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gPiA+ID4gPiA+ICAgICAgID4gPg0KPiA+ID4gPiA+ID4gICAgICAgPiA+IE9mIGNvdXJzZSwg YW4gRUNNUCBhZGphY2VuY3kgY2FuIGJlIGFjcm9zcyBhbnkgdHlwZSBvZg0KPiA+ID4gPiA+ID4g ICAgICAgYWRqYWNlbmNpZXMsIGJ1dCBhbGwgdGhlIHRleHQvZXhwbGFuYXRpb25zIHVzZWQgZm9y d2FyZF9jb25uZWN0ZWQsDQo+ID4gPiA+ID4gPiAgICAgICBhbmQgbm93IHRoZSBwaWN0dXJlcyBz aG93IHRoYXQgZXhwbGljaXRseS4NCj4gPiA+ID4gPiA+ICAgICAgID4gPg0KPiA+ID4gPiA+ID4g ICAgICAgPiA+IFp6aD4gSSBjYW4gdW5kZXJzdGFuZCB0aGUgbXVsdGktbGluayBjYXNlLCBidXQg dGhlIG11bHRpLWhvcA0KPiA+ID4gPiA+ID4gICAgICAgRUNNUCBjYXNlIChmcm9tIEJGUjEgdG93 YXJkcyBCRlIxMCkgaXMgY29uZnVzaW5nIG1lLiBJdCB3b3VsZCBoZWxwDQo+ID4gPiA+ID4gPiAg ICAgICB0byBnaXZlIGFuIGV4YW1wbGUgaG93IGl0IGNhbiBiZSB1c2VkLCBXSVRIT1VUIHdvcnJ5 aW5nIGFib3V0DQo+ID4gPiA+ID4gPiAgICAgICBwb2xhcml6YXRpb24uDQo+ID4gPiA+ID4gPiAg ICAgICA+DQo+ID4gPiA+ID4gPiAgICAgICA+IFBsZWFzZSBjaGVjayAtMDUgdGV4dCB0aGF0IGhh cyB0aGUgZnVsbCBzZXQgb2YgQklGVCBsaXN0ZWQgbm93Og0KPiA+ID4gPiA+ID4gICAgICAgPg0K PiA+ID4gPiA+ID4gICAgICAgPiBUaGVyZSBpc8KgIHJlYWxseSBub3RoaW5nIG5vdGhpbmcgdW5p cXVlIGluIG11bHRpLWhvcCBFQ01QIGZvcg0KPiA+ID4gPiA+ID4gICAgICAgQklFUi1URQ0KPiA+ ID4gPiA+ID4gICAgICAgPiB0aGF0IHdlIGRvIG5vdCBhbHNvIGhhdmUgaW4gYW55IG90aGVyIEVD TVAsIGV4Y2VwdCB0aGUNCj4gPiA+ID4gPiA+ICAgICAgIGNvbmNsdXNpb24gdGhhdA0KPiA+ID4g PiA+ID4gICAgICAgPiB3ZSB3YW50IHRvIHN1cHBvcnQgZmFzdCBIVyBoYXNoIG1lY2hhbmlzbXMg QU5EIGFsbG93IHRoZQ0KPiA+ID4gPiA+ID4gICAgICAgY29udHJvbGxlciB0bw0KPiA+ID4gPiA+ ID4gICAgICAgPiBzZXQgdXAgbm9uLXBvbGFyaXplZCBtdWx0aS1ob3AgRUNNUCBBTkQgYmUgYWJs ZSB0byBwcmVjYWxjdWxhdGUNCj4gPiA+ID4gPiA+ICAgICAgIHBhdGhzLg0KPiA+ID4gPiA+ID4g ICAgICAgPiBIZW5jZSB0aGUgc3BlY2lmaWNhdGlvbiBvZiBFQ01QIGFkamFjZW5jaWVzIHRvIGhh dmUgYSBjb250cm9sbGVyDQo+ID4gPiA+ID4gPiAgICAgICA+IGNvbmZpZ3VyYWJsZSBzZWVkLg0K PiA+ID4gPiA+ID4gICAgICAgPg0KPiA+ID4gPiA+ID4gICAgICAgPiBCdHc6IFRoZSBwaWN0dXJl IGlzIG1heWJlIHVubmVjZXNzYXJpbHkgbGFyZ2UgYmVjYXVzZSBpJ3ZlIHVzZWQNCj4gPiA+ID4g PiA+ICAgICAgIGl0IGZvcg0KPiA+ID4gPiA+ID4gICAgICAgPiAyMCB5ZWFycyB0byBleHBsYWlu IHRoZSBzYW1lIHBvbGFyaXphdGlvbiBpc3N1ZSBmb3IgdW5pY2FzdCB2cw0KPiA+ID4gPiA+ID4g ICAgICAgPiBtdWx0aWNhc3QsIGFuZCBmb3IgbXVsdGljYXN0IG9ubHkgQkZSMTAuLi5CRlI0IGFy ZSByZWxldmFudA0KPiA+ID4gPiA+ID4gICAgICAgKEVDTVAgb2YNCj4gPiA+ID4gPiA+ICAgICAg ID4gdGhlIFBJTS9tTERQIGpvaW5zKSwgd2hlcmVhcyBmb3IgdW5pY2FzdC9CSUVSIG9ubHkNCj4g PiA+ID4gPiA+ICAgICAgID4gQkZSMS4uLkJGUjcgYXJlIHJlbGV2YW50LiBCdXQgYmVpbmcgc3lt bWV0cmljLCB0aGUgcGljdHVyZSBtYWtlcyBpdA0KPiA+ID4gPiA+ID4gICAgICAgPiBjbGVhciBp dHMgdGhlIHNhbWUgcHJvYmxlbS4NCj4gPiA+ID4gPiA+ICAgICAgID4NCj4gPiA+ID4gPiA+ICAg ICAgID4gPiA+wqAgwqAgVG8gaW5oaWJpdCBsb29waW5nIGluIHRoZSBmYWNlIG9mIHN1Y2ggcGh5 c2ljYWwNCj4gPiA+ID4gPiA+ICAgICAgIG1pc2NvbmZpZ3VyYXRpb24sDQo+ID4gPiA+ID4gPiAg ICAgICA+ID4gPsKgIMKgIG9ubHkgZm9yd2FyZF9jb25uZWN0ZWQgYWRqYWNlbmNpZXMgYXJlIHBl cm1pdHRlZCB0byBoYXZlDQo+ID4gPiA+ID4gPiAgICAgICBETlIgc2V0LCBhbmQNCj4gPiA+ID4g PiA+ICAgICAgID4gPiA+wqAgwqAgdGhlIGxpbmsgbGF5ZXIgZGVzdGluYXRpb24gYWRkcmVzcyBv ZiB0aGUgYWRqYWNlbmN5DQo+ID4gPiA+ID4gPiAgICAgICAoZS5nLsKgIE1BQw0KPiA+ID4gPiA+ ID4gICAgICAgPiA+ID7CoCDCoCBhZGRyZXNzKSBwcm90ZWN0cyBhZ2FpbnN0IGNsb3NpbmcgdGhl IGxvb3AuwqAgTGluayBsYXllcnMNCj4gPiA+ID4gPiA+ICAgICAgIHdpdGhvdXQgcG9ydA0KPiA+ ID4gPiA+ID4gICAgICAgPiA+ID7CoCDCoCB1bmlxdWUgbGluayBsYXllciBhZGRyZXNzZXMgc2hv dWxkIG5vdCBiZSB1c2VkIHdpdGggdGhlDQo+ID4gPiA+ID4gPiAgICAgICBETlIgZmxhZyBzZXQu DQo+ID4gPiA+ID4gPiAgICAgICA+ID4gPg0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gSXQ/Pz9z IG5vdCBjbGVhciBob3cgbGluayBsYXllciBhZGRyZXNzIGhlbHBzPw0KPiA+ID4gPiA+ID4gICAg ICAgPiA+DQo+ID4gPiA+ID4gPiAgICAgICA+ID4gSSBoYXZlIGV4cGFuZGVkIHRoaXMgdG8NCj4g PiA+ID4gPiA+ICAgICAgID4gPiAibGluayBsYXllciBwb3J0IHVuaXF1ZSB1bmljYXN0IGRlc3Rp bmF0aW9uIGFkZHJlc3MiDQo+ID4gPiA+ID4gPiAgICAgICA+ID4NCj4gPiA+ID4gPiA+ICAgICAg ID4gPiBBa2E6IE1QTFMgb3IgZXRoZXJuZXQgaGF2ZSB1bmlxdWUgbGluayBsYXllciBkZXN0aW5h dGlvbg0KPiA+ID4gPiA+ID4gICAgICAgZGVzdGluYXRpb24gYWRkcmVzc2VzIChsYWJlbCBvciBk ZXN0aW5hdGlvbiBNQUMpLiBJZiB5b3UgdGhpbmsNCj4gPiA+ID4gPiA+ICAgICAgIGFib3V0IGlu Y29ycmVjdGx5IHBsdWdnZWQgSERMQyBsaW5rcyAoc3VjaCBhcyBvbGQgVDEvVDMvLi4uLg0KPiA+ ID4gPiA+ID4gICAgICAgbGlua3MpLCB0aGV5IG9ubHkgaGF2ZSAyIGdlbmVyaWMgYWRkcmVzc2Vz LCBpZiBpIHJlbWVtYmVyIDEgb3IgMw0KPiA+ID4gPiA+ID4gICAgICAgaW4gdGhlIEhETEMgZnJh bWUuIFNvIHdoZW4geW91IG1pc3BsdWcgb25lIG9mIHRob3NlIHAycCBjYWJsZXMNCj4gPiA+ID4g PiA+ICAgICAgIHdyb25nLCB0aGUgcGFja2V0cyB3b3VsZCBiZSBpbmNycmVjdGx5IHJlY2VpdmVk IGJ5IHRoZSB3cm9uZw0KPiA+ID4gPiA+ID4gICAgICAgcmVjZWl2ZXIgbm9kZSBhbmQgdGhlbiBE TlIgY291bGQgY2F1c2UgcGVyc2lzdGVudCBsb29wcyBvbmx5DQo+ID4gPiA+ID4gPiAgICAgICBz b2x2ZWQgYnkgVFRMLg0KPiA+ID4gPiA+ID4gICAgICAgPiA+DQo+ID4gPiA+ID4gPiAgICAgICA+ ID4gWnpoPiAiQ29uc2lkZXIgaW4gdGhlIHJpbmcgcGljdHVyZSB0aGF0IGxpbmsgTDQgZnJvbSBC RlIzIGlzDQo+ID4gPiA+ID4gPiAgICAgICBwbHVnZ2VkIGludG8gdGhlIEwxIGludGVyZmFjZSBv ZiBCRlJhIiAtIHN0aWxsIG5vdCBzdXJlIGhvdw0KPiA+ID4gPiA+ID4gICAgICAgbGFiZWwvbWFj IGhlbHBzIGhlcmUuIEkgc3VwcG9zZSB0aGUgcmluZyB0b3BvbG9neSBpcw0KPiA+ID4gPiA+ID4g ICAgICAgZGlzY292ZXJlZC92ZXJpZmllZCBieSB0aGUgY29udHJvbCBwbGFuZSBhbmQgd2hlbiB0 aGUgbWlzY2FsbGluZw0KPiA+ID4gPiA+ID4gICAgICAgaGFwcGVucyB0aGVuIHRoZSByaW5nIHdp bGwgbm90IGluY2x1ZGUgdGhlIEJGUjEvQkZSMiBwYXJ0IGFuZCBCRlIzDQo+ID4gPiA+ID4gPiAg ICAgICB3aWxsIG5vdCBoYXZlIHRoZSBETlIgc2V0PyBJZiByaW5nIGRpc2NvdmVyeS92YXJpY2F0 aW9uIGlzIG5vdA0KPiA+ID4gPiA+ID4gICAgICAgZG9uZSB0aGVuIHBlcmhhcHMgd2Ugc2hvdWxk IHBvaW50IG91dCB0aGF0IFJQRiBiYXNlZCBvbiBsaW5rIGxheWVyDQo+ID4gPiA+ID4gPiAgICAg ICBhZGRyZXNzIGlzIG5lZWRlZCAtIHRoZSBrZXkgaXMgUlBGICh3aGljaCBuZWVkcyB1bmlxdWUg bGluayBsYXllcg0KPiA+ID4gPiA+ID4gICAgICAgYWRkcmVzcyk/DQo+ID4gPiA+ID4gPiAgICAg ICA+DQo+ID4gPiA+ID4gPiAgICAgICA+IEZvcmdldCBSUEYuIEJJRVIoLVRFKSBoYXMgbm8gUlBG IChpc3N1ZXMpLiBJdHMganVzdCBsaWtlDQo+ID4gPiA+ID4gPiAgICAgICB1bmljYXN0LiBSUEYN Cj4gPiA+ID4gPiA+ICAgICAgID4gaXMganVzdCBhIHByb2JsZW0gZm9yIHJlY2VpdmVyIG9yaWdp bmF0ZWQgam9pbnMgbGlrZSBpbg0KPiA+ID4gPiA+ID4gICAgICAgUElNL21MRFAsIGJ1dA0KPiA+ ID4gPiA+ID4gICAgICAgPiBub3QgdW5pY2FzdC9iaWVyKC10ZSkvUlNWUC1URS4NCj4gPiA+ID4g PiA+ICAgICAgID4NCj4gPiA+ID4gPiA+ICAgICAgID4gRm9yd2FyZF9jb25uZWN0ZWQgaXMganVz dCBsaWtlIGEgdW5pY2FzdCBzdWJuZXQgYWRqYWNlbmN5IHRvIGENCj4gPiA+ID4gPiA+ICAgICAg IGRpcmVjdA0KPiA+ID4gPiA+ID4gICAgICAgPiBuZWlnaGJvcjogSW50ZXJmYWNlIGFuZCBMMiBh ZGRyZXNzcyBvZiB0aGUgZGVzdGluYXRpb24uDQo+ID4gPiA+ID4gPiAgICAgICA+DQo+ID4gPiA+ ID4gPiAgICAgICA+IFRoZSBjb250cm9sbGVyIChjb3VsZCBiZSBhIGh1bWFuKSAiYXNzdW1lcyIg YSBwYXJ0aWN1bGFyIHBoeXNpY2lhbA0KPiA+ID4gPiA+ID4gICAgICAgPiB0b3BvbG9neSwgZnJv bSB0ZWxlbWV0cnkva25vd2xlZGdlL3doYXRldmVyLiBJdCB0aGVuIGNhbGN1bGF0ZXMgdGhlDQo+ ID4gPiA+ID4gPiAgICAgICA+IGRlc2lyZWQgQklFUi1URSB0b3BvbG9neSBhbmQgcHVzaGVzIGl0 IGRvd24uIFRoaXMgdG9wb2xvZ3kgaXMNCj4gPiA+ID4gPiA+ICAgICAgIG1lYW50IHRvDQo+ID4g PiA+ID4gPiAgICAgICA+IGJlIGxvb3AgZnJlZSBvZiBjb3Vyc2Ugd3J0IHRvIHRoZSBjb25maWd1 cmVkIGFkamFjZW5jaWVzLg0KPiA+ID4gPiA+ID4gICAgICAgPiBJbiB0aGlzIEJJRVItVEUgdG9w b2xvZ3ksIEJGUjMgd2lsbCBoYXZlIGEgQlAgd2l0aCB0aGUNCj4gPiA+ID4gPiA+ICAgICAgID4g Zm9yd2FyZF9jb25uZWN0ZWQoTDQsIE1BQy1vZi1CRlIyKSBhZGphY2VuY3kuDQo+ID4gPiA+ID4g PiAgICAgICA+DQo+ID4gPiA+ID4gPiAgICAgICA+IElmIHRoZSBjYWJsZSBjb25uZWN0aW5nIHRv IEw0IGlzIG1pc3dpcmVkLCB0aGVuIEJGUjMgd291bGQgc3RpbGwNCj4gPiA+ID4gPiA+ICAgICAg IHNlbmQNCj4gPiA+ID4gPiA+ICAgICAgID4gdGhlIHBhY2tldHMgdG8gdGhlIE1BQyBhZGRyZXNz IG9mIEJGUjIsIGJ1dCBnaXZlbiBob3cgdGhlIGNhYmxlDQo+ID4gPiA+ID4gPiAgICAgICA+IGNv bm5lY3RzIHRvIHNvbWUgb3RoZXIgbm9kZSwgdGhlc2UgcGFja2V0cyB3aWxsIGJlIGRpc2NhcmRl ZCBieQ0KPiA+ID4gPiA+ID4gICAgICAgdGhhdA0KPiA+ID4gPiA+ID4gICAgICAgPiBub2RlLiBi ZWNhdXNlIHRoZXkncmUganVzdCBMMiB1bmljYXN0IHBhY2tldHMuDQo+ID4gPiA+ID4gPiAgICAg ICA+DQo+ID4gPiA+ID4gPiAgICAgICA+IEkgdGhpbmsgdGhpcyBpcyBlcXVhbGx5IHRydWUgd2hl biB3ZSBoYXZlIG5vcm1hbCBCSUVSL01QTFMgZW5hY3AuDQo+ID4gPiA+ID4gPiAgICAgICA+IFRo b3NlIHBhY2tldHMgdG9vIGFyZSBhZGRyZXNzZWQgdG8gdGhlIHVuaWNhc3QgTUFDIGFkZHJlc3Mg b2YgdGhlDQo+ID4gPiA+ID4gPiAgICAgICA+IG5laWdoYm9yLg0KPiA+ID4gPiA+ID4gICAgICAg Pg0KPiA+ID4gPiA+ID4gICAgICAgPiBOb3csIGlmL3doZW4gaGUgY29udHJvbGxlciByZWNvZ25p emVzIHRoYXQgdGhlIHBoeXNpY2FsIHRvcG9sb2d5DQo+ID4gPiA+ID4gPiAgICAgICBoYXMNCj4g PiA+ID4gPiA+ICAgICAgID4gY2hhbmdlZCwgdGhhdHMgYSBjb21wbGV0ZWx5IGRpZmZlcmVudCBz dG9yeSBhbmQgbm90IGFkZHJlc3NlZCBoZXJlLg0KPiA+ID4gPiA+ID4gICAgICAgPiBHaXZlbiBo b3cgd2UgYXNzdW1lZCB0aGlzIHdhcyBhIGNhYmxpbmcgbWlzdGFrZSwgdGhlIGNvbnRyb2xsZXIN Cj4gPiA+ID4gPiA+ICAgICAgIHdvdWxkDQo+ID4gPiA+ID4gPiAgICAgICA+IHByb2JhYmx5IG9u bHkgY29tcGxhaW4gYWJvdXQgdGhlIG1pc3dpcmluZyB0byBvcGVyYXRpb25zIGJ1dCBiZQ0KPiA+ ID4gPiA+ID4gICAgICAgaGFwcHkNCj4gPiA+ID4gPiA+ICAgICAgID4gdGhhdCB0aGUgZm9yd2Fy ZGluZyBwbGFuZSBqdXN0IG1ha2VzIHBhY2tldHMgZmFpbCBpbnN0ZWFkIG9mDQo+ID4gPiA+ID4g PiAgICAgICBsb29wLiBJZg0KPiA+ID4gPiA+ID4gICAgICAgPiB0aGlzIHdhcyBhIHBsYW5uZWQg Y2hhbmdlIHByb2Nlc3MsIHRoZW4gaXQgd2lsbCBiZSBzaW1pbGFyaWx5DQo+ID4gPiA+ID4gPiAg ICAgICA+IGNvbnZvbHV0ZWQgYXMgaXQgd291bGQgdG9kYXkgYmUgd2l0aCByZXdpcmluZyBjYWJs ZXMgaW4gYW4NCj4gPiA+ID4gPiA+ICAgICAgID4gU1ItTVBMUy9TUnY2IHRvcG9sb2d5IGFuZCB1 cGRhdGluZyBTSURzLg0KPiA+ID4gPiA+ID4gICAgICAgPg0KPiA+ID4gPiA+ID4gICAgICAgPiA+ ID4gQmVjYXVzZSB0aGUgZm9yd2FyZGluZyBpcyBkaWZmZXJlbnQgZnJvbSBCSUVSIGZvcndhcmRp bmcNCj4gPiA+ID4gPiA+ICAgICAgIChiZWNhdXNlIG9mIFsxXSBhYm92ZSksIHdlIG1pZ2h0IGFz IHdlbGwgaW50cm9kdWNlIGFuIG9wdGltaXphdGlvbg0KPiA+ID4gPiA+ID4gICAgICAgaGVyZSA/ Pz8gZm9yIGVhY2ggQklGVCwgY2FsY3VsYXRlIHRoZSBGLUJNIG9mIHRoZSBCSUZUIGl0c2VsZiAo dGhlDQo+ID4gPiA+ID4gPiAgICAgICBsb2dpY2FsID8/P29yPz8/IG9mIGFsbCB0aGUgQlBzIHBy ZXNlbnRlZCBpbiB0aGlzIEJJRlQpIGFuZCB0aGVuDQo+ID4gPiA+ID4gPiAgICAgICB1c2UgKHBh Y2tldC0+Yml0c3RyaW5nICYgQklGVC5GLUJNKSBhcyB0aGUgaW5wdXQgdG8NCj4gPiA+ID4gPiA+ ICAgICAgIEdldEZpcnN0L05leHRCaXRQb3NpdGlvbigpLiBUaGF0IHNob3VsZCBza2lwIG1hbnkg Yml0cy4NCj4gPiA+ID4gPiA+ICAgICAgID4gPg0KPiA+ID4gPiA+ID4gICAgICAgPiA+IFJpZ2h0 LiBCdXQgaSBleHBsaWNpdGx5IHJlbW92ZWQgdGhvc2Ugb3B0aW1pemF0aW9ucyAoaSBoYWQNCj4g PiA+ID4gPiA+ICAgICAgIHRoZW0gaW4gb2xkZXIgZHJhZnQgdmVyc2lvbnMpIGJlY2F1c2UgdGhl IHdob2xlIGlkZWEgb2YgdGhpcw0KPiA+ID4gPiA+ID4gICAgICAgcGljdHVyZSBpcyBzb2xlbHkg dGhlIGNvbXBhcmlzb24gd2l0aCBmaWd1cmUgNCBvZiBSRkM4Mjc5Lg0KPiA+ID4gPiA+ID4gICAg ICAgPiA+DQo+ID4gPiA+ID4gPiAgICAgICA+ID4gWnpoPiBJIHRoaW5rIGl0J3Mgd29ydGggcG9p bnQgdGhhdCBvcHRpbWl6YXRpb24gb3V0OyB5b3UgY2FuDQo+ID4gPiA+ID4gPiAgICAgICBtYXJr IGl0IG9wdGlvbmFsIGlmIHlvdSB3YW50IHRvIGVtcGhhc2l6ZSB0aGUgc2ltaWxhcml0eSB0byBC SUVSDQo+ID4gPiA+ID4gPiAgICAgICBmb3J3YXJkaW5nLCBidXQgc2luY2UgQklFUiBmb3J3YXJk aW5nIGRvZXMgZG8gdGhlIG1hc2tvZmYgc3RlcCwgaXQNCj4gPiA+ID4gPiA+ICAgICAgIGlzIHZl cnkgZWZmaWNpZW50IHdoaWxlIEJJRVItVEUgZm9yd2FyZGluZyBkb2VzIG5vdCBpdCB0aGUgbWFz a29mZg0KPiA+ID4gPiA+ID4gICAgICAgc3RlcCBzbyB0aGlzIG9wdGltaXphdGlvbiBpcyBpbXBv cnRhbnQuDQo+ID4gPiA+ID4gPiAgICAgICA+DQo+ID4gPiA+ID4gPiAgICAgICA+IE9rLiBJIHNp bXBsaWZpZWQgdGhlIHRleHQgY29tcGFyaXNvbiBCSUVSL0JJRVItVEUgd3J0LiB0byB0aGUgRkJN DQo+ID4gPiA+ID4gPiAgICAgICA+IHJ1bGVzIFsxXSBhbmQgWzJdIGFuZCBhZGRlZCBmb2xsb3dp bmcgcGFyYWdyYXBoOg0KPiA+ID4gPiA+ID4gICAgICAgPg0KPiA+ID4gPiA+ID4gICAgICAgPiA8 dD5JbiBCSUVSLCB0aGUgb3JkZXIgb2YgQlBzIGltcGFjdHMgdGhlIHJlc3VsdCBvZiBmb3J3YXJk aW5nDQo+ID4gPiA+ID4gPiAgICAgICBiZWNhdXNlIG9mIFsxXS4NCj4gPiA+ID4gPiA+ICAgICAg ID4gSW4gQklFUi1URSwgZm9yd2FyZGluZyBpcyBub3QgaW1wYWN0ZWQgYnkgdGhlIG9yZGVyIG9m IEJQcy4gSXQgaXMNCj4gPiA+ID4gPiA+ICAgICAgID4gdGhlcmVmb3JlIHBvc3NpYmxlIHRvIGZ1 cnRoZXIgb3B0aW1pemUgZm9yd2FyZGluZyB0aGFuIGluIEJJRVIuIEZvcg0KPiA+ID4gPiA+ID4g ICAgICAgPiBleGFtcGxlIHBhcmFsbGVsaXppbmcgZm9yd2FyZGluZyBhY3Jvc3MgbXVsdGlwbGUg RlBFIGNvcmVzIG9yDQo+ID4gPiA+ID4gPiAgICAgICA+IGRpc3RyaWJ1dGVkIGxpbmVjYXJkcyBk b2VzIG9ubHkgbmVlZCB0byBleGFtaW5lIGFuIGFyYml0cmFyeQ0KPiA+ID4gPiA+ID4gICAgICAg c3Vic2V0IG9mDQo+ID4gPiA+ID4gPiAgICAgICA+IEJQIGFuZCBub3QgZXZhbHVhdGUgdGhlIGRl cGVuZGVuY3kgYmV0d2VlbiBCUHMuPC90Pg0KPiA+ID4gPiA+ID4gICAgICAgPg0KPiA+ID4gPiA+ ID4gICAgICAgPiA+ID7CoCDCoCBUaGUgZm9sbG93aW5nIHBzZXVkb2NvZGUgaXMgY29tcHJlaGVu c2l2ZToNCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+DQo+ID4gPiA+ID4gPiAgICAgICA+ID4gPiBU aGUgYWJvdmUgc2VudGVuY2UgcmVhZHMgYSBiaXQgc3RyYW5nZSAob3IgbGFja3Mgc29tZSBzZWd1 ZSkuDQo+ID4gPiA+ID4gPiAgICAgICA+ID4NCj4gPiA+ID4gPiA+ICAgICAgID4gPiBJIGhvcGUg bm90LCBidXQgbWF5YmUgYmVzdCBsZWZ0IHRvIGEgbmF0aXZlIGVuZ2xpc2ggc3BlYWtlcg0KPiA+ ID4gPiA+ID4gICAgICAgKFJGQy1lZGl0b3IpLg0KPiA+ID4gPiA+ID4gICAgICAgPiA+DQo+ID4g PiA+ID4gPiAgICAgICA+ID4gVGhlIGZpcnN0IChSRkM4Mjc5KSBwc2V1ZG9jb2RlIHdhcyBzaW1w bGlmaWVkLiBUaGUgc2Vjb25kIG9uZQ0KPiA+ID4gPiA+ID4gICAgICAgaXMgY29tcHJlaGVuc2l2 ZS4gSWYgbm90IGNvbXByZWhlbnNpdmUsIHdoYXRzIGEgZ29vZCBvcHBvc2l0ZSBvZg0KPiA+ID4g PiA+ID4gICAgICAgc2ltcGxpZmllZCA/DQo+ID4gPiA+ID4gPiAgICAgICA+ID4NCj4gPiA+ID4g PiA+ICAgICAgID4gPiBaemg+IFBlcmhhcHMgIlRoZSBhYm92ZSBzaW1wbGlmaWVkIHBzZXVkb2Nv ZGUgaXMgZWxhYm9yYXRlZA0KPiA+ID4gPiA+ID4gICAgICAgZnVydGhlciBhcyBmb2xsb3dpbmci Pw0KPiA+ID4gPiA+ID4gICAgICAgPiA+IFp6aD4gSmVmZnJleQ0KPiA+ID4gPiA+ID4gICAgICAg Pg0KPiA+ID4gPiA+ID4gICAgICAgPiBEb25lLg0KPiA+ID4gPiA+ID4gICAgICAgPg0KPiA+ID4g PiA+ID4gICAgICAgPiBUaGFua3MgYSBsb3QuDQo+ID4gPiA+ID4gPiAgICAgICA+DQo+ID4gPiA+ ID4gPiAgICAgICA+DQo+ID4gPiA+ID4gPiAgICAgICA+ID4NCj4gPiA+ID4gPiA+ICAgICAgID4g PiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPiA+ ICAgICAgID4gPiA+IEZyb206IEJJRVIgW2JpZXItYm91bmNlc0BpZXRmLm9yZw0KPiA+ID4gPiA+ ID4gICAgICAgPG1haWx0bzpiaWVyLWJvdW5jZXNAaWV0Zi5vcmc+PG1haWx0bzpiaWVyLWJvdW5j ZXNAaWV0Zi5vcmcNCj4gPiA+ID4gPiA+ICAgICAgIDxtYWlsdG86Ymllci1ib3VuY2VzQGlldGYu b3JnPj5dDQo+ID4gPiA+ID4gPiAgICAgICA+ID4gPiBvbiBiZWhhbGYgb2YgVG9lcmxlc3MgRWNr ZXJ0IFt0dGVAY3MuZmF1LmRlDQo+ID4gPiA+ID4gPiAgICAgICA8bWFpbHRvOnR0ZUBjcy5mYXUu ZGU+PG1haWx0bzp0dGVAY3MuZmF1LmRlIDxtYWlsdG86dHRlQGNzLmZhdS4uZGU+Pl0NCj4gPiA+ ID4gPiA+ICAgICAgID4gPiA+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMDksIDIwMTkgMjM6MzgNCj4g PiA+ID4gPiA+ICAgICAgID4gPiA+IFRvOiBNaWtlIE1jQnJpZGUNCj4gPiA+ID4gPiA+ICAgICAg ID4gPiA+IENjOiBHcmVnIFNoZXBoZXJkOyBCSUVSIFdHOyBQYXNjYWwgVGh1YmVydCAocHRodWJl cnQpDQo+ID4gPiA+ID4gPiAgICAgICA+ID4gPiBTdWJqZWN0OiBSZTogW0JpZXJdIFdHTEMgLSBk cmFmdC1pZXRmLWJpZXItdGUtYXJjaA0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4NCj4gPiA+ID4g PiA+ICAgICAgID4gPiA+IFRoYW5rcywgTWlrZQ0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4NCj4g PiA+ID4gPiA+ICAgICAgID4gPiA+IFRoZSBhdXRob3JzIGFsc28gcmV2aWV3ZWQgdGhlIGRvY3Vt ZW50IGFuZCBjb25jbHVkZWQgdGhhdCBpdA0KPiA+ID4gPiA+ID4gICAgICAgd2FzDQo+ID4gPiA+ ID4gPiAgICAgICA+ID4gPiByZWFsbHkgaGFyZCB0byBnZXQgaW50byB0aGUgZG9jdW1lbnQgY29u dGV4dCBiZWNhdXNlIG9mIHRvbw0KPiA+ID4gPiA+ID4gICAgICAgbWFueQ0KPiA+ID4gPiA+ID4g ICAgICAgPiA+ID4gZm9yd2FyZCBkZXBlbmRlbmNpZXMuIFdlIHRyaWVkIHRvIGZpeCB0aGlzIGJ5 IGFkZGluZyB0d28NCj4gPiA+ID4gPiA+ICAgICAgIGhvcGVmdWxseQ0KPiA+ID4gPiA+ID4gICAg ICAgPiA+ID4gZ29vZCAmIGJhc2ljIGV4YW1wbGVzIGludG8gdGhlIEludHJvZHVjdGlvbiBzZWN0 aW9uIGFuZA0KPiA+ID4gPiA+ID4gICAgICAgdXNpbmcgdGhlbQ0KPiA+ID4gPiA+ID4gICAgICAg PiA+ID4gdG8gYWxzbyBhZGQgYSBiZXR0ZXIgZGVmaW5pdGlvbiBvZiB0aGUgdGVybSAiQklFUi1U RQ0KPiA+ID4gPiA+ID4gICAgICAgVG9wb2xvZ3kiIGluIHRoZSBJbnRyb2R1Y3Rpb24uDQo+ID4g PiA+ID4gPiAgICAgICA+ID4gPiBIb3BlZnVsbHkgdGhpcyBtYWtlcyByZWFkaW4gdGhlIHJlc3Qg b2YgdGUgZG9jdW1lbnQgc21vb3RoZXIuDQo+ID4gPiA+ID4gPiAgICAgICA+ID4gPg0KPiA+ID4g PiA+ID4gICAgICAgPiA+ID4gQWxzbyBpbXByb3ZlZCB0ZXh0IG9mIEFic3RyYWN0IGFuZCByZWZp bmVkIHRleHQgY29tcGFyaWluZw0KPiA+ID4gPiA+ID4gICAgICAgQklFUi1URSB3aXRoIFNSLg0K PiA+ID4gPiA+ID4gICAgICAgPiA+ID4NCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+DQo+ID4gPiA+ ID4gPiAgICAgICBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cDovL3Rvb2xzLmlldGYu b3JnLypyZmNkaWZmP3VybDE9aHR0cHM6DQo+ID4gPiA+ID4gPiAgICAgICA+ID4gPiAqKkF0b29s cy5pZXRmLm9yZw0KPiA+ID4gPiA+ID4gICAgICAgPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbS92Mi91cmw/dT1odHRwLTNBX19BdG9vbHMuaWV0Zi5vcmcmZD1Ed0lGQXcmYz1MRlla LW85X0hVTWVNVFNRaWN2aklnJnI9NlVoR3BXOWx3aTlkTTdqWWx4WEQ4dyZtPU1XM1MwbXZoTk45 dXE1Vm1qWGROWEd3c2lzVlA1d3p6TzhyMDRoNGFQMG8mcz1nZ1Bya1NCemlCeGNVVjQ4Tkttc2ty dzZmT3pVOTRtM0RrNXU2N1VNY1JnJmU9ID4qaWQqZHJhZnQtaWV0Zi1iaWVyLXRlLWFyY2gtMDIu dHh0JnVybDI9aHR0cHM6KipBDQo+ID4gPiA+ID4gPiAgICAgICA+ID4gPiB0b29sDQo+ID4gPiA+ ID4gPiAgICAgICA+ID4gPiBzLmlldGYub3JnDQo+ID4gPiA+ID4gPiAgICAgICA8aHR0cHM6Ly91 cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX3MuaWV0Zi5vcmcmZD1E d0lGQXcmYz1MRllaLW85X0hVTWVNVFNRaWN2aklnJnI9NlVoR3BXOWx3aTlkTTdqWWx4WEQ4dyZt PU1XM1MwbXZoTk45dXE1Vm1qWGROWEd3c2lzVlA1d3p6TzhyMDRoNGFQMG8mcz1PeDhBUHIwQVU4 aU1hTmphV05jR1lRRGZrcmhKQk50c0FaV1J2Zm1PX1pJJmU9ID4qaWQqZHJhZnQtaWV0Zi1iaWVy LXRlLWFyY2gtMDMudHh0X187THk4dkx5OHZMeTh2IThXb0E2Ug0KPiA+ID4gPiA+ID4gICAgICAg PiA+ID4gakM4MQ0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4NCj4gPiA+ID4gPiA+ICAgICAgIGMh WHZINEFBeGZyRGpGb0tfc2VyY3daTXNjME81TjQyZUVOT3M0bF9xZHNYRjBLd1pEODJjSkxERkZO Vl9lVFVFaA0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gJA0KPiA+ID4gPiA+ID4gICAgICAgPiA+ ID4NCj4gPiA+ID4gPiA+ICAgICAgIDxodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cDov dG9vbHMuaWV0Zi5vcmcvKnJmY2RpZmY/dXJsMT1odHRwczoNCj4gPiA+ID4gPiA+ICAgICAgID4g PiA+ICoqQXRvb2xzLmlldGYub3JnDQo+ID4gPiA+ID4gPiAgICAgICA8aHR0cHM6Ly91cmxkZWZl bnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHAtM0FfX0F0b29scy5pZXRmLm9yZyZkPUR3 SUZBdyZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj02VWhHcFc5bHdpOWRNN2pZbHhYRDh3Jm09 TVczUzBtdmhOTjl1cTVWbWpYZE5YR3dzaXNWUDV3enpPOHIwNGg0YVAwbyZzPWdnUHJrU0J6aUJ4 Y1VWNDhOS21za3J3NmZPelU5NG0zRGs1dTY3VU1jUmcmZT0gPippZCpkcmFmdC1pZXRmLWJpZXIt dGUtYXJjaC0wMi50eHQmdXJsMj1odHRwczoqKkENCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+IHRv b2wNCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+IHMuaWV0Zi5vcmcNCj4gPiA+ID4gPiA+ICAgICAg IDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fcy5p ZXRmLm9yZyZkPUR3SUZBdyZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj02VWhHcFc5bHdpOWRN N2pZbHhYRDh3Jm09TVczUzBtdmhOTjl1cTVWbWpYZE5YR3dzaXNWUDV3enpPOHIwNGg0YVAwbyZz PU94OEFQcjBBVThpTWFOamFXTmNHWVFEZmtyaEpCTnRzQVpXUnZmbU9fWkkmZT0gPippZCpkcmFm dC1pZXRmLWJpZXItdGUtYXJjaC0wMy50eHRfXztMeTh2THk4dkx5OHYhOFdvQTZSDQo+ID4gPiA+ ID4gPiAgICAgICA+ID4gPiBqQzgxDQo+ID4gPiA+ID4gPiAgICAgICA+ID4gPg0KPiA+ID4gPiA+ ID4gICAgICAgYyFVQlRHdldXcE1IeWVpU2FueHM2dkliX0VuQlZneWc2Ym9BQVc0bnJxanU4VUNM T2dpdVhjOFlfNnNOZDFuamNYDQo+ID4gPiA+ID4gPiAgICAgICA+ID4gPiAkPg0KPiA+ID4gPiA+ ID4gICAgICAgPiA+ID4NCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+IENoZWVycw0KPiA+ID4gPiA+ ID4gICAgICAgPiA+ID7CoCDCoCDCoFRvZXJsZXNzDQo+ID4gPiA+ID4gPiAgICAgICA+ID4gPg0K PiA+ID4gPiA+ID4gICAgICAgPiA+ID4gT24gV2VkLCBKdW4gMjYsIDIwMTkgYXQgMTA6Mzk6MzZB TSAtMDcwMCwgTWlrZSBNY0JyaWRlIHdyb3RlOg0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gPiBI b3cgYWJvdXQgdGhyZWU/IEkgc3VwcG9ydC4NCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+ID4gbWlr ZQ0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gPg0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gPiBP biBUdWUsIEp1biAyNSwgMjAxOSBhdCAxMDo0MiBBTSBHcmVnIFNoZXBoZXJkDQo+ID4gPiA+ID4g PiAgICAgICA8Z2pzaGVwQGdtYWlsLmNvbQ0KPiA+ID4gPiA+ID4gICAgICAgPG1haWx0bzpnanNo ZXBAZ21haWwuY29tPjxtYWlsdG86Z2pzaGVwQGdtYWlsLmNvbQ0KPiA+ID4gPiA+ID4gICAgICAg PG1haWx0bzpnanNoZXBAZ21haWwuY29tPj4+IHdyb3RlOg0KPiA+ID4gPiA+ID4gICAgICAgPiA+ ID4gPiA+DQo+ID4gPiA+ID4gPiAgICAgICA+ID4gPiA+ID4gV2UgY2Fubm90IHRha2UgdHdvICd5 ZXMnIHZvdGVzIGFuZCBXRyBjb25zZW5zdXMuDQo+ID4gPiA+ID4gPiAgICAgICA+ID4gPiA+ID4g UGxlYXNlLCByZWFkIGFuZCByZXNwb25kLiBJZiB5b3UgZG9uJ3Qgc3VwcG9ydCwgdGhlbg0KPiA+ ID4gPiA+ID4gICAgICAgcGxlYXNlIHZvdGUgYXMgbXVjaCBwdWJsaWNseSByaWdodCBoZXJlLg0K PiA+ID4gPiA+ID4gICAgICAgPiA+ID4gPiA+DQo+ID4gPiA+ID4gPiAgICAgICA+ID4gPiA+ID4g VGhhbmtzLA0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gPiA+IEdyZWcNCj4gPiA+ID4gPiA+ICAg ICAgID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gPiA+IE9uIE1vbiwgSnVuIDMs IDIwMTkgYXQgMTA6MDUgUE0gUGFzY2FsIFRodWJlcnQNCj4gPiA+ID4gPiA+ICAgICAgIChwdGh1 YmVydCkgPHB0aHViZXJ0QGNpc2NvLmNvbQ0KPiA+ID4gPiA+ID4gICAgICAgPG1haWx0bzpwdGh1 YmVydEBjaXNjby5jb20+PG1haWx0bzpwdGh1YmVydEBjaXNjby5jb20NCj4gPiA+ID4gPiA+ICAg ICAgIDxtYWlsdG86cHRodWJlcnRAY2lzY28uY29tPj4+IHdyb3RlOg0KPiA+ID4gPiA+ID4gICAg ICAgPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gPiA+PiBTdXBwb3J0Og0KPiA+ ID4gPiA+ID4gICAgICAgPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gPiA+PiBJ IHNlZSBncmVhdCB2YWx1ZSBpbiBkZXRlcm1pbmlzdGljIG5ldHdvcmtzIGFzIHdlbGwgYXMNCj4g PiA+ID4gPiA+ICAgICAgIElPVCAod2l0aCBSUEwpLg0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4g PiA+Pg0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gPiA+PiBBbGwgdGhlIGJlc3QsDQo+ID4gPiA+ ID4gPiAgICAgICA+ID4gPiA+ID4+DQo+ID4gPiA+ID4gPiAgICAgICA+ID4gPiA+ID4+IFBhc2Nh bA0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gPiA+Pg0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4g PiA+PiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiA+ID4gPiAgICAgICA+ID4g PiA+ID4+ID4gRnJvbTogQklFUg0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gPiA+PiA+IDxiaWVy LWJvdW5jZXNAaWV0Zi5vcmcNCj4gPiA+ID4gPiA+ICAgICAgIDxtYWlsdG86Ymllci1ib3VuY2Vz QGlldGYub3JnPjxtYWlsdG86Ymllci1ib3VuY2VzQGlldGYub3JnDQo+ID4gPiA+ID4gPiAgICAg ICA8bWFpbHRvOmJpZXItYm91bmNlc0BpZXRmLm9yZz4+PiBPbg0KPiA+ID4gPiA+ID4gICAgICAg PiA+ID4gPiA+PiA+IEJlaGFsZiBPZiBUb2VybGVzcyBFY2tlcnQNCj4gPiA+ID4gPiA+ICAgICAg ID4gPiA+ID4gPj4gPiBTZW50OiBtYXJkaSA0IGp1aW4gMjAxOSAwMjowMw0KPiA+ID4gPiA+ID4g ICAgICAgPiA+ID4gPiA+PiA+IFRvOiBHcmVnIFNoZXBoZXJkDQo+ID4gPiA+ID4gPiAgICAgICA+ ID4gPiA+ID4+ID4gPGdqc2hlcEBnbWFpbC5jb20NCj4gPiA+ID4gPiA+ICAgICAgIDxtYWlsdG86 Z2pzaGVwQGdtYWlsLmNvbT48bWFpbHRvOmdqc2hlcEBnbWFpbC5jb20NCj4gPiA+ID4gPiA+ICAg ICAgIDxtYWlsdG86Z2pzaGVwQGdtYWlsLmNvbT4+Pg0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4g PiA+PiA+IENjOiBCSUVSIFdHIDxiaWVyQGlldGYub3JnDQo+ID4gPiA+ID4gPiAgICAgICA8bWFp bHRvOmJpZXJAaWV0Zi5vcmc+PG1haWx0bzpiaWVyQGlldGYub3JnIDxtYWlsdG86YmllckBpZXRm Lm9yZz4+Pg0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gPiA+PiA+IFN1YmplY3Q6IFJlOiBbQmll cl0gV0dMQyAtIGRyYWZ0LWlldGYtYmllci10ZS1hcmNoDQo+ID4gPiA+ID4gPiAgICAgICA+ID4g PiA+ID4+ID4NCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+ID4gPj4gPiArMQ0KPiA+ID4gPiA+ID4g ICAgICAgPiA+ID4gPiA+PiA+IE9idmlvdXNseSBzdXBwb3J0IGFzIGNvLWF1dGhvci4NCj4gPiA+ ID4gPiA+ICAgICAgID4gPiA+ID4gPj4gPg0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gPiA+PiA+ IE9uIFdlZCwgTWF5IDI5LCAyMDE5IGF0IDEyOjQxOjI2UE0gLTA3MDAsIEdyZWcNCj4gPiA+ID4g PiA+ICAgICAgIFNoZXBoZXJkIHdyb3RlOg0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gPiA+PiA+ ID4gUGxlYXNlIHJlYWQgYW5kIHJlc3BvbmQgdG8gdGhpcyB0aHJlYWQgdy8gb3Igdy9vDQo+ID4g PiA+ID4gPiAgICAgICBzdXBwb3J0Lg0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gPiA+PiA+ID4N Cj4gPiA+ID4gPiA+ICAgICAgID4gPiA+ID4gPj4gPiA+DQo+ID4gPiA+ID4gPiAgICAgICBodHRw czovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly9kYXRhdHJhY2tlci4uaWV0Zi5vcmcNCj4g PiA+ID4gPiA+ICAgICAgID4gPiA+ID4gPj4gPiA+IC9kb2MNCj4gPiA+ID4gPiA+ICAgICAgID4g PiA+ID4gPj4gPiA+DQo+ID4gPiA+ID4gPiAgICAgICAvZHJhZnQtaWV0Zi1iaWVyLXRlLWFyY2gv X187IThXb0E2UmpDODFjIVh2SDRBQXhmckRqRm9LX3MNCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+ ID4gPj4gPiA+IGVyY3cgWk1zYzBPNU40MmVFTk9zNGxfcWRzWEYwS3daRDgyY0pMREZGTlY5ZUNs QmokDQo+ID4gPiA+ID4gPiAgICAgICA+ID4gPiA+ID4+ID4gPg0KPiA+ID4gPiA+ID4gICAgICAg PGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovZGF0YXRyYWNrZXIuaWV0Zi5vcmcv DQo+ID4gPiA+ID4gPiAgICAgICA+ID4gPiA+ID4+ID4gPiBkb2MvDQo+ID4gPiA+ID4gPiAgICAg ICA+ID4gPiA+ID4+ID4gPg0KPiA+ID4gPiA+ID4gICAgICAgZHJhZnQtaWV0Zi1iaWVyLXRlLWFy Y2gvX187IThXb0E2UmpDODFjIVVCVEd2V1dwTUh5ZWlTYW54DQo+ID4gPiA+ID4gPiAgICAgICA+ ID4gPiA+ID4+ID4gPiBzNnZJIGJfRW5CVmd5ZzZib0FBVzRucnFqdThVQ0xPZ2l1WGM4WV82c0Q0 MGttdEgkPg0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gPiA+PiA+ID4NCj4gPiA+ID4gPiA+ICAg ICAgID4gPiA+ID4gPj4gPiA+IFZvdGUgZW5kcyA1IEp1bmUgMjAxOS4NCj4gPiA+ID4gPiA+ICAg ICAgID4gPiA+ID4gPj4gPiA+DQo+ID4gPiA+ID4gPiAgICAgICA+ID4gPiA+ID4+ID4gPiBUaGFu a3MsDQo+ID4gPiA+ID4gPiAgICAgICA+ID4gPiA+ID4+ID4gPiBTaGVwDQo+ID4gPiA+ID4gPiAg ICAgICA+ID4gPiA+ID4+ID4gPiAoY2hhaXJzKQ0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gPiA+ PiA+DQo+ID4gPiA+ID4gPiAgICAgICA+ID4gPiA+ID4+ID4gPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gPiA+ PiA+ID4gQklFUiBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+ID4gPj4gPiA+ IEJJRVJAaWV0Zi5vcmcNCj4gPiA+ID4gPiA+ICAgICAgIDxtYWlsdG86QklFUkBpZXRmLm9yZz48 bWFpbHRvOkJJRVJAaWV0Zi5vcmcgPG1haWx0bzpCSUVSQGlldGYub3JnPj4NCj4gPiA+ID4gPiA+ ICAgICAgID4gPiA+ID4gPj4gPiA+DQo+ID4gPiA+ID4gPiAgICAgICBodHRwczovL3VybGRlZmVu c2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi8NCj4gPiA+ID4gPiA+ICAg ICAgID4gPiA+ID4gPj4gPiA+IGxpc3QNCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+ID4gPj4gPiA+ DQo+ID4gPiA+ID4gPiAgICAgICBpbmZvL2JpZXJfXzshOFdvQTZSakM4MWMhWHZINEFBeGZyRGpG b0tfc2VyY3daTXNjME81TjQyZUUNCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+ID4gPj4gPiA+IE5P czQgbF9xZHNYRjBLd1pEODJjSkxERkZOVDJXVlhXWCQNCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+ ID4gPj4gPiA+DQo+ID4gPiA+ID4gPiAgICAgICA8aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9f X2h0dHBzOi93d3cuaWV0Zi5vcmcvbWFpbG1hbi8NCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+ID4g Pj4gPiA+IGxpc3QNCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+ID4gPj4gPiA+DQo+ID4gPiA+ID4g PiAgICAgICBpbmZvL2JpZXJfXzshOFdvQTZSakM4MWMhVUJUR3ZXV3BNSHllaVNhbnhzNnZJYl9F bkJWZ3lnNmINCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+ID4gPj4gPiA+IG9BQVcgNG5ycWp1OFVD TE9naXVYYzhZXzZzS24yS29BVCQ+DQo+ID4gPiA+ID4gPiAgICAgICA+ID4gPiA+ID4+ID4NCj4g PiA+ID4gPiA+ICAgICAgID4gPiA+ID4gPj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gPiA+PiA+IEJJRVIg bWFpbGluZyBsaXN0DQo+ID4gPiA+ID4gPiAgICAgICA+ID4gPiA+ID4+ID4gQklFUkBpZXRmLm9y Zw0KPiA+ID4gPiA+ID4gICAgICAgPG1haWx0bzpCSUVSQGlldGYub3JnPjxtYWlsdG86QklFUkBp ZXRmLm9yZyA8bWFpbHRvOkJJRVJAaWV0Zi5vcmc+Pg0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4g PiA+PiA+DQo+ID4gPiA+ID4gPiAgICAgICBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saQ0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gPiA+ PiA+IHN0aW4NCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+ID4gPj4gPg0KPiA+ID4gPiA+ID4gICAg ICAgZm8vYmllcl9fOyE4V29BNlJqQzgxYyFYdkg0QUF4ZnJEakZvS19zZXJjd1pNc2MwTzVONDJl RU5PczQNCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+ID4gPj4gPiBsX3FkDQo+ID4gPiA+ID4gPiAg ICAgICA+ID4gPiA+ID4+ID4gc1hGMEt3WkQ4MmNKTERGRk5UMldWWFdYJA0KPiA+ID4gPiA+ID4g ICAgICAgPiA+ID4gPiA+PiA+DQo+ID4gPiA+ID4gPiAgICAgICA8aHR0cHM6Ly91cmxkZWZlbnNl LmNvbS92My9fX2h0dHBzOi93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saQ0KPiA+ID4gPiA+ID4gICAg ICAgPiA+ID4gPiA+PiA+IHN0aW4NCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+ID4gPj4gPg0KPiA+ ID4gPiA+ID4gICAgICAgZm8vYmllcl9fOyE4V29BNlJqQzgxYyFVQlRHdldXcE1IeWVpU2FueHM2 dkliX0VuQlZneWc2Ym9BQVcNCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+ID4gPj4gPiA0bnJxDQo+ ID4gPiA+ID4gPiAgICAgICA+ID4gPiA+ID4+ID4ganU4VUNMT2dpdVhjOFlfNnNLbjJLb0FUJD4N Cj4gPiA+ID4gPiA+ICAgICAgID4gPiA+ID4gPg0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gPiA+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gPiA+ ID4gPiAgICAgICA+ID4gPiA+ID4gQklFUiBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPiA+ICAgICAg ID4gPiA+ID4gPiBCSUVSQGlldGYub3JnDQo+ID4gPiA+ID4gPiAgICAgICA8bWFpbHRvOkJJRVJA aWV0Zi5vcmc+PG1haWx0bzpCSUVSQGlldGYub3JnIDxtYWlsdG86QklFUkBpZXRmLm9yZz4+DQo+ ID4gPiA+ID4gPiAgICAgICA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ICAgICAgIGh0dHBzOi8vdXJs ZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpDQo+ID4g PiA+ID4gPiAgICAgICA+ID4gPiA+ID4gbmZvLw0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gPiA+ DQo+ID4gPiA+ID4gPiAgICAgICBiaWVyX187IThXb0E2UmpDODFjIVh2SDRBQXhmckRqRm9LX3Nl cmN3Wk1zYzBPNU40MmVFTk9zNGxfcWRzWA0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gPiA+IEYw S3cNCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+ID4gPiBaRDgyY0pMREZGTlQyV1ZYV1gkDQo+ID4g PiA+ID4gPiAgICAgICA+ID4gPiA+ID4NCj4gPiA+ID4gPiA+ICAgICAgIDxodHRwczovL3VybGRl ZmVuc2UuY29tL3YzL19faHR0cHM6L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpDQo+ID4gPiA+ ID4gPiAgICAgICA+ID4gPiA+ID4gbmZvLw0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gPiA+DQo+ ID4gPiA+ID4gPiAgICAgICBiaWVyX187IThXb0E2UmpDODFjIVVCVEd2V1dwTUh5ZWlTYW54czZ2 SWJfRW5CVmd5ZzZib0FBVzRucnFqdQ0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gPiA+IDhVQ0wN Cj4gPiA+ID4gPiA+ICAgICAgID4gPiA+ID4gPiBPZ2l1WGM4WV82c0tuMktvQVQkPg0KPiA+ID4g PiA+ID4gICAgICAgPiA+ID4NCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+IC0tDQo+ID4gPiA+ID4g PiAgICAgICA+ID4gPiAtLS0NCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+IHR0ZUBjcy5mYXUuZGUg PG1haWx0bzp0dGVAY3MuZmF1LmRlPjxtYWlsdG86dHRlQGNzLmZhdS5kZQ0KPiA+ID4gPiA+ID4g ICAgICAgPG1haWx0bzp0dGVAY3MuZmF1LmRlPj4NCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+DQo+ ID4gPiA+ID4gPiAgICAgICA+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+ID4gPiA+ID4gICAgICAgPiA+ID4gQklFUiBtYWlsaW5nIGxpc3QN Cj4gPiA+ID4gPiA+ICAgICAgID4gPiA+IEJJRVJAaWV0Zi5vcmcgPG1haWx0bzpCSUVSQGlldGYu b3JnPjxtYWlsdG86QklFUkBpZXRmLm9yZw0KPiA+ID4gPiA+ID4gICAgICAgPG1haWx0bzpCSUVS QGlldGYub3JnPj4NCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+DQo+ID4gPiA+ID4gPiAgICAgICBo dHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby8NCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+IGJpZXINCj4gPiA+ID4gPiA+ICAgICAg ID4gPiA+DQo+ID4gPiA+ID4gPiAgICAgICBfXzshOFdvQTZSakM4MWMhWHZINEFBeGZyRGpGb0tf c2VyY3daTXNjME81TjQyZUVOT3M0bF9xZHNYRjBLd1pEODINCj4gPiA+ID4gPiA+ICAgICAgID4g PiA+IGNKTEQNCj4gPiA+ID4gPiA+ICAgICAgID4gPiA+IEZGTlQyV1ZYV1gkDQo+ID4gPiA+ID4g PiAgICAgICA+ID4gPg0KPiA+ID4gPiA+ID4gICAgICAgPGh0dHBzOi8vdXJsZGVmZW5zZS5jb20v djMvX19odHRwczovd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vDQo+ID4gPiA+ID4gPiAg ICAgICA+ID4gPiBiaWVyDQo+ID4gPiA+ID4gPiAgICAgICA+ID4gPg0KPiA+ID4gPiA+ID4gICAg ICAgX187IThXb0E2UmpDODFjIVVCVEd2V1dwTUh5ZWlTYW54czZ2SWJfRW5CVmd5ZzZib0FBVzRu cnFqdThVQ0xPZ2l1DQo+ID4gPiA+ID4gPiAgICAgICA+ID4gPiBYYzhZDQo+ID4gPiA+ID4gPiAg ICAgICA+ID4gPiBfNnNLbjJLb0FUJD4NCj4gPiA+ID4gPiA+ICAgICAgID4gPg0KPiA+ID4gPiA+ ID4gICAgICAgPiA+IC0tDQo+ID4gPiA+ID4gPiAgICAgICA+ID4gLS0tDQo+ID4gPiA+ID4gPiAg ICAgICA+ID4gdHRlQGNzLmZhdS5kZSA8bWFpbHRvOnR0ZUBjcy5mYXUuZGU+DQo+ID4gPiA+ID4g PiAgICAgICA+DQo+ID4gPiA+ID4gPiAgICAgICA+IC0tDQo+ID4gPiA+ID4gPiAgICAgICA+IC0t LQ0KPiA+ID4gPiA+ID4gICAgICAgPiB0dGVAY3MuZmF1LmRlIDxtYWlsdG86dHRlQGNzLmZhdS5k ZT4NCj4gPiA+ID4gPiA+ICAgICAgID4NCj4gPiA+ID4gPiA+ICAgICAgID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ID4gPiA+ICAgICAgID4g QklFUiBtYWlsaW5nIGxpc3QNCj4gPiA+ID4gPiA+ICAgICAgID4gQklFUkBpZXRmLm9yZyA8bWFp bHRvOkJJRVJAaWV0Zi5vcmc+DQo+ID4gPiA+ID4gPiAgICAgICA+DQo+ID4gPiA+ID4gPiAgICAg ICBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9iaWVyDQo+ID4gPiA+ID4gPiAgICAgICA+DQo+ID4gPiA+ID4gPiAgICAgICBf XzshIU5FdDZ5TWFPLWdrIVZ1UUNWSG5xSnlfYVlJLUZOdDlBMWE1RXpIT0NyMGZaa0xQYmdnM0NQ TnUwUHlyV3NyRng0DQo+ID4gPiA+ID4gPiAgICAgICA+IDFfaldWM1lVQTZEJA0KPiA+ID4gPiA+ ID4gDQo+ID4gPiA+ID4gPiAgICAgICAtLQ0KPiA+ID4gPiA+ID4gICAgICAgLS0tDQo+ID4gPiA+ ID4gPiAgICAgICB0dGVAY3MuZmF1LmRlIDxtYWlsdG86dHRlQGNzLmZhdS5kZT4NCj4gPiA+ID4g PiA+IA0KPiA+ID4gPiA+ID4gICAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiA+ID4gPiA+ICAgICAgIEJJRVIgbWFpbGluZyBsaXN0DQo+ID4g PiA+ID4gPiAgICAgICBCSUVSQGlldGYub3JnIDxtYWlsdG86QklFUkBpZXRmLm9yZz4NCj4gPiA+ ID4gPiA+ICAgICAgIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fYmllciZkPUR3SUZBdyZjPUxG WVotbzlfSFVNZU1UU1FpY3ZqSWcmcj02VWhHcFc5bHdpOWRNN2pZbHhYRDh3Jm09TVczUzBtdmhO Tjl1cTVWbWpYZE5YR3dzaXNWUDV3enpPOHIwNGg0YVAwbyZzPURyTG9kRDBhMk1GZTYwYTJfREVD RGVMSldMZ3hncWQ2NXJBZ25wazR1OE0mZT0gDQo+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gPiA+IEJJ RVIgbWFpbGluZyBsaXN0DQo+ID4gPiA+ID4gQklFUkBpZXRmLm9yZw0KPiA+ID4gPiA+IGh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu b3JnX21haWxtYW5fbGlzdGluZm9fYmllciZkPUR3SUZBdyZjPUxGWVotbzlfSFVNZU1UU1FpY3Zq SWcmcj02VWhHcFc5bHdpOWRNN2pZbHhYRDh3Jm09TVczUzBtdmhOTjl1cTVWbWpYZE5YR3dzaXNW UDV3enpPOHIwNGg0YVAwbyZzPURyTG9kRDBhMk1GZTYwYTJfREVDRGVMSldMZ3hncWQ2NXJBZ25w azR1OE0mZT0gDQo+ID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+ID4gQklFUiBtYWlsaW5nIGxpc3QNCj4gPiA+IEJJRVJAaWV0Zi5vcmcNCj4g PiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f d3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fYmllciZkPUR3SUZBdyZjPUxGWVotbzlfSFVN ZU1UU1FpY3ZqSWcmcj02VWhHcFc5bHdpOWRNN2pZbHhYRDh3Jm09TVczUzBtdmhOTjl1cTVWbWpY ZE5YR3dzaXNWUDV3enpPOHIwNGg0YVAwbyZzPURyTG9kRDBhMk1GZTYwYTJfREVDRGVMSldMZ3hn cWQ2NXJBZ25wazR1OE0mZT0gDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gPiBCSUVSIG1haWxpbmcgbGlzdA0KPiA+IEJJRVJAaWV0Zi5vcmcN Cj4gPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff X3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2JpZXImZD1Ed0lGQXcmYz1MRllaLW85X0hV TWVNVFNRaWN2aklnJnI9NlVoR3BXOWx3aTlkTTdqWWx4WEQ4dyZtPU1XM1MwbXZoTk45dXE1Vm1q WGROWEd3c2lzVlA1d3p6TzhyMDRoNGFQMG8mcz1EckxvZEQwYTJNRmU2MGEyX0RFQ0RlTEpXTGd4 Z3FkNjVyQWducGs0dThNJmU9IA0KPiA+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gQklFUiBtYWlsaW5nIGxpc3QNCj4gQklFUkBpZXRm Lm9yZw0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX2JpZXImZD1Ed0lGQXcmYz1MRllaLW85 X0hVTWVNVFNRaWN2aklnJnI9NlVoR3BXOWx3aTlkTTdqWWx4WEQ4dyZtPU1XM1MwbXZoTk45dXE1 Vm1qWGROWEd3c2lzVlA1d3p6TzhyMDRoNGFQMG8mcz1EckxvZEQwYTJNRmU2MGEyX0RFQ0RlTEpX TGd4Z3FkNjVyQWducGs0dThNJmU9IA0KDQotLSANCi0tLQ0KdHRlQGNzLmZhdS5kZQ0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KQklFUiBtYWlsaW5n IGxpc3QNCkJJRVJAaWV0Zi5vcmcNCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fYmllciZkPUR3 SUZBdyZjPUxGWVotbzlfSFVNZU1UU1FpY3ZqSWcmcj02VWhHcFc5bHdpOWRNN2pZbHhYRDh3Jm09 TVczUzBtdmhOTjl1cTVWbWpYZE5YR3dzaXNWUDV3enpPOHIwNGg0YVAwbyZzPURyTG9kRDBhMk1G ZTYwYTJfREVDRGVMSldMZ3hncWQ2NXJBZ25wazR1OE0mZT0gDQo= From nobody Wed Feb 26 17:20:29 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F613A0D89 for ; Wed, 26 Feb 2020 17:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, 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 5mFdoTu7GDOC for ; Wed, 26 Feb 2020 17:20:17 -0800 (PST) Received: from mx03.uni-tuebingen.de (mx03.uni-tuebingen.de [134.2.5.213]) (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 F37B63A0D7F for ; Wed, 26 Feb 2020 17:20:15 -0800 (PST) Received: from [10.96.1.23] (wzr-eduroam-nat1.rz.uni-ulm.de [134.60.112.72]) by mx03.uni-tuebingen.de (Postfix) with ESMTPSA id 112938ECD0; Thu, 27 Feb 2020 02:20:11 +0100 (CET) To: Toerless Eckert Cc: "gjshep@gmail.com" , "bier@ietf.org" , "Jeffrey (Zhaohui) Zhang" References: <11ab30da-8701-b491-6162-5a69aa9d6965@labn.net> <20200220035620.GA42520@faui48f.informatik.uni-erlangen.de> <20200225015718.GC20521@faui48f.informatik.uni-erlangen.de> <20200226000206.GA31874@faui48f.informatik.uni-erlangen.de> From: Michael Menth Autocrypt: addr=menth@uni-tuebingen.de; prefer-encrypt=mutual; keydata= mQENBFEwuvUBCAC0e0350KZ4gcyRT7ia8iJ/yaSopkvA14XFLnu9ooRFsw7FvYThSQa6mJ0a fZuAqxs4/ymD6pbLEjQWhuHcZyVOWHsuIYtHBGLOmmSCvoYURgJ1w1wJCwH2uA2I8xT/cV3e fwJym09f/Tl71gLopIIzaSZo6T9NG3jGF2D9cfzapp8IOq1iSiBq5Ry+Sq3IPHkUkpcg3Zk6 td6MtlvRQUnK9nIffxG0RKMF28PCAYFwzx4Nj7zsjfYgcTAIt/ld7Ptk1olb9B9l8xVTuojK /s8sk6yZn0LgE0wjABxUCVSB9wMSyZac4f3QHSl5//ZnstjaqDCM0lijrHHnBI8pmVyHABEB AAG0Jk1pY2hhZWwgTWVudGggPG1lbnRoQHVuaS10dWViaW5nZW4uZGU+iQE+BBMBAgAoBQJR MLr1AhsjBQkJZgGABgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRDxmVdyt1FYm9hyCACz D7Q8imyW9G++j2N97jF9ybcQJ8eCUeiJ20DFy3gAGR/Ic/RB+Y1fsD/1DY2Ahe82iKphp1Fp UK8qhfz+zDVJgz0CyzESyIztOkc1RyhO5295iRG30ClGYaxHHw7/1EbQ8CKEKIAD2WEHIk6I pZkYlBey1uMQLT4LE+nWwrMdo7BDt74rmUpRyWqDHI4J96i/VWKJGbpky5laRwd5hZeVEWGA Blz3/CL7vZzOHLwZduVTs4upZyc2zJHEqQKuHb0+ixs4xaP5yWpQPvacq5+G6IOSawHyDI5T hkRp48yJV519jOWYc/daT0MLHCHK6bt3AK+CfvmBf/ACSS84ravp Message-ID: <38c8f739-5eb1-2c43-f6d6-055ceb055f81@uni-tuebingen.de> Date: Thu, 27 Feb 2020 02:28:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 01:20:27 -0000 Hallo Toerless, würde BIER-SR passen? Wir haben ja intern schon öfter argumentiert, dass BIER-TE so ähnlich wie SR ist. VG, Michael Am 26.02.2020 um 22:33 schrieb BRUNGARD, DEBORAH A: > Hi Toerless, > > Your comment: >>> I would appreciate if you could try to partition your opinions into >>> things you think MUST be solved before passing the document to IESG (for >>> IETF/IESG review) and those issues that could then be solved when it is >>> in IETF/IESG review. For example, i think a final choice of name could >>> be something that shouldn't block the document to take this step. >>> > > Waiting for the IESG to "name" your technology will definitely result in a much longer delay than sorting out in WG Last Call. You noted, you had presented an earlier version of this document in TEAS, but it is at the time of WG Last Call (per the charter), the TEAS/MPLS/and probably PCE, should have been notified (I included MPLS as you have multiple proposals on use of MPLS labels). I've contacted your BIER Chairs/AD to extend at least a week the Last Call. > > On naming, as Lou noted, preference is to align terminology used in other working groups - especially within the routing area. The RFC-editor also recommends careful use of abbreviations - it is expected new abbreviations are added to a list: > https://www.rfc-editor.org/materials/abbrev.expansion.txt > > As you can see, PE is already used. And in the Routing Area, for our PE abbreviation, we could say it should have an asterisk😊 Your justification is that "PE" is short similar to "TE", but for the Routing Area, it needs to be either different or maybe add a letter (three letters). If you look thru the list, that's what others have done e.g. in SPRING, they have a new document also using "PE" differently but it's abbreviated "EPE". > > As we all enjoy trying to name "something", I checked PCE documents (as you noted in the document, BIER-PE requires SDN/PCE controller). As Lou says - there is no mention of "path engineering" either in PCE documents or any IETF documents. So maybe "PE" in the string is not the best. My 2-cents, how about "SREP-BIER" (Source Routed Engineered Path)? Have fun naming - but please stabilize on a name before hand-off to the IESG - otherwise the IESG will have all the fun. > > As BIER-PE requires use of an SDN/PCE controller - here's my early AD comments - please mention this earlier in the document - abstract, intro. e.g. the SPRING document has as the title "centralized" EPE. The centralized controller is the key differentiator for BIER-PE. Also, in section 8, there is no need to be critical of RSVP-TE, we are not trying to market one vs. the other: > "SR aims to enable lightweight path steering via loose source routing. Compared to its more heavy-weight predecessor RSVP-TE, SR does for example not require per-path signaling to each of these hops." > > RSVP-TE provides very different capabilities than SR and BIER. With RSVP-TE glasses on, one could say SR and BIER provide very limited capabilities. And both SR and BIER require very heavy-weight SDN controllers. So it just depends where the operator/vendor wants to put their "weight". But it's not for IETF to do the judgement. Same for some of your pro BIER-PE comments vs. SR. SR has it's advantages over BIER too. An RFC is not for marketing one technology vs. another. > > Hopefully my working groups (TEAS, MPLS, PCE) are given the "heads-up" soon - I'd prefer discussion during working group last call vs. IETF Last Call or my needing to enter a "Discuss" waiting for their review. > > Thanks! > Deborah > (AD hat on) > > -----Original Message----- > From: BIER On Behalf Of Toerless Eckert > Sent: Tuesday, February 25, 2020 7:02 PM > To: Lou Berger > Cc: gjshep@gmail.com; bier@ietf.org; Jeffrey (Zhaohui) Zhang > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK > > Lou, *: > > Here is the next and hopefully final github version for your review. > If you can give a thumbsup i will upload to datatracker, > and the WG chairs would also be able to finalize WG last-call. > > https://urldefense.proofpoint.com/v2/url?u=https-3A__raw.githubusercontent.com_toerless_bier-2Dte-2Darch_7e996deb1dcd18596d4864c750f6e7541d737e6f_draft-2Dietf-2Dbier-2Dte-2Darch.txt&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=hbVUmt6ob-Ilgt00kiOlwAOcA68kldlxvO0Lqq-gKxo&e= > > And here the diff to -05, last version before taking input from your review into account. > Given how 1.1 was removed, this seems like the most logical comparison point. > > https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org_tools_rfcdiff_rfcdiff.pyht-3Furl1-3Dhttps-3A__tools.ietf.org_id_draft-2Dietf-2Dbier-2Dte-2Darch-2D05.txt-26url2-3Dhttps-3A__raw.githubusercontent.com_toerless_bier-2Dte-2Darch_7e996deb1dcd18596d4864c750f6e7541d737e6f_draft-2Dietf-2Dbier-2Dte-2Darch.txt&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=jTvrGagqHgPKneTUpOvNkeYcl7cxDSV32gLk--vyzdQ&e= > > Changes to -05 are now easily seen as limited textual: > - Name change BIER-TE to BIER-PE > - Explanations using steering/policy > - [RFC-editor remove note] about name change. > - BIER-TE controller host -> BIER-TE Controller (unrelated to Lou) > > Detailled answers, explanations below. > > Cheers > Toerless > > On Tue, Feb 25, 2020 at 01:19:26PM -0500, Lou Berger wrote: >> Hi Toerless, >> >>     This revision will mostly remove my objection related to the use of TE >> by the document.  I suspect in section 7.2 you have two instances where >> "traffic" needs to be replaced with "path". > > Fixed > >>  More substantively, I think you >> should delete section 1.1 and leave its subject  matter  to >> eckert-teas-bier-te-framework to be covered/worked out.  If you want to keep >> it, I think there's a longer discussion need on its contents. > > Removed section 1.1 from the text. > > I have added to the beginning of 1. an [RFC-editor: pls. remove ] section > explaining the naming change so late in the process to further IETF/IESG > reviewers (if i had just put it into the changelog i fear it will > be overlooked by reviewers). > > For what is worth, i did like the idea of having explanations > about relationship of BIER-PE to BIER-TE, especially because the > framework is IMHO not yet in a state to serve as a good even draft > reference (it was only pointed to in section 1.1, so also removed > as reference). > > How about this: If IESG review wants to have that type of explanation back, > i'll knock on your door to revive and help me fix up that text. > >> FWIW I still think the introduction of the a new term "Path Engineering", >> rather than reusing one of the existing IETF terms for the same capability >> ("routing policy", "policy based routing", "path steering") seems  likely to >> lead to more confusion then if you stuck with an established term.  I'll >> leave this to others to argue. > > Ok, second time around you're suggesting this, i now owe you an explanation > why i think these terms are technically misleading: > (its a bit long, that why i avoided the explanation in before). > > All the established terms you propose come from unicast and > never had a re-definition/re-interpretation for IP multicast. > > Using any of these terms in the name would easily lead to > people (especially when not reading the doc) think the > BIER solution here works like in both IP multicast and > BIER in before BIER-PE: By impacting the underlying unicast > (forward) routing (BIER) or RPF (reverse path) routing (IP Multicast). > > Examples: You can use static muRIB routes to steer traffic for > IP Multicast or BIER. You can also use separate IGP (Flex-)topologies > to do the same dynamically. Thats all great stuff to describe in a > BIER-TE framework document (in conjunction with BIER), but that > is also the stuff i do not want BIER-PE to be confused with > because there are technical limitations to those unicast routing policy/ > steering approaches when its applied to trees: > > Try to use any of the pre-existing mechanisms for unicast routing policy > or path steering with BIER or IP multicast to build steiner trees. > Not generally possible. With BIER-PE, no problem. Same thing with > disjoint trees (even MRT flex-algo's wouldn't achieve the same). > > IMHO, the term "Path Engineering" is free of this mis-name-recognition > because it is a new. The name also hints at the fact that this could be > in support of, or a component of traffic engineering. > And wrt to minimizing the change to the long held name, > the hamming distance is just one character/word. So it's the > 'safest/most-conservative/logical' name change this late in the > process. > > As i said, i would be happier with a more unique new descriptive > name like "Tree Steering Bitstrings" (BIER-TSB), but i do not feel > like making such a big naming change without more explicit support > by more members of the WG this late in the process. > >> I think this covers all the detailed discussion points below. If not, can >> you extract the ones you'd like to keep discussing? > > Still sad about the missed opportunity of fixing this naming > problem earlier wrt. to the mail you sopposedly sent, and > happy to beat myself up if that ended up being my fault, but > i guess i shouldn't continue to dig into that issue if it would > turn out to be someone else's fault. > > Otherwise i am fine. > > If you want to give the doc now a thumbs up in response to the last > call, that would be great ;-) > > EOF > >> Thanks again for the responsiveness to my comments! >> >> Lou >> >> On 2/24/2020 8:57 PM, Toerless Eckert wrote: >>> Hi Lou, round 2. >>> >>> Here is the github pre-version of -07 of the draft: >>> >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__raw.githubusercontent.com_toerless_bier-2Dte-2Darch_62378f618299307349a934fc6ad78e1af9e16771_draft-2Dietf-2Dbier-2Dte-2Darch.txt&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=ijbHbeNowm8uYigeF3tPQBOSrFL5chyoxfjBXyDOxPg&e= >>> >>> Diff: >>> >>> https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org_tools_rfcdiff_rfcdiff.pyht-3Furl1-3Dhttps-3A__tools.ietf.org_id_draft-2Dietf-2Dbier-2Dte-2Darch-2D06.txt-26url2-3Dhttps-3A__raw.githubusercontent.com_toerless_bier-2Dte-2Darch_62378f618299307349a934fc6ad78e1af9e16771_draft-2Dietf-2Dbier-2Dte-2Darch.txt&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=VMWxCE2IzT007rczFZWwh1CEB3xG48xOj5RifpjIt5s&e= >>> >>> I would appreciate if you could try to partition your opinions into >>> things you think MUST be solved before passing the document to IESG (for >>> IETF/IESG review) and those issues that could then be solved when it is >>> in IETF/IESG review. For example, i think a final choice of name could >>> be something that shouldn't block the document to take this step. >>> >>> If this goes along into IETF107, it would be great if you could find the >>> time to be at the BIER-WG meeting. >>> >>> Summary of changes: >>> >>> 1. Changed abbreviation BIER-TE to BIER-PE, otherwise we can not unconfuse >>> readers of the difference between BIER-PE and BIER-TE. >>> >>> Relationship: BIER-TE = (BIER with steering: BIER-PE or othre) plus resource >>> allocation mechanisms, and this document only describes BIER-PE. >>> >>> 2. Removed all use of the term "path engineering" from the (explanatory) text, >>> replaced with path / tree steering or policy in the text (like RFC8402). >>> >>> 3. In result, "Path Engineering" is now solely a name for the mechanism. >>> In the same way as SR introduced "Segment Routing" as a name, but explains >>> what it does with the terms "steering" and "policy". >>> >>> 4. I think a unique new term not already used in before is helpful because >>> what BIER-PE does is quite unique and new. And reusing an existing term >>> always brings out more people wanting to argue about the accuracy of how >>> their pre-existing term is applied. >>> >>> I hope we can have a deterministic, short latency decision mechanism for >>> the term. After we've decided on the term, its easy to update the doc >>> again with that new term (%s/PE/XXX/g). >>> >>> I'll throw "Tree Steering Bitstrings" (BIER-TSB) into the ring. >>> >>> [The main issue with name change now is that we've gotten some followup >>> work such as YANG model that also refers to BIER-TE meaning BIER-PE, so >>> that would also need to change name. See below for my reply to that naming >>> change you said you suggested .] >>> >>> 5. I also refined the section 1.1 that was introduced in -06 to mention >>> e.g.: PCE. >>> >>> Specific answers to the mail thread below. >>> >>> Cheers >>> Toerless >>> >>> On Fri, Feb 21, 2020 at 03:01:51PM -0500, Lou Berger wrote: >>>>> [ Would have been nice if you could have commented a bit earlier. >>>>> But i can understand how a few years is not enough time ;-P >>>>> (actually no kidding, i really can.) ] >>>> I raised this as an issue last march - at both the Chair and AD level..  I >>>> thought I made the same point to you privately after one the presentations >>>> at IETF101, but if you don't remember it, I accept that I didn't. >>> Did you include the authors ? I could not find any email about this. >>> Also no forwarded emails from AD/chairs i could find. If you still have >>> a copy, pls. PM. This is annoying... >>> >>> I do not remember naming issue discussed after IETF101, but i am >>> sure i was preoccupied with technical issues and might not have >>> given it too much thought back then. Of course there was a lot of >>> time since IETF101 to bring up the naming point again... >>> >>>> Well that document seems like a fine place to describe how BIER-RP (routing >>>> policy) can be used to deliver BIER-TE. >>>> >>> [...] >>>> Do we really need a new term to describe here?  I find zero (0) instances of >>>> Path Engineering in any RFC.  Routing policy (and policy-based routing) on >>>> the other hand are fairly well established terms in the industry.  I think >>>> this just sows seeds for future confusion on this topic. >>>> >>>> Why is "routing policy" not good enough for what is being defining here?  I >>>> again point out, this is the term being used in SPRING for basically the >>>> equivalent function/purpose. (Yes the forwarding mechanism is different, but >>>> the objective is not.) >>> SPRING did establish new unique name/terminologies, like "Segment". >>> As said above, i think its best we do the samegiven how unique this is. >>> >>> Looking at rfc8402, "steering" and "policy" are used in verbal >>> explanations, without providing specific terminology for them, >>> so i did follow that example too. >>> >>>>> but kept name BIER-TE (see below). >>>>> >>>>> - Added section 1.1 explaining how BIER-TE relates to traffic >>>>> engineering, naming use-cases where its for example beneficial standalone and >>>>> and what it could be combined with for more comprehensive TE solutions, >>>>> but also stating that those integrations are outside the scope of this >>>>> document. >>>> So this section seems to miss what has been going on in traffic engineering >>>> / TEAS for the last 5+ years (i.e., controller-based TE approaches) >>> I don't think that is a correct assessment. BIER-PE itself requires a >>> controller to calculate paths / trees. With or without other traffic >>> engineering components. That component is called the BIER-PE controller and >>> has been in the draft forever. >>> >>> The new section 1.1 added in response to your review relates that >>> BIER-TE controller to an overall TE controller, using the PCE example >>> and refrerence to it. >>> >>> There is really nothing more that a BIER-WG document could or should >>> do. What this document intended to support is whats necessary and >>> sufficient to get the forwarding plane implemented/standardized. >>> Everything else is for independent followup work in TEAS IMHO, >>> such as reviving the framwork draft. >>> >>>>   and then goes on describe path steering  in a very brief way.  I read this as >>>> saying that BIER *could* do TE in the future and *can* support routing >>>> policy and path steering today. >>> Even stronger: BIER-PE is always meant to ONLY do that (steering), >>> any additional TE functions wold come from independent other components. >>> And simple examples for that are given in section 1.1. >>> >>>>> - changed "traffic engineering" term in the whole doc to "path engineering", >>>>> where appropriate. >>>> While this is appreciated, I'm not sure it's helpful.  As stated above, I >>>> think the introduction of the new PE term is confusing as the continued use >>>> of BIER-TE. >>> See above. We can certainly not use "BIER-TE" to mean two different >>> things, so i hope that concern is resolved. >>> >>>>> The mayority of customers i talked to only used RSVP-TE for path >>>>> engineering, and not for anything more. Several didn't even know it >>>>> can do bandwidth reservation. Nobody knew it could do latency >>>>> guarantees, because nobody knows an implementation that supports that. >>>>> [All reasons btw. why replacing RSVP-TE with SR happened in the industry.] >>>> While I'm going to avoid getting into product differentiators and marketing, >>>> you're not mentioning that even those products and customers who didn't >>>> support/use per LSP queuing, did available resource bookkeeping and even >>>> admission control. >>> I think the point is mood now (given how we'll change the name BIER-TE >>> to a better term). But maybe to better explain: We started calling this >>> TE so customers would easier understand that this is intended to give >>> them what they actually use RSVP-TE for (Traffic Steering), and not >>> necessarily all that RSVP-TE could do beyond that. A central controller >>> is assumed to exist in BIER-PE too. >>> >>> Given how SR also shows how you can be successful in deployment >>> without betting on 'TE' name recognition, i have no quarrels in >>> changing the name. As said above, its motly a question of finding >>> the best term and changing the followup works names too. >>> >>>>> In any case, the name BIER-TE was selected to reduce confusion >>>>> with customers, not to maximize naming correctness in IETF. >>>> umm, the IETF is a standards body not an industry marketing forum, so I'm >>>> unclear how this point helps your argument. >>> It's not am argument or justification, just an explanation. Not only to you, >>> but also the WG. >>> >>>>  It seems that you're saying >>>> that if we call it BIER-TE we can market it in place of existing IETF TE >>>> solutions - even though it doesn't yet have the TE capability covered in >>>> draft-eckert-teas-bier-te-framework. >>> .... >>> >>>> Assuming I'm reading it right, this just confirms to me that the current >>>> work needs to be renamed and that draft-eckert-teas-bier-te-framework will >>>> define BIER-TE. >>> Yes. BIER-TE could btw. rely on BIER-PE or BIER + other path steering >>> (e.g.: flex-algos), so BIER-PE is only one option for the path-steering >>> options for BIER-TE. >>> >>>> My point wasn't that BIER=SR, but rather both deliver support for path >>>> steering and policy based routing. >>> Yepp, i hope we're in violent agreement. >>> >>> Cheers >>> Toerless >>> >>>> Thanks for being responsive! >>>> >>>> Lou >>>> >>>>> All the SR options do really require that you set up multicast trees with >>>>> e.g.: replication-SIDs that together form the equivalent of a >>>>> multicast tree, like you would have built with RSVP-TE. Except that >>>>> the signaling how to build the tree is left for someone else, like >>>>> PCECC. (AFAIK, i may not be on top of all details). In BIER-TE, >>>>> there is no such per-tree state on transit nodes. >>>>> >>>>> Instead of a 256 bit bitstring in BIER-TE think of a header with up to 256 SIDs >>>>> (e.g.: 128 bit per SID in SRv6). That would be the SR equivalent of BIER-TE. >>>>> Just a bit less ( ;-) ) less efficient on the wire than BIER-TE and extremely >>>>> harder to parse. >>>>> >>>>> Cheers >>>>> Toerless >>>>> >>>>> >>>>> On Wed, Feb 19, 2020 at 06:38:38PM -0500, Lou Berger wrote: >>>>>> Hi, >>>>>> >>>>>>     I have no issue or objection to the mechanisms being defined in this >>>>>> document as much as they go, but I was quite disappointed that despite the >>>>>> name of the document and use of 'bier-te'  to see that the document doesn't >>>>>> define any traffic engineering support, at least as far as the term has been >>>>>> used in IETF RFCs.  In particular it totally lacks any discussion of >>>>>> resources usage and/or allocation.  What it currently describes certainly >>>>>> provides good and useful path/traffic steering that can be used to support >>>>>> policy-based routing.  Basically it does the same as what is defined by >>>>>> draft-ietf-spring-segment-routing-policy. >>>>>> >>>>>> I personally (not speaking for the related WGs that I chair) would prefer to >>>>>> see this document be revised  to include resource allocation that would >>>>>> allow BIER-TE to support TE usage such as DetNet.  Barring such an addition, >>>>>> I'm against publication of this document as is and I think the document >>>>>> should be recast and renamed to be aligned with the SR example, i..e., BIER >>>>>> routing policy (or path steering). >>>>>> >>>>>> Lou >>>>>> >>>>>> On 2/18/20 3:45 PM, Greg Shepherd wrote: >>>>>>> Thanks Toerless and Jeffrey >>>>>>> >>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbier-2Dte-2Darch_&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=jH9x7gacv335Qdcq_btgUNtO3-TQxwLspmfVzbCC9Oo&e= >>>>>>> >>>>>>> One more week of WGLC. Please read the latest rev and respond to this >>>>>>> thread w/wo support. >>>>>>> >>>>>>> Chairs >>>>>>> (Shep) >>>>>>> >>>>>>> >>>>>>> On Tue, Feb 18, 2020 at 12:07 PM Jeffrey (Zhaohui) Zhang >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> Hi Toerless, >>>>>>> >>>>>>> Thanks! >>>>>>> I support moving this to the next stage. >>>>>>> >>>>>>> Jeffrey >>>>>>> >>>>>>> On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote: >>>>>>> > Thanks Jeff >>>>>>> > >>>>>>> > I have now pushed out -05 with the answers and hopefully >>>>>>> resolution to >>>>>>> > your points in email below.  Biggest addition was a section about >>>>>>> > reuse of BPs (without DNR) which came out of the confusion i >>>>>>> think the >>>>>>> > reuse in the ECMP example raised. I was afraid so far to explan >>>>>>> that >>>>>>> > as it may not be easy to absorb and ultimately is stuff only >>>>>>> > controller developers need to understand, but hopefully useful. >>>>>>> > And then of course the summary of BP optimizatins you asked for >>>>>>> > >>>>>>> > Diff from last version i sent you: >>>>>>> > >>>>>>> > >>>>>>> https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: >>>>>>> > **Araw.githubusercontent.com >>>>>>> *toerless*bier-te-arch*master*draft-ietf-b >>>>>>> > ier-te-arch-05.1.txt&url2=http:**Atools.ietf.org >>>>>>> *id*draft-ietf-bier-te >>>>>>> > >>>>>>> -arch-05.txt__;Ly8vLy8vLy8vLy8!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzH >>>>>>> > OCr0fZkLPbgg3CPNu0PyrWsrFx41_jWX2At8V-$ >>>>>>> > >>>>>>> > full -04 -> 05 diff: >>>>>>> > >>>>>>> > >>>>>>> https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=http:* >>>>>>> > *Atools.ietf.org >>>>>>> *id*draft-ietf-bier-te-arch-04.txt&url2=http:**Atools. >>>>>>> > ietf.org >>>>>>> *id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk >>>>>>> > !VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx41_jWancpziv$ >>>>>>> > >>>>>>> > Comments inline below. >>>>>>> > >>>>>>> > Cheers >>>>>>> >     toerless >>>>>>> > >>>>>>> > On Mon, Oct 28, 2019 at 07:52:59PM +0000, Jeffrey (Zhaohui) >>>>>>> Zhang wrote: >>>>>>> > > I Thought u-turn is the most simple comparison leaf vs. >>>>>>> non-leaf BFR. >>>>>>> > > >>>>>>> > > Zzh> The text in the email is seriously misaligned. Looking at >>>>>>> the picture in the diff link, while you gave a U-turn example, >>>>>>> though even if BFER2 is not connected to BFR2  but only connected >>>>>>> to BFER1 (hence no U-turn), then BFER1 is still not a leaf BFER I >>>>>>> suppose. That's why I said the first sentence of the above >>>>>>> paragraph is enough to define Leaf BFER while the example itself >>>>>>> is actually not needed. >>>>>>> > >>>>>>> > Argh... ok, had to fix two words, BFIR->BFER and left-hand -> >>>>>>> right-hand: >>>>>>> > >>>>>>> > Consider how redundant disjoint traffic can reach BFER1/BFER2 in >>>>>>> above >>>>>>> > picture: When BFER1/BFER2 are Non-Leaf BFER as shown on the >>>>>>> right hand >>>>>>> > side, one traffic copy would be forwarded to BFER1 from BFR1, >>>>>>> but the >>>>>>> > other one could only reach BFER1 via BFER2, which makes BFER2 a >>>>>>> > non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forwarding >>>>>>> > traffic to BFER2 >>>>>>> > >>>>>>> > > Zzh> Additionally, in left part of the picture you added, if >>>>>>> some failure leads to BFR2 to be only reachable via BFER1, then >>>>>>> BFER1 is no longer a leaf BFER. >>>>>>> > >>>>>>> > Added sentence: >>>>>>> > >>>>>>> > Note that the BFER in the left hand picture are only >>>>>>> guaranteed to >>>>>>> > be leaf-BFR by fitting routing configuration that prohibits transit >>>>>>> > traffic to pass through a PE, which is commonly applied in these >>>>>>> > topologies. >>>>>>> > >>>>>>> > > I assume you don't reassign BPs when links go up and down. >>>>>>> > >>>>>>> > I didn't want to discuss that option in this document. Its >>>>>>> obviously >>>>>>> > perfectly feasible, but be yet a big amount of text (especially the >>>>>>> > considerations how to do this make-before-break. Future doc. >>>>>>> > >>>>>>> > > > but subsequent polarization example confuses me. It seems >>>>>>> that BP 0:6 is assigned to the routed adjacency BFR10 (which is >>>>>>> actually talked about in Section 4.8). >>>>>>> > > >>>>>>> > > Section 4.7 does not mention "routed" at all, so there are no >>>>>>> routed adjacencies at all used in 4.7. So i am not sure what you >>>>>>> are confused about. >>>>>>> > > >>>>>>> > > Zzh> "The BIFT of each BFR are only populated with BPs that >>>>>>> are adjacent to the BFR in the BIER-TE topology". >>>>>>> > >>>>>>> > Correct text from the introduction. Ok. >>>>>>> > >>>>>>> > > Zzh> Since the same 0:6 is in BIFTS of BFR1/BFR2/BFR3 (and I >>>>>>> suppose in BFR4~BFR9 as well even though not drawn), I assumed >>>>>>> it's for the "MP2P" routed adjacency to R10; though I then ruled >>>>>>> that out - but I don't know what 0:6 represent now on BFR1, BFR2, >>>>>>> and BFR3. >>>>>>> > >>>>>>> > Ah. Ok. I thought i could strip down the example to show only the >>>>>>> > adjacencies relevant to the following discusion, but seemingly this >>>>>>> > can introduce the confusion you have. >>>>>>> > >>>>>>> > So i completed the example with the BP assignment acoss all >>>>>>> nodes, but >>>>>>> > added text pointing to a new section further down to discuss the >>>>>>> > re-use of BP for which thi picture is also an example. >>>>>>> > >>>>>>> > (check out the diff, new reuse text to long to copy inline). >>>>>>> > >>>>>>> > > The whole purpose of the ECMP BPs is of course to save bits, >>>>>>> otherwise we'd give each link a separate BP, which would be 6 BP >>>>>>> to reach to BFR4...BFR7 from BFR1. >>>>>>> > > >>>>>>> > > Zzh> The trouble I am having is that the same 0:6 is assigned >>>>>>> to different things and it's present on all BFR1/BFR2/BFR3. It is >>>>>>> perhaps an intentional smart design but I have not wrapped my mind >>>>>>> around it. It's apparently different from the link bundle case, so >>>>>>> better separate it out and elaborate it (including the DNR flag >>>>>>> that might be needed here - If the packet arrives on BFR1 with >>>>>>> 0:6, would the BP reset when it is sent to BFR2/3)? >>>>>>> > >>>>>>> > Yes, there was the bug of reusing BP 0:6 across sequential BFR >>>>>>> along >>>>>>> > the path, but now the example correctly reuses separate BP at >>>>>>> > different stages of the paths (BP 0:6 on BFR1, BP 0:7 on >>>>>>> BFR2/BFR3) and so on. >>>>>>> > >>>>>>> > Thanks! >>>>>>> > >>>>>>> > > > 4.8.  Routed adjacencies >>>>>>> > > > >>>>>>> > > > If I understand it correctly, there is a BP assigned to >>>>>>> L1/L2/L3 >>>>>>> > > > respectively (p2p link), and then there are BPs assigned to >>>>>>> MP2P tunnels (routed adjacency from every BFR) to the L1/L2/L3 >>>>>>> interface addresses and loopback addresses on BFR2/3. >>>>>>> > > >>>>>>> > > Ok that wasn't quite the read i expected. Let me clarify the >>>>>>> text/picture: >>>>>>> > > >>>>>>> > >                    ............... >>>>>>> > >          ...BFR1--...           ...--L1-- BFR2... >>>>>>> > >                   ... .Routers. ....--L2--/ >>>>>>> > >          ...BFR4--...           ...------ BFR3... >>>>>>> > >                    ................         | >>>>>>> > >                                           LO >>>>>>> > >                     Network Area 1 >>>>>>> > > >>>>>>> > > Assume the requirement in the above picture is to explicitly >>>>>>> steer traffic flows that have arrived at BFR1 or BFR4 via a >>>>>>> shortest path in the routing underlay "network area 1" to one of >>>>>>> the following three next segments: (1) BFR2 via link L1, (2) BFR2 >>>>>>> via link L2, (3) via BFR3. >>>>>>> > > >>>>>>> > > To achieve this, both BFR1 and BFR4 are set up with a >>>>>>> forward_routed adjacency BitPosition towards an address of BFR2 on >>>>>>> link L1, another forward_routed BitPosition towards an address of >>>>>>> BFR2 on link L2 and a third forward_routed Bitposition towards a >>>>>>> node address LO of BFR3. >>>>>>> > > >>>>>>> > > Does this clear ip the confusion ? >>>>>>> > > >>>>>>> > > Zzh> The picture is badly misaligned. I'll wait till 4.7 >>>>>>> questions are cleared. >>>>>>> > >>>>>>> > Ok. >>>>>>> > >>>>>>> > > > If BFR2/3 are also BFERs, then they additionally will have >>>>>>> BFER BPs. >>>>>>> > > > On BFR1/4, the BIFT entries for the MP2P BPs for the >>>>>>> L1/L2/L3/loopback interface addresses of BFR2/3 will use >>>>>>> forward_routed(interface/loopback address). For a packet to be >>>>>>> decapsulated on a BFER, there is a need for both the BFER BP and >>>>>>> another BP (p2p/lan/hub-spoke/routed-adjacency) in the packet (the >>>>>>> former is for decapsulation and the latter is for getting it there). >>>>>>> > > >>>>>>> > > This is not discussed in this section, but you are right - unless >>>>>>> > > BFR2 or BFR3 is a leaf BFR. In that case, it would just >>>>>>> leverage the one shared "leaf-BFR" BP, so they do not need a >>>>>>> per-BFER BP for local_decap(). >>>>>>> > > >>>>>>> > > Zzh> Right - shared leaf-BFR BP but still need that BP (the >>>>>>> key is that we need a BP to get packet to a BFER and then a BP for >>>>>>> decapsulation). >>>>>>> > >>>>>>> > You got it. >>>>>>> > >>>>>>> > > > If that???s the case, it???s worth point the above out. >>>>>>> > > >>>>>>> > > Hmm... The logic of BFER BPs is totally independent of the >>>>>>> logic of forward_routed adjacency, so i would worry that repeating >>>>>>> the explanation of BFER BPs would conflate the forward_routed >>>>>>> explanation. >>>>>>> > > >>>>>>> > > Zzh> It's just that this is a place where all kinds of BPs are >>>>>>> used so it's good to have a summary (could be a subsection 4.9). >>>>>>> > >>>>>>> > Yes, added such a summary. Pls. check. >>>>>>> > >>>>>>> > > > Actually, the reason that I thought this is MP2P is that 0:6 >>>>>>> is present on R1, R2, and R3 (and more I assume) in Figure 12, but >>>>>>> now I think it can???t be MP2P (so it is not correct to have 0:6 >>>>>>> present on those routers ??? only the p2p tunnel head/tail should >>>>>>> have the BP present in the BIFT). The reason is that if it were >>>>>>> MP2P, any router getting a copy will send it to the endpoint of >>>>>>> the routed adjacency, causing lots of duplicates. >>>>>>> > > > >>>>>>> > > > Am I getting this correct? >>>>>>> > > >>>>>>> > > I think you are still explaining from the misunderstsanding >>>>>>> that the ECMP explanations where about routed adjacencies. >>>>>>> > > >>>>>>> > > I have now expanded the somewhat terse text in the BIFT table >>>>>>> pictures, to make it clear that the ECMP is across multipe >>>>>>> forward_connected adjacencies in the examples. For example, first >>>>>>> BIFT picture: >>>>>>> > > >>>>>>> > >   BIFT entry in BFR1: >>>>>>> > > >>>>>>>  ------------------------------------------------------------------ >>>>>>> > >   | Index |  Adjacencies                  | >>>>>>> > > >>>>>>>  ================================================================== >>>>>>> > >   | 0:6   |  ECMP({forward_connected(L1, BFR2),                 | >>>>>>> > >   |       |        forward_connected(L2, BFR2),                 | >>>>>>> > >   |       |        forward_connected(L3, BFR2)}, seed) >>>>>>>      | >>>>>>> > > >>>>>>>  ------------------------------------------------------------------ >>>>>>> > > >>>>>>> > > Of course, an ECMP adjacency can be across any type of >>>>>>> adjacencies, but all the text/explanations used forward_connected, >>>>>>> and now the pictures show that explicitly. >>>>>>> > > >>>>>>> > > Zzh> I can understand the multi-link case, but the multi-hop >>>>>>> ECMP case (from BFR1 towards BFR10) is confusing me. It would help >>>>>>> to give an example how it can be used, WITHOUT worrying about >>>>>>> polarization. >>>>>>> > >>>>>>> > Please check -05 text that has the full set of BIFT listed now: >>>>>>> > >>>>>>> > There is  really nothing nothing unique in multi-hop ECMP for >>>>>>> BIER-TE >>>>>>> > that we do not also have in any other ECMP, except the >>>>>>> conclusion that >>>>>>> > we want to support fast HW hash mechanisms AND allow the >>>>>>> controller to >>>>>>> > set up non-polarized multi-hop ECMP AND be able to precalculate >>>>>>> paths. >>>>>>> > Hence the specification of ECMP adjacencies to have a controller >>>>>>> > configurable seed. >>>>>>> > >>>>>>> > Btw: The picture is maybe unnecessarily large because i've used >>>>>>> it for >>>>>>> > 20 years to explain the same polarization issue for unicast vs >>>>>>> > multicast, and for multicast only BFR10...BFR4 are relevant >>>>>>> (ECMP of >>>>>>> > the PIM/mLDP joins), whereas for unicast/BIER only >>>>>>> > BFR1...BFR7 are relevant. But being symmetric, the picture makes it >>>>>>> > clear its the same problem. >>>>>>> > >>>>>>> > > >    To inhibit looping in the face of such physical >>>>>>> misconfiguration, >>>>>>> > > >    only forward_connected adjacencies are permitted to have >>>>>>> DNR set, and >>>>>>> > > >    the link layer destination address of the adjacency >>>>>>> (e.g.  MAC >>>>>>> > > >    address) protects against closing the loop.  Link layers >>>>>>> without port >>>>>>> > > >    unique link layer addresses should not be used with the >>>>>>> DNR flag set. >>>>>>> > > > >>>>>>> > > > It???s not clear how link layer address helps? >>>>>>> > > >>>>>>> > > I have expanded this to >>>>>>> > > "link layer port unique unicast destination address" >>>>>>> > > >>>>>>> > > Aka: MPLS or ethernet have unique link layer destination >>>>>>> destination addresses (label or destination MAC). If you think >>>>>>> about incorrectly plugged HDLC links (such as old T1/T3/.... >>>>>>> links), they only have 2 generic addresses, if i remember 1 or 3 >>>>>>> in the HDLC frame. So when you misplug one of those p2p cables >>>>>>> wrong, the packets would be incrrectly received by the wrong >>>>>>> receiver node and then DNR could cause persistent loops only >>>>>>> solved by TTL. >>>>>>> > > >>>>>>> > > Zzh> "Consider in the ring picture that link L4 from BFR3 is >>>>>>> plugged into the L1 interface of BFRa" - still not sure how >>>>>>> label/mac helps here. I suppose the ring topology is >>>>>>> discovered/verified by the control plane and when the miscalling >>>>>>> happens then the ring will not include the BFR1/BFR2 part and BFR3 >>>>>>> will not have the DNR set? If ring discovery/varication is not >>>>>>> done then perhaps we should point out that RPF based on link layer >>>>>>> address is needed - the key is RPF (which needs unique link layer >>>>>>> address)? >>>>>>> > >>>>>>> > Forget RPF. BIER(-TE) has no RPF (issues). Its just like >>>>>>> unicast. RPF >>>>>>> > is just a problem for receiver originated joins like in >>>>>>> PIM/mLDP, but >>>>>>> > not unicast/bier(-te)/RSVP-TE. >>>>>>> > >>>>>>> > Forward_connected is just like a unicast subnet adjacency to a >>>>>>> direct >>>>>>> > neighbor: Interface and L2 addresss of the destination. >>>>>>> > >>>>>>> > The controller (could be a human) "assumes" a particular physicial >>>>>>> > topology, from telemetry/knowledge/whatever. It then calculates the >>>>>>> > desired BIER-TE topology and pushes it down. This topology is >>>>>>> meant to >>>>>>> > be loop free of course wrt to the configured adjacencies. >>>>>>> > In this BIER-TE topology, BFR3 will have a BP with the >>>>>>> > forward_connected(L4, MAC-of-BFR2) adjacency. >>>>>>> > >>>>>>> > If the cable connecting to L4 is miswired, then BFR3 would still >>>>>>> send >>>>>>> > the packets to the MAC address of BFR2, but given how the cable >>>>>>> > connects to some other node, these packets will be discarded by >>>>>>> that >>>>>>> > node. because they're just L2 unicast packets. >>>>>>> > >>>>>>> > I think this is equally true when we have normal BIER/MPLS enacp. >>>>>>> > Those packets too are addressed to the unicast MAC address of the >>>>>>> > neighbor. >>>>>>> > >>>>>>> > Now, if/when he controller recognizes that the physical topology >>>>>>> has >>>>>>> > changed, thats a completely different story and not addressed here. >>>>>>> > Given how we assumed this was a cabling mistake, the controller >>>>>>> would >>>>>>> > probably only complain about the miswiring to operations but be >>>>>>> happy >>>>>>> > that the forwarding plane just makes packets fail instead of >>>>>>> loop. If >>>>>>> > this was a planned change process, then it will be similarily >>>>>>> > convoluted as it would today be with rewiring cables in an >>>>>>> > SR-MPLS/SRv6 topology and updating SIDs. >>>>>>> > >>>>>>> > > > Because the forwarding is different from BIER forwarding >>>>>>> (because of [1] above), we might as well introduce an optimization >>>>>>> here ??? for each BIFT, calculate the F-BM of the BIFT itself (the >>>>>>> logical ???or??? of all the BPs presented in this BIFT) and then >>>>>>> use (packet->bitstring & BIFT.F-BM) as the input to >>>>>>> GetFirst/NextBitPosition(). That should skip many bits. >>>>>>> > > >>>>>>> > > Right. But i explicitly removed those optimizations (i had >>>>>>> them in older draft versions) because the whole idea of this >>>>>>> picture is solely the comparison with figure 4 of RFC8279. >>>>>>> > > >>>>>>> > > Zzh> I think it's worth point that optimization out; you can >>>>>>> mark it optional if you want to emphasize the similarity to BIER >>>>>>> forwarding, but since BIER forwarding does do the maskoff step, it >>>>>>> is very efficient while BIER-TE forwarding does not it the maskoff >>>>>>> step so this optimization is important. >>>>>>> > >>>>>>> > Ok. I simplified the text comparison BIER/BIER-TE wrt. to the FBM >>>>>>> > rules [1] and [2] and added following paragraph: >>>>>>> > >>>>>>> > In BIER, the order of BPs impacts the result of forwarding >>>>>>> because of [1]. >>>>>>> > In BIER-TE, forwarding is not impacted by the order of BPs. It is >>>>>>> > therefore possible to further optimize forwarding than in BIER. For >>>>>>> > example parallelizing forwarding across multiple FPE cores or >>>>>>> > distributed linecards does only need to examine an arbitrary >>>>>>> subset of >>>>>>> > BP and not evaluate the dependency between BPs. >>>>>>> > >>>>>>> > > >    The following pseudocode is comprehensive: >>>>>>> > > > >>>>>>> > > > The above sentence reads a bit strange (or lacks some segue). >>>>>>> > > >>>>>>> > > I hope not, but maybe best left to a native english speaker >>>>>>> (RFC-editor). >>>>>>> > > >>>>>>> > > The first (RFC8279) pseudocode was simplified. The second one >>>>>>> is comprehensive. If not comprehensive, whats a good opposite of >>>>>>> simplified ? >>>>>>> > > >>>>>>> > > Zzh> Perhaps "The above simplified pseudocode is elaborated >>>>>>> further as following"? >>>>>>> > > Zzh> Jeffrey >>>>>>> > >>>>>>> > Done. >>>>>>> > >>>>>>> > Thanks a lot. >>>>>>> > >>>>>>> > >>>>>>> > > >>>>>>> > > > ________________________________________ >>>>>>> > > > From: BIER [bier-bounces@ietf.org >>>>>>> >>>>>> >] >>>>>>> > > > on behalf of Toerless Eckert [tte@cs.fau.de >>>>>>> >] >>>>>>> > > > Sent: Tuesday, July 09, 2019 23:38 >>>>>>> > > > To: Mike McBride >>>>>>> > > > Cc: Greg Shepherd; BIER WG; Pascal Thubert (pthubert) >>>>>>> > > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch >>>>>>> > > > >>>>>>> > > > Thanks, Mike >>>>>>> > > > >>>>>>> > > > The authors also reviewed the document and concluded that it >>>>>>> was >>>>>>> > > > really hard to get into the document context because of too >>>>>>> many >>>>>>> > > > forward dependencies. We tried to fix this by adding two >>>>>>> hopefully >>>>>>> > > > good & basic examples into the Introduction section and >>>>>>> using them >>>>>>> > > > to also add a better definition of the term "BIER-TE >>>>>>> Topology" in the Introduction. >>>>>>> > > > Hopefully this makes readin the rest of te document smoother. >>>>>>> > > > >>>>>>> > > > Also improved text of Abstract and refined text compariing >>>>>>> BIER-TE with SR. >>>>>>> > > > >>>>>>> > > > >>>>>>> https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: >>>>>>> > > > **Atools.ietf.org >>>>>>> *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A >>>>>>> > > > tool >>>>>>> > > > s.ietf.org >>>>>>> *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R >>>>>>> > > > jC81 >>>>>>> > > > >>>>>>> c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV_eTUEh >>>>>>> > > > $ >>>>>>> > > > >>>>>>> >>>>>> > > > **Atools.ietf.org >>>>>>> *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A >>>>>>> > > > tool >>>>>>> > > > s.ietf.org >>>>>>> *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R >>>>>>> > > > jC81 >>>>>>> > > > >>>>>>> c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sNd1njcX >>>>>>> > > > $> >>>>>>> > > > >>>>>>> > > > Cheers >>>>>>> > > >     Toerless >>>>>>> > > > >>>>>>> > > > On Wed, Jun 26, 2019 at 10:39:36AM -0700, Mike McBride wrote: >>>>>>> > > > > How about three? I support. >>>>>>> > > > > mike >>>>>>> > > > > >>>>>>> > > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd >>>>>>> >>>>>> >>>>>> >> wrote: >>>>>>> > > > > > >>>>>>> > > > > > We cannot take two 'yes' votes and WG consensus. >>>>>>> > > > > > Please, read and respond. If you don't support, then >>>>>>> please vote as much publicly right here. >>>>>>> > > > > > >>>>>>> > > > > > Thanks, >>>>>>> > > > > > Greg >>>>>>> > > > > > >>>>>>> > > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert >>>>>>> (pthubert) >>>>>> >>>>>> >> wrote: >>>>>>> > > > > >> >>>>>>> > > > > >> Support: >>>>>>> > > > > >> >>>>>>> > > > > >> I see great value in deterministic networks as well as >>>>>>> IOT (with RPL). >>>>>>> > > > > >> >>>>>>> > > > > >> All the best, >>>>>>> > > > > >> >>>>>>> > > > > >> Pascal >>>>>>> > > > > >> >>>>>>> > > > > >> > -----Original Message----- >>>>>>> > > > > >> > From: BIER >>>>>>> > > > > >> > >>>>>> >>>>>> >> On >>>>>>> > > > > >> > Behalf Of Toerless Eckert >>>>>>> > > > > >> > Sent: mardi 4 juin 2019 02:03 >>>>>>> > > > > >> > To: Greg Shepherd >>>>>>> > > > > >> > >>>>>> >>>>>> >> >>>>>>> > > > > >> > Cc: BIER WG >>>>>> >> >>>>>>> > > > > >> > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch >>>>>>> > > > > >> > >>>>>>> > > > > >> > +1 >>>>>>> > > > > >> > Obviously support as co-author. >>>>>>> > > > > >> > >>>>>>> > > > > >> > On Wed, May 29, 2019 at 12:41:26PM -0700, Greg >>>>>>> Shepherd wrote: >>>>>>> > > > > >> > > Please read and respond to this thread w/ or w/o >>>>>>> support. >>>>>>> > > > > >> > > >>>>>>> > > > > >> > > >>>>>>> https://urldefense.com/v3/__https://datatracker..ietf.org >>>>>>> > > > > >> > > /doc >>>>>>> > > > > >> > > >>>>>>> /draft-ietf-bier-te-arch/__;!8WoA6RjC81c!XvH4AAxfrDjFoK_s >>>>>>> > > > > >> > > ercw ZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV9eClBj$ >>>>>>> > > > > >> > > >>>>>>> >>>>>> > > > > >> > > doc/ >>>>>>> > > > > >> > > >>>>>>> draft-ietf-bier-te-arch/__;!8WoA6RjC81c!UBTGvWWpMHyeiSanx >>>>>>> > > > > >> > > s6vI b_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sD40kmtH$> >>>>>>> > > > > >> > > >>>>>>> > > > > >> > > Vote ends 5 June 2019. >>>>>>> > > > > >> > > >>>>>>> > > > > >> > > Thanks, >>>>>>> > > > > >> > > Shep >>>>>>> > > > > >> > > (chairs) >>>>>>> > > > > >> > >>>>>>> > > > > >> > > _______________________________________________ >>>>>>> > > > > >> > > BIER mailing list >>>>>>> > > > > >> > > BIER@ietf.org >>>>>>> > >>>>>>> > > > > >> > > >>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/ >>>>>>> > > > > >> > > list >>>>>>> > > > > >> > > >>>>>>> info/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eE >>>>>>> > > > > >> > > NOs4 l_qdsXF0KwZD82cJLDFFNT2WVXWX$ >>>>>>> > > > > >> > > >>>>>>> >>>>>> > > > > >> > > list >>>>>>> > > > > >> > > >>>>>>> info/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6b >>>>>>> > > > > >> > > oAAW 4nrqju8UCLOgiuXc8Y_6sKn2KoAT$> >>>>>>> > > > > >> > >>>>>>> > > > > >> > _______________________________________________ >>>>>>> > > > > >> > BIER mailing list >>>>>>> > > > > >> > BIER@ietf.org >>>>>>> > >>>>>>> > > > > >> > >>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/li >>>>>>> > > > > >> > stin >>>>>>> > > > > >> > >>>>>>> fo/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4 >>>>>>> > > > > >> > l_qd >>>>>>> > > > > >> > sXF0KwZD82cJLDFFNT2WVXWX$ >>>>>>> > > > > >> > >>>>>>> >>>>>> > > > > >> > stin >>>>>>> > > > > >> > >>>>>>> fo/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW >>>>>>> > > > > >> > 4nrq >>>>>>> > > > > >> > ju8UCLOgiuXc8Y_6sKn2KoAT$> >>>>>>> > > > > > >>>>>>> > > > > > _______________________________________________ >>>>>>> > > > > > BIER mailing list >>>>>>> > > > > > BIER@ietf.org >>>>>>> > >>>>>>> > > > > > >>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listi >>>>>>> > > > > > nfo/ >>>>>>> > > > > > >>>>>>> bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsX >>>>>>> > > > > > F0Kw >>>>>>> > > > > > ZD82cJLDFFNT2WVXWX$ >>>>>>> > > > > > >>>>>>> >>>>>> > > > > > nfo/ >>>>>>> > > > > > >>>>>>> bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju >>>>>>> > > > > > 8UCL >>>>>>> > > > > > OgiuXc8Y_6sKn2KoAT$> >>>>>>> > > > >>>>>>> > > > -- >>>>>>> > > > --- >>>>>>> > > > tte@cs.fau.de >>>>>> > >>>>>>> > > > >>>>>>> > > > _______________________________________________ >>>>>>> > > > BIER mailing list >>>>>>> > > > BIER@ietf.org >>>>>> > >>>>>>> > > > >>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ >>>>>>> > > > bier >>>>>>> > > > >>>>>>> __;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82 >>>>>>> > > > cJLD >>>>>>> > > > FFNT2WVXWX$ >>>>>>> > > > >>>>>>> >>>>>> > > > bier >>>>>>> > > > >>>>>>> __;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiu >>>>>>> > > > Xc8Y >>>>>>> > > > _6sKn2KoAT$> >>>>>>> > > >>>>>>> > > -- >>>>>>> > > --- >>>>>>> > > tte@cs.fau.de >>>>>>> > >>>>>>> > -- >>>>>>> > --- >>>>>>> > tte@cs.fau.de >>>>>>> > >>>>>>> > _______________________________________________ >>>>>>> > BIER mailing list >>>>>>> > BIER@ietf.org >>>>>>> > >>>>>>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier >>>>>>> > >>>>>>> __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx4 >>>>>>> > 1_jWV3YUA6D$ >>>>>>> >>>>>>> -- >>>>>>> --- >>>>>>> tte@cs.fau.de >>>>>>> >>>>>>> _______________________________________________ >>>>>>> BIER mailing list >>>>>>> BIER@ietf.org >>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=DrLodD0a2MFe60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e= >>>>>>> >>>>>> _______________________________________________ >>>>>> BIER mailing list >>>>>> BIER@ietf.org >>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=DrLodD0a2MFe60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e= >>>> _______________________________________________ >>>> BIER mailing list >>>> BIER@ietf.org >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=DrLodD0a2MFe60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e= >>> _______________________________________________ >>> BIER mailing list >>> BIER@ietf.org >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=DrLodD0a2MFe60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e= >>> >> >> _______________________________________________ >> BIER mailing list >> BIER@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=DrLodD0a2MFe60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e= > -- Prof. Dr. habil. Michael Menth University of Tuebingen Faculty of Science Department of Computer Science Chair of Communication Networks Sand 13, 72076 Tuebingen, Germany phone: (+49)-7071/29-70505 fax: (+49)-7071/29-5220 mailto:menth@uni-tuebingen.de http://kn.inf.uni-tuebingen.de From nobody Thu Feb 27 00:36:03 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236B23A1527 for ; Thu, 27 Feb 2020 00:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 F_wItFLwblt0 for ; Thu, 27 Feb 2020 00:35:57 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C6FC3A1524 for ; Thu, 27 Feb 2020 00:35:56 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 00ECA548053; Thu, 27 Feb 2020 09:35:48 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id EF662440040; Thu, 27 Feb 2020 09:35:47 +0100 (CET) Date: Thu, 27 Feb 2020 09:35:47 +0100 From: Toerless Eckert To: "BRUNGARD, DEBORAH A" Cc: Lou Berger , "gjshep@gmail.com" , "bier@ietf.org" , "Jeffrey (Zhaohui) Zhang" Message-ID: <20200227083547.GA23965@faui48f.informatik.uni-erlangen.de> References: <11ab30da-8701-b491-6162-5a69aa9d6965@labn.net> <20200220035620.GA42520@faui48f.informatik.uni-erlangen.de> <20200225015718.GC20521@faui48f.informatik.uni-erlangen.de> <20200226000206.GA31874@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 08:36:02 -0000 Hi Deborah, inline On Wed, Feb 26, 2020 at 09:33:17PM +0000, BRUNGARD, DEBORAH A wrote: > Hi Toerless, > > Your comment: > > > I would appreciate if you could try to partition your opinions into > > > things you think MUST be solved before passing the document to IESG (for > > > IETF/IESG review) and those issues that could then be solved when it is > > > in IETF/IESG review. For example, i think a final choice of name could > > > be something that shouldn't block the document to take this step. > > > > > Waiting for the IESG to "name" your technology will definitely result in a much longer delay than sorting out in WG Last Call. Ack > You noted, you had presented an earlier version of this document in TEAS, but it is at the time of WG Last Call (per the charter), the TEAS/MPLS/and probably PCE, should have been notified (I included MPLS as you have multiple proposals on use of MPLS labels). I've contacted your BIER Chairs/AD to extend at least a week the Last Call. Thanks. I hope that feedback would still have to go all go to BIER, and not to those other WG mailing lists, right ? Don't want to hunt feedback across many WG lists. > On naming, as Lou noted, preference is to align terminology used in other working groups - especially within the routing area. The RFC-editor also recommends careful use of abbreviations - it is expected new abbreviations are added to a list: > https://www.rfc-editor.org/materials/abbrev.expansion.txt See below > As you can see, PE is already used. a) 461 out of 2651 abbreviations in that doc are overloaded. b) There is no indication that suffixes of a composite abbreviation have to be unique. c) We would only want to use BIER-PE as an abbreviation, not PE alone. That is btw. why i changed all the occurances of "path engineering" in the text to explanatory "steering" or "policy" and only use BIER-PE as a name. d) Of course i would get BIER-PE registered when being in RFC-editor state like i have done in the past in other RFCs. e) How about SR first meaning Source Routing and then being overloaded with Segment Routing ? And if Segment Routing was a valid new term (as it has more flexibility than Source Routing), why then not allow Path Engineering as a new term for us ? e) SR in abbrv.expansion.txt: SR - sender report (SR) No "Source Routing", "Segment Routing", no SR-MPLS, No SRH from RFC6554, No consideration for disambiguating RFC6554 SRH from SRv6 SRH, ... NADA! (not even NADA/RFC8698) I know your and Lou's comments wrt. naming are well meaning, but given those and other (below) realities i hope it is not too rude for me to say that its perceived on my end a bit more like selective hazing. Can we please turn this around and you help us in actually selecting a good name ? > And in the Routing Area, for our PE abbreviation, we could say it should have an asterisk???? Sure, please talk with RFC editor to get it added to the doc. But asterix does not say anything about whether or not there is a conflict when reusing another abbreviation in a suffix of a longer name. Maybe when you get the asterisk, ask the RFC editor about that. There are no prior cases of this in the doc, so not possible to derive case law from the existing abbreviations. >Your justification is that "PE" is short similar to "TE", but for the Routing Area, it needs to be either different or maybe add a letter (three letters). If you look thru the list, that's what others have done e.g. in SPRING, they have a new document also using "PE" differently but it's abbreviated "EPE". [ SPRING is the WG working on sender report (SR) ? (sorry, could not resist) ] draft-ietf-spring-segment-routing-central-epe - "Egres Peer Engineering" To me its primarily a good reference that other work is not contested when combining the word engineering with other words beside "Traffic" whereas this is contested when i am prosing to do it for the BIER work. > As we all enjoy trying to name "something", Not when the baby has a name for 5 years and that then gets contested. > I checked PCE documents (as you noted in the document, BIER-PE requires SDN/PCE controller). BIER-PE does not require a PCE according to RFC 4655, RFC 4657. That is a highly desirable option when you want to use BIER-PE for Traffic Engineering, but it is explicitly not scoped in this document so as to not encumber the document or constrain the applicability of its technology. The document has early on in section 2 the mandatory dependencies of BIER-PE, which includes the "BIER-PE Controller" as a concept as abstract as possible, and the document does explain what that BIER-TE controller needs to do without expecting any PCE arch TE definition . Such a BIER-PE controller could in one instance be an operator using CLI. I had another explanation in section 1.1 i added/proposed for Lou, stating how the "BIER-PE controller" would be a new function within a larger PCE if BIER-PE was used in a traffic engineering / PCE framework, but Lou said i should rather remove that section 1.1, which i did, so i think he is fine with waiting for the BIER-TE framework draft to define how the BIER-PE controller relates to a PCE. > As Lou says - there is no mention of "path engineering" either in PCE documents or any IETF documents. So maybe "PE" in the string is not the best. There was also no mention in IETF or PCE documents of "Segment Routing" before it was invented, and SR likely meant something else, so what is the point ? >My 2-cents, how about "SREP-BIER" (Source Routed Engineered Path)? See above on the SR confusion. Also note that the bigger common technology here is not 'source routing', but BIER, so that should be the prefix. Also, see below. > Have fun naming. See above. > but please stabilize on a name before hand-off to the IESG - otherwise the IESG will have all the fun. What would really help the authors and the WG to finalize on a name would be for you and Lou go beyond explaining what we should NOT choose as a name to what we are allowed to choose as names. Otherwise we could as well have the poor WG circle around this block multiple time. So please with sugar and whipped creme topping, let us know what will be permitted. Lou said we should re-use existing terms, i told him why using ONLY those would not well represent the unique novelty of BIER-PE but lead to confusion with unicast semantics (and besides: see SR and anybody else choosing new names for equal good reasons). BIER-PE is an easy compromise that i think makes everybody equally but only little unhappy. If not then then please comment on the following list which i hope would be sufficiently broad for the WG to select a name from: BIER-ET - Explicit Trees BIER-EET - Explicit Engineered Trees BIER-BET - Bit Engineered Trees BIER-BST - Bit Steered Trees BIER-TrE - Tree engineering BIER-ET - Engineered Trees BIER-ST - Steered Trees BIER-ASB - Adjacency Steering Bits (adjacencies are how bits in BIER-PE are defined) BIER-AB - Adjacency Bits BIER-SB - Steering Bits (overloads with "Source Block" - never heard) [ I prefer terms with Tree, because thats the unique distinction to paths, and highlight the multicast specific characteristic. ] > As BIER-PE requires use of an SDN/PCE controller - here's my early AD comments - please mention this earlier in the document - abstract, intro. e.g. the SPRING document has as the title "centralized" EPE. I answered this alredy above. > "SR aims to enable lightweight path steering via loose source routing. Compared to its more heavy-weight predecessor RSVP-TE, SR does for example not require per-path signaling to each of these hops." > > RSVP-TE provides very different capabilities than SR and BIER. With RSVP-TE glasses on, one could say SR and BIER provide very limited capabilities. And both SR and BIER require very heavy-weight SDN controllers. So it just depends where the operator/vendor wants to put their "weight". > But it's not for IETF to do the judgement. > An RFC is not for marketing one technology vs. another. The goal of the text was not to make non-technical judgements about the overall TE systems or to market SR, but simply to provide a technical explanation of the aspects of SR that relate to BIER-PE and relate that to RSVP-TE given how RSVP-TE/P2MP is also the equivalent alternative for BIER-PE: SR : RSVP-TE ~= BIER-TE : RSVP-TE/P2MP But: "predecessor" is an imprecise qualification. I just thought about the timeline, not the possible misinterpretation that SR would/could/should 1:1 superceed RSVP-TE. Also, the verbage of heavy vs. lightweight is not correctly constrained to the technical point of comparison (on-transit-hop heavyness of path steering). I propose to change that sentence accordingly: "SR supports through the use of source-routing strict and loose hop path steering across transit hops that is lightweight on those transit hops because it does not require per-hop/per-flow signaling to and forwarding plane state on those transit hops. In comparison, RSVP-TE and RSVP-TE/P2MP do require such per-hop/per-flow transit-hop signaling and forwarding plane state " I think this is now technically precise and limited to the necessary comparison in this context. If you still have concerns, pls. let me know why, ideally with proposed text that would solve those concerns. I think it is important to explain the relevant technical aspects that where the core reasons for doing BIER-PE, especially in comparison to existing solutions. [ Btw: If memory serves me well, the whole PCE architecture was introduced first by recognizing that you could not use RSVP-TE in situations with multi-headend resource contention without a central/coordinated PCE efficiently, and then implementations managed to build those PCE fairly lightweight into headend routers. Technically i would therefore disagree with your contentions that PCE need to be very heavy-weight and that RSVP wouldn't need them but only SR/BIER-PE. But definitely this BIER-PE document is not the place to have that argument. A later BIER-TE framework document nevertheless would IMHO be more useful to adopters and operators if it had such technical description - without judgement and marketing, just the facts! ] > Hopefully my working groups (TEAS, MPLS, PCE) are given the "heads-up" soon - I'd prefer discussion during working group last call vs. IETF Last Call or my needing to enter a "Discuss" waiting for their review. I did see Lou sending mail to TEAS and DetNet and Lea to MPLS, did you send to PCE ?. I do of course welcome feedback from any group, but i am not worried about MPLS or PCE. There are no changes on the MPLS encap side, and as explained above, mapping BIER-PE into the PCE framework is also subject to followup work (like i think it was for SR as well). Thanks a lot. Cheers Toerless > Thanks! > Deborah > (AD hat on) > > -----Original Message----- > From: BIER On Behalf Of Toerless Eckert > Sent: Tuesday, February 25, 2020 7:02 PM > To: Lou Berger > Cc: gjshep@gmail.com; bier@ietf.org; Jeffrey (Zhaohui) Zhang > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK > > Lou, *: > > Here is the next and hopefully final github version for your review. > If you can give a thumbsup i will upload to datatracker, > and the WG chairs would also be able to finalize WG last-call. > > https://urldefense.proofpoint.com/v2/url?u=https-3A__raw.githubusercontent.com_toerless_bier-2Dte-2Darch_7e996deb1dcd18596d4864c750f6e7541d737e6f_draft-2Dietf-2Dbier-2Dte-2Darch.txt&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=hbVUmt6ob-Ilgt00kiOlwAOcA68kldlxvO0Lqq-gKxo&e= > > And here the diff to -05, last version before taking input from your review into account. > Given how 1.1 was removed, this seems like the most logical comparison point. > > https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org_tools_rfcdiff_rfcdiff.pyht-3Furl1-3Dhttps-3A__tools.ietf.org_id_draft-2Dietf-2Dbier-2Dte-2Darch-2D05.txt-26url2-3Dhttps-3A__raw.githubusercontent.com_toerless_bier-2Dte-2Darch_7e996deb1dcd18596d4864c750f6e7541d737e6f_draft-2Dietf-2Dbier-2Dte-2Darch.txt&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=jTvrGagqHgPKneTUpOvNkeYcl7cxDSV32gLk--vyzdQ&e= > > Changes to -05 are now easily seen as limited textual: > - Name change BIER-TE to BIER-PE > - Explanations using steering/policy > - [RFC-editor remove note] about name change. > - BIER-TE controller host -> BIER-TE Controller (unrelated to Lou) > > Detailled answers, explanations below. > > Cheers > Toerless > > On Tue, Feb 25, 2020 at 01:19:26PM -0500, Lou Berger wrote: > > Hi Toerless, > > > >     This revision will mostly remove my objection related to the use of TE > > by the document.  I suspect in section 7.2 you have two instances where > > "traffic" needs to be replaced with "path". > > Fixed > > > More substantively, I think you > > should delete section 1.1 and leave its subject  matter  to > > eckert-teas-bier-te-framework to be covered/worked out.  If you want to keep > > it, I think there's a longer discussion need on its contents. > > Removed section 1.1 from the text. > > I have added to the beginning of 1. an [RFC-editor: pls. remove ] section > explaining the naming change so late in the process to further IETF/IESG > reviewers (if i had just put it into the changelog i fear it will > be overlooked by reviewers). > > For what is worth, i did like the idea of having explanations > about relationship of BIER-PE to BIER-TE, especially because the > framework is IMHO not yet in a state to serve as a good even draft > reference (it was only pointed to in section 1.1, so also removed > as reference). > > How about this: If IESG review wants to have that type of explanation back, > i'll knock on your door to revive and help me fix up that text. > > > FWIW I still think the introduction of the a new term "Path Engineering", > > rather than reusing one of the existing IETF terms for the same capability > > ("routing policy", "policy based routing", "path steering") seems  likely to > > lead to more confusion then if you stuck with an established term.  I'll > > leave this to others to argue. > > Ok, second time around you're suggesting this, i now owe you an explanation > why i think these terms are technically misleading: > (its a bit long, that why i avoided the explanation in before). > > All the established terms you propose come from unicast and > never had a re-definition/re-interpretation for IP multicast. > > Using any of these terms in the name would easily lead to > people (especially when not reading the doc) think the > BIER solution here works like in both IP multicast and > BIER in before BIER-PE: By impacting the underlying unicast > (forward) routing (BIER) or RPF (reverse path) routing (IP Multicast). > > Examples: You can use static muRIB routes to steer traffic for > IP Multicast or BIER. You can also use separate IGP (Flex-)topologies > to do the same dynamically. Thats all great stuff to describe in a > BIER-TE framework document (in conjunction with BIER), but that > is also the stuff i do not want BIER-PE to be confused with > because there are technical limitations to those unicast routing policy/ > steering approaches when its applied to trees: > > Try to use any of the pre-existing mechanisms for unicast routing policy > or path steering with BIER or IP multicast to build steiner trees. > Not generally possible. With BIER-PE, no problem. Same thing with > disjoint trees (even MRT flex-algo's wouldn't achieve the same). > > IMHO, the term "Path Engineering" is free of this mis-name-recognition > because it is a new. The name also hints at the fact that this could be > in support of, or a component of traffic engineering. > And wrt to minimizing the change to the long held name, > the hamming distance is just one character/word. So it's the > 'safest/most-conservative/logical' name change this late in the > process. > > As i said, i would be happier with a more unique new descriptive > name like "Tree Steering Bitstrings" (BIER-TSB), but i do not feel > like making such a big naming change without more explicit support > by more members of the WG this late in the process. > > > I think this covers all the detailed discussion points below. If not, can > > you extract the ones you'd like to keep discussing? > > Still sad about the missed opportunity of fixing this naming > problem earlier wrt. to the mail you sopposedly sent, and > happy to beat myself up if that ended up being my fault, but > i guess i shouldn't continue to dig into that issue if it would > turn out to be someone else's fault. > > Otherwise i am fine. > > If you want to give the doc now a thumbs up in response to the last > call, that would be great ;-) > > EOF > > > Thanks again for the responsiveness to my comments! > > > > Lou > > > > On 2/24/2020 8:57 PM, Toerless Eckert wrote: > > > Hi Lou, round 2. > > > > > > Here is the github pre-version of -07 of the draft: > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__raw.githubusercontent.com_toerless_bier-2Dte-2Darch_62378f618299307349a934fc6ad78e1af9e16771_draft-2Dietf-2Dbier-2Dte-2Darch.txt&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=ijbHbeNowm8uYigeF3tPQBOSrFL5chyoxfjBXyDOxPg&e= > > > > > > Diff: > > > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org_tools_rfcdiff_rfcdiff.pyht-3Furl1-3Dhttps-3A__tools.ietf.org_id_draft-2Dietf-2Dbier-2Dte-2Darch-2D06.txt-26url2-3Dhttps-3A__raw.githubusercontent.com_toerless_bier-2Dte-2Darch_62378f618299307349a934fc6ad78e1af9e16771_draft-2Dietf-2Dbier-2Dte-2Darch.txt&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=VMWxCE2IzT007rczFZWwh1CEB3xG48xOj5RifpjIt5s&e= > > > > > > I would appreciate if you could try to partition your opinions into > > > things you think MUST be solved before passing the document to IESG (for > > > IETF/IESG review) and those issues that could then be solved when it is > > > in IETF/IESG review. For example, i think a final choice of name could > > > be something that shouldn't block the document to take this step. > > > > > > If this goes along into IETF107, it would be great if you could find the > > > time to be at the BIER-WG meeting. > > > > > > Summary of changes: > > > > > > 1. Changed abbreviation BIER-TE to BIER-PE, otherwise we can not unconfuse > > > readers of the difference between BIER-PE and BIER-TE. > > > > > > Relationship: BIER-TE = (BIER with steering: BIER-PE or othre) plus resource > > > allocation mechanisms, and this document only describes BIER-PE. > > > > > > 2. Removed all use of the term "path engineering" from the (explanatory) text, > > > replaced with path / tree steering or policy in the text (like RFC8402). > > > > > > 3. In result, "Path Engineering" is now solely a name for the mechanism. > > > In the same way as SR introduced "Segment Routing" as a name, but explains > > > what it does with the terms "steering" and "policy". > > > > > > 4. I think a unique new term not already used in before is helpful because > > > what BIER-PE does is quite unique and new. And reusing an existing term > > > always brings out more people wanting to argue about the accuracy of how > > > their pre-existing term is applied. > > > > > > I hope we can have a deterministic, short latency decision mechanism for > > > the term. After we've decided on the term, its easy to update the doc > > > again with that new term (%s/PE/XXX/g). > > > > > > I'll throw "Tree Steering Bitstrings" (BIER-TSB) into the ring. > > > > > > [The main issue with name change now is that we've gotten some followup > > > work such as YANG model that also refers to BIER-TE meaning BIER-PE, so > > > that would also need to change name. See below for my reply to that naming > > > change you said you suggested .] > > > > > > 5. I also refined the section 1.1 that was introduced in -06 to mention > > > e.g.: PCE. > > > > > > Specific answers to the mail thread below. > > > > > > Cheers > > > Toerless > > > > > > On Fri, Feb 21, 2020 at 03:01:51PM -0500, Lou Berger wrote: > > > > > [ Would have been nice if you could have commented a bit earlier. > > > > > But i can understand how a few years is not enough time ;-P > > > > > (actually no kidding, i really can.) ] > > > > I raised this as an issue last march - at both the Chair and AD level..  I > > > > thought I made the same point to you privately after one the presentations > > > > at IETF101, but if you don't remember it, I accept that I didn't. > > > Did you include the authors ? I could not find any email about this. > > > Also no forwarded emails from AD/chairs i could find. If you still have > > > a copy, pls. PM. This is annoying... > > > > > > I do not remember naming issue discussed after IETF101, but i am > > > sure i was preoccupied with technical issues and might not have > > > given it too much thought back then. Of course there was a lot of > > > time since IETF101 to bring up the naming point again... > > > > > > > Well that document seems like a fine place to describe how BIER-RP (routing > > > > policy) can be used to deliver BIER-TE. > > > > > > > [...] > > > > Do we really need a new term to describe here?  I find zero (0) instances of > > > > Path Engineering in any RFC.  Routing policy (and policy-based routing) on > > > > the other hand are fairly well established terms in the industry.  I think > > > > this just sows seeds for future confusion on this topic. > > > > > > > > Why is "routing policy" not good enough for what is being defining here?  I > > > > again point out, this is the term being used in SPRING for basically the > > > > equivalent function/purpose. (Yes the forwarding mechanism is different, but > > > > the objective is not.) > > > SPRING did establish new unique name/terminologies, like "Segment". > > > As said above, i think its best we do the samegiven how unique this is. > > > > > > Looking at rfc8402, "steering" and "policy" are used in verbal > > > explanations, without providing specific terminology for them, > > > so i did follow that example too. > > > > > > > > but kept name BIER-TE (see below). > > > > > > > > > > - Added section 1.1 explaining how BIER-TE relates to traffic > > > > > engineering, naming use-cases where its for example beneficial standalone and > > > > > and what it could be combined with for more comprehensive TE solutions, > > > > > but also stating that those integrations are outside the scope of this > > > > > document. > > > > So this section seems to miss what has been going on in traffic engineering > > > > / TEAS for the last 5+ years (i.e., controller-based TE approaches) > > > I don't think that is a correct assessment. BIER-PE itself requires a > > > controller to calculate paths / trees. With or without other traffic > > > engineering components. That component is called the BIER-PE controller and > > > has been in the draft forever. > > > > > > The new section 1.1 added in response to your review relates that > > > BIER-TE controller to an overall TE controller, using the PCE example > > > and refrerence to it. > > > > > > There is really nothing more that a BIER-WG document could or should > > > do. What this document intended to support is whats necessary and > > > sufficient to get the forwarding plane implemented/standardized. > > > Everything else is for independent followup work in TEAS IMHO, > > > such as reviving the framwork draft. > > > > > > >   and then goes on describe path steering  in a very brief way.  I read this as > > > > saying that BIER *could* do TE in the future and *can* support routing > > > > policy and path steering today. > > > Even stronger: BIER-PE is always meant to ONLY do that (steering), > > > any additional TE functions wold come from independent other components. > > > And simple examples for that are given in section 1.1. > > > > > > > > - changed "traffic engineering" term in the whole doc to "path engineering", > > > > > where appropriate. > > > > While this is appreciated, I'm not sure it's helpful.  As stated above, I > > > > think the introduction of the new PE term is confusing as the continued use > > > > of BIER-TE. > > > See above. We can certainly not use "BIER-TE" to mean two different > > > things, so i hope that concern is resolved. > > > > > > > > The mayority of customers i talked to only used RSVP-TE for path > > > > > engineering, and not for anything more. Several didn't even know it > > > > > can do bandwidth reservation. Nobody knew it could do latency > > > > > guarantees, because nobody knows an implementation that supports that. > > > > > [All reasons btw. why replacing RSVP-TE with SR happened in the industry.] > > > > While I'm going to avoid getting into product differentiators and marketing, > > > > you're not mentioning that even those products and customers who didn't > > > > support/use per LSP queuing, did available resource bookkeeping and even > > > > admission control. > > > I think the point is mood now (given how we'll change the name BIER-TE > > > to a better term). But maybe to better explain: We started calling this > > > TE so customers would easier understand that this is intended to give > > > them what they actually use RSVP-TE for (Traffic Steering), and not > > > necessarily all that RSVP-TE could do beyond that. A central controller > > > is assumed to exist in BIER-PE too. > > > > > > Given how SR also shows how you can be successful in deployment > > > without betting on 'TE' name recognition, i have no quarrels in > > > changing the name. As said above, its motly a question of finding > > > the best term and changing the followup works names too. > > > > > > > > In any case, the name BIER-TE was selected to reduce confusion > > > > > with customers, not to maximize naming correctness in IETF. > > > > umm, the IETF is a standards body not an industry marketing forum, so I'm > > > > unclear how this point helps your argument. > > > It's not am argument or justification, just an explanation. Not only to you, > > > but also the WG. > > > > > > >  It seems that you're saying > > > > that if we call it BIER-TE we can market it in place of existing IETF TE > > > > solutions - even though it doesn't yet have the TE capability covered in > > > > draft-eckert-teas-bier-te-framework. > > > .... > > > > > > > Assuming I'm reading it right, this just confirms to me that the current > > > > work needs to be renamed and that draft-eckert-teas-bier-te-framework will > > > > define BIER-TE. > > > Yes. BIER-TE could btw. rely on BIER-PE or BIER + other path steering > > > (e.g.: flex-algos), so BIER-PE is only one option for the path-steering > > > options for BIER-TE. > > > > > > > My point wasn't that BIER=SR, but rather both deliver support for path > > > > steering and policy based routing. > > > Yepp, i hope we're in violent agreement. > > > > > > Cheers > > > Toerless > > > > > > > Thanks for being responsive! > > > > > > > > Lou > > > > > > > > > All the SR options do really require that you set up multicast trees with > > > > > e.g.: replication-SIDs that together form the equivalent of a > > > > > multicast tree, like you would have built with RSVP-TE. Except that > > > > > the signaling how to build the tree is left for someone else, like > > > > > PCECC. (AFAIK, i may not be on top of all details). In BIER-TE, > > > > > there is no such per-tree state on transit nodes. > > > > > > > > > > Instead of a 256 bit bitstring in BIER-TE think of a header with up to 256 SIDs > > > > > (e.g.: 128 bit per SID in SRv6). That would be the SR equivalent of BIER-TE. > > > > > Just a bit less ( ;-) ) less efficient on the wire than BIER-TE and extremely > > > > > harder to parse. > > > > > > > > > > Cheers > > > > > Toerless > > > > > > > > > > > > > > > On Wed, Feb 19, 2020 at 06:38:38PM -0500, Lou Berger wrote: > > > > > > Hi, > > > > > > > > > > > >     I have no issue or objection to the mechanisms being defined in this > > > > > > document as much as they go, but I was quite disappointed that despite the > > > > > > name of the document and use of 'bier-te'  to see that the document doesn't > > > > > > define any traffic engineering support, at least as far as the term has been > > > > > > used in IETF RFCs.  In particular it totally lacks any discussion of > > > > > > resources usage and/or allocation.  What it currently describes certainly > > > > > > provides good and useful path/traffic steering that can be used to support > > > > > > policy-based routing.  Basically it does the same as what is defined by > > > > > > draft-ietf-spring-segment-routing-policy. > > > > > > > > > > > > I personally (not speaking for the related WGs that I chair) would prefer to > > > > > > see this document be revised  to include resource allocation that would > > > > > > allow BIER-TE to support TE usage such as DetNet.  Barring such an addition, > > > > > > I'm against publication of this document as is and I think the document > > > > > > should be recast and renamed to be aligned with the SR example, i..e., BIER > > > > > > routing policy (or path steering). > > > > > > > > > > > > Lou > > > > > > > > > > > > On 2/18/20 3:45 PM, Greg Shepherd wrote: > > > > > > > Thanks Toerless and Jeffrey > > > > > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbier-2Dte-2Darch_&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=jH9x7gacv335Qdcq_btgUNtO3-TQxwLspmfVzbCC9Oo&e= > > > > > > > > > > > > > > One more week of WGLC. Please read the latest rev and respond to this > > > > > > > thread w/wo support. > > > > > > > > > > > > > > Chairs > > > > > > > (Shep) > > > > > > > > > > > > > > > > > > > > > On Tue, Feb 18, 2020 at 12:07 PM Jeffrey (Zhaohui) Zhang > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > Hi Toerless, > > > > > > > > > > > > > > Thanks! > > > > > > > I support moving this to the next stage. > > > > > > > > > > > > > > Jeffrey > > > > > > > > > > > > > > On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote: > > > > > > > > Thanks Jeff > > > > > > > > > > > > > > > > I have now pushed out -05 with the answers and hopefully > > > > > > > resolution to > > > > > > > > your points in email below.  Biggest addition was a section about > > > > > > > > reuse of BPs (without DNR) which came out of the confusion i > > > > > > > think the > > > > > > > > reuse in the ECMP example raised. I was afraid so far to explan > > > > > > > that > > > > > > > > as it may not be easy to absorb and ultimately is stuff only > > > > > > > > controller developers need to understand, but hopefully useful. > > > > > > > > And then of course the summary of BP optimizatins you asked for > > > > > > > > > > > > > > > > Diff from last version i sent you: > > > > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: > > > > > > > > **Araw.githubusercontent.com > > > > > > > *toerless*bier-te-arch*master*draft-ietf-b > > > > > > > > ier-te-arch-05.1.txt&url2=http:**Atools.ietf.org > > > > > > > *id*draft-ietf-bier-te > > > > > > > > > > > > > > > -arch-05.txt__;Ly8vLy8vLy8vLy8!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzH > > > > > > > > OCr0fZkLPbgg3CPNu0PyrWsrFx41_jWX2At8V-$ > > > > > > > > > > > > > > > > full -04 -> 05 diff: > > > > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=http:* > > > > > > > > *Atools.ietf.org > > > > > > > *id*draft-ietf-bier-te-arch-04.txt&url2=http:**Atools. > > > > > > > > ietf.org > > > > > > > *id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk > > > > > > > > !VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx41_jWancpziv$ > > > > > > > > > > > > > > > > Comments inline below. > > > > > > > > > > > > > > > > Cheers > > > > > > > >     toerless > > > > > > > > > > > > > > > > On Mon, Oct 28, 2019 at 07:52:59PM +0000, Jeffrey (Zhaohui) > > > > > > > Zhang wrote: > > > > > > > > > I Thought u-turn is the most simple comparison leaf vs. > > > > > > > non-leaf BFR. > > > > > > > > > > > > > > > > > > Zzh> The text in the email is seriously misaligned. Looking at > > > > > > > the picture in the diff link, while you gave a U-turn example, > > > > > > > though even if BFER2 is not connected to BFR2  but only connected > > > > > > > to BFER1 (hence no U-turn), then BFER1 is still not a leaf BFER I > > > > > > > suppose. That's why I said the first sentence of the above > > > > > > > paragraph is enough to define Leaf BFER while the example itself > > > > > > > is actually not needed. > > > > > > > > > > > > > > > > Argh... ok, had to fix two words, BFIR->BFER and left-hand -> > > > > > > > right-hand: > > > > > > > > > > > > > > > > Consider how redundant disjoint traffic can reach BFER1/BFER2 in > > > > > > > above > > > > > > > > picture: When BFER1/BFER2 are Non-Leaf BFER as shown on the > > > > > > > right hand > > > > > > > > side, one traffic copy would be forwarded to BFER1 from BFR1, > > > > > > > but the > > > > > > > > other one could only reach BFER1 via BFER2, which makes BFER2 a > > > > > > > > non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forwarding > > > > > > > > traffic to BFER2 > > > > > > > > > > > > > > > > > Zzh> Additionally, in left part of the picture you added, if > > > > > > > some failure leads to BFR2 to be only reachable via BFER1, then > > > > > > > BFER1 is no longer a leaf BFER. > > > > > > > > > > > > > > > > Added sentence: > > > > > > > > > > > > > > > > Note that the BFER in the left hand picture are only > > > > > > > guaranteed to > > > > > > > > be leaf-BFR by fitting routing configuration that prohibits transit > > > > > > > > traffic to pass through a PE, which is commonly applied in these > > > > > > > > topologies. > > > > > > > > > > > > > > > > > I assume you don't reassign BPs when links go up and down. > > > > > > > > > > > > > > > > I didn't want to discuss that option in this document. Its > > > > > > > obviously > > > > > > > > perfectly feasible, but be yet a big amount of text (especially the > > > > > > > > considerations how to do this make-before-break. Future doc. > > > > > > > > > > > > > > > > > > but subsequent polarization example confuses me. It seems > > > > > > > that BP 0:6 is assigned to the routed adjacency BFR10 (which is > > > > > > > actually talked about in Section 4.8). > > > > > > > > > > > > > > > > > > Section 4.7 does not mention "routed" at all, so there are no > > > > > > > routed adjacencies at all used in 4.7. So i am not sure what you > > > > > > > are confused about. > > > > > > > > > > > > > > > > > > Zzh> "The BIFT of each BFR are only populated with BPs that > > > > > > > are adjacent to the BFR in the BIER-TE topology". > > > > > > > > > > > > > > > > Correct text from the introduction. Ok. > > > > > > > > > > > > > > > > > Zzh> Since the same 0:6 is in BIFTS of BFR1/BFR2/BFR3 (and I > > > > > > > suppose in BFR4~BFR9 as well even though not drawn), I assumed > > > > > > > it's for the "MP2P" routed adjacency to R10; though I then ruled > > > > > > > that out - but I don't know what 0:6 represent now on BFR1, BFR2, > > > > > > > and BFR3. > > > > > > > > > > > > > > > > Ah. Ok. I thought i could strip down the example to show only the > > > > > > > > adjacencies relevant to the following discusion, but seemingly this > > > > > > > > can introduce the confusion you have. > > > > > > > > > > > > > > > > So i completed the example with the BP assignment acoss all > > > > > > > nodes, but > > > > > > > > added text pointing to a new section further down to discuss the > > > > > > > > re-use of BP for which thi picture is also an example. > > > > > > > > > > > > > > > > (check out the diff, new reuse text to long to copy inline). > > > > > > > > > > > > > > > > > The whole purpose of the ECMP BPs is of course to save bits, > > > > > > > otherwise we'd give each link a separate BP, which would be 6 BP > > > > > > > to reach to BFR4...BFR7 from BFR1. > > > > > > > > > > > > > > > > > > Zzh> The trouble I am having is that the same 0:6 is assigned > > > > > > > to different things and it's present on all BFR1/BFR2/BFR3. It is > > > > > > > perhaps an intentional smart design but I have not wrapped my mind > > > > > > > around it. It's apparently different from the link bundle case, so > > > > > > > better separate it out and elaborate it (including the DNR flag > > > > > > > that might be needed here - If the packet arrives on BFR1 with > > > > > > > 0:6, would the BP reset when it is sent to BFR2/3)? > > > > > > > > > > > > > > > > Yes, there was the bug of reusing BP 0:6 across sequential BFR > > > > > > > along > > > > > > > > the path, but now the example correctly reuses separate BP at > > > > > > > > different stages of the paths (BP 0:6 on BFR1, BP 0:7 on > > > > > > > BFR2/BFR3) and so on. > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > 4.8.  Routed adjacencies > > > > > > > > > > > > > > > > > > > > If I understand it correctly, there is a BP assigned to > > > > > > > L1/L2/L3 > > > > > > > > > > respectively (p2p link), and then there are BPs assigned to > > > > > > > MP2P tunnels (routed adjacency from every BFR) to the L1/L2/L3 > > > > > > > interface addresses and loopback addresses on BFR2/3. > > > > > > > > > > > > > > > > > > Ok that wasn't quite the read i expected. Let me clarify the > > > > > > > text/picture: > > > > > > > > > > > > > > > > > >                    ............... > > > > > > > > >          ...BFR1--...           ...--L1-- BFR2... > > > > > > > > >                   ... .Routers. ....--L2--/ > > > > > > > > >          ...BFR4--...           ...------ BFR3... > > > > > > > > >                    ................         | > > > > > > > > >                                           LO > > > > > > > > >                     Network Area 1 > > > > > > > > > > > > > > > > > > Assume the requirement in the above picture is to explicitly > > > > > > > steer traffic flows that have arrived at BFR1 or BFR4 via a > > > > > > > shortest path in the routing underlay "network area 1" to one of > > > > > > > the following three next segments: (1) BFR2 via link L1, (2) BFR2 > > > > > > > via link L2, (3) via BFR3. > > > > > > > > > > > > > > > > > > To achieve this, both BFR1 and BFR4 are set up with a > > > > > > > forward_routed adjacency BitPosition towards an address of BFR2 on > > > > > > > link L1, another forward_routed BitPosition towards an address of > > > > > > > BFR2 on link L2 and a third forward_routed Bitposition towards a > > > > > > > node address LO of BFR3. > > > > > > > > > > > > > > > > > > Does this clear ip the confusion ? > > > > > > > > > > > > > > > > > > Zzh> The picture is badly misaligned. I'll wait till 4.7 > > > > > > > questions are cleared. > > > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > If BFR2/3 are also BFERs, then they additionally will have > > > > > > > BFER BPs. > > > > > > > > > > On BFR1/4, the BIFT entries for the MP2P BPs for the > > > > > > > L1/L2/L3/loopback interface addresses of BFR2/3 will use > > > > > > > forward_routed(interface/loopback address). For a packet to be > > > > > > > decapsulated on a BFER, there is a need for both the BFER BP and > > > > > > > another BP (p2p/lan/hub-spoke/routed-adjacency) in the packet (the > > > > > > > former is for decapsulation and the latter is for getting it there). > > > > > > > > > > > > > > > > > > This is not discussed in this section, but you are right - unless > > > > > > > > > BFR2 or BFR3 is a leaf BFR. In that case, it would just > > > > > > > leverage the one shared "leaf-BFR" BP, so they do not need a > > > > > > > per-BFER BP for local_decap(). > > > > > > > > > > > > > > > > > > Zzh> Right - shared leaf-BFR BP but still need that BP (the > > > > > > > key is that we need a BP to get packet to a BFER and then a BP for > > > > > > > decapsulation). > > > > > > > > > > > > > > > > You got it. > > > > > > > > > > > > > > > > > > If that???s the case, it???s worth point the above out. > > > > > > > > > > > > > > > > > > Hmm... The logic of BFER BPs is totally independent of the > > > > > > > logic of forward_routed adjacency, so i would worry that repeating > > > > > > > the explanation of BFER BPs would conflate the forward_routed > > > > > > > explanation. > > > > > > > > > > > > > > > > > > Zzh> It's just that this is a place where all kinds of BPs are > > > > > > > used so it's good to have a summary (could be a subsection 4.9). > > > > > > > > > > > > > > > > Yes, added such a summary. Pls. check. > > > > > > > > > > > > > > > > > > Actually, the reason that I thought this is MP2P is that 0:6 > > > > > > > is present on R1, R2, and R3 (and more I assume) in Figure 12, but > > > > > > > now I think it can???t be MP2P (so it is not correct to have 0:6 > > > > > > > present on those routers ??? only the p2p tunnel head/tail should > > > > > > > have the BP present in the BIFT). The reason is that if it were > > > > > > > MP2P, any router getting a copy will send it to the endpoint of > > > > > > > the routed adjacency, causing lots of duplicates. > > > > > > > > > > > > > > > > > > > > Am I getting this correct? > > > > > > > > > > > > > > > > > > I think you are still explaining from the misunderstsanding > > > > > > > that the ECMP explanations where about routed adjacencies. > > > > > > > > > > > > > > > > > > I have now expanded the somewhat terse text in the BIFT table > > > > > > > pictures, to make it clear that the ECMP is across multipe > > > > > > > forward_connected adjacencies in the examples. For example, first > > > > > > > BIFT picture: > > > > > > > > > > > > > > > > > >   BIFT entry in BFR1: > > > > > > > > > > > > > > > >  ------------------------------------------------------------------ > > > > > > > > >   | Index |  Adjacencies                  | > > > > > > > > > > > > > > > >  ================================================================== > > > > > > > > >   | 0:6   |  ECMP({forward_connected(L1, BFR2),                 | > > > > > > > > >   |       |        forward_connected(L2, BFR2),                 | > > > > > > > > >   |       |        forward_connected(L3, BFR2)}, seed) > > > > > > >      | > > > > > > > > > > > > > > > >  ------------------------------------------------------------------ > > > > > > > > > > > > > > > > > > Of course, an ECMP adjacency can be across any type of > > > > > > > adjacencies, but all the text/explanations used forward_connected, > > > > > > > and now the pictures show that explicitly. > > > > > > > > > > > > > > > > > > Zzh> I can understand the multi-link case, but the multi-hop > > > > > > > ECMP case (from BFR1 towards BFR10) is confusing me. It would help > > > > > > > to give an example how it can be used, WITHOUT worrying about > > > > > > > polarization. > > > > > > > > > > > > > > > > Please check -05 text that has the full set of BIFT listed now: > > > > > > > > > > > > > > > > There is  really nothing nothing unique in multi-hop ECMP for > > > > > > > BIER-TE > > > > > > > > that we do not also have in any other ECMP, except the > > > > > > > conclusion that > > > > > > > > we want to support fast HW hash mechanisms AND allow the > > > > > > > controller to > > > > > > > > set up non-polarized multi-hop ECMP AND be able to precalculate > > > > > > > paths. > > > > > > > > Hence the specification of ECMP adjacencies to have a controller > > > > > > > > configurable seed. > > > > > > > > > > > > > > > > Btw: The picture is maybe unnecessarily large because i've used > > > > > > > it for > > > > > > > > 20 years to explain the same polarization issue for unicast vs > > > > > > > > multicast, and for multicast only BFR10...BFR4 are relevant > > > > > > > (ECMP of > > > > > > > > the PIM/mLDP joins), whereas for unicast/BIER only > > > > > > > > BFR1...BFR7 are relevant. But being symmetric, the picture makes it > > > > > > > > clear its the same problem. > > > > > > > > > > > > > > > > > >    To inhibit looping in the face of such physical > > > > > > > misconfiguration, > > > > > > > > > >    only forward_connected adjacencies are permitted to have > > > > > > > DNR set, and > > > > > > > > > >    the link layer destination address of the adjacency > > > > > > > (e.g.  MAC > > > > > > > > > >    address) protects against closing the loop.  Link layers > > > > > > > without port > > > > > > > > > >    unique link layer addresses should not be used with the > > > > > > > DNR flag set. > > > > > > > > > > > > > > > > > > > > It???s not clear how link layer address helps? > > > > > > > > > > > > > > > > > > I have expanded this to > > > > > > > > > "link layer port unique unicast destination address" > > > > > > > > > > > > > > > > > > Aka: MPLS or ethernet have unique link layer destination > > > > > > > destination addresses (label or destination MAC). If you think > > > > > > > about incorrectly plugged HDLC links (such as old T1/T3/.... > > > > > > > links), they only have 2 generic addresses, if i remember 1 or 3 > > > > > > > in the HDLC frame. So when you misplug one of those p2p cables > > > > > > > wrong, the packets would be incrrectly received by the wrong > > > > > > > receiver node and then DNR could cause persistent loops only > > > > > > > solved by TTL. > > > > > > > > > > > > > > > > > > Zzh> "Consider in the ring picture that link L4 from BFR3 is > > > > > > > plugged into the L1 interface of BFRa" - still not sure how > > > > > > > label/mac helps here. I suppose the ring topology is > > > > > > > discovered/verified by the control plane and when the miscalling > > > > > > > happens then the ring will not include the BFR1/BFR2 part and BFR3 > > > > > > > will not have the DNR set? If ring discovery/varication is not > > > > > > > done then perhaps we should point out that RPF based on link layer > > > > > > > address is needed - the key is RPF (which needs unique link layer > > > > > > > address)? > > > > > > > > > > > > > > > > Forget RPF. BIER(-TE) has no RPF (issues). Its just like > > > > > > > unicast. RPF > > > > > > > > is just a problem for receiver originated joins like in > > > > > > > PIM/mLDP, but > > > > > > > > not unicast/bier(-te)/RSVP-TE. > > > > > > > > > > > > > > > > Forward_connected is just like a unicast subnet adjacency to a > > > > > > > direct > > > > > > > > neighbor: Interface and L2 addresss of the destination. > > > > > > > > > > > > > > > > The controller (could be a human) "assumes" a particular physicial > > > > > > > > topology, from telemetry/knowledge/whatever. It then calculates the > > > > > > > > desired BIER-TE topology and pushes it down. This topology is > > > > > > > meant to > > > > > > > > be loop free of course wrt to the configured adjacencies. > > > > > > > > In this BIER-TE topology, BFR3 will have a BP with the > > > > > > > > forward_connected(L4, MAC-of-BFR2) adjacency. > > > > > > > > > > > > > > > > If the cable connecting to L4 is miswired, then BFR3 would still > > > > > > > send > > > > > > > > the packets to the MAC address of BFR2, but given how the cable > > > > > > > > connects to some other node, these packets will be discarded by > > > > > > > that > > > > > > > > node. because they're just L2 unicast packets. > > > > > > > > > > > > > > > > I think this is equally true when we have normal BIER/MPLS enacp. > > > > > > > > Those packets too are addressed to the unicast MAC address of the > > > > > > > > neighbor. > > > > > > > > > > > > > > > > Now, if/when he controller recognizes that the physical topology > > > > > > > has > > > > > > > > changed, thats a completely different story and not addressed here. > > > > > > > > Given how we assumed this was a cabling mistake, the controller > > > > > > > would > > > > > > > > probably only complain about the miswiring to operations but be > > > > > > > happy > > > > > > > > that the forwarding plane just makes packets fail instead of > > > > > > > loop. If > > > > > > > > this was a planned change process, then it will be similarily > > > > > > > > convoluted as it would today be with rewiring cables in an > > > > > > > > SR-MPLS/SRv6 topology and updating SIDs. > > > > > > > > > > > > > > > > > > Because the forwarding is different from BIER forwarding > > > > > > > (because of [1] above), we might as well introduce an optimization > > > > > > > here ??? for each BIFT, calculate the F-BM of the BIFT itself (the > > > > > > > logical ???or??? of all the BPs presented in this BIFT) and then > > > > > > > use (packet->bitstring & BIFT.F-BM) as the input to > > > > > > > GetFirst/NextBitPosition(). That should skip many bits. > > > > > > > > > > > > > > > > > > Right. But i explicitly removed those optimizations (i had > > > > > > > them in older draft versions) because the whole idea of this > > > > > > > picture is solely the comparison with figure 4 of RFC8279. > > > > > > > > > > > > > > > > > > Zzh> I think it's worth point that optimization out; you can > > > > > > > mark it optional if you want to emphasize the similarity to BIER > > > > > > > forwarding, but since BIER forwarding does do the maskoff step, it > > > > > > > is very efficient while BIER-TE forwarding does not it the maskoff > > > > > > > step so this optimization is important. > > > > > > > > > > > > > > > > Ok. I simplified the text comparison BIER/BIER-TE wrt. to the FBM > > > > > > > > rules [1] and [2] and added following paragraph: > > > > > > > > > > > > > > > > In BIER, the order of BPs impacts the result of forwarding > > > > > > > because of [1]. > > > > > > > > In BIER-TE, forwarding is not impacted by the order of BPs. It is > > > > > > > > therefore possible to further optimize forwarding than in BIER. For > > > > > > > > example parallelizing forwarding across multiple FPE cores or > > > > > > > > distributed linecards does only need to examine an arbitrary > > > > > > > subset of > > > > > > > > BP and not evaluate the dependency between BPs. > > > > > > > > > > > > > > > > > >    The following pseudocode is comprehensive: > > > > > > > > > > > > > > > > > > > > The above sentence reads a bit strange (or lacks some segue). > > > > > > > > > > > > > > > > > > I hope not, but maybe best left to a native english speaker > > > > > > > (RFC-editor). > > > > > > > > > > > > > > > > > > The first (RFC8279) pseudocode was simplified. The second one > > > > > > > is comprehensive. If not comprehensive, whats a good opposite of > > > > > > > simplified ? > > > > > > > > > > > > > > > > > > Zzh> Perhaps "The above simplified pseudocode is elaborated > > > > > > > further as following"? > > > > > > > > > Zzh> Jeffrey > > > > > > > > > > > > > > > > Done. > > > > > > > > > > > > > > > > Thanks a lot. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > > > > > > > From: BIER [bier-bounces@ietf.org > > > > > > > > > > > > > >] > > > > > > > > > > on behalf of Toerless Eckert [tte@cs.fau.de > > > > > > > >] > > > > > > > > > > Sent: Tuesday, July 09, 2019 23:38 > > > > > > > > > > To: Mike McBride > > > > > > > > > > Cc: Greg Shepherd; BIER WG; Pascal Thubert (pthubert) > > > > > > > > > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch > > > > > > > > > > > > > > > > > > > > Thanks, Mike > > > > > > > > > > > > > > > > > > > > The authors also reviewed the document and concluded that it > > > > > > > was > > > > > > > > > > really hard to get into the document context because of too > > > > > > > many > > > > > > > > > > forward dependencies. We tried to fix this by adding two > > > > > > > hopefully > > > > > > > > > > good & basic examples into the Introduction section and > > > > > > > using them > > > > > > > > > > to also add a better definition of the term "BIER-TE > > > > > > > Topology" in the Introduction. > > > > > > > > > > Hopefully this makes readin the rest of te document smoother. > > > > > > > > > > > > > > > > > > > > Also improved text of Abstract and refined text compariing > > > > > > > BIER-TE with SR. > > > > > > > > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: > > > > > > > > > > **Atools.ietf.org > > > > > > > *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A > > > > > > > > > > tool > > > > > > > > > > s.ietf.org > > > > > > > *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R > > > > > > > > > > jC81 > > > > > > > > > > > > > > > > > c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV_eTUEh > > > > > > > > > > $ > > > > > > > > > > > > > > > > > > > > > > > > > > **Atools.ietf.org > > > > > > > *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A > > > > > > > > > > tool > > > > > > > > > > s.ietf.org > > > > > > > *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R > > > > > > > > > > jC81 > > > > > > > > > > > > > > > > > c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sNd1njcX > > > > > > > > > > $> > > > > > > > > > > > > > > > > > > > > Cheers > > > > > > > > > >     Toerless > > > > > > > > > > > > > > > > > > > > On Wed, Jun 26, 2019 at 10:39:36AM -0700, Mike McBride wrote: > > > > > > > > > > > How about three? I support. > > > > > > > > > > > mike > > > > > > > > > > > > > > > > > > > > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd > > > > > > > > > > > > > > > > > > > >> wrote: > > > > > > > > > > > > > > > > > > > > > > > > We cannot take two 'yes' votes and WG consensus. > > > > > > > > > > > > Please, read and respond. If you don't support, then > > > > > > > please vote as much publicly right here. > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Greg > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert > > > > > > > (pthubert) > > > > > > > > > > > > >> wrote: > > > > > > > > > > > >> > > > > > > > > > > > >> Support: > > > > > > > > > > > >> > > > > > > > > > > > >> I see great value in deterministic networks as well as > > > > > > > IOT (with RPL). > > > > > > > > > > > >> > > > > > > > > > > > >> All the best, > > > > > > > > > > > >> > > > > > > > > > > > >> Pascal > > > > > > > > > > > >> > > > > > > > > > > > >> > -----Original Message----- > > > > > > > > > > > >> > From: BIER > > > > > > > > > > > >> > > > > > > > > > > > > > >> On > > > > > > > > > > > >> > Behalf Of Toerless Eckert > > > > > > > > > > > >> > Sent: mardi 4 juin 2019 02:03 > > > > > > > > > > > >> > To: Greg Shepherd > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > >> > Cc: BIER WG > > > > > > >> > > > > > > > > > > > >> > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch > > > > > > > > > > > >> > > > > > > > > > > > > >> > +1 > > > > > > > > > > > >> > Obviously support as co-author. > > > > > > > > > > > >> > > > > > > > > > > > > >> > On Wed, May 29, 2019 at 12:41:26PM -0700, Greg > > > > > > > Shepherd wrote: > > > > > > > > > > > >> > > Please read and respond to this thread w/ or w/o > > > > > > > support. > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > https://urldefense.com/v3/__https://datatracker..ietf.org > > > > > > > > > > > >> > > /doc > > > > > > > > > > > >> > > > > > > > > > /draft-ietf-bier-te-arch/__;!8WoA6RjC81c!XvH4AAxfrDjFoK_s > > > > > > > > > > > >> > > ercw ZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV9eClBj$ > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > >> > > doc/ > > > > > > > > > > > >> > > > > > > > > > draft-ietf-bier-te-arch/__;!8WoA6RjC81c!UBTGvWWpMHyeiSanx > > > > > > > > > > > >> > > s6vI b_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sD40kmtH$> > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > Vote ends 5 June 2019. > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > Thanks, > > > > > > > > > > > >> > > Shep > > > > > > > > > > > >> > > (chairs) > > > > > > > > > > > >> > > > > > > > > > > > > >> > > _______________________________________________ > > > > > > > > > > > >> > > BIER mailing list > > > > > > > > > > > >> > > BIER@ietf.org > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/ > > > > > > > > > > > >> > > list > > > > > > > > > > > >> > > > > > > > > > info/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eE > > > > > > > > > > > >> > > NOs4 l_qdsXF0KwZD82cJLDFFNT2WVXWX$ > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > >> > > list > > > > > > > > > > > >> > > > > > > > > > info/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6b > > > > > > > > > > > >> > > oAAW 4nrqju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > > > > > > > > >> > > > > > > > > > > > > >> > _______________________________________________ > > > > > > > > > > > >> > BIER mailing list > > > > > > > > > > > >> > BIER@ietf.org > > > > > > > > > > > > > > > > > > > >> > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/li > > > > > > > > > > > >> > stin > > > > > > > > > > > >> > > > > > > > > fo/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4 > > > > > > > > > > > >> > l_qd > > > > > > > > > > > >> > sXF0KwZD82cJLDFFNT2WVXWX$ > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > stin > > > > > > > > > > > >> > > > > > > > > fo/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW > > > > > > > > > > > >> > 4nrq > > > > > > > > > > > >> > ju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > BIER mailing list > > > > > > > > > > > > BIER@ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listi > > > > > > > > > > > > nfo/ > > > > > > > > > > > > > > > > > > > bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsX > > > > > > > > > > > > F0Kw > > > > > > > > > > > > ZD82cJLDFFNT2WVXWX$ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > nfo/ > > > > > > > > > > > > > > > > > > > bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju > > > > > > > > > > > > 8UCL > > > > > > > > > > > > OgiuXc8Y_6sKn2KoAT$> > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > --- > > > > > > > > > > tte@cs.fau.de > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > BIER mailing list > > > > > > > > > > BIER@ietf.org > > > > > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ > > > > > > > > > > bier > > > > > > > > > > > > > > > > > __;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82 > > > > > > > > > > cJLD > > > > > > > > > > FFNT2WVXWX$ > > > > > > > > > > > > > > > > > > > > > > > > > > bier > > > > > > > > > > > > > > > > > __;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiu > > > > > > > > > > Xc8Y > > > > > > > > > > _6sKn2KoAT$> > > > > > > > > > > > > > > > > > > -- > > > > > > > > > --- > > > > > > > > > tte@cs.fau.de > > > > > > > > > > > > > > > > -- > > > > > > > > --- > > > > > > > > tte@cs.fau.de > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > BIER mailing list > > > > > > > > BIER@ietf.org > > > > > > > > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier > > > > > > > > > > > > > > > __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx4 > > > > > > > > 1_jWV3YUA6D$ > > > > > > > > > > > > > > -- > > > > > > > --- > > > > > > > tte@cs.fau.de > > > > > > > > > > > > > > _______________________________________________ > > > > > > > BIER mailing list > > > > > > > BIER@ietf.org > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=DrLodD0a2MFe60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e= > > > > > > > > > > > > > _______________________________________________ > > > > > > BIER mailing list > > > > > > BIER@ietf.org > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=DrLodD0a2MFe60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e= > > > > _______________________________________________ > > > > BIER mailing list > > > > BIER@ietf.org > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=DrLodD0a2MFe60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e= > > > _______________________________________________ > > > BIER mailing list > > > BIER@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=DrLodD0a2MFe60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e= > > > > > > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=DrLodD0a2MFe60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e= > > -- > --- > tte@cs.fau.de > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=DrLodD0a2MFe60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e= -- --- tte@cs.fau.de From nobody Thu Feb 27 12:40:50 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E443A0B93; Thu, 27 Feb 2020 12:40:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 7gfMdx4zBukz; Thu, 27 Feb 2020 12:40:45 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B5793A0BA9; Thu, 27 Feb 2020 12:40:44 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 8753D548005; Thu, 27 Feb 2020 21:40:38 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 7ADB4440040; Thu, 27 Feb 2020 21:40:38 +0100 (CET) Date: Thu, 27 Feb 2020 21:40:38 +0100 From: Toerless Eckert To: "bier@ietf.org" Cc: bier-chairs@ietf.org, bier-ads@ietf.org, Lou Berger , "BRUNGARD, DEBORAH A" Message-ID: <20200227204038.GB23965@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 20:40:48 -0000 Dear WG Please chime in with opinions about the following or any new name you like as the new name for BIER-TE. Timeout is deadline for submission of draft before IETF107, when i'll post an update. If you propose a new name try to avoid re-using abbreviations that may be misinterpreted. 5 = best name ever, ... 1 = lame name, no number assigned means 0 votes are just added up and maximum sum option wins. Explanations if you haven't followed thread at the end. BIER-PE - Path Engineering BIER-ET - Explicit Trees BIER-EET - Explicit Engineered Trees BIER-BET - Bit Engineered Trees BIER-BST - Bit Steered Trees BIER-TrE - Tree engineering BIER-ET - Engineered Trees BIER-ST - Steered Trees BIER-ASB - Adjacency Steering Bits (adjacencies are how bits in BIER-PE are defined) BIER-AB - Adjacency Bits BIER-SB - Steering Bits (overloads with "Source Block" - never heard) Thanks, Toerless Explanations: If you have read through the threads with Lou and Deborah, and my understanding is correct: Lou desired there to be a new name so BIER-TE the forwarding/steering mechanism (this document) is named differently from BIER-TE the larger framework utilizing TEAS/PCE definition (separate future draft). Lou did not like my "Path Engineering" proposal as the name in the last version of the doc and felt we should pick a name with Steering/routing-policy in it. I think usn only steering/routing would be misleading (confused with unicast approaches). Deborah pointed to avoiding confusions in the name with pre-established named (e.g.: "PE" meaning Provider Edge). Said we should finalize on the name before we as the WG should pass the document to IESG. And she asked chairs to extend last-call by one more week (unrelated). Hence timeout end of next week. From nobody Thu Feb 27 12:44:05 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9513A0B9F; Thu, 27 Feb 2020 12:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 lsb5lG3B-IFE; Thu, 27 Feb 2020 12:44:01 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99D533A0BA6; Thu, 27 Feb 2020 12:44:01 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 167E8548048; Thu, 27 Feb 2020 21:43:57 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 0F65A440040; Thu, 27 Feb 2020 21:43:57 +0100 (CET) Date: Thu, 27 Feb 2020 21:43:57 +0100 From: Toerless Eckert To: "bier@ietf.org" Cc: Lou Berger , bier-ads@ietf.org, "BRUNGARD, DEBORAH A" , bier-chairs@ietf.org Message-ID: <20200227204357.GA35999@faui48f.informatik.uni-erlangen.de> References: <20200227204038.GB23965@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200227204038.GB23965@faui48f.informatik.uni-erlangen.de> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 20:44:03 -0000 2 BIER-PE - Path Engineering 5 BIER-ET - Explicit Trees 3 BIER-EET - Explicit Engineered Trees 4 BIER-BET - Bit Engineered Trees 3 BIER-BST - Bit Steered Trees 2 BIER-TrE - Tree engineering 3 BIER-ET - Engineered Trees 2 BIER-ST - Steered Trees 2 BIER-ASB - Adjacency Steering Bits (adjacencies are how bits in BIER-PE are defined) BIER-AB - Adjacency Bits BIER-SB - Steering Bits (overloads with "Source Block" - never heard) I prefer Explixit Trees because it is indicative of what is signalled(trees), and it nicely doubles down as a name Bit Indexed Explicit Replication, Explixit Trees From nobody Thu Feb 27 13:37:34 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3283A0C7A for ; Thu, 27 Feb 2020 13:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 ju6c1y-5xTSF for ; Thu, 27 Feb 2020 13:37:27 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 B629E3A0C79 for ; Thu, 27 Feb 2020 13:37:27 -0800 (PST) Received: from pps.filterd (m0049297.ppops.net [127.0.0.1]) by m0049297.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 01RLVmcQ039665; Thu, 27 Feb 2020 16:37:09 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049297.ppops.net-00191d01. with ESMTP id 2yegmu9ppm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Feb 2020 16:37:08 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 01RLb6xK012481; Thu, 27 Feb 2020 16:37:07 -0500 Received: from zlp27130.vci.att.com (zlp27130.vci.att.com [135.66.87.38]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 01RLb4lo012418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 27 Feb 2020 16:37:04 -0500 Received: from zlp27130.vci.att.com (zlp27130.vci.att.com [127.0.0.1]) by zlp27130.vci.att.com (Service) with ESMTP id E700140169E8; Thu, 27 Feb 2020 21:37:03 +0000 (GMT) Received: from MISOUT7MSGHUBAC.ITServices.sbc.com (unknown [130.9.129.147]) by zlp27130.vci.att.com (Service) with ESMTPS id 6A67040169E5; Thu, 27 Feb 2020 21:37:03 +0000 (GMT) Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.48]) by MISOUT7MSGHUBAC.ITServices.sbc.com ([130.9.129.147]) with mapi id 14.03.0468.000; Thu, 27 Feb 2020 16:37:03 -0500 From: "BRUNGARD, DEBORAH A" To: Toerless Eckert CC: Lou Berger , "gjshep@gmail.com" , "bier@ietf.org" Thread-Topic: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK Thread-Index: AQHV53213EDGuluOYkqDU6m9Z5Dxz6gjyEEAgAKgGICABRpOAIABEmgAgABfvQCAAQP34IABHeSAgABT9kA= Date: Thu, 27 Feb 2020 21:37:02 +0000 Message-ID: References: <11ab30da-8701-b491-6162-5a69aa9d6965@labn.net> <20200220035620.GA42520@faui48f.informatik.uni-erlangen.de> <20200225015718.GC20521@faui48f.informatik.uni-erlangen.de> <20200226000206.GA31874@faui48f.informatik.uni-erlangen.de> <20200227083547.GA23965@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200227083547.GA23965@faui48f.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.239] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-27_07:2020-02-26, 2020-02-27 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 adultscore=0 spamscore=0 mlxlogscore=999 clxscore=1015 bulkscore=0 mlxscore=0 suspectscore=0 priorityscore=1501 phishscore=0 malwarescore=0 impostorscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002270143 Archived-At: Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 21:37:34 -0000 Toerless, A couple of high level comments: I've seen you mention 5-years lifetime of the draft a couple of times as ra= tionalization not to change. Publication is not based on lifetime of a draf= t. Authors/WG need to be open to change especially during WG last call (whe= n collaborating with other working groups in an Area and the document has n= ot been shared over "lifetime"), IETF Last Call (especially other Area Dire= ctorate reviews), and, of course, IESG review. As you have been an author m= any times, I think you are very familiar with the churn. I just want to rem= ind for the benefit of others as I've seen many new authors frustrated when= their document becomes a working group document and there is churn. It's always difficult to interpret personal comments over email - even thos= e meant with the best intention or to amuse. Best is to keep to technical d= iscussion. E.g. comments such as " but given those and other (below) realit= ies i hope it is not too rude for me to say that its perceived on my end a = bit more like selective hazing" and " to the mail you sopposedly sent" may = be interpreted very differently by the intended person or others on the mai= ling list than what you meant. As I was doing this email, I see you already= responded to Lou explaining. For me, "selective hazing" is a rather strong= reaction to someone commenting. We want to encourage folks to comment, not= discourage. And it's not to you, it's the document. We all have different = styles of writing, but on the lists, best is to keep it technical. On the document: As you say yourself, current abbreviations are overloaded. Which is why whe= n new ones are proposed, the preference is to not keep overloading (in this= case, "PE") if more accurate abbreviations can be identified. This documen= t is defining replication and forwarding based on a precalculated path. I w= as not questioning the use of the term "engineering" for something other th= an TE, I was questioning the naming of this BIER mechanism as "engineering"= . I haven't seen replication/forwarding referred to as "engineering". If yo= u and the working group think the best name is "engineering" - let it stand= for now. Most important for me (as AD for TEAS) was that you removed "TE" = as that was inaccurate. Again, just because it has been 5 years, now is the= time to improve, once a document is published, it is for a lifetime. I jus= t noted your email asking input on the naming - thanks - that's good - we c= an see what folks think. Your suggested revision for the sentence comparing with RSVP-TE is much bet= ter. I understand when you use the term controller, it is not necessarily a PCE.= What I was asking (especially as an operator) was to include in the abstra= ct and intro sentences on the difference of BIER and BIER-PE. This sentence= in section 1.3 "BIER-PE replaces in-network autonomous path calculation by= explicit paths calculated off-path by the BIER-PE Controller" would be ver= y helpful in understanding the technology earlier in the document. In the a= bstract, suggest a sentence "BIER-PE differs from BIER in the use of explic= it paths calculated off-path by a controller." A new comment - if you intend this mechanism to be supported by BIER hardwa= re (section 3.2) - you probably want to get support for this document to be= an update of RFC8279? Thanks, Deborah -----Original Message----- From: Toerless Eckert =20 Sent: Thursday, February 27, 2020 3:36 AM To: BRUNGARD, DEBORAH A Cc: Lou Berger ; gjshep@gmail.com; bier@ietf.org; Jeffrey= (Zhaohui) Zhang Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK Hi Deborah, inline On Wed, Feb 26, 2020 at 09:33:17PM +0000, BRUNGARD, DEBORAH A wrote: > Hi Toerless, >=20 > Your comment: > > > I would appreciate if you could try to partition your opinions into > > > things you think MUST be solved before passing the document to IESG (= for > > > IETF/IESG review) and those issues that could then be solved when it = is > > > in IETF/IESG review. For example, i think a final choice of name coul= d > > > be something that shouldn't block the document to take this step. > > > >=20 > Waiting for the IESG to "name" your technology will definitely result in = a much longer delay than sorting out in WG Last Call. Ack > You noted, you had presented an earlier version of this document in TEAS,= but it is at the time of WG Last Call (per the charter), the TEAS/MPLS/and= probably PCE, should have been notified (I included MPLS as you have multi= ple proposals on use of MPLS labels). I've contacted your BIER Chairs/AD to= extend at least a week the Last Call. Thanks. I hope that feedback would still have to go all go to BIER, and not to those other WG mailing lists, right ? Don't want to hunt feedback across many WG lists.=20 > On naming, as Lou noted, preference is to align terminology used in other= working groups - especially within the routing area. The RFC-editor also r= ecommends careful use of abbreviations - it is expected new abbreviations a= re added to a list: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.rfc-2Deditor.o= rg_materials_abbrev.expansion.txt&d=3DDwIDAw&c=3DLFYZ-o9_HUMeMTSQicvjIg&r= =3D6UhGpW9lwi9dM7jYlxXD8w&m=3DyX_6NAhGb01k0I5mGk47ecTvjnxrstlW9R1Vjdlxy_Y&s= =3DMqqVe6A0srzY2l9XMurr7U__uZcGjMjqTWAw6bMDew8&e=3D=20 See below > As you can see, PE is already used. a) 461 out of 2651 abbreviations in that doc are overloaded. b) There is no indication that suffixes of a composite abbreviation have to= be unique. c) We would only want to use BIER-PE as an abbreviation, not PE alone. That is btw. why i changed all the occurances of "path engineering" in the text to explanatory "steering" or "policy" and only use BIER-PE as a= name. d) Of course i would get BIER-PE registered when being in RFC-editor state like i have done in the past in other RFCs. e) How about SR first meaning Source Routing and then being overloaded with Segment Routing ? And if Segment Routing was a valid new term (as it has more flexibility than Source Routing), why then not allow Path Engineering as a new term for us ? =20 e) SR in abbrv.expansion.txt: SR - sender report (SR) No "Source Routing", "Segment Routing", no SR-MPLS, No SRH from RFC6554, No consideration for disambiguating RFC6554 SRH from SRv6 SRH, ... NADA! (not even NADA/RFC8698) I know your and Lou's comments wrt. naming are well meaning, but given those and other (below) realities i hope it is not too rude for me to say that its perceived on my end a bit more like selective hazing. Can we please turn this around and you help us in actually selecting a good= name ? > And in the Routing Area, for our PE abbreviation, we could say it should = have an asterisk???? Sure, please talk with RFC editor to get it added to the doc. But asterix does not say anything about whether or not there is a conflict when reusing another abbreviation in a suffix of a longer name. Maybe when you get the asterisk, ask the RFC editor about that. There are no prior cases of this in the doc, so not possible to derive case law from the existing abbreviations. >Your justification is that "PE" is short similar to "TE", but for the Rout= ing Area, it needs to be either different or maybe add a letter (three lett= ers). If you look thru the list, that's what others have done e.g. in SPRIN= G, they have a new document also using "PE" differently but it's abbreviate= d "EPE". [ SPRING is the WG working on sender report (SR) ? (sorry, could not resis= t) ] draft-ietf-spring-segment-routing-central-epe - "Egres Peer Engineering" To me its primarily a good reference that other work is not contested when combining the word engineering with other words beside "Traffic" whereas this is contested when i am prosing to do it for the BIER work. > As we all enjoy trying to name "something", Not when the baby has a name for 5 years and that then gets contested. > I checked PCE documents (as you noted in the document, BIER-PE requires S= DN/PCE controller). BIER-PE does not require a PCE according to RFC 4655, RFC 4657. That is a highly desirable option when you want to use BIER-PE for Traffic Engineer= ing, but it is explicitly not scoped in this document so as to not encumber the document or constrain the applicability of its technology. The document has early on in section 2 the mandatory dependencies of BIER-PE, which includes the "BIER-PE Controller" as a concept as abstract as possible, and the document does explain what that BIER-TE controller needs to do without expecting any PCE arch TE definition . Such a BIER-PE controller could in one instance be an operator using CLI. I had another explanation in section 1.1 i added/proposed for Lou, stating how the "BIER-PE controller" would be a new function within a larger PCE if BIER-PE was used in a traffic engineering / PCE framework, but Lou said i should rather remove that section 1.1, which i did, so i think he is fine with waiting for the BIER-TE framework draft to define how the BIER-PE controller relates to a PCE. > As Lou says - there is no mention of "path engineering" either in PCE doc= uments or any IETF documents. So maybe "PE" in the string is not the best. There was also no mention in IETF or PCE documents of "Segment Routing" before it was invented, and SR likely meant something else, so what is the = point ? >My 2-cents, how about "SREP-BIER" (Source Routed Engineered Path)? See above on the SR confusion. Also note that the bigger common technology here is not 'source routing', but BIER, so that should be the pr= efix. Also, see below. > Have fun naming. See above.=20 > but please stabilize on a name before hand-off to the IESG - otherwise th= e IESG will have all the fun. What would really help the authors and the WG to finalize on a name=20 would be for you and Lou go beyond explaining what we should NOT choose as a name to what we are allowed to choose as names. Otherwise we could as well have the poor WG circle around this block multiple time. So please with sugar and whipped creme topping, let us know what will be permitted. Lou said we should re-use existing terms, i told him why using ONLY those would not well represent the unique novelty of BIER-PE but lead to confusion with unicast semantics (and besides: see SR and anybody else choosing new names for equal good reasons). BIER-PE is an easy compromise that i think makes everybody equally but only little unhappy. If not then then please comment on the following list which i hope would be=20 sufficiently broad for the WG to select a name from: BIER-ET - Explicit Trees BIER-EET - Explicit Engineered Trees BIER-BET - Bit Engineered Trees BIER-BST - Bit Steered Trees BIER-TrE - Tree engineering =20 BIER-ET - Engineered Trees BIER-ST - Steered Trees BIER-ASB - Adjacency Steering Bits (adjacencies are how bits in BIER-PE a= re defined) BIER-AB - Adjacency Bits =20 BIER-SB - Steering Bits (overloads with "Source Block" - never= heard) [ I prefer terms with Tree, because thats the unique distinction to paths, and highlight the multicast specific characteristic. ] > As BIER-PE requires use of an SDN/PCE controller - here's my early AD com= ments - please mention this earlier in the document - abstract, intro. e.g.= the SPRING document has as the title "centralized" EPE. I answered this alredy above. > "SR aims to enable lightweight path steering via loose source routing. Co= mpared to its more heavy-weight predecessor RSVP-TE, SR does for example no= t require per-path signaling to each of these hops." >=20 > RSVP-TE provides very different capabilities than SR and BIER. With RSVP-= TE glasses on, one could say SR and BIER provide very limited capabilities.= And both SR and BIER require very heavy-weight SDN controllers. So it jus= t depends where the operator/vendor wants to put their "weight".=20 > But it's not for IETF to do the judgement. > An RFC is not for marketing one technology vs. another. The goal of the text was not to make non-technical judgements about the ove= rall TE systems or to market SR, but simply to provide a technical explanation of the aspects of SR that relate to BIER-PE and relate that to RSVP-TE given how RSVP-TE/P2MP is also the equivalent alternative for BIER-PE: SR : RSVP-TE ~=3D BIER-TE : RSVP-TE/P2MP But: "predecessor" is an imprecise qualification. I just thought about the timeline, not the possible misinterpretation that SR would/could/should 1:1 superceed RSVP-TE. Also, the verbage of heavy=20 vs. lightweight is not correctly constrained to the technical point of comparison (on-transit-hop heavyness of path steering). I propose to change that sentence accordingly: "SR supports through the use of source-routing strict and loose hop path st= eering across transit hops that is lightweight on those transit hops becaus= e it does not require per-hop/per-flow signaling to and forwarding plane st= ate on those transit hops. In comparison, RSVP-TE and RSVP-TE/P2MP do requi= re such per-hop/per-flow transit-hop signaling and forwarding plane state " I think this is now technically precise and limited to the necessary comparison in this context. If you still have concerns, pls. let me know why, ideally with proposed text that would solve those concerns. I think it is important to explain the relevant technical aspects that where the core reasons for doing BIER-PE, especially in comparison to existing solutions. [ Btw: If memory serves me well, the whole PCE architecture was introduced = first by recognizing that you could not use RSVP-TE in situations with multi-headend resource contention without a central/coordinated PCE efficiently, and then implementations managed to build those PCE fairly lightweight into headend routers. Technically i would therefore disagree with your contentions that PCE need to be very heavy-weight and that RSVP wouldn't need them but only SR/BIER-PE. But definitely this BIER-PE document is not the place to have that argument. A later BIER-TE = framework document nevertheless would IMHO be more useful to adopters and operators if it had such technical description - without judgement and marketing, just the facts! ] > Hopefully my working groups (TEAS, MPLS, PCE) are given the "heads-up" so= on - I'd prefer discussion during working group last call vs. IETF Last Cal= l or my needing to enter a "Discuss" waiting for their review. I did see Lou sending mail to TEAS and DetNet and Lea to MPLS, did you send= to PCE ?.=20 I do of course welcome feedback from any group, but i am not worried about MPLS or PCE. There are no changes on the MPLS encap side, and as explained above, mapping BIER-PE into the PCE framework is also subject to followup work (like i think it was for SR as well). Thanks a lot.=20 Cheers Toerless > Thanks! > Deborah > (AD hat on) >=20 > -----Original Message----- > From: BIER On Behalf Of Toerless Eckert > Sent: Tuesday, February 25, 2020 7:02 PM > To: Lou Berger > Cc: gjshep@gmail.com; bier@ietf.org; Jeffrey (Zhaohui) Zhang > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK >=20 > Lou, *: >=20 > Here is the next and hopefully final github version for your review. > If you can give a thumbsup i will upload to datatracker, > and the WG chairs would also be able to finalize WG last-call. >=20 > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__raw.githubusercont= ent.com_toerless_bier-2Dte-2Darch_7e996deb1dcd18596d4864c750f6e7541d737e6f_= draft-2Dietf-2Dbier-2Dte-2Darch.txt&d=3DDwIFAw&c=3DLFYZ-o9_HUMeMTSQicvjIg&r= =3D6UhGpW9lwi9dM7jYlxXD8w&m=3DMW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s= =3DhbVUmt6ob-Ilgt00kiOlwAOcA68kldlxvO0Lqq-gKxo&e=3D=20 >=20 > And here the diff to -05, last version before taking input from your revi= ew into account. > Given how 1.1 was removed, this seems like the most logical comparison po= int. >=20 > https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__tools.ietf.org_tool= s_rfcdiff_rfcdiff.pyht-3Furl1-3Dhttps-3A__tools.ietf.org_id_draft-2Dietf-2D= bier-2Dte-2Darch-2D05.txt-26url2-3Dhttps-3A__raw.githubusercontent.com_toer= less_bier-2Dte-2Darch_7e996deb1dcd18596d4864c750f6e7541d737e6f_draft-2Dietf= -2Dbier-2Dte-2Darch.txt&d=3DDwIFAw&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3D6UhGpW9lw= i9dM7jYlxXD8w&m=3DMW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=3DjTvrGagqH= gPKneTUpOvNkeYcl7cxDSV32gLk--vyzdQ&e=3D=20 >=20 > Changes to -05 are now easily seen as limited textual: > - Name change BIER-TE to BIER-PE > - Explanations using steering/policy > - [RFC-editor remove note] about name change. > - BIER-TE controller host -> BIER-TE Controller (unrelated to Lou) >=20 > Detailled answers, explanations below. >=20 > Cheers > Toerless >=20 > On Tue, Feb 25, 2020 at 01:19:26PM -0500, Lou Berger wrote: > > Hi Toerless, > >=20 > > =A0=A0=A0 This revision will mostly remove my objection related to the = use of TE > > by the document.=A0 I suspect in section 7.2 you have two instances whe= re > > "traffic" needs to be replaced with "path". >=20 > Fixed >=20 > >=A0More substantively, I think you > > should delete section 1.1 and leave its subject=A0 matter=A0 to > > eckert-teas-bier-te-framework to be covered/worked out.=A0 If you want = to keep > > it, I think there's a longer discussion need on its contents. >=20 > Removed section 1.1 from the text. >=20 > I have added to the beginning of 1. an [RFC-editor: pls. remove ] section > explaining the naming change so late in the process to further IETF/IESG > reviewers (if i had just put it into the changelog i fear it will=20 > be overlooked by reviewers). >=20 > For what is worth, i did like the idea of having explanations=20 > about relationship of BIER-PE to BIER-TE, especially because the > framework is IMHO not yet in a state to serve as a good even draft > reference (it was only pointed to in section 1.1, so also removed > as reference). >=20 > How about this: If IESG review wants to have that type of explanation bac= k, > i'll knock on your door to revive and help me fix up that text. >=20 > > FWIW I still think the introduction of the a new term "Path Engineering= ", > > rather than reusing one of the existing IETF terms for the same capabil= ity > > ("routing policy", "policy based routing", "path steering") seems=A0 li= kely to > > lead to more confusion then if you stuck with an established term.=A0 I= 'll > > leave this to others to argue. >=20 > Ok, second time around you're suggesting this, i now owe you an explanati= on > why i think these terms are technically misleading: > (its a bit long, that why i avoided the explanation in before). >=20 > All the established terms you propose come from unicast and > never had a re-definition/re-interpretation for IP multicast. >=20 > Using any of these terms in the name would easily lead to > people (especially when not reading the doc) think the > BIER solution here works like in both IP multicast and > BIER in before BIER-PE: By impacting the underlying unicast > (forward) routing (BIER) or RPF (reverse path) routing (IP Multicast).=20 >=20 > Examples: You can use static muRIB routes to steer traffic for > IP Multicast or BIER. You can also use separate IGP (Flex-)topologies > to do the same dynamically. Thats all great stuff to describe in a > BIER-TE framework document (in conjunction with BIER), but that > is also the stuff i do not want BIER-PE to be confused with > because there are technical limitations to those unicast routing policy/ > steering approaches when its applied to trees: >=20 > Try to use any of the pre-existing mechanisms for unicast routing policy > or path steering with BIER or IP multicast to build steiner trees. > Not generally possible. With BIER-PE, no problem. Same thing with > disjoint trees (even MRT flex-algo's wouldn't achieve the same). >=20 > IMHO, the term "Path Engineering" is free of this mis-name-recognition > because it is a new. The name also hints at the fact that this could be > in support of, or a component of traffic engineering.=20 > And wrt to minimizing the change to the long held name, > the hamming distance is just one character/word. So it's the > 'safest/most-conservative/logical' name change this late in the > process. >=20 > As i said, i would be happier with a more unique new descriptive > name like "Tree Steering Bitstrings" (BIER-TSB), but i do not feel > like making such a big naming change without more explicit support > by more members of the WG this late in the process.=20 >=20 > > I think this covers all the detailed discussion points below. If not, c= an > > you extract the ones you'd like to keep discussing? >=20 > Still sad about the missed opportunity of fixing this naming=20 > problem earlier wrt. to the mail you sopposedly sent, and > happy to beat myself up if that ended up being my fault, but > i guess i shouldn't continue to dig into that issue if it would > turn out to be someone else's fault. >=20 > Otherwise i am fine. >=20 > If you want to give the doc now a thumbs up in response to the last > call, that would be great ;-) >=20 > EOF >=20 > > Thanks again for the responsiveness to my comments! > >=20 > > Lou > >=20 > > On 2/24/2020 8:57 PM, Toerless Eckert wrote: > > > Hi Lou, round 2. > > >=20 > > > Here is the github pre-version of -07 of the draft: > > >=20 > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__raw.githubuser= content.com_toerless_bier-2Dte-2Darch_62378f618299307349a934fc6ad78e1af9e16= 771_draft-2Dietf-2Dbier-2Dte-2Darch.txt&d=3DDwIFAw&c=3DLFYZ-o9_HUMeMTSQicvj= Ig&r=3D6UhGpW9lwi9dM7jYlxXD8w&m=3DMW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP= 0o&s=3DijbHbeNowm8uYigeF3tPQBOSrFL5chyoxfjBXyDOxPg&e=3D=20 > > >=20 > > > Diff: > > >=20 > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__tools.ietf.org_= tools_rfcdiff_rfcdiff.pyht-3Furl1-3Dhttps-3A__tools.ietf.org_id_draft-2Diet= f-2Dbier-2Dte-2Darch-2D06.txt-26url2-3Dhttps-3A__raw.githubusercontent.com_= toerless_bier-2Dte-2Darch_62378f618299307349a934fc6ad78e1af9e16771_draft-2D= ietf-2Dbier-2Dte-2Darch.txt&d=3DDwIFAw&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3D6UhGp= W9lwi9dM7jYlxXD8w&m=3DMW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=3DVMWxC= E2IzT007rczFZWwh1CEB3xG48xOj5RifpjIt5s&e=3D=20 > > >=20 > > > I would appreciate if you could try to partition your opinions into > > > things you think MUST be solved before passing the document to IESG (= for > > > IETF/IESG review) and those issues that could then be solved when it = is > > > in IETF/IESG review. For example, i think a final choice of name coul= d > > > be something that shouldn't block the document to take this step. > > >=20 > > > If this goes along into IETF107, it would be great if you could find = the > > > time to be at the BIER-WG meeting. > > >=20 > > > Summary of changes: > > >=20 > > > 1. Changed abbreviation BIER-TE to BIER-PE, otherwise we can not unco= nfuse > > > readers of the difference between BIER-PE and BIER-TE. > > >=20 > > > Relationship: BIER-TE =3D (BIER with steering: BIER-PE or othre) plus= resource > > > allocation mechanisms, and this document only describes BIER-PE. > > >=20 > > > 2. Removed all use of the term "path engineering" from the (explanato= ry) text, > > > replaced with path / tree steering or policy in the text (like RFC840= 2). > > >=20 > > > 3. In result, "Path Engineering" is now solely a name for the mechan= ism. > > > In the same way as SR introduced "Segment Routing" as a name, but exp= lains > > > what it does with the terms "steering" and "policy". > > >=20 > > > 4. I think a unique new term not already used in before is helpful be= cause > > > what BIER-PE does is quite unique and new. And reusing an existing te= rm > > > always brings out more people wanting to argue about the accuracy of = how > > > their pre-existing term is applied. > > >=20 > > > I hope we can have a deterministic, short latency decision mechanism = for > > > the term. After we've decided on the term, its easy to update the doc > > > again with that new term (%s/PE/XXX/g). > > >=20 > > > I'll throw "Tree Steering Bitstrings" (BIER-TSB) into the ring. > > >=20 > > > [The main issue with name change now is that we've gotten some follow= up > > > work such as YANG model that also refers to BIER-TE meaning BIER-PE, = so > > > that would also need to change name. See below for my reply to that n= aming > > > change you said you suggested .] > > >=20 > > > 5. I also refined the section 1.1 that was introduced in -06 to menti= on > > > e.g.: PCE. > > >=20 > > > Specific answers to the mail thread below. > > >=20 > > > Cheers > > > Toerless > > >=20 > > > On Fri, Feb 21, 2020 at 03:01:51PM -0500, Lou Berger wrote: > > > > > [ Would have been nice if you could have commented a bit earlier. > > > > > But i can understand how a few years is not enough time ;-P > > > > > (actually no kidding, i really can.) ] > > > > I raised this as an issue last march - at both the Chair and AD lev= el..=A0 I > > > > thought I made the same point to you privately after one the presen= tations > > > > at IETF101, but if you don't remember it, I accept that I didn't. > > > Did you include the authors ? I could not find any email about this. > > > Also no forwarded emails from AD/chairs i could find. If you still ha= ve > > > a copy, pls. PM. This is annoying... > > >=20 > > > I do not remember naming issue discussed after IETF101, but i am > > > sure i was preoccupied with technical issues and might not have > > > given it too much thought back then. Of course there was a lot of > > > time since IETF101 to bring up the naming point again... > > >=20 > > > > Well that document seems like a fine place to describe how BIER-RP = (routing > > > > policy) can be used to deliver BIER-TE. > > > >=20 > > > [...] > > > > Do we really need a new term to describe here?=A0 I find zero (0) i= nstances of > > > > Path Engineering in any RFC.=A0 Routing policy (and policy-based ro= uting) on > > > > the other hand are fairly well established terms in the industry.= =A0 I think > > > > this just sows seeds for future confusion on this topic. > > > >=20 > > > > Why is "routing policy" not good enough for what is being defining = here?=A0 I > > > > again point out, this is the term being used in SPRING for basicall= y the > > > > equivalent function/purpose. (Yes the forwarding mechanism is diffe= rent, but > > > > the objective is not.) > > > SPRING did establish new unique name/terminologies, like "Segment". > > > As said above, i think its best we do the samegiven how unique this i= s. > > >=20 > > > Looking at rfc8402, "steering" and "policy" are used in verbal > > > explanations, without providing specific terminology for them, > > > so i did follow that example too. > > >=20 > > > > > but kept name BIER-TE (see below). > > > > >=20 > > > > > - Added section 1.1 explaining how BIER-TE relates to traffic > > > > > engineering, naming use-cases where its for example beneficia= l standalone and > > > > > and what it could be combined with for more comprehensive TE = solutions, > > > > > but also stating that those integrations are outside the scop= e of this > > > > > document. > > > > So this section seems to miss what has been going on in traffic eng= ineering > > > > / TEAS for the last 5+ years (i.e., controller-based TE approaches) > > > I don't think that is a correct assessment. BIER-PE itself requires a > > > controller to calculate paths / trees. With or without other traffic > > > engineering components. That component is called the BIER-PE controll= er and > > > has been in the draft forever. > > >=20 > > > The new section 1.1 added in response to your review relates that > > > BIER-TE controller to an overall TE controller, using the PCE example > > > and refrerence to it. > > >=20 > > > There is really nothing more that a BIER-WG document could or should > > > do. What this document intended to support is whats necessary and > > > sufficient to get the forwarding plane implemented/standardized. > > > Everything else is for independent followup work in TEAS IMHO, > > > such as reviving the framwork draft. > > >=20 > > > > =A0 and then goes on describe path steering=A0 in a very brief way= .=A0 I read this as > > > > saying that BIER *could* do TE in the future and *can* support rout= ing > > > > policy and path steering today. > > > Even stronger: BIER-PE is always meant to ONLY do that (steering), > > > any additional TE functions wold come from independent other componen= ts. > > > And simple examples for that are given in section 1.1. > > >=20 > > > > > - changed "traffic engineering" term in the whole doc to "path en= gineering", > > > > > where appropriate. > > > > While this is appreciated, I'm not sure it's helpful.=A0 As stated = above, I > > > > think the introduction of the new PE term is confusing as the conti= nued use > > > > of BIER-TE. > > > See above. We can certainly not use "BIER-TE" to mean two different > > > things, so i hope that concern is resolved. > > >=20 > > > > > The mayority of customers i talked to only used RSVP-TE for path > > > > > engineering, and not for anything more. Several didn't even know = it > > > > > can do bandwidth reservation. Nobody knew it could do latency > > > > > guarantees, because nobody knows an implementation that supports = that. > > > > > [All reasons btw. why replacing RSVP-TE with SR happened in the i= ndustry.] > > > > While I'm going to avoid getting into product differentiators and m= arketing, > > > > you're not mentioning that even those products and customers who di= dn't > > > > support/use per LSP queuing, did available resource bookkeeping and= even > > > > admission control. > > > I think the point is mood now (given how we'll change the name BIER-T= E > > > to a better term). But maybe to better explain: We started calling th= is > > > TE so customers would easier understand that this is intended to give > > > them what they actually use RSVP-TE for (Traffic Steering), and not > > > necessarily all that RSVP-TE could do beyond that. A central controll= er > > > is assumed to exist in BIER-PE too. > > >=20 > > > Given how SR also shows how you can be successful in deployment > > > without betting on 'TE' name recognition, i have no quarrels in > > > changing the name. As said above, its motly a question of finding > > > the best term and changing the followup works names too. > > >=20 > > > > > In any case, the name BIER-TE was selected to reduce confusion > > > > > with customers, not to maximize naming correctness in IETF. > > > > umm, the IETF is a standards body not an industry marketing forum, = so I'm > > > > unclear how this point helps your argument. > > > It's not am argument or justification, just an explanation. Not only = to you, > > > but also the WG. > > >=20 > > > > =A0It seems that you're saying > > > > that if we call it BIER-TE we can market it in place of existing IE= TF TE > > > > solutions - even though it doesn't yet have the TE capability cover= ed in > > > > draft-eckert-teas-bier-te-framework. > > > .... > > >=20 > > > > Assuming I'm reading it right, this just confirms to me that the cu= rrent > > > > work needs to be renamed and that draft-eckert-teas-bier-te-framewo= rk will > > > > define BIER-TE. > > > Yes. BIER-TE could btw. rely on BIER-PE or BIER + other path steering > > > (e.g.: flex-algos), so BIER-PE is only one option for the path-steeri= ng > > > options for BIER-TE. > > >=20 > > > > My point wasn't that BIER=3DSR, but rather both deliver support for= path > > > > steering and policy based routing. > > > Yepp, i hope we're in violent agreement. > > >=20 > > > Cheers > > > Toerless > > >=20 > > > > Thanks for being responsive! > > > >=20 > > > > Lou > > > >=20 > > > > > All the SR options do really require that you set up multicast tr= ees with > > > > > e.g.: replication-SIDs that together form the equivalent of a > > > > > multicast tree, like you would have built with RSVP-TE. Except th= at > > > > > the signaling how to build the tree is left for someone else, lik= e > > > > > PCECC. (AFAIK, i may not be on top of all details). In BIER-TE, > > > > > there is no such per-tree state on transit nodes. > > > > >=20 > > > > > Instead of a 256 bit bitstring in BIER-TE think of a header with = up to 256 SIDs > > > > > (e.g.: 128 bit per SID in SRv6). That would be the SR equivalent = of BIER-TE. > > > > > Just a bit less ( ;-) ) less efficient on the wire than BIER-TE a= nd extremely > > > > > harder to parse. > > > > >=20 > > > > > Cheers > > > > > Toerless > > > > >=20 > > > > >=20 > > > > > On Wed, Feb 19, 2020 at 06:38:38PM -0500, Lou Berger wrote: > > > > > > Hi, > > > > > >=20 > > > > > > =A0=A0=A0 I have no issue or objection to the mechanisms bein= g defined in this > > > > > > document as much as they go, but I was quite disappointed that = despite the > > > > > > name of the document and use of 'bier-te'=A0 to see that the do= cument doesn't > > > > > > define any traffic engineering support, at least as far as the = term has been > > > > > > used in IETF RFCs.=A0 In particular it totally lacks any discus= sion of > > > > > > resources usage and/or allocation.=A0 What it currently describ= es certainly > > > > > > provides good and useful path/traffic steering that can be used= to support > > > > > > policy-based routing.=A0 Basically it does the same as what is = defined by > > > > > > draft-ietf-spring-segment-routing-policy. > > > > > >=20 > > > > > > I personally (not speaking for the related WGs that I chair) wo= uld prefer to > > > > > > see this document be revised=A0 to include resource allocation = that would > > > > > > allow BIER-TE to support TE usage such as DetNet.=A0 Barring su= ch an addition, > > > > > > I'm against publication of this document as is and I think the = document > > > > > > should be recast and renamed to be aligned with the SR example,= i..e., BIER > > > > > > routing policy (or path steering). > > > > > >=20 > > > > > > Lou > > > > > >=20 > > > > > > On 2/18/20 3:45 PM, Greg Shepherd wrote: > > > > > > > Thanks Toerless and Jeffrey > > > > > > >=20 > > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatr= acker.ietf.org_doc_draft-2Dietf-2Dbier-2Dte-2Darch_&d=3DDwIFAw&c=3DLFYZ-o9_= HUMeMTSQicvjIg&r=3D6UhGpW9lwi9dM7jYlxXD8w&m=3DMW3S0mvhNN9uq5VmjXdNXGwsisVP5= wzzO8r04h4aP0o&s=3DjH9x7gacv335Qdcq_btgUNtO3-TQxwLspmfVzbCC9Oo&e=3D=20 > > > > > > >=20 > > > > > > > One more week of WGLC. Please read the latest rev and respond= to this > > > > > > > thread w/wo support. > > > > > > >=20 > > > > > > > Chairs > > > > > > > (Shep) > > > > > > >=20 > > > > > > >=20 > > > > > > > On Tue, Feb 18, 2020 at 12:07 PM Jeffrey (Zhaohui) Zhang > > > > > > > > > > > > > > wrote: > > > > > > >=20 > > > > > > > Hi Toerless, > > > > > > >=20 > > > > > > > Thanks! > > > > > > > I support moving this to the next stage. > > > > > > >=20 > > > > > > > Jeffrey > > > > > > >=20 > > > > > > > On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Ecke= rt wrote: > > > > > > > > Thanks Jeff > > > > > > > > > > > > > > > > I have now pushed out -05 with the answers and hopefu= lly > > > > > > > resolution to > > > > > > > > your points in email below.=A0 Biggest addition was a= section about > > > > > > > > reuse of BPs (without DNR) which came out of the conf= usion i > > > > > > > think the > > > > > > > > reuse in the ECMP example raised. I was afraid so far= to explan > > > > > > > that > > > > > > > > as it may not be easy to absorb and ultimately is stu= ff only > > > > > > > > controller developers need to understand, but hopeful= ly useful. > > > > > > > > And then of course the summary of BP optimizatins you= asked for > > > > > > > > > > > > > > > > Diff from last version i sent you: > > > > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcd= iff?url1=3Dhttps: > > > > > > > > **Araw.githubusercontent.com > > > > > > > *toerless*bier-te-arch*master*d= raft-ietf-b > > > > > > > > ier-te-arch-05.1.txt&url2=3Dhttp:**Atools.ietf.org > > > > > > > *id*draft-ietf-bier-te > > > > > > > > > > > > > > > -arch-05.txt__;Ly8vLy8vLy8vLy8!!NEt6yMaO-gk!VuQCVHnqJy_= aYI-FNt9A1a5EzH > > > > > > > > OCr0fZkLPbgg3CPNu0PyrWsrFx41_jWX2At8V-$ > > > > > > > > > > > > > > > > full -04 -> 05 diff: > > > > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcd= iff?url1=3Dhttp:* > > > > > > > > *Atools.ietf.org > > > > > > > *id*draft-ietf-bier-te-arch-04.txt&url2=3D= http:**Atools. > > > > > > > > ietf.org > > > > > > > *id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v= !!NEt6yMaO-gk > > > > > > > > !VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx= 41_jWancpziv$ > > > > > > > > > > > > > > > > Comments inline below. > > > > > > > > > > > > > > > > Cheers > > > > > > > >=A0 =A0 =A0toerless > > > > > > > > > > > > > > > > On Mon, Oct 28, 2019 at 07:52:59PM +0000, Jeffrey (Zh= aohui) > > > > > > > Zhang wrote: > > > > > > > > > I Thought u-turn is the most simple comparison leaf= vs. > > > > > > > non-leaf BFR. > > > > > > > > > > > > > > > > > > Zzh> The text in the email is seriously misaligned.= Looking at > > > > > > > the picture in the diff link, while you gave a U-turn e= xample, > > > > > > > though even if BFER2 is not connected to BFR2=A0 but on= ly connected > > > > > > > to BFER1 (hence no U-turn), then BFER1 is still not a l= eaf BFER I > > > > > > > suppose. That's why I said the first sentence of the ab= ove > > > > > > > paragraph is enough to define Leaf BFER while the examp= le itself > > > > > > > is actually not needed. > > > > > > > > > > > > > > > > Argh... ok, had to fix two words, BFIR->BFER and left= -hand -> > > > > > > > right-hand: > > > > > > > > > > > > > > > > Consider how redundant disjoint traffic can reach BFE= R1/BFER2 in > > > > > > > above > > > > > > > > picture: When BFER1/BFER2 are Non-Leaf BFER as shown = on the > > > > > > > right hand > > > > > > > > side, one traffic copy would be forwarded to BFER1 fr= om BFR1, > > > > > > > but the > > > > > > > > other one could only reach BFER1 via BFER2, which mak= es BFER2 a > > > > > > > > non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when= forwarding > > > > > > > > traffic to BFER2 > > > > > > > > > > > > > > > > > Zzh> Additionally, in left part of the picture you = added, if > > > > > > > some failure leads to BFR2 to be only reachable via BFE= R1, then > > > > > > > BFER1 is no longer a leaf BFER. > > > > > > > > > > > > > > > > Added sentence: > > > > > > > > > > > > > > > > Note that the BFER in the left hand picture are on= ly > > > > > > > guaranteed to > > > > > > > > be leaf-BFR by fitting routing configuration that pro= hibits transit > > > > > > > > traffic to pass through a PE, which is commonly appli= ed in these > > > > > > > > topologies. > > > > > > > > > > > > > > > > > I assume you don't reassign BPs when links go up an= d down. > > > > > > > > > > > > > > > > I didn't want to discuss that option in this document= . Its > > > > > > > obviously > > > > > > > > perfectly feasible, but be yet a big amount of text (= especially the > > > > > > > > considerations how to do this make-before-break. Futu= re doc. > > > > > > > > > > > > > > > > > > but subsequent polarization example confuses me. = It seems > > > > > > > that BP 0:6 is assigned to the routed adjacency BFR10 (= which is > > > > > > > actually talked about in Section 4.8). > > > > > > > > > > > > > > > > > > Section 4.7 does not mention "routed" at all, so th= ere are no > > > > > > > routed adjacencies at all used in 4.7. So i am not sure= what you > > > > > > > are confused about. > > > > > > > > > > > > > > > > > > Zzh> "The BIFT of each BFR are only populated with = BPs that > > > > > > > are adjacent to the BFR in the BIER-TE topology". > > > > > > > > > > > > > > > > Correct text from the introduction. Ok. > > > > > > > > > > > > > > > > > Zzh> Since the same 0:6 is in BIFTS of BFR1/BFR2/BF= R3 (and I > > > > > > > suppose in BFR4~BFR9 as well even though not drawn), I = assumed > > > > > > > it's for the "MP2P" routed adjacency to R10; though I t= hen ruled > > > > > > > that out - but I don't know what 0:6 represent now on B= FR1, BFR2, > > > > > > > and BFR3. > > > > > > > > > > > > > > > > Ah. Ok. I thought i could strip down the example to s= how only the > > > > > > > > adjacencies relevant to the following discusion, but = seemingly this > > > > > > > > can introduce the confusion you have. > > > > > > > > > > > > > > > > So i completed the example with the BP assignment aco= ss all > > > > > > > nodes, but > > > > > > > > added text pointing to a new section further down to = discuss the > > > > > > > > re-use of BP for which thi picture is also an example= . > > > > > > > > > > > > > > > > (check out the diff, new reuse text to long to copy i= nline). > > > > > > > > > > > > > > > > > The whole purpose of the ECMP BPs is of course to s= ave bits, > > > > > > > otherwise we'd give each link a separate BP, which woul= d be 6 BP > > > > > > > to reach to BFR4...BFR7 from BFR1. > > > > > > > > > > > > > > > > > > Zzh> The trouble I am having is that the same 0:6 i= s assigned > > > > > > > to different things and it's present on all BFR1/BFR2/B= FR3. It is > > > > > > > perhaps an intentional smart design but I have not wrap= ped my mind > > > > > > > around it. It's apparently different from the link bund= le case, so > > > > > > > better separate it out and elaborate it (including the = DNR flag > > > > > > > that might be needed here - If the packet arrives on BF= R1 with > > > > > > > 0:6, would the BP reset when it is sent to BFR2/3)? > > > > > > > > > > > > > > > > Yes, there was the bug of reusing BP 0:6 across seque= ntial BFR > > > > > > > along > > > > > > > > the path, but now the example correctly reuses separa= te BP at > > > > > > > > different stages of the paths (BP 0:6 on BFR1, BP 0:7= on > > > > > > > BFR2/BFR3) and so on. > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > 4.8.=A0 Routed adjacencies > > > > > > > > > > > > > > > > > > > > If I understand it correctly, there is a BP assig= ned to > > > > > > > L1/L2/L3 > > > > > > > > > > respectively (p2p link), and then there are BPs a= ssigned to > > > > > > > MP2P tunnels (routed adjacency from every BFR) to the L= 1/L2/L3 > > > > > > > interface addresses and loopback addresses on BFR2/3. > > > > > > > > > > > > > > > > > > Ok that wasn't quite the read i expected. Let me cl= arify the > > > > > > > text/picture: > > > > > > > > > > > > > > > > > >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ............= ... > > > > > > > > >=A0 =A0 =A0 =A0 =A0 ...BFR1--...=A0 =A0 =A0 =A0 =A0 = =A0...--L1-- BFR2... > > > > > > > > >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0... .Routers.= ....--L2--/ > > > > > > > > >=A0 =A0 =A0 =A0 =A0 ...BFR4--...=A0 =A0 =A0 =A0 =A0 = =A0...------ BFR3... > > > > > > > > >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ............= ....=A0 =A0 =A0 =A0 =A0| > > > > > > > > >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0LO > > > > > > > > >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Network A= rea 1 > > > > > > > > > > > > > > > > > > Assume the requirement in the above picture is to e= xplicitly > > > > > > > steer traffic flows that have arrived at BFR1 or BFR4 v= ia a > > > > > > > shortest path in the routing underlay "network area 1" = to one of > > > > > > > the following three next segments: (1) BFR2 via link L1= , (2) BFR2 > > > > > > > via link L2, (3) via BFR3. > > > > > > > > > > > > > > > > > > To achieve this, both BFR1 and BFR4 are set up with= a > > > > > > > forward_routed adjacency BitPosition towards an address= of BFR2 on > > > > > > > link L1, another forward_routed BitPosition towards an = address of > > > > > > > BFR2 on link L2 and a third forward_routed Bitposition = towards a > > > > > > > node address LO of BFR3. > > > > > > > > > > > > > > > > > > Does this clear ip the confusion ? > > > > > > > > > > > > > > > > > > Zzh> The picture is badly misaligned. I'll wait til= l 4.7 > > > > > > > questions are cleared. > > > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > If BFR2/3 are also BFERs, then they additionally = will have > > > > > > > BFER BPs. > > > > > > > > > > On BFR1/4, the BIFT entries for the MP2P BPs for = the > > > > > > > L1/L2/L3/loopback interface addresses of BFR2/3 will us= e > > > > > > > forward_routed(interface/loopback address). For a packe= t to be > > > > > > > decapsulated on a BFER, there is a need for both the BF= ER BP and > > > > > > > another BP (p2p/lan/hub-spoke/routed-adjacency) in the = packet (the > > > > > > > former is for decapsulation and the latter is for getti= ng it there). > > > > > > > > > > > > > > > > > > This is not discussed in this section, but you are = right - unless > > > > > > > > > BFR2 or BFR3 is a leaf BFR. In that case, it would = just > > > > > > > leverage the one shared "leaf-BFR" BP, so they do not n= eed a > > > > > > > per-BFER BP for local_decap(). > > > > > > > > > > > > > > > > > > Zzh> Right - shared leaf-BFR BP but still need that= BP (the > > > > > > > key is that we need a BP to get packet to a BFER and th= en a BP for > > > > > > > decapsulation). > > > > > > > > > > > > > > > > You got it. > > > > > > > > > > > > > > > > > > If that???s the case, it???s worth point the abov= e out. > > > > > > > > > > > > > > > > > > Hmm... The logic of BFER BPs is totally independent= of the > > > > > > > logic of forward_routed adjacency, so i would worry tha= t repeating > > > > > > > the explanation of BFER BPs would conflate the forward_= routed > > > > > > > explanation. > > > > > > > > > > > > > > > > > > Zzh> It's just that this is a place where all kinds= of BPs are > > > > > > > used so it's good to have a summary (could be a subsect= ion 4.9). > > > > > > > > > > > > > > > > Yes, added such a summary. Pls. check. > > > > > > > > > > > > > > > > > > Actually, the reason that I thought this is MP2P = is that 0:6 > > > > > > > is present on R1, R2, and R3 (and more I assume) in Fig= ure 12, but > > > > > > > now I think it can???t be MP2P (so it is not correct to= have 0:6 > > > > > > > present on those routers ??? only the p2p tunnel head/t= ail should > > > > > > > have the BP present in the BIFT). The reason is that if= it were > > > > > > > MP2P, any router getting a copy will send it to the end= point of > > > > > > > the routed adjacency, causing lots of duplicates. > > > > > > > > > > > > > > > > > > > > Am I getting this correct? > > > > > > > > > > > > > > > > > > I think you are still explaining from the misunders= tsanding > > > > > > > that the ECMP explanations where about routed adjacenci= es. > > > > > > > > > > > > > > > > > > I have now expanded the somewhat terse text in the = BIFT table > > > > > > > pictures, to make it clear that the ECMP is across mult= ipe > > > > > > > forward_connected adjacencies in the examples. For exam= ple, first > > > > > > > BIFT picture: > > > > > > > > > > > > > > > > > >=A0 =A0BIFT entry in BFR1: > > > > > > > > > > > > > > > > =A0----------------------------------------------------= -------------- > > > > > > > > >=A0 =A0| Index |=A0 Adjacencies =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0| > > > > > > > > > > > > > > > > =A0=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > >=A0 =A0| 0:6=A0 =A0|=A0 ECMP({forward_connected(L1, = BFR2), =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > > > > > > > > >=A0 =A0|=A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 forward_conn= ected(L2, BFR2), =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > > > > > > > > >=A0 =A0|=A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 forward_conn= ected(L3, BFR2)}, seed) > > > > > > > =A0 =A0 =A0| > > > > > > > > > > > > > > > > =A0----------------------------------------------------= -------------- > > > > > > > > > > > > > > > > > > Of course, an ECMP adjacency can be across any type= of > > > > > > > adjacencies, but all the text/explanations used forward= _connected, > > > > > > > and now the pictures show that explicitly. > > > > > > > > > > > > > > > > > > Zzh> I can understand the multi-link case, but the = multi-hop > > > > > > > ECMP case (from BFR1 towards BFR10) is confusing me. It= would help > > > > > > > to give an example how it can be used, WITHOUT worrying= about > > > > > > > polarization. > > > > > > > > > > > > > > > > Please check -05 text that has the full set of BIFT l= isted now: > > > > > > > > > > > > > > > > There is=A0 really nothing nothing unique in multi-ho= p ECMP for > > > > > > > BIER-TE > > > > > > > > that we do not also have in any other ECMP, except th= e > > > > > > > conclusion that > > > > > > > > we want to support fast HW hash mechanisms AND allow = the > > > > > > > controller to > > > > > > > > set up non-polarized multi-hop ECMP AND be able to pr= ecalculate > > > > > > > paths. > > > > > > > > Hence the specification of ECMP adjacencies to have a= controller > > > > > > > > configurable seed. > > > > > > > > > > > > > > > > Btw: The picture is maybe unnecessarily large because= i've used > > > > > > > it for > > > > > > > > 20 years to explain the same polarization issue for u= nicast vs > > > > > > > > multicast, and for multicast only BFR10...BFR4 are re= levant > > > > > > > (ECMP of > > > > > > > > the PIM/mLDP joins), whereas for unicast/BIER only > > > > > > > > BFR1...BFR7 are relevant. But being symmetric, the pi= cture makes it > > > > > > > > clear its the same problem. > > > > > > > > > > > > > > > > > >=A0 =A0 To inhibit looping in the face of such phy= sical > > > > > > > misconfiguration, > > > > > > > > > >=A0 =A0 only forward_connected adjacencies are per= mitted to have > > > > > > > DNR set, and > > > > > > > > > >=A0 =A0 the link layer destination address of the = adjacency > > > > > > > (e.g.=A0 MAC > > > > > > > > > >=A0 =A0 address) protects against closing the loop= .=A0 Link layers > > > > > > > without port > > > > > > > > > >=A0 =A0 unique link layer addresses should not be = used with the > > > > > > > DNR flag set. > > > > > > > > > > > > > > > > > > > > It???s not clear how link layer address helps? > > > > > > > > > > > > > > > > > > I have expanded this to > > > > > > > > > "link layer port unique unicast destination address= " > > > > > > > > > > > > > > > > > > Aka: MPLS or ethernet have unique link layer destin= ation > > > > > > > destination addresses (label or destination MAC). If yo= u think > > > > > > > about incorrectly plugged HDLC links (such as old T1/T3= /.... > > > > > > > links), they only have 2 generic addresses, if i rememb= er 1 or 3 > > > > > > > in the HDLC frame. So when you misplug one of those p2p= cables > > > > > > > wrong, the packets would be incrrectly received by the = wrong > > > > > > > receiver node and then DNR could cause persistent loops= only > > > > > > > solved by TTL. > > > > > > > > > > > > > > > > > > Zzh> "Consider in the ring picture that link L4 fro= m BFR3 is > > > > > > > plugged into the L1 interface of BFRa" - still not sure= how > > > > > > > label/mac helps here. I suppose the ring topology is > > > > > > > discovered/verified by the control plane and when the m= iscalling > > > > > > > happens then the ring will not include the BFR1/BFR2 pa= rt and BFR3 > > > > > > > will not have the DNR set? If ring discovery/varication= is not > > > > > > > done then perhaps we should point out that RPF based on= link layer > > > > > > > address is needed - the key is RPF (which needs unique = link layer > > > > > > > address)? > > > > > > > > > > > > > > > > Forget RPF. BIER(-TE) has no RPF (issues). Its just l= ike > > > > > > > unicast. RPF > > > > > > > > is just a problem for receiver originated joins like = in > > > > > > > PIM/mLDP, but > > > > > > > > not unicast/bier(-te)/RSVP-TE. > > > > > > > > > > > > > > > > Forward_connected is just like a unicast subnet adjac= ency to a > > > > > > > direct > > > > > > > > neighbor: Interface and L2 addresss of the destinatio= n. > > > > > > > > > > > > > > > > The controller (could be a human) "assumes" a particu= lar physicial > > > > > > > > topology, from telemetry/knowledge/whatever. It then = calculates the > > > > > > > > desired BIER-TE topology and pushes it down. This top= ology is > > > > > > > meant to > > > > > > > > be loop free of course wrt to the configured adjacenc= ies. > > > > > > > > In this BIER-TE topology, BFR3 will have a BP with th= e > > > > > > > > forward_connected(L4, MAC-of-BFR2) adjacency. > > > > > > > > > > > > > > > > If the cable connecting to L4 is miswired, then BFR3 = would still > > > > > > > send > > > > > > > > the packets to the MAC address of BFR2, but given how= the cable > > > > > > > > connects to some other node, these packets will be di= scarded by > > > > > > > that > > > > > > > > node. because they're just L2 unicast packets. > > > > > > > > > > > > > > > > I think this is equally true when we have normal BIER= /MPLS enacp. > > > > > > > > Those packets too are addressed to the unicast MAC ad= dress of the > > > > > > > > neighbor. > > > > > > > > > > > > > > > > Now, if/when he controller recognizes that the physic= al topology > > > > > > > has > > > > > > > > changed, thats a completely different story and not a= ddressed here. > > > > > > > > Given how we assumed this was a cabling mistake, the = controller > > > > > > > would > > > > > > > > probably only complain about the miswiring to operati= ons but be > > > > > > > happy > > > > > > > > that the forwarding plane just makes packets fail ins= tead of > > > > > > > loop. If > > > > > > > > this was a planned change process, then it will be si= milarily > > > > > > > > convoluted as it would today be with rewiring cables = in an > > > > > > > > SR-MPLS/SRv6 topology and updating SIDs. > > > > > > > > > > > > > > > > > > Because the forwarding is different from BIER for= warding > > > > > > > (because of [1] above), we might as well introduce an o= ptimization > > > > > > > here ??? for each BIFT, calculate the F-BM of the BIFT = itself (the > > > > > > > logical ???or??? of all the BPs presented in this BIFT)= and then > > > > > > > use (packet->bitstring & BIFT.F-BM) as the input to > > > > > > > GetFirst/NextBitPosition(). That should skip many bits. > > > > > > > > > > > > > > > > > > Right. But i explicitly removed those optimizations= (i had > > > > > > > them in older draft versions) because the whole idea of= this > > > > > > > picture is solely the comparison with figure 4 of RFC82= 79. > > > > > > > > > > > > > > > > > > Zzh> I think it's worth point that optimization out= ; you can > > > > > > > mark it optional if you want to emphasize the similarit= y to BIER > > > > > > > forwarding, but since BIER forwarding does do the masko= ff step, it > > > > > > > is very efficient while BIER-TE forwarding does not it = the maskoff > > > > > > > step so this optimization is important. > > > > > > > > > > > > > > > > Ok. I simplified the text comparison BIER/BIER-TE wrt= . to the FBM > > > > > > > > rules [1] and [2] and added following paragraph: > > > > > > > > > > > > > > > > In BIER, the order of BPs impacts the result of fo= rwarding > > > > > > > because of [1]. > > > > > > > > In BIER-TE, forwarding is not impacted by the order o= f BPs. It is > > > > > > > > therefore possible to further optimize forwarding tha= n in BIER. For > > > > > > > > example parallelizing forwarding across multiple FPE = cores or > > > > > > > > distributed linecards does only need to examine an ar= bitrary > > > > > > > subset of > > > > > > > > BP and not evaluate the dependency between BPs. > > > > > > > > > > > > > > > > > >=A0 =A0 The following pseudocode is comprehensive: > > > > > > > > > > > > > > > > > > > > The above sentence reads a bit strange (or lacks = some segue). > > > > > > > > > > > > > > > > > > I hope not, but maybe best left to a native english= speaker > > > > > > > (RFC-editor). > > > > > > > > > > > > > > > > > > The first (RFC8279) pseudocode was simplified. The = second one > > > > > > > is comprehensive. If not comprehensive, whats a good op= posite of > > > > > > > simplified ? > > > > > > > > > > > > > > > > > > Zzh> Perhaps "The above simplified pseudocode is el= aborated > > > > > > > further as following"? > > > > > > > > > Zzh> Jeffrey > > > > > > > > > > > > > > > > Done. > > > > > > > > > > > > > > > > Thanks a lot. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > > > > > > > From: BIER [bier-bounces@ietf.org > > > > > > > > > > > > > >] > > > > > > > > > > on behalf of Toerless Eckert [tte@cs.fau.de > > > > > > > >] > > > > > > > > > > Sent: Tuesday, July 09, 2019 23:38 > > > > > > > > > > To: Mike McBride > > > > > > > > > > Cc: Greg Shepherd; BIER WG; Pascal Thubert (pthub= ert) > > > > > > > > > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arc= h > > > > > > > > > > > > > > > > > > > > Thanks, Mike > > > > > > > > > > > > > > > > > > > > The authors also reviewed the document and conclu= ded that it > > > > > > > was > > > > > > > > > > really hard to get into the document context beca= use of too > > > > > > > many > > > > > > > > > > forward dependencies. We tried to fix this by add= ing two > > > > > > > hopefully > > > > > > > > > > good & basic examples into the Introduction secti= on and > > > > > > > using them > > > > > > > > > > to also add a better definition of the term "BIER= -TE > > > > > > > Topology" in the Introduction. > > > > > > > > > > Hopefully this makes readin the rest of te docume= nt smoother. > > > > > > > > > > > > > > > > > > > > Also improved text of Abstract and refined text c= ompariing > > > > > > > BIER-TE with SR. > > > > > > > > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcd= iff?url1=3Dhttps: > > > > > > > > > > **Atools.ietf.org > > > > > > > *id*draft-ietf-bier-te-arch-02.txt&url2=3D= https:**A > > > > > > > > > > tool > > > > > > > > > > s.ietf.org > > > > > > > *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy= 8v!8WoA6R > > > > > > > > > > jC81 > > > > > > > > > > > > > > > > > c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82cJL= DFFNV_eTUEh > > > > > > > > > > $ > > > > > > > > > > > > > > > > > > > > > > > > > > **Atools.ietf.org > > > > > > > *id*draft-ietf-bier-te-arch-02.txt&url2=3D= https:**A > > > > > > > > > > tool > > > > > > > > > > s.ietf.org > > > > > > > *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy= 8v!8WoA6R > > > > > > > > > > jC81 > > > > > > > > > > > > > > > > > c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiuXc8= Y_6sNd1njcX > > > > > > > > > > $> > > > > > > > > > > > > > > > > > > > > Cheers > > > > > > > > > >=A0 =A0 =A0Toerless > > > > > > > > > > > > > > > > > > > > On Wed, Jun 26, 2019 at 10:39:36AM -0700, Mike Mc= Bride wrote: > > > > > > > > > > > How about three? I support. > > > > > > > > > > > mike > > > > > > > > > > > > > > > > > > > > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd > > > > > > > > > > > > > > > > > > > >> wrote: > > > > > > > > > > > > > > > > > > > > > > > > We cannot take two 'yes' votes and WG consens= us. > > > > > > > > > > > > Please, read and respond. If you don't suppor= t, then > > > > > > > please vote as much publicly right here. > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Greg > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thuber= t > > > > > > > (pthubert) > > > > > > > > > > > > >> wrote: > > > > > > > > > > > >> > > > > > > > > > > > >> Support: > > > > > > > > > > > >> > > > > > > > > > > > >> I see great value in deterministic networks = as well as > > > > > > > IOT (with RPL). > > > > > > > > > > > >> > > > > > > > > > > > >> All the best, > > > > > > > > > > > >> > > > > > > > > > > > >> Pascal > > > > > > > > > > > >> > > > > > > > > > > > >> > -----Original Message----- > > > > > > > > > > > >> > From: BIER > > > > > > > > > > > >> > > > > > > > > > > > > > >> On > > > > > > > > > > > >> > Behalf Of Toerless Eckert > > > > > > > > > > > >> > Sent: mardi 4 juin 2019 02:03 > > > > > > > > > > > >> > To: Greg Shepherd > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > > > >> > Cc: BIER WG > > > > > > >> > > > > > > > > > > > >> > Subject: Re: [Bier] WGLC - draft-ietf-bier= -te-arch > > > > > > > > > > > >> > > > > > > > > > > > > >> > +1 > > > > > > > > > > > >> > Obviously support as co-author. > > > > > > > > > > > >> > > > > > > > > > > > > >> > On Wed, May 29, 2019 at 12:41:26PM -0700, = Greg > > > > > > > Shepherd wrote: > > > > > > > > > > > >> > > Please read and respond to this thread w= / or w/o > > > > > > > support. > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > > > > > > > https://urldefense.com/v3/__https://datatracker..ietf.o= rg > > > > > > > > > > > >> > > /doc > > > > > > > > > > > >> > > > > > > > > > /draft-ietf-bier-te-arch/__;!8WoA6RjC81c!XvH4AAxfrDjFoK= _s > > > > > > > > > > > >> > > ercw ZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDF= FNV9eClBj$ > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > >> > > doc/ > > > > > > > > > > > >> > > > > > > > > > draft-ietf-bier-te-arch/__;!8WoA6RjC81c!UBTGvWWpMHyeiSa= nx > > > > > > > > > > > >> > > s6vI b_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6= sD40kmtH$> > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > Vote ends 5 June 2019. > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > Thanks, > > > > > > > > > > > >> > > Shep > > > > > > > > > > > >> > > (chairs) > > > > > > > > > > > >> > > > > > > > > > > > > >> > > ________________________________________= _______ > > > > > > > > > > > >> > > BIER mailing list > > > > > > > > > > > >> > > BIER@ietf.org > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailma= n/ > > > > > > > > > > > >> > > list > > > > > > > > > > > >> > > > > > > > > > info/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42= eE > > > > > > > > > > > >> > > NOs4 l_qdsXF0KwZD82cJLDFFNT2WVXWX$ > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > >> > > list > > > > > > > > > > > >> > > > > > > > > > info/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg= 6b > > > > > > > > > > > >> > > oAAW 4nrqju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > > > > > > > > >> > > > > > > > > > > > > >> > __________________________________________= _____ > > > > > > > > > > > >> > BIER mailing list > > > > > > > > > > > >> > BIER@ietf.org > > > > > > > > > > > > > > > > > > > >> > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailma= n/li > > > > > > > > > > > >> > stin > > > > > > > > > > > >> > > > > > > > > fo/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eE= NOs4 > > > > > > > > > > > >> > l_qd > > > > > > > > > > > >> > sXF0KwZD82cJLDFFNT2WVXWX$ > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > >> > stin > > > > > > > > > > > >> > > > > > > > > fo/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6b= oAAW > > > > > > > > > > > >> > 4nrq > > > > > > > > > > > >> > ju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > > > > > > > > > > > > > > > > > > > > > _____________________________________________= __ > > > > > > > > > > > > BIER mailing list > > > > > > > > > > > > BIER@ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailma= n/listi > > > > > > > > > > > > nfo/ > > > > > > > > > > > > > > > > > > > bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs= 4l_qdsX > > > > > > > > > > > > F0Kw > > > > > > > > > > > > ZD82cJLDFFNT2WVXWX$ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > nfo/ > > > > > > > > > > > > > > > > > > > bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAA= W4nrqju > > > > > > > > > > > > 8UCL > > > > > > > > > > > > OgiuXc8Y_6sKn2KoAT$> > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > --- > > > > > > > > > > tte@cs.fau.de > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > BIER mailing list > > > > > > > > > > BIER@ietf.org > > > > > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailma= n/listinfo/ > > > > > > > > > > bier > > > > > > > > > > > > > > > > > __;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_q= dsXF0KwZD82 > > > > > > > > > > cJLD > > > > > > > > > > FFNT2WVXWX$ > > > > > > > > > > > > > > > > > > > > > > > > > > bier > > > > > > > > > > > > > > > > > __;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nr= qju8UCLOgiu > > > > > > > > > > Xc8Y > > > > > > > > > > _6sKn2KoAT$> > > > > > > > > > > > > > > > > > > -- > > > > > > > > > --- > > > > > > > > > tte@cs.fau.de > > > > > > > > > > > > > > > > -- > > > > > > > > --- > > > > > > > > tte@cs.fau.de > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > BIER mailing list > > > > > > > > BIER@ietf.org > > > > > > > > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailma= n/listinfo/bier > > > > > > > > > > > > > > > __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg= 3CPNu0PyrWsrFx4 > > > > > > > > 1_jWV3YUA6D$ > > > > > > >=20 > > > > > > > -- > > > > > > > --- > > > > > > > tte@cs.fau.de > > > > > > >=20 > > > > > > > _______________________________________________ > > > > > > > BIER mailing list > > > > > > > BIER@ietf.org > > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__= www.ietf.org_mailman_listinfo_bier&d=3DDwIFAw&c=3DLFYZ-o9_HUMeMTSQicvjIg&r= =3D6UhGpW9lwi9dM7jYlxXD8w&m=3DMW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s= =3DDrLodD0a2MFe60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e=3D=20 > > > > > > >=20 > > > > > > _______________________________________________ > > > > > > BIER mailing list > > > > > > BIER@ietf.org > > > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_bier&d=3DDwIFAw&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3D6UhGpW= 9lwi9dM7jYlxXD8w&m=3DMW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=3DDrLodD= 0a2MFe60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e=3D=20 > > > > _______________________________________________ > > > > BIER mailing list > > > > BIER@ietf.org > > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org= _mailman_listinfo_bier&d=3DDwIFAw&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3D6UhGpW9lwi= 9dM7jYlxXD8w&m=3DMW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=3DDrLodD0a2M= Fe60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e=3D=20 > > > _______________________________________________ > > > BIER mailing list > > > BIER@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_m= ailman_listinfo_bier&d=3DDwIFAw&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3D6UhGpW9lwi9d= M7jYlxXD8w&m=3DMW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=3DDrLodD0a2MFe= 60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e=3D=20 > > >=20 > >=20 > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_bier&d=3DDwIFAw&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3D6UhGpW9lwi9dM7= jYlxXD8w&m=3DMW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=3DDrLodD0a2MFe60= a2_DECDeLJWLgxgqd65rAgnpk4u8M&e=3D=20 >=20 > --=20 > --- > tte@cs.fau.de >=20 > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_bier&d=3DDwIFAw&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3D6UhGpW9lwi9dM7jY= lxXD8w&m=3DMW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=3DDrLodD0a2MFe60a2= _DECDeLJWLgxgqd65rAgnpk4u8M&e=3D=20 --=20 --- tte@cs.fau.de From nobody Thu Feb 27 17:07:02 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A1B3A0B50 for ; Thu, 27 Feb 2020 17:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 0x_hcID0NFgl for ; Thu, 27 Feb 2020 17:06:46 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F62B3A0B3B for ; Thu, 27 Feb 2020 17:06:45 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 652E6548005; Fri, 28 Feb 2020 02:06:37 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 5EE38440040; Fri, 28 Feb 2020 02:06:37 +0100 (CET) Date: Fri, 28 Feb 2020 02:06:37 +0100 From: Toerless Eckert To: "BRUNGARD, DEBORAH A" Cc: "bier@ietf.org" , "gjshep@gmail.com" , Lou Berger Message-ID: <20200228010637.GB35999@faui48f.informatik.uni-erlangen.de> References: <11ab30da-8701-b491-6162-5a69aa9d6965@labn.net> <20200220035620.GA42520@faui48f.informatik.uni-erlangen.de> <20200225015718.GC20521@faui48f.informatik.uni-erlangen.de> <20200226000206.GA31874@faui48f.informatik.uni-erlangen.de> <20200227083547.GA23965@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 01:07:00 -0000 On Thu, Feb 27, 2020 at 09:37:02PM +0000, BRUNGARD, DEBORAH A wrote: > Toerless, > > A couple of high level comments: > > I've seen you mention 5-years lifetime of the draft a couple of times as rationalization not to change. Publication is not based on lifetime of a draft. Authors/WG need to be open to change especially during WG last call (when collaborating with other working groups in an Area and the document has not been shared over "lifetime"), IETF Last Call (especially other Area Directorate reviews), and, of course, IESG review. As you have been an author many times, I think you are very familiar with the churn. I just want to remind for the benefit of others as I've seen many new authors frustrated when their document becomes a working group document and there is churn. Completely agreed. I only mentioned the age in response to your claim that i would have fun and in combination that this is not a technical issue, and that it is annoying that this issue was "lost" (if that is the right word) for 2 years where it could have easily been addressed. That in combinations makes up for a very non-fun situation. > > It's always difficult to interpret personal comments over email - even those meant with the best intention or to amuse. Best is to keep to technical discussion. E.g. comments such as " but given those and other (below) realities i hope it is not too rude for me to say that its perceived on my end a bit more like selective hazing" and " to the mail you sopposedly sent" may be interpreted very differently by the intended person or others on the mailing list than what you meant. As I was doing this email, I see you already responded to Lou explaining. For me, "selective hazing" is a rather strong reaction to someone commenting. We want to encourage folks to comment, not discourage. And it's not to you, it's the document. We all have different styles of writing, but on the lists, best is to keep it technical. Completely agree on the non-discouragement and technical discussion. These specific (naming/abreviation) comments came from a 2xWG chair and an AD, where therefore (maybe mis-)perceived by me to be less comments but more expression of strong rules/reqiremens/process that i saw not equally being applied elsewhere, and when they started to look to me as as not being helping for the document technically anymore, that made me quite discouraged and hence the reply. I will remove "hazing" from my list of useful colloquialisms. Supposedly was the wrong word. I do believe that Lou sent the email. Personally i have been hit so many times with email delivery problems that i tried to factor that possibility into my sentence, but confused supposedly with presumably. I try to be verbally insensitive on the receiving side. E.g: I did not comment on you attributing my text "marketing" and "judgement", even though it sounded as if it could have been meant disparagingly (there are disparaging terms like "IMTF" going around for example). It did help me to improve the text and thats all that matters to me. > On the document: > > As you say yourself, current abbreviations are overloaded. Which is why when new ones are proposed, the preference is to not keep overloading (in this case, "PE") if more accurate abbreviations can be identified. This document is defining replication and forwarding based on a precalculated path. I was not questioning the use of the term "engineering" for something other than TE, I was questioning the naming of this BIER mechanism as "engineering".. I haven't seen replication/forwarding referred to as "engineering". If you and the working group think the best name is "engineering" - let it stand for now. Most important for me (as AD for TEAS) was that you removed "TE" as that was inaccurate. Again, just because it has been 5 years, now is the time to improve, once a document is published, it is for a lifetime. I just noted your email asking input on the naming - thanks - that's good - we can see what folks think. The 5 year discuss died in the previous paragraphs, no need to revive it. I immediately agreed to Lou's suggestion to change the name from TE because that was IMHO a sound ask. Even though i received in private suggestions not to go down this (perceived) rathole this late in the process. I pointed you to the fact that the ESE example you made is yet another one, where "engineering" is used in a context different to "Traffic". Even though i don't know what Peer Engineering means. But Engineering is always a good generic term for something convoluted/involved IMHO (where a simpler more specific term does not fit). How would you even characterize the components of Traffic Engineering ? To me i would tell a non-technical person its about the combination of path engineering, bandwidth reservations and buffer management (for latency). Aka: To me Traffic Engineering inherits the term engineering from what we do with paths plus managing the traffic (bandwidth, latency). Is there any better or even official explanation for the use of the word "Engineering" in TE ? > Your suggested revision for the sentence comparing with RSVP-TE is much better. Thanks. It actually helped to revisit that sentence because i forgot to include a sentence included mentioning of RSVP-TE/P2MP. Will include that too. > I understand when you use the term controller, it is not necessarily a PCE. What I was asking (especially as an operator) was to include in the abstract and intro sentences on the difference of BIER and BIER-PE. This sentence in section 1.3 "BIER-PE replaces in-network autonomous path calculation by explicit paths calculated off-path by the BIER-PE Controller" would be very helpful in understanding the technology earlier in the document. In the abstract, suggest a sentence "BIER-PE differs from BIER in the use of explicit paths calculated off-path by a controller." Thanks, i totally didn't get that from your first comment, suggested text always helps. Will add. > A new comment - if you intend this mechanism to be supported by BIER hardware (section 3.2) - you probably want to get support for this document to be an update of RFC8279? No, i don't think thats necessary or useful. Think for example if RSVP would have been defined for MPLS on the IGP/LDP shortest path, then RSVP-TE would still not have been (IMHO) an update to that RSVP/MPLS base spec, but an extension of the same framework / alternative. (the comparison may not be perfect but i hope it makes the point). Aka: You can continue to implement and use BIER without BIER-PE, and if you choose to also support BIER-TE, there are hopefully sufficiently well limited forwarding plane details that need to be supported in addition to what's required for BIER (at least for the basic subset of BIER-PE), that's why there are those forwarding plane comparisons. Cheers Toerless > Thanks, > Deborah > > > -----Original Message----- > From: Toerless Eckert > Sent: Thursday, February 27, 2020 3:36 AM > To: BRUNGARD, DEBORAH A > Cc: Lou Berger ; gjshep@gmail.com; bier@ietf.org; Jeffrey (Zhaohui) Zhang > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK > > > Hi Deborah, > > inline > > On Wed, Feb 26, 2020 at 09:33:17PM +0000, BRUNGARD, DEBORAH A wrote: > > Hi Toerless, > > > > Your comment: > > > > I would appreciate if you could try to partition your opinions into > > > > things you think MUST be solved before passing the document to IESG (for > > > > IETF/IESG review) and those issues that could then be solved when it is > > > > in IETF/IESG review. For example, i think a final choice of name could > > > > be something that shouldn't block the document to take this step. > > > > > > > > Waiting for the IESG to "name" your technology will definitely result in a much longer delay than sorting out in WG Last Call. > > Ack > > > You noted, you had presented an earlier version of this document in TEAS, but it is at the time of WG Last Call (per the charter), the TEAS/MPLS/and probably PCE, should have been notified (I included MPLS as you have multiple proposals on use of MPLS labels). I've contacted your BIER Chairs/AD to extend at least a week the Last Call. > > Thanks. I hope that feedback would still have to go all go to BIER, and > not to those other WG mailing lists, right ? Don't want to hunt feedback > across many WG lists. > > > On naming, as Lou noted, preference is to align terminology used in other working groups - especially within the routing area. The RFC-editor also recommends careful use of abbreviations - it is expected new abbreviations are added to a list: > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_materials_abbrev.expansion.txt&d=DwIDAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=yX_6NAhGb01k0I5mGk47ecTvjnxrstlW9R1Vjdlxy_Y&s=MqqVe6A0srzY2l9XMurr7U__uZcGjMjqTWAw6bMDew8&e= > > See below > > > As you can see, PE is already used. > > a) 461 out of 2651 abbreviations in that doc are overloaded. > > b) There is no indication that suffixes of a composite abbreviation have to be unique. > > c) We would only want to use BIER-PE as an abbreviation, not PE alone. > > That is btw. why i changed all the occurances of "path engineering" in > the text to explanatory "steering" or "policy" and only use BIER-PE as a name. > > d) Of course i would get BIER-PE registered when being in RFC-editor > state like i have done in the past in other RFCs. > > e) How about SR first meaning Source Routing and then being > overloaded with Segment Routing ? And if Segment Routing > was a valid new term (as it has more flexibility than > Source Routing), why then not allow Path Engineering as > a new term for us ? > > e) SR in abbrv.expansion.txt: > > SR - sender report (SR) > No "Source Routing", "Segment Routing", no SR-MPLS, > No SRH from RFC6554, No consideration for disambiguating > RFC6554 SRH from SRv6 SRH, ... NADA! (not even NADA/RFC8698) > > I know your and Lou's comments wrt. naming are well meaning, > but given those and other (below) realities i hope it is not too rude for > me to say that its perceived on my end a bit more like selective hazing. > > Can we please turn this around and you help us in actually selecting a good name ? > > > And in the Routing Area, for our PE abbreviation, we could say it should have an asterisk???? > > Sure, please talk with RFC editor to get it added to the doc. > > But asterix does not say anything about whether or not there > is a conflict when reusing another abbreviation in a suffix > of a longer name. Maybe when you get the asterisk, ask the RFC > editor about that. There are no prior cases of this in the > doc, so not possible to derive case law from the existing abbreviations. > > >Your justification is that "PE" is short similar to "TE", but for the Routing Area, it needs to be either different or maybe add a letter (three letters). If you look thru the list, that's what others have done e.g. in SPRING, they have a new document also using "PE" differently but it's abbreviated "EPE". > > [ SPRING is the WG working on sender report (SR) ? (sorry, could not resist) ] > > draft-ietf-spring-segment-routing-central-epe - "Egres Peer Engineering" > > To me its primarily a good reference that other work is not contested > when combining the word engineering with other words beside "Traffic" > whereas this is contested when i am prosing to do it for the BIER work. > > > As we all enjoy trying to name "something", > > Not when the baby has a name for 5 years and that then gets contested. > > > I checked PCE documents (as you noted in the document, BIER-PE requires SDN/PCE controller). > > BIER-PE does not require a PCE according to RFC 4655, RFC 4657. That is > a highly desirable option when you want to use BIER-PE for Traffic Engineering, > but it is explicitly not scoped in this document so as to not encumber > the document or constrain the applicability of its technology. > > The document has early on in section 2 the mandatory dependencies > of BIER-PE, which includes the "BIER-PE Controller" as a concept > as abstract as possible, and the document does explain what that > BIER-TE controller needs to do without expecting any PCE arch > TE definition . Such a BIER-PE controller could in one instance > be an operator using CLI. > > I had another explanation in section 1.1 i added/proposed for Lou, > stating how the "BIER-PE controller" would be a new function within > a larger PCE if BIER-PE was used in a traffic engineering / PCE > framework, but Lou said i should rather remove that section 1.1, > which i did, so i think he is fine with waiting for the BIER-TE > framework draft to define how the BIER-PE controller relates to a PCE. > > > As Lou says - there is no mention of "path engineering" either in PCE documents or any IETF documents. So maybe "PE" in the string is not the best. > > There was also no mention in IETF or PCE documents of "Segment Routing" > before it was invented, and SR likely meant something else, so what is the point ? > > >My 2-cents, how about "SREP-BIER" (Source Routed Engineered Path)? > > See above on the SR confusion. Also note that the bigger common > technology here is not 'source routing', but BIER, so that should be the prefix. > > Also, see below. > > > Have fun naming. > > See above. > > > but please stabilize on a name before hand-off to the IESG - otherwise the IESG will have all the fun. > > What would really help the authors and the WG to finalize on a name > would be for you and Lou go beyond explaining what we should NOT choose > as a name to what we are allowed to choose as names. Otherwise > we could as well have the poor WG circle around this block multiple time. > > So please with sugar and whipped creme topping, let us know > what will be permitted. Lou said we should re-use existing terms, > i told him why using ONLY those would not well represent the > unique novelty of BIER-PE but lead to confusion with unicast > semantics (and besides: see SR and anybody else choosing new names > for equal good reasons). > > BIER-PE is an easy compromise that i think makes everybody > equally but only little unhappy. If not then then please > comment on the following list which i hope would be > sufficiently broad for the WG to select a name from: > > BIER-ET - Explicit Trees > BIER-EET - Explicit Engineered Trees > BIER-BET - Bit Engineered Trees > BIER-BST - Bit Steered Trees > BIER-TrE - Tree engineering > BIER-ET - Engineered Trees > BIER-ST - Steered Trees > > BIER-ASB - Adjacency Steering Bits (adjacencies are how bits in BIER-PE are defined) > BIER-AB - Adjacency Bits > BIER-SB - Steering Bits (overloads with "Source Block" - never heard) > > [ I prefer terms with Tree, because thats the unique distinction > to paths, and highlight the multicast specific characteristic. ] > > > As BIER-PE requires use of an SDN/PCE controller - here's my early AD comments - please mention this earlier in the document - abstract, intro. e.g. the SPRING document has as the title "centralized" EPE. > > I answered this alredy above. > > > "SR aims to enable lightweight path steering via loose source routing. Compared to its more heavy-weight predecessor RSVP-TE, SR does for example not require per-path signaling to each of these hops." > > > > RSVP-TE provides very different capabilities than SR and BIER. With RSVP-TE glasses on, one could say SR and BIER provide very limited capabilities. And both SR and BIER require very heavy-weight SDN controllers. So it just depends where the operator/vendor wants to put their "weight". > > > But it's not for IETF to do the judgement. > > An RFC is not for marketing one technology vs. another. > > The goal of the text was not to make non-technical judgements about the overall TE > systems or to market SR, but simply to provide a technical explanation of > the aspects of SR that relate to BIER-PE and relate that to RSVP-TE given > how RSVP-TE/P2MP is also the equivalent alternative for BIER-PE: > > SR : RSVP-TE ~= BIER-TE : RSVP-TE/P2MP > > But: > "predecessor" is an imprecise qualification. I just thought > about the timeline, not the possible misinterpretation that SR > would/could/should 1:1 superceed RSVP-TE. Also, the verbage of heavy > vs. lightweight is not correctly constrained to the technical > point of comparison (on-transit-hop heavyness of path steering). > > I propose to change that sentence accordingly: > > "SR supports through the use of source-routing strict and loose hop path steering across transit hops that is lightweight on those transit hops because it does not require per-hop/per-flow signaling to and forwarding plane state on those transit hops. In comparison, RSVP-TE and RSVP-TE/P2MP do require such per-hop/per-flow transit-hop signaling and forwarding plane state " > > I think this is now technically precise and limited to the necessary > comparison in this context. If you still have concerns, > pls. let me know why, ideally with proposed text that would solve > those concerns. I think it is important to explain the > relevant technical aspects that where the core reasons for doing > BIER-PE, especially in comparison to existing solutions. > > [ Btw: If memory serves me well, the whole PCE architecture was introduced first > by recognizing that you could not use RSVP-TE in situations with > multi-headend resource contention without a central/coordinated PCE > efficiently, and then implementations managed to build those PCE fairly > lightweight into headend routers. Technically i would therefore disagree > with your contentions that PCE need to be very heavy-weight and that > RSVP wouldn't need them but only SR/BIER-PE. But definitely this > BIER-PE document is not the place to have that argument. A later BIER-TE framework > document nevertheless would IMHO be more useful to adopters and operators > if it had such technical description - without judgement and marketing, > just the facts! ] > > > Hopefully my working groups (TEAS, MPLS, PCE) are given the "heads-up" soon - I'd prefer discussion during working group last call vs. IETF Last Call or my needing to enter a "Discuss" waiting for their review. > > I did see Lou sending mail to TEAS and DetNet and Lea to MPLS, did you send to PCE ?. > > I do of course welcome feedback from any group, but i am not worried > about MPLS or PCE. There are no changes on the MPLS encap side, and > as explained above, mapping BIER-PE into the PCE framework is > also subject to followup work (like i think it was for SR as well). > > Thanks a lot. > > Cheers > Toerless > > > Thanks! > > Deborah > > (AD hat on) > > > > -----Original Message----- > > From: BIER On Behalf Of Toerless Eckert > > Sent: Tuesday, February 25, 2020 7:02 PM > > To: Lou Berger > > Cc: gjshep@gmail.com; bier@ietf.org; Jeffrey (Zhaohui) Zhang > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK > > > > Lou, *: > > > > Here is the next and hopefully final github version for your review. > > If you can give a thumbsup i will upload to datatracker, > > and the WG chairs would also be able to finalize WG last-call. > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__raw.githubusercontent.com_toerless_bier-2Dte-2Darch_7e996deb1dcd18596d4864c750f6e7541d737e6f_draft-2Dietf-2Dbier-2Dte-2Darch.txt&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=hbVUmt6ob-Ilgt00kiOlwAOcA68kldlxvO0Lqq-gKxo&e= > > > > And here the diff to -05, last version before taking input from your review into account. > > Given how 1.1 was removed, this seems like the most logical comparison point. > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org_tools_rfcdiff_rfcdiff.pyht-3Furl1-3Dhttps-3A__tools.ietf.org_id_draft-2Dietf-2Dbier-2Dte-2Darch-2D05.txt-26url2-3Dhttps-3A__raw.githubusercontent.com_toerless_bier-2Dte-2Darch_7e996deb1dcd18596d4864c750f6e7541d737e6f_draft-2Dietf-2Dbier-2Dte-2Darch.txt&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=jTvrGagqHgPKneTUpOvNkeYcl7cxDSV32gLk--vyzdQ&e= > > > > Changes to -05 are now easily seen as limited textual: > > - Name change BIER-TE to BIER-PE > > - Explanations using steering/policy > > - [RFC-editor remove note] about name change. > > - BIER-TE controller host -> BIER-TE Controller (unrelated to Lou) > > > > Detailled answers, explanations below. > > > > Cheers > > Toerless > > > > On Tue, Feb 25, 2020 at 01:19:26PM -0500, Lou Berger wrote: > > > Hi Toerless, > > > > > >     This revision will mostly remove my objection related to the use of TE > > > by the document.  I suspect in section 7.2 you have two instances where > > > "traffic" needs to be replaced with "path". > > > > Fixed > > > > > More substantively, I think you > > > should delete section 1.1 and leave its subject  matter  to > > > eckert-teas-bier-te-framework to be covered/worked out.  If you want to keep > > > it, I think there's a longer discussion need on its contents. > > > > Removed section 1.1 from the text. > > > > I have added to the beginning of 1. an [RFC-editor: pls. remove ] section > > explaining the naming change so late in the process to further IETF/IESG > > reviewers (if i had just put it into the changelog i fear it will > > be overlooked by reviewers). > > > > For what is worth, i did like the idea of having explanations > > about relationship of BIER-PE to BIER-TE, especially because the > > framework is IMHO not yet in a state to serve as a good even draft > > reference (it was only pointed to in section 1.1, so also removed > > as reference). > > > > How about this: If IESG review wants to have that type of explanation back, > > i'll knock on your door to revive and help me fix up that text. > > > > > FWIW I still think the introduction of the a new term "Path Engineering", > > > rather than reusing one of the existing IETF terms for the same capability > > > ("routing policy", "policy based routing", "path steering") seems  likely to > > > lead to more confusion then if you stuck with an established term.  I'll > > > leave this to others to argue. > > > > Ok, second time around you're suggesting this, i now owe you an explanation > > why i think these terms are technically misleading: > > (its a bit long, that why i avoided the explanation in before). > > > > All the established terms you propose come from unicast and > > never had a re-definition/re-interpretation for IP multicast. > > > > Using any of these terms in the name would easily lead to > > people (especially when not reading the doc) think the > > BIER solution here works like in both IP multicast and > > BIER in before BIER-PE: By impacting the underlying unicast > > (forward) routing (BIER) or RPF (reverse path) routing (IP Multicast). > > > > Examples: You can use static muRIB routes to steer traffic for > > IP Multicast or BIER. You can also use separate IGP (Flex-)topologies > > to do the same dynamically. Thats all great stuff to describe in a > > BIER-TE framework document (in conjunction with BIER), but that > > is also the stuff i do not want BIER-PE to be confused with > > because there are technical limitations to those unicast routing policy/ > > steering approaches when its applied to trees: > > > > Try to use any of the pre-existing mechanisms for unicast routing policy > > or path steering with BIER or IP multicast to build steiner trees. > > Not generally possible. With BIER-PE, no problem. Same thing with > > disjoint trees (even MRT flex-algo's wouldn't achieve the same). > > > > IMHO, the term "Path Engineering" is free of this mis-name-recognition > > because it is a new. The name also hints at the fact that this could be > > in support of, or a component of traffic engineering. > > And wrt to minimizing the change to the long held name, > > the hamming distance is just one character/word. So it's the > > 'safest/most-conservative/logical' name change this late in the > > process. > > > > As i said, i would be happier with a more unique new descriptive > > name like "Tree Steering Bitstrings" (BIER-TSB), but i do not feel > > like making such a big naming change without more explicit support > > by more members of the WG this late in the process. > > > > > I think this covers all the detailed discussion points below. If not, can > > > you extract the ones you'd like to keep discussing? > > > > Still sad about the missed opportunity of fixing this naming > > problem earlier wrt. to the mail you sopposedly sent, and > > happy to beat myself up if that ended up being my fault, but > > i guess i shouldn't continue to dig into that issue if it would > > turn out to be someone else's fault. > > > > Otherwise i am fine. > > > > If you want to give the doc now a thumbs up in response to the last > > call, that would be great ;-) > > > > EOF > > > > > Thanks again for the responsiveness to my comments! > > > > > > Lou > > > > > > On 2/24/2020 8:57 PM, Toerless Eckert wrote: > > > > Hi Lou, round 2. > > > > > > > > Here is the github pre-version of -07 of the draft: > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__raw.githubusercontent.com_toerless_bier-2Dte-2Darch_62378f618299307349a934fc6ad78e1af9e16771_draft-2Dietf-2Dbier-2Dte-2Darch.txt&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=ijbHbeNowm8uYigeF3tPQBOSrFL5chyoxfjBXyDOxPg&e= > > > > > > > > Diff: > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__tools.ietf.org_tools_rfcdiff_rfcdiff.pyht-3Furl1-3Dhttps-3A__tools.ietf.org_id_draft-2Dietf-2Dbier-2Dte-2Darch-2D06.txt-26url2-3Dhttps-3A__raw.githubusercontent.com_toerless_bier-2Dte-2Darch_62378f618299307349a934fc6ad78e1af9e16771_draft-2Dietf-2Dbier-2Dte-2Darch.txt&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=VMWxCE2IzT007rczFZWwh1CEB3xG48xOj5RifpjIt5s&e= > > > > > > > > I would appreciate if you could try to partition your opinions into > > > > things you think MUST be solved before passing the document to IESG (for > > > > IETF/IESG review) and those issues that could then be solved when it is > > > > in IETF/IESG review. For example, i think a final choice of name could > > > > be something that shouldn't block the document to take this step. > > > > > > > > If this goes along into IETF107, it would be great if you could find the > > > > time to be at the BIER-WG meeting. > > > > > > > > Summary of changes: > > > > > > > > 1. Changed abbreviation BIER-TE to BIER-PE, otherwise we can not unconfuse > > > > readers of the difference between BIER-PE and BIER-TE. > > > > > > > > Relationship: BIER-TE = (BIER with steering: BIER-PE or othre) plus resource > > > > allocation mechanisms, and this document only describes BIER-PE. > > > > > > > > 2. Removed all use of the term "path engineering" from the (explanatory) text, > > > > replaced with path / tree steering or policy in the text (like RFC8402). > > > > > > > > 3. In result, "Path Engineering" is now solely a name for the mechanism. > > > > In the same way as SR introduced "Segment Routing" as a name, but explains > > > > what it does with the terms "steering" and "policy". > > > > > > > > 4. I think a unique new term not already used in before is helpful because > > > > what BIER-PE does is quite unique and new. And reusing an existing term > > > > always brings out more people wanting to argue about the accuracy of how > > > > their pre-existing term is applied. > > > > > > > > I hope we can have a deterministic, short latency decision mechanism for > > > > the term. After we've decided on the term, its easy to update the doc > > > > again with that new term (%s/PE/XXX/g). > > > > > > > > I'll throw "Tree Steering Bitstrings" (BIER-TSB) into the ring. > > > > > > > > [The main issue with name change now is that we've gotten some followup > > > > work such as YANG model that also refers to BIER-TE meaning BIER-PE, so > > > > that would also need to change name. See below for my reply to that naming > > > > change you said you suggested .] > > > > > > > > 5. I also refined the section 1.1 that was introduced in -06 to mention > > > > e.g.: PCE. > > > > > > > > Specific answers to the mail thread below. > > > > > > > > Cheers > > > > Toerless > > > > > > > > On Fri, Feb 21, 2020 at 03:01:51PM -0500, Lou Berger wrote: > > > > > > [ Would have been nice if you could have commented a bit earlier. > > > > > > But i can understand how a few years is not enough time ;-P > > > > > > (actually no kidding, i really can.) ] > > > > > I raised this as an issue last march - at both the Chair and AD level..  I > > > > > thought I made the same point to you privately after one the presentations > > > > > at IETF101, but if you don't remember it, I accept that I didn't. > > > > Did you include the authors ? I could not find any email about this. > > > > Also no forwarded emails from AD/chairs i could find. If you still have > > > > a copy, pls. PM. This is annoying... > > > > > > > > I do not remember naming issue discussed after IETF101, but i am > > > > sure i was preoccupied with technical issues and might not have > > > > given it too much thought back then. Of course there was a lot of > > > > time since IETF101 to bring up the naming point again... > > > > > > > > > Well that document seems like a fine place to describe how BIER-RP (routing > > > > > policy) can be used to deliver BIER-TE. > > > > > > > > > [...] > > > > > Do we really need a new term to describe here?  I find zero (0) instances of > > > > > Path Engineering in any RFC.  Routing policy (and policy-based routing) on > > > > > the other hand are fairly well established terms in the industry.  I think > > > > > this just sows seeds for future confusion on this topic. > > > > > > > > > > Why is "routing policy" not good enough for what is being defining here?  I > > > > > again point out, this is the term being used in SPRING for basically the > > > > > equivalent function/purpose. (Yes the forwarding mechanism is different, but > > > > > the objective is not.) > > > > SPRING did establish new unique name/terminologies, like "Segment". > > > > As said above, i think its best we do the samegiven how unique this is. > > > > > > > > Looking at rfc8402, "steering" and "policy" are used in verbal > > > > explanations, without providing specific terminology for them, > > > > so i did follow that example too. > > > > > > > > > > but kept name BIER-TE (see below). > > > > > > > > > > > > - Added section 1.1 explaining how BIER-TE relates to traffic > > > > > > engineering, naming use-cases where its for example beneficial standalone and > > > > > > and what it could be combined with for more comprehensive TE solutions, > > > > > > but also stating that those integrations are outside the scope of this > > > > > > document. > > > > > So this section seems to miss what has been going on in traffic engineering > > > > > / TEAS for the last 5+ years (i.e., controller-based TE approaches) > > > > I don't think that is a correct assessment. BIER-PE itself requires a > > > > controller to calculate paths / trees. With or without other traffic > > > > engineering components. That component is called the BIER-PE controller and > > > > has been in the draft forever. > > > > > > > > The new section 1.1 added in response to your review relates that > > > > BIER-TE controller to an overall TE controller, using the PCE example > > > > and refrerence to it. > > > > > > > > There is really nothing more that a BIER-WG document could or should > > > > do. What this document intended to support is whats necessary and > > > > sufficient to get the forwarding plane implemented/standardized. > > > > Everything else is for independent followup work in TEAS IMHO, > > > > such as reviving the framwork draft. > > > > > > > > >   and then goes on describe path steering  in a very brief way..  I read this as > > > > > saying that BIER *could* do TE in the future and *can* support routing > > > > > policy and path steering today. > > > > Even stronger: BIER-PE is always meant to ONLY do that (steering), > > > > any additional TE functions wold come from independent other components. > > > > And simple examples for that are given in section 1.1. > > > > > > > > > > - changed "traffic engineering" term in the whole doc to "path engineering", > > > > > > where appropriate. > > > > > While this is appreciated, I'm not sure it's helpful.  As stated above, I > > > > > think the introduction of the new PE term is confusing as the continued use > > > > > of BIER-TE. > > > > See above. We can certainly not use "BIER-TE" to mean two different > > > > things, so i hope that concern is resolved. > > > > > > > > > > The mayority of customers i talked to only used RSVP-TE for path > > > > > > engineering, and not for anything more. Several didn't even know it > > > > > > can do bandwidth reservation. Nobody knew it could do latency > > > > > > guarantees, because nobody knows an implementation that supports that. > > > > > > [All reasons btw. why replacing RSVP-TE with SR happened in the industry.] > > > > > While I'm going to avoid getting into product differentiators and marketing, > > > > > you're not mentioning that even those products and customers who didn't > > > > > support/use per LSP queuing, did available resource bookkeeping and even > > > > > admission control. > > > > I think the point is mood now (given how we'll change the name BIER-TE > > > > to a better term). But maybe to better explain: We started calling this > > > > TE so customers would easier understand that this is intended to give > > > > them what they actually use RSVP-TE for (Traffic Steering), and not > > > > necessarily all that RSVP-TE could do beyond that. A central controller > > > > is assumed to exist in BIER-PE too. > > > > > > > > Given how SR also shows how you can be successful in deployment > > > > without betting on 'TE' name recognition, i have no quarrels in > > > > changing the name. As said above, its motly a question of finding > > > > the best term and changing the followup works names too. > > > > > > > > > > In any case, the name BIER-TE was selected to reduce confusion > > > > > > with customers, not to maximize naming correctness in IETF. > > > > > umm, the IETF is a standards body not an industry marketing forum, so I'm > > > > > unclear how this point helps your argument. > > > > It's not am argument or justification, just an explanation. Not only to you, > > > > but also the WG. > > > > > > > > >  It seems that you're saying > > > > > that if we call it BIER-TE we can market it in place of existing IETF TE > > > > > solutions - even though it doesn't yet have the TE capability covered in > > > > > draft-eckert-teas-bier-te-framework. > > > > .... > > > > > > > > > Assuming I'm reading it right, this just confirms to me that the current > > > > > work needs to be renamed and that draft-eckert-teas-bier-te-framework will > > > > > define BIER-TE. > > > > Yes. BIER-TE could btw. rely on BIER-PE or BIER + other path steering > > > > (e.g.: flex-algos), so BIER-PE is only one option for the path-steering > > > > options for BIER-TE. > > > > > > > > > My point wasn't that BIER=SR, but rather both deliver support for path > > > > > steering and policy based routing. > > > > Yepp, i hope we're in violent agreement. > > > > > > > > Cheers > > > > Toerless > > > > > > > > > Thanks for being responsive! > > > > > > > > > > Lou > > > > > > > > > > > All the SR options do really require that you set up multicast trees with > > > > > > e.g.: replication-SIDs that together form the equivalent of a > > > > > > multicast tree, like you would have built with RSVP-TE. Except that > > > > > > the signaling how to build the tree is left for someone else, like > > > > > > PCECC. (AFAIK, i may not be on top of all details). In BIER-TE, > > > > > > there is no such per-tree state on transit nodes. > > > > > > > > > > > > Instead of a 256 bit bitstring in BIER-TE think of a header with up to 256 SIDs > > > > > > (e.g.: 128 bit per SID in SRv6). That would be the SR equivalent of BIER-TE. > > > > > > Just a bit less ( ;-) ) less efficient on the wire than BIER-TE and extremely > > > > > > harder to parse. > > > > > > > > > > > > Cheers > > > > > > Toerless > > > > > > > > > > > > > > > > > > On Wed, Feb 19, 2020 at 06:38:38PM -0500, Lou Berger wrote: > > > > > > > Hi, > > > > > > > > > > > > > >     I have no issue or objection to the mechanisms being defined in this > > > > > > > document as much as they go, but I was quite disappointed that despite the > > > > > > > name of the document and use of 'bier-te'  to see that the document doesn't > > > > > > > define any traffic engineering support, at least as far as the term has been > > > > > > > used in IETF RFCs.  In particular it totally lacks any discussion of > > > > > > > resources usage and/or allocation.  What it currently describes certainly > > > > > > > provides good and useful path/traffic steering that can be used to support > > > > > > > policy-based routing.  Basically it does the same as what is defined by > > > > > > > draft-ietf-spring-segment-routing-policy. > > > > > > > > > > > > > > I personally (not speaking for the related WGs that I chair) would prefer to > > > > > > > see this document be revised  to include resource allocation that would > > > > > > > allow BIER-TE to support TE usage such as DetNet.  Barring such an addition, > > > > > > > I'm against publication of this document as is and I think the document > > > > > > > should be recast and renamed to be aligned with the SR example, i..e., BIER > > > > > > > routing policy (or path steering). > > > > > > > > > > > > > > Lou > > > > > > > > > > > > > > On 2/18/20 3:45 PM, Greg Shepherd wrote: > > > > > > > > Thanks Toerless and Jeffrey > > > > > > > > > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbier-2Dte-2Darch_&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=jH9x7gacv335Qdcq_btgUNtO3-TQxwLspmfVzbCC9Oo&e= > > > > > > > > > > > > > > > > One more week of WGLC. Please read the latest rev and respond to this > > > > > > > > thread w/wo support. > > > > > > > > > > > > > > > > Chairs > > > > > > > > (Shep) > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Feb 18, 2020 at 12:07 PM Jeffrey (Zhaohui) Zhang > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi Toerless, > > > > > > > > > > > > > > > > Thanks! > > > > > > > > I support moving this to the next stage. > > > > > > > > > > > > > > > > Jeffrey > > > > > > > > > > > > > > > > On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote: > > > > > > > > > Thanks Jeff > > > > > > > > > > > > > > > > > > I have now pushed out -05 with the answers and hopefully > > > > > > > > resolution to > > > > > > > > > your points in email below.  Biggest addition was a section about > > > > > > > > > reuse of BPs (without DNR) which came out of the confusion i > > > > > > > > think the > > > > > > > > > reuse in the ECMP example raised. I was afraid so far to explan > > > > > > > > that > > > > > > > > > as it may not be easy to absorb and ultimately is stuff only > > > > > > > > > controller developers need to understand, but hopefully useful. > > > > > > > > > And then of course the summary of BP optimizatins you asked for > > > > > > > > > > > > > > > > > > Diff from last version i sent you: > > > > > > > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: > > > > > > > > > **Araw.githubusercontent.com > > > > > > > > *toerless*bier-te-arch*master*draft-ietf-b > > > > > > > > > ier-te-arch-05.1.txt&url2=http:**Atools.ietf.org > > > > > > > > *id*draft-ietf-bier-te > > > > > > > > > > > > > > > > > -arch-05.txt__;Ly8vLy8vLy8vLy8!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzH > > > > > > > > > OCr0fZkLPbgg3CPNu0PyrWsrFx41_jWX2At8V-$ > > > > > > > > > > > > > > > > > > full -04 -> 05 diff: > > > > > > > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=http:* > > > > > > > > > *Atools.ietf.org > > > > > > > > *id*draft-ietf-bier-te-arch-04.txt&url2=http:**Atools. > > > > > > > > > ietf.org > > > > > > > > *id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk > > > > > > > > > !VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx41_jWancpziv$ > > > > > > > > > > > > > > > > > > Comments inline below. > > > > > > > > > > > > > > > > > > Cheers > > > > > > > > >     toerless > > > > > > > > > > > > > > > > > > On Mon, Oct 28, 2019 at 07:52:59PM +0000, Jeffrey (Zhaohui) > > > > > > > > Zhang wrote: > > > > > > > > > > I Thought u-turn is the most simple comparison leaf vs. > > > > > > > > non-leaf BFR. > > > > > > > > > > > > > > > > > > > > Zzh> The text in the email is seriously misaligned. Looking at > > > > > > > > the picture in the diff link, while you gave a U-turn example, > > > > > > > > though even if BFER2 is not connected to BFR2  but only connected > > > > > > > > to BFER1 (hence no U-turn), then BFER1 is still not a leaf BFER I > > > > > > > > suppose. That's why I said the first sentence of the above > > > > > > > > paragraph is enough to define Leaf BFER while the example itself > > > > > > > > is actually not needed. > > > > > > > > > > > > > > > > > > Argh... ok, had to fix two words, BFIR->BFER and left-hand -> > > > > > > > > right-hand: > > > > > > > > > > > > > > > > > > Consider how redundant disjoint traffic can reach BFER1/BFER2 in > > > > > > > > above > > > > > > > > > picture: When BFER1/BFER2 are Non-Leaf BFER as shown on the > > > > > > > > right hand > > > > > > > > > side, one traffic copy would be forwarded to BFER1 from BFR1, > > > > > > > > but the > > > > > > > > > other one could only reach BFER1 via BFER2, which makes BFER2 a > > > > > > > > > non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forwarding > > > > > > > > > traffic to BFER2 > > > > > > > > > > > > > > > > > > > Zzh> Additionally, in left part of the picture you added, if > > > > > > > > some failure leads to BFR2 to be only reachable via BFER1, then > > > > > > > > BFER1 is no longer a leaf BFER. > > > > > > > > > > > > > > > > > > Added sentence: > > > > > > > > > > > > > > > > > > Note that the BFER in the left hand picture are only > > > > > > > > guaranteed to > > > > > > > > > be leaf-BFR by fitting routing configuration that prohibits transit > > > > > > > > > traffic to pass through a PE, which is commonly applied in these > > > > > > > > > topologies. > > > > > > > > > > > > > > > > > > > I assume you don't reassign BPs when links go up and down. > > > > > > > > > > > > > > > > > > I didn't want to discuss that option in this document.. Its > > > > > > > > obviously > > > > > > > > > perfectly feasible, but be yet a big amount of text (especially the > > > > > > > > > considerations how to do this make-before-break. Future doc. > > > > > > > > > > > > > > > > > > > > but subsequent polarization example confuses me. It seems > > > > > > > > that BP 0:6 is assigned to the routed adjacency BFR10 (which is > > > > > > > > actually talked about in Section 4.8). > > > > > > > > > > > > > > > > > > > > Section 4.7 does not mention "routed" at all, so there are no > > > > > > > > routed adjacencies at all used in 4.7. So i am not sure what you > > > > > > > > are confused about. > > > > > > > > > > > > > > > > > > > > Zzh> "The BIFT of each BFR are only populated with BPs that > > > > > > > > are adjacent to the BFR in the BIER-TE topology". > > > > > > > > > > > > > > > > > > Correct text from the introduction. Ok. > > > > > > > > > > > > > > > > > > > Zzh> Since the same 0:6 is in BIFTS of BFR1/BFR2/BFR3 (and I > > > > > > > > suppose in BFR4~BFR9 as well even though not drawn), I assumed > > > > > > > > it's for the "MP2P" routed adjacency to R10; though I then ruled > > > > > > > > that out - but I don't know what 0:6 represent now on BFR1, BFR2, > > > > > > > > and BFR3. > > > > > > > > > > > > > > > > > > Ah. Ok. I thought i could strip down the example to show only the > > > > > > > > > adjacencies relevant to the following discusion, but seemingly this > > > > > > > > > can introduce the confusion you have. > > > > > > > > > > > > > > > > > > So i completed the example with the BP assignment acoss all > > > > > > > > nodes, but > > > > > > > > > added text pointing to a new section further down to discuss the > > > > > > > > > re-use of BP for which thi picture is also an example. > > > > > > > > > > > > > > > > > > (check out the diff, new reuse text to long to copy inline). > > > > > > > > > > > > > > > > > > > The whole purpose of the ECMP BPs is of course to save bits, > > > > > > > > otherwise we'd give each link a separate BP, which would be 6 BP > > > > > > > > to reach to BFR4...BFR7 from BFR1. > > > > > > > > > > > > > > > > > > > > Zzh> The trouble I am having is that the same 0:6 is assigned > > > > > > > > to different things and it's present on all BFR1/BFR2/BFR3. It is > > > > > > > > perhaps an intentional smart design but I have not wrapped my mind > > > > > > > > around it. It's apparently different from the link bundle case, so > > > > > > > > better separate it out and elaborate it (including the DNR flag > > > > > > > > that might be needed here - If the packet arrives on BFR1 with > > > > > > > > 0:6, would the BP reset when it is sent to BFR2/3)? > > > > > > > > > > > > > > > > > > Yes, there was the bug of reusing BP 0:6 across sequential BFR > > > > > > > > along > > > > > > > > > the path, but now the example correctly reuses separate BP at > > > > > > > > > different stages of the paths (BP 0:6 on BFR1, BP 0:7 on > > > > > > > > BFR2/BFR3) and so on. > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > > > 4.8.  Routed adjacencies > > > > > > > > > > > > > > > > > > > > > > If I understand it correctly, there is a BP assigned to > > > > > > > > L1/L2/L3 > > > > > > > > > > > respectively (p2p link), and then there are BPs assigned to > > > > > > > > MP2P tunnels (routed adjacency from every BFR) to the L1/L2/L3 > > > > > > > > interface addresses and loopback addresses on BFR2/3. > > > > > > > > > > > > > > > > > > > > Ok that wasn't quite the read i expected. Let me clarify the > > > > > > > > text/picture: > > > > > > > > > > > > > > > > > > > >                    ................ > > > > > > > > > >          ...BFR1--...           ...--L1-- BFR2... > > > > > > > > > >                   ... .Routers. ....--L2--/ > > > > > > > > > >          ...BFR4--...           ...------ BFR3... > > > > > > > > > >                    .................         | > > > > > > > > > >                                           LO > > > > > > > > > >                     Network Area 1 > > > > > > > > > > > > > > > > > > > > Assume the requirement in the above picture is to explicitly > > > > > > > > steer traffic flows that have arrived at BFR1 or BFR4 via a > > > > > > > > shortest path in the routing underlay "network area 1" to one of > > > > > > > > the following three next segments: (1) BFR2 via link L1, (2) BFR2 > > > > > > > > via link L2, (3) via BFR3. > > > > > > > > > > > > > > > > > > > > To achieve this, both BFR1 and BFR4 are set up with a > > > > > > > > forward_routed adjacency BitPosition towards an address of BFR2 on > > > > > > > > link L1, another forward_routed BitPosition towards an address of > > > > > > > > BFR2 on link L2 and a third forward_routed Bitposition towards a > > > > > > > > node address LO of BFR3. > > > > > > > > > > > > > > > > > > > > Does this clear ip the confusion ? > > > > > > > > > > > > > > > > > > > > Zzh> The picture is badly misaligned. I'll wait till 4.7 > > > > > > > > questions are cleared. > > > > > > > > > > > > > > > > > > Ok. > > > > > > > > > > > > > > > > > > > > If BFR2/3 are also BFERs, then they additionally will have > > > > > > > > BFER BPs. > > > > > > > > > > > On BFR1/4, the BIFT entries for the MP2P BPs for the > > > > > > > > L1/L2/L3/loopback interface addresses of BFR2/3 will use > > > > > > > > forward_routed(interface/loopback address). For a packet to be > > > > > > > > decapsulated on a BFER, there is a need for both the BFER BP and > > > > > > > > another BP (p2p/lan/hub-spoke/routed-adjacency) in the packet (the > > > > > > > > former is for decapsulation and the latter is for getting it there). > > > > > > > > > > > > > > > > > > > > This is not discussed in this section, but you are right - unless > > > > > > > > > > BFR2 or BFR3 is a leaf BFR. In that case, it would just > > > > > > > > leverage the one shared "leaf-BFR" BP, so they do not need a > > > > > > > > per-BFER BP for local_decap(). > > > > > > > > > > > > > > > > > > > > Zzh> Right - shared leaf-BFR BP but still need that BP (the > > > > > > > > key is that we need a BP to get packet to a BFER and then a BP for > > > > > > > > decapsulation). > > > > > > > > > > > > > > > > > > You got it. > > > > > > > > > > > > > > > > > > > > If that???s the case, it???s worth point the above out. > > > > > > > > > > > > > > > > > > > > Hmm... The logic of BFER BPs is totally independent of the > > > > > > > > logic of forward_routed adjacency, so i would worry that repeating > > > > > > > > the explanation of BFER BPs would conflate the forward_routed > > > > > > > > explanation. > > > > > > > > > > > > > > > > > > > > Zzh> It's just that this is a place where all kinds of BPs are > > > > > > > > used so it's good to have a summary (could be a subsection 4.9). > > > > > > > > > > > > > > > > > > Yes, added such a summary. Pls. check. > > > > > > > > > > > > > > > > > > > > Actually, the reason that I thought this is MP2P is that 0:6 > > > > > > > > is present on R1, R2, and R3 (and more I assume) in Figure 12, but > > > > > > > > now I think it can???t be MP2P (so it is not correct to have 0:6 > > > > > > > > present on those routers ??? only the p2p tunnel head/tail should > > > > > > > > have the BP present in the BIFT). The reason is that if it were > > > > > > > > MP2P, any router getting a copy will send it to the endpoint of > > > > > > > > the routed adjacency, causing lots of duplicates. > > > > > > > > > > > > > > > > > > > > > > Am I getting this correct? > > > > > > > > > > > > > > > > > > > > I think you are still explaining from the misunderstsanding > > > > > > > > that the ECMP explanations where about routed adjacencies. > > > > > > > > > > > > > > > > > > > > I have now expanded the somewhat terse text in the BIFT table > > > > > > > > pictures, to make it clear that the ECMP is across multipe > > > > > > > > forward_connected adjacencies in the examples. For example, first > > > > > > > > BIFT picture: > > > > > > > > > > > > > > > > > > > >   BIFT entry in BFR1: > > > > > > > > > > > > > > > > > >  ------------------------------------------------------------------ > > > > > > > > > >   | Index |  Adjacencies                  | > > > > > > > > > > > > > > > > > >  ================================================================== > > > > > > > > > >   | 0:6   |  ECMP({forward_connected(L1, BFR2),                 | > > > > > > > > > >   |       |        forward_connected(L2, BFR2),                 | > > > > > > > > > >   |       |        forward_connected(L3, BFR2)}, seed) > > > > > > > >      | > > > > > > > > > > > > > > > > > >  ------------------------------------------------------------------ > > > > > > > > > > > > > > > > > > > > Of course, an ECMP adjacency can be across any type of > > > > > > > > adjacencies, but all the text/explanations used forward_connected, > > > > > > > > and now the pictures show that explicitly. > > > > > > > > > > > > > > > > > > > > Zzh> I can understand the multi-link case, but the multi-hop > > > > > > > > ECMP case (from BFR1 towards BFR10) is confusing me. It would help > > > > > > > > to give an example how it can be used, WITHOUT worrying about > > > > > > > > polarization. > > > > > > > > > > > > > > > > > > Please check -05 text that has the full set of BIFT listed now: > > > > > > > > > > > > > > > > > > There is  really nothing nothing unique in multi-hop ECMP for > > > > > > > > BIER-TE > > > > > > > > > that we do not also have in any other ECMP, except the > > > > > > > > conclusion that > > > > > > > > > we want to support fast HW hash mechanisms AND allow the > > > > > > > > controller to > > > > > > > > > set up non-polarized multi-hop ECMP AND be able to precalculate > > > > > > > > paths. > > > > > > > > > Hence the specification of ECMP adjacencies to have a controller > > > > > > > > > configurable seed. > > > > > > > > > > > > > > > > > > Btw: The picture is maybe unnecessarily large because i've used > > > > > > > > it for > > > > > > > > > 20 years to explain the same polarization issue for unicast vs > > > > > > > > > multicast, and for multicast only BFR10...BFR4 are relevant > > > > > > > > (ECMP of > > > > > > > > > the PIM/mLDP joins), whereas for unicast/BIER only > > > > > > > > > BFR1...BFR7 are relevant. But being symmetric, the picture makes it > > > > > > > > > clear its the same problem. > > > > > > > > > > > > > > > > > > > >    To inhibit looping in the face of such physical > > > > > > > > misconfiguration, > > > > > > > > > > >    only forward_connected adjacencies are permitted to have > > > > > > > > DNR set, and > > > > > > > > > > >    the link layer destination address of the adjacency > > > > > > > > (e.g.  MAC > > > > > > > > > > >    address) protects against closing the loop..  Link layers > > > > > > > > without port > > > > > > > > > > >    unique link layer addresses should not be used with the > > > > > > > > DNR flag set. > > > > > > > > > > > > > > > > > > > > > > It???s not clear how link layer address helps? > > > > > > > > > > > > > > > > > > > > I have expanded this to > > > > > > > > > > "link layer port unique unicast destination address" > > > > > > > > > > > > > > > > > > > > Aka: MPLS or ethernet have unique link layer destination > > > > > > > > destination addresses (label or destination MAC). If you think > > > > > > > > about incorrectly plugged HDLC links (such as old T1/T3/.... > > > > > > > > links), they only have 2 generic addresses, if i remember 1 or 3 > > > > > > > > in the HDLC frame. So when you misplug one of those p2p cables > > > > > > > > wrong, the packets would be incrrectly received by the wrong > > > > > > > > receiver node and then DNR could cause persistent loops only > > > > > > > > solved by TTL. > > > > > > > > > > > > > > > > > > > > Zzh> "Consider in the ring picture that link L4 from BFR3 is > > > > > > > > plugged into the L1 interface of BFRa" - still not sure how > > > > > > > > label/mac helps here. I suppose the ring topology is > > > > > > > > discovered/verified by the control plane and when the miscalling > > > > > > > > happens then the ring will not include the BFR1/BFR2 part and BFR3 > > > > > > > > will not have the DNR set? If ring discovery/varication is not > > > > > > > > done then perhaps we should point out that RPF based on link layer > > > > > > > > address is needed - the key is RPF (which needs unique link layer > > > > > > > > address)? > > > > > > > > > > > > > > > > > > Forget RPF. BIER(-TE) has no RPF (issues). Its just like > > > > > > > > unicast. RPF > > > > > > > > > is just a problem for receiver originated joins like in > > > > > > > > PIM/mLDP, but > > > > > > > > > not unicast/bier(-te)/RSVP-TE. > > > > > > > > > > > > > > > > > > Forward_connected is just like a unicast subnet adjacency to a > > > > > > > > direct > > > > > > > > > neighbor: Interface and L2 addresss of the destination. > > > > > > > > > > > > > > > > > > The controller (could be a human) "assumes" a particular physicial > > > > > > > > > topology, from telemetry/knowledge/whatever. It then calculates the > > > > > > > > > desired BIER-TE topology and pushes it down. This topology is > > > > > > > > meant to > > > > > > > > > be loop free of course wrt to the configured adjacencies. > > > > > > > > > In this BIER-TE topology, BFR3 will have a BP with the > > > > > > > > > forward_connected(L4, MAC-of-BFR2) adjacency. > > > > > > > > > > > > > > > > > > If the cable connecting to L4 is miswired, then BFR3 would still > > > > > > > > send > > > > > > > > > the packets to the MAC address of BFR2, but given how the cable > > > > > > > > > connects to some other node, these packets will be discarded by > > > > > > > > that > > > > > > > > > node. because they're just L2 unicast packets. > > > > > > > > > > > > > > > > > > I think this is equally true when we have normal BIER/MPLS enacp. > > > > > > > > > Those packets too are addressed to the unicast MAC address of the > > > > > > > > > neighbor. > > > > > > > > > > > > > > > > > > Now, if/when he controller recognizes that the physical topology > > > > > > > > has > > > > > > > > > changed, thats a completely different story and not addressed here. > > > > > > > > > Given how we assumed this was a cabling mistake, the controller > > > > > > > > would > > > > > > > > > probably only complain about the miswiring to operations but be > > > > > > > > happy > > > > > > > > > that the forwarding plane just makes packets fail instead of > > > > > > > > loop. If > > > > > > > > > this was a planned change process, then it will be similarily > > > > > > > > > convoluted as it would today be with rewiring cables in an > > > > > > > > > SR-MPLS/SRv6 topology and updating SIDs. > > > > > > > > > > > > > > > > > > > > Because the forwarding is different from BIER forwarding > > > > > > > > (because of [1] above), we might as well introduce an optimization > > > > > > > > here ??? for each BIFT, calculate the F-BM of the BIFT itself (the > > > > > > > > logical ???or??? of all the BPs presented in this BIFT) and then > > > > > > > > use (packet->bitstring & BIFT.F-BM) as the input to > > > > > > > > GetFirst/NextBitPosition(). That should skip many bits. > > > > > > > > > > > > > > > > > > > > Right. But i explicitly removed those optimizations (i had > > > > > > > > them in older draft versions) because the whole idea of this > > > > > > > > picture is solely the comparison with figure 4 of RFC8279. > > > > > > > > > > > > > > > > > > > > Zzh> I think it's worth point that optimization out; you can > > > > > > > > mark it optional if you want to emphasize the similarity to BIER > > > > > > > > forwarding, but since BIER forwarding does do the maskoff step, it > > > > > > > > is very efficient while BIER-TE forwarding does not it the maskoff > > > > > > > > step so this optimization is important. > > > > > > > > > > > > > > > > > > Ok. I simplified the text comparison BIER/BIER-TE wrt.. to the FBM > > > > > > > > > rules [1] and [2] and added following paragraph: > > > > > > > > > > > > > > > > > > In BIER, the order of BPs impacts the result of forwarding > > > > > > > > because of [1]. > > > > > > > > > In BIER-TE, forwarding is not impacted by the order of BPs. It is > > > > > > > > > therefore possible to further optimize forwarding than in BIER. For > > > > > > > > > example parallelizing forwarding across multiple FPE cores or > > > > > > > > > distributed linecards does only need to examine an arbitrary > > > > > > > > subset of > > > > > > > > > BP and not evaluate the dependency between BPs. > > > > > > > > > > > > > > > > > > > >    The following pseudocode is comprehensive: > > > > > > > > > > > > > > > > > > > > > > The above sentence reads a bit strange (or lacks some segue). > > > > > > > > > > > > > > > > > > > > I hope not, but maybe best left to a native english speaker > > > > > > > > (RFC-editor). > > > > > > > > > > > > > > > > > > > > The first (RFC8279) pseudocode was simplified. The second one > > > > > > > > is comprehensive. If not comprehensive, whats a good opposite of > > > > > > > > simplified ? > > > > > > > > > > > > > > > > > > > > Zzh> Perhaps "The above simplified pseudocode is elaborated > > > > > > > > further as following"? > > > > > > > > > > Zzh> Jeffrey > > > > > > > > > > > > > > > > > > Done. > > > > > > > > > > > > > > > > > > Thanks a lot. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ________________________________________ > > > > > > > > > > > From: BIER [bier-bounces@ietf.org > > > > > > > > > > > > > > > >] > > > > > > > > > > > on behalf of Toerless Eckert [tte@cs.fau.de > > > > > > > > >] > > > > > > > > > > > Sent: Tuesday, July 09, 2019 23:38 > > > > > > > > > > > To: Mike McBride > > > > > > > > > > > Cc: Greg Shepherd; BIER WG; Pascal Thubert (pthubert) > > > > > > > > > > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch > > > > > > > > > > > > > > > > > > > > > > Thanks, Mike > > > > > > > > > > > > > > > > > > > > > > The authors also reviewed the document and concluded that it > > > > > > > > was > > > > > > > > > > > really hard to get into the document context because of too > > > > > > > > many > > > > > > > > > > > forward dependencies. We tried to fix this by adding two > > > > > > > > hopefully > > > > > > > > > > > good & basic examples into the Introduction section and > > > > > > > > using them > > > > > > > > > > > to also add a better definition of the term "BIER-TE > > > > > > > > Topology" in the Introduction. > > > > > > > > > > > Hopefully this makes readin the rest of te document smoother. > > > > > > > > > > > > > > > > > > > > > > Also improved text of Abstract and refined text compariing > > > > > > > > BIER-TE with SR. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: > > > > > > > > > > > **Atools.ietf.org > > > > > > > > *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A > > > > > > > > > > > tool > > > > > > > > > > > s.ietf.org > > > > > > > > *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R > > > > > > > > > > > jC81 > > > > > > > > > > > > > > > > > > > c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV_eTUEh > > > > > > > > > > > $ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > **Atools.ietf.org > > > > > > > > *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A > > > > > > > > > > > tool > > > > > > > > > > > s.ietf.org > > > > > > > > *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R > > > > > > > > > > > jC81 > > > > > > > > > > > > > > > > > > > c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sNd1njcX > > > > > > > > > > > $> > > > > > > > > > > > > > > > > > > > > > > Cheers > > > > > > > > > > >     Toerless > > > > > > > > > > > > > > > > > > > > > > On Wed, Jun 26, 2019 at 10:39:36AM -0700, Mike McBride wrote: > > > > > > > > > > > > How about three? I support. > > > > > > > > > > > > mike > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd > > > > > > > > > > > > > > > > > > > > > > >> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > We cannot take two 'yes' votes and WG consensus. > > > > > > > > > > > > > Please, read and respond. If you don't support, then > > > > > > > > please vote as much publicly right here. > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > Greg > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert > > > > > > > > (pthubert) > > > > > > > > > > > > > > >> wrote: > > > > > > > > > > > > >> > > > > > > > > > > > > >> Support: > > > > > > > > > > > > >> > > > > > > > > > > > > >> I see great value in deterministic networks as well as > > > > > > > > IOT (with RPL). > > > > > > > > > > > > >> > > > > > > > > > > > > >> All the best, > > > > > > > > > > > > >> > > > > > > > > > > > > >> Pascal > > > > > > > > > > > > >> > > > > > > > > > > > > >> > -----Original Message----- > > > > > > > > > > > > >> > From: BIER > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> On > > > > > > > > > > > > >> > Behalf Of Toerless Eckert > > > > > > > > > > > > >> > Sent: mardi 4 juin 2019 02:03 > > > > > > > > > > > > >> > To: Greg Shepherd > > > > > > > > > > > > >> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > >> > Cc: BIER WG > > > > > > > >> > > > > > > > > > > > > >> > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > +1 > > > > > > > > > > > > >> > Obviously support as co-author. > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > On Wed, May 29, 2019 at 12:41:26PM -0700, Greg > > > > > > > > Shepherd wrote: > > > > > > > > > > > > >> > > Please read and respond to this thread w/ or w/o > > > > > > > > support. > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > > > > > > > > > https://urldefense.com/v3/__https://datatracker..ietf.org > > > > > > > > > > > > >> > > /doc > > > > > > > > > > > > >> > > > > > > > > > > /draft-ietf-bier-te-arch/__;!8WoA6RjC81c!XvH4AAxfrDjFoK_s > > > > > > > > > > > > >> > > ercw ZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV9eClBj$ > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > >> > > doc/ > > > > > > > > > > > > >> > > > > > > > > > > draft-ietf-bier-te-arch/__;!8WoA6RjC81c!UBTGvWWpMHyeiSanx > > > > > > > > > > > > >> > > s6vI b_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sD40kmtH$> > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > Vote ends 5 June 2019. > > > > > > > > > > > > >> > > > > > > > > > > > > > > >> > > Thanks, > > > > > > > > > > > > >> > > Shep > > > > > > > > > > > > >> > > (chairs) > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > > _______________________________________________ > > > > > > > > > > > > >> > > BIER mailing list > > > > > > > > > > > > >> > > BIER@ietf.org > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/ > > > > > > > > > > > > >> > > list > > > > > > > > > > > > >> > > > > > > > > > > info/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eE > > > > > > > > > > > > >> > > NOs4 l_qdsXF0KwZD82cJLDFFNT2WVXWX$ > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > >> > > list > > > > > > > > > > > > >> > > > > > > > > > > info/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6b > > > > > > > > > > > > >> > > oAAW 4nrqju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > > > > > > > > > >> > > > > > > > > > > > > > >> > _______________________________________________ > > > > > > > > > > > > >> > BIER mailing list > > > > > > > > > > > > >> > BIER@ietf.org > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/li > > > > > > > > > > > > >> > stin > > > > > > > > > > > > >> > > > > > > > > > fo/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4 > > > > > > > > > > > > >> > l_qd > > > > > > > > > > > > >> > sXF0KwZD82cJLDFFNT2WVXWX$ > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > >> > stin > > > > > > > > > > > > >> > > > > > > > > > fo/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW > > > > > > > > > > > > >> > 4nrq > > > > > > > > > > > > >> > ju8UCLOgiuXc8Y_6sKn2KoAT$> > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > BIER mailing list > > > > > > > > > > > > > BIER@ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listi > > > > > > > > > > > > > nfo/ > > > > > > > > > > > > > > > > > > > > > bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsX > > > > > > > > > > > > > F0Kw > > > > > > > > > > > > > ZD82cJLDFFNT2WVXWX$ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > nfo/ > > > > > > > > > > > > > > > > > > > > > bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju > > > > > > > > > > > > > 8UCL > > > > > > > > > > > > > OgiuXc8Y_6sKn2KoAT$> > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > --- > > > > > > > > > > > tte@cs.fau.de > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > BIER mailing list > > > > > > > > > > > BIER@ietf.org > > > > > > > > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ > > > > > > > > > > > bier > > > > > > > > > > > > > > > > > > > __;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82 > > > > > > > > > > > cJLD > > > > > > > > > > > FFNT2WVXWX$ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > bier > > > > > > > > > > > > > > > > > > > __;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiu > > > > > > > > > > > Xc8Y > > > > > > > > > > > _6sKn2KoAT$> > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > --- > > > > > > > > > > tte@cs.fau.de > > > > > > > > > > > > > > > > > > -- > > > > > > > > > --- > > > > > > > > > tte@cs.fau.de > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > BIER mailing list > > > > > > > > > BIER@ietf.org > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier > > > > > > > > > > > > > > > > > __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx4 > > > > > > > > > 1_jWV3YUA6D$ > > > > > > > > > > > > > > > > -- > > > > > > > > --- > > > > > > > > tte@cs.fau.de > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > BIER mailing list > > > > > > > > BIER@ietf.org > > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=DrLodD0a2MFe60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e= > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > BIER mailing list > > > > > > > BIER@ietf.org > > > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf..org_mailman_listinfo_bier&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=DrLodD0a2MFe60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e= > > > > > _______________________________________________ > > > > > BIER mailing list > > > > > BIER@ietf.org > > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=DrLodD0a2MFe60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e= > > > > _______________________________________________ > > > > BIER mailing list > > > > BIER@ietf.org > > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=DrLodD0a2MFe60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e= > > > > > > > > > > _______________________________________________ > > > BIER mailing list > > > BIER@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=DrLodD0a2MFe60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e= > > > > -- > > --- > > tte@cs.fau.de > > > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIFAw&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=MW3S0mvhNN9uq5VmjXdNXGwsisVP5wzzO8r04h4aP0o&s=DrLodD0a2MFe60a2_DECDeLJWLgxgqd65rAgnpk4u8M&e= > > -- > --- > tte@cs.fau.de > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier -- --- tte@cs.fau.de From nobody Thu Feb 27 23:54:18 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C78653A0EFF; Thu, 27 Feb 2020 23:54:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8uwuNZ8slEdI; Thu, 27 Feb 2020 23:54:15 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A3B53A1268; Thu, 27 Feb 2020 23:54:15 -0800 (PST) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id A6D2FBF0EEBDE57A7B3C; Fri, 28 Feb 2020 07:54:12 +0000 (GMT) Received: from LHREML501-MBS.china.huawei.com ([10.201.109.50]) by LHREML713-CAH.china.huawei.com ([10.201.108.36]) with mapi id 14.03.0415.000; Fri, 28 Feb 2020 07:54:07 +0000 From: Dirk Trossen To: Toerless Eckert , "bier@ietf.org" CC: Lou Berger , "bier-ads@ietf.org" , "BRUNGARD, DEBORAH A" , "bier-chairs@ietf.org" Thread-Topic: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) Thread-Index: AQHV7a5B9i3JWSo4iEW+r4TQMbNWUqgwOYqw Date: Fri, 28 Feb 2020 07:54:07 +0000 Message-ID: <91BA3A406CA139458B56D8C52EAB227D147F35@lhreml501-mbs> References: <20200227204038.GB23965@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200227204038.GB23965@faui48f.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.220.96.241] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 07:54:17 -0000 Toerless, all, May I add to the mix (which might not help) with the proposal for 'path-bas= ed routing' (or BIER-PBR) or 'path-based steering' (or BIER-PST)? If you wa= nt to keep a two letter acronym, I'd add 'path steering' (rather than path = engineering) to the mix. From the below, without considering any alternativ= es, I'd go for BIER-PE but it comes with the issues like many two letter ac= ronyms, namely the higher 'collision rate' with others. Best, Dirk -----Original Message----- From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Toerless Eckert Sent: 27 February 2020 21:41 To: bier@ietf.org Cc: Lou Berger ; bier-ads@ietf.org; BRUNGARD, DEBORAH A <= db3546@att.com>; bier-chairs@ietf.org Subject: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) Dear WG Please chime in with opinions about the following or any new name you like = as the new name for BIER-TE. Timeout is deadline for submission of draft be= fore IETF107, when i'll post an update. If you propose a new name try to av= oid re-using abbreviations that may be misinterpreted. 5 =3D best name ever, ... 1 =3D lame name, no number assigned means 0 votes= are just added up and maximum sum option wins. Explanations if you haven't followed thread at the end. BIER-PE - Path Engineering BIER-ET - Explicit Trees BIER-EET - Explicit Engineered Trees BIER-BET - Bit Engineered Trees BIER-BST - Bit Steered Trees BIER-TrE - Tree engineering BIER-ET - Engineered Trees BIER-ST - Steered Trees BIER-ASB - Adjacency Steering Bits (adjacencies are how bits in BIER-PE a= re defined) BIER-AB - Adjacency Bits BIER-SB - Steering Bits (overloads with "Source Block" - never= heard) Thanks, Toerless Explanations: If you have read through the threads with Lou and Deborah, an= d my understanding is correct: Lou desired there to be a new name so BIER-TE the forwarding/steering mecha= nism (this document) is named differently from BIER-TE the larger framework= utilizing TEAS/PCE definition (separate future draft). Lou did not like my "Path Engineering" proposal as the name in the last ver= sion of the doc and felt we should pick a name with Steering/routing-policy= in it. I think usn only steering/routing would be misleading (confused wit= h unicast approaches). Deborah pointed to avoiding confusions in the name with pre-established nam= ed (e.g.: "PE" meaning Provider Edge). Said we should finalize on the name before we as the WG should pass the doc= ument to IESG. And she asked chairs to extend last-call by one more week (u= nrelated). Hence timeout end of next week. _______________________________________________ BIER mailing list BIER@ietf.org https://www.ietf.org/mailman/listinfo/bier From nobody Fri Feb 28 06:23:04 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A6D3A18B3; Fri, 28 Feb 2020 06:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 8EDbH8Q7eWQK; Fri, 28 Feb 2020 06:22:59 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A7D13A18B8; Fri, 28 Feb 2020 06:22:59 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 11129548052; Fri, 28 Feb 2020 15:22:54 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 0AAA8440040; Fri, 28 Feb 2020 15:22:54 +0100 (CET) Date: Fri, 28 Feb 2020 15:22:54 +0100 From: Toerless Eckert To: Dirk Trossen Cc: "bier@ietf.org" , Lou Berger , "bier-ads@ietf.org" , "BRUNGARD, DEBORAH A" , "bier-chairs@ietf.org" Message-ID: <20200228142253.GA44403@faui48f.informatik.uni-erlangen.de> References: <20200227204038.GB23965@faui48f.informatik.uni-erlangen.de> <91BA3A406CA139458B56D8C52EAB227D147F35@lhreml501-mbs> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <91BA3A406CA139458B56D8C52EAB227D147F35@lhreml501-mbs> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 14:23:02 -0000 Sure, Just reply wth the ones you like whether existing or added and give them the weiht you like, e.g.: from your email something like: 5 BIER-PBR (Path Based Routing) 5 BIER-PST (Path based STeering) 3 BIER-PE (Path Engineering) On Fri, Feb 28, 2020 at 07:54:07AM +0000, Dirk Trossen wrote: > Toerless, all, > > May I add to the mix (which might not help) with the proposal for 'path-based routing' (or BIER-PBR) or 'path-based steering' (or BIER-PST)? If you want to keep a two letter acronym, I'd add 'path steering' (rather than path engineering) to the mix. From the below, without considering any alternatives, I'd go for BIER-PE but it comes with the issues like many two letter acronyms, namely the higher 'collision rate' with others. > > Best, > > Dirk > > > > -----Original Message----- > From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Toerless Eckert > Sent: 27 February 2020 21:41 > To: bier@ietf.org > Cc: Lou Berger ; bier-ads@ietf.org; BRUNGARD, DEBORAH A ; bier-chairs@ietf.org > Subject: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) > > Dear WG > > Please chime in with opinions about the following or any new name you like as the new name for BIER-TE. Timeout is deadline for submission of draft before IETF107, when i'll post an update. If you propose a new name try to avoid re-using abbreviations that may be misinterpreted. > > 5 = best name ever, ... 1 = lame name, no number assigned means 0 votes are just added up and maximum sum option wins. > Explanations if you haven't followed thread at the end. > > BIER-PE - Path Engineering > BIER-ET - Explicit Trees > BIER-EET - Explicit Engineered Trees > BIER-BET - Bit Engineered Trees > BIER-BST - Bit Steered Trees > BIER-TrE - Tree engineering > BIER-ET - Engineered Trees > BIER-ST - Steered Trees > > BIER-ASB - Adjacency Steering Bits (adjacencies are how bits in BIER-PE are defined) > BIER-AB - Adjacency Bits > BIER-SB - Steering Bits (overloads with "Source Block" - never heard) > > Thanks, > Toerless > > Explanations: If you have read through the threads with Lou and Deborah, and my understanding is correct: > > Lou desired there to be a new name so BIER-TE the forwarding/steering mechanism (this document) is named differently from BIER-TE the larger framework utilizing TEAS/PCE definition (separate future draft). > > Lou did not like my "Path Engineering" proposal as the name in the last version of the doc and felt we should pick a name with Steering/routing-policy in it. I think usn only steering/routing would be misleading (confused with unicast approaches). > > Deborah pointed to avoiding confusions in the name with pre-established named (e.g.: "PE" meaning Provider Edge). > Said we should finalize on the name before we as the WG should pass the document to IESG. And she asked chairs to extend last-call by one more week (unrelated). Hence timeout end of next week. > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier -- --- tte@cs.fau.de From nobody Fri Feb 28 06:27:07 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930D53A18BA; Fri, 28 Feb 2020 06:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 3MfdamDYFwDr; Fri, 28 Feb 2020 06:27:03 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E25033A18B3; Fri, 28 Feb 2020 06:27:02 -0800 (PST) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 494BEB98A180B43BABB5; Fri, 28 Feb 2020 14:27:01 +0000 (GMT) Received: from LHREML501-MBS.china.huawei.com ([10.201.109.50]) by lhreml701-cah.china.huawei.com ([10.201.108.42]) with mapi id 14.03.0415.000; Fri, 28 Feb 2020 14:27:00 +0000 From: Dirk Trossen To: Toerless Eckert CC: "bier@ietf.org" , Lou Berger , "bier-ads@ietf.org" , "BRUNGARD, DEBORAH A" , "bier-chairs@ietf.org" Thread-Topic: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) Thread-Index: AQHV7a5B9i3JWSo4iEW+r4TQMbNWUqgwOYqwgABwOgCAAABmgA== Date: Fri, 28 Feb 2020 14:26:59 +0000 Message-ID: <91BA3A406CA139458B56D8C52EAB227D148251@lhreml501-mbs> References: <20200227204038.GB23965@faui48f.informatik.uni-erlangen.de> <91BA3A406CA139458B56D8C52EAB227D147F35@lhreml501-mbs> <20200228142253.GA44403@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200228142253.GA44403@faui48f.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.220.96.241] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 14:27:06 -0000 Indeed, I'd go for 5 BIER-PBR, 5 BIER-PBS (or BIER-PST) and 2 for BIER-PE. = The last one is the only one really I like with 'engineering' although I fo= llow the argument that the work is less about the engineering itself but th= e enablement of it.=20 Dirk -----Original Message----- From: Toerless Eckert [mailto:tte@cs.fau.de]=20 Sent: 28 February 2020 15:23 To: Dirk Trossen Cc: bier@ietf.org; Lou Berger ; bier-ads@ietf.org; BRUNGA= RD, DEBORAH A ; bier-chairs@ietf.org Subject: Re: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) Sure, Just reply wth the ones you like whether existing or added and give t= hem the weiht you like, e.g.: from your email something like: 5 BIER-PBR (Path Based Routing) 5 BIER-PST (Path based STeering) 3 BIER-PE (Path Engineering) On Fri, Feb 28, 2020 at 07:54:07AM +0000, Dirk Trossen wrote: > Toerless, all, >=20 > May I add to the mix (which might not help) with the proposal for 'path-b= ased routing' (or BIER-PBR) or 'path-based steering' (or BIER-PST)? If you = want to keep a two letter acronym, I'd add 'path steering' (rather than pat= h engineering) to the mix. From the below, without considering any alternat= ives, I'd go for BIER-PE but it comes with the issues like many two letter = acronyms, namely the higher 'collision rate' with others. >=20 > Best, >=20 > Dirk >=20 >=20 >=20 > -----Original Message----- > From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Toerless Eckert > Sent: 27 February 2020 21:41 > To: bier@ietf.org > Cc: Lou Berger ; bier-ads@ietf.org; BRUNGARD,=20 > DEBORAH A ; bier-chairs@ietf.org > Subject: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) >=20 > Dear WG >=20 > Please chime in with opinions about the following or any new name you lik= e as the new name for BIER-TE. Timeout is deadline for submission of draft = before IETF107, when i'll post an update. If you propose a new name try to = avoid re-using abbreviations that may be misinterpreted. >=20 > 5 =3D best name ever, ... 1 =3D lame name, no number assigned means 0 vot= es are just added up and maximum sum option wins. > Explanations if you haven't followed thread at the end. >=20 > BIER-PE - Path Engineering > BIER-ET - Explicit Trees > BIER-EET - Explicit Engineered Trees > BIER-BET - Bit Engineered Trees > BIER-BST - Bit Steered Trees > BIER-TrE - Tree engineering > BIER-ET - Engineered Trees > BIER-ST - Steered Trees >=20 > BIER-ASB - Adjacency Steering Bits (adjacencies are how bits in BIER-PE= are defined) > BIER-AB - Adjacency Bits > BIER-SB - Steering Bits (overloads with "Source Block" - nev= er heard) >=20 > Thanks, > Toerless >=20 > Explanations: If you have read through the threads with Lou and Deborah, = and my understanding is correct: >=20 > Lou desired there to be a new name so BIER-TE the forwarding/steering mec= hanism (this document) is named differently from BIER-TE the larger framewo= rk utilizing TEAS/PCE definition (separate future draft). >=20 > Lou did not like my "Path Engineering" proposal as the name in the last v= ersion of the doc and felt we should pick a name with Steering/routing-poli= cy in it. I think usn only steering/routing would be misleading (confused w= ith unicast approaches). >=20 > Deborah pointed to avoiding confusions in the name with pre-established n= amed (e.g.: "PE" meaning Provider Edge). > Said we should finalize on the name before we as the WG should pass the d= ocument to IESG. And she asked chairs to extend last-call by one more week = (unrelated). Hence timeout end of next week. >=20 > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier >=20 > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier -- --- tte@cs.fau.de From nobody Fri Feb 28 07:31:20 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE7B3A19A6; Fri, 28 Feb 2020 07:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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=T0+AzFGP; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=vJuW+z2y 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 9X_1MT6Djp3P; Fri, 28 Feb 2020 07:31:16 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70A3E3A1995; Fri, 28 Feb 2020 07:31:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5654; q=dns/txt; s=iport; t=1582903876; x=1584113476; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=LioW0eipLQzuTnXiatYQKGcxI1PfZBGAxqmYq6M4Hbc=; b=T0+AzFGPIEhuy9gm4rIluWBvdFy0gQBaF3hX4eYexRKpmoxqNgA8SJki esrDawG+TgkJpprrI5MJZBYK04H97YWyNY2JlHT3ubIaIJSHcCCgBNX3X uGCe3GKR4p3WimGaycQOo/nsvFbPlmZoz4/Yqyh+FHHxZ4QAwzrvblcEp 8=; IronPort-PHdr: =?us-ascii?q?9a23=3AKIupWxGDf3seRZhnW0lHZJ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4w0Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjyJ/PnRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CCAACaMVle/5FdJa1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBEQEBAQEBAQEBAQEBgXuBVFAFbFggBAsqCoQKg0YDimaCX5g?= =?us-ascii?q?VgUKBEANUCQEBAQwBARgLCgIEAQGEQAIXgXMkOBMCAw0BAQUBAQECAQUEbYV?= =?us-ascii?q?WDIVjAQEBAQMBARAREQwBASwLAQsEAgEIDgMEAQEBAgIjAwICAiULFAEICAI?= =?us-ascii?q?EAQ0FIoMEAYJKAy4BDqMIAoE5iGJ1gTKCfwEBBYUDGIIMAwaBDiqMJRqCAIE?= =?us-ascii?q?QAScggk0+gmQBAYErBQESAUeCazKCLI1Mgl47hhSZJgqCPJZlHIJJiB+ETYt?= =?us-ascii?q?8jnCBTZl7AgQCBAUCDgEBBYFpImdxcBU7KgGCQVAYDVeNRgwXg1CFFIVBdIE?= =?us-ascii?q?pjQUBgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.70,496,1574121600"; d="scan'208";a="438773972" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Feb 2020 15:31:15 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 01SFVFFf016411 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Feb 2020 15:31:15 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 28 Feb 2020 09:31:14 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 28 Feb 2020 10:31:09 -0500 Received: from NAM10-DM6-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; Fri, 28 Feb 2020 10:31:09 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kzUkTPq/u37kmxU8wbYnpkpF5958xUmDLDTXyNrQFvhhLeRbOX8lBRJIQPedwtMnHH7SX0ATeA4uKNXmBu5PbRZNPofSaOCyFqCRZhiRQZ4/VYAIFwjCvOtiISXFBqmF4rndd32QgH9mM/B3uybMigyWZNY6wcG1Eivm8OCDd6bTr8VcnUBNIk0KRBx8wR9wO/J4g2oIvR3YUJU0H5qzBPbgowgzwmCkLlczGMPKWz9QNDUL7tTnnfMkWsHYKl9IYrO6HRfB25VqWZxIVYPyFseFNfp1Ov48yD0n5yj8vIcXzRtu9Wuc0QIYTLfhoiPqURGiBP0khbm89PR77tR18w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LioW0eipLQzuTnXiatYQKGcxI1PfZBGAxqmYq6M4Hbc=; b=WyZd5DBMyTUS/5rrxMCcK3QOmZO08JcdCZN9FndrUSX4j1oFHbPEKYvOQQWy0DCTUxzLdu8hT6YVmVDNXjc2PccIU+IlbpyMzqkW92W87d6kUwHuY2StTNHr9KiKG1rkJBQ28jhkxPJltOFjlnZXdwr8Szbw+V6winD35lM8KKpDH2ZTmJcB0qHe/SzdnYI7elnyzMzecu7TrpHEdsKGxwBPNLK7Pi8IWYcM/RLEtNaE/Hu398HJCFs/YL3jq7qlYc+7OYZLCwdXYbgp8lMe8pgqh6GzSmUq3wDRfqETtwXocZpCIjN1KDuhp4lK3DEvXhhACHAgMz7/ZlFLIgVbMQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; 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=LioW0eipLQzuTnXiatYQKGcxI1PfZBGAxqmYq6M4Hbc=; b=vJuW+z2y91O3Lcp2EaOAoq1rdvh9qxhBK0eCH2WBH7dUzGdmIxI5epS2MBvcB5aNEKgR60ESFa94nn4KLBWPFjoB/6Ew/5uM6wyQ/29O70WvzAmLd/R+k7H6X0EIFDFOTgkOktqjA4aWTeDjY3zSksk+8/elFiDfbcWUkh3tOVk= Received: from BN8PR11MB3794.namprd11.prod.outlook.com (2603:10b6:408:8f::13) by BN8PR11MB3827.namprd11.prod.outlook.com (2603:10b6:408:90::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14; Fri, 28 Feb 2020 15:31:08 +0000 Received: from BN8PR11MB3794.namprd11.prod.outlook.com ([fe80::d939:a6fb:475:cddd]) by BN8PR11MB3794.namprd11.prod.outlook.com ([fe80::d939:a6fb:475:cddd%4]) with mapi id 15.20.2772.012; Fri, 28 Feb 2020 15:31:08 +0000 From: "Acee Lindem (acee)" To: Toerless Eckert , Dirk Trossen CC: "bier@ietf.org" , "bier-ads@ietf.org" , "BRUNGARD, DEBORAH A" , Lou Berger , "bier-chairs@ietf.org" Thread-Topic: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) Thread-Index: AQHV7a45vVgnND9+2EGrrFVSzkINWqgwPSSAgABsoAD//78+gA== Date: Fri, 28 Feb 2020 15:31:08 +0000 Message-ID: <5A558653-37FD-4D0B-A637-8F0078D91C81@cisco.com> References: <20200227204038.GB23965@faui48f.informatik.uni-erlangen.de> <91BA3A406CA139458B56D8C52EAB227D147F35@lhreml501-mbs> <20200228142253.GA44403@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200228142253.GA44403@faui48f.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com; x-originating-ip: [65.190.53.159] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 477a3aef-ac71-40be-2698-08d7bc633bb0 x-ms-traffictypediagnostic: BN8PR11MB3827: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0327618309 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(366004)(346002)(396003)(376002)(189003)(199004)(2906002)(966005)(54906003)(8676002)(4326008)(2616005)(64756008)(66446008)(36756003)(76116006)(8936002)(66946007)(66476007)(66556008)(110136005)(81166006)(81156014)(6506007)(478600001)(26005)(53546011)(33656002)(186003)(5660300002)(71200400001)(86362001)(6486002)(6512007)(316002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR11MB3827; H:BN8PR11MB3794.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: BCL:0; x-microsoft-antispam-message-info: wmVIRwJLMNHVM6uabFMbU1QuD68rzxUVAYj/HFFD3ZEAZJTaPK/7BZttmGNZNyhQal5MxNENyVshYEOiNcbk10Bd1PURQpVTWiEVfoYNu4VYjDwAGGTjvfTY2vVZBELrJxtUafKk103h+Qf7aKNs85TEEWT2o37BHYb8Io1Y4rCfmzR27ntpoByp7PTeo9HRMA0oT+98YLzQZgiStFph39VEg26HXvcjHVosGvkhk88e7Ac4TgJdyXdgbfHpvK8Yygu1VDtphH3rA37jX2rZ0gxLmPKgfsohsMyUnYlD1BesVUPYc/u/zILyjjqLqybJj5j+lIF5YFYx2DdSVsK+w7RlT88AuPe+rKMQzpsrC+z9jOOB/N0jTGUm8KGk2zefGXL+YAA2U0cCPaiuNf1sLnGXtyL9n/+yUxM5I9cuhxHNHUxk1jrqSQ8DH47tbkoBpeifl5TmuxYq1gqaeYUjDxbIDOuy2gF9HHhznApMalyNn/ZcXzsXqk7D6H3cYs4yTuXl+12fhUTMKOUVseDo3w== x-ms-exchange-antispam-messagedata: C/Sqyxl2Qz6Ud3CWrECn2VUI3Y6Fs9IytCrz0g53j74uBBypoVHNNwI/YRQqsDicHHjegtlgHi4WAqDJx6MgPfDRxouSIKr4AqAN7Jl7m8SIJA38+ufgiRbDlF1IOCuJ7sj7/KAjMQyVqp06M1ypzQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 477a3aef-ac71-40be-2698-08d7bc633bb0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2020 15:31:08.3439 (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: rehJODAQcjujuCdzXZT/47zZxcy035dggSfwhOHcx0Us32B/HTOVJ8L0EP4SO2TS X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3827 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 15:31:19 -0000 SWYgeW91IGdvIHdpdGggUEJSLCB5b3UgY291bGQgY29udGludWUgdGhlIEJJRVIgV0cgdHJhZGl0 aW9uYWwgb2Ygc2VsZWN0aW5nIGJyZXctYmFzZWQgYWNyb255bXMuIEhlbmNlLCB0aGF0IHdvdWxk IGJlIG15IHZvdGUuIEl0IGNvdWxkIGJlIGNvbmZ1c2VkIHdpdGggUG9saWN5IEJhc2VkIFJvdXRp bmcgYnV0IG9ubHkgaWYgc29tZW9uZSBhY3R1YWxseSBpbXBsZW1lbnRzIGl0Lg0KVGhhbmtzLA0K QWNlZQ0KDQrvu79PbiAyLzI4LzIwLCA5OjIzIEFNLCAiQklFUiBvbiBiZWhhbGYgb2YgVG9lcmxl c3MgRWNrZXJ0IiA8Ymllci1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiB0dGVAY3MuZmF1 LmRlPiB3cm90ZToNCg0KICAgIFN1cmUsIEp1c3QgcmVwbHkgd3RoIHRoZSBvbmVzIHlvdSBsaWtl IHdoZXRoZXIgZXhpc3Rpbmcgb3IgYWRkZWQgYW5kDQogICAgZ2l2ZSB0aGVtIHRoZSB3ZWlodCB5 b3UgbGlrZSwgZS5nLjogZnJvbSB5b3VyIGVtYWlsIHNvbWV0aGluZyBsaWtlOg0KICAgIA0KICAg IDUgIEJJRVItUEJSICAgIChQYXRoIEJhc2VkIFJvdXRpbmcpDQogICAgNSAgQklFUi1QU1QgICAg KFBhdGggYmFzZWQgU1RlZXJpbmcpDQogICAgMyAgQklFUi1QRSAgICAgKFBhdGggRW5naW5lZXJp bmcpDQogICAgDQogICAgT24gRnJpLCBGZWIgMjgsIDIwMjAgYXQgMDc6NTQ6MDdBTSArMDAwMCwg RGlyayBUcm9zc2VuIHdyb3RlOg0KICAgID4gVG9lcmxlc3MsIGFsbCwNCiAgICA+IA0KICAgID4g TWF5IEkgYWRkIHRvIHRoZSBtaXggKHdoaWNoIG1pZ2h0IG5vdCBoZWxwKSB3aXRoIHRoZSBwcm9w b3NhbCBmb3IgJ3BhdGgtYmFzZWQgcm91dGluZycgKG9yIEJJRVItUEJSKSBvciAncGF0aC1iYXNl ZCBzdGVlcmluZycgKG9yIEJJRVItUFNUKT8gSWYgeW91IHdhbnQgdG8ga2VlcCBhIHR3byBsZXR0 ZXIgYWNyb255bSwgSSdkIGFkZCAncGF0aCBzdGVlcmluZycgKHJhdGhlciB0aGFuIHBhdGggZW5n aW5lZXJpbmcpIHRvIHRoZSBtaXguIEZyb20gdGhlIGJlbG93LCB3aXRob3V0IGNvbnNpZGVyaW5n IGFueSBhbHRlcm5hdGl2ZXMsIEknZCBnbyBmb3IgQklFUi1QRSBidXQgaXQgY29tZXMgd2l0aCB0 aGUgaXNzdWVzIGxpa2UgbWFueSB0d28gbGV0dGVyIGFjcm9ueW1zLCBuYW1lbHkgdGhlIGhpZ2hl ciAnY29sbGlzaW9uIHJhdGUnIHdpdGggb3RoZXJzLg0KICAgID4gDQogICAgPiBCZXN0LA0KICAg ID4gDQogICAgPiBEaXJrDQogICAgPiANCiAgICA+IA0KICAgID4gDQogICAgPiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KICAgID4gRnJvbTogQklFUiBbbWFpbHRvOmJpZXItYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRvZXJsZXNzIEVja2VydA0KICAgID4gU2VudDogMjcgRmVi cnVhcnkgMjAyMCAyMTo0MQ0KICAgID4gVG86IGJpZXJAaWV0Zi5vcmcNCiAgICA+IENjOiBMb3Ug QmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0PjsgYmllci1hZHNAaWV0Zi5vcmc7IEJSVU5HQVJELCBE RUJPUkFIIEEgPGRiMzU0NkBhdHQuY29tPjsgYmllci1jaGFpcnNAaWV0Zi5vcmcNCiAgICA+IFN1 YmplY3Q6IFtCaWVyXSBQbHMgInZvdGUiIG9uIG5hbWUgKGRyYWZ0LWlldGYtYmllci10ZS1hcmNo KQ0KICAgID4gDQogICAgPiBEZWFyIFdHDQogICAgPiANCiAgICA+IFBsZWFzZSBjaGltZSBpbiB3 aXRoIG9waW5pb25zIGFib3V0IHRoZSBmb2xsb3dpbmcgb3IgYW55IG5ldyBuYW1lIHlvdSBsaWtl IGFzIHRoZSBuZXcgbmFtZSBmb3IgQklFUi1URS4gVGltZW91dCBpcyBkZWFkbGluZSBmb3Igc3Vi bWlzc2lvbiBvZiBkcmFmdCBiZWZvcmUgSUVURjEwNywgd2hlbiBpJ2xsIHBvc3QgYW4gdXBkYXRl LiBJZiB5b3UgcHJvcG9zZSBhIG5ldyBuYW1lIHRyeSB0byBhdm9pZCByZS11c2luZyBhYmJyZXZp YXRpb25zIHRoYXQgbWF5IGJlIG1pc2ludGVycHJldGVkLg0KICAgID4gDQogICAgPiA1ID0gYmVz dCBuYW1lIGV2ZXIsIC4uLiAxID0gbGFtZSBuYW1lLCBubyBudW1iZXIgYXNzaWduZWQgbWVhbnMg MCB2b3RlcyBhcmUganVzdCBhZGRlZCB1cCBhbmQgbWF4aW11bSBzdW0gb3B0aW9uIHdpbnMuDQog ICAgPiBFeHBsYW5hdGlvbnMgaWYgeW91IGhhdmVuJ3QgZm9sbG93ZWQgdGhyZWFkIGF0IHRoZSBl bmQuDQogICAgPiANCiAgICA+IEJJRVItUEUgIC0gUGF0aCBFbmdpbmVlcmluZw0KICAgID4gQklF Ui1FVCAgLSBFeHBsaWNpdCBUcmVlcw0KICAgID4gQklFUi1FRVQgLSBFeHBsaWNpdCBFbmdpbmVl cmVkIFRyZWVzDQogICAgPiBCSUVSLUJFVCAtIEJpdCBFbmdpbmVlcmVkIFRyZWVzDQogICAgPiBC SUVSLUJTVCAtIEJpdCBTdGVlcmVkIFRyZWVzDQogICAgPiBCSUVSLVRyRSAtIFRyZWUgZW5naW5l ZXJpbmcNCiAgICA+IEJJRVItRVQgIC0gRW5naW5lZXJlZCBUcmVlcw0KICAgID4gQklFUi1TVCAg LSBTdGVlcmVkIFRyZWVzDQogICAgPiANCiAgICA+IEJJRVItQVNCIC0gQWRqYWNlbmN5IFN0ZWVy aW5nIEJpdHMgICAoYWRqYWNlbmNpZXMgYXJlIGhvdyBiaXRzIGluIEJJRVItUEUgYXJlIGRlZmlu ZWQpDQogICAgPiBCSUVSLUFCICAtIEFkamFjZW5jeSBCaXRzDQogICAgPiBCSUVSLVNCICAtIFN0 ZWVyaW5nIEJpdHMgICAgICAgICAgICAgKG92ZXJsb2FkcyB3aXRoICJTb3VyY2UgQmxvY2siIC0g bmV2ZXIgaGVhcmQpDQogICAgPiANCiAgICA+IFRoYW5rcywNCiAgICA+ICAgICBUb2VybGVzcw0K ICAgID4gDQogICAgPiBFeHBsYW5hdGlvbnM6IElmIHlvdSBoYXZlIHJlYWQgdGhyb3VnaCB0aGUg dGhyZWFkcyB3aXRoIExvdSBhbmQgRGVib3JhaCwgYW5kIG15IHVuZGVyc3RhbmRpbmcgaXMgY29y cmVjdDoNCiAgICA+IA0KICAgID4gTG91IGRlc2lyZWQgdGhlcmUgdG8gYmUgYSBuZXcgbmFtZSBz byBCSUVSLVRFIHRoZSBmb3J3YXJkaW5nL3N0ZWVyaW5nIG1lY2hhbmlzbSAodGhpcyBkb2N1bWVu dCkgaXMgbmFtZWQgZGlmZmVyZW50bHkgZnJvbSBCSUVSLVRFIHRoZSBsYXJnZXIgZnJhbWV3b3Jr IHV0aWxpemluZyBURUFTL1BDRSBkZWZpbml0aW9uIChzZXBhcmF0ZSBmdXR1cmUgZHJhZnQpLg0K ICAgID4gDQogICAgPiBMb3UgZGlkIG5vdCBsaWtlIG15ICJQYXRoIEVuZ2luZWVyaW5nIiBwcm9w b3NhbCBhcyB0aGUgbmFtZSBpbiB0aGUgbGFzdCB2ZXJzaW9uIG9mIHRoZSBkb2MgYW5kIGZlbHQg d2Ugc2hvdWxkIHBpY2sgYSBuYW1lIHdpdGggU3RlZXJpbmcvcm91dGluZy1wb2xpY3kgaW4gaXQu IEkgdGhpbmsgdXNuIG9ubHkgc3RlZXJpbmcvcm91dGluZyB3b3VsZCBiZSBtaXNsZWFkaW5nIChj b25mdXNlZCB3aXRoIHVuaWNhc3QgYXBwcm9hY2hlcykuDQogICAgPiANCiAgICA+IERlYm9yYWgg cG9pbnRlZCB0byBhdm9pZGluZyBjb25mdXNpb25zIGluIHRoZSBuYW1lIHdpdGggcHJlLWVzdGFi bGlzaGVkIG5hbWVkIChlLmcuOiAiUEUiIG1lYW5pbmcgUHJvdmlkZXIgRWRnZSkuDQogICAgPiBT YWlkIHdlIHNob3VsZCBmaW5hbGl6ZSBvbiB0aGUgbmFtZSBiZWZvcmUgd2UgYXMgdGhlIFdHIHNo b3VsZCBwYXNzIHRoZSBkb2N1bWVudCB0byBJRVNHLiBBbmQgc2hlIGFza2VkIGNoYWlycyB0byBl eHRlbmQgbGFzdC1jYWxsIGJ5IG9uZSBtb3JlIHdlZWsgKHVucmVsYXRlZCkuIEhlbmNlIHRpbWVv dXQgZW5kIG9mIG5leHQgd2Vlay4NCiAgICA+IA0KICAgID4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IEJJRVIgbWFpbGluZyBsaXN0DQogICAg PiBCSUVSQGlldGYub3JnDQogICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2JpZXINCiAgICA+IA0KICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCiAgICA+IEJJRVIgbWFpbGluZyBsaXN0DQogICAgPiBCSUVSQGlldGYu b3JnDQogICAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JpZXINCiAg ICANCiAgICAtLSANCiAgICAtLS0NCiAgICB0dGVAY3MuZmF1LmRlDQogICAgDQogICAgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBCSUVSIG1haWxp bmcgbGlzdA0KICAgIEJJRVJAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2JpZXINCiAgICANCg0K From nobody Fri Feb 28 08:00:37 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E797A3A1AB4; Fri, 28 Feb 2020 08:00:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 aKJ-uEDPYCSw; Fri, 28 Feb 2020 08:00:33 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 2FC113A1AD0; Fri, 28 Feb 2020 08:00:33 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id b5so3384173qkh.8; Fri, 28 Feb 2020 08:00:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=I0nrZmuUF+SXqjk+Wvb0vUekHNRMc6FK89uh1Hp6ERU=; b=GLcZLYPa5+P2aUioa0e0hYs9vrCPagDu7aNBeOxgJZSjZ3FroAFM3CtlV09XMARgKe VY536mlpEkfxF885+wfs3Gif6LXmn+ll0SILJOeORYwoj7+5z16pynISCiRk6imncnSO GMzoiU8eLgvRLOI+LeaxCWlJPL8iQQGf95JcNVOt+WDpU87TJV7HhaI5oHCuhtmh/EMX eX06jZyAfA7XEQoK5lUgnCWhdugIVWDz0MZfr7VVOVYaklUaQ/J3oFsxpGX77VK7Vbgm kHKzaNiEXQDvYyoSQm0zFlGC/xAKeRi3DIGzeTUpzuDLdxvThO8hRmMarpsfzN6HNAn6 dTQA== 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:reply-to :from:date:message-id:subject:to:cc; bh=I0nrZmuUF+SXqjk+Wvb0vUekHNRMc6FK89uh1Hp6ERU=; b=KHQCAArI3XJfKbGumvfO6hOclfwi7QMmJLYlaO1N7Ja5kTJ6b8/DuQNtAFLODtKReg rYHucE71I6BFoXTDEzUnX9EFIHjDmM6bCfLqDFIWYvao63Rvq4iHSaLT7q77hwNi+Gku 0vVQDsIFKNDFObhMf8P4Rvwf1JzdV2aZ1xwX7pn0l+wM9HuBu0QynlYjomfYC1xi7I/N XMnNnmBbZCafLhavb6efIvk+tCcG6UW49AfLllLs42QIOzvMIC5EKieB267ByCBwk/AV t7M5D0l9GXFUcdjxe81h+Q0gjt10mx68O1rmiiRLAa/uL+r3t7mc86IDGPWeY9S0RqC6 X+Wg== X-Gm-Message-State: APjAAAV5sKJlF/E62SfYVsGOV9yJxXhGRdmAdmMKjYsoL2n4yvToXD+W WooznbZir7S7O7KaAa/8hMW4FxbBZ+k01QU4eoo= X-Google-Smtp-Source: APXvYqxtSuexX1GhyV3LUkJTkkDIiE+NhzoDFnqwPqI+8iFzvs2NDf1HHBbrtrQRSu/yWwBOruSZ11p5FZ5myvvj07E= X-Received: by 2002:a37:e30d:: with SMTP id y13mr4929642qki.72.1582905632217; Fri, 28 Feb 2020 08:00:32 -0800 (PST) MIME-Version: 1.0 References: <20200227204038.GB23965@faui48f.informatik.uni-erlangen.de> <91BA3A406CA139458B56D8C52EAB227D147F35@lhreml501-mbs> <20200228142253.GA44403@faui48f.informatik.uni-erlangen.de> <5A558653-37FD-4D0B-A637-8F0078D91C81@cisco.com> In-Reply-To: <5A558653-37FD-4D0B-A637-8F0078D91C81@cisco.com> Reply-To: gjshep@gmail.com From: Greg Shepherd Date: Fri, 28 Feb 2020 08:00:21 -0800 Message-ID: To: "Acee Lindem (acee)" Cc: Toerless Eckert , Dirk Trossen , "bier@ietf.org" , "bier-ads@ietf.org" , "BRUNGARD, DEBORAH A" , Lou Berger , "bier-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ebde85059fa4ef9e" Archived-At: Subject: Re: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 16:00:36 -0000 --000000000000ebde85059fa4ef9e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable My vote: BIER-TE Call it Tree Engineering. If we were so concerned with acronym overuse the IETF would grind to a halt. I've been involved in other WGs where I felt the name missed the mark describing the ideas in the draft, but felt reading the draft was how someone got their heads around the proposed solution, rather than miss-read the title and run away confused. ie - Vlex-Algo. No, it's Flex-Topo, but what's to be gained from arguing for a name at this point? Yes, we should strive to be as 'correct' as possible. But the IETF is full of baggage that engineers have managed to wade through, make sense of, and implement successfully. Get the spec right, No #1 priority. If you don't like the name, read on. It will grow on you. :) Shep (w/o chair hat) On Fri, Feb 28, 2020 at 7:31 AM Acee Lindem (acee) wrote: > If you go with PBR, you could continue the BIER WG traditional of > selecting brew-based acronyms. Hence, that would be my vote. It could be > confused with Policy Based Routing but only if someone actually implement= s > it. > Thanks, > Acee > > =EF=BB=BFOn 2/28/20, 9:23 AM, "BIER on behalf of Toerless Eckert" < > bier-bounces@ietf.org on behalf of tte@cs.fau.de> wrote: > > Sure, Just reply wth the ones you like whether existing or added and > give them the weiht you like, e.g.: from your email something like: > > 5 BIER-PBR (Path Based Routing) > 5 BIER-PST (Path based STeering) > 3 BIER-PE (Path Engineering) > > On Fri, Feb 28, 2020 at 07:54:07AM +0000, Dirk Trossen wrote: > > Toerless, all, > > > > May I add to the mix (which might not help) with the proposal for > 'path-based routing' (or BIER-PBR) or 'path-based steering' (or BIER-PST)= ? > If you want to keep a two letter acronym, I'd add 'path steering' (rather > than path engineering) to the mix. From the below, without considering an= y > alternatives, I'd go for BIER-PE but it comes with the issues like many t= wo > letter acronyms, namely the higher 'collision rate' with others. > > > > Best, > > > > Dirk > > > > > > > > -----Original Message----- > > From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Toerless > Eckert > > Sent: 27 February 2020 21:41 > > To: bier@ietf.org > > Cc: Lou Berger ; bier-ads@ietf.org; BRUNGARD, > DEBORAH A ; bier-chairs@ietf.org > > Subject: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) > > > > Dear WG > > > > Please chime in with opinions about the following or any new name > you like as the new name for BIER-TE. Timeout is deadline for submission = of > draft before IETF107, when i'll post an update. If you propose a new name > try to avoid re-using abbreviations that may be misinterpreted. > > > > 5 =3D best name ever, ... 1 =3D lame name, no number assigned means= 0 > votes are just added up and maximum sum option wins. > > Explanations if you haven't followed thread at the end. > > > > BIER-PE - Path Engineering > > BIER-ET - Explicit Trees > > BIER-EET - Explicit Engineered Trees > > BIER-BET - Bit Engineered Trees > > BIER-BST - Bit Steered Trees > > BIER-TrE - Tree engineering > > BIER-ET - Engineered Trees > > BIER-ST - Steered Trees > > > > BIER-ASB - Adjacency Steering Bits (adjacencies are how bits in > BIER-PE are defined) > > BIER-AB - Adjacency Bits > > BIER-SB - Steering Bits (overloads with "Source Block" > - never heard) > > > > Thanks, > > Toerless > > > > Explanations: If you have read through the threads with Lou and > Deborah, and my understanding is correct: > > > > Lou desired there to be a new name so BIER-TE the > forwarding/steering mechanism (this document) is named differently from > BIER-TE the larger framework utilizing TEAS/PCE definition (separate futu= re > draft). > > > > Lou did not like my "Path Engineering" proposal as the name in the > last version of the doc and felt we should pick a name with > Steering/routing-policy in it. I think usn only steering/routing would be > misleading (confused with unicast approaches). > > > > Deborah pointed to avoiding confusions in the name with > pre-established named (e.g.: "PE" meaning Provider Edge). > > Said we should finalize on the name before we as the WG should pass > the document to IESG. And she asked chairs to extend last-call by one mor= e > week (unrelated). Hence timeout end of next week. > > > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org > > https://www.ietf.org/mailman/listinfo/bier > > > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org > > https://www.ietf.org/mailman/listinfo/bier > > -- > --- > tte@cs.fau.de > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > > > --000000000000ebde85059fa4ef9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
My vote: BIER-TE=C2=A0
Call it Tree Engineering. If we= were so concerned=C2=A0with acronym overuse the IETF would grind to a halt= . I've been involved in other WGs where I felt the name missed the mark= describing the ideas in the draft, but felt reading the draft was how some= one got their heads around the proposed solution, rather than miss-read the= title and run away confused. ie - Vlex-Algo. No, it's Flex-Topo, but w= hat's to be gained from arguing for a name at this point?=C2=A0

Yes, we should strive=C2=A0to be as 'correct' as = possible. But the IETF is full of baggage that engineers have managed to wa= de through, make sense of, and implement successfully. Get the spec right, = No #1 priority. If you don't like the name, read on. It will grow on yo= u. :)

Shep (w/o chair hat)

On Fri, Feb 28, 20= 20 at 7:31 AM Acee Lindem (acee) <acee= @cisco.com> wrote:
If you go with PBR, yo= u could continue the BIER WG traditional of selecting brew-based acronyms. = Hence, that would be my vote. It could be confused with Policy Based Routin= g but only if someone actually implements it.
Thanks,
Acee

=EF=BB=BFOn 2/28/20, 9:23 AM, "BIER on behalf of Toerless Eckert"= <bier-bounce= s@ietf.org on behalf of tte@cs.fau.de> wrote:

=C2=A0 =C2=A0 Sure, Just reply wth the ones you like whether existing or ad= ded and
=C2=A0 =C2=A0 give them the weiht you like, e.g.: from your email something= like:

=C2=A0 =C2=A0 5=C2=A0 BIER-PBR=C2=A0 =C2=A0 (Path Based Routing)
=C2=A0 =C2=A0 5=C2=A0 BIER-PST=C2=A0 =C2=A0 (Path based STeering)
=C2=A0 =C2=A0 3=C2=A0 BIER-PE=C2=A0 =C2=A0 =C2=A0(Path Engineering)

=C2=A0 =C2=A0 On Fri, Feb 28, 2020 at 07:54:07AM +0000, Dirk Trossen wrote:=
=C2=A0 =C2=A0 > Toerless, all,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > May I add to the mix (which might not help) with the pro= posal for 'path-based routing' (or BIER-PBR) or 'path-based ste= ering' (or BIER-PST)? If you want to keep a two letter acronym, I'd= add 'path steering' (rather than path engineering) to the mix. Fro= m the below, without considering any alternatives, I'd go for BIER-PE b= ut it comes with the issues like many two letter acronyms, namely the highe= r 'collision rate' with others.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Best,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Dirk
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > -----Original Message-----
=C2=A0 =C2=A0 > From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Toerless Ecke= rt
=C2=A0 =C2=A0 > Sent: 27 February 2020 21:41
=C2=A0 =C2=A0 > To: b= ier@ietf.org
=C2=A0 =C2=A0 > Cc: Lou Berger <lberger@labn.net>; bier-ads@ietf.org; BRUNGARD, DEBORAH A <db3546@att.com>; bier-chairs@ietf.org<= /a>
=C2=A0 =C2=A0 > Subject: [Bier] Pls "vote" on name (draft-ietf= -bier-te-arch)
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Dear WG
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Please chime in with opinions about the following or any= new name you like as the new name for BIER-TE. Timeout is deadline for sub= mission of draft before IETF107, when i'll post an update. If you propo= se a new name try to avoid re-using abbreviations that may be misinterprete= d.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > 5 =3D best name ever, ... 1 =3D lame name, no number ass= igned means 0 votes are just added up and maximum sum option wins.
=C2=A0 =C2=A0 > Explanations if you haven't followed thread at the e= nd.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > BIER-PE=C2=A0 - Path Engineering
=C2=A0 =C2=A0 > BIER-ET=C2=A0 - Explicit Trees
=C2=A0 =C2=A0 > BIER-EET - Explicit Engineered Trees
=C2=A0 =C2=A0 > BIER-BET - Bit Engineered Trees
=C2=A0 =C2=A0 > BIER-BST - Bit Steered Trees
=C2=A0 =C2=A0 > BIER-TrE - Tree engineering
=C2=A0 =C2=A0 > BIER-ET=C2=A0 - Engineered Trees
=C2=A0 =C2=A0 > BIER-ST=C2=A0 - Steered Trees
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > BIER-ASB - Adjacency Steering Bits=C2=A0 =C2=A0(adjacenc= ies are how bits in BIER-PE are defined)
=C2=A0 =C2=A0 > BIER-AB=C2=A0 - Adjacency Bits
=C2=A0 =C2=A0 > BIER-SB=C2=A0 - Steering Bits=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0(overloads with "Source Block" - never heard= )
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Thanks,
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Toerless
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Explanations: If you have read through the threads with = Lou and Deborah, and my understanding is correct:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Lou desired there to be a new name so BIER-TE the forwar= ding/steering mechanism (this document) is named differently from BIER-TE t= he larger framework utilizing TEAS/PCE definition (separate future draft).<= br> =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Lou did not like my "Path Engineering" proposa= l as the name in the last version of the doc and felt we should pick a name= with Steering/routing-policy in it. I think usn only steering/routing woul= d be misleading (confused with unicast approaches).
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Deborah pointed to avoiding confusions in the name with = pre-established named (e.g.: "PE" meaning Provider Edge).
=C2=A0 =C2=A0 > Said we should finalize on the name before we as the WG = should pass the document to IESG. And she asked chairs to extend last-call = by one more week (unrelated). Hence timeout end of next week.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > BIER mailing list
=C2=A0 =C2=A0 > BIER@= ietf.org
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/b= ier
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > BIER mailing list
=C2=A0 =C2=A0 > BIER@= ietf.org
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/b= ier

=C2=A0 =C2=A0 --
=C2=A0 =C2=A0 ---
=C2=A0 =C2=A0 tte@cs.fau= .de

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 BIER mailing list
=C2=A0 =C2=A0 BIER@ietf.= org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/bier


--000000000000ebde85059fa4ef9e-- From nobody Fri Feb 28 08:02:34 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4332A3A1ACE; Fri, 28 Feb 2020 08:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 581Gy61I-mmS; Fri, 28 Feb 2020 08:02:29 -0800 (PST) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 C8C663A1AC6; Fri, 28 Feb 2020 08:02:29 -0800 (PST) Received: by mail-il1-x12c.google.com with SMTP id f10so3117262ils.8; Fri, 28 Feb 2020 08:02:29 -0800 (PST) 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=3krz2sytxrCbqKfrS6McSwmTRbTv0s/QzKuu/2Mbz6U=; b=IOL5LQfBpYnQjHrBXkYKiu9xu7I33pYu4/5gnj2Kd6iWXKM0iSZDY6AIHKyT5PaX19 JmA/jS8sNG9IUu1eVx0cN/OMBwhbRS/OHk82doGsYQ9kadRGqwPDBSLLigUgbfm+P/4T ZWOEGCzexsR0Yk2zI9nYlI5xWVlKYQzf+CPS2G9TpFrGg8QYhEtikaJ6RY7oS0g2CPTY OuWCSTeT6AW6X8Ns1CoueCz/KeM0PGe4IEtiF199cdylFC907iDLUi3E0XpcAXeyJEc4 UaTqZYLWJJkYBPIpIDYybnGK1vbUqbp3lHpSDQeHYgIe0lnc6K6CeCb8/rrNFpLiT+kF Qs4w== 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=3krz2sytxrCbqKfrS6McSwmTRbTv0s/QzKuu/2Mbz6U=; b=ZVWpYtem4Tx9tjS3KwtGYmVD2tJN68AIQF78ya7LHPeaDSPPQk772RnFn5UuVbUhkZ GW3X74S1f3e9OeGPfdVlDBDPd2S8U7Ut9EhA3ya/8XSpaxo05Hc74lFrUBM1+Irwv7SW /3RxEty2AM42faPPKmU2MAoOc6kHzgITBHfcaURrMAJbv4nE0+xjVaFZ+mFystVC85JJ opvihElCD0cW0e3yFtQEr0z5JjgwCHYWsPXDkuv2k0GnmVsl7MSyoLI2p2mJtF8EfyLb zvxkrIl2vseI80D/kO7AEZr2ZqbAoD5NVpDolckU/yaJoIE5qEaPA4vHfY1aeff0Ch0P rmBg== X-Gm-Message-State: APjAAAWoO7/ffxZ2TGBOSiJPZZ174t0N3u4DyUI8gBPDkILfuegJJYcw 41iO9G4HZxF1Ezh/GoAbgLkBAfz1V9bEFzesPvs= X-Google-Smtp-Source: APXvYqwwcicAsoRfe0LdqoY6szavIO/dfbJf94PnOIWFdjn43Zg2VfmbUaWoCKg3RZZ3tYdoIK/uzjAXm8xB4VodZ/s= X-Received: by 2002:a92:3989:: with SMTP id h9mr4768747ilf.156.1582905749036; Fri, 28 Feb 2020 08:02:29 -0800 (PST) MIME-Version: 1.0 References: <20200227204038.GB23965@faui48f.informatik.uni-erlangen.de> <91BA3A406CA139458B56D8C52EAB227D147F35@lhreml501-mbs> <20200228142253.GA44403@faui48f.informatik.uni-erlangen.de> <5A558653-37FD-4D0B-A637-8F0078D91C81@cisco.com> In-Reply-To: From: Tony Przygienda Date: Fri, 28 Feb 2020 08:01:24 -0800 Message-ID: To: Greg Shepherd Cc: "Acee Lindem (acee)" , Toerless Eckert , Dirk Trossen , "bier@ietf.org" , "bier-ads@ietf.org" , "BRUNGARD, DEBORAH A" , Lou Berger , "bier-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e264a3059fa4f608" Archived-At: Subject: Re: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 16:02:32 -0000 --000000000000e264a3059fa4f608 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yepp, I concur with Greg ... tony On Fri, Feb 28, 2020 at 8:00 AM Greg Shepherd wrote: > My vote: BIER-TE > Call it Tree Engineering. If we were so concerned with acronym overuse th= e > IETF would grind to a halt. I've been involved in other WGs where I felt > the name missed the mark describing the ideas in the draft, but felt > reading the draft was how someone got their heads around the proposed > solution, rather than miss-read the title and run away confused. ie - > Vlex-Algo. No, it's Flex-Topo, but what's to be gained from arguing for a > name at this point? > > Yes, we should strive to be as 'correct' as possible. But the IETF is ful= l > of baggage that engineers have managed to wade through, make sense of, an= d > implement successfully. Get the spec right, No #1 priority. If you don't > like the name, read on. It will grow on you. :) > > Shep (w/o chair hat) > > On Fri, Feb 28, 2020 at 7:31 AM Acee Lindem (acee) wrote= : > >> If you go with PBR, you could continue the BIER WG traditional of >> selecting brew-based acronyms. Hence, that would be my vote. It could be >> confused with Policy Based Routing but only if someone actually implemen= ts >> it. >> Thanks, >> Acee >> >> =EF=BB=BFOn 2/28/20, 9:23 AM, "BIER on behalf of Toerless Eckert" < >> bier-bounces@ietf.org on behalf of tte@cs.fau.de> wrote: >> >> Sure, Just reply wth the ones you like whether existing or added and >> give them the weiht you like, e.g.: from your email something like: >> >> 5 BIER-PBR (Path Based Routing) >> 5 BIER-PST (Path based STeering) >> 3 BIER-PE (Path Engineering) >> >> On Fri, Feb 28, 2020 at 07:54:07AM +0000, Dirk Trossen wrote: >> > Toerless, all, >> > >> > May I add to the mix (which might not help) with the proposal for >> 'path-based routing' (or BIER-PBR) or 'path-based steering' (or BIER-PST= )? >> If you want to keep a two letter acronym, I'd add 'path steering' (rathe= r >> than path engineering) to the mix. From the below, without considering a= ny >> alternatives, I'd go for BIER-PE but it comes with the issues like many = two >> letter acronyms, namely the higher 'collision rate' with others. >> > >> > Best, >> > >> > Dirk >> > >> > >> > >> > -----Original Message----- >> > From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Toerless >> Eckert >> > Sent: 27 February 2020 21:41 >> > To: bier@ietf.org >> > Cc: Lou Berger ; bier-ads@ietf.org; BRUNGARD, >> DEBORAH A ; bier-chairs@ietf.org >> > Subject: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) >> > >> > Dear WG >> > >> > Please chime in with opinions about the following or any new name >> you like as the new name for BIER-TE. Timeout is deadline for submission= of >> draft before IETF107, when i'll post an update. If you propose a new nam= e >> try to avoid re-using abbreviations that may be misinterpreted. >> > >> > 5 =3D best name ever, ... 1 =3D lame name, no number assigned mean= s 0 >> votes are just added up and maximum sum option wins. >> > Explanations if you haven't followed thread at the end. >> > >> > BIER-PE - Path Engineering >> > BIER-ET - Explicit Trees >> > BIER-EET - Explicit Engineered Trees >> > BIER-BET - Bit Engineered Trees >> > BIER-BST - Bit Steered Trees >> > BIER-TrE - Tree engineering >> > BIER-ET - Engineered Trees >> > BIER-ST - Steered Trees >> > >> > BIER-ASB - Adjacency Steering Bits (adjacencies are how bits in >> BIER-PE are defined) >> > BIER-AB - Adjacency Bits >> > BIER-SB - Steering Bits (overloads with "Source Block= " >> - never heard) >> > >> > Thanks, >> > Toerless >> > >> > Explanations: If you have read through the threads with Lou and >> Deborah, and my understanding is correct: >> > >> > Lou desired there to be a new name so BIER-TE the >> forwarding/steering mechanism (this document) is named differently from >> BIER-TE the larger framework utilizing TEAS/PCE definition (separate fut= ure >> draft). >> > >> > Lou did not like my "Path Engineering" proposal as the name in the >> last version of the doc and felt we should pick a name with >> Steering/routing-policy in it. I think usn only steering/routing would b= e >> misleading (confused with unicast approaches). >> > >> > Deborah pointed to avoiding confusions in the name with >> pre-established named (e.g.: "PE" meaning Provider Edge). >> > Said we should finalize on the name before we as the WG should pas= s >> the document to IESG. And she asked chairs to extend last-call by one mo= re >> week (unrelated). Hence timeout end of next week. >> > >> > _______________________________________________ >> > BIER mailing list >> > BIER@ietf.org >> > https://www.ietf.org/mailman/listinfo/bier >> > >> > _______________________________________________ >> > BIER mailing list >> > BIER@ietf.org >> > https://www.ietf.org/mailman/listinfo/bier >> >> -- >> --- >> tte@cs.fau.de >> >> _______________________________________________ >> BIER mailing list >> BIER@ietf.org >> https://www.ietf.org/mailman/listinfo/bier >> >> >> --000000000000e264a3059fa4f608 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yepp, I concur with Greg ... tony

On Fri, Feb 28, 2020= at 8:00 AM Greg Shepherd <gjshep@gm= ail.com> wrote:
My vote: BIER-TE=C2=A0
Call it Tree Engineering= . If we were so concerned=C2=A0with acronym overuse the IETF would grind to= a halt. I've been involved in other WGs where I felt the name missed t= he mark describing the ideas in the draft, but felt reading the draft was h= ow someone got their heads around the proposed solution, rather than miss-r= ead the title and run away confused. ie - Vlex-Algo. No, it's Flex-Topo= , but what's to be gained from arguing for a name at this point?=C2=A0<= /div>

Yes, we should strive=C2=A0to be as 'correct&#= 39; as possible. But the IETF is full of baggage that engineers have manage= d to wade through, make sense of, and implement successfully. Get the spec = right, No #1 priority. If you don't like the name, read on. It will gro= w on you. :)

Shep (w/o chair hat)

<= div class=3D"gmail_quote">
On Fri, Feb= 28, 2020 at 7:31 AM Acee Lindem (acee) <acee@cisco.com> wrote:
If you go with PBR, you could continue t= he BIER WG traditional of selecting brew-based acronyms. Hence, that would = be my vote. It could be confused with Policy Based Routing but only if some= one actually implements it.
Thanks,
Acee

=EF=BB=BFOn 2/28/20, 9:23 AM, "BIER on behalf of Toerless Eckert"= <bier-bounce= s@ietf.org on behalf of tte@cs.fau.de> wrote:

=C2=A0 =C2=A0 Sure, Just reply wth the ones you like whether existing or ad= ded and
=C2=A0 =C2=A0 give them the weiht you like, e.g.: from your email something= like:

=C2=A0 =C2=A0 5=C2=A0 BIER-PBR=C2=A0 =C2=A0 (Path Based Routing)
=C2=A0 =C2=A0 5=C2=A0 BIER-PST=C2=A0 =C2=A0 (Path based STeering)
=C2=A0 =C2=A0 3=C2=A0 BIER-PE=C2=A0 =C2=A0 =C2=A0(Path Engineering)

=C2=A0 =C2=A0 On Fri, Feb 28, 2020 at 07:54:07AM +0000, Dirk Trossen wrote:=
=C2=A0 =C2=A0 > Toerless, all,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > May I add to the mix (which might not help) with the pro= posal for 'path-based routing' (or BIER-PBR) or 'path-based ste= ering' (or BIER-PST)? If you want to keep a two letter acronym, I'd= add 'path steering' (rather than path engineering) to the mix. Fro= m the below, without considering any alternatives, I'd go for BIER-PE b= ut it comes with the issues like many two letter acronyms, namely the highe= r 'collision rate' with others.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Best,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Dirk
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > -----Original Message-----
=C2=A0 =C2=A0 > From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Toerless Ecke= rt
=C2=A0 =C2=A0 > Sent: 27 February 2020 21:41
=C2=A0 =C2=A0 > To: b= ier@ietf.org
=C2=A0 =C2=A0 > Cc: Lou Berger <lberger@labn.net>; bier-ads@ietf.org; BRUNGARD, DEBORAH A <db3546@att.com>; bier-chairs@ietf.org<= /a>
=C2=A0 =C2=A0 > Subject: [Bier] Pls "vote" on name (draft-ietf= -bier-te-arch)
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Dear WG
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Please chime in with opinions about the following or any= new name you like as the new name for BIER-TE. Timeout is deadline for sub= mission of draft before IETF107, when i'll post an update. If you propo= se a new name try to avoid re-using abbreviations that may be misinterprete= d.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > 5 =3D best name ever, ... 1 =3D lame name, no number ass= igned means 0 votes are just added up and maximum sum option wins.
=C2=A0 =C2=A0 > Explanations if you haven't followed thread at the e= nd.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > BIER-PE=C2=A0 - Path Engineering
=C2=A0 =C2=A0 > BIER-ET=C2=A0 - Explicit Trees
=C2=A0 =C2=A0 > BIER-EET - Explicit Engineered Trees
=C2=A0 =C2=A0 > BIER-BET - Bit Engineered Trees
=C2=A0 =C2=A0 > BIER-BST - Bit Steered Trees
=C2=A0 =C2=A0 > BIER-TrE - Tree engineering
=C2=A0 =C2=A0 > BIER-ET=C2=A0 - Engineered Trees
=C2=A0 =C2=A0 > BIER-ST=C2=A0 - Steered Trees
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > BIER-ASB - Adjacency Steering Bits=C2=A0 =C2=A0(adjacenc= ies are how bits in BIER-PE are defined)
=C2=A0 =C2=A0 > BIER-AB=C2=A0 - Adjacency Bits
=C2=A0 =C2=A0 > BIER-SB=C2=A0 - Steering Bits=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0(overloads with "Source Block" - never heard= )
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Thanks,
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Toerless
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Explanations: If you have read through the threads with = Lou and Deborah, and my understanding is correct:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Lou desired there to be a new name so BIER-TE the forwar= ding/steering mechanism (this document) is named differently from BIER-TE t= he larger framework utilizing TEAS/PCE definition (separate future draft).<= br> =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Lou did not like my "Path Engineering" proposa= l as the name in the last version of the doc and felt we should pick a name= with Steering/routing-policy in it. I think usn only steering/routing woul= d be misleading (confused with unicast approaches).
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Deborah pointed to avoiding confusions in the name with = pre-established named (e.g.: "PE" meaning Provider Edge).
=C2=A0 =C2=A0 > Said we should finalize on the name before we as the WG = should pass the document to IESG. And she asked chairs to extend last-call = by one more week (unrelated). Hence timeout end of next week.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > BIER mailing list
=C2=A0 =C2=A0 > BIER@= ietf.org
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/b= ier
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > BIER mailing list
=C2=A0 =C2=A0 > BIER@= ietf.org
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/b= ier

=C2=A0 =C2=A0 --
=C2=A0 =C2=A0 ---
=C2=A0 =C2=A0 tte@cs.fau= .de

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 BIER mailing list
=C2=A0 =C2=A0 BIER@ietf.= org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/bier


--000000000000e264a3059fa4f608-- From nobody Fri Feb 28 08:33:34 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA22F3A1AF6; Fri, 28 Feb 2020 08:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.638 X-Spam-Level: X-Spam-Status: No, score=-1.638 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 VlIOrH5zepeO; Fri, 28 Feb 2020 08:33:26 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0C2A3A1AEB; Fri, 28 Feb 2020 08:33:25 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 11345548005; Fri, 28 Feb 2020 17:33:19 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 05494440040; Fri, 28 Feb 2020 17:33:19 +0100 (CET) Date: Fri, 28 Feb 2020 17:33:18 +0100 From: Toerless Eckert To: "Acee Lindem (acee)" Cc: Dirk Trossen , "bier@ietf.org" , "bier-ads@ietf.org" , "BRUNGARD, DEBORAH A" , Lou Berger , "bier-chairs@ietf.org" Message-ID: <20200228163318.GB44403@faui48f.informatik.uni-erlangen.de> References: <20200227204038.GB23965@faui48f.informatik.uni-erlangen.de> <91BA3A406CA139458B56D8C52EAB227D147F35@lhreml501-mbs> <20200228142253.GA44403@faui48f.informatik.uni-erlangen.de> <5A558653-37FD-4D0B-A637-8F0078D91C81@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A558653-37FD-4D0B-A637-8F0078D91C81@cisco.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 16:33:32 -0000 Votes only count when you attach a number 5..1 to them. On Fri, Feb 28, 2020 at 03:31:08PM +0000, Acee Lindem (acee) wrote: > If you go with PBR, you could continue the BIER WG traditional of selecting brew-based acronyms. > Hence, that would be my vote. It could be confused with Policy Based Routing but only > if someone actually implements it. Do you mean the beer brand name PBR ? Yes, i had a long rant to Lou against using terms that could be confused with unicast mechanisms because he was suggesting to use those terms as they are used in e.g.: explaining how SR steers traffic (policy, routing, steering). Given how you also feel it would be confusing, If you like to have a beer themed name, could i instead upsell you into something larger: BIER-VAT Vertex Adjacency-bit Trees Its a pretty accurate description of what we do (the bits are for adjacencies, which are the vertices of the tree they describe). Cheers Toerless > Thanks, > Acee > > ???On 2/28/20, 9:23 AM, "BIER on behalf of Toerless Eckert" wrote: > > Sure, Just reply wth the ones you like whether existing or added and > give them the weiht you like, e.g.: from your email something like: > > 5 BIER-PBR (Path Based Routing) > 5 BIER-PST (Path based STeering) > 3 BIER-PE (Path Engineering) > > On Fri, Feb 28, 2020 at 07:54:07AM +0000, Dirk Trossen wrote: > > Toerless, all, > > > > May I add to the mix (which might not help) with the proposal for 'path-based routing' (or BIER-PBR) or 'path-based steering' (or BIER-PST)? If you want to keep a two letter acronym, I'd add 'path steering' (rather than path engineering) to the mix. From the below, without considering any alternatives, I'd go for BIER-PE but it comes with the issues like many two letter acronyms, namely the higher 'collision rate' with others. > > > > Best, > > > > Dirk > > > > > > > > -----Original Message----- > > From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Toerless Eckert > > Sent: 27 February 2020 21:41 > > To: bier@ietf.org > > Cc: Lou Berger ; bier-ads@ietf.org; BRUNGARD, DEBORAH A ; bier-chairs@ietf.org > > Subject: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) > > > > Dear WG > > > > Please chime in with opinions about the following or any new name you like as the new name for BIER-TE. Timeout is deadline for submission of draft before IETF107, when i'll post an update. If you propose a new name try to avoid re-using abbreviations that may be misinterpreted. > > > > 5 = best name ever, ... 1 = lame name, no number assigned means 0 votes are just added up and maximum sum option wins. > > Explanations if you haven't followed thread at the end. > > > > BIER-PE - Path Engineering > > BIER-ET - Explicit Trees > > BIER-EET - Explicit Engineered Trees > > BIER-BET - Bit Engineered Trees > > BIER-BST - Bit Steered Trees > > BIER-TrE - Tree engineering > > BIER-ET - Engineered Trees > > BIER-ST - Steered Trees > > > > BIER-ASB - Adjacency Steering Bits (adjacencies are how bits in BIER-PE are defined) > > BIER-AB - Adjacency Bits > > BIER-SB - Steering Bits (overloads with "Source Block" - never heard) > > > > Thanks, > > Toerless > > > > Explanations: If you have read through the threads with Lou and Deborah, and my understanding is correct: > > > > Lou desired there to be a new name so BIER-TE the forwarding/steering mechanism (this document) is named differently from BIER-TE the larger framework utilizing TEAS/PCE definition (separate future draft). > > > > Lou did not like my "Path Engineering" proposal as the name in the last version of the doc and felt we should pick a name with Steering/routing-policy in it. I think usn only steering/routing would be misleading (confused with unicast approaches). > > > > Deborah pointed to avoiding confusions in the name with pre-established named (e.g.: "PE" meaning Provider Edge). > > Said we should finalize on the name before we as the WG should pass the document to IESG. And she asked chairs to extend last-call by one more week (unrelated). Hence timeout end of next week. > > > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org > > https://www.ietf.org/mailman/listinfo/bier > > > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org > > https://www.ietf.org/mailman/listinfo/bier > > -- > --- > tte@cs.fau.de > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > > -- --- tte@cs.fau.de From nobody Fri Feb 28 08:35:17 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDBAB3A1B29; Fri, 28 Feb 2020 08:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 8ACCXs01okyM; Fri, 28 Feb 2020 08:34:47 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A1F03A1A9D; Fri, 28 Feb 2020 08:34:45 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id A8CC3548052; Fri, 28 Feb 2020 17:34:39 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id A6A1C440040; Fri, 28 Feb 2020 17:34:39 +0100 (CET) Date: Fri, 28 Feb 2020 17:34:39 +0100 From: Toerless Eckert To: Greg Shepherd Cc: "Acee Lindem (acee)" , Dirk Trossen , "bier@ietf.org" , "bier-ads@ietf.org" , "BRUNGARD, DEBORAH A" , Lou Berger , "bier-chairs@ietf.org" Message-ID: <20200228163439.GC44403@faui48f.informatik.uni-erlangen.de> References: <20200227204038.GB23965@faui48f.informatik.uni-erlangen.de> <91BA3A406CA139458B56D8C52EAB227D147F35@lhreml501-mbs> <20200228142253.GA44403@faui48f.informatik.uni-erlangen.de> <5A558653-37FD-4D0B-A637-8F0078D91C81@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 16:34:55 -0000 Ok. Sigh.. i'll relax the rules to simply count all proposed names without number as 5. On Fri, Feb 28, 2020 at 08:00:21AM -0800, Greg Shepherd wrote: > My vote: BIER-TE > Call it Tree Engineering. If we were so concerned with acronym overuse the > IETF would grind to a halt. I've been involved in other WGs where I felt > the name missed the mark describing the ideas in the draft, but felt > reading the draft was how someone got their heads around the proposed > solution, rather than miss-read the title and run away confused. ie - > Vlex-Algo. No, it's Flex-Topo, but what's to be gained from arguing for a > name at this point? > > Yes, we should strive to be as 'correct' as possible. But the IETF is full > of baggage that engineers have managed to wade through, make sense of, and > implement successfully. Get the spec right, No #1 priority. If you don't > like the name, read on. It will grow on you. :) > > Shep (w/o chair hat) > > On Fri, Feb 28, 2020 at 7:31 AM Acee Lindem (acee) wrote: > > > If you go with PBR, you could continue the BIER WG traditional of > > selecting brew-based acronyms. Hence, that would be my vote. It could be > > confused with Policy Based Routing but only if someone actually implements > > it. > > Thanks, > > Acee > > > > ???On 2/28/20, 9:23 AM, "BIER on behalf of Toerless Eckert" < > > bier-bounces@ietf.org on behalf of tte@cs.fau.de> wrote: > > > > Sure, Just reply wth the ones you like whether existing or added and > > give them the weiht you like, e.g.: from your email something like: > > > > 5 BIER-PBR (Path Based Routing) > > 5 BIER-PST (Path based STeering) > > 3 BIER-PE (Path Engineering) > > > > On Fri, Feb 28, 2020 at 07:54:07AM +0000, Dirk Trossen wrote: > > > Toerless, all, > > > > > > May I add to the mix (which might not help) with the proposal for > > 'path-based routing' (or BIER-PBR) or 'path-based steering' (or BIER-PST)? > > If you want to keep a two letter acronym, I'd add 'path steering' (rather > > than path engineering) to the mix. From the below, without considering any > > alternatives, I'd go for BIER-PE but it comes with the issues like many two > > letter acronyms, namely the higher 'collision rate' with others. > > > > > > Best, > > > > > > Dirk > > > > > > > > > > > > -----Original Message----- > > > From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Toerless > > Eckert > > > Sent: 27 February 2020 21:41 > > > To: bier@ietf.org > > > Cc: Lou Berger ; bier-ads@ietf.org; BRUNGARD, > > DEBORAH A ; bier-chairs@ietf.org > > > Subject: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) > > > > > > Dear WG > > > > > > Please chime in with opinions about the following or any new name > > you like as the new name for BIER-TE. Timeout is deadline for submission of > > draft before IETF107, when i'll post an update. If you propose a new name > > try to avoid re-using abbreviations that may be misinterpreted. > > > > > > 5 = best name ever, ... 1 = lame name, no number assigned means 0 > > votes are just added up and maximum sum option wins. > > > Explanations if you haven't followed thread at the end. > > > > > > BIER-PE - Path Engineering > > > BIER-ET - Explicit Trees > > > BIER-EET - Explicit Engineered Trees > > > BIER-BET - Bit Engineered Trees > > > BIER-BST - Bit Steered Trees > > > BIER-TrE - Tree engineering > > > BIER-ET - Engineered Trees > > > BIER-ST - Steered Trees > > > > > > BIER-ASB - Adjacency Steering Bits (adjacencies are how bits in > > BIER-PE are defined) > > > BIER-AB - Adjacency Bits > > > BIER-SB - Steering Bits (overloads with "Source Block" > > - never heard) > > > > > > Thanks, > > > Toerless > > > > > > Explanations: If you have read through the threads with Lou and > > Deborah, and my understanding is correct: > > > > > > Lou desired there to be a new name so BIER-TE the > > forwarding/steering mechanism (this document) is named differently from > > BIER-TE the larger framework utilizing TEAS/PCE definition (separate future > > draft). > > > > > > Lou did not like my "Path Engineering" proposal as the name in the > > last version of the doc and felt we should pick a name with > > Steering/routing-policy in it. I think usn only steering/routing would be > > misleading (confused with unicast approaches). > > > > > > Deborah pointed to avoiding confusions in the name with > > pre-established named (e.g.: "PE" meaning Provider Edge). > > > Said we should finalize on the name before we as the WG should pass > > the document to IESG. And she asked chairs to extend last-call by one more > > week (unrelated). Hence timeout end of next week. > > > > > > _______________________________________________ > > > BIER mailing list > > > BIER@ietf.org > > > https://www.ietf.org/mailman/listinfo/bier > > > > > > _______________________________________________ > > > BIER mailing list > > > BIER@ietf.org > > > https://www.ietf.org/mailman/listinfo/bier > > > > -- > > --- > > tte@cs.fau.de > > > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org > > https://www.ietf.org/mailman/listinfo/bier > > > > > > -- --- tte@cs.fau.de From nobody Fri Feb 28 08:39:44 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F27EE3A1B1B; Fri, 28 Feb 2020 08:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 WiT-lhN74hq1; Fri, 28 Feb 2020 08:39:36 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 8AA6D3A1B04; Fri, 28 Feb 2020 08:39:36 -0800 (PST) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.42/8.16.0.42) with SMTP id 01SGW9nM012002; Fri, 28 Feb 2020 11:39:14 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 2yepye92pk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Feb 2020 11:39:12 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 01SGdAv6004366; Fri, 28 Feb 2020 11:39:10 -0500 Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [135.66.87.50]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id 01SGd5Wj004271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 28 Feb 2020 11:39:05 -0500 Received: from zlp27128.vci.att.com (zlp27128.vci.att.com [127.0.0.1]) by zlp27128.vci.att.com (Service) with ESMTP id 18AB2400A0A8; Fri, 28 Feb 2020 16:39:05 +0000 (GMT) Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (unknown [130.9.129.152]) by zlp27128.vci.att.com (Service) with ESMTPS id EBFD3400043E; Fri, 28 Feb 2020 16:39:04 +0000 (GMT) Received: from MISOUT7MSGUSRDE.ITServices.sbc.com ([169.254.5.48]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0487.000; Fri, 28 Feb 2020 11:39:04 -0500 From: "BRUNGARD, DEBORAH A" To: Toerless Eckert , "Acee Lindem (acee)" CC: Dirk Trossen , "bier@ietf.org" , "bier-ads@ietf.org" , Lou Berger , "bier-chairs@ietf.org" Thread-Topic: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) Thread-Index: AQHV7a4z8h/LZWsgXkOO/40+0v+pKagwkPaAgABsoACAABMRAIAAEV4A//+s93A= Date: Fri, 28 Feb 2020 16:39:03 +0000 Message-ID: References: <20200227204038.GB23965@faui48f.informatik.uni-erlangen.de> <91BA3A406CA139458B56D8C52EAB227D147F35@lhreml501-mbs> <20200228142253.GA44403@faui48f.informatik.uni-erlangen.de> <5A558653-37FD-4D0B-A637-8F0078D91C81@cisco.com> <20200228163318.GB44403@faui48f.informatik.uni-erlangen.de> In-Reply-To: <20200228163318.GB44403@faui48f.informatik.uni-erlangen.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.239] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-28_05:2020-02-28, 2020-02-28 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 mlxscore=0 phishscore=0 suspectscore=0 priorityscore=1501 mlxlogscore=999 malwarescore=0 clxscore=1011 spamscore=0 bulkscore=0 lowpriorityscore=0 adultscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002280130 Archived-At: Subject: Re: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 16:39:42 -0000 I was not going to vote (it's for the wg to decide) but on this one - Toerl= ess - it's really good - can not resist -as I was thinking also to put adja= cency in but couldn't think of something - my vote should be weighted lower= than the rest of the working group - 5 BIER-VAT Thanks! Deborah -----Original Message----- From: Toerless Eckert =20 Sent: Friday, February 28, 2020 11:33 AM To: Acee Lindem (acee) Cc: Dirk Trossen ; bier@ietf.org; bier-ads@ietf.or= g; BRUNGARD, DEBORAH A ; Lou Berger ; bie= r-chairs@ietf.org Subject: Re: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) Votes only count when you attach a number 5..1 to them. On Fri, Feb 28, 2020 at 03:31:08PM +0000, Acee Lindem (acee) wrote: > If you go with PBR, you could continue the BIER WG traditional of selecti= ng brew-based acronyms. > Hence, that would be my vote. It could be confused with Policy Based Rout= ing but only > if someone actually implements it. Do you mean the beer brand name PBR ? Yes, i had a long rant to Lou against using terms that could be confused wi= th unicast mechanisms because he was suggesting to use those terms as they are used in e.g.: explaining how SR steers traffic (policy, routing, steering). Given how you also feel it would be confusing, If you like to have a beer themed name, could i instead upsell you into som= ething larger: BIER-VAT Vertex Adjacency-bit Trees Its a pretty accurate description of what we do (the bits are for adjacencies, which are the vertices of the tree they describe). Cheers Toerless > Thanks, > Acee >=20 > ???On 2/28/20, 9:23 AM, "BIER on behalf of Toerless Eckert" wrote: >=20 > Sure, Just reply wth the ones you like whether existing or added and > give them the weiht you like, e.g.: from your email something like: > =20 > 5 BIER-PBR (Path Based Routing) > 5 BIER-PST (Path based STeering) > 3 BIER-PE (Path Engineering) > =20 > On Fri, Feb 28, 2020 at 07:54:07AM +0000, Dirk Trossen wrote: > > Toerless, all, > >=20 > > May I add to the mix (which might not help) with the proposal for '= path-based routing' (or BIER-PBR) or 'path-based steering' (or BIER-PST)? I= f you want to keep a two letter acronym, I'd add 'path steering' (rather th= an path engineering) to the mix. From the below, without considering any al= ternatives, I'd go for BIER-PE but it comes with the issues like many two l= etter acronyms, namely the higher 'collision rate' with others. > >=20 > > Best, > >=20 > > Dirk > >=20 > >=20 > >=20 > > -----Original Message----- > > From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Toerless Eck= ert > > Sent: 27 February 2020 21:41 > > To: bier@ietf.org > > Cc: Lou Berger ; bier-ads@ietf.org; BRUNGARD, DEB= ORAH A ; bier-chairs@ietf.org > > Subject: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) > >=20 > > Dear WG > >=20 > > Please chime in with opinions about the following or any new name y= ou like as the new name for BIER-TE. Timeout is deadline for submission of = draft before IETF107, when i'll post an update. If you propose a new name t= ry to avoid re-using abbreviations that may be misinterpreted. > >=20 > > 5 =3D best name ever, ... 1 =3D lame name, no number assigned means= 0 votes are just added up and maximum sum option wins. > > Explanations if you haven't followed thread at the end. > >=20 > > BIER-PE - Path Engineering > > BIER-ET - Explicit Trees > > BIER-EET - Explicit Engineered Trees > > BIER-BET - Bit Engineered Trees > > BIER-BST - Bit Steered Trees > > BIER-TrE - Tree engineering > > BIER-ET - Engineered Trees > > BIER-ST - Steered Trees > >=20 > > BIER-ASB - Adjacency Steering Bits (adjacencies are how bits in B= IER-PE are defined) > > BIER-AB - Adjacency Bits > > BIER-SB - Steering Bits (overloads with "Source Block"= - never heard) > >=20 > > Thanks, > > Toerless > >=20 > > Explanations: If you have read through the threads with Lou and Deb= orah, and my understanding is correct: > >=20 > > Lou desired there to be a new name so BIER-TE the forwarding/steeri= ng mechanism (this document) is named differently from BIER-TE the larger f= ramework utilizing TEAS/PCE definition (separate future draft). > >=20 > > Lou did not like my "Path Engineering" proposal as the name in the = last version of the doc and felt we should pick a name with Steering/routin= g-policy in it. I think usn only steering/routing would be misleading (conf= used with unicast approaches). > >=20 > > Deborah pointed to avoiding confusions in the name with pre-establi= shed named (e.g.: "PE" meaning Provider Edge). > > Said we should finalize on the name before we as the WG should pass= the document to IESG. And she asked chairs to extend last-call by one more= week (unrelated). Hence timeout end of next week. > >=20 > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org= _mailman_listinfo_bier&d=3DDwIBAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3D6UhGpW9lwi= 9dM7jYlxXD8w&m=3DNUaI2_KsSPm66ASmDykx9_GSjXJLODLJWuqtzo0Z3-U&s=3Dgf1IBPqsSC= WpA77_Nd1uxa7HR_2e5TcAYRDChmbSLxw&e=3D=20 > >=20 > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org= _mailman_listinfo_bier&d=3DDwIBAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3D6UhGpW9lwi= 9dM7jYlxXD8w&m=3DNUaI2_KsSPm66ASmDykx9_GSjXJLODLJWuqtzo0Z3-U&s=3Dgf1IBPqsSC= WpA77_Nd1uxa7HR_2e5TcAYRDChmbSLxw&e=3D=20 > =20 > --=20 > --- > tte@cs.fau.de > =20 > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_m= ailman_listinfo_bier&d=3DDwIBAg&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3D6UhGpW9lwi9d= M7jYlxXD8w&m=3DNUaI2_KsSPm66ASmDykx9_GSjXJLODLJWuqtzo0Z3-U&s=3Dgf1IBPqsSCWp= A77_Nd1uxa7HR_2e5TcAYRDChmbSLxw&e=3D=20 > =20 >=20 --=20 --- tte@cs.fau.de From nobody Fri Feb 28 09:55:42 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F1D3A0D74; Fri, 28 Feb 2020 09:55:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.64 X-Spam-Level: X-Spam-Status: No, score=-1.64 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 30SFnTerLtzL; Fri, 28 Feb 2020 09:55:30 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76C563A0E0D; Fri, 28 Feb 2020 09:55:30 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 940E6548005; Fri, 28 Feb 2020 18:55:23 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 8C953440040; Fri, 28 Feb 2020 18:55:23 +0100 (CET) Date: Fri, 28 Feb 2020 18:55:23 +0100 From: Toerless Eckert To: "BRUNGARD, DEBORAH A" Cc: "Acee Lindem (acee)" , Dirk Trossen , "bier@ietf.org" , "bier-ads@ietf.org" , Lou Berger , "bier-chairs@ietf.org" Message-ID: <20200228175523.GD44403@faui48f.informatik.uni-erlangen.de> References: <20200227204038.GB23965@faui48f.informatik.uni-erlangen.de> <91BA3A406CA139458B56D8C52EAB227D147F35@lhreml501-mbs> <20200228142253.GA44403@faui48f.informatik.uni-erlangen.de> <5A558653-37FD-4D0B-A637-8F0078D91C81@cisco.com> <20200228163318.GB44403@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 17:55:39 -0000 Haha, thanks. Deb. You know, the name also doubles in being upfront about the main cost of the design: Vertexvalue Added bit Tax ;-) On Fri, Feb 28, 2020 at 04:39:03PM +0000, BRUNGARD, DEBORAH A wrote: > I was not going to vote (it's for the wg to decide) but on this one - Toerless - it's really good - can not resist -as I was thinking also to put adjacency in but couldn't think of something - my vote should be weighted lower than the rest of the working group - > > 5 BIER-VAT > > Thanks! > Deborah > > > -----Original Message----- > From: Toerless Eckert > Sent: Friday, February 28, 2020 11:33 AM > To: Acee Lindem (acee) > Cc: Dirk Trossen ; bier@ietf.org; bier-ads@ietf.org; BRUNGARD, DEBORAH A ; Lou Berger ; bier-chairs@ietf.org > Subject: Re: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) > > Votes only count when you attach a number 5..1 to them. > > On Fri, Feb 28, 2020 at 03:31:08PM +0000, Acee Lindem (acee) wrote: > > If you go with PBR, you could continue the BIER WG traditional of selecting brew-based acronyms. > > Hence, that would be my vote. It could be confused with Policy Based Routing but only > > if someone actually implements it. > > Do you mean the beer brand name PBR ? > > Yes, i had a long rant to Lou against using terms that could be confused with unicast mechanisms > because he was suggesting to use those terms as they are used in e.g.: > explaining how SR steers traffic (policy, routing, steering). > > Given how you also feel it would be confusing, > If you like to have a beer themed name, could i instead upsell you into something larger: > > BIER-VAT Vertex Adjacency-bit Trees > > Its a pretty accurate description of what we do (the bits are for > adjacencies, which are the vertices of the tree they describe). > > Cheers > Toerless > > > Thanks, > > Acee > > > > ???On 2/28/20, 9:23 AM, "BIER on behalf of Toerless Eckert" wrote: > > > > Sure, Just reply wth the ones you like whether existing or added and > > give them the weiht you like, e.g.: from your email something like: > > > > 5 BIER-PBR (Path Based Routing) > > 5 BIER-PST (Path based STeering) > > 3 BIER-PE (Path Engineering) > > > > On Fri, Feb 28, 2020 at 07:54:07AM +0000, Dirk Trossen wrote: > > > Toerless, all, > > > > > > May I add to the mix (which might not help) with the proposal for 'path-based routing' (or BIER-PBR) or 'path-based steering' (or BIER-PST)? If you want to keep a two letter acronym, I'd add 'path steering' (rather than path engineering) to the mix. From the below, without considering any alternatives, I'd go for BIER-PE but it comes with the issues like many two letter acronyms, namely the higher 'collision rate' with others. > > > > > > Best, > > > > > > Dirk > > > > > > > > > > > > -----Original Message----- > > > From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Toerless Eckert > > > Sent: 27 February 2020 21:41 > > > To: bier@ietf.org > > > Cc: Lou Berger ; bier-ads@ietf.org; BRUNGARD, DEBORAH A ; bier-chairs@ietf.org > > > Subject: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) > > > > > > Dear WG > > > > > > Please chime in with opinions about the following or any new name you like as the new name for BIER-TE. Timeout is deadline for submission of draft before IETF107, when i'll post an update. If you propose a new name try to avoid re-using abbreviations that may be misinterpreted. > > > > > > 5 = best name ever, ... 1 = lame name, no number assigned means 0 votes are just added up and maximum sum option wins. > > > Explanations if you haven't followed thread at the end. > > > > > > BIER-PE - Path Engineering > > > BIER-ET - Explicit Trees > > > BIER-EET - Explicit Engineered Trees > > > BIER-BET - Bit Engineered Trees > > > BIER-BST - Bit Steered Trees > > > BIER-TrE - Tree engineering > > > BIER-ET - Engineered Trees > > > BIER-ST - Steered Trees > > > > > > BIER-ASB - Adjacency Steering Bits (adjacencies are how bits in BIER-PE are defined) > > > BIER-AB - Adjacency Bits > > > BIER-SB - Steering Bits (overloads with "Source Block" - never heard) > > > > > > Thanks, > > > Toerless > > > > > > Explanations: If you have read through the threads with Lou and Deborah, and my understanding is correct: > > > > > > Lou desired there to be a new name so BIER-TE the forwarding/steering mechanism (this document) is named differently from BIER-TE the larger framework utilizing TEAS/PCE definition (separate future draft). > > > > > > Lou did not like my "Path Engineering" proposal as the name in the last version of the doc and felt we should pick a name with Steering/routing-policy in it. I think usn only steering/routing would be misleading (confused with unicast approaches). > > > > > > Deborah pointed to avoiding confusions in the name with pre-established named (e.g.: "PE" meaning Provider Edge). > > > Said we should finalize on the name before we as the WG should pass the document to IESG. And she asked chairs to extend last-call by one more week (unrelated). Hence timeout end of next week. > > > > > > _______________________________________________ > > > BIER mailing list > > > BIER@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIBAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=NUaI2_KsSPm66ASmDykx9_GSjXJLODLJWuqtzo0Z3-U&s=gf1IBPqsSCWpA77_Nd1uxa7HR_2e5TcAYRDChmbSLxw&e= > > > > > > _______________________________________________ > > > BIER mailing list > > > BIER@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIBAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=NUaI2_KsSPm66ASmDykx9_GSjXJLODLJWuqtzo0Z3-U&s=gf1IBPqsSCWpA77_Nd1uxa7HR_2e5TcAYRDChmbSLxw&e= > > > > -- > > --- > > tte@cs.fau.de > > > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwIBAg&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=NUaI2_KsSPm66ASmDykx9_GSjXJLODLJWuqtzo0Z3-U&s=gf1IBPqsSCWpA77_Nd1uxa7HR_2e5TcAYRDChmbSLxw&e= > > > > > > -- > --- > tte@cs.fau.de -- --- tte@cs.fau.de From nobody Fri Feb 28 10:01:11 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 859A33A1790; Fri, 28 Feb 2020 10:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=RDs7kF1a; dkim=pass (1024-bit key) header.d=juniper.net header.b=OXw5kXbU 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 y9Acr7o3RH4X; Fri, 28 Feb 2020 10:00:52 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 9B6343A0D73; Fri, 28 Feb 2020 10:00:52 -0800 (PST) Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 01SHpkf4019351; Fri, 28 Feb 2020 10:00:25 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=rAqIKIDlAEiFQpwHKzrP+vjjVkBR62ezLJ7YD9c7avs=; b=RDs7kF1akVozbg2u86Mj8+ijWtGlM/XbK0OG09Lk7BTYfYHGrSn+e1wg/X7rc17AUSpl lUJNSj2mavMr9PjesfFC1VN5nhDSHfHE0/FaEfAn8K49nb0JMZYv6pBtqjWo5wVyW80m aljjfcrxHbuQHmFuj9liEDG9jnmyQxuW826nhzCDJOA1h15kjpSqg2p8T3Q0ikpKCWwm GjCeqdDOPijrl86rvZYR6PJPkJEMVZhHjovWiUljWT/4DLKDX8RpaQb3L5/bEnl1QvSN wiOXmZ2Vzz1JxHnBOQNGOFdD8vtm95QMOZFb9nGFj1osBCe8i1ME1kWQ9g/nlkQoKS0K KQ== Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2172.outbound.protection.outlook.com [104.47.59.172]) by mx0b-00273201.pphosted.com with ESMTP id 2yepym1p36-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 28 Feb 2020 10:00:25 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JX6KoqN1sIzdwEIlv0sRqLs7hQQvrmIv+W+wJaumoiSkHXEmm1tSZpC/Jv/GKhuNAi1uCXpSPXXImCsksYa/8tPb7ZterK+hjtACApFZyDcHE6+YhyUHRaGBKYqwsvL6PPZQNrsrADRneY7XL9RG2rVcuYcQN0+9E3u/9gcMouRkeqvkibBikHenfwAloAP2ATYh7AQGkWG1bGzDllr626KyXDTMzK/eWh6sIwELB876GRvhKEDpYgQHWcxPskyJUy0Y7VbwnGbkeQIGvzvGOdg8buncPeg/7DbNHm3txXP0xBxVOoXYiDAC35iO/UBS9c+5YS0zf5AbFi04h2sVbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rAqIKIDlAEiFQpwHKzrP+vjjVkBR62ezLJ7YD9c7avs=; b=QFBKkcYPujZB1HtFKFB00NJTFoHuIOl2qr1Pnu8DlMqM6E21RuRr5e4Cc7JMljUzqmGWfQtn/PjNfrb9zv0AKNDR8hQJk0GoA1peUF4e4IynAlAk6Dueeb4jX5FoEukeDpCvaJherYcCXMfKveXtzPto7aD/cCg9UoPmwx1Cf/FquZm6Zn/NsqlE/+D6PAVnBPJWI4jCnSFwcLZhEFYbawKcGNMa9ZWqrVKAdw/+6F6gj4oIvlHv/Uu+mZqRaEb0IcQG4kV2O2dk4+BYxrM76XDtvrxwaaptXcJvS6Fb2/20ul+/Y1W1haZO9p8mvhEuRlwwSkrxHSYv3TRbkQdKVQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rAqIKIDlAEiFQpwHKzrP+vjjVkBR62ezLJ7YD9c7avs=; b=OXw5kXbUgsuZL2ycuMmv0w4T5nx3zlJ6+ZegTRT0BAW9ro1kRXVcZjoZQhZg1FwCAkbcvAa0uvHjJhPBzeixzGtYJN9vzbDLDwq6Xe1vomvj2SdbLgNiaFQV5ZRMZrUY0E5VAY0xni38WkmtXmog9NZUHCDzkbphm0MQNq6Tb1g= Received: from MN2PR05MB5981.namprd05.prod.outlook.com (2603:10b6:208:c3::15) by MN2PR05MB6030.namprd05.prod.outlook.com (2603:10b6:208:c6::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.9; Fri, 28 Feb 2020 18:00:21 +0000 Received: from MN2PR05MB5981.namprd05.prod.outlook.com ([fe80::1eb:4391:ece1:c540]) by MN2PR05MB5981.namprd05.prod.outlook.com ([fe80::1eb:4391:ece1:c540%7]) with mapi id 15.20.2772.012; Fri, 28 Feb 2020 18:00:21 +0000 From: "Jeffrey (Zhaohui) Zhang" To: "gjshep@gmail.com" , "Acee Lindem (acee)" CC: Dirk Trossen , "bier@ietf.org" , "bier-ads@ietf.org" , "BRUNGARD, DEBORAH A" , Toerless Eckert , Lou Berger , "bier-chairs@ietf.org" Thread-Topic: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) Thread-Index: AQHV7a42tZMb8G+rHUSVBGW2s1TpR6gwPSWAgABsnwCAABMRAIAACCqAgAAhfuA= Date: Fri, 28 Feb 2020 18:00:21 +0000 Message-ID: References: <20200227204038.GB23965@faui48f.informatik.uni-erlangen.de> <91BA3A406CA139458B56D8C52EAB227D147F35@lhreml501-mbs> <20200228142253.GA44403@faui48f.informatik.uni-erlangen.de> <5A558653-37FD-4D0B-A637-8F0078D91C81@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.2.8 dlp-reaction: no-action x-originating-ip: [71.248.165.31] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: c618a682-8d60-4732-bc0b-08d7bc781427 x-ms-traffictypediagnostic: MN2PR05MB6030: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0327618309 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(376002)(346002)(366004)(396003)(39860400002)(136003)(189003)(199004)(81166006)(8936002)(186003)(8676002)(81156014)(2906002)(53546011)(5660300002)(6506007)(7696005)(52536014)(478600001)(26005)(9686003)(966005)(55016002)(33656002)(4326008)(54906003)(110136005)(316002)(71200400001)(76116006)(86362001)(66556008)(64756008)(66476007)(66446008)(66946007); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR05MB6030; H:MN2PR05MB5981.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: hpV16T5fq65by6tHNUY6UoWGYw0/q/8oXxz0WEjo9GhnIPWQSgVrIwFrS5fUJY8wNjAQ8NhW6n3Dvi77lFj2kqhImYa5X9TstLHEHVboVXC6+kUU6RRTUkj8v1CvlEaLMGVuGdIhbiDAIdQfdGMTW6xgEAaqUxfrHkqDO7LfF3WPCM80+SJzGMAUpDgpibkfcVM/V0fgNtGYIaKsnBpAc/np62V08q2OQUFeJP8qA2IPeJdwInmIwTtA8MyRYolfAbyYE7WztsMobvah6FmRzNrXaYb4N5DXcrejUOpBafOCEEN2aI7lgToMoJZXxpnULMl8oXZPr4GrnH6N0R22QsyIA35izKsFTUjhRU11R3fIzwM0Sk1sT1FhvZMfKlo8DHWT6nwktJ/9oPsFyWd/vtUGHOBRO4bZktqGrvO2uwHMRF+DYsjdvT7Ov3YjU3LZYnKTOQlpg8XcO2Z6Hu2R3VtQUXt2VHHnlheNEq5nKSkbXnrpcE3vVtimA9P+l/q7DY7vCWfUA3Nef3ihVW9Rcg== x-ms-exchange-antispam-messagedata: rxIR3n3lx2bbnCIs3V4vghwd1S5e7Mp4VK7GjgQ4XDwzvnt5mRmInBSe00/RxZcET0qPEneWBwn0/0yPuRALFnmqqQw58PVhUbRl2bv3B2nsAK/gkK0EJTNCWXW5lHzGFzjwdx/WOBLCd0Zjm3YtLw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR05MB59812228B37EECDC684B433ED4E80MN2PR05MB5981namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: c618a682-8d60-4732-bc0b-08d7bc781427 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2020 18:00:21.3771 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pYN2isb2jEjw/X874fDGWDQFqPTuRxiSqVMZioljICTonMKo+AWCx0Uy09xOrjkFhYjXk/rMzucJPMVsy4hKbw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6030 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138, 18.0.572 definitions=2020-02-28_06:2020-02-28, 2020-02-28 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxlogscore=999 impostorscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 suspectscore=0 lowpriorityscore=0 mlxscore=0 priorityscore=1501 adultscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2001150001 definitions=main-2002280135 Archived-At: Subject: Re: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 18:01:08 -0000 --_000_MN2PR05MB59812228B37EECDC684B433ED4E80MN2PR05MB5981namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KRnJvbTogQklFUiA8Ymllci1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgR3Jl ZyBTaGVwaGVyZA0KU2VudDogRnJpZGF5LCBGZWJydWFyeSAyOCwgMjAyMCAxMTowMCBBTQ0KVG86 IEFjZWUgTGluZGVtIChhY2VlKSA8YWNlZUBjaXNjby5jb20+DQpDYzogRGlyayBUcm9zc2VuIDxk aXJrLnRyb3NzZW5AaHVhd2VpLmNvbT47IGJpZXJAaWV0Zi5vcmc7IGJpZXItYWRzQGlldGYub3Jn OyBCUlVOR0FSRCwgREVCT1JBSCBBIDxkYjM1NDZAYXR0LmNvbT47IFRvZXJsZXNzIEVja2VydCA8 dHRlQGNzLmZhdS5kZT47IExvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+OyBiaWVyLWNoYWly c0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtCaWVyXSBQbHMgInZvdGUiIG9uIG5hbWUgKGRyYWZ0 LWlldGYtYmllci10ZS1hcmNoKQ0KDQpNeSB2b3RlOiBCSUVSLVRFDQpDYWxsIGl0IFRyZWUgRW5n aW5lZXJpbmcuIElmIHdlIHdlcmUgc28gY29uY2VybmVkIHdpdGggYWNyb255bSBvdmVydXNlIHRo ZSBJRVRGIHdvdWxkIGdyaW5kIHRvIGEgaGFsdC4uIEkndmUgYmVlbiBpbnZvbHZlZCBpbiBvdGhl ciBXR3Mgd2hlcmUgSSBmZWx0IHRoZSBuYW1lIG1pc3NlZCB0aGUgbWFyayBkZXNjcmliaW5nIHRo ZSBpZGVhcyBpbiB0aGUgZHJhZnQsIGJ1dCBmZWx0IHJlYWRpbmcgdGhlIGRyYWZ0IHdhcyBob3cg c29tZW9uZSBnb3QgdGhlaXIgaGVhZHMgYXJvdW5kIHRoZSBwcm9wb3NlZCBzb2x1dGlvbiwgcmF0 aGVyIHRoYW4gbWlzcy1yZWFkIHRoZSB0aXRsZSBhbmQgcnVuIGF3YXkgY29uZnVzZWQuIGllIC0g VmxleC1BbGdvLiBObywgaXQncyBGbGV4LVRvcG8sIGJ1dCB3aGF0J3MgdG8gYmUgZ2FpbmVkIGZy b20gYXJndWluZyBmb3IgYSBuYW1lIGF0IHRoaXMgcG9pbnQ/DQoNClllcywgd2Ugc2hvdWxkIHN0 cml2ZSB0byBiZSBhcyAnY29ycmVjdCcgYXMgcG9zc2libGUuIEJ1dCB0aGUgSUVURiBpcyBmdWxs IG9mIGJhZ2dhZ2UgdGhhdCBlbmdpbmVlcnMgaGF2ZSBtYW5hZ2VkIHRvIHdhZGUgdGhyb3VnaCwg bWFrZSBzZW5zZSBvZiwgYW5kIGltcGxlbWVudCBzdWNjZXNzZnVsbHkuIEdldCB0aGUgc3BlYyBy aWdodCwgTm8gIzEgcHJpb3JpdHkuIElmIHlvdSBkb24ndCBsaWtlIHRoZSBuYW1lLCByZWFkIG9u LiBJdCB3aWxsIGdyb3cgb24geW91LiA6KQ0KDQpTaGVwICh3L28gY2hhaXIgaGF0KQ0KDQpPbiBG cmksIEZlYiAyOCwgMjAyMCBhdCA3OjMxIEFNIEFjZWUgTGluZGVtIChhY2VlKSA8YWNlZUBjaXNj by5jb208bWFpbHRvOmFjZWVAY2lzY28uY29tPj4gd3JvdGU6DQpJZiB5b3UgZ28gd2l0aCBQQlIs IHlvdSBjb3VsZCBjb250aW51ZSB0aGUgQklFUiBXRyB0cmFkaXRpb25hbCBvZiBzZWxlY3Rpbmcg YnJldy1iYXNlZCBhY3Jvbnltcy4gSGVuY2UsIHRoYXQgd291bGQgYmUgbXkgdm90ZS4gSXQgY291 bGQgYmUgY29uZnVzZWQgd2l0aCBQb2xpY3kgQmFzZWQgUm91dGluZyBidXQgb25seSBpZiBzb21l b25lIGFjdHVhbGx5IGltcGxlbWVudHMgaXQuDQpUaGFua3MsDQpBY2VlDQoNCu+7v09uIDIvMjgv MjAsIDk6MjMgQU0sICJCSUVSIG9uIGJlaGFsZiBvZiBUb2VybGVzcyBFY2tlcnQiIDxiaWVyLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmJpZXItYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9m IHR0ZUBjcy5mYXUuZGU8bWFpbHRvOnR0ZUBjcy5mYXUuZGU+PiB3cm90ZToNCg0KICAgIFN1cmUs IEp1c3QgcmVwbHkgd3RoIHRoZSBvbmVzIHlvdSBsaWtlIHdoZXRoZXIgZXhpc3Rpbmcgb3IgYWRk ZWQgYW5kDQogICAgZ2l2ZSB0aGVtIHRoZSB3ZWlodCB5b3UgbGlrZSwgZS5nLjogZnJvbSB5b3Vy IGVtYWlsIHNvbWV0aGluZyBsaWtlOg0KDQogICAgNSAgQklFUi1QQlIgICAgKFBhdGggQmFzZWQg Um91dGluZykNCiAgICA1ICBCSUVSLVBTVCAgICAoUGF0aCBiYXNlZCBTVGVlcmluZykNCiAgICAz ICBCSUVSLVBFICAgICAoUGF0aCBFbmdpbmVlcmluZykNCg0KICAgIE9uIEZyaSwgRmViIDI4LCAy MDIwIGF0IDA3OjU0OjA3QU0gKzAwMDAsIERpcmsgVHJvc3NlbiB3cm90ZToNCiAgICA+IFRvZXJs ZXNzLCBhbGwsDQogICAgPg0KICAgID4gTWF5IEkgYWRkIHRvIHRoZSBtaXggKHdoaWNoIG1pZ2h0 IG5vdCBoZWxwKSB3aXRoIHRoZSBwcm9wb3NhbCBmb3IgJ3BhdGgtYmFzZWQgcm91dGluZycgKG9y IEJJRVItUEJSKSBvciAncGF0aC1iYXNlZCBzdGVlcmluZycgKG9yIEJJRVItUFNUKT8gSWYgeW91 IHdhbnQgdG8ga2VlcCBhIHR3byBsZXR0ZXIgYWNyb255bSwgSSdkIGFkZCAncGF0aCBzdGVlcmlu ZycgKHJhdGhlciB0aGFuIHBhdGggZW5naW5lZXJpbmcpIHRvIHRoZSBtaXguIEZyb20gdGhlIGJl bG93LCB3aXRob3V0IGNvbnNpZGVyaW5nIGFueSBhbHRlcm5hdGl2ZXMsIEknZCBnbyBmb3IgQklF Ui1QRSBidXQgaXQgY29tZXMgd2l0aCB0aGUgaXNzdWVzIGxpa2UgbWFueSB0d28gbGV0dGVyIGFj cm9ueW1zLCBuYW1lbHkgdGhlIGhpZ2hlciAnY29sbGlzaW9uIHJhdGUnIHdpdGggb3RoZXJzLg0K ICAgID4NCiAgICA+IEJlc3QsDQogICAgPg0KICAgID4gRGlyaw0KICAgID4NCiAgICA+DQogICAg Pg0KICAgID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCiAgICA+IEZyb206IEJJRVIgW21h aWx0bzpiaWVyLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmJpZXItYm91bmNlc0BpZXRmLm9yZz5d IE9uIEJlaGFsZiBPZiBUb2VybGVzcyBFY2tlcnQNCiAgICA+IFNlbnQ6IDI3IEZlYnJ1YXJ5IDIw MjAgMjE6NDENCiAgICA+IFRvOiBiaWVyQGlldGYub3JnPG1haWx0bzpiaWVyQGlldGYub3JnPg0K ICAgID4gQ2M6IExvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ8bWFpbHRvOmxiZXJnZXJAbGFi bi5uZXQ+PjsgYmllci1hZHNAaWV0Zi5vcmc8bWFpbHRvOmJpZXItYWRzQGlldGYub3JnPjsgQlJV TkdBUkQsIERFQk9SQUggQSA8ZGIzNTQ2QGF0dC5jb208bWFpbHRvOmRiMzU0NkBhdHQuY29tPj47 IGJpZXItY2hhaXJzQGlldGYub3JnPG1haWx0bzpiaWVyLWNoYWlyc0BpZXRmLm9yZz4NCiAgICA+ IFN1YmplY3Q6IFtCaWVyXSBQbHMgInZvdGUiIG9uIG5hbWUgKGRyYWZ0LWlldGYtYmllci10ZS1h cmNoKQ0KICAgID4NCiAgICA+IERlYXIgV0cNCiAgICA+DQogICAgPiBQbGVhc2UgY2hpbWUgaW4g d2l0aCBvcGluaW9ucyBhYm91dCB0aGUgZm9sbG93aW5nIG9yIGFueSBuZXcgbmFtZSB5b3UgbGlr ZSBhcyB0aGUgbmV3IG5hbWUgZm9yIEJJRVItVEUuIFRpbWVvdXQgaXMgZGVhZGxpbmUgZm9yIHN1 Ym1pc3Npb24gb2YgZHJhZnQgYmVmb3JlIElFVEYxMDcsIHdoZW4gaSdsbCBwb3N0IGFuIHVwZGF0 ZS4gSWYgeW91IHByb3Bvc2UgYSBuZXcgbmFtZSB0cnkgdG8gYXZvaWQgcmUtdXNpbmcgYWJicmV2 aWF0aW9ucyB0aGF0IG1heSBiZSBtaXNpbnRlcnByZXRlZC4NCiAgICA+DQogICAgPiA1ID0gYmVz dCBuYW1lIGV2ZXIsIC4uLiAxID0gbGFtZSBuYW1lLCBubyBudW1iZXIgYXNzaWduZWQgbWVhbnMg MCB2b3RlcyBhcmUganVzdCBhZGRlZCB1cCBhbmQgbWF4aW11bSBzdW0gb3B0aW9uIHdpbnMuDQog ICAgPiBFeHBsYW5hdGlvbnMgaWYgeW91IGhhdmVuJ3QgZm9sbG93ZWQgdGhyZWFkIGF0IHRoZSBl bmQuDQogICAgPg0KICAgID4gQklFUi1QRSAgLSBQYXRoIEVuZ2luZWVyaW5nDQogICAgPiBCSUVS LUVUICAtIEV4cGxpY2l0IFRyZWVzDQogICAgPiBCSUVSLUVFVCAtIEV4cGxpY2l0IEVuZ2luZWVy ZWQgVHJlZXMNCiAgICA+IEJJRVItQkVUIC0gQml0IEVuZ2luZWVyZWQgVHJlZXMNCiAgICA+IEJJ RVItQlNUIC0gQml0IFN0ZWVyZWQgVHJlZXMNCiAgICA+IEJJRVItVHJFIC0gVHJlZSBlbmdpbmVl cmluZw0KICAgID4gQklFUi1FVCAgLSBFbmdpbmVlcmVkIFRyZWVzDQogICAgPiBCSUVSLVNUICAt IFN0ZWVyZWQgVHJlZXMNCiAgICA+DQogICAgPiBCSUVSLUFTQiAtIEFkamFjZW5jeSBTdGVlcmlu ZyBCaXRzICAgKGFkamFjZW5jaWVzIGFyZSBob3cgYml0cyBpbiBCSUVSLVBFIGFyZSBkZWZpbmVk KQ0KICAgID4gQklFUi1BQiAgLSBBZGphY2VuY3kgQml0cw0KICAgID4gQklFUi1TQiAgLSBTdGVl cmluZyBCaXRzICAgICAgICAgICAgIChvdmVybG9hZHMgd2l0aCAiU291cmNlIEJsb2NrIiAtIG5l dmVyIGhlYXJkKQ0KICAgID4NCiAgICA+IFRoYW5rcywNCiAgICA+ICAgICBUb2VybGVzcw0KICAg ID4NCiAgICA+IEV4cGxhbmF0aW9uczogSWYgeW91IGhhdmUgcmVhZCB0aHJvdWdoIHRoZSB0aHJl YWRzIHdpdGggTG91IGFuZCBEZWJvcmFoLCBhbmQgbXkgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0 Og0KICAgID4NCiAgICA+IExvdSBkZXNpcmVkIHRoZXJlIHRvIGJlIGEgbmV3IG5hbWUgc28gQklF Ui1URSB0aGUgZm9yd2FyZGluZy9zdGVlcmluZyBtZWNoYW5pc20gKHRoaXMgZG9jdW1lbnQpIGlz IG5hbWVkIGRpZmZlcmVudGx5IGZyb20gQklFUi1URSB0aGUgbGFyZ2VyIGZyYW1ld29yayB1dGls aXppbmcgVEVBUy9QQ0UgZGVmaW5pdGlvbiAoc2VwYXJhdGUgZnV0dXJlIGRyYWZ0KS4NCiAgICA+ DQogICAgPiBMb3UgZGlkIG5vdCBsaWtlIG15ICJQYXRoIEVuZ2luZWVyaW5nIiBwcm9wb3NhbCBh cyB0aGUgbmFtZSBpbiB0aGUgbGFzdCB2ZXJzaW9uIG9mIHRoZSBkb2MgYW5kIGZlbHQgd2Ugc2hv dWxkIHBpY2sgYSBuYW1lIHdpdGggU3RlZXJpbmcvcm91dGluZy1wb2xpY3kgaW4gaXQuIEkgdGhp bmsgdXNuIG9ubHkgc3RlZXJpbmcvcm91dGluZyB3b3VsZCBiZSBtaXNsZWFkaW5nIChjb25mdXNl ZCB3aXRoIHVuaWNhc3QgYXBwcm9hY2hlcykuDQogICAgPg0KICAgID4gRGVib3JhaCBwb2ludGVk IHRvIGF2b2lkaW5nIGNvbmZ1c2lvbnMgaW4gdGhlIG5hbWUgd2l0aCBwcmUtZXN0YWJsaXNoZWQg bmFtZWQgKGUuZy46ICJQRSIgbWVhbmluZyBQcm92aWRlciBFZGdlKS4NCiAgICA+IFNhaWQgd2Ug c2hvdWxkIGZpbmFsaXplIG9uIHRoZSBuYW1lIGJlZm9yZSB3ZSBhcyB0aGUgV0cgc2hvdWxkIHBh c3MgdGhlIGRvY3VtZW50IHRvIElFU0cuIEFuZCBzaGUgYXNrZWQgY2hhaXJzIHRvIGV4dGVuZCBs YXN0LWNhbGwgYnkgb25lIG1vcmUgd2VlayAodW5yZWxhdGVkKS4gSGVuY2UgdGltZW91dCBlbmQg b2YgbmV4dCB3ZWVrLg0KICAgID4NCiAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQogICAgPiBCSUVSIG1haWxpbmcgbGlzdA0KICAgID4gQklFUkBp ZXRmLm9yZzxtYWlsdG86QklFUkBpZXRmLm9yZz4NCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vYmllcjxodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6 L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JpZXJfXzshIU5FdDZ5TWFPLWdrIVhUcXd0 czItNXpkbzFJa1FDNS1VLUFPR0s2WVhlNjRHdUQ3cHB5YUVETExrNnlGMkRGSkczOVozZ1dBUV9m MkskPg0KICAgID4NCiAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQogICAgPiBCSUVSIG1haWxpbmcgbGlzdA0KICAgID4gQklFUkBpZXRmLm9yZzxt YWlsdG86QklFUkBpZXRmLm9yZz4NCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vYmllcjxodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JpZXJfXzshIU5FdDZ5TWFPLWdrIVhUcXd0czItNXpkbzFJ a1FDNS1VLUFPR0s2WVhlNjRHdUQ3cHB5YUVETExrNnlGMkRGSkczOVozZ1dBUV9mMkskPg0KDQog ICAgLS0NCiAgICAtLS0NCiAgICB0dGVAY3MuZmF1Li5kZTxtYWlsdG86dHRlQGNzLmZhdS5kZT4N Cg0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQog ICAgQklFUiBtYWlsaW5nIGxpc3QNCiAgICBCSUVSQGlldGYub3JnPG1haWx0bzpCSUVSQGlldGYu b3JnPg0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYmllcjxodHRw czovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2JpZXJfXzshIU5FdDZ5TWFPLWdrIVhUcXd0czItNXpkbzFJa1FDNS1VLUFPR0s2WVhlNjRH dUQ3cHB5YUVETExrNnlGMkRGSkczOVozZ1dBUV9mMkskPg0KDQo= --_000_MN2PR05MB59812228B37EECDC684B433ED4E80MN2PR05MB5981namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mIzQzOzE8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+RnJvbTo8L2I+IEJJRVIgJmx0O2JpZXItYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24g QmVoYWxmIE9mIDwvYj4NCkdyZWcgU2hlcGhlcmQ8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBG ZWJydWFyeSAyOCwgMjAyMCAxMTowMCBBTTxicj4NCjxiPlRvOjwvYj4gQWNlZSBMaW5kZW0gKGFj ZWUpICZsdDthY2VlQGNpc2NvLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IERpcmsgVHJvc3NlbiAm bHQ7ZGlyay50cm9zc2VuQGh1YXdlaS5jb20mZ3Q7OyBiaWVyQGlldGYub3JnOyBiaWVyLWFkc0Bp ZXRmLm9yZzsgQlJVTkdBUkQsIERFQk9SQUggQSAmbHQ7ZGIzNTQ2QGF0dC5jb20mZ3Q7OyBUb2Vy bGVzcyBFY2tlcnQgJmx0O3R0ZUBjcy5mYXUuZGUmZ3Q7OyBMb3UgQmVyZ2VyICZsdDtsYmVyZ2Vy QGxhYm4ubmV0Jmd0OzsgYmllci1jaGFpcnNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtCaWVyXSBQbHMgJnF1b3Q7dm90ZSZxdW90OyBvbiBuYW1lIChkcmFmdC1pZXRmLWJpZXIt dGUtYXJjaCk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IHZvdGU6IEJJRVItVEUm bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DYWxsIGl0 IFRyZWUgRW5naW5lZXJpbmcuIElmIHdlIHdlcmUgc28gY29uY2VybmVkJm5ic3A7d2l0aCBhY3Jv bnltIG92ZXJ1c2UgdGhlIElFVEYgd291bGQgZ3JpbmQgdG8gYSBoYWx0Li4gSSd2ZSBiZWVuIGlu dm9sdmVkIGluIG90aGVyIFdHcyB3aGVyZSBJIGZlbHQgdGhlIG5hbWUgbWlzc2VkIHRoZSBtYXJr IGRlc2NyaWJpbmcgdGhlIGlkZWFzIGluIHRoZSBkcmFmdCwgYnV0IGZlbHQgcmVhZGluZyB0aGUg ZHJhZnQNCiB3YXMgaG93IHNvbWVvbmUgZ290IHRoZWlyIGhlYWRzIGFyb3VuZCB0aGUgcHJvcG9z ZWQgc29sdXRpb24sIHJhdGhlciB0aGFuIG1pc3MtcmVhZCB0aGUgdGl0bGUgYW5kIHJ1biBhd2F5 IGNvbmZ1c2VkLiBpZSAtIFZsZXgtQWxnby4gTm8sIGl0J3MgRmxleC1Ub3BvLCBidXQgd2hhdCdz IHRvIGJlIGdhaW5lZCBmcm9tIGFyZ3VpbmcgZm9yIGEgbmFtZSBhdCB0aGlzIHBvaW50PyZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Z ZXMsIHdlIHNob3VsZCBzdHJpdmUmbmJzcDt0byBiZSBhcyAnY29ycmVjdCcgYXMgcG9zc2libGUu IEJ1dCB0aGUgSUVURiBpcyBmdWxsIG9mIGJhZ2dhZ2UgdGhhdCBlbmdpbmVlcnMgaGF2ZSBtYW5h Z2VkIHRvIHdhZGUgdGhyb3VnaCwgbWFrZSBzZW5zZSBvZiwgYW5kIGltcGxlbWVudCBzdWNjZXNz ZnVsbHkuIEdldCB0aGUgc3BlYyByaWdodCwgTm8gIzEgcHJpb3JpdHkuIElmIHlvdSBkb24ndCBs aWtlIHRoZSBuYW1lLA0KIHJlYWQgb24uIEl0IHdpbGwgZ3JvdyBvbiB5b3UuIDopPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNoZXAgKHcvbyBj aGFpciBoYXQpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIEZyaSwgRmViIDI4LCAyMDIwIGF0IDc6MzEgQU0gQWNlZSBMaW5kZW0gKGFjZWUp ICZsdDs8YSBocmVmPSJtYWlsdG86YWNlZUBjaXNjby5jb20iPmFjZWVAY2lzY28uY29tPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPklmIHlvdSBnbyB3aXRoIFBC UiwgeW91IGNvdWxkIGNvbnRpbnVlIHRoZSBCSUVSIFdHIHRyYWRpdGlvbmFsIG9mIHNlbGVjdGlu ZyBicmV3LWJhc2VkIGFjcm9ueW1zLiBIZW5jZSwgdGhhdCB3b3VsZCBiZSBteSB2b3RlLiBJdCBj b3VsZCBiZSBjb25mdXNlZCB3aXRoIFBvbGljeSBCYXNlZCBSb3V0aW5nIGJ1dCBvbmx5IGlmIHNv bWVvbmUgYWN0dWFsbHkgaW1wbGVtZW50cw0KIGl0Ljxicj4NClRoYW5rcyw8YnI+DQpBY2VlPGJy Pg0KPGJyPg0K77u/T24gMi8yOC8yMCwgOToyMyBBTSwgJnF1b3Q7QklFUiBvbiBiZWhhbGYgb2Yg VG9lcmxlc3MgRWNrZXJ0JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Ymllci1ib3VuY2VzQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Ymllci1ib3VuY2VzQGlldGYub3JnPC9hPiBvbiBiZWhh bGYgb2YNCjxhIGhyZWY9Im1haWx0bzp0dGVAY3MuZmF1LmRlIiB0YXJnZXQ9Il9ibGFuayI+dHRl QGNzLmZhdS5kZTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgU3VyZSwg SnVzdCByZXBseSB3dGggdGhlIG9uZXMgeW91IGxpa2Ugd2hldGhlciBleGlzdGluZyBvciBhZGRl ZCBhbmQ8YnI+DQombmJzcDsgJm5ic3A7IGdpdmUgdGhlbSB0aGUgd2VpaHQgeW91IGxpa2UsIGUu Zy46IGZyb20geW91ciBlbWFpbCBzb21ldGhpbmcgbGlrZTo8YnI+DQo8YnI+DQombmJzcDsgJm5i c3A7IDUmbmJzcDsgQklFUi1QQlImbmJzcDsgJm5ic3A7IChQYXRoIEJhc2VkIFJvdXRpbmcpPGJy Pg0KJm5ic3A7ICZuYnNwOyA1Jm5ic3A7IEJJRVItUFNUJm5ic3A7ICZuYnNwOyAoUGF0aCBiYXNl ZCBTVGVlcmluZyk8YnI+DQombmJzcDsgJm5ic3A7IDMmbmJzcDsgQklFUi1QRSZuYnNwOyAmbmJz cDsgJm5ic3A7KFBhdGggRW5naW5lZXJpbmcpPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBPbiBG cmksIEZlYiAyOCwgMjAyMCBhdCAwNzo1NDowN0FNICYjNDM7MDAwMCwgRGlyayBUcm9zc2VuIHdy b3RlOjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBUb2VybGVzcywgYWxsLDxicj4NCiZuYnNwOyAm bmJzcDsgJmd0OyA8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgTWF5IEkgYWRkIHRvIHRoZSBtaXgg KHdoaWNoIG1pZ2h0IG5vdCBoZWxwKSB3aXRoIHRoZSBwcm9wb3NhbCBmb3IgJ3BhdGgtYmFzZWQg cm91dGluZycgKG9yIEJJRVItUEJSKSBvciAncGF0aC1iYXNlZCBzdGVlcmluZycgKG9yIEJJRVIt UFNUKT8gSWYgeW91IHdhbnQgdG8ga2VlcCBhIHR3byBsZXR0ZXIgYWNyb255bSwgSSdkIGFkZCAn cGF0aCBzdGVlcmluZycgKHJhdGhlciB0aGFuIHBhdGggZW5naW5lZXJpbmcpIHRvIHRoZSBtaXgu IEZyb20NCiB0aGUgYmVsb3csIHdpdGhvdXQgY29uc2lkZXJpbmcgYW55IGFsdGVybmF0aXZlcywg SSdkIGdvIGZvciBCSUVSLVBFIGJ1dCBpdCBjb21lcyB3aXRoIHRoZSBpc3N1ZXMgbGlrZSBtYW55 IHR3byBsZXR0ZXIgYWNyb255bXMsIG5hbWVseSB0aGUgaGlnaGVyICdjb2xsaXNpb24gcmF0ZScg d2l0aCBvdGhlcnMuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IDxicj4NCiZuYnNwOyAmbmJzcDsg Jmd0OyBCZXN0LDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8YnI+DQombmJzcDsgJm5ic3A7ICZn dDsgRGlyazxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8YnI+DQombmJzcDsgJm5ic3A7ICZndDsg PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBGcm9tOiBCSUVSIFtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOmJpZXItYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPmJpZXItYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBUb2VybGVzcyBFY2tl cnQ8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgU2VudDogMjcgRmVicnVhcnkgMjAyMCAyMTo0MTxi cj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOmJpZXJAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5iaWVyQGlldGYub3JnPC9hPjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0 OyBDYzogTG91IEJlcmdlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxiZXJnZXJAbGFibi5uZXQiIHRh cmdldD0iX2JsYW5rIj5sYmVyZ2VyQGxhYm4ubmV0PC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86 Ymllci1hZHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5iaWVyLWFkc0BpZXRmLm9yZzwvYT47 IEJSVU5HQVJELCBERUJPUkFIIEEgJmx0OzxhIGhyZWY9Im1haWx0bzpkYjM1NDZAYXR0LmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmRiMzU0NkBhdHQuY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86 Ymllci1jaGFpcnNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5iaWVyLWNoYWlyc0BpZXRmLm9y ZzwvYT48YnI+DQombmJzcDsgJm5ic3A7ICZndDsgU3ViamVjdDogW0JpZXJdIFBscyAmcXVvdDt2 b3RlJnF1b3Q7IG9uIG5hbWUgKGRyYWZ0LWlldGYtYmllci10ZS1hcmNoKTxicj4NCiZuYnNwOyAm bmJzcDsgJmd0OyA8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgRGVhciBXRzxicj4NCiZuYnNwOyAm bmJzcDsgJmd0OyA8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgUGxlYXNlIGNoaW1lIGluIHdpdGgg b3BpbmlvbnMgYWJvdXQgdGhlIGZvbGxvd2luZyBvciBhbnkgbmV3IG5hbWUgeW91IGxpa2UgYXMg dGhlIG5ldyBuYW1lIGZvciBCSUVSLVRFLiBUaW1lb3V0IGlzIGRlYWRsaW5lIGZvciBzdWJtaXNz aW9uIG9mIGRyYWZ0IGJlZm9yZSBJRVRGMTA3LCB3aGVuIGknbGwgcG9zdCBhbiB1cGRhdGUuIElm IHlvdSBwcm9wb3NlIGEgbmV3IG5hbWUgdHJ5IHRvIGF2b2lkIHJlLXVzaW5nIGFiYnJldmlhdGlv bnMNCiB0aGF0IG1heSBiZSBtaXNpbnRlcnByZXRlZC48YnI+DQombmJzcDsgJm5ic3A7ICZndDsg PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IDUgPSBiZXN0IG5hbWUgZXZlciwgLi4uIDEgPSBsYW1l IG5hbWUsIG5vIG51bWJlciBhc3NpZ25lZCBtZWFucyAwIHZvdGVzIGFyZSBqdXN0IGFkZGVkIHVw IGFuZCBtYXhpbXVtIHN1bSBvcHRpb24gd2lucy48YnI+DQombmJzcDsgJm5ic3A7ICZndDsgRXhw bGFuYXRpb25zIGlmIHlvdSBoYXZlbid0IGZvbGxvd2VkIHRocmVhZCBhdCB0aGUgZW5kLjxicj4N CiZuYnNwOyAmbmJzcDsgJmd0OyA8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgQklFUi1QRSZuYnNw OyAtIFBhdGggRW5naW5lZXJpbmc8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgQklFUi1FVCZuYnNw OyAtIEV4cGxpY2l0IFRyZWVzPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IEJJRVItRUVUIC0gRXhw bGljaXQgRW5naW5lZXJlZCBUcmVlczxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBCSUVSLUJFVCAt IEJpdCBFbmdpbmVlcmVkIFRyZWVzPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IEJJRVItQlNUIC0g Qml0IFN0ZWVyZWQgVHJlZXM8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgQklFUi1UckUgLSBUcmVl IGVuZ2luZWVyaW5nPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IEJJRVItRVQmbmJzcDsgLSBFbmdp bmVlcmVkIFRyZWVzPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IEJJRVItU1QmbmJzcDsgLSBTdGVl cmVkIFRyZWVzPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0 OyBCSUVSLUFTQiAtIEFkamFjZW5jeSBTdGVlcmluZyBCaXRzJm5ic3A7ICZuYnNwOyhhZGphY2Vu Y2llcyBhcmUgaG93IGJpdHMgaW4gQklFUi1QRSBhcmUgZGVmaW5lZCk8YnI+DQombmJzcDsgJm5i c3A7ICZndDsgQklFUi1BQiZuYnNwOyAtIEFkamFjZW5jeSBCaXRzPGJyPg0KJm5ic3A7ICZuYnNw OyAmZ3Q7IEJJRVItU0ImbmJzcDsgLSBTdGVlcmluZyBCaXRzJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7KG92ZXJsb2FkcyB3aXRoICZxdW90O1NvdXJjZSBC bG9jayZxdW90OyAtIG5ldmVyIGhlYXJkKTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8YnI+DQom bmJzcDsgJm5ic3A7ICZndDsgVGhhbmtzLDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7VG9lcmxlc3M8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7 ICZuYnNwOyAmZ3Q7IEV4cGxhbmF0aW9uczogSWYgeW91IGhhdmUgcmVhZCB0aHJvdWdoIHRoZSB0 aHJlYWRzIHdpdGggTG91IGFuZCBEZWJvcmFoLCBhbmQgbXkgdW5kZXJzdGFuZGluZyBpcyBjb3Jy ZWN0Ojxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgTG91 IGRlc2lyZWQgdGhlcmUgdG8gYmUgYSBuZXcgbmFtZSBzbyBCSUVSLVRFIHRoZSBmb3J3YXJkaW5n L3N0ZWVyaW5nIG1lY2hhbmlzbSAodGhpcyBkb2N1bWVudCkgaXMgbmFtZWQgZGlmZmVyZW50bHkg ZnJvbSBCSUVSLVRFIHRoZSBsYXJnZXIgZnJhbWV3b3JrIHV0aWxpemluZyBURUFTL1BDRSBkZWZp bml0aW9uIChzZXBhcmF0ZSBmdXR1cmUgZHJhZnQpLjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8 YnI+DQombmJzcDsgJm5ic3A7ICZndDsgTG91IGRpZCBub3QgbGlrZSBteSAmcXVvdDtQYXRoIEVu Z2luZWVyaW5nJnF1b3Q7IHByb3Bvc2FsIGFzIHRoZSBuYW1lIGluIHRoZSBsYXN0IHZlcnNpb24g b2YgdGhlIGRvYyBhbmQgZmVsdCB3ZSBzaG91bGQgcGljayBhIG5hbWUgd2l0aCBTdGVlcmluZy9y b3V0aW5nLXBvbGljeSBpbiBpdC4gSSB0aGluayB1c24gb25seSBzdGVlcmluZy9yb3V0aW5nIHdv dWxkIGJlIG1pc2xlYWRpbmcgKGNvbmZ1c2VkIHdpdGggdW5pY2FzdCBhcHByb2FjaGVzKS48YnI+ DQombmJzcDsgJm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IERlYm9yYWggcG9p bnRlZCB0byBhdm9pZGluZyBjb25mdXNpb25zIGluIHRoZSBuYW1lIHdpdGggcHJlLWVzdGFibGlz aGVkIG5hbWVkIChlLmcuOiAmcXVvdDtQRSZxdW90OyBtZWFuaW5nIFByb3ZpZGVyIEVkZ2UpLjxi cj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBTYWlkIHdlIHNob3VsZCBmaW5hbGl6ZSBvbiB0aGUgbmFt ZSBiZWZvcmUgd2UgYXMgdGhlIFdHIHNob3VsZCBwYXNzIHRoZSBkb2N1bWVudCB0byBJRVNHLiBB bmQgc2hlIGFza2VkIGNoYWlycyB0byBleHRlbmQgbGFzdC1jYWxsIGJ5IG9uZSBtb3JlIHdlZWsg KHVucmVsYXRlZCkuIEhlbmNlIHRpbWVvdXQgZW5kIG9mIG5leHQgd2Vlay48YnI+DQombmJzcDsg Jm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IEJJRVIg bWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpCSUVS QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+QklFUkBpZXRmLm9yZzwvYT48YnI+DQombmJzcDsg Jm5ic3A7ICZndDsgPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iaWVyX187ISFORXQ2eU1hTy1nayFYVHF3dHMy LTV6ZG8xSWtRQzUtVS1BT0dLNllYZTY0R3VEN3BweWFFRExMazZ5RjJERkpHMzlaM2dXQVFfZjJL JCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9iaWVyPC9hPjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8YnI+DQombmJzcDsgJm5ic3A7ICZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQom bmJzcDsgJm5ic3A7ICZndDsgQklFUiBtYWlsaW5nIGxpc3Q8YnI+DQombmJzcDsgJm5ic3A7ICZn dDsgPGEgaHJlZj0ibWFpbHRvOkJJRVJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5CSUVSQGll dGYub3JnPC9hPjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8YSBocmVmPSJodHRwczovL3VybGRl ZmVuc2UuY29tL3YzL19faHR0cHM6L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JpZXJf XzshIU5FdDZ5TWFPLWdrIVhUcXd0czItNXpkbzFJa1FDNS1VLUFPR0s2WVhlNjRHdUQ3cHB5YUVE TExrNnlGMkRGSkczOVozZ1dBUV9mMkskIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JpZXI8L2E+PGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw OyAtLSA8YnI+DQombmJzcDsgJm5ic3A7IC0tLTxicj4NCiZuYnNwOyAmbmJzcDsgPGEgaHJlZj0i bWFpbHRvOnR0ZUBjcy5mYXUuZGUiIHRhcmdldD0iX2JsYW5rIj50dGVAY3MuZmF1Li5kZTwvYT48 YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KJm5ic3A7ICZuYnNwOyBCSUVSIG1haWxpbmcgbGlzdDxicj4N CiZuYnNwOyAmbmJzcDsgPGEgaHJlZj0ibWFpbHRvOkJJRVJAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5CSUVSQGlldGYub3JnPC9hPjxicj4NCiZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0cHM6 Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9iaWVyX187ISFORXQ2eU1hTy1nayFYVHF3dHMyLTV6ZG8xSWtRQzUtVS1BT0dLNllYZTY0R3VE N3BweWFFRExMazZ5RjJERkpHMzlaM2dXQVFfZjJLJCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9iaWVyPC9hPjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_MN2PR05MB59812228B37EECDC684B433ED4E80MN2PR05MB5981namp_-- From nobody Fri Feb 28 14:40:19 2020 Return-Path: X-Original-To: bier@ietf.org Delivered-To: bier@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 597ED3A1B2F; Fri, 28 Feb 2020 14:35:29 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: aretana.ietf@gmail.com, bier@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158292932934.19931.1416073364018051999@ietfa.amsl.com> Date: Fri, 28 Feb 2020 14:35:29 -0800 Archived-At: Subject: [Bier] bier - Requested session has been scheduled for IETF 107 X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 22:35:37 -0000 Dear Greg Shepherd, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. bier Session 1 (2:00 requested) Wednesday, 25 March 2020, Morning Session I 1000-1200 Room Name: Georgia A size: 100 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/sessions/bier.ics Request Information: --------------------------------------------------------- Working Group Name: Bit Indexed Explicit Replication Area Name: Routing Area Session Requester: Greg Shepherd Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: mpls pim lsr mboned roll spring rift idr People who must be present: Tony Przygienda Greg Shepherd Alvaro Retana Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Feb 28 15:13:23 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76C013A1D7B for ; Fri, 28 Feb 2020 15:13:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, 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 (768-bit key) header.d=labn.net 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 fJmKVmHy8pNA for ; Fri, 28 Feb 2020 15:13:21 -0800 (PST) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) (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 A77CC3A1B9A for ; Fri, 28 Feb 2020 15:13:20 -0800 (PST) Received: from cmgw15.unifiedlayer.com (unknown [10.9.0.15]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id 6DD8140132 for ; Fri, 28 Feb 2020 16:13:17 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id 7oonjHw8N1as57oonjKA1z; Fri, 28 Feb 2020 16:13:17 -0700 X-Authority-Reason: nr=8 X-Authority-Analysis: v=2.3 cv=HoJY5XbS c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=dLZJa+xiwSxG16/P+YVxDGlgEgI=:19 a=xqWC_Br6kY4A:10:nop_ipv6 a=l697ptgUJYAA:10:nop_rcvd_month_year a=Vy_oeq2dmq0A:10:endurance_base64_authed_username_1 a=r77TgQKjGQsHNAKrUKIA:9 a=pGLkceISAAAA:8 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=wU2YTnxGAAAA:8 a=zQP7CpKOAAAA:8 a=470PsG_FMCf2IZooNgwA:9 a=uxrWFqYfGlSz7FIa:21 a=pcvXs96-GMJHHkDP:21 a=QEXdDO2ut3YA:10:nop_charset_2 a=gfGs23yA7rLORz4d9P8A:9 a=rC73a_Nn0qH7YDKz:21 a=mEDczMhu5jpx_xiw:21 a=qF4OkqZY-QZbPfRs:21 a=_W_S_7VecoQA:10:nop_html a=w1C3t2QeGrPiZgrLijVG:22 a=Yz9wTY_ffGCQnEDHKrcv:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:MIME-Version:Subject:References:In-Reply-To: Message-ID:Date:CC:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=orsbqtHTqOIdztJtIyI1EIX0CiZxOsR1i3wGL0R0UAw=; b=zahVsoeRMws+mAwd5AN3N79jhD gawy3gMcSoJl1qAHoTdYb6G0JOj/P5RIQENY7QPD8LbOQz7y5nim3bCUvBqC+KvQ+HBsBitqEre61 0oY+dQrDzHXH4P2fnYqp6wBI+; Received: from [172.58.187.173] (port=51884 helo=[IPV6:2607:fb90:a833:59c2:0:b:68e4:c901]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1j7oom-002Q5X-SI; Fri, 28 Feb 2020 16:13:17 -0700 From: Lou Berger To: Tony Przygienda , Greg Shepherd CC: Dirk Trossen , , , "BRUNGARD, DEBORAH A" , Toerless Eckert , "Acee Lindem (acee)" , Date: Fri, 28 Feb 2020 18:13:14 -0500 Message-ID: <1708e134728.277b.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: <20200227204038.GB23965@faui48f.informatik.uni-erlangen.de> <91BA3A406CA139458B56D8C52EAB227D147F35@lhreml501-mbs> <20200228142253.GA44403@faui48f.informatik.uni-erlangen.de> <5A558653-37FD-4D0B-A637-8F0078D91C81@cisco.com> User-Agent: AquaMail/1.22.0-1511 (build: 102200004) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------1708e134b5b7ea8277b8677494" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 172.58.187.173 X-Source-L: No X-Exim-ID: 1j7oom-002Q5X-SI X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPV6:2607:fb90:a833:59c2:0:b:68e4:c901]) [172.58.187.173]:51884 X-Source-Auth: lberger@labn.net X-Email-Count: 6 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Org: HG=bhcustomer;ORG=bluehost; X-Local-Domain: yes Archived-At: Subject: Re: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 23:13:23 -0000 This is a multi-part message in MIME format. ------------1708e134b5b7ea8277b8677494 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit Chairs/all Rather than play games with the name why not just add the one section that's missing to support traffic engineering and then you can legitimately call it TE? (Some may have noted that this was my preference in my mail that kicked off this discussion.). I'm even happy to contribute text. Doesn't this make the most sense? Lou ---------- On February 28, 2020 11:03:04 AM Tony Przygienda wrote: > Yepp, I concur with Greg ... tony > > On Fri, Feb 28, 2020 at 8:00 AM Greg Shepherd wrote: > >> My vote: BIER-TE >> Call it Tree Engineering. If we were so concerned with acronym overuse the >> IETF would grind to a halt. I've been involved in other WGs where I felt >> the name missed the mark describing the ideas in the draft, but felt >> reading the draft was how someone got their heads around the proposed >> solution, rather than miss-read the title and run away confused. ie - >> Vlex-Algo. No, it's Flex-Topo, but what's to be gained from arguing for a >> name at this point? >> >> Yes, we should strive to be as 'correct' as possible. But the IETF is full >> of baggage that engineers have managed to wade through, make sense of, and >> implement successfully. Get the spec right, No #1 priority. If you don't >> like the name, read on. It will grow on you. :) >> >> Shep (w/o chair hat) >> >> On Fri, Feb 28, 2020 at 7:31 AM Acee Lindem (acee) wrote: >> >>> If you go with PBR, you could continue the BIER WG traditional of >>> selecting brew-based acronyms. Hence, that would be my vote. It could be >>> confused with Policy Based Routing but only if someone actually implements >>> it. >>> Thanks, >>> Acee >>> >>> On 2/28/20, 9:23 AM, "BIER on behalf of Toerless Eckert" < >>> bier-bounces@ietf.org on behalf of tte@cs.fau.de> wrote: >>> >>> Sure, Just reply wth the ones you like whether existing or added and >>> give them the weiht you like, e.g.: from your email something like: >>> >>> 5 BIER-PBR (Path Based Routing) >>> 5 BIER-PST (Path based STeering) >>> 3 BIER-PE (Path Engineering) >>> >>> On Fri, Feb 28, 2020 at 07:54:07AM +0000, Dirk Trossen wrote: >>> > Toerless, all, >>> > >>> > May I add to the mix (which might not help) with the proposal for >>> 'path-based routing' (or BIER-PBR) or 'path-based steering' (or BIER-PST)? >>> If you want to keep a two letter acronym, I'd add 'path steering' (rather >>> than path engineering) to the mix. From the below, without considering any >>> alternatives, I'd go for BIER-PE but it comes with the issues like many two >>> letter acronyms, namely the higher 'collision rate' with others. >>> > >>> > Best, >>> > >>> > Dirk >>> > >>> > >>> > >>> > -----Original Message----- >>> > From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Toerless >>> Eckert >>> > Sent: 27 February 2020 21:41 >>> > To: bier@ietf.org >>> > Cc: Lou Berger ; bier-ads@ietf.org; BRUNGARD, >>> DEBORAH A ; bier-chairs@ietf.org >>> > Subject: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) >>> > >>> > Dear WG >>> > >>> > Please chime in with opinions about the following or any new name >>> you like as the new name for BIER-TE. Timeout is deadline for submission of >>> draft before IETF107, when i'll post an update. If you propose a new name >>> try to avoid re-using abbreviations that may be misinterpreted. >>> > >>> > 5 = best name ever, ... 1 = lame name, no number assigned means 0 >>> votes are just added up and maximum sum option wins. >>> > Explanations if you haven't followed thread at the end. >>> > >>> > BIER-PE - Path Engineering >>> > BIER-ET - Explicit Trees >>> > BIER-EET - Explicit Engineered Trees >>> > BIER-BET - Bit Engineered Trees >>> > BIER-BST - Bit Steered Trees >>> > BIER-TrE - Tree engineering >>> > BIER-ET - Engineered Trees >>> > BIER-ST - Steered Trees >>> > >>> > BIER-ASB - Adjacency Steering Bits (adjacencies are how bits in >>> BIER-PE are defined) >>> > BIER-AB - Adjacency Bits >>> > BIER-SB - Steering Bits (overloads with "Source Block" >>> - never heard) >>> > >>> > Thanks, >>> > Toerless >>> > >>> > Explanations: If you have read through the threads with Lou and >>> Deborah, and my understanding is correct: >>> > >>> > Lou desired there to be a new name so BIER-TE the >>> forwarding/steering mechanism (this document) is named differently from >>> BIER-TE the larger framework utilizing TEAS/PCE definition (separate future >>> draft). >>> > >>> > Lou did not like my "Path Engineering" proposal as the name in the >>> last version of the doc and felt we should pick a name with >>> Steering/routing-policy in it. I think usn only steering/routing would be >>> misleading (confused with unicast approaches). >>> > >>> > Deborah pointed to avoiding confusions in the name with >>> pre-established named (e.g.: "PE" meaning Provider Edge). >>> > Said we should finalize on the name before we as the WG should pass >>> the document to IESG. And she asked chairs to extend last-call by one more >>> week (unrelated). Hence timeout end of next week. >>> > >>> > _______________________________________________ >>> > BIER mailing list >>> > BIER@ietf.org >>> > https://www.ietf.org/mailman/listinfo/bier >>> > >>> > _______________________________________________ >>> > BIER mailing list >>> > BIER@ietf.org >>> > https://www.ietf.org/mailman/listinfo/bier >>> >>> -- >>> --- >>> tte@cs.fau.de >>> >>> _______________________________________________ >>> BIER mailing list >>> BIER@ietf.org >>> https://www.ietf.org/mailman/listinfo/bier >>> >>> >>> > > > > ---------- > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > ------------1708e134b5b7ea8277b8677494 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Chairs/all

Rather than play games with t= he name why not just add the one section that's missing to support traffic = engineering and then you can legitimately call it TE? (Some may have noted = that this was my preference in my mail that kicked off this discussion.). I= 'm even happy to contribute text.

Doesn't this make the most se= nse?

Lou

On February 28, 2020 11:03:04 AM Tony Przygienda <tonysietf@gma= il.com> wrote:

Yepp, I concur with Greg ... tony

On Fri, Feb 28, 2020= at 8:00 AM Greg Shepherd <gjshep@gm= ail.com> wrote:
My vote: BIER-TE=C2=A0
Call it Tree Engineering= .. If we were so concerned=C2=A0with acronym overuse the IETF would grind t= o a halt. I've been involved in other WGs where I felt the name missed = the mark describing the ideas in the draft, but felt reading the draft was = how someone got their heads around the proposed solution, rather than miss-= read the title and run away confused. ie - Vlex-Algo. No, it's Flex-Top= o, but what's to be gained from arguing for a name at this point?=C2=A0=

Yes, we should strive=C2=A0to be as 'correct&= #39; as possible. But the IETF is full of baggage that engineers have manag= ed to wade through, make sense of, and implement successfully. Get the spec= right, No #1 priority. If you don't like the name, read on. It will gr= ow on you. :)

Shep (w/o chair hat)

=
On Fri, Fe= b 28, 2020 at 7:31 AM Acee Lindem (acee) <acee@cisco.com> wrote:
If you go with PBR, you could continue = the BIER WG traditional of selecting brew-based acronyms. Hence, that would= be my vote. It could be confused with Policy Based Routing but only if som= eone actually implements it.
Thanks,
Acee

=EF=BB=BFOn 2/28/20, 9:23 AM, "BIER on behalf of Toerless Eckert"= <bier-bounce= s@ietf.org on behalf of tte@cs.fau.de> wrote:

=C2=A0 =C2=A0 Sure, Just reply wth the ones you like whether existing or ad= ded and
=C2=A0 =C2=A0 give them the weiht you like, e.g.: from your email something= like:

=C2=A0 =C2=A0 5=C2=A0 BIER-PBR=C2=A0 =C2=A0 (Path Based Routing)
=C2=A0 =C2=A0 5=C2=A0 BIER-PST=C2=A0 =C2=A0 (Path based STeering)
=C2=A0 =C2=A0 3=C2=A0 BIER-PE=C2=A0 =C2=A0 =C2=A0(Path Engineering)

=C2=A0 =C2=A0 On Fri, Feb 28, 2020 at 07:54:07AM +0000, Dirk Trossen wrote:=
=C2=A0 =C2=A0 > Toerless, all,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > May I add to the mix (which might not help) with the pro= posal for 'path-based routing' (or BIER-PBR) or 'path-based ste= ering' (or BIER-PST)? If you want to keep a two letter acronym, I'd= add 'path steering' (rather than path engineering) to the mix. Fro= m the below, without considering any alternatives, I'd go for BIER-PE b= ut it comes with the issues like many two letter acronyms, namely the highe= r 'collision rate' with others.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Best,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Dirk
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > -----Original Message-----
=C2=A0 =C2=A0 > From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Toerless Ecke= rt
=C2=A0 =C2=A0 > Sent: 27 February 2020 21:41
=C2=A0 =C2=A0 > To: b= ier@ietf.org
=C2=A0 =C2=A0 > Cc: Lou Berger <lberger@labn.net>; bier-ads@ietf.org; BRUNGARD, DEBORAH A <db3546@att.com>; bier-chairs@ietf.org<= /a>
=C2=A0 =C2=A0 > Subject: [Bier] Pls "vote" on name (draft-ietf= -bier-te-arch)
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Dear WG
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Please chime in with opinions about the following or any= new name you like as the new name for BIER-TE. Timeout is deadline for sub= mission of draft before IETF107, when i'll post an update. If you propo= se a new name try to avoid re-using abbreviations that may be misinterprete= d.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > 5 =3D best name ever, ... 1 =3D lame name, no number ass= igned means 0 votes are just added up and maximum sum option wins.
=C2=A0 =C2=A0 > Explanations if you haven't followed thread at the e= nd.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > BIER-PE=C2=A0 - Path Engineering
=C2=A0 =C2=A0 > BIER-ET=C2=A0 - Explicit Trees
=C2=A0 =C2=A0 > BIER-EET - Explicit Engineered Trees
=C2=A0 =C2=A0 > BIER-BET - Bit Engineered Trees
=C2=A0 =C2=A0 > BIER-BST - Bit Steered Trees
=C2=A0 =C2=A0 > BIER-TrE - Tree engineering
=C2=A0 =C2=A0 > BIER-ET=C2=A0 - Engineered Trees
=C2=A0 =C2=A0 > BIER-ST=C2=A0 - Steered Trees
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > BIER-ASB - Adjacency Steering Bits=C2=A0 =C2=A0(adjacenc= ies are how bits in BIER-PE are defined)
=C2=A0 =C2=A0 > BIER-AB=C2=A0 - Adjacency Bits
=C2=A0 =C2=A0 > BIER-SB=C2=A0 - Steering Bits=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0(overloads with "Source Block" - never heard= )
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Thanks,
=C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Toerless
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Explanations: If you have read through the threads with = Lou and Deborah, and my understanding is correct:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Lou desired there to be a new name so BIER-TE the forwar= ding/steering mechanism (this document) is named differently from BIER-TE t= he larger framework utilizing TEAS/PCE definition (separate future draft).<= br> =C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Lou did not like my "Path Engineering" proposa= l as the name in the last version of the doc and felt we should pick a name= with Steering/routing-policy in it. I think usn only steering/routing woul= d be misleading (confused with unicast approaches).
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Deborah pointed to avoiding confusions in the name with = pre-established named (e.g.: "PE" meaning Provider Edge).
=C2=A0 =C2=A0 > Said we should finalize on the name before we as the WG = should pass the document to IESG. And she asked chairs to extend last-call = by one more week (unrelated). Hence timeout end of next week.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > BIER mailing list
=C2=A0 =C2=A0 > BIER@= ietf.org
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/b= ier
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > BIER mailing list
=C2=A0 =C2=A0 > BIER@= ietf.org
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/b= ier

=C2=A0 =C2=A0 --
=C2=A0 =C2=A0 ---
=C2=A0 =C2=A0 tte@cs.fau= ..de

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 BIER mailing list
=C2=A0 =C2=A0 BIER@ietf.= org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/bier


_______________________________________________
BIER mailing list

------------1708e134b5b7ea8277b8677494-- From nobody Fri Feb 28 16:31:46 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE323A07AE; Fri, 28 Feb 2020 16:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 G3RW3Y2D6YKA; Fri, 28 Feb 2020 16:31:41 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A1753A07AB; Fri, 28 Feb 2020 16:31:40 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 23169548052; Sat, 29 Feb 2020 01:31:35 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 1C98D440040; Sat, 29 Feb 2020 01:31:35 +0100 (CET) Date: Sat, 29 Feb 2020 01:31:35 +0100 From: Toerless Eckert To: Lou Berger Cc: Tony Przygienda , Greg Shepherd , Dirk Trossen , bier@ietf.org, bier-ads@ietf.org, "BRUNGARD, DEBORAH A" , "Acee Lindem (acee)" , bier-chairs@ietf.org Message-ID: <20200229003135.GE44403@faui48f.informatik.uni-erlangen.de> References: <20200227204038.GB23965@faui48f.informatik.uni-erlangen.de> <91BA3A406CA139458B56D8C52EAB227D147F35@lhreml501-mbs> <20200228142253.GA44403@faui48f.informatik.uni-erlangen.de> <5A558653-37FD-4D0B-A637-8F0078D91C81@cisco.com> <1708e134728.277b.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1708e134728.277b.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 00:31:44 -0000 I do not think we are playing games, we are i think just following the advice a least as i understand it from the feedback received from you and Deb. I added a section 1.1 after your first feedback explaining how this BIER-PE draft relates to traffic engineering the best way i understand it, but then you suggested that i should remove it again or else it would require mayor changes (which i still expressed interest in seeing). If you think traffic engineering support would only require an additional section (without changes to the rest of the document ?) then i would happy to understand what that section would need to say and of course you are more than welcome to contribute text. I can not say yet if that solution makes more sense unless i understand better what you are proposing. But i think it would be great if it did (make more sense). And no, i am sorry, but i did not read your preference to extend this document to be able to claim traffic engineering from the feedback i have seen from you so far. Cheers Toerless On Fri, Feb 28, 2020 at 06:13:14PM -0500, Lou Berger wrote: > Chairs/all > > Rather than play games with the name why not just add the one section that's > missing to support traffic engineering and then you can legitimately call it > TE? (Some may have noted that this was my preference in my mail that kicked > off this discussion.). I'm even happy to contribute text. > > Doesn't this make the most sense? > > Lou > > > ---------- > On February 28, 2020 11:03:04 AM Tony Przygienda wrote: > > > Yepp, I concur with Greg ... tony > > > > On Fri, Feb 28, 2020 at 8:00 AM Greg Shepherd wrote: > > > > > My vote: BIER-TE > > > Call it Tree Engineering. If we were so concerned with acronym overuse the > > > IETF would grind to a halt. I've been involved in other WGs where I felt > > > the name missed the mark describing the ideas in the draft, but felt > > > reading the draft was how someone got their heads around the proposed > > > solution, rather than miss-read the title and run away confused. ie - > > > Vlex-Algo. No, it's Flex-Topo, but what's to be gained from arguing for a > > > name at this point? > > > > > > Yes, we should strive to be as 'correct' as possible. But the IETF is full > > > of baggage that engineers have managed to wade through, make sense of, and > > > implement successfully. Get the spec right, No #1 priority. If you don't > > > like the name, read on. It will grow on you. :) > > > > > > Shep (w/o chair hat) > > > > > > On Fri, Feb 28, 2020 at 7:31 AM Acee Lindem (acee) wrote: > > > > > > > If you go with PBR, you could continue the BIER WG traditional of > > > > selecting brew-based acronyms. Hence, that would be my vote. It could be > > > > confused with Policy Based Routing but only if someone actually implements > > > > it. > > > > Thanks, > > > > Acee > > > > > > > > ???On 2/28/20, 9:23 AM, "BIER on behalf of Toerless Eckert" < > > > > bier-bounces@ietf.org on behalf of tte@cs.fau.de> wrote: > > > > > > > > Sure, Just reply wth the ones you like whether existing or added and > > > > give them the weiht you like, e.g.: from your email something like: > > > > > > > > 5 BIER-PBR (Path Based Routing) > > > > 5 BIER-PST (Path based STeering) > > > > 3 BIER-PE (Path Engineering) > > > > > > > > On Fri, Feb 28, 2020 at 07:54:07AM +0000, Dirk Trossen wrote: > > > > > Toerless, all, > > > > > > > > > > May I add to the mix (which might not help) with the proposal for > > > > 'path-based routing' (or BIER-PBR) or 'path-based steering' (or BIER-PST)? > > > > If you want to keep a two letter acronym, I'd add 'path steering' (rather > > > > than path engineering) to the mix. From the below, without considering any > > > > alternatives, I'd go for BIER-PE but it comes with the issues like many two > > > > letter acronyms, namely the higher 'collision rate' with others. > > > > > > > > > > Best, > > > > > > > > > > Dirk > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Toerless > > > > Eckert > > > > > Sent: 27 February 2020 21:41 > > > > > To: bier@ietf.org > > > > > Cc: Lou Berger ; bier-ads@ietf.org; BRUNGARD, > > > > DEBORAH A ; bier-chairs@ietf.org > > > > > Subject: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) > > > > > > > > > > Dear WG > > > > > > > > > > Please chime in with opinions about the following or any new name > > > > you like as the new name for BIER-TE. Timeout is deadline for submission of > > > > draft before IETF107, when i'll post an update. If you propose a new name > > > > try to avoid re-using abbreviations that may be misinterpreted. > > > > > > > > > > 5 = best name ever, ... 1 = lame name, no number assigned means 0 > > > > votes are just added up and maximum sum option wins. > > > > > Explanations if you haven't followed thread at the end. > > > > > > > > > > BIER-PE - Path Engineering > > > > > BIER-ET - Explicit Trees > > > > > BIER-EET - Explicit Engineered Trees > > > > > BIER-BET - Bit Engineered Trees > > > > > BIER-BST - Bit Steered Trees > > > > > BIER-TrE - Tree engineering > > > > > BIER-ET - Engineered Trees > > > > > BIER-ST - Steered Trees > > > > > > > > > > BIER-ASB - Adjacency Steering Bits (adjacencies are how bits in > > > > BIER-PE are defined) > > > > > BIER-AB - Adjacency Bits > > > > > BIER-SB - Steering Bits (overloads with "Source Block" > > > > - never heard) > > > > > > > > > > Thanks, > > > > > Toerless > > > > > > > > > > Explanations: If you have read through the threads with Lou and > > > > Deborah, and my understanding is correct: > > > > > > > > > > Lou desired there to be a new name so BIER-TE the > > > > forwarding/steering mechanism (this document) is named differently from > > > > BIER-TE the larger framework utilizing TEAS/PCE definition (separate future > > > > draft). > > > > > > > > > > Lou did not like my "Path Engineering" proposal as the name in the > > > > last version of the doc and felt we should pick a name with > > > > Steering/routing-policy in it. I think usn only steering/routing would be > > > > misleading (confused with unicast approaches). > > > > > > > > > > Deborah pointed to avoiding confusions in the name with > > > > pre-established named (e.g.: "PE" meaning Provider Edge). > > > > > Said we should finalize on the name before we as the WG should pass > > > > the document to IESG. And she asked chairs to extend last-call by one more > > > > week (unrelated). Hence timeout end of next week. > > > > > > > > > > _______________________________________________ > > > > > BIER mailing list > > > > > BIER@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/bier > > > > > > > > > > _______________________________________________ > > > > > BIER mailing list > > > > > BIER@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/bier > > > > > > > > -- > > > > --- > > > > tte@cs.fau.de > > > > > > > > _______________________________________________ > > > > BIER mailing list > > > > BIER@ietf.org > > > > https://www.ietf.org/mailman/listinfo/bier > > > > > > > > > > > > > > > > > > > > ---------- > > _______________________________________________ > > BIER mailing list > > BIER@ietf.org > > https://www.ietf.org/mailman/listinfo/bier > > -- --- tte@cs.fau.de From nobody Fri Feb 28 16:52:10 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228783A081A; Fri, 28 Feb 2020 16:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 riNsqybghTWH; Fri, 28 Feb 2020 16:52:05 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2F083A0818; Fri, 28 Feb 2020 16:52:05 -0800 (PST) Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 44D81548053; Sat, 29 Feb 2020 01:52:00 +0100 (CET) Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 3DA7A440040; Sat, 29 Feb 2020 01:52:00 +0100 (CET) Date: Sat, 29 Feb 2020 01:52:00 +0100 From: Toerless Eckert To: Lou Berger Cc: Dirk Trossen , Greg Shepherd , bier@ietf.org, bier-ads@ietf.org, "BRUNGARD, DEBORAH A" , bier-chairs@ietf.org, "Acee Lindem (acee)" Message-ID: <20200229005200.GF44403@faui48f.informatik.uni-erlangen.de> References: <20200227204038.GB23965@faui48f.informatik.uni-erlangen.de> <91BA3A406CA139458B56D8C52EAB227D147F35@lhreml501-mbs> <20200228142253.GA44403@faui48f.informatik.uni-erlangen.de> <5A558653-37FD-4D0B-A637-8F0078D91C81@cisco.com> <1708e134728.277b.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20200229003135.GE44403@faui48f.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200229003135.GE44403@faui48f.informatik.uni-erlangen.de> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 00:52:08 -0000 Pressed :wq (send button) too fast, quick amendment: If i think of a larger "Traffic Engineering" with BIER framework (BIER-TE ?) i think that could also include BIER (not BIER-PE) combined with PCE, combined with same bandwdith/buffering addons, but now we have no explicit per-tree path steering but could only combine with what i called unicast policy routing (e.g.: (flex-)topologies, which of course more limited in path steering than BIER-PE. [ If thats too confusing, think of IPv6 multicast to make the question easier: PIM-SM plus RSVP (NOT RSVP-TE) plus e.g.: optional (flex)topologies plus PCE. ] I do not know if such options could rightfully be called "Traffic Engineering" (which i think is a term wholly owned by TEAS). If it would, and if it would be desirable for TEAS to also document such an option, and have that be covered under the larger umbrella of BIER Traffic Engineering (together of course with the option of BIER-PE), then we would have the fact that we are back to the naming overlap where we started: BIER-TE(1) as this documents Tree Engineering method , but called "Traffic Engineering" BIER-TE(2) as a larger framework with the option to include BIER-TE(1) and BIER, and also called "Traffic Engineering". WG seems to like calling BIER-TE(1) "Tree Engineering", so we'd end up with the same abbreviation, but at least two different meanings between (1) and (2). But i'll withhold my opinion about what i'd ultimately think is least confusing until i hear back from you about what you think the section you claim missing in the doc would exactly have to entail. Just wanted to add what i missed to say in the first mail. Cheers Toerless On Sat, Feb 29, 2020 at 01:31:35AM +0100, Toerless Eckert wrote: > I do not think we are playing games, we are i think just following the > advice a least as i understand it from the feedback received from you and Deb. > > I added a section 1.1 after your first feedback explaining how this > BIER-PE draft relates to traffic engineering the best way i understand it, > but then you suggested that i should remove it again or else it would > require mayor changes (which i still expressed interest in seeing). > > If you think traffic engineering support would only require an additional section > (without changes to the rest of the document ?) then i would happy to > understand what that section would need to say and of course you are > more than welcome to contribute text. > > I can not say yet if that solution makes more sense unless i understand > better what you are proposing. But i think it would be great if it did > (make more sense). > > And no, i am sorry, but i did not read your preference to extend this > document to be able to claim traffic engineering from the feedback i > have seen from you so far. > > Cheers > Toerless > > On Fri, Feb 28, 2020 at 06:13:14PM -0500, Lou Berger wrote: > > Chairs/all > > > > Rather than play games with the name why not just add the one section that's > > missing to support traffic engineering and then you can legitimately call it > > TE? (Some may have noted that this was my preference in my mail that kicked > > off this discussion.). I'm even happy to contribute text. > > > > Doesn't this make the most sense? > > > > Lou > > > > > > ---------- > > On February 28, 2020 11:03:04 AM Tony Przygienda wrote: > > > > > Yepp, I concur with Greg ... tony > > > > > > On Fri, Feb 28, 2020 at 8:00 AM Greg Shepherd wrote: > > > > > > > My vote: BIER-TE > > > > Call it Tree Engineering. If we were so concerned with acronym overuse the > > > > IETF would grind to a halt. I've been involved in other WGs where I felt > > > > the name missed the mark describing the ideas in the draft, but felt > > > > reading the draft was how someone got their heads around the proposed > > > > solution, rather than miss-read the title and run away confused. ie - > > > > Vlex-Algo. No, it's Flex-Topo, but what's to be gained from arguing for a > > > > name at this point? > > > > > > > > Yes, we should strive to be as 'correct' as possible. But the IETF is full > > > > of baggage that engineers have managed to wade through, make sense of, and > > > > implement successfully. Get the spec right, No #1 priority. If you don't > > > > like the name, read on. It will grow on you. :) > > > > > > > > Shep (w/o chair hat) > > > > > > > > On Fri, Feb 28, 2020 at 7:31 AM Acee Lindem (acee) wrote: > > > > > > > > > If you go with PBR, you could continue the BIER WG traditional of > > > > > selecting brew-based acronyms. Hence, that would be my vote. It could be > > > > > confused with Policy Based Routing but only if someone actually implements > > > > > it. > > > > > Thanks, > > > > > Acee > > > > > > > > > > ???On 2/28/20, 9:23 AM, "BIER on behalf of Toerless Eckert" < > > > > > bier-bounces@ietf.org on behalf of tte@cs.fau.de> wrote: > > > > > > > > > > Sure, Just reply wth the ones you like whether existing or added and > > > > > give them the weiht you like, e.g.: from your email something like: > > > > > > > > > > 5 BIER-PBR (Path Based Routing) > > > > > 5 BIER-PST (Path based STeering) > > > > > 3 BIER-PE (Path Engineering) > > > > > > > > > > On Fri, Feb 28, 2020 at 07:54:07AM +0000, Dirk Trossen wrote: > > > > > > Toerless, all, > > > > > > > > > > > > May I add to the mix (which might not help) with the proposal for > > > > > 'path-based routing' (or BIER-PBR) or 'path-based steering' (or BIER-PST)? > > > > > If you want to keep a two letter acronym, I'd add 'path steering' (rather > > > > > than path engineering) to the mix. From the below, without considering any > > > > > alternatives, I'd go for BIER-PE but it comes with the issues like many two > > > > > letter acronyms, namely the higher 'collision rate' with others. > > > > > > > > > > > > Best, > > > > > > > > > > > > Dirk > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Toerless > > > > > Eckert > > > > > > Sent: 27 February 2020 21:41 > > > > > > To: bier@ietf.org > > > > > > Cc: Lou Berger ; bier-ads@ietf.org; BRUNGARD, > > > > > DEBORAH A ; bier-chairs@ietf.org > > > > > > Subject: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) > > > > > > > > > > > > Dear WG > > > > > > > > > > > > Please chime in with opinions about the following or any new name > > > > > you like as the new name for BIER-TE. Timeout is deadline for submission of > > > > > draft before IETF107, when i'll post an update. If you propose a new name > > > > > try to avoid re-using abbreviations that may be misinterpreted. > > > > > > > > > > > > 5 = best name ever, ... 1 = lame name, no number assigned means 0 > > > > > votes are just added up and maximum sum option wins. > > > > > > Explanations if you haven't followed thread at the end. > > > > > > > > > > > > BIER-PE - Path Engineering > > > > > > BIER-ET - Explicit Trees > > > > > > BIER-EET - Explicit Engineered Trees > > > > > > BIER-BET - Bit Engineered Trees > > > > > > BIER-BST - Bit Steered Trees > > > > > > BIER-TrE - Tree engineering > > > > > > BIER-ET - Engineered Trees > > > > > > BIER-ST - Steered Trees > > > > > > > > > > > > BIER-ASB - Adjacency Steering Bits (adjacencies are how bits in > > > > > BIER-PE are defined) > > > > > > BIER-AB - Adjacency Bits > > > > > > BIER-SB - Steering Bits (overloads with "Source Block" > > > > > - never heard) > > > > > > > > > > > > Thanks, > > > > > > Toerless > > > > > > > > > > > > Explanations: If you have read through the threads with Lou and > > > > > Deborah, and my understanding is correct: > > > > > > > > > > > > Lou desired there to be a new name so BIER-TE the > > > > > forwarding/steering mechanism (this document) is named differently from > > > > > BIER-TE the larger framework utilizing TEAS/PCE definition (separate future > > > > > draft). > > > > > > > > > > > > Lou did not like my "Path Engineering" proposal as the name in the > > > > > last version of the doc and felt we should pick a name with > > > > > Steering/routing-policy in it. I think usn only steering/routing would be > > > > > misleading (confused with unicast approaches). > > > > > > > > > > > > Deborah pointed to avoiding confusions in the name with > > > > > pre-established named (e.g.: "PE" meaning Provider Edge). > > > > > > Said we should finalize on the name before we as the WG should pass > > > > > the document to IESG. And she asked chairs to extend last-call by one more > > > > > week (unrelated). Hence timeout end of next week. > > > > > > > > > > > > _______________________________________________ > > > > > > BIER mailing list > > > > > > BIER@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/bier > > > > > > > > > > > > _______________________________________________ > > > > > > BIER mailing list > > > > > > BIER@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/bier > > > > > > > > > > -- > > > > > --- > > > > > tte@cs.fau.de > > > > > > > > > > _______________________________________________ > > > > > BIER mailing list > > > > > BIER@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/bier > > > > > > > > > > > > > > > > > > > > > > > > > > > ---------- > > > _______________________________________________ > > > BIER mailing list > > > BIER@ietf.org > > > https://www.ietf.org/mailman/listinfo/bier > > > > > -- > --- > tte@cs.fau.de > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier -- --- tte@cs.fau.de From nobody Sat Feb 29 01:26:04 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32DFF3A0D1A for ; Sat, 29 Feb 2020 01:26:03 -0800 (PST) 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, 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 AM9otUEpvpNr for ; Sat, 29 Feb 2020 01:25:59 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9964A3A0D17 for ; Sat, 29 Feb 2020 01:25:58 -0800 (PST) Received: from [192.168.1.6] (unknown [119.94.165.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 853913647AE; Sat, 29 Feb 2020 10:25:51 +0100 (CET) To: Toerless Eckert Cc: Lou Berger , gjshep@gmail.com, "Jeffrey (Zhaohui) Zhang" , "bier@ietf.org" References: <11ab30da-8701-b491-6162-5a69aa9d6965@labn.net> <20200221184542.GA20521@faui48f.informatik.uni-erlangen.de> From: Loa Andersson Message-ID: <0f0745ca-530c-5a9b-0f6c-323aa0338db3@pi.nu> Date: Sat, 29 Feb 2020 17:25:48 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200221184542.GA20521@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch 1 WEEK X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 09:26:03 -0000 Toerless, et.al., I think 2 (or maybe 3 discussions are mixed. 1. Soliciting input on a) which working that will progress the document; and b) which working that should be kept in the loop I don't have any serious concerns over this part of the process, as a note I'd like to add the the MPLS wg is chartered to do Traffic Engineering work in the packet domain. Indicating that MPLS should be kept in the loop and the work flagged to MPLS around IETF 101. 2. The content of the document I see convergence on this and think that if this discussion is allowed conclude the issues (most resource allocation) will be resolved. The number of people from the MPLS wg that are subscribed to the bier-list is sufficient to bring MPLS wg point of views into the discussions. One development I don't want to see is that we start using concepts that have been established and used for a long time in other wg's to be used for something different in other wg's. 3. What should happen at wglc. When the wglc call is started and closed, the working groups that have en interest in the documnent should be notified. If the overlap is substantial we should consider last call the document in more than one wg. I have not seen this happen for this document, /Loa On 22/02/2020 02:45, Toerless Eckert wrote: > Hi Loa, > > On Fri, Feb 21, 2020 at 12:25:46PM +0800, Loa Andersson wrote: >> Authors, working group, >> >> Inline plz. > [lou's text...] >> chair hat off >> >> Personally I agree with Lou, plz add the resource allocation. >> >> chair hat on >> >> mpls wg chairs discussed this, and it is our opinion that this document >> should have been at lest flagged in mpls and teas, preferably a cross >> wg review should have been organized. > > The BIER-TE architecture was broadly disseminated @IETF101 with presentations > adjusted to the specific WG audience to both TEAS and DetNet. I also > posted a draft about the bier-te framework architecture that ultimately > was meant to go into TEAS and describe for example how bandwidth > resource allocation would happen on a controller in the same way > as it would for example for SR. > > I apologize for not having gone to MPLS, but before 101 i asked around > and was told TEAS was the appropriate place. nobody brought up a suggestion > to go to MPLS. Note that we did have other WGs/chairs interested in BIER-TE > reach out to BIER-WG by themselves (e.g.: from Roll). I think the people working > in SR and having an interest in multicast for example are well aware of > BIER/BIER-TE too. > > This is just WG last call, not IETF last call, so i'd certainly be > happy to come @107 to your WG and present on BIER-TE. Let me know. > > BIER-TE was from the beginning designed to be the variation of BIER > to support TE, but not the same all-in-one signaling that e.g.: RSVP-TE is. > If you understand the technology, i think it's clear why the > path engineering and resource management are two orthogonal > components of a modular solution. [ And we all know what happened to > RSVP-TE (all-in-one) when the mayority of users didn't leverage it's > resource allocation functionality. ] > > As you are probably not subscribed BIER mailing list, let me append > at the bottom the reply i sent to Lou and the list. Pls. read the new > section in the doc, and let me know if you have any further questions. > > Cheers > Toerless > > --- > > Thanks a lot, Lou > > [ Would have been nice if you could have commented a bit earlier. > But i can understand how a few years is not enough time ;-P > (actually no kidding, i really can.) ] > > Originally i had planned to address the explanations you are missing > in this doc in the BIER-TE traffic engineering framework document, > for which i had written the -00 version and presented at TEAS WG, IETF101, > but given how we first wanted to get BIER-TE out as RFC, i let that > expire, and in hindsight it's certainly useful to have a short > section summarizing this in the BIER-TE RFC itself: > > So, I just pushed -06 of the draft to address your concerns with > additional explanations. > Summary below, diff here: > > http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-bier-te-arch-05.txt&url2=https://tools.ietf.org/id/draft-ietf-bier-te-arch-06.txt > > - Title changed from "Traffic Engineering for..." to "Path Engineering > for...", but kept name BIER-TE (see below). > > - Added section 1.1 explaining how BIER-TE relates to traffic > engineering, naming use-cases where its for example beneficial standalone and > and what it could be combined with for more comprehensive TE solutions, > but also stating that those integrations are outside the scope of this > document. > > - changed "traffic engineering" term in the whole doc to "path engineering", > where appropriate. > > - Unrelated to you, there was one leftover fix from ietf106 review to rename BIER-TE > Controller Host to just BIER-TE Controller > > Wrt to naming: > > The mayority of customers i talked to only used RSVP-TE for path > engineering, and not for anything more. Several didn't even know it > can do bandwidth reservation. Nobody knew it could do latency > guarantees, because nobody knows an implementation that supports that. > [All reasons btw. why replacing RSVP-TE with SR happened in the industry.] > > In any case, the name BIER-TE was selected to reduce confusion > with customers, not to maximize naming correctness in IETF. > Something like "BIER-PE" (Path Engineering) would have > probably confused more than it would have helped. Think > of the justification for the name BIER-TE not as > "all you need to do TE", but "the variation of BIER to support TE". > > Wrt to SR: > > SR can actually NOT do the same as BIER-TE. It has no stateless multicast. > All the SR options do really require that you set up multicast trees with > e.g.: replication-SIDs that together form the equivalent of a > multicast tree, like you would have built with RSVP-TE. Except that > the signaling how to build the tree is left for someone else, like > PCECC. (AFAIK, i may not be on top of all details). In BIER-TE, > there is no such per-tree state on transit nodes. > > Instead of a 256 bit bitstring in BIER-TE think of a header with up to 256 SIDs > (e.g.: 128 bit per SID in SRv6). That would be the SR equivalent of BIER-TE. > Just a bit less ( ;-) ) less efficient on the wire than BIER-TE and extremely > harder to parse. > > Cheers > Toerless > > > On Wed, Feb 19, 2020 at 06:38:38PM -0500, Lou Berger wrote: >> Hi, >> >>     I have no issue or objection to the mechanisms being defined in this >> document as much as they go, but I was quite disappointed that despite the >> name of the document and use of 'bier-te'  to see that the document doesn't >> define any traffic engineering support, at least as far as the term has been >> used in IETF RFCs.  In particular it totally lacks any discussion of >> resources usage and/or allocation.  What it currently describes certainly >> provides good and useful path/traffic steering that can be used to support >> policy-based routing.  Basically it does the same as what is defined by >> draft-ietf-spring-segment-routing-policy. >> >> I personally (not speaking for the related WGs that I chair) would prefer to >> see this document be revised  to include resource allocation that would >> allow BIER-TE to support TE usage such as DetNet.  Barring such an addition, >> I'm against publication of this document as is and I think the document >> should be recast and renamed to be aligned with the SR example, i.e., BIER >> routing policy (or path steering). >> >> Lou >> >> On 2/18/20 3:45 PM, Greg Shepherd wrote: >>> Thanks Toerless and Jeffrey >>> >>> https://datatracker.ietf.org/doc/draft-ietf-bier-te-arch/ >>> >>> One more week of WGLC. Please read the latest rev and respond to this >>> thread w/wo support. >>> >>> Chairs >>> (Shep) >>> >>> >>> On Tue, Feb 18, 2020 at 12:07 PM Jeffrey (Zhaohui) Zhang >>> >> > wrote: >>> >>> Hi Toerless, >>> >>> Thanks! >>> I support moving this to the next stage. >>> >>> Jeffrey >>> >>> On Fri, Nov 01, 2019 at 07:42:38PM +0100, Toerless Eckert wrote: >>> > Thanks Jeff >>> > >>> > I have now pushed out -05 with the answers and hopefully >>> resolution to >>> > your points in email below.  Biggest addition was a section about >>> > reuse of BPs (without DNR) which came out of the confusion i >>> think the >>> > reuse in the ECMP example raised. I was afraid so far to explan >>> that >>> > as it may not be easy to absorb and ultimately is stuff only >>> > controller developers need to understand, but hopefully useful. >>> > And then of course the summary of BP optimizatins you asked for >>> > >>> > Diff from last version i sent you: >>> > >>> > >>> https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: >>> > **Araw.githubusercontent.com >>> *toerless*bier-te-arch*master*draft-ietf-b >>> > ier-te-arch-05.1.txt&url2=http:**Atools.ietf.org >>> *id*draft-ietf-bier-te >>> > >>> -arch-05.txt__;Ly8vLy8vLy8vLy8!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzH >>> > OCr0fZkLPbgg3CPNu0PyrWsrFx41_jWX2At8V-$ >>> > >>> > full -04 -> 05 diff: >>> > >>> > >>> https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=http:* >>> > *Atools.ietf.org >>> *id*draft-ietf-bier-te-arch-04.txt&url2=http:**Atools. >>> > ietf.org >>> *id*draft-ietf-bier-te-arch-05.txt__;Ly8vLy8vLy8v!!NEt6yMaO-gk >>> > !VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx41_jWancpziv$ >>> > >>> > Comments inline below. >>> > >>> > Cheers >>> >     toerless >>> > >>> > On Mon, Oct 28, 2019 at 07:52:59PM +0000, Jeffrey (Zhaohui) >>> Zhang wrote: >>> > > I Thought u-turn is the most simple comparison leaf vs. >>> non-leaf BFR. >>> > > >>> > > Zzh> The text in the email is seriously misaligned. Looking at >>> the picture in the diff link, while you gave a U-turn example, >>> though even if BFER2 is not connected to BFR2  but only connected >>> to BFER1 (hence no U-turn), then BFER1 is still not a leaf BFER I >>> suppose. That's why I said the first sentence of the above >>> paragraph is enough to define Leaf BFER while the example itself >>> is actually not needed. >>> > >>> > Argh... ok, had to fix two words, BFIR->BFER and left-hand -> >>> right-hand: >>> > >>> > Consider how redundant disjoint traffic can reach BFER1/BFER2 in >>> above >>> > picture: When BFER1/BFER2 are Non-Leaf BFER as shown on the >>> right hand >>> > side, one traffic copy would be forwarded to BFER1 from BFR1, >>> but the >>> > other one could only reach BFER1 via BFER2, which makes BFER2 a >>> > non-Leaf BFER. Likewise BFER1 is a non-Leaf BFER when forwarding >>> > traffic to BFER2 >>> > >>> > > Zzh> Additionally, in left part of the picture you added, if >>> some failure leads to BFR2 to be only reachable via BFER1, then >>> BFER1 is no longer a leaf BFER. >>> > >>> > Added sentence: >>> > >>> > Note that the BFER in the left hand picture are only >>> guaranteed to >>> > be leaf-BFR by fitting routing configuration that prohibits transit >>> > traffic to pass through a PE, which is commonly applied in these >>> > topologies. >>> > >>> > > I assume you don't reassign BPs when links go up and down. >>> > >>> > I didn't want to discuss that option in this document. Its >>> obviously >>> > perfectly feasible, but be yet a big amount of text (especially the >>> > considerations how to do this make-before-break. Future doc. >>> > >>> > > > but subsequent polarization example confuses me. It seems >>> that BP 0:6 is assigned to the routed adjacency BFR10 (which is >>> actually talked about in Section 4.8). >>> > > >>> > > Section 4.7 does not mention "routed" at all, so there are no >>> routed adjacencies at all used in 4.7. So i am not sure what you >>> are confused about. >>> > > >>> > > Zzh> "The BIFT of each BFR are only populated with BPs that >>> are adjacent to the BFR in the BIER-TE topology". >>> > >>> > Correct text from the introduction. Ok. >>> > >>> > > Zzh> Since the same 0:6 is in BIFTS of BFR1/BFR2/BFR3 (and I >>> suppose in BFR4~BFR9 as well even though not drawn), I assumed >>> it's for the "MP2P" routed adjacency to R10; though I then ruled >>> that out - but I don't know what 0:6 represent now on BFR1, BFR2, >>> and BFR3. >>> > >>> > Ah. Ok. I thought i could strip down the example to show only the >>> > adjacencies relevant to the following discusion, but seemingly this >>> > can introduce the confusion you have. >>> > >>> > So i completed the example with the BP assignment acoss all >>> nodes, but >>> > added text pointing to a new section further down to discuss the >>> > re-use of BP for which thi picture is also an example. >>> > >>> > (check out the diff, new reuse text to long to copy inline). >>> > >>> > > The whole purpose of the ECMP BPs is of course to save bits, >>> otherwise we'd give each link a separate BP, which would be 6 BP >>> to reach to BFR4...BFR7 from BFR1. >>> > > >>> > > Zzh> The trouble I am having is that the same 0:6 is assigned >>> to different things and it's present on all BFR1/BFR2/BFR3. It is >>> perhaps an intentional smart design but I have not wrapped my mind >>> around it. It's apparently different from the link bundle case, so >>> better separate it out and elaborate it (including the DNR flag >>> that might be needed here - If the packet arrives on BFR1 with >>> 0:6, would the BP reset when it is sent to BFR2/3)? >>> > >>> > Yes, there was the bug of reusing BP 0:6 across sequential BFR >>> along >>> > the path, but now the example correctly reuses separate BP at >>> > different stages of the paths (BP 0:6 on BFR1, BP 0:7 on >>> BFR2/BFR3) and so on. >>> > >>> > Thanks! >>> > >>> > > > 4.8.  Routed adjacencies >>> > > > >>> > > > If I understand it correctly, there is a BP assigned to >>> L1/L2/L3 >>> > > > respectively (p2p link), and then there are BPs assigned to >>> MP2P tunnels (routed adjacency from every BFR) to the L1/L2/L3 >>> interface addresses and loopback addresses on BFR2/3. >>> > > >>> > > Ok that wasn't quite the read i expected. Let me clarify the >>> text/picture: >>> > > >>> > >                    ............... >>> > >          ...BFR1--...           ...--L1-- BFR2... >>> > >                   ... .Routers. ...--L2--/ >>> > >          ...BFR4--...           ...------ BFR3... >>> > >                    ...............         | >>> > >                                           LO >>> > >                     Network Area 1 >>> > > >>> > > Assume the requirement in the above picture is to explicitly >>> steer traffic flows that have arrived at BFR1 or BFR4 via a >>> shortest path in the routing underlay "network area 1" to one of >>> the following three next segments: (1) BFR2 via link L1, (2) BFR2 >>> via link L2, (3) via BFR3. >>> > > >>> > > To achieve this, both BFR1 and BFR4 are set up with a >>> forward_routed adjacency BitPosition towards an address of BFR2 on >>> link L1, another forward_routed BitPosition towards an address of >>> BFR2 on link L2 and a third forward_routed Bitposition towards a >>> node address LO of BFR3. >>> > > >>> > > Does this clear ip the confusion ? >>> > > >>> > > Zzh> The picture is badly misaligned. I'll wait till 4.7 >>> questions are cleared. >>> > >>> > Ok. >>> > >>> > > > If BFR2/3 are also BFERs, then they additionally will have >>> BFER BPs. >>> > > > On BFR1/4, the BIFT entries for the MP2P BPs for the >>> L1/L2/L3/loopback interface addresses of BFR2/3 will use >>> forward_routed(interface/loopback address). For a packet to be >>> decapsulated on a BFER, there is a need for both the BFER BP and >>> another BP (p2p/lan/hub-spoke/routed-adjacency) in the packet (the >>> former is for decapsulation and the latter is for getting it there). >>> > > >>> > > This is not discussed in this section, but you are right - unless >>> > > BFR2 or BFR3 is a leaf BFR. In that case, it would just >>> leverage the one shared "leaf-BFR" BP, so they do not need a >>> per-BFER BP for local_decap(). >>> > > >>> > > Zzh> Right - shared leaf-BFR BP but still need that BP (the >>> key is that we need a BP to get packet to a BFER and then a BP for >>> decapsulation). >>> > >>> > You got it. >>> > >>> > > > If that???s the case, it???s worth point the above out. >>> > > >>> > > Hmm... The logic of BFER BPs is totally independent of the >>> logic of forward_routed adjacency, so i would worry that repeating >>> the explanation of BFER BPs would conflate the forward_routed >>> explanation. >>> > > >>> > > Zzh> It's just that this is a place where all kinds of BPs are >>> used so it's good to have a summary (could be a subsection 4.9). >>> > >>> > Yes, added such a summary. Pls. check. >>> > >>> > > > Actually, the reason that I thought this is MP2P is that 0:6 >>> is present on R1, R2, and R3 (and more I assume) in Figure 12, but >>> now I think it can???t be MP2P (so it is not correct to have 0:6 >>> present on those routers ??? only the p2p tunnel head/tail should >>> have the BP present in the BIFT). The reason is that if it were >>> MP2P, any router getting a copy will send it to the endpoint of >>> the routed adjacency, causing lots of duplicates. >>> > > > >>> > > > Am I getting this correct? >>> > > >>> > > I think you are still explaining from the misunderstsanding >>> that the ECMP explanations where about routed adjacencies. >>> > > >>> > > I have now expanded the somewhat terse text in the BIFT table >>> pictures, to make it clear that the ECMP is across multipe >>> forward_connected adjacencies in the examples. For example, first >>> BIFT picture: >>> > > >>> > >   BIFT entry in BFR1: >>> > > >>>  ------------------------------------------------------------------ >>> > >   | Index |  Adjacencies                  | >>> > > >>>  ================================================================== >>> > >   | 0:6   |  ECMP({forward_connected(L1, BFR2),                 | >>> > >   |       |        forward_connected(L2, BFR2),                 | >>> > >   |       |        forward_connected(L3, BFR2)}, seed) >>>      | >>> > > >>>  ------------------------------------------------------------------ >>> > > >>> > > Of course, an ECMP adjacency can be across any type of >>> adjacencies, but all the text/explanations used forward_connected, >>> and now the pictures show that explicitly. >>> > > >>> > > Zzh> I can understand the multi-link case, but the multi-hop >>> ECMP case (from BFR1 towards BFR10) is confusing me. It would help >>> to give an example how it can be used, WITHOUT worrying about >>> polarization. >>> > >>> > Please check -05 text that has the full set of BIFT listed now: >>> > >>> > There is  really nothing nothing unique in multi-hop ECMP for >>> BIER-TE >>> > that we do not also have in any other ECMP, except the >>> conclusion that >>> > we want to support fast HW hash mechanisms AND allow the >>> controller to >>> > set up non-polarized multi-hop ECMP AND be able to precalculate >>> paths. >>> > Hence the specification of ECMP adjacencies to have a controller >>> > configurable seed. >>> > >>> > Btw: The picture is maybe unnecessarily large because i've used >>> it for >>> > 20 years to explain the same polarization issue for unicast vs >>> > multicast, and for multicast only BFR10...BFR4 are relevant >>> (ECMP of >>> > the PIM/mLDP joins), whereas for unicast/BIER only >>> > BFR1...BFR7 are relevant. But being symmetric, the picture makes it >>> > clear its the same problem. >>> > >>> > > >    To inhibit looping in the face of such physical >>> misconfiguration, >>> > > >    only forward_connected adjacencies are permitted to have >>> DNR set, and >>> > > >    the link layer destination address of the adjacency >>> (e.g.  MAC >>> > > >    address) protects against closing the loop.  Link layers >>> without port >>> > > >    unique link layer addresses should not be used with the >>> DNR flag set. >>> > > > >>> > > > It???s not clear how link layer address helps? >>> > > >>> > > I have expanded this to >>> > > "link layer port unique unicast destination address" >>> > > >>> > > Aka: MPLS or ethernet have unique link layer destination >>> destination addresses (label or destination MAC). If you think >>> about incorrectly plugged HDLC links (such as old T1/T3/... >>> links), they only have 2 generic addresses, if i remember 1 or 3 >>> in the HDLC frame. So when you misplug one of those p2p cables >>> wrong, the packets would be incrrectly received by the wrong >>> receiver node and then DNR could cause persistent loops only >>> solved by TTL. >>> > > >>> > > Zzh> "Consider in the ring picture that link L4 from BFR3 is >>> plugged into the L1 interface of BFRa" - still not sure how >>> label/mac helps here. I suppose the ring topology is >>> discovered/verified by the control plane and when the miscalling >>> happens then the ring will not include the BFR1/BFR2 part and BFR3 >>> will not have the DNR set? If ring discovery/varication is not >>> done then perhaps we should point out that RPF based on link layer >>> address is needed - the key is RPF (which needs unique link layer >>> address)? >>> > >>> > Forget RPF. BIER(-TE) has no RPF (issues). Its just like >>> unicast. RPF >>> > is just a problem for receiver originated joins like in >>> PIM/mLDP, but >>> > not unicast/bier(-te)/RSVP-TE. >>> > >>> > Forward_connected is just like a unicast subnet adjacency to a >>> direct >>> > neighbor: Interface and L2 addresss of the destination. >>> > >>> > The controller (could be a human) "assumes" a particular physicial >>> > topology, from telemetry/knowledge/whatever. It then calculates the >>> > desired BIER-TE topology and pushes it down. This topology is >>> meant to >>> > be loop free of course wrt to the configured adjacencies. >>> > In this BIER-TE topology, BFR3 will have a BP with the >>> > forward_connected(L4, MAC-of-BFR2) adjacency. >>> > >>> > If the cable connecting to L4 is miswired, then BFR3 would still >>> send >>> > the packets to the MAC address of BFR2, but given how the cable >>> > connects to some other node, these packets will be discarded by >>> that >>> > node. because they're just L2 unicast packets. >>> > >>> > I think this is equally true when we have normal BIER/MPLS enacp. >>> > Those packets too are addressed to the unicast MAC address of the >>> > neighbor. >>> > >>> > Now, if/when he controller recognizes that the physical topology >>> has >>> > changed, thats a completely different story and not addressed here. >>> > Given how we assumed this was a cabling mistake, the controller >>> would >>> > probably only complain about the miswiring to operations but be >>> happy >>> > that the forwarding plane just makes packets fail instead of >>> loop. If >>> > this was a planned change process, then it will be similarily >>> > convoluted as it would today be with rewiring cables in an >>> > SR-MPLS/SRv6 topology and updating SIDs. >>> > >>> > > > Because the forwarding is different from BIER forwarding >>> (because of [1] above), we might as well introduce an optimization >>> here ??? for each BIFT, calculate the F-BM of the BIFT itself (the >>> logical ???or??? of all the BPs presented in this BIFT) and then >>> use (packet->bitstring & BIFT.F-BM) as the input to >>> GetFirst/NextBitPosition(). That should skip many bits. >>> > > >>> > > Right. But i explicitly removed those optimizations (i had >>> them in older draft versions) because the whole idea of this >>> picture is solely the comparison with figure 4 of RFC8279. >>> > > >>> > > Zzh> I think it's worth point that optimization out; you can >>> mark it optional if you want to emphasize the similarity to BIER >>> forwarding, but since BIER forwarding does do the maskoff step, it >>> is very efficient while BIER-TE forwarding does not it the maskoff >>> step so this optimization is important. >>> > >>> > Ok. I simplified the text comparison BIER/BIER-TE wrt. to the FBM >>> > rules [1] and [2] and added following paragraph: >>> > >>> > In BIER, the order of BPs impacts the result of forwarding >>> because of [1]. >>> > In BIER-TE, forwarding is not impacted by the order of BPs. It is >>> > therefore possible to further optimize forwarding than in BIER. For >>> > example parallelizing forwarding across multiple FPE cores or >>> > distributed linecards does only need to examine an arbitrary >>> subset of >>> > BP and not evaluate the dependency between BPs. >>> > >>> > > >    The following pseudocode is comprehensive: >>> > > > >>> > > > The above sentence reads a bit strange (or lacks some segue). >>> > > >>> > > I hope not, but maybe best left to a native english speaker >>> (RFC-editor). >>> > > >>> > > The first (RFC8279) pseudocode was simplified. The second one >>> is comprehensive. If not comprehensive, whats a good opposite of >>> simplified ? >>> > > >>> > > Zzh> Perhaps "The above simplified pseudocode is elaborated >>> further as following"? >>> > > Zzh> Jeffrey >>> > >>> > Done. >>> > >>> > Thanks a lot. >>> > >>> > >>> > > >>> > > > ________________________________________ >>> > > > From: BIER [bier-bounces@ietf.org >>> >> >] >>> > > > on behalf of Toerless Eckert [tte@cs.fau.de >>> >] >>> > > > Sent: Tuesday, July 09, 2019 23:38 >>> > > > To: Mike McBride >>> > > > Cc: Greg Shepherd; BIER WG; Pascal Thubert (pthubert) >>> > > > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch >>> > > > >>> > > > Thanks, Mike >>> > > > >>> > > > The authors also reviewed the document and concluded that it >>> was >>> > > > really hard to get into the document context because of too >>> many >>> > > > forward dependencies. We tried to fix this by adding two >>> hopefully >>> > > > good & basic examples into the Introduction section and >>> using them >>> > > > to also add a better definition of the term "BIER-TE >>> Topology" in the Introduction. >>> > > > Hopefully this makes readin the rest of te document smoother. >>> > > > >>> > > > Also improved text of Abstract and refined text compariing >>> BIER-TE with SR. >>> > > > >>> > > > >>> https://urldefense.com/v3/__http://tools.ietf.org/*rfcdiff?url1=https: >>> > > > **Atools.ietf.org >>> *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A >>> > > > tool >>> > > > s.ietf.org >>> *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R >>> > > > jC81 >>> > > > >>> c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV_eTUEh >>> > > > $ >>> > > > >>> >> > > > **Atools.ietf.org >>> *id*draft-ietf-bier-te-arch-02.txt&url2=https:**A >>> > > > tool >>> > > > s.ietf.org >>> *id*draft-ietf-bier-te-arch-03.txt__;Ly8vLy8vLy8v!8WoA6R >>> > > > jC81 >>> > > > >>> c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sNd1njcX >>> > > > $> >>> > > > >>> > > > Cheers >>> > > >     Toerless >>> > > > >>> > > > On Wed, Jun 26, 2019 at 10:39:36AM -0700, Mike McBride wrote: >>> > > > > How about three? I support. >>> > > > > mike >>> > > > > >>> > > > > On Tue, Jun 25, 2019 at 10:42 AM Greg Shepherd >>> >> >> >> wrote: >>> > > > > > >>> > > > > > We cannot take two 'yes' votes and WG consensus. >>> > > > > > Please, read and respond. If you don't support, then >>> please vote as much publicly right here. >>> > > > > > >>> > > > > > Thanks, >>> > > > > > Greg >>> > > > > > >>> > > > > > On Mon, Jun 3, 2019 at 10:05 PM Pascal Thubert >>> (pthubert) >> >> >> wrote: >>> > > > > >> >>> > > > > >> Support: >>> > > > > >> >>> > > > > >> I see great value in deterministic networks as well as >>> IOT (with RPL). >>> > > > > >> >>> > > > > >> All the best, >>> > > > > >> >>> > > > > >> Pascal >>> > > > > >> >>> > > > > >> > -----Original Message----- >>> > > > > >> > From: BIER >>> > > > > >> > >> >> >> On >>> > > > > >> > Behalf Of Toerless Eckert >>> > > > > >> > Sent: mardi 4 juin 2019 02:03 >>> > > > > >> > To: Greg Shepherd >>> > > > > >> > >> >> >> >>> > > > > >> > Cc: BIER WG >> >> >>> > > > > >> > Subject: Re: [Bier] WGLC - draft-ietf-bier-te-arch >>> > > > > >> > >>> > > > > >> > +1 >>> > > > > >> > Obviously support as co-author. >>> > > > > >> > >>> > > > > >> > On Wed, May 29, 2019 at 12:41:26PM -0700, Greg >>> Shepherd wrote: >>> > > > > >> > > Please read and respond to this thread w/ or w/o >>> support. >>> > > > > >> > > >>> > > > > >> > > >>> https://urldefense.com/v3/__https://datatracker..ietf.org >>> > > > > >> > > /doc >>> > > > > >> > > >>> /draft-ietf-bier-te-arch/__;!8WoA6RjC81c!XvH4AAxfrDjFoK_s >>> > > > > >> > > ercw ZMsc0O5N42eENOs4l_qdsXF0KwZD82cJLDFFNV9eClBj$ >>> > > > > >> > > >>> >> > > > > >> > > doc/ >>> > > > > >> > > >>> draft-ietf-bier-te-arch/__;!8WoA6RjC81c!UBTGvWWpMHyeiSanx >>> > > > > >> > > s6vI b_EnBVgyg6boAAW4nrqju8UCLOgiuXc8Y_6sD40kmtH$> >>> > > > > >> > > >>> > > > > >> > > Vote ends 5 June 2019. >>> > > > > >> > > >>> > > > > >> > > Thanks, >>> > > > > >> > > Shep >>> > > > > >> > > (chairs) >>> > > > > >> > >>> > > > > >> > > _______________________________________________ >>> > > > > >> > > BIER mailing list >>> > > > > >> > > BIER@ietf.org >>> > >>> > > > > >> > > >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/ >>> > > > > >> > > list >>> > > > > >> > > >>> info/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eE >>> > > > > >> > > NOs4 l_qdsXF0KwZD82cJLDFFNT2WVXWX$ >>> > > > > >> > > >>> >> > > > > >> > > list >>> > > > > >> > > >>> info/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6b >>> > > > > >> > > oAAW 4nrqju8UCLOgiuXc8Y_6sKn2KoAT$> >>> > > > > >> > >>> > > > > >> > _______________________________________________ >>> > > > > >> > BIER mailing list >>> > > > > >> > BIER@ietf.org >>> > >>> > > > > >> > >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/li >>> > > > > >> > stin >>> > > > > >> > >>> fo/bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4 >>> > > > > >> > l_qd >>> > > > > >> > sXF0KwZD82cJLDFFNT2WVXWX$ >>> > > > > >> > >>> >> > > > > >> > stin >>> > > > > >> > >>> fo/bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW >>> > > > > >> > 4nrq >>> > > > > >> > ju8UCLOgiuXc8Y_6sKn2KoAT$> >>> > > > > > >>> > > > > > _______________________________________________ >>> > > > > > BIER mailing list >>> > > > > > BIER@ietf.org >>> > >>> > > > > > >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listi >>> > > > > > nfo/ >>> > > > > > >>> bier__;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsX >>> > > > > > F0Kw >>> > > > > > ZD82cJLDFFNT2WVXWX$ >>> > > > > > >>> >> > > > > > nfo/ >>> > > > > > >>> bier__;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju >>> > > > > > 8UCL >>> > > > > > OgiuXc8Y_6sKn2KoAT$> >>> > > > >>> > > > -- >>> > > > --- >>> > > > tte@cs.fau.de >> > >>> > > > >>> > > > _______________________________________________ >>> > > > BIER mailing list >>> > > > BIER@ietf.org >> > >>> > > > >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ >>> > > > bier >>> > > > >>> __;!8WoA6RjC81c!XvH4AAxfrDjFoK_sercwZMsc0O5N42eENOs4l_qdsXF0KwZD82 >>> > > > cJLD >>> > > > FFNT2WVXWX$ >>> > > > >>> >> > > > bier >>> > > > >>> __;!8WoA6RjC81c!UBTGvWWpMHyeiSanxs6vIb_EnBVgyg6boAAW4nrqju8UCLOgiu >>> > > > Xc8Y >>> > > > _6sKn2KoAT$> >>> > > >>> > > -- >>> > > --- >>> > > tte@cs.fau.de >>> > >>> > -- >>> > --- >>> > tte@cs.fau.de >>> > >>> > _______________________________________________ >>> > BIER mailing list >>> > BIER@ietf.org >>> > >>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bier >>> > >>> __;!!NEt6yMaO-gk!VuQCVHnqJy_aYI-FNt9A1a5EzHOCr0fZkLPbgg3CPNu0PyrWsrFx4 >>> > 1_jWV3YUA6D$ >>> >>> -- >>> --- >>> tte@cs.fau.de >>> >>> _______________________________________________ >>> BIER mailing list >>> BIER@ietf.org >>> https://www.ietf.org/mailman/listinfo/bier >>> > >> _______________________________________________ >> BIER mailing list >> BIER@ietf.org >> https://www.ietf.org/mailman/listinfo/bier > > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64 From nobody Sat Feb 29 01:37:10 2020 Return-Path: X-Original-To: bier@ietfa.amsl.com Delivered-To: bier@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E86A63A0D33 for ; Sat, 29 Feb 2020 01:37:08 -0800 (PST) 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, 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 D6CnPaYBUZ04 for ; Sat, 29 Feb 2020 01:37:07 -0800 (PST) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C4233A0D40 for ; Sat, 29 Feb 2020 01:37:07 -0800 (PST) Received: from [192.168.1.6] (unknown [119.94.165.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 30F6D3647B0 for ; Sat, 29 Feb 2020 10:37:04 +0100 (CET) To: bier@ietf.org References: <20200227204038.GB23965@faui48f.informatik.uni-erlangen.de> <20200227204357.GA35999@faui48f.informatik.uni-erlangen.de> From: Loa Andersson Message-ID: <2cb66c61-3f08-494d-73db-e7e9010b708a@pi.nu> Date: Sat, 29 Feb 2020 17:37:01 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0 MIME-Version: 1.0 In-Reply-To: <20200227204357.GA35999@faui48f.informatik.uni-erlangen.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Bier] Pls "vote" on name (draft-ietf-bier-te-arch) X-BeenThere: bier@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "\"Bit Indexed Explicit Replication discussion list\"" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 09:37:09 -0000 Working Group, Of the proposals below I feel most comfortable with BIER-ET. /Loa On 28/02/2020 04:43, Toerless Eckert wrote: > 2 BIER-PE - Path Engineering > 5 BIER-ET - Explicit Trees > 3 BIER-EET - Explicit Engineered Trees > 4 BIER-BET - Bit Engineered Trees > 3 BIER-BST - Bit Steered Trees > 2 BIER-TrE - Tree engineering > 3 BIER-ET - Engineered Trees > 2 BIER-ST - Steered Trees > > 2 BIER-ASB - Adjacency Steering Bits (adjacencies are how bits in BIER-PE are defined) > BIER-AB - Adjacency Bits > BIER-SB - Steering Bits (overloads with "Source Block" - never heard) > > I prefer Explixit Trees because it is indicative of what is > signalled(trees), and it nicely doubles down as a name > Bit Indexed Explicit Replication, Explixit Trees > > _______________________________________________ > BIER mailing list > BIER@ietf.org > https://www.ietf.org/mailman/listinfo/bier > -- Loa Andersson email: loa@pi.nu Senior MPLS Expert Bronze Dragon Consulting phone: +46 739 81 21 64